ugrás a tartalomhoz

Miért engedélyezett a style attribútum a strict doctype-okban?

Őry Máté · 2006. Jún. 7. (Sze), 15.48
A svéd Roger Johansson Why is the style attribute allowed in strict doctypes? címmel írt elgondolkodtató blogbejegyzést. Gondolatmenetét azzal kezdi, hogy a strict doctype-ok egyik alapja a szemantika és a megjelenés szétválasztása, ezért nem része a szabványnak sok megjelenést befolyásoló elem (példaként: center, font, strike tagek és align, bgcolor illetve border attribútumok). Ő ebbe a kategóriába sorolja a style-t is. Emellett megjegyzi, hogy egyes esetekben csak nehezen kerülhető el a style használata, főleg CMS-ek használatánál. Az attribútumot az onclick közvetlen használatához és a javascript: pszeudoprotokollhoz hasonlítja.

Emil Stenström is hasonló gondolatokat fogalmazott meg Inline CSS should not be allowed in strict doctypes című cikkében. Ő egy szemléletes példát is mellékelt:
<body bgcolor="blue">
<center>
<body style="background: blue">
<div style="text-align: center">
Az első a csúnya, régi, »pfuj« transitional megoldás. A második pedig ugyanaz, csak valid. Fel lehet tenni a kérdést: jobb ez?

A hivatkozott blogbejegyzésekre zsepi is felhívta a figyelmünk, köszönjük.
 ■
1

tyúk vagy a tojás

zsepi · 2006. Jún. 7. (Sze), 16.03
Igaz, hogy Roger ismertebb, de azért tisztázzuk: a cikk s az ötlet Emil Stenström-é, Roger csak felhívta rá a nagy(obb) közönség figyelmét - a honlapján nem is a saját cikkei közé, hanem a gyorslinkek közé tette be
4

jogos

Őry Máté · 2006. Jún. 7. (Sze), 19.25
amikor elkezdtem írni a bejegyzést, valahogy elkerülte a figyelmemet a hivatkozás, a végén meg már nem sikerült jól visszaadni a kapcsolatot. (amúgy Roger rss feedjét olvasom, tehát nekem az volt az első:)
2

Igaza van

-zsolti- · 2006. Jún. 7. (Sze), 17.16
Tényleg fura dolog, hogy ez benne maradt. Viszont egy példa: amikor csak egy kis egyszerű display:none szövegdarabot "hívsz elő" valamilyen eseményre, akkor az ott már nem annyira design, mint inkább funkcionalitás, tehát nem vennem ki onnan a css fájlba.
3

JS

zsepi · 2006. Jún. 7. (Sze), 17.32
de az már javascript, s létre lehet hozni css szabályokat is javascriptből :) külső css fájlban is letárolhatod ezeket a szabályokat, s a script inicializálásakor szúrod csak be a dom struktúrába a megfelelő style elemet
5

Oda tartozzanak megváltoztathatatlanul

Jano · 2006. Jún. 7. (Sze), 19.33
Mi az egyik ok a CSS különválasztásának? Hogy másik CSS fájl segítségével megváltoztathassuk az oldal kinézetét. Az inline definiciók azonban ekkor is megmaradnak. ÉS általában pont ilyen helyeken alkalmazzuk őket.

Ezek a szabályok nem azért vannak az adott elemhez a HTML-ben kötve mert "szemantikusak" lennének, hanem mert ahhoz az elemhez kell, hogy tartozzanak megváltoztathatatlanul.

Bármennyire is szép elmélet a HTML és CSS nyelvek segítségével a szerkezet(és nem a tartalom) valamint a kinézet teljes szétválasztása ez nem jelenti azt, hogy ezt 2 külön fájlba kell tenni. Hatékonysági okokból sokkal egszerűbb ha bizonyos egyszerű stílus megadások ott helyben a HTML elemhez közvetlenűl kapcsolva kerülnek megadásra.

Képzeljük el, hogyha minden egyes kis szöveg formázási dolgot csak úgy tudnánk az adott elemhez kapcsolni, ha annak egy egyedi azonósítot generálunk és gondoskodunk róla, hogy ehhez az azonósítohoz tartozó szabály a dokumentumhoz csatolt CSS fájlban benne legyen.

Ugyanilyen logikával egy olyan class bejegyzésnek aminek az az értéke, hogy "zöld" semmi keresnivalója a strict HTML-ben. Pedig a validátor attribútum értékre és főleg annak jelentésére végkép nem ellenőriz. Tehát nem az kérdés, hogy van-e létjogosultsága a style tulajdonságnak, hanem az, hogy mikor.
6

zöld

Őry Máté · 2006. Jún. 7. (Sze), 20.59
és biztos vagy abban, hogy az jobb, ha a htmlbe belekódolod, h zöld legyen? biztos, hogy egy tartalmi elemben kell legyen egyszerűen zöld szöveg? az nem jelent valamit? figyelmet hív fel, stb? szerintem inkább értelmes classokat kell létrehozni, és csak erősen indokolt esetben lehessen eltérni ettől. (sztem itt is jobb egy id, de itt még van némi létjogosultsága a style-nak.) lehet, h egy színvak kikapcsolná a külső stíluslapot. ő nem sok…at fog látni a zöldből. és sztem annál, h zöld legyen a kívánt szöveg sokkal fontosabb az, h következetesen a jelölések mindig ugyanazt jelentsék az oldalon belül. és így nehéz megoldani, h az eddig zöld feliratot tartalmazó cikkek a húsvéti dizájnon is látsszanak.
7

példa

Jano · 2006. Jún. 7. (Sze), 22.29
Mondok egy példát: legyen egy ABC nevű cégről írt híred, amiben szeretnéd a cég nevét az általuk használt/előírt színekkel kíirni.
A konferencia nyitó előadását a főszponzor <span style="color:red;">A</span><span style="color:white;">B</span><span style="color:green;">C</span> tanácsadója tartja.
Itt ha nagyon akarod akkor megerőszakolhatod a kódot és a span-oknak "elsobetu", "kozepsobetu", "harmadikbetu" class-okat addhatod, majd ezekhez
CSS-ben külön a betűszíneket.

Vagy trükkösen kihasználhatod a kiválasztókat és egy befoglaló spannal aminek a cég neve classt adod és :first-child, :last-child vagy nth child, vagy '+' trükközéssel, a belső class neveket elhagyhatod stb. De vajon ez "szemantikusabb" lesz?
8

Egy konkrét példa

Balogh Tibor · 2006. Jún. 7. (Sze), 23.24
Google
11

Objektumként

attlad · 2006. Jún. 8. (Cs), 00.31
Nem mondom, hogy jobb megoldás, de ilyen esetben tekintheted úgy mint egy objektumot/logót és objektumként/képként illeszted be. Mert ugye mi lenne ha 30 betűből állna a cég neve, mind más színű, akkor 30 SPAN-t raknál?

De vajon ez "szemantikusabb" lesz?

Az akkor lesz ha ACRONYM elembe teszed :-)
12

Nem acronym, kép width vs style

Jano · 2006. Jún. 8. (Cs), 01.50
A Google nem betűszó, vagyis téves lenne a jelölés.

A képek felhozása pedig nagyon jó. A képeknél a width, height attributum értéke vagy százalékban adható meg, vagy pixelben. Más mértékegység nem használható. Ha te nyomtatáshoz készítesz egy dokumentumot ahol mondjuk mm-ben szeretnéd a képek méretét megadni akkor azt mégis csak szerencsésebb az inline style segítségével.

És akkor ha valaki a style tulajdonságot támadja, miért nem a képek width, height vagy a táblázatok cellspacing, cellpadding tulajdonságával kezdi a tisztogatást?
13

ABC

attlad · 2006. Jún. 8. (Cs), 09.47
ACRONYM-ot nem a Google-re írtam hanem az ABC-re.
26

Ugyan az

Balogh Tibor · 2006. Jún. 8. (Cs), 21.07
És Janó szerint is betűszó az ABC vállalat neve? :)
Mert ugye ő ismeri ezt a vállalatot, és lehet, hogy a név csak hasraütésre született, és az ég világon nem jelent semmit, csak esetleg ezzel a névvel a vállalat különböző listákon az első helyen szerepelhet.
27

Az igaz

attlad · 2006. Jún. 8. (Cs), 21.42
Nyilván ha nem az akkor nem kell.
14

azaz: táblázatok cellspacing, cellpadding-je

Dualon · 2006. Jún. 8. (Cs), 11.55
Hm, pont a cellspacing és cellpadding járt az eszemben. :)
19

em

attlad · 2006. Jún. 8. (Cs), 15.42
Ha te nyomtatáshoz készítesz egy dokumentumot ahol mondjuk mm-ben szeretnéd a képek méretét

Így együtt változik a szöveggel:

<style type="text/css">
p {
  font-size: 10mm;
}
p img {
  height: 1em;
  vertical-align: middle;
}
</style>

<p>A <img src="http://www.google.com/jsky/images/GoogleJsky.png"> egy kereső..</p>
22

valahol torz lesz

Jano · 2006. Jún. 8. (Cs), 16.42
Ennél a megoldásnál a kép valahol torzulni fog. Másrészt az egy tipikus igény, hogy több különböző méretű képed legyen egy oldalon, és ezeknek mind egyesével adod meg a méretét.
24

Példa

attlad · 2006. Jún. 8. (Cs), 17.17
Ok, ez arra volt példa, hogy mm-ben akarod mondjuk megadni a szöveg méretét, akkor a beillesztett kép se maradjon kicsi. Mivel előző hozzászólásod kicsit félreértelmeztem. :-/ (De torz nem lesz.)

Nekem nincs bajom az inline style-lal, CSS-ben is hasznosnak tartom az IE-only expression megoldást.

(Hsz. javítva 21:53-kor)
30

Zoom?

Anonymous · 2006. Jún. 11. (V), 17.56
És a zoom? nem minden böngésző nagyitja a képeket is zoomolásnál (ld. Explorer < 6)
A másik meg: A képekkel sérül az any browser kitétel: Ha cél az any browser megjelenés, akkor pl. a konzolos böngészők csak kihagyják a szöveget, amivel csak magad alatt végod a fát. Az inline CSS-nél ugyanis csak ott van a szöveg szövegként. Abba meg nem lehet bízni, hogy a browser helyette az alt tagot írja ki, mert mi van ha nem teszi?
Én például rengeteget bosszankodom emiatt...
31

Javítás

Anonymous · 2006. Jún. 11. (V), 17.58
a konzolos böngészők csak kihagyják a szöveget


Mármint a képet...
33

Zoom, ALT

attlad · 2006. Jún. 11. (V), 20.10
Ha relatívan van megadva a képméret, akkor elvileg a szövegmérettel együtt változik, IE-ben is.

Melyik szöveges böngésző nem írja ki az ALT-ot? Lynx, Links, Elinks, w3m, netrik kiírja.

De én egyiket se tartom jó megoldásnak, írtam a #11-ben hogy ez se jobb, de a sok SPAN se szép.
9

színvak

tiny · 2006. Jún. 8. (Cs), 00.10
Olyan nincs, hogy színvak. És attól, hogy mondjuk más színt lát, miért kapcsolná ki a css-t?

De egyébként szerintem is az a lényeg, hogy mikor használjuk a style-t. És amire van külön tag, arra fölösleges (itt a kiemelésre gondolok).
10

ugyanmár

Jano · 2006. Jún. 8. (Cs), 00.26
Mutass nekem egy olyan lapot ahol egyáltalán eszükbe jut a színtévesztők és mutass egyet ahol külön CSS van számukra. De még ha van is ilyen, akkoris az hogy a szín konkrétan hol is van definiálva az abszolút független a színtévesztő nézőpontjából.

De ha már valahogyan ezt le kéne kezelni akkor a böngészőben kell egy olyan funkció, hogy "inline style figyelmen kívűl hagyása sajár CSS alkalmazása esetén". (Bár nem accessibilty okok miatt, de ilyen funkció van a Firefox WebDeveloper eszköztárában.)
23

Kérdés

tiny · 2006. Jún. 8. (Cs), 17.09
Lehet, hogy tévedek, de te azt érzékeled, hogy ott más árnyalat, csak azt nem tudod megállapítani, hogy milyen színű, nem?
szerk.: Hoppá, bocsi ezt egyel lejjebb akartam írni, Máténak. Egyébként nem azt mondtam, hogy külön css van. Csak hogy miért kapcsolná ki.
17

van

Őry Máté · 2006. Jún. 8. (Cs), 15.11
én színtévesztő vagyok, pár színt nem tudok megkülönböztetni (!=másnak látom). a színvak gyak. feketefehérben lát. ha jól tudom, pl. nem tudja megkülönböztetni a #0f0-t az #f00-tól.
(az elnevezés attól függ, h hány féle csap müxik hibásan/nem)
18

tudsz erről bővebben írni?

Jano · 2006. Jún. 8. (Cs), 15.36
Milyen típusú szintévesztő vagy? Tudnál kicsit bővebben írni, hogy mikor vannak olyan esetek amikor nagyon megnehezíti számodra egy oldal használatát, illetve mit tudsz javasolni megoldásként?
20

Engem is érdekelnének a tapasztalataid...

Dualon · 2006. Jún. 8. (Cs), 15.58
... esetleg egy új szál keretében, ha jut rá időd.
21

Cikk

Anonymous · 2006. Jún. 8. (Cs), 16.29
Esetleg írhatnál róla cikket.
15

Szemantikus web és fejlesztési előnyök optimuma

Dualon · 2006. Jún. 8. (Cs), 12.05
Úgy gondolom, a szemantikus web iránti törekvést is ésszerű kereteken belül érdemes csinálni. Nem látok egzakt módon megfogalmazható szabályosságot abban, hogy mekkora áldozatok árán érdemes valamit szemantikussá (esetleg más szempontból transitional helyett strict-té) tenni. Nyilván ahol csak lehet, tessék utánajárni a lehető legszabványosabb, a jövőt tekintve is legelőnyösebb megoldásnak (usability, accessibility, stb...), de az ember önkéntelenül is "érzi", ha valami nagyon megerőszakolt jellegű megoldást használ.

Kicsit közhelyesen: az alapvető szemléletnek "korrektnek" kell lennie, de a konkrét megközelítés esetenként más és más lehet.

Enyhén hanyagul fejeztem ki magam, de remélem, érthető, mire gondolok.
16

HTML és szemantikusság

Jano · 2006. Jún. 8. (Cs), 13.31
Valójában a HTML kapcsán szemantikusságról beszélni is butaság. Én is belekevertem, elnézést. A HTML maximum az elem szerepét jelöli ami valójában nem szemantikus jelentés. Ha valaki szemantikusságot akar az valahol RDF-nél keresgéljen.

Másrészt a HTML nyelvben is nagyon korlátozott típusú szerepre van jelölő, vagyis csak egy bizonyos szintig tudunk mindent helyesen megjelölni.

Azért érdemes erről beszélni, mert pl. a "tabless layout" kifejezést is sokan félreérteeték és átesve a ló túloldalára a table elemet mint messze elkerülendő dolgot kapcsolták a CSS-hez. Nem kell átesni a ló túloldalára.
25

Szem - antik - us

amonrpg · 2006. Jún. 8. (Cs), 17.45
Figyelem, cinikus vélemény következik!

Egy időszakban én is elkezdtem ezt az egész felesleges haccacárét, és nekiálltam szemantikus dolgokat gyártani.
Aztán megnéztem az oldalakat a különböző böngészőkben.

Nagyon gyorsan elkezdtem magasról fütyülni arra, hogy mi a szemantikus és mi nem az.

Az XHTML strict még oké. Kiizzadom magamból azt a rahedli hekket, amit el kell követni a különböző böngészők inkompatibilitása miatt.

De sajnos pl. ha a fehértől eléggé elütő színű hátteren kell dolgoznom, azonnal bevágom a <body bgcolor="<szín>" link="<szín>"[etc...]> definíciót a HTML-be.

Hogy miért?
Látta már vki ezeket a dolgokat pl. Safariban?
Én sajnos láttam. Gányul néz ki az egész oldalváltáskor.

A megrendelőim meg nem azért fizetnek, hogy szemantikus legyen a lap, hanem azért, hogy ne villajon be egy nyomorék fehér háttér a történetesen fekete alapszínű oldalak között még Safariban se!

Ez a szomorú valóság.
Én jegeltem a szemantikuságossági erőfeszítéseket addig, amíg megfelelőképpen meg nem változik a böngészőpiac. Gyanítom mindig más lesz a hasfájás tárgya, de hasfájás mindig lesz.

Úgyhogy a szemantikus bigyó egy jókora lufi, amit elviekben támogatok, és elviekben jónak is tartok, de a gyakorlatban felejtős.
28

Jó pap holtig tanul

Török Gábor · 2006. Jún. 8. (Cs), 23.09
Ez nem cinikus, hanem csacsi vélemény. A hiba benned van. Tanulj többet, ismerd meg jobban az ajánlásokat, szabványokat. Ajánlom figyelmedbe a http://w3csites.com/ oldalt. Ha másnak sikerült, akkor némi többlet tanulással neked is fog.

Ezt a vitaszálat kéretik a Szemantikus és egyben helyesen megjelenő oldal kivitelezhetetlen fórumtémában folytatni.
32

Csatlakozom

Anonymous · 2006. Jún. 11. (V), 18.10
Csatlakozom.
Mondjuk, ha valaki most téreget át HTML4-ről annak nem feltétlen XHTML Strict-tel kell kezdenie. Ezzel együtt az XHTML és a CSS megfelelő alkalmazásával igenis nagyon szép oldalakat lehet előállítani. Nem mondom, hogy pl. IE3-ba Win3.11 alatt jól fog kinézni, de azért olyan nagyon nem kell gánhyolni a böngészők közötti kompatibilitással. Nyilván ha vmi speciálist akar az ember azért meg kell izzadni. De ha nem akarsz füzfán fütyülő rigót kirakni, egész jóllehet dolgozni vele.
A bevillanó fehér hátteret meg nem igazán értem. A böngészők töltés előtt mindenképp fehéret villantanak, hiszen gőzük nincs a következő oldalról. Ha pedig az oldalon bukkan elő a fehér háttér, az egyértelműen az oldal kódjának (vagy CSS-ének) hibája.
Én nem érzem magamat még csak a témát ismerőnek se, de dolgoztam már XHTML-be, és bizony oda kell figyelni.

PS: Török Gábor: Utólag láttam a figyelmeztetést, sorry...
29

Údó

vbence · 2006. Jún. 9. (P), 14.59
pszeudoprotokoll

Ez tetszik.. :)
34

Dustin Diaz véleménye

zsepi · 2006. Jún. 15. (Cs), 11.09
Dustin egyik fő érve, hogy adott esetben a szín jelentéssel bír, s emiatt megengedhető. Személy szerint nem értek egyett vele, de ettől még érdemes elolvasni:
http://www.dustindiaz.com/style-with-strict/
35

Szavazások grafikonjai

saxus · 2006. Jún. 16. (P), 13.51
Egy nagyon egyszerű példa: szavazások grafikonjai. Eléggé logikátlan lenne sztem definiálni 100 különböző értéket, ha nagyon egyszerűen meg lehet adni a grafikon szélességét így:

<div style="width: 50%;"></div>
36

Az a helyzet, hogy vannak más szempontok is

Anonymous · 2006. Nov. 28. (K), 07.32
Az a helyzet, hogy vannak más szempontok is, mint a technikai értelemben vett stílus és a technikai értelemben vett tartalom szétválasztása.

Amint rávilágított itt az előző hozzászóló egy kiváló példával, előfordul, nem is ritkán, hogy a css-tulajdonság inkább a tartalmi oldalhoz sorolandó, mint a stílushoz.

Azonkívül az inline style és a kihelyezett közt van egy igen lényeges különbség, nevezetesen hogy az előbbi anonim. Könnyen belátható, hogy a külön névadás adott esetben csak fölöslegesen terheli a kódot, és a kód egyszerűsége és karbantarthatósága mindenek fölött áll. A névleges szemantika/stílus dichotóm megfogalmazás is csak addig érvényes, amíg a kód tisztaságát segíti, de van egy pont, ami után már nem segíti.

Csak egy egyszerű példa: kétoszlopos elrendezéskor a két floatolt div után szükség van egy lezáró <div style="clear: both"></div> kódra, mert a float elemek nem bővítik a konténert. Namost erre minek külön osztály?

Elég nagy szigor már az is, hogy a style taget a head karanténjába száműzték, többszörös php include-os template-rendszerekben nagyon kényelmes volna, ha az adott aloldal saját stílusjegyeket tudna magára alkalmazni (fejléc háttérszíne stb.), maximálisan kimerítve a css nevében is rejlő filozófiát, erre föl most meg külön változókkal meg miegyébbel kell sz*rozni, mert egy beágyazott aloldal-template nem tud stilizálni. Sztem már ez a lépés is szűk látókörűségre vall, egy magasztos idea nevében.
37

egyetértek, és ezt egy ember jobban tudja

Anonymous · 2006. Dec. 7. (Cs), 14.21
Egyetértek, és még egy dolgot hozzáfűznék:
Hogy miért engedélyezett a style? Miért ne lehetne? Miért kéne ezen a ponton egy szabványnak kényszerítenie a programozót, hogy valamit tegyen, vagy ne?
Szerintem a felesleges korlátozások maga a szabvány ellen dolgoznak, csökkentik a felhasználó eszköztárát. Egy gép nem fogja jól eldönteni, hogy mely elem tekinthető logikus, szeparálható stíluselemnek, és mely jobb beágyazva. Esetleg majd ha a programot is a gép írja...