W3C, you ignorant slut(blog.halindrome.com)
blog.halindrome.com
W3C, you ignorant slut
http://blog.halindrome.com/2009/07/w3c-you-ignorant-slut.html
16 comments
When the web was young, it was fine if people missed a tag somewhere, or mis-nested tags, or did other mistakes. The browsers were forgiving. Moreover, the standard was forgiving. This is useful when you want mass adoption. It makes early adopters' lives easy and increases spread.
It's been a long while since those times. We have validators, editors that match tags, tools that write markup for you and other fancy gadgets, and people whose professions contain a good amount of markup-writing. You know what? It's not acceptable to not conform anymore. Too much effort is spent on trying to make meaning out of peoples' broken markup, rendering pages that shouldn't normally be rendered. Even the major browser vendors can't decide how standards compliant markup should be rendered, only recently has there been visible improvement. It's not that the vendors are dumb or unable, it's that their job is difficult because of the giant kludge they have to work with.
XML is "elegant" compared to HTML in the sense that it's uniform, it's consistent, kinda like lisp syntax. Parsing it is easy. This is even more important with all the talk of the "semantic web". Notice how difficult it is to extract meaning out of natural language, and how natural language has non-uniform (or very complicated) grammar. Now notice how simple, in comparison, it is to extract meaning out of something with a small and simple grammar, such as a small programming language. This is what we want.
The point is, once we fix the infrastructure, we can add new functionality as needed. XHTML might not have a canvas tag and HTML may, but what's to happen if in the future we decide that we need some other extension? We revise the whole standard? Ridiculous.
It's been a long while since those times. We have validators, editors that match tags, tools that write markup for you and other fancy gadgets, and people whose professions contain a good amount of markup-writing. You know what? It's not acceptable to not conform anymore. Too much effort is spent on trying to make meaning out of peoples' broken markup, rendering pages that shouldn't normally be rendered. Even the major browser vendors can't decide how standards compliant markup should be rendered, only recently has there been visible improvement. It's not that the vendors are dumb or unable, it's that their job is difficult because of the giant kludge they have to work with.
XML is "elegant" compared to HTML in the sense that it's uniform, it's consistent, kinda like lisp syntax. Parsing it is easy. This is even more important with all the talk of the "semantic web". Notice how difficult it is to extract meaning out of natural language, and how natural language has non-uniform (or very complicated) grammar. Now notice how simple, in comparison, it is to extract meaning out of something with a small and simple grammar, such as a small programming language. This is what we want.
The point is, once we fix the infrastructure, we can add new functionality as needed. XHTML might not have a canvas tag and HTML may, but what's to happen if in the future we decide that we need some other extension? We revise the whole standard? Ridiculous.
I do love XHTML. When each and every element is specifically "closed" the code is much easier to grasp for me.
Me too. Also, knowing that the DOM will be structured as I intended it to be is a good thing...especially when traversing/manipulating with JS. There is an HTML5 parser that will tidy up those omissions but I doubt that will be implemented consistently across all browsers.
Leaving the browser to tidy up after you is IMHO bad practice.
Leaving the browser to tidy up after you is IMHO bad practice.
>> "especially when traversing/manipulating with JS"
The DOM is great. It's a pretty well designed API, and makes things easy. HTML/XHTML are just crappy ugly serializations of it. It'd be nice if there were some alternative serialization schemes supported by browsers more like JSON.
If you're manipulating the DOM with js, then you can't far wrong. You can't omit closing tags. You can't have invalid nesting. You can't typo closing tags. etc
The DOM is great. It's a pretty well designed API, and makes things easy. HTML/XHTML are just crappy ugly serializations of it. It'd be nice if there were some alternative serialization schemes supported by browsers more like JSON.
If you're manipulating the DOM with js, then you can't far wrong. You can't omit closing tags. You can't have invalid nesting. You can't typo closing tags. etc
the dom is a terribly designed api, it has to be one of the worst apis I have ever used
to change a nodeName, you have to clone its children and replicate its attributes.
to delete on object,
object.parentNode.removeChild(object);
to insert after an element
object.parentNode.insertBefore(newObject, object.nextSibling);
and that only works by auto'magic' nonsense.
things like jquery would still be around if the browser all implemented everything nicely because the dom api is just terrible
to change a nodeName, you have to clone its children and replicate its attributes.
to delete on object,
object.parentNode.removeChild(object);
to insert after an element
object.parentNode.insertBefore(newObject, object.nextSibling);
and that only works by auto'magic' nonsense.
things like jquery would still be around if the browser all implemented everything nicely because the dom api is just terrible
The W3C DOM API is a nightmare.
Every of them.
Every of them.
If all you care about is making websites that people using current browsers can see, there's already a rich, stable technology for that. It's called Flash. An extensible, semantic web markup standard is needed if you want to create content that can be consumed in all sorts of ways (e.g. text-only, search bots, future browser-like technologies, etc).
>> >> "so he could form the World Wide Web Foundation (ironically, an organization that can't put up a web page that is valid!)."
>> Case in point. If it shows up nicely in real world browsers, who cares.
I'm sure all the browser-makers who has to tidy up all that shit markup, always, appreciates how much you take their massive effort for granted.
>> Case in point. If it shows up nicely in real world browsers, who cares.
I'm sure all the browser-makers who has to tidy up all that shit markup, always, appreciates how much you take their massive effort for granted.
It's the browser vendors' fault that shit markup renders properly. Blame the first one that let it happen, not the person writing the HTML.
I truly believe that we would be years ahead in terms of web technology if the browsers had just said from the start "yeh this code doesnt make sense, Im not fixing it"
imagine we served websites with valid xml, every language around would have a wealth of tools available available that they already use, the term "screenscraper" wouldnt even be mentioned on the web because reading an xml file is such a trivial task, a whole bunch of apis would actually just be replaced by the actual websites they are duplicating data from
that has to be worth having to close your tags
screw dtd's and all the other bloat around xml, I just want an easy to parse, unambigous data format to transfer stuff.
imagine we served websites with valid xml, every language around would have a wealth of tools available available that they already use, the term "screenscraper" wouldnt even be mentioned on the web because reading an xml file is such a trivial task, a whole bunch of apis would actually just be replaced by the actual websites they are duplicating data from
that has to be worth having to close your tags
screw dtd's and all the other bloat around xml, I just want an easy to parse, unambigous data format to transfer stuff.
My dislike of XML is pretty simple: it forces you to be more verbose. That is bad for the web.
For instance <tag att1=val att2> is valid HTML. The XML equivalent is <tag att1="val" att2="att2" />. Why is this a good idea, again?
For instance <tag att1=val att2> is valid HTML. The XML equivalent is <tag att1="val" att2="att2" />. Why is this a good idea, again?
If there's any real complexity in your site you won't write HTML by hand anyway, so I don't care if the "object code" is a bit more verbose if it means it's more computer-friendly.
Because the second can more easily be parsed 100% correctly and consistently, while the first one will not allow you to fully understand a document-tree without lots of wile and complex forward and backward document scanning, and you may still be wrong.
This especially true for bigger and deeper document-trees.
This especially true for bigger and deeper document-trees.
I'm sort of gutted that they're leaving XHTML behind, if only because we were told it was the future of standards compliant web design at the start of the standards revolution. I changed my entire way of thinking for that movement. It's annoying that I have to go back (at least, partially!).
Does he call for further disconnection from reality?
>> "Nothing that represents industry consensus about how the structure of web content should mature so that it is accessible to the handicapped. Nothing that makes it easier to markup content with its semantics in an extensible way."
Yeah just a lot of "useful" "practical" stuff like Audio, Video tags, postMessage, web workers, canvas, etc etc
HTML5 is about improving the REAL world wide web. Not the imaginary 'wouldn't if be nice if we started again' web. I think they've done a great job with the features they've added.
XHTML failed because it had a small subset of the functionality available with HTML, and gave no real world advantages. It made people obsess over validation rather than what actually works in real world browsers.
>> "so he could form the World Wide Web Foundation (ironically, an organization that can't put up a web page that is valid!)."
Case in point. If it shows up nicely in real world browsers, who cares.
>> "I have great passion for the X in XHTML - extensibility."
I am the complete opposite. I believe you should use a solution tailored to the problem. Not some multipurpose open ended general purpose 'can do anything' solution. And guess what... Extensibility is simple X* just makes it look really hard.
XML, XHTML, XMPP - they are all ridiculously over engineered overly complex things. They're the opposite of an 'elegant' solution.
>> "I assume those 4 out of your ~400 members were saying "hey, we don't want to implement XML-based semantic web. It's haaaaaard (insert whine here)"."
No, I'd expect they were thinking to themselevs "Make something people want". Why the hell would anyone using a browser care if it's XML-based semantic over complexity. They were more likely thinking about adding features PEOPLE WANT. Like audio/video/canvas tags etc Why would they do a ton of work to support something that has less functionality :/