

On HTML 5 Drag And Drop - boucher
http://www.alertdebugging.com/2009/08/16/on-html-5-drag-and-drop/

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

~~~
thristian
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. :)

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

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

