On HTML 5 Drag And Drop | Hacker News Reader

On HTML 5 Drag And Drop

alertdebugging.com

32 pointsboucher4 comments

Is it just me, or has HTML5 strayed away from defining how content should be interpreted and rendered in favor of defining how the resulting page should interact with the system it's running on?

Even the video element is made awkward by codec issues, thus depending on the browser implementer or underlying platform to function properly.

Before the sexy new "HTML5" moniker, that specification was known as "Web Apps 1.0" and aimed to specify extensions to HTML that would make creating richer, desktop-like cross-browser applications possible (largely by reverse-engineering IE's implementation). It was only after Hixie realised how woefully under-specified the rest of HTML was that the spec shifted to the more useful goal of formally specifying all current browser behaviour.

So, in a sense, you have it exactly backwards. :)

Why is 'formally specifying current browser behavior' a useful goal? Do you perhaps mean 'formally specifying how the browser interacts with the system'? Why would anyone even remotely think this should fall under the auspices of the HTML specification.

Back in the early days of HTML standards, there were comparatively few browsers, and comparatively few HTML documents for them to read, and the HTML working group seemed to feel it was reasonable to release updated standards that specified what browsers should do with conforming markup, and assumed that non-conforming markup would be rare or wildly broken enough that nobody would depend on any particular behaviour.

In the modern age, we know that broken and non-conforming markup is the vast majority of content on the Web, and not only does this content depend on certain parsing behaviours, but those parsing behaviours are fairly reliably implemented across browsers. Of course, that interoperability is far from perfect, and took vast effort to achieve (legend has it that in early versions of IE, Microsoft reverse-engineered and re-implemented parsing bugs Netscape didn't even know they had, and later Mozilla had to do a lot of the same work on IE's behaviour). This is a good part of the reason that there's only four reasonably useful HTML rendering engines on a planet of six billion people.

One of the goals of HTML5 is to reverse-engineer and document what it is that browsers actually do to turn tag-soup into an internally consistent DOM tree, in the hope that future browser vendors won't have to reverse-engineer the wheel yet again. For example, ".innerHTML" is a property on DOM elements that allows script to quickly change the content of that element. It's widely used on websites, and supported in all major HTML engines, so you'd think it'd be pretty easy to get right and interoperable, right? Wrong:

    http://ln.hixie.ch/?start=1158969783&count=1

How about the property "document.title", which should just reflect the content of the title element?

    http://ln.hixie.ch/?start=1161121410&count=1

In short, yes - I think formally specifying browser behaviour in the face of the existing web is a truly noble and useful goal, especially if it helps increase competition in the field of useful HTML renderers, and it falls under the auspices of the HTML specification because what other specification will tell a browser vendor how to understand and display the existing corpus of HTML documents?

Reply on news.ycombinator.com