According to the HTML5 description the attribute rowspan may have value 0. In this case the value zero means that the cell is to span all remaining cells of the given column in the row group.
However the value of colspan may not be equal to zero.
So a question arises what is the reason for such a restriction for the attribute colspan?
This is quoted from https://lists.w3.org/Archives/Public/public-html/2011Aug/0293.html but it explains the issue in detail.
In HTML4, "colspan" and "rowspan" attributes of TD/TH elements has been allowed to have zero value ("0"):
http://www.w3.org/TR/html4/struct/tables.html#adef-colspan
This is very useful when column or row number is unknown in advance.
It's harmful to force web-editors to calculate column or row number
manually while browser could easily do this automatically.
There is a known rule in spec development: when there are two
independent implementations of a specification, then the specification
status is promoted to "recommendation" ("candidate" or "proposed").
But there ARE already two (well, 1.5) working independent
implementations of zero colspan/rowspan:
Firefox (both zero colspan and rowspan are fully working)
and Opera (supports rowspan="0" and does not support colspan="0").
So, zero value of colspan/rowspan is very good candidate to keep in
HTML spec and, moreover, to encourage rest browser vendors to
implement this useful feature as soon as possible.
There are no serious reasons to remove zero values of colspan/rowspan
from the HTML specification. It's not something "unimplemented at
all", it's already quite usably implemented and should be kept intact
in the HTML spec.
Also the HTML5 spec (4.9.11) explicitly states that colspan shall be non-zero and rowspan can be zero along with what it means to be zero. http://www.w3.org/TR/html5/tabular-data.html#attr-tdth-colspan
The quick answer to why would be to say that the HTML5 spec explicitly states this restriction. IMO I see no reason why browsers wouldn't reserve the meaning of zero to act the way Firefox has implmented other than to follow specification.
Related
I'm using HTML tables to create a timetable. Each row represents half hour, and the cells can span multiple rows by using rowspan.
Sometimes I have empty tr elements, because all the slots are taken by cells from previous rows.
In that case, the HTML validator complains:
Row [N] of a row group established by a tbody element has no cells
beginning on it.
Sure, I could remove those empty tr and reduce the rowspan value of the expanded cells. But then the rowspan value would no longer univocally correspond to the duration of the cell.
Therefore, are empty trs really invalid? Why?
You can’t have empty rows in a table in a valid HTML document per the current HTML spec.
Maybe you rightly should be able to, but the spec currently clearly says that you can’t. So if anybody believes it should be allowed by the spec, the right thing to do is to file an issue against the HTML Standard in its github tracker or even write a patch and open a PR for it.
Specifically the spec defines the following error case:
https://html.spec.whatwg.org/multipage/tables.html#the-table-element
If there exists a row or column in the table containing only slots that do not have a cell anchored to them, then this is a table model error.
In Internet-spec terms, that is a “normative” authoritative statement that can’t be ignored or overridden by anything else. It is stating a hard requirement.
The spec elsewhere says this:
The tr element: Content model
https://html.spec.whatwg.org/multipage/tables.html#the-tr-element
Zero or more td, th, and script-supporting elements
But that’s not actually a contradiction and does not conflict with or supersede or override the “table model error” requirement cited above. In fact, it’s the opposite—the “table model error” requirement supersedes the more-liberal requirement in the other section (cited above) that a valid tr element can have zero or more children.
Any stricter requirements in a spec always supersedes or overrides any more-liberal requirements.
In the table model section of the HTML spec, you can find the following statement:
Rows usually correspond to tr elements, though a row group can have some implied rows at the end in some cases involving cells spanning multiple rows.
However, that doesn't work for empty rows in the middle of your table, as the implied rows can only occur at the end.
Another possibility would be to add a column with <th> elements to the left that serve as a caption for the row. After all, the user may want to know what one table row represents - just as you have told us here.
Assuming, xxxx is always a positive, unique number, has someone done tests on breaking tabindex. For example, is any length of number acceptable in major browsers? Is there a maximum number of elements on a page?
HTML 4.01 sets a maximum value of 32767 for the tabindex attribute. HTML5 LC and WHATWG HTML do not set such a restriction, but this appears to be an oversight, and I have proposed that it be fixed.
Browsers actually enforce the limit, though in incompatible ways. Chrome and Firefox interpret larger values as 32767 or (for very large numbers) 0, IE as negative numbers (except that 32768 is taken as 0).
There is no limit on the number of elements on a page. Neither is there any limit on the number of elements that participate in the tabbing order. You can set the order explicitly with the tabindex attribute “only” for 32767 elements. If you need more elements in the tabbing order, you need specify the rest so that they appear (in source HTML) in that order (and after elements with a positive tabindex value).
I'm curious what the impact is of colspan in different browsers.
I have a table with a row acting as a heading which uses colspan to spread across all columns, and I might want to add columns in the future. If I simply make the colspan some really large number so that I can add columns without having to update the heading, does this have any negative impacts?
Will browsers behave badly and creating loads of dud columns, or should they be smart enough to limit this to how many columns the table actually has?
Using colspan to span columns that have no cells beginning in them violates the HTML table model (which is being formalized in HTML5 table processing model). All bets are off then, and testing on all existing browsers (which isn’t really possible) wouldn’t be enough – future browsers could handle your markup error differently.
Theoretically, according to HTML 4.01, colspan=0 means that “the cell spans all columns from the current column to the last column of the column group (COLGROUP) in which the cell is defined”. However, this was not implemented, and it is being removed (value of 0 made an error) in HTML5, without any replacement.
The idea is clearly that the author, or the software that generates an HTML document, is responsible for counting the columns. That is, if you add columns to the table, you need to modify the colspan value, if you want a cell to span all columns.
MDN says there are two behaviors, one for <th> and one for <td>.
For header cells (th), the value must be >=0, <=1000. If it is >1000 it clips to 1000, if it is 0 it spans the entire <colgroup>.
For data cells (td), the value value must be >= 0, <= 1000. If it is >1000 it is set to 1, if it is 0 it spans the entire <colgroup>.
Also, it appears Firefox is the only one to support the 0 = colgroup rule.
Best way is to try it. But my guess is they'll all be fine.
What's a really large number? 50? 100? 10000?
here's a fiddle with 200 columns and a colspan:
<table>
<tr>
<th colspan="200">test</th>
</tr>
<tr>
<td>test</td>
...
</tr>
</table>
http://jsfiddle.net/FYKqb/
try it in different browsers. I reckon they'd all be fine.
simply put, i think that the input 'size' field is now obsolete (like the rest of html styling outside of css), and most of the sizing attributes have been deprecated, so why not input.size?
Maybe you got confused between size and width/height attributes (btw I got confused at first when you said field). But assuming you didn't, let me explain what size is for.
size attribute
The attribute size for element <input> applies to text inputs, like e-mail, password, etc. It defines the maximum character width for the input. Let's say for example you want the maximum password length to be 4 to screw the users, you give it size=4, so you cannot enter passwords like dinosaur (anything you type after dino will not appear unless you delete the previous letters first)
Edit: as pointed out by Maksym in the comments, the above is defined by maxwidth, not size. size is, if we refer to HTML4 spec,
except when type attribute has the value "text" or "password". In that case, its value refers to the (integer) number of characters.
So size=4 is about 4 (monospaced?) characters wide (My experiment with Google Chrome has makes it size+1 though, i.e. size=4 is 5 characters wide.)
Dimension attributes
Now in case of the dimension attributes width and height. For <input> elements, they apply only to image buttons. They define the dimensions of the button. Now why can't you just apply CSS to them?
First, know that CSS is for visual purposes. Image buttons submit coordinates that the user clicked on. This behavior needs to be consistent across browsers, whether they support CSS or not. See this warped image:
There may be a case where the user is asked to click the letter e for the form submit to be processed differently. Probably the server will check whether the x coordinate is 75 <= x <= 90. But if you defined the dimension with CSS, browsers which disabled CSS will see this image instead:
And the previous coordinate range check is no longer valid, seeing that the letter e is further to the right, hardly within 75 and 90 (and you need to click on the left side of the first o to get the same input).
That is a rhetorical question really... or an attempt at persuasive argument. You are right, though-- it could easily be deprecated and CSS take over. As for why, that answer can only come from someone inside W3C who is part of the decision making process. You could also ask why cellpadding, cellspacing, and width properties are not deprecated in tables.
The best answer I can give you to your non-question is that HTML isn't a purist language--while it's getting back to it's roots of being just content and not style or behavior, it still has it's legacy from the 90's and 00's, which means it still has concerns beyond just content.
There's a valid reason why this attribute isn't deprecated: "Web Usability"
When a user views your site, considering the CSS is turned of or unavailable, it's really a bad idea to let the person see a long field while in fact, the field only requires a few characters (such as ids, phone numbers, etc.).
CSS is good, yes, but only if you also considered people who won't be able to use them.
I'm creating a table in an asp.net code behind dynamically, and I want to have a footer row that only has 2 cells. The first should span all the columns in the table-1. Is there some way other then keeping track of the # of columns in the table manually for me to set the colspan to be # of all the columns in the table-1?
Preferably a HTML or CSS solution?
Colspan can't be done with CSS. It's structural rather than stylistic so it's pure HTML.
No you can't specify "all but one" as a colspan. The best you can do is colspan="0", which will span the remaining columns in the column group but to take advantage the <colgroup> at the top will need to know the number of columns anyway and be define statically.
See Tables in the HTML spec:
colspan = number [CN]
This attribute specifies the number of
columns spanned by the current cell.
The default value of this attribute is
one ("1"). The value zero ("0") means
that the cell spans all columns from
the current column to the last column
of the column group (COLGROUP)
in which the cell is defined.
But basically this just kicks the can down the street and I don't know what the browser support is like so it doesn't necessarily buy you anything.
You'll either need to know the number of columns when you generate the HTML or use Javascript.
Sorry this isn't an HTML or CSS solution... I'm only suggesting it because I don't think there is an HTML or CSS solution that will work cross-browser/cross-broweser version.
You could convert the table to an Asp:Table and then use the first row's Cells.Count...
But it would probably be more work than tracking the number of columns added the way you're doing it now. BUT it would not depend on Browser support as it would all be in the code-behind.
In case anybody else winds up here in the future, colspan=0 isn't supported in HTML 5. There are more details here: https://stackoverflow.com/a/52355253/18494923
<tr><td colspan="100%">1000</td></tr>
From question: Colspan all columns
Works in IE 7/8 & Firefox 5