I object to making border invalid as it is a key
table attribute.
The HTML feature that should trigger them to actually draw table borders is simply <table>
[…] it seems rather self-evident to me. Just look in any book, tables are almost always rendered with borders.
But, without border present, no known HTML
user agents have drawn borders by default (e.g. Mosaic didn't).
HTML5's Rendering chapter thus follows tradition when it only requires
tables with border present to render borders by
default. That borders are «self-evident» is not
sufficient justification for saying that some user agents can just
break with tradition (including with HTML5 itself).
border
is lacking) is incompatible with the Web. To test, armour yourself
with a user style
sheet that forces border rendering on any table and visit a table layout based Web page and watch
the confusing, meaningless lines that this results in. Lack of borders
doesn't need to be a layout table signal, but it often is a prerequisite if
users are meant to not perceive whether tables nor meaningless lines. almost always rendered with borders, is actually a media related observation caused by the fact that print typically is a monocolored medium, whereas tables on the Web often use background color/zebra striping for the same thing. Example: a GUI user agent/
@media
screen{} may render backgrounds to hightlight cells/rows/columns
(for an example, see the below note about
WYMeditor or a zebra striped example), but background-free
printing might still be useful to save ink or to support black-white
printing of the same document.) Borders are cheap compared with
backgrounds, and does much of the same job. Thus the border
tradition in books is an example of how border is
useful for targetting less capable media. To use table border=1 allows easy support of table borders
even in CSS constrained user agents by removing the borders only in the
media where fallback styling isn't needed: style
media="screen,handheld,tv"td{border:0}style. border. But without border=1 present, WYSIWYG editors can't default to
render borders, as such a thing would break the WYSIWYG
expectation. Some WYSIWYG editors default to show borders, some
defaults to not show borders. But regardless, when there is a
border, then border="1" is what is used, e.g. try
browser based CKeditor, SeaMonkey's Composer, Bluegriffon and more. And
when the editor or the user sets the table to have no
borders, then border="0" is what is used — e.g.
check SeaMonkey, Bluegriffon, CKEditor and TinyMC. But even with the value
border=0, these editors render a thin, dotted
border — to help the user to perceive the cells while at the same time
also hinting to the user that these borders will not be visible in
the browsers (which they won't). Ironically - but logically - the only
graphical editor I have tested which appeared to render borders
even with border not present, was browser based
WYMeditor - which isn't a WYSIWYG
editor but supposedly a "What-You-Mean editor". After a deeper look, it
turns out that WYMeditor doesn't render CSS borders: it just makes use
of «fake borders», which can be achieved via background colors
when the table has the default table{border-collapse:separate}, see Live
DOM Viewer demonstration. border: However, while I could imaging that the worst
layout table examples do not get syndicated, a precondition for not
needing to discern between layout and data tables is that the medium only
contains the one or the other kind of tables. I don't know enough about syndication
to say layout tables actually do get syndicated or not.border is a presentational attribute» argument border indicates that it wasn't conceived as
as presentational: Due to RFC 1942, the HTML4 DTD treats the value "border"as equal to
border=1
HTML4 deprecated img border="*" but not
table border="*".table isn't the only element that depends on an
attribute in order attain its most archetypical default rendering. E.g.
HTML5 sees a as 'interactive content' even
without href. But it is only with an href that a looks as a
link. Similarly table is 'table content' too, but
table border=1 is easier to perceive as table
content. border (in the other Change Proposal - CP1) isn't about CSS border-width,
-style or -color, but only about basic highlighting of data tables' most
basic feature: the cell structure. border. border), authors could add a class for each table that
needs border (which would typically result in a new one for each
context...) instead of attaching semantics to border=1. border=1 is not anti-CSS: Like authors can
alter the default styling of a href, they can
remove the 1px border default too. border or CSS borders supports this view. Also supporting this view is the fact that when something is declared as having role="presentation", then then what's happen is that the native semantics are removed. Regarding Ian's claim that border=1 would:
encourage … to write layout tables by suggesting … there are valid reasons to distinguish tables _with_ borders from tables _without_ borders
That's fine, if it leads authors to add border! Theoretical grasp isn't as important as author
behaviour. And *only* data tables *should* have border=1 as only a with href should behave like interactive content etc.
Besides, HTML5's permission to use role=presentation clarifies that any other table is a
data table.
border a boolean attribute, as the proposed CSS causes even border="0" to result in a 1 pixel border around each cell:
table[border] > tr > td, table[border] > tr > th,
table[border] > thead > tr > td, table[border] > thead > tr > th,
table[border] > tbody > tr > td, table[border] > tbody > tr > th,
table[border] > tfoot > tr > td, table[border] > tfoot > tr > th {
border-width: 1px;
}border as a presentational attribute, a thinking which doesn’t stand the test of reality: no user agent renders borders for border="0".From from analysis of Bug 12413, it seems clear that my own Change Proposal doesn’t go far enough: border needs to permit not only the value "1" but also the value "0". Simply put, border needs to be a normal, enumerated attribute with 3 keywords (1, 0 and the empty string), one missing value default (no attribute) and one invalid value default, similar to the preload attribute. To sum it up in a table:
| Value | Example | Resulting state | Resulting border width |
|---|---|---|---|
"1" |
table |
Valid keyword state | 1px |
"" (the empty string) |
table |
Valid keyword state | |
other value than "0", "1"or the empty "" |
table |
Invalid value default | |
table |
|||
"0" |
table |
Valid keyword state | 0px |
| no attribute | table |
Missing value default |