This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 24705 - Revert deletion of table@border in commit 5f540174f5fde713e45b72c81e530fb5d964d2df
Summary: Revert deletion of table@border in commit 5f540174f5fde713e45b72c81e530fb5d96...
Status: CLOSED FIXED
Alias: None
Product: HTML WG
Classification: Unclassified
Component: HTML5 spec (show other bugs)
Version: unspecified
Hardware: PC All
: P2 normal
Target Milestone: ---
Assignee: This bug has no owner yet - up for the taking
QA Contact: HTML WG Bugzilla archive list
URL: https://github.com/w3c/html/commit/5f...
Whiteboard:
Keywords: CR
Depends on:
Blocks:
 
Reported: 2014-02-17 20:03 UTC by Leif Halvard Silli
Modified: 2014-03-07 21:23 UTC (History)
8 users (show)

See Also:


Attachments

Description Leif Halvard Silli 2014-02-17 20:03:24 UTC
SITUATION:

* Since the HTML WG decision, table@border has been part of the spec.
  http://lists.w3.org/Archives/Public/public-html/2011Apr/0377.html

* However, in commit 5f540174f5fde713e45b72c81e530fb5d964d2df of 7th of November 2013, the table@border attribute was deleted from HTML 5.1.
 
* Some time in January 2014, the change propagated in to HTML 5.0 - I have not dug up the specific commit as of yet. Later the change affected the NU validator.

* The commit, by Erika Doyle, was authored by Ian Hickson. Based on the commit message, the change appears to have been an unintended result of the fact that table@border has another status in the WHATWG spec than in the HTMLWG spec.

REQUEST:

Please revert to the status before this accident.
Comment 1 Travis Leithead [MSFT] 2014-02-18 19:45:06 UTC
Marking for CR
Comment 2 Sam Ruby 2014-02-24 21:45:46 UTC
Clearly this bug is related to:

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

My input there:

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

Note: as my weblog was mentioned in the original change proposals, I recused myself from the original decision.

That being said, from a process perspective, I don't believe that Mike has identified any new information as such the decision should stand.  Alternately, Mike is welcome to Formally Object to that decision.  That being said, the decision was for 5.0, and 5.1 could very well come up with a different solution.
Comment 3 Erika Doyle Navara 2014-02-25 01:14:38 UTC
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are
satisfied with this response, please change the state of this bug to CLOSED. If
you have additional information and would like the Editor to reconsider, please
reopen this bug. If you would like to escalate the issue to the full HTML
Working Group, please add the TrackerRequest keyword to this bug, and suggest
title and text for the Tracker Issue; or you may create a Tracker Issue
yourself, if you are able to do so. For more details, see this document:


   http://dev.w3.org/html5/decision-policy/decision-policy.html

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 23591), this change at least keeps the spec internally consistent for the time being, and honors the current WG decision for 5.0.

[1] https://github.com/w3c/html/commit/5f540174f5fde713e45b72c81e530fb5d964d2df
Comment 4 Leif Halvard Silli 2014-02-25 12:28:19 UTC
I acknowledge the option that HTML 5.0 and HTML 5.1 could end up with different solutions to the status of table@border.

But we are only talking a short one liner - a simple fix. Hence, except for matters of ”prestige”, I don’t understand why we still discuss whether an accidental outcome of refactoring should be fixed, also in HTML 5.1.

I think that a possible removal of table@border should happen in one go. There should be no reference to the ”fact” that ”table@border was already halfway removed anyway”. So, yes, you should insert it - and deleted it again, if so be.

If bug 24591 is accepted, the editors will have to delete much more than a single line, since acceptance of that bug would cause the prose of the table element specification to be written and would cause table@border to be removed from the list over HTMl5 attributes.

For now, I simply make this statement, leaving the status of the bug as is.
Comment 5 Leif Halvard Silli 2014-02-25 21:14:59 UTC
(In reply to Erika Doyle Navara from comment #3)

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

Ah, sorry, I did not realize that you fixed both HTML 5.1 and HTML 5.0 ... Guess I am some sort of skeptical guy ...

So in that case, I say thank you. Ignore my previous comment. Bug closed.
Comment 6 Andrea Rendine 2014-02-26 19:06:11 UTC
How long will it take for editors to modify the web page specs accordingly?
Guess what, I'm the kind of skeptical guy too...
Comment 7 Andrea Rendine 2014-03-06 14:19:15 UTC
The texts of the HTML5 CR spec and HTML5.1 Working Draft haven't been fixed accordingly.
Comment 8 Erika Doyle Navara 2014-03-06 23:45:54 UTC
(In reply to Andrea Rendine from comment #7)
> The texts of the HTML5 CR spec and HTML5.1 Working Draft haven't been fixed
> accordingly.

The changes are reflected in the current editor's drafts:

    HTML5: http://www.w3.org/html/wg/drafts/html/CR/tabular-data.html#the-table-element

    HTML5.1 Nightly: http://www.w3.org/html/wg/drafts/html/master/tabular-data.html#the-table-element

They will not be reflected in the Working Drafts of those specs until the HTML WG publishes new heartbeat drafts. Thus far, the process of the editors has been to resolve bugs as they are fixed in the source of the spec, though its certainly the prerogative of the bug filer to wait to close the bug until it is reflected in an official working draft, if desired.

I'm going to resolve this again as fixed, however if you wish to raise objections to the general editorial bug management process, please feel free to start a discussion on public-html.
Comment 9 Leif Halvard Silli 2014-03-07 21:23:40 UTC
Usually I resolve bugs as CLOSED once the editor has fixed it in the working draft. So I will do this in this case too.