-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Revise the section for table markup #5
Comments
I agree. It would be good to mention explicitly the use of It is unclear to me why |
If I remember right, tbody is inserted automatically by most browsers when parsing a table. That affects how you write CSS rules. It is probably also mandatory if you want to also include a thead or tfoot. Page breaks in the middle of a table, and CSS rules for those page breaks are also something to keep in mind when defining table markup. I think requiring a tbody ensures that the DOM is consistent across reading systems. |
I think the original reasoning was along the lines @josteinaj mentioned. We got the |
I have re-worked and added to the table section. Added requirements about |
I will close this issue soon, unless there is something I need to change. |
Do we need an example of the markup? |
A full, beautifully marked up table example could be very neat. I think this section is really good. |
Ok! I'll add a full example and then close this issue! |
Perfect! |
Great updates here! My comments: The Daisy KB does not require (and their table example does not include) the scope attribute for simple cases where the first row(s) or column(s) contain the header cells. Screenreaders will infer the scope in such cases. To keep markup as simple as possible, we may not want to require scope for simple cases, but only for complex tables. Benetech, who previously required scope for all heading cells in their GCA certification, also loosened this requirement last year: "Only for very complex tables where sub-headings for a subset of cells not in the first row or first column is present will explicit use of "scope" or "Headers & ID's" will be a requirement." (From their Technical Bulletin in June 2023.) Using scope is still a best practice, but a requirement only in complex tables. We might also want to emphasize that the first column of a data table usually contains row header cells that need to be Lastly, I find the Daisy KB Example 1, where repeated |
I'll add the thing with repeated |
If we don't require scope for all cases we need clear criteria for when it is needed. Suggested criteria: a) when heading cells are merged with colspan or rowspan, or b) when column headings are present anywhere else than in the first (topmost) row, or row headings are present anywhere else than in the first (leftmost) column. I think it is enough to use scope for the cells satisying these criteria, i.e. it may not be needed for every |
Sounds like good criteria! We are a little bit unsure about how well this will be applied in production, but let's see. /Martin, Oscar and Linda |
I am sorry for writing in this closed issue, but I think my question relates to this subject. Let me know if I should move this to somewhere else. I have tried to add
And nordic-html5.rng only allows this order:
Should this be changed in the rng code? |
That seems like an error, to me, Probably should be changed. |
If that's the case, I guess it's a bug yes. The content model of
|
In DTBook, tfoot was before tbody: <!ELEMENT table (caption?, (col* | colgroup*), thead?, tfoot?, (tbody+| (tr|pagenum)+)) > Placing it like this was also the case in HTML4, and it was also allowed in HTML5 when the 2015 guidelines were written. To be able to convert between DTBook and EPUB3 both ways, it was therefore convenient to require this order also in our books. In December 2015 however, HTML5 was changed to disallow placing tfoot before tbody: Commit comment:
|
Ok. Then it needs to be changed! |
There are additional markup that would be beneficial to add, for example header scope.
The text was updated successfully, but these errors were encountered: