Does XHTML have an 'opinion' regarding the use of <thead>, <tfoot> and <tbody>?
Is there a case where they should be used?
Thank you.
They allow you to add semantics to your table, and also allow you to style the head and the foot of the table without introducing redundant classes/ids.
I can't think of a situation where you have to use it, although I know some jQuery plugins use the head & foot to control behaviors.
If your tabular data needs headings and summary rows, use them, if not don't
The thead, tbody, and tfoot elements
in HTML are used to group table rows
into logical sections based on their
content. There are two main reasons
you'd want to do this:
To allow the body to be scrolled independently of the header and/or
footer
To make it easier to apply different style rules to the
different sections of the table.
as stated here What is benefit of <thead>
If you are using tables to make layout then don't use these. If you are showing tabular data then use it.
And if you don't have anything to put in tfoot then don't add this.
You will find some good answers here also What is benefit of <thead>
The only rules, that I'm aware of, is that the thead (if used) must be defined first, and the tfoot (if used) before the tbody (somewhat counter-intuitive, to my mind, but them's the rules).
I think that the purpose of thead is partially for print purposes, allowing columns printed on a second page to have the thead repeated, in order that the data makes more sense.
In theory it could also allow for a scrolling tbody in the case of long tables, with fixed headers:
This division enables user agents to support scrolling of table bodies independently of the table head and foot. When long tables are printed, the table head and foot information may be repeated on each page that contains table data.
Source: http://www.w3.org/TR/html401/struct/tables.html#edef-TFOOT
This does not, however, work currently (without using at least two tables, I think).
The largest benefit, though, as #Glenn Slaven notes, seems to be semantic.
Related
I'm trying to figure out if there's a way to achieve sane printing straight from HTML. Our users often want to print a few pages for their own records. The printouts contain Google Charts and the grid is handled by bootstrap. Very frequently we want a set of content per page and thus page breaks are very much required.
Traditionally we've used print media queries, but it's been nigh impossible to achieve consistent results across browsers, say Firefox, Chrome and Mobile Safari etc. Pieces will spill over, page breaks will be ignored etc.
Some companies like Amazon and Newegg provide customers with the ability to print out invoices and other pages. It seems that usually that involves having a separate print-only version of the content that's either all tables or very simplified -based markup that looks extremely basic when printed out. Generally there's little to no styling, few if any images, definitely no and no page breaks as far as I can tell.
Another option is to just convert everything to PDF, but that has its own pitfalls and expenses. Now you have to re-generate the same content in a second format for every page that needs to be printed, and perfectly styling PDF is non-trivial as well.
Is there anything out there can can help with this? Any commonly accepted solutions?
We use wkhtmltopdf and PrinceXML to get consistent styling. Both are command line tools that can take a URL plus a custom CSS file. They generate consistent output, and are browser independent, because they are the rendering engine.
We used to use wkhtmltopdf, but we're starting to move to PrinceXML because it supports margin-boxes and two-column layout. (The main caveat with PrinceXML is the price.)
Perfectly styling PDF doesn't seem any worse or harder than styling for web display. My experience is that it takes an hour or two to get a print page styled correctly. I've never tried to handle Google Charts.
All of the popular desktop browsers now support the CSS #page rule for setting page margins, and the CSS properties page-break-inside, page-break-before, and page-break-after for handling page breaks. These will generally provide enough control to achieve consistent cross-platform printing, but there are a few things that only one or two of the browsers can do. Some examples are:
page numbering
running page headers and footers
orphan/widow control
control of background colors
If you need any of those things, PDF might be your best option; otherwise, it might be overkill. A PDF converter isn't going to automatically determine the ideal way to paginate whatever content you throw at it; human judgement will still be required.
That doesn't mean you need to explicitly declare the location of every page break, though. It's usually a lot easier to prevent bad pagination than to force good pagination. In other words, instead of telling the browser where you do want page breaks, tell it where you don't want them.
Examples of places you might want to prevent page breaks:
between a section title and the first line of section text
between a table's column headers and the first row of data*
between closely-related form fields.
The go-to CSS declaration in these situations is page-break-inside: avoid;**. It would be easier to use page-break-after: avoid; in the first two examples, but Firefox only supports the always and auto values for that property. So instead, you have to create an unbreakable div that contains or overlaps the stuff you want to keep together. Here's one way to do it:
<style>
.section {
line-height: 1.25em;
}
.title {
page-break-inside: avoid;
padding-bottom: 1.25em;
font-weight: bold;
}
.overlap {
margin-bottom: -1.25em;
}
</style>
<div class="section">
<div class="title">
Title of This Section
</div>
<div class="overlap">
</div>
This is the section text. It could be any length, so we have to
allow page breaks in it. However, we don't want the first line to
be separated from the section title. The title is unbreakable, so
we just need to add some bottom padding to it and make it overlap
the first line of text.
</div>
*Tables are probably the most challenging thing to print consistently across browsers, but it is possible.
**Old versions of Firefox, Chrome, and Safari don't support the CSS declaration page-break-inside: avoid;, but you can achieve the same effect with display: inline-block;, if needed.
What are helpful CSS properties which can be helpful for table?
I have to make so many complex tables which have different type of colors in columns, thead, borders, padding, alternate row and column colors etc. I want to use as less as possible of css classes.
How to make complex tables design with combination of as much as possible of HTML tags and CSS properties? and should look identical in all browsers.
Update:
And on same page I have to add multiple table with totally different styles
Tables are really, really old technology and tend to be very reliable in my experience. I would just get going, plan the CSS well and deal with any cross-browser issues if and when they come up.
http://developer.yahoo.com/yui/reset/
The foundational YUI Reset CSS file
removes and neutralizes the
inconsistent default styling of HTML
elements, creating a level playing
field across A-grade browsers and
providing a sound foundation upon
which you can explicitly declare your
intentions.
I must admit though, I am not sure I understand your question
you should use for this reset style sheet.you can visit this and read about reset stylesheet
reset staylesheet
I have a web application with bunch of HTML code. There are some style-attributes that I can't get rid of, but I was wondering if it's worth the cleanness to get rid of class-names and use CSS selectors instead. Do CSS selectors perform slowly?
I'm talking about replacing class-name selectors such as .example with more complex selectors like #example div > div:nth-child(3) > p
Take a look at this article to see a graph on this. I don't know how exact this benchmark is, but it seems child selectors are indeed slower, but you're not going to find any visible gains by avoiding child selectors.. this is a micro optimization that has "diminishing returns" written all over it.
The performance hit is tiny.
Here you can find an interesting blog post on the argument with examples and tests of CSS selectors performances on most common browsers:
http://www.stevesouders.com/blog/2009/03/10/performance-impact-of-css-selectors/
This is the conclusion of the author:
Based on these tests I have the
following hypothesis: For most web
sites, the possible performance gains
from optimizing CSS selectors will be
small, and are not worth the costs.
There are some types of CSS rules and
interactions with JavaScript that can
make a page noticeably slower. This is
where the focus should be.
The browser matches from right to left, and any non-specific tags will cause more of a performance hit.*
1–Slower:
.foo p
2–Faster
.foo p.bar
What happens is in the first example, the browser matches ALL paragraphs, then narrows it down to those whose ancestor has the foo class.
In the second example, the browser matches all elements that have the bar class, then matches the subset that are paragraphs, then the subset whose ancestor has the foo class.
One would generally expect the initial set of the second example to be smaller than that of the first example.
*Bear in mind that the hit will really only become apparent with poorly-crafted CSS on pages that are very large (megs) and/or have many, many elements (e.g., hundreds of spans or divs). Small pages with only a few number of elements will not see a real—if any—performance hit, even with poorly-written CSS.
Consider the following three scenarios...
Scenario A
#import "reset.css";
/* ... */
p {margin:1em 0;}
/* ... */
p#copyright {margin:0; padding:10px;}
In Scenario A, a generic rule is applied to all <p> elements that gives it top and bottom margins, so that the paragraphs are properly spaced when used in the HTML. But, by doing so, this causes cases where a <p> element now needs its generic margins removed for decorative purposes, e.g. the Copyright at the foot of the document must have no margins.
Scenario B
#import "reset.css";
/* ... */
div.content_body p,
div.sidebar_body p {margin:1em 0;}
/* ... */
p#copyright {padding:10px;}
In Scenario B, it is assumed that <p> elements don't need top and bottom margins unless explicitly defined. Here the Content and Sidebar elements will need well-spaced paragraphs
Scenario C
#import "reset.css";
/* ... */
p.spaced {margin:1em 0;}
/* ... */
p#copyright {padding:10px;}
In Scenario C, only <p> elements with a class spaced will have top and bottom margins applied.
Questions:
Which is the better scenario to use, and more importantly why?
What impact does each scenario have on:
browser CSS performance
CSS weight and maintainability
the proliferation of UI defects
If you had to add a new widget that needed flowing paragraphs, which scenario would be better for you?
Thanks!
I try to follow the principle that unadorned selectors (like "p" by itself) should provide reasonable defaults, and then use more specific selectors to override those defaults. I think this is best represented by Scenarios A and B.
If the markup is simple, and there exists a good, global default, then my stylesheets look like Scenario A.
If the markup is less simple, or global defaults are hard to define, then my stylesheets look more like Scenario B.
I try to avoid Scenario C if possible. I want it to be super easy for me (or someone else) to add new content 6 months later. I find that:
The fewer specialized classes there are, the easier it is to "fall into the pit of success" because the simplest thing you write (<p>Whatever</p>) will just work.
The more specialized classes there are, the greater the chance that you'll need to practice copy/paste programming to maintain consistent markup usage.
CSS works better when classes are semantic and describe what a piece of content is than when they are presentational and describe how content should be displayed. Scenario C is an example of presentational styling, which is only marginally better than inline styles.
Generic first because it's better to allow all first and then block fews later. :)
It totally depends on the design of your site.
If most paragraphs on the site should have margins, but a couple don’t, then the approach in A would require the least code, and would thus probably result in lower CSS weight and more maintainability.
But if only paragraphs within your content and sidebar areas require margins (or there aren’t many outside them that do), then the approach in B is a better idea.
As for the approach in C, my main worry with that would be how the HTML for the site is generated. If it’s generated by a back-end system, that system will have to know which paragraphs should be spaced, and which shouldn’t. That’s extra complexity for the system, or its users, to deal with.
For the specific example of paragraphs, I’ve often ended up with something like B. It’s easy to assume that paragraphs should have some nice, decent styling that would make, say an article nice to read. But if you look at most modern websites, most of what’s on the page isn’t content like that: it’s menus and sidebars and special little things. Now, that may not be great, design-wise, but if you’re implementing a design like that, B is the way to do that with less code, and less code generally means lower weight, easier maintainability, and fewer defects.
Personally I prefer scenario A. I find if you do things this way you can make the most of the cascade. The question you have to ask yourself though is "what is the sensible default?" Meaning is it more likely that a p will need spacing, or more likely that it wont. That should help you determine what your blanket defaults should be. Generally speaking the answer to this question is going to put you in line with scenario A.
D None of the above
#import ""; // don't need this
p { } // don't need this
ul#footer li { padding: 10px }
Browsers manufacturers know an awful lot about their technology in particular and about typography and layout in general. A 'reset' is a great way of disposing of all that aggregated experience. Browser default behaviour is a good thing and should only be overwritten in exceptional circumstances. Different browsers do look a bit different. This is not a bad thing. See: http://dowebsitesneedtolookexactlythesameineverybrowser.com/
A copyright citation is not a paragraph of text. It is probably one among several items in a list of supporting information about the page in question. If not, it is a list of one.
Is there any way to control the order of which the GridView control renders it's thead, tbody and tfoot child elements?
According to W3C, the correct order is:
thead
tfoot
tbody
The GridView control renders out:
thead
tbody
tfoot
I am extending the GridView control, and I'm using the "first column controls the width of all columns" approach. But if the W3C specifications are not met (thead -> tfoot -> tbody) all hell breaks loose.
I've been reading up on this issue, and it seems that the GridView control has no support for this yet--it's planned though. Even so; I bet there must be some way to counter this sketchy implementation.
Any and all help apreciated.
If you need strict W3C Validation of your HTML (you must have a valid reason), you better not use ASP.net server controls, because you don't have any control on the HTML they generate.
I bet that this little problem is just the tip of the iceberg of the problems that you will find later.
I would imagine that any HTML generated by a Microsoft class will 100% definitely break validation and only work with it's Internet Explorer.
Write your own implementation - or find some Open Source class that will take care of it properly.
This is not yet possible. Although Microsoft is planning this feature for a future release.