

HTML 4.2 - marketer
http://blog.360.yahoo.com/blog-TBPekxc1dLNy5DOloPfzVvFIVOWMB0li?p=978

======
sh1mmer
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.

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

~~~
sam_in_nyc
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.

~~~
mcav
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>

~~~
sam_in_nyc
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?

~~~
olavk
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.

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

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

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

~~~
kwamenum86
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.

