WHATWG Wiki - User contributions [en]

Implementations in Web browsers

2009-04-29T16:08:51Z

Jeff schiller: /* General */

List of known implementations of HTML 5 in web browsers (list is incomplete, feel free to extend it)

For summary see [http://en.wikipedia.org/wiki/Comparison_of_layout_engines_%28WHATWG%29 Comparison of layout engines (WHATWG)] in Wikipedia.

For an interactive view of features and which browsers they work in, see [http://a.deveria.com/caniuse/ http://a.deveria.com/caniuse/]

==HTML 5==

===General===

* '''[http://www.whatwg.org/specs/web-apps/current-work/#the-canvas canvas]''' with some limitation implemented in Firefox, Opera, Safari, and Konqueror 4, with [http://excanvas.sourceforge.net/ ExplorerCanvas] emulated in Internet Explorer
* '''[http://www.whatwg.org/specs/web-apps/current-work/#getelementsbyclassname getElementsByClassName]''' implemented in Firefox 3, Safari 3.1, Opera 9.5
* '''[http://www.whatwg.org/specs/web-apps/current-work/#storage localStorage and sessionStorage]''' implemented in Firefox 2, IE 8, nightly WebKit
* '''[http://www.whatwg.org/specs/web-apps/current-work/#sql Database storage]'''implemented in Safari
* '''[http://www.whatwg.org/specs/web-apps/current-work/#custom-handlers Custom content handlers]''' partially implemented in Firefox 2
* '''[http://www.whatwg.org/specs/web-apps/current-work/#ping ping attribute]''' implemented in Firefox 3 ([https://bugzilla.mozilla.org/show_bug.cgi?id=415168 turned off by default]) - note the implementation does not reflect the latest changes in the specification
* '''[http://www.whatwg.org/specs/web-apps/current-work/#crossDocumentMessages cross-document messaging]''' implemented in Opera 9, Safari and Firefox 3, IE 8
* '''[http://www.whatwg.org/specs/web-apps/current-work/#sound Audio interface]''' implemented in Opera 9, Konqueror 4, Safari 3.1
* ''' [http://www.whatwg.org/specs/web-apps/current-work/multipage/section-video.html#video video element]''' implemented in Safari 3.1 and Firefox 3.1 alfa 2, basic implementation in [http://people.opera.com/howcome/2007/video/ experimental Opera build]; with [http://metavid.ucsc.edu/blog/2007/06/07/html5-video-the-future-is-now/ mv_embed script] in every browser with Java support
* '''[http://www.whatwg.org/specs/web-apps/current-work/#server-sent-events Server-sent DOM events]''' implemented in Opera 9
* '''[http://www.whatwg.org/specs/web-apps/current-work/#contenteditable contenteditable attribute]''' implemented by Opera, Internet Explorer, Safari and Firefox 3
* '''[http://www.whatwg.org/specs/web-apps/current-work/#dnd Drag & drop]''' (partially) implemented in Internet Explorer, Safari and Firefox nightly builds.
* '''[http://www.whatwg.org/specs/web-apps/current-work/#the-end event DOMContentLoaded]''' implemented in Firefox, Safari, Opera
* '''[http://www.whatwg.org/specs/web-workers/current-work/ Web Workers]''' partly implemented in Firefox 3.1 alfa 2
* '''[http://www.whatwg.org/specs/web-apps/current-work/#offline Offline Web applications]''' implemented in Chrome (via Gears plugin), latest Safari on iPhone and Firefox 3.1
* '''[http://www.whatwg.org/specs/web-apps/current-work/#mathml inline MathML]'''
* '''[http://www.whatwg.org/specs/web-apps/current-work/#svg inline SVG]''' partially implemented in Firefox, Safari, Opera (xhtml5 serialization only)

====Emulation====
* '''[http://www.whatwg.org/specs/web-apps/current-work/#the-localstorage localStorage]''' [http://translate.google.com/translate?u=http%3A%2F%2Fd.hatena.ne.jp%2FZIGOROu%2F20080924%2F1222221363&hl=ja&ie=UTF-8&sl=ja&tl=en emulation for IE6 and IE7]

===Web Forms 2.0===

* Opera 9 fully implemented [http://www.whatwg.org/wf2 Web Forms 2].
* Firefox 2 implemented '''[http://www.whatwg.org/specs/web-forms/current-work/#the-change input event]''' (there is still [https://bugzilla.mozilla.org/show_bug.cgi?id=195696 bug #195696])

====Emulation====

* Project '''[http://code.google.com/p/webforms2/ webforms2]''' emulates a big part of WF2 in every browser
* '''date input element''' with [http://code.google.com/p/input-type-date/ input-type-date] works in Firefox, IE6/7, Safari
* '''[http://www.whatwg.org/specs/web-forms/current-work/#repeatingFormControls Repetition Model]''' - Opera 9 (native), with [http://code.google.com/p/repetitionmodel/ repetitionmodel] works in Firefox, IE6/7, Safari 2.0.4
* Project [http://sourceforge.net/projects/wf2/] emulate in IE6/7 validation, date and time types, range, repetition, calculated fields, datalist, autofocus.

==Web Sockets==

No implementations yet but there is work ongoing to implement this for Firefox.

[[Category:Implementations]]

Implementations in Web browsers

2009-04-29T16:08:30Z

Jeff schiller: /* General */

List of known implementations of HTML 5 in web browsers (list is incomplete, feel free to extend it)

For summary see [http://en.wikipedia.org/wiki/Comparison_of_layout_engines_%28WHATWG%29 Comparison of layout engines (WHATWG)] in Wikipedia.

For an interactive view of features and which browsers they work in, see [http://a.deveria.com/caniuse/ http://a.deveria.com/caniuse/]

==HTML 5==

===General===

* '''[http://www.whatwg.org/specs/web-apps/current-work/#the-canvas canvas]''' with some limitation implemented in Firefox, Opera, Safari, and Konqueror 4, with [http://excanvas.sourceforge.net/ ExplorerCanvas] emulated in Internet Explorer
* '''[http://www.whatwg.org/specs/web-apps/current-work/#getelementsbyclassname getElementsByClassName]''' implemented in Firefox 3, Safari 3.1, Opera 9.5
* '''[http://www.whatwg.org/specs/web-apps/current-work/#storage localStorage and sessionStorage]''' implemented in Firefox 2, IE 8, nightly WebKit
* '''[http://www.whatwg.org/specs/web-apps/current-work/#sql Database storage]'''implemented in Safari
* '''[http://www.whatwg.org/specs/web-apps/current-work/#custom-handlers Custom content handlers]''' partially implemented in Firefox 2
* '''[http://www.whatwg.org/specs/web-apps/current-work/#ping ping attribute]''' implemented in Firefox 3 ([https://bugzilla.mozilla.org/show_bug.cgi?id=415168 turned off by default]) - note the implementation does not reflect the latest changes in the specification
* '''[http://www.whatwg.org/specs/web-apps/current-work/#crossDocumentMessages cross-document messaging]''' implemented in Opera 9, Safari and Firefox 3, IE 8
* '''[http://www.whatwg.org/specs/web-apps/current-work/#sound Audio interface]''' implemented in Opera 9, Konqueror 4, Safari 3.1
* ''' [http://www.whatwg.org/specs/web-apps/current-work/multipage/section-video.html#video video element]''' implemented in Safari 3.1 and Firefox 3.1 alfa 2, basic implementation in [http://people.opera.com/howcome/2007/video/ experimental Opera build]; with [http://metavid.ucsc.edu/blog/2007/06/07/html5-video-the-future-is-now/ mv_embed script] in every browser with Java support
* '''[http://www.whatwg.org/specs/web-apps/current-work/#server-sent-events Server-sent DOM events]''' implemented in Opera 9
* '''[http://www.whatwg.org/specs/web-apps/current-work/#contenteditable contenteditable attribute]''' implemented by Opera, Internet Explorer, Safari and Firefox 3
* '''[http://www.whatwg.org/specs/web-apps/current-work/#dnd Drag & drop]''' (partially) implemented in Internet Explorer, Safari and Firefox nightly builds.
* '''[http://www.whatwg.org/specs/web-apps/current-work/#the-end event DOMContentLoaded]''' implemented in Firefox, Safari, Opera
* '''[http://www.whatwg.org/specs/web-workers/current-work/ Web Workers]''' partly implemented in Firefox 3.1 alfa 2
* '''[http://www.whatwg.org/specs/web-apps/current-work/#offline Offline Web applications]''' implemented in Chrome (via Gears plugin), latest Safari on iPhone and Firefox 3.1
* '''[http://www.whatwg.org/specs/web-apps/current-work/#mathml inline MathML]'''
* '''[http://www.whatwg.org/specs/web-apps/current-work/#svg inline SVG]''' (partially) implemented in Firefox, Safari, Opera (xhtml5 serialization only)

====Emulation====
* '''[http://www.whatwg.org/specs/web-apps/current-work/#the-localstorage localStorage]''' [http://translate.google.com/translate?u=http%3A%2F%2Fd.hatena.ne.jp%2FZIGOROu%2F20080924%2F1222221363&hl=ja&ie=UTF-8&sl=ja&tl=en emulation for IE6 and IE7]

===Web Forms 2.0===

* Opera 9 fully implemented [http://www.whatwg.org/wf2 Web Forms 2].
* Firefox 2 implemented '''[http://www.whatwg.org/specs/web-forms/current-work/#the-change input event]''' (there is still [https://bugzilla.mozilla.org/show_bug.cgi?id=195696 bug #195696])

====Emulation====

* Project '''[http://code.google.com/p/webforms2/ webforms2]''' emulates a big part of WF2 in every browser
* '''date input element''' with [http://code.google.com/p/input-type-date/ input-type-date] works in Firefox, IE6/7, Safari
* '''[http://www.whatwg.org/specs/web-forms/current-work/#repeatingFormControls Repetition Model]''' - Opera 9 (native), with [http://code.google.com/p/repetitionmodel/ repetitionmodel] works in Firefox, IE6/7, Safari 2.0.4
* Project [http://sourceforge.net/projects/wf2/] emulate in IE6/7 validation, date and time types, range, repetition, calculated fields, datalist, autofocus.

==Web Sockets==

No implementations yet but there is work ongoing to implement this for Firefox.

[[Category:Implementations]]

Implementations in Web browsers

2009-04-29T16:02:25Z

Jeff schiller: /* HTML 5 */

List of known implementations of HTML 5 in web browsers (list is incomplete, feel free to extend it)

For summary see [http://en.wikipedia.org/wiki/Comparison_of_layout_engines_%28WHATWG%29 Comparison of layout engines (WHATWG)] in Wikipedia.

For an interactive view of features and which browsers they work in, see [http://a.deveria.com/caniuse/ http://a.deveria.com/caniuse/]

==HTML 5==

===General===

* '''[http://www.whatwg.org/specs/web-apps/current-work/#the-canvas canvas]''' with some limitation implemented in Firefox, Opera, Safari, and Konqueror 4, with [http://excanvas.sourceforge.net/ ExplorerCanvas] emulated in Internet Explorer
* '''[http://www.whatwg.org/specs/web-apps/current-work/#getelementsbyclassname getElementsByClassName]''' implemented in Firefox 3, Safari 3.1, Opera 9.5
* '''[http://www.whatwg.org/specs/web-apps/current-work/#storage localStorage and sessionStorage]''' implemented in Firefox 2, IE 8, nightly WebKit
* '''[http://www.whatwg.org/specs/web-apps/current-work/#sql Database storage]'''implemented in Safari
* '''[http://www.whatwg.org/specs/web-apps/current-work/#custom-handlers Custom content handlers]''' partially implemented in Firefox 2
* '''[http://www.whatwg.org/specs/web-apps/current-work/#ping ping attribute]''' implemented in Firefox 3 ([https://bugzilla.mozilla.org/show_bug.cgi?id=415168 turned off by default]) - note the implementation does not reflect the latest changes in the specification
* '''[http://www.whatwg.org/specs/web-apps/current-work/#crossDocumentMessages cross-document messaging]''' implemented in Opera 9, Safari and Firefox 3, IE 8
* '''[http://www.whatwg.org/specs/web-apps/current-work/#sound Audio interface]''' implemented in Opera 9, Konqueror 4, Safari 3.1
* ''' [http://www.whatwg.org/specs/web-apps/current-work/multipage/section-video.html#video video element]''' implemented in Safari 3.1 and Firefox 3.1 alfa 2, basic implementation in [http://people.opera.com/howcome/2007/video/ experimental Opera build]; with [http://metavid.ucsc.edu/blog/2007/06/07/html5-video-the-future-is-now/ mv_embed script] in every browser with Java support
* '''[http://www.whatwg.org/specs/web-apps/current-work/#server-sent-events Server-sent DOM events]''' implemented in Opera 9
* '''[http://www.whatwg.org/specs/web-apps/current-work/#contenteditable contenteditable attribute]''' implemented by Opera, Internet Explorer, Safari and Firefox 3
* '''[http://www.whatwg.org/specs/web-apps/current-work/#dnd Drag & drop]''' (partially) implemented in Internet Explorer, Safari and Firefox nightly builds.
* '''[http://www.whatwg.org/specs/web-apps/current-work/#the-end event DOMContentLoaded]''' implemented in Firefox, Safari, Opera
* '''[http://www.whatwg.org/specs/web-workers/current-work/ Web Workers]''' partly implemented in Firefox 3.1 alfa 2
* '''[http://www.whatwg.org/specs/web-apps/current-work/#offline Offline Web applications]''' implemented in Chrome (via Gears plugin), latest Safari on iPhone and Firefox 3.1
* '''[http://www.whatwg.org/specs/web-apps/current-work/#mathml inline MathML]'''
* '''[http://www.whatwg.org/specs/web-apps/current-work/#svg inline SVG]'''

====Emulation====
* '''[http://www.whatwg.org/specs/web-apps/current-work/#the-localstorage localStorage]''' [http://translate.google.com/translate?u=http%3A%2F%2Fd.hatena.ne.jp%2FZIGOROu%2F20080924%2F1222221363&hl=ja&ie=UTF-8&sl=ja&tl=en emulation for IE6 and IE7]

===Web Forms 2.0===

* Opera 9 fully implemented [http://www.whatwg.org/wf2 Web Forms 2].
* Firefox 2 implemented '''[http://www.whatwg.org/specs/web-forms/current-work/#the-change input event]''' (there is still [https://bugzilla.mozilla.org/show_bug.cgi?id=195696 bug #195696])

====Emulation====

* Project '''[http://code.google.com/p/webforms2/ webforms2]''' emulates a big part of WF2 in every browser
* '''date input element''' with [http://code.google.com/p/input-type-date/ input-type-date] works in Firefox, IE6/7, Safari
* '''[http://www.whatwg.org/specs/web-forms/current-work/#repeatingFormControls Repetition Model]''' - Opera 9 (native), with [http://code.google.com/p/repetitionmodel/ repetitionmodel] works in Firefox, IE6/7, Safari 2.0.4
* Project [http://sourceforge.net/projects/wf2/] emulate in IE6/7 validation, date and time types, range, repetition, calculated fields, datalist, autofocus.

==Web Sockets==

No implementations yet but there is work ongoing to implement this for Firefox.

[[Category:Implementations]]

RelExtensions

2009-04-14T16:10:36Z

Jeff schiller: Border the table so it is readable

This page lists the allowed extension values for the rel="" attribute in HTML5. You may add your own values to this list, which makes them legal HTML5 rel values. We ask that you try to avoid redundancy; if someone has already defined a value that does roughly what you want, please reuse it.

{|border=1
! rowspan=2 | Keyword
! colspan=2 | Effect on...
! rowspan=2 | Brief description
! rowspan=2 | Link to more details
! rowspan=2 | Synonyms
! rowspan=2 | Status
|-
! link
! a and area
|-
| acquaintance
| hyperlink
| hyperlink
| the person represented by the current document considers the person represented by the referenced document to be an acquaintance
| [http://gmpg.org/xfn/11 XFN]
|
| Proposal
|-
| author
| hyperlink
| hyperlink
| The linked document is the page/email an agent (people or firm or...) responsible for the content.
|
|
| Proposal
|-
| canonical
| hyperlink
| not allowed
| Robots (e.g., search engines) should treat the document containing the tag as a minor variation of the linked document, which may result in the removal of the former from a web index and in the consolidation of its quality signals in the latter.
| [http://googlewebmastercentral.blogspot.com/2009/02/specify-your-canonical.html]
|
| Proposal
|-
| chapter
| hyperlink
| hyperlink
| Target document is a subdocument of the current document.
| [http://www.w3.org/TR/html4/types.html#h-6.12 HTML4]
| section, subsection, appendix
| Proposal
|-
| child
| hyperlink
| hyperlink
| the referenced person is a child of the person represented by the current document
| [http://gmpg.org/xfn/11 XFN]
|
| Proposal
|-
| co-resident
| hyperlink
| hyperlink
| the referenced person lives in the same residence as the person represented by the current document
| [http://gmpg.org/xfn/11 XFN]
|
| Proposal
|-
| co-worker
| hyperlink
| hyperlink
| the referenced person is a co-worker of the person represented by the current document
| [http://gmpg.org/xfn/11 XFN]
|
| Proposal
|-
| colleague
| hyperlink
| hyperlink
| the referenced person is a colleague of the person represented by the current document
| [http://gmpg.org/xfn/11 XFN]
|
| Proposal
|-
| contact
| hyperlink
| hyperlink
| the person represented by the current document considers the person represented by the referenced document to be a contact
| [http://gmpg.org/xfn/11 XFN]
|
| Proposal
|-
| contributor
| hyperlink
| hyperlink
| The linked document is the page/email an agent (people or firm or...) involved in the production of the content, but not his main author(s).
|
|
| Proposal
|-
| crush
| hyperlink
| hyperlink
| this person considers the referenced person to be a crush (i.e. has a crush on the referenced person)
| [http://gmpg.org/xfn/11 XFN]
|
| Proposal
|-
| date
| hyperlink
| hyperlink
| this person considers the referenced person to be a date (i.e. is dating the referenced person)
| [http://gmpg.org/xfn/11 XFN]
|
| Proposal
|-
| edit
| hyperlink
| hyperlink
| Target document is an editable version of the current document.
| [http://bitworking.org/projects/atom/draft-ietf-atompub-protocol-11.html#new-link-relation Atom Protocol]
|
| Proposal
|-
| edituri
| hyperlink
| not allowed
| a link to an RSD file describing how to edit the given page.
| [http://cyber.law.harvard.edu/blogs/gems/tech/rsd.htm rsd]
|
| Proposal
|-
| friend
| hyperlink
| hyperlink
| the person represented by the current document considers the person represented by the referenced document to be a friend
| [http://gmpg.org/xfn/11 XFN]
|
| Proposal
|-
| glossary
| hyperlink
| hyperlink
| Target document provides definitions for words in current document.
| [http://www.w3.org/TR/html4/types.html#h-6.12 HTML4]
|
| Proposal
|-
| kin
| hyperlink
| hyperlink
| the referenced person is part of the extended family of the person represented by the current document
| [http://gmpg.org/xfn/11 XFN]
|
| Proposal
|-
| license
| hyperlink
| hyperlink
| The linked document is a license for the current document
| [http://microformats.org/wiki/rel-license rel-license]
|
| Proposal
|-
| me
| hyperlink
| hyperlink
| the referenced document represents the same person as does the current document
| [http://gmpg.org/xfn/11 XFN]
|
| Proposal
|-
| met
| hyperlink
| hyperlink
| this person has met the referenced person
| [http://gmpg.org/xfn/11 XFN]
|
| Proposal
|-
| muse
| hyperlink
| hyperlink
| the referenced person inspires the person represented by the current document
| [http://gmpg.org/xfn/11 XFN]
|
| Proposal
|-
| neighbor
| hyperlink
| hyperlink
| the referenced person lives nearby the person represented by the current document
| [http://gmpg.org/xfn/11 XFN]
|
| Proposal
|-
| openid.delegate
| external resource
| not allowed
| OpenID 1.1 authentication delegation
| [http://openid.net/specs/openid-authentication-1_1.html#delegating_authentication OpenID specification]
|
| Proposal
|-
| openid.server
| external resource
| not allowed
| OpenID 1.1 authentication delegation
| [http://openid.net/specs/openid-authentication-1_1.html#delegating_authentication OpenID specification]
|
| Proposal
|-
| openid2.local_id
| external resource
| not allowed
| OpenID 2.0 authentication delegation
| [http://openid.net/specs/openid-authentication-2_0.html#html_disco OpenID Auth 2.0 section 7.3.3]
|
| Proposal
|-
| openid2.provider
| external resource
| not allowed
| OpenID 2.0 authentication endpoint
| [http://openid.net/specs/openid-authentication-2_0.html#html_disco OpenID Auth 2.0 section 7.3.3]
|
| Proposal
|-
| parent
| hyperlink
| hyperlink
| the referenced person is a parent of the person represented by the current document
| [http://gmpg.org/xfn/11 XFN]
|
| Proposal
|-
| pgpkey
| hyperlink
| not allowed
| The linked document is the PGP public key file (which may contain multiple keys) of the author(s) of the page.
| [http://purl.org/net/pgpkey/], [http://golem.ph.utexas.edu/~distler/blog/archives/000320.html]
|
| Proposal
|-
| profile
| hyperlink
| not allowed
| this referenced link is a metadata profile for the current document
| [http://www.w3.org/TR/html401/struct/global.html#profiles HTML Meta data profiles]
|
| Proposal
|-
| related
| hyperlink
| hyperlink
| this referenced link identifies a resource related to the current document
| [http://tools.ietf.org/html/rfc4287#section-4.2.7 Atom Syndication Format]
|
| Proposal
|-
| reviewer
| hyperlink
| not allowed
| The linked document is the page/email an agent (people or firm or...) responsible for reviewing the content.
| Of interest: used by the CSS WG for the CSS 2.1 Test Suite.
|-
| script
| not allowed
| not allowed
| Was proposed to replace <script>. Use <script> instead.
| none
|
| Rejected
|-
| service
| external resource
| not allowed
| Points to a resource describing a service API
| [[ServiceRelExtension]]
|
| Proposal
|-
| shortlink
| hyperlink
| hyperlink
| Identifies a shorter form of the URL for the current document, provided by the document owner.
| [http://code.google.com/p/shortlink/wiki/Specification shortlink Specification]
|
| Proposal
|-
| sibling
| hyperlink
| hyperlink
| the referenced person is a sibling of the person represented by the current document
| [http://gmpg.org/xfn/11 XFN]
|
| Proposal
|-
| spouse
| hyperlink
| hyperlink
| the referenced person is a spouse of the person represented by the current document
| [http://gmpg.org/xfn/11 XFN]
|
| Proposal
|-
| sweetheart
| hyperlink
| hyperlink
| this person considers the referenced person to be their sweetheart
| [http://gmpg.org/xfn/11 XFN]
|
| Proposal
|-
| tag
| hyperlink
| hyperlink
| The linked document is an author-designated "tag" (or keyword/subject) for the current page.
| [http://microformats.org/wiki/rel-tag rel-tag]
|
| Proposal
|-
| technicalauthor
| hyperlink
| hyperlink
| The linked document is the page/email an agent (people or firm or...) responsible for the technical construction of the page (i.e. the HTML/CSS/PHP code), not for the content.
|
|
| Proposal
|-
| timesheet
| external resource
| not allowed
| SMIL Timesheet
| [http://www.w3.org/TR/timesheets/#smilTimesheetsNS-Elements-Timesheet SMIL Timesheets 1.0]
|
| Proposal
|-
| translator
| hyperlink
| hyperlink
| The linked document is the page/email an agent (people or firm or...) responsible for the translation of the page.
|
|
| Proposal
|-
| webmaster
| hyperlink
| hyperlink
| The linked document is the page/email an agent (people or firm or...) aviable for requests about the content of the page.
|
| maintainer
| Proposal
|-
| widget
| hyperlink
| hyperlink
| Points to a widget.
| [http://dev.w3.org/2006/waf/widgets/Overview.html#autodiscovery Widgets 1.0 Editor's draft]
|
| Proposal
|-
| wlwmanifest
| hyperlink
| not allowed
| A link to a manifest for Windows Live Writer.
| [http://msdn.microsoft.com/en-us/library/bb463263.aspx msdn]
|
| Proposal
|}

The "Effect on... link" column must either say "not allowed" if the rel value is not allowed on <link> elements, "hyperlink" if the rel value creates a hyperlink, or "external resource" if the rel value creates a link to an external resource.

The "Effect on... a and area" column must either say "not allowed" or "hyperlink".

For the "Status" section to be changed to "Accepted", the proposed keyword must either have been through the [http://microformats.org/wiki/process Microformats process], and been approved by the Microformats community; or must be defined by a W3C specification in the Candidate Recommendation or Recommendation state. If it fails to go through this process, it is "Rejected".

For more details, see [http://whatwg.org/specs/web-apps/current-work/#linkTypes the HTML5 specification]. See also [http://microformats.org/wiki/existing-rel-values the Microformats wiki page on this matter].

RelExtensions

2008-05-28T11:53:36Z

Jeff schiller: Added SMIL Timesheet rel

Animation in HTML

2008-04-01T17:09:24Z

Jeff schiller:

'''Use a form of SMIL''' 
Pros: 
* Already a W3C specification with an active Working Group and Activity
* Existing tools and content use SMIL (two web browsers now support SVG+SMIL: Opera and Apple)
* Microsoft has shown some interest in SMIL (HTML+TIME)

'''Use SMIL Timesheets with a link element''' 
Pros: 
* Provides externally referenced 'timesheet' to define temporal behavior of document
* Works for HTML without markup change (uses existing HTML:link element similar)
* Spec currently in Working Draft status with an active Working Group and Activity
* See example [http://www.w3.org/TR/timesheets/#smilTimesheetsNS-Elements-Timesheet|here]

'''Apple's CSS animation proposal''' 
Pros: 
* Already implemented by Apple in Safari
* Works for HTML without markup changes.

'''Questions''' 
* Any patent-encumberances with Apple's proposal? ''They are willing to submit it to W3C''
* Has the "CSS animation proposal" been formalized in a spec, peer reviewed? ''Not yet''
* If "CSS animation" was chosen, would this effort become an additional activity of the HTML Working Group? Or would it be a separate proposal formalized by Apple with which the HTML WG would coordinate? ''CSS working group''
* The [[New_Vocabularies|current proposal]] suggests CSS animation. Other than the fact that it's XML, are there any technical arguments against using SMIL (i.e. why is it considered the inferior choice)? ''SMIL requires markup changes to use, for stylistic effects''

Animation in HTML

2008-04-01T17:07:45Z

Jeff schiller: Added ref to SMIL timesheets

'''Use a form of SMIL''' 
Pros: 
* Already a W3C specification with an active Working Group and Activity
* Existing tools and content use SMIL (two web browsers now support SVG+SMIL: Opera and Apple)
* Microsoft has shown some interest in SMIL (HTML+TIME)

'''Use SMIL Timesheets with a link element''' 
Pros: 
* Provides externally referenced 'timesheet' to define temporal behavior of document
* Works for HTML without markup change (uses existing HTML:link element similar)
* See example [http://www.w3.org/TR/timesheets/#smilTimesheetsNS-Elements-Timesheet|here]

'''Apple's CSS animation proposal''' 
Pros: 
* Already implemented by Apple in Safari
* Works for HTML without markup changes.

'''Questions''' 
* Any patent-encumberances with Apple's proposal? ''They are willing to submit it to W3C''
* Has the "CSS animation proposal" been formalized in a spec, peer reviewed? ''Not yet''
* If "CSS animation" was chosen, would this effort become an additional activity of the HTML Working Group? Or would it be a separate proposal formalized by Apple with which the HTML WG would coordinate? ''CSS working group''
* The [[New_Vocabularies|current proposal]] suggests CSS animation. Other than the fact that it's XML, are there any technical arguments against using SMIL (i.e. why is it considered the inferior choice)? ''SMIL requires markup changes to use, for stylistic effects''

Animation in HTML

2008-03-30T04:02:19Z

Jeff schiller:

Animation in HTML

2008-03-30T04:01:35Z

Jeff schiller:

Animation in HTML

2008-03-30T03:46:25Z

Jeff schiller:

'''Use a form of SMIL'''

* The existing proposal states using the "CSS animation proposal". I assume this is the proprietary, experimental form of animation put forth by Apple? What are the technical merits of the CSS animation proposal over SMIL?
* Has the "CSS animation proposal" been formalized in a spec? Has it been peer reviewed? Why should the HTML group spend time and resources reviewing, editing a new proposal when an existing one exists (SMIL)?
* Assuming some form of SVG inline with HTML, since SVG can already be animated via SMIL, there would be two different ways of animating content. Why?

Animation in HTML

2008-03-30T03:42:32Z

Jeff schiller: New page: '''Use a form of SMIL''' * The existing proposal states using the "CSS animation proposal". I assume this is the proprietary, experimental form of animation put forth by Apple? What are...

'''Use a form of SMIL'''

* The existing proposal states using the "CSS animation proposal". I assume this is the proprietary, experimental form of animation put forth by Apple? What are the technical merits of the CSS animation proposal over SMIL?
* Has the "CSS animation proposal" been formalized in a spec? Has it been peer reviewed? Why should the HTML group spend time and resources reviewing, editing a new proposal when an existing one exists?
* Assuming some form of SVG inline with HTML, since SVG can already be animated via SMIL, there would be two different ways of animating content. Why?

SVG and (X)HTML

2008-03-25T17:04:33Z

Jeff schiller: wikilink

The way to do vector graphics on the Web is SVG.

Per http://lists.w3.org/Archives/Public/public-html/2007Nov/0487.html there are numerous ways to use SVG together with (X)HTML:

# For an SVG document that is an image or animated image, without interaction, embedding in <img> is suitable (this is supported in experimental builds of Opera and Safari).
# For an SVG document that is a purely presentational decuration, referencing as a CSS background image is suitable (this is supported in experimental builds of Opera and Safari).
# For an SVG document that supports rich interaction (and has more application-like properties) or that requires scripting interaction between the containing HTML document and the SVG, either <object> or <iframe> is suitable. This works today in the latest shipping versions of Safari, Opera and Firefox. <object> even works in IE with a suitable plugin installed.
# In XHTML, the <svg> element in the SVG namespace is a suitable way to embed any kind of inline SVG directly in the same document. Many are working on a design to let this work in HTML as well. See [[New_Vocabularies|this research page]].
# In both Classic and XML serializations of HTML, SVG content can be dynamically generated by script and inserted into the DOM at runtime, with an svg:svg element as root. This is perhaps closest to the way <canvas> operates. This is supported by Safari, Opera and Firefox and is used by popular JavaScript libraries, such as the Dojo charting toolkit.

SVG and (X)HTML

2008-03-25T17:02:58Z

Jeff schiller: typo

The way to do vector graphics on the Web is SVG.

Per http://lists.w3.org/Archives/Public/public-html/2007Nov/0487.html there are numerous ways to use SVG together with (X)HTML:

# For an SVG document that is an image or animated image, without interaction, embedding in <img> is suitable (this is supported in experimental builds of Opera and Safari).
# For an SVG document that is a purely presentational decuration, referencing as a CSS background image is suitable (this is supported in experimental builds of Opera and Safari).
# For an SVG document that supports rich interaction (and has more application-like properties) or that requires scripting interaction between the containing HTML document and the SVG, either <object> or <iframe> is suitable. This works today in the latest shipping versions of Safari, Opera and Firefox. <object> even works in IE with a suitable plugin installed.
# In XHTML, the <svg> element in the SVG namespace is a suitable way to embed any kind of inline SVG directly in the same document. Many are working on a design to let this work in HTML as well.
# In both Classic and XML serializations of HTML, SVG content can be dynamically generated by script and inserted into the DOM at runtime, with an svg:svg element as root. This is perhaps closest to the way <canvas> operates. This is supported by Safari, Opera and Firefox and is used by popular JavaScript libraries, such as the Dojo charting toolkit.

FAQ

2008-03-25T16:49:26Z

Jeff schiller: /* What is the namespace declaration? */

== What is the WHATWG? ==

The WHATWG is a growing community of people interested in evolving the Web. It focuses primarily on the development of HTML and APIs needed for Web applications.

The WHATWG was founded by individuals of Apple, the Mozilla Foundation, and Opera Software in 2004, after a W3C workshop. Apple, Mozilla and Opera were becoming increasingly concerned about the W3C’s direction with XHTML, lack of interest in HTML and apparent disregard for the needs of real-world authors. So, in response, these organisations set out with a mission to address these concerns and the Web Hypertext Application Technology Working Group was born.

== What does the acronym WHATWG stand for? ==

It stands for "Web Hypertext Application Technology Working Group".

== What is the WHATWG working on? ==

The WHATWG is working on HTML 5 (see below). In the past it has worked on Web Forms 2.0 and Web Controls 1.0 as well. Web Forms 2.0 (see below) has reached a stable stage and we're awaiting implementation experience. Web Controls 1.0 has been abandoned for now, awaiting what [http://www.w3.org/TR/xbl/ XBL 2.0] will bring us.

== What is HTML 5? ==

[http://www.whatwg.org/specs/web-apps/current-work/ HTML 5] is the main focus of the WHATWG community and also that of the (new) W3C HTML Working Group. HTML 5 is a new version of HTML 4.01 and XHTML 1.0 addressing many of the issues of those specifications while at the same time enhancing (X)HTML to more adequately address Web applications. Besides defining a markup language that can be written in both HTML (HTML5) and XML (XHTML5) it also defines many APIs that form the basis of the Web architecture. These APIs are known to some as "DOM Level 0" and have never been documented. Yet they are extremely important for browser vendors to support existing Web content and for authors to be able to build Web applications.

== What is Web Forms 2.0? ==

[http://www.whatwg.org/specs/web-forms/current-work/ Web Forms 2.0] is an update to the forms chapters of HTML 4.01 and XHTML 1.0. The specification is informally declared feature complete and the WHATWG is awaiting implementation experience. This specification will in due course be folded into the HTML 5 specification when HTML 5 reaches a more stable state.

== How can I get involved? ==

There are lots of ways you can get involved, take a look and see ''[[What you can do]]''!

== Is participation free? ==

Yes, everyone can contribute. There are no memberships fees involved, it's an open process. You may easily subscribe to the WHATWG [http://whatwg.org/mailing-list mailing lists]. You may also [http://blog.whatwg.org/w3c-restarts-html-effort join the the W3C's new HTMLWG] by going through the slightly longer application process.

== Will (X)HTML 5 finally put an end the XHTML as <code>text/html</code> debate? ==

Yes. Unlike HTML 4.01 and XHTML 1.0, the choice of HTML or XHTML is solely dependent upon the choice of MIME type, rather than the DOCTYPE. See [[HTML vs. XHTML]]''

== What will the DOCTYPE be? ==

In HTML: <code><!doctype html></code>. The only reason there is one for HTML is to trigger standards mode in browsers.

In XHTML: no DOCTYPE. You may include one if you wish, though this is not recommended as they are only relevant when using a validating parser which web browsers do not have.

== If there is no DTD, how can I validate my page? ==

With an [http://validator.whatwg.org/ HTML 5 validator].

== What is an HTML Serialisation? ==

The HTML serialisation refers to the syntax of an HTML document defined in HTML5. The syntax is inspired by the SGML syntax from earlier versions of HTML, but it is defined to be more compatible with the way browsers actually handle HTML in reality.

Any document whose MIME type is determined to be <code>text/html</code> is considered to be an HTML serialisation, even if the author has tried to use XML syntax.

== What is an XML (or XHTML) Serialisation? ==

The XML Serialization refers to the syntax defined by XML 1.0 and Namespaces in XML 1.0. A resource that has an XML MIME type, such as <code>application/xhtml+xml</code> or <code>application/xml</code>, is an XML document and if it uses elements in the HTML namespace, it contains XHTML. If the root element is “html” in the HTML namespace, the document is referred to as an XHTML document.

== What MIME type does HTML5 use? ==

The HTML serialisation ''must'' be served using the <code>text/html</code> MIME type.

The XHTML serialisation ''must'' be served using an XML MIME type, such as <code>application/xhtml+xml</code> or <code>application/xml</code>. Unlike XHTML 1.0, XHTML 5 ''must not'' be served as <code>text/html</code>.

Using the incorrect MIME type (<code>text/html</code>) for XHTML will cause the document to be parsed according to parsing requirements for HTML. In other words, it will be treated as tag soup. Ensuring the use of an XML MIME type is the only way to ensure that browsers handle the document as XML.

== What about Microsoft and Internet Explorer? ==

Microsoft has already started implementing parts of HTML5 in IE8.

HTML 5 is being developed with compatibility with existing browsers in mind, though (including IE). Support for many features can be simulated using JavaScript.

== When will we be able to start using these new features? ==

As soon as browsers begin to support them. You do not need to wait till HTML5 becomes a recommendation, because that can’t happen until after the implementations are completely finished.

For example, the <canvas> feature is already widely implemented.

The specification has annotations in the margins showing what browsers implement each section.

== When will HTML 5 be finished? ==

"Finished" is a big deal... You'll be able to use HTML5 long before then. See the previous question.

It is estimated by the editor that HTML5 will reach the W3C Candidate Recommendation stage during 2012. That doesn't mean you can't start using it yet, though. Different parts of the specification are at different maturity levels. Some sections are already relatively stable and there are implementations that are already quite close to completion, and those features can be used today (e.g. <canvas>). But other sections are still being actively worked on and changed regularly, or not even written yet.

'''You can see annotations in the margins showing the estimated stability of each section.'''

The possible states are:

* ''Idea; yet to be specified'' -- the section is a placeholder.
* ''First draft'' -- An early stage.
* ''Working draft'' -- An early stage, but more mature than just "first draft".
* ''Last call for comments'' -- The section is nearly done, but there may be feedback still to be processed. Send feedback sooner rather than later, or it might be too late.
* ''Awaiting implementation feedback'' -- The section is basically done, but might change in response to feedback from implementors. Major changes are unlikely past this point unless it is found that the feature, as specified, really doesn't work well.
* ''Implemented and widely deployed'' -- the feature is specified and complete. Once a section is interoperably implemented, it’s quite stable and unlikely to change significantly. Any changes to such a section would most likely only be editorial in nature, particularly if the feature is already in widespread use.

There are also two special states:

* ''Being edited right now'' -- the section is in high flux and is actively being edited. Contact Hixie on [[IRC]] if you have immediate feedback.
* ''Being considered for removal'' -- for one reason or another, the section is being considered for removal. Send feedback soon to help with the decision.

The point to all this is that you shouldn’t place too much weight on the status of the specification as a whole. You need to consider the stability and maturity level of each section individually.

It is estimated, again by the editor, that HTML5 will reach a W3C recommendation in the year 2022 or later. This will be approximately 18-20 years of development, since beginning in mid-2004. That's actually not that crazy, though. Work on HTML4 started in the mid 90s, and HTML4 ''still'', more than ten years later, hasn't reached the level that we want to reach with HTML5. There is no real test suite, there are many parts of the spec that are lacking real implementations, there are big parts that aren't interoperable, and the spec has hundreds if not thousands of known errors that haven't been fixed. When HTML4 came out, REC meant something much less exciting than it does now.

For a spec to become a REC today, it requires two 100% complete and fully interoperable implementations, which is proven by each successfully passing literally thousands of test cases (20,000 tests for the whole spec would probably be a conservative estimate). When you consider how long it takes to write that many test cases and how long it takes to implement each feature, you’ll begin to understand why the time frame seems so long.

(In the interests of full disclosure, the W3C's [http://www.w3.org/2007/03/HTML-WG-charter.html#deliverables official line] is that the HTML5 spec will be complete, with interoperable implementations, in late 2010. However, as of December 2007 the W3C had already missed the first milestone on that same timetable, First Public Working Draft, by 6 months, with no reason to believe publication would come soon. You can make your own judgements regarding the W3C timetable's credibility.)

== Is there a process for removing bad ideas from the spec? ==

There are several processes by which we trim weeds from the specifications.

* On a regular basis, especially around explicit call-for-comments, we go through every section and mark areas as being considered for removal. This happened early in 2008 with the data templates, repetition blocks, and DFN-element cross references, for example. If no feedback is received to give us strong reasons to keep such features, then they eventually are removed altogether.

* Anyone can ask for a feature to be removed; such feedback is considered like all other feedback and is based on the merits of the arguments put forward.

* If browsers don't widely implement a feature, or if authors don't use a feature, or if the uses of the feature are inconsequential of fundamentally wrong or damaging, then, after due consideration, features will be removed.

Removing features is a critical part of spec development.

== How can I keep track of changes to the spec? ==

The specification is available in the [http://svn.whatwg.org/ subversion repository]. You may use any svn client to check out the latest version and use your clients diff tools in order compare revisions and see what has been changed. You may also use the online [http://html5.org/tools/web-apps-tracker (X)HTML5 Tracker Tool]. The tool provides an online interface for selecting and comparing revisions of the spec.

== Should I close empty elements with <code>/></code> or <code>></code>? ==

Void elements in HTML (the new name for empty elements) do not require a trailing slash. e.g. Instead of writing <code> </code>, you only need to write <code> </code>. This applies to all void elements, including <code>img</code>, <code>input</code>, etc.

However, due to the widespread attempts to use XHTML 1.0, there are a significant number of pages using the trailing slash. Because of this, the syntax has been permitted (though it is not recommended) in order to ease migration from XHTML 1.0 to HTML5.

It is important to realise that this syntax serves no purpose in HTML, it is just ignored by browsers. Despite the fact that it is based upon the XML syntax, it does not mean that HTML documents can be parsed with XML tools. HTML and XHTML are separate serialisations and they each must be processed using tools designed to handle each format.

== If I’m careful with the syntax I use in my HTML document, can I process it with an XML parser? ==

No, HTML and XML have [[HTML_vs._XHTML#Differences_Between_HTML_and_XHTML|many significant differences]], particularly parsing requirements, and you cannot process one using tools designed for the other. However, since HTML5 is defined in terms of the DOM, in most cases there are both HTML and XHTML serialisations available that can represent the same document. There are, however, a few differences explained later that make it impossible to represent some HTML documents accurately as XHTML and vice versa.

If you wish to process an HTML document as XHTML, it requires that you and convert it into XHTML first; and vice versa for processing XHTML as HTML.

== What is the namespace declaration? ==

In XHTML, you are required to specify the namespace. (need to find a simple explanation for what namespaces are for)

<html xmlns="http://www.w3.org/1999/xhtml">

In HTML, the <code>xmlns</code> attribute is currently only allowed on the <code>html</code> element, and only if it has the value “<code>http://www.w3.org/1999/xhtml</code>“. It doesn’t do anything at all, it is merely allowed to ease migration from XHTML 1.0. It is not actually a namespace declaration in HTML, because HTML doesn’t yet support namespaces. See [[FAQ#Will_there_be_support_for_namespaces_in_HTML.3F|here]].

== Will there be support for namespaces in HTML? ==

HTML 5 is being defined in terms of the DOM and all HTML elements will exist in the HTML namespace: <code>http://www.w3.org/1999/xhtml</code>. However, unlike the XHTML serialisation, there is no real namespace syntax available in the HTML serialisation (see previous question). In other words, you do not need to declare the namespace in your HTML markup, like you do in XHTML.

XHTML requires that the namespace to be declared appropriately using the <code>xmlns</code> attribute. The namespace declaration is unnecessary in HTML because browsers will already know it’s an HTML document based on the MIME type (<code>text/html</code>).

There have been proposals for introducing MathML or SVG markup into HTML, which would exist in the MathML or SVG namespaces. This subject is [http://blog.whatwg.org/exploring-new-vocabularies-for-html being studied at the moment].

== How do I specify the character encoding? ==

For HTML, it is strongly recommended that you specify the encoding using the HTTP <code>Content-Type</code> header. If you are unable to [http://www.w3.org/International/O-HTTP-charset configure your server] to send the correct headers, then you may use the <code>meta</code> element. The <code>meta</code> element used for this purpose must occur as the first element in the head (even before the <code>title</code>), and within the first 512 bytes of the file.

<meta charset="UTF-8">

Note that this <code>meta</code> element is different from HTML 4, though it is compatible with many browsers because of the way encoding detection has been implemented.

In XHTML, XML rules for determining the character encoding apply. You may use either the HTTP <code>Content-Type</code> header or the XML declaration to specify the encoding.

<?xml version="1.0" encoding="UTF-8"?>

Otherwise, you must use the default of <code>UTF-8</code> or <code>UTF-16</code>. It is recommended that you use <code>UTF-8</code>.

== What are the differences between HTML and XHTML? ==

See the list of [[HTML vs. XHTML#Differences_Between_HTML_and_XHTML|differences between HTML and XHTML]] in the wiki.

== Does HTML5 support <code>href</code> on any element like XHTML 2.0? ==

No, supporting <code>href</code> on any element has several problems associated with it that make it difficult to support in HTML5.

* It isn’t backwards compatible with existing browsers.
* It adds no new functionality that can’t already be achieved using the <code>a</code> element.
* It doesn’t make sense for all elements, such as interactive elements like <code>input</code> and <code>button</code>, where the use of href would interfere with their normal function.
* Browser vendors have reported that implementing it would be extremely complex.

The only advantage it seems to add is that it reduces typing for authors in some cases, but that is not a strong enough reason to support it in light of the other reasons.

== Why does HTML5 legitimise tag soup? ==

Actually it doesn’t. This is a misconception that comes from the confusion between conformance requirements for documents, and the requirements for user agents.

Due to the fundamental design principle of supporting existing content, the spec must define how to handle all HTML, regardless of whether documents are conforming or not. Therefore, the spec defines (or will define) precisely how to handle and recover from erroneous markup, much of which would be considered tag soup.

For example, the spec defines algorithms for dealing with syntax errors such as misnested tags, which will ensure that a well structured DOM tree can be produced.

Defining that is essential for one day achieving interoperability between browsers and reducing the dependence upon reverse engineering each other.

However, the conformance requirements for authors are defined separately from the processing requirements. Just because browsers are required to handle erroneous content, it does not make such markup conforming.

For example, user agents will be required to support the marquee element, but authors must not use the marquee element in conforming documents.

It is important to make the distinction between the rules that apply to user agents and the rules that apply to authors for produce conforming documents. They are completely orthogonal.

== What are “Web Applications”? ==

The term “Web Application” in this context refers to applications accessed over the World Wide Web by using a Web browser. This group is not attempting to describe APIs for writing high-end sophisticated programs such as office productivity suites, graphics manipulation packages, or 3D games.

Some of the most famous examples of Web applications currently deployed are [http://www.ebay.com/ eBay] and [http://www.amazon.com/ Amazon].

== Aren’t “Web Applications” already possible? ==

Yes. This working group aims to make their development ''easier'', and hopes to specify new technologies that make it possible to make much prettier and more usable interfaces with less dependence on complex scripts, less dependence on server-generated pages, and a more seamless user experience.

For example, currently HTML forms do not specify a way to specify that a control is a required control that must be filled in before submission: such features have to be scripted explicitly.

== WHATWG and the W3C HTML WG ==

=== Are there plans to merge the groups? ===

Not especially. There are people who for a number of reasons are unable to join the W3C group, and there are others who are unable to join the WHATWG group. The editor is in both groups and takes all input into account -- and there are far more places where input on HTML5 is sent than just these two mailing lists (e.g. blogs, www-html@w3.org, forums, direct mail, meetings, etc).

=== Which group has authority in the event of a dispute? ===

The editor takes feedback from everyone into account and does not look at the source of those arguments for technical arguments.

== The WHATWG Process ==

=== How does the WHATWG work? ===

People send e-mail to [http://www.whatwg.org/mailing-list#specs the mailing list]. The editor then reads that [http://www.whatwg.org/issues/ feedback] and, taking it into account along with research, studies, and feedback from many other sources (blogs, forums, IRC, etc) makes language design decisions intended to address everyone's needs as well as possible while keeping the language consistent.

This continues, with people sending more feedback, until nobody is able to convince the editor to change the spec any more (e.g. because two people want opposite things, and the editor has considered all the information available and decided that one of the two proposals is the better one).

This is not a consensus-based approach -- there's no guarantee that everyone will be happy! There is also no voting.

There is a small oversight committee (known as the "WHATWG members", see the [http://www.whatwg.org/charter charter]) who have the authority to override or replace the editor if he starts making bad decisions.

Currently the editor is Ian Hickson.

FAQ

2008-03-25T16:48:14Z

Jeff schiller: /* If I’m careful with the syntax I use in my HTML document, can I process it with an XML parser? */ wikilink

== What is the WHATWG? ==

The WHATWG is a growing community of people interested in evolving the Web. It focuses primarily on the development of HTML and APIs needed for Web applications.

The WHATWG was founded by individuals of Apple, the Mozilla Foundation, and Opera Software in 2004, after a W3C workshop. Apple, Mozilla and Opera were becoming increasingly concerned about the W3C’s direction with XHTML, lack of interest in HTML and apparent disregard for the needs of real-world authors. So, in response, these organisations set out with a mission to address these concerns and the Web Hypertext Application Technology Working Group was born.

== What does the acronym WHATWG stand for? ==

It stands for "Web Hypertext Application Technology Working Group".

== What is the WHATWG working on? ==

The WHATWG is working on HTML 5 (see below). In the past it has worked on Web Forms 2.0 and Web Controls 1.0 as well. Web Forms 2.0 (see below) has reached a stable stage and we're awaiting implementation experience. Web Controls 1.0 has been abandoned for now, awaiting what [http://www.w3.org/TR/xbl/ XBL 2.0] will bring us.

== What is HTML 5? ==

[http://www.whatwg.org/specs/web-apps/current-work/ HTML 5] is the main focus of the WHATWG community and also that of the (new) W3C HTML Working Group. HTML 5 is a new version of HTML 4.01 and XHTML 1.0 addressing many of the issues of those specifications while at the same time enhancing (X)HTML to more adequately address Web applications. Besides defining a markup language that can be written in both HTML (HTML5) and XML (XHTML5) it also defines many APIs that form the basis of the Web architecture. These APIs are known to some as "DOM Level 0" and have never been documented. Yet they are extremely important for browser vendors to support existing Web content and for authors to be able to build Web applications.

== What is Web Forms 2.0? ==

[http://www.whatwg.org/specs/web-forms/current-work/ Web Forms 2.0] is an update to the forms chapters of HTML 4.01 and XHTML 1.0. The specification is informally declared feature complete and the WHATWG is awaiting implementation experience. This specification will in due course be folded into the HTML 5 specification when HTML 5 reaches a more stable state.

== How can I get involved? ==

There are lots of ways you can get involved, take a look and see ''[[What you can do]]''!

== Is participation free? ==

Yes, everyone can contribute. There are no memberships fees involved, it's an open process. You may easily subscribe to the WHATWG [http://whatwg.org/mailing-list mailing lists]. You may also [http://blog.whatwg.org/w3c-restarts-html-effort join the the W3C's new HTMLWG] by going through the slightly longer application process.

== Will (X)HTML 5 finally put an end the XHTML as <code>text/html</code> debate? ==

Yes. Unlike HTML 4.01 and XHTML 1.0, the choice of HTML or XHTML is solely dependent upon the choice of MIME type, rather than the DOCTYPE. See [[HTML vs. XHTML]]''

== What will the DOCTYPE be? ==

In HTML: <code><!doctype html></code>. The only reason there is one for HTML is to trigger standards mode in browsers.

In XHTML: no DOCTYPE. You may include one if you wish, though this is not recommended as they are only relevant when using a validating parser which web browsers do not have.

== If there is no DTD, how can I validate my page? ==

With an [http://validator.whatwg.org/ HTML 5 validator].

== What is an HTML Serialisation? ==

The HTML serialisation refers to the syntax of an HTML document defined in HTML5. The syntax is inspired by the SGML syntax from earlier versions of HTML, but it is defined to be more compatible with the way browsers actually handle HTML in reality.

Any document whose MIME type is determined to be <code>text/html</code> is considered to be an HTML serialisation, even if the author has tried to use XML syntax.

== What is an XML (or XHTML) Serialisation? ==

The XML Serialization refers to the syntax defined by XML 1.0 and Namespaces in XML 1.0. A resource that has an XML MIME type, such as <code>application/xhtml+xml</code> or <code>application/xml</code>, is an XML document and if it uses elements in the HTML namespace, it contains XHTML. If the root element is “html” in the HTML namespace, the document is referred to as an XHTML document.

== What MIME type does HTML5 use? ==

The HTML serialisation ''must'' be served using the <code>text/html</code> MIME type.

The XHTML serialisation ''must'' be served using an XML MIME type, such as <code>application/xhtml+xml</code> or <code>application/xml</code>. Unlike XHTML 1.0, XHTML 5 ''must not'' be served as <code>text/html</code>.

Using the incorrect MIME type (<code>text/html</code>) for XHTML will cause the document to be parsed according to parsing requirements for HTML. In other words, it will be treated as tag soup. Ensuring the use of an XML MIME type is the only way to ensure that browsers handle the document as XML.

== What about Microsoft and Internet Explorer? ==

Microsoft has already started implementing parts of HTML5 in IE8.

HTML 5 is being developed with compatibility with existing browsers in mind, though (including IE). Support for many features can be simulated using JavaScript.

== When will we be able to start using these new features? ==

As soon as browsers begin to support them. You do not need to wait till HTML5 becomes a recommendation, because that can’t happen until after the implementations are completely finished.

For example, the <canvas> feature is already widely implemented.

The specification has annotations in the margins showing what browsers implement each section.

== When will HTML 5 be finished? ==

"Finished" is a big deal... You'll be able to use HTML5 long before then. See the previous question.

It is estimated by the editor that HTML5 will reach the W3C Candidate Recommendation stage during 2012. That doesn't mean you can't start using it yet, though. Different parts of the specification are at different maturity levels. Some sections are already relatively stable and there are implementations that are already quite close to completion, and those features can be used today (e.g. <canvas>). But other sections are still being actively worked on and changed regularly, or not even written yet.

'''You can see annotations in the margins showing the estimated stability of each section.'''

The possible states are:

* ''Idea; yet to be specified'' -- the section is a placeholder.
* ''First draft'' -- An early stage.
* ''Working draft'' -- An early stage, but more mature than just "first draft".
* ''Last call for comments'' -- The section is nearly done, but there may be feedback still to be processed. Send feedback sooner rather than later, or it might be too late.
* ''Awaiting implementation feedback'' -- The section is basically done, but might change in response to feedback from implementors. Major changes are unlikely past this point unless it is found that the feature, as specified, really doesn't work well.
* ''Implemented and widely deployed'' -- the feature is specified and complete. Once a section is interoperably implemented, it’s quite stable and unlikely to change significantly. Any changes to such a section would most likely only be editorial in nature, particularly if the feature is already in widespread use.

There are also two special states:

* ''Being edited right now'' -- the section is in high flux and is actively being edited. Contact Hixie on [[IRC]] if you have immediate feedback.
* ''Being considered for removal'' -- for one reason or another, the section is being considered for removal. Send feedback soon to help with the decision.

The point to all this is that you shouldn’t place too much weight on the status of the specification as a whole. You need to consider the stability and maturity level of each section individually.

It is estimated, again by the editor, that HTML5 will reach a W3C recommendation in the year 2022 or later. This will be approximately 18-20 years of development, since beginning in mid-2004. That's actually not that crazy, though. Work on HTML4 started in the mid 90s, and HTML4 ''still'', more than ten years later, hasn't reached the level that we want to reach with HTML5. There is no real test suite, there are many parts of the spec that are lacking real implementations, there are big parts that aren't interoperable, and the spec has hundreds if not thousands of known errors that haven't been fixed. When HTML4 came out, REC meant something much less exciting than it does now.

For a spec to become a REC today, it requires two 100% complete and fully interoperable implementations, which is proven by each successfully passing literally thousands of test cases (20,000 tests for the whole spec would probably be a conservative estimate). When you consider how long it takes to write that many test cases and how long it takes to implement each feature, you’ll begin to understand why the time frame seems so long.

(In the interests of full disclosure, the W3C's [http://www.w3.org/2007/03/HTML-WG-charter.html#deliverables official line] is that the HTML5 spec will be complete, with interoperable implementations, in late 2010. However, as of December 2007 the W3C had already missed the first milestone on that same timetable, First Public Working Draft, by 6 months, with no reason to believe publication would come soon. You can make your own judgements regarding the W3C timetable's credibility.)

== Is there a process for removing bad ideas from the spec? ==

There are several processes by which we trim weeds from the specifications.

* On a regular basis, especially around explicit call-for-comments, we go through every section and mark areas as being considered for removal. This happened early in 2008 with the data templates, repetition blocks, and DFN-element cross references, for example. If no feedback is received to give us strong reasons to keep such features, then they eventually are removed altogether.

* Anyone can ask for a feature to be removed; such feedback is considered like all other feedback and is based on the merits of the arguments put forward.

* If browsers don't widely implement a feature, or if authors don't use a feature, or if the uses of the feature are inconsequential of fundamentally wrong or damaging, then, after due consideration, features will be removed.

Removing features is a critical part of spec development.

== How can I keep track of changes to the spec? ==

The specification is available in the [http://svn.whatwg.org/ subversion repository]. You may use any svn client to check out the latest version and use your clients diff tools in order compare revisions and see what has been changed. You may also use the online [http://html5.org/tools/web-apps-tracker (X)HTML5 Tracker Tool]. The tool provides an online interface for selecting and comparing revisions of the spec.

== Should I close empty elements with <code>/></code> or <code>></code>? ==

Void elements in HTML (the new name for empty elements) do not require a trailing slash. e.g. Instead of writing <code> </code>, you only need to write <code> </code>. This applies to all void elements, including <code>img</code>, <code>input</code>, etc.

However, due to the widespread attempts to use XHTML 1.0, there are a significant number of pages using the trailing slash. Because of this, the syntax has been permitted (though it is not recommended) in order to ease migration from XHTML 1.0 to HTML5.

It is important to realise that this syntax serves no purpose in HTML, it is just ignored by browsers. Despite the fact that it is based upon the XML syntax, it does not mean that HTML documents can be parsed with XML tools. HTML and XHTML are separate serialisations and they each must be processed using tools designed to handle each format.

== If I’m careful with the syntax I use in my HTML document, can I process it with an XML parser? ==

No, HTML and XML have [[HTML_vs._XHTML#Differences_Between_HTML_and_XHTML|many significant differences]], particularly parsing requirements, and you cannot process one using tools designed for the other. However, since HTML5 is defined in terms of the DOM, in most cases there are both HTML and XHTML serialisations available that can represent the same document. There are, however, a few differences explained later that make it impossible to represent some HTML documents accurately as XHTML and vice versa.

If you wish to process an HTML document as XHTML, it requires that you and convert it into XHTML first; and vice versa for processing XHTML as HTML.

== What is the namespace declaration? ==

In XHTML, you are required to specify the namespace. (need to find a simple explanation for what namespaces are for)

<html xmlns="http://www.w3.org/1999/xhtml">

In HTML, the <code>xmlns</code> attribute is only allowed on the <code>html</code> element, and only if it has the value “<code>http://www.w3.org/1999/xhtml</code>“. It doesn’t do anything at all, it is merely allowed to ease migration from XHTML 1.0. It is not actually a namespace declaration in HTML, because HTML doesn’t support namespaces.

== Will there be support for namespaces in HTML? ==

HTML 5 is being defined in terms of the DOM and all HTML elements will exist in the HTML namespace: <code>http://www.w3.org/1999/xhtml</code>. However, unlike the XHTML serialisation, there is no real namespace syntax available in the HTML serialisation (see previous question). In other words, you do not need to declare the namespace in your HTML markup, like you do in XHTML.

XHTML requires that the namespace to be declared appropriately using the <code>xmlns</code> attribute. The namespace declaration is unnecessary in HTML because browsers will already know it’s an HTML document based on the MIME type (<code>text/html</code>).

There have been proposals for introducing MathML or SVG markup into HTML, which would exist in the MathML or SVG namespaces. This subject is [http://blog.whatwg.org/exploring-new-vocabularies-for-html being studied at the moment].

== How do I specify the character encoding? ==

For HTML, it is strongly recommended that you specify the encoding using the HTTP <code>Content-Type</code> header. If you are unable to [http://www.w3.org/International/O-HTTP-charset configure your server] to send the correct headers, then you may use the <code>meta</code> element. The <code>meta</code> element used for this purpose must occur as the first element in the head (even before the <code>title</code>), and within the first 512 bytes of the file.

<meta charset="UTF-8">

Note that this <code>meta</code> element is different from HTML 4, though it is compatible with many browsers because of the way encoding detection has been implemented.

In XHTML, XML rules for determining the character encoding apply. You may use either the HTTP <code>Content-Type</code> header or the XML declaration to specify the encoding.

<?xml version="1.0" encoding="UTF-8"?>

Otherwise, you must use the default of <code>UTF-8</code> or <code>UTF-16</code>. It is recommended that you use <code>UTF-8</code>.

== What are the differences between HTML and XHTML? ==

See the list of [[HTML vs. XHTML#Differences_Between_HTML_and_XHTML|differences between HTML and XHTML]] in the wiki.

== Does HTML5 support <code>href</code> on any element like XHTML 2.0? ==

No, supporting <code>href</code> on any element has several problems associated with it that make it difficult to support in HTML5.

* It isn’t backwards compatible with existing browsers.
* It adds no new functionality that can’t already be achieved using the <code>a</code> element.
* It doesn’t make sense for all elements, such as interactive elements like <code>input</code> and <code>button</code>, where the use of href would interfere with their normal function.
* Browser vendors have reported that implementing it would be extremely complex.

The only advantage it seems to add is that it reduces typing for authors in some cases, but that is not a strong enough reason to support it in light of the other reasons.

== Why does HTML5 legitimise tag soup? ==

Actually it doesn’t. This is a misconception that comes from the confusion between conformance requirements for documents, and the requirements for user agents.

Due to the fundamental design principle of supporting existing content, the spec must define how to handle all HTML, regardless of whether documents are conforming or not. Therefore, the spec defines (or will define) precisely how to handle and recover from erroneous markup, much of which would be considered tag soup.

For example, the spec defines algorithms for dealing with syntax errors such as misnested tags, which will ensure that a well structured DOM tree can be produced.

Defining that is essential for one day achieving interoperability between browsers and reducing the dependence upon reverse engineering each other.

However, the conformance requirements for authors are defined separately from the processing requirements. Just because browsers are required to handle erroneous content, it does not make such markup conforming.

For example, user agents will be required to support the marquee element, but authors must not use the marquee element in conforming documents.

It is important to make the distinction between the rules that apply to user agents and the rules that apply to authors for produce conforming documents. They are completely orthogonal.

== What are “Web Applications”? ==

The term “Web Application” in this context refers to applications accessed over the World Wide Web by using a Web browser. This group is not attempting to describe APIs for writing high-end sophisticated programs such as office productivity suites, graphics manipulation packages, or 3D games.

Some of the most famous examples of Web applications currently deployed are [http://www.ebay.com/ eBay] and [http://www.amazon.com/ Amazon].

== Aren’t “Web Applications” already possible? ==

Yes. This working group aims to make their development ''easier'', and hopes to specify new technologies that make it possible to make much prettier and more usable interfaces with less dependence on complex scripts, less dependence on server-generated pages, and a more seamless user experience.

For example, currently HTML forms do not specify a way to specify that a control is a required control that must be filled in before submission: such features have to be scripted explicitly.

== WHATWG and the W3C HTML WG ==

=== Are there plans to merge the groups? ===

Not especially. There are people who for a number of reasons are unable to join the W3C group, and there are others who are unable to join the WHATWG group. The editor is in both groups and takes all input into account -- and there are far more places where input on HTML5 is sent than just these two mailing lists (e.g. blogs, www-html@w3.org, forums, direct mail, meetings, etc).

=== Which group has authority in the event of a dispute? ===

The editor takes feedback from everyone into account and does not look at the source of those arguments for technical arguments.

== The WHATWG Process ==

=== How does the WHATWG work? ===

People send e-mail to [http://www.whatwg.org/mailing-list#specs the mailing list]. The editor then reads that [http://www.whatwg.org/issues/ feedback] and, taking it into account along with research, studies, and feedback from many other sources (blogs, forums, IRC, etc) makes language design decisions intended to address everyone's needs as well as possible while keeping the language consistent.

This continues, with people sending more feedback, until nobody is able to convince the editor to change the spec any more (e.g. because two people want opposite things, and the editor has considered all the information available and decided that one of the two proposals is the better one).

This is not a consensus-based approach -- there's no guarantee that everyone will be happy! There is also no voting.

There is a small oversight committee (known as the "WHATWG members", see the [http://www.whatwg.org/charter charter]) who have the authority to override or replace the editor if he starts making bad decisions.

Currently the editor is Ian Hickson.

Talk:New Vocabularies

2008-03-25T16:42:49Z

Jeff schiller:

I hand author MathMl and SVG in XHTML pages. Most recently FireFox 3 added the ability to display [http://www.comfsm.fm/~dleeling/tech/mathml-in-svg.xhtml mathml in svg in xhtml] - nested XML namespaces. The languages can and will be learned by many like me who generate math and science materials for academic web sites. Since I author HTML5 using essentially HTML 4.01 strict standards, I can fairly easily shift from an HTML5 compliant document to an XHTML+MathMl+SVG compliant document. This is neither hard nor scary. I suspect the real issue is the draconian error handling that XHTML+MathMl+SVG brings with it, and may be why many authors want to see MathMl and SVG namespaces in HTML. That is an implementor issue, however, and not a language issue. It seems to this naive person that an implementor could choose other options besides a "yellow screen of death" simply because an img tag was not closed/terminated properly.
: "an implementor could choose other options" [https://bugzilla.mozilla.org/show_bug.cgi?id=418305 Agreed]. Opera already does a decent job (even giving you the option to re-parse the page as HTML. [[User:Jeff schiller|Jeff schiller]] 16:42, 25 March 2008 (UTC)

New Vocabularies

2008-03-25T16:34:45Z

Jeff schiller: Highlight use case titles

This page summarises the ''problems'' discussed in the e-mails that ended up in the [http://www.whatwg.org/issues/#html-parsing-rules-namespaces-discussion html-parsing-rules-namespaces-discussion] folder.

* '''Putting an equation in a Web page''' Priorities:
** Maintainability
** Searchability
** Accessibility
** Typographically-sound printing
** Ease of authoring (are authors willing to learn new formats?)
** Ease of import from existing documents
** Ease of implementation (are UAs willing to implement new formats?)
** Resistance to errors (e.g. not brittle in the face of syntax errors)
** Ability to include

* '''Migrating from LaTeX to HTML''' Priorities:
** Fidelity

* '''Writing a document by hand, with inline diagrams imported from a graphics package''' Priorities:
** Compatibility with existing graphics packages
** Resistance to errors (e.g. not brittle in the face of syntax errors)
** Scriptable (retained-mode, with DOM support, without requiring cross-frame scripting)
** Round-tripping (the ability to take image fragments from a Web page and edit them)

* '''Writing documents that include diagrams that include typographically-correct mathematics'''

* '''The ability to animate elements in a web page (hypertext, vector graphics) without using script''' Priorities:
** Set or animate sizes, positions, opacities, colors, transforms (basically most attributes and properties)
** Many ways of triggering begin/end (time-based and DOM events)
** Inlined (for simple web pages) and non-inlined animations (to promote separation of content and presentation)
** Linear and Spline interpolation

Philip also wrote [http://www.w3.org/mid/47DC70FB.1060205@cam.ac.uk a detailed story], which touches on several of the points above, of what we want to enable. In addition to the points above, his requirements include a solution for ID clashes in multiple-document transclution, and a solution for embedding custom non-visible data in an HTML document for scripting purposes.

==Supporting data and research==

* What is the most widely known way of authoring mathematics?
* What human-editable source language are equations mostly serialised in today?
* Animation is a desired capability for web authors of Rich Internet Applications. Of the [http://en.wikipedia.org/wiki/Ajax_framework#JavaScript top Ajax Javascript toolkits] listed on Wikipedia, all support some level of animation, each in a different, and possibly incompatible, way:
** [http://bdn.backbase.com/docs/client_4_1_2/Reference_files/index.html#bb_smil_281732121.html Backbase]
** [http://redesign.dojotoolkit.org/jsdoc/dojo/HEAD/dojo.animateProperty dojo]
** [http://extjs.com/deploy/dev/docs/output/Ext.Element.html ext]
** [http://docs.jquery.com/Effects jQuery]
** [http://docs.mootools.net/out/files/Effects/Fx-Styles-js.html Mootools]
** [http://prototypejs.org/api/periodicalExecuter prototype] (weak)
** [http://wiki.script.aculo.us/scriptaculous/show/VisualEffects script.aculo.us]
** [http://developer.yahoo.com/yui/animation/ YUI]

New Vocabularies

2008-03-25T16:32:50Z

Jeff schiller: /* Supporting data and research */ Remove second RIA reference

This page summarises the ''problems'' discussed in the e-mails that ended up in the [http://www.whatwg.org/issues/#html-parsing-rules-namespaces-discussion html-parsing-rules-namespaces-discussion] folder.

* Putting an equation in a Web page. Priorities:
** Maintainability
** Searchability
** Accessibility
** Typographically-sound printing
** Ease of authoring (are authors willing to learn new formats?)
** Ease of import from existing documents
** Ease of implementation (are UAs willing to implement new formats?)
** Resistance to errors (e.g. not brittle in the face of syntax errors)
** Ability to include

* Migrating from LaTeX to HTML. Priorities:
** Fidelity

* Writing a document by hand, with inline diagrams imported from a graphics package. Priorities:
** Compatibility with existing graphics packages
** Resistance to errors (e.g. not brittle in the face of syntax errors)
** Scriptable (retained-mode, with DOM support, without requiring cross-frame scripting)
** Round-tripping (the ability to take image fragments from a Web page and edit them)

* Writing documents that include diagrams that include typographically-correct mathematics.

* The ability to animate elements in a web page (hypertext, vector graphics) without using script. Priorities:
** Set or animate sizes, positions, opacities, colors, transforms (basically most attributes and properties)
** Many ways of triggering begin/end (time-based and DOM events)
** Inlined (for simple web pages) and non-inlined animations (to promote separation of content and presentation)
** Linear and Spline interpolation

Philip also wrote [http://www.w3.org/mid/47DC70FB.1060205@cam.ac.uk a detailed story], which touches on several of the points above, of what we want to enable. In addition to the points above, his requirements include a solution for ID clashes in multiple-document transclution, and a solution for embedding custom non-visible data in an HTML document for scripting purposes.

==Supporting data and research==

* What is the most widely known way of authoring mathematics?
* What human-editable source language are equations mostly serialised in today?
* Animation is a desired capability for web authors of Rich Internet Applications. Of the [http://en.wikipedia.org/wiki/Ajax_framework#JavaScript top Ajax Javascript toolkits] listed on Wikipedia, all support some level of animation, each in a different, and possibly incompatible, way:
** [http://bdn.backbase.com/docs/client_4_1_2/Reference_files/index.html#bb_smil_281732121.html Backbase]
** [http://redesign.dojotoolkit.org/jsdoc/dojo/HEAD/dojo.animateProperty dojo]
** [http://extjs.com/deploy/dev/docs/output/Ext.Element.html ext]
** [http://docs.jquery.com/Effects jQuery]
** [http://docs.mootools.net/out/files/Effects/Fx-Styles-js.html Mootools]
** [http://prototypejs.org/api/periodicalExecuter prototype] (weak)
** [http://wiki.script.aculo.us/scriptaculous/show/VisualEffects script.aculo.us]
** [http://developer.yahoo.com/yui/animation/ YUI]

New Vocabularies

2008-03-25T16:32:09Z

Jeff schiller: Declarative animation use case

This page summarises the ''problems'' discussed in the e-mails that ended up in the [http://www.whatwg.org/issues/#html-parsing-rules-namespaces-discussion html-parsing-rules-namespaces-discussion] folder.

* Putting an equation in a Web page. Priorities:
** Maintainability
** Searchability
** Accessibility
** Typographically-sound printing
** Ease of authoring (are authors willing to learn new formats?)
** Ease of import from existing documents
** Ease of implementation (are UAs willing to implement new formats?)
** Resistance to errors (e.g. not brittle in the face of syntax errors)
** Ability to include

* Migrating from LaTeX to HTML. Priorities:
** Fidelity

* Writing a document by hand, with inline diagrams imported from a graphics package. Priorities:
** Compatibility with existing graphics packages
** Resistance to errors (e.g. not brittle in the face of syntax errors)
** Scriptable (retained-mode, with DOM support, without requiring cross-frame scripting)
** Round-tripping (the ability to take image fragments from a Web page and edit them)

* Writing documents that include diagrams that include typographically-correct mathematics.

* The ability to animate elements in a web page (hypertext, vector graphics) without using script. Priorities:
** Set or animate sizes, positions, opacities, colors, transforms (basically most attributes and properties)
** Many ways of triggering begin/end (time-based and DOM events)
** Inlined (for simple web pages) and non-inlined animations (to promote separation of content and presentation)
** Linear and Spline interpolation

Philip also wrote [http://www.w3.org/mid/47DC70FB.1060205@cam.ac.uk a detailed story], which touches on several of the points above, of what we want to enable. In addition to the points above, his requirements include a solution for ID clashes in multiple-document transclution, and a solution for embedding custom non-visible data in an HTML document for scripting purposes.

==Supporting data and research==

* What is the most widely known way of authoring mathematics?
* What human-editable source language are equations mostly serialised in today?
* Animation is a desired capability for web authors of Rich Internet Applications. Of the [http://en.wikipedia.org/wiki/Ajax_framework#JavaScript top Ajax Javascript toolkits] listed on Wikipedia, all support some level of animation in Rich Internet Applications, each in a different, and possibly incompatible, way:
** [http://bdn.backbase.com/docs/client_4_1_2/Reference_files/index.html#bb_smil_281732121.html Backbase]
** [http://redesign.dojotoolkit.org/jsdoc/dojo/HEAD/dojo.animateProperty dojo]
** [http://extjs.com/deploy/dev/docs/output/Ext.Element.html ext]
** [http://docs.jquery.com/Effects jQuery]
** [http://docs.mootools.net/out/files/Effects/Fx-Styles-js.html Mootools]
** [http://prototypejs.org/api/periodicalExecuter prototype] (weak)
** [http://wiki.script.aculo.us/scriptaculous/show/VisualEffects script.aculo.us]
** [http://developer.yahoo.com/yui/animation/ YUI]