- From: <bugzilla@jessica.w3.org>
- Date: Sun, 16 Jan 2011 10:49:09 +0000
- To: public-html-bugzilla@w3.org
http://www.w3.org/Bugs/Public/show_bug.cgi?id=7468
Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |REOPENED
CC| |xn--mlform-iua@xn--mlform-i
| |ua.no
Depends on| |10963
Resolution|WONTFIX |
--- Comment #14 from Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no> 2011-01-16 10:49:05 UTC ---
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>).
--
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
Received on Sunday, 16 January 2011 10:49:11 UTC