WHATWG Wiki - User contributions [en]

Layout tables

2007-07-02T21:18:37Z

Brentonboy: /* Solution */

== Problem Description ==
A majority of HTML coders find the ease and simplicity of the table layout irrisistible, despite the fact that tables should only be used for tabular data.

CSS layouts are possible, however there are some things that are deterringly complicated to do with CSS layouts. Even among coders who validate their code and strive to meet the standards, table layouts are frequently resorted to because they offer the only solution.

== Solution ==
Create a new table type that is purely presentational. It has the ability to easily put expanding cells next to eachother and most of the other things that make tables so attractive.

However, it also has some unique features which make it purely presentational:

* Cells have the ability to break out of their rows under some circumstances.
** A table consisting of one row of four cells, when screenwidth is decreaced sufficiently, could become a single columned table with four rows of one cell each.
** Cells can also be marked as joined or linked, so that they do not break even when the width of the browser is decreased.
* Cells can be marked as presentational only: their contents would be completely removed or ignored in text only browsers or if styles are disabled.
* Browsers load the table one cell at a time, so that users do not have to wait for the last cell to load to see content in the first.
* Additional features inappropriate for tabular tables could be added.
** Improved cell spanning, similar to colspan or rowspan, allowing cells to span ''selectively'' creating non-rectangular shaped cells through designation to a common "span group".

Feature Proposals

2007-04-12T21:32:59Z

Brentonboy: /* Document Markup */

This document contains a list of the problems for which feature requests have been made. Linked problem pages contain the document of the problem and their relevant solutions. Obviously, we want to keep HTML as simple as possible. That means not everyone will get what they want. Having good documentation for the problems at hand will help all of us work out what is most important.

== Guidelines ==

Before proposing a feature, please read [http://blog.whatwg.org/proposing-features Proposing features]. If you want to add a feature request, start by copying the [[Problem Solving]] template page onto a new page and fill out as much information as you can.

You don't have to provide detailed answers for everything straight away. The most important information to provide at first is the problem description. Once we have detailed descriptions, use cases and an understanding of the limitations with existing markup, we can then begin to discuss the best way in which to address the problems and work out more of the more technical details.

== Document Markup ==
* [[Dialogue]]
* [[Annotation]]
* [[Footnotes]]
* [[Sidenotes]]
* [[Image Caption]]
* [[Inline Math]]
* [[Layout tables]]

== DOM Scripting ==
* [[Text in Canvas]]

== Security ==
* [[Link Hashes]]
* [[Digital Signatures]]

== Other ==

This list of features needs to be sorted out. They've come from all the [http://del.icio.us/lachlan.hunt/WHATWG feedback provided on blogs] over the past few weeks.

* Don't render quotation marks around <code>q</code> elements.
* Make form validation easier
** <code>required</code> attribute
** <code>maxlength</code> attribute for textarea
** <code>pattern</code> attribute
** <code>min</code>
** <code>max</code>
* New Form Controls
** Search fields
** Combo boxes
** Date/Time
** E-mail
** Int
** Long
** Unsigned
** Float
** Number
** Currency
** URL
* WYSIWIG Editor (<code>contentEditable</code>)
* Placeholder attribute
* Captions for images
* Bring back the <code>start</code> and <code>value</code> attributes for ordered lists.
* Bring back the <code>menu</code> element
* Require XHTML-link syntax for HTML
* Caption/label/list header for lists
* Include the <code>role</code> attribute.
* Allow <code>href</code> on all elements
* Make it easier to mark up blocks of code
* Allow block level elements inside paragraphs
* “a tag that could hold "bad grammar" and not have any effect on the validation (sort of like a document.write from JavaScript) and would terminate all unclosed items at the end of the element (like TDs tend to do).”
* <code>blink</code>!
* Fix the <code>object</code> element.
* Unify <code>img</code>, <code>object</code>, </code>embed</code> and <code>iframe</code> into a single element
* Headers and footers
* A mechanism to include content from an external source (e.g. <code>include</code>, perhaps like XInclude)
* A <code>corner</code> element (presumably for making rounded corners)
* Markup for advertisements
* Easier column layouts
* A <code>foot</code> element for containing scripts at the bottom of the page, or something to help deal with cross-browser load events.
* Key Generation/Certificate management (The <code>keygen</code> element)

Feature Proposals

2007-04-12T21:32:43Z

Brentonboy: /* Document Markup */

This document contains a list of the problems for which feature requests have been made. Linked problem pages contain the document of the problem and their relevant solutions. Obviously, we want to keep HTML as simple as possible. That means not everyone will get what they want. Having good documentation for the problems at hand will help all of us work out what is most important.

== Guidelines ==

Before proposing a feature, please read [http://blog.whatwg.org/proposing-features Proposing features]. If you want to add a feature request, start by copying the [[Problem Solving]] template page onto a new page and fill out as much information as you can.

You don't have to provide detailed answers for everything straight away. The most important information to provide at first is the problem description. Once we have detailed descriptions, use cases and an understanding of the limitations with existing markup, we can then begin to discuss the best way in which to address the problems and work out more of the more technical details.

== Document Markup ==
* [[Dialogue]]
* [[Annotation]]
* [[Footnotes]]
* [[Sidenotes]]
* [[Image Caption]]
* [[Inline Math]]
* [[Layout Tables]]

== DOM Scripting ==
* [[Text in Canvas]]

== Security ==
* [[Link Hashes]]
* [[Digital Signatures]]

== Other ==

This list of features needs to be sorted out. They've come from all the [http://del.icio.us/lachlan.hunt/WHATWG feedback provided on blogs] over the past few weeks.

* Don't render quotation marks around <code>q</code> elements.
* Make form validation easier
** <code>required</code> attribute
** <code>maxlength</code> attribute for textarea
** <code>pattern</code> attribute
** <code>min</code>
** <code>max</code>
* New Form Controls
** Search fields
** Combo boxes
** Date/Time
** E-mail
** Int
** Long
** Unsigned
** Float
** Number
** Currency
** URL
* WYSIWIG Editor (<code>contentEditable</code>)
* Placeholder attribute
* Captions for images
* Bring back the <code>start</code> and <code>value</code> attributes for ordered lists.
* Bring back the <code>menu</code> element
* Require XHTML-link syntax for HTML
* Caption/label/list header for lists
* Include the <code>role</code> attribute.
* Allow <code>href</code> on all elements
* Make it easier to mark up blocks of code
* Allow block level elements inside paragraphs
* “a tag that could hold "bad grammar" and not have any effect on the validation (sort of like a document.write from JavaScript) and would terminate all unclosed items at the end of the element (like TDs tend to do).”
* <code>blink</code>!
* Fix the <code>object</code> element.
* Unify <code>img</code>, <code>object</code>, </code>embed</code> and <code>iframe</code> into a single element
* Headers and footers
* A mechanism to include content from an external source (e.g. <code>include</code>, perhaps like XInclude)
* A <code>corner</code> element (presumably for making rounded corners)
* Markup for advertisements
* Easier column layouts
* A <code>foot</code> element for containing scripts at the bottom of the page, or something to help deal with cross-browser load events.
* Key Generation/Certificate management (The <code>keygen</code> element)

Layout tables

2007-04-12T21:31:10Z

Brentonboy: /* Solution */

Layout tables

2007-04-12T21:30:09Z

Brentonboy: /* Solution */

Layout tables

2007-04-12T21:29:03Z

Brentonboy: create article

Image Caption

2007-03-15T23:13:11Z

Brentonboy: /* Problem Description */

Image caption are often found on the web, but there is no standard markup for this.

== Problem Description ==
Currently, most people use either a table, custom class names, or simply put the image inside a paragraph, each option either conveying a wrong meaning or being ambiguous with the rest of the content.

An interesting analysis has been done on the subject by Dan Cederholm in one of his SimpleQuiz. [http://www.simplebits.com/notebook/2004/01/20/sqxi_conclusion.html His conclusion]:

<blockquote>So in this case, I might choose option A -- because visually it shows the relationship between the items better than the others. But I suppose this is bad semantics. Or maybe just another case where we don't have the 'perfect' set of defined elements for this (very) specific job.</blockquote>

And his option A was:
<pre>
<p><img scr="..."><br />
Caption Text</p>
</pre>

In other word, he could not figure out anything good using current elements available in HTML, and, as most people do, had to create his own solution.

Setting a standard for such things -- an explicit association between the caption and the illustration -- would help image search engines, it could enable the automatic creation of a figure index for a page. It would also be benificial for sight-impaired users. The fact that image captions should be treated differently to body text (they are not in the main flow of the document) suggests this element could be important for figure handling by assistive tools allowing e.g. aural browsers to skip captions except on explicit user request.

=== Current Methods and Workarounds ===
See [[Image Caption Examples]] for a couple of sample cases.

== Proposed Solutions ==

=== <figure> with <caption> ===
A <figure> element contains illustrative content for the current section. It can contain a <caption> element, either as the first or the last child, that will be used to describe or give a caption to the content of the figure.

<pre>
<figure>
<caption>Caption Text</caption>
<img src="...">
</figure>
</pre>

==== Processing Model ====
The processing model for HTML files must be changed so that the <caption> is no longer ignored when outside the context of a table. It could also be a good idea to add a new figure insertion mode that would prevent figure captions from being moved to the enclosing table when inside a table cell, otherwise <figure> will break in table-based layouts.

<pre>
<table>
<tr><td>
<figure>
<caption>Caption Text</caption>
<img src="...">
</figure>
</td></tr>
</table>
</pre>

==== Limitations ====
<caption> being ignored by current browsers when outside a table makes it impossible to style, and it'll also be terribly broken with table layouts when figure captions end up at the top (or the bottom) of the enclosing layout table.

==== Implementation ====
Parsing changes in this solution could be hard to implement given <caption> element's legacy within <table>.

Putting aside the parsing problem, there's not much else to implement for visual browsers. A good display model that could be used to display figures is already available in CSS 2.1:

<pre>
figure { display: table; }
caption { display: table-caption; }
</pre>

This would display the figure as a one-cell table, and the caption either at the top or at the bottom (depending on the [http://www.w3.org/TR/CSS21/tables.html#propdef-caption-side caption-side] property). The interesting part of this model is that the caption's width is constrained by the width of the figure, making it the ideal choice for floated figures.

==== Adoption ====
The syntax is pretty straightforward to use. "figure" and "caption" are commonly used terms to designate exactly this feature in the print world. It should be a natural choice to authors that wonder how to markup their images.

This markup won't work however if an author wants the caption to be elsewhere in the document. (In this proposal, <caption> is pinned to the figure's content.) It does not seem a common use case however.

=== <figure> with <legend> ===
A <figure> element contains illustrative content for the current section. It can contain a <legend> element, either as the first or the last child, that will be used to describe or give a caption to the content of the figure.

<pre>
<figure>
<legend>Caption Text</legend>
<img src="...">
</figure>
</pre>

==== Processing Model ====
:''To be completed''

==== Limitations ====
:''To be completed''

==== Implementation ====
A good display model that could be used to display figures is already available in CSS 2.1, the table model. A default stylesheet could look like this:

<pre>
figure { display: table; }
figure legend { display: table-caption; }
</pre>

This would display the figure as a one-cell table, and the figure legend either at the top or at the bottom (depending on the [http://www.w3.org/TR/CSS21/tables.html#propdef-caption-side caption-side] property). The interesting part of this model is that the legend's width is constrained by the width of the figure, making it the ideal choice for floated figures.

==== Adoption ====
"figure" and "legend" are commonly used terms in the print world, so their use could prove natural to authors. It is most likely that authors that need a markup for their figure will chose this one if it is sanctioned in a standard.

This markup won't work if an author wants the caption to be elsewhere in the document. (In this proposal, <legend> is pinned to the figure's content.) It does not seem a common use case however.

=== Adjacent <caption> or <legend> ===
<caption> or <legend> elements directly following a <img> element give the caption text for that image.

<pre>
<img src="...">
<caption>Caption Text</caption>
</pre>

<pre>
<img src="...">
<legend>Caption Text</legend>
</pre>

==== Processing Model ====
The processing model for HTML files must be changed so that the <caption> is no longer ignored when outside the context of a table. It could also be a good idea to add a new figure insertion mode that would prevent figure captions from being moved to the enclosing table when inside a table cell, otherwise <figure> will break in table-based layouts.

:''Are the elements in this construct inline or block-level content? Currently <img> is inline.''

If any other element, or non-whitespace text nodes are found between <img> and its corresponding caption element, elements are considered to not be adjacent, the semantic link is broken and it generates a parse error.

==== Limitations ====
<caption> being ignored by current browsers when outside a table makes it impossible to style, and it'll also be terribly broken with table layouts when captions end up at the top (or the bottom) of the enclosing layout table.

:''To be completed: <legend> parsing''

==== Implementation ====
Parsing changes in this solution could be hard to implement given <caption> element's legacy within <table>.

:''To be completed: <legend> parsing implementation''

Giving a distinctive visual style to figure captions may prove difficult with this design. If a browser wants to treat figures in a distinctive manner, it'll have treat them as a special case; the adjacent element selector in CSS can't distinguish between adjacent elements which are separated by text and those that are not.

==== Adoption ====
:''To be completed''

"legend" and "caption" are commonly used terms in the print world, so their use could prove natural to authors. Difficulties in styling are likely however to cause authors to always warp figures in a <div> element as most already do anyway (see [[Image Caption Examples]]).

This markup won't work if an author wants the caption to be elsewhere in the document. It does not seem a common use case however.

=== <label> defining attributes with nested markup ===
A <label> element holds a value which should be treated the same way like the title attribute on <img>, except that it can contain nested markup. The for attribute of the label contains the id of the target element. A new type attribute on the label indicates which attribute the label intend to replace on the target.

<pre>
<img id="img1" src="...">
<label for="img1" type="title">...</label>
</pre>

==== Processing Model ====
:''To be completed: Attribute override, progressive rendering, etc.''

==== Limitations ====
:''To be completed''

==== Implementation ====
:''To be completed''

==== Adoption ====
This markup has the benefit that it'll work if an author wants the caption to be elsewhere in the document.

:''To be completed''

[[Category:Feature Request]]