- Apple iPhone 16 Pro - rutinvizsga
- Hammer 6 LTE - ne butáskodj!
- Honor 400 Pro - gép a képben
- Galaxy Z Fold6-hoz viszonyítva mutatják, mennyivel lesz vékonyabb a Z Fold7
- iPhone topik
- MIUI / HyperOS topik
- Okosóra és okoskiegészítő topik
- Erős specifikáció, kompakt formában
- Xiaomi 15 Ultra - kamera, telefon
- Milyen okostelefont vegyek?
Új hozzászólás Aktív témák
-
#2200
Sk8erPeter
nagyúr
fordfairlane
#2198
Sk8erPeter
nagyúr
válasz
fordfairlane
#2198
üzenetére
Ez úgy emlékszem, hogy huzamosabban inkább csak az IE (talán még 9-esig?) esetén volt probléma, hogy rakott egy felesleges bordert önkényesen a képek köré, amikor senki nem kérte rá, de nincs már ez a probléma egy ideje igazából egyik említésre méltó böngészőnél sem. Az Edge, IE11, az aktuális Blink-alapú böngészők (Chrome, Opera, Vivaldi), illetve a Firefox sem rak a képek köré bordert, és így lefedtük a "normálisabb" böngészők körét (a Faszarit meg direkt nem említettem
![;]](//cdn.rios.hu/dl/s/v1.gif)
).(#2196) pckownz:
Hát ja, ez a selector csak arra az oldalra volt érvényes, ahol teszteltem.
(Konkrétan Index egyik cikkénél volt egy "Ajánlom" gomb, ott próbáltam ki.)
Ilyenkor első, hogy meg kell nyitni a fejlesztői panelt, és ránézni, hogy egyáltalán érvényes-e a selector az adott elemre. Ha nem, akkor utána kell igazítani.(#2197):
"De ha már mobil böngészők, nemrég fedeztem fel ezt a debug módszert."
Nem rossz, hasznosnak tűnik! -
#2194
Sk8erPeter
nagyúr
pckownz
#2193
Sk8erPeter
nagyúr
válasz
pckownz
#2193
üzenetére
Ez a trükk oldja meg, tehát hogy a selectornál használod a [style] attribútum-meghatározást is (ezzel jelzed, hogy az adott elem rendelkezik a style attribútummal, és még specifikusabbá teszed a selectort), jelen esetben pl. span[style] lesz a jó megoldás:
#fb_like_bottom > span[style], fb\:like > span[style] {
vertical-align: top !important;
}
(igazából ugyanarra az elemre vonatkozik elvileg, csak több esetet is lefedtem, hátha máshol másképp jelenik meg) -
#2191
Sk8erPeter
nagyúr
pckownz
#2190
Sk8erPeter
nagyúr
válasz
pckownz
#2190
üzenetére
Relatív pozíciót adsz a fő szülőelemnek, majd a "fixen" pozicionálni kívánt elemeknek adsz egy közös osztályt, az az osztály pedig abszolút pozíciót kap, aztán meghatározod, hogy pontosan hol is jelenik meg (left, top, ilyesmi tulajdonságok). Lesd el pl. az általad belinkelt oldalról, esetleg keress Gugliban, tuti lesz erre is Stack Overflow-találat.
-
#2189
Sk8erPeter
nagyúr
pckownz
#2188
Sk8erPeter
nagyúr
válasz
pckownz
#2188
üzenetére
Ott, ahol jelenleg is van. Hozzáadtam egy collapsed osztályt, és kicsit bénácska példával megmutatom, hogy mi történik (béna, mert setTimeouttal buzerálom a collapsed osztályt, hogy lásd, de most jó az vidékre a normális megoldásig):
https://jsfiddle.net/6sjnj1g7/5/ -
#2187
Sk8erPeter
nagyúr
Sk8erPeter
#2186
Sk8erPeter
nagyúr
válasz
Sk8erPeter
#2186
üzenetére
Bocs, most néztem csak meg normálisan, elsőre benéztem a struktúrádat, az teljesen jónak tűnik, igazából pont olyan, amit javasoltam, szóval asszem feleslegesen koptattam az ujjamat, meg a billentyűzetemet, jól csináltad elsőre is.
Ha jól értem, csak az a baj, hogy el vannak csúszva a gyerekelemként definiált <ul> elemek, és azok beljebb tolódnak, emiatt csúnya lesz. De szólj, ha nem ez a gond.
Szóval alapból az <ul> elem kap egy bizonyos paddinget, emiatt mindig eleve beljebb tolódik, hacsak ezt nem nullázod ki egy saját stílusdefinícióval. Ezt a böngésző default stylesheetje definiálja, ezért szoktak "normalizáló", "resetelő" CSS-eket használni, hogy az ilyen alapértelmezett, böngésző által definiált stílusokat kiiktassák, és minden releváns stílus egyénileg meghatározott legyen. Szóval ha hozzáadsz egy padding-left: 0px; margin-left: 0px; stílust az <ul>-ekhez, akkor nincs eltolódás:
https://jsfiddle.net/6sjnj1g7/4/
Remélem, így értetted. (Hozzáadtam keretet az <ul>-ekhez, hogy jobban lásd, hol vannak a határok, ilyesmikkel érdemes játszani tesztelés erejéig.) -
#2186
Sk8erPeter
nagyúr
pckownz
#2184
Sk8erPeter
nagyúr
válasz
pckownz
#2184
üzenetére
Gondolom arra a részre gondolsz, ami lenyílik a fölső, horizontálisan rendezett menünél, amelynek a gyerekeleme (egy dima <div>) már több, vertikálisan megjelenő (mivel fölülről lefelé vannak ott már az elemek), de horizontálisan egymás mellé rendezett listából áll.
A példád nem jó ebben a formában, persze ez egyértelmű, de mondjuk olyan nagyon nem vágom, mit szerettél volna kihozni ebből.A lényeg: semmi mágia nincs benne, ilyesmi szerkezet:
<ul>
<li>Lorem ipsum dolor sit amet, consectetuer adipiscing elit.</li>
<li>
<a href="#">Aliquam tincidunt mauris eu risus.</a>
<div class="ez_lesz_a_lenyilo_gyerekelem">
<ul class="float_lefttel_egymas_melle_rendezve">
<li>Lorem ipsum dolor sit amet, consectetuer adipiscing elit.</li>
<li>Aliquam tincidunt mauris eu risus.</li>
</ul>
<ul class="float_lefttel_egymas_melle_rendezve">
<li>Lorem ipsum dolor sit amet, consectetuer adipiscing elit.</li>
<li>Aliquam tincidunt mauris eu risus.</li>
</ul>
<ul class="float_lefttel_egymas_melle_rendezve">
<li>Lorem ipsum dolor sit amet, consectetuer adipiscing elit.</li>
<li>Aliquam tincidunt mauris eu risus.</li>
</ul>
</div>
</li>
<li>Vestibulum auctor dapibus neque.</li>
</ul>Gondolom értelemszerű, hogy itt a példában a float_lefttel_egymas_melle_rendezve el lesz látva egy float: left; tulajdonsággal.
Az ez_lesz_a_lenyilo_gyerekelem osztállyal ellátott divet meg hoverre kéne előhozni, ez elvileg CSS-sel is megoldható, keress utána a dropdown menu CSS keresőszavakkal. (Természetesen sose legyen ilyen hülye nevű osztályaid, főleg ne magyarul, csak hogy érthető legyen a kód, itt azért alkalmaztam.) -
#2180
Sk8erPeter
nagyúr
pckownz
#2179
Sk8erPeter
nagyúr
válasz
pckownz
#2179
üzenetére
Attól lesz "csúnya", hogy több a hátránya, mint az előnye.
Az !important kulcsszó igazából arra való, hogy kierőszakold a Te stílus-meghatározásodat, hogy az legyen érvényes az adott elemre, ha a fene fenét eszik is. Téged nem érdekel, hogy más milyen stílust határozott meg valahol, legyen az a Te fájlod előtt vagy után, akkor is azt akarod, hogy az adott szöveg zöld legyen, és ne piros. (Igaz, ez egy másik !important szabállyal, ami ugyanerre az elemre vonatkozik, még így is felülbírálható.)
Na ezzel csak az a baj, hogy ennek nem így kellene működnie. A sorrendben legutóbb megjelenő (esetleg specifikusabb) stílus-meghatározásnak kellene érvényesülnie (amennyiben nem a szintén ocsmány style-attribútum segítségével bedrótozott megoldásokról van szó), hogy több fejlesztő is tudjon egymástól függetlenül is dolgozni, ne feltétlenül legyen szükséges mások fájljába belekontárkodni ahhoz, hogy a Te stílus-meghatározásod érvényesüljön. Bosszantó tud lenni, amikor kiderül, hogy bár Te jól definiáltad a stílust, kiderül, hogy valaki elintézte, hogy a tiéd ne legyen érvényes, mert ott az !important kulcsszó. Na és akkor ott a harc, hogy de Te pedig akkor is, és akkor Te is odacsapod az !important kulcsszót. Szóval ez így gázos.
Vannak esetek viszont, amikor nem tudsz jobbat - például épp az utóbb említett esetben, akár a Bootstrap alapvető szarait felülbírálva, vagy amikor böngésző-bővítményt fejlesztve szeretnél ráerőszakolni egy adott stílust valamilyen elemre (és mondjuk akár az oldalon alapból injektálódik később egy stíluslap, ami felülcsapná ezt a beállításodat, vagy bármi hasonló). -
#2178
Sk8erPeter
nagyúr
DNReNTi
#2176
Sk8erPeter
nagyúr
-
#2173
Sk8erPeter
nagyúr
#81999360
#2172
Sk8erPeter
nagyúr
válasz
#81999360
#2172
üzenetére
De ahhoz, hogy ezt a kódot alkalmazni tudd, igazából nem is kell értened a JavaScripthez különösebben, elég csak felületes tudás hozzá, hogy a script tagek közé bepakold a kódot, jelen esetben ezt:
http://jsfiddle.net/vagvL/40/
Ez az előzőnek a plain JavaScript verziója, jQuery nélkül, az ablak load eseményének elsülésekor fut le. -
#2171
Sk8erPeter
nagyúr
#81999360
#2170
Sk8erPeter
nagyúr
válasz
#81999360
#2170
üzenetére
Mármint miért vagytok ellenségek a JavaScripttel?
Az a webfejlesztésben nem túl szerencsés dolog.
Egyébként itt egy SO threadben azt írják, hogy lehet Tumblr-be is beágyazni saját scriptet:
http://stackoverflow.com/questions/20552391/javascript-on-individual-tumblr-post
Mellesleg a feladathoz nem kell persze jQuery, elég a plain JavaScript is, csak most így gyorsabb volt. -
#2169
Sk8erPeter
nagyúr
#81999360
#2168
Sk8erPeter
nagyúr
válasz
#81999360
#2168
üzenetére
CSS-sel ilyesmit sajnos nem lehet.
Lustaságból gyorsan rágugliztam, ez a regexp felületes ránézés alapján jónak tűnik, ez alapján itt egy gyorspélda jQuery-vel:
http://jsfiddle.net/vagvL/38/ -
#2154
Sk8erPeter
nagyúr
biker
#2153
Sk8erPeter
nagyúr
"Csak nem volt benne semmi olyan, amit tovább érdemes boncolgatni"
Korábban nem értetted, miért nem jó az, hogy a kliensoldallal generáltatod le a stylesheeteket (bár nem is értem, hogy ennyi év tapasztalat után hogy nem tudod ezt megfejteni, nem túl bonyolult képlet), látszólag azt sem vágtad, hogy van watch-lehetőség, aminek segítségével különösebb probléma nélkül a fejlesztés során is folyamatosan lehet legeneráltatni a LESS-ből a kész CSS-fájlokat, problémáztál a szerverre való feltöltésen, mondván, ez túl sok kör, és még a gyorsítótárazáson is keseregtél, valamint úgy tűnt, hogy nem is igazán találtál végső megoldást a gondjaidra. Akkor hogyhogy nem érdemes boncolgatni? Ilyen alapon minek tetted fel a kérdést?"A legtöbb kérdésre már írtam okfejtést"
Csak kimagyarázásokat láttam, hogy miért nem jó, amiket javasolunk, miért élsz inkább az eddig használt módszereiddel, de cáfold, ha nem így volt."Ami az általam használt editorhoz van plugin, az less>css ès css minify, de nincs egyben a kettő
"
És ki mondta, hogy feltétlenül az általad használt szövegszerkesztővel/fejlesztőeszközzel kellene generáltatni? Parancssorból ráküldöd a LESS watch-ot, meg a minify-oltatást, az meg csinálja a dolgát a háttérben, nem vagy a szerkesztődhöz kötve."Zipelősdi: a rendszer készítő azt találta ki, hogy az összes filet be kell zipelni, azt egy formon feltölteni, amit a rendszere használ utána vagy teszt, vagy élesben"
Imádom az ilyen retardált megoldásokat, amiknek értelme nincs, de még legalább jól el is bonyolítják a munkafolyamatot is... -
#2152
Sk8erPeter
nagyúr
biker
#2150
Sk8erPeter
nagyúr
Az én hsz.-emre nem reagáltál, miért?
Minify-olásra van lehetőség:
http://stackoverflow.com/questions/25579926/what-is-the-best-way-to-minified-output-css-from-lessHogy a zipelésre miért van szükség, azt ennyiből nem igazán értettem.
-
#2147
Sk8erPeter
nagyúr
biker
#2134
Sk8erPeter
nagyúr
Ez a fejlesztés szakaszában még elfogadható (de inkább nem, vagy csak kényszerhelyzetben, pl. ha (szerveroldali) előfeldolgozó épp nem áll a rendelkezésedre), productionben viszont tilos. Gondolj bele, mit is csinálsz ilyenkor: rábízod a kliensre, hogy a less.js fájlban található JavaScript-kód segítségével parse-old + előfeldolgozd a LESS-fájlodat/fájljaidat, átalakítsd a böngésző által elfogadható CSS-formátumba, majd injektáld a dokumentum head-részébe. Ez katasztrofálisan erőforrás-igényes. Szóval az a "3 kör futás" kell, bár nem kell, hogy ez olyan kényelmetlen legyen.
Érdemes lehet ezt úgy megoldani, hogy a LESS-fájlokat tartalmazó könyvtárat watch-olod az előfeldolgozóval, ami változtatás esetén azonnal legenerálja a szükséges CSS-fájlokat, és emellett folyamatosan szinkronizálod a CSS-fájlokat tartalmazó könyvtárat a távoli szerver könyvtárával (élő FTP-(vagy egyéb protokoll, mindegy)kapcsolatnál) - ez utóbbi például WinSCP-vel könnyedén megoldható (Linuxra és Macre is nyilván vannak alternatívák). Én pont ezt szoktam csinálni az SCSS/SASS-fájlokkal, már ha épp valamilyen oknál fogva nem tudok/akarok előbb MINDENT lokális környezetben tesztelni (de úgy illik!!), csak ez a kettő monitorozás kell, hogy fusson, észre sem veszed, viszont ha módosítasz a fájlon, elég gyorsan fent is van a szerveren a belőle legenerált CSS.A cache-ürítés a Ctrl+F5-ös módszer miatt meg ne legyen már akkora gond, ha magadnál teszteled, ha meg a megrendelő/más teszteli, akkor arra létezik más módszer is, hogy ne a korábban gyorsítótárazott fájlt kapja elő a böngésző.
Amit a (#2137)-ben írtál, hogy milyen hű de nagy a legenerált CSS, szemben a LESS-fájlokkal, amik sokkal kisebbek (tehát a logikád alapján jobb a less.js-sel feldolgozni a fájlokat), irreleváns, akkor sem a LESS-fájlt fogja olvasgatni a böngésződ, hanem a legenerált CSS-fájlt...
Mivel azt tudja. (És az most "mindegy" (kérdés, hogy tényleg mindegy-e, vagy lesz különbség, ugyanaz-e az előfeldolgozó minden tekintetben, bár gondolom alapvetően igen), hogy magát a CSS-fájlt szerveroldalon gyártod le, vagy a klienssel erőlködöd ki.)Szerk.: most látom Cathfaern (#2136)-os és fordfairlane (#2138)-as hsz.-ét, ők is jól és nálam kicsit rövidebben összefoglalták a lényeget.
-
#2108
Sk8erPeter
nagyúr
brickm
#2104
Sk8erPeter
nagyúr
"Nem ismerem konkrétan a bootstrap -et, de ahogy nézegetem a leírását, eléggé felesleges ennyire megbonyolítani egy sima passzív weblapot."
Ez így általánosságban természetesen nagyon nem igaz. Azt, hogy milyen mértékben segíti a munkádat egy ilyen frontend framework, a későbbiekben fogod igazán értékelni, amikor már érteni fogod a HTML és CSS működését mélyebben is. Kezdőként viszont jobb, ha végigjárod az utat, és kézzel rakod össze az oldalaidat, tényleg nem érdemes nekiesni egyből ilyen komplex állattal; később viszont nagyon jól fog jönni. -
#2076
Sk8erPeter
nagyúr
Zedz
#2073
Sk8erPeter
nagyúr
Az extensionös példa egyáltalán nem extrém. Nekem is vannak extensionjeim, amikkel átszabom az oldalak megjelenését, és ha lehet, akár komplikált selectorral, de inkább CSS-sel teszem, ez ugye hatékonyabb. Meg gondolom láttad ezt a threadet, a srác is pont ilyet próbált csinálni több elemre is a PH!-n.
A CMS-nél meg nem azt írtam, hogy "nem lehet" piszkálni a generált struktúrát, hanem hogy elképzelhető olyan eset, hogy gyors módosítást szeretnél eszközölni. (Szerk.: na most nézd meg DNReNTi hsz.-ét, akkor máris nem lesz ez sem extrém, pont erről beszéltem.)
De ahogy fordfairlane írta, lehet olyan eset is, hogy külső forrásból (webszolgáltatás, stb.) kapsz valamilyen tartalmat, amit mondjuk injektálsz az oldalba, vagy hasonló, és ennek a megjelenítését is szeretnéd testreszabni.(#2075) DNReNTi:
Na, pont ilyen példát írtam az előbb... Szóval csöppet sem volt extrém (csak nem CMS-ről, hanem frameworkről van szó, de tökéletesen mindegy). -
#2072
Sk8erPeter
nagyúr
Zedz
#2071
Sk8erPeter
nagyúr
Pedig lehet pár ilyen példát említeni, amikor valamilyen okból a generált/statikus HTML-kódba nem tudsz belenyúlni, mert meg van kötve a kezed, és csak CSS-sel vagy JavaScripttel tudsz belepiszkálni. Legjobb példa erre az, ha böngésző-bővítménnyel bírálod felül egy adott oldal megjelenését. Ilyenkor nem tudsz jobbat, mint hogy injektált CSS-sel vagy JavaScript-kóddal nyúlsz hozzá. De akár lehet olyan is, hogy egy adott CMS-hez nem szeretnél külön modult/komponenst/plug-int fejleszteni, PHP-vel belekontárkodni, esetleg nincs időd/kedved megismerkedni az API-val, és úgy belenyúlni, de van egy saját template-ed, amivel csak gyorsan felül akarod bírálni valamilyen elem megjelenését (core-ba meg ugye nem nyúlunk bele). Most egyéb példákon nem töröm az agyam, ezek ugrottak be rögtön.
-
#2061
Sk8erPeter
nagyúr
G.F.
#2060
Sk8erPeter
nagyúr
"Hogyan lehetne kizárni azt, hogy a képek mögé, amin szintén linkek vannak, ne tegye ki a kis ikont?"
Hogy mit? Nem értem.Egyébként egyrészt azt tudod csinálni, hogy ellátod a megfelelő elemeket valami osztállyal, ami miatt a selector a kizárandó elemre épp nem vonatkozik, másrészt használhatod a CSS3-as :not() pszeudoosztályt (ez utóbbi csak IE9-től kezdve megy, ha egyáltalán ez érdekes).
-
#2056
Sk8erPeter
nagyúr
Zedz
#2054
Sk8erPeter
nagyúr
Nem kell többéves tapasztalat, használd a fantáziád.
(#2052):
"Na ha valahol, akkor ott biztos van pénz ilyenekre. Egyszerűen csak lusták megreformálni a dolgot."
Direkt kiemeltem ezt az állítást, hogy meg tudd ismét csócsálni, és érezd, ahogy átjárja a tested-lelked ez a borzongató leegyszerűsítés. -
#2051
Sk8erPeter
nagyúr
Zedz
#2050
Sk8erPeter
nagyúr
Lehet, hogy picit megértőbb lennél, ha te lennél egy olyan cégnek a vezetője/pénzügyi felelőse/stb., akinek a költségvetéséből adott időszakban épp rohadtul fájó, és nagyon nem futja arra a pármillió Ft-ot érő beruházásra, ami a számítógéppark lecserélésével, vagy épp csak az OS/szoftverek frissítésével járna. Ez akár tetszik, akár nem, fennálló jelenség, a modernizálás időbe és pénzbe kerül, annak meg örülhetünk, ha valaki mégis rá tudja szánni a pénzt (más meg nem biztos, hogy öncélú fösvénységből nem teszi). És igen, a lóvé az, amit mindenki sajnál, ez biza ilyen, örülök, hogy erre rájöttél.
-
#2049
Sk8erPeter
nagyúr
Zedz
#2048
Sk8erPeter
nagyúr
"Egyszer kellene rászánni az időt és normálisan megcsinálni..."
Ha ez ilyen egyszerű lenne, nyilván meg lenne oldva. Kell hozzá szakember, a frissítéshez nem árt egy jó/jobb infrastruktúra, akár új OS, idő, lóvé... De az az egyszeri költség sajnos adott esetben óriási lehet, de épp ilyen esetet említett az imént DNReNTi kolléga. -
#2039
Sk8erPeter
nagyúr
biker
#2038
Sk8erPeter
nagyúr
Alapvetően nem a legjobb, persze, de lehet olyan eset, hogy nem akarja buzerálni az eredeti, alkalmanként akár frissülő alapot - ami jelen esetben a Bootstrap cucca, meg a rá épülő theme -, mert akkor pl. frissítéskor kidobhatná a saját megoldását (vagy folyton össze kéne tákolni), ezért kihasználja a CSS azon tulajdonságát, hogy a stílusok felülbírálhatók. Saját felülbírálásból persze már nem túl egészséges, ha több is van.
-
#2036
Sk8erPeter
nagyúr
biker
#2035
Sk8erPeter
nagyúr
A < biztos nem, mert olyan nincs CSS-ben, > van, ami meg az elem közvetlen gyermekelemére illeszkedik. Mondjuk ezt ennyi év webfejlesztés után illene tudnod. A két/több egymás után írt elemselector - pl. li li - pedig azt jelenti, hogy az első elemnek VALAHOL a hierarchiában leszármazottja az utána írt elem (vagy több elem is akár), és teljesen mindegy, hanyadik szinten a hierarchiában (lehet közvetlen gyermekeleme is, de lehet valahol sokkal mélyebben is).
Szerk.:
Itt aztán mindent megtalálsz, ami érdekes ezzel kapcsolatban:
http://www.quirksmode.org/css/selectors/ -
#2021
Sk8erPeter
nagyúr
kispx
#2020
Sk8erPeter
nagyúr
Röviden azért, mert ha nem tartja be az ember a sorrendet, és mindegyik szóbanforgó pszeudoosztályra külön stílus lenne érvényes, előfordulhatna olyan eset, hogy ezek a stílusok felülírják egymást, és nem érvényesülnek az adott elemen akkor, amikor kellene. (Például színekkel könnyen tesztelhető egy ilyen viselkedés, de ugye az ember nem feltétlenül csak színeket definiálhat adott pszeudoosztályra (és a gyakorlatban sokszor nincs minden pszeudoosztálynak külön színe).)
Hosszabban: az LVHA-szabály az érvényes, vagyis a Link-Visited-Hover-Active. A legkönnyebben talán a LoVe, HAte szavak ebben a sorrendben történő használatával jegyezhető meg.
A :focus pszeudoosztály sorrendjével kapcsolatban nem egyértelműek az álláspontok, de mindenképpen a :link és :visited és után kell jönnie, és még az :active előtt (ez viszont nem kérdés!). De ha ezzel is kiegészítjük az LVHA-t, akkor arra az LVHFA vagy LVFHA rövidítés illik, én az utóbbit, vagyis inkább az LVFHA-t támogatnám - szemben pl. ezzel a cikkel. Ennek az okáról mindjárt. Utóbbinak a megjegyezhetőségére én az előbbiből kiindulva a LoVe Furious HAte szavakat találtam ki.L: A :link pszeudoosztály tulajdonképpen a nemlétező :unvisitednek felelhetne meg, tehát annak, hogy a felhasználó még nem "látogatta meg" az adott linket. (És a linkelt cikkek szerzőjéhez hasonlóan én sem tudom, hogy miért nem :unvisitednek hívják inkább.
) Azért ez az első a sorrendben a definiálandó pszeudoosztályok közül, mert értelemszerűen azt akarod először is megmondani, hogy hogy nézzen ki az a link, amit még nem látogattak meg (nem kattintottak rá, és engedték el a nyomógombot). De tulajdonképpen ennek és a :visited-nek a sorrendje mindegy lenne, mivel egyszerre nem lehet látogatott és nem látogatott egy link, tehát ezek kölcsönösen kizárják egymást (szóval lehetne :visited-:link sorrend is, de a :link-:visited sorrend logikusabb).
V: A :visited link meg értelemszerűen a már meglátogatott linkekre vonatkozik. Tehát kilőttük az LVHA-ból az első kettőt.
F: A :focus arra vonatkozik, ha egy adott elem megkapta a fókuszt, akár billentyűzetről vezérelve (pl. odaugrálva Tabbal, akár egy gyorsbillentyűvel, ha épp lehetséges), akár egér segítségével (pl. ha belekattintasz egy <input> elembe).
H: A :hover arra vonatkozik, ha a felhasználó a link fölé viszi az egérkurzort, és ez azért következik a :link és :visited után, mert amikor a felhasználó a linked fölé viszi a kurzorját, akkor azt szeretnéd, hogy az erre vonatkozó stílus legyen érvényes, ne pedig az, hogy kattintott-e már a linkre vagy sem (mert akkor az az érdekes, hogy épp afölött a link fölött tartózkodik, nem az, hogy volt-e már "látogatva" a link), és az előző kettő felülírná.
A: Az :active arra vonatkozik, ha az elem "aktiválásra" került. Egérrel való vezérléskor aközött a két időpont között érvényes, amikor rákattintasz, majd elengeded a gombot. Például ha bármelyik egérgombbal való kattintáskor egy darabig nem engeded el a gombot, hanem lenyomva hagyod, akkor látod, hogy épp az :active pszeudoosztály érvényesül. Ha billentyűzetet használsz, akkor úgy látod aktívnak, ha például egy épp fókuszban lévő (!) gombon hosszan nyomvatartod a Space-t.Ami miatt én jobbnak tartom, ha a :focus előbb van, mint a :hover (LVFHA), az az, hogy így érvényre tud jutni a :hover pszeudoosztály akkor is, ha az adott elem épp fókuszban van. De érdemes tudni, hogy ilyenkor a :hover ugye felülírja a :focus szabályát.
Példa a megértéshez: legyen egy input elem, amire az alábbi CSS-kód érvényes:
input:focus {background-color: orange;}
input:hover {background-color: red;}
Ha a fókuszt az elemre helyezed akár egérrel való belekattintással, akár billentyűzettel való odanavigálgatással (pl. Tab segítségével), akkor ugye megkapja a narancssárga háttérszínt. Ha még fölé is viszed az egeret, akkor pedig piros lesz az elem háttere.
Ha a következő szabály lenne érvényben:
input:hover {background-color: red;}
input:focus {background-color: orange;}
Tehát pont fel lenne cserélve, akkor ugyanebben az esetben hiába vinnéd fölé az egeret, a :hover szabályt felülírná a :focus, és nem kapná meg a piros háttérszínt hover esetén sem.
Persze van, aki pont fordítva gondolja, és aki szerint ha már egy elem fókuszban van, akkor ne érvényesüljön rá még a hover szabály is (LVHFA). Hát ez fejlesztői döntés kérdése.Remélem, érthető volt.
Ide felraktam egy példát is, amivel elég jól tesztelhető az említett pszeudoosztályok működése:
http://jsfiddle.net/Sk8erPeter/3ovgrwyg/ -
#2002
Sk8erPeter
nagyúr
adam_
#2001
-
#1998
Sk8erPeter
nagyúr
adam_
#1997
Sk8erPeter
nagyúr
Nyilván attól is függ, mi a távlati cél, akarsz-e Bootstrapet vagy más ehhez hasonlót használni, ha igen, mert rájössz, hogy sokkal gyorsabb, mint mindenre kiguglizni a megfelelő megoldást, vagy épp kikotorni magából a Bootstrapből, akkor egyszerűbb és gyorsabb lehet átállni rá, igaz, a Bootstrap saját stílusait felül kell definiálnod a sajátodra. Ezzel is pöcsölni kell, ezt nem úszod meg, de nem akkora katasztrófa, még így is talán kevesebb időtöltés, mint átemelni a vonatkozó részeket a saját kódodba, hogy valóban jól jelenjen meg az oldalad a mobileszközökön is.
"media querieseket"
Többesszámban lévő szót teszel többesszámba. Ezt már amúgy írtam.
Értelmesen: "media query-ket"."Pl.: valakinek van tapasztalata a .me domainendinggel kapcsolatban? Arról olvastam, hogy pl. jól illik az online önéletrajz, portfolióval kapcsolatos oldalakhoz. Pl. kisjozsi.me
vagy hasonló."
Például Jim-Y kollégának .me-végződésű a honlapja, nézd meg az aláírását.
És ja, akár jópofa is, hogy .me a végződés, de egyébként teljesen mindegy, .hu is lehet, ha berakod az önéletrajzodba az URL-t, nem emiatt fogják kevésbé megnézni. Igaz, a .me "nemzetközibb". Válaszd azt, amelyik jobban tetszik. Bár lehet, hogy ha mondjuk idegen nyelven akarsz blogolni, tehát vegyes a közönséged, akkor nem a .hu a legnyerőbb, de ezt se kell túlreagálni. -
#1988
Sk8erPeter
nagyúr
Zedz
#1987
Sk8erPeter
nagyúr
Amúgy most pont nem volt a gépemen se Ruby, se SASS (reinstall után nem került rá még), úgyhogy direkt kíváncsi is voltam, mennyi időbe kerül az egész procedúra, letöltéssel, egy SSL-problémára való ráguglizással, a megoldás megtalálásával és figyelembe vételével (csak simán update-elni kellett, gem install --local d:\Downloads\rubygems-update-2.2.3.gem, majd update_rubygems --no-ri --no-rdoc), gem install sass-szal együtt 6 perc volt, direkt mértem.
Szemétrohadékvindóz!!!Szerk.: amúgy a konkrét hibaüzenet ez volt (leírom, hátha Ádámnak is ez volt a parája, ezt nem osztotta meg velünk):
C:\>gem install sass
ERROR: Could not find a valid gem 'sass' (>= 0), here is why:
Unable to download data from https://rubygems.org/ - SSL_connect returned=1 errno=0 state=SSLv3 read server certificate B: certificate verify failed (https://api.rubygems.org/latest_specs.4.
8.gz) -
#1982
Sk8erPeter
nagyúr
adam_
#1981
Sk8erPeter
nagyúr
Mi az, hogy "nem megy"? Részleteznéd, hogy miket tettél idáig, és konkrétan mit is tapasztalsz?
"Kezdő vagyok, de már most vili, hogy a Windowst miért nem fejlesztésekre alkották meg..."
Jaj. Könyörgöm, ne higgyél már el minden baromságot, amit valami idióta kretének kitaláltak és terjesztenek. Ezenkívül attól, mert most szerencsétlenkedsz valamivel, és nem jön össze, még nem a Windows a hibás, már bocs. Nagyon sok fejlesztő tök jól elvan Windows-on.
Nagyon is alkalmas a Windows is fejlesztésekre, csak beszűkült látókörű elvakult gyökér Linux- (esetleg Mac-?) fanok mondják azt, hogy nem az. Linuxon ÉS Windows-on is nagyon jól lehet fejleszteni. Kész. Nincs olyan, hogy melyiken jobb. Az a jobb, amelyik neked jobban tetszik. Szimplán szubjektív a dolog. Ha az objektív tényeket nézzük, mindkettőn jó eszközök, IDE-k állnak rendelkezésre, mindkettőn jól lehet scriptelni, blablablablabla... annyira unalmasak már ezek az újból és újból előkerülő "melyik az igazi"-témák. Próbáld ki és döntsd el, melyik tetszik jobban, és akkor számodra az lesz a megfelelő választás. -
#1963
Sk8erPeter
nagyúr
Zedz
#1961
Sk8erPeter
nagyúr
"Azért érdekel, mert 2 CSS framework is a LESS-t használja, és kíváncsi vagyok mi lehet ennek az oka. Gondolom nem random pickeltek egyet, és nosza írjuk egybe."
Szerintem különösebben nem érdemes rajta agyalni, egyszerűen valamelyikkel kezdték, azt találták szimpatikusabbnak, az náluk bevált. Nem álltak át a SASS-ra, mert a LESS segítségével is el tudták érni, amit akartak. Ha a SASS lett volna az első, akkor arra mondanák azt, hogy el tudták érni vele, amit akartak. Mindkettőre nyilván lehet példát találni, szóval ez olyan, mint azon gondolkodni, miért pont barnás lett a PH! fórumának háttere."LESS-szel lehet-e figyeltetni egy könyvtárat, és real-time fordítson mindent"
Csak egy kis kiegészítéssel:
http://www.hongkiat.com/blog/less-auto-compile/Ha adhatok egy tanácsot, ahelyett, hogy most kíváncsiságból elkezded tanulgatni a SASS után a LESS-t is, mert miért ne, inkább mélyítsd el a tudásodat valami hasznosabb nyelvben.
-
#1957
Sk8erPeter
nagyúr
PumpkinSeed
#1956
Sk8erPeter
nagyúr
válasz
PumpkinSeed
#1956
üzenetére
Ilyenkor nézd meg a webfejlesztő panelnél a Computed fülön a display-tulajdonságot - itt azt is látod, ha a böngésző alapértelmezett tulajdonsága érvényes, illetve azt is, ha egy vagy több egyéni beállítás felülbírálta ezt.
Ja, amúgy itt láthatsz listát az inline vagy blokkszintű elemekről:
https://developer.mozilla.org/en-US/docs/Web/HTML/Inline_elemente
https://developer.mozilla.org/en-US/docs/Web/HTML/Block-level_elements -
#1943
Sk8erPeter
nagyúr
_ak_
#1942
Sk8erPeter
nagyúr
Első felére: szerintem ez elég egyértelmű, hogy köze nincs a footerhez.
Végig a .container osztállyal ellátott elemről beszél, tehát az érdemi tartalmat körbeölelő részről, ami ha el van látva egy háttérrel, de épp nagyon kevés a tartalom, akkor hülyén mutat, ha csak egy csíknyi részt foglal el az oldalból. Ergo a megoldás a min-height tulajdonság megadása/megnövelése. Ebből csak fura indirekciókon keresztül lehetne oda eljutni, hogy a footerrel lenne probléma... Második felére:
Ha ilyen kérdések merülnek fel, akkor szerintem a Stack Overflow egy igen jó forrás, a kapott pontokból a legtöbb esetben lehet sejteni egy hozzászólás igazságtartalmát (még ha vannak helyenként csak reflexből upvote-olt hsz.-ek is, amik nem biztos, hogy annyi pontot érdemelnének, többnyire ez kevésbé jellemző), és általában mások összeszedik azt a tudásbázist, amit egyébként sok egyéb helyről kellene összekaparni.A px/em/rem problémával kapcsolatban itt van egy vonatkozó thread a sok közül:
http://stackoverflow.com/questions/11799236/should-i-use-px-or-rem-value-units-in-my-css
Még egy megközelítés:
https://j.eremy.net/confused-about-rem-and-em/ -
#1941
Sk8erPeter
nagyúr
Sk8erPeter
nagyúr
Ha valaki meg szeretné tanulni a Bootstrap használatát, akkor ez egy egész fasza oktatóanyag videóval és gyakorlati feladatokkal:
https://www.codeschool.com/courses/blasting-off-with-bootstrap
Ez sztem nyugodtan linkelhető kezdőknek, vagy annak, aki stabilabbá szeretné tenni az alapokat, és/vagy lusta a doksit végigolvasni, amennyit végigkattintgattam belőle, az alapján elég jól ki van találva az anyag. (Haladóknak fölösleges végignyomni, amik itt vannak, azok tényleg az alapok.) Persze angoltudás kell hozzá. -
#1934
Sk8erPeter
nagyúr
honda 1993
#1932
Sk8erPeter
nagyúr
válasz
honda 1993
#1932
üzenetére
Igen, ilyenkor az a megoldás, hogy adsz egy min-height tulajdonságot a fő tartalmazó elemnek, hogy ne nézzen ki olyan bénán, hogy csak egy kis vékony csík látszik a helyén. De az 1500px igen erős túlzásnak tűnik, akkor meg azért néz ki hülyén, mert van egy óriási rész még a tartalom alatt, amihez tök fölöslegesen scrollozni kell mondjuk egy kisebb kijelzőn...
A menü amúgy oldalt van vagy fölül?
(#1933) DNReNTi:
Arról beszél, hogy van egy olyan menüpont, ahol mondjuk csak egy mondatnyi tartalom van. Ekkor meg az őt körbeölelő tartalom is nagyjából akkora, mint az az egy mondat, és így a hátterével együtt olyan, mint egy vékony csík (a többi menüpontban több tartalom van, így azok nem néznek ki hülyén). Na és azt akarja, hogy kicsit jobban kitöltse a teret az ilyen kevés tartalommal levő részeken is a fő konténerelem háttere, hogy ne legyen ezeken a helyeken ilyen csíkszerű, szóval meg kell növelni a min-height-et, azt' kész. -
#1922
Sk8erPeter
nagyúr
DNReNTi
#1921
-
#1919
Sk8erPeter
nagyúr
honda 1993
#1918
Sk8erPeter
nagyúr
válasz
honda 1993
#1918
üzenetére
Hát ez kellemetlen. Ha majd sikerül, szólj.
A kitöltőképek beszúrására (hogy ne látsszon a ronda ikon, hogy nem elérhető a képed) ajánlom ezt:
http://placehold.it/"Elő
sször is nem tudom hogy képet hogyan lehet itt beszúrni"
Na ne... Próbálkozz erősebben. -
#1916
Sk8erPeter
nagyúr
honda 1993
#1915
Sk8erPeter
nagyúr
válasz
honda 1993
#1915
üzenetére
Akkor az előbbi kódot hogy küldted, ha nincs elérhető közelségben a kódod?
Amúgy lehet, hogy ha akarnánk agyalni rajta, rájönnénk, de nem akarunk, nekünk is véges a szabadidőnk, amiből X időt akarunk a fórumon tölteni, gondolom belátod, hogy nem feltétlenül a kódod kibogarászása a legszórakoztatóbb tevékenység. -
#1914
Sk8erPeter
nagyúr
honda 1993
#1913
Sk8erPeter
nagyúr
válasz
honda 1993
#1913
üzenetére
Nem, nem tudjuk jsFiddle-példa nélkül. Kíváncsi vagyok, eljön-e az az idő, amikor ezt megtanulod.
Most komolyan, ebből csak annyit lát szerintem a legtöbbünk, hogy egy halom kód, és a franc fog elgondolkozni rajta demó nélkül. Tőlünk meg nyilván nem várhatod el, hogy majd saját kis környezetünkben valahogy teszteljük, mert az nekünk kerül időbe, amit te lespóroltál magadtól. -
#1911
Sk8erPeter
nagyúr
adam_
#1909
Sk8erPeter
nagyúr
Amit linkeltél, biztos nem rossz, utólagos kiegészítések, javaslatok miatt használhatónak tűnik (bár nem teszteltem, csak az alapján, amit írnak az utófeldolgozó scriptről). Szóval simán használhatod ellenőrizgetésekre.
Amit DNReNTi linkelt, az teljesen más, az sok környezetben és eszközön teszi lehetővé az oldala(i)d tesztelését, hogy megtudd, azokon hogy néz ki, anélkül, hogy fizikailag rendelkezésedre állnának ezek az eszközök. -
#1910
Sk8erPeter
nagyúr
honda 1993
#1908
Sk8erPeter
nagyúr
válasz
honda 1993
#1908
üzenetére
Tudod jól a kulcsszót...
Biztos még kétszázszor le kell írni, hogy rögzüljön.
Amúgy ilyeneket, mint a widht, tényleg beleírsz a kódba? Tehát kimásoltad azt a kódrészletet, vagy ezt csak bepötyögted? Keresd a hibát a szóban! Csak mert ha szintaktikai hibákkal van tele a stylesheet - az is az, hogy nem zártad le a sort pontosvesszővel a hsz.-ed legvégén lévő kódrészletben -, akkor nem várható el, hogy jól működjön. Ilyenek miatt is érdemes tisztességes fejlesztőkörnyezetet használni, mert az szól a hibákért. -
#1905
Sk8erPeter
nagyúr
honda 1993
#1904
Sk8erPeter
nagyúr
válasz
honda 1993
#1904
üzenetére
De konkrétan mi az, amit nem vágsz rajta? Ha csak a felbontásokra nézzük, akkor egyszerű példával élve annyit mondasz egy-egy feltétel meghatározásával, hogy ekkora szélességre így nézzenek ki ezek és ezek az elemek, akkora szélességre meg úgy, egy tök másik szélességre megint másképp... például ebben is segítenek a media query-k, így tudod elintézni, hogy különböző felbontással (vagy egyéb paraméterekkel) rendelkező eszközökkel megnézve az oldalt (vagy amikor más paraméter teljesül) is élvezhető legyen az egész.
Meg még sok más paramétert is lehet említeni, amikről korábban szó volt (színmélység, blabla; meg lehet simán megtekintéshez ilyen, nyomtatáshoz meg amolyan stílust alkalmazni az oldalra, stb.).
Szerintem bonyolultabbnak gondolod ezt az egészet, mint amilyen.Leegyszerűsítve ennyiről szól az egész: csinálsz egy-egy blokkot, amiknek a fejlécébe egy-egy feltételt teszel (a feltételek tetszés szerint kombinálhatók logikai ÉS-, VAGY-, ill. NEM-kapcsolattal), ha ezek a feltételek teljesülnek, akkor a böngésző az abban a blokkban szereplő stílusdefiníciókat érvényre juttatja. Ha a feltételek nem teljesülnek, akkor egyszerűen ignorálja őket.
-
#1903
Sk8erPeter
nagyúr
honda 1993
#1901
Sk8erPeter
nagyúr
válasz
honda 1993
#1901
üzenetére
"én egy link segítségével próbálkoztam"
Ezt hogy érted?Egyébként igazából nem értem, mi a probléma, nem értem, hogy miért akarsz feltétlenül mást használni, mint a media query-ket, kerülöd a problémát innen-onnan, aztán előbb-utóbb úgyis rájössz, hogy az fog kelleni, és akkor már értelmesebb lenne eleve azzal kezdened, főleg, hogy már összességében többszáz hsz.-t produkáltunk a témában neked válaszul, a moderátor által töröltekkel együtt biztosan.
-
#1900
Sk8erPeter
nagyúr
honda 1993
#1899
Sk8erPeter
nagyúr
válasz
honda 1993
#1899
üzenetére
Tehát media query-ket szeretnél media query-k nélkül. Good luck!
-
#1796
Sk8erPeter
nagyúr
adam_
#1795
Sk8erPeter
nagyúr
Pont nemrég volt szó ugyanerről, ugyanitt:
http://prohardver.hu/tema/css_megjelenitesi_problemak/hsz_1635-1698.html -
#1791
Sk8erPeter
nagyúr
PumpkinSeed
#1790
Sk8erPeter
nagyúr
válasz
PumpkinSeed
#1790
üzenetére
Ja, akkor bocsi, figyelmetlen voltam.
(#1789) Zedz: jaja, csak ijesztő volt azt hallani, hogy tervezed, hogy átnyergelsz OS X-re.
-
#1788
Sk8erPeter
nagyúr
Zedz
#1787
Sk8erPeter
nagyúr
Ugyan már, nincsenek ilyen különbségek. A legtöbb komoly és népszerű kapcsolódó proginak van Windows-os változata.
(#1786) PumpkinSeed:
De vágod, most fejlesztői környezetről beszélünk, nem szerverekről. Szerver simán lehet headless is, tehát olyan, ami nulla grafikus felülettel rendelkezik. -
#1785
Sk8erPeter
nagyúr
Jim-Y
#1784
Sk8erPeter
nagyúr
A véleményekkel semmi baj nincsen, meg azzal, ha az ember azt írja, hogy neki egyszerűen jobban bevált valami, és kész, mert az tök szubjektív, azzal vitatkozni nincs is nagyon értelme. Azzal viszont már van, ha kész tényként állítunk valamiket.
Mint pl. "a bash jobb", ezt úgy lehet értelmezni, hogy egyszerűen többet tud, pedig ez közel sem igaz. Ha azt írod, hogy a PowerShellt nem ismered, a bash-t viszont szereted, abba a mondatba nem lehet belekötni sem. Csak azért érdekesek ezek a kijelentések, mert még lehet olyan is, aki elhiszi, aztán még a végén továbbterjeszti azt, ami nem igaz. De remélem, legalább Te nem sértődsz meg azon, ha az ember vitatkozik, mert sokan ilyenkor teljesen magukra veszik, pedig ez egy szakmai fórum, erről szól. -
#1783
Sk8erPeter
nagyúr
Jim-Y
#1777
Sk8erPeter
nagyúr
"Ezt mind windows alatt powershellben is meg lehet tenni, de egyreszt, a bash jobb"
Bocs, de ez ebben a formában egy nagyon nagy baromság. Programoztál már huzamosabban Powershellben? Mert az egy dolog, hogy a bash scriptek írását vágod, és ránéztél egy PowerShell-kódra, és azt mondtad, hogy az ocsmány, de nem árt tisztában lenni a PowerShellel is ahhoz, hogy véleményt alkossunk róla.
Például az egy igen komoly és jelentős különbség a PowerShell javára, hogy míg bash-ben stringeket passzolgatsz és vagdosol, meg kell feldolgoznod, addig PowerShellben a pipe-pal objektumokat (!!!) passzolgatsz, és tudsz felhasználni egy másik kódban, ennek megfelelően tudsz attribútumokat elérni, metódusokat hívogatni, illetve függvényeknek objektumot passzolsz át. Nagyon nem mindegy. Mondom ezt úgy, hogy elég sok bash scriptet is írogattam már, és annak is megvan a szépsége. Például külsőre szebb, meg sok dolog intuitívabb."Szoval egesz egyszeruen munkara alkalmasabb egy Linux rendszer -szerintem-, mint egy windowsos."
Ez a mondat már megint teljesen értelmetlen hülyeség, csak flamewar kiváltására jó. Tökéletesen alkalmas a Windows is a fejlesztői munkára.
Például ha C#-ban dolgozol, akkor b@szakodhatsz a Linuxos fejlesztőkörnyezettel, de hamar rá fogsz jönni, hogy amíg a Visual Studiónak nincs egy Linuxos változata, addig a Windows lesz az igazi, plusz ha ASP.NET-ezel, akkor ezenbelül az IIS (bár egyre komolyabban veszi a Microsoft szerencsére a Linux-környezetet is, de egyelőre problémákba lehet ütközni (pl. kényelmetlenebb fejlesztőkörnyezet), ahogy olvasható fórumokon).
Attól, hogy az ember alapvetően olyan programozási nyelveken dolgozik, meg olyan alkalmazásokat használ, amihez a Linux is megfelelő, attól nem kell kapásból kijelenteni, hogy az, amit én használok, az jobb. Főleg, ha elég sok példa bizonyítja, hogy Windows-on is tökéletesen jól lehet fejlesztői munkát végezni. Sőt, nekem hosszú távon kényelmesebbnek bizonyult a Windows-környezet (ld. pl. Visual Studio), igazából ezért "tértem vissza" rá (pedig becsszó próbáltam átállítani magam, igaz, annyira nem volt nagy a kényszer, de úgy gondoltam, próbát mindenképp megér).
Ettől még Linuxon is tök jól elboldogulok. Akkor is vannak olyan alkalmazásaim, amiknek a Linuxos megfelelői számomra nem megfelelőek. Sok mindent meg nagyon szívesen emelnék át Linuxból, aminek nincs Windows-alternatívája (de a jellemző az, hogy Windows-változata gyakrabban van az alkalmazásoknak).
Hogy átalakítsam a mondatodat: Szóval egész egyszerűen munkára mind a Linux, mind a Windows alkalmas.
"svn, git | commit, update, add, stb..
ant, maven | build, init stb..
node, npm, grunt, gulp stb.."
Az a jó, hogy az általad írtak közül az ÖSSZES (!!) elérhető Windows-on is, command promptból. Nem beszélve arról, hogy ott a MinGW és társai.
Tök jól lehet Windows-ban is command promptból dolgozni.
Amúgy Githez van a Git Bash, amit eleve kapsz telepítéskor, így kicsit Linuxos feelinged lehet Windows-on.A korrektség kedvéért mondom megint, amit írtam korábban is, hogy a Linuxos terminálban pötyörészést, meg az ottani csomagkezelést én is jóval kényelmesebbnek és kézenfekvőbbnek találom. De azért a legtöbb dologra bőven megvan az alternatíva (igaz, lehet, hogy Windows-on GUI van erre, ami adott esetben (pl. webszerver) nem feltétlenül baj (főleg, hogy pl. az IIS a GUI mellett konzolos babrálhatóságot is lehetővé tesz)).
"Azert az se veletlen, hogy ahol fejlesztes folyik, es nem kimondottan Microsoft technologiakkal, ott surun unix rendszer van"
Igen, például ennek egy igen egyszerű oka van: hogy nem kell pénzt költeni a Windows-ra... Ez semmit nem igazol abból, hogy Linuxon alkalmasabb lenne dolgozni. Nem beszélve arról, hogy ha a vállalati kultúra azt követeli meg, hogy az X operációs rendszert használd az Y helyett, akkor nyilván az X-et fogod használni, és kész. Vagy elmész máshova. Szerk.:
(#1779) martonx:
Na, király, legalább ennyivel beljebb vagyunk! Amúgy tényleg egy vicc, hogy ez a 10-esben került elő, mint valami komolyan vehető feature... -
#1769
Sk8erPeter
nagyúr
Zedz
#1768
Sk8erPeter
nagyúr
"Tényleg egy kezünk alá dolgozó rendszert, vagy mindez csak túl van hypeolva"
Utóbbi. Túlhype-olás és sznobizmus az Apple-buzik lételeme, anélkül levegőt venni is nehezen tudnak (ha nem ájfónnal telefonálnak, akkor nagy ütemben kezd elrohadni a fülük, és a szívük is erősen elkezd szúrni, mert nehezen bírják elviselni ezt a stresszt). -
#1767
Sk8erPeter
nagyúr
Zedz
#1766
Sk8erPeter
nagyúr
Csomó dolog nekem nagyon szimpatikus a Linuxban, volt egy elég hosszú idő, amikor próbáltam átállni rá, de egyszerűen annyi Windows-hoz kötődő program van, amire tényleg nem találtam Linux-alternatívát (ami TÉNYLEG megfelelt volna minden igénynek, pedig rengeteg kapcsolódó programot próbáltam, alapos keresés után, hogy ki mit ajánl), és még Wine-nal sem működik, hogy aztán úgy voltam vele, hogy ami nem megy, azt nem kell feltétlenül erőltetni.
Pedig imádom a függőségeket behúzó csomagkezelést, az egysoros scriptelgetést, amivel egyszerre rakok fel felügyelet nélkül 30 programot, ha olyanom van, tetszetős, hogy szanaszéjjel tudom konfigurálni a rendszert, blablabla... Valahogy a két OS kombója lenne az igaz, bár ezzel nem mondok túl nagy bölcsességet. Például a Windows tárhelyzabáló terpeszkedése zavaró (elég megnézni a Windows-könyvtár méretét a rendszerpartíción), meg az olyan nyomorék dolgok, mint hogy 2014-ben nem lehet billentyűzetről copy-paste-elni a command promptba (még Windows 8.1 esetén sem, a 10-et még nem próbáltam), csak 3rd party szoftverek segítségével (ez most csak egy példa a zavaró dolgokból). Cserébe továbbra is a Windows az elsődleges célplatform, a Linux mindig másodlagos (valószínűleg még jó sokáig így is marad), így sok alkalmazás utóbbira el sem készül, emiatt az ember nagyon sokszor falakba ütközik (és még ha talál is a feladatot elvégző szoftvert, az nem olyan, vagy nem úgy, vagy majdnem jó, de mégsem, vagy tök más megközelítést igényel, stb.). Persze vannak, akiknek simán megfelelnek az alternatív szoftverek is, azoknak tök jó. -
#1749
Sk8erPeter
nagyúr
honda 1993
#1743
Sk8erPeter
nagyúr
válasz
honda 1993
#1743
üzenetére
"pl ma írtok nekem valamit és elolvasom, az nem azt jelenti hogy ma fogom alkalmazni, mert lehet hogy 2 napig nem is foglalkozok a témával mert éppen nem vagyok otthon, vagy nincs rá időm.
Aztán amikor pedig leülök a gép elé, valószínűleg elfelejtem a dolgot"
Hát pontosan erről van szó, erről beszéltem. Ha épp nem tudsz reagálni ezekre, meg nem is tudod kipróbálni, azzal semmi gond nincsen, de amikor mégis odajutsz, hogy lenne lehetőséged kipróbálni, amit javasoltak neked, akkor már nem nézed meg, sőt, elfelejted, aztán magadtól kezdesz el szenvedni pontosan ugyanazzal, amire rákérdeztél, és amire megoldásokat kaptál, tehát teljes mértékben értelmetlen neked válaszolni, mert úgyis elfelejted. -
#1748
Sk8erPeter
nagyúr
Zedz
#1741
Sk8erPeter
nagyúr
"A kódmennyiséggel kapcsolatos felvetésed nem teljesen értem. [...] Szóval igazából a felhasználó ebből mit sem érzékel, hisz úgy is csak a kész .css fájlt kapja meg, amit akkor is megkapna ha mi azt "natívan" kódoljuk le."
Itt a felhasználó annyiból kerül képbe, hogy mennyi adatot kell letöltenie, és az általa használt böngészőnek mennyi időbe kerül feldolgozni a betöltött kódot. Ez például mobileszközöknél nem (sem) mindegy. Szóval így van, úgyis csak a kész CSS-fájlt kapja meg, hiszen azt előre legenerálod a SASS/LESS/...-kódodból. Viszont nem mindegy, hogy ebből a kódból mekkora legenerált kódbázis keletkezik: előfordul olyan eset, hogy míg Te egy darab sort írsz az adott kódblokkba pl. SASS+Compass segítségével, addig a legenerált CSS-kód már fog tartalmazni vagy 10 vagy több (!) sort, ami ebből az 1-ből keletkezett. Ez több letöltendő és feldolgozandó adat.
Csak egy kicsit talán túlzottan is extrém példa (most épp ez akadt a kezembe), ami mondjuk annyiból sántít, hogy a Compass a SASS-hoz képest is bővebb, szimplán csak összehasonlítás kedvéért, hogy a mennyiséggel kapcsolatos érvet alátámasszam:
http://compass-style.org/examples/compass/tables/striping/SCSS:
@import "compass/utilities/tables/alternating-rows-and-columns";
.example {
table {
$table-color: #7a98c6;
@include alternating-rows-and-columns($table-color, adjust-hue($table-color, -120deg), #222222);
}
}az ebből keletkező CSS-kód:
.example table th {
background-color: white;
}
.example table th.even, .example table th:nth-child(2n) {
background-color: #dddddd;
}
.example table tr.odd td, .example table tr:nth-child(2n+1) td {
background-color: #98c67a;
}
.example table tr.odd td.even, .example table tr.odd td:nth-child(2n), .example table tr:nth-child(2n+1) td.even, .example table tr:nth-child(2n+1) td:nth-child(2n) {
background-color: #76a458;
}
.example table tr.even td {
background-color: #7a98c6;
}
.example table tr.even td.even, .example table tr.even td:nth-child(2n) {
background-color: #5876a4;
}
.example table tfoot th, .example table tfoot td {
background-color: white;
}
.example table tfoot th.even, .example table tfoot th:nth-child(2n), .example table tfoot td.even, .example table tfoot td:nth-child(2n) {
background-color: #dddddd;
}De mondjuk bevallom, ez tényleg túl extrém példa.
De ha a böngésződ natívan támogatna olyan lehetőségeket, amiket eddig csak preprocessorral tudtál kényelmesen elérni (anélkül, hogy a kódod átláthatatlan lett volna, mert például ebben is nagy segítséget nyújtanak ezek az eszközök), akkor az mindenképp egy jobb irány.
-
#1740
Sk8erPeter
nagyúr
Zedz
#1731
Sk8erPeter
nagyúr
"ha használ az ember egy Sasst mondjuk, akkor igazából majdnem mindegy mikor terjednek el ezek a funkciók"
Hát azért nem mindegy, hogy ezeket a funkciókat "külső" segédeszközökkel kell elérni, úgy, hogy viszonylag nagy kódtömeg generálódik a viszonylag egyszerű kódból (pl. a SASS-kódból CSS-kód), vagy a böngésző natívan támogatja, és ezáltal a kisebb kód és a belső implementáció esetleges optimalizációja miatt még akár gyorsabb is lehet. Persze ez a nagyon távoli jövő, addig is maradnak a preprocessorok, de azért a natív támogatottság a jobb esetekben faszább is - igaz, a CSS3-as animációknál is lehetett bugokba futni eleinte, például amikor Firefoxon egy transition igen durván izzasztotta a CPU-t. (utóbbit csak a natív megoldás minden esetben jóságának cáfolatára írtam De nyilván ez is olyan, amit szép lassan javítanak)Azt én sem értem, az egymásba ágyazhatóság miért nem került képbe, ezt preprocessorok esetén mindenki szereti.
(#1734) honda 1993:
Ezek szerint tehát hivatalosan is elismered, hogy nem nézed meg a neked küldött megoldások egyikét sem? Zedz úgy emlékszem, mintha kétszer is írta volna már korábban is neked a középre igazíthatóságot. Ha nem nézed meg, amit javasolnak neked, akkor igazából minek kérdezed? -
#1723
Sk8erPeter
nagyúr
adam_
#1713
Sk8erPeter
nagyúr
"a mai fjúcsöröknek"
Akarod mondani fíííííííícsöröknek.
»»» feature:
USA: fiː'tʃəː· UK: fiːtʃər
vagy ˈfēCHər
kiejtés:
https://translate.google.com/translate_tts?ie=UTF-8&q=feature&tl=en
Sorry, nem tudtam kihagyni, mert már annyiszor írtad "fjúcsörnek". "legyen egy nagyon egyszerű sallangmentes honlap, akár normális középre igazított reszponzívitás nélküli?"
Közelítsd meg a munkáltató felől a dolgot: ha arra vágynál, hogy legyen egy munkavállalód, aki képes összehozni egy igényes honlapot, akkor mi lenne a meggyőzőbb, egy, a mai kor adottságainak megfelelő, jól áttekinthető, mobilról is könnyen olvasható honlap, vagy egy faék egyszerűségű, mobilon nehezen olvashatóan, zoomolást, ide-oda görgetést igénylően megjelenő tartalom? Persze nehogy félreértsd, nem kell túlzásokba esni, szerintem egy Bootstrap és egyéb segédeszközök felhasználásával elkészített, alapvetően igényesen kinéző, reszponzív honlap elegendő lehet (aminek nem gány a kódja), nem kell telerakni csillivillivel ahhoz, hogy valahova felvegyenek, ami számíthat, az az, ha van referencia, meg hogy meggyőző legyél az interjún. -
#1707
Sk8erPeter
nagyúr
Zedz
#1704
Sk8erPeter
nagyúr
Persze, ez is jogos, de nem hiszem, hogy ha hosszabb távon is komolyan gondolja a dolgot, akkor komoly törést okozna az életében, hogy most kipróbálta a táblázatos megjelenítést... annak idején, amikor tanultam a HTML-t, én is kipróbáltam a táblázatos megjelenítést (akkor még nem attól zengett minden fórum, hogy ha beírod a <table> szócskát, akkor elvisz egy dühös raptor, és letépi a fejed
), és legalább szép lassan rájöttem, miért is tud undorító lenni, például akkor, amikor a táblázatba beágyazott táblázatot találod egyetlen kerülő megoldásnak. Hibázni is kell néha, még ha okos ember más kárából is tanul. Szerk.: meg mint martonx írja, van, amikor nem úszod meg a gusztustalan kókányolást, milyen meglepő, hogy ez a különutas hülyeség és extraszopás igénye is a Microsoft nevéhez köthető...
(#1705) martonx:
Ezt én sem értem, hogy ehhez miért tartozik különálló renderelő motor. Ez még a 2013-as Outlooknál is így van? -
#1703
Sk8erPeter
nagyúr
fordfairlane
#1702
Sk8erPeter
nagyúr
válasz
fordfairlane
#1702
üzenetére
Pontosan! Ugyanerre gondoltam, hogy itt sokan már picit túlzottan agyonerőltetik ezt a "fúj, táblázatot soha, semmilyen körülmények között" dolgot, mintha a táblázatoknak soha nem lenne létjogosultságuk, csak gondoltam inkább elengedem, de örülök, hogy más is így látja, hogy egy ilyen pici, csupán a rendezettség vagy egyszerűség miatt táblázatba rendezett űrlapnál kb. tökéletesen mindegy. Nyilván az ellene szól, hogy ha a jövőben bővíteni szeretné ezt az űrlapot, és az elemek elrendezését kicsit összetettebbé tenni, akkor már találkozhat a táblázatok fejlesztési maceráival (újabb sor/oszlop felvétele után bizonyos sorok/oszlopok merge-ölésének kényszere, csúnya code bloat, stb.) és nonreszponzivitásával.
Félő, hogy az agymosás eredménye még a végén az lesz, hogy ha valakinek ténylegesen klasszikus táblázatra van szüksége, akkor elkezdi divekkel és display:table-cell;-ekkel és hasonlókkal kialakítani azt... -
#1699
Sk8erPeter
nagyúr
Zedz
#1695
Sk8erPeter
nagyúr
A label tag használatára három jobb módszer kínálkozik hozzá kapcsolódó űrlapelemnél (amit tulajdonképpen leír a label, aminek a címkéje/felirata):
1. a label tag tartalmazza magát az elemet, amit leír:
<label>My label <input type="text" ... /></label>
vagy/és
2. a label tag tartalmazza egy for-attribútum értékében az általa leírt elem id-ját:
<label for="mytextfield">My label</label>
<input type="text" id="mytextfield" ... />
3. a kettő kombinációja:
<label for="mytextfield">My label <input type="text" id="mytextfield" ... /></label>Tehát ha már külön van választva a két elem, ahogy a példádban látszik, akkor érdemes id-val jelölni, hogy minek is a címkéje.
A felsorolt módszerek erősen javítják a felhasználói élményt, hiszen a fókusz így a labelre rákattintva is belekerül az általa "vezérelt" űrlapmezőbe.A példádat javítva id-kkel (ja, mondjuk mivel ez a 785-ös edit lett, valszeg nem a Te példád, hanem vetted valami Stack Overflow-s válaszból, ami ilyen szempontból "rossz" volt
):
http://jsfiddle.net/WX58z/785/Habár ez nem kötelező, rontja a felhasználói élményt, ha a labelre kattintva nem ugrik a fókusz a mezőre.
-
#1690
Sk8erPeter
nagyúr
honda 1993
#1689
Sk8erPeter
nagyúr
válasz
honda 1993
#1689
üzenetére
Teljesen attól függ, milyen felbontásról nézed. Tabletnél egyáltalán nem sok, bizonyos mobiloknál sok lehet (az enyém vízszintes felbontása pl. 480px), nagy kijelzővel rendelkező téglafónoknál nem biztos, sok rétegre kell gondolni. Mellesleg mivel óriásira növekedett az okostelók felhasználóbázisa, ezért nem véletlenül terjedt el a "mobile first" fejlesztési koncepció, ami szerint először a kisebb kijelzővel rendelkező eszközökre kezdünk el tervezgetni, aztán haladunk szép lassan felfelé. Persze lehet valahol a kettő közt is, hogy mindkettőt folyamatosan nézegeted. Ahogy érzed.
Na de nézd meg a korábbi egyszerű példát, itt fogd meg a középső rácsot, ami elválasztja a HTML, JavaScript paneleket a CSS, Result panelektől, és kezdd el jobbra húzni, ezzel összenyomva a Result területét, láthatod, hogy a betűszín 500px alatt pirosra változik (pedig korábban fekete volt). Kb. így néz ki, amikor különböző méretektől függővé téve változtatgatod a stílusokat. Ez alá beírhatsz még akármennyi szélességű/más paraméterű stílusdefiníciót is. Vágesz? -
#1688
Sk8erPeter
nagyúr
honda 1993
#1679
Sk8erPeter
nagyúr
válasz
honda 1993
#1679
üzenetére
"az 500px; érték helyett mi lenne a leg ideálisabb ?"
Nincs ilyen, hogy ideális méret, olyan szélességekre optimalizálsz, amilyenre akarsz. Te találod ki, és tesztelgeted, hogy ahogy váltakozik a felbontás, hogy néz ki az oldal. Erre a böngészőkben található fejlesztőpanelt mindenképpen használd, hogy le tudd tesztelni. MÁR MOST kezdj el ismerkedni vele, és akkor jobban fogod talán érteni, hogy működik a dolog, hogyan váltakozik a stílus a felbontás váltakozásával. Ez amúgy eddigi próbálkozásaim alapján a FF-ban speciel jobban működik, mint pl. Chrome-ban (amikor Chrome-ban totál mindegy, hogy változtatom a szélességet, az oldal csak arányosan kisebb lesz, mintha kizoomolnék belőle, de a stílus nem nagyon változik, az elég zavaró tud lenni, volt már ilyen párszor)."Jólvanna, ez idáig is világos volt, csak azt nem értem hogy ha nekem 500px; van megadva, akkor az hogyan lehet hogy a telefonon automatikusan a mobil nézet jön be..."
Ezt a kérdést már csak azért sem értem, mert Zedz pontosan ilyenre mutatott neked példát, hogy ahol 500 pixel a maximális szélesség, ott az az adott stílus legyen érvényben.
Ezt a végtelenségig bővítheted például úgy, ahogy Zedz mutatta, ahogy fordfairlane linkelte neked a tutorialt, ahogy DNReNTi is próbálkozott átadni az üzenetet, meg mindenki, aki elég kitartó volt.
Melyik része nem világos?
Egyszerű példa: van X szélesség, arra így néz ki az adott div, van Y szélesség, arra így, van Z szélesség, arra meg amúgy. Lényegében ezeket változtatgatod, nincs benne különösebb mágia. Persze nem csak szélesség létezik, hanem más szempontok is, mint a többiek már írták.Egyébként nem kell minden egyes breakpointra külön-külön CSS-fájlt csinálni, lehet egy nagy CSS-fájlod is (vagy pl. több szélesség egy fájlban).
"Hiszen a px; érték egy távolság, nem pedig egy méret."
Hogy mi a büdös bráner van? -
#1668
Sk8erPeter
nagyúr
DNReNTi
#1667
Sk8erPeter
nagyúr
válasz
DNReNTi
#1667
üzenetére
"Na de vissza a lényegre, attól mert már elterjedtebbek a nagyobb felbontások mint az ősi 1024-1260, én még nem tenném a desktop nézetet az e feletti felbontástartományba, rákényszerítve a kisebb felbontáson netezőket a tablet nézet használatára."
Ezt a tabletnézetre "kényszerítést" most nem értem: pont az a lényege a reszponzív kialakításnak, hogy nincsenek különálló desktop és mobil (vagy tablet) nézetek, hanem az oldal elemei felbontástól függően másképp helyezkednek el, kicsit máshogy néznek ki (pl. más szélességűek, stb.), de egyéb tekintetben az oldal ugyanaz. Szóval pl. teszteled, hogy kisebb szélességen hogy néz ki, aztán mi van, ha nagyobb felbontáson nézed, és így tovább, és közben szépítgeted.
Nem úgy, mint itt, a PH!-n, ahol a kissé lejárt, béna, különdomaines, mobilfelületre átirányítós megoldás van (m.prohardver.hu aldomainen). -
#1647
Sk8erPeter
nagyúr
DNReNTi
#1643
Sk8erPeter
nagyúr
válasz
DNReNTi
#1643
üzenetére
"Szerintem a többség (pl én) default-nak a desktopot tekinti, ami ugye az 1024-1260px szélesség körül/között mozog"
What? Saját felhasználási szokásainkból nem érdemes átlagot vonni. Azért manapság elég gyakoriak a nagy monitorok (épp ilyenen bámulom a fórumot), pl. egy 24"-es monitoron a min. 1920×1080-as felbontás elég valószínű, és ez a felbontás manapság egyáltalán nem számít extrémnek. Több ismerősömnek is van ekkora monitorja, meg itt a fórumon is sokan rendelkeznek ilyennel, de ez alapján sem érdemes átlagot vonni (létezik ugye 27"-es monitor is, meg persze gyakoribb az ennél kisebb monitor), ettől függetlenül kijelenthető, hogy egyre többen relatíve nagy monitoron böngésznek, mert már elérhetőbb áron kaphatók egész jó minőségűek. De még a laptopomnál is a nem túl izmos 1366x768-as felbontás a jellemző, ez a szélesség is nagyobb, mint amit írtál (BTW 15.6"-es kijelző).
Aztán lehet csavarni a dolgon, a tálcát ki szoktam rakni a default alsó elhelyezésről bal oldalra (függőleges lesz), így az 1920-as vagy épp 1366-os (vagy ha további másik monitor, akkor megint más) szélesség csökken, cserébe a függőleges terület nagyobb (ez nagyon sokszor jól jön, mert kevésbé szélesek szoktak lenni pl. a honlapok is, mint a hosszanti (függőleges) tartalom az érdekes), szóval a szélességek össze-vissza változnak - ez utóbbi tény persze nem túl meglepő, csak a tesztelés miatt mondom, ami a developer toolokkal is könnyen elérhető (ebben mondjuk az én tapasztalatom szerint a Firefox különböző felbontásokra tesztelést lehetővé tevő eszköze jobb, mint a Chrome-é, pedig utóbbit gyakrabban használom).
Az 1024 pixeles szélesség asztali monitornál azért manapság már ritka (legalábbis jóval ritkább, mint az ennél nagyobbak).
Szóval elméletileg sok szélességre kellene tesztelni, nyilván túlzásokba sem érdemes esni, mert az a karbantartást is nehezíti.A media query-k, meg általában a reszponzivitás nem úgy tekintendők, hogy van az én kijelzőm, és aztán vannak az annál kisebbek.
Sanszos, hogy vannak nagyobbak is, amikre elméletileg szintén gondolni kéne.Egy példa: a Javítsuk a Prohardvert! topicban néhányan panaszkodtak, hogy egy nagy monitoron (pl. 24"-en) már hülyén néz ki a "csíkfórum", tehát hogy középen van egy, az elérhető területhez képest relatíve szűk csík, amin elhelyezkednek a hozzászólások, a többi terület kihasználatlan. Bár az olvashatóság miatt szerintem nem rossz a korlátozott oszlopszélesség (ha nagyon széles lenne a hozzászólás, rontaná az olvashatóságot sztem), vannak, akik szerint valamilyen módon jobban ki kellene használni a helyet.
Szóval nem árt olykor gondolni a nagyobb kijelzőkre is (bár tény, hogy nem egy egyszerű kérdés, hogy egy akkora területen mi az, ami még nem nézne ki idétlenül).(#1636) PumpkinSeed:
Úgy értem, ahogy itt fentebb írtam.
Meg ahogy fordfairlane is írta. Szerk.: és velem pont egyszerre hasonlót írt, azzal a kiegészítéssel még jobban érthető a mondandónk. -
#1635
Sk8erPeter
nagyúr
PumpkinSeed
#1633
Sk8erPeter
nagyúr
válasz
PumpkinSeed
#1633
üzenetére
"A reszponzív design csak akkor lép érvénybe
n, ha az eredetileg tervezett felbontásnál kisebb felbontáson is szeretnéd megjeleníteni az oldalad."
Vagy épp nagyobbon. -
#1625
Sk8erPeter
nagyúr
#39417856
#1624
Sk8erPeter
nagyúr
válasz
#39417856
#1624
üzenetére
Azt ugye tudod, hogy a borzalmas kódon semmit nem javítottál, pedig ketten is jeleztük neked, hogy bőven van vele gond? Senkit nem zavart az oldal kinézete eddig sem, a kód elavultsága, a kifejezetten kerülendő megoldások alkalmazása viszont annál inkább. Az előbb egész konkrét megoldás(oka)t is linkeltem, amik arról szólnak, hogy hogyan oldd meg, hogy még mobilon is élvezhető legyen az oldalad (ehhez képest ugyan reagáltál, de valamiért mintha a tartalmat nem értetted volna meg, amit írtam neked). Jelen formájában ez közel sem mondható el róla, hogy élvezhető lenne mobilon, pedig egyelőre túl sok módosítást nem igényelne, kb. le kéne másolni az előbbi hsz.-emben mutatott linken szereplő példát, és átszabni a saját ízlésedre.
Még most csináld meg a módosítást, mert a mostani, kezdeti kialakításod gány fos, később sokkal nehezebb lesz már átalakítgatni. -
#1623
Sk8erPeter
nagyúr
#39417856
#1621
Sk8erPeter
nagyúr
válasz
#39417856
#1621
üzenetére
A kérdésre reagálva: ilyen - KERÜLENDŐ - táblázatos esetben a "szöveg" részt tartalmazó cellának adhatsz egy vertical-align: top; tulajdonságot, és akkor fölülre kerül. De ezt csak érdekességként írtam, egyébként felejtsd el a megoldásodat, mert nem jó, a kódod tele van hibákkal, elavult tagekkel, ezenkívül az a gáz, hogy most készítettél egy klasszikus táblázatot, ami ugyan félig megoldotta a problémát, de valójában nagyon sok gond van a táblázatos layouttal, nem véletlenül nem használják: rugalmatlan, kényelmetlen a bővítgetése, és ami főleg gond, hogy nem a reszponzivitásáról híres, tehát pl. mobilon jobbra-balra kell görgetni ahhoz, hogy meg tudd nézni a táblázatos oldal különböző részeit.
Sőt, rájöttem, hogy tök szar a példa, amit korábban linkeltem, nem néztem meg rendesen, sorry, viszont itt van egy Bootstrapes, sztem már sokkal jobbnak tűnő, reszponzív megoldást kínáló válasz:
http://stackoverflow.com/questions/10771713/twitter-bootstrap-same-heights-on-fluid-columns/14004918#14004918
Konkrét demó:
http://jsfiddle.net/panchroma/D4xdE/
(kattints a TidyUp gombra, hogy szebb legyen a kód!) -
#1620
Sk8erPeter
nagyúr
#39417856
#1619
Sk8erPeter
nagyúr
válasz
#39417856
#1619
üzenetére
Ez pont erről szól:
http://css-tricks.com/fluid-width-equal-height-columns/
Itt egy demo:
http://css-tricks.com/examples/FluidEqualHeightFauxColumns/ -
#1617
Sk8erPeter
nagyúr
#39417856
#1612
Sk8erPeter
nagyúr
válasz
#39417856
#1612
üzenetére
Ha javasolhatom, annak érdekében, hogy választ kapj, rakj fel jsFiddle-re egy szemléltető példát, mert anélkül a legtöbb segítő szándékú emberkének nincs kedve belekezdeni sem az agyalásba, mert akkor az ő idejéből vesz el sokat (és itt mindenki ráérő idejében segít, hobbiból, szakmai érdeklődésből).
-
#1616
Sk8erPeter
nagyúr
honda 1993
#1605
Sk8erPeter
nagyúr
válasz
honda 1993
#1605
üzenetére
Érdekelne ennek a dolognak a pszichológiája, hogy ilyenkor mi zajlik a lelkedben, ha valamit épp 10 perce kezdtél el olvasgatni, és szinte előre érzed, hogy kínos lesz a kérdés, miért nem olvasol még egy pár
(szor 60)perccel tovább? -
#1587
Sk8erPeter
nagyúr
DNReNTi
#1586
Sk8erPeter
nagyúr
válasz
DNReNTi
#1586
üzenetére
Amit én linkeltem, ott nem kell kattolni.
Ott a hoverre reagál. Ha egy gyerekelem fölé viszed az egeret, akkor egyben nyilván a szülőelem fölé is, tehát ezzel már lehet játszani. Na persze abban igazad van, hogy ez azért elég korlátos, szóval simán lehet, hogy az adott helyzetre nem alkalmazható, de ehhez látnunk kellene, miről van szó, mert lehet, hogy működne az, ami a példakódban. -
#1585
Sk8erPeter
nagyúr
^Boss
#1581
Sk8erPeter
nagyúr
Mit jelent az, hogy "nem megy"? Amit linkeltem, ott még egy jsFiddle-példa is van a szemléltetésre.
Ha te is felraknál egy egyszerűsített jsFiddle-példát a saját kódoddal, akkor meg is tudnánk mondani, mit csinálsz rosszul.(#1583) ^Boss:
Ezt akkor már úgy illik írni, hogy .css("valamitulajdonság", "valamilyenérték"), tehát mondjuk .css("display", "none"), DE mivel pont az elrejtésre való, értelmesebb lenne használni a .hide() metódust, ennek paraméterül még azt is átadhatod, hogy mennyi idő alatt tűnjön el az elem. -
#1579
Sk8erPeter
nagyúr
^Boss
#1578
Sk8erPeter
nagyúr
Sztem simán CSS-sel ez csak úgy működik, hogy van egy közös szülőelem, és aztán így:
http://stackoverflow.com/questions/17393231/css-on-hover-show-and-hide-different-divs-at-the-same-time/17393262#17393262 -
#1573
Sk8erPeter
nagyúr
honda 1993
#1572
Sk8erPeter
nagyúr
válasz
honda 1993
#1572
üzenetére
"CSS3 gradient", ezt írd be Google-be, és számtalan találatot fogsz kapni, vannak generátorok is, amik arra jók, hogy kiválasztod a megfelelő színátmenetet grafikus felületen, és ahhoz generálódik egy CSS-kód (aminél lehet régebbi böngészőkre is támogatás).
-
#1570
Sk8erPeter
nagyúr
Zedz
#1568
Sk8erPeter
nagyúr
Nem tudom, szerintem ez már a felesleges agyalás kategória.
Kategorikusan nem érdemes kijelenteni, hogy erre érdemes, erre nem, úgyis a helyzet dönti el; na meg lehet tömörítve is átküldeni ezeket a fájlokat a hálózaton, lehet CDN-t használni, meg ott van a böngésző gyorsítótára (így többszöri látogatáskor gyorsítótártörlésig vagy fájlmódosulásig csak egyszer kell letöltenie a felhasználónak), meg aztán lehet, hogy a minimális letöltendő méret elérése a cél, de lehet, hogy az a 100 KB már pont nem számít, blablablabla, mindig attól függ.
Azzal sem értek egyet, amit DNReNTi írt, hogy "ágyúval verébre"-kategória lenne, minimalista oldalnál is megérheti a kapott szolgáltatások miatt (pl. reszponzivitás, amit nem kell megint megírni, de persze biztos van minimalistább stylesheet is).
De mindenki el tudja dönteni, hogy adott helyzetben megéri-e kézzel összerakni a stíluslapokat, vagy felhasználja azt a munkát, amit már más elvégzett helyette.==================================
(#1569) adam_:
Szerintem az ilyen pénzbe kerülő plecsnik helyett sokkal jobban megéri inkább referenciákat gyűjteni (akár haveroknak/családtagoknak/ismerős cégének/akárkinek fejlesztett, igényesebb honlap fejlesztése is jobb lehet; meg ha valamilyen papírról van szó, ami számíthat, akkor az inkább már egyetemi/főiskolai szakirányú képzettség), a munkáltatót az többnyire sokkal jobban érdekli. -
#1566
Sk8erPeter
nagyúr
Zedz
#1565
-
#1564
Sk8erPeter
nagyúr
Zedz
#1561
Sk8erPeter
nagyúr
Azért ez attól is függ, hogy van-e már kész sablon arra a bizonyos webshopra vagy sem, ha 0-ról kezdik írni, akkor a "nem sok mindent lehetne onnan hasznosítani" nem igaz, kapásból kézhez kapsz egy komplett gyűjteményt a reszponzivitás és még rengeteg más kialakításához, valami alapvető stílussal való felruházásához, persze aztán még erre ráépülhet az egyedi dizájn.
Ez sem fekete vagy fehér (szóval nem csak az van, hogy egyszerű oldalhoz oké, komplexhez nem oké), sztem a Bootstrapet vagy más hasonló frameworkszerűséget simán lehet kiindulási alapnak használni egy komplexebb oldalhoz is, szóval elég hasznos tud lenni, ha ismer ilyet.Szerk.: martonx megelőzött, közben ő is írt neked választ.
(#1562) martonx:
Egyetértek, tényleg nagyon jó a doksija a Bootstrapnek.(#1563) martonx:
Szerintem minimalista oldalra is jól lehet használni. A minimalista oldalt is simán lehet, hogy valaki mobilon is jól olvashatóvá akarja tenni, de nem akar tökölni az alap kézzel való megírásával. Mondjuk számolni kell azzal, hogy a Bootstrap saját fájlocskáit is be kell töltögetni. -
#1490
Sk8erPeter
nagyúr
DNReNTi
#1489
Sk8erPeter
nagyúr
válasz
DNReNTi
#1489
üzenetére
Sőt, a visibility, opacity és transition segítségével némi áttűnéssel is lehet játszani.
>> http://jsfiddle.net/pad5q1kx/1/ -
#1471
Sk8erPeter
nagyúr
honda 1993
#1470
Sk8erPeter
nagyúr
válasz
honda 1993
#1470
üzenetére
Ja, de illik feltüntetni a kép forrását.
-
#1469
Sk8erPeter
nagyúr
Jim-Y
#1467
Sk8erPeter
nagyúr
De, teljesen logikus, csak értelmezni kell a szavakat.
"A vélemény szó utalhat arra, hogy amit írok azt saját kútfőből teszem, és nem másolom valahonnan"
Nem, a vélemény nem csak sajátod lehet, hanem lehet másé is. A vélemény pont az, amit idéztél az előbb ("egy személynek a saját nézőpontjából kiinduló elgondolása a dolgokról"), úgyhogy ez most félremagyarázás, ha másolnád/idéznéd valahonnan, akkor az attól még, hogy nem a saját nézőpontod, ettől még lehetne akár más véleménye is, ebből következően a másolt szöveg az illetőnek a saját nézőpontjából kiinduló elgondolása, következésképp továbbra sem lehet objektív.
Ha viszont száraz tényeken alapuló szöveget írsz (pl. leírod, hogy van gravitáció), vagy épp ilyeneket másolsz valahonnan (tök mindegy, milyen forrásból származik), az már nem vélemény - ergo nem is szubjektív, hanem objektív.A "szubjektív vélemény" szavak összetétele tehát redundáns, és tulajdonképpen értelmetlen (mivel vélemény sosem lehet objektív).
Én szívesen OFF-olok erről még pár hsz.-en át, bármilyen szőrszálhasogatás is, eldumálhatunk róla, de mások nem biztos, hogy díjazzák.(#1468) martonx:
Egyetértek, ezek a határok amúgy is legtöbbször szerintem elmosódnak, nincs olyan, hogy mondjuk a "web-developer" "nem ért" a design-hoz semmilyen szinten, vagy hogy a "backend-ninja" ne értene a kliensoldalhoz, "nem ért különösebben a browserhez, JavaScripthez, CSS-hez, HTML-hez", szerintem ez bullshit, elég nagy probléma, ha ilyen szinten csőlátású egy webfejlesztő, akár a frontenden, akár a backenden dolgozik.
Azért nekem elég fura lenne, ha valaki PHP expert lenne, de fingja nem lenne, hogy működik a böngésző, hogy kell leírni egy működő kódot JavaScriptben, és ne tudná, hogy kell CSS-sel formázni, vagy HTML-ben pötyögni... -
#1462
Sk8erPeter
nagyúr
adam_
#1458
Sk8erPeter
nagyúr
"Apropó Photoshopos, Illustratoros okosságok mennyire játszanak fontos szerepet?"
Hát szerintem frontendesnek kötelező ismernie valamennyire (mindenképp) vagy nagyon (attól függ, egész pontosan a munkakörnél mit értünk most frontend alatt (lehet, hogy kb. mindent beleért a munkáltató, amit az ügyfél a honlapodból lát, lehet, hogy annak csak egy szeletével foglalkozik), kicsit sztem elmosódik ez a fogalom) a Photoshopot."Unterschiede zu XHTML und HTML4"
Hát nem tom, szerintem az XHTML és HTML4 különbségeivel most tök felesleges foglalkoznod, foglalkozz azzal, amivel a jövőben is fogsz, tehát HTML5-tel. Aztán majd ha később mégis érdekel, majd magadtól megtanulod, mi is az az XHTML.Amúgy tényleg alaposan nézz körül, hogy egy adott tanfolyamról milyen visszajelzések vannak (ha lehet ilyen véleményeket olvasni valahol), mert túl sok helyen túl sok a kókler, aki elmegy tanárnak, mert azt hiszi, ért hozzá (még BME-n is találkoztam olyan webfejlesztő kurzussal (szabadon választható tárgy volt, kíváncsiságból felvettem), ahol nekem égett az arcom a tanár nevetségesen elmaradott (90-es évekbeli) tudásától és leadott tananyagától (még valaki komolyan veszi); de szerencsére ennek ellenkezőjét is tapasztaltam, egy Microsoftnál is dolgozó emberkétől, akitől rengeteget lehetett tanulni, és nagyon képben volt).
Németországban tartózkodsz egyébként?
(#1461) Jim-Y:
"ami jön az szubjektív vélemény"
És megint Egy vélemény még mindig csakis szubjektív lehet... Olyan nincs, hogy "objektív vélemény", mivel a kettő kizárja egymást. Muszáj volt megjegyeznem. -
#1455
Sk8erPeter
nagyúr
adam_
#1454
Sk8erPeter
nagyúr
"Az SVG2 nyelvet mennyire érdemes elsajátítani a HTML5 és a CSS3 mellé?"
Annak ellenére, hogy összességében nyilván nem haszontalan, szerintem teljesen felesleges egyelőre foglalkoznod vele, inkább mélyítsd az eddigi tanulmányaidat, plusz kezdd el inkább tanulni pl. a (kliensoldali) JavaScriptet. Aztán jöhet valami szerveroldali nyelv. -
#1448
Sk8erPeter
nagyúr
adam_
#1445
Sk8erPeter
nagyúr
Nem árt odafigyelni a szintaxis-kijelölésre, nem véletlenül van, a pirossal jelölt tagek jelzik a hibát:
Ha kijavítod, máris nem látod a piros részt:
A lényeg: a Termékeink list itemet előbb lezártad, mint kellett volna, pedig az tartalmaz egy másik unordered listet is, ezenkívül az <ul> tag megfelelő lezárása az </ul>.
Itt az új változat:
http://jsfiddle.net/tob7fqec/5/
![;]](http://cdn.rios.hu/dl/s/v1.gif)
).
Ha jól értem, csak az a baj, hogy el vannak csúszva a gyerekelemként definiált <ul> elemek, és azok beljebb tolódnak, emiatt csúnya lesz. De szólj, ha nem ez a gond.
Az ez_lesz_a_lenyilo_gyerekelem osztállyal ellátott divet meg hoverre kéne előhozni, ez elvileg CSS-sel is megoldható, keress utána a dropdown menu CSS keresőszavakkal. (Természetesen sose legyen ilyen hülye nevű osztályaid, főleg ne magyarul, csak hogy érthető legyen a kód, itt azért alkalmaztam.)
"
Mivel azt tudja. (És az most "mindegy" (kérdés, hogy tényleg mindegy-e, vagy lesz különbség, ugyanaz-e az előfeldolgozó minden tekintetben, bár gondolom alapvetően igen), hogy magát a CSS-fájlt szerveroldalon gyártod le, vagy a klienssel erőlködöd ki.)
Új hozzászólás Aktív témák
Hirdetés
- AMD Ryzen 7 5700X processzor eladó /Garanciás/
- Xbox Series S + 2 kontroller
- Dell laptop eladó i5 11. gen, 8GB RAM, 512GB SSD, újszerű állapotban!
- Bomba ár! HP EliteBook Folio 1040 G1 - i5-G4 I 8GB I 256GB SSD I 14" HD+ I Cam I W10 I Garancia!
- Bomba ár! HP Elitebook Folio 9470M - i5-3GEN I 8GB I 256GB SSD I 14" I DP I Cam I W10 I Garancia!
- Telefon felvásárlás!! iPhone 13 Mini/iPhone 13/iPhone 13 Pro/iPhone 13 Pro Max
- ÁRGARANCIA!Épített KomPhone Ryzen 7 5700X 16/32/64GB RAM RX 7600 8GB GAMER PC termékbeszámítással
- ÚJ HP EliteBook 840 G8 - 14"FHD IPS - i5-1145G7 - 32GB - 512GB SSD - Win10 - 6 hónap Garancia
- DELL PowerEdge R630 rack szerver barebone - 2xSocket 2011v4 , 24x DDR4 DIMM, H330 RAID, 39369Ft+ÁFA
- Xiaomi Redmi 10 128GB, Kártyafüggetlen, 1 Év Garanciával
Állásajánlatok
Cég: Promenade Publishing House Kft.
Város: Budapest
Cég: PC Trade Systems Kft.
Város: Szeged