[css] Waar is het W3C eigenlijk mee bezig...

[Clay]

Een groeiende groep mensen hier heeft de "front geen tables voor opmaak" in hun sig staan om het gebruik van mooie (x)html en css(2) te stimuleren. In een idillische wereld zou dat makkelijk en mooi en goed zijn, maar in de praktijk loop je steeds weer tegen eigenaardigheden aan waarbij je je sterk afvraagt waar men aan dacht toen de spec verzonnen werd.

Je gaat aan de gang met css, en als je denkt dat je wat werkends hebt blijkt het er op andere browsers, die dezelfde specs zouden moeten volgen, toch anders uit te zien. Toegegeven is het niet vergelijkbaar met de ellende ten tijde van Netscape 4, maar toch is er nog flink wat om over te klagen.

Een lijstje:

• Hoogte; Het is belachelijk ingewikkeld om een algemeen werkende style te bakken die goed gebruik maakt van de hoogte. Height:100%; is buiten IE in de praktijk slechts de hoogte van je scherm, en op Opera, Safari, MacIE5 en zelfs Mozilla (sinds Moz1.4RC3, 24/06/03) zal content die in een element zit met height:100%; die doorloopt tot buiten het scherm, de container NIET uitrekken. Backgrounds houden dus doodleuk onderaan de schermhoogte op, terwijl de content nog doorloopt.
  Je bent dan toegewezen tot min-height, maar dan werkt het overal op behalve IE. Daarvoor zal je dan b.v. weer een stukje moeten scripten (!! neEe !!)
  De officiele Box-model specs volgend is het eigenlijk onmogelijk een element te tonen dat 100% hoogte pakt, min 100px aan boven- en onderkant. Tenzij je een andere boxmodel opgeeft, maar daar doet IE dus niet aan, terwijl het met een geldige xhtml doctype wel de boxmodel aanpast naar de officiele.
• Boxmodel: Hoe logisch is dat? width is je content width. Padding, border en margin vallen daarbuiten, en worden dus bij de width opgeteld. Om daarop in te haken en toch padding in top-level layout elementen te gebruiken over verschillende boxmodel interpretaties heen is de voice-family "hack" bedacht, en dat zegt in het css wazigheden straatje imo op zichzelf al genoeg.
• Floats; floats zijn k*t. Niet direct om wat ze doen, maar om de ellende die ze veroorzaken. 9 van de 10 gevallen is een post in /13 over een css probleem te wijten aan het gebruik van een float. Een element wat gefloat is "hoort" volgens de specs namelijk niet het parent element uit te rekken ('t zit in de naam). een element met "clear" is dan soms nodig om je layout niet in de soep te laten lopen. Wie heeft dit ooit bedacht? en wat is er mis met de parent WEL uitrekken? Dat zal je in 99% van de gevallen namelijk juist wel willen.
• Kolommen; Probeer eens een aantal dingen naast elkaar te zetten, en je komt al gauw weer floats of rare position & margin combinaties tegen. Geen tables voor layout roepen we, maar in de praktijk is dat dus wel mooi het makkelijkst. Als het niet in de globale layout is is het wel in de meer specifiekere layout elementen. Er zijn gewoon dingen mee mogelijk die met css bijna niet te doen zijn.
  Zeker toen de table geintroduceerd werd (html3.2) was er echt geen fatsoenlijk alternatief.

bosmonster@icq
de 'gewone' html-er snapt van die onzin toch niks.. dus gaat dan maar alleen voor IE bouwen onder het motto 'die gekke browsers doen het allemaal fout'

en das nu net wat het w3c zou moeten voorkomen...

En dat is een beetje de essentie. Het W3C propageert een standaard, en deze standaard zou (naast "standaard", wat op zich redelijk aan het lukken is nu) ook eenvoudig moeten zijn in het gebruik.
In de praktijk zijn de simpelste dingen maar met moeite te doen; je hebt er een (te) grondige kennis van css voor nodig en je moet je kunnen voorstellen wat jouw css doet in je html om op meer dan 1 browser dat te bereiken wat jij voor ogen had. Dat kan toch niet kloppen?

front geen tables voor opmaak

Globaal is het goed te doen om zonder tables x-browser html/css goed te laten werken, maar ideaal is het nog lang niet. Puristisch css'en is bijna een vorm van zelf-kwelling ...
Specs zijn goed, maar zijn het goede specs?

[SchizoDuckie]

Tsja, Ik gebruik zelf lekker wél tabellen voor opmaak, mede door dit soort grappenmakerij. In de praktijk komt het er op neer dat je uiteindelijk 80% van je tijd (die je aan je opmaak besteedt) bezig bent met het hunten van wazige (x-browser) bugs die je nooit tegengekomen was als je tables gebruikt had.

Leuk hoor, die standaarden allemaal, maar zolang iedereen ze anders implementeert is er nog steeds GEEN standaard imo.

[ Voor 4% gewijzigd door SchizoDuckie op 30-06-2003 14:10 ]

[Bosmonster]

De hele W3C-(on)logica doet me vermoeden dat het W3C geen notie heeft van waar ze mee bezig is. Ze zouden er moeten zijn om de boel te standaardiseren en makkelijker te maken voor ontwikkelaars. Maar wie merkt daar nu iets van? Zonder ingewikkelde CSS-trucs is er bijna niks mogelijk als je je houdt aan het anti-table ontwerp. Doorzichtiger is het voor de 'gewone' html-er in ieder geval niet geworden. Meer dan ooit moet je HTML/CSS expert zijn om nog een degelijk ontwerp in elkaar te zetten.

[Willem]

Mooi stuk Clay, kan het er zeker mee eens zijn.

Rest de vraag dus wanneer wèl en wanneer geen tables te gebruiken, maar dat hangt denk ik ook samen met een deel browsercompatibiliteit die sommige van ons moeten toepassen vanwege een bepaalde opdracht.

We kennen het Mac IE 5 verhaal nu onderhand wel (althans, jij wel ) en daarbij zou het niet geheel onverstandig zijn om -als je een website compatible wilt maken met die browser- HTML in de opmaak te gebruiken.

Maar om "moeilijk" te gaan doen terwijl het makkelijk, en eigenlijk beter met CSS kan (lees: divjes icm css) dan zal ik dat zeker niet laten, en eigenlijk zou het dom zijn het met tables te doen.

Als laatst denk ik wel dat er dmv CSS een hoop problemen kunnen worden voorkomen.
Maar dat staat los van de stelling "front geen tables voor opmaak" ...

[LauPro]

Ik kan me hier volledig bij aansluiten: voor mijn site ben ik pas bezig geweest om de boel met DIV'jes te regelen omdat ik met persentages werk voor de lettertypes, als TD en P dan dezelfde style hebben dan wordt een P in een TD dus dubbel 'gesized'.

Ben er echt een dag mee bezig geweest maar het was nog niks, en dan dacht ik het rond te hebben en dan start je Mozilla op en . Weer een uur voor niks gewerkt omdat Mozilla dat niet kent...

Ik ben van mening dat die standaard geweest BAGGER is en dat er een NIEUWE moet komen. En geen XHTML 1.1 want die is ook al verkloot, maak er meteen XHTML 2.0 van en CSS 3.0. Met een totaal andere opzet. Af en toe zit ik eraan te denken om zoiets op te gaan zetten (misschien wel een idee om dat op GoT te doen?).

[RolandWitvoet]

CSS is geeft net zo onbetrouwbare resultaten als html3.2 dat deed. Elke browser doet het weer anders. Er irritant is dat met "width" soms de breedte van de inhoud wordt aangeduid, en soms de breedte van het parent object. Ik heb nog gen logica kunnen ontdekken in op welke plaatsen ie en mozilla dat doen. Erger nog, ie doet het weer op andere plaatsen dan mozilla
Positioneren van elementen is ook al zo'n kriem inderdaad.
De specs kunnen beter en er moeten meer open plekken (waar browsers nu verschillend reageren) opgevuld worden.

Een handige work-around is om een browser-specifiek stylesheet mee te sturen. Gewoon style.css een serverside script maken dat style.ie of style.moz ophoest al naar gelang de gebruikte browser. Dan kun je in ieder geval die lelijke voice-family hack weglaten.
Probleem blijft echter dat je x verschillende websites moet bouwen en er toch dingen zijn die niet simpelweg met een andere stylesheet te corrigeren zijn. (en je moet een window hebbem met IE5 en een met IE6 en daarnaast nog een mac en een linux-bak omdat je alles moet testen op x verschillende browsers.)

Aan de andere kan is het natuurlijk ook zo dat we steeds complexere dingen willen. Pixelprecies werken kun je voorlopig beter nog steeds vermijden.

[ Voor 8% gewijzigd door RolandWitvoet op 30-06-2003 14:29 ]

[Bosmonster]

LauPro schreef op 30 June 2003 @ 14:23:
Ik ben van mening dat die standaard geweest BAGGER is en dat er een NIEUWE moet komen. En geen XHTML 1.1 want die is ook al verkloot, maak er meteen XHTML 2.0 van en CSS 3.0. Met een totaal andere opzet. Af en toe zit ik eraan te denken om zoiets op te gaan zetten (misschien wel een idee om dat op GoT te doen?).

De drafts voor die versie zullen allang bestaan en zelf zoiets opzetten is nogal erg onzinnig

De discussie starten kan echter geen kwaad.. als er niet getwijfeld en gediscussieerd wordt weet niemand dat er iets mis is.

Verder gaat het dus niet alleen om anti-tables, maar meer om het gedrag van elementen nu, zoals het hoogte probleem en het boxmodel wat Clay noemt. Dingen die heel simpel en logisch kunnen, maar die het W3C dan weer compleet onlogisch in elkaar zet. Wat dat betreft heb ik altijd respect voor Microsoft, die zich van de onlogica niks aantrekt en doet wat ze zelf WEL logisch vinden voor 'hun' ontwikkelaars (o.a. dus ook weer met hun interpretatie van height en boxmodels).

[Justice]

Probleem is dus niet dat ze als ontwikkelaars aan die taal werken, maar als wetenschappers en dus een taal produceren waarmee precies opmaak van een webtaal beschreven kan worden.

Deze discussie zelf is al honderden keren gevoerd (zo ook in DWWS by Jeffrey Zeldman)

Opera, Safari, MacIE5 en zelfs Mozilla (sinds Moz1.4RC3, 24/06/03) zal content die in een element zit met height:100%; die doorloopt tot buiten het scherm, de container NIET uitrekken.

Dit zijn de best CSS ondersteunende browsers, maar ik snap niet wat je bedoeld. Heb je een voorbeeltje. Als mijn content meer dan het scherm is schaalt de box altijd mee namelijk. En de achtergrond is altijd goed. Lijke me meer een implementatie probleem dus van TS, of ik begrijp je verkeerd. (parent elementen ook 100% meegeven dus).

min-height heb ik altijd omheen kunnen werken.

De officiele Box-model specs volgend is het eigenlijk onmogelijk een element te tonen dat 100% hoogte pakt, min 100px aan boven- en onderkant

dat klopt, maar een perfecte wereld is er nooit natuurlijk.

Je kan altijd een element 100% hoogte geven en daarbinnen 100px padding zetten, zodat je hetzelfde effect krijgt (en dan die 100px boven en onder absoluut eroverheen zetten).

Volgens mij liggen de problemen met float meer aan de implementatie van de browsers (er is geen browser zonder float problemen AFAIK)

Toen HTML3.2 geintroduceerd werd was er nog geen CSS, dus inderdaad geen alternatief
Heel vaak is het goed mogelijk door display:inline elementen naast elkaar te zetten btw.

Maar het grootste probleem voor mij persoonlijk is al die alternativen om hetzelfde voor elkaar te krijgen. Dit is helaas een resultaat van de flexibiliteit van CSS, maar daardoor is het lastig testen.

Daarnaast ben ik het met je eens dat je veel tijd kwijt kan zijn aan layout problemen, maar dit is maar eenmalig. Een goede manier van debuggen is verschillende divs weghalen en het probleem isoleren, daarna hetzelfde bij css doen, (altijd css valideren, zo kan je zien dat je elementen meerdere keren andere waardes weergeeft bijvoorbeeld).

Als je 1 keer een probleem opgelost hebt dan is het weg. Als het allemaal zo makkelijk was dat elke onbenul CSS kon dan was er ook geen werk voor ons

[Justice]

RolandWitvoet schreef op 30 June 2003 @ 14:25:
CSS is geeft net zo onbetrouwbare resultaten als html3.2 dat deed. Elke browser doet het weer anders. Er irritant is dat met "width" soms de breedte van de inhoud wordt aangeduid, en soms de breedte van het parent object. Ik heb nog gen logica kunnen ontdekken in op welke plaatsen ie en mozilla dat doen. Erger nog, ie doet het weer op andere plaatsen dan mozilla

Zal het even voor je oplossen dan, om alle browsers hetzelfde boxmodel te geven:
http://gutfeldt.ch/matthias/articles/doctypeswitch.html
http://www.opera.com/docs/specs/doctype/index.dml

Oh en XHTML2.0 en CSS3 zijn al een draft dus nog in ontwikkeling.

RolandWitvoet schreef op 30 June 2003 @ 14:25:
Een handige work-around is om een browser-specifiek stylesheet mee te sturen. Gewoon style.css een serverside script maken dat style.ie of style.moz ophoest al naar gelang de gebruikte browser. Dan kun je in ieder geval die lelijke voice-family hack weglaten.
Probleem blijft echter dat je x verschillende websites moet bouwen en er toch dingen zijn die niet simpelweg met een andere stylesheet te corrigeren zijn. (en je moet een window hebbem met IE5 en een met IE6 en daarnaast nog een mac en een linux-bak omdat je alles moet testen op x verschillende browsers.)

Ahh stop. Die voice family hack is eigenlijk nooit nodig, als je eenmalig een <div> binnen je <div> zet en daar je padding aan geeft, of je de padding aan de elementen binnen je div geeft (zoals h1, p, pre etc). Dan gebruik je namelijk de individuele boxmodels binnen je content division en is er niks aan de hand.

Serside scripts die css geven is niet erg slim, browsers worden geupdate, en je kan nooit overal testen, een layout standariseren over mozilla en Opera, dat niet verneukt in safari en IE 5.5+win en 5.0mac garandeert 99% dat het overal gelijk eruitziet.

Daarnaast zou je beter kunnen werken met een standaard css, en op bases van ondersteunde functionaliteit (ipv browser sniffen) extra's toevoegen.

Aan de andere kan is het natuurlijk ook zo dat we steeds complexere dingen willen. Pixelprecies werken kun je voorlopig beter nog steeds vermijden.

het web is niet gemaakt voor pixelprecies werken, dan kan je beter gaan ontwerpen in PDF formaat ipv websites. Je kan niet weten wie je website bezoekt, of iemand maximised, zijn monitor kapot is etc.

Binnen flexibel ontwerpen kan je nog steeds VEEL voor elkaar krijgen, en visueel hoef je je daar nog steeds niet in te beperken.

[ Voor 67% gewijzigd door Justice op 30-06-2003 14:43 ]

[McVirusS]

Ik denk dat je toch wel een fout maakt in je betoog Clay (en Bosmonster); in principe is er volgens mij weinig mis met de standaard. Het probleem zit 'm zoals altijd weer in de implementatie en dan vooral in de verschillen van implementatie tussen de verschillende browsers. Ben het met Papa Eend eens dat zolang de standaard niet 100% correct wordt geimplementeerd het slecht een theoretisch gegeven is en dat je in de praktijk nog altijd zult kiezen voor de gemakkelijkere maar minder correcte oplossing. Het is erg jammer dat de situatie zo is, ik zou ook liever hebben dat als ik een document via standaard opstel het er gewoon hetzelfe uitziet in de verschillende browsers. De praktijk is zoals zo vaak helaas weer verre van ideaal.

[McVirusS]

Bosmonster schreef op 30 June 2003 @ 14:27:
Verder gaat het dus niet alleen om anti-tables, maar meer om het gedrag van elementen nu, zoals het hoogte probleem en het boxmodel wat Clay noemt. Dingen die heel simpel en logisch kunnen, maar die het W3C dan weer compleet onlogisch in elkaar zet.

Wat dat betreft heb ik altijd respect voor Microsoft, die zich van de onlogica niks aantrekt en doet wat ze zelf WEL logisch vinden voor 'hun' ontwikkelaars (o.a. dus ook weer met hun interpretatie van height en boxmodels).

Hier ben ik het dus totaal mee oneens, hierdoor ontstaan juist de problemen. Hoe slecht de standaard volgens jou ook is; als iedereen zich eraan houdt weet je tenminste waar je aan toe bent. W3c heeft een bepaald boxmodel opgesteld, als Mozilla en IE zich daar gewoon aan hielden was er helemaal geen boxmodel probleem. Dit staat dus nog buiten de logica van dat boxmodel van de W3c .

[Justice]

Het box-model probleem wordt trouwens met CSS3 opgelost, aangezien je daar kan speciferen of je volgens het "IE model" of het "onlogische W3C model" wilt werken.

[McVirusS]

Justice schreef op 30 June 2003 @ 14:45:
Het box-model probleem wordt trouwens met CSS3 opgelost, aangezien je daar kan speciferen of je volgens het "IE model" of het "onlogische W3C model" wilt werken.

Vind ik behoorlijk smerige oplossing, maar goed .

[Justice]

Wel smerig, maar dat zal wel komen omdat je standaard met het W3C model werkt en anders miljoenen websites de vernieling in helpt. Ik vind het ook onlogisch, het is alsof ze niet willen toegeven dat ze fout zitten, maar wel dat het makkelijker kan. Tegen CSS5 zit je dan tegen een enorme bloat-taal met 50 verschillende oplossingen voor 1 probleem.

Ik hoop dus niet dat het weer een overgangstaal wordt zoals XHTML1 was voor HTML -> XML dan kunnen ze weer de schade gaan repareren, maar we zullen zien.

Ik heb trouwens ook problemen met die 100% hoogte, aangezien als je 2 kolommen hebt en de linker (bijvoorbeeld navigatie) niet zo lang is als de rechter (>100%) dat de box ophoudt, eigenlijk zou je een Link: selector moeten hebben waarbij je de hoogte van de 1 kan laten afhangen van de ander.

[ Voor 23% gewijzigd door Justice op 30-06-2003 14:52 ]

[Pelle]

Clay:

Blij dat ik niet de enige ben die zich over deze dingen loopt op te winden. Jij noemt precies die dingen waarvan ik van plan was om ze nog een keer aan de kaak te stellen. Kunnen we niet een soort petitie in elkaar draaien en die aan wat hotshots van het w3c mailen?
Daar kunnen ze niet omheen, als het getekend is door het neusje van de Nederlandse internetzalm

[Clay]

het web is niet gemaakt voor pixelprecies werken, dan kan je beter gaan ontwerpen in PDF formaat ipv websites. Je kan niet weten wie je website bezoekt, of iemand maximised, zijn monitor kapot is etc.

Dat weet ik nog zo net niet. Waarom kan je anders maten in 'px' opgeven als de browser er toch maar met de pet naar zou gooien? Er zijn idd elementen die wat lastig op de pixel te krijgen zijn, maar over het algemeen zie ik geen bezwaar tegen pixelprecies designen. Het mag nog zo lastig zijn, maar ik moet het eerste design nog tegenkomen wat wat dat betreft echt niet uitvoerbaar is.

Kunnen we niet een soort petitie in elkaar draaien en die aan wat hotshots van het w3c mailen?

* Clay stemt voor

[Expander]

Ik snap van deze onzin inderdaad niets.

Tables zijn toch te gebruiken in combinatie met CSS? Zo deed ik het op mijn site. Gewoon in heel net HTML 4.01. Tabellen zijn super compatible met oude browsers en ook gewoon volgens de standaard. Waar een aparte stijl nodig is gebruik ik ook DIV'jes.

Op een gegeven moment zagen mijn (ok, simpele) pagina's er identiek uit in Mozilla en IE.

[Bosmonster]

Expander schreef op 30 juni 2003 @ 15:02:
Ik snap van deze onzin inderdaad niets.

Tables zijn toch te gebruiken in combinatie met CSS? Zo deed ik het op mijn site. Gewoon in heel net HTML 4.01. Tabellen zijn super compatible met oude browsers en ook gewoon volgens de standaard. Waar een aparte stijl nodig is gebruik ik ook DIV'jes.

Op een gegeven moment zagen mijn (ok, simpele) pagina's er identiek uit in Mozilla en IE.

Het anti-tables-front is ook niet zozeer ontstaan vanuit een technische verplichting, maar vanuit een principe-kwestie Volgens sommigen mag je elementen niet voor andere dingen gebruiken dan ze bedoeld zijn.

[André]

Bosmonster schreef op 30 June 2003 @ 15:17:
[...]


Het anti-tables-front is ook niet zozeer ontstaan vanuit een technische verplichting, maar vanuit een principe-kwestie Volgens sommigen mag je elementen niet voor andere dingen gebruiken dan ze bedoeld zijn.

Dan moet je dus ook heel erg oppassen met CSS. Je kunt daarmee elementen een compleet andere functie geven dan waarvoor ze eigenlijk bedoeld zijn. Dat zou dus net zo 'fout' zijn als het gebruik van tables voor de opmaak.

[Justice]

Clay schreef op 30 juni 2003 @ 15:01:
Dat weet ik nog zo net niet. Waarom kan je anders maten in 'px' opgeven als de browser er toch maar met de pet naar zou gooien? Er zijn idd elementen die wat lastig op de pixel te krijgen zijn, maar over het algemeen zie ik geen bezwaar tegen pixelprecies designen. Het mag nog zo lastig zijn, maar ik moet het eerste design nog tegenkomen wat wat dat betreft echt niet uitvoerbaar is.

Het voordeel is inderdaad dat pixelprecies designen maar op 1 manier interpreteerbaar is (ha dacht je ).

Het ligt natuurlijk maar net aan je doelgroep, maar je zou een van de volgende dingen tegen kunnen komen:
-users die vanwege oude pcs / pda's / niet-maximized windows / mobiele telefoons je niet terugkomen op je pagina omdat ze horizontaal willen scrollen of een deel van de content niet zichtbaar is (nielsen
-fonts die niet geresized kunnen worden (in IE hehe)
-Het feit dat pixels in stylesheets niet een absolute eenheid zijn maar relatief net als procenten

W3c zegt:
Pixel units are relative to the resolution of the viewing device, i.e., most often a computer display. If the pixel density of the output device is very different from that of a typical computer display, the user agent should rescale pixel values. It is recommended that the reference pixel be the visual angle of one pixel on a device with a pixel density of 90dpi and a distance from the reader of an arm's length. For a nominal arm's length of 28 inches, the visual angle is therefore about 0.0227 degrees.

-het niet goed ondersteunen van bepaalde specificaties /standaarden zorgt ervoor dat je hele layout verneukt eruitziet. Immers doordat je al je opmaak aan elkaar relateerd heb je meer problemen bij incompatibiliteit dan als je alles relatief neerzet.

-als je veranderingen moet maken (bijvoorbeeld font-family) kan je waardes aanpasssen omdat het ene font breder is dan het andere etc, terwijl je niet kan zeggen of iedereen dat font kan zien etc.

-mensen met minder zicht (iedereen boven de 40 jaar) die graag grotere text etc willen hebben zorgen voor layoutproblemen of kunnen de text niet lezen.

---

Waarschijnlijk zul je deze problemen vaak niet tegenkomen, maar waarom zouden mensen met slecht zicht niet geinteresseerd zijn in webdesign (waar jouw pagina over gaat), of mensen met mobiele telefoon en browser niet naar trance feesten willen...

Dus eigenlijk komt het eropneer dat je met pixel-perfect bouwen de ondersteunde optimale desktop user BETERE service geeft, maar alles daaronder sneller onwerkbaar wordt.

Dat is de theorie tenminste Niemand is heilig.

[Justice]

André schreef op 30 juni 2003 @ 15:19:
Dan moet je dus ook heel erg oppassen met CSS. Je kunt daarmee elementen een compleet andere functie geven dan waarvoor ze eigenlijk bedoeld zijn. Dat zou dus net zo 'fout' zijn als het gebruik van tables voor de opmaak.

Maar dat kan je CSS niet aanrekenen, dus hoe bedoel je dit? Een keukenmes kan je ook voor andere dingen gebruiken dan het snijden van tomaten, maar om daarom te zeggen dat een keukenmes beter niet gebruiken kan.. Hoewel een keukenmes gebruiken wel makkelijker is dan goede CSS natuurlijk

[André]

Justice schreef op 30 June 2003 @ 15:31:
[...]

Maar dat kan je CSS niet aanrekenen, dus hoe bedoel je dit? Een keukenmes kan je ook voor andere dingen gebruiken dan het snijden van tomaten, maar om daarom te zeggen dat een keukenmes beter niet gebruiken kan.. Hoewel een keukenmes gebruiken wel makkelijker is dan goede CSS natuurlijk

Ik bedoel daar mee dat als je tables niet voor layout moet gebruiken omdat ze daar niet voor bedoeld zijn, dat je css niet moet gebruiken om elementen een andere functie te geven dan waarvoor ze bedoeld zijn.

Dus moet je 'voorzichtig' zijn met de manier waarop je CCS toepast. Dit is CCS ook niet aan te rekenen, maar de gebruiker die CCS toepast.

[equationunequal]

Tables werken perfect, dus why fix something that's broken

* equationunequal doet al z'n lay-outs gewoon met tables en de rest van de opmaak met css...

[Willem]

Geloof niet dat Hankey echt in 't vak zit als ik dat zo hoor.

[ Voor 8% gewijzigd door Willem op 30-06-2003 15:43 ]

[André]

Ik geloof ook niet dat de discussie hier over gaat

[equationunequal]

willem169 schreef op 30 juni 2003 @ 15:42:
Geloof niet dat Hankey echt in 't vak zit als ik dat zo hoor.

Uhmmm jawel, hoesjo

* equationunequal is 2e jaars HBO multimediale informatica...

Ik vind het hele anti-table verhaal alleen nergens op slaan. Het heeft jarenlang gewerkt, iedere webdesigner heeft er jarenlang gebruik van gemaakt en dan zou het nu ineens fout zijn? Whatever...

Mijn sites werken perfect in elke browser en image ready maakt nog steeds tables van mn ifaces, dus waarom zou ik moeilijk gaan doen...

[André]

Hankey schreef op 30 June 2003 @ 15:46:
[...]


Uhmmm jawel, hoesjo

* André is 2e jaars HBO multimediale informatica...

Ik vind het hele anti-table verhaal alleen nergens op slaan. Het heeft jarenlang gewerkt, iedere webdesigner heeft er jarenlang gebruik van gemaakt en dan zou het nu ineens fout zijn? Whatever...

Mijn sites werken perfect in elke browser en image ready maakt nog steeds tables van mn ifaces, dus waarom zou ik moeilijk gaan doen...

Er word ook niet beweerd dat tables fout zijn, het gaat er meer over dat de tables eigenlijk niet bedoeld zijn voor de opmaak.

En zo zijn er meer dingen die TS al aangeeft, dus dit is geen discussie die over die tables gaat.

[equationunequal]

André schreef op 30 June 2003 @ 15:49:
[...]

Er word ook niet beweerd dat tables fout zijn, het gaat er meer over dat de tables eigenlijk niet bedoeld zijn voor de opmaak.

En zo zijn er meer dingen die TS al aangeeft, dus dit is geen discussie die over die tables gaat.

Ik wist niet dat er hier zoveel aanhangers van Greenberg waren?

Het getuigt imo juist van creativiteit en inzicht als je nieuwe toepassingen kan vinden voor bestaande zaken. So what als tables niet voor lay-out gemaakt zijn? Je kan er een lay-out mee maken dus waarom zou je dat niet doen!

Photoshop is bedoelt om foto's mee te bewerken. Zou je er dan geen interfaces mee mogen maken? Moeten we dan persé een pakket maken dat Adobe InterFace heet en vrijwel hetzelfde doet?

Oftwel: ik vind het principe verhaal nergens op slaan en ik vind dat je de taal (in dit geval html/css) op zo'n manier moet gebruiken dat je er makkelijk mee kan werken en het goed werkt...

[Willem]

@Hankey: Ah, je studeert

Dat betekent dus dat je nog niet in aanraking bent gekomen met de verschillende facetten van het web-development op klanten-basis/niveau. Als er bepaalde eisen zijn die met een opdracht meekomen kun je in de situatie komen dat je wel aan CSS en/of divs moet gaan geloven.

Jouw ervaring is dat dat nooit heeft gehoeven, simpelweg omdat je nooit in die situatie terecht bent gekomen omdat je -waarschijnlijk?- (nog) niet op professionele basis een webdevelop-taak vervult. Maar zoals al eerder- en vaker aangegeven is dit niet het issue, maar ik wilde je het toch even toelichten.

[marty]

Het wordt gewoon tijd dat er eens iemand flink hard met z'n vuist op tafel slaat
Ik ben het ook totaal niet eens met de opmerking van bosmonster - die eigenwijze houding van microsoft zorgt er juist voor dat wel over tig jaar nog steeds met hetzelfde geëmmer zitten.
Ik had het al niet zo op IE als browser, maar sinds ik wat meer met CSS ben gaan doen heb ik er helemaal een gloeiende ******* hekel aan gekregen. Wat schiet je er nu mee op een potje eigenwijs te gaan lopen doen? Het kan nog zo logisch zijn, maar niemand is er op die manier mee gebaat, je zult het namelijk toch altijd een oplossing moeten bedenken die ook conform de standaard is. En als dat nou een simpele optel som was [1 + 1] qua tijd was het nog geeneens zo erg, maar je kunt er rustig x8 voor zetten voordat je het echt overal werkend in heb. en dat komt puur en alleen door eigenwijsheid van browsers. En dat vind ik zo'n zonde van me tijd! Ik heb ook niet echt het idee dat ik iets bij leer - het enige wat je leert is met alle onvolkomenheden om te gaan. Net alsof je naar Engeland gaat en alle verschillende dialecten eerst gaat leren - dat staat natuurlijk wel interessant, maar wat heb je er nou in feite aan?
Wellicht dat het W3C ook wat democratischer moet worden. Zodat 'onlogischheden' (lekker woord) minder kans krijgen en MS bijvoorbeeld ook z'n zegje kan doen.

McVirusS schreef op 30 June 2003 @ 14:45:
[...]


Vind ik behoorlijk smerige oplossing, maar goed .

Tja, smerig? Het is ook een beetje radicaal het van het ene op het andere moment niet meer te ondersteunen. Je zou het ook als overgangsfase kunnen zien - maar weet natuurlijk niet met welke bedoelingen ze dit hebben gedaan. wellicht dat ze hun 'eigen' visie er in CSS4 uitgooien.

Het mooiste zou natuurlijk zijn als er op een gegeven moment een systeem bedacht wordt dat browsers dwingt zich aan een bepaalde interpretatie te houden. Maar dat zal juridisch enzo wel niet eenvoudig zijn

[equationunequal]

willem169 schreef op 30 June 2003 @ 16:01:
@Hankey: Ah, je studeert

Dat betekent dus dat je nog niet in aanraking bent gekomen met de verschillende facetten van het web-development op klanten-basis/niveau. Als er bepaalde eisen zijn die met een opdracht meekomen kun je in de situatie komen dat je wel aan CSS en/of divs moet gaan geloven.

Jouw ervaring is dat dat nooit heeft gehoeven, simpelweg omdat je nooit in die situatie terecht bent gekomen omdat je -waarschijnlijk?- (nog) niet op professionele basis een webdevelop-taak vervult. Maar zoals al eerder- en vaker aangegeven is dit niet het issue, maar ik wilde je het toch even toelichten.

Pas nog een website gebouwd voor een verfhandel-bedrijf: Relius
(zo goed als af) bestaat uit framesets en tables...

Maar goed, ik geloof je op je woord..

[Willem]

Hankey:
Pas nog een website gebouwd voor een verfhandel-bedrijf: Relius
(zo goed als af) bestaat uit framesets en tables...

OK, stel; Ik ben je klant. Als ik als jouw klant een doelgroep zou willen bereiken waarvan bijvoorbeeld meer dan 20% op internet surft met een Mac, bestaat de kans dat het overgrote merendeel uit die groep browst met IE 5.

Als ik dan die website zou zien, zou ik er niet mee akkoord gaan.

Dat de website uit "frames en tables" zou zijn opgemaakt zou ondergeschikt zijn aan het feit dat 'ie er in IE 5 niet uitziet.. catch my drift? Vandaar even dit korte verhaaltje tussendoor.

edit:
Overigens staat dit los van de "main" discussie, alsmede van afspraken, maar dit terzijde

[ Voor 8% gewijzigd door Willem op 30-06-2003 16:17 ]

[Bosmonster]

ONTOPIC GRAAG

Het gaat hier niet om frames/tables/css vs whatever, het gaat om of de standaarden die W3C opzet wel zo handig zijn. Maw, zoals het topictitle zegt, waar het W3C nou eigenlijk mee bezig is.

[equationunequal]

willem169 schreef op 30 juni 2003 @ 16:16:
[...]


OK, stel; Ik ben je klant. Als ik als jouw klant een doelgroep zou willen bereiken waarvan bijvoorbeeld meer dan 20% op internet surft met een Mac, bestaat de kans dat het overgrote merendeel uit die groep browst met IE 5.

Als ik dan die website zou zien, zou ik er niet mee akkoord gaan.

Dat de website uit "frames en tables" zou zijn opgemaakt zou ondergeschikt zijn aan het feit dat 'ie er in IE 5 niet uitziet.. catch my drift? Vandaar even dit korte verhaaltje tussendoor.

edit:
Overigens staat dit los van de "main" discussie, alsmede van afspraken, maar dit terzijde

Ziet ie er in IE 5 niet uit dan?

Hij werkt zelfs perfect in Netschaap 4...

zitten toch nog wat foutjes in die ik er ff uit moet halen...

[ Voor 7% gewijzigd door equationunequal op 30-06-2003 16:43 ]

[Justice]

Wat ik heb lopen denken is dat al die problemen niet zouden bestaan wanneer:
-Er (meer) developers bij de W3C zaten die nadachten over de implementatie
-Er (meer) webdesigners bij de browsermakers zaten
-Er minder geluisterd werd naar clienten die bepaalde zaken ondersteund willen hebben voor hun website (bij Internet Explorer bijvoorbeeld)
-Er (meer) feedback vanuit de webdesign wereld kwam op de drafts van W3c

Maar het probleem is dat de drafts zo technisch zijn dat alleen browsermakers ze kunnen begrijpen, webdesigners de implementatie of resultaten niet zien totdat ze realiteit zijn en de browsermakers tussen alle partijen in zitten en het dus of naar de zin moeten maken van de W3C en alle implicaties voor de gebruikers moeten inschatten, en dat terwijl ze ook maar gelimiteerde resources hebben.

Mja geen wonder dat het een en ander lastig te implementeren is.

[Woudloper]

Clay een goed punt (ofwel goede punten). Ik denk dat de specs wel goed zijn al zeg ik hetzelf, echter had er een leeswijzer bij moeten zitten hoe 1 en ander geinterpreteerd dient te worden.

Overigens denk ik dat het probleem van de specs o.a. ook gezocht kan worden bij wie de specs heeft geschreven. Maar dit is een onoplosbaar probleem als je het mij vraagt. Ik heb inmiddels verschillende specs (Functioneel, Technisch) gezien, maar nog nooit is het zo geweest dat iedereen die de specs las het op dezelfde manier interpreteerde. Dat gebeurt pas nadat de schrijver verklaart heeft wat deze ermee bedoelt.

Pelle schreef:
Kunnen we niet een soort petitie in elkaar draaien en die aan wat hotshots van het w3c mailen?

Pelle, dit zou op zich wel kunnen. Echter denk ik dat je het niet alleen red met een petititie, naar mijn idee moet je ook bij de diverse webloggers (o.a. Zeldman) aankloppen opdat het idee/petitie breed gedragen zal worden. Dan oefen je nl. veel meer invloed uit...

Justice schreef op 30 June 2003 @ 14:45:
Het box-model probleem wordt trouwens met CSS3 opgelost, aangezien je daar kan speciferen of je volgens het "IE model" of het "onlogische W3C model" wilt werken.

Niet netjes hoe dit wordt gedaan, daarbij zit er nog een nadeel aan de ondersteuning van CSS3 binnen IE aangetien je daarvoor straks dus ook de nieuwe OS bij moet aanschaffen....

[Justice]

Volgens mij wordt er met het IE model gewoon de methode de IE6 in Quirks Mode gebruikt bedoeld en niet automatisch de laatste versie van IE Longhorn. Dus met een nieuw OS heeft dit niets te maken, het is niet meer dan een andere rekenmethode.

[Verwijderd]

Clay schreef op 30 June 2003 @ 14:04:
• Hoogte; Het is belachelijk ingewikkeld om een algemeen werkende style te bakken die goed gebruik maakt van de hoogte. Height:100%; is buiten IE in de praktijk slechts de hoogte van je scherm, en op Opera, Safari, MacIE5 en zelfs Mozilla (sinds Moz1.4RC3, 24/06/03) zal content die in een element zit met height:100%; die doorloopt tot buiten het scherm, de container NIET uitrekken. Backgrounds houden dus doodleuk onderaan de schermhoogte op, terwijl de content nog doorloopt.

Ik betwijfel of dit iets met de specs te maken heeft. Backgrounds in elementen met overflow (zoals de body meestal) zijn voor zo'n beetje alle browsers problematisch.

Je bent dan toegewezen tot min-height, maar dan werkt het overal op behalve IE. Daarvoor zal je dan b.v. weer een stukje moeten scripten (!! neEe !!)
De officiele Box-model specs volgend is het eigenlijk onmogelijk een element te tonen dat 100% hoogte pakt, min 100px aan boven- en onderkant. Tenzij je een andere boxmodel opgeeft, maar daar doet IE dus niet aan, terwijl het met een geldige xhtml doctype wel de boxmodel aanpast naar de officiele.

Cascading Stylesheet:

div {
    margin:100px 0;
    height:100%;
}
/* of */
div {
    top:100px;
    bottom:100px;
}
/* zou allebei moeten werken */

• Boxmodel: Hoe logisch is dat? width is je content width. Padding, border en margin vallen daarbuiten, en worden dus bij de width opgeteld. Om daarop in te haken en toch padding in top-level layout elementen te gebruiken over verschillende boxmodel interpretaties heen is de voice-family "hack" bedacht, en dat zegt in het css wazigheden straatje imo op zichzelf al genoeg.

Agreed. Het W3C-Boxmodel slaat de plank volledig mis en zou zeker geen *default* moeten zijn.

• Floats; floats zijn k*t. Niet direct om wat ze doen, maar om de ellende die ze veroorzaken. 9 van de 10 gevallen is een post in /13 over een css probleem te wijten aan het gebruik van een float. Een element wat gefloat is "hoort" volgens de specs namelijk niet het parent element uit te rekken ('t zit in de naam). een element met "clear" is dan soms nodig om je layout niet in de soep te laten lopen. Wie heeft dit ooit bedacht? en wat is er mis met de parent WEL uitrekken? Dat zal je in 99% van de gevallen namelijk juist wel willen.

Nee, da's niet waar. Dan krijg je namelijk dit:

code:

********* stuk paragraaf tekst
*PLAATJE* stuk paragraaf tekst
*PLAATJE* stuk paragraaf tekst
*PLAATJE* einde paragraaf
*PLAATJE* 
*PLAATJE* 
*PLAATJE* 
********* 


stuk paragraaf tekst stuk para
graaf tekst stuk paragraaf 
tekst stuk paragraaf tekst


i.p.v. dit:


********* stuk paragraaf tekst
*PLAATJE* stuk paragraaf tekst
*PLAATJE* stuk paragraaf tekst
*PLAATJE* einde paragraaf
*PLAATJE* 
*PLAATJE* stuk paragraaf tekst
*PLAATJE* stuk paragraaf tekst
********* stuk paragraaf tekst
stuk paragraaf tekst stuk para
graaf tekst

Globaal is het goed te doen om zonder tables x-browser html/css goed te laten werken, maar ideaal is het nog lang niet. Puristisch css'en is bijna een vorm van zelf-kwelling ...
Specs zijn goed, maar zijn het goede specs?

Ja, het zijn goede specs. Ze zijn alleen nog verre van perfect. Toch is de situatie al een stuk beter dan in (b.v.) 2000. De ellende die je toen op je hals moest halen om x-browser te HTML-en was vele malen irritanter.

[Clay]

Dat klopt. Ik zei ook al dat het lang zo erg niet is als de ellende met b.v. Netscape 4 (Of IE4 wat dat betreft). Css werkend krijgen vind ik ook wel een leukere "uitdaging" dan toen met html. De floats heb je wel gelijk in. Maar het blijven lastige dingen, zeker omdat mensen iets verwachten wat dus alleen in IE gebeurt, maar niet zo hoort.

Cascading Stylesheet:

div {
    margin:100px 0;
    height:100%;
}
/* of */
div {
    top:100px;
    bottom:100px;
}
/* zou allebei moeten werken */

De eerste geeft helaas toch een scrollbar, omdat 100% plus 100px meer is dan de schermhoogte. Alleen met een aangepaste boxmodel, of zonder doctype in IE werkt dat. De 2e werkt op zich wel, maar die kan je alsnog geen hoogte geven van 100% - 200px, en (wat ik ff had moeten zeggen excuses) het is met een position:absolute, en dat wil ik juist niet.