[Bug 24591] Make W3C HTML5 spec clearly and correctly state that table@border is obsolete & invalid (nonconforming)

https://www.w3.org/Bugs/Public/show_bug.cgi?id=24591

--- Comment #21 from Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no> ---
(In reply to Sam Ruby from comment #20)
> (In reply to Leif Halvard Silli from comment #19)

> Fair enough.

(I made an error: <p> in quirks only accepts <table> - and not any block
element. Could be I made other errors too.)

Will study what Google.com uses div-inside-span for. Probably for browsers
without enough CSS support.

Another Google example of ”wrong” use is how Google Docs exports documents as
quirks-mode HTML pages (without DOCTYPE) and with both cellpadding="0",
cellspacing="0", and probably other things.

>  While that changes my specific recommendation, that actually
> strengthens my overall recommendation, namely that if people are en-mass
> ignoring restrictions in the specification, but are doing so in ways that
> are effective and interoperable, then the restrictions should be lifted.  To
> do otherwise reduces the utility of both the specification and any
> validators based on the specification.
> 
> See also:  http://www.w3.org/TR/html-design-principles/ (specifically:
> Support Existing Content, Pave the Cowpaths, and Priority of Constituencies).

Some would probably place Google in the category of ”über authors” and say that
authors should not be bothered with all those options that the “über authors”
can identify. 

May be, as a first step, the spec could start with, somehow, acknowledging the
different uses of HTML - that there exists cases where authors would like to
solve things different from how things are usually solved in a typical Web page
that is part of a typical Web site.

The problem with this could be that the spec, somehow, can be seen as
”versioned”, again.

The alternative to that approach (and one would perhaps have to do this,
anyhow), would be to try to go the route of ”semantisizing” those features that
one like to see as conforming. Thus, to define when and how they can be used.
Again, this is the approach the spec has followed, till now, I think. May be
there should the be a project for the whole thing, a kind of ”papa bug” for the
project. And the name of the project should probably be something like ”project
to allow as many obsolete and illegal features as possible, provided they are
actually used and make sense, at least in some contexts”. For such a papa
project, I already have some babies ...

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Tuesday, 25 February 2014 23:15:24 UTC