7468 2009-08-31 14:33:27 +0000 make <table border="1" cellpadding="10" cellspacing="0"> conforming 2011-04-14 23:47:05 +0000 1 1 1 Unclassified HTML WG pre-LC1 HTML5 spec (editor: Ian Hickson) unspecified PC Linux RESOLVED FIXED NE, WGDecision P1 normal --- 1 rubys ian annevk ayg ian mike mjs Ms2ger public-html-admin public-html-wg-issue-tracking xn--mlform-iua public-html-bugzilla oldest_to_newest 26754 0 rubys 2009-08-31 14:33:27 +0000 I intentionally use these attributes on my weblog as I know that my entries will be syndicated, and that the alternatives (including inline CSS) are clumsy and are less likely to survive the process of syndication intact. 26756 1 annevk 2009-08-31 15:20:00 +0000 What's next, <font>? I assume that will survive syndication better as well... 27288 2 ian 2009-09-18 09:35:03 +0000 This use case is handled by <style scoped> in HTML5. 33368 3 mjs 2010-03-14 14:50:26 +0000 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. 33552 4 rubys 2010-03-14 21:27:01 +0000 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. 33555 5 mjs 2010-03-15 02:14:49 +0000 (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? 33626 6 Ms2ger 2010-03-16 19:45:47 +0000 (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? 33921 7 rubys 2010-03-25 18:21:01 +0000 (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. 33922 8 rubys 2010-03-25 18:23:25 +0000 (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. 33977 9 ayg 2010-03-28 01:45:36 +0000 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. 34014 10 ian 2010-03-28 22:09:19 +0000 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. 34019 11 rubys 2010-03-28 22:33:45 +0000 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 34151 12 847 mjs 2010-03-30 16:43:44 +0000 Created attachment 847 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. 34506 13 ian 2010-04-04 10:00:45 +0000 (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. 44375 14 xn--mlform-iua 2011-01-16 10:49:05 +0000 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>). 44377 15 xn--mlform-iua 2011-01-16 18:01:31 +0000 There is a link to bug 10963, but categorizing it as dependency was not to the point ... 44378 16 ayg 2011-01-16 20:27:48 +0000 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. 44394 17 rubys 2011-01-17 21:54:44 +0000 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. 44397 18 xn--mlform-iua 2011-01-17 22:23:44 +0000 Added a TrackerRequest. Sam, will this do? Or must it also appear in the Tracker before that date? 44399 19 rubys 2011-01-17 22:34:27 +0000 http://www.w3.org/html/wg/tracker/issues/155 47431 20 rubys 2011-04-14 13:01:37 +0000 Working Group Decision: http://lists.w3.org/Archives/Public/public-html/2011Apr/0377.html 847 2010-03-30 16:43:44 +0000 2010-03-30 16:43:44 +0000 Test case webkit.rss application/rss+xml 1431 mjs PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz48IS0tIGdlbmVyYXRvcj0iV29y ZFByZXNzLzIuOC41IiAtLT4KPHJzcyB2ZXJzaW9uPSIwLjkyIj4KPGNoYW5uZWw+Cgk8dGl0bGU+ U3VyZmluJyBTYWZhcmk8L3RpdGxlPgoJPGxpbms+aHR0cDovL3dlYmtpdC5vcmcvYmxvZzwvbGlu az4KCTxkZXNjcmlwdGlvbj5BbGwgYWJvdXQgV2ViS2l0IGRldmVsb3BtZW50PC9kZXNjcmlwdGlv bj4KCTxsYXN0QnVpbGREYXRlPlNhdCwgMjAgTWFyIDIwMTAgMDg6MjE6MTMgKzAwMDA8L2xhc3RC dWlsZERhdGU+Cgk8ZG9jcz5odHRwOi8vYmFja2VuZC51c2VybGFuZC5jb20vcnNzMDkyPC9kb2Nz PgoJPGxhbmd1YWdlPmVuPC9sYW5ndWFnZT4KCQoJPGl0ZW0+CgkJPHRpdGxlPkRhbmllbCBCYXRl cyBpcyBub3cgYSBXZWJLaXQgcmV2aWV3ZXIhPC90aXRsZT4KCQk8ZGVzY3JpcHRpb24+RGFuaWVs IGhhcyBtYWRlIG1hbnkgdmFsdWFibGUgY29udHJpYnV0aW9ucyB0byBXZWJLaXQgaW5jbHVkaW5n IGFkZGl0aW9ucyB0byB0aGXCoFhTU0F1ZGl0b3IsIHdoaWNoIGhlbHBzIHByZXZlbnQgcmVmbGVj dGl2ZSBjcm9zcyBzaXRlIHNjcmlwdGluZyBhdHRhY2tzLCBhcyB3ZWxsIGFzwqBudW1lcm91cyBj aGFuZ2VzIHRvIGRyYWcgYW5kIGRyb3AgZW5zdXJpbmcgdGhhdCBXZWJLaXQgY29tcGxpZXMgd2l0 aCB0aGUgSFRNTDXCoHNwZWMuIE9mIGNvdXJzZSwgYWxsIG9mIHRoaXMgd2FzIHN1cHBvcnRlZCB3 aXRoIHRob3JvdWdoIHRlc3RzIGFuZCBpbXByb3ZlbWVudHMgdG8gV2ViS2l0J3PCoHRlc3Rpbmcg aGFybmVzcy4gLi4uCiAgICAgICAgICAgICAgICA8dGFibGU+PHRyPjx0ZD5ObyBzdHlsaW5nPC90 ZD48L3RyPjwvdGFibGU+CiAgICAgICAgICAgICAgICA8dGFibGUgYm9yZGVyPTEgY2VsbHNwYWNp bmc9MD48dHI+PHRkPlByZXNlbnRhdGlvbmFsIGF0dHJpYnV0ZXM8L3RkPjwvdHI+PC90YWJsZT4K CiAgICAgICAgICAgICAgICA8dGFibGUgc3R5bGU9ImJvcmRlci13aWR0aDogMXB4OyI+PHRyPjx0 ZD5zdHlsZSBhdHRyaWJ1dGU8L3RkPjwvdHI+PC90YWJsZT4KICAgICAgICAgICAgICAgIDx0YWJs ZSBpZD10MT48c3R5bGU+I3QxIHsgYm9yZGVyLXdpZHRoOiAxcHg7IH08L3N0eWxlPjx0cj48dGQ+ c3R5bGUgZWxlbWVudDwvdGQ+PC90cj48L3RhYmxlPgogICAgICAgICAgICAgICAgPHRhYmxlIGlk PXQyPjxzdHlsZSBzY29wZWQ+I3QyIHsgYm9yZGVyLXdpZHRoOiAxcHg7IH08L3N0eWxlPjx0cj48 dGQ+c3R5bGUgc2NvcGVkPC90ZD48L3RyPjwvdGFibGU+CgogICAgICAgICAgICAgICAgPC9kZXNj cmlwdGlvbj4KCQk8bGluaz5odHRwOi8vd2Via2l0Lm9yZy9ibG9nLzEwNjkvZGFuaWVsLWJhdGVz LWlzLW5vdy1hLXdlYmtpdC1yZXZpZXdlci88L2xpbms+CgkJCTwvaXRlbT4KPC9jaGFubmVsPgo8 L3Jzcz4K