quote:
Fuzzillogic schreef op donderdag 19 april 2007 @ 17:33:
[...]
We gooien niks weg. Maar assembler interesseert mij ook bar weinig. Of dat AWT van Java <v1.2 nogal matig was. Je hoeft je daar niet in te verdiepen, tenzij je dat wilt. Er is gewoon iets nieuws, iets beters, dat alles wat ervoor was vervangt. Hetzelfde geldt voor de opvolger van HTML. Als je dat als je basis neemt, wat zou het jou dan aan je achterste roesten hoe men vroeger werkte?
Als de opvolger van HTML (zo goed mogelijk) backwards-compatible is met oude content dan zal ik HTML4 graag vergeten ja
quote:
[...]
Met mijn voorbeeld van <p><table /></p> zal de browser in veel gevallen niet eens merken dat het fout is. Maar als er <p><table colspan=2></p> staat, dan begint een XML-parser wel te zeiken. Natuurlijk kun je die 'XML'-parser dan zo verbouwen dat-ie dit ook nog wel snapt, bijv. door te veronderstellen dat elk element automatisch is afgesloten als zijn parent wordt afgesloten. Maar als auteur moet je daar gewoon niet vanuit gaan. Het levert ambiguiteiten op.
Ik bedoelde dit:
HTML:
1
| <p><table><tr><td>foo</td></tr></table></p>
|
Invalid in zowel HTML4 (niet in HTML5 though
) als XHTML (maar wel well-formed), maar het levert de volgende DOM-tree op:
in HTML:
code:
1
2
3
4
5
6
| P
TABLE
TBODY
TR
TD
#text |
in XHTML:
code:
get my point?
quote:
[...]
Bingo! Precies dit soort "hm hoe zat het ook alweer? <p>, moest je die afsluiten? En <meta>?" Het is gewoon HANDIG als er eenduidige, simpele regels zijn. Zonder dat ik het nakijk durf ik wel te zeggen dat die puntkomma gewoon verplicht is in XML, en met een goede reden dus.
Die is inderdaad verplicht in XML, en feit is dat geen enkele browser de puntkomma als optioneel ondersteund. HTML5 maakt de puntkomma derhalve ook verplicht.
Punt met optional tags is dat je dat niet kan uitbannen omdat oude content er gebruik van maakt en huidige browsers daar nu ook support voor bieden. Ik denk echter niet dat je dergelijke minimalisaties als good practice moet beschouwen en ik vind ook dat de specificatie zou moeten aanraden om toch zoveel mogelijk "well-formed" te werken al is het alleen maar omdat fouten dan sneller opvallen (in het <p><table> verhaal was het voorbeeld valid HTML geweest als ik de </p> had weggelaten, maar wellicht had ik toch een andere DOM-tree voor ogen als ik niet had geweten dat <table> niet in <p> mag).
quote:
[...]
Er zijn nu ook bergen scripts uit 19nul die met document.all werken en toch nog rondzwerven. Dus dan zie je ook hier dat het handig zou zijn geweest als er destijds al één systeem zou zijn geweest. Maar HTML5 biedt de keuze tussen gecastreerde SGML en XML-varianten. Leren ze nooit van de fouten?
Je zou XML ook als een rigide gecastreerd SGML-derivaat kunnen zien natuurlijk
HTML had van oorsprong misschien iets minder los opgezet moeten worden en zonder allerlei SGML-features als SHORTTAG die toch nooit geimplementeerd zijn. Optional tags hebben natuurlijk hun oorsprong vanuit het feit dat storage en bandwidth duur was in die tijd.
Ja, er is wel geleerd van die fouten, dus bepaalde features worden geschrapt. Enkel de features die wel supported waren en ook in het wild gebruikt zijn kan je niet zomaar schrappen in een opmaaktaal die backwards-compatible wenst te zijn.
document.all is een slecht voorbeeld in deze omdat je dan praat over propriety technologie.
quote:
[...]
Wanneer is een error een error? Een error tegen de specificatie hoeft de parser niet perse op te vallen. Is het dan een error? Zie ook stukje hierboven.
Ja, dat zijn allemaal errors, maar verschillende typen: parse-errors (syntax) vs conformance-errors. En inderdaad, de parser heeft niets te maken met de conformance rules, daar is een seperate conformance-checker voor nodig.
quote:
[...]
Nou ok, dan zijn we het erover eens dat er 1 markup-taal moet komen. Maar for the sake of uniformity, doe dat XML, en flikker alle legacy uit de standaard.
Ok, let's have it your way: we doen een compleet nieuwe markup-taal gebaseerd op XML
1) uiteraard kan dat niet een taal zijn die deels backwards-compatible is met HTML/XHTML1; mensen gaan het dan toch weer als tagsoup versturen omdat het dan meestal toch wel "werkt" (zie XHTML1) en het zou veels te verwarrend zijn.
2) om kans van slagen te hebben moet alles erop voorbereid zijn tegen de tijd dat het geintroduceerd wordt. Laten we maar aannemen dat het een absolute killer-technologie is en iedereen er op zit te wachten, early adoptie is belangrijk en dus moeten authoring-tools, CMS-en, content-providers, legacy systemen, serverside programmeertalen en niet te vergeten browsers er helemaal klaar voor zijn; we krijgen immers een compleet nieuw soort internet!
3) oh wacht, we zitten nog met legacy content; wat doen we daarmee? Och, dan zorgen we toch dat alle voornoemde systemen ook nog kunnen omgaan met die oude meuk. Maar voor hoelang?
4) Beb snapt er niets meer van, maar da's pech voor Beb
quote:
[...]
Leg die voorkeur dan vast in de standaard. Dan nog lijkt het mij een slecht idee.
Wat is een slecht idee? De aanname dat een client waarschijnlijk eerder text/html kan verwerken dan application/xhtml+xml is gezien de praktijk toch geen verkeerde lijkt me?
quote:
[...]
Ligt eraan. JSON is leuk en aardig, maar je zult het niet standaard aantreffen in de browsers. En als je een server hebt die de data in XML-vorm aanbiedt, dan heb je weer een conversiestap nodig. XSL zit tegenwoordig vrij standaard in browsers. Ach het heeft zijn voors en tegens.
JSON-support is voorgesteld om standaard opgenomen te worden in javascript2 en veel serverside talen ondersteunen het al native. XSL support in browsers is maar matig (nou ja, in ieder geval in IE omdat IE geen onderscheid kan maken tussen XHTML en XML en op z'n plaat gaat als je bijvoorbeeld named entities gebruikt die in XHTML volledig valid zijn). Daarnaast is het aantal systemen dat niet native met XML werkt behoorlijk groter dan het aantal systemen dat wel een volledige XML-backend heeft.
![[RSS]](http://tweakimg.net/g/if/v2/icons/rss_small.png){kind=icon}
Door: 
)
Door: 
