Kan je dat niet oplossen met wat CData'tjes hier en daar?Gomez12 schreef op dinsdag 08 juni 2010 @ 01:44:
[...]
En daar zit ook gelijk het grote manco van xhtml, het is niet vergevingsgezind. Een devver kan een perfecte valide xhtml pagina maken en de eerste de beste marketingmedewerker heeft binnen 1 seconde een borkende pagina veroorzaakt.
Ik geloof het wel ja, dan hoef je <>&" en ' ook niet te escapen: Wikipedia: CDATACaelorum schreef op dinsdag 08 juni 2010 @ 16:22:
[...]
Kan je dat niet oplossen met wat CData'tjes hier en daar?
[ Voor 11% gewijzigd door Sebazzz op 08-06-2010 16:40 ]
[Te koop: 3D printers] [Website] Agile tools: [Return: retrospectives] [Pokertime: planning poker]
Alleen al de manier waarop je het formuleert zegt eigenlijk genoeg over waarom je niet tegen dit soort dingen aan wil lopen. "Wat dingetjes hier en daar toevoegen" vloekt lichtelijk met een overdreven systematisch zeikerig systeem.Caelorum schreef op dinsdag 08 juni 2010 @ 16:22:
[...]
Kan je dat niet oplossen met wat CData'tjes hier en daar?
Totdat je per ongeluk een "]]>" in je data hebt staan.Sebazzz schreef op dinsdag 08 juni 2010 @ 16:40:
[...]
Ik geloof het wel ja, dan hoef je <>&" en ' ook niet te escapen: Wikipedia: CDATA
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
Klopt, het beste is dan ook om te escapen..oisyn schreef op dinsdag 08 juni 2010 @ 17:04:
[...]
Totdat je per ongeluk een "]]>" in je data hebt staan.
[Te koop: 3D printers] [Website] Agile tools: [Return: retrospectives] [Pokertime: planning poker]
Niks overdreven. XML is juist bijzonder clean als je het mij vraagt. Heerlijk in duidelijkheid en eenvoud. Ik vind het dan ook zeer dubieus als een ICT'er gaat klagen als een systeem niet voldoende "vergevingsgezind" is...curry684 schreef op dinsdag 08 juni 2010 @ 16:46:
[...]
Alleen al de manier waarop je het formuleert zegt eigenlijk genoeg over waarom je niet tegen dit soort dingen aan wil lopen. "Wat dingetjes hier en daar toevoegen" vloekt lichtelijk met een overdreven systematisch zeikerig systeem.
Loont het nou nog om je te verdiepen in alle ins en outs van XHTML, terwijl HTML5 op dit moment de toekomst lijkt te hebben?
XHTML5 valt ook onder die noemer. Dus wat dat betreft ja. Alleen heeft XHTML niet meer mogelijkheden ofzo boven HTML, en ziet het er ook niet naar uit dat dat nog gaat komen. Dus als je de HTML-syntax gewend bent, gewoon lekker daarbij blijven.mcdronkz schreef op woensdag 09 juni 2010 @ 21:43:
Loont het nou nog om je te verdiepen in alle ins en outs van XHTML, terwijl HTML5 op dit moment de toekomst lijkt te hebben?
Er valt weinig te verdiepen. XHTML1.0 is gewoon HTML4 in een XML-jasje. Net zo is XHTML5 een XML-versie van HTML5. Alle browsers die HTML5 ondersteunen snappen ook XHTML5. Mijn gok is dat XHTML5 sneller is, simpelweg omdat het veel eenvoudiger te parsen is dan HTML. Of je daar als gebruiker iets van merkt betwijfel ik.mcdronkz schreef op woensdag 09 juni 2010 @ 21:43:
Loont het nou nog om je te verdiepen in alle ins en outs van XHTML, terwijl HTML5 op dit moment de toekomst lijkt te hebben?
Wij gebruiken XSLT voor onze templating. De keuze voor XHTML(5) is daarmee eigenlijk een no-brainer. Deden ze dat bij Wehkamp ook maar, de site werkt nog steeds niet

[edit] De webmaster maar es gemaild. Althans, dat denk ik. Nog geen bounce terug, dus wie weet.
[edit2] Nou kijk aan: "Hartelijk dank voor uw e-mail. Dit is een automatisch verzonden ontvangstbevestiging."
[ Voor 12% gewijzigd door Fuzzillogic op 09-06-2010 23:00 ]
Is het niet zo dat omdat XHTML5 XML is, het hele document binnen moet zijn voordat je kan beginnen met parsen?
[Te koop: 3D printers] [Website] Agile tools: [Return: retrospectives] [Pokertime: planning poker]
Anoniem: 26306
Nee, waarom? Hoe denk je dat SAX parsers werken?Sebazzz schreef op woensdag 09 juni 2010 @ 22:51:
Is het niet zo dat omdat XHTML5 XML is, het hele document binnen moet zijn voordat je kan beginnen met parsen?
Gewoon ergens gehoord, van een XHTML tegenstander dan wel
[Te koop: 3D printers] [Website] Agile tools: [Return: retrospectives] [Pokertime: planning poker]
Anoniem: 26306
Van iemand die er blijkbaar niets van begrijpt ja. Het is natuurlijk mogelijk om te beginnen met parsen zodra de eerste bytes binnen zijn.
Wat die figuur waarschijnlijk bedoelt is dat je pas weet of een document well-formed is als het helemaal binnen is. Dat wel ja, maar daar hoef je natuurlijk niet op te wachten. Als een document well-formed is zal de parser namelijk nergens over struikelen.
Wat die figuur waarschijnlijk bedoelt is dat je pas weet of een document well-formed is als het helemaal binnen is. Dat wel ja, maar daar hoef je natuurlijk niet op te wachten. Als een document well-formed is zal de parser namelijk nergens over struikelen.
Als ik naar de verschillen kijk, lijkt het me wel iets om in detail naar te kijken.Fuzzillogic schreef op woensdag 09 juni 2010 @ 22:48:
[...]
Er valt weinig te verdiepen. XHTML1.0 is gewoon HTML4 in een XML-jasje. Net zo is XHTML5 een XML-versie van HTML5. Alle browsers die HTML5 ondersteunen snappen ook XHTML5. Mijn gok is dat XHTML5 sneller is, simpelweg omdat het veel eenvoudiger te parsen is dan HTML. Of je daar als gebruiker iets van merkt betwijfel ik.
Ik ben nu bezig met dit boek (vrij beschikbaar), daar komt volgens mij XHTML5 niet aan de orde. Is het een goede volgorde om eerst dat boek eens door te werken, en daarna te kijken naar de meerwaarde van XHTML5?
De verschillen slaan vooral op de syntax van XML/XHTML. Qua semantiek is eigenlijk geen verschil tussen HTML en XHTML.mcdronkz schreef op woensdag 09 juni 2010 @ 23:03:
[...]
Als ik naar de verschillen kijk, lijkt het me wel iets om in detail naar te kijken.
Ik zou me daar niet druk over maken. Persoonlijk vind ik XHTML gewoon cleaner en de logische keuze, maar praktisch gezien zijn de verschillen dermate klein dat het eigenlijk onboeiend is. Zolang je maar geen HTML gaat serveren terwijl je claimt dat het XHTML is, is er weinig aan de hand. Als je nu begint bent met HTML(5) dan lijkt het me onwaarschijnlijk dat je binnenkort al problemen krijgt dat je code opeens XHTML MOET zijn. Tegen de tijd dat dat wel een zaak is zul je zien dat het een fluitje van een cent is.Ik ben nu bezig met dit boek (vrij beschikbaar), daar komt volgens mij XHTML5 niet aan de orde. Is het een goede volgorde om eerst dat boek eens door te werken, en daarna te kijken naar de meerwaarde van XHTML5?
Het geblaat in dit topic is vooral van principiële aard
Die potentie heeft het inderdaad, maar zolang je het als "text/html" verstuurt, wordt het gewoon als HTML gerenderd. En zolang IE bestaat, kun je het niet als "application/xml" versturen.Fuzzillogic schreef op woensdag 09 juni 2010 @ 22:48:
[...]
Er valt weinig te verdiepen. XHTML1.0 is gewoon HTML4 in een XML-jasje. Net zo is XHTML5 een XML-versie van HTML5. Alle browsers die HTML5 ondersteunen snappen ook XHTML5. Mijn gok is dat XHTML5 sneller is, simpelweg omdat het veel eenvoudiger te parsen is dan HTML. Of je daar als gebruiker iets van merkt betwijfel ik.
Enige voordeel is dan nog de striktere syntax, die misschien wat snelheidswinst oplevert omdat er minder foutcorrectie hoeft plaats te vinden. Maar niemand weerhoudt je ervan om je HTML-tags ook gewoon netjes af te sluiten.
En toch doe je dit standaard voor 60% van de browsers vandaag de dag.Fuzzillogic schreef op woensdag 09 juni 2010 @ 23:21:
[...]
Zolang je maar geen HTML gaat serveren terwijl je claimt dat het XHTML is, is er weinig aan de hand.
Dan heb je veel van de argumenten niet begrepen. De keuze van HTML(5) is voor de meeste hier geen principiele keuze, maar een praktische.Het geblaat in dit topic is vooral van principiële aard
Jawel. De HTML specs. Lang niet elke tag mag je afsluiten.mcDavid schreef op donderdag 10 juni 2010 @ 01:11:
[...]
Maar niemand weerhoudt je ervan om je HTML-tags ook gewoon netjes af te sluiten.
Sja dat krijg je ervan als je "tolerant" bent voor fouten. Dan gaan veel mensen er automatisch een puinhoop van maken, al dan niet bewust.Bosmonster schreef op donderdag 10 juni 2010 @ 08:40:
[...]
En toch doe je dit standaard voor 60% van de browsers vandaag de dag.
Ik heb het heel goed begrepen. Ik zeg toch ook dat het vooral geneuzel in de marge is en dat je vooral moet doen wat je het handigst vindt. Ik geef enkel wat argumenten waarom ik vind dat XHTML beter is.Dan heb je veel van de argumenten niet begrepen. De keuze van HTML(5) is voor de meeste hier geen principiele keuze, maar een praktische.
We hebben het over XHTML. Jij zegt dat je dat goed moet doen, terwijl je dat vandaag de dag simpelweg niet KAN. Je bent dus zelf degene die tolerant bent/moet zijn voor fouten, aangezien je XHTML door het merendeel van de browsers fout geinterpreteerd wordt.Fuzzillogic schreef op donderdag 10 juni 2010 @ 08:56:
[...]
Sja dat krijg je ervan als je "tolerant" bent voor fouten. Dan gaan veel mensen er automatisch een puinhoop van maken, al dan niet bewust.
Derhalve snap ik niet wat je met bovenstaande bedoelt.
Als je zegt dat het principieel is en geneuzel in de marge heb je het nog steeds niet begrepen. Goed onderbouwde praktische bezwaren zijn niet principieel en zijn geen geneuzel in de marge. Wat wel geneuzel in de marge is, is het argument over het afsluiten van tags en "netheid".Ik heb het heel goed begrepen. Ik zeg toch ook dat het vooral geneuzel in de marge is en dat je vooral moet doen wat je het handigst vindt. Ik geef enkel wat argumenten waarom ik vind dat XHTML beter is.
Ik heb het gevoel dat je de echte argumenten een beetje naast je neerlegt en blijft hameren op je eigen argumenten. En die komen, voor wat ik gezien heb, nog niet verder dan "dat jij dat netter vindt".
[ Voor 8% gewijzigd door Bosmonster op 10-06-2010 10:20 ]
Merendeel? Alleen IE slaat de plank mis. Als een browser in zijn headers expliciet aangeeft application/xhtml+xml te ondersteunen, dan werkt dat ook prima, maar dan moet je wel tenminste well-formed code aanleveren.Bosmonster schreef op donderdag 10 juni 2010 @ 10:17:
[...]
We hebben het over XHTML. Jij zegt dat je dat goed moet doen, terwijl je dat vandaag de dag simpelweg niet KAN. Je bent dus zelf degene die tolerant bent/moet zijn voor fouten, aangezien je XHTML door het merendeel van de browsers fout geinterpreteerd wordt.
Derhalve snap ik niet wat je met bovenstaande bedoelt.
Potato/potato. Dat is net zo'n principieel geneuzel in de marge.Als je zegt dat het principieel is en geneuzel in de marge heb je het nog steeds niet begrepen.
Ja, precies, omdat ik die "echte" argumenten zwak vind. Ze zijn vaak gestoeld op het gedrag van archaïsche browsers als IE. Maar zelfs dan is XHTML prima bruikbaar, mits je rekening houdt met wat quirks. Firefox die over de zeik gaat met <iframe />, zoals ik net merk. Triest dat je er tegenwoordig nog rekening mee moet houden, maar het resultaat blijft valid XHTML. Dat heeft echt zo zijn voordelen; XPath en XSLT zijn mooie hulpmiddelen, die wel XML vereisen.Ik heb het gevoel dat je de echte argumenten een beetje naast je neerlegt.
IE blijft nog steeds het merendeel.Fuzzillogic schreef op donderdag 10 juni 2010 @ 10:49:
[...]
Merendeel? Alleen IE slaat de plank mis.
Als jij praktische argumenten en bezwaren geneuzel vindt, dan valt daar verder weinig over te discussieren idd.Potato/potato. Dat is net zo'n principieel geneuzel in de marge.
Als jij dit soort problemen geen bezwaar vindt is dat ook prima. Aan het topic te zien ben jij echter een van de weinigenJa, precies, omdat ik die "echte" argumenten zwak vind. Ze zijn vaak gestoeld op het gedrag van archaïsche browsers als IE. Maar zelfs dan is XHTML prima bruikbaar, mits je rekening houdt met wat quirks. Firefox die over de zeik gaat met <iframe />, zoals ik net merk.
Ik heb me een beetje ingelezen, en volgens mij is het voordeel van XHTML zeer beperkt. XHTML 1.0 mag je met het MIME-type 'text/html' over het net versturen. Zo biedt XHTML 1.0 - correct me if I'm wrong - werkelijk geen voordeel, omdat dan nog steeds niets duidelijk is over de well-formedness van het document. Je kunt dan nog steeds aankloten, en de browser het lekker laten uitzoeken. XHTML 1.1 mag je alleen als 'application/xhtml+xml' over het web sturen, maar dan sluit je het meerendeel van de browsers uit, simpelweg geen optie.
Wat is dan een overtuigende reden om tóch XHTML te serveren?
edit: Ja, je kunt natuurlijk m.b.v. content negotiation bepalen wat je aan een browser serveert, maar ik kan me niet voorstellen dat de voordelen daarvan tegen de nadelen opwegen.
Wat is dan een overtuigende reden om tóch XHTML te serveren?
edit: Ja, je kunt natuurlijk m.b.v. content negotiation bepalen wat je aan een browser serveert, maar ik kan me niet voorstellen dat de voordelen daarvan tegen de nadelen opwegen.
[ Voor 14% gewijzigd door mcdronkz op 10-06-2010 12:53 ]
Heb jij al eens een klant verteld dat je je website niet in IE kan laten werken omdat je dan XHTML niet goed toe kan passen?Fuzzillogic schreef op donderdag 10 juni 2010 @ 10:49:
[...]
Merendeel? Alleen IE slaat de plank mis. Als een browser in zijn headers expliciet aangeeft application/xhtml+xml te ondersteunen, dan werkt dat ook prima, maar dan moet je wel tenminste well-formed code aanleveren.

'E's fighting in there!' he stuttered, grabbing the captain's arm.
'All by himself?' said the captain.
'No, with everyone!' shouted Nobby, hopping from one foot to the other.
Allemachtig. Is enige ideologie bij ICT'ers dan zo ver te zoeken? Kijkt er niemand verder dan vandaag?
Natuurlijk zorgen we ervoor dat onze sites nu in IE werken, en ja dan gaat de well-formed-maar-brakker-renderer-patched XHTML dus "gewoon" als text/html de deur uit. Duh.
Met de komst van de HTML5-compatible browsers zal het (mag ik hopen) geen probleem meer zijn om gewoon XHTML5 te versturen, met een XML-content type. Technisch en ideologisch gezien vind ik XML gewoon een stuk fijner. En tegen de tijd dat de browsers er eindelijk ook eens klaar voor zijn hebben wij alles al klaar om pure, nette XHTML te serveren.
Dus ja, XHTML is beter/flexibeler, nee hard-core XHTML is nu nog geen optie, maar je kunt je er al op voorbereiden (XHTML genereren die ook door HTML-parsers gesnapt wordt) ook al heeft het *nu* weinig voordelen boven HTML.

Met de komst van de HTML5-compatible browsers zal het (mag ik hopen) geen probleem meer zijn om gewoon XHTML5 te versturen, met een XML-content type. Technisch en ideologisch gezien vind ik XML gewoon een stuk fijner. En tegen de tijd dat de browsers er eindelijk ook eens klaar voor zijn hebben wij alles al klaar om pure, nette XHTML te serveren.
Dus ja, XHTML is beter/flexibeler, nee hard-core XHTML is nu nog geen optie, maar je kunt je er al op voorbereiden (XHTML genereren die ook door HTML-parsers gesnapt wordt) ook al heeft het *nu* weinig voordelen boven HTML.
Het heeft géén voordelen boven HTML. Als het ooit een keer goed door browsers ondersteund wordt, ja. Dan wel. Nu niet. We developen nu, niet morgen.
HTML5 is nog niet af maar wordt wel goed ondersteund, en zelfs in IE8 kun je het gebruiken. IE9 wordt zelfs een HTML5-voorvechter. XHTML is het ondergeschoven kindje en zal dat ook blijven.
Verder kun je je HTML5 ook gewoon well-formed schrijven, da's echt niet iets waar XHTML een patent op heeft ofzo.
XHTML was een leuk idee, maar meteen ook een dat min of meer achterhaald is. Best hoor dat je het daar niet mee eens bent, maar ga dan niet anderen verwijten dat ze niet vooruit kijken. HTML5 is de toekomst, zeker nu Apple, Microsoft én Google het zo omarmen.
HTML5 is nog niet af maar wordt wel goed ondersteund, en zelfs in IE8 kun je het gebruiken. IE9 wordt zelfs een HTML5-voorvechter. XHTML is het ondergeschoven kindje en zal dat ook blijven.
Verder kun je je HTML5 ook gewoon well-formed schrijven, da's echt niet iets waar XHTML een patent op heeft ofzo.
XHTML was een leuk idee, maar meteen ook een dat min of meer achterhaald is. Best hoor dat je het daar niet mee eens bent, maar ga dan niet anderen verwijten dat ze niet vooruit kijken. HTML5 is de toekomst, zeker nu Apple, Microsoft én Google het zo omarmen.
'E's fighting in there!' he stuttered, grabbing the captain's arm.
'All by himself?' said the captain.
'No, with everyone!' shouted Nobby, hopping from one foot to the other.
Dat is apart dat je dat zegt, aangezien het juist de XHTML-ontwikkeling is die is stopgezet. Het is een gepasseerd station.
Het was even een hype onder ontwikkelaars toen XML helemaal de bom was en alles dat begon met een X automatisch goed was.
Dus ja.. ik kijk verder dan vandaag en gisteren. En dat is een van de redenen dat ik liever geen XHTML gebruik, maar mijn voorkeur uitgaat naar de standaard van morgen: HTML5.
[ Voor 70% gewijzigd door Bosmonster op 10-06-2010 15:08 ]
W3C lijkt trouwens zelf het verkeerde voorbeeld te geven. Wanneer ik deze pagina open, wordt 'ie als 'text/html' gestuurd, terwijl de HTML-code me weet te vertellen dat het volgens de XHTML 1.1 standaard geschreven zou moeten zijn. Of zie ik iets over het hoofd?
Het zijn statische pagina's, en de server gaat niet kijken of het doctype XHTML is. En anders vallen IE gebruikers ook buiten de boot, die kunnen de specificatie dan niet bekijken.
Ahhh
Ahhh
[Te koop: 3D printers] [Website] Agile tools: [Return: retrospectives] [Pokertime: planning poker]
Grappig, ik zat me net af te vragen of jij wel enig realistisch besef had... Of dat het enkel maar theoretisch geneuzel was. ( niet bedoeld als flame, lees de rest van de post )Fuzzillogic schreef op donderdag 10 juni 2010 @ 14:41:
Allemachtig. Is enige ideologie bij ICT'ers dan zo ver te zoeken? Kijkt er niemand verder dan vandaag?
Dus feitelijk presenteer je geen html en ook geen xhtml aan IE?Natuurlijk zorgen we ervoor dat onze sites nu in IE werken, en ja dan gaat de well-formed-maar-brakker-renderer-patched XHTML dus "gewoon" als text/html de deur uit. Duh.
Je produceert gewoon een tag-soup en hoopt dat IE er wijs uit kan worden, dat is zo ongeveer het grootste probleem met xhtml. Of je zou momenteel 2 ontwikkeltrajecten hebben ( html voor IE en xhtml voor de rest ) of je presenteert enkel maar een tag-soup.
En tot die tijd serveer je gewoon een allegaartje aan het grootste gedeelte van de webusers...En tegen de tijd dat de browsers er eindelijk ook eens klaar voor zijn hebben wij alles al klaar om pure, nette XHTML te serveren.
Je bent misschien klaar voor de toekomst, maar nu produceer je "rommel" volgens geen enkele standaard.
Tja, als ICT'er ben ik dan iets rechtlijniger, of ik produceer html of ik produceer xhtml.Dus ja, XHTML is beter/flexibeler, nee hard-core XHTML is nu nog geen optie, maar je kunt je er al op voorbereiden (XHTML genereren die ook door HTML-parsers gesnapt wordt) ook al heeft het *nu* weinig voordelen boven HTML.
Zolang IE geen xhtml accepteert vind ik het een mooi ideaal maar praktisch niet uitvoerbaar. Als IE het al zou gaan accepteren dan komen er weer additionele problemen om de hoek kijken ( zoals copy/paste fixes etc ).
Oftewel, ik snap je theoretische punt maar praktisch vind ik het niet.
Uit mijn templates komt valid XHTML rollen, zoals ik al zei. Die XHTML is wel zodanig dat HTML-parsers van IE e.d. er geen probleem van maakt. En we serveren het als text/html, om geen gezeik te krijgen van dat stuk antiek. Werkt prima, "dankzij" de tolerantie van de browsers.
Mijn voorkeur zou echter gaan naar valid XHTML1.1 voor nu, en op termijn XHTML5. XHTML1.1 is een no-go helaas, maar XHTML5 zal toch echt wel ondersteund worden, mag ik hopen.
Dat is toch niet zo moeilijk te begrijpen?!
Mijn voorkeur zou echter gaan naar valid XHTML1.1 voor nu, en op termijn XHTML5. XHTML1.1 is een no-go helaas, maar XHTML5 zal toch echt wel ondersteund worden, mag ik hopen.
Dat is toch niet zo moeilijk te begrijpen?!
[ Voor 4% gewijzigd door Fuzzillogic op 10-06-2010 21:22 ]
Het is toch ook niet moeilijk te begrijpen dat mensen het niks vinden?
Feit is dat die X niks toevoegt als je geen XSLT gebruikt. Jij vind die combinatie blijkbaar prettig werken en dat is prima, maar accepteer dan ook dat het merendeel van de developers die combinatie niet prettig vindt.
[ Voor 32% gewijzigd door Bosmonster op 10-06-2010 21:40 ]
En stiekem lever je dan spul dat volgens geen enkele standaard correct is. Netjes.Fuzzillogic schreef op donderdag 10 juni 2010 @ 21:19:
Uit mijn templates komt valid XHTML rollen, zoals ik al zei. Die XHTML is wel zodanig dat HTML-parsers van IE e.d. er geen probleem van maakt. En we serveren het als text/html, om geen gezeik te krijgen van dat stuk antiek. Werkt prima, "dankzij" de tolerantie van de browsers.
'E's fighting in there!' he stuttered, grabbing the captain's arm.
'All by himself?' said the captain.
'No, with everyone!' shouted Nobby, hopping from one foot to the other.
Niet dat je er iets mee opschiet, maar omdat XHTML 1.0 een soort van overgangsstandaard is, mag je het volgens de standaard gewoon als text/html aanbieden. Als je de code zelf dan ook nog eens volgens de standaard schrijft, doe je volgens mij niets 'verkeerd'. IE6/7/8 en de rest van de browsers zouden dat moeten begrijpen.NMe schreef op donderdag 10 juni 2010 @ 22:16:
[...]
En stiekem lever je dan spul dat volgens geen enkele standaard correct is. Netjes.
Ze begrijpen het, maar dat komt omdat ze spul dat ze niet begrijpen gewoon overslaan. Je doet er alle voordelen van XHTML een beetje mee teniet als je het niet ook als XHTML serveert, en dat kán gewoon niet als je IE niet achter wil stellen. Kiezen voor HTML5 en zelfs voor HTML4 boven XHTML is dus vrij makkelijk.mcdronkz schreef op donderdag 10 juni 2010 @ 23:08:
[...]
Niet dat je er iets mee opschiet, maar omdat XHTML 1.0 een soort van overgangsstandaard is, mag je het volgens de standaard gewoon als text/html aanbieden. Als je de code zelf dan ook nog eens volgens de standaard schrijft, doe je volgens mij niets 'verkeerd'. IE6/7/8 en de rest van de browsers zouden dat moeten begrijpen.
'E's fighting in there!' he stuttered, grabbing the captain's arm.
'All by himself?' said the captain.
'No, with everyone!' shouted Nobby, hopping from one foot to the other.
Uiteindelijk komt het maar op één ding neer in deze discussie: namelijk welke syntax je zelf het makkelijkst vindt om te typen. Voor de rest werkt het allebei even goed en kun je er het zelfde mee.
Dat gedoe over standaarden en correctheid is eigenlijk ook overrated. Uiteindelijk gaat het erom dat je site er in iedere browser goed uit ziet, en naleven van standaarden is een middel om dat te bereiken, geen doel opzich.
Dat gedoe over standaarden en correctheid is eigenlijk ook overrated. Uiteindelijk gaat het erom dat je site er in iedere browser goed uit ziet, en naleven van standaarden is een middel om dat te bereiken, geen doel opzich.
Als je geen XHTML met application/xml en dus ook de xpath en andere xhtml speciale features gebruikt dan heeft het toch totaal geen nut om XHTML te gebruiken ?
In plaats van het leuke Xje ervoor kun je gewoon HTML4 strict pakken en er klaar mee zijn. Dat W3C validator zegt dat de xhtml valid is betekent niet dat je het daarom perfect voor het goede doel gebruikt.
In plaats van het leuke Xje ervoor kun je gewoon HTML4 strict pakken en er klaar mee zijn. Dat W3C validator zegt dat de xhtml valid is betekent niet dat je het daarom perfect voor het goede doel gebruikt.
Ik wil niet nog iemand zijn die dingen op je afvuurt, maar leg eens uit wat voor jou de voordelen van XHTML zijnFuzzillogic schreef op donderdag 10 juni 2010 @ 21:19:
Uit mijn templates komt valid XHTML rollen, zoals ik al zei. Die XHTML is wel zodanig dat HTML-parsers van IE e.d. er geen probleem van maakt. En we serveren het als text/html, om geen gezeik te krijgen van dat stuk antiek. Werkt prima, "dankzij" de tolerantie van de browsers.
Mijn voorkeur zou echter gaan naar valid XHTML1.1 voor nu, en op termijn XHTML5. XHTML1.1 is een no-go helaas, maar XHTML5 zal toch echt wel ondersteund worden, mag ik hopen.
Dat is toch niet zo moeilijk te begrijpen?!
Ace of Base vs Charli XCX - All That She Boom Claps (RMT) | Clean Bandit vs Galantis - I'd Rather Be You (RMT)
You've moved up on my notch-list. You have 1 notch
I have a black belt in Kung Flu.
Daar ben ik ook benieuwd naar, want volgens mij werk je dan meer vanuit een ideologie dan vanuit een praktisch standpunt. XHTML is in theorie leuk, maar (zoals al vaker hier helderder uitgelegd dan ik zou kunnen) in de praktijk gewoon te problematisch.
Eigenaar/brouwer Milky Road Brewery
Ik heb slechts de eerste pagina gelezen.
Maar ik zou TS aanraden om gewoon voor HTML4 te gaan. Het verschilt weinig van XHTML en net zo makkelijk aan te leren.
En inderdaad, zoals vele al hebben gezegd. Focus je voornamelijk op CSS.
CSS is erg belangrijk (ook in de toekomst) voor het opmaken van je website. CSS is bovendien ook erg makkelijk te leren.
Maar ik zou TS aanraden om gewoon voor HTML4 te gaan. Het verschilt weinig van XHTML en net zo makkelijk aan te leren.
En inderdaad, zoals vele al hebben gezegd. Focus je voornamelijk op CSS.
CSS is erg belangrijk (ook in de toekomst) voor het opmaken van je website. CSS is bovendien ook erg makkelijk te leren.
Volgens mij is deze zelfde vraag (en discussie) inmiddels al heel wat keer op en neer gegaan in dit topic.BtM909 schreef op vrijdag 11 juni 2010 @ 14:11:
[...]
Ik wil niet nog iemand zijn die dingen op je afvuurt, maar leg eens uit wat voor jou de voordelen van XHTML zijn
Anoniem: 147126
Een van de 'features' van XHTML boven HTML is in-line SVG/mathml. Straks met HTML5 is het ookmcDavid schreef op vrijdag 11 juni 2010 @ 00:27:
Uiteindelijk komt het maar op één ding neer in deze discussie: namelijk welke syntax je zelf het makkelijkst vindt om te typen. Voor de rest werkt het allebei even goed en kun je er het zelfde mee.
mogelijk maar voor nu heb je daar XHTML voor nodig. (testcase: www.cdejonge.com/stip.xhtml).
Probleem is alleen dat je er pratisch niet superveel aan hebt. Er zijn erg veel mensen die bewust XHTML gebruiken omdat ze denken dat de beste taal is terwijl het in de meeste gevallen net zo goed HTML 4.0 had kunnen zijn.
Klopt, maar dat was vrij algemeen... Sure er zijn toepassingen waar je eerst niet onder XHTML uitkwam, maar ik wilde weten of Fuzzillogic nu al gebruik maakte van specifieke XHTML modules.Bosmonster schreef op vrijdag 11 juni 2010 @ 14:43:
[...]
Volgens mij is deze zelfde vraag (en discussie) inmiddels al heel wat keer op en neer gegaan in dit topic.
Ace of Base vs Charli XCX - All That She Boom Claps (RMT) | Clean Bandit vs Galantis - I'd Rather Be You (RMT)
You've moved up on my notch-list. You have 1 notch
I have a black belt in Kung Flu.
Wegens de huidige batch aan brakke browsers die gewoon slecht met well-formed XML om kunnen gaan heb je er client-side inderdaad erg weinig aan. Zolang browsers te stupide zijn om met iets basics als namespaces om te gaan wordt het nut van XML ernstig ondermijnd.BtM909 schreef op maandag 14 juni 2010 @ 16:44:
[...]
maar ik wilde weten of Fuzzillogic nu al gebruik maakte van specifieke XHTML modules.
Maar toch wil je het perse blijven gebruiken? Je moet toch werken met de middelen die je hebt, en momenteel zijn er betere middelen.
Namespaces in XML zijn ook gewoon een verschrikking (en ook een punt waar X(HT)ML-parsers weer complexer zijn dan HTML-parsersFuzzillogic schreef op maandag 14 juni 2010 @ 19:16:
[...]
Wegens de huidige batch aan brakke browsers die gewoon slecht met well-formed XML om kunnen gaan heb je er client-side inderdaad erg weinig aan. Zolang browsers te stupide zijn om met iets basics als namespaces om te gaan wordt het nut van XML ernstig ondermijnd.
[ Voor 7% gewijzigd door crisp op 15-06-2010 00:07 ]
Intentionally left blank
Ik gebruik XHTML 1.0 Strict om het het, zoals het zegt, strict is. Ik hou van strict, geen gekloot met grijze gebieden over wat wel 'mag' en wat 'niet mag', geen gezeur met tags die misschien wel maar misschien ook niet bruikbaar blijven, maar gewoon goede code of slechte code. Met HTML4 heb je het probleem dat je zelf mag uitzoeken of je upper case, lower case, shorttag, valid SGML wil gebruiken. Als je het niet doet krijg je een of ander raar resultaat, verschillend per browser, en als je het wel doet ook. Moet je weer browser-specifics gaan hacken, schiet je ook niks mee op (het is 2010, geen 1980).
Als je XHTML neemt kan je dat lekker (mits well-formed) manipuleren met script/programmeertaal naar keuze en heb je geen gezeur met code die zich niet aan bekende regels houdt. De regels voor XHTML 1.0 zijn gewoon duidelijker dan voor HTML4, en daar ontkom je niet aan als je low-level moet bouwen voor een library die high-level gebruikt mag worden. Bekende regels kan je mee werken, onbekende niet.
Dan heb je nog het renderer probleem, maar dat heeft met browsers te maken en niets met talen op zich.
Als je met business-ogen naar programmeren kijkt zul je nooit iets te maken hebben met 'goede code' of 'kwaliteit', maar alleen maar bang for the buck. En laat dat nou precies het probleem zijn dat HTML4 renderers ons nu laten zien: allemaal hun eigen manier, en allemaal net-niet-helemaal goed.
Als iedereen de regels naleeft werkt het gewoon, doet iemand dat niet, dan valt die buiten de boot, behalve als die iets als geld, macht of positie heeft. Microsoft had dat ooit met IE, en is daarom alle bekende regels gaan mollen, heeft zelf hier en daar closed-platform 'hacks' bedacht (ActiveX anyone?) en nu zitten we met de gebakken peren.
Als je een 'developer' bent die alleen maar geld wil verdienen: neem jQuery, plak het met HTML4 en CSS1 vast in Dreamweaver en lever je spul op. Klant tevreden, jij een zak met geld.
Als je een *Developer* bent die ook echt dingen ontwikkelt, dan denk je meer in open termen, standaarden en regels die je deelt om samen met andere mensen een geheel te maken zonder daar zelf perse wat mee te moeten verdienen. Misschien dat je uiteindelijk zo veel kennis hebt van die termen, standaarden, regels en richtlijnen dat je daardoor sneller en efficienter kan werken, en dat je daar door meer geld kan verdienen door taken uit te voren met een hogere snelheid dan anderen en daarmee meer werk verzetten in dezelfde tijd waardoor er meer te verdienen is, is alleen maar mooi meegenomen.
typo's e.d. niet gecheckt, fanboy disclaimer: geen OSS evangelist en geen closed source hater, geen anti-massa en geen anti-watdanook. wel pro open web standaarden die nageleefd worden
Als je XHTML neemt kan je dat lekker (mits well-formed) manipuleren met script/programmeertaal naar keuze en heb je geen gezeur met code die zich niet aan bekende regels houdt. De regels voor XHTML 1.0 zijn gewoon duidelijker dan voor HTML4, en daar ontkom je niet aan als je low-level moet bouwen voor een library die high-level gebruikt mag worden. Bekende regels kan je mee werken, onbekende niet.
Dan heb je nog het renderer probleem, maar dat heeft met browsers te maken en niets met talen op zich.
Als je met business-ogen naar programmeren kijkt zul je nooit iets te maken hebben met 'goede code' of 'kwaliteit', maar alleen maar bang for the buck. En laat dat nou precies het probleem zijn dat HTML4 renderers ons nu laten zien: allemaal hun eigen manier, en allemaal net-niet-helemaal goed.
Als iedereen de regels naleeft werkt het gewoon, doet iemand dat niet, dan valt die buiten de boot, behalve als die iets als geld, macht of positie heeft. Microsoft had dat ooit met IE, en is daarom alle bekende regels gaan mollen, heeft zelf hier en daar closed-platform 'hacks' bedacht (ActiveX anyone?) en nu zitten we met de gebakken peren.
Als je een 'developer' bent die alleen maar geld wil verdienen: neem jQuery, plak het met HTML4 en CSS1 vast in Dreamweaver en lever je spul op. Klant tevreden, jij een zak met geld.
Als je een *Developer* bent die ook echt dingen ontwikkelt, dan denk je meer in open termen, standaarden en regels die je deelt om samen met andere mensen een geheel te maken zonder daar zelf perse wat mee te moeten verdienen. Misschien dat je uiteindelijk zo veel kennis hebt van die termen, standaarden, regels en richtlijnen dat je daardoor sneller en efficienter kan werken, en dat je daar door meer geld kan verdienen door taken uit te voren met een hogere snelheid dan anderen en daarmee meer werk verzetten in dezelfde tijd waardoor er meer te verdienen is, is alleen maar mooi meegenomen.
typo's e.d. niet gecheckt, fanboy disclaimer: geen OSS evangelist en geen closed source hater, geen anti-massa en geen anti-watdanook. wel pro open web standaarden die nageleefd worden
Leuk dat je ook even komt kijken, maar lees het topic even door, want 80% van je post (en dat is een milde schatting) is onzin.
edit: ik pas, na nog een keer lezen, mijn milde schatting even aan naar 100%. Geen woord van wat je zegt is waar of heeft enige onderbouwing.
edit: ik pas, na nog een keer lezen, mijn milde schatting even aan naar 100%. Geen woord van wat je zegt is waar of heeft enige onderbouwing.
[ Voor 50% gewijzigd door Bosmonster op 15-06-2010 00:46 ]
met Bosmonster.
Huh? Noem mij één browser die een verschil maakt tussen bijv. <p> en <P> of die onder HTML een probleem maakt van <br />johnkeates schreef op dinsdag 15 juni 2010 @ 00:31:
Ik gebruik XHTML 1.0 Strict om het het, zoals het zegt, strict is. Ik hou van strict, geen gekloot met grijze gebieden over wat wel 'mag' en wat 'niet mag', geen gezeur met tags die misschien wel maar misschien ook niet bruikbaar blijven, maar gewoon goede code of slechte code. Met HTML4 heb je het probleem dat je zelf mag uitzoeken of je upper case, lower case, shorttag, valid SGML wil gebruiken. Als je het niet doet krijg je een of ander raar resultaat, verschillend per browser, en als je het wel doet ook. Moet je weer browser-specifics gaan hacken, schiet je ook niks mee op (het is 2010, geen 1980).
Full-stack webdeveloper in Groningen
Het grootste probleem is dat johnkeates blijkbar niet op de hoogte is van het feit dat ook html4 bestaat in een STRICT variant, of van het bestaan van html5.
Anoniem: 147126
HTML 5 'bestaat' nog niet. Tenminste niet in het wild. De grootste browsers ondersteunen het nog niet.
Na dit hele topic gaan vallen over het woordje "bestaat" wordt wel een beetje vervelend... Je weet best wat ik bedoel. De html5 doctype is backwards compatible. Html5-specifieke features gebruiken is uiteraard een heel ander verhaal vooralsnog en een vrije keuze afhankelijk van je wensen en eisen (bijvoorbeeld of je video op een iPhone of iPad wil laten werken, etc).Anoniem: 147126 schreef op dinsdag 15 juni 2010 @ 09:46:
HTML 5 'bestaat' nog niet. Tenminste niet in het wild. De grootste browsers ondersteunen het nog niet.
[ Voor 12% gewijzigd door Bosmonster op 15-06-2010 09:56 ]
Het heeft geen zin om constant in discussie te gaan over wat nou beter moet zijn.
Als TS het liefst "modern" wilt programmeren in HTML raad ik hem W3Schools.com aan.
Duidelijk, simpel en effectief.
Na afloop zul je zelf ook merken, het maakt geen bal uit hoe je werkt. Test je website gewoon in meerdere browsers in een test omgeving. En doe net als mij: lak hebben aan browsers die niet mee willen gaan in de tijd
Als TS het liefst "modern" wilt programmeren in HTML raad ik hem W3Schools.com aan.
Duidelijk, simpel en effectief.
Na afloop zul je zelf ook merken, het maakt geen bal uit hoe je werkt. Test je website gewoon in meerdere browsers in een test omgeving. En doe net als mij: lak hebben aan browsers die niet mee willen gaan in de tijd
Oei, je hebt wel in de gaten hoe je jezelf moet diskwalificeren in een topic als dit
.
Dit topic is nu bijna 2 jaar oud, zou de TS niet al zijn keuze hebben gemaakt ?Hiroj schreef op vrijdag 11 juni 2010 @ 14:40:
Ik heb slechts de eerste pagina gelezen.
Maar ik zou TS aanraden om gewoon voor HTML4 te gaan. Het verschilt weinig van XHTML en net zo makkelijk aan te leren.
En inderdaad, zoals vele al hebben gezegd. Focus je voornamelijk op CSS.
CSS is erg belangrijk (ook in de toekomst) voor het opmaken van je website. CSS is bovendien ook erg makkelijk te leren.
Het is altijd een goed excuus om nog es te drammen over XHTML neen? ;^)Gotech86 schreef op donderdag 17 juni 2010 @ 17:03:
Dit topic is nu bijna 2 jaar oud, zou de TS niet al zijn keuze hebben gemaakt ?