[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 #15 from Andrea Rendine <master.skywalker.88@gmail.com> ---
>>>
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24705#c3
--- Revert deletion of table@border in commit
5f540174f5fde713e45b72c81e530fb5d964d2df ---

Status: Accepted
Change Description: Corrected a partial accidental deletion of the border
definition caused by some recent editorial spec refactoring [1], and
cherry-picked it into the CR branch.

    master:
https://github.com/w3c/html/commit/ba951a06fd8eacad106afb24de35098d1a25b6c3
    CR:
https://github.com/w3c/html/commit/ef86132cb20d5826db9708763bc32d95dc53785a

Rationale: 
Even if the border attribute becomes obsolete/invalid for 5.1 (per Bug 24591),
this change at least keeps the spec internally consistent for the time being,
and honors the current WG decision for 5.0.
<<<

As it is, this bug is formally invalid. What it suggests does not make sense,
as in HTML5 <table@border> WAS conforming and IS considered conforming again.
It means that authors, i.e. those who implement and therefore test features in
the REAL LIFE, decided that <table@border> is conforming NOT because of
theoretical purity, but because it is *useful*(see what has been said as of
now).
Problem: what has been achieved is only the first part of the task. Up until
October 12th, 2013, @border was conforming according to W3 HTML5.1 WD too. I
don't know when it dropped out of the permitted attributes in the Working
Draft, but I have some hints:
 - It is still conforming for the latest Nightly Build
 - The prose in the Working Draft is exactly the same of the one for WHATWG
HTML5 CR for <table>, so I suppose it was meant with the idea that @border were
conforming. It must have been ""inadvertently"" changed together with HTML5, so
after mid January.

@border has nothing to prove. Ever. It's exactly like other old and new
elements and attributes that, though born as presentational, now fulfill a new
and more logical purpose, that of readability. The fact is, even other
elements/attributes from HTML4.01 and from the practice could have a purpose,
but it has been decided that their scope wasn't that important to deserve a
mention in the markup and could therefore be delegated to the presentational
(i.e. CSS) layer. As Mr Silli said once, it was a matter of compromise.
<table@border> is in the compromise. Whoever wants it to be definitely deleted
must not talk about abstract points like "conflict with other points of the
spec", "origin as presentational feature and so on".
It's their turn now to demonstrate both:
 - that @border with its current syntax and meaning is not so widely
implemented, and so that its obsolescence does not damage many authors.
 - that it doesn't fulfill any other purpose but presentation, in particular
that it is not an aid to readability of ANY table (with particular regard to
data tables and complex tables).
 - that all user agents/web clients can implement the VERY SAME level of
readability/usability achieved by @border solely thanks to the CSS layer.
 - that no user agents DO, DID, PLAN TO or MAY use this feature in their
internal heuristics in order to tell away data tables and non-data tables
 - that the addition of @border is therefore NOT ONLY unnecessary but also
harmful, because it diminishes interoperability/maintainability of Web pages.
If anybody can demonstrate ALL these things TOGETHER, then they can raise a
formal question to abolish it. As of now, @border is already child of a
repeated positive choice and has nothing more to prove.

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

Received on Tuesday, 25 February 2014 17:34:20 UTC