Miért nem engedik a böngészők CSS-sel változtatni a checkbox, select, Tallózás elemeket?
2021 van, modern honlapok készítésére van lehetőség CSS-sel, Flexbox-szal, html5-tel.
Amit nem értek (próbáltam utánajárni, az okának), hogy miért nem engedik a böngészők CSS-sel változtatni a checkbox, select, Tallózás, stb. alap elemeket?
Miért vagyunk arra kényszerítve, hogy mindenféle hack megoldást alkalmazzunk, ráadásul van amit nem is lehet rendesen, pl. a Tallózás gombot.
Magát a jelenséget nem értem. Ez valami beteges maradvány a böngészőháborúból, hogy mindenki ránk kényszerítse a saját ronda elemeit?
■ Amit nem értek (próbáltam utánajárni, az okának), hogy miért nem engedik a böngészők CSS-sel változtatni a checkbox, select, Tallózás, stb. alap elemeket?
Miért vagyunk arra kényszerítve, hogy mindenféle hack megoldást alkalmazzunk, ráadásul van amit nem is lehet rendesen, pl. a Tallózás gombot.
Magát a jelenséget nem értem. Ez valami beteges maradvány a böngészőháborúból, hogy mindenki ránk kényszerítse a saját ronda elemeit?
Valahogy úgy. Egyébként lehet
Engedik
Egyedül a file input nehézkes egy kicsit, mert több részből áll, de szó sincs arról, hogy ne "engednék".
2021-ben - ha később nem is akarod felhasználni - próbaképpen húzz be a projektbe egy népszerű frontend keretet (pl Bootstrap, de más is lehet), csinálj vele egy teszt-formot, és nézd meg, milyen szelektorokkal milyen szabályokat használ. Sokat lehet belőle tanulni; ha utána nem is használod élesben, akkor is jócskán lehet tanulni a meglévő modern FE keretekből. Ezeket - a népszerűbbeket - sokan fejlesztik, így sok ember tudása benne van.
Aztán ha valamelyik megtetszik, az se baj, ha "bent hagyod" a projektben és használod, nekem legalábbis már nemigen van időm és türelmem arra, hogy 0-ról én írjam az összes css-t...
Drupal Zen témából indulok ki
Csak hát a gányolás elkerülhetetlen, amit nem szeretek.
Ha engednék, az azt jelentené, hogy lenne rá CSS separator, ami kedvünk szerint engedné a változtatás, nem eltüntetni, meg átlátszóvá tenni az elemeket, stb.
A Bootstrap-ot is néztem, de az túl összetett, meg kéne az egészet érteni, túlságosan kötve vagyok akkor.
Én a 90-es évek vége óta
Én nem így látom.Szerintem
Szerintem elég tempósan haladunk afelé, hogy egységes legyen a böngésző.
Lassan nem marad más, mint a chrome... pardon, chromium alap.
A mozilla már egy éve dolgozik a firefox tempós tönkretételén, a MS már chromium a ... más most nem is nagyon jut eszembe ami elterjedt.
Opera/vivaldi még talán ott vannak, de helyenként a vivaldi kísértetiesen chrome-szerű... nem tudom, miért. (felhasználóként mondom)
ui: ja, meg a Safari ami talán kilóg mindebből.
Ja Firefox-nál ha megnézed a
Opera, meg a többi.
Hogyan teszi tönkre a Mozilla
Akkor te nem használod
Már az első váltás pár évvel ezelőtt is, finoman szólva katasztrofális romlást hozott a használhatóságban, ez az egészen új, amivel a bővítmények 90%-a ment a kukába... egyszerűen tragikus.
A közelmúltban kirúgták a fejlesztők nagy részét.
Sok jót ezek után nem várok tőlük.
De, androidon is a kedvencem.
Tákolás
Egyrészt ugyebár a frontend "NeM IGaZi PrOgRAmOzÁs". Főleg a HTML és a CSS, és elkezdtek mindent áttolni JS-be. Mert hát CSS-sel nem lehet problémákat megoldani, de akik ezt mondják azoknál a CSS kimerül abban, hogy:
A másik probléma meg az, hogy még mindig megpróbálják a webes megjelenítést megerőszakolni egy pixelpontos elrendezéssel bármilyen eszközön (mert nyomtatásban az milyen jól működik) ahelyett, hogy egyszerűen a használhatóságra mennének.
+1
color: red;miért nem important?... :-DKonzisztencia
Probléma
A probléma inkább az, hogy van nekünk a HT*, ami tök jó dokumentumok megosztására a hálózaton, csak hát az igények túlnőtték. Nem elég már, hogy csak megjelenítjük böngészőben, hanem szerkesszük is böngészőben, közben videócseteljünk is mellette szintén böngészőben, satöbbi. Az a véleményem az egészről, hogy tököt kéne növeszteni és azt mondani hogy a HTML akkor maradjon csak meg dokumentumoknak, és mellé/fölé valami olyan alkalmazások írására alkalmas tech rakást odatenni, ami tényleg alkalmazások írására van kitalálva. Mert — továbbra is csak véleményem szerint — ezzel a HTML5-tel és a modern webnek csúfolt valamivel csak egy seggel próbálunk meg két lovat megülni. És valamiért tudomást sem akarunk venni arról, hogy így akár a két ló közé is be lehet esni. Szerintem.
Volt ilyen, java applet,
Annyi légy nem tévedhet
Korai APEH adóbevallás?
Vagy az nem applet volt?
Azon túl csak egykori munkahelyem egyik csodaszoftverét tudnám emlegetni, de esetleg elpirul a háttérkép is :D
Korai APEH adóbevallás?
Vagy az nem applet volt?
Nem tudom, akkoriban még nem kellett adóbevallással foglalkoznom.
A Flash azt hiszem többé
Tudtommal a html továbbra is
Most inkább úgy tűnik, hogy a tömegek megragadtak az IE korszakban és oda-vissza erőszakolják meg* a fenti három technológiát olyan dolgokkal, amik nem a feladatuk, és csodálkoznak, hogy nem, lassan, vagy rosszul működnek.
Plusz mindenkinek meg van ígérve, hogy 5 perc alatt fb klónt csinálhat, "jótékonyan" hallgatva a szükséges tudásról és az oda vezető útról. Emberi problémákat akarunk megoldani technológiai megoldásokkal*. Az embereket kéne segíteni a fejlődésben ahelyett, hogy hozzávágunk a dologhoz még "5 kiló technológiát", aztán furcsálljuk, hogy az emberek nem tudnak kiigazodni rajta.
* Gondolok itt a css-in-js vagy a
<span class="button"></span>jellegű csodákra.Hogy őszinte legyek én már a
Kulcsszó: "struktúra"
Kicsit részletezve:
- HTML: mit akarok megjeleníteni
- CSS: hogyan jelenik meg, milyen színű, mekkora, legyen-e körülötte rózsaszín köd, stb
- JS: mi történjen akkor, amikor a user pl megnyom egy gombot.
Aztán sajnos azok miatt, akiknek meg lett ígérve,
(Egyébként attól, hogy js-ből változtatsz html-t vagy css-t, ezek még mindig különálló leíró nyelvek maradnak.)
Nem akarlak meggyőzni, mert a technológiai szabványok feladata nem az, hogy egy-egy embert meggyőzzön, hanem az, hogy ha sok ember akar azonos technológiát használni, akkor ezt megtehessék, egyforma tudásszinttel egyforma minőséget tudjanak létrehozni.
A CSS-sel
Például nem véletlen, hogy megjelentek a CSS-animációk. A JS animációk teljesítménye olyan gyatra volt, hogy kellett egy jobb, gyorsabb megoldás: CSS. Vagy pl. a masonry layout.
Arról nem is beszélve, hogy a JS nem csak akkor nem működik, ha valaki direkt kikapcsolja. Reklám- vagy szkriptblokkolók, hibás vagy direkt szűrő proxyk, szakadozó/hullámzó kapcsolat mind okozhatják. Vagy akár egy nem 100%-ig bugmentes JS kód is futhat úgy hibára, hogy a layout engine leáll (vagy a layout engine hibája miatt áll le az alkalmazáslogika; egyik se túl szerencsés).
Mondjuk furcsa, hogy az IT más területein azért "harcolunk", hogy minden csak a saját feladatát oldja meg (SRP), vagy ne kelljen ugyanazt többször megcsinálni (DRY), de a JS-be csak azért is bele próbáljuk erőltetni a layout/megjelenítés számolását, újra meg újra megoldva azokat dolgokat kevésbé hatékonyan, amik CSS-ből már működnek, ráadásul nagyobb hibatoleranciával.
Mondjuk furcsa, hogy az IT
Az SRP teljesen más kontextusban értendő. A HTML és a CSS domain specific language-ek, a JS meg general purpose language. Ennyi erővel minden alkalmazáshoz tervezhetnénk külön nyelvet könyvtárak helyett, ha ez így működne. Szerintem csak arról van szó, hogy sokan nem voltak hajlandóak a HTML helyett valami újat megtanulni. Ami végülis oké, ha csak néhány dokumentumot akarunk a weben megjeleníteni, de ha alkalmazás fejlesztésről van szó, akkor gagyi a HTML.
Nyilván
Ezen felül, ahogy Pepita mondta, attól még, hogy JS-ből piszkálják egyesek a CSS-t, attól az még CSS marad. Ha nem értik a CSS-t, akkor JS-en keresztül sem lesz egyszerűbb jó, hatékony CSS-t írni. Tehát végeredményben a szuboptimális CSS-üket még megfejelték némi szükségtelen JS feldolgozási és futtatási idővel, ami elég kontraproduktívnak tűnik.
Szerintem csak arról van szó, hogy sokan nem hajlandóak a JS helyett valami "újat" (khm, az alapokat) megtanulni :)
Ezen felül, ahogy Pepita
Jó, de én egyáltalán nem erről beszéltem, hanem hogy amikor annak idején 20 éve behozták a CSS-t, akkor kellett volna egy kicsit átgondolni, és helyette JS-el megoldani. Biztos, hogy abban is elérhető ugyanez a sebesség, mint CSS-el, ha hajlandóak ráfordítani a fejlesztési időt. És akkor nem kellett volna tök feleslegesen még egy nyelvet megtanulni, vagy mondjuk azon agyalni, hogy ez a stílus, amit egy elem éppen kapott a CSS, HTML vagy a JS fájlban van megadva. Na mindegy ez a hajó már 20 éve elment, úgyhogy kár vitatkozni rajta.
Nem hozták be
Emellett sok más asztali szoftverben is megszokott volt a '90-es évektől, hogy a megjelenésre vonatkozó adatokat (pl ablak, gombok mérete, felirata) külön tárolja a működéstől (pl windows alatt *.ini fájlok).
Remélem feltűnt, hogy idáig csak dokumentum, kinézet, szerző és felhasználó szerepelt. Még semmi sem "működik", csak visszamentünk az alapokhoz.
És akkor az érdekesség:
Megjegyzem: valószínűleg sokkal kevesebb és másmilyen webfejlesztők lennének ma, ha egykor meggondolatlanul "összegyúrták" volna a nem összeillő dolgokat.
Az tud cumi lenni ebben, amikor pl js-ből kap további css class-t az elem, vagy netán inline style-t: böngészőben az látszik, hogy ott van, az nem, hogy "js-ből jött". Ezért sem szabad js-ből "design-olni".
Alapok: HTML, CSS, JS. Ebben a sorrendben. Valószínű Neked a CSS kimaradt, vagy nincs elég jó szinten, ezért szeretnéd js-ből megoldani. Mindig sokkal lassabb lesz úgy, mert újra kell építeni hozzá a DOM-ot (egy részét).
Csinálj szép weboldalt teljesen js nélkül, meg fogod látni, hogy valójában nem kell a megjelenéshez js.
Én úgy emlékszem, hogy annak
Na visszanéztem, mégiscsak
Ilyesmi kódok voltak 2000 előtt, némi JS-el megtűzve tipikusan ellenőriztek, hogy IE vagy NS böngészőben fut e a kód, néha kiírták, hogy csak IE-re van optimalizálva az oldal meg ilyesmik. Olyat nem találtam most, amiben már JS is van, de még CSS nincsen. Inkább csak ilyen menü szín változtatások voltak mikor ráhúztad az egeret meg tényleg alap dolgok. Azért logikusan jött volna, hogyha amúgy is valamennyire a kinézetért és az animációkért a JS felel, akkor azzal csinálják meg a megjelenítést.
Bocsi, de
Mi történik akkor, amikor js-el "animálsz"?
1. betöltődik a html
2. betöltődnek (jó esetben aszinkron) a hozzá tartozó css és js fájlok, valamint képek, egyéb statikus tartalmak.
3. a böngésző rendereli az oldalt (kvázi "lefordítja" a html-t + css-t + megjeleníti a képeket) - ez egy szál
4. elindul a js animációd (új szál, ráadásul interpreteres nyelv)
5. Hopp, megváltozott a DOM, SOS renderelni kell! - veszi észre az első szál.
6. újrarenderel (első)
7. közben tovább futott a második is, és jön a következő módosítás (pl csak inline style-ban egy width értéket változtatunk adott sebességgel)
8. Úristen már megint! - mondja az első szál
És ez így megy, mondjuk 3 sec alatt 60-szor, mire sikerült "leanimálni", hogy a user valami fölé vitte az egeret...
Mi van, ha css-el animálod ugyanezt?
A 3. pont annyiban változik, hogy a zárójeles rész kicsit kibővül. A css "fordítása" közben - mivel hover volt az esemény - már "ráakasztja" a célzott elemekre az eseménykezelőt (core szinten, nem egy interpreteres nyelven), plusz előre kiszámolja az animációhoz szükséges matekot.
Amikor "jön a hover", már semmit nem kell matekolni (pláne nem neked js-ből), és gyönyörűen megjeleníti amit kell, nem "akad" és nincs se "hopp", se "Úristen".
Nos ezért a css-ben a helye a megjelenítésnek.
akár hányezer sornyi
Nyilván a szerver oldali kód nincs benne, de annak idején 2000-ben ezt adta vissza az oldal.
Ez nagyon jó példája, hogy miért nem érdemes kiragadni a kontextusból mondatokat és átértelmezni. Az IE és Netscape időkben 25 éve a JS-t használták arra, amire most a CSS-t, pl :hover helyett onmouseover-el oldották meg. Annyit kellett volna tenni, hogy betesznek egy style API-t, amit JS kóddal megváltoztathatunk az oldal betöltődése közben, és ugyanazt csinálja, mint a CSS. Az újra renderelés problémája ezzel meg lenne oldva. Plusz nem lenne az, ami most van, hogy a CSS-be megpróbálnak minél több okosságot beletákolni.
Ha a CSS a JS része lenne, és
Továbbá ha a CSS a JS része lenne, akkor cserébe azt keresgélhetnéd, hogy melyik JS fájlban van megadva a megjelenés :) Így legalább tudod, hogy CSS fájlban kell keresgélni. Persze lehetnek kivételek, amikor a teljesítmény nevében inline-olni kell néhány szabályt, vagy valami nagyon egzotikus megjelenéshez JS-ből kell hozzányúlni a megjelenéshez, de az esetek túlnyomó többségében nagyon is könnyen kideríthető, hogy honnan jön a stílusszabály.
Nem ez a lényeg, hanem hogy
Továbbra sem értem, hogy
Kicsit olyan érzésem van ettől, mintha azon vitáznánk, hogy pl. az assembly után miért volt szükség más nyelvre, amikor az már ott volt és kötődött a géppel való kommunikációhoz.
Én feleslegesnek éreztem,
+1
Pedig előtte is ott volt a gépi kód!
(És bibibííí, nekem még van egy kis halvány emlékem Commodore-16 Assembly-ről, utána a .386 valós mód is már a kánaán volt! :-D )
Ha már visszatértünk ehhez
A CSS ezzel szemben a JS-hez képest nem nyújt semmi extrát, sőt visszalépés hozzá képest. Persze elhiszem, hogy egyszerűbb volt gyorsan tákolni rá egy DSL-t, mint elgondolkodni, hogy esetleg fejleszthetnék a meglévő eszközöket.
Mondjuk itt van ez, ami gondolom a CSS 1.0-val is működik.
Engem ez az egész sokkal inkább arra emlékeztet, hogy létrehoznak n+1 sablonnyelvet szerver oldalon, aztán a 10.0 verzióra, amikor már 1000 featuret és függvényt hozzáadtak, mindig rájönnek, hogy mégiscsak ugyanazt kéne tudnia, mint az eredeti nyelvnek, amin létrehozták.
Én nem tartom visszalépésnek
Egy jól megírt CSS-sel plusz sorok/logika nélkül támogatod a változtatható betűméretet reszponzív módon. A felhasználó ezt be tudja állítani magának a böngészőben, és nem azt kell használnia, amit te JS-ben megadsz.
Ha időtől függően azt akarod, hogy máshogy nézzen ki, akkor hozzáadsz egy osztályt a html elemhez és kész. A logika marad a JS-ben, a dokumentumtól függő megjelenés meg a CSS-ben.
Én továbbra is csak előnyöket látok.
Nyilván nem fogok fél óra
Senki nem kötelez rá, hogy mindent egybe csomagolj. A stílust tartalmazó JS fájloknál ugyanúgy lehetne jelezni a böngészőnek egy link rel-el, vagy egy attribútummal, hogy dolgozza fel mielőtt áttér a maradékra, mert kell a rendereléshez, esetleg betehetünk defert a maradékra. Ha konfig fájl jellegű szintaxist akarsz, akkor meg JSON-ban vagy ahhoz hasonló formátumban meg lehetett volna adni, aminek a feldolgozása a CSS-el azonos sebességgel megoldható.
Ezzel el is veszik egyúttal a lehetőséget azoktól, akik bármilyen okból nem akarnak reszponzív oldalt csinálni csak mondjuk támogatni egy alap és egy nagybetűs kinézetet valami vállalható formában. A reszponzívval kapcsolatban valószínűleg sokkal jobban megoldható lehet egy normális programnyelven, ahhoz képest, ami most CSS-ben van, de nem vagyok benne biztos.
Ja hát igen, pont erről beszéltem, hogyha már minimális logikát akarsz belevinni a kinézetbe, akkor nyúlhatsz a JS-hez, aztán kommunikálhatod tovább a CSS felé amennyire ez lehetséges a DOM betöltése előtt. Eleve a CSS bizonyította, hogy a JS DOM megléte egyáltalán nem szükséges a stílus változtatásához, elég ha megadunk egy szabályt, hogy ami megfelel egy query-nek, arra a következő stílus vonatkozik, aztán majd a renderelő alkalmazza a szabályt, ha illik valamire a query, amit éppen ki akar rajzolni. A DOM csak arra kell, hogy bejárhassuk a HTML csomópontok fáját, és hozzáadjunk vagy elvegyünk valamit. Jelenleg ha kommunikálni akarunk a JS és CSS között mielőtt a teljes DOM-ot betöltené a böngésző, akkor kénytelenek vagyunk egy félkész DOM-ot módosítani hozzá ahelyett, hogy csak hozzáadnánk egy szabályt.
Sokkal egyszerűbb és
Pont ez a gond. A JS-nek az a dolga, hogy módosítsa a dokumentumot. Így ha betöltés közben talál a böngésző egy normál script elemet, akkor a megjelenítést meg kell állítania, (adott esetben) letöltenie a kódot, értelmeznie és futtatnia, és utána tudja tovább építeni a dokumentumot. És ezt a viselkedést nem lehet csak úgy eldobni, mert sok régi oldal lehet, hogy nem működne ezek után. Tehát hiába akarunk elvonatkoztatni a jelenlegi (és az akkori helyzettől), csak bizonyos keretek között lehet ezt megtenni úgy, hogy a meglévő infrastruktúra is működőképes maradjon.
Nem kétlem, hogy lehet olyan (kitchen sink) nyelvet írni nulláról, ami mindent is meg tud csinálni optimálisan, de a komplexitása könnyen lehet, hogy akkora lenne, hogy az egyes feladatokra optimalizált API-jai annyira más gondolkodást és szintaxist igényelnének, hogy praktikusak legyenek, hogy akár külön nyelvek is lehetnének. Főleg ha elkezded "külön csomagolni" ezeket a részeket a hatékonyság kedvéért.
A HTML alapból reszponzív. Ha megtanul az ember CSS-ül, akkor nem kerül plusz erőfeszítésbe reszponzív módon megírni egy oldal megjelenését ahhoz képest, mint ami egy nem reszponzív oldalhoz kell. Szóval ezzel azt mondod, hogy elveszik azt a lehetőséget az embertől, hogy olyanra csinálja meg az oldalát, amit kevesebb eszközzel vagy kevesebb különböző adottságokkal rendelkező ember tudja használni. De ugyebár ez a lehetősége nincs elvéve. Kedvedre csinálhatsz olyan gyatra reszponzivitású és hozzáférhetőségű oldalt, amilyet csak szeretnél (ld. ma létező weboldalak). Milyen jók is voltak az "ez az oldal csak az IE6-ot támogatja 1024×768 felbontásban" idők :)
Nyilván. És senki más sem. Ehhez idő kell. De közben azt is szeretnénk, hogy fejlődjön a web. Ezért a problémát partícionálni kell, hogy a logikusan összetartozó dolgokat praktikusan lehessen megoldani. És ebből a folyamatból született meg a CSS. Volt egy adott helyzet, amiben különböző problémákra megoldásokat kellett találni jobbára visszafelé kompatibilis módon.
Pont ez a gond. A JS-nek az a
Ja és ezt ki döntötte el és mikor? Mert simán hozzá lehetett volna csapni a stíluslapokat is JS-hez mielőtt valakinek jött az a világmegváltó ötlete a W3C-nél, hogy kitalál rá egy harmadik nyelvet.
Meg lehetne csinálni ma is visszafele kompatibilisen, viszont kapásból jönne az, hogy nincs semmi értelme, mert működnek CSS-el is az alap dolgok, a maradékhoz meg hozzátákolunk egy kis JS-t, aztán kész. A CSS kivezetése meg szintén baromi megterhelő lenne mindenkinek. Ezt akkor cseszték el javíthatatlanul, amikor fel se tették a kérdést, hogy milyen létező eszközöket lehetne erre a célra használni.
Ja és ezt ki döntötte el és
Eleve azért hozták létre a JS-t, hogy letöltődés után meg lehessen változtatni a dokumentumokat, és ne csak statikus oldalak legyenek. Szóval ezt még a Mosaic/Netscape-nél döntötték el.
De igazad van, azzal nem tudok mit kezdeni, hogy neked antipatikus valamiért a CSS. Mindez annak ellenére, hogy belátható, hogy a hatékony layout kezelést nem szerencsés összekeverni dokumentum módosításokkal, hogy érdemes külön kezelni a megjelenésért felelős kódot az egyéb logikától, stb.
A korábbi kódrészletekből azt gondolom, hogy ismered a CSSOM-ot. Ezt használva bárki, aki rendesen ért a CSS-hez, talán csinálhatna egy nem túl borzasztó JS alapú stílus APIt. De egyrészt aki kellően magabiztos CSS tudással rendelkezik, az valószínűleg nem fog egy nyakatekertebb megoldást használni, másrészt meg ugye ennek a hatékony használatához továbbra is érteni kéne, hogy a böngészők hogyan végzik a megjelenítést, ami független attól, hogy milyen nyelven van az APIja.
Ahogy már az elején is írtam, szerintem nem a nyelvvel van a baj, hanem hogy az emberek csak felszínesen hajlandóak megérteni egy weboldal renderelésének a folyamatát és mechanizmusait. Úgy meg nehéz lesz bármilyen nyelven jó megjelenést írni. Ha JS-ben menne a stílusolás, akkor szerintem a JS stílus APIval kapcsolatban menne az, ami most a CSS-re irányul, és lenne ugyanennyi elfuserált, lebutított wrapper körülötte ahelyett, hogy rávennék az embereket, hogy megtanulják használni. Ehhez a megértéshez meg hozzátartozna a másik nagy probléma, hogy egy weboldal megjelenésének mikéntjét nem tudjuk befolyásolni úgy, mint egy nyomtatott kiadványnál. Tehát aki szembemegy a reszponzivitással, az számítson a masszív szenvedésre, ami emiatt vár rá.
Pontatlanul fogalmaztam, úgy
modern web
Egyébként a "modern webnek" lassan el kell(ene) indulnia egy, a mostanihoz képest nagyon más irányba. Elértük órajelben, RAM-ban, háttértárban és hálózatban nagyjából a maximum sebességet, "darabszámot" még tudunk növelni, cluster-t építeni, de minek?
Minél nagyobb sávszélességet tudok adni pl mobilon, annál olcsóbban kell adnom az egységnyi adatot, közben nekem, a szolgáltatónak egyre drágább a több eszköz és nagyobb üzemeltetési költség miatt.
Kinek jó ez? Senkinek. A kliens(ek) számára sem, mert ugyan nagyobb adatforgalmat kap ugyanannyiért, de semmivel se több hasznos tartalmat, és még a teló is hamarabb lemerül...
Emellett nincs igazán helye további "technológiáknak", amik még több sávszélt + procit + memóriát igényelnek, csak azért, hogy a "fejlesztők" gyorsabban, kevesebb munkával tudjanak haszontalan tartalmat gyártani...
Az irány inkább az lesz, hogy hogyan tudjuk az energiafogyasztást csökkenteni, értékes tartalom mellett. (Nem, attól nem fogják jobban megvenni a gumilabdát, hogy a pontos leírás helyett egy autostart fullhd videón van egy labdázó kisgyerek.)
Ha már annyira technológia: üzemeltetési oldalon van pár (viszonylag) újdonság a sebesség növelésére, adatforgalom csökkentésére.
Hajrá
Igen, összetett. Annyiból kötöttséget is jelent, hogy kénytelen leszel azt az "építési struktúrát" követni, amire ki van találva.
Összességében ezek nem rossz dolgok, sőt, sokat lehet tanulni is belőle.
Más is írta: nem mellékesen produktívabb is, mint 0-ról egyedül.
(Egyébként a Drupal Zen téma nem hsználja véletlenül? :) )
A Zen Zent használ.
Ontopic
checkboxésradioelemek elég jól stílusolhatóak a:checkedpszeudo-osztály segítségével.A
selectszintén tűrhetően alakítható, ha csak az elemet nézzük. A legördülő rész macerás tud lenni, és OS függő.A
fileelemhez meg létezik a::file-selector-button/::-webkit-file-upload-buttonpszeudo-elem. Esetleg akár egylabelbe csomagolva és elrejtve lényegében tetszőleges megjelenést tudsz neki adni.Bizonyos esetekben érdemes lehet megpróbálni egy
appearance: none;szabályt.