WHATWG Wiki - User contributions [en]

New Features Awaiting Implementation Interest

2012-11-22T00:56:30Z

Mjs: Fix Dean Jackson's affiliation

There are features that have been requested, but for which we are lacking implementor interest. Without two or more vendors interested in implementing the feature, they are unlikely to get added to the specs.

<table class="wikitable">
<tr><th rowspan=2>Feature <th colspan=6>Interest indicated by... <th rowspan=2>Comments
<tr><th>Mozilla (Firefox) <th>Opera <th>Microsoft (IE) <th>Apple (Safari) <th>Google (Chrome) <th>Others
<tr>
<td>[http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Jan/0082.html Progress events on IMG elements]
<td>[http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Jan/0195.html Jonas Sicking]
<td>
<td>
<td>[http://lists.webkit.org/pipermail/webkit-dev/2012-January/019182.html Dean Jackson]
<td>
<td>
<td>Will likely be added soon
<tr>
<td>[https://bugzilla.mozilla.org/show_bug.cgi?id=803124 Canvas: isPointInStroke]
<td>[http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Nov/0148.html Jeff Muizelaar]
<td>
<td>
<td>
<td>
<td>
<td>
<tr>
<td>[https://bugzilla.mozilla.org/show_bug.cgi?id=655926 Canvas: fillRule]
<td>[http://lists.w3.org/Archives/Public/public-whatwg-archive/2011Jun/0123.html Chris Jones]
<td>
<td>
<td>
<td>
<td>
<td>
<tr>
<td>[[AllowSeamless|Cross-origin seamless iframes]]
<td>
<td>
<td>
<td>
<td> Adam Barth
<td>
<td>
<tr>
<td>[http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Nov/0272.html A method to trigger autofill]
<td>
<td>
<td>
<td>
<td> [http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Oct/0231.html Elliott Sprehn], [http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Nov/0289.html Peter Kasting]
<td>
<td>
<tr>
<td>The <menu> feature with many elements providing commands
<td>''Negative interest''
<td>
<td>
<td>
<td>
<td>
<td>Will likely be dropped if no interest is indicated
<tr>
<td>[[FormData]]
<td>
<td>
<td>
<td>
<td>
<td>
<td>
<tr>
<td>[http://lists.w3.org/Archives/Public/public-whatwg-archive/2010Jul/0238.html Canvas: Stroke alignment]
<td>
<td>
<td>
<td>
<td>
<td>
<td>
</table>

Getting started with browser development

2012-05-16T17:47:51Z

Mjs: /* Webkit */

{{stub}}

= Getting started with browser development =
Want to get started with browser development, e.g. help implement HTML?

== General Approaches ==
* finding and filing bugs to various browsers' bug databases is a great way to get involved

== Specific Browser Engines ==
Help with the development of specific browser engines. (alphabetical, please feel free to add/insert more).

=== Gecko ===
Gecko powers the Firefox browser.
* http://www.mozilla.org/contribute
* https://developer.mozilla.org/en/Introduction

=== Presto ===
Opera uses the Presto engine.
* http://opera.jobs/

=== Webkit ===
Webkit is used by Safari, Chrome, and recent BlackBerry browsers.
* http://www.webkit.org/building/checkout.html
* http://www.webkit.org/building/build.html
* http://www.webkit.org/coding/contributing.html
* http://www.webkit.org/quality/reporting.html
* http://www.webkit.org/quality/testwriting.html
* http://jobs.apple.com/ - search for WebKit

== See Also ==
* [[Specs]]

Dialogs

2011-06-23T07:22:18Z

Mjs: /* Lightboxes */

= Problem statement =

There's no markup or API for dialog boxes, tool palettes, hovering tooltips, the contents of popup widgets, and the like.

== Real world examples today ==

=== Dialogs ===

==== Registration Dialogs ====

* http://www.reddit.com/ - make sure to be logged out if you have an account, and click the register link
* http://digg.com/ - make sure to be logged out if you have an account, and click the Join Digg! button
* http://slashdot.org/ - make sure to be logged out if you have an account, and click the Join link

==== Login Dialogs ====

* http://slashdot.org/ - make sure to be logged out if you have an account, and click the Log In link
* http://digg.com/ - make sure to be logged out if you have an account, and click the Login button
* http://newsvine.com/ - make sure to be logged out if you have an account, and click the Log In | Register link
* http://www.bahn.de/ - Login link is rightmost in main navigation bar - try tapping: funny handling of focus order, skipping positions, at times keyboard trap

=== Other Dialogs ===

* http://www.kongregate.com/ - register for account, log in, click Get Kreds, click Fund Your Account button
* GMail - Click "more" on the left, then Create New Label.

=== Tooltips ===

* The tooltips in the table of [http://bioinfo-prod.mpl.ird.fr/xantho/x.org/gui/seqterm.php] are interesting because they are currently <div>s and force the parent to be a TD rather than a TH since TH is inline only, even though the visible content is really just phrasing content.

* GMail's contacts list has rich tooltips.

=== Lightboxes ===

* http://www.flickr.com/photos/christina_stasia/5317650777/in/pool-44124373027@N01/ - click on the magnifying glass icon in the top toolbar.
* http://trailers.apple.com/trailers/independent/therift/ - click "View Trailers" and then "Teaser" - video lightbox, many other examples on trailers.apple.com
* http://warmetal.wikia.com/wiki/Aegis - click on the picture of the card

=== Other ===

A list of URLs from Steve Faulkner to look at — if anyone has the time to go through these and pick out those that are real use cases (as opposed to demos or examples, since those tend to not reflect real needs but more reflect what's easy to demo!) then please add them where appropriate above.

http://flowplayer.org/tools/overlay/index.html
http://alloy.liferay.com/deploy/demos/dialog/
http://www.bbc.co.uk/glow/docs/1.5/furtherinfo/widgets/overlay/
http://rightjs.org/ui/dialog/demo
http://jqueryui.com/demos/dialog/
http://download.dojotoolkit.org/release-0.4.2/dojo-0.4.2p1-widget/tests/widget/test_Dialog.html
http://www.sencha.com/examples/pages/window/hello.html
http://www.sencha.com/examples/pages/window/dialog.html
http://www.sencha.com/examples/pages/window/accordion.html
http://dev.sencha.com/deploy/ext-4.0.2a/examples/window/window.html
http://leandrovieira.com/projects/jquery/lightbox/
http://www.huddletogether.com/projects/lightbox/
http://developer.yahoo.com/yui/examples/container/panel.html
http://reghellin.com/milkbox/
http://bertramakers.com/moolabs/imagezoom.php
http://www.aryweb.nl/projects/MooDialog/

== Code Examples ==
=== Reddit ===

HTML:
<pre>
<a href="#" onclick="return showcover(false);">register</a>
...
<div class="login-popup cover-overlay" style="display: none; "
<div class="cover" onclick="return hidecover(this)"></div>
<div class="popup">
...
</div>
</div>
</pre>

Javascript:
<pre>
function showcover(a, b) {
$(".login-popup:first").show().find('form input[name="reason"]').val(b || "");
return !1
}
function hidecover(a) {
$(a).parents(".cover-overlay").hide();
return !1
}
</pre>
(showcover() has been truncated to remove code not relevant to showing the dialog: if variable a is set as 'true', another element (not found in this page) is also shown)

CSS:
<pre>
.popup {
position: fixed;
left: 10%;
background-color: white;
top: 40px;
width: 80%;
z-index: 1001;
}
.cover {
position: fixed;
top: 0px;
left: 0px;
height: 100%;
width: 100%;
background-color: gray;
opacity: .7;
z-index: 1000;
}
</pre>

=== Slashdot ===
HTML:
<pre>
<div id="modal_cover" class="push" onclick="hide_modal_box(); return false;" style="display: none;"></div>
<div id="modal_box" class="push" style="display: none;">
...
<div id="modal_box_content">...</div>
</div>

<a href="//slashdot.org/my/newuser" onclick="javascript:getModalPrefs('newUserModal', 'Create Account', 1); $('#modal_box').addClass('join'); return false;" class="btn link">Join</a>
</pre>

Javascript: (getModalPrefs has been truncated to remove code not relevant to showing the dialog)
<pre>
function getModalPrefs(section, title, tabbed, params) {
Slash.busy(BUSY_FETCHING_MODAL, true);
$bg = get_modal_parts('#modal_cover').css('opacity', 0.75).show();
$any('modal_box_content').load('/ajax.pl', $.extend({op: this_op,section: section,reskey: reskey_static,tabbed: tabbed,return_to: return_to}, params || null), function(response, status, transport) {
if (status === 'success') {
$any('preference_title').html(title);
var $modal = show_modal_box().data('tabbed', tabbed);
tabbed && $modal.addClass("tabbed");
} else {
$bg.hide();
}
Slash.busy(BUSY_FETCHING_MODAL, false);
});
}

function show_modal_box() {
return custom_modal_box('show').keyup(function(e) {
e.which == $.ui.keyCode.ESCAPE && hide_modal_box();
});
}

function hide_modal_box() {
var retainclass = " ";
if ($('#modal_box').hasClass('push')) {
retainclasses = 'push';
}
custom_modal_box('hide').hide().attr('style', 'display: none;').removeClass().addClass(retainclasses).removeData('tabbed').unbind();
if (document.forms.modal_prefs && document.forms.modal_prefs.refresh_onclose && document.forms.modal_prefs.refresh_onclose.value) {
document.location = document.URL;
}
return false;
}
</pre>

CSS:
<pre>
#modal_box.join {
margin: 0px 33% 0;
width: 390px;
height: 440px;
}
#embbeded_login_modal.push, #modal_box.push {
margin-top: 9em !important;
}
#modal_box {
position: fixed;
z-index: 1000001;
}
#modal_cover {
margin-top: -12px;
margin-left: -13px;
background: rgba(0, 0, 0, .6);
height: 100%;
position: fixed;
width: 100%;
z-index: 1000000;
}
</pre>

===DB Dahn===
HTML:
<pre>
<li id="mn-login" class="rollover">
<a href="https://fahrkarten.bahn.de/privatkunde/start/start.post?lang=de&scope=login" id="login" class="jhover" rel="nofollow"><span>Login</span></a>
<h3><span>Login</span></h3>
<ul>...</ul>
</li>
</pre>

If #mn-login is given class of rollover (done using javascript on focus and mouseover, removed on blur, the h3 and ul tags are displayed in CSS:
<pre>
#main-nav ul ul, #main-nav ul h3 {
border: 1px solid #9FA3AB;
display: none;
left: -9999em;
position: absolute;
}
#main-nav li#mn-login.rollover h3 {
left: -6px;
}
#main-nav li#mn-login.rollover ul {
left: auto;
right: 6px;
}
</pre>

[[Category:Proposals]]

Dialogs

2011-06-23T07:19:17Z

Mjs: /* Lightboxes */

= Problem statement =

There's no markup or API for dialog boxes, tool palettes, hovering tooltips, the contents of popup widgets, and the like.

== Real world examples today ==

=== Dialogs ===

==== Registration Dialogs ====

* http://www.reddit.com/ - make sure to be logged out if you have an account, and click the register link
* http://digg.com/ - make sure to be logged out if you have an account, and click the Join Digg! button
* http://slashdot.org/ - make sure to be logged out if you have an account, and click the Join link

==== Login Dialogs ====

* http://slashdot.org/ - make sure to be logged out if you have an account, and click the Log In link
* http://digg.com/ - make sure to be logged out if you have an account, and click the Login button
* http://newsvine.com/ - make sure to be logged out if you have an account, and click the Log In | Register link
* http://www.bahn.de/ - Login link is rightmost in main navigation bar - try tapping: funny handling of focus order, skipping positions, at times keyboard trap

=== Other Dialogs ===

* http://www.kongregate.com/ - register for account, log in, click Get Kreds, click Fund Your Account button
* GMail - Click "more" on the left, then Create New Label.

=== Tooltips ===

* The tooltips in the table of [http://bioinfo-prod.mpl.ird.fr/xantho/x.org/gui/seqterm.php] are interesting because they are currently <div>s and force the parent to be a TD rather than a TH since TH is inline only, even though the visible content is really just phrasing content.

* GMail's contacts list has rich tooltips.

=== Lightboxes ===

* http://www.flickr.com/photos/christina_stasia/5317650777/in/pool-44124373027@N01/ - click on the magnifying glass icon in the top toolbar.
* http://trailers.apple.com/trailers/independent/therift/ - click "View Trailers" and then "Teaser" - video lightbox, many other examples on trailers.apple.com

=== Other ===

A list of URLs from Steve Faulkner to look at — if anyone has the time to go through these and pick out those that are real use cases (as opposed to demos or examples, since those tend to not reflect real needs but more reflect what's easy to demo!) then please add them where appropriate above.

http://flowplayer.org/tools/overlay/index.html
http://alloy.liferay.com/deploy/demos/dialog/
http://www.bbc.co.uk/glow/docs/1.5/furtherinfo/widgets/overlay/
http://rightjs.org/ui/dialog/demo
http://jqueryui.com/demos/dialog/
http://download.dojotoolkit.org/release-0.4.2/dojo-0.4.2p1-widget/tests/widget/test_Dialog.html
http://www.sencha.com/examples/pages/window/hello.html
http://www.sencha.com/examples/pages/window/dialog.html
http://www.sencha.com/examples/pages/window/accordion.html
http://dev.sencha.com/deploy/ext-4.0.2a/examples/window/window.html
http://leandrovieira.com/projects/jquery/lightbox/
http://www.huddletogether.com/projects/lightbox/
http://developer.yahoo.com/yui/examples/container/panel.html
http://reghellin.com/milkbox/
http://bertramakers.com/moolabs/imagezoom.php
http://www.aryweb.nl/projects/MooDialog/

== Code Examples ==
=== Reddit ===

HTML:
<pre>
<a href="#" onclick="return showcover(false);">register</a>
...
<div class="login-popup cover-overlay" style="display: none; "
<div class="cover" onclick="return hidecover(this)"></div>
<div class="popup">
...
</div>
</div>
</pre>

Javascript:
<pre>
function showcover(a, b) {
$(".login-popup:first").show().find('form input[name="reason"]').val(b || "");
return !1
}
function hidecover(a) {
$(a).parents(".cover-overlay").hide();
return !1
}
</pre>
(showcover() has been truncated to remove code not relevant to showing the dialog: if variable a is set as 'true', another element (not found in this page) is also shown)

CSS:
<pre>
.popup {
position: fixed;
left: 10%;
background-color: white;
top: 40px;
width: 80%;
z-index: 1001;
}
.cover {
position: fixed;
top: 0px;
left: 0px;
height: 100%;
width: 100%;
background-color: gray;
opacity: .7;
z-index: 1000;
}
</pre>

=== Slashdot ===
HTML:
<pre>
<div id="modal_cover" class="push" onclick="hide_modal_box(); return false;" style="display: none;"></div>
<div id="modal_box" class="push" style="display: none;">
...
<div id="modal_box_content">...</div>
</div>

<a href="//slashdot.org/my/newuser" onclick="javascript:getModalPrefs('newUserModal', 'Create Account', 1); $('#modal_box').addClass('join'); return false;" class="btn link">Join</a>
</pre>

Javascript: (getModalPrefs has been truncated to remove code not relevant to showing the dialog)
<pre>
function getModalPrefs(section, title, tabbed, params) {
Slash.busy(BUSY_FETCHING_MODAL, true);
$bg = get_modal_parts('#modal_cover').css('opacity', 0.75).show();
$any('modal_box_content').load('/ajax.pl', $.extend({op: this_op,section: section,reskey: reskey_static,tabbed: tabbed,return_to: return_to}, params || null), function(response, status, transport) {
if (status === 'success') {
$any('preference_title').html(title);
var $modal = show_modal_box().data('tabbed', tabbed);
tabbed && $modal.addClass("tabbed");
} else {
$bg.hide();
}
Slash.busy(BUSY_FETCHING_MODAL, false);
});
}

function show_modal_box() {
return custom_modal_box('show').keyup(function(e) {
e.which == $.ui.keyCode.ESCAPE && hide_modal_box();
});
}

function hide_modal_box() {
var retainclass = " ";
if ($('#modal_box').hasClass('push')) {
retainclasses = 'push';
}
custom_modal_box('hide').hide().attr('style', 'display: none;').removeClass().addClass(retainclasses).removeData('tabbed').unbind();
if (document.forms.modal_prefs && document.forms.modal_prefs.refresh_onclose && document.forms.modal_prefs.refresh_onclose.value) {
document.location = document.URL;
}
return false;
}
</pre>

CSS:
<pre>
#modal_box.join {
margin: 0px 33% 0;
width: 390px;
height: 440px;
}
#embbeded_login_modal.push, #modal_box.push {
margin-top: 9em !important;
}
#modal_box {
position: fixed;
z-index: 1000001;
}
#modal_cover {
margin-top: -12px;
margin-left: -13px;
background: rgba(0, 0, 0, .6);
height: 100%;
position: fixed;
width: 100%;
z-index: 1000000;
}
</pre>

===DB Dahn===
HTML:
<pre>
<li id="mn-login" class="rollover">
<a href="https://fahrkarten.bahn.de/privatkunde/start/start.post?lang=de&scope=login" id="login" class="jhover" rel="nofollow"><span>Login</span></a>
<h3><span>Login</span></h3>
<ul>...</ul>
</li>
</pre>

If #mn-login is given class of rollover (done using javascript on focus and mouseover, removed on blur, the h3 and ul tags are displayed in CSS:
<pre>
#main-nav ul ul, #main-nav ul h3 {
border: 1px solid #9FA3AB;
display: none;
left: -9999em;
position: absolute;
}
#main-nav li#mn-login.rollover h3 {
left: -6px;
}
#main-nav li#mn-login.rollover ul {
left: auto;
right: 6px;
}
</pre>

[[Category:Proposals]]

Dialogs

2011-06-23T07:16:13Z

Mjs: /* Login Dialogs */

= Problem statement =

There's no markup or API for dialog boxes, tool palettes, hovering tooltips, the contents of popup widgets, and the like.

== Real world examples today ==

=== Dialogs ===

==== Registration Dialogs ====

* http://www.reddit.com/ - make sure to be logged out if you have an account, and click the register link
* http://digg.com/ - make sure to be logged out if you have an account, and click the Join Digg! button
* http://slashdot.org/ - make sure to be logged out if you have an account, and click the Join link

==== Login Dialogs ====

* http://slashdot.org/ - make sure to be logged out if you have an account, and click the Log In link
* http://digg.com/ - make sure to be logged out if you have an account, and click the Login button
* http://newsvine.com/ - make sure to be logged out if you have an account, and click the Log In | Register link
* http://www.bahn.de/ - Login link is rightmost in main navigation bar - try tapping: funny handling of focus order, skipping positions, at times keyboard trap

=== Other Dialogs ===

* http://www.kongregate.com/ - register for account, log in, click Get Kreds, click Fund Your Account button
* GMail - Click "more" on the left, then Create New Label.

=== Tooltips ===

* The tooltips in the table of [http://bioinfo-prod.mpl.ird.fr/xantho/x.org/gui/seqterm.php] are interesting because they are currently <div>s and force the parent to be a TD rather than a TH since TH is inline only, even though the visible content is really just phrasing content.

* GMail's contacts list has rich tooltips.

=== Lightboxes ===

* http://www.flickr.com/photos/christina_stasia/5317650777/in/pool-44124373027@N01/ - click on the magnifying glass icon in the top toolbar.

=== Other ===

A list of URLs from Steve Faulkner to look at — if anyone has the time to go through these and pick out those that are real use cases (as opposed to demos or examples, since those tend to not reflect real needs but more reflect what's easy to demo!) then please add them where appropriate above.

http://flowplayer.org/tools/overlay/index.html
http://alloy.liferay.com/deploy/demos/dialog/
http://www.bbc.co.uk/glow/docs/1.5/furtherinfo/widgets/overlay/
http://rightjs.org/ui/dialog/demo
http://jqueryui.com/demos/dialog/
http://download.dojotoolkit.org/release-0.4.2/dojo-0.4.2p1-widget/tests/widget/test_Dialog.html
http://www.sencha.com/examples/pages/window/hello.html
http://www.sencha.com/examples/pages/window/dialog.html
http://www.sencha.com/examples/pages/window/accordion.html
http://dev.sencha.com/deploy/ext-4.0.2a/examples/window/window.html
http://leandrovieira.com/projects/jquery/lightbox/
http://www.huddletogether.com/projects/lightbox/
http://developer.yahoo.com/yui/examples/container/panel.html
http://reghellin.com/milkbox/
http://bertramakers.com/moolabs/imagezoom.php
http://www.aryweb.nl/projects/MooDialog/

== Code Examples ==
=== Reddit ===

HTML:
<pre>
<a href="#" onclick="return showcover(false);">register</a>
...
<div class="login-popup cover-overlay" style="display: none; "
<div class="cover" onclick="return hidecover(this)"></div>
<div class="popup">
...
</div>
</div>
</pre>

Javascript:
<pre>
function showcover(a, b) {
$(".login-popup:first").show().find('form input[name="reason"]').val(b || "");
return !1
}
function hidecover(a) {
$(a).parents(".cover-overlay").hide();
return !1
}
</pre>
(showcover() has been truncated to remove code not relevant to showing the dialog: if variable a is set as 'true', another element (not found in this page) is also shown)

CSS:
<pre>
.popup {
position: fixed;
left: 10%;
background-color: white;
top: 40px;
width: 80%;
z-index: 1001;
}
.cover {
position: fixed;
top: 0px;
left: 0px;
height: 100%;
width: 100%;
background-color: gray;
opacity: .7;
z-index: 1000;
}
</pre>

=== Slashdot ===
HTML:
<pre>
<div id="modal_cover" class="push" onclick="hide_modal_box(); return false;" style="display: none;"></div>
<div id="modal_box" class="push" style="display: none;">
...
<div id="modal_box_content">...</div>
</div>

<a href="//slashdot.org/my/newuser" onclick="javascript:getModalPrefs('newUserModal', 'Create Account', 1); $('#modal_box').addClass('join'); return false;" class="btn link">Join</a>
</pre>

Javascript: (getModalPrefs has been truncated to remove code not relevant to showing the dialog)
<pre>
function getModalPrefs(section, title, tabbed, params) {
Slash.busy(BUSY_FETCHING_MODAL, true);
$bg = get_modal_parts('#modal_cover').css('opacity', 0.75).show();
$any('modal_box_content').load('/ajax.pl', $.extend({op: this_op,section: section,reskey: reskey_static,tabbed: tabbed,return_to: return_to}, params || null), function(response, status, transport) {
if (status === 'success') {
$any('preference_title').html(title);
var $modal = show_modal_box().data('tabbed', tabbed);
tabbed && $modal.addClass("tabbed");
} else {
$bg.hide();
}
Slash.busy(BUSY_FETCHING_MODAL, false);
});
}

function show_modal_box() {
return custom_modal_box('show').keyup(function(e) {
e.which == $.ui.keyCode.ESCAPE && hide_modal_box();
});
}

function hide_modal_box() {
var retainclass = " ";
if ($('#modal_box').hasClass('push')) {
retainclasses = 'push';
}
custom_modal_box('hide').hide().attr('style', 'display: none;').removeClass().addClass(retainclasses).removeData('tabbed').unbind();
if (document.forms.modal_prefs && document.forms.modal_prefs.refresh_onclose && document.forms.modal_prefs.refresh_onclose.value) {
document.location = document.URL;
}
return false;
}
</pre>

CSS:
<pre>
#modal_box.join {
margin: 0px 33% 0;
width: 390px;
height: 440px;
}
#embbeded_login_modal.push, #modal_box.push {
margin-top: 9em !important;
}
#modal_box {
position: fixed;
z-index: 1000001;
}
#modal_cover {
margin-top: -12px;
margin-left: -13px;
background: rgba(0, 0, 0, .6);
height: 100%;
position: fixed;
width: 100%;
z-index: 1000000;
}
</pre>

===DB Dahn===
HTML:
<pre>
<li id="mn-login" class="rollover">
<a href="https://fahrkarten.bahn.de/privatkunde/start/start.post?lang=de&scope=login" id="login" class="jhover" rel="nofollow"><span>Login</span></a>
<h3><span>Login</span></h3>
<ul>...</ul>
</li>
</pre>

If #mn-login is given class of rollover (done using javascript on focus and mouseover, removed on blur, the h3 and ul tags are displayed in CSS:
<pre>
#main-nav ul ul, #main-nav ul h3 {
border: 1px solid #9FA3AB;
display: none;
left: -9999em;
position: absolute;
}
#main-nav li#mn-login.rollover h3 {
left: -6px;
}
#main-nav li#mn-login.rollover ul {
left: auto;
right: 6px;
}
</pre>

[[Category:Proposals]]

Bugzilla conventions

2011-06-19T01:35:32Z

Mjs: /* Resolutions */

These are the conventions used for bugs filed in the W3C Bugzilla for specs also maintained by the WHATWG.

== Subject prefixes ==

Some specific topics have prefixes in the bug summaries to help group the bugs.

;'''<video>'''
:bugs relating to <video>, <audio>, HTMLMediaElement, Controller, WebVTT, WebRTC (PeerConnection and Stream), and closely related topics.
;'''WF2:'''
:bugs relating to form controls.
;'''WF3:'''
:feature requests relating to form controls.

== Priorities and Severities ==

All bugs should be P2 or P3 by default. Bugs might get marked P1 by the W3C HTML WG chairs; bugs marked P1 by anyone else should be returned to P3. Bugs that are particularly minor might be marked P5. The priority field is "owned" by the chairs.

All bugs should be normal severity by default. Typos, grammar mistakes that don't affect normative status, and other such trivial matters can be marked "trivial". Feature requests should be marked "enhancement". Bugs that affect the parser algorithm should be marked "critical". Bugs that are immediately affecting implementors should be marked "blocker". "major" and "minor" are currently unused. The severity field is "owned" by the editor.

== Components ==

The bug filing system should automatically pick the right component. The components are pretty self-explanatory. WHATWG-specific issues should be moved to the "other Hixie drafts" component.

== Resolutions ==

The boilerplate used when resolving the bug comes from: http://lists.w3.org/Archives/Public/public-html/2009Oct/0680.html

The requirements for use of different resolutions are here:

http://dev.w3.org/html5/decision-policy/decision-policy-v2.html#bug-resolutions

== Helpful query links ==

* [http://goo.gl/Zh9tC List of all open and deferred HTML-related bugs]

Dialogs

2011-06-16T06:18:36Z

Mjs: /* Dialogs */

Dialogs

2011-06-16T05:28:24Z

Mjs: /* Login Dialogs */

Dialogs

2011-06-16T05:27:20Z

Mjs: /* Dialogs */

Dialogs

2011-06-16T05:26:05Z

Mjs: /* Registration Dialogs */

Dialogs

2011-06-16T05:24:22Z

Mjs: /* Dialogs */

Dialogs

2011-06-16T05:24:07Z

Mjs: /* Dialogs */

Dialogs

2011-06-16T05:22:15Z

Mjs: /* Problem statement */

= Problem statement =

There's no markup or API for dialog boxes, tool palettes, hovering tooltips, the contents of popup widgets, and the like.

== Real world examples today ==

=== Dialogs ===

=== Tooltips ===

* The tooltips in the table of [http://bioinfo-prod.mpl.ird.fr/xantho/x.org/gui/seqterm.php] are interesting because they are currently <div>s and force the parent to be a TD rather than a TH since TH is inline only, even though the visible content is really just phrasing content.

=== Lightboxes ===

[[Category:Proposals]]

Forking

2011-05-05T15:53:59Z

Mjs: Let's not make this too personal.

The purpose of this page is to summarize information and arguments relevant to whether it makes sense for web specification copyright licenses to permit [[Wikipedia:Fork (software development)|forking]].

For our purposes, there are two different approaches to forking.

: Language Forking
:: An alternative development path for the language created without using existing specification text as the basis of the work.
: Specification Forking
:: An alternative development path using existing specification text as the basis of a derivative work.

Since a ''language fork'' is not a derivative work according to copyright law, it may be done without the permission of the copyright holder. A ''specification fork'', however, requires a permissive licence or explicit permission from the copyright holder.

Standard licenses that permit specification forking include [https://creativecommons.org/publicdomain/zero/1.0/ CC0], the [http://opensource.org/licenses/mit-license.php MIT license], and the [http://www.opensource.org/licenses/bsd-license.php BSD licenses].

This page focuses on whether the W3C's HTML5 specification should allow forks, as the WHATWG version always has.

== Existing forks of HTML ==
(based on [http://krijnhoetmer.nl/irc-logs/whatwg/20110430#l-179 IRC comment]; possibly not everything here is strictly a fork, could use classification and explanation work)

=== W3C-hosted forks ===

* [http://www.w3.org/TR/xhtml-basic/ XHTML Basic]
* [http://www.w3.org/TR/1999/NOTE-html40-mobile-19990315/ HTML 4 Mobile]
* [http://www.w3.org/TR/xhtml2/ XHTML 2]
* [http://www.w3.org/TR/xhtml-print/ XHTML-Print]
* [http://dev.w3.org/html5/spec-author-view/ HTML5 Edition for Web Authors]
* [http://dev.w3.org/html5/markup/ HTML: The Markup Language]

=== W3C-published but disavowed forks ===

* [http://www.w3.org/TR/NOTE-Submission-HDML-spec.html HDML]
* [http://www.w3.org/TR/2002/NOTE-XHTMLplusSMIL-20020131/ XHTML+SMIL]
* [http://www.w3.org/TR/1998/NOTE-compactHTML-19980209/ CHTML]

=== Other forks ===

* [http://www.scss.tcd.ie/misc/15445/15445.html ISO HTML]: Diff spec.
* [http://www.openmobilealliance.org/tech/affiliates/wap/wap-277-xhtmlmp-20011029-a.pdf XHTML-MP]: Apparently no free download. Reportedly not widely used.
* [http://www.wapforum.org/what/technical.htm WML]: Apparently no free download. Reportedly very widely used and extremely harmful.
* [http://webapp.etsi.org/workprogram/Report_WorkItem.asp?WKI_ID=19886 WTVML]: Apparently no free download.
* [http://www.whatwg.org/specs/web-apps/current-work/multipage/ WHATWG HTML]: No comment.
* [http://www.ce.org/Standards/browseByCommittee_2757.asp CE-HTML]: Apparently only a preview is available for free, which contains almost nothing beyond the table of contents.
* [http://idpf.org/epub/30/spec/epub30-publications.html EPUB]: Diff spec.
* [http://html4all.org/HTMLDraft.html HTML 4.1]: Accessibility-oriented fork. Seems to attempt to respec from scratch, but it doesn't sound like it has anyone actually implementing it.

=== Not really forks ===
* [http://developers.whatwg.org HTML5 for Web developers]: A subset of WHATWG HTML.
* [http://w3c-test.org/html/tests/submission/PhilipTaylor/annotated-spec/canvas.html Philip Taylor's annotated canvas spec]: No normative differences, or at least isn't supposed to have normative differences.

== Organizational forks ==
One argument presented in favor of allowing forks is that if the W3C ever makes poor decisions that compromise the quality of its standards, other organizations should have the right to issue competing standards, with implementers agreeing to follow the better standard. When the W3C owns the right to large, established specifications that it doesn't permit others to fork, this becomes harder. Looking at cases where standards authors have abandoned an existing standards group to form their own should give an idea of whether this tends to be a good or bad thing.

=== W3C competing with IETF ===
The W3C itself was founded at least partly because Tim Berners-Lee felt that standardization at the IETF wasn't working well. As he writes in his book, [http://www.w3.org/People/Berners-Lee/Weaving/Overview.html ''Weaving the Web''] (pp. 62-3):

<blockquote>Progress in the [IETF's] URI working group was slow, partly due to the number of endless philosophical rat holes down which technical conversations would disappear. . . . Sometimes there was a core philosophy being argued, and from my point of view that was not up for compromise. Sometimes there was a basically arbitrary decision (like which punctuation characters to use) that I had already made, and changing it would only mean that millions of Web browsers and existing links would have to be changed.</blockquote>

In practice, the W3C has wound up cooperating with the IETF more than competing.

=== WHATWG competing with W3C ===
After HTML 4.01 was finalized in 1998, no new features were added to the HTML markup language other than in XHTML variants that browsers didn't implement. Thus HTML as a standard markup language did not progress at all between about 1998 and 2004. In 2004, Mozilla and Opera requested permission from the W3C to work on improving non-XML-based versions of HTML, and they were denied permission. Apple, Mozilla, and Opera then founded the WHATWG, which began work on a new version of the HTML specification outside the W3C. In a couple of years, the WHATWG rewrote the HTML standard from scratch, made it drastically more precise, and added many new highly-demanded features (such as video and canvas) that were previously only available through proprietary plugins. In 2007, the W3C formed an HTML Working Group again to work on non-XML-based versions of HTML, based on and in conjunction with the work of the WHATWG.

== Modularization ==

[http://www.w3.org/TR/xhtml-modularization/ XHTML Modularization] has the goal of "providing a means for subsetting and extending XHTML, a feature needed for extending XHTML's reach onto emerging platforms". Although this is not technically a fork (in the sense that it does not imply taking the W3C spec text and rewriting portions of it), the ability to create new HTML-derived specs that add or replace functionality carries many of the same risks that are brought up in the context of forking.

== Supposed risks of forking ==

* "A national government could create its own intentionally incompatible national version of the html specification in order to prevent general Web access from within that country": This argument is wrong at multiple levels:
** A national government could exempt itself from copyright anyway. Even [http://arstechnica.com/tech-policy/news/2008/08/air-force-cracks-software-carpet-bombs-dmca.ars the US government] does not consider itself bound by copyright law in all cases.
** A specification is only needed if there is a desire for multiple independent interoperable implementations, i.e., if competition is being encouraged. But what government would on the one hand encourage competition amongst browser vendors and on the other hand prevent those browser vendors from implementing other versions of HTML?
** In practice, it would be economically impractical to control the Web by developing a parallel HTML that is similar enough that the W3C spec could be used as a basis, but different enough that it is incompatible with the Web's HTML. In reality, countries use content filtering software to do such control (q.v., China).

* "Other undesirable forks could be for device specific variants of specs where it would be better for those groups to come into W3C [...] than to splinter html": When the W3C forks HTML (as it has in the past, see the list above), it is just as bad as when anyone else does. There is nothing special about the W3C here.
** In practice, vendors who want to add device-specific features commonly just add new features without forking the spec. For instance, Apple has made up its own [http://developer.apple.com/library/safari/#documentation/appleapplications/reference/safariwebcontent/configuringwebapplications/configuringwebapplications.html proprietary features] such as <meta name="apple-touch-icon"> and <meta name="apple-mobile-web-app-capable"> to allow web pages to integrate better with the iOS browser. Forking the whole HTML spec would be a waste of time.

== Advantages of allowing forking ==

* It encourages the W3C to do a good job, because of the risk that if the W3C does ''not'' do a good job, it will lose relevance. This has already been shown to be beneficial both to the W3C and the Web at large with HTML5 itself: the W3C tried to strongarm the Web into abandoning HTML, and when the WHATWG worked on it instead, the W3C changed its mind. This demonstrates the benefit of allowing forking (though in this case, it turns out copyright restrictions were not any kind of barrier to forking, because HTML4 wasn't good enough to be a useful starting point and we instead started from scratch).

== Reasons preventing forking is not necessary ==

* If the W3C is the best place to work on specs, then people will not need to fork, they'll just work on them at the W3C.

Forking

2011-05-02T08:52:36Z

Mjs: /* W3C-hosted forks */

The purpose of this page is to summarize information and arguments relevant to whether it makes sense for web specification copyright licenses to permit [[Wikipedia:Fork (software development)|forking]]. For our purposes, forking means the ability for a third party to redistribute modified versions of the specification without the permission of the copyright holders. Standard licenses that permit forking include [http://creativecommons.org/choose/zero/ CC0], the [http://opensource.org/licenses/mit-license.php MIT license], and the [http://www.opensource.org/licenses/bsd-license.php BSD licenses].

More specifically, this page focuses on whether the W3C's HTML5 specification should allow forks, as the WHATWG version always has.

== Existing forks of HTML ==
(based on [http://krijnhoetmer.nl/irc-logs/whatwg/20110430#l-179 IRC comment] by Maciej; possibly not everything here is strictly a fork, could use classification and explanation work)

=== W3C-hosted forks ===

* [http://www.w3.org/TR/xhtml-basic/ XHTML Basic]
* [http://www.w3.org/TR/1999/NOTE-html40-mobile-19990315/ HTML 4 Mobile]
* [http://www.w3.org/TR/xhtml2/ XHTML 2]
* [http://www.w3.org/TR/xhtml-print/ XHTML-Print]

=== W3C-published but disavowed forks ===

* [http://www.w3.org/TR/NOTE-Submission-HDML-spec.html HDML]
* [http://www.w3.org/TR/2002/NOTE-XHTMLplusSMIL-20020131/ XHTML+SMIL]
* [http://www.w3.org/TR/1998/NOTE-compactHTML-19980209/ CHTML]

=== Other forks ===

* [http://jp29.org/iso.htm ISO HTML]
* [http://www.openmobilealliance.org/tech/affiliates/wap/wap-277-xhtmlmp-20011029-a.pdf XHTML-MP]
* [http://www.wapforum.org/what/technical.htm WML] (apparently no free download)
* [http://webapp.etsi.org/workprogram/Report_WorkItem.asp?WKI_ID=19886 WTVML] (apparently no free download)
* [http://www.whatwg.org/specs/web-apps/current-work/multipage/ WHATWG HTML]
* [http://www.ce.org/Standards/browseByCommittee_2757.asp CE-HTML] (apparently only a preview available for free)
* [http://idpf.org/epub/30/spec/epub30-publications.html EPUB]
* [http://html4all.org/HTMLDraft.html HTML 4.1]

== Organizational forks ==
One argument presented in favor of allowing forks is that if the W3C ever makes poor decisions that compromise the quality of its standards, other organizations should have the right to issue competing standards, with implementers agreeing to follow the better standard. When the W3C owns the right to large, established specifications that it doesn't permit others to fork, this becomes harder. Looking at cases where standards authors have abandoned an existing standards group to form their own should give an idea of whether this tends to be a good or bad thing.

=== W3C competing with IETF ===
The W3C itself was founded at least partly because Tim Berners-Lee felt that standardization at the IETF wasn't working well. As he writes in his book, [http://www.w3.org/People/Berners-Lee/Weaving/Overview.html ''Weaving the Web''] (pp. 62-3):

<blockquote>Progress in the [IETF's] URI working group was slow, partly due to the number of endless philosophical rat holes down which technical conversations would disappear. . . . Sometimes there was a core philosophy being argued, and from my point of view that was not up for compromise. Sometimes there was a basically arbitrary decision (like which punctuation characters to use) that I had already made, and changing it would only mean that millions of Web browsers and existing links would have to be changed.</blockquote>

In practice, the W3C has wound up cooperating with the IETF more than competing.

=== WHATWG competing with W3C ===
After HTML 4.01 was finalized in 1998, no new features were added to the HTML markup language other than in XHTML variants that browsers didn't implement. Thus HTML as a standard markup language did not progress at all between about 1998 and 2004. In 2004, Mozilla and Opera requested permission from the W3C to work on improving non-XML-based versions of HTML, and they were denied permission. Apple, Mozilla, and Opera then founded the WHATWG, which began work on a new version of the HTML specification outside the W3C. In a couple of years, the WHATWG rewrote the HTML standard from scratch, made it drastically more precise, and added many new highly-demanded features (such as video and canvas) that were previously only available through proprietary plugins. In 2007, the W3C formed an HTML Working Group again to work on non-XML-based versions of HTML, based on and in conjunction with the work of the WHATWG.

== Supposed risks of forking ==

* "A national government could create its own intentionally incompatible national version of the html specification in order to prevent general Web access from within that country": This argument is wrong at multiple levels:
** A national government would not be bound by copyright anyway. Even [http://arstechnica.com/tech-policy/news/2008/08/air-force-cracks-software-carpet-bombs-dmca.ars the US government] does not consider itself bound by copyright law.
** A specification is only needed if there is a desire for multiple independent interoperable implementations, i.e., if competition is being encouraged. But what government would on the one hand encourage competition amongst browser vendors and on the other hand prevent those browser vendors from implementing other versions of HTML?
** In practice, it would be economically impractical to control the Web by developing a parallel HTML that is similar enough that the W3C spec could be used as a basis, but different enough that it is incompatible with the Web's HTML. In reality, countries use content filtering software to do such control (c.f. China).
** Whether the W3C allows forking or not, and even if we grant that a license could stop this, this scenario could already happen because the entire HTML spec is already under a liberal license at the WHATWG.

* "Other undesirable forks could be for device specific variants of specs where it would be better for those groups to come into W3C [...] than to splinter html": When the W3C forks HTML (as it has in the past, see the list above), it is just as bad as when anyone else does. There is nothing special about the W3C here.

== Advantages of allowing forking ==

* It encourages the W3C to do a good job, because of the risk that if the W3C does ''not'' do a good job, it will lose relevance. This has already been shown to be beneficial both to the W3C and the Web at large with HTML5 itself: the W3C tried to strongarm the Web into abandoning HTML, and when the WHATWG worked on it instead, the W3C changed its mind. This demonstrates the benefit of allowing forking (though in this case, it turns out copyright restrictions were not any kind of barrier to forking, because HTML4 wasn't good enough to be a useful starting point and we instead started from scratch).

== Reasons preventing forking is not necessary ==

* If the W3C is the best place to work on specs, then people will not need to fork, they'll just work on them at the W3C.

Specs

2011-01-25T09:38:08Z

Mjs: /* Infrastructure */

This wiki page lists all the specifications that a Web browser is likely to implement.

For each spec, link the spec's title to the most up to date draft (typically the editor's draft, for specs written in public; for specs written in secret, the latest published working draft), followed by a comma separated list of links in parentheses, named "feedback" for links to the current pending feedback, "discussion" for a link to the archives of the main relevant mailing list or to a page describing relevant mailing lists, "bugs" for a link to a bug system query showing the current open bugs. For specifications that are published in multiple forms, link to the most complete version (e.g. link to the one-page complete.html WHATWG spec rather than all the split-out W3C drafts).

See also: [[Companion specifications|Specs without editors]]

== Network Layer ==
* [http://tools.ietf.org/wg/httpbis/ HTTP]
** [http://tools.ietf.org/html/draft-ietf-websec-mime-sniff Media Type Sniffing]
** [http://tools.ietf.org/html/draft-ietf-httpstate-cookie Cookies]
* [http://tools.ietf.org/html/rfc0959 FTP]
* [http://tools.ietf.org/html/rfc5246 TLS]
* [http://tools.ietf.org/html/draft-ietf-websec-origin Origin]

== Infrastructure ==

* [http://www.unicode.org/versions/Unicode6.0.0/ Unicode]
* [http://dev.w3.org/2006/webapi/WebIDL/ WebIDL]
* [http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html DOM Core] ([http://lists.w3.org/Archives/Public/public-webapps/ discussion])
* [http://www.w3.org/TR/xml/ XML]
* [http://www.w3.org/TR/xml-names/ XMLNS]
* [http://www.w3.org/TR/xmlbase/ <code>xml:base</code>] ([http://lists.w3.org/Archives/Public/www-xml-linking-comments/ discussion])

== Media-Independent Features ==

* [http://www.whatwg.org/specs/web-apps/current-work/complete.html Web Applications 1.0] ([http://www.whatwg.org/issues/ feedback], [http://www.whatwg.org/mailing-list discussion], [http://www.w3.org/Bugs/Public/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&long_desc_type=allwordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&keywords_type=allwords&keywords=&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&emailassigned_to1=1&emailtype1=exact&email1=ian%40hixie.ch&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Last+Changed&field0-0-0=noop&type0-0-0=noop&value0-0-0= bugs])
* [http://html5.org/specs/dom-parsing.html DOM Parsing and Serialization]
* [http://html5.org/specs/dom-range.html DOM Range] ([http://www.w3.org/Bugs/Public/buglist.cgi?product=WebAppsWG&component=DOM%20Range&resolution=--- bugs])
* [https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/doc/spec/WebGL-spec.html WebGL]
* [http://monet.nag.co.uk/~dpc/draft-spec/ MathML] ([http://lists.w3.org/Archives/Public/www-math/ discussion])
* [http://dev.w3.org/2006/webapi/clipops/clipops.html Clipboard] (cut/copy/paste; [http://lists.w3.org/Archives/Public/public-webapps/ discussion])

== Media-Specific Layer ==

* [http://www.w3.org/TR/CSS21/ CSS] ([http://lists.w3.org/Archives/Public/www-style/latest discussion])
** [http://dev.w3.org/csswg/css3-color/ CSS Color]
* [http://www.w3.org/Graphics/GIF/spec-gif89a.txt GIF]
* [http://www.w3.org/TR/PNG/ PNG]
* [http://www.w3.org/TR/SVG/ SVG]
* [http://people.mozilla.org/~cmccormack/anim-timing/Overview.html Timing control for script-based animations] ([irc://irc.freenode.net/whatwg discussion])

Iframe Sandbox

2010-08-26T02:46:28Z

Mjs: /* use cases */

{{stub}}

= iframe sandbox attribute =

This page is for collecting issues and proposals related to the new <code><iframe></code> <code>sandbox</code> attribute.

== proposal drop sandbox attribute ==

The new 'sandbox' feature on <code><iframe></code> should be considered for removal.

In speaking with fellow developers at Mozilla, I've collected the following feedback:

* The sandbox feature and functionality needs a thorough security review.
* It will be a lot of work to implement properly.
* It may not actually solve the problem it is intending to solve.

— [[User:Tantek|Tantek]] 01:56, 2 August 2010 (UTC)

=== opinions and discussion ===
* +1 [[User:Tantek|Tantek Çelik]]
* -1 [http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-August/027484.html Ian Fette]
* -1 [http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-August/027485.html Adam Barth]
* -1 [http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-August/027491.html Maciej Stachowiak]
* -1 [[User:EdwardOConnor|EdwardOConnor]] - While I'm put off by the syntax (markup in attribute values looks quite gross), I think the feature is needed and the design certainly meets the need.
* ...

== why sandbox should be kept ==
=== implementation experience ===
[http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-August/027491.html Per Maciej], support for the new 'sandbox' feature on <code><iframe></code> is "shipping in current versions of Safari and Chrome."

The initial patch implementing it for WebKit can be seen here: http://trac.webkit.org/changeset/51577.

This patch was 100k, but more than half of it is tests and the ChangeLog entry.

=== security ===
"There's been a lot of security review, both on this list and in the W3C HTML WG. I've been meaning to write up a summary of all the discussion, but I haven't gotten around to it yet. We ended up tweaking a few aspects, but generally the design seems solid." — [http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-August/027485.html Adam Barth 2010-08-01]

Also [http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-August/027491.html from Maciej]:
Security experts have reviewed it (which security experts? links?). 'sandbox' itself seems pretty solid, although there are possibly issues with related features such as text/html-sandboxed and 'seamless' attribute.

While more security review is always welcome, it seems like the basic idea is solid, and it's demonstrably implementable.

=== examples in the wild ===
[http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-August/027491.html Per Maciej], Content has been built using it.

Which content? URLs to examples in the wild?

- At one point, <iframe sandbox> was used by Google Image Search to prevent framebusting by enframed content. However, I believe it is currently disabled since it prevents plugins from working.

=== use cases ===
[http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-August/027491.html Per Maciej], while it's unclear if <iframe sandbox> will work well for comments or other such cases of seamless untrusted content, it seems clearly useful for use cases like:
* gadgets
* ads

Examples? Could someone provide code examples of how <iframe sandbox> could be used for gadgets or ads or other use cases?

Not a full worked example, but embeding an gadget like this, in combination with postMessage, is safer than a vanilla iframe:

<source lang=html>
<iframe sandbox="allow-scripts allow-same-origin" src="http://external.server.com/gadget.html"<</iframe>
</source>

It prevents the framed content from being able to navigate the top level, among other things.

If the allow-same-origin flag is left off, then the gadget can even be hosted on the same site as the embedding content, but would still be isolated from DOM access and network access to the site's resources. In this case it would need to be used in combination with srcdoc or with the text/html-sandboxed MIME type to give sound security.

Iframe Sandbox

2010-08-26T02:37:41Z

Mjs: /* examples in the wild */

Change Proposal: figure and details

2010-01-12T01:31:13Z

Mjs: /* Proposal Details */

== Summary ==
The current HTML5 draft uses the dt and dd elements to markup the captions and content of the figure and details elements. This change proposal explains why the dt and dd elements are a poor choice for these purposes and proposes an alternative.
----
== Rationale Against Using dt/dd for figure and details Elements ==

=== Backwards Compatibility ===
Due to IE's legacy parsing issues, the dt and dd elements create problems for authors attempting to use and style these elements. The simplest workaround (wrapping both figure and details in an extra div) that authors would need to apply to avoid these issues is not intuitive, as clearly demonstrated by the wide range of alternative solutions that were attempted prior to its discovery.

=== Legacy Cruft ===
The use of extra div elements may lead to a lot of confusion among authors, at least initially, and ultimately end up becoming extraneous markup that authors just include without really understanding why, even after the current generation of browsers are long since dead.

We've seen this kind of problem before with authors, for example, frequently wrapping scripts with pseudo-HTML-comments initially intended to hide the script from what are now very ancient browsers, none of which have been in use for over a decade.

=== Styling Clashes ===
In addition to the aforementioned styling bug in IE, many existing stylesheets already include styles for the dt and dd elements, used in description lists (dl elements). Authors attempting to incorporate figure or details into their existing pages would have to take care to avoid unintended styling clashes caused by selectors that aren't specific enough. i.e. It's common for authors to simply use the selector as "dt" or "dd", rather than "dl>dt" and "dl>dd", as that is currently unnecessary. Authors will then have to adjust their styles, which could potentially cause unintended side affects to to the change in specificity of the selectors.

=== Default Styles ===
The default styles for dt and dd elements is not ideal for figures. As the dd element is usually indented with margin and/or padding, authors will usually be required to remove this with their own stylesheets, rather than being able to rely on more sensible defaults. It is true that eventually UA stylesheets may have special rules for "figure > dt" and the like, but during the transition period it will be extra work to remove inappropriate default styles.

=== Structural Differences ===
Since authors are already familiar with the meanings and structure of dt and dd when used within dl, their very distinct meanings and structure when used within the figure and details may be confusing to authors.

The dl element may contain multiple groups of dt and dd elements, wheres within figure and details, each element may only be used once.

Within dl, a group must have one or more dt elements followed by one or more dd elements, whereas within figure, the elements may appear in any order.

=== Semantic Differences ===
For the figure element, it's not very intuitive to determine which of either dt or dd represents the caption and which represents the content such as an image. Some authors may interpret dd as being the description, which is what it means within dl, and thus assume that dd is meant for the caption, and the dt meant for the image or other content. However, the spec defines these with the opposite meanings, with the understanding the dt, or title, is a synonym for caption. Both alternatives points of view make some sense, but neither stands out as being obviously correct. This will likely lead to a lot of authors using these elements in reverse.

=== Unnecessary Elements ===
The dd element is completely unnecessary to distinguish it from the caption, which has its own element. This combined with the extraneous div required for IE compatibility adds two extra elements that are not logically needed. A previous iteration of the spec used the legend element for the caption, without any special wrapper just for the content. This model seems much more intuitive and required less markup to use, and thus easier to get right. Authors who do wish to have an extra wrapper around the content may use div if they choose, but should not be required to use it.

When there is no caption, using figure then requires authors to use 3 extra elements, where they should only need one:

<div> 
<figure>
<dd><img src="image" alt="..."></dd>
</figure>
</div>

This will be unappealing to authors who may, as a result of the complexity, opt not to use the figure element.

=== Aesthetics ===
Aesthetics is not necessarily the sole or most important concern. However, many authors seem to find the novel use of dt and dd unpleasant to read. dt and dd are relatively obscure elements, they are very short abbreviations, and their meaning in context is unclear, especially in figure. In particular, the following markup seems mysterious and strikes many as ugly and unintuitive:

<figure>
<dd><img src="image" alt="..."></dd>
<dt>A Pair of Cats</dd>
</figure>

This seems to trigger a "yuck factor", and it would be wise to avoid that. Aesthetics may seem like a relatively unimportant factor; however, the desire to avoid introducing new elements that led to dt/dd being used is itself largely an aesthetic concern.

----

== Proposal 1 (<code><figure><legend>...</legend>...</figure>; <details><legend>...</legend>...</details></code>) ==
The proposal is to restore the use of the legend element for marking up the captions within both figure and details elements.

== Proposal 2 (<code><figure><c>...</c>...</figure>; <details><c>...</c>...</details></code>) ==
The proposal is to introduce a new c element for marking up the captions within both figure and details elements.

== Proposal 3 (<code><figure><fcaption>...</fcaption>...</figure>; <details><dlabel>...</dlabel>...</details></code>) ==

=== Summary ===
The current HTML5 draft uses the dt and dd elements to markup the captions and content of the figure and details elements. This change proposal explains why the dt and dd elements are a poor choice for these purposes and proposes an alternative. Specifically, the proposal is to introduce a new fcaption element for marking up the caption within figure, and a dlabel element for use within details. The content portions of these elements (as opposed to the caption or label) would not have any special markup, they would be nested directly inside the figure or details element.

=== Additional Rationale ===

In addition to the rationale relative to the status quo in the spec, this proposal is better than some of the proposed alternatives.

==== Follows HTML Precedent for Structured Elements ====

Some HTML elements have relatively free content models, while others are "structured" - there are some or all child elements that have special meaning. Structured elements typically have helper elements that are specific to one element, or to a small family of related elements, to express their internal structure. Examples, from past versions of HTML, new in HTML5, and proposed for future versions of HTML:

* table has thead, tfoot, tbody, td, th, tr, caption, col and colgroup.
* ul, ol and menu have li.
* fieldset has legend.
* applet and object have param.
* video and audio have source.
* dl has dt and dd.
* select and datalist have option and optgroup.
* ruby has rp and rt.
* datagrid was proposed to have a number of specialized child elements.

In some cases (such as table or the list elements), the structured element can ''only'' have its specialized children. In other cases (fieldset, applet/object, or audio/video), the structured element can have relatively free content in addition to its specialized children.

Thus, when introducing new structured elements such as figure and details, the normal design pattern for HTML is to introduce new specialized child elements to represent their structure. It is not the norm to reuse a very common element such as "h1" to represent specialized structure in a certain context. It is not the norm to reuse specialized child elements in a way that differs from their established content and meaning, as with dt/dd or legend. And it is unprecedented to use an attribute that can occur on any element to represent specialized structure, as with the proposed caption attribute. Furthermore, details and figure are not particularly closely related in purpose. One is a UI control, the other is a representation of the structure of prose documents. So it does not make sense for them to share a specialized child element.

Applying a different design pattern for internal element structure to figure and details is likely to be confusing. The confusion of deviating from the usual HTML design pattern for this is likely to be greater than the cognitive cost of introducing no or fewer new elements.

==== Avoids Clunky or Inappropriate Names ====

The new element fltcap, suggested by another Change Proposal, appears confusing and mysterious. No one seems to get what it means on first reading. The expansion as "floating caption" seems confusing and semantically wrong. First, "floating caption" is not a very common term of art in publishing, but whenever it is used, it seems to refer to [http://www.google.com/search?client=safari&rls=en&q=floating+caption&ie=UTF-8&oe=UTF-8 captions overlayed on top of the image], not figure captions in general. Furthermore, a details control does not in general have a "caption", floating or otherwise, rather it is a UI control and therefore is normally considered to have a "label".

The new element c is an extremely short and mysterious name. There is a limit to how many one-letter identifiers one can have in a language without rendering it unreadable or confusing, and they should be reserved for extremely common elements. Captions do not make the cut.

Reusing legend does not seem like a good semantic fit for either figure or details. While a figure's caption is sometimes called a legend, the term "legend" in this context more often refers to the key next to a map or chart explaining how to read various visual elements. A details element is a UI element and those aren't ordinarily referred to as having a legend.

h1 connotes "header", which is not quite right for either figure or details.

The caption attribute is good for figure, but not details. However, that proposal retains the dt/dd names for details. And those names remain clunky and non-obvious in the context of details (hard to remember which is which) and retain all of the general problems of using dt/dd for both elements.

"caption" and "label", or variations thereof, are the most semantically appropriate names for the caption and label respectively on figure and details.

==== Does Not Introduce Compatibility Problems ====

Reuse of almost any existing element in an unrelated context introduces compatibility problems, whether "hard" problems with parsing or behavior, or "soft" problems with pre-existing author styles. This Change Proposal uses brand new elements and thus avoids all these problems, unlike the use of dt/dd, legend, label, caption, or h1. All of those are known to have some lesser or greater technical issues.

==== Does Not Introduce Redundant Elements for the Content ====

Semantically, and for purposes of UA behavior, we only really need to distinguish the caption part of the element. There is no need to wrap the remaining body part with a special element. True, they can be handy as a styling hook, but authors who need that styling hook can always use <div>.

=== Details ===

This proposal includes the following specific changes:

1) Define a new element fcaption. Details would be approximately as follows:

Categories: none
Contexts in which the element may be used: As the first or last child of a figure element.
Content model: flow content
Content attributes: global attributes
DOM interface: HTMLElement
Semantics: The fcaption element represents the caption of the figure that is its parent, if it has a parent that is a figure element.

2) Define a new element dlabel. Details would be as above, but replacing mentions of "figure" with "details".

3) Change figure as follows:
New content model: "Flow content, optionally either preceded by or followed by an fcaption element."
New caption definition: "The first fcaption element child of the element, if any, represents the caption of the figure element's contents. If there is no child fcaption element, then there is no caption."
New content definition: "All child elements other than the first fcaption element, if there are any, represent the element's contents. If there are no child elements besides the first fcaption, then there are no contents.
Update the examples appropriately.
Update the suggested UA stylesheet in the Rendering section as appropriate.

4) Change details as follows:
New content model: "One dlabel element, followed by Flow content."
New summary definition: "The first dlabel element child of the element, if any, represents the summary of the details. If there is no child dlabel element, the user agent should provide its own label (e.g. "Details")."
New details definition: "All child elements other than the first dlabel element, if there are any, represent the details. If there are no child elements besides the first dlabel, then there are no details.
Update the examples appropriately.
Update the suggested UA stylesheet in the Rendering section as appropriate.

=== Impact ===

This proposal would have a potential negative impact on authors: it would introduce two new elements relative to the current spec.

However, the positive impact is arguably greater. The new elements would be more readable, more intuitive, and more in line with the standard HTML design pattern for structured elements. Thus, despite the addition of more elements, the overall increase in cognitive load will be less. In addition, there is no need to use <div> or any other wonky workarounds to get it to work in legacy UAs.

The impact on implementations is trivial. fcaption and dlabel are trivial to implement, and the appearance and behavior can be mostly defined via stylesheet. This is not significantly more work than altering the rendering of dt and dd inside figure and details; in fact it may be less work in some implementations.

The impact on conformance checkers and authoring tools is also trivial; neither approach is easier or harder to validate or generate.

There is no direct impact on users either way.

== Proposal 3b (<code><figure><figcaption>...</figcaption>...</figure>; <details><dsummary>...</dsummary>...</details></code>) ==
Same as proposal 3, but with the element names "figcaption" and "dsummary" respectively.

Reasoning: "figcaption" is more memorable. "dsummary" more accurately describes what the "label" of a <details> element is.

== Proposal 4 (<code><figure><caption>...</caption>...</figure>; <details><label>...</label>...</details></code>) ==
The proposal is to use the caption element within figure and the label element within details for marking up the captions.

CON: "caption" has significant unsolved parsing problems.

CON: "label" use in <details> would prevent the summary of a <details> from containing a labeled <progress> element, which is common, and would make the content model ambiguous (since the contents of a <details> can itself contain labels).

== Proposal 5 (<code><figure><h1>...</h1>...</figure>; <details><h1>...</h1>...</details></code>) ==
The proposal is to repurpose the h1 element for marking up the captions within both figure and details elements.

CON: Styling issues in legacy UAs.

CON: Content model would be ambiguous.

== Proposal 6 (<code><figure><p caption>...</p>...</figure></code>)==
===Summary===
The proposal is to introduce a caption attribute that may be used on an element within figure to denote the contents of that element as being the caption. This proposal does not address the details element.

===Rationale===
* This allows the most intuitive name to be used, without the problems caused by actually using <caption> as an element name.
* It roughly parallels the existing uses of attributes to tie together an element and some containing element with additional semantics, as seen in <time pubdate>.
* It does not alter the existing semantics of the element it is applied to; a <ul caption> is still a <ul>, a <time caption> is still a <time>, etc.
* It forgoes the need for a 'wrapper' element when you just want to immediately apply a special element. For example, if you are putting photographs in a figure, with the only caption being the time it was taken, it would be best if you could simply put in the <time> without a wrapper. That is, <figure><img src=foo><time caption datetime=2010-01-11>January 11th, 2010</time></figure> is preferable to <figure><img src=foo><caption><time datetime=2010-01-11>January 11th, 2010</time></caption></figure>

===Details===
* Figure content model should be changed to "Flow Content".
* The third paragraph in the prose (explaining the use of the <dt> element) should be changed to roughly: "The first child element with the caption attribute, if any, represents the caption of the figure element's contents. If there is no child element with the caption attribute, then there is no caption."
* The fourth paragraph in the prose (explaining the use of the <dd> element) should be changed to roughly: "Any additional contents of the element beyond the caption (defined above), if any, represents the element's contents. If there are no additional contents, then there are no contents."
* "caption" added to the list of global attributes in the "Global Attributes" section. In its section it should contain roughly: "All HTML elements in the Flow Content category may have the caption content attribute set. The caption attribute is a boolean attribute. When caption is set on an element that is a child of a figure element, the first such element defines the caption for that figure element. It is invalid for a figure to have multiple child elements with the caption attribute set; in such a case, the first such element is the caption for the figure and the caption attribute is invalid and has no effect on subsequent elements. The caption attribute is invalid and has no effect on any element that is not a direct child of a figure element."

===Impact===
Easy denotation of figure captions, without any compatibility hacks that may persist long into the future.

== Proposal 7 (<code><figure><fcaption>...</fcaption>...</figure>; <details><dlabel>...</dlabel>...</details></code> or <code><figure><fcaption>...</fcaption><fbody>...</fbody></figure>; <details><dlabel>...</dlabel><dbody>...</dbody></details></code>) ==

=== Summary ===

The current HTML5 draft uses the dt and dd elements to markup the captions and content of the figure and details elements. This change proposal explains why the dt and dd elements are a poor choice for these purposes and proposes an alternative. Specifically, the proposal is to introduce a new fcaption element for marking up the caption within figure, and a dlabel element for use within details to replace dt. In addition, it proposes an optional fbody element for use inside figure, and an optional dbody element for use inside details, to mark up the content/body and replace dd.

Change Proposal: figure and details

2010-01-12T00:02:50Z

Mjs: /* Proposal Details */

== Summary ==
The current HTML5 draft uses the dt and dd elements to markup the captions and content of the figure and details elements. This change proposal explains why the dt and dd elements are a poor choice for these purposes and proposes an alternative.
----
== Rationale Against Using dt/dd for figure and details Elements ==

=== Backwards Compatibility ===
Due to IE's legacy parsing issues, the dt and dd elements create problems for authors attempting to use and style these elements. The simplest workaround (wrapping both figure and details in an extra div) that authors would need to apply to avoid these issues is not intuitive, as clearly demonstrated by the wide range of alternative solutions that were attempted prior to its discovery.

=== Legacy Cruft ===
The use of extra div elements may lead to a lot of confusion among authors, at least initially, and ultimately end up becoming extraneous markup that authors just include without really understanding why, even after the current generation of browsers are long since dead.

We've seen this kind of problem before with authors, for example, frequently wrapping scripts with pseudo-HTML-comments initially intended to hide the script from what are now very ancient browsers, none of which have been in use for over a decade.

=== Styling Clashes ===
In addition to the aforementioned styling bug in IE, many existing stylesheets already include styles for the dt and dd elements, used in description lists (dl elements). Authors attempting to incorporate figure or details into their existing pages would have to take care to avoid unintended styling clashes caused by selectors that aren't specific enough. i.e. It's common for authors to simply use the selector as "dt" or "dd", rather than "dl>dt" and "dl>dd", as that is currently unnecessary. Authors will then have to adjust their styles, which could potentially cause unintended side affects to to the change in specificity of the selectors.

=== Default Styles ===
The default styles for dt and dd elements is not ideal for figures. As the dd element is usually indented with margin and/or padding, authors will usually be required to remove this with their own stylesheets, rather than being able to rely on more sensible defaults. It is true that eventually UA stylesheets may have special rules for "figure > dt" and the like, but during the transition period it will be extra work to remove inappropriate default styles.

=== Structural Differences ===
Since authors are already familiar with the meanings and structure of dt and dd when used within dl, their very distinct meanings and structure when used within the figure and details may be confusing to authors.

The dl element may contain multiple groups of dt and dd elements, wheres within figure and details, each element may only be used once.

Within dl, a group must have one or more dt elements followed by one or more dd elements, whereas within figure, the elements may appear in any order.

=== Semantic Differences ===
For the figure element, it's not very intuitive to determine which of either dt or dd represents the caption and which represents the content such as an image. Some authors may interpret dd as being the description, which is what it means within dl, and thus assume that dd is meant for the caption, and the dt meant for the image or other content. However, the spec defines these with the opposite meanings, with the understanding the dt, or title, is a synonym for caption. Both alternatives points of view make some sense, but neither stands out as being obviously correct. This will likely lead to a lot of authors using these elements in reverse.

=== Unnecessary Elements ===
The dd element is completely unnecessary to distinguish it from the caption, which has its own element. This combined with the extraneous div required for IE compatibility adds two extra elements that are not logically needed. A previous iteration of the spec used the legend element for the caption, without any special wrapper just for the content. This model seems much more intuitive and required less markup to use, and thus easier to get right. Authors who do wish to have an extra wrapper around the content may use div if they choose, but should not be required to use it.

When there is no caption, using figure then requires authors to use 3 extra elements, where they should only need one:

<div> 
<figure>
<dd><img src="image" alt="..."></dd>
</figure>
</div>

This will be unappealing to authors who may, as a result of the complexity, opt not to use the figure element.

=== Aesthetics ===
Aesthetics is not necessarily the sole or most important concern. However, many authors seem to find the novel use of dt and dd unpleasant to read. dt and dd are relatively obscure elements, they are very short abbreviations, and their meaning in context is unclear, especially in figure. In particular, the following markup seems mysterious and strikes many as ugly and unintuitive:

<figure>
<dd><img src="image" alt="..."></dd>
<dt>A Pair of Cats</dd>
</figure>

This seems to trigger a "yuck factor", and it would be wise to avoid that. Aesthetics may seem like a relatively unimportant factor; however, the desire to avoid introducing new elements that led to dt/dd being used is itself largely an aesthetic concern.

----

== Proposal 1 (<code><figure><legend>...</legend>...</figure>; <details><legend>...</legend>...</details></code>) ==
The proposal is to restore the use of the legend element for marking up the captions within both figure and details elements.

== Proposal 2 (<code><figure><c>...</c>...</figure>; <details><c>...</c>...</details></code>) ==
The proposal is to introduce a new c element for marking up the captions within both figure and details elements.

== Proposal 3 (<code><figure><fcaption>...</fcaption>...</figure>; <details><dlabel>...</dlabel>...</details></code>) ==

=== Summary ===
The current HTML5 draft uses the dt and dd elements to markup the captions and content of the figure and details elements. This change proposal explains why the dt and dd elements are a poor choice for these purposes and proposes an alternative. Specifically, the proposal is to introduce a new fcaption element for marking up the caption within figure, and a dlabel element for use within details. The content portions of these elements (as opposed to the caption or label) would not have any special markup, they would be nested directly inside the figure or details element.

=== Additional Rationale ===

In addition to the rationale relative to the status quo in the spec, this proposal is better than some of the proposed alternatives.

==== Follows HTML Precedent for Structured Elements ====

Some HTML elements have relatively free content models, while others are "structured" - there are some or all child elements that have special meaning. Structured elements typically have helper elements that are specific to one element, or to a small family of related elements, to express their internal structure. Examples, from past versions of HTML, new in HTML5, and proposed for future versions of HTML:

* table has thead, tfoot, tbody, td, th, tr, caption, col and colgroup.
* ul, ol and menu have li.
* fieldset has legend.
* applet and object have param.
* video and audio have source.
* dl has dt and dd.
* select and datalist have option and optgroup.
* ruby has rp and rt.
* datagrid was proposed to have a number of specialized child elements.

In some cases (such as table or the list elements), the structured element can ''only'' have its specialized children. In other cases (fieldset, applet/object, or audio/video), the structured element can have relatively free content in addition to its specialized children.

Thus, when introducing new structured elements such as figure and details, the normal design pattern for HTML is to introduce new specialized child elements to represent their structure. It is not the norm to reuse a very common element such as "h1" to represent specialized structure in a certain context. It is not the norm to reuse specialized child elements in a way that differs from their established content and meaning, as with dt/dd or legend. And it is unprecedented to use an attribute that can occur on any element to represent specialized structure, as with the proposed caption attribute. Furthermore, details and figure are not particularly closely related in purpose. One is a UI control, the other is a representation of the structure of prose documents. So it does not make sense for them to share a specialized child element.

Applying a different design pattern for internal element structure to figure and details is likely to be confusing. The confusion of deviating from the usual HTML design pattern for this is likely to be greater than the cognitive cost of introducing no or fewer new elements.

==== Avoids Clunky or Inappropriate Names ====

The new element fltcap, suggested by another Change Proposal, appears confusing and mysterious. No one seems to get what it means on first reading. The expansion as "floating caption" seems confusing and semantically wrong. First, "floating caption" is not a very common term of art in publishing, but whenever it is used, it seems to refer to [http://www.google.com/search?client=safari&rls=en&q=floating+caption&ie=UTF-8&oe=UTF-8 captions overlayed on top of the image], not figure captions in general. Furthermore, a details control does not in general have a "caption", floating or otherwise, rather it is a UI control and therefore is normally considered to have a "label".

The new element c is an extremely short and mysterious name. There is a limit to how many one-letter identifiers one can have in a language without rendering it unreadable or confusing, and they should be reserved for extremely common elements. Captions do not make the cut.

Reusing legend does not seem like a good semantic fit for either figure or details. While a figure's caption is sometimes called a legend, the term "legend" in this context more often refers to the key next to a map or chart explaining how to read various visual elements. A details element is a UI element and those aren't ordinarily referred to as having a legend.

h1 connotes "header", which is not quite right for either figure or details.

The caption attribute is good for figure, but not details. However, that proposal retains the dt/dd names for details. And those names remain clunky and non-obvious in the context of details (hard to remember which is which) and retain all of the general problems of using dt/dd for both elements.

"caption" and "label", or variations thereof, are the most semantically appropriate names for the caption and label respectively on figure and details.

==== Does Not Introduce Compatibility Problems ====

Reuse of almost any existing element in an unrelated context introduces compatibility problems, whether "hard" problems with parsing or behavior, or "soft" problems with pre-existing author styles. This Change Proposal uses brand new elements and thus avoids all these problems, unlike the use of dt/dd, legend, label, caption, or h1. All of those are known to have some lesser or greater technical issues.

==== Does Not Introduce Redundant Elements for the Content ====

Semantically, and for purposes of UA behavior, we only really need to distinguish the caption part of the element. There is no need to wrap the remaining body part with a special element. True, they can be handy as a styling hook, but authors who need that styling hook can always use <div>.

=== Proposal Details ===

This proposal includes the following specific changes:

1) Define a new element fcaption. Details would be approximately as follows:

Categories: none
Contexts in which the element may be used: As the first or last child of a figure element.
Content model: flow content
Content attributes: global attributes
DOM interface: HTMLElement
Semantics: The fcaption element represents the caption of the figure that is its parent, if it has a parent that is a figure element.

2) Define a new element dlabel. Details would be as above, but replacing mentions of "figure" with "details".

3) Change figure as follows:
New content model: "Flow content, optionally either preceded by or followed by an fcaption element."
New caption definition: "The first fcaption element child of the element, if any, represents the caption of the figure element's contents. If there is no child fcaption element, then there is no caption."
New content definition: "All child elements other than the first fcaption element, if there are any, represent the element's contents. If there are no child elements besides the first fcaption, then there are no contents.
Update the examples appropriately.
Update the suggested UA stylesheet in the Rendering section as appropriate.

4) Change details as follows:
New content model: "One dlabel element, followed by Flow content."
New summary definition: "The first dlabel element child of the element, if any, represents the summary of the details. If there is no child dlabel element, the user agent should provide its own label (e.g. "Details")."
New details definition: "All child elements other than the first dlabel element, if there are any, represent the details. If there are no child elements besides the first dlabel, then there are no details.
Update the examples appropriately.
Update the suggested UA stylesheet in the Rendering section as appropriate.

=== Impact ===

This proposal would have a potential negative impact on authors: it would introduce two new elements relative to the current spec.

However, the positive impact is arguably greater. The new elements would be more readable, more intuitive, and more in line with the standard HTML design pattern for structured elements. Thus, despite the addition of more elements, the overall increase in cognitive load will be less. In addition, there is no need to use <div> or any other wonky workarounds to get it to work in legacy UAs.

The impact on implementations is trivial. fcaption and dlabel are trivial to implement, and the appearance and behavior can be mostly defined via stylesheet. This is not significantly more work than altering the rendering of dt and dd inside figure and details; in fact it may be less work in some implementations.

The impact on conformance checkers and authoring tools is also trivial; neither approach is easier or harder to validate or generate.

There is no direct impact on users either way.

== Proposal 3b (<code><figure><figcaption>...</figcaption>...</figure>; <details><dsummary>...</dsummary>...</details></code>) ==
Same as proposal 3, but with the element names "figcaption" and "dsummary" respectively.

Reasoning: "figcaption" is more memorable. "dsummary" more accurately describes what the "label" of a <details> element is.

== Proposal 4 (<code><figure><caption>...</caption>...</figure>; <details><label>...</label>...</details></code>) ==
The proposal is to use the caption element within figure and the label element within details for marking up the captions.

CON: "caption" has significant unsolved parsing problems.

CON: "label" use in <details> would prevent the summary of a <details> from containing a labeled <progress> element, which is common, and would make the content model ambiguous (since the contents of a <details> can itself contain labels).

== Proposal 5 (<code><figure><h1>...</h1>...</figure>; <details><h1>...</h1>...</details></code>) ==
The proposal is to repurpose the h1 element for marking up the captions within both figure and details elements.

CON: Styling issues in legacy UAs.

CON: Content model would be ambiguous.

== Proposal 6 (<code><figure><p caption>...</p>...</figure></code>)==
===Summary===
The proposal is to introduce a caption attribute that may be used on an element within figure to denote the contents of that element as being the caption. This proposal does not address the details element.

===Rationale===
* This allows the most intuitive name to be used, without the problems caused by actually using <caption> as an element name.
* It roughly parallels the existing uses of attributes to tie together an element and some containing element with additional semantics, as seen in <time pubdate>.
* It does not alter the existing semantics of the element it is applied to; a <ul caption> is still a <ul>, a <time caption> is still a <time>, etc.
* It forgoes the need for a 'wrapper' element when you just want to immediately apply a special element. For example, if you are putting photographs in a figure, with the only caption being the time it was taken, it would be best if you could simply put in the <time> without a wrapper. That is, <figure><img src=foo><time caption datetime=2010-01-11>January 11th, 2010</time></figure> is preferable to <figure><img src=foo><caption><time datetime=2010-01-11>January 11th, 2010</time></caption></figure>

===Details===
* Figure content model should be changed to "Flow Content".
* The third paragraph in the prose (explaining the use of the <dt> element) should be changed to roughly: "The first child element with the caption attribute, if any, represents the caption of the figure element's contents. If there is no child element with the caption attribute, then there is no caption."
* The fourth paragraph in the prose (explaining the use of the <dd> element) should be changed to roughly: "Any additional contents of the element beyond the caption (defined above), if any, represents the element's contents. If there are no additional contents, then there are no contents."
* "caption" added to the list of global attributes in the "Global Attributes" section. In its section it should contain roughly: "All HTML elements in the Flow Content category may have the caption content attribute set. The caption attribute is a boolean attribute. When caption is set on an element that is a child of a figure element, the first such element defines the caption for that figure element. It is invalid for a figure to have multiple child elements with the caption attribute set; in such a case, the first such element is the caption for the figure and the caption attribute is invalid and has no effect on subsequent elements. The caption attribute is invalid and has no effect on any element that is not a direct child of a figure element."

===Impact===
Easy denotation of figure captions, without any compatibility hacks that may persist long into the future.

== Proposal 7 (<code><figure><fcaption>...</fcaption>...</figure>; <details><dlabel>...</dlabel>...</details></code> or <code><figure><fcaption>...</fcaption><fbody>...</fbody></figure>; <details><dlabel>...</dlabel><dbody>...</dbody></details></code>) ==

=== Summary ===

The current HTML5 draft uses the dt and dd elements to markup the captions and content of the figure and details elements. This change proposal explains why the dt and dd elements are a poor choice for these purposes and proposes an alternative. Specifically, the proposal is to introduce a new fcaption element for marking up the caption within figure, and a dlabel element for use within details to replace dt. In addition, it proposes an optional fbody element for use inside figure, and an optional dbody element for use inside details, to mark up the content/body and replace dd.

Change Proposal: figure and details

2010-01-12T00:00:16Z

Mjs: /* Proposal Details */

== Summary ==
The current HTML5 draft uses the dt and dd elements to markup the captions and content of the figure and details elements. This change proposal explains why the dt and dd elements are a poor choice for these purposes and proposes an alternative.
----
== Rationale Against Using dt/dd for figure and details Elements ==

=== Backwards Compatibility ===
Due to IE's legacy parsing issues, the dt and dd elements create problems for authors attempting to use and style these elements. The simplest workaround (wrapping both figure and details in an extra div) that authors would need to apply to avoid these issues is not intuitive, as clearly demonstrated by the wide range of alternative solutions that were attempted prior to its discovery.

=== Legacy Cruft ===
The use of extra div elements may lead to a lot of confusion among authors, at least initially, and ultimately end up becoming extraneous markup that authors just include without really understanding why, even after the current generation of browsers are long since dead.

We've seen this kind of problem before with authors, for example, frequently wrapping scripts with pseudo-HTML-comments initially intended to hide the script from what are now very ancient browsers, none of which have been in use for over a decade.

=== Styling Clashes ===
In addition to the aforementioned styling bug in IE, many existing stylesheets already include styles for the dt and dd elements, used in description lists (dl elements). Authors attempting to incorporate figure or details into their existing pages would have to take care to avoid unintended styling clashes caused by selectors that aren't specific enough. i.e. It's common for authors to simply use the selector as "dt" or "dd", rather than "dl>dt" and "dl>dd", as that is currently unnecessary. Authors will then have to adjust their styles, which could potentially cause unintended side affects to to the change in specificity of the selectors.

=== Default Styles ===
The default styles for dt and dd elements is not ideal for figures. As the dd element is usually indented with margin and/or padding, authors will usually be required to remove this with their own stylesheets, rather than being able to rely on more sensible defaults. It is true that eventually UA stylesheets may have special rules for "figure > dt" and the like, but during the transition period it will be extra work to remove inappropriate default styles.

=== Structural Differences ===
Since authors are already familiar with the meanings and structure of dt and dd when used within dl, their very distinct meanings and structure when used within the figure and details may be confusing to authors.

The dl element may contain multiple groups of dt and dd elements, wheres within figure and details, each element may only be used once.

Within dl, a group must have one or more dt elements followed by one or more dd elements, whereas within figure, the elements may appear in any order.

=== Semantic Differences ===
For the figure element, it's not very intuitive to determine which of either dt or dd represents the caption and which represents the content such as an image. Some authors may interpret dd as being the description, which is what it means within dl, and thus assume that dd is meant for the caption, and the dt meant for the image or other content. However, the spec defines these with the opposite meanings, with the understanding the dt, or title, is a synonym for caption. Both alternatives points of view make some sense, but neither stands out as being obviously correct. This will likely lead to a lot of authors using these elements in reverse.

=== Unnecessary Elements ===
The dd element is completely unnecessary to distinguish it from the caption, which has its own element. This combined with the extraneous div required for IE compatibility adds two extra elements that are not logically needed. A previous iteration of the spec used the legend element for the caption, without any special wrapper just for the content. This model seems much more intuitive and required less markup to use, and thus easier to get right. Authors who do wish to have an extra wrapper around the content may use div if they choose, but should not be required to use it.

When there is no caption, using figure then requires authors to use 3 extra elements, where they should only need one:

<div> 
<figure>
<dd><img src="image" alt="..."></dd>
</figure>
</div>

This will be unappealing to authors who may, as a result of the complexity, opt not to use the figure element.

=== Aesthetics ===
Aesthetics is not necessarily the sole or most important concern. However, many authors seem to find the novel use of dt and dd unpleasant to read. dt and dd are relatively obscure elements, they are very short abbreviations, and their meaning in context is unclear, especially in figure. In particular, the following markup seems mysterious and strikes many as ugly and unintuitive:

<figure>
<dd><img src="image" alt="..."></dd>
<dt>A Pair of Cats</dd>
</figure>

This seems to trigger a "yuck factor", and it would be wise to avoid that. Aesthetics may seem like a relatively unimportant factor; however, the desire to avoid introducing new elements that led to dt/dd being used is itself largely an aesthetic concern.

----

== Proposal 1 (<code><figure><legend>...</legend>...</figure>; <details><legend>...</legend>...</details></code>) ==
The proposal is to restore the use of the legend element for marking up the captions within both figure and details elements.

== Proposal 2 (<code><figure><c>...</c>...</figure>; <details><c>...</c>...</details></code>) ==
The proposal is to introduce a new c element for marking up the captions within both figure and details elements.

== Proposal 3 (<code><figure><fcaption>...</fcaption>...</figure>; <details><dlabel>...</dlabel>...</details></code>) ==

=== Summary ===
The current HTML5 draft uses the dt and dd elements to markup the captions and content of the figure and details elements. This change proposal explains why the dt and dd elements are a poor choice for these purposes and proposes an alternative. Specifically, the proposal is to introduce a new fcaption element for marking up the caption within figure, and a dlabel element for use within details. The content portions of these elements (as opposed to the caption or label) would not have any special markup, they would be nested directly inside the figure or details element.

=== Additional Rationale ===

In addition to the rationale relative to the status quo in the spec, this proposal is better than some of the proposed alternatives.

==== Follows HTML Precedent for Structured Elements ====

Some HTML elements have relatively free content models, while others are "structured" - there are some or all child elements that have special meaning. Structured elements typically have helper elements that are specific to one element, or to a small family of related elements, to express their internal structure. Examples, from past versions of HTML, new in HTML5, and proposed for future versions of HTML:

* table has thead, tfoot, tbody, td, th, tr, caption, col and colgroup.
* ul, ol and menu have li.
* fieldset has legend.
* applet and object have param.
* video and audio have source.
* dl has dt and dd.
* select and datalist have option and optgroup.
* ruby has rp and rt.
* datagrid was proposed to have a number of specialized child elements.

In some cases (such as table or the list elements), the structured element can ''only'' have its specialized children. In other cases (fieldset, applet/object, or audio/video), the structured element can have relatively free content in addition to its specialized children.

Thus, when introducing new structured elements such as figure and details, the normal design pattern for HTML is to introduce new specialized child elements to represent their structure. It is not the norm to reuse a very common element such as "h1" to represent specialized structure in a certain context. It is not the norm to reuse specialized child elements in a way that differs from their established content and meaning, as with dt/dd or legend. And it is unprecedented to use an attribute that can occur on any element to represent specialized structure, as with the proposed caption attribute. Furthermore, details and figure are not particularly closely related in purpose. One is a UI control, the other is a representation of the structure of prose documents. So it does not make sense for them to share a specialized child element.

Applying a different design pattern for internal element structure to figure and details is likely to be confusing. The confusion of deviating from the usual HTML design pattern for this is likely to be greater than the cognitive cost of introducing no or fewer new elements.

==== Avoids Clunky or Inappropriate Names ====

The new element fltcap, suggested by another Change Proposal, appears confusing and mysterious. No one seems to get what it means on first reading. The expansion as "floating caption" seems confusing and semantically wrong. First, "floating caption" is not a very common term of art in publishing, but whenever it is used, it seems to refer to [http://www.google.com/search?client=safari&rls=en&q=floating+caption&ie=UTF-8&oe=UTF-8 captions overlayed on top of the image], not figure captions in general. Furthermore, a details control does not in general have a "caption", floating or otherwise, rather it is a UI control and therefore is normally considered to have a "label".

The new element c is an extremely short and mysterious name. There is a limit to how many one-letter identifiers one can have in a language without rendering it unreadable or confusing, and they should be reserved for extremely common elements. Captions do not make the cut.

Reusing legend does not seem like a good semantic fit for either figure or details. While a figure's caption is sometimes called a legend, the term "legend" in this context more often refers to the key next to a map or chart explaining how to read various visual elements. A details element is a UI element and those aren't ordinarily referred to as having a legend.

h1 connotes "header", which is not quite right for either figure or details.

The caption attribute is good for figure, but not details. However, that proposal retains the dt/dd names for details. And those names remain clunky and non-obvious in the context of details (hard to remember which is which) and retain all of the general problems of using dt/dd for both elements.

"caption" and "label", or variations thereof, are the most semantically appropriate names for the caption and label respectively on figure and details.

==== Does Not Introduce Compatibility Problems ====

Reuse of almost any existing element in an unrelated context introduces compatibility problems, whether "hard" problems with parsing or behavior, or "soft" problems with pre-existing author styles. This Change Proposal uses brand new elements and thus avoids all these problems, unlike the use of dt/dd, legend, label, caption, or h1. All of those are known to have some lesser or greater technical issues.

==== Does Not Introduce Redundant Elements for the Content ====

Semantically, and for purposes of UA behavior, we only really need to distinguish the caption part of the element. There is no need to wrap the remaining body part with a special element. True, they can be handy as a styling hook, but authors who need that styling hook can always use <div>.

=== Proposal Details ===

This proposal includes the following specific changes:

1) Define a new element fcaption. Details would be approximately as follows:
Categories: none
Contexts in which the element may be used: As the first or last child of a figure element.
Content model: flow content
Content attributes: global attributes
DOM interface: HTMLElement
Semantics: The fcaption element represents the caption of the figure that is its parent, if it has a parent that is a figure element.

2) Define a new element dlabel. Details would be as above, but replacing mentions of "figure" with "details".

3) Change figure as follows:
New content model: "Flow content, optionally either preceded by or followed by an fcaption element."
New caption definition: "The first fcaption element child of the element, if any, represents the caption of the figure element's contents. If there is no child fcaption element, then there is no caption."
New content definition: "All child elements other than the first fcaption element, if there are any, represent the element's contents. If there are no child elements besides the first fcaption, then there are no contents.
Update the examples appropriately.
Update the suggested UA stylesheet in the Rendering section as appropriate.

4) Change details as follows:
New content model: "One dlabel element, followed by Flow content."
New summary definition: "The first dlabel element child of the element, if any, represents the summary of the details. If there is no child dlabel element, the user agent should provide its own label (e.g. "Details")."
New details definition: "All child elements other than the first dlabel element, if there are any, represent the details. If there are no child elements besides the first dlabel, then there are no details.
Update the examples appropriately.
Update the suggested UA stylesheet in the Rendering section as appropriate.

=== Impact ===

This proposal would have a potential negative impact on authors: it would introduce two new elements relative to the current spec.

However, the positive impact is arguably greater. The new elements would be more readable, more intuitive, and more in line with the standard HTML design pattern for structured elements. Thus, despite the addition of more elements, the overall increase in cognitive load will be less. In addition, there is no need to use <div> or any other wonky workarounds to get it to work in legacy UAs.

The impact on implementations is trivial. fcaption and dlabel are trivial to implement, and the appearance and behavior can be mostly defined via stylesheet. This is not significantly more work than altering the rendering of dt and dd inside figure and details; in fact it may be less work in some implementations.

The impact on conformance checkers and authoring tools is also trivial; neither approach is easier or harder to validate or generate.

There is no direct impact on users either way.

== Proposal 3b (<code><figure><figcaption>...</figcaption>...</figure>; <details><dsummary>...</dsummary>...</details></code>) ==
Same as proposal 3, but with the element names "figcaption" and "dsummary" respectively.

Reasoning: "figcaption" is more memorable. "dsummary" more accurately describes what the "label" of a <details> element is.

== Proposal 4 (<code><figure><caption>...</caption>...</figure>; <details><label>...</label>...</details></code>) ==
The proposal is to use the caption element within figure and the label element within details for marking up the captions.

CON: "caption" has significant unsolved parsing problems.

CON: "label" use in <details> would prevent the summary of a <details> from containing a labeled <progress> element, which is common, and would make the content model ambiguous (since the contents of a <details> can itself contain labels).

== Proposal 5 (<code><figure><h1>...</h1>...</figure>; <details><h1>...</h1>...</details></code>) ==
The proposal is to repurpose the h1 element for marking up the captions within both figure and details elements.

CON: Styling issues in legacy UAs.

CON: Content model would be ambiguous.

== Proposal 6 (<code><figure><p caption>...</p>...</figure></code>)==
===Summary===
The proposal is to introduce a caption attribute that may be used on an element within figure to denote the contents of that element as being the caption. This proposal does not address the details element.

===Rationale===
* This allows the most intuitive name to be used, without the problems caused by actually using <caption> as an element name.
* It roughly parallels the existing uses of attributes to tie together an element and some containing element with additional semantics, as seen in <time pubdate>.
* It does not alter the existing semantics of the element it is applied to; a <ul caption> is still a <ul>, a <time caption> is still a <time>, etc.
* It forgoes the need for a 'wrapper' element when you just want to immediately apply a special element. For example, if you are putting photographs in a figure, with the only caption being the time it was taken, it would be best if you could simply put in the <time> without a wrapper. That is, <figure><img src=foo><time caption datetime=2010-01-11>January 11th, 2010</time></figure> is preferable to <figure><img src=foo><caption><time datetime=2010-01-11>January 11th, 2010</time></caption></figure>

===Details===
* Figure content model should be changed to "Flow Content".
* The third paragraph in the prose (explaining the use of the <dt> element) should be changed to roughly: "The first child element with the caption attribute, if any, represents the caption of the figure element's contents. If there is no child element with the caption attribute, then there is no caption."
* The fourth paragraph in the prose (explaining the use of the <dd> element) should be changed to roughly: "Any additional contents of the element beyond the caption (defined above), if any, represents the element's contents. If there are no additional contents, then there are no contents."
* "caption" added to the list of global attributes in the "Global Attributes" section. In its section it should contain roughly: "All HTML elements in the Flow Content category may have the caption content attribute set. The caption attribute is a boolean attribute. When caption is set on an element that is a child of a figure element, the first such element defines the caption for that figure element. It is invalid for a figure to have multiple child elements with the caption attribute set; in such a case, the first such element is the caption for the figure and the caption attribute is invalid and has no effect on subsequent elements. The caption attribute is invalid and has no effect on any element that is not a direct child of a figure element."

===Impact===
Easy denotation of figure captions, without any compatibility hacks that may persist long into the future.

== Proposal 7 (<code><figure><fcaption>...</fcaption>...</figure>; <details><dlabel>...</dlabel>...</details></code> or <code><figure><fcaption>...</fcaption><fbody>...</fbody></figure>; <details><dlabel>...</dlabel><dbody>...</dbody></details></code>) ==

=== Summary ===

The current HTML5 draft uses the dt and dd elements to markup the captions and content of the figure and details elements. This change proposal explains why the dt and dd elements are a poor choice for these purposes and proposes an alternative. Specifically, the proposal is to introduce a new fcaption element for marking up the caption within figure, and a dlabel element for use within details to replace dt. In addition, it proposes an optional fbody element for use inside figure, and an optional dbody element for use inside details, to mark up the content/body and replace dd.

Change Proposal: figure and details

2010-01-11T23:51:33Z

Mjs: /* Proposal 3 */

== Summary ==
The current HTML5 draft uses the dt and dd elements to markup the captions and content of the figure and details elements. This change proposal explains why the dt and dd elements are a poor choice for these purposes and proposes an alternative.
----
== Rationale Against Using dt/dd for figure and details Elements ==

=== Backwards Compatibility ===
Due to IE's legacy parsing issues, the dt and dd elements create problems for authors attempting to use and style these elements. The simplest workaround (wrapping both figure and details in an extra div) that authors would need to apply to avoid these issues is not intuitive, as clearly demonstrated by the wide range of alternative solutions that were attempted prior to its discovery.

=== Legacy Cruft ===
The use of extra div elements may lead to a lot of confusion among authors, at least initially, and ultimately end up becoming extraneous markup that authors just include without really understanding why, even after the current generation of browsers are long since dead.

We've seen this kind of problem before with authors, for example, frequently wrapping scripts with pseudo-HTML-comments initially intended to hide the script from what are now very ancient browsers, none of which have been in use for over a decade.

=== Styling Clashes ===
In addition to the aforementioned styling bug in IE, many existing stylesheets already include styles for the dt and dd elements, used in description lists (dl elements). Authors attempting to incorporate figure or details into their existing pages would have to take care to avoid unintended styling clashes caused by selectors that aren't specific enough. i.e. It's common for authors to simply use the selector as "dt" or "dd", rather than "dl>dt" and "dl>dd", as that is currently unnecessary. Authors will then have to adjust their styles, which could potentially cause unintended side affects to to the change in specificity of the selectors.

=== Default Styles ===
The default styles for dt and dd elements is not ideal for figures. As the dd element is usually indented with margin and/or padding, authors will usually be required to remove this with their own stylesheets, rather than being able to rely on more sensible defaults. It is true that eventually UA stylesheets may have special rules for "figure > dt" and the like, but during the transition period it will be extra work to remove inappropriate default styles.

=== Structural Differences ===
Since authors are already familiar with the meanings and structure of dt and dd when used within dl, their very distinct meanings and structure when used within the figure and details may be confusing to authors.

The dl element may contain multiple groups of dt and dd elements, wheres within figure and details, each element may only be used once.

Within dl, a group must have one or more dt elements followed by one or more dd elements, whereas within figure, the elements may appear in any order.

=== Semantic Differences ===
For the figure element, it's not very intuitive to determine which of either dt or dd represents the caption and which represents the content such as an image. Some authors may interpret dd as being the description, which is what it means within dl, and thus assume that dd is meant for the caption, and the dt meant for the image or other content. However, the spec defines these with the opposite meanings, with the understanding the dt, or title, is a synonym for caption. Both alternatives points of view make some sense, but neither stands out as being obviously correct. This will likely lead to a lot of authors using these elements in reverse.

=== Unnecessary Elements ===
The dd element is completely unnecessary to distinguish it from the caption, which has its own element. This combined with the extraneous div required for IE compatibility adds two extra elements that are not logically needed. A previous iteration of the spec used the legend element for the caption, without any special wrapper just for the content. This model seems much more intuitive and required less markup to use, and thus easier to get right. Authors who do wish to have an extra wrapper around the content may use div if they choose, but should not be required to use it.

When there is no caption, using figure then requires authors to use 3 extra elements, where they should only need one:

<div> 
<figure>
<dd><img src="image" alt="..."></dd>
</figure>
</div>

This will be unappealing to authors who may, as a result of the complexity, opt not to use the figure element.

=== Aesthetics ===
Aesthetics is not necessarily the sole or most important concern. However, many authors seem to find the novel use of dt and dd unpleasant to read. dt and dd are relatively obscure elements, they are very short abbreviations, and their meaning in context is unclear, especially in figure. In particular, the following markup seems mysterious and strikes many as ugly and unintuitive:

<figure>
<dd><img src="image" alt="..."></dd>
<dt>A Pair of Cats</dd>
</figure>

This seems to trigger a "yuck factor", and it would be wise to avoid that. Aesthetics may seem like a relatively unimportant factor; however, the desire to avoid introducing new elements that led to dt/dd being used is itself largely an aesthetic concern.

----

== Proposal 1 (<code><figure><legend>...</legend>...</figure>; <details><legend>...</legend>...</details></code>) ==
The proposal is to restore the use of the legend element for marking up the captions within both figure and details elements.

== Proposal 2 (<code><figure><c>...</c>...</figure>; <details><c>...</c>...</details></code>) ==
The proposal is to introduce a new c element for marking up the captions within both figure and details elements.

== Proposal 3 (<code><figure><fcaption>...</fcaption>...</figure>; <details><dlabel>...</dlabel>...</details></code>) ==

=== Summary ===
The current HTML5 draft uses the dt and dd elements to markup the captions and content of the figure and details elements. This change proposal explains why the dt and dd elements are a poor choice for these purposes and proposes an alternative. Specifically, the proposal is to introduce a new fcaption element for marking up the caption within figure, and a dlabel element for use within details. The content portions of these elements (as opposed to the caption or label) would not have any special markup, they would be nested directly inside the figure or details element.

=== Additional Rationale ===

In addition to the rationale relative to the status quo in the spec, this proposal is better than some of the proposed alternatives.

==== Follows HTML Precedent for Structured Elements ====

Some HTML elements have relatively free content models, while others are "structured" - there are some or all child elements that have special meaning. Structured elements typically have helper elements that are specific to one element, or to a small family of related elements, to express their internal structure. Examples, from past versions of HTML, new in HTML5, and proposed for future versions of HTML:

* table has thead, tfoot, tbody, td, th, tr, caption, col and colgroup.
* ul, ol and menu have li.
* fieldset has legend.
* applet and object have param.
* video and audio have source.
* dl has dt and dd.
* select and datalist have option and optgroup.
* ruby has rp and rt.
* datagrid was proposed to have a number of specialized child elements.

In some cases (such as table or the list elements), the structured element can ''only'' have its specialized children. In other cases (fieldset, applet/object, or audio/video), the structured element can have relatively free content in addition to its specialized children.

Thus, when introducing new structured elements such as figure and details, the normal design pattern for HTML is to introduce new specialized child elements to represent their structure. It is not the norm to reuse a very common element such as "h1" to represent specialized structure in a certain context. It is not the norm to reuse specialized child elements in a way that differs from their established content and meaning, as with dt/dd or legend. And it is unprecedented to use an attribute that can occur on any element to represent specialized structure, as with the proposed caption attribute. Furthermore, details and figure are not particularly closely related in purpose. One is a UI control, the other is a representation of the structure of prose documents. So it does not make sense for them to share a specialized child element.

Applying a different design pattern for internal element structure to figure and details is likely to be confusing. The confusion of deviating from the usual HTML design pattern for this is likely to be greater than the cognitive cost of introducing no or fewer new elements.

==== Avoids Clunky or Inappropriate Names ====

The new element fltcap, suggested by another Change Proposal, appears confusing and mysterious. No one seems to get what it means on first reading. The expansion as "floating caption" seems confusing and semantically wrong. First, "floating caption" is not a very common term of art in publishing, but whenever it is used, it seems to refer to [http://www.google.com/search?client=safari&rls=en&q=floating+caption&ie=UTF-8&oe=UTF-8 captions overlayed on top of the image], not figure captions in general. Furthermore, a details control does not in general have a "caption", floating or otherwise, rather it is a UI control and therefore is normally considered to have a "label".

The new element c is an extremely short and mysterious name. There is a limit to how many one-letter identifiers one can have in a language without rendering it unreadable or confusing, and they should be reserved for extremely common elements. Captions do not make the cut.

Reusing legend does not seem like a good semantic fit for either figure or details. While a figure's caption is sometimes called a legend, the term "legend" in this context more often refers to the key next to a map or chart explaining how to read various visual elements. A details element is a UI element and those aren't ordinarily referred to as having a legend.

h1 connotes "header", which is not quite right for either figure or details.

The caption attribute is good for figure, but not details. However, that proposal retains the dt/dd names for details. And those names remain clunky and non-obvious in the context of details (hard to remember which is which) and retain all of the general problems of using dt/dd for both elements.

"caption" and "label", or variations thereof, are the most semantically appropriate names for the caption and label respectively on figure and details.

==== Does Not Introduce Compatibility Problems ====

Reuse of almost any existing element in an unrelated context introduces compatibility problems, whether "hard" problems with parsing or behavior, or "soft" problems with pre-existing author styles. This Change Proposal uses brand new elements and thus avoids all these problems, unlike the use of dt/dd, legend, label, caption, or h1. All of those are known to have some lesser or greater technical issues.

==== Does Not Introduce Redundant Elements for the Content ====

Semantically, and for purposes of UA behavior, we only really need to distinguish the caption part of the element. There is no need to wrap the remaining body part with a special element. True, they can be handy as a styling hook, but authors who need that styling hook can always use <div>.

=== Proposal Details ===

This proposal includes the following specific changes:

1) Define a new element fcaption. Details would be approximately as follows:
Categories: none
Contexts in which the element may be used: As the first or last child of a figure element.
Content model: flow content
Content attributes: global attributes
DOM interface: HTMLElement
Semantics: The fcaption element represents the caption of the figure that is its parent, if it has a parent that is a figure element.

2) Define a new element dlabel. Details would be as above, but replacing mentions of "figure" with "details".

3) Change figure as follows:
New content model: "Flow content, optionally either preceded by or followed by an fcaption element."
New caption definition: "The first fcaption element child of the element, if any, represents the caption of the figure element's contents. If there is no child fcaption element, then there is no caption."
New content definition: "All child elements other than the first fcaption element, if there are any, represent the element's contents. If there are no child elements besides the first fcaption, then there are no contents.
Update the examples appropriately.
Update the suggested UA stylesheet in the Rendering section as appropriate.

4) Change details as follows:
New content model: "Flow content, optionally either preceded by or followed by a dlabel element."
New summary definition: "The first dlabel element child of the element, if any, represents the summary of the details. If there is no child dlabel element, the user agent should provide its own label (e.g. "Details")."
New details definition: "All child elements other than the first dlabel element, if there are any, represent the details. If there are no child elements besides the first dlabel, then there are no details.
Update the examples appropriately.
Update the suggested UA stylesheet in the Rendering section as appropriate.

=== Impact ===

This proposal would have a potential negative impact on authors: it would introduce two new elements relative to the current spec.

However, the positive impact is arguably greater. The new elements would be more readable, more intuitive, and more in line with the standard HTML design pattern for structured elements. Thus, despite the addition of more elements, the overall increase in cognitive load will be less. In addition, there is no need to use <div> or any other wonky workarounds to get it to work in legacy UAs.

The impact on implementations is trivial. fcaption and dlabel are trivial to implement, and the appearance and behavior can be mostly defined via stylesheet. This is not significantly more work than altering the rendering of dt and dd inside figure and details; in fact it may be less work in some implementations.

The impact on conformance checkers and authoring tools is also trivial; neither approach is easier or harder to validate or generate.

There is no direct impact on users either way.

== Proposal 3b (<code><figure><figcaption>...</figcaption>...</figure>; <details><dsummary>...</dsummary>...</details></code>) ==
Same as proposal 3, but with the element names "figcaption" and "dsummary" respectively.

Reasoning: "figcaption" is more memorable. "dsummary" more accurately describes what the "label" of a <details> element is.

== Proposal 4 (<code><figure><caption>...</caption>...</figure>; <details><label>...</label>...</details></code>) ==
The proposal is to use the caption element within figure and the label element within details for marking up the captions.

CON: "caption" has significant unsolved parsing problems.

CON: "label" use in <details> would prevent the summary of a <details> from containing a labeled <progress> element, which is common, and would make the content model ambiguous (since the contents of a <details> can itself contain labels).

== Proposal 5 (<code><figure><h1>...</h1>...</figure>; <details><h1>...</h1>...</details></code>) ==
The proposal is to repurpose the h1 element for marking up the captions within both figure and details elements.

CON: Styling issues in legacy UAs.

CON: Content model would be ambiguous.

== Proposal 6 (<code><figure><p caption>...</p>...</figure></code>)==
===Summary===
The proposal is to introduce a caption attribute that may be used on an element within figure to denote the contents of that element as being the caption. This proposal does not address the details element.

===Rationale===
* This allows the most intuitive name to be used, without the problems caused by actually using <caption> as an element name.
* It roughly parallels the existing uses of attributes to tie together an element and some containing element with additional semantics, as seen in <time pubdate>.
* It does not alter the existing semantics of the element it is applied to; a <ul caption> is still a <ul>, a <time caption> is still a <time>, etc.
* It forgoes the need for a 'wrapper' element when you just want to immediately apply a special element. For example, if you are putting photographs in a figure, with the only caption being the time it was taken, it would be best if you could simply put in the <time> without a wrapper. That is, <figure><img src=foo><time caption datetime=2010-01-11>January 11th, 2010</time></figure> is preferable to <figure><img src=foo><caption><time datetime=2010-01-11>January 11th, 2010</time></caption></figure>

===Details===
* Figure content model should be changed to "Flow Content".
* The third paragraph in the prose (explaining the use of the <dt> element) should be changed to roughly: "The first child element with the caption attribute, if any, represents the caption of the figure element's contents. If there is no child element with the caption attribute, then there is no caption."
* The fourth paragraph in the prose (explaining the use of the <dd> element) should be changed to roughly: "Any additional contents of the element beyond the caption (defined above), if any, represents the element's contents. If there are no additional contents, then there are no contents."
* "caption" added to the list of global attributes in the "Global Attributes" section. In its section it should contain roughly: "All HTML elements in the Flow Content category may have the caption content attribute set. The caption attribute is a boolean attribute. When caption is set on an element that is a child of a figure element, the first such element defines the caption for that figure element. It is invalid for a figure to have multiple child elements with the caption attribute set; in such a case, the first such element is the caption for the figure and the caption attribute is invalid and has no effect on subsequent elements. The caption attribute is invalid and has no effect on any element that is not a direct child of a figure element."

===Impact===
Easy denotation of figure captions, without any compatibility hacks that may persist long into the future.

== Proposal 7 (<code><figure><fcaption>...</fcaption>...</figure>; <details><dlabel>...</dlabel>...</details></code> or <code><figure><fcaption>...</fcaption><fbody>...</fbody></figure>; <details><dlabel>...</dlabel><dbody>...</dbody></details></code>) ==

=== Summary ===

The current HTML5 draft uses the dt and dd elements to markup the captions and content of the figure and details elements. This change proposal explains why the dt and dd elements are a poor choice for these purposes and proposes an alternative. Specifically, the proposal is to introduce a new fcaption element for marking up the caption within figure, and a dlabel element for use within details to replace dt. In addition, it proposes an optional fbody element for use inside figure, and an optional dbody element for use inside details, to mark up the content/body and replace dd.

Change Proposal: figure and details

2010-01-11T22:09:04Z

Mjs:

== Summary ==
The current HTML5 draft uses the dt and dd elements to markup the captions and content of the figure and details elements. This change proposal explains why the dt and dd elements are a poor choice for these purposes and proposes an alternative.
----
== Rationale Against Using dt/dd for figure and details Elements ==

=== Backwards Compatibility ===
Due to IE's legacy parsing issues, the dt and dd elements create problems for authors attempting to use and style these elements. The simplest workaround (wrapping both figure and details in an extra div) that authors would need to apply to avoid these issues is not intuitive, as clearly demonstrated by the wide range of alternative solutions that were attempted prior to its discovery.

=== Legacy Cruft ===
The use of extra div elements may lead to a lot of confusion among authors, at least initially, and ultimately end up becoming extraneous markup that authors just include without really understanding why, even after the current generation of browsers are long since dead.

We've seen this kind of problem before with authors, for example, frequently wrapping scripts with pseudo-HTML-comments initially intended to hide the script from what are now very ancient browsers, none of which have been in use for over a decade.

=== Styling Clashes ===
In addition to the aforementioned styling bug in IE, many existing stylesheets already include styles for the dt and dd elements, used in description lists (dl elements). Authors attempting to incorporate figure or details into their existing pages would have to take care to avoid unintended styling clashes caused by selectors that aren't specific enough. i.e. It's common for authors to simply use the selector as "dt" or "dd", rather than "dl>dt" and "dl>dd", as that is currently unnecessary. Authors will then have to adjust their styles, which could potentially cause unintended side affects to to the change in specificity of the selectors.

=== Default Styles ===
The default styles for dt and dd elements is not ideal for figures. As the dd element is usually indented with margin and/or padding, authors will usually be required to remove this with their own stylesheets, rather than being able to rely on more sensible defaults. It is true that eventually UA stylesheets may have special rules for "figure > dt" and the like, but during the transition period it will be extra work to remove inappropriate default styles.

=== Structural Differences ===
Since authors are already familiar with the meanings and structure of dt and dd when used within dl, their very distinct meanings and structure when used within the figure and details may be confusing to authors.

The dl element may contain multiple groups of dt and dd elements, wheres within figure and details, each element may only be used once.

Within dl, a group must have one or more dt elements followed by one or more dd elements, whereas within figure, the elements may appear in any order.

=== Semantic Differences ===
For the figure element, it's not very intuitive to determine which of either dt or dd represents the caption and which represents the content such as an image. Some authors may interpret dd as being the description, which is what it means within dl, and thus assume that dd is meant for the caption, and the dt meant for the image or other content. However, the spec defines these with the opposite meanings, with the understanding the dt, or title, is a synonym for caption. Both alternatives points of view make some sense, but neither stands out as being obviously correct. This will likely lead to a lot of authors using these elements in reverse.

=== Unnecessary Elements ===
The dd element is completely unnecessary to distinguish it from the caption, which has its own element. This combined with the extraneous div required for IE compatibility adds two extra elements that are not logically needed. A previous iteration of the spec used the legend element for the caption, without any special wrapper just for the content. This model seems much more intuitive and required less markup to use, and thus easier to get right. Authors who do wish to have an extra wrapper around the content may use div if they choose, but should not be required to use it.

When there is no caption, using figure then requires authors to use 3 extra elements, where they should only need one:

<div> 
<figure>
<dd><img src="image" alt="..."></dd>
</figure>
</div>

This will be unappealing to authors who may, as a result of the complexity, opt not to use the figure element.

=== Aesthetics ===
Aesthetics is not necessarily the sole or most important concern. However, many authors seem to find the novel use of dt and dd unpleasant to read. dt and dd are relatively obscure elements, they are very short abbreviations, and their meaning in context is unclear, especially in figure. In particular, the following markup seems mysterious and strikes many as ugly and unintuitive:

<figure>
<dd><img src="image" alt="..."></dd>
<dt>A Pair of Cats</dd>
</figure>

This seems to trigger a "yuck factor", and it would be wise to avoid that. Aesthetics may seem like a relatively unimportant factor; however, the desire to avoid introducing new elements that led to dt/dd being used is itself largely an aesthetic concern.

----

== Proposal 1 ==
The proposal is to restore the use of the legend element for marking up the captions within both figure and details elements.

== Proposal 2 ==
The proposal is to introduce a new c element for marking up the captions within both figure and details elements.

== Proposal 3 ==

=== Summary ===
The current HTML5 draft uses the dt and dd elements to markup the captions and content of the figure and details elements. This change proposal explains why the dt and dd elements are a poor choice for these purposes and proposes an alternative. Specifically, the proposal is to introduce a new fcaption element for marking up the caption within figure, and a dlabel element for use within details. The content portions of these elements (as opposed to the caption or label) would not have any special markup, they would be nested directly inside the figure or details element.

=== Additional Rationale ===

In addition to the rationale relative to the status quo in the spec, this proposal is better than some of the proposed alternatives.

==== Follows HTML Precedent for Structured Elements ====

Some HTML elements have relatively free content models, while others are "structured" - there are some or all child elements that have special meaning. Structured elements typically have helper elements that are specific to one element, or to a small family of related elements, to express their internal structure. Examples, from past versions of HTML, new in HTML5, and proposed for future versions of HTML:

* table has thead, tfoot, tbody, td, th, tr, caption, col and colgroup.
* ul, ol and menu have li.
* fieldset has legend.
* applet and object have param.
* video and audio have source.
* dl has dt and dd.
* select and datalist have option and optgroup.
* ruby has rp and rt.
* datagrid was proposed to have a number of specialized child elements.

In some cases (such as table or the list elements), the structured element can ''only'' have its specialized children. In other cases (fieldset, applet/object, or audio/video), the structured element can have relatively free content in addition to its specialized children.

Thus, when introducing new structured elements such as figure and details, the normal design pattern for HTML is to introduce new specialized child elements to represent their structure. It is not the norm to reuse a very common element such as "h1" to represent specialized structure in a certain context. It is not the norm to reuse specialized child elements in a way that differs from their established content and meaning, as with dt/dd or legend. And it is unprecedented to use an attribute that can occur on any element to represent specialized structure, as with the proposed caption attribute. Furthermore, details and figure are not particularly closely related in purpose. One is a UI control, the other is a representation of the structure of prose documents. So it does not make sense for them to share a specialized child element.

Applying a different design pattern for internal element structure to figure and details is likely to be confusing. The confusion of deviating from the usual HTML design pattern for this is likely to be greater than the cognitive cost of introducing no or fewer new elements.

==== Avoids Clunky or Inappropriate Names ====

The new element fltcap, suggested by another Change Proposal, appears confusing and mysterious. No one seems to get what it means on first reading. The expansion as "floating caption" seems confusing and semantically wrong. First, "floating caption" is not a very common term of art in publishing, but whenever it is used, it seems to refer to [http://www.google.com/search?client=safari&rls=en&q=floating+caption&ie=UTF-8&oe=UTF-8 captions overlayed on top of the image], not figure captions in general. Furthermore, a details control does not in general have a "caption", floating or otherwise, rather it is a UI control and therefore is normally considered to have a "label".

The new element c is an extremely short and mysterious name. There is a limit to how many one-letter identifiers one can have in a language without rendering it unreadable or confusing, and they should be reserved for extremely common elements. Captions do not make the cut.

Reusing legend does not seem like a good semantic fit for either figure or details. While a figure's caption is sometimes called a legend, the term "legend" in this context more often refers to the key next to a map or chart explaining how to read various visual elements. A details element is a UI element and those aren't ordinarily referred to as having a legend.

h1 connotes "header", which is not quite right for either figure or details.

"caption" and "label", or variations thereof, are the most semantically appropriate names for the caption and label respectively on figure and details.

==== Does Not Introduce Compatibility Problems ====

Reuse of almost any existing element in an unrelated context introduces compatibility problems, whether "hard" problems with parsing or behavior, or "soft" problems with pre-existing author styles. This Change Proposal uses brand new elements and thus avoids all these problems, unlike the use of dt/dd, legend, label, caption, or h1. All of those are known to have some lesser or greater technical issues.

=== Proposal Details ===

=== Impact ===

== Proposal 4 ==
The proposal is to use the caption element within figure and the label element within details for marking up the captions.

== Proposal 5 ==
The proposal is to repurpose the h1 element for marking up the captions within both figure and details elements.

== Proposal 6==
===Summary===
The proposal is to introduce a caption attribute that may be used on an element within figure to denote the contents of that element as being the caption. This proposal does not address the details element.

===Rationale===
* This allows the most intuitive name to be used, without the problems caused by actually using <caption> as an element name.
* It roughly parallels the existing uses of attributes to tie together an element and some containing element with additional semantics, as seen in <time pubdate>.
* It does not alter the existing semantics of the element it is applied to; a <ul caption> is still a <ul>, a <time caption> is still a <time>, etc.
* It forgoes the need for a 'wrapper' element when you just want to immediately apply a special element. For example, if you are putting photographs in a figure, with the only caption being the time it was taken, it would be best if you could simply put in the <time> without a wrapper. That is, <figure><img src=foo><time caption datetime=2010-01-11>January 11th, 2010</time></figure> is preferable to <figure><img src=foo><caption><time datetime=2010-01-11>January 11th, 2010</time></caption></figure>

===Details===
* Figure content model should be changed to "Flow Content".
* The third paragraph in the prose (explaining the use of the <dt> element) should be changed to roughly: "The first child element with the caption attribute, if any, represents the caption of the figure element's contents. If there is no child element with the caption attribute, then there is no caption."
* The fourth paragraph in the prose (explaining the use of the <dd> element) should be changed to roughly: "Any additional contents of the element beyond the caption (defined above), if any, represents the element's contents. If there are no additional contents, then there are no contents."
* "caption" added to the list of global attributes in the "Global Attributes" section. In its section it should contain roughly: "All HTML elements in the Flow Content category may have the caption content attribute set. The caption attribute is a boolean attribute. When caption is set on an element that is a child of a figure element, the first such element defines the caption for that figure element. It is invalid for a figure to have multiple child elements with the caption attribute set; in such a case, the first such element is the caption for the figure and the caption attribute is invalid and has no effect on subsequent elements. The caption attribute is invalid and has no effect on any element that is not a direct child of a figure element."

===Impact===
Easy denotation of figure captions, without any compatibility hacks that may persist long into the future.

== Proposal 7 ==

=== Summary ===

The current HTML5 draft uses the dt and dd elements to markup the captions and content of the figure and details elements. This change proposal explains why the dt and dd elements are a poor choice for these purposes and proposes an alternative. Specifically, the proposal is to introduce a new fcaption element for marking up the caption within figure, and a dlabel element for use within details to replace dt. In addition, it proposes an fbody element for use inside figure, and a dbody element for use inside details, to mark up the content/body and replace dd.

Change Proposal: figure and details

2010-01-11T18:01:10Z

Mjs: /* Follows HTML Precedent for Structured Elements */

== Summary ==
The current HTML5 draft uses the dt and dd elements to markup the captions and content of the figure and details elements. This change proposal explains why the dt and dd elements are a poor choice for these purposes and proposes an alternative.
----
== Rationale Against Using dt/dd for figure and details Elements ==

=== Backwards Compatibility ===
Due to IE's legacy parsing issues, the dt and dd elements create problems for authors attempting to use and style these elements. The simplest workaround (wrapping both figure and details in an extra div) that authors would need to apply to avoid these issues is not intuitive, as clearly demonstrated by the wide range of alternative solutions that were attempted prior to its discovery.

=== Legacy Cruft ===
The use of extra div elements may lead to a lot of confusion among authors, at least initially, and ultimately end up becoming extraneous markup that authors just include without really understanding why, even after the current generation of browsers are long since dead.

We've seen this kind of problem before with authors, for example, frequently wrapping scripts with pseudo-HTML-comments initially intended to hide the script from what are now very ancient browsers, none of which have been in use for over a decade.

=== Styling Clashes ===
In addition to the aforementioned styling bug in IE, many existing stylesheets already include styles for the dt and dd elements, used in description lists (dl elements). Authors attempting to incorporate figure or details into their existing pages would have to take care to avoid unintended styling clashes caused by selectors that aren't specific enough. i.e. It's common for authors to simply use the selector as "dt" or "dd", rather than "dl>dt" and "dl>dd", as that is currently unnecessary. Authors will then have to adjust their styles, which could potentially cause unintended side affects to to the change in specificity of the selectors.

=== Default Styles ===
The default styles for dt and dd elements is not ideal for figures. As the dd element is usually indented with margin and/or padding, authors will usually be required to remove this with their own stylesheets, rather than being able to rely on more sensible defaults. It is true that eventually UA stylesheets may have special rules for "figure > dt" and the like, but during the transition period it will be extra work to remove inappropriate default styles.

=== Structural Differences ===
Since authors are already familiar with the meanings and structure of dt and dd when used within dl, their very distinct meanings and structure when used within the figure and details may be confusing to authors.

The dl element may contain multiple groups of dt and dd elements, wheres within figure and details, each element may only be used once.

Within dl, a group must have one or more dt elements followed by one or more dd elements, whereas within figure, the elements may appear in any order.

=== Semantic Differences ===
For the figure element, it's not very intuitive to determine which of either dt or dd represents the caption and which represents the content such as an image. Some authors may interpret dd as being the description, which is what it means within dl, and thus assume that dd is meant for the caption, and the dt meant for the image or other content. However, the spec defines these with the opposite meanings, with the understanding the dt, or title, is a synonym for caption. Both alternatives points of view make some sense, but neither stands out as being obviously correct. This will likely lead to a lot of authors using these elements in reverse.

=== Unnecessary Elements ===
The dd element is completely unnecessary to distinguish it from the caption, which has its own element. This combined with the extraneous div required for IE compatibility adds two extra elements that are not logically needed. A previous iteration of the spec used the legend element for the caption, without any special wrapper just for the content. This model seems much more intuitive and required less markup to use, and thus easier to get right. Authors who do wish to have an extra wrapper around the content may use div if they choose, but should not be required to use it.

When there is no caption, using figure then requires authors to use 3 extra elements, where they should only need one:

<div> 
<figure>
<dd><img src="image" alt="..."></dd>
</figure>
</div>

This will be unappealing to authors who may, as a result of the complexity, opt not to use the figure element.

=== Aesthetics ===
Aesthetics is not necessarily the sole or most important concern. However, many authors seem to find the novel use of dt and dd unpleasant to read. dt and dd are relatively obscure elements, they are very short abbreviations, and their meaning in context is unclear, especially in figure. In particular, the following markup seems mysterious and strikes many as ugly and unintuitive:

<figure>
<dd><img src="image" alt="..."></dd>
<dt>A Pair of Cats</dd>
</figure>

This seems to trigger a "yuck factor", and it would be wise to avoid that. Aesthetics may seem like a relatively unimportant factor; however, the desire to avoid introducing new elements that led to dt/dd being used is itself largely an aesthetic concern.

----

== Proposal 1 ==
The proposal is to restore the use of the legend element for marking up the captions within both figure and details elements.

== Proposal 2 ==
The proposal is to introduce a new c element for marking up the captions within both figure and details elements.

== Proposal 3 ==

=== Summary ===
The current HTML5 draft uses the dt and dd elements to markup the captions and content of the figure and details elements. This change proposal explains why the dt and dd elements are a poor choice for these purposes and proposes an alternative. Specifically, the proposal is to introduce a new fcaption element for marking up the caption within figure, and a dlabel element for use within details. The content portions of these elements (as opposed to the caption or label) would not have any special markup, they would be nested directly inside the figure or details element.

=== Additional Rationale ===

In addition to the rationale relative to the status quo in the spec, this proposal is better than some of the proposed alternatives.

==== Follows HTML Precedent for Structured Elements ====

Some HTML elements have relatively free content models, while others are "structured" - there are some or all child elements that have special meaning. Structured elements typically have helper elements that are specific to one element, or to a small family of related elements, to express their internal structure. Examples, from past versions of HTML, new in HTML5, and proposed for future versions of HTML:

* table has thead, tfoot, tbody, td, th, tr, caption, col and colgroup.
* ul, ol and menu have li.
* fieldset has legend.
* applet and object have param.
* video and audio have source.
* dl has dt and dd.
* select and datalist have option and optgroup.
* ruby has rp and rt.
* datagrid was proposed to have a number of specialized child elements.

In some cases (such as table or the list elements), the structured element can ''only'' have its specialized children. In other cases (fieldset, applet/object, or audio/video), the structured element can have relatively free content in addition to its specialized children.

Thus, when introducing new structured elements such as figure and details, the normal design pattern for HTML is to introduce new specialized child elements to represent their structure. It is not the norm to reuse a very common element such as "h1" to represent specialized structure in a certain context. It is not the norm to reuse specialized child elements in a way that differs from their established content and meaning, as with dt/dd or legend. And it is unprecedented to use an attribute that can occur on any element to represent specialized structure, as with the proposed caption attribute. Furthermore, details and figure are not particularly closely related in purpose. One is a UI control, the other is a representation of the structure of prose documents. So it does not make sense for them to share a specialized child element.

Applying a different design pattern for internal element structure to figure and details is likely to be confusing. The confusion of deviating from the usual HTML design pattern for this is likely to be greater than the cognitive cost of introducing no or fewer new elements.

==== Avoids Clunky or Inappropriate Names ====

The new element fltcap, suggested by another Change Proposal, appears confusing and mysterious. No one seems to get what it means on first reading. The expansion as "floating caption" seems confusing and semantically wrong. First, "floating caption" is not a very common term of art in publishing, but whenever it is used, it seems to refer to [http://www.google.com/search?client=safari&rls=en&q=floating+caption&ie=UTF-8&oe=UTF-8 captions overlayed on top of the image], not figure captions in general. Furthermore, a details control does not in general have a "caption", floating or otherwise, rather it is a UI control and therefore is normally considered to have a "label".

The new element c is an extremely short and mysterious name. There is a limit to how many one-letter identifiers one can have in a language without rendering it unreadable or confusing, and they should be reserved for extremely common elements. Captions do not make the cut.

Reusing legend does not seem like a good semantic fit for either figure or details. While a figure's caption is sometimes called a legend, the term "legend" in this context more often refers to the key next to a map or chart explaining how to read various visual elements. A details element is a UI element and those aren't ordinarily referred to as having a legend.

h1 connotes "header", which is not quite right for either figure or details.

"caption" and "label", or variations thereof, are the most semantically appropriate names for the caption and label respectively on figure and details.

==== Does Not Introduce Compatibility Problems ====

Reuse of almost any existing element in an unrelated context introduces compatibility problems, whether "hard" problems with parsing or behavior, or "soft" problems with pre-existing author styles. This Change Proposal uses brand new elements and thus avoids all these problems, unlike the use of dt/dd, legend, label, caption, or h1. All of those are known to have some lesser or greater technical issues.

=== Proposal Details ===

=== Impact ===

== Proposal 4 ==
The proposal is to use the caption element within figure and the label element within details for marking up the captions.

== Proposal 5 ==
The proposal is to repurpose the h1 element for marking up the captions within both figure and details elements.

== Proposal 6==
===Summary===
The proposal is to introduce a caption attribute that may be used on an element within figure to denote the contents of that element as being the caption. This proposal does not address the details element.

===Rationale===
* This allows the most intuitive name to be used, without the problems caused by actually using <caption> as an element name.
* It roughly parallels the existing uses of attributes to tie together an element and some containing element with additional semantics, as seen in <time pubdate>.
* It does not alter the existing semantics of the element it is applied to; a <ul caption> is still a <ul>, a <time caption> is still a <time>, etc.
* It forgoes the need for a 'wrapper' element when you just want to immediately apply a special element. For example, if you are putting photographs in a figure, with the only caption being the time it was taken, it would be best if you could simply put in the <time> without a wrapper. That is, <figure><img src=foo><time caption datetime=2010-01-11>January 11th, 2010</time></figure> is preferable to <figure><img src=foo><caption><time datetime=2010-01-11>January 11th, 2010</time></caption></figure>

===Details===
* Figure content model should be changed to "Flow Content".
* The third paragraph in the prose (explaining the use of the <dt> element) should be changed to roughly: "The first child element with the caption attribute, if any, represents the caption of the figure element's contents. If there is no child element with the caption attribute, then there is no caption."
* The fourth paragraph in the prose (explaining the use of the <dd> element) should be changed to roughly: "Any additional contents of the element beyond the caption (defined above), if any, represents the element's contents. If there are no additional contents, then there are no contents."
* "caption" added to the list of global attributes in the "Global Attributes" section. In its section it should contain roughly: "All HTML elements in the Flow Content category may have the caption content attribute set. The caption attribute is a boolean attribute. When caption is set on an element that is a child of a figure element, the first such element defines the caption for that figure element. It is invalid for a figure to have multiple child elements with the caption attribute set; in such a case, the first such element is the caption for the figure and the caption attribute is invalid and has no effect on subsequent elements. The caption attribute is invalid and has no effect on any element that is not a direct child of a figure element."

===Impact===
Easy denotation of figure captions, without any compatibility hacks that may persist long into the future.

Change Proposal: figure and details

2010-01-11T18:00:32Z

Mjs: /* Follows HTML Precedent for Structured Elements */

== Summary ==
The current HTML5 draft uses the dt and dd elements to markup the captions and content of the figure and details elements. This change proposal explains why the dt and dd elements are a poor choice for these purposes and proposes an alternative.
----
== Rationale Against Using dt/dd for figure and details Elements ==

=== Backwards Compatibility ===
Due to IE's legacy parsing issues, the dt and dd elements create problems for authors attempting to use and style these elements. The simplest workaround (wrapping both figure and details in an extra div) that authors would need to apply to avoid these issues is not intuitive, as clearly demonstrated by the wide range of alternative solutions that were attempted prior to its discovery.

=== Legacy Cruft ===
The use of extra div elements may lead to a lot of confusion among authors, at least initially, and ultimately end up becoming extraneous markup that authors just include without really understanding why, even after the current generation of browsers are long since dead.

We've seen this kind of problem before with authors, for example, frequently wrapping scripts with pseudo-HTML-comments initially intended to hide the script from what are now very ancient browsers, none of which have been in use for over a decade.

=== Styling Clashes ===
In addition to the aforementioned styling bug in IE, many existing stylesheets already include styles for the dt and dd elements, used in description lists (dl elements). Authors attempting to incorporate figure or details into their existing pages would have to take care to avoid unintended styling clashes caused by selectors that aren't specific enough. i.e. It's common for authors to simply use the selector as "dt" or "dd", rather than "dl>dt" and "dl>dd", as that is currently unnecessary. Authors will then have to adjust their styles, which could potentially cause unintended side affects to to the change in specificity of the selectors.

=== Default Styles ===
The default styles for dt and dd elements is not ideal for figures. As the dd element is usually indented with margin and/or padding, authors will usually be required to remove this with their own stylesheets, rather than being able to rely on more sensible defaults. It is true that eventually UA stylesheets may have special rules for "figure > dt" and the like, but during the transition period it will be extra work to remove inappropriate default styles.

=== Structural Differences ===
Since authors are already familiar with the meanings and structure of dt and dd when used within dl, their very distinct meanings and structure when used within the figure and details may be confusing to authors.

The dl element may contain multiple groups of dt and dd elements, wheres within figure and details, each element may only be used once.

Within dl, a group must have one or more dt elements followed by one or more dd elements, whereas within figure, the elements may appear in any order.

=== Semantic Differences ===
For the figure element, it's not very intuitive to determine which of either dt or dd represents the caption and which represents the content such as an image. Some authors may interpret dd as being the description, which is what it means within dl, and thus assume that dd is meant for the caption, and the dt meant for the image or other content. However, the spec defines these with the opposite meanings, with the understanding the dt, or title, is a synonym for caption. Both alternatives points of view make some sense, but neither stands out as being obviously correct. This will likely lead to a lot of authors using these elements in reverse.

=== Unnecessary Elements ===
The dd element is completely unnecessary to distinguish it from the caption, which has its own element. This combined with the extraneous div required for IE compatibility adds two extra elements that are not logically needed. A previous iteration of the spec used the legend element for the caption, without any special wrapper just for the content. This model seems much more intuitive and required less markup to use, and thus easier to get right. Authors who do wish to have an extra wrapper around the content may use div if they choose, but should not be required to use it.

When there is no caption, using figure then requires authors to use 3 extra elements, where they should only need one:

<div> 
<figure>
<dd><img src="image" alt="..."></dd>
</figure>
</div>

This will be unappealing to authors who may, as a result of the complexity, opt not to use the figure element.

=== Aesthetics ===
Aesthetics is not necessarily the sole or most important concern. However, many authors seem to find the novel use of dt and dd unpleasant to read. dt and dd are relatively obscure elements, they are very short abbreviations, and their meaning in context is unclear, especially in figure. In particular, the following markup seems mysterious and strikes many as ugly and unintuitive:

<figure>
<dd><img src="image" alt="..."></dd>
<dt>A Pair of Cats</dd>
</figure>

This seems to trigger a "yuck factor", and it would be wise to avoid that. Aesthetics may seem like a relatively unimportant factor; however, the desire to avoid introducing new elements that led to dt/dd being used is itself largely an aesthetic concern.

----

== Proposal 1 ==
The proposal is to restore the use of the legend element for marking up the captions within both figure and details elements.

== Proposal 2 ==
The proposal is to introduce a new c element for marking up the captions within both figure and details elements.

== Proposal 3 ==

=== Summary ===
The current HTML5 draft uses the dt and dd elements to markup the captions and content of the figure and details elements. This change proposal explains why the dt and dd elements are a poor choice for these purposes and proposes an alternative. Specifically, the proposal is to introduce a new fcaption element for marking up the caption within figure, and a dlabel element for use within details. The content portions of these elements (as opposed to the caption or label) would not have any special markup, they would be nested directly inside the figure or details element.

=== Additional Rationale ===

In addition to the rationale relative to the status quo in the spec, this proposal is better than some of the proposed alternatives.

==== Follows HTML Precedent for Structured Elements ====

Some HTML elements have relatively free content models, while others are "structured" - there are some or all child elements that have special meaning. Structured elements typically have helper elements that are specific to one element, or to a small family of related elements, to express their internal structure. Examples, from past versions of HTML, new in HTML5, and proposed for future versions of HTML:

* table has thead, tfoot, tbody, td, th, tr, caption, col and colgroup.
* ul, ol and menu have li.
* fieldset has legend.
* applet and object have param.
* video and audio have source.
* dl has dt and dd.
* select and datalist have option and optgroup.
* ruby has rp and rt.
* datagrid was proposed to have a number of specialized child elements.

In some cases (such as table or the list elements), the structured element can *only* have its specialized children. In other cases (fieldset, applet/object, or audio/video), the structured element can have relatively free content in addition to its specialized children.

Thus, when introducing new structured elements such as figure and details, the normal design pattern for HTML is to introduce new specialized child elements to represent their structure. It is not the norm to reuse a very common element such as "h1" to represent specialized structure in a certain context. It is not the norm to reuse specialized child elements in a way that differs from their established content and meaning, as with dt/dd or legend. And it is unprecedented to use an attribute that can occur on any element to represent specialized structure, as with the proposed caption attribute. Furthermore, details and figure are not particularly closely related in purpose. One is a UI control, the other is a representation of the structure of prose documents. So it does not make sense for them to share a specialized child element.

Applying a different design pattern for internal element structure to figure and details is likely to be confusing. The confusion of deviating from the usual HTML design pattern for this is likely to be greater than the cognitive cost of introducing no or fewer new elements.

==== Avoids Clunky or Inappropriate Names ====

The new element fltcap, suggested by another Change Proposal, appears confusing and mysterious. No one seems to get what it means on first reading. The expansion as "floating caption" seems confusing and semantically wrong. First, "floating caption" is not a very common term of art in publishing, but whenever it is used, it seems to refer to [http://www.google.com/search?client=safari&rls=en&q=floating+caption&ie=UTF-8&oe=UTF-8 captions overlayed on top of the image], not figure captions in general. Furthermore, a details control does not in general have a "caption", floating or otherwise, rather it is a UI control and therefore is normally considered to have a "label".

The new element c is an extremely short and mysterious name. There is a limit to how many one-letter identifiers one can have in a language without rendering it unreadable or confusing, and they should be reserved for extremely common elements. Captions do not make the cut.

Reusing legend does not seem like a good semantic fit for either figure or details. While a figure's caption is sometimes called a legend, the term "legend" in this context more often refers to the key next to a map or chart explaining how to read various visual elements. A details element is a UI element and those aren't ordinarily referred to as having a legend.

h1 connotes "header", which is not quite right for either figure or details.

"caption" and "label", or variations thereof, are the most semantically appropriate names for the caption and label respectively on figure and details.

==== Does Not Introduce Compatibility Problems ====

Reuse of almost any existing element in an unrelated context introduces compatibility problems, whether "hard" problems with parsing or behavior, or "soft" problems with pre-existing author styles. This Change Proposal uses brand new elements and thus avoids all these problems, unlike the use of dt/dd, legend, label, caption, or h1. All of those are known to have some lesser or greater technical issues.

=== Proposal Details ===

=== Impact ===

== Proposal 4 ==
The proposal is to use the caption element within figure and the label element within details for marking up the captions.

== Proposal 5 ==
The proposal is to repurpose the h1 element for marking up the captions within both figure and details elements.

== Proposal 6==
===Summary===
The proposal is to introduce a caption attribute that may be used on an element within figure to denote the contents of that element as being the caption. This proposal does not address the details element.

===Rationale===
* This allows the most intuitive name to be used, without the problems caused by actually using <caption> as an element name.
* It roughly parallels the existing uses of attributes to tie together an element and some containing element with additional semantics, as seen in <time pubdate>.
* It does not alter the existing semantics of the element it is applied to; a <ul caption> is still a <ul>, a <time caption> is still a <time>, etc.
* It forgoes the need for a 'wrapper' element when you just want to immediately apply a special element. For example, if you are putting photographs in a figure, with the only caption being the time it was taken, it would be best if you could simply put in the <time> without a wrapper. That is, <figure><img src=foo><time caption datetime=2010-01-11>January 11th, 2010</time></figure> is preferable to <figure><img src=foo><caption><time datetime=2010-01-11>January 11th, 2010</time></caption></figure>

===Details===
* Figure content model should be changed to "Flow Content".
* The third paragraph in the prose (explaining the use of the <dt> element) should be changed to roughly: "The first child element with the caption attribute, if any, represents the caption of the figure element's contents. If there is no child element with the caption attribute, then there is no caption."
* The fourth paragraph in the prose (explaining the use of the <dd> element) should be changed to roughly: "Any additional contents of the element beyond the caption (defined above), if any, represents the element's contents. If there are no additional contents, then there are no contents."
* "caption" added to the list of global attributes in the "Global Attributes" section. In its section it should contain roughly: "All HTML elements in the Flow Content category may have the caption content attribute set. The caption attribute is a boolean attribute. When caption is set on an element that is a child of a figure element, the first such element defines the caption for that figure element. It is invalid for a figure to have multiple child elements with the caption attribute set; in such a case, the first such element is the caption for the figure and the caption attribute is invalid and has no effect on subsequent elements. The caption attribute is invalid and has no effect on any element that is not a direct child of a figure element."

===Impact===
Easy denotation of figure captions, without any compatibility hacks that may persist long into the future.

Change Proposal: figure and details

2010-01-11T16:40:24Z

Mjs: /* Summary */

== Summary ==
The current HTML5 draft uses the dt and dd elements to markup the captions and content of the figure and details elements. This change proposal explains why the dt and dd elements are a poor choice for these purposes and proposes an alternative.
----
== Rationale Against Using dt/dd for figure and details Elements ==

=== Backwards Compatibility ===
Due to IE's legacy parsing issues, the dt and dd elements create problems for authors attempting to use and style these elements. The simplest workaround (wrapping both figure and details in an extra div) that authors would need to apply to avoid these issues is not intuitive, as clearly demonstrated by the wide range of alternative solutions that were attempted prior to its discovery.

=== Legacy Cruft ===
The use of extra div elements may lead to a lot of confusion among authors, at least initially, and ultimately end up becoming extraneous markup that authors just include without really understanding why, even after the current generation of browsers are long since dead.

We've seen this kind of problem before with authors, for example, frequently wrapping scripts with pseudo-HTML-comments initially intended to hide the script from what are now very ancient browsers, none of which have been in use for over a decade.

=== Styling Clashes ===
In addition to the aforementioned styling bug in IE, many existing stylesheets already include styles for the dt and dd elements, used in description lists (dl elements). Authors attempting to incorporate figure or details into their existing pages would have to take care to avoid unintended styling clashes caused by selectors that aren't specific enough. i.e. It's common for authors to simply use the selector as "dt" or "dd", rather than "dl>dt" and "dl>dd", as that is currently unnecessary. Authors will then have to adjust their styles, which could potentially cause unintended side affects to to the change in specificity of the selectors.

=== Default Styles ===
The default styles for dt and dd elements is not ideal for figures. As the dd element is usually indented with margin and/or padding, authors will usually be required to remove this with their own stylesheets, rather than being able to rely on more sensible defaults. It is true that eventually UA stylesheets may have special rules for "figure > dt" and the like, but during the transition period it will be extra work to remove inappropriate default styles.

=== Structural Differences ===
Since authors are already familiar with the meanings and structure of dt and dd when used within dl, their very distinct meanings and structure when used within the figure and details may be confusing to authors.

The dl element may contain multiple groups of dt and dd elements, wheres within figure and details, each element may only be used once.

Within dl, a group must have one or more dt elements followed by one or more dd elements, whereas within figure, the elements may appear in any order.

=== Semantic Differences ===
For the figure element, it's not very intuitive to determine which of either dt or dd represents the caption and which represents the content such as an image. Some authors may interpret dd as being the description, which is what it means within dl, and thus assume that dd is meant for the caption, and the dt meant for the image or other content. However, the spec defines these with the opposite meanings, with the understanding the dt, or title, is a synonym for caption. Both alternatives points of view make some sense, but neither stands out as being obviously correct. This will likely lead to a lot of authors using these elements in reverse.

=== Unnecessary Elements ===
The dd element is completely unnecessary to distinguish it from the caption, which has its own element. This combined with the extraneous div required for IE compatibility adds two extra elements that are not logically needed. A previous iteration of the spec used the legend element for the caption, without any special wrapper just for the content. This model seems much more intuitive and required less markup to use, and thus easier to get right. Authors who do wish to have an extra wrapper around the content may use div if they choose, but should not be required to use it.

When there is no caption, using figure then requires authors to use 3 extra elements, where they should only need one:

<div> 
<figure>
<dd><img src="image" alt="..."></dd>
</figure>
</div>

This will be unappealing to authors who may, as a result of the complexity, opt not to use the figure element.

=== Aesthetics ===
Aesthetics is not necessarily the sole or most important concern. However, many authors seem to find the novel use of dt and dd unpleasant to read. dt and dd are relatively obscure elements, they are very short abbreviations, and their meaning in context is unclear, especially in figure. In particular, the following markup seems mysterious and strikes many as ugly and unintuitive:

<figure>
<dd><img src="image" alt="..."></dd>
<dt>A Pair of Cats</dd>
</figure>

This seems to trigger a "yuck factor", and it would be wise to avoid that. Aesthetics may seem like a relatively unimportant factor; however, the desire to avoid introducing new elements that led to dt/dd being used is itself largely an aesthetic concern.

----

== Proposal 1 ==
The proposal is to restore the use of the legend element for marking up the captions within both figure and details elements.

== Proposal 2 ==
The proposal is to introduce a new c element for marking up the captions within both figure and details elements.

== Proposal 3 ==

=== Summary ===
The current HTML5 draft uses the dt and dd elements to markup the captions and content of the figure and details elements. This change proposal explains why the dt and dd elements are a poor choice for these purposes and proposes an alternative. Specifically, the proposal is to introduce a new fcaption element for marking up the caption within figure, and a dlabel element for use within details. The content portions of these elements (as opposed to the caption or label) would not have any special markup, they would be nested directly inside the figure or details element.

=== Additional Rationale ===

In addition to the rationale relative to the status quo in the spec, this proposal is better than some of the proposed alternatives.

==== Follows HTML Precedent for Structured Elements ====

Some HTML elements have relatively free content models, while others are "structured" - there are some or all child elements that have special meaning. Structured elements typically have helper elements that are specific to one element, or to a small family of related elements, to express their internal structure. Examples, from past versions of HTML, new in HTML5, and proposed for future versions of HTML:

* table has thead, tfoot, tbody, td, th, tr, caption, col and colgroup.
* ul, ol and menu have li.
* fieldset has legend.
* applet and object have param.
* video and audio have source.
* dl has dt and dd.
* select and datalist have option and optgroup.
* ruby has rp and rt.
* datagrid was proposed to have a number of specialized child elements.

In some cases (such as table or the list elements), the structured element can *only* have its specialized children. In other cases (fieldset, applet/object, or audio/video), the structured element can have relatively free content in addition to its specialized children.

Thus, when introducing new structured elements such as figure and details, the normal design pattern for HTML is to introduce new specialized child elements to represent their structure. It is not the norm to reuse a very common element such as "h1" to represent specialized structure in a certain context. It is not the norm to reuse specialized child elements in a way that differs from their established content and meaning, as with dt/dd or legend. And it is unprecedented to use an attribute that can occur on any element to represent specialized structure, as with the proposed caption attribute. Furthermore, details and figure are not particularly closely related in purpose. One is a UI control, the other is a representation of the structure of prose documents. So it does not make sense for them to share a specialized child element.

Applying a different design pattern for internal element structure to figure and details is likely to be confusing. The confusion of deviating from the usual HTML design pattern for this is likely to be greater than the cognitive cost of introducing no or fewer new elements.

==== Avoids Clunky or Inappropriate Names ====

The new element fltcap, suggested by another Change Proposal, appears confusing and mysterious. No one seems to get what it means on first reading. The expansion as "floating caption" seems confusing and semantically wrong. First, "floating caption" is not a very common term of art in publishing, but whenever it is used, it seems to refer to [http://www.google.com/search?client=safari&rls=en&q=floating+caption&ie=UTF-8&oe=UTF-8 captions overlayed on top of the image], not figure captions in general. Furthermore, a details control does not in general have a "caption", floating or otherwise, rather it is a UI control and therefore is normally considered to have a "label".

The new element c is an extremely short and mysterious name. There is a limit to how many one-letter identifiers one can have in a language without rendering it unreadable or confusing, and they should be reserved for extremely common elements. Captions do not make the cut.

Reusing legend does not seem like a good semantic fit for either figure or details. While a figure's caption is sometimes called a legend, the term "legend" in this context more often refers to the key next to a map or chart explaining how to read various visual elements. A details element is a UI element and those aren't ordinarily referred to as having a legend.

h1 connotes "header", which is not quite right for either figure or details.

"caption" and "label", or variations thereof, are the most semantically appropriate names for the caption and label respectively on figure and details.

==== Does Not Introduce Compatibility Problems ====

Reuse of almost any existing element in an unrelated context introduces compatibility problems, whether "hard" problems with parsing or behavior, or "soft" problems with pre-existing author styles. This Change Proposal uses brand new elements and thus avoids all these problems, unlike the use of dt/dd, legend, label, caption, or h1. All of those are known to have some lesser or greater technical issues.

=== Proposal Details ===

=== Impact ===

== Proposal 4 ==
The proposal is to use the caption element within figure and the label element within details for marking up the captions.

== Proposal 5 ==
The proposal is to repurpose the h1 element for marking up the captions within both figure and details elements.

== Proposal 6==
===Summary===
The proposal is to introduce a caption attribute that may be used on an element within figure to denote the contents of that element as being the caption. This proposal does not address the details element.

===Rationale===
* This allows the most intuitive name to be used, without the problems caused by actually using <caption> as an element name.
* It roughly parallels the existing uses of attributes to tie together an element and some containing element with additional semantics, as seen in <time pubdate>.
* It does not alter the existing semantics of the element it is applied to; a <ul caption> is still a <ul>, a <time caption> is still a <time>, etc.
* It forgoes the need for a 'wrapper' element when you just want to immediately apply a special element. For example, if you are putting photographs in a figure, with the only caption being the time it was taken, it would be best if you could simply put in the <time> without a wrapper. That is, <figure><img src=foo><time caption datetime=2010-01-11>January 11th, 2010</time></figure> is preferable to <figure><img src=foo><caption><time datetime=2010-01-11>January 11th, 2010</time></caption></figure>

===Details===
* Figure content model should be changed to "Flow Content".
* The third paragraph in the prose (explaining the use of the <dt> element) should be changed to roughly: "The first child element with the caption attribute, if any, represents the caption of the figure element's contents. If there is no child element with the caption attribute, then there is no caption."
* The fourth paragraph in the prose (explaining the use of the <dd> element) should be changed to roughly: "Any additional contents of the element beyond the caption (defined above), if any, represents the element's contents. If there are no additional contents, then there are no contents."
* "caption" added to the list of global attributes in the "Global Attributes" section. In its section it should contain roughly: "All HTML elements may have the caption content attribute set. The caption attribute is a boolean attribute. When caption is set on an element that is a child of a figure element, the first such element defines the caption for that figure element. It is invalid for a figure to have multiple child elements with the caption attribute set; in such a case, the first such element is the caption for the figure and the caption attribute is invalid and has no effect on subsequent elements. The caption attribute is invalid and has no effect on any element that is not a direct child of a figure element."

===Impact===
Easy denotation of figure captions, without any compatibility hacks that may persist long into the future.

Change Proposal: figure and details

2010-01-11T16:38:27Z

Mjs: /* Avoids Clunky or Inappropriate Names */

== Summary ==
The current HTML5 draft uses the dt and dd elements to markup the captions and content of the figure and details elements. This change proposal explains why the dt and dd elements are a poor choice for these purposes and proposes an alternative.
----
== Rationale Against Using dt/dd for figure and details Elements ==

=== Backwards Compatibility ===
Due to IE's legacy parsing issues, the dt and dd elements create problems for authors attempting to use and style these elements. The simplest workaround (wrapping both figure and details in an extra div) that authors would need to apply to avoid these issues is not intuitive, as clearly demonstrated by the wide range of alternative solutions that were attempted prior to its discovery.

=== Legacy Cruft ===
The use of extra div elements may lead to a lot of confusion among authors, at least initially, and ultimately end up becoming extraneous markup that authors just include without really understanding why, even after the current generation of browsers are long since dead.

We've seen this kind of problem before with authors, for example, frequently wrapping scripts with pseudo-HTML-comments initially intended to hide the script from what are now very ancient browsers, none of which have been in use for over a decade.

=== Styling Clashes ===
In addition to the aforementioned styling bug in IE, many existing stylesheets already include styles for the dt and dd elements, used in description lists (dl elements). Authors attempting to incorporate figure or details into their existing pages would have to take care to avoid unintended styling clashes caused by selectors that aren't specific enough. i.e. It's common for authors to simply use the selector as "dt" or "dd", rather than "dl>dt" and "dl>dd", as that is currently unnecessary. Authors will then have to adjust their styles, which could potentially cause unintended side affects to to the change in specificity of the selectors.

=== Default Styles ===
The default styles for dt and dd elements is not ideal for figures. As the dd element is usually indented with margin and/or padding, authors will usually be required to remove this with their own stylesheets, rather than being able to rely on more sensible defaults. It is true that eventually UA stylesheets may have special rules for "figure > dt" and the like, but during the transition period it will be extra work to remove inappropriate default styles.

=== Structural Differences ===
Since authors are already familiar with the meanings and structure of dt and dd when used within dl, their very distinct meanings and structure when used within the figure and details may be confusing to authors.

The dl element may contain multiple groups of dt and dd elements, wheres within figure and details, each element may only be used once.

Within dl, a group must have one or more dt elements followed by one or more dd elements, whereas within figure, the elements may appear in any order.

=== Semantic Differences ===
For the figure element, it's not very intuitive to determine which of either dt or dd represents the caption and which represents the content such as an image. Some authors may interpret dd as being the description, which is what it means within dl, and thus assume that dd is meant for the caption, and the dt meant for the image or other content. However, the spec defines these with the opposite meanings, with the understanding the dt, or title, is a synonym for caption. Both alternatives points of view make some sense, but neither stands out as being obviously correct. This will likely lead to a lot of authors using these elements in reverse.

=== Unnecessary Elements ===
The dd element is completely unnecessary to distinguish it from the caption, which has its own element. This combined with the extraneous div required for IE compatibility adds two extra elements that are not logically needed. A previous iteration of the spec used the legend element for the caption, without any special wrapper just for the content. This model seems much more intuitive and required less markup to use, and thus easier to get right. Authors who do wish to have an extra wrapper around the content may use div if they choose, but should not be required to use it.

When there is no caption, using figure then requires authors to use 3 extra elements, where they should only need one:

<div> 
<figure>
<dd><img src="image" alt="..."></dd>
</figure>
</div>

This will be unappealing to authors who may, as a result of the complexity, opt not to use the figure element.

=== Aesthetics ===
Aesthetics is not necessarily the sole or most important concern. However, many authors seem to find the novel use of dt and dd unpleasant to read. dt and dd are relatively obscure elements, they are very short abbreviations, and their meaning in context is unclear, especially in figure. In particular, the following markup seems mysterious and strikes many as ugly and unintuitive:

<figure>
<dd><img src="image" alt="..."></dd>
<dt>A Pair of Cats</dd>
</figure>

This seems to trigger a "yuck factor", and it would be wise to avoid that. Aesthetics may seem like a relatively unimportant factor; however, the desire to avoid introducing new elements that led to dt/dd being used is itself largely an aesthetic concern.

----

== Proposal 1 ==
The proposal is to restore the use of the legend element for marking up the captions within both figure and details elements.

== Proposal 2 ==
The proposal is to introduce a new c element for marking up the captions within both figure and details elements.

== Proposal 3 ==

=== Summary ===
The current HTML5 draft uses the dt and dd elements to markup the captions and content of the figure and details elements. This change proposal explains why the dt and dd elements are a poor choice for these purposes and proposes an alternative. Specifically, the proposal is to introduce a new fcaption element for marking up the caption within figure, and a dlabel element for use within details. The body parts of these elements would not have any additional markup.

=== Additional Rationale ===

In addition to the rationale relative to the status quo in the spec, this proposal is better than some of the proposed alternatives.

==== Follows HTML Precedent for Structured Elements ====

Some HTML elements have relatively free content models, while others are "structured" - there are some or all child elements that have special meaning. Structured elements typically have helper elements that are specific to one element, or to a small family of related elements, to express their internal structure. Examples, from past versions of HTML, new in HTML5, and proposed for future versions of HTML:

* table has thead, tfoot, tbody, td, th, tr, caption, col and colgroup.
* ul, ol and menu have li.
* fieldset has legend.
* applet and object have param.
* video and audio have source.
* dl has dt and dd.
* select and datalist have option and optgroup.
* ruby has rp and rt.
* datagrid was proposed to have a number of specialized child elements.

In some cases (such as table or the list elements), the structured element can *only* have its specialized children. In other cases (fieldset, applet/object, or audio/video), the structured element can have relatively free content in addition to its specialized children.

Thus, when introducing new structured elements such as figure and details, the normal design pattern for HTML is to introduce new specialized child elements to represent their structure. It is not the norm to reuse a very common element such as "h1" to represent specialized structure in a certain context. It is not the norm to reuse specialized child elements in a way that differs from their established content and meaning, as with dt/dd or legend. And it is unprecedented to use an attribute that can occur on any element to represent specialized structure, as with the proposed caption attribute. Furthermore, details and figure are not particularly closely related in purpose. One is a UI control, the other is a representation of the structure of prose documents. So it does not make sense for them to share a specialized child element.

Applying a different design pattern for internal element structure to figure and details is likely to be confusing. The confusion of deviating from the usual HTML design pattern for this is likely to be greater than the cognitive cost of introducing no or fewer new elements.

==== Avoids Clunky or Inappropriate Names ====

The new element fltcap, suggested by another Change Proposal, appears confusing and mysterious. No one seems to get what it means on first reading. The expansion as "floating caption" seems confusing and semantically wrong. First, "floating caption" is not a very common term of art in publishing, but whenever it is used, it seems to refer to [http://www.google.com/search?client=safari&rls=en&q=floating+caption&ie=UTF-8&oe=UTF-8 captions overlayed on top of the image], not figure captions in general. Furthermore, a details control does not in general have a "caption", floating or otherwise, rather it is a UI control and therefore is normally considered to have a "label".

The new element c is an extremely short and mysterious name. There is a limit to how many one-letter identifiers one can have in a language without rendering it unreadable or confusing, and they should be reserved for extremely common elements. Captions do not make the cut.

Reusing legend does not seem like a good semantic fit for either figure or details. While a figure's caption is sometimes called a legend, the term "legend" in this context more often refers to the key next to a map or chart explaining how to read various visual elements. A details element is a UI element and those aren't ordinarily referred to as having a legend.

h1 connotes "header", which is not quite right for either figure or details.

"caption" and "label", or variations thereof, are the most semantically appropriate names for the caption and label respectively on figure and details.

==== Does Not Introduce Compatibility Problems ====

Reuse of almost any existing element in an unrelated context introduces compatibility problems, whether "hard" problems with parsing or behavior, or "soft" problems with pre-existing author styles. This Change Proposal uses brand new elements and thus avoids all these problems, unlike the use of dt/dd, legend, label, caption, or h1. All of those are known to have some lesser or greater technical issues.

=== Proposal Details ===

=== Impact ===

== Proposal 4 ==
The proposal is to use the caption element within figure and the label element within details for marking up the captions.

== Proposal 5 ==
The proposal is to repurpose the h1 element for marking up the captions within both figure and details elements.

== Proposal 6==
===Summary===
The proposal is to introduce a caption attribute that may be used on an element within figure to denote the contents of that element as being the caption. This proposal does not address the details element.

===Rationale===
* This allows the most intuitive name to be used, without the problems caused by actually using <caption> as an element name.
* It roughly parallels the existing uses of attributes to tie together an element and some containing element with additional semantics, as seen in <time pubdate>.
* It does not alter the existing semantics of the element it is applied to; a <ul caption> is still a <ul>, a <time caption> is still a <time>, etc.
* It forgoes the need for a 'wrapper' element when you just want to immediately apply a special element. For example, if you are putting photographs in a figure, with the only caption being the time it was taken, it would be best if you could simply put in the <time> without a wrapper. That is, <figure><img src=foo><time caption datetime=2010-01-11>January 11th, 2010</time></figure> is preferable to <figure><img src=foo><caption><time datetime=2010-01-11>January 11th, 2010</time></caption></figure>

===Details===
* Figure content model should be changed to "Flow Content".
* The third paragraph in the prose (explaining the use of the <dt> element) should be changed to roughly: "The first child element with the caption attribute, if any, represents the caption of the figure element's contents. If there is no child element with the caption attribute, then there is no caption."
* The fourth paragraph in the prose (explaining the use of the <dd> element) should be changed to roughly: "Any additional contents of the element beyond the caption (defined above), if any, represents the element's contents. If there are no additional contents, then there are no contents."
* "caption" added to the list of global attributes in the "Global Attributes" section. In its section it should contain roughly: "All HTML elements may have the caption content attribute set. The caption attribute is a boolean attribute. When caption is set on an element that is a child of a figure element, the first such element defines the caption for that figure element. It is invalid for a figure to have multiple child elements with the caption attribute set; in such a case, the first such element is the caption for the figure and the caption attribute is invalid and has no effect on subsequent elements. The caption attribute is invalid and has no effect on any element that is not a direct child of a figure element."

===Impact===
Easy denotation of figure captions, without any compatibility hacks that may persist long into the future.

Change Proposal: figure and details

2010-01-11T16:21:40Z

Mjs: /* Additional Rationale */

== Summary ==
The current HTML5 draft uses the dt and dd elements to markup the captions and content of the figure and details elements. This change proposal explains why the dt and dd elements are a poor choice for these purposes and proposes an alternative.
----
== Rationale Against Using dt/dd for figure and details Elements ==

=== Backwards Compatibility ===
Due to IE's legacy parsing issues, the dt and dd elements create problems for authors attempting to use and style these elements. The simplest workaround (wrapping both figure and details in an extra div) that authors would need to apply to avoid these issues is not intuitive, as clearly demonstrated by the wide range of alternative solutions that were attempted prior to its discovery.

=== Legacy Cruft ===
The use of extra div elements may lead to a lot of confusion among authors, at least initially, and ultimately end up becoming extraneous markup that authors just include without really understanding why, even after the current generation of browsers are long since dead.

We've seen this kind of problem before with authors, for example, frequently wrapping scripts with pseudo-HTML-comments initially intended to hide the script from what are now very ancient browsers, none of which have been in use for over a decade.

=== Styling Clashes ===
In addition to the aforementioned styling bug in IE, many existing stylesheets already include styles for the dt and dd elements, used in description lists (dl elements). Authors attempting to incorporate figure or details into their existing pages would have to take care to avoid unintended styling clashes caused by selectors that aren't specific enough. i.e. It's common for authors to simply use the selector as "dt" or "dd", rather than "dl>dt" and "dl>dd", as that is currently unnecessary. Authors will then have to adjust their styles, which could potentially cause unintended side affects to to the change in specificity of the selectors.

=== Default Styles ===
The default styles for dt and dd elements is not ideal for figures. As the dd element is usually indented with margin and/or padding, authors will usually be required to remove this with their own stylesheets, rather than being able to rely on more sensible defaults. It is true that eventually UA stylesheets may have special rules for "figure > dt" and the like, but during the transition period it will be extra work to remove inappropriate default styles.

=== Structural Differences ===
Since authors are already familiar with the meanings and structure of dt and dd when used within dl, their very distinct meanings and structure when used within the figure and details may be confusing to authors.

The dl element may contain multiple groups of dt and dd elements, wheres within figure and details, each element may only be used once.

Within dl, a group must have one or more dt elements followed by one or more dd elements, whereas within figure, the elements may appear in any order.

=== Semantic Differences ===
For the figure element, it's not very intuitive to determine which of either dt or dd represents the caption and which represents the content such as an image. Some authors may interpret dd as being the description, which is what it means within dl, and thus assume that dd is meant for the caption, and the dt meant for the image or other content. However, the spec defines these with the opposite meanings, with the understanding the dt, or title, is a synonym for caption. Both alternatives points of view make some sense, but neither stands out as being obviously correct. This will likely lead to a lot of authors using these elements in reverse.

=== Unnecessary Elements ===
The dd element is completely unnecessary to distinguish it from the caption, which has its own element. This combined with the extraneous div required for IE compatibility adds two extra elements that are not logically needed. A previous iteration of the spec used the legend element for the caption, without any special wrapper just for the content. This model seems much more intuitive and required less markup to use, and thus easier to get right. Authors who do wish to have an extra wrapper around the content may use div if they choose, but should not be required to use it.

When there is no caption, using figure then requires authors to use 3 extra elements, where they should only need one:

<div> 
<figure>
<dd><img src="image" alt="..."></dd>
</figure>
</div>

This will be unappealing to authors who may, as a result of the complexity, opt not to use the figure element.

=== Aesthetics ===
Aesthetics is not necessarily the sole or most important concern. However, many authors seem to find the novel use of dt and dd unpleasant to read. dt and dd are relatively obscure elements, they are very short abbreviations, and their meaning in context is unclear, especially in figure. In particular, the following markup seems mysterious and strikes many as ugly and unintuitive:

<figure>
<dd><img src="image" alt="..."></dd>
<dt>A Pair of Cats</dd>
</figure>

This seems to trigger a "yuck factor", and it would be wise to avoid that. Aesthetics may seem like a relatively unimportant factor; however, the desire to avoid introducing new elements that led to dt/dd being used is itself largely an aesthetic concern.

----

== Proposal 1 ==
The proposal is to restore the use of the legend element for marking up the captions within both figure and details elements.

== Proposal 2 ==
The proposal is to introduce a new c element for marking up the captions within both figure and details elements.

== Proposal 3 ==

=== Summary ===
The current HTML5 draft uses the dt and dd elements to markup the captions and content of the figure and details elements. This change proposal explains why the dt and dd elements are a poor choice for these purposes and proposes an alternative. Specifically, the proposal is to introduce a new fcaption element for marking up the caption within figure, and a dlabel element for use within details. The body parts of these elements would not have any additional markup.

=== Additional Rationale ===

In addition to the rationale relative to the status quo in the spec, this proposal is better than some of the proposed alternatives.

==== Follows HTML Precedent for Structured Elements ====

Some HTML elements have relatively free content models, while others are "structured" - there are some or all child elements that have special meaning. Structured elements typically have helper elements that are specific to one element, or to a small family of related elements, to express their internal structure. Examples, from past versions of HTML, new in HTML5, and proposed for future versions of HTML:

* table has thead, tfoot, tbody, td, th, tr, caption, col and colgroup.
* ul, ol and menu have li.
* fieldset has legend.
* applet and object have param.
* video and audio have source.
* dl has dt and dd.
* select and datalist have option and optgroup.
* ruby has rp and rt.
* datagrid was proposed to have a number of specialized child elements.

In some cases (such as table or the list elements), the structured element can *only* have its specialized children. In other cases (fieldset, applet/object, or audio/video), the structured element can have relatively free content in addition to its specialized children.

Thus, when introducing new structured elements such as figure and details, the normal design pattern for HTML is to introduce new specialized child elements to represent their structure. It is not the norm to reuse a very common element such as "h1" to represent specialized structure in a certain context. It is not the norm to reuse specialized child elements in a way that differs from their established content and meaning, as with dt/dd or legend. And it is unprecedented to use an attribute that can occur on any element to represent specialized structure, as with the proposed caption attribute. Furthermore, details and figure are not particularly closely related in purpose. One is a UI control, the other is a representation of the structure of prose documents. So it does not make sense for them to share a specialized child element.

Applying a different design pattern for internal element structure to figure and details is likely to be confusing. The confusion of deviating from the usual HTML design pattern for this is likely to be greater than the cognitive cost of introducing no or fewer new elements.

==== Avoids Clunky or Inappropriate Names ====

The new element fltcap, suggested by another Change Proposal, appears confusing and mysterious. No one seems to get what it means on first reading. The expansion as "floating caption" seems confusing and semantically wrong. First, "floating caption" is not a very common term of art in publishing, but whenever it is used, it seems to refer to <a href="http://www.google.com/search?client=safari&rls=en&q=floating+caption&ie=UTF-8&oe=UTF-8">captions overlayed on top of the image</a>, not figure captions in general. Furthermore, a details control does not in general have a "caption", floating or otherwise, rather it is a UI control and therefore is normally considered to have a "label".

The new element c is an extremely short and mysterious name. There is a limit to how many one-letter identifiers one can have in a language without rendering it unreadable or confusing, and they should be reserved for extremely common elements. Captions do not make the cut.

Reusing legend does not seem like a good semantic fit for either figure or details. While a figure's caption is sometimes called a legend, the term "legend" in this context more often refers to the key next to a map or chart explaining how to read various visual elements. A details element is a UI element and those aren't ordinarily referred to as having a legend.

h1 connotes "header", which is not quite right for either figure or details.

"caption" and "label", or variations thereof, are the most semantically appropriate names for the caption and label respectively on figure and details.

==== Does Not Introduce Compatibility Problems ====

Reuse of almost any existing element in an unrelated context introduces compatibility problems, whether "hard" problems with parsing or behavior, or "soft" problems with pre-existing author styles. This Change Proposal uses brand new elements and thus avoids all these problems, unlike the use of dt/dd, legend, label, caption, or h1. All of those are known to have some lesser or greater technical issues.

=== Proposal Details ===

=== Impact ===

== Proposal 4 ==
The proposal is to use the caption element within figure and the label element within details for marking up the captions.

== Proposal 5 ==
The proposal is to repurpose the h1 element for marking up the captions within both figure and details elements.

== Proposal 6==
===Summary===
The proposal is to introduce a caption attribute that may be used on an element within figure to denote the contents of that element as being the caption. This proposal does not address the details element.

===Rationale===
* This allows the most intuitive name to be used, without the problems caused by actually using <caption> as an element name.
* It roughly parallels the existing uses of attributes to tie together an element and some containing element with additional semantics, as seen in <time pubdate>.
* It does not alter the existing semantics of the element it is applied to; a <ul caption> is still a <ul>, a <time caption> is still a <time>, etc.
* It forgoes the need for a 'wrapper' element when you just want to immediately apply a special element. For example, if you are putting photographs in a figure, with the only caption being the time it was taken, it would be best if you could simply put in the <time> without a wrapper. That is, <figure><img src=foo><time caption datetime=2010-01-11>January 11th, 2010</time></figure> is preferable to <figure><img src=foo><caption><time datetime=2010-01-11>January 11th, 2010</time></caption></figure>

===Details===
* Figure content model should be changed to "Flow Content".
* The third paragraph in the prose (explaining the use of the <dt> element) should be changed to roughly: "The first child element with the caption attribute, if any, represents the caption of the figure element's contents. If there is no child element with the caption attribute, then there is no caption."
* The fourth paragraph in the prose (explaining the use of the <dd> element) should be changed to roughly: "Any additional contents of the element beyond the caption (defined above), if any, represents the element's contents. If there are no additional contents, then there are no contents."
* "caption" added to the list of global attributes in the "Global Attributes" section. In its section it should contain roughly: "All HTML elements may have the caption content attribute set. The caption attribute is a boolean attribute. When caption is set on an element that is a child of a figure element, the first such element defines the caption for that figure element. It is invalid for a figure to have multiple child elements with the caption attribute set; in such a case, the first such element is the caption for the figure and the caption attribute is invalid and has no effect on subsequent elements. The caption attribute is invalid and has no effect on any element that is not a direct child of a figure element."

===Impact===
Easy denotation of figure captions, without any compatibility hacks that may persist long into the future.

Change Proposal: figure and details

2010-01-11T15:51:50Z

Mjs: /* Aesthetics */

Change Proposal: figure and details

2010-01-11T15:44:26Z

Mjs: /* Proposal 3 */

Change Proposal: figure and details

2010-01-11T15:42:29Z

Mjs: /* Unnecessary Elements */

Change Proposal: figure and details

2010-01-11T15:39:58Z

Mjs: /* Rationale Against Using dt/dd for figure and details Elements */

Change Proposal: figure and details

2010-01-11T15:33:29Z

Mjs: /* Default Styles */

Change Proposal: figure and details

2010-01-11T15:32:41Z

Mjs: /* Legacy Cruft */

Talk:Differences from HTML4

2007-04-10T07:07:10Z

Mjs: New page: Things to possibly add: * new <input> types * Miscellaneous new HTMLDocument APIs: ** getElementsByClassName ** activeElement ** hasFocus * Miscellaneous new HTMLElement APIs: ** getE...

Things to possibly add:

* new <input> types

* Miscellaneous new HTMLDocument APIs:

** getElementsByClassName
** activeElement
** hasFocus

* Miscellaneous new HTMLElement APIs:

** getElementsByClassName
** innerHTML
** classList
** click / blur / focus made global

* Predefined class names
* Predefined link types

* Miscellaneous new APIs on specific elements (only ones that aren't tied directly to new attributes and aren't already listed)

** relList on HTMLLinkElement, HTMLAElement

* Auto-linking to term definitions
* Sectioning
* Scoped styles