Standaarden (W3C, etc.)

[Verwijderd]

Lees nou toch is man. B _kwam_ _later_ . Daarnaast heeft B een andere betekenis dan STRONG, ze zijn niet equivalent, je hoeft B niet te vervangen door STRONG. Dat zou nergens op slaan.

[We Are Borg]

Verwijderd schreef op 09 april 2004 @ 20:12:
[...]


Hoe kun je mijn opmerking nou flamen noemen, het zou anders worden als ik zei dat je ongesteld reageerde

Om even op het verhaal terug te komen, harstikke leuk en aardig dat de heren bij het W3C die never nooit niet naar de developers luisteren, de tags wijzigen, maar geef me nou één goede reden, die ook nog is functioneel is, waarom bijv. <b> <strong> moet worden

Zoals Anne al zegt:

Ik vind deze tekst in het bold erg mooi staan <- BOLD <- lay-out
Ik vind deze tekst in het bold erg mooi staan <- STRONG <- nadruk

[ Voor 12% gewijzigd door We Are Borg op 09-04-2004 22:53 ]

[Grijze Vos]

We Are Borg schreef op 09 april 2004 @ 22:53:
[...]

Zoals Anne al zegt:

Ik vind deze tekst in het bold erg mooi staan <- BOLD <- lay-out
Ik vind deze tekst in het bold erg mooi staan <- STRONG <- nadruk

En ook nog het feit dat <b> door text-readers genegeerd zal (moeten) worden, en <strong> niet. Stel je deze twee teksten voor:

And the general said: <b>"Move Out!"</b>

And the general said: <strong>"Move Out!"</strong>

In het eerste geval gaat een (toekomstige) textreader gewoon droogjes die tekst lezen, in het tweede geval legt de textreader extra nadruk op die tekst, want hij herkent strong als zijnde nadruk leggend.

[Verwijderd]

Misschien een uitbreiding aan de faq:

http://www.brainstormsand...cles/semantics/structure/

Documentje over Semantiek... Een must voor iedereen, zeer verhelderend!

[chris]

En een leuk artikel van Jeffrey Zeldman: Metrics Reloaded.

En voor mensen die twijfelen aan de mogelijkheden van css:
CSS Zen Garden, dit soort dingen zijn niet mogelijk met tables....

[ Voor 42% gewijzigd door chris op 11-04-2004 17:16 ]

[oh,when?]

Toch nog even op deze mooie paasdag reageren. Ik wil nog even teruggaan naar de mensen die roepen dat met CSS je website in 1 keer omgezet kan worden naar een andere layout. Dave Shea en Doug Bouwman hebben op 1 april een grap uitgehaald door de layouts van hun sites te verwisselen. Beide zijn vooraanstaande developers in de 'Webstandards' community ( om het maar ff samen te vatten ) en gebruiken dan ook XHTML en CSS compliant websites.

Appeltje eitje zou je denken toch? 1 keer de stylesheet verwisselen en je bent klaar.

Niets is minder waar, zowel Dave als Doug beschrijven hoe ze deze grap hebben uitgehaald. Schrik niet, het omvat het aanpassen van de originele Photoshop bestanden, het weglaten van menu-structuren, en het toepassen van obscure CSS hacks om het daadwerkelijk voor elkaar te krijgen.

Nu wil ik niet beweren dat het gebruik van Tables en font tags hier wel zou hebben geholpen, maar het toont wel aan dat zelfs de groten onder ons niet 1-2-3 een 'layout verwisselen'.

[Mx. Alba]

oh,when? schreef op 12 april 2004 @ 13:19:
Nu wil ik niet beweren dat het gebruik van Tables en font tags hier wel zou hebben geholpen, maar het toont wel aan dat zelfs de groten onder ons niet 1-2-3 een 'layout verwisselen'.

Het aanpassen van een CSS layout is veel makkelijker dan het aanpassen van een table layout - mits die CSS layout "goed" opgezet is. Dat betekent niet dat het aanpassen van een CSS layout makkelijk is - dat betekent slechts wat het zegt: dat het makkelijker is dan een table layout aanpassen.

Als je grafische onderdelen gebruikt, zul je inderdaad moeten gaan soepen om je layout te veranderen, of je nou tables of CSS gebruikt...

[Not Pingu]

We spent about 30 minutes each, making minor markup tweaks to fix over-obvious imperfections. The results we shared with each other were impressive, but weren’t good enough given the rendering problems caused by differences in our underlying markup structure.

Slechts 30 minuten nodig hebben om stylesheets uit te wisselen van sites die qua structuur erg verschillend zijn, en dan een resultaat over te houden wat, hoewel niet goed genoeg, toch al een heel eind in de buurt komt.
Ik zou dit toch echt niet opvatten als teken dat het uitwisselen van CSS erg moeizaam gaat.

Schrik niet, het omvat het aanpassen van de originele Photoshop bestanden, het weglaten van menu-structuren, en het toepassen van obscure CSS hacks om het daadwerkelijk voor elkaar te krijgen.

Overdrijven is een kunst het 'aanpassen van de originele Photoshop bestanden' was alleen zodat ze nieuwe plaatjes konden maken met hun tijdelijke 'nieuwe' logo's.

[edit] ik moet wel zeggen dat de commentaren van Doug en Dave beiden erg verschillen.

[ Voor 7% gewijzigd door Not Pingu op 12-04-2004 15:52 ]

[chris]

oh,when? schreef op 12 april 2004 @ 13:19:
Nu wil ik niet beweren dat het gebruik van Tables en font tags hier wel zou hebben geholpen, maar het toont wel aan dat zelfs de groten onder ons niet 1-2-3 een 'layout verwisselen'.

Dat is ook niet zo, maar zoals gezegd is het gewoon veel makkelijker. En wat ook handig is, is dat je je layout puur op css kan baseren. Dit betekent dus dat je maar 1 bestand hoeft aan te passen als je je layout update. Je zit in ieder geval niet meer met 10+ php-bestanden waarin je in functies moet gaan klooien omdat een ander design ook andere html vereist.

Zie bijvoorbeeld (heb 'm hierboven ook genoemd): http://www.csszengarden.com/
Je hoeft dus niet meer in de html/php/whatever te kutten, maar je zit met een css-bestandje. Het is in ieder geval een stuk _overzichtelijker_.

[Grijze Vos]

Ik vraag me af hoe moeilijk het voor hun was geweest als ze met zn tweeen een gestandaardizeerde XML-structuur hadden gebruikt. Dan zou het waarschijnlijk al een stuk simpeler zijn geweest. Ik weet bijna zeker dat je met een table-based structuur toch wel meer dan een half uur bezig bent hoor...

[Verwijderd]

@Chris: als je een goed PHP Framework heb en logic scheidt van weergave, dan is dat geen enkel probleem. CSS heeft voordelen hoor, dat wel

[chris]

Verwijderd schreef op 12 april 2004 @ 17:12:
@Chris: als je een goed PHP Framework heb en logic scheidt van weergave, dan is dat geen enkel probleem. CSS heeft voordelen hoor, dat wel

Dan heb je het wel centraal, maar je bent alsnog je html aan het aanpassen, en ik weet uit ervaring dat dat gewoon veel meer werk is.

De voordelen die ik nu nog van table-based layouts zie:

Het is soms makkelijker in te zien hoe elementen zijn gepositioneerd.
Het is veel meer compatible met oudere browsers.

en voor sommige mensen zal het ook nog een voordeel zijn dat ze de techniek hiervan wel onder de knie hebben, maar van css nog niet. Dit is een non-argument imho.

[Verwijderd]

Wow, kijk mij eens registreren op GoT en zowaar reageren op deze interressante discussie (die helaas al een tijdje dood was )

oh,when? schreef op 12 april 2004 @ 13:19:
Toch nog even op deze mooie paasdag reageren. Ik wil nog even teruggaan naar de mensen die roepen dat met CSS je website in 1 keer omgezet kan worden naar een andere layout. Dave Shea en Doug Bouwman hebben op 1 april een grap uitgehaald door de layouts van hun sites te verwisselen. Beide zijn vooraanstaande developers in de 'Webstandards' community ( om het maar ff samen te vatten ) en gebruiken dan ook XHTML en CSS compliant websites.

Appeltje eitje zou je denken toch? 1 keer de stylesheet verwisselen en je bent klaar.

Niets is minder waar, zowel Dave als Doug beschrijven hoe ze deze grap hebben uitgehaald. Schrik niet, het omvat het aanpassen van de originele Photoshop bestanden, het weglaten van menu-structuren, en het toepassen van obscure CSS hacks om het daadwerkelijk voor elkaar te krijgen.

Nu wil ik niet beweren dat het gebruik van Tables en font tags hier wel zou hebben geholpen, maar het toont wel aan dat zelfs de groten onder ons niet 1-2-3 een 'layout verwisselen'.

Ja, leuk verhaal. Maar je schetst eigenlijk een heel verkeerd beeld, m.i.

Dave en Doug hebben twee sites waarbij hun gekozen HTML sturctuur zeer verschilt, op sommige punten (Mezzoblue's navigatie is vele malen complexer en anders samengesteld dan die van StopDesign). Toch hebben die twee elkaars layout met "minimal effort" kunnen switchen. Tuurlijk moet je de photoshop bestanden aanpassen - ze namen elkaars logo ook over qua stijl, maar gebruikten desondanks nog wel hun EIGEN logo. Dat is een redesign kwestie.

Al met al zijn de twee heren niet lang bezig geweest.

En NU ga je vergelijken met hoe dat zou zijn geweest in het geval van table-based layouts. Daar zou zo'n redesign (want dat is het in principe gewoon) enkele dagen zoniet weken hebben gekost.

Vaak is het zo dat wanneer een bedrijf, gemeente, school of wat dan ook, hun site vernieuwt, het enkele weken kost om alle pagina's om te zetten naar het nieuwe design. Dit omdat elke pagina vol staat met inline opmaak, gemaakt is met tables zodat alles perfect in het design paste, etc.
Door een goede scheiding te maken van content, structuur en opmaak, kan je oneindig veel flexibeler spelen met elk van de drie. De CSS Zen Garden is een vaak-genoemd voorbeeld, simpelweg omdat het ook het perfecte voorbeeld is van de onvoorstelbare kracht van CSS.

Stel, je bent een bedrijf dat heel erg inspeelt op huidige trends en moderne zaken en alles. Je site geef je een redesign elke 12 maanden om bij te blijven en trendy te blijven. Met tables zouden de webdevelopers en designers, afhankelijk van de grootte van de site, minstens een week of twee bezig zijn, elke keer, om deze klus te klaren. Sure, dat brengt voor de site-ontwikkelaar lekker geld in het laadje, maar voor jou is dat eigenlijk niet zo fijn.
Met een goed-voorbereide, goed-gestructureerde site heb je in theorie vaak slechts 2 dagen nodig om de klus te klaren, waarbij een groot deel van de tijd opgaat aan het maken van het nieuwe Design. Dat is voor jou als bedrijf veel aantrekkelijker, en stelt je zelfs in staat om zonder veel geld kwijt te zijn, elke 6 maanden ipv. elke 12 je site te redesignen.

Mezzoblue en Stopdesign waren in principe slechts een ruim half uur bezig met het belangrijke werk (Photoshop zut moet je niet meetellen, dat is design en heeft niks met XHTML, CSS en goede structuur te maken).

Beeld je nu eens in dat bijvoorbeeld www.yahoo.com en www.msn.com ditzelfde grapje zouden uithalen. Die zijn echt niet in 30 minuten klaar hoor, en ook niet in 60 minuten. Alleen via knippen en plakken kan je die twee voorpagina's enigszins snel van layout wisselen, maar dan nog ben je 30+ minuten bezig, en dat is slechts 1 enkele pagina die je dan gedaan hebt. NIET je hele site van een paar honderd tot paar duizend pagina's. En bij een MSN en Yahoo switch hou je ECHT niks meer van elkaars HTML structuur behouden. Bij Mezzoblue en Stopdesign was dat voor 99% wel zo (alleen dat menu van Mezzoblue was een echt heikel punt, maar goed).

Wereldje van verschil.

Tuurlijk, ook met CSS en goede XHTML ben je niet in 5 minuten klaar met een volledig nieuw design voor je site, maar als je de hoeveelheid tijd, werk en dus kosten goed gaat vergelijken, dan kan je niet anders dan inzien dat je met XHTML/CSS en een goed geschreven structuur, veel sneller, makkelijker en goedkoper klaar bent.

Poehee, sorry voor de rant.

[Blue-eagle]

Uitzonderingen zijn leuk:

http://mezzoblue.com/arch...5/15/tables_oh_th/#000585

[Tom-Eric]

Blue-eagle schreef op 18 mei 2004 @ 16:26:
Uitzonderingen zijn leuk:

http://mezzoblue.com/arch...5/15/tables_oh_th/#000585

Er is een groot verschil tussen een website die 1 tabel gebruikt om bijvoorbeeld een aantal kollomen te maken en een website die meteen kleur informatie erin zet en dingen als border dikte en kleur, of nog erger, websites die er een grote tagsoup van maken met geneste tables in geneste tables in geneste tables.

[Verwijderd]

Verwijderd schreef op 18 mei 2004 @ 15:37:

Je bent nu ook een relatief kleine site gericht op één type content aan het vergelijken met een portal size website Dat is ook een wereld van verschil.

Waar het owen ook om ging was niet de hoeveelheid tijd die je kwijt bent met een redesign, maar wel dat je zoals zoveel zealots beweren met 1 stylesheet je hele site kunt wijzigen, en dat in de praktijk blijkt dat voor commerciele projecten ook de inhoud zodanig wijzigt dat een stylesheet wijziging ook een andere richting krijgt.

Verder geven zelfs de groten indirect aan dat het te ver gaat met het hele onderwerp, vandaar ook mijn signature. Eerst nadenken, dan doen

[Dionysus007281]

Ik lees heel vaak dat tabellen "not done" zijn voor opmaak, dus 2 vraagjes:

1 - Waarom niet?
2 - Zie bv. de Ati.com website, die stikt van de tabellen. Stel dat ik diezelfde layout wil maken, met (denk ik) CSS, waar moet ik beginnen? Iemand een link naar een goede HOWTO ofzo?

[CrashOne]

Ten eerste gebruik je een element waarvoor het bedoelt is, een tabel is niet voor layout doeleinde bedoelt.
Ten tweede heb je bij een tabel based layout vaak een erge tag soep, veranderingen daarin zijn complex (vooral geneste tabellen).

Op alistapart.com kan je leuke dingen vinden qua css, maar surf wat rond, er is zat over.

[Verwijderd]

Verwijderd schreef op 18 mei 2004 @ 16:36:
[...]
Je bent nu ook een relatief kleine site gericht op één type content aan het vergelijken met een portal size website Dat is ook een wereld van verschil.

Waar het owen ook om ging was niet de hoeveelheid tijd die je kwijt bent met een redesign, maar wel dat je zoals zoveel zealots beweren met 1 stylesheet je hele site kunt wijzigen, en dat in de praktijk blijkt dat voor commerciele projecten ook de inhoud zodanig wijzigt dat een stylesheet wijziging ook een andere richting krijgt.

Verder geven zelfs de groten indirect aan dat het te ver gaat met het hele onderwerp, vandaar ook mijn signature. Eerst nadenken, dan doen

Mijn enige punt, wat ik trachtte duidelijk te maken en wat nog steeds volledig overeind staat, is dat het wel degelijk veel tijd, moeite en (dus) geld kan schelen om goed-geschreven XHTML met CSS-layouts te gebruiken ipv. Tables voor de layout en alles op de ouderwetse manier blijven doen. Owen deed voorkomen dat dat niet zo was en dat het zelfs "de groten" in de CSS-wereld er 'moeite' mee hebben om dat in 1 keer te bewerkstelligen, maar dat is dus echt niet het geval.

Tha's all

[Verwijderd]

Verwijderd schreef op 18 mei 2004 @ 17:10:
[...]


Mijn enige punt, wat ik trachtte duidelijk te maken en wat nog steeds volledig overeind staat, is dat het wel degelijk veel tijd, moeite en (dus) geld kan schelen om goed-geschreven XHTML met CSS-layouts te gebruiken ipv. Tables voor de layout en alles op de ouderwetse manier blijven doen. Owen deed voorkomen dat dat niet zo was en dat het zelfs "de groten" in de CSS-wereld er 'moeite' mee hebben om dat in 1 keer te bewerkstelligen, maar dat is dus echt niet het geval.

Tha's all

Ja hallo, laten we alles wel eventjes reeel houden En ja de groten hadden er wel moeite mee, ik heb er toch redelijk veel van meegekregen om het zo te zeggen

[Verwijderd]

Ja, ze hadden er moeite mee. Nee, tables gebruiken is niet beter, het is en blijft gewoon veel makkelijker met XHTML en CSS dan met tables. Simpel toch? Waarom blijf je nou doorhameren?

[ Voor 3% gewijzigd door Verwijderd op 18-05-2004 17:30 ]

[oh,when?]

Verwijderd schreef op 18 mei 2004 @ 17:10:
[...]
Owen deed voorkomen dat dat niet zo was en dat het zelfs "de groten" in de CSS-wereld er 'moeite' mee hebben om dat in 1 keer te bewerkstelligen, maar dat is dus echt niet het geval.

Zonder dat het een wellus-nietus verhaal gaat worden...dat heb ik nooit beweerd en nooit de intentie gehad om dat te suggereren. Verder vindt ik deze discussie nogal verloren moeite. Ik heb al mijn punten ooit al eens vermeld, ik sta open voor suggesties, maar om elke maand mijn punten te verdedigen tegen mensen die net komen kijken in dit wereldje heb ik eerlijk gezegd geen zin an, ik heb genoeg ander werk te doen. Hiermee doel ik dus op de mensen die het licht hebben gezien in XHTML en/of CSS en dit krampachtig bij elke post moeten vermelden.

[Verwijderd]

Dionysus007281 schreef op 18 mei 2004 @ 16:38:
Ik lees heel vaak dat tabellen "not done" zijn voor opmaak, dus 2 vraagjes:

1 - Waarom niet?
2 - Zie bv. de Ati.com website, die stikt van de tabellen. Stel dat ik diezelfde layout wil maken, met (denk ik) CSS, waar moet ik beginnen? Iemand een link naar een goede HOWTO ofzo?

2 - kijk hier eens: http://www.cssref.be/cursus/cursus.asp. Wellicht niet de allerbeste tutorials, maar je komt er al een heel eind mee. Check ook deze site eens: http://www.handleidinghtml.nl/css/inhoud-css.html.

Ikzelf heb altijd met tables gewerkt, en sinds kort ben ik overgestapt op XHTML/CSS. Het gaat me nog niet allemaal even goed af, en ik betwijfel of je een compleet nieuw design voor je site kunt maken zonder aan de HTML te hoeven komen (niet iedereen is zo'n CSS expert als de mensen van CSS Zen), maar vooralsnog vind ik het erg mooi om zulke compacte en nette code te hebben. Daarnaast laden je pagina's wat sneller (aangezien het style bestand slechts één keer gedownload hoeft te worden en dan in de chache van je browser staat), is het makkelijker om wat veranderingen in de lay-out door te voeren, en is je website beter compatible met niet-grafische browsers.

Overigens bereik je veel van deze effecten ook door slechts één HTML pagina te maken met de hele lay-out, en via php-include de afzonderlijke pagina's steeds in deze lay-out te laten laden. Ik zie niet echt in wat hier verkeerd aan zou zijn (behalve dat het wellicht niet al te best zal zijn voor je positie bij zoekmachines), maar ergens heb ik het gevoel dat veel mensen hier toch bezwaar tegen hebben.

[ Voor 6% gewijzigd door Verwijderd op 18-05-2004 17:50 ]

[Verwijderd]

[b]Verwijderd schreef op 18 mei 2004 @ 17:48

Troost je, voor Zen heb je geen ultieme CSS skills nodig, de hoeveelheid content en complexiteit ervan in een Zen template is heel minimaal, en is leuk om de kracht van CSS te laten zien, maar meer ook niet.

Ik ben tegenwoordig bezig met behoorlijke complexe datastructuren icm xhtml en css en daarbij komt wel wat meer kijken dan ZenGarden, maar weet wel dat dit veel meer tijd kost om te ontwikkelen dat de table based layout. Je loopt tegen diverse zaken aan die je normaliter bij een basic template niet tegenkomt maar waarbij je in css al je hacks en tricks uit de kast moet halen.

Het uiteindelijk resultaat haal je altijd, maar voordat het zover is loop je op tegen onvoorspelbaar gedrag, en ja meestal is dit in MSIE, maar wat verwacht je ook bij een browser die zo oud is. Vind het eerder knap dat het allemaal nog te halen is in MSIE, hetzij met wat sloppy hacks.

[Verwijderd]

Ik had laatst nog een site gemaakt voor een klant, met mn CMS, en ik hoefde slechts 1 template aan te passen qua HTML. De rest van de default HTML kon ik laten zoals het was, enkel de CSS was echt anders. Leuke was nog wel dat het in IE allemaal ook gewoon meteen werkte, behalve IE 4 (die position: niet kent...)

[Mx. Alba]

CrashOne schreef op 18 mei 2004 @ 16:44:
Ten eerste gebruik je een element waarvoor het bedoelt is, een tabel is niet voor layout doeleinde bedoelt.
Ten tweede heb je bij een tabel based layout vaak een erge tag soep, veranderingen daarin zijn complex (vooral geneste tabellen).

Op alistapart.com kan je leuke dingen vinden qua css, maar surf wat rond, er is zat over.

Het argument dat je elementen moet gebruiken waarvoor ze bedoeld zijn vind ik een non-argument. De meest geniale doorbraken in de techniek en wetenschap zijn juist voortgevloeid uit juist het gebruiken van een bekend element op een compleet nieuwe manier, die totaal niet de originele bedoeling was.

Radio bijvoorbeeld, was in eerste instantie "bedoeld" voor draadloze communicatie op afstand. De eerste radiotechnici zouden iemand voor compleet voor gek verklaren die het over radio-uitzendingen zou hebben, waarna geluisterd wordt met behulp van radio-ontvangers waarmee niet uitgezonden kan worden. Maar toch is dat de basis voor onze huidige media. De geschiedenis staat boorde(n?)vol van dat soort voorbeelden.

Als je bijvoorbeeld PHP gebruikt om de content in een template te laden, kan je zonder enige problemen een tabellensoep site maken die vrij makkelijk om te zetten is. Content en layout is immers via een andere techniek gescheiden, waardoor je de content niet hoeft aan te passen. Op mijn persoonlijke website, http://eaglestorm.net, gebruik ik die techniek. Ik zie niet in waarom dat fout zou zijn...

[Clay]

Op zich zit daar wel een kern van waarheid in internet was ooit gruwelijk lelijk, totdat die table tag geintroduceerd werd en men erachter kwam dat die goed te misbruiken was om niet alleen tabulaire data op te maken, maar ook designs om te zetten naar mooie sites. Tot een zekere hoogte heeft dat ertoe bijgedragen dat Internet ueberhaupt populair is geworden, want lelijke dingen kijkt niemand graag lang tegenaan. En echt mooi is iets niet te maken als je alleen maar dingen onder elkaar kan zetten.

Maar een non-argument is het imo niet. Toen was er geen alternatief. Nu is dat alternatief er wel (ook al is het misschien niet perfect, maar dat is de table ook niet). De table heeft z'n tijd gewoon gehad, de mogelijkheden (ook buiten het oorsponkelijke doel) zijn allemaal al lang gevonden en uitgekauwd, en nu is het de beurt aan buiten getrede paden denkende mensen om de (al dan niet "onbedoelde") mogelijkheden van CSS te vinden die met tables simpelweg onmogelijk zijn.

Daar zijn er zat van, en die zijn nog lang niet allemaal gevonden. CSS is niet alleen een visuele techniek, je kan er ook functionele/interactieve dingen mee doen.

[Mx. Alba]

Clay schreef op 19 mei 2004 @ 12:35:
Op zich zit daar wel een kern van waarheid in internet was ooit gruwelijk lelijk, totdat die table tag geintroduceerd werd en men erachter kwam dat die goed te misbruiken was om niet alleen tabulaire data op te maken, maar ook designs om te zetten naar mooie sites. Tot een zekere hoogte heeft dat ertoe bijgedragen dat Internet ueberhaupt populair is geworden, want lelijke dingen kijkt niemand graag lang tegenaan. En echt mooi is iets niet te maken als je alleen maar dingen onder elkaar kan zetten.

Maar een non-argument is het imo niet. Toen was er geen alternatief. Nu is dat alternatief er wel (ook al is het misschien niet perfect, maar dat is de table ook niet). De table heeft z'n tijd gewoon gehad, de mogelijkheden (ook buiten het oorsponkelijke doel) zijn allemaal al lang gevonden en uitgekauwd, en nu is het de beurt aan buiten getrede paden denkende mensen om de (al dan niet "onbedoelde") mogelijkheden van CSS te vinden die met tables simpelweg onmogelijk zijn.

Daar zijn er zat van, en die zijn nog lang niet allemaal gevonden. CSS is niet alleen een visuele techniek, je kan er ook functionele/interactieve dingen mee doen.

Goed, dus is er een alternatief. En inderdaad is het een goed alternatief, dat ik voor mijn nieuwere sites ook gebruik: CSS2. Maar waarom zou ik mijn goed functionerende oude tabellensites ombouwen tot CSS2sites? Ik heb wel zinnigere dingen te doen in mijn vrije tijd

Er zijn vele alternatieven voor diesel en benzine als autobrandstof: LPG, aardgas, plantaardige dieselolie, brandstofcellen, etc. Maar vrijwel niemand gebruikt ze. Er bestaat de Motionless Electromagnetig Generator, die alomaanwezige magnetische winden gebruikt om een inputstroom te versterken (een soort van windmolen zegmaar, maar dan electromagnetisch), resulterend in gratis electriciteit - een gratis booster die in vrijwel elke mogelijke bestaande electriciteitsgenerator ingezet zou kunnen worden - maar nog nergens wordt deze (overigens redelijk recente) techniek grootschalig, of ook maar kleinschalig, toegepast.

[David]

Mx. Alba schreef op 19 mei 2004 @ 12:50:
Er zijn vele alternatieven voor diesel en benzine als autobrandstof: LPG, aardgas, plantaardige dieselolie, brandstofcellen, etc. Maar vrijwel niemand gebruikt ze. Er bestaat de Motionless Electromagnetig Generator, die alomaanwezige magnetische winden gebruikt om een inputstroom te versterken (een soort van windmolen zegmaar, maar dan electromagnetisch), resulterend in gratis electriciteit - een gratis booster die in vrijwel elke mogelijke bestaande electriciteitsgenerator ingezet zou kunnen worden - maar nog nergens wordt deze (overigens redelijk recente) techniek grootschalig, of ook maar kleinschalig, toegepast.

De voorbeelden die jij schetst zijn niet echt relevant voor de Standaarden-discussie. Toepassen van een alternatieve aandrijving voor auto's heeft wat meer voeten in aarde dan het gebruiken van webstandaards in een website. Het gebruiken van een standaard kost, als je ze eenmaal kunt toepassen, geen geld en vereist ook geen verandering van de infrastructuur.

[Clay]

Mx. Alba schreef op 19 mei 2004 @ 12:50:
[...]


Goed, dus is er een alternatief. En inderdaad is het een goed alternatief, dat ik voor mijn nieuwere sites ook gebruik: CSS2. Maar waarom zou ik mijn goed functionerende oude tabellensites ombouwen tot CSS2sites? Ik heb wel zinnigere dingen te doen in mijn vrije tijd

Er zijn vele alternatieven voor diesel en benzine als autobrandstof: LPG, aardgas, plantaardige dieselolie, brandsto....

Dat er een alternatief is betekent dat wanneer je wat nieuws gaat maken dat je meerdere keuzes hebt (en onderzoek doet, afwegingen maakt), niet dat je met terugwerkende kracht alles moet gaan lopen ombouwen.

[Mx. Alba]

DiMension schreef op 19 mei 2004 @ 13:00:
De voorbeelden die jij schetst zijn niet echt relevant voor de Standaarden-discussie. Toepassen van een alternatieve aandrijving voor auto's heeft wat meer voeten in aarde dan het gebruiken van webstandaards in een website. Het gebruiken van een standaard kost, als je ze eenmaal kunt toepassen, geen geld en vereist ook geen verandering van de infrastructuur.

Het compleet ombouwen van een bestaande site, bijvoorbeeld van HTML + Tables naar XHTML + CSS, heeft net zoveel voeten in de aarde als bijvoorbeeld het inbouwen van een LPG-installatie in een auto, of het toevoegen van een MEG-module aan een bestaande electriciteitscentrale.

Om dat laatste voorbeeld te nemen, kan je door de uitbreiding van een bestaande electriciteitscentrale met een MEG-module, door een éénmalige investering, de output van die centrale permanent verdubbelen (om een arbitrair getal te pakken). Daar is geen enkele verandering van de bestaande infrastructuur voor nodig.

Clay schreef op 19 mei 2004 @ 13:53:
Dat er een alternatief is betekent dat wanneer je wat nieuws gaat maken dat je meerdere keuzes hebt (en onderzoek doet, afwegingen maakt), niet dat je met terugwerkende kracht alles moet gaan lopen ombouwen.

Eens.

[Blaise]

Zie bijvoorbeeld (heb 'm hierboven ook genoemd): http://www.csszengarden.com/
Je hoeft dus niet meer in de html/php/whatever te kutten, maar je zit met een css-bestandje. Het is in ieder geval een stuk _overzichtelijker_.

Die site is niet echt representatief. Ik erger me aan het "kijk hoe ultiem en probleemloos CSS is" terwijl CSS door elke browser er weer anders uitziet (overdrijving). Het kost me heel wat tijd om iets gecompliceerds in Safari 1.2, IE6, Opera7 en Firefox er hetzelfde uit wil laten zien. Met tabellen is dat veel minder lastig.

Waarom CSSzengarden IMO schijnheilig () is:

• Er zitten allemaal overbodige tags in die enkel bedoeld zijn voor opmaak-doeleinden die bij veel skins overbodig zijn. Dat is even incorrect als een tabelletje hier en daar.

  <!-- These extra divs/spans may be used as catch-alls to add extra imagery. -->

• De helft van de skins gebruikt achtergrondplaatjes voor de headers, wat bij een dynamische pagina onmogelijk is.
• De inhoud/structuur is totaal niet gecompliceerd en het gemak van een redesign is daardoor niet hetzelfde voor een grote site die veel informatie tegelijk op een pagina weergeeft.
• CSSzengarden bevat geen <img> tags, terwijl die tag in veel gevallen nog onmisbaar is. Je kan dat wel allemaal wegwerken met ingenieuze CSS maar dat neigt dan toch naar instabiele CSS hacks. Je moet dus alsnog allemaal plaatjes vervangen wat niet kan met CSS (helaas ).

[Clay]

Blaise
[...]
Die site is niet echt representatief. Ik erger me aan het "kijk hoe ultiem en probleemloos CSS is" terwijl CSS door elke browser er weer anders uitziet (overdrijving). Het kost me heel wat tijd om iets gecompliceerds in Safari 1.2, IE6, Opera7 en Firefox er hetzelfde uit wil laten zien. Met tabellen is dat veel minder lastig.

Dat is maar deels waar. CSS heeft ook problemen en eigenaardigheden, maar het is net zo hard een kweste van kennisniveau. Persoonlijk vind ik CSS niet lastiger dan tables.

Waarom CSSzengarden IMO schijnheilig () is:
[list]
• Er zitten allemaal overbodige tags in die enkel bedoeld zijn voor opmaak-doeleinden die bij veel skins overbodig zijn. Dat is even incorrect als een tabelletje hier en daar.

Klopt. Helemaal zuiver op de graad is het niet. Maar het geeft wel duidelijk aan dat het ueberhaupt kan.

• De helft van de skins gebruikt achtergrondplaatjes voor de headers, wat bij een dynamische pagina onmogelijk is.

In die zin dat wanneer je er tekst inzet wel ja. Alhoewel je dat voor b.v. een aantal hoofdcategorien dat niet zo aan verandering onderhevig is best kan doen trouwens. En een tilende deco background waar dan verder gewone tekst overheen staat kan natuurlijk helemaal prima.

• De inhoud/structuur is totaal niet gecompliceerd en het gemak van een redesign is daardoor niet hetzelfde voor een grote site die veel informatie tegelijk op een pagina weergeeft.

In de praktijk zul je bij een redesign ueberhaupt vaak alles opnieuw gaan doen. Functionaliteit en informatiearchitectuur zijn dan immers net zo vaak aan een "redesign" onderhevig, aangezien je een redesign niet zomaar gaat doen om enkel dezelfde dingen er anders uit te laten zien. Je boodschap komt misschien niet goed over, en je gaat de informatie die je biedt op andere manieren toegankelijk maken om iedere (sub)doelgroep op een gepaste manier aan te kunnen spreken. Dat zal dus inderdaad vaak betekenen dat je markup niet meer voldoet.
Skinnability is een heel ander verhaal, en dat laat CSSZenGarden imo ontzettend goed zien. Maar zowel redesign als skinnen zijn ook maar onderdelen van CSS, die je bovendien in de praktijk ook amper toepast. Er is veel op aan te merken en het is idd niet perfect, maar het is dus alles behalve het kernpunt van het bestaan van CSS.

• CSSzengarden bevat geen <img> tags, terwijl die tag in veel gevallen nog onmisbaar is. Je kan dat wel allemaal wegwerken met ingenieuze CSS maar dat neigt dan toch naar instabiele CSS hacks. Je moet dus alsnog allemaal plaatjes vervangen wat niet kan met CSS (helaas ).[/list]

Het is misschien vloeken in de kerk, maar ik wil graag de discussie aangaan dat de <img /> tag ook helemaal niet bedoeld is voor designs van een site, en daar zelfs zwaar ongeschikt voor is. Dat het wegwerken van die <img /> tag tot instabiele CSS hacks leidt is een vooroordeel dat ik niet deel. Veel van die zogenaamde hacks zijn schitterende staaltjes van stabiele en betrouwbare CSS waar niets engs aan is, en worden in de toekomst net zo ingeburgerd en geaccepteerd als het misbruiken van tables voor layout, met als verschil dat het een gebruik van de techniek is waar die wel voor bedoeld is.

Onbekend maakt onbemind Ligt een beetje in het verlenge van:

De table heeft z'n tijd gewoon gehad, de mogelijkheden (ook buiten het oorsponkelijke doel) zijn allemaal al lang gevonden en uitgekauwd, en nu is het de beurt aan buiten getrede paden denkende mensen om de (al dan niet "onbedoelde") mogelijkheden van CSS te vinden

[Blaise]

Het is misschien vloeken in de kerk, maar ik wil graag de discussie aangaan dat de <img /> tag ook helemaal niet bedoeld is voor designs van een site, en daar zelfs zwaar ongeschikt voor is. Dat het wegwerken van die <img /> tag tot instabiele CSS hacks leidt is een vooroordeel dat ik niet deel.

Dat ben ik met je eens, en ik vind het zelfs geen "vloeken in de kerk". Ik doelde zelf op plaatjes die content aanduiden zoals smiles en "dit is mijn kat" (had ik moeten zeggen, ja ).

Bij een redesign maar vooral skinnable site zullen plaatjes niet in alle layouts passen (als je oude content wil bewaren). Door het gebrek aan content-plaatjes in zengarden lijkt het net alsof het allemaal zo ultiem werkt.

Bij het maken van mijn skinnable site stuitte ik echter een paar keer op dat probleem. Zo kon bijvoorbeeld de achtergrond niet te donker omdat de .gif anti-aliasing (of gebrek daaraan?) dan zichtbaar werd.

[oh,when?]

Ik schop hem weer omhoog uit de vochtige, duistere kelders van /13. Sprak laatst met mijn goede concollega's @ Lost Boys want een site van hun viel me op: http://www.vaya.nl/vaya/

check de sourcecode eens...zit gestructureerd en heel netjes in elkaar.

"...we leveren nog louter XHTML 1.0 op..."

Dus het kan wel

[Pelle]

Het is valid XHTML ja, maar semantisch kan het allemaal nog veel beter. Overal gebruiken ze div's en span's, in plaats van headers en paragraphs en lists etc.

[Verwijderd]

De sourcecode is een beetje op driekwart blijven steken. Het heeft er alle schijn van dat de author(s) de klok wel hebben horen luiden maar niet weten waar de klepel hangt.

Dat er een XHTML doctype staat wil nog niet zeggen dat het ook XHTML is. En hoe 'dieper' (meer genest) je een div element tegenkomt, hoe meer je er vanuit kunt gaan dat deze onnodig wordt gebruikt. Syntactisch gezien is het geen XHTML of HTML, dit is alleen te parsen met een parser die wel een beetje vergevingsgezind is.

Ik vind het niet veel bijzonders dus. Ja, het kan op zich wel, maar dan moet je dus eerst zorgen dat je weet wat je doet. Helaas zijn de Boys dus nog steeds een beetje Lost

[BtM909]

Verwijderd schreef op 03 september 2004 @ 11:45:
Helaas zijn de Boys dus nog steeds een beetje Lost

Ondanks kunnen een aantal dingen wel beter (semantiek), ben ik ook benieuwd of de 'Boys' daar uberhaupt over nadenken of bewust hiervoor kiezen (al dan niet vanuit een CMS die dit uitpoept).

[ Voor 9% gewijzigd door BtM909 op 03-09-2004 12:00 ]

[crisp]

Opera 7.6, identify as Opera: http://www.vaya.nl/vaya/browsermelding.html

Ze zijn m.i. nog definitely lost, en je wordt notabene nog onload op deze manier geredirect nadat je eerst gewoon de pagina zag:

JavaScript:

document.location.href = 'browsermelding.html';

hoe vaak moet ik nog roepen dat location een property van het window object is?...

[Verwijderd]

* Anne ziet 660 fouten....

Ik vraag me af of ze niet beter voor HTML hadden kunnen gaan.

[André]

Verwijderd schreef op 03 september 2004 @ 12:15:
* Anne ziet 660 fouten....

Ik vraag me af of ze niet beter voor HTML hadden kunnen gaan.

Nee, de validator zegt dat. En als je 1 echte fout in je pagina hebt maakt de validator daar wel eens meer van omdat dan andere dingen ook niet kloppen

[Mx. Alba]

André schreef op 03 september 2004 @ 12:25:
Nee, de validator zegt dat. En als je 1 echte fout in je pagina hebt maakt de validator daar wel eens meer van omdat dan andere dingen ook niet kloppen

Of doordat je dezelfde fout 660 keer maakt

[oh,when?]

Dus alle kommaneukers hier vinden dit niet een stap in de goede richting?

* oh,when? zijn petje valt af...

Op projecten van deze schaal ben ik iig blij dat deze stap gezet wordt. Van de grote webbouwers in Nederland lopen ze redelijk voorop. ik moet zelf toegeven dat wij bij Clockwork nog niet op dit nivo zitten. Ik doel hier met name op de grote webbouwers ( > 80 man ) omdat ik weet hoeveel moeite het kost om in een grote organisatie waarbij vaak meerdere partijen betrokken zijn, iedereen op 1 lijn te krijgen, en omdat het hier gaat om grote klussen waarbij de ordergrootte vaak boven een ton zitten en waarbij juist zoiets het toepassen van webstandaarden niet ter sprake komt ( als je echt geen argumenten hebt, verschuil je je maar achter standaarden nietwaar )

Wat ik me dan wel afvraag, wat vindt de 'Web standards' politie hier dan wel een acceptabel nivo?

[Verwijderd]

oh,when? schreef op 03 september 2004 @ 12:59:
Wat ik me dan wel afvraag, wat vindt de 'Web standards' politie hier dan wel een acceptabel nivo?

Als het hele ontwikkelteam dagenlang gaat lopen prutsen en miereneuken over semantische punten, en zo de marge erdoorheen jaagt. Ik hoor de opmerkingen al komen..... stampede! .. wheeheehee dat hoeft helemaal niet zoveel tijd te kosten, kost zelfs minder tijd, en geld, en is sneller, en, en, en.. toen was er een ontwikkelteam dat moet samenwerken,... anyone ook ervaring hiermee?

Ik vind die code er niet zo slecht uitzien, overigens. Als je over alle miniscule zaken gaat dwarsliggen komt een project van dergelijk formaat nooit af. En we weten allemaal dat elke zelfrespecterende web developer tijd overhoud om tijdens het schijten op de plee de w3c pocket editie open te slaan

Nu serieus, ik vind het een mooi resultaat kan niets anders zeggen, alleen op usability vlak zie ik nog wat verbeteringen.

[Verwijderd]

oh,when je hebt helemaal gelijk. Tuurlijk valt er ontzettend veel op zo'n site aan te merken; er heeft tenslotte niemand van /13 aan gewerkt Dat neemt niet weg dat het goed is van Lost Boys om deze weg in te slaan. Executie zal van project tot project beter worden.

[André]

oh,when? schreef op 03 september 2004 @ 12:59:
Dus alle kommaneukers hier vinden dit niet een stap in de goede richting?

* oh,when? zijn petje valt af...

* André zet petje terug

Het is zeer zeker wel een stap in de goede richting, dat ben ik helemaal met je eens. Nu staat de weg open voor de volgende stappen

[Verwijderd]

oh,when? schreef op 03 september 2004 @ 12:59:
Dus alle kommaneukers hier vinden dit niet een stap in de goede richting?

* oh,when? zijn petje valt af...

Jij hebt het over XHTML terwijl het geen XHTML is. Het is zelfs geen juist toegepaste HTML. Wat je van 'onze' kant hoort is geen mening, zuiver een vaststelling van feiten. Als je die feiten niet kent moet je het onderwerp ook niet ter sprake brengen, vind ik.

Met zoveel mensen zou je zeggen dat er toch wel voldoende kennis in huis moet zijn. Je hebt dan ongetwijfeld specialisten die de layout en markup in elkaar zetten. Als iemand kan bedenken dat er geen tabellen gebruikt moeten worden voor een bepaald element had die persoon moeten weten dat div en span elementen niet veel toevoegen. Anders is het dus echt zonde van je tijd.

Het is een stap in de goede richting, maar voldoet nog niet aan de eisen om iets een goede (X)HTML pagina te kunnen noemen. Dat jij dat wel vindt. Tja, zoals ik al zei, dat is geen kwestie van een mening hebben. Het is niet zo. Feit.

[Pelle]

Verwijderd schreef op 03 september 2004 @ 13:18:
oh,when je hebt helemaal gelijk. Tuurlijk valt er ontzettend veel op zo'n site aan te merken; er heeft tenslotte niemand van /13 aan gewerkt Dat neemt niet weg dat het goed is van Lost Boys om deze weg in te slaan. Executie zal van project tot project beter worden.

Ik hoop het.. het is een stap in de goede richting, maar ik vraag me af waarom ze dan 'half werk' doen.

_{offtopic: kreeg gister overigens een mailtje van je baas..}

[crisp]

Toegeven; het ziet er qua code gestructureerd uit, maar als je het bekijkt zonder stylesheet is het 1 grote puinhoop - over semantiek is dus niet echt nagedacht en dat is gewoon een gemiste kans.
Die browsercheck is het eerste wat eruit gesloopt dient te worden, want op dit moment sluit je alsnog groepen uit - niet dat de site werkbaar is in een screenreader, maar capabele browsers als Opera en Konquerer worden nu ook uitgesloten en dat is gewoon jammer.

Als ik de entity-fouten in de links weglaat hou ik nog een handjevol foutjes over; o.a. een lege UL-tag, INPUT-tags die niet afgesloten worden, 2x een dubbele ID, een verdwaalt BORDER-attribuut en een dubbel NAME-attribuut in een FORM-tag. Dat valt dus nog wel mee, en er is geen browser die daarover struikelt, maar zoals o.a. ook Cheatah terecht opmerkt is het vervangen van tables door div's en span's gewoon niet genoeg.

[ Voor 11% gewijzigd door crisp op 03-09-2004 13:38 ]

[Verwijderd]

Behalve dat in je XHTML (als het goed gebruikt wordt) zo'n leuke XML Fatal error op je browser scherm krijgt als mensen niet juist omgaan met entiteiten.

Het is uiteraard wel mooi dat ze ermee begonnen zijn, maar van zo'n groot bedrijf zou je kunnen verwachten dat er een stel client-side specialisten bijzaten.

[Verwijderd]

Verwijderd schreef op 03 september 2004 @ 13:38:
Behalve dat in je XHTML (als het goed gebruikt wordt) zo'n leuke XML Fatal error op je browser scherm krijgt als mensen niet juist omgaan met entiteiten.

Even een aanvulling hierop:
Om dit goed te kunnen testen moet je maar eens een Content-Type header meesturen die zegt dat het een document van het type application/xhtml+xml is. Bekijk de website met Firefox en je weet genoeg.

[André]

Verwijderd schreef op 03 september 2004 @ 13:44:
[...]

Even een aanvulling hierop:
Om dit goed te kunnen testen moet je maar eens een Content-Type header meesturen die zegt dat het een document van het type application/xhtml+xml is. Bekijk de website met firefox en je weet genoeg.

Op die manier doe ik het ook met mijn eigen site, ik vind dat een perfecte manier om te kijken of je doucment valide is. Ik vind ook dat de fout-tolerantie uit browsers gesloopt moet worden, zo scheid je het kaf van het koren.

[CrashOne]

Zodra dat gebeurt stapt de helft van alle mozilla/firefox gebruikers over op IE, welke natuurlijk nooit van zijn levens dagen mee doet.

Al lijkt het me een prachtig idee, een mooie stap richting een perfecte wereld.

[Verwijderd]

André schreef op 03 september 2004 @ 13:46:
Op die manier doe ik het ook met mijn eigen site, ik vind dat een perfecte manier om te kijken of je doucment valide is. Ik vind ook dat de fout-tolerantie uit browsers gesloopt moet worden, zo scheid je het kaf van het koren.

Grote sites worden meestal niet uit één bron opgebouwd. Daar komen CMS'en, clicktrackers, ad-generators, weet ik wat voor rotzooi bij kijken. Vaak heeft de 'eigenaar' van een site geen directe controle over al die aspecten.

[Verwijderd]

Verwijderd schreef op 03 september 2004 @ 13:38:
Het is uiteraard wel mooi dat ze ermee begonnen zijn, maar van zo'n groot bedrijf zou je kunnen verwachten dat er een stel client-side specialisten bijzaten.

Specialisten hebben ook maar 2 handen, en als er tig projecten liggen tja. Voor de rest ga ik ervanuit dat het project onder leiding van Lost Boys is gemaakt, en niet door Lost Boys omdat het overgrote deel van Lost Boys opdrachten ge-outsourced wordt, maar wellicht dat Owen daar wat meer van weet.

Wie weet zijn er speciale redenen geweest voor het opdelen in blokken van de source. Want dat is wat ze hebben gedaan als je goed kijkt. Wellicht dat een building block in het achterliggende systeem echt door div's werd gedefinieerd op zo de inhoud van een block vast te zetten zodat layout eromheen minder invloed heeft op de layout .

[ Voor 24% gewijzigd door Verwijderd op 03-09-2004 13:54 ]

[Clay]

* Clay heeft er al best wel respect voor hoor

Het kost best wat moeite om bij zeer grootschalige projecten als client side ontwikkelaar je stempel te drukken op de html die er door de applicatie uitgepoept gaat worden. Veel die hard serverside coders weten vaak a) niet hoe je "hoort" te htmllen, en b) kan het ze ook niet altijd even veel schelen.

Wat ik overigens wel grappig vind is de whitespace Zie ik het goed dat het java is? je kan uit whitespace de jstl / jsp / struts / wathetookis indents terugzien

[André]

Verwijderd schreef op 03 september 2004 @ 13:51:
[...]

Grote sites worden meestal niet uit één bron opgebouwd. Daar komen CMS'en, clicktrackers, ad-generators, weet ik wat voor rotzooi bij kijken. Vaak heeft de 'eigenaar' van een site geen directe controle over al die aspecten.

Klopt, ik liep met mijn lullige site'je al tegen zo'n probleem aan: De Nedstat teller doet het niet. Maar door het JS bestandje zelf lokaal te hosten en aan te passen doet hij het nu wel weer. Ik heb overigens Nedstat hiervan op de hoogte gebracht in een joekel van een mail: en ik kreeg een keurig antwoord terug dat ze dit interessant vinden en dit zeker in het achterhoofd gehouden zou worden.

Clay schreef op 03 september 2004 @ 13:52:
* Clay heeft er al best wel respect voor hoor

Het kost best wat moeite om bij zeer grootschalige projecten als client side ontwikkelaar je stempel te drukken op de html die er door de applicatie uitgepoept gaat worden. Veel die hard serverside coders weten vaak a) niet hoe je "hoort" te htmllen, en b) kan het ze ook niet altijd even veel schelen.

Daarom is het voor een goede html'ler ook noodzaak om de serverside taal te kunnen spreken/coden.

[ Voor 30% gewijzigd door André op 03-09-2004 13:56 ]

[mbravenboer]

crisp: Opera 7.6, identify as Opera: http://www.vaya.nl/vaya/browsermelding.html

Zelf Firefox (0.9.3 op Linux) wordt doorgegestuurd naar deze pagina. Ik vraag me af wanneer het nu eindelijk eens aan de bezoeker zelf wordt overgelaten of hij een pagina kan zien of niet.

[André]

mbravenboer schreef op 03 september 2004 @ 13:59:
[...]

Zelf Firefox (0.9.3 op Linux) wordt doorgegestuurd naar deze pagina. Ik vraag me af wanneer het nu eindelijk eens aan de bezoeker zelf wordt overgelaten of hij een pagina kan zien of niet.

Tja, zodra pagina's op de goede manier gemaakt worden ben je geen browsercheck nodig omdat ze overal werken.

[Verwijderd]

Op die manier doe ik het ook met mijn eigen site, ik vind dat een perfecte manier om te kijken of je doucment valide is. Ik vind ook dat de fout-tolerantie uit browsers gesloopt moet worden, zo scheid je het kaf van het koren.

Als je XHTML als 'text/html' verstuurd ben je in feite gewoon met HTML aan het spelen (al is het dan wel invalid HTML).

[Verwijderd]

André schreef op 03 september 2004 @ 14:00:
[...]

Tja, zodra pagina's op de goede manier gemaakt worden ben je geen browsercheck nodig omdat ze overal werken.

Elke toko weet dat mensen gaan klagen, bellen en mailen als er zaken niet naar behoren werken. Dat heeft niet eens met de manier van maken van een pagina te maken.

Dan zul je daar mensen tussen hebben zitten met beta, alpha, en development builds van browsers, daar wordt je echt niet vrolijk van. Vooral het release beleid van de Mozilla stichting is daar een goed voorbeeld van, want dat is er niet echt heb ik het idee.... genoeg functionaliteit verzameld, alles getest? ... ok... release... volgende lijst, o jij hebt ook wat leuks in elkaar geflanst voor in de browser.... ok .... release... zoiets zeg maar

Dan heb je niet veel keuze meer om de mensen die dan zo graag speciaal willen doen, te blokkeren. Het is gewoon commerciele damage control.

[ Voor 5% gewijzigd door Verwijderd op 03-09-2004 14:15 ]

[oh,when?]

Verwijderd schreef op 03 september 2004 @ 13:32:
[...]

Wat je van 'onze' kant hoort is geen mening, zuiver een vaststelling van feiten. Als je die feiten niet kent moet je het onderwerp ook niet ter sprake brengen, vind ik.

[...]

Dat jij dat wel vindt. Tja, zoals ik al zei, dat is geen kwestie van een mening hebben. Het is niet zo. Feit.

Goh dat je me zomaar woorden in de mond legt, wordt eens wakker en zet die oogkleppen af, en ga aub niet zo kort door de bocht. Is ook zo zonde op zo'n mooie dag als vandaag. Ik heb nergens gerept over valide XHTML of over semantiek, ik quote alleen het team wat er bij Lost Boys aan heeft gewerkt. Ik mag van jou niet meepraten over dit onderwerp, want ik zou de feiten niet kennen, shit, zit ik zowaar al 6 jaar uit me nek te zwetsen. Waar kan ik me aanmelden voor een cursus "Feiten en waarheden in Webdevelopment"?

Gelukkig ben ik druk genoeg in mijn eigen kleine vakgebiedje, en hoef ik niet continue in de marge te pielen met kleine MKB sites...hoe gestructureerd en semantisch correct die ook in elkaar mogen zitten.

* oh,when? vindt de sfeer er hier nogal op achteruit gegaan...waar is het plezier gebleven? Of is het tegenwoordig mode om je vakgebroeders af te kraken op ieder 'onfeit' wat ze produceren...

[BtM909]

oh,when? schreef op 03 september 2004 @ 14:42:
[...]

* oh,when? vindt de sfeer er hier nogal op achteruit gegaan...waar is het plezier gebleven? Of is het tegenwoordig mode om je vakgebroeders af te kraken op ieder 'onfeit' wat ze produceren...

Daarom wordt het ook tijd voor een meeting en een grouphug

_{Het enige wat ik soms beproef is: alles semantisch anders is het ruk. Dat smaakt soms niet echt lekker.
/me rent weg}

[ Voor 10% gewijzigd door BtM909 op 03-09-2004 14:45 ]

[André]

oh,when? schreef op 03 september 2004 @ 14:42:

* oh,when? vindt de sfeer er hier nogal op achteruit gegaan...waar is het plezier gebleven? Of is het tegenwoordig mode om je vakgebroeders af te kraken op ieder 'onfeit' wat ze produceren...

Dat is wel een trent die je hier steeds meer tegenkomt

[Verwijderd]

Is dat niet een standaard?

[André]

Verwijderd schreef op 03 september 2004 @ 14:46:
Is dat niet een standaard?

Bijna Maar standaarden worden wel door meer mensen genegeerd

[crisp]

Verwijderd schreef op 03 september 2004 @ 14:14:
[...]
Dan heb je niet veel keuze meer om de mensen die dan zo graag speciaal willen doen, te blokkeren. Het is gewoon commerciele damage control.

Geef ze dan in ieder geval de keuze om toch de site te bezoeken met hun alpha-beta-development-experimentele-ofwhatever browser; nu wordt keihard de deur dichtgedaan "nee, jij bent groen dus mag je er niet in"...

[Verwijderd]

crisp schreef op 03 september 2004 @ 14:55:
Geef ze dan in ieder geval de keuze om toch de site te bezoeken met hun alpha-beta-development-experimentele-ofwhatever browser; nu wordt keihard de deur dichtgedaan "nee, jij bent groen dus mag je er niet in"...

Zoals ik al aangaf, is het gewoon damage control. Bedrijven nemen gewoon niet het risico dat ze zeikerds krijgen die over elk puntje gaan lopen zeiken omdat hun exotische browser het schijnbaar niet kan verhappen. Als je die mensen alsnog gaat toelaten dan krijg je ongewenst gedrag, en kun je niet garanderen dat een website het nog goed blijft doen.

Dat is van het type mensen dat op hun 2de hands AS400 machine een pre-pre-pre-pre alpha browser installeren en vervolgens buiten adem verontwaardigd aan de telefoon hangen omdat de website het niet doet.

[crisp]

wat is er dan mis met een algemene waarschuwing vooraf waarin je zegt dat eigenlijk alleen bepaalde browsers ondersteund worden, maar dat ze op eigen "risico" via <insert link hier> toch gewoon de site kunnen bezoeken?
En op het moment dat je telefoontjes krijgt van mensen die toch een vrij gangbare browser gebruiken, maar die waarschuwing krijgen, dan zou je je mischien achter je oren moeten gaan krabben - dan is de site wellicht iets te overhaast gelanceerd.
ja, ik weet hoe dat gaat, maar afgaan op een door de client meegestuurde string genaamd userAgent is sowieso bad practice - veel antiviruspaketten onderdrukken die string ook of vullen 'm met bogus content - hebben ze een ondersteunde browser, krijgen ze alsnog die waarschuwing voor hun neus en hangen ze toch aan de telefoon

[ Voor 28% gewijzigd door crisp op 03-09-2004 15:25 ]

[mbravenboer]

Gordijnstok: Dat is van het type mensen dat op hun 2de hands AS400 machine een pre-pre-pre-pre alpha browser installeren en vervolgens buiten adem verontwaardigd aan de telefoon hangen omdat de website het niet doet.

Deze discussie begon met mijn opmerking over Firefox op Linux. Dat is gewoon Gecko en het lijkt me nogal onzin om wel Mozilla 1.x te accepteren (die staat immers het lijstje), maar niet Firefox. De browsercheck is gewoon brak.

[Verwijderd]

oh,when? schreef op 03 september 2004 @ 14:42:
* oh,when? vindt de sfeer er hier nogal op achteruit gegaan...waar is het plezier gebleven? Of is het tegenwoordig mode om je vakgebroeders af te kraken op ieder 'onfeit' wat ze produceren...

/me dacht altijd dat de laatste mensen die plezier hadden in de IT de mensen waren die aan de originele Apple MacIntosh werkten.
Volgens mij zijn er niet veel mensen in /13 die artikelen schrijven en de wereld over reizen om te (s)preken over hun vakgebied. Ik zou me niet te druk maken over de meningen van anderen als ik jou was.

[Verwijderd]

oh,when? schreef op 03 september 2004 @ 14:42:

Goh dat je me zomaar woorden in de mond legt, wordt eens wakker en zet die oogkleppen af, en ga aub niet zo kort door de bocht. Is ook zo zonde op zo'n mooie dag als vandaag. Ik heb nergens gerept over valide XHTML of over semantiek, ik quote alleen het team wat er bij Lost Boys aan heeft gewerkt. Ik mag van jou niet meepraten over dit onderwerp, want ik zou de feiten niet kennen, shit, zit ik zowaar al 6 jaar uit me nek te zwetsen. Waar kan ik me aanmelden voor een cursus "Feiten en waarheden in Webdevelopment"?

Jij vindt het allemaal geweldig wat die Lost Boys hebben gedaan of hebben laten doen. Ik vond het niet zo geweldig, en dat heb ik uitgelegd. Ik heb in eerste instantie helemaal niets gezegd over jou. Ik leg zometeen uit waarom ik dat in de tweede instantie wel deed.

Gelukkig ben ik druk genoeg in mijn eigen kleine vakgebiedje, en hoef ik niet continue in de marge te pielen met kleine MKB sites...hoe gestructureerd en semantisch correct die ook in elkaar mogen zitten.

Dit is gewoon triest, ga ik niet op in. Het zegt meer over jou dan over mij trouwens.

* oh,when? vindt de sfeer er hier nogal op achteruit gegaan...waar is het plezier gebleven? Of is het tegenwoordig mode om je vakgebroeders af te kraken op ieder 'onfeit' wat ze produceren...

Guess what, die sfeer wordt verziekt door mensen die zich heel wat vinden. Ik ben daar ook een van ja, als het onderwerp toevallig in mijn straatje ligt.

oh,when?, je bent arrogant, en dat pik ik zolang dat is gebaseerd op iets dat ik kan waarderen. Gezonde vakkennis bijvoorbeeld. De grootte van het bedrijf waar je werkt kan mij persoonlijk helemaal niets schelen. Dat is niet echt een maatstaf op een forum, volgens mij.

Nog een keer hoe ik de zaken zie:
• Lost Boys produceren een website die volgens hun zeggen XHTML is.
• oh,when? vindt het allemaal heel geweldig en post dat in /13
• Cheatah post dat hij het allemaal niet zo geweldig vind, dat had hij al gauw gezien namelijk, en geeft aan dat de makers van die site de plank hebben misgeslagen, en verwijt dat aan een gebrek aan kennis.
• oh,when? noemt mensen die wel die kennis hebben en vaak anderen iets proberen te leren en anderen aansporen "kommaneukers" em de "web standards politie". oh,when? begint over de grootte van het bedrijf en de opdracht.
• Cheatah vat de benamingen in de post van oh,when? op als een belediging, en maakt oh,when? dus maar even duidelijk hoe de zaak in elkaar steekt. De source van Lost Boys is echt niet zo geweldig, en als oh,when? dat wel vindt, dan snapt oh,when? het zelf kennelijk ook nog niet zo goed. oh,when? Cheatah vindt dat oh,when? er dus geen oordeel over kan vellen, en maakt dat duidelijk. Cheatah is niet zo subtiel door oh,when?'s beledigingen.

offtopic:
Overigens is het niet mijn werk om artikelen te schrijven, of de wereld over te reizen. Ik vind het prima om af en toe eens wat uit te leggen op dit forum, en daar blijft het dan wel bij. Ik ben geen schrijver, ik ben niet erg goed in iets uitleggen, maar ik vind dat ik wel wat weet van HTML. En volgens mij vinden wel meer mensen dat. Iedereen mag me tegenspreken als ik onzin verkoop, en ik zal dat ook doen bij anderen. Kun je daar niet mee leven, dan kun je beter wegblijven.

Maar ik zeg je nu: als je met mij discussieert, kom dan met relevante feiten. welk bedrijf de HTML hoort totaal geen invloed te hebben over je mening of het goed gestructureerde code is. Begin niet over de grootte van het project, beledig anderen niet met 'kleine MKB sites'. Volgende keer dat je dat soort zaken erbij betrekt laat ik dat niet zomaar toe.

Misschien is dat wel een goede stimulans om zinvol te blijven discussiëren. Flamen is eigenlijk zooo kinderachtig.

[-Lars-]

offtopic:
Voordat iemand gaat flamen over dat ik er geen verstand van heb, wil ik degene alvast gelijk geven... Ik ben van het niveau 'gestandaardiseerd hobbiist" (typo?), d.w.z. dat ik voor de lol een site onderhoudt en dat ik daarbij zoveel mogelijk (voor zover mijn kennis en reikt) probeer standaarden toe te passen.

Ik vind het wel goed dat die site XHTML gebruikt/probeert te gebruiken. Zover ik heb begrepen is XHTML 1.0 de opvolger (!=vervanger) van HTML 4.01. Als men er voor kiest om over te stappen op een nieuwere 'versie' dan lijkt mij dat nooit een probleem.
Natuurlijk zullen er syntactisch, semantische of wat dan ook voor 'n soort fouten in zitten. Dat is niet zo gek, er zijn immers enorm veel ' regeltjes' waaraan een pagina zou moeten voldoen, en vaak zijn de regels weinig tot niet relevant voor het uiteindelijke doel. (Wat zou het de gemiddelde IE6-gebruiker schelen of een stukje tekst in een div- of p-tag wordt geplaatst, het ziet er hetzelfde uit).

Ik vraag me af of het 'world wide' in het WWW niet te ver is doorgeschoten. Is het wel rendabel om er bijvoorbeeld voor te zorgen dat sites kunnen worden bezocht via een GSM? Misschien moeten we apparaten gaan gebruiken waarvoor ze echt zijn gemaakt: de TV voor tv-kijken, de radio om naar radiozenders te luisteren, de GSM om te bellen en te SMS'en en de computer voor de vele dingen waarvoor het veelzijdige apparaat is bedoeld.

In de perfecte wereld zou elke site aan alle standaarden voldoen, maar dat is nu eenmaal niet zo.
Misschien moet je het maken van een website vergelijken met het schrijven van een boek. Iedereen kan en mag een boek schrijven. Het is aan de schrijver om al dan niet de standaarden (paragrafen, interpunctie, hoofdletters, hoofdstukken) te volgen. Volgt de schrijver de standaarden, dan zullen veel meer mensen het boek kunnen lezen, volgt hij ze niet, dan zal er maar een beperkt publiek van kunnen lezen. Die mensen mag je echter niet verbieden een slechtgeschreven boek te lezen, net zo min als je het voorstel van Andre moet doorvoeren om 'het kaf van het koren' te kunnen scheiden.
Als ik mijn eerste HTML-pagina hier zo posten zouden de mensen hier omvallen van het lachen: geen html-tags, geen head-tags, geen semantiek, om nog maar te zwijgen van de kleurcombinatie. Maar het werkte wel, en daarom ben ik er mee doorgegaan en heb me er nu zo in verdiept dat ik denk dat ik mijn code bovengemiddeld mag noemen. Had men me destijds gelijk de W3C-standaard onder de neus geschoven was ik heel hard weggerend...

offtopic:
Hoezo een onsamenhangende post? Maarja, ik moest even m'n zegje doen

[Verwijderd]

Cheetah niet alles is zwart en wit, en zodra je in een bedrijf dergelijke projecten gaat doen betekend dit niet dat je lekker 8 uur kunt aan hobbien om het gewenste resultaat te bereiken, omdat je hiermee je andere 10 man die bij het project betrokken zijn niet alleen tegen de haren instrijkt.

Mijn reactie hierop komt niet uit op de opmerking of het wel of niet valid xhtml is, maar op het feit dat er bijna direct gevallen wordt over semantiek. Er wordt direct de sfeer gezet dat zodra de semantiek niet klopt het eigenlijk gewoon slecht is gedaan, en oh when weet net als andere mensen die met grote teams aan dergelijke projecten werken dat de doelen die men denkt te kunnen stellen in theorie mogelijk zijn maar in de praktijk niet haalbaar.

Ik merk het gewoon ook in het dagelijkse gebeuren en ik doe eigenlijk ook alleen grote projecten, dat er meer de nadruk wordt gelegd op het programmeergedeelte van de website dan op de frontend. Goede frontend specialisten zijn er niet veel, en de tijd om de hele boel eromheen te leren is er in het algemeen niet.

Het komt aan op persoonlijke interesses en dit in je vrije tijd leren, oefenen, etc. maar dan nog is er in de praktijk wegens gebrekkige support, vreemde bugs, en er zijn niet veel bedrijven die graag hun marge opofferen voor accessability zonder aantoonbare revenue.

Er zijn ook niet veel mensen die het interessant vinden om hier hun vrije tijd mee te vullen. Het gevolg is dan dat je op een groot project een of twee personen hebt zitten die zich redelijk kunnen vinden in de ultieme markup hype, die vervolgens de andere 8 personen totaal in de weg zitten of ophouden.

Dat LostBoys nu de eerste stapjes heeft gezet getuigt van behoorlijk wat lef, en ik kan me goed voorstellen dat er een aanzienlijk deel van de winstmarge verloren is gegaan aan opleiding. Lompweg de setting van "slecht" neerzetten vind ik totaal misplaatst, daar de source er wel degelijk netjes uitziet, en zonder al teveel moeite kan worden aangepast.

[Verwijderd]

Gordijnstok, ik had het over driekwart, en daar blijf ik bij. Er is iemand (of een aantal iemanden) die kennelijk over de HTML heeft nagedacht, ik zie wel wat structuur, maar het is allemaal niet zo geweldig uitgevoerd.

Eerst was er de discussie dat je geen tabellen moest gebruiken voor opmaak. Daar zit iets in. Alleen hebben veel mensen niet goed begrepen wat er dan wél de bedoeling was. Mensen gingen dus van alles en nogwat doen met div en span elementen. Toen kwam het woordje semantiek ter sprake. Het ging erom dat er wat meer betekenisvolle HTML elementen gebruikt moesten worden.

Bovenstaande verhaalje is je niet vreemd natuurlijk, maar laat ik aan de hand van het verhaaltje eens gaan onderverdelen in groepen. Je hebt mensen die tabellen gebruiken voor de globale layout van een website, programma's als Dreamweaver en Frontpage waren daar vroeger ook niet vies van. Je hebt mensen die wat meer doen met CSS, maar vaak wat minder betekenisvolle HTML elementen gebruiken, zoals div en span, en je hebt mensen die wel aardig in de richting zitten. Wat mij betreft zitten de makers van die HTML op ongeveer driekwart van de weg naar daadwerkelijk goede broncode.

Zodra je ongeveer de helft van de weg gepasseerd bent, denk ik niet dat je nog tijdsverlies gaat lijden. Vanaf dat moment moet je wel ongeveer doorhebben hoe je met CSS het een en ander met de layout kunt. Het laatste stukje is echter het juist gebruiken van de HTML elementen. Als je erbij stil hebt gestaan dat je voor een bepaald doel geen tabel moet gebruiken, en je zet er dus maar een stel div's neer, dan had je in praktisch dezelfde tijd ook kunnen denken aan een ander HTML element. Een unordered list element bijvoorbeeld, voor een menu of iets dergelijks. Als je er maar genoeg mee aan de gang bent, krijg je er vanzelf handigheid in. Dat miste in de site die oh,when? noemde nog.

Je begint zelf over zwart-wit. Ik heb nergens gezegd dat het slecht gedaan was. Ik vind het niet veel bijzonders, er ontbreekt nog een hoop structuur. Laat ik een voorbeeld geven.

Ergens in de source staat een hele rij img tags onder elkaar. Een vlugge analyse wijst uit dat dit het menu bovenaan de website is. Na al die img tags kun je een paar div's en ul's tegen. Waarom is dat menu niet een ul, met binnen een aantal list items weer een ul genest als submenu? Op deze manier is het document dus niet goed gestructureerd. Een zoekmachine kan echt niet vaststellen dat "Uitgebreid zoeken" een onderdeel is binnen "Zoek en boek".

Het is niet geheel eerlijk om zulke dingen "beginnersfoutjes" te noemen, maar het komt daar wel aardig in de buurt. En er zijn genoeg dingen over de broncode te zeggen waardoor ik denk: dat is niet zo bijzonder. Het is volgens mij dus absoluut geen voorbeeld waarvan je zegt: "Zo moet het."

Het is duidelijk dat iemand zijn best heeft gedaan om volgens "de standaarden" te werken, maar helaas zit die persoon nog niet volledig op het juiste spoor. Ik bedoel dat helemaal niet negatief, ik stel dat gewoon vast. Ben niet zo goed in vriendelijk doen, maar dat wil niet zeggen dat ik alles maar onvriendelijk bedoel

[Verwijderd]

Een reden voor het plaatsen van al die elementen kan heel goed de werking van het achterliggende systeem zijn. In css heb je snel dat elementen worden beinvloed door de css van andere elementen of je moet veel met descendants alles afschermen.

Nu is het zo dat veel enterprise cms systemen met building blocks werken, en dat je dus een stuk layout toevoegt aan de totaal layout. Als je deze building blocks op variabele posities kunt laten terugkomen kan ik me goed voorstellen dat Lost Boys heeft gekozen om deze building blocks af te schermen door ze te omvatten met een div tag. Ze hadden evt. ook een class kunnen gebruiken, maar ook hierbij kun je wel eens last krijgen van invloeden.

Dat de image tags onderin staan zal daar ook afkomstig van kunnen zijn. In ons eigen CMS heeft de klant ook de mogelijkheid om zijn eigen templates te maken met behulp van building blocks, een navigatie block, een container block, een poll block etc. Als je deze blocks semantisch wilt plaatsen moet een dergelijk systeem een systeem omvatten waarbij het weet wat het building block is, en hoe het visueel in de source zou moeten komen, dus navigation block bovenaan in de source bijvoorbeeld. Dit bereiken is extreem lastig, en ik heb vooralsnog geen enkel enterprise cms gezien wat dat kan.

[Verwijderd]

Ik ben het met Gordijnstok en oh,when? eens; Het is een belangrijk gegeven dat zo'n typische 'grote jongen' als Lost Boys deze stap heeft gezet. Er blijft natuurlijk altijd ruimte voor verbetering...

• Het is valide maar niet semantisch
• Het is semantisch maar krijgt niet de juiste content-type
• Het krijgt de juiste content-type maar houdt bepaalde browsers tegen
• etc...

(en dan heb ik het nog alleen over code -- belangrijke zaken als usability en accessibility laat ik nog achterwege)

Waarom vinden wij het belangrijk dat LB toch die eerste stap gezet heeft? Veel front-end coders realiseren zich niet hoe totaal onbelangrijk hun vakgebied werd en wordt gevonden. Van design tot back-end architectuur, alles is belangrijker dan de code die het uiteindelijk op het scherm tovert. Waarom? Daar ga ik hier en nu niet over speculeren maar misschien dat deze ommezwaai een indicatie is van een herwaardering van ons vak.

Al is in dit geval de wens duidelijk de vader van de gedachte

Verwijderd schreef op 03 september 2004 @ 12:15:
Ik vraag me af of ze niet beter voor HTML hadden kunnen gaan.

Kun je me uberhaupt een reden geven om niet voor HTML te gaan?

[coubertin119]

1 reden om voor XHTML te kiezen, integratie met MathML/SVG. Vooral die eerste kan wel eens handig zijn.

[Clay]

De "status" van clientside developer is best iets om juist wel op in te gaan eigenlijk Dat is net zo hard een reden ervoor dat het hele xhtml idee maar zo langzaam voortkabbelt.

PPK heeft er in een (inmiddels oud) artikel wel iets zinnigs over gezegd: http://www.digital-web.co...the_ideal_web_team_part2/ en dan ff scrollen naar de client side progger.

[Verwijderd]

coubertin119 schreef op 03 september 2004 @ 21:22:
1 reden om voor XHTML te kiezen, integratie met MathML/SVG. Vooral die eerste kan wel eens handig zijn.

Bravo je hebt alles goed gelezen.

Blues

Het klopt inderdaad wat je zegt over de aandacht die frontend sourcecode krijgt. De meest logische reden is nog altijd dat management geen interesse heeft in het ondersteunen van ofwel zoveel mogelijk browsers, of textreaders voor de visueel gehandicapten. Immers wat zijn de inkomsten uit die doelgroepen vergeleken met de investeringen erin. Zo is nou eenmaal hoe een manager het nog steeds bekijkt.

Nu kun je zeggen, maar het hoeft niet meer tijd te kosten. Tot dat moment moet er wel behoorlijk zijn geinvesteerd in opleiding, en acceptatie van de techniek. Zonder een gezonde basis (zie alinea 1) zijn er maar weinig managers die dergelijke investeringen willen maken, en de klanten zijn er meestal al helemaal niet in geinteresseerd als het extra geld kost.

Dan blijven nog een paar oplossingen over:

- maak de techniek toegankelijker
- betere ondersteuning van de technieken (met IE6 als lastpak kan dat nog tot Longhorn duren)
- lagere learning curve, zodat investeringen lager uitvallen, betekend automatisch ook weer degradatie van het vak "frontend developer
- subsidie vanuit de overheid op bedrijven die standards opleveren (met de huidige bezuiningen lastig)
- iso certificering (ben ik in 2001/2002 al mee actief geweest, is lastig te bereiken)
- maak effectieve kostenbesparingen op zowel korte als lange termijn inzichtelijk gezien over een diversiteit aan projecten.
- zorg voor een tussentijdse update van MSIE, zodat in ieder geval column based layouts ook zonder background en javascript gebruik normaal te maken zijn. In CSS3 zitten nieuwe functionaliteiten speciaal gericht op column layouts.
- geef het de tijd

De nieuwe MSN muziek shop is ook ondanks dat het een makkelijk slachtoffer is voor tabeless layouts, nog steeds in tables gelayouted. De source is groot, de opmaak is niet bijzonder moeilijk maar toch. En toch zitten er behoorlijk getalenteerde developers achter de Music store. Dat moet dan toch ergens vandaan komen

[ Voor 41% gewijzigd door Verwijderd op 03-09-2004 22:11 ]

[Verwijderd]

Kun je me uberhaupt een reden geven om niet voor HTML te gaan?

Nee eigenlijk niet. De redenen om te kiezen voor XHTML zijn niet echt relevant aangezien je de mogelijkheden die je dan krijgt niet kunt gebruiken. (Internet Explorer heeft er geen ondersteuning voor.)

Mocht je nou een intranet maken en je hebt het op een of andere manier voor elkaar gekregen dat FireFox intern wordt gebruikt dan zou het wellicht interessanter kunnen worden. Bijvoorbeeld om het dan te mixen met XForms (waarneer FireFox daarvoor de plugin heeft) mocht die functionaliteit nodig zijn of met SVG. Of als het een of andere (technische) universiteit betreft kan MathML misschien handig zijn voor het uitwisselen van lesmateriaal.

[We Are Borg]

Verwijderd schreef op 03 september 2004 @ 21:10:
Ik ben het met Gordijnstok en oh,when? eens; Het is een belangrijk gegeven dat zo'n typische 'grote jongen' als Lost Boys deze stap heeft gezet. Er blijft natuurlijk altijd ruimte voor verbetering...
[list]
• Het is valide maar niet semantisch

Naar mijn mening is andersom belangrijker. Die validator kan roepen dat het niet helemaal klopt, maar als je daardoor wel een semantisch correcte code hebt is dat meer waard. Vaak is een semantische code ook wel valid, daar niet van

[Verwijderd]

We Are Borg schreef op 04 september 2004 @ 20:06:
[...]

Naar mijn mening is andersom belangrijker. Die validator kan roepen dat het niet helemaal klopt, maar als je daardoor wel een semantisch correcte code hebt is dat meer waard. Vaak is een semantische code ook wel valid, daar niet van

Waarom is dat voor jou belangrijker?

[We Are Borg]

Verwijderd schreef op 04 september 2004 @ 21:13:
[...]


Waarom is dat voor jou belangrijker?

Waarom is XHTML valid zo belangrijk vraag ik me dan af ? Het gaat toch om de achterliggende gedachte van de code, niet wat die domme validator als valid aangeeft of niet. Uiteraard kan je dat niet met mij eens zijn; ik geef het als mening

[ Voor 10% gewijzigd door We Are Borg op 04-09-2004 21:50 ]

[Verwijderd]

Even tussendoor: je hebt het over semantiek, niet over XHTML. HTML kent ook semantiek en is momenteel een betere optie, zoals boven aangegeven. (Invalid XHTML betekent trouwens een gruwelijke user experience. De site niet kunnen bekijken lijkt me niet echt goed voor de PR e.d.)

[Verwijderd]

Verwijderd schreef op 05 september 2004 @ 11:13:
Even tussendoor: je hebt het over semantiek, niet over XHTML. HTML kent ook semantiek en is momenteel een betere optie, zoals boven aangegeven. (Invalid XHTML betekent trouwens een gruwelijke user experience. De site niet kunnen bekijken lijkt me niet echt goed voor de PR e.d.)

Precies Daar doelde ik op

[oh,when?]

@Cheatah:
Grappig. Ik zou je beledigen. Ik zou niet met relevante feiten komen. En daarnaast vindt je me een arrogante eikel/klootzak/whatever. Natuurlijk ben ik het niet met je reactie eens. Maar ergens vindt ik dat we deze discussie maar IRL op een meeting met een biertje erbij moeten voortzetten. Ik zou nu weer een hele lange reply kunnen tikken, maar daar heb ik geen fut voor nu ( plus ik heb een joekel van een kater ) en heftige discussies via internet werken niet echt vindt ik. Communicatie via beeldscherm alleen is soms zo ambigu...

Neemt niet weg dat ik wel een egoïstisch mannetje blijf, dus nu toch een voorzet geeft tot discussie:

De grootte van het bedrijf waar je werkt kan mij persoonlijk helemaal niets schelen. Dat is niet echt een maatstaf op een forum, volgens mij.

[...]

Begin niet over de grootte van het project, beledig anderen niet met 'kleine MKB sites'.

Was al eerder beantwoord in mijn reply, plus wordt nog eens bevestigd door anderen hier:

Ik doel hier met name op de grote webbouwers ( > 80 man ) omdat ik weet hoeveel moeite het kost om in een grote organisatie waarbij vaak meerdere partijen betrokken zijn, iedereen op 1 lijn te krijgen...

en

Grote sites worden meestal niet uit één bron opgebouwd. Daar komen CMS'en, clicktrackers, ad-generators, weet ik wat voor rotzooi bij kijken. Vaak heeft de 'eigenaar' van een site geen directe controle over al die aspecten.

Het kost best wat moeite om bij zeer grootschalige projecten als client side ontwikkelaar je stempel te drukken op de html die er door de applicatie uitgepoept gaat worden. Veel die hard serverside coders weten vaak a) niet hoe je "hoort" te htmllen, en b) kan het ze ook niet altijd even veel schelen.

Er zijn ook niet veel mensen die het interessant vinden om hier hun vrije tijd mee te vullen. Het gevolg is dan dat je op een groot project een of twee personen hebt zitten die zich redelijk kunnen vinden in de ultieme markup hype, die vervolgens de andere 8 personen totaal in de weg zitten of ophouden.

Genoeg stof tot relevante discussie lijkt me zo, zonder op de man te spelen...

[AkaXakA]

Verwijderd schreef op 05 september 2004 @ 11:13:
Invalid XHTML betekent trouwens een gruwelijke user experience. De site niet kunnen bekijken lijkt me niet echt goed voor de PR e.d.

Hoezo geeft invalid xhtml een "gruwelijke" user experience?

http://www.nundroo.com/archives/000007.html
http://www.mikeindustries...arch-to-your-own-standard

Net als die twee zie ik de validator als een stuk gereedschap, niet als een doel op zich. Je kent de gedachtegang: "Voor een man met een hamer ziet elk probleem er uit als een spijker" ?

Invalide xml zorgt natuurlijk wel voor problemen, maar dat wil ik even buiten beschouwing laten.

[JeromeB]

AkaXakA schreef op 07 september 2004 @ 22:36:
[...]


Hoezo geeft invalid xhtml een "gruwelijke" user experience?

http://www.nundroo.com/archives/000007.html
http://www.mikeindustries...arch-to-your-own-standard

Net als die twee zie ik de validator als een stuk gereedschap, niet als een doel op zich. Je kent de gedachtegang: "Voor een man met een hamer ziet elk probleem er uit als een spijker" ?

Invalide xml zorgt natuurlijk wel voor problemen, maar dat wil ik even buiten beschouwing laten.

XHTML is een XML-subset, geen XML-superset. Dat houdt dus in dat een XHTML document aan de XML regels moet voldoen en daarbovenop ook aan de extra XHTML regels.

Dit is ook een reden waarom XHTML misschien toch niet zo geschikt is om webdocumenten mee te maken.

[ Voor 3% gewijzigd door JeromeB op 07-09-2004 23:34 ]

[Verwijderd]

Als je ervoor zorgt dat de browser je document als xhtml gaat behandelen heeft Anne gelijk hoor Xhtml is xml, en als een echt xml document niet goed is opgezet klapt je browser eruit met een error Ik had het gisteren ook in IE6 zelfs..jaja

[AkaXakA]

Dus dan zorg je dat je dat (dus de browser informeren dat het xhtml is) niet doet, totdat alle browsers er echt klaar voor zijn (en omliggende dingen, e.g. CMS'en, enz).

Dan hoef je maar een paar dingen te veranderen en voila, prachtige xhtml. (met alle voordelen zoals MathML, enz)

xHtml breekt niet als het verstuurd wordt als html, hoe pijn het ook mag doen in het hart van puristen ( ).

[Verwijderd]

Tja, maar waarom zou je dan geen HTML gebruiken? In feite verstuur je dan gewoon invalid HTML, kun je beter valid HTML versturen imo.

Van HTML naar XHTML is 1 keer langs tidy en klaar.

[Verwijderd]

behalve als het door een cms geproduceerd wordt, dan betekent die ommezwaai alle componenten doorspitten. Dus als ik een CMS bouw of componenten ervoor, zorg ik dat ie xhtml uitspuwt (zeker in mijn huidige project waarin MathML zeker een issue gaat worden). Browsers die geen xhtml aankunnen serveren we dan lekker text/html

ik ben het eens met je stelling dat het een beetje eng aanvoelt, en voor kleinere sites zou ik ook altijd html aanbevelen (dat is wel eens anders geweest ja), maar voor grote projecten die we in de toekomst niet weer helemaal willen omgooien, grijp ik liever nu al naar xhtml en dan hoeven we er niet meer naar om te kijken (als IE xhtml accepteerd, zorgt het script gewoon voor een gelijke behandeling)

[ Voor 39% gewijzigd door Verwijderd op 08-09-2004 18:09 ]

[AkaXakA]

Wat Mophor zei.

FF langs tidy gaat gewoon niet* op als je met cms'en werkt.

*e.g. het is niet onmogelijk, maar het creeert enorm veel werk.

[Tom-Eric]

Het is toch niet zo moeilijk om voor browsers die alleen HTML ondersteunen de XHTML door een XSLT parser te halen en zo het zooitje transformeert naar HTML 4.01 strict, dat kan in 10 regels code.

[mullah]

TumTum schreef op 09 september 2004 @ 15:35:
Het is toch niet zo moeilijk om voor browsers die alleen HTML ondersteunen de XHTML door een XSLT parser te halen en zo het zooitje transformeert naar HTML 4.01 strict, dat kan in 10 regels code.

Help? 10 regels code is niet interessant in zo een geval... je kunt beter 300 regels code doen die het op een slimme en efficiente manier voor je doen, want anders loop je bij een grote site on the fly voor 95% van de requests je site door die 10 regels code te persen... en eigenlijk je processor(s) alleen maar nutteloos op te warmen.

Laat ook maar

[Genoil]

TumTum schreef op 09 september 2004 @ 15:35:
Het is toch niet zo moeilijk om voor browsers die alleen HTML ondersteunen de XHTML door een XSLT parser te halen en zo het zooitje transformeert naar HTML 4.01 strict, dat kan in 10 regels code.

10 regels is best optimistisch

sorry layout ... daar ga je:

PHP:

<?php
    
    $x = (stristr($_SERVER["HTTP_ACCEPT"],"application/xhtml+xml")) ? true : false;

    $oa                         = array();
    $oa['method']               = $x ? "xml" : "html";
    $oa['version']              = $x ? "1.0" : "4.01";
    $oa['media-type']           = $x ? "application/xhtml+xml" : "text/html";
    $oa['encoding']             = "UTF-8";
    $oa['doctype-public']       = $x ? "//W3C//DTD XHTML 1.0 Strict//EN" : 
                                       "//W3C//DTD HTML 4.01 Strict//EN" ;
    $oa['doctype-system']       = $x ? "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd" : 
                                       "http://www.w3.org/TR/html4/strict.dtd";
    $oa['omit-xml-declaration'] = $x ? "no" : "yes";
    $oa['indent']               = "yes";
            
    $xmldoc = new DomDocument();
    $xmldoc->load($_GET['xml']);

    $xsltdoc = new DomDocument();
    $xsltdoc->load($_GET['xsl']);
    
    $xpath = new Domxpath($xsltdoc);
    $result = $xpath->query("//xsl:output");
    
    if($result->length == 0) {
        $result2 = $xpath->query("//xsl:stylesheet");
        $stylesheet = $result2->item(0);
        $output  = $xsltdoc->createElementNS("http://www.w3.org/1999/XSL/Transform", "xsl:output");
        
        $stylesheet->insertBefore($output,$stylesheet->firstChild);
        foreach($oa as $name => $value) 
            $output->setAttribute($name, $value);
    }
    else 
        foreach($result as $output) 
            foreach($oa as $name => $value) 
                $output->setAttribute($name, $value);

    $xsltproc= new Xsltprocessor();
    $xsl = $xsltproc->importStylesheet($xsltdoc);
    $xsltproc->setParameter("", "outputmethod", $oa['method']);
    
    header("content-type:".$oa['media-type'].";charset=".$oa['encoding']);      
    print $xsltproc->transformToXml($xmldoc);
?>

dit scriptje is niet meer dan de normale manier om met php5 en libxml2 een XSLT transformatie uit te voeren, behalve dat voordat de transformatie wordt uitgevoerd, het xsl:output element wordt ingevoegd/veranderd om zich aan te passen aan de mogelijkheden van de user-agent.

als extraatje wordt de output-method ook nog als parameter aan de stylesheet doorgegeven, zodat je in de XSL eventueel nog wijzigingen in de output-code kunt aanbrengena dhv de output-method..

'zinvol' XHTML voorbeeldje:
http://php5.meneer.net/te...math.xhtml&xsl=output.xsl
(om de formule in IE goed te zien , moet je Mathplayer geinstalleerd hebben.

[ Voor 37% gewijzigd door Genoil op 09-09-2004 20:43 ]

[Tom-Eric]

Het kan ook korter hoor, in mijn CMS werkt het allemaal via DOM XML, maar onderstaande code zou ook gewoon moeten werken en cached ook meteen het resultaat.

PHP:

if(strpos('application/xhtml+xml', $_SERVER['HTTP_ACCEPT']) == -1) {
    header('Content-Type: text/html;charset=UTF-8');
    $cache  =   CACHE_DIR . md5($content) . '.html';
    if(file_exists($cache))
        echo    implode("\n", file($cache));
    else {
        $xsltproc   =   xslt_create();
        xslt_set_encoding($xsltproc, 'UTF-8');
        $content    =   xslt_process($xsltproc, 'arg:/_xml', '/location/of/xhtm-to-html.xslt', null, array('/_xml', => $output));
        fputs(fopen($cache, 'w'), $content);
        echo    $content;       
    }
}
else
    echo    $content;

[ Voor 11% gewijzigd door Tom-Eric op 09-09-2004 21:18 ]

[Genoil]

ja ok zo kan het ook, maar dan neem je wel een extra stap. mijn scriptje modificeert on-the-fly de gegeven xsl-sheet, m.a.w. er hoeft geen xhtml in, de xml kan alles zijn (mits de xsl -sheet er (x)html van maakt).

[Tom-Eric]

Dat gebeurt in mijn CMS ook. Ik hou door een hele request een XML document bij, en aan het einde parse ik dat naar het gewenste content type (atom/xhtml/xsl:fo). Soms gooi ik daar dan nog een transformatie overheen voor een ander content type (atom -> rss, atom -> rdf, xhtml -> html) of gooi ik er een script overheen om de gewenste content naar een binair formaat te transformeren (xsl:fo -> pdf). Voordeel hiervan is dat ik van elke gewenste pagina meteen een x aantal verschillende versies heb (voorbeeld: XHTML -> HTML dmv. XHTML -> HTML + object -> img, Atom -> RSS dmv. Atom -> RDF, pdf gedeelte ben ik nu aan het reviseren want ik wil van XSL:FO af). Het lijkt mij dat als je jou methode met die van mij vergelijkt de executie tijd grotendeels hetzelfde zal blijven (en als je cached, waarschijnlijk gelijk).

Punt is, het is mogelijk om zonder veel moeite te doen je XHTML als HTML 4.01 te versturen naar clients die XHTML niet ondersteunen, dus een "CMS" is niet echt een valide reden (behalve als je zelf geen aanpassingen zou kunnen maken).