HTML 4.2 | Hacker News Reader

HTML 4.2

blog.360.yahoo.com

21 pointsmarketer11 comments

This is actually the problem with a lot of the W3C standards (I should know I've worked on 3).

Often times the working groups identify a problem that needs to be solved, but there isn't a solution. The web moves so fast there is this great desire to bring things together as soon as new trend emerges. However, the point of standards is for a lot of experimentation to have happened so that some consensus about what works and what doesn't can happen.

Doug is absolutely right, standards and research don't mix.

I believe this is one of the reasons one of the standards I worked on (WCAG 2) took around 8 years to create. Starting WCAG 2 hot on the heels of WCAG 1 meant that the industry hadn't figured out how to do accessibility, for whatever socio-political reasons. As such the 8 years was more the time it took for patterns to emerge as to good practice than it was the working group's inability to understand the problem, or apply appropriate definitions and constraints.

HTML5 seems different than ECMAScript 4 in that it proposes substantial, widely beneficial, updates to HTML that would do the web itself a lot of good.

Standardized, yet open, enhancements for the web: video, audio, sockets, cross-window communication, and more. Sure, it's ambitious, but it stands to push the web forward in noticeable ways.

If we take IE out of the equation, a lot of HTML5 features have already hit Safari, Firefox, (opera?). The primary drag on HTML5 is IE, but even Microsoft has embraced HTML5 to some extent (it describes HTML5 features in its documentation for IE7/8).

Since you seem to know a lot about HTML5, and I don't have the inclination to browse through and ingest it all, maybe you could answer this: will there be support for defining custom attributes, and will these attributes allowed be JSON objects?

I've often had the need for something like <div params="{..json..}"></div>. Up until now you're left with the choice of on pageload attaching the JSON to some arbitrary property of the DOM object, or reading the attribute and eval'ing it.

"onxyz" attributes are interpreted automatically as JS, albeit they are automatically cast into a function. I'm hoping there's a similar way to define custom attributes and their types.

HTML5 allows "data" attributes: any attribute starting with "data-" can be used for that purpose. Those fields are accessible via node.getAttribute() and also node.dataset. But it does not automatically parse JSON.

More info:

http://ejohn.org/blog/html-5-data-attributes/

http://ajaxian.com/archives/embed-your-data-in-html-5

That doesn't seem like much of an improvement over what already works, other than the namespacing. Is there a reason they chose the attribute "data-whatever" to map to "dataset.whatever" instead of just "data.whatever"? I can create my own attributes, such as _data_id and _data_name, and it's accessible through getAttribute(). It just won't validate, which doesn't bother me too much, since it makes things very convenient.

Alas, I'm not here to gripe to you. Is there a way to suggest support for embedding data other than text in attributes? In your experience, are "they" open to new ideas? Is it a time consuming process?

The "data" prefix is indeed for the sake of namespacing. This is actually quite useful since you can validate and e.g. find typos in ordinary attributes while still having your custom data attributes.

If you have some good ideas for HTML5, you just post a well-argued message on the open mailing list (http://www.whatwg.org/mailing-list), and it will be considered.

It is strange he proposes a HTML4.2 without any hint of what it actually will contain, except fluffy words like "simplify", "streamline" and so on. This is actually what XHTML and XHTML2 attempted - by means of the draconian error handling all parsing ambiguities would disappear, making parsing much simpler. By eliminating all legacy presentational HTML, the vocabulary would get much simpler and so on.

The problem with XHTML was that is was too simple and elegant, and didn't consider the actual state of the web: There are already billions of malformed documents, and they dont go away just because you declare them illegal.

HTML5 on the other hand accepts and embraces the actuale state of the web. By declaring rules for how to parse malformed HTML, it attempts to solve the major source of interoperability problems between browsers. But this also requires a much more complex spec.

I don't like peddling conspiracy theories, but I have to mention that Crockfords attack at ECMAScript 4 only succeeded because of backing by Microsoft. Microsoft supports Crockfords notion that JavaScript absolutely does not need high-level features like classes, type annotations, packages and so on - we are fine with a minimal language, thank you! While at the same time focusing significant ressources to support C# (a much larger language than ES4) as a client side language through Silverlight.

Crockford worked in secret with Microsoft on ECMAScript 3.1 before it went public, and I suspect this announcement means that they are working on a HTML4.2 proposal. And I am pretty sure this HTML4.2 will not cointain features like canvas, audio and video, since these features is a selling point of Silverlight relative to HTML.

Not everything is a conspiracy. They were right to nix ES4.

Javascript has prototype based inheritance: adding classes would only further disguise this, confusing people more. And javascript is a dynamic language, this isn't something that needs to be fixed any more than Ruby or Python do.

Javascript is basically a cross between scheme and self, it's actually a great language. Why turn it into C#? Especially when C# and a billion languages like it already exist.

Perhaps what we need is for browser developers to actually use the language attribute on the script element so you can program in the language you want rather than trying to change javascript into that language.

(BTW the more believable conspiracy theory is that all these suggestions add up to ES4 looking a lot like ActionScript and that ES4 was an attempt by Adobe to do an end run round Microsoft.)

Now we are getting somewhere. But, why do we even need a HTML 4.2 or a CSS3? Bundling these standards up into giant documents doesn't do anybody any good. First, we should try writing a separate document for each new feature, standardizing each one individually. Then, browsers will have HTML 4.01 + CSS 2.1 + <canvas> + <video> + CSS opacity + CSS 2009 Selectors + Query Selectors + Cross-Domain XHR.

Seems much more complicated than even the current setup where browser either do not implement all features or implement them inconsistently. Browser-building companies interact with the standards a bit differently than the rest of us (I am assuming you do not work on IE, Firefox, Opera, Safari, Chrome etc.) Separating features into separate documents likely does not affect their process much.

I imagine that if you're willing to write and maintain a spec, and build a community around it, for one of these bits (think a full time job for one or two people, at least), the HTML5 guys would be totally happy to sign the responsibility over.

Reply on news.ycombinator.com