The tabular structured layout using so-called blind tables is not very popular among web designers. They recommend instead Präsentierungselementen like
\u0026lt;table>
day as consistently as possible to work with semantic elements - such as
\u0026lt;label>
,
\u0026lt;fieldset>
or of course with the more general wildcard
\u0026lt;div>
and
\u0026lt;span>
.
following weaknesses of the
table-based layout for example, lead Rachel Andrew and Dan Shafer in their CSS-standard work [1]: Tables slow down the loading times. "- Here I miss a performance analysis that compares the rendering Times a blind table with those of a substitute that works only with semantic elements. Without even knowing one that I like to take a contrary position to that of a modern browser rendering Times falling for a blind table just as little weight as a similar Präsentierungskonstrukt based on CSS.
Tables care is a nightmare. "- it? If you have a nested table layout is not bottomless deep, it is possible to write down it in a readable form. Unfortunately, paid to the readability in the generated HTML code editors of little value. Because a good web designer but anyway the "blown" HTML code and preferred HTML editor avoids like the plague, I see here is not really a problem. On the other hand moves to finally complexity only when it is the HTML source code moved to the CSS: change orders, is not one way or another to have no expense. That the changes in a blind table, but fall so terribly significant, seems to me to be a propagandist exaggeration.
"tables cause problems with accessibility." -
It alleges that a screen reader for the blind is not visible Formatting elements of a table read. The blind man gets so listen to those used for visualization elements. I have not tested themselves, but think it if it is really so, for a problem of the screen reader! Such a program should be able to recognize only the code used to structure the presentation and not to read - unless the structure can also reproduce speech. not convinced me so all these arguments. The only argument I would accept would be this:
A table layout mixed up the content with the presentation of this content .-
The content is stored on the same site as the information about its visual representation. It would be flexible if you could separate the content from the presentation.
One could argue that we are already in HTML anyway Präsentierungslayer. But it is often found that even here the separation of content and presentation is still useful. The HTML document is readable, clear, if preparation of the information is relocated in the style sheet. Also can reuse the style sheet for other similar HTML documents.
If CSS in the present state of made this separation, I would be the first to use them! Unfortunately, the
, as far as I can see this is not the case.
To demonstrate this, I will once concrete and put a very simple, basic exercise to the web designer - as if you were to ask the rider if he can step on the gas.
The designer would draw your a form like the following to enter name, first name and e-mail address:
with table elements you have written down the form quickly, it could look like this :
\u0026lt;table id="adresse"> 
\u0026lt;caption> address data \u0026lt;/ caption>
<tr> \u0026lt;caption> address data \u0026lt;/ caption> <td class="label">Name</td>
- <td><input type="text" name="name"/></td>
- <tr>
<td class="label">Vorname</td> - <td><input type="text" name="vorname"/></td>
</tr> - <tr>
<td class="label">E-Mail-Adresse</td> - <td><input type = "text" name = "email "/>\u0026lt;/ td> \u0026lt;/ tr> \u0026lt;/ table> This is so determined that the input fields should all appear aligned with each other, and as their identifier . Breaks are controlled by switching to a new table row.
This code actually mixed presentation with content: what fields appear in which line is statically defined in the Code and therefore not from the actual page content separately. This is certainly not beautiful. Beautiful code with semantic elements would be, as the following: -
- \u0026lt;fieldset id="adresse">
\u0026lt;legend> address information \u0026lt;/ legend> - \u0026lt;label for="name"> Name \u0026lt;/ label> \u0026lt;input type="text"
id="name"/> - \u0026lt;label for = "first name" > first name \u0026lt;/ label> \u0026lt;input type="text"
id="vorname"/>
</tr>
\u0026lt;input type = "text" id = "email" /> \u0026lt;/ fieldset> Here we have really only content, and also the element name as label
and
fieldset
used to describe the semantics of the content. To access the style sheet (and JavaScript), there is next to the item name or an ID. More is not: No breaks, no alignment [2] But . Try again, to use the CSS2 usable today, so the above HTML code will appear as shown in the graph. A simple exercise, you see? Mind you, without the above code fragment \u0026lt;fieldset> Other HTML code to add: No auxiliary elements such as
\u0026lt;p/>
or \u0026lt;br/> to force a break (pure presentation, which must but go in the CSS!), not a "wrapper" divs or similar tricks. These are nothing but hacks for the presentation, who seek nothing in the content! Who needs to introduce a wrapper div, just so he wanted hinbekommt his presentation with CSS - without that the content requires it - finally makes nothing more than his predecessors, the evil transparent.gif inserting! And we find such pure Presentation Divs in CSS masters of every rank in the Web. As an unabashedly \u0026lt;div class="clear"/> is used, only because in the absence of such language CSS Div not possible to say that three consecutive elements are arranged in a row, but then a new line should begin: The three elements have to float with : Format left , and thus set the direction of flow must
clear: both
be reset (which the above CSS Classclear
would be assigned). What a wonderful separation of content and presentation! I just want to say: In its current form I do not think CSS mature and not appetizing enough to take over the Präsentierungslayer completely. And as long as that's the case, I'm in some cases (like the one above) with the table layout faster without any drawbacks compared with a CSS2 solution to have. In future versions of CSS may change that. But why not actually write like an XSL stylesheet that processes the following content and how you want the browser renders: \u0026lt;z:fieldset legend="Adressdaten"> \u0026lt;z:input name="name"> Name \u0026lt;z:input> \u0026lt;z:input name="firstname"> first name \u0026lt;z /: input> name="email"> e-mail address \u0026lt;z:input \u0026lt;/ z: input> \u0026lt; , / z: fieldset>
These newly-defined elements allow for a total reduction of document on the semantic level. The presentation takes the form of an XSLT program on the content and prepares it. Such an XSL style sheet can render, for example, the field group in the form of a table layout. If CSS then once so far is that simple tasks like this can be solved by simple means, only the XSL style sheet to be adjusted, but not the document that contains the content. XSLT processors are available in all browsers already on such a good state that it is no longer a problem to convert such elements on-the-fly in the browser (X) HTML. Where - for more complex sites - but should represent a performance problem, one can transform too - where it makes sense is buffered - running on the server. And the content is in this way really completely separate from the layout.
[1] Rachel Andrew, Dan Shafer: CSS - Challenging sites with Cascading Style Sheets
. 2. Dpunkt edition, Verlag, Heidelberg 2006th
[2] However, there is a arrangement : name comes before first name, and before the e-mail address. Changes to the arrangement in the HTML source code, this generally results in a change in the presentation (if not all elements are absolutely positioned via ID). Thus, the arrangement is in most cases, information in form präsentierungsrelevante
