WHATWG Wiki - User contributions [en]

Feature Proposals

2007-02-11T13:40:36Z

Silvaner: /* Document Markup */ rm

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

== Guidelines ==

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

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

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

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

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

== Other ==

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

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

Static

2007-02-11T13:40:17Z

Silvaner: "changed my mind"

Static

2007-02-10T21:35:56Z

Silvaner: /* My Solution */ some more...

This page is about a tag called '''static''' or '''locked''' that marks a portion of the page as not to be refreshed when refreshing or navigating to another page on the site.

== Use Case Description ==
Often some parts of the page on a site do not change in content, size and position on a given page or pages on a site. These parts shouldn't be redrawn when refreshing or navigating to a different page with the same elements. These elements are usually navigation bars, logos and legal disclamers on the bottom.

=== Current Limitations ===
There is no such tag at current, and though pics are stored in the browser cache, they are re-rendered every time the page or a similar one loads.

=== Current Usage and Workarounds ===
Frames work around this problem, but they are not widely used, and have problems which make them unpopular

=== Benefits ===
Browsing through a list of search results would become faster, also browsing through sites with many graphical elements

=== Requests for this Feature ===

== Proposed Solutions ==

=== My Solution ===
The solution would be to introduce <static> and </static> tags that would include the attributes static_url for the site and a static_id for the class of documents. For example <static static_url=whatwg.org static_id=001> ''insert code for the navigation bar'' </static static_id=001>

Then the browser would know on the next page that url and id are identical and just redraw the part of the screen corresponding to the code inside <static></static>. Through the id, a site can also adopt different static elements like navigation bars for different sections of the site. An alternative to the number would be a keyword like static_id="navbar1"

==== Processing Model ====
The browser would need a bitmap cache for the <static> parts of the current website, or possibly the ''n'' last visited websites together with their positions on the page. Also a timeframe should be set when to reload the static parts, either in the tag via a static_expires=x number of days property or via a fixed timespan, or from session to session (that would lessen the benefits considerably). Misuse should be difficult, since the website has to be one currently displayed. It doesn't work on pages on servers with different top domains, but that would be a case occurring seldomly.

==== Limitations ====
It doesn't work on pages of organizations with different top domains e.g. wikipedia.org vs. wikibooks.org etc., but that would be a case occurring not too often.

==== Implementation ====
Implementation on the browser seems straight forward, since redrawing parts of the screen is easy. It wouldn't work with sites that do not specify exact sizes or positions (or positioning elements that determine the position in an unamiguous way like a table with a width percentage) for elements.

==== Adoption ====
Faster rendering. A site with lots of graphics (NYT) would (re)load nearly as fast as a site with text only. Certainly ads and picture content would still have to reload, so not every page would reload faster.

Static

2007-02-10T21:27:41Z

Silvaner: /* My Solution */ typo

This page is about a tag called '''static''' or '''locked''' that marks a portion of the page as not to be refreshed when refreshing or navigating to another page on the site.

== Use Case Description ==
Often some parts of the page on a site do not change in content, size and position on a given page or pages on a site. These parts shouldn't be redrawn when refreshing or navigating to a different page with the same elements. These elements are usually navigation bars, logos and legal disclamers on the bottom.

=== Current Limitations ===
There is no such tag at current, and though pics are stored in the browser cache, they are re-rendered every time the page or a similar one loads.

=== Current Usage and Workarounds ===
Frames work around this problem, but they are not widely used, and have problems which make them unpopular

=== Benefits ===
Browsing through a list of search results would become faster, also browsing through sites with many graphical elements

=== Requests for this Feature ===

== Proposed Solutions ==

=== My Solution ===
The solution would be to introduce <static> and </static> tags that would include the attributes static_url for the site and a static_id for the class of documents. For example <static static_url=whatwg.org static_id=001> ''insert code for the navigation bar'' </static static_id=001>

Then the browser would know on the next page that url and id are identical and just redraw the part of the screen corresponding to the code inside <static></static>. Through the id, a site can also adopt different static elements like navigation bars for different sections of the site. An alternative to the number would be a keyword like static_id="navbar1"

==== Processing Model ====
The browser would need a bitmap cache for the static documents of the current website, or possibly the ''n'' last visited websites together with their positions on the page. Misuse should be difficult, since the website has to be one currently displayed. It doesn't work on pages on servers with different top domains, but that would be a case occurring seldomly.

==== Limitations ====
It doesn't work on pages on organizations with different top domains e.g. wikipedia vs. wikibooks etc., but that would be a case occurring not too often.

==== Implementation ====
Implementation on the browser seems straight forward, since redrawing parts of the screen is easy. It wouldn't work with sites that do not specify exact sizes for elements.

==== Adoption ====
Faster rendering. A site with lots of graphics (ESPN) would (re)load nearly as fast as a site with text only. Certainly ads would still have to reload, so it might not be that faster everywhere

Static

2007-02-10T21:26:42Z

Silvaner: /* My Solution */ why static_id

This page is about a tag called '''static''' or '''locked''' that marks a portion of the page as not to be refreshed when refreshing or navigating to another page on the site.

== Use Case Description ==
Often some parts of the page on a site do not change in content, size and position on a given page or pages on a site. These parts shouldn't be redrawn when refreshing or navigating to a different page with the same elements. These elements are usually navigation bars, logos and legal disclamers on the bottom.

=== Current Limitations ===
There is no such tag at current, and though pics are stored in the browser cache, they are re-rendered every time the page or a similar one loads.

=== Current Usage and Workarounds ===
Frames work around this problem, but they are not widely used, and have problems which make them unpopular

=== Benefits ===
Browsing through a list of search results would become faster, also browsing through sites with many graphical elements

=== Requests for this Feature ===

== Proposed Solutions ==

=== My Solution ===
The solution would be to introduce <static> and </static> tags that would include the attributes static_url for the site and a static_id for the class of documents. For example <static static_url=whatwg.org static_is=001> ''insert code for the navigation bar'' </static static_id=001>

Then the browser would know on the next page that url and id are identical and just redraw the part of the screen corresponding to the code inside <static></static>. Through the id, a site can also adopt different static elements like navigation bars for different sections of the site. An alternative to the number would be a keyword like static_id="navbar1"

==== Processing Model ====
The browser would need a bitmap cache for the static documents of the current website, or possibly the ''n'' last visited websites together with their positions on the page. Misuse should be difficult, since the website has to be one currently displayed. It doesn't work on pages on servers with different top domains, but that would be a case occurring seldomly.

==== Limitations ====
It doesn't work on pages on organizations with different top domains e.g. wikipedia vs. wikibooks etc., but that would be a case occurring not too often.

==== Implementation ====
Implementation on the browser seems straight forward, since redrawing parts of the screen is easy. It wouldn't work with sites that do not specify exact sizes for elements.

==== Adoption ====
Faster rendering. A site with lots of graphics (ESPN) would (re)load nearly as fast as a site with text only. Certainly ads would still have to reload, so it might not be that faster everywhere

Feature Proposals

2007-02-10T21:21:06Z

Silvaner: /* Document Markup */

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

== Guidelines ==

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

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

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

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

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

== Other ==

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

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

Static

2007-02-10T21:20:38Z

Silvaner: just a thought

This page is about a tag called '''static''' or '''locked''' that marks a portion of the page as not to be refreshed when refreshing or navigating to another page on the site.

== Use Case Description ==
Often some parts of the page on a site do not change in content, size and position on a given page or pages on a site. These parts shouldn't be redrawn when refreshing or navigating to a different page with the same elements. These elements are usually navigation bars, logos and legal disclamers on the bottom.

=== Current Limitations ===
There is no such tag at current, and though pics are stored in the browser cache, they are re-rendered every time the page or a similar one loads.

=== Current Usage and Workarounds ===
Frames work around this problem, but they are not widely used, and have problems which make them unpopular

=== Benefits ===
Browsing through a list of search results would become faster, also browsing through sites with many graphical elements

=== Requests for this Feature ===

== Proposed Solutions ==

=== My Solution ===
The solution would be to introduce <static> and </static> tags that would include the attributes static_url for the site and a static_id for the class of documents. For example <static static_url=whatwg.org static_is=001> ''insert code for the navigation bar'' </static static_id=001>

Then the browser would know on the next page that url and id are identical and just redraw the part of the screen corresponding to the code inside <static></static>

==== Processing Model ====
The browser would need a bitmap cache for the static documents of the current website, or possibly the ''n'' last visited websites together with their positions on the page. Misuse should be difficult, since the website has to be one currently displayed. It doesn't work on pages on servers with different top domains, but that would be a case occurring seldomly.

==== Limitations ====
It doesn't work on pages on organizations with different top domains e.g. wikipedia vs. wikibooks etc., but that would be a case occurring not too often.

==== Implementation ====
Implementation on the browser seems straight forward, since redrawing parts of the screen is easy. It wouldn't work with sites that do not specify exact sizes for elements.

==== Adoption ====
Faster rendering. A site with lots of graphics (ESPN) would (re)load nearly as fast as a site with text only. Certainly ads would still have to reload, so it might not be that faster everywhere