Difference between revisions of "HTML/next"

From W3C Wiki
Jump to: navigation, search
(== Allow or require script element to be placed outside)
(Multimedia: Responsive Images)
Line 162: Line 162:
==== Multimedia ====
==== Multimedia ====
===== Adaptive Images =====
===== Responsive Images =====
See the documentation of Responsive [[Images]] on this wiki. Please add to that, including incorporating other ideas like the below (Adaptive Images etc.).
===== Adaptive Images =====
Read more about [[Adaptive Images]] or see [https://gist.github.com/2159117 Adaptive Image Element].
Read more about [[Adaptive Images]] or see [https://gist.github.com/2159117 Adaptive Image Element].

Revision as of 18:59, 20 July 2012


Part of HTML/wg work.

HTML.next in W3C bugzilla

Ideas for HTML.next

Ideas don't need to be fully fleshed out. In fact, in many cases a simple pointer to a proposal or even a discussion hosted elsewhere is all that is needed at this time.

There isn't a hard deadline on this request, but we anticipate that the data captured will be discussed at the next AC meeting which goes from the 15th of May to the 17th of May. — Sam Ruby

Do not hesitate to make lists. A good source of ideas are the bugs resolved LATER.

See also (and copy from there to here)

Ideas List

New Semantics

Decompress Element <decompress> to integrate files from ZIP folders into webpages directly

Goal: To allow files from compressed folders (primarily .ZIP, and so forth) to be accessible in web browsers. This could have many uses, such as reducing bandwidth for computer and mobile platforms by distributing large HTML or image files through a ZIP folder and allowing them to be accessible through a web browser.

First, specify the ZIP folder that carries the files that you wish to be displayed on your webpage.


<decompress href=”http://thisisanexample.com/mobile/familyreunion.zip”>

This informs the browser that the zip folder “familyreunion.zip” contains files that may need to be used in the HTML document. After the decompress element has been used, files from the ZIP folder can be integrated into the webpage like the following examples:

<a href=”familyreunion.zip/html/activities.html”>Activities from our family reunion</a>

<img src=”familyreunion.zip/img/familyreunion1.jpg”>

In the first line of code from the example, the anchor tag provides a link to an HTML document inside the file “familyreunion.zip”. Since the ZIP folder has already been specified in the decompress tag, the anchor tag automatically is aware of where to go inside the ZIP folder if the user clicks on the link “Activities from our family reunion.”

On the second line of code from the example, the image tag works likewise but grabs a photo from the specified “familyreunion.zip” and sticks it on the current page the user is browsing.

Just as note, it is imperative that each ZIP file that contains files to be integrated into a webpage is called through the decompress tag. Not doing so might have the browser prompt the user to save the ZIP folder to the user’s hard drive instead of displaying the contents directly in the webpage.

--Jace Voracek November 5, 2011

Isn't this already achieved through the Content-Encoding and Transfer-Encoding headers of HTTP/1.1?

--Asbjørn Ulsberg

Semantics for expressing titles and authors

Being able to identify the title of a book, blog posts, movie, etc. and to relate to it the authors even if the markup is being spread over a few paragraph. In a pseudo markup to illustrate what could be the links in between the items. That would not be mandatory to establish the relations in between them.

    [title: The praise of Shadow id:praise by:junichiro] 
    is a book written by [author: Junichiro Tanizaki id:junichiro] 
    explaining … etc.
<location> element (like

Eg <location lat=54.3 long=32 altitude=540>Bill's mother's house</location

<datagrid> element
<teaser> Element

I've made this proposal elsewhere, but here seems a good place to reiterate it. The <teaser> element is intended to be a wrapper around a summary block of content with an associated link to a fuller block of content. You see similar structures all over the web, from search result listings to front pages for blogging sites, in which you generally have a title (often linked), a summary block with or without some kind of media resource, and either a _more_ link or a URL to the full article. In general it would be a sectional element that might be placed in another sectional element, such as <nav> pages:

            <h1><a href="http://www.myserver.com/myFirstCoolArticle.html">My First Cool Article</a></h1>
        <p>This is my first article on the page, and it's really cool.</p>
            <time>3 Days Ago</time>
            <div><a href="http://www.myserver.com/myFirstCoolArticle.html"
            <h1><a href="http://www.myserver.com/mySecondCoolArticle.html"
            >My Second Cool Article</a></h1>
        <p>This article is on superconducting fields, and is even cooler than my first article.</p>
            <time>1 Days Ago</time>
                <a href="http://www.myserver.com/mySecondCoolArticle.html"

There are a number of good reasons for adopting the <teaser> element:

  • It describes a common, frequently used structure in HTML.
  • There are currently no elements that serve the same purpose (the closest may be <cite>, but that more commonly is used specifically as a footnote citation mechanism, and is not specifically aware of the <header>/<footer> structure of HTML5).
  • It increases search engine optimization and component control optimization, as different widgets could be used to render this structure in different ways from a list of items to a shoutbox or similar component.
  • It doesn't necessarily participate in the list numbering mechanism.
  • It can be used with internal named anchorst to make a fast TOC.
  • It works well in the blogging model that HTML5 seems to be adopting as the foundation for sectional content.
Importing font file formats using a "fontsrc" tag attribute

Being able to integrate specific font file formats into a webpage using a "fontsrc" attribute. Such would be used for purposes of allowing a "special" font to be displayed on a page that would typically be unrecognized by other web browsers. This would allow a developer to use unique special characters on the page, or developers to customize the font of languages that are sometimes difficult to read because of jumbled pixels. (Arabic, Farsi, etc.) It may be best to use this element with the common .TTF, .FNT, and .TF formats.

For example, the font format could be called using the font tag:

 <font fontsrc="http://www.example.com/fontexample.ttf" size="5">
    Text written here will be displayed according to the font file format specified.

--Jace Voracek April 2011

This functionality is already supported via the CSS @font-face rule [1].

--Glenn Adams November 2011


Automatic capitalization in input fields

See the proposal for use cases and details.

Enhancing Authentication Forms

Today most browsers include heuristics for guessing when a page includes a form that represents an authentication or login form with variable accuracy. These heuristics are sometimes confused by password change forms, for example. Adding annotations to forms and fields representing authentication would allow user agents to more accurately recognise these scenarios and improve interoperability in this area.

--Adrian Bateman [MSFT] 11 May 2011

Localising Form Controls

Web developers frequently ask for the ability to localise form controls that include text such as the Browse or Pick button on <input type=file> and the strings that make up date/time controls.

--Adrian Bateman [MSFT] 28 June 2011


Web developers need a inputable dropdown select like other UI system.

<select name="age" inputable="inputable">
<option value="11"></option>
<option value="12"></option>

--Yanming Zhou 1 Feb 2012


Responsive Images

See the documentation of Responsive Images on this wiki. Please add to that, including incorporating other ideas like the below (Adaptive Images etc.).

Adaptive Images

Read more about Adaptive Images or see Adaptive Image Element.

Adaptive Streaming

See http://wiki.whatwg.org/wiki/Adaptive_Streaming and http://wiki.whatwg.org/wiki/Video_Metrics for some initial work.

There are a number of different adaptive streaming formats (just like there are a number of different progressive download media formats). Many uses cases for adaptive streaming also require some form of protected content. The current HTML5 media elements support selecting from different formats and defining these formats is outside the scope of the HTML working group. Nevertheless, there are aspects of adaptive streaming and protected content that do require enhancement in the scope of HTML to support common use cases (especially those from popular video distribution networks). Specifically, these include:

  • Additional media element states to allow the UA to display status (for example negotiating acquisition with the server)
  • Additional media element errors (for example failed negotiation)
  • Additional media element events (for example bit-rate change)
  • Additional media element properties (for example current bit-rate - this may be related to the other QOS metrics)
Audio Balance

HTML5 Audio balance adjustment (left/right) for stereo tracks.

Video enhancements

(fast/slow) rewind, previous/next frame

Fullscreen and Screenshots

domElement.fullScreen(); and domElement.getImageData(0, 0, domElement.offsetWidth, domElement.offsetHeight);

For fullscreen, see Fullscreen


<editor> element

An editor element which allows saving back to the same page one is editing without all the hassle we have to go through today.

<textarea type="wysiwyg">

It could be <textarea type="wysiwyg"> or some such. It should support "flat" yet simplified HTML.

Main purpose of the editor: WYSIWYG editing of structured (semantic) text. Intended usage: blogs, emails, WYSIWYG wiki editing.

Proposed list of supported elements:

  • blocks p, ul/li,ol/li,dl/dt/dd,blockquote,pre
  • spans: strong/em/a/sup/sub/u/code/strike.
  • inline-blocks: img and br(with proper visualization).
  • simple tables: table/tr/th/td


  • shall support copy/paste of images from/to system clipboard (can be disabled by attribute)
  • shall support copy/paste of text and HTML from/to system clipboard (can be disabled by attribute)
  • shall not support inline styles of any kinds.
  • may have attribute content-style="some.css" defining styles of elements inside the editor.
    • only simple "tag" and "tag.class" selectors in some.css shall be used.

Serialization: It shall be serializeable (set/get) into markup with structure close to this:

    <image cid="1234" name="..." type=mime/type>base-64-encoded body</image>
    <image cid="5678" name="..." type=mime/type>base-64-encoded body</image>
  <body>... mini-html markup ... <img alt=... cid="5678"> </body>

cid's (content id's) shall support unique naming that allows to do simple body.replace("cid=1234","src=final.url") when content needs to be rendered outside the editor.

Form submission of such input element shall be done as a whole: images, if any, are part of the content. Value of the input element is either plain text, HTML fragment (with images having only external urls) and <envelope> - for JavaScript it is a JSON map {"head":[],body:""}. --Andrew Fedoniouk 05:46, 11 April 2011 (UTC)


Imagine a list like this one: <ol><li>Lorem<li>Ipsum<li>Dolor<li>sit<li>et cetera</ol> It will render like this:

  1. Lorem
  2. Ipsum
  3. Dolor
  4. sit
  5. et cetera

Now, if you as user/author copy the entire list item with 'Dolor', and paste it into a normal WYSIWYG text editor, its "3." will be replaced with "1." But I want to be able to copy it as number "3."

Components and ECMAScript


Also known as dynamic subclassing of DOM elements.

This feature is greatly useful for UI component frameworks and toolkits.

Consider this JavaScript code:

document.behaviors["ul.some>li"] = { // the behavior class:
  attached: function() {...},
  detached: function() {...},
  onmousedown: function() {...}, 
  onclick: function() {...}, 

The behavior is a collection of methods that is assigned (mixed-in) to all elements satisfying the selector used in declaration. When the element gets the behavior then the attached function is invoked. onmousedown and others will be default event handlers for such elements.

For the same purposes we can reuse binding property from CSS (See BECSS at http://www.w3.org/TR/becss/#the-binding )

document.behaviors["some.name"] = { // registration of the behavior class:
  attached: function() {...},
  detached: function() {...},
  onmousedown: function() {...}, 
  onclick: function() {...}, 

And in CSS:

  color: red;
  binding: "some.name" [optional js source url];

Example of its use, in CSS we can define

input[type="masked"] { binding:"jquery-ui.masked"; }

And so in markup it will be enough to define

<input type="masked" >

to insert and activate it in place (assuming that behavioral jquery-ui implementation is included).

--Andrew Fedoniouk 06:14, 11 April 2011 (UTC)


For the sake of modularity it should be window.include("url"[,mime/type]) method available in JavaScript.

Similar to what @import url(...) does in CSS.

If to assume that behaviors are there then the include() should able to include CSS resources too.

--Andrew Fedoniouk 06:25, 11 April 2011 (UTC)

Allow or require script element to be placed outside <body></body>

script elements or any other inclusion tag (like included css files) should be placed outside the body of a document.

             scripts, css etc 
             the place for html
             scripts etc 

--Marco Kotrotsos 09 Juli 2012

JavaScript: namespaces and classes

(I don't know is this the right place for JavaScript improvement proposals or not, anyway...)

JavaScript code is getting more and more complex these days. Many libraries can be used on the same page. But lack of namespaces [and classes] is just non-acceptable. May I suggest to consider namespaces and classes in JavaScript from my TIScript? TIScript uses similar (to JS) runtime and syntax so I am pretty sure they can be added to JS as they are.

--Andrew Fedoniouk 06:37, 11 April 2011 (UTC)

Syntax highlighting for <code> elements

I believe this has already been hinted on before, but here goes. Browsers usually already have a syntax highlighting code path, used when viewing HTML, CSS or JavaScript source code. It would be neat to enable syntax highlighting on <code> elements, without the need for crazy server-side or client-side parsers. It should be possible to specify the programming language through an attribute (although I’m not sure @lang should be used for this). The presence of this special attribute could imply that syntax highlighting is desired, but it can still be disabled by attribute. Native code highlighting for HTML, CSS and JS would be great start, but maybe there could be a standardized way for authors to include new programming languages. I’d imagine this would use the shadow DOM to render, and styles could be tweaked through the use of pseudo-elements in CSS.

--Mathias Bynens 05:56, 12 April 2011 (UTC)

Code Formatting for <code> elements

Regarding the proposal above me 'Syntax Highlighting' I would like to extend this with Code Formatting. Same rules and standards but to include formatting.

--Marco Kotrotsos 15:14, 09 May 2012 (UTC)

Document Organisation

Modular Enhancements

Thinking about enhancing HTML after the HTML5 specification moves into Last Call, we believe that an approach similar to the CSS3 structure is favourable. The CSS working group works on a number of different modules in parallel, each progressing at a different rate, some being successful and some falling by the wayside. They all depend on the framework defined by CSS 2.1, the large monolithic spec that they all reference. Most of the modules are additive but some may modify or extend the behaviour of the underlying 2.1 spec.

Applying this notion to HTML, we would like to see new HTML features proposed as cohesive modules with a dependency back to the monolithic HTML5 spec that provides the overall framework. One of the problems with a large specification is that different features stabilise at different rates. Adopting a more modular approach would allow the features with most interest and support to move forward more quickly. This allows implementers to ship without vendor prefixes and yet avoid some of the versioning issues we've seen recently.

--Adrian Bateman [MSFT] 11 May 2011