WHATWG Wiki - User contributions [en]

GIF

2014-05-30T02:33:49Z

SamB: More fractint info.

Animated GIFs need a spec that, in particular, specifies how to handle timings (not all browsers honor all values, so we should specify what needs to be honored exactly)

== Implementations ==

=== Gecko ===

* http://mxr.mozilla.org/mozilla-central/source/image/decoders/nsGIFDecoder2.h
* http://mxr.mozilla.org/mozilla-central/source/image/decoders/GIF2.h
* http://mxr.mozilla.org/mozilla-central/source/image/decoders/nsGIFDecoder2.cpp

=== WebKit ===

* http://trac.webkit.org/browser/trunk/Source/WebCore/platform/image-decoders/gif/GIFImageDecoder.h
* http://trac.webkit.org/browser/trunk/Source/WebCore/platform/image-decoders/gif/GIFImageReader.h
* http://trac.webkit.org/browser/trunk/Source/WebCore/platform/image-decoders/gif/GIFImageDecoder.cpp
* http://trac.webkit.org/browser/trunk/Source/WebCore/platform/image-decoders/gif/GIFImageReader.cpp
* http://trac.webkit.org/browser/trunk/Source/WebCore/platform/image-decoders/ImageDecoder.cpp

=== Blink ===

* https://chromium.googlesource.com/chromium/blink/+/master/Source/core/platform/image-decoders/gif/GIFImageDecoder.h
* https://chromium.googlesource.com/chromium/blink/+/master/Source/core/platform/image-decoders/gif/GIFImageReader.h
* https://chromium.googlesource.com/chromium/blink/+/master/Source/core/platform/image-decoders/gif/GIFImageDecoder.cpp
* https://chromium.googlesource.com/chromium/blink/+/master/Source/core/platform/image-decoders/gif/GIFImageReader.cpp
* https://chromium.googlesource.com/chromium/blink/+/master/Source/core/platform/image-decoders/ImageDecoder.cpp

=== Other ===

* http://sourceforge.net/p/giflib/code/ci/master/tree/ (giflib)
* https://github.com/jnordberg/gif.js (gif.js)
* https://github.com/deanm/omggif (omggif)
* https://github.com/avik-das/giferly (giferly)
* http://code.google.com/p/gifdotnet/source/browse/ (gifdotnet)

== References ==

=== Specifications ===

* GIF87a: [http://web.archive.org/web/20100929230301/http://www.etsimo.uniovi.es/gifanim/gif87a.txt Text] (Stanford) / [http://www.w3.org/Graphics/GIF/spec-gif87.txt Text] (W3C)
* GIF89a: [http://www.w3.org/Graphics/GIF/spec-gif89a.txt Text] / [http://odur.let.rug.nl/~kleiweg/gif/GIF89a.html HTML]
* GIF Application Extensions:
** <code>NETSCAPE</code> <code>2.0</code>
*** [http://odur.let.rug.nl/~kleiweg/gif/netscape.html GIF Application Extension: NETSCAPE2.0]
*** [http://www.vurdalakov.net/misc/gif/netscape-looping-application-extension Netscape Looping Application Extension]
*** [http://www.vurdalakov.net/misc/gif/netscape-buffering-application-extension Netscape Buffering Application Extension]
** <code>ANIMEXTS</code> <code>1.0</code>
*** [http://www.vurdalakov.net/misc/gif/animexts-looping-application-extension AnimExts Looping Application Extension]
** <code>ICCRGBG1</code> <code>012</code>
*** [http://www.color.org/icc1V42.pdf Specification ICC.1:2004-10 (Profile version 4.2.0.0) – Image technology colour management: Architecture, profile format, and data structure] (section B.6)
** <code>XMP Data</code> <code>XMP</code>
*** [http://wwwimages.adobe.com/www.adobe.com/content/dam/Adobe/en/devnet/xmp/pdfs/XMPSpecificationPart3.pdf XMP Specification, Part 3: Storage in Files] (section 2.1.2)
** <code>fractint</code>
*** [http://fractint.net/fractsvn/trunk/fractint/common/encoder.c fractint encoder source code]
*** [http://fractint.net/fractsvn/trunk/fractint/common/loadfile.c fractint decoder source code], with notes and backwards compatibility for older versions of the fractint extension blocks. All of their extension blocks have names of the form <code>fractint<var>nnn</var></code>, where <code><var>nnn</var></code> is a 3 digit block number.

=== Further details ===

* [[Wikipedia:Graphics Interchange Format]]
* [http://fileformats.archiveteam.org/wiki/GIF GIF File Format]
* [http://www.matthewflickinger.com/lab/whatsinagif/ What's in a GIF]
* [http://commandlinefanatic.com/cgi-bin/showarticle.cgi?article=art011 Command Line Fanatic: Inside the GIF file format]
* [http://www.theimage.com/animation/toc/toc.html Gifology: Understanding GIF Files & GIF Animation]
* [http://web.archive.org/web/20100929231133/http://www.etsimo.uniovi.es/gifanim/gifabout.htm All About GIF89a]

=== Test images ===

* ImageTestSuite
** [http://code.google.com/p/imagetestsuite/wiki/GIFTestSuite Documentation]
** [http://imagetestsuite.googlecode.com/files/imagetestsuite-gif-1.00.tar.gz Images (Archive)]
** [http://code.google.com/p/imagetestsuite/source/browse/trunk/gif/ Images (SVN)]

[[Category:Spec coordination]]

How to write a spec

2014-04-24T03:39:03Z

SamB: zap double redirect

#REDIRECT [[Specs/howto]]

User:Matthew Raymond

2014-03-07T17:44:04Z

SamB: Link to actual subpages

On my user page I have some links to proposals I've made for various WHATWG specifications.

== Proposals for Web Forms 2.0 and Web Forms 3.0 ==

=== Current Proposals ===

* [[/altinput_element|<altinput>]] element
* [[/dataentry_element|<dataentry>]] element
* [[/date_element|<date>]] element
* [[/time_element|<time>]] element
* [[/datetime_element|<datetime>]] element
* [[/month_element|<month>]] element
* [[/week_element|<week>]] element

=== Outdated / Abandoned Proposals ===

* [[/format_element|<format>]] element
* [[/idate_element|<idate>]] element
* [[/icomplex_element|<icomplex>]] element

== Proposals for Web Applications 1.0 ==

* [[/vcalendar_and_vcard_elements|<vcard>, <vcalendar>, <vevent> and <vattr>]] elements

== Proposals for Web Controls 1.0 ==

I have no current proposals for Web Controls 1.0.

User:Matthew Raymond:vcalendar and vcard elements

2014-03-07T17:40:31Z

SamB: SamB moved page User:Matthew Raymond:vcalendar and vcard elements to User:Matthew Raymond/vcalendar and vcard elements: Make actual subpage

#REDIRECT [[User:Matthew Raymond/vcalendar and vcard elements]]

User:Matthew Raymond/vcalendar and vcard elements

2014-03-07T17:40:31Z

SamB: SamB moved page User:Matthew Raymond:vcalendar and vcard elements to User:Matthew Raymond/vcalendar and vcard elements: Make actual subpage

I'll write a detailed description later. Until then, see my [http://listserver.dreamhost.com/pipermail/whatwg-whatwg.org/2005-February/003111.html Markup for vCalendar and vCard] post in the mailing list archive.

User:Matthew Raymond:date element

2014-03-07T17:39:30Z

SamB: SamB moved page User:Matthew Raymond:date element to User:Matthew Raymond/date element: Make actual subpage

#REDIRECT [[User:Matthew Raymond/date element]]

User:Matthew Raymond/date element

2014-03-07T17:39:30Z

SamB: SamB moved page User:Matthew Raymond:date element to User:Matthew Raymond/date element: Make actual subpage

Date elements are used to provide date values for [[Web Forms 2.0]] compliant [[user agent]]s, and to provide a means for those same dates to be displayed in HTML 4.01 compliant browsers.

The date information provided by the date element can be used for scheduling purposes, or for any other date-related purposes. The actual data is contained in the element's value attribute.

:
:<date value="2005-01-25">25-Jan-2005</date>

In the above example, the suggested rendering on a [[Web Forms 2.0]] compliant user agent would be the date contained in value in a localized format. For example, the browser may render "January 25th, 2005". Alternatively, it would also be valid to render the child contents of the element, with the localized date displayed as a tooltip. The second rendering, however, is not recommended.

The child contents of a date element are intended for legacy user agent support. Although they can be used by a Web Forms 2.0 compliant browser, the primary intent is that a localized date value be rendered in the place of the contents.

If the value attribute of a date element is not specified, the user agent must check to see if the child contents are a text string containing an [[ISO 8601]] formatted date, and if so, the value of the value attribute should default to that of the child contents.

:
:<date>2010-02-14</date>

The above example may be rendered as "February 14th, 2010", or some other localized date string.

User:Matthew Raymond:dataentry element

2014-03-07T17:39:08Z

SamB: SamB moved page User:Matthew Raymond:dataentry element to User:Matthew Raymond/dataentry element: Make actual subpage

#REDIRECT [[User:Matthew Raymond/dataentry element]]

User:Matthew Raymond/dataentry element

2014-03-07T17:39:08Z

SamB: SamB moved page User:Matthew Raymond:dataentry element to User:Matthew Raymond/dataentry element: Make actual subpage

The <dataentry> element is just like <input>, with three exceptions:

* It doesn't have the depreciated attributes.
* It has no |alt| attribute, but instead contains alternative contents as child nodes for legacy support.
* It requires a closing tag ("</dataentry>").
* It must contain at least one form control. If </dataentry> has a defined |name| attribute, then it must contain at least one form control with a defined |name| attribute.

==Examples==

Here's a simple example for the three <select> scenario:

<dataentry type="date" id="d1" name="d1" value="2005-02-09">
<select name="d1_day"></select> /
<select name="d1_month"></select> /
<select name="d1_year"></select>
</dataentry>

Here's an example for users of jscalendar:

<dataentry type="date" id="sel1_WF2" name="date1">
<input type="text" id="sel1" name="date1" size="30">
<input type="reset" value=" ... " onclick="return showCalendar('sel1', '%Y-%m-%d');">
YYYY-MM-DD
</dataentry>

==Pros==

# The <dataentry> element can allow for a far greater range of legacy fallback than <input>.
# Because the |type| is defined in an attribute, <dataentry> can be used for input types in later specifications, or for vendor-specific input types.
# The element is designed in both semantics and structure to encourages the use of <input> in simple cases where legacy fallback needs are minimal.
# The element is designed only to prevent the presentation of its child elements. It does not require user agents to delete contents from the DOM or suppress Javascript execution.
# Because it has the same attributes as <input>, there's nothing new to learn except the inclusion of fallback content.

==Cons==

# The size of a form's elements collection in Javascript may differ between user agents.
# There may be legacy Javascript issues that cause script failure when generating unrecognized elements.
# When creating an <dataentry> element, you should be able to test for the correct element type by checking to see if it has a .type property, but I can't be 100% certain.
# Some unneeded Javascript overhead on WF2 clients.
# CSS styling for <dataentry> can't be done directly because user agents that support unrecognized elements may use the styling instead of ignoring the <dataentry> as intended.

==Solutions For Cons==

# A simple method could be added to the DOM that would set whether a form control is include in the .elements collection. A function could then be run when the page loads to hide the <dataentry> elements from the collection.
# This is a general issue affecting all new elements we introduce.
# May not be an issue, but I'd like to hear from an expert.
# Ian seems to feel this is a non-issue, so I won't argue with him.
# I'm considering a pseudo-class (":controltype()" or ":dom(attr, val)"?) that should allow a web author to style <dataentry type="controltype"> when the control type is supported. I'm still working on this concept, though, and I'm wondering if a more general and more powerful pseudo-class can't be developed.
__NOTOC__

User:Matthew Raymond:altinput element

2014-03-07T17:38:45Z

SamB: SamB moved page User:Matthew Raymond:altinput element to User:Matthew Raymond/altinput element: Make actual subpage

#REDIRECT [[User:Matthew Raymond/altinput element]]

User:Matthew Raymond/altinput element

2014-03-07T17:38:45Z

SamB: SamB moved page User:Matthew Raymond:altinput element to User:Matthew Raymond/altinput element: Make actual subpage

The <altinput> element is intended to be a possible alternative to my earlier [[User:Matthew_Raymond:dataentry_element|<dataentry>]] element.

The <altinput> element is a way of accomplishing the same goals as <dataentry> while ensuring that the size of a form's elements collection and the position of controls within it doesn't change between legacy and WF2 browsers. Rather than the element itself being a form control, <altinput> instead performs the following:

* If it has a control with an |id| attribute equal to its |for| attribute, then it attempts to assign its own |type| attribute value to the |type| of the specified control.
* If the |type| is not supported, then the <altinput> acts as nothing more than a <span>.
* However, if the |type| is supported, the control has its |type| changed and the entire contents of the <altinput> element, with the exception of specified control, are not be rendered.

The result is that, in most cases, <altinput> acts almost exactly like <dataentry>.

==Examples==

Here's a simple example for the three <select> scenario:

<altinput for="d1" type="date" value="2005-02-09">
<input type="hidden" id="d1" name="d1" />
<select name="d1_day"></select> /
<select name="d1_month"></select> /
<select name="d1_year"></select>
</altinput>

Here's an example for users of jscalendar:

<altinput for="sel1" type="date">
<input type="text" id="sel1" name="date1" size="30" />
<input type="reset" value=" ... " onclick="return showCalendar('sel1', '%Y-%m-%d');">
YYYY-MM-DD
</altinput>

==Pros==

# The size of a form's elements collection in Javascript never changes.
# The <altinput> element can allow for a far greater range of legacy fallback than <input> alone.
# Because the |type| is defined in an attribute, <altinput> can be used for input types in later specifications, or for vendor-specific input types.
# Because the elemnt requires a child form control, it encourages the use of <input> alone in simple cases where legacy fallback needs are minimal.
# The element is designed only to prevent the presentation of its child elements. It does not require user agents to delete contents from the DOM or suppress Javascript execution.

==Cons==

# It's slightly more complicated to use than <dataentry>.
# In some situations, you must use a hidden <input> control as the target of the <altinput> element's |for| attribute.
# It may still inherit some minor issues from <dataentry>.

Component Model Use Cases

2011-06-09T19:01:18Z

SamB: /* Shadow DOM */

A canonical set of uses cases that represents the set of problems we are trying to solve by implementing a component model. For implementation details, see [http://dev.w3.org/2006/xbl2/Overview.html XBL2 Spec].

This document is broken out into two sections: '''general use cases''' provide insight into how the component model could be used; '''specific use cases''' are interesting scenarios within the general use cases that should be treated as constraints/requirements, imposed on the specification/implementation of the component model.

=General Use Cases=

==Built-in HTML Elements==

Many non-trivial (i.e. with additional behavior and styling beyond the standard box model) elements that exist in HTML today could be implemented using HTML/CSS/JS. [https://wiki.mozilla.org/Gecko:Home_Page Gecko] already takes this approach pretty far. It makes sense to provide a standardized way to accomplish this, with the short-term goals of reducing the size of browsers C++ code and making new element implementation easier, and the long-term goal of converging built-in HTML element implementations across browsers.

== Custom Widget System ==

As it is today (Jan 1, 2011), pretty much every Javascript framework has a widget system (see http://jqueryui.com/, http://sproutcore.com/, http://o.dojotoolkit.org/projects/dijit, http://cappuccino.org/, http://code.google.com/webtoolkit/, http://code.google.com/closure/library/, http://www.sencha.com/ as just a few examples). All of these these widget systems are framework-specific and mostly incompatible with each other.
Because the Web platform doesn't provide a well-functioning way to extend HTML elements, all of these tend to build a parallel widget space, where widget objects act as proxies to DOM objects, and the extensibility exists only within that parallel widget space. A DOM-based component model should aim to eliminate the need for this parallel space and allow widget systems to just use DOM with the goals of:
* reducing the amount of widget-space-related code written in each framework
* providing better, leak-free abstraction for widgets
* providing interoperable API to allow widgets from different frameworks to coexist and integrate.

Requirements:
* provide a uniform way (i.e. DOM) to declare widget APIs
* encapsulate widget implementation details
* enable control over how styles and events outside of a widget affect it
* enable widget styling primitives
* asynchronously instantiate and initialize widgets (for instance, display a widget without starting up a script context, then progressively enhance with script).
* allow seamless reuse a widget written using various libraries or frameworks
* allow using widgets declaratively, with minimal knowledge of the underlying implementation
* provide a way to create new widgets by extending existing widgets

Needs:
* content element (output ports)
* attachment using CSS and DOM
* separate instantiation and binding phases (or another way to allow asynchronous binding)
* attribute/pseudo forwarding
* declarative templating/binding

Could use:
* dynamic attachment/detachment
* template inheritance
* supporting form-control like behavior like "disable" HTML attribute, "form" JS property, etc.

Doesn't care:
* mutable templates
* xml:base handling

Interesting scenarios:
* Implement a "polaroid frame" widget? This widget, when bound to any element would display its contents in a Polaroid(tm)-like frame.
* Suppose the widget system has a centralized "settings" widget, with which all other widgets should communicate to add their settings. Implement this communication, provided that all widgets are opaque elements.
* Implement a "tab set" widget. As you add "tabs" to it, tab titles appear in a row at the top, and tab contents appear in the main area, only visible when the corresponding tab title is selected.

==Layout Manager==

Does:
* provide a framework for client-side restructuring of content to accommodate layout
* support both imperative a declarative layout models
* provide templating/theming capabilities

Needs:
* content element (output ports)
* attachment using CSS and DOM
* separate instantiation and binding phases (or another way to allow asynchronous binding)

Could use:

Doesn't care:
* mutable templates
* xml:base handling

==Specialized Markup Languages==

It's possible to imagine the component model to be used for lightweight implementations of specialized markup languages, such as MathML.
'''This section needs work.'''

=Specific Use Cases=

==Shadow DOM==
A component model should allow a component to hide its implementation details from the consumer. For instance, consider this bit of code:
<pre>
<input type="range">
</pre>
The last thing the user of this element would expect is being able to walk down the DOM subtree of the <code>input</code> element and find the thumb element inside:
<pre>
<input type="range">
<div></div>
</input>
</pre>

Similarly, that's not what the code managing the range slider would want to happen. Thus, the '''shadow DOM''' is ''a way to implement a DOM subtree that is rendered as part of the document, but is not accessible by traversing the document tree''. Shadow DOM provides the necessary level of isolation between component and non-component parts of the DOM tree and is the fundamental part of the component model.

==Dynamic Binding Mechanism==
Being able to apply and unapply a shadow DOM tree, its style information and the code that manages them as one atomic action seems important. For instance, changing the <code>type</code> attribute of the input element immediately triggers the change of how the element looks and behaves. One can view this described in CSS as:

<pre>
input[type='text'] {
binding: url(http://example.com/input/text/);
}

input[type='range'] {
binding: url(http://example.com/input/range/);
}
</pre>

In the code snippet above, it is implied that the shadow subtree, styles, and code are applied/unapplied atomically and dynamically as the <code>type</code> attribute value changes.

TODO: We need to be very careful about executing JavaScript at the behest of CSS. Browsers vendors that have tried that in the past have later come to regret that decision.

==Multiple Shadow DOM Subtrees On Element==
A new component might want to build upon an existing component to provide new functionality. For example, I might want to turn the <code>input type="range"</code> into a dial, rather than a slider. The dial code is implemented as a shadow DOM subtree and is bound to the element like so:

<pre>
/* CSS */
input[type='range'].dial {
binding: url(http://example.com/dial/);
}
</pre>

To use my dial, I have this bit of code:

<pre>
function setDialMode(id, dial)
{
var input = document.getElementById(id);
if (dial)
input.classList.add('dial');
else
input.classList.remove('dial');
}
</pre>

The user's expectations is that the <code>input</code> element turns into a dial once the <code>dial</code> class is set and reverts back to the slider once it's removed. Given that slider itself is implemented as a shadow DOM subtree, this indicates that either:
# '''Mltiple shadow subtrees could exist on an element at the same time with only one subtree rendered'''. This implies some sort of "selector memory" ability, which is completely foreign to how things work in the browser today.
# '''A shadow subtree is destroyed and rebuilt every time selector applies/unapplies'''. This is also bad, because destroying discards any modifications to the subtree that may have occurred during its lifetime. In addition, this approach seems very prone to performance troubles.

==User Agent-Level Attachment==
Since the component model is used to implement built-in HTML elements, there has to be a way apply subtree/style/code at the UA level. The attachment at this level has to satisfy these criteria:
# It should happen before any other component attachment (like UA-level stylesheets).
# It should allow the component code to access API methods that are accessible only to the UA-level attachment. For instance, a <code>video</code> element implementation may need to operate on the native video frame. Direct access to the video frame should not be allowed outside of the UA-level components.
# It should allow the component implementation details to be completely hidden. There should be no way to detect whether an HTML element is built using the component model.

==Applying stylesheets to shadow DOM subtree==
Styles, defined by the author should not reach into the shadow DOM subtree, at least not by default. Otherwise, the items inside of the built-in HTML elements would react to general style selectors. However, the user agent and user stylesheets must always apply. Otherwise, built-in HTML elements inside of another shadow DOM would lose they styling.

==Styling Using Pseudo Elements==
To replicate existing functionality, there should be a way to apply styles to the elements in shadow DOM subtree using pseudo elements. For example:
<pre>
input[type='range']::-webkit-slider-thumb
{
background-color: Cyan;
}
</pre>
Currently, this matches the thumb in the slider, allowing you to style it. This capability should be available in the new component model to support these existing use cases. This implies that there must be a way to associate an arbitrary string with an element in a shadow subtree, which is matched as a pseudo-element value on the host element of the shadow subtree.

==Nesting Pseudo Elements and Mixing with Pseudo Classes==
An element that's exposed to the outside of the shadow DOM with a pseudo-element may also have applicable pseudo-classes. For example, if an element is a button, the user may want to be able to style its various states, exposed via dynamic pseudo-classes:
<pre>
audio::-webkit-controls-play-button:active {
background-color: Red;
}
</pre>
Also, it is useful to be able to style shadow DOM subtrees, nested within each other:
<pre>
audio::-webkit-controls-timeline::-webkit-slider-thumb:active {
border: 1px Red solid;
}
</pre>
The chain of column and double-column delimiters gets confusing quickly:
<pre>
audio::-webkit-controls-timeline:focused::-webkit-slider-thumb:active {
border: 1px Red solid;
}
</pre>
The example above speaks in favor of perhaps matching shadow DOM subtree elements using a (wholly different and new) special selector. For example:
<pre>
audio part(-webkit-controls-timeline):focused part(-webkit-slider-thumb):active {
border: 1px Red solid;
}
</pre>

==Events and Shadow Subtrees==
Events, originated in shadow subtrees, should, in most cases, escape into the main document. For example, if I click on the thumb of the slider in the <code>input[type=range]</code>, I expect to hear all of the respective mouse events at the input. One important notion is that the target of the event and the event object itself should be changed to not to reveal the shadow subtree. In the example above, the value of <code>event.target</code> in the document should be the input, not the thumb.

==Focus and Shadow Subtrees==
Elements in shadow subtrees can get the input focus. Tab-traversal of elements in the page should include elements in shadow subtrees (subject to the typical constraints—that the elements can have the focus, are visible, and so on.) When an element is projected through an output port, the tab-traversal order may skip from an element in the shadow tree, to an output target element in another part of the tree, and back to a subsequent element in the shadow tree.

Some components, for example <code>input[type="text"]</code>, act as monolithic focus targets. Event retargeting of focus and blur events emanating from the shadow tree helps maintain this impression. When the component is focussed, for example by calling the <code>focus</code> function in JavaScript, the component needs to project that focus onto an element it contains. Ideally components could also affect the <code>:focus</code> CSS pseudo-class.

==Near-native Performance==
HTML elements, built using the component system should perform as well as if they were implemented natively and have similar memory consumption characteristics.

==Conceptual Similarity to Ordinary Markup==
There are two ways to build a DOM tree, using HTML (a declarative API) and using DOM methods (an imperative API). It seems like a ''good thing'' to allow developers having the same options for building a shadow DOM subtree. Both options should feel as similar as possible to creating an ordinary DOM tree.

==Template/Stencil Mental Model of a Declarative API==
Since both widgets and built-in HTML elements are meant to have multiple instances, created and destroyed at will, it appears logical to adapt the template/stencil mental model of how a shadow DOM subtree is instantiated:
* the subtree is built from some template of a widget/element;
* the subtree is used to manage behavior or widget/element;
* the subtree is destroyed with the widget/element.

==Reacting to bound element state change==
A widget may want to know if its state (focused/selected/activated) has changed. This can be accomplished by attaching an event listener to its ''light'' node:
<pre>
<html>
<head>
<binding element="div">
<template>
<span>I am asleep</span>
</template>
<implementation>
({
xblEnteredDocument: function()
{
var tree = this.shadowTree;
this.boundElement.addEventListener("DOMActivate",
function()
{
tree.firstChild.textContent = "I AM AWAKE";
}, false);
}
})
</implementation>
</binding>
</head>
<body>
<div></div>
</body>
</html>
</pre>

==Reacting to bound element attribute changes==
A widget may want to know when its attributes are changed. Similarly to the state change, this can be accomplished by attaching a DOM mutation event listener to its ''light'' node (see example for the state change and imagine a DOM mutation event listener being registered instead).

==Mindless Forwarding of the Attribute Changes==
In cases where the meaning of the attribute needs to be reflected by an element in the shadow DOM subtree, forwarding attribute changes mindlessly (without registering listeners and generally executing script) is useful:
<pre>
<html>
<head>
<binding element="myinput">
<template>
<h2>O HAI! MY INPUT IZ TEH AWSUM</h2>
<input type="text" attributes="value disabled readonly">
</template>
</binding>
</head>
<body>
<myinput></myinput>
</body>
</html>
</pre>

==Using Shadow DOM Boundary for Isolation==
The boundary between shadow and light DOM presents an interesting opportunity to use this boundary for script and DOM subtree isolation. For example, binding trusted code to an element in an untrusted tree could be used for clearer separation between control and data channel in the document.

There are three cases worth considering:

# The parent document trusts its components but the components do not trust the parent document.
# The parent document does not trust its components but the components does trust the parent document.
# Neither the parent document nor the components trust the other.

===Parent trusts component but not vice versa===

Because the components are embedded into the parent document, the parent document will be able to control how the component appears to the user. However, the component could hope to hide its internal state from the parent document. More specifically, imagine that the component contains a secret value, such as a capability for accessing a web service. The component should be able to keep this value confidential from the parent document.

===Component trusts parent but not vice versa===

Much like embedding an iframe, a parent document should be able to include an untrusted component without abandoning its security. For example, imagine a video hosting web site provides a video player component that can be embedded in other documents. Those documents should be able to embed the video player component without allowing the video player to inject arbitrary content into the parent page.

===Mutual distrust===

If the component system achieves the above two use cases in a sufficiently generic manner, the component model should also allow the parent document and the component to be mutually distrusting. For example, the video player described above could contain a capability for accessing a web service as above.

==Faster-than-imperative Parsing of Shadow DOM Markup==
It should be possible for browsers to use declarative shadow DOM APIs to achieve performance than the imperative APIs, because the subtree template can be pre-parsed and optimized for cloning + wire-up instead of building from scratch for every instance.

==Tens of Thousands of Widgets==
The implementation should be able to efficiently handle a very large number of instances from the same template (see [http://lists.w3.org/Archives/Public/public-webapps/2010OctDec/0979.html discussion]).
<pre>
<html>
<head>
<binding element="div">
<style scoped>
div.pretty {
background-color: Pretty;
}
</style>
<template>
<div class="pretty">Pretty is, pretty does.</div>
</template>
</binding>
</head>
<body>
<script>
for(var i = 0; i < 20 * 1000; ++i)
document.body.appendChild(document.createElement('div'));
</script>
</body>
</html>
</pre>

==Insertion Points, Not Containers==
Output ports need to be insertion points, not cointainers. If the output port is a container (that is, an existing element in the shadow subtree is designated as a place to add the "light" nodes), some layout scenarios aren't possible. In this example, you can not use flexbox to layout all of the paragraphs in the story:
<pre>
<template>
<p>Once upon a time,
<content includes="p">
<p>And they lived happily ever after
</template>
</pre>
It is useful to think of the output port as a [https://developer.mozilla.org/en/DOM:range.collapsed collapsed range].

==Shadow Subtree Mutation==
Because content element is an insertion point, what happens when the elements around it change? What happens when the insertion point moves?
* '''Modifying includes attribute'''. What happens when you modify the <code>includes</code> element on the output port?
* '''Nested shadow subtrees'''. Suppose you have two bindings, one applied inside another:
<pre>
<html>
<head>
<binding element="div#foo">
<template>
<span>
<content></content>
</span>
</template>
</binding>
<binding element="div#bar">
<template>
<div>
<div id="foo">
<span>Blah</span>
<content></content>
</div>
</template>
</binding>
</head>
<body>
<div id="foo">
<p>Monkeys
</div>
</body>
</html>
</pre>
Sequence of actions:
# Add a <code>div</code> element to <code>div#bar</code>.
# Move <code>content</code> element in <code>div#bar</code> template as the first child of <code>div</code>
What happens?

==Dynamicity of Rules==
As XBL2 spec'd today, the [http://dev.w3.org/2006/xbl2/Overview.html#includes includes] attribute is fully dynamic. That is, changing this attribute results in node redistribution. Being able to control node distribution from outside of the shadow subtree seems like a useful feature. Consider this example:
<pre>
<html>
<head>
<binding element="ul.news">
<template>
<h2>Breaking News</h2>
<ul id="breaking">
<content includes="li.breaking"></content>
</ul>
<h2>Other News</h2>
<ul id="other">
<content></content>
</ul>
</template>
</binding>
</head>
<body>
<ul class="news">
<li class="breaking">Santa seen crossing Atlantic</li>
<li>Pies pose serious health risk, scientists say</li>
</ul>
</body>
</html>
</pre>
Here, the importance of the news item is controlled outside of the shadow subtree. By setting/removing class <code>breaking</code> on a news item, the consumer of the binding can move it in and out of the breaking news section. Implementing this without dynamic rules seems cumbersome and non-trivial.

== Forwarding of the text content ==

The native HTML <option> element renders the textContent of all its children, but not the children themselves. This seems like a mildly useful feature by itself, and would also be useful for completeness is demagicking the behavior of the element in browsers.

[[Category:Proposals]]

Category:Stubs

2011-05-26T01:05:19Z

SamB: Created page with 'These articles are stubs, and should be expanded.'

These articles are stubs, and should be expanded.

Table Summary

2011-05-25T21:39:40Z

SamB:

{{stub}}

HTML 5 needs to find a solution to address the issue of providing explanatory descriptions, or summaries, of complex tables. This page attempts to document the research, proposed solutions, and arguments for and against each proposed technical solution.

== Research ==
=== data on table summary usage ===
The following research presents raw data on table summary attribute usage, with citation to sources:
* http://philip.html5.org/data/table-summary-values.html

=== sorted common values of summary attributes ===
Analysis of the above raw data, collated by common values used for the summary attribute, sorted by number of domains that make use of a common value.
* http://philip.html5.org/data/table-summary-values-dotbot.html

=== user studies ===
From http://lists.w3.org/Archives/Public/public-html/2009Aug/0111.html :
A usability study of the observation of a single blind user that Joshue recorded, in which the user stated that he thought the information provided by the summary was too much.

* [http://www.youtube.com/watch?v=xMGBX8gAM6g#t=0m30s Youtube: HTML5 WG header/id test Video: Table 5]

== Solutions ==
=== HTML4 summary Attribute ===
The summary attribute was the solution provided in HTML4.

==== Pros ====
# Supported by existing screen reader software
#* Which screen reader software vendor?
#* Which software?
#* Which version(s)?
#* On which operating system(s)?
#* On what URL to an existing web page with a table element with a summary attribute?
{{Incomplete list}}

==== Cons ====
{{Incomplete list}}

== Elsewhere ==

This is also being discussed on the HTML WG wiki: http://esw.w3.org/topic/HTML/SummaryForTABLE

[[Category:Proposals]]

Template:Incomplete list

2011-05-25T21:37:13Z

SamB:

# THIS LIST IS INCOMPLETE - please contribute by [{{fullurl:{{FULLPAGENAME}}|action=edit}} editing this wiki page].
<includeonly>[[Category:Pages with incomplete lists]]</includeonly>

Template:Incomplete list

2011-05-25T21:35:43Z

SamB: Created page with '# THIS LIST IS INCOMPLETE - please contribute by [{{fullurl:{{FULLPAGENAME}}|action=edit}} editing this wiki page].'

# THIS LIST IS INCOMPLETE - please contribute by [{{fullurl:{{FULLPAGENAME}}|action=edit}} editing this wiki page].

Template:Stub

2011-05-25T20:47:44Z

SamB: Add Category:Stubs & other tricks from http://en.wikipedia.org/w/index.php?title=Template:Stub&action=edit&oldid=304078838

'''This article is a stub.''' You can help the whatwg.org wiki by [{{fullurl:{{FULLPAGENAME}}|action=edit}} expanding it]. <includeonly>[[Category:Stubs]]</includeonly>