[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 #13 from Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no> ---
(In reply to Sam Ruby from comment #12)

> The validation results for google.com are a good example of this.  Amongst
> the 23 "errors" I see four clear problems: elements such as <p> and <div>
> being used as children of span, and <nobr> being used as a child of <div>.

 PS: What Google serves validators & text browsers
     differs from what Web browsers get. 
PPS: Both versions contains some of the same, illegal
     features - such as <center>.

> For more than a decade, there has been an attempt to identify
> "presentational" markup and deprecate it in favor of CSS.  As near as I can
> tell, the reasons for this are that pages intended to be accessed by a
> browser are typically part of a site, and factoring the presentation to a
> separate file is good design.  Fair enough.

If we focus on table@border: 

Sam, if you propose to do what the spec has already done in order incorporate
e.g. <u> (namely to add semantics to the feature), then HTML 5.1 has *already*
done that: Per what HTML 5.1 (so far still) says, the table@border is not free
of non-presentational semantics.

For example, per its specified semantics (and despite validator’s lack of
signal a warning), it seems like an author error to use table@border if the
table is *not* a data table. (Thus, the validator could perhaps whine if it saw
<table role="presentation" border="1" >.)

> But browsers aren't the only user agents that consume HTML. 

Even if we limit the HTML5 for Web browsers versus other browsers, then at
least Firefox, Blink and Webkit do send the signal to AT that any table that
displays borders is a data table, see bug 24679 and bug 24678.

If we focus on the wide issue:

When it comes to the wider issue, and thus to other features, such as e.g.
<center>, block elements as child of <span> and - relevant to table@border -
table@rules and table@frame, then I believe I am very much on the side of
making ”presentational” features conforming. However, what would that mean in
practice? Would it mean to seek to narrow down their use cases and define their
semantics as ”for this and that use case”? The alternative of permitting them
without any usage rules, seems out of question to me.

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

Received on Tuesday, 25 February 2014 16:35:58 UTC