3 ms·

Die XHTML Die. No one wants you, no one loves you. Sorry... breathe >> "Nothing that represents industry consensus about how the structure of web content shoul

by axod 17y ago

Die XHTML Die. No one wants you, no one loves you. Sorry... breathe >> "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 :/

aw3c2 17y ago
I do love XHTML. When each and every element is specifically "closed" the code is much easier to grasp for me.
- jqm0 17y ago
  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.
  - axod 17y ago
    >> "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
    - ilyak 17y ago
      The W3C DOM API is a nightmare. Every of them.
    - daleharvey 17y ago
      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
trezor 17y ago
>> >> "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.
- natrius 17y ago
  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.
hnal943 17y ago
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).
makmanalp 17y ago
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.

by axod 17y ago

aw3c2 17y ago

I do love XHTML. When each and every element is specifically "closed" the code is much easier to grasp for me.

jqm0 17y ago
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.
- axod 17y ago
  >> "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
  - ilyak 17y ago
    The W3C DOM API is a nightmare. Every of them.
  - daleharvey 17y ago
    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

trezor 17y ago

>> >> "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.

natrius 17y ago
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.

hnal943 17y ago

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

makmanalp 17y ago

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.