Standaarden (W3C, etc.)

[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).