Hacker News new | past | comments | ask | show | jobs | submit login
HTML 5 is another guess at the future (bigcontrarian.com)
29 points by maryrosecook on Sept 7, 2009 | hide | past | favorite | 9 comments



I understand his argument that what we've got works now, so who cares, but it doesn't work for _everyone_. I'm sure people with screen readers (it's the header because it's darker and that's the nav bar because it's got that box around it, duh!) would really appreciate some standard way to know what's what on the page.


See Douglas Crockford's suggestion for HTML5 at http://www.crockford.com/html/


Well, all those points were discussed and there are sound reasons why they are as they are in HTML5

Versioning — it just does not make any sense. Browsers render web content to their abilities, not by spec. Some my not support parts of HTML4 but support other parts from HTML five.

No doctype — creators of HTML5 would be glad to get rid of it, alas, it is required to force browsers to use standards compliant rendering mode. Without doctype they fall back to quirks mode, which is bad.

CSS — unified rendering would be nice, but that's not the subject of HTML spec. And reset stylesheets are just plain stupid.

Self closing <script> — historical reasons… :)

Custom tags — what? You can invent any tags you like and modern browsers will allow you to style them. If you want custom tags, you don't need a spec. The point of the spec to define agreement on what which elements means.

Custom attributes: HTML5 has that in the form of data-* attributes and elements get element.dataset accessor.


That's actually similar to what I was thinking. Making HTML5 support generic tags and attributes that could be defined as first-class elements would completely eliminate the need to create a huge pile of new tags. This would allow for much more innovation while not limiting the design to some arbitrary set of new elements. Instead of thinking of HTML as a "document format", it should be thought of as a display interface with a low-level protocol for interaction.


so you're going to implement <video> in javascript?


No, but browser implementors could implement <video> and define it within the high-level HTML markup language. There is no need for the HTML spec to define elements that can be determined to be necessary by the market. If it provides a framework for creating new elements, the market can come up with the necessary elements. Obviously, every page would not have to define every element in existence before being viewable, there would develop -- organically -- a stock of pre-existing elements in browsers.


The market does a really shitty job at interoperability, one of the main goals of the internet.


You are getting down voted because browser vendors inventing their own tags based on their market research didn't work out so well last time, and the last thing we need is for that to even be suggested again. http://www.webreference.com/dev/html4nsie/prop.html is a list of the kind of crap they came up with. Marquee? Blink! Confusion over Embed and Object, which still exists somewhat to this day.


Wow, I must've offended the designers of HTML5!




Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: