What's next, <font>? I assume that will survive syndication better as well...

This use case is handled by <style scoped> in HTML5.

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.

Style scoped is not widely implemented at this time.

This bug may be a duplicate of 7034, but as the request is to have multiple separate bug reports, this one should be left open.

(In reply to comment #4)
> Style scoped is not widely implemented at this time.
> 
> This bug may be a duplicate of 7034, but as the request is to have multiple
> separate bug reports, this one should be left open.
> 

Is this bug report solely about the border, cellpadding, and cellspacing attributes on <table> or are there other table attributes that should be considered?

(In reply to comment #4)
> Style scoped is not widely implemented at this time.

What's stopping you from using HTML4 transitional until it is?

(In reply to comment #6)
> (In reply to comment #4)
> > Style scoped is not widely implemented at this time.
> 
> What's stopping you from using HTML4 transitional until it is?

My site is HTML5, using the DOCTYPE and even new tags such as section and article.  I even have embedded SVG that displays using IE9's platform preview even though I am currently serving the content as text/html to that user agent.

(In reply to comment #5)
> (In reply to comment #4)
> > Style scoped is not widely implemented at this time.
> > 
> > This bug may be a duplicate of 7034, but as the request is to have multiple
> > separate bug reports, this one should be left open.
> 
> Is this bug report solely about the border, cellpadding, and cellspacing
> attributes on <table> or are there other table attributes that should be
> considered?

7034 covers all Author Conformance Requirements.

This bug only covers what is mentioned in the bug report.  I'm OK with this bug being marked as being blocked by bug 7034.

I agree with Sam that at least until such time as <style scoped> is reliably implemented, it would be better if cellpadding, border, and cellspacing (as well as possibly some other presentational elements/attributes that don't map easily to inline CSS) were conforming.

Perhaps they could be obsolete but conforming.  My understanding is that "obsolete but conforming" is used when something should be obsolete, but where it's harmless and permitting it for now would significantly ease transition to HTML5.  I believe this applies to the three attributes that Sam mentions, and to any other presentational attributes that cannot be easily mapped to inline style yet in practice.

For what it's worth, it will not be realistically possible for MediaWiki (or Wikipedia) to output conforming HTML5 as consistently as we now output conforming XHTML 1.0 Transitional as long as all these presentational attributes are invalid.  We have a large body of content using these attributes that must be supported -- e.g., most infoboxes on Wikipedia, which means most articles.  We could convert <font face> and such automatically, but not <table border> or such.

Therefore, if the spec aims to only impose author conformance requirements that are practically implementable for sites with large bodies of legacy content -- I doubt MediaWiki is the only app in this position, although it might be -- then these restrictions need to be relaxed.  I believe that to do otherwise would violate the principle that the spec should conform to reality.

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: Rejected
Change Description: no spec change
Rationale: This use case is handled by <style scoped> in HTML5. This feature has graceful fallback that works in all the browsers I tested: you just have to add an ID to the root element of your syndicated article and then prefix all the selectors in the style sheet with that ID. It's not ideal, which is why we're introducing the scoped="" attribute, but it does work well enough to address this for now.

The bug report specified syndication as a use case.  The response provided did not address this usage.

If you wish to test user agents, I suggest you select a few from this set:

http://en.wikipedia.org/wiki/Comparison_of_feed_aggregators

Created attachment 847 [details]
Test case

Test case for different ways of styling a table in an RSS feed.

In Safari's built-in RSS reader, the border attribute on table was the only way to give the table a border; none of the other techniques worked.

(In reply to comment #11)
> 
> If you wish to test user agents, I suggest you select a few from this set:
> 
> http://en.wikipedia.org/wiki/Comparison_of_feed_aggregators

The list above seemed to have a lot of weird software on it that I wasn't sure how to test, so I instead checked the most popular feed readers according to feed-readers.com:

My Yahoo: Doesn't even support <p>, let alone any styling.
Bloglines: Supports style="".
Firefox LiveBookmarks: Doesn't seem to render the page except for the preview, where it ignores CSS.
NetNewsWire: Supports both <style> and style="".

I also checked a few others I happen to know about:

Google Reader: Supports style="".
Opera: Supports <style> and style="".
Safari: Ignores all CSS.

So it seems that a number of these products support at least style="", sometimes both style="" and <style>. Some don't, and some don't even do basic styling like <p>.


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: Rejected
Change Description: no spec change
Rationale: The state of HTML syndication in feed readers is a mess, and we do not do authors a service by encouraging them to hack around this mess by using features that were deprecated over a decade ago. The most popular feed readers that actually render the pages usefully do support style="", so that should be an adequate workaround for the time being. In any case, assuming you are using semantic HTML correctly, it doesn't matter if the styles don't make it through the syndication process intact — the whole point of HTML is that it is a presentation-independent markup language that can be restyled without losing the meaning of the content.

Reopen with a focus solely on @border. 

Summary of the suggested outcome of this bug: 

   EITHER make @border fully valid
   OR limit validity to border="1" (similar to how 
   border="0" is permitted for  the <img> element)

Summary of reasons for re-opening with a focus on @border:

1) the validity of @border is linked to bug 10963 (that is: 
    ISSUE-130: allow tables to be used for layout purposes).

    This is how:
  a) <table border=1 > ensures that a table is perceived as
      a data table by users who browse the Web without CSS;
  b) the defacto existence of layout tables means that it is 
      not an option for less CSS-savvy UAs to display table
      borders by default (that is, when @border is lacking)

2) Sam focused on reuse of HTML in another format (RSS)
     - but there are "native" use cases as well. Use cases:

   a) table-capable text browser without CSS support
       browsing a data table
   b) GUI browsers with CSS disabled
       browsing a data table
   c) WYSIWYG editors in need of simple editing styling
        when browsing/editing a data table when 
       stylesheet is disabled/not attached

Justification in more detail:

1) ISSUE-130 - [ table bordes plays a semantic role: ] 

   table-border (whether set by CSS or @border) *often* (not always and not alone) play an important role - for users - in deciding whether a table is a layout table (such tables are not perceived by users as tables, unless the user is HTML-savvy)  or a data table. In most cases, when a table with the border attribute set to a low, non-zero value (and if each cell is also not too big), the table is a data table. And opposite, if the table is used for layout, then there either isn't a border attribute, or it is set to zero.
    Thus, for a user which browses the web without CSS, the fact that a table has borders arounds its (small) cells, helps the user to identify the table as a table and also helps in reeading and interpreting the table cells, by  showing how the cells are connected. 
    (It is thinkable that AT could use @border to discern between data and layout tables, but I have no insight into whether they do.)

2) Use cases [ being semantic, table borders should be available to not so CSS-savvy user agents: ] 

  a) Text browsers (lynx, elinks, links, w3m etc) 
      These have different strategies for handling tables. Some of them transforms any table into paragraphs or space separated arrays. L ynx is one of those. And Lynx makes no use of table cell borders. But other text browsers, such as elinks, links and w3m, are able to display tables, including their. For the latter group of text browsers, the borders contributes a lot to making sense of web pages.
    Examples: 

    http://www.elinks.ch 
    = a page with layout tables. The tables are rendered without borders in w3m,elinks,links

    http://dev.w3.org/html5/status/issue-status.html
    = datatable which is hard to read in w3m/links/elinks due to lack of border="1" - it is very difficult to understand to which header-cell each row belongs - the only border-like lines in said text browsers, are generated by the <hr> element, which - alas - only is used to split the <th> into sections. (HTML5, btw, does not permit <hr> - or <p> - inside <th>.)

    http://icab.de/test.html
    = this example page contains a several data tables which are easy to read in w3m/links/elinks because the tables *do* include a border="1" attribute.

 b) GUI browsers with CSS disabled
     Who disables the CSS in a GUI browser? Well, one group is Web authors. Another are those who prefer to browse the web "without clutter". For thes first group, Web authors, while it could make sense for Web authors to check that a data table is perceivable even when it contains no borders whatsoever, such a rehearsal is futile -and, the author could just as well make the same rehearsal via CSS. In a summary: a web author who checks his data tables for readablility even when CSS is disabled, would probably like to see that the table has cell borders. And, of course, *users* who falls into this group - those who want to turn off "the clutter", would of courrse like to see the cell borders as well.

  c) WYSIWYG editors
      When editing a web page, authors often need to disable regular CSS styling, in order to focus more on content and also because it is often demanding on the computer to edit a page with all the "bells and whistles" enabled. In that case, if a table is entirely styled via CSS, the cell borders will go away. This can hamper the editing. I have experienced this myself. Both in in-browser WYSIWYG editor as well as in specialized editors, such as Amaya Adding a basic border via @border is often a trememdous help during editing.

Refuting a possible counter-argumet againt @border:

 One could argue that @border opens the door for the othter table related attributes (@cellpadding, @cellspacing, @frame @rules) and even for the <font> element.

  However, while I am personally in favour of full validity for the @frame and @rules attributes (because they are very "semantic", @border is a a much more basic attribute which focuses on a more basic semantic level. All the other mentioned table related attributes are refinement attributes. Therefore I don't believe @border needs to be seen as opening upp for all the other table attribtues (not to speak about <font>).

There is a link to bug 10963, but categorizing it as dependency was not to the point ...

FWIW, MediaWiki has had a bug filed against it by a user of a non-CSS-supporting text browser, complaining that the lack of border="1" made many tables illegible:

https://bugzilla.wikimedia.org/show_bug.cgi?id=18829

This issue does appear to impede the usability of even well-written HTML with CSS disabled.

Reminder: - Jan 22, 2010 is the cutoff for escalating bugs for pre-LC consideration - all issues in tracker, calls for proposal issued by this date.
Consequences of missing this date: any further escalations will be treated as a Last Call comment.

Added a TrackerRequest. Sam, will this do? Or must it also appear in the Tracker before that date?

http://www.w3.org/html/wg/tracker/issues/155

Working Group Decision: http://lists.w3.org/Archives/Public/public-html/2011Apr/0377.html