This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Per the submittal of the PFWG's recommended alternative text for the table summary attribute, this element should be removed from the obsolete but conforming section of the HTML5 draft (per related bug at http://www.w3.org/Bugs/Public/show_bug.cgi?id=7539), and the description of summary be modified to provide more useful information for web page authors. This includes providing a more useful example demonstrating the proper use of summary.
The note in the "obsolete but conforming" section is present just to make sure people know a warning will be triggered, it doesn't actually make it obsolete or anything. The attribute, even though conforming, is strongly discouraged, which is why there's no example.
(In reply to comment #1) > The note in the "obsolete but conforming" section is present just to make sure > people know a warning will be triggered, it doesn't actually make it obsolete > or anything. > ... So if it isn't obsolete, why does it appear under "obsolete but conforming"?
Because it triggers a warning, like the things that _are_ obsolete but conforming, and so it is useful for authors who are looking for a list of all the warnings.
(In reply to comment #3) > Because it triggers a warning, like the things that _are_ obsolete but > conforming, and so it is useful for authors who are looking for a list of all > the warnings. Does not compute. If it's not obsolete then either move it elsewhere, rename the section, or add a clarification that this is an exception. (are there more cases like this?)
Only a very naïve reading would lead to the conclusion that the summary="" attribute is _not_ an exception: it doesn't say "should not", it says that the attribute is defined elsewhere, and it is in green non-normative text with the word "Note:" in front of it. This basically all but screams "this is an exception". We don't want to make it sound like it's ok to use the summary="" attribute; even though it is technically conforming and not technically obsolete, it's still strongly discouraged. It would be counter-productive to make it sound like it was ok. We could make it obsolete again, if the problem is that it is an exception. That would be certainly much preferable to me than removing this sentence or making it even weaker.
Citing the spec: "12.1.1 Warnings for obsolete but conforming features To ease the transition from HTML4 Transitional documents to the language defined in this specification, and to discourage certain features that are only allowed in very few circumstances, conformance checkers are required to warn the user when the following features are used in a document. These are generally old obsolete features that have no effect, and are allowed only to distinguish between likely mistakes (regular conformance errors) and mere vestigial markup or unusual and discouraged practices (these warnings). The following features must be categorized as described above: ... * The presence of a summary attribute on a table element." I do not see how this can be read other as "table/@summary is obsolete".
Wait, you're talking about the validator conformance requirements? I thought we were talking about what was "obsolete and conforming", which is the previous section. The section you just quoted has nothing to do with authors and doesn't say what's obsolete or not. It just lists the things that validators must warn about. As the bit you quoted says, they are generally obsolete things, but they are by no means _all_ obsolete things, and that's why it doesn't say they are all obsolete things. Marking INVALID; if you disagree, please escalate to the chairs.
If you want to escalate this to the chairs, feel free. There is an issue on this, and I'm keeping the bug alive until the Issue is resolved. I'm the originator of this bug, and my description of the bug, and what I want changed is clear: remove summary from the obsolete but conforming section, so that it does _not_ trigger a validator warning, remove the warning referencing it earlier in the specification, and provide an example similar to the other examples, in the table section. I don't think I can explain it more clearly.
Oh, you want to change the actual normative meaning of the spec, this is not just an editorial request? That was unclear previously. I thought this was about changing the text within the constraints of the compromise agreed-to at the last publication. I definitely don't think summary="" should not trigger a warning; if anything, I'd much rather make the element non-conforming again, to avoid the potential accessibility problems that summary="" has been shown to bring with it. According to the instructions I have received from the chairs, if you disagree with my conclusion, it is your responsibility to escalate the issue to the chairs.
We have issue 32 open for tracking the summary attribute, so I've added a link to this bug there. I've also requested that the a "Related Bugs" field be added to the Tracker, which I think will help for cases like the table/@summary issue, where we may have multiple bugs associated with a particular issue. http://www.w3.org/html/wg/tracker/issues/32
Mike?
moving this back to WONTFIX per my previous comment: http://www.w3.org/Bugs/Public/show_bug.cgi?id=7633#c10 The chairs are currently have discussion about the exact process for disposition of bugzilla bugs. But the proposed process is basically this: For bugzilla bugs for which a commenter does not agree with the editor's proposed resolution, and for which we have a related Tracker issue, we leave the resolution of the bug at whatever value the editor set it to (e.g., WONTFIX), and then after we get a Working Group decision on the related issue, we go back and update the bug with information about that decision, including some indication about whether it the decision concurred with the commenter or not. So I'd like to suggest that we leave this issue at WONTFIX.
"So I'd like to suggest that we leave this issue at WONTFIX." I fundamentally disagree with this status, as the problem as described still exists and needs to be addressed. The fact that Issue 32 is still open only serves to re-enforce the fact that this bug issue is unresolved, and leaving it at WONTFIX is tantamount to saying that Ian's opinion has more weight than those who disagree. It is wrong, and an affront to the web accessibility community that existing accessibility solutions that the current editor disagrees with have the status of WONTFIX simply because the editor disagrees. It is a political statement in what should be a non-partisan issue tracker. Any bug issue that is promoted to the Issue Tracker should, by default, render all associated bugs as Status: ASSIGNED (to the Issue # of record) & Resolution: MOVED which is factual, non-biased, and appropriate. Anything else is unacceptable.
Removing myself from cc list, default on bug edits is to add, but I'm only acting on behalf of HTML A11Y TF which is already cc'd.
The HTML Accessibility Task Force intends to track these issues, per the proposal at http://lists.w3.org/Archives/Public/public-html-a11y/2010Jan/0245.html.
This bug predates the HTML Working Group Decision Policy. If you are satisfied with the resolution of this bug, 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 This bug is now being moved to VERIFIED. Please respond within two weeks. If this bug is not closed, reopened or escalated within two weeks, it may be marked as NoReply and will no longer be considered a pending comment.
This bug is related to Issue 32, even if it predatest the decission policy. I therefore don't see how it can have status "Verified".
VERIFIED with a TrackerIssue keyword is the correct state for a bug that has been resolved by the editor but has not yet been resolved via the escalation process. See the Decision Policy. Moving back to VERIFIED.
Reopened per discussion on a11y TF telcon 2010-03-18
As per previous comment, a bug that has been escalated should not also be reopened. Back to VERIFIED.
(In reply to comment #20) > As per previous comment, a bug that has been escalated should not also be > reopened. Back to VERIFIED. Maciej set the status of this bug to VERIFIED FIXED after it was reopened through a misunderstanding of the decision process at the a11y teleconference. Maciej's rationale is that this bug is already escalated to a tracker issue. VERIFIED with a TrackerIssue keyword is indeed the correct state for a bug that has been "resolved" by the editor but has not yet in fact been decided by the working group via the escalation process. Maciej was correct to move the bug back to VERIFIED. It shouldn't have been REOPENED per HTML working group process. http://dev.w3.org/html5/decision-policy/decision-policy.html#states-and-keywords However, it should have been left in the state that it had last been set it to. Ian did not FIX this bug. It is not FIXED. Relabeling this bug VERIFIED WONTFIX as that is was last set it to. http://lists.w3.org/Archives/Public/public-html-bugzilla/2009Sep/0996.html