On 17/12/2011 03:10, Adam D. Ruppe wrote:
On Friday, 16 December 2011 at 23:41:19 UTC, Stewart Gordon wrote:
Yes:
I'll agree that some of the validator's things help
with that, but not all of it.
If you write <a href="#"><div>block in inline</div></a>,
the validator will reject it, but it works... and that's
a useful thing when doing drag+drop applications (since
older IE doesn't let you drag other elements).
What built-in support does HTML/JS/CSS have for dragging of elements? I always understood
that it had to be explicitly implemented in JS in terms of
onmousedown/onmousemove/onmouseup or something like that, and therefore cannot in itself
be something that some browsers support and others don't.
Moreover, dummy hrefs are an abomination. Not just compatibility when JS is disabled -
this link is also the one followed when you open a link in a new window/tab. This
regularly bites me.
<snip>
Anyway, though, the specific doctype still isn't terribly
important, since, in practice, tools tend to ignore it
anyway. Browsers see it's presence as an on/off switch
with standards compliance mode vs quirks mode; declaring
the wrong one doesn't break anything. (Indeed, HTML5
has agreed to use the common, previously wrong, shorthand
of <!DOCTYPE html> as the new standard!)
Strange. I don't recall ever seeing <!DOCTYPE html> before HTML5 came along.
But I am made to wonder why. What will happen when HTML6 comes out? Or have they decided
that validators are just going to update themselves to the new standard rather than
keeping separate HTML5/HTML6 DTDs (or whatever the HTML5+ equivalent of a DTD is)?
PNG's reason for not including a version number in the file is to avoid the scenario where
a program knows only of PNG up to version 1.2, and rejects a file as being in PNG 1.3 even
though all the critical chunks conform to the PNG 1.0 spec. See
http://www.libpng.org/pub/png/spec/1.2/PNG-Rationale.html#R.Chunk-naming-conventions
But I have trouble believing anybody would make a web browser that rejects HTML files as
being in too new a version of HTML.
Stuff like improperly closed tags or bad entity
encoding can break, but that's pretty well independent
of doctype validation. That's simply a matter of the
document being well-formed.
No, because in order to determine whether it's well-formed, one must know whether it's
meant to be in SGML-based HTML, HTML5 or XHTML.
<snip>
Are custom attributes distinguished from standard attributes in some way, in
order to
keep attributes invented by different browser manufacturers from clashing with
each
other and with attributes that become part of a later HTML standard?
They are in html5 - the data- prefix is allowed and reserved
for the user. In older versions of the html standard, there
weren't allowed at all, whether prefixed or not. (They did
work in practice, though.)
<snip>
So it's something that web authors can use to store custom data in an element for
scripting purposes, but browsers aren't supposed to have any built-in handling of them?
Stewart.
