New homepage design of d-p-l.org is now live. <eom>

Sat Dec 17 05:09:35 PST 2011

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.