WHATWG Wiki - User contributions [en]

Problem Solving

2008-12-01T13:21:18Z

Mabdul: adding cat

This is an empty page that describes what should be documented about a problem and the different solutions proposed to address it. Feel free to copy this template to when creating a new page.

:''Brief description of the problem to solve.''

== Use Case Description ==
''Complete description of the use case.''

=== Current Limitations ===
''Explanation of why the current markup is insufficient.''

=== Current Usage and Workarounds ===
''Some evidence that this feature is desperately needed on the web. You may provide a separate examples page for listing these.''

=== Benefits ===

''Explanation of how and why new markup would be useful.''

=== Requests for this Feature ===

* <cite>[http://example.com Source]</cite> <blockquote><p>I would like this feature ...</p></blockquote>

== Proposed Solutions ==

=== My Solution ===
:''Brief description of the solution and of how it address the problem at hand.''

==== Processing Model ====
:''Explanation of the changes introduced by this solution. It explains how the document is processed, and how errors are handled. This should be very clear, including things such as event timing if the solution involves events, how to create graphs representing the data in the case of semantic proposals, etc.''

==== Limitations ====
:''Cases not covered by this solution in relation to the problem description; other problems with this solution, if any.''

==== Implementation ====
:''Description of how and why browser vendors would take advantage of this feature.''

==== Adoption ====
:''Reasons why page authors would use this solution.''

[[Category:Feature Request|empty Template]]

Generic Metadata Mechanisms

2008-12-01T11:54:05Z

Mabdul: adding extrenal metadata con; commenting out the "notes to me"; the reader gets the impression of reading a diary

There have been some requests for introducing generic metadata mechanisms into HTML5.

To help determine what we would need to add, and whether it is worth adding anything, we have to come to an understanding of what the goals and requirements are of such a proposal.

Please document arguments with links to supporting research or links to other wiki pages detailing the anecdotal evidence for or against particular aspects of the goals and requirements.

= Goals =
== What is the problem we are trying to solve? ==
'''Nobody has yet answered this in this wiki; please see http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2008-September/016186.html for commentary and advice on how to fill this in.'''

== Who faces this problem? ==
Currently a few groups. In the future metadata may become necessary for the average "web consumer" (human or machine) to sort actual information from presentation and structural cruft. In other words, a useful tool for determining the meaning, terms of use, quality and/or authority of a piece of data inside (X)HTML.


= Requirements: If we assume that we are going to address this need, what do we need to provide? =
Please demonstrate the reasoning behind each requirement, along with examples of how the requirements could be addressed.

== Machine-readable ==
A machine-readable and standardized way to apply semantic properties (metadata) to DOM elements in HTML5 and XHTML5.


== Disambiguation ==
These properties are capable of being disambiguated between multiple definitions of the property name.

== Finding or defining meaning ==
We should be able to find or define an "authoritative" meaning for an abstract concept like "title" (eg. book title, job title, person's title, land deed, etc...).

== Machine-usability ==
The metadata could be read by UA's and other tools to perform actions that would not be possible without "knowing" what type of thing, quantity, unit or quality an element represents.

== DOM consistency ==
The DOM has to be consistent between the HTML and XHTML representations of the HTML5 specification. If it isn't, then migrating between the two becomes non-trivial, especially for scripting.

== Ease of deployment ==
The syntax has to be something that Web authors can easily deploy. If authors can't deploy this, then it won't get critical mass and won't matter.

One could argue that tools will be used to deploy this, that it'll mostly be used by big sites like Facebook, and that thus individual authors don't matter, but this kind of argument ("the tools will save us") has been repeatedly shown to not work, because in practice the tools have to be hand-authored too, and so the complexity is just moved to other people.

== Inlinability ==
It has to have a way to include it inline, so that it is quicker for non-professional developers to use and adopt. Also, putting metadata in the same location as content could prevent errors in updates or copying.

== Abstractability ==
It has to have both a way to abstract it from the HTML, like JS or CSS.

== Sustainability ==
Where possible the proposal should be resistant to temporary or permanent unavailability of an authoritative source (ie, vocabulary provider). This could be achieved, for example, through a P2P or DNS-like mechanism, or by not relying on external sources (e.g. in the way that SSL certificates are checked).

Not doing this would lead to failures during temporary outages or overloading of an authoritative source of metadata definitions, and may make it more resistant to hostile takeover or shutdown of authority.

Distributing an authoritative source needs not make it less authoritative.

== Reuse ==
The proposal should allow metadata and authoritative sources to be reused across elements, pages and sites, because web developers are more likely to use something that does not require repetitively typing the same data.

== Multilingual and Multicultural ==
Not all concepts can be expressed properly in English. A proposal should allow metadata for foreign languages and concepts.

== Authority and Security ==
Since a potential use of metadata appears to be enabling future features of UAs and other tools it follows that this opens the end-user to additional risks. For example, could a page author or hijacker feed a virus to a tool by falsely claiming it to be another type of data; could harm be caused when a metadata authority is hijacked by a group to deliberately mislead or blackmail; could metadata be used for unintended purposes such as spying on or annoying users.

With these risks in mind should there be standard mechanisms for securing metadata and verifying its source (such as signing certificates, encryption or white/black lists).

= Related Proposals, Research and Discussions =
* [http://www.mail-archive.com/whatwg@lists.whatwg.org/index.html#11037 WHATWG Discussions]
* [http://www.w3.org/2001/sw/interest/ w3c Semantic Web Interest Group (SWIG)]
* [http://lists.w3.org/Archives/Public/semantic-web/ W3C SWIG Mailing List Archive]
* [http://microformats.org/wiki/grddl GRRDL (Transformations of XHTML to RDF)]
* [http://www.xanthir.com/rdfa-vs-crdf.php RDFa vs. CRDF (Cascading RDF Proposal)]
* [http://research.talis.com/2005/erdf/wiki Embedded RDF Wiki]
* [http://research.talis.com/2005/erdf/wiki/Main/RdfInHtml RDF in HTML (Embedded RDF Examples)]
* [http://en.wikipedia.org/wiki/Semantic_web Wikipedia page on Semantic Web]
* [http://microformats.org/wiki/what-are-microformats What are Microformats? (microformats.org)]
* [http://www.foaf-project.org/ Friend of a Friend Project (FOAF)]
* [http://dublincore.org/ Dublin Core Metadata Initiative (DCMI)]

= Pre-Existing Software Systems That Demonstrate A Need =
* [http://www.kaply.com/weblog/operator/ Operator] - A semantic web processor for extracting metadata from all forms of HTML embedded by using Microformats and RDFa.
* [http://rdfa.digitalbazaar.com/fuzzbot/ Fuzzbot] - A semantic web processor for extracting triples from HTML4 and XHTML1.0, 1.1 and 2.0 data sources.
* [http://simile.mit.edu/wiki/Longwell Longwell] - Longwell is a web-based RDF-powered highly-configurable faceted browser.
* [http://simile.mit.edu/wiki/Piggy_Bank Piggy Bank] - Piggy Bank is a Firefox extension that turns your browser into a mashup platform, by allowing you to extract data from different web sites and mix them together. Piggy Bank also allows you to store this extracted information locally for you to search later and to exchange at need the collected information with others.
* [http://simile.mit.edu/wiki/Solvent Solvent] - Solvent is a Firefox extension that helps you write screen scrapers for Piggy Bank.
* [http://simile.mit.edu/wiki/Semantic_Bank Semantic Bank] - Semantic Bank is the server companion of Piggy Bank that lets you persist, share and publish data collected by individuals, groups or communities.
* [http://simile.mit.edu/wiki/Crowbar Crowbar] - Crowbar is a web scraping environment based on the use of a server-side headless mozilla-based browser. Its purpose is to allow running javascript scrapers against a DOM to automate web sites scraping but avoiding all the syntax normalization issues.
* [http://simile.mit.edu/wiki/Referee Referee] - Referee is a program that reads your web server logs and crawls your referrers (the links that point to your pages) and extract metadata from those pages and text around the links that pointed to your pages.

== Proposals ==
=== Inline (as multiple attributes) ===
Multiple new metadata attributes such as in RDFa.

* Pro: Reasonably simple to add to spec.

* Con: Dependent on changes to HTML spec for future changes to metadata spec.
* Con: Would probably require a different syntax for block or external version of same metadata (makes it hard to move).
* Con: Requires documentation and standardization in the HTML spec rather than through a separate document and standards body.
* Con: More potential for attribute name collisions with future HTML attributes.
* Con: Appears to make metadata reuse difficult.

=== Inline (in a single attribute) ===
One metadata attribute with complex content (such as the style attribute)

* Pro: New properties can be added without changing the HTML spec.
* Pro: Changing properties does not affect the DOM.
* Pro: The properties are grouped together.
* Pro: Requirements very similar to style="" and onclick="".

* Con: Requires new metadata format to be created.
* Con: Makes it harder to select individual property/value pairs through CSS or DOM scripting. (Might require dedicated APIs... Ugh.)

=== Block or external metadata ===
Metadata is defined elsewhere from element and targeted in the manner of CSS or Javascript.

* Pro: Does not clutter the HTML.
* Pro: Gives it more space to develop such as style did once it was abstracted from HTML.
* Pro: May be easier to import, export, reuse, sign and translate.
* Pro: May be applied to elements that the author cannot change attributes on (eg, dynamic, protected or generated content).
* Pro: Speed up where external metadata can be cached.

* Con: Requires new metadata format to be created.
* Con: CSS-like targeting or use of class or id to apply metadata adds complexity/indirection.
* Con: Extra HTTP-request

[[Category:Feature Request]]

Generic Metadata Mechanisms

2008-12-01T11:49:11Z

Mabdul: adding Category:Feature Request

There have been some requests for introducing generic metadata mechanisms into HTML5.

To help determine what we would need to add, and whether it is worth adding anything, we have to come to an understanding of what the goals and requirements are of such a proposal.

Please document arguments with links to supporting research or links to other wiki pages detailing the anecdotal evidence for or against particular aspects of the goals and requirements.

= Goals =

== What is the problem we are trying to solve? ==

'''Nobody has yet answered this in this wiki; please see http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2008-September/016186.html for commentary and advice on how to fill this in.'''

== Who faces this problem? ==

Currently a few groups. In the future metadata may become necessary for the average "web consumer" (human or machine) to sort actual information from presentation and structural cruft. In other words, a useful tool for determining the meaning, terms of use, quality and/or authority of a piece of data inside (X)HTML.

'''This section needs to be much, much more detailed. Who exactly faces the problem we're trying to solve? Name names of communities, organizations, companies, etc; show how they are "suffering" today and how they are currently working around the problem.'''

= Requirements: If we assume that we are going to address this need, what do we need to provide? =

Please demonstrate the reasoning behind each requirement, along with examples of how the requirements could be addressed.

== Machine-readable ==

A machine-readable and standardized way to apply semantic properties (metadata) to DOM elements in HTML5 and XHTML5.

'''Needs more detail. What does it mean to be machine-readable?'''

== Disambiguation ==

These properties are capable of being disambiguated between multiple definitions of the property name.

== Finding or defining meaning ==

We should be able to find or define an "authoritative" meaning for an abstract concept like "title" (eg. book title, job title, person's title, land deed, etc...).

'''Needs more detail. What does it mean to "find" an authoritative meaning?'''

== Machine-usability ==

The metadata could be read by UA's and other tools to perform actions that would not be possible without "knowing" what type of thing, quantity, unit or quality an element represents.

'''Needs more detail. How can this work? What does it mean in practice?'''

== DOM consistency ==

The DOM has to be consistent between the HTML and XHTML representations of the HTML5 specification. If it isn't, then migrating between the two becomes non-trivial, especially for scripting.

== Ease of deployment ==

The syntax has to be something that Web authors can easily deploy. If authors can't deploy this, then it won't get critical mass and won't matter.

One could argue that tools will be used to deploy this, that it'll mostly be used by big sites like Facebook, and that thus individual authors don't matter, but this kind of argument ("the tools will save us") has been repeatedly shown to not work, because in practice the tools have to be hand-authored too, and so the complexity is just moved to other people.

== Inlinability ==

It has to have a way to include it inline, so that it is quicker for non-professional developers to use and adopt. Also, putting metadata in the same location as content could prevent errors in updates or copying.

== Abstractability ==

It has to have both a way to abstract it from the HTML, like JS or CSS.

'''Needs more detail. Why does it need to be abstractable?'''

== Sustainability ==

Where possible the proposal should be resistant to temporary or permanent unavailability of an authoritative source (ie, vocabulary provider). This could be achieved, for example, through a P2P or DNS-like mechanism, or by not relying on external sources (e.g. in the way that SSL certificates are checked).

Not doing this would lead to failures during temporary outages or overloading of an authoritative source of metadata definitions, and may make it more resistant to hostile takeover or shutdown of authority.

Distributing an authoritative source needs not make it less authoritative.

== Reuse ==

The proposal should allow metadata and authoritative sources to be reused across elements, pages and sites, because web developers are more likely to use something that does not require repetitively typing the same data.

'''Needs more detail. Reuse how?'''

== Multilingual and Multicultural ==

Not all concepts can be expressed properly in English. A proposal should allow metadata for foreign languages and concepts.

== Authority and Security ==

Since a potential use of metadata appears to be enabling future features of UAs and other tools it follows that this opens the end-user to additional risks. For example, could a page author or hijacker feed a virus to a tool by falsely claiming it to be another type of data; could harm be caused when a metadata authority is hijacked by a group to deliberately mislead or blackmail; could metadata be used for unintended purposes such as spying on or annoying users.

With these risks in mind should there be standard mechanisms for securing metadata and verifying its source (such as signing certificates, encryption or white/black lists).

= Related Proposals, Research and Discussions =

* [http://www.mail-archive.com/whatwg@lists.whatwg.org/index.html#11037 WHATWG Discussions]
* [http://www.w3.org/2001/sw/interest/ w3c Semantic Web Interest Group (SWIG)]
* [http://lists.w3.org/Archives/Public/semantic-web/ W3C SWIG Mailing List Archive]
* [http://microformats.org/wiki/grddl GRRDL (Transformations of XHTML to RDF)]
* [http://www.xanthir.com/rdfa-vs-crdf.php RDFa vs. CRDF (Cascading RDF Proposal)]
* [http://research.talis.com/2005/erdf/wiki Embedded RDF Wiki]
* [http://research.talis.com/2005/erdf/wiki/Main/RdfInHtml RDF in HTML (Embedded RDF Examples)]
* [http://en.wikipedia.org/wiki/Semantic_web Wikipedia page on Semantic Web]
* [http://microformats.org/wiki/what-are-microformats What are Microformats? (microformats.org)]
* [http://www.foaf-project.org/ Friend of a Friend Project (FOAF)]
* [http://dublincore.org/ Dublin Core Metadata Initiative (DCMI)]

= Pre-Existing Software Systems That Demonstrate A Need =

* [http://www.kaply.com/weblog/operator/ Operator] - A semantic web processor for extracting metadata from all forms of HTML embedded by using Microformats and RDFa.
* [http://rdfa.digitalbazaar.com/fuzzbot/ Fuzzbot] - A semantic web processor for extracting triples from HTML4 and XHTML1.0, 1.1 and 2.0 data sources.
* [http://simile.mit.edu/wiki/Longwell Longwell] - Longwell is a web-based RDF-powered highly-configurable faceted browser.
* [http://simile.mit.edu/wiki/Piggy_Bank Piggy Bank] - Piggy Bank is a Firefox extension that turns your browser into a mashup platform, by allowing you to extract data from different web sites and mix them together. Piggy Bank also allows you to store this extracted information locally for you to search later and to exchange at need the collected information with others.
* [http://simile.mit.edu/wiki/Solvent Solvent] - Solvent is a Firefox extension that helps you write screen scrapers for Piggy Bank.
* [http://simile.mit.edu/wiki/Semantic_Bank Semantic Bank] - Semantic Bank is the server companion of Piggy Bank that lets you persist, share and publish data collected by individuals, groups or communities.
* [http://simile.mit.edu/wiki/Crowbar Crowbar] - Crowbar is a web scraping environment based on the use of a server-side headless mozilla-based browser. Its purpose is to allow running javascript scrapers against a DOM to automate web sites scraping but avoiding all the syntax normalization issues.
* [http://simile.mit.edu/wiki/Referee Referee] - Referee is a program that reads your web server logs and crawls your referrers (the links that point to your pages) and extract metadata from those pages and text around the links that pointed to your pages.

== Proposals ==

=== Inline (as multiple attributes) ===

Multiple new metadata attributes such as in RDFa.

* Pro: Reasonably simple to add to spec.

* Con: Dependent on changes to HTML spec for future changes to metadata spec.
* Con: Would probably require a different syntax for block or external version of same metadata (makes it hard to move).
* Con: Requires documentation and standardization in the HTML spec rather than through a separate document and standards body.
* Con: More potential for attribute name collisions with future HTML attributes.
* Con: Appears to make metadata reuse difficult.

=== Inline (in a single attribute) ===

One metadata attribute with complex content (such as the style attribute)

* Pro: New properties can be added without changing the HTML spec.
* Pro: Changing properties does not affect the DOM.
* Pro: The properties are grouped together.
* Pro: Requirements very similar to style="" and onclick="".

* Con: Requires new metadata format to be created.
* Con: Makes it harder to select individual property/value pairs through CSS or DOM scripting. (Might require dedicated APIs... Ugh.)

=== Block or external metadata ===

Metadata is defined elsewhere from element and targeted in the manner of CSS or Javascript.

* Pro: Does not clutter the HTML.
* Pro: Gives it more space to develop such as style did once it was abstracted from HTML.
* Pro: May be easier to import, export, reuse, sign and translate.
* Pro: May be applied to elements that the author cannot change attributes on (eg, dynamic, protected or generated content).
* Pro: Speed up where external metadata can be cached.

* Con: Requires new metadata format to be created.
* Con: CSS-like targeting or use of class or id to apply metadata adds complexity/indirection.

[[Category:Feature Request]]

User talk:Hixie

2008-12-01T11:43:39Z

Mabdul: /* Wikipedia */ sign again

== With regards to spam-bots ==

I would recommend enabling captchas during the registration process to stem the flood of nonsense accounts that are spamming the wiki. This can be done with the [http://www.mediawiki.org/wiki/Extension:ConfirmEdit ConfirmEdit] extension. — <span style="font-variant:small-caps;font-family:sans-serif;">[[User:Edward Z. Yang|Edward Z. Yang]]</span><sup style="font-family:serif;">([[User talk:Edward Z. Yang|Talk]])</sup> 19:39, 21 August 2007 (UTC)

'''it's not clear to me that the spammers aren't humans'''

== Do not relegate discussion to IRC ==

The summary of your edit at [http://wiki.whatwg.org/index.php?title=FAQ&oldid=3434 FAQ] is inappropriate. IRC discussion should not be required for editing. MediaWiki has better mechanisms for that.

While I am at that, thanks for adding at least some text that makes sense for Microsoft Outlook users.
--[[User:Yecril71pl|Yecril71pl]] 08:51, 15 November 2008 (UTC)

== rel="nofollow" ==

Hi,
I don't know if it is a feature request,but i read on [http://en.wikipedia.org/wiki/Nofollow wikipedia] that rel="nofollow" is actual in use. will this become a standard?/is there a discussion about this? should we make a wiki page? --[[User:Mabdul|Mabdul]] 11:26, 1 December 2008 (UTC)

== Wikipedia ==

Should we "port" some articles for explaining the fundamental terms (like svg, etc.) ? --[[User:Mabdul|Mabdul]] 11:43, 1 December 2008 (UTC)

User talk:Hixie

2008-12-01T11:42:57Z

Mabdul: New section: Wikipedia

Constraints for New Vocabularies

2008-12-01T11:39:19Z

Mabdul: rm see below; the reader will see it by one, we shouldn't advise himto"read that and that"

This page documents some of the constraints we have to work within when developing new syntax for HTML. It is primarily written in the context of MathML and SVG being added to text/html.

For a more detailed discussion, see the notes in:
* http://lists.w3.org/Archives/Public/www-svg/2008Apr/0028.html
* http://krijnhoetmer.nl/irc-logs/whatwg/20080417
* http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2008-April/014372.html

In summary, the constraints are that we must:
* Render the following in a way that is not significantly worse than today (extra whitespace is probably ok, most other things are probably not):
** http://www.cocopahrv.com/map.html
** http://www.laroseweb.com/calcs/fans.php
** http://puysl.com/view.htm
** http://albren.blogspot.com/2007/02/l05-traductor.html
* Render pages that today contain MathML in text/html better than today.
* Support MathML and SVG in the same way where possible.
* Fail gracefully in the face of ignorant author copy/paste.

==Ignorant author copy/paste==
Authors have, for some reason I haven't understood but which I have seen a ''lot'' on the web, a weird way of working, which consists of, sometimes, copying seemingly random chunks of pages, and pasting them into their own. They will even copy stuff from pages where the stuff does something in one browser (e.g. Firefox when that page is sent as XML), and paste them into their page where it does nothing (e.g. they're using IE). So even if a tag is unused now, in the time between UA 1 implementing the feature (and leading edge users using it) and UA 4 implementing the feature (and thus all users having it) there will be millions of crackpot authors who copy and paste content from good authors targetting UA1 and expose that content to UA4, thus creating a pile of "legacy" content ''after'' we define the syntax. (This has already happened with SVG and MathML in text/html, q.v. http://www.cocopahrv.com/map.html and http://www.laroseweb.com/calcs/fans.php .)

[[Category:Feature Request]]

Constraints for New Vocabularies

2008-12-01T11:37:20Z

Mabdul: adding Category:Feature Request

This page documents some of the constraints we have to work within when developing new syntax for HTML. It is primarily written in the context of MathML and SVG being added to text/html.

For a more detailed discussion, see the notes in:
* http://lists.w3.org/Archives/Public/www-svg/2008Apr/0028.html
* http://krijnhoetmer.nl/irc-logs/whatwg/20080417
* http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2008-April/014372.html

In summary, the constraints are that we must:
* Render the following in a way that is not significantly worse than today (extra whitespace is probably ok, most other things are probably not):
** http://www.cocopahrv.com/map.html
** http://www.laroseweb.com/calcs/fans.php
** http://puysl.com/view.htm
** http://albren.blogspot.com/2007/02/l05-traductor.html
* Render pages that today contain MathML in text/html better than today.
* Support MathML and SVG in the same way where possible.
* Fail gracefully in the face of ignorant author copy/paste (see below).

==Ignorant author copy/paste==
Authors have, for some reason I haven't understood but which I have seen a ''lot'' on the web, a weird way of working, which consists of, sometimes, copying seemingly random chunks of pages, and pasting them into their own. They will even copy stuff from pages where the stuff does something in one browser (e.g. Firefox when that page is sent as XML), and paste them into their page where it does nothing (e.g. they're using IE). So even if a tag is unused now, in the time between UA 1 implementing the feature (and leading edge users using it) and UA 4 implementing the feature (and thus all users having it) there will be millions of crackpot authors who copy and paste content from good authors targetting UA1 and expose that content to UA4, thus creating a pile of "legacy" content ''after'' we define the syntax. (This has already happened with SVG and MathML in text/html, q.v. http://www.cocopahrv.com/map.html and http://www.laroseweb.com/calcs/fans.php .)

[[Category:Feature Request]]

Layout tables

2008-12-01T11:36:06Z

Mabdul: adding critism

== Problem Description ==
A majority of HTML coders find the ease and simplicity of the table layout irrisistible, despite the fact that tables should only be used for tabular data.

CSS layouts are possible, however there are some things that are deterringly complicated to do with CSS layouts. Even among coders who validate their code and strive to meet the standards, table layouts are frequently resorted to because they offer the only solution.

== Solution ==
Create a new table type that is purely presentational. It has the ability to easily put expanding cells next to eachother and most of the other things that make tables so attractive.

However, it also has some unique features which make it purely presentational:

* Cells have the ability to break out of their rows under some circumstances.
** A table consisting of one row of four cells, when screenwidth is decreaced sufficiently, could become a single columned table with four rows of one cell each.
** Cells can also be marked as joined or linked, so that they do not break even when the width of the browser is decreased.
* Cells can be marked as presentational only: their contents would be completely removed or ignored in text only browsers or if styles are disabled.
* Browsers load the table one cell at a time, so that users do not have to wait for the last cell to load to see content in the first.
* Additional features inappropriate for tabular tables could be added.
** Improved cell spanning, similar to colspan or rowspan, allowing cells to span ''selectively'' creating non-rectangular shaped cells through designation to a common "span group".

== Critism ==
Many developers have the fear that there will be a reintroducing of the mixed up of the CSS and the HTML part.

An alternative is the[http://www.w3.org/TR/css3-layout CSS 3 Advanced Layout Module].

[[Category:Feature Request]]

Layout tables

2008-12-01T11:31:20Z

Mabdul: adding Category:Feature Request

Text in Canvas

2008-12-01T11:30:43Z

Mabdul: adding Category:Feature Request

Currently, the Canvas API does not include the ability to draw text strings. That makes several potential Canvas applications, such as dynamic graphs or maps, more complex than necessary. Instead of using the text facilities of the platform, Canvas applications need to bundle their own vector fonts or use inaccessible pre-rendered images for text display. Thus, using Canvas it is unattractive for authors and users are forced to use a proprietary plugin (Flash) for some applications.

== Use Case Description ==

* Maps (Street names, ...)
* All kinds of graphs needing labels
* Games (High score, "Game Over" etc)

=== Current Limitations ===
''Explanation of why the current markup is insufficient.''

Possible workarounds and the associated problems are described in great detail at http://canvaspaint.org/blog/2006/12/rendering-text/

Executive Summary:

* Images are large and do not scale
* Vector fonts are large, too

Moreover, the workarounds make accessibility more difficult, and authors need to worry about font copyright, normally addressed by the users operating system vendor

=== Current Usage and Workarounds ===

''Some evidence that this feature is desperately needed on the web. You may provide a separate examples page for listing these.''

* http://osteele.com/sources/javascript/docs/textcanvas
* http://canvaspaint.org/blog/2006/12/rendering-text/
* http://www.random.abrahamjoffe.com.au/public/JavaScripts/canvas/fontGenerator.htm
* http://minijoe.com/ota/emulator?sid=canvasoids
* http://minijoe.com/ota/emulator?sid=canvasout

=== Benefits ===

''Explanation of how and why new markup would be useful.''

The problems described in "Current Limitations" would disappear :)

=== Requests for this Feature ===

* http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2006-October/007363.html
* http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2006-June/006527.html

== Proposed Solutions ==

=== My Solution ===
:''Brief description of the solution and of how it address the problem at hand.''

see http://rhino-canvas.sourceforge.net/www/drawstring.html#api

==== Processing Model ====
:''Explanation of the changes introduced by this solution. It explains how the document is processed, and how errors are handled. This should be very clear, including things such as event timing if the solution involves events, how to create graphs representing the data in the case of semantic proposals, etc.''

==== Limitations ====
:''Cases not covered by this solution in relation to the problem description; other problems with this solution, if any.''

==== Implementation ====
:''Description of how and why browser vendors would take advantage of this feature.''

==== Adoption ====
:''Reasons why page authors would use this solution.''

[[Category:Feature Request]]

New Vocabularies

2008-12-01T11:28:05Z

Mabdul: adding Category:Feature Request

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.

== Specified ==

* '''Writing applications that contain graphics that represent custom data, while including that data for script manipulation.'''<br>Proposal: <code>data-<var>foo</var>=""</code> on any element; <code>element.dataset[<var>foo</var>]</code> for DOM access. ([[CustomData|Other ideas...]])<br>Priorities:
** Embedding custom non-visible data in an HTML document for scripting purposes ✓‬
** Forward compatible (so that future extensions don't introduce name clashes) ✓‬
** Ability to avoid ID clashes in multiple-document transclusion ✘

* '''Ability for an author to unilaterally extend the language to address problems we are currently unaware of and that therefore are not covered by existing functionality.'''<br>Proposal: <code>div</code> and <code>span</code> elements, <code>class</code> and <code>data-<var>foo</var>=""</code> on any element, along with JS, CSS, and, eventually, XBL2 ([[Extensions|Other ideas...]])<br>Priorities:
** Without trampling on the toes of others ✓‬
** Without being beholden to an external entity to provide the enhancements for the author on a timescale that is useful to the author ✓‬

See: http://www.whatwg.org/specs/web-apps/current-work/#embedding

* '''Putting an equation in a Web page.'''<br>Proposal: make <math> enter [[New Vocabularies Solution|a new insertion mode]] in which non-HTML elements end up in the MathML namespace ([[Equations in HTML|Other ideas...]])<br>Priorities:
** Maintainability ✘‬ ''(MathML is too verbose to solve this; making the syntax less verbose makes it even more complicated)''
** Searchability ✓
** Accessibility ✓
** Typographically-sound printing ✓
** Ease of authoring (are authors willing to learn new formats?) ✓✘ ''(Ok for MathML authors; not for LaTeX authors.)''
** Ease of import from existing documents ✓✘ ''(Ok for MathML source documents, not for LaTeX source documents.)''
** Ease of implementation (are UAs willing to implement new formats?) ✓✘ ''(Ok for Mozilla, but not for other vendors.)''
** Resistance to errors (e.g. not brittle in the face of syntax errors) ✓
** Numbering the equation ✓ ''(Using, e.g. the <code>title</code> attribute and CSS.)''

* '''Writing a document by hand, with inline diagrams imported from a graphics package.'''<br>Proposal: make <svg> enter [[New Vocabularies Solution|a new insertion mode]] in which non-HTML elements end up in the SVG namespace ([[Diagrams in HTML|Other ideas...]])<br>Priorities:
** Compatibility with existing graphics packages ✓✘ ''(if they support SVG export)''
** 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) ✓✘ ''(Somewhat, if authors are careful; tool support would make this possible easily.)''
** Ease of implementation (are UAs willing to implement new formats?) ✓
** Resistance to errors (e.g. not brittle in the face of syntax errors) ✓

* '''Writing a document by hand, with vector graphic icons.'''<br>Proposal: <code>img</code> elements with external SVG ([[Vector Icons|Other ideas...]])<br>Priorities:
** Maintainability ✓
** Good caching behaviour ✓

* '''Mixing vector graphics, mathematics, and other features.'''<br>Proposal: MathML, SVG, and HTML ([[Mixed namespaces|Other ideas...]])<br>Priorities:
** Diagrams that include typographically-correct mathematics ✓
** Formulae that include vector graphics ✓
** Formulae and diagrams that contain form controls ✓

* '''Writing highly interactive, graphically intensive sites.'''<br>Proposal: SVG, SVG's SMIL, and scripting ([[Interactive Sites|Other ideas...]])<br>Priorities:
** Searchability ✓
** Accessibility ✓

== Rejected requirements ==

* '''Animating Web page content (hypertext, vector graphics).'''<br>Proposal: Use the CSS animation proposal ([[Animation in HTML|Other ideas...]])<br>Priorities:
** Set or animate sizes, positions, opacities, colors, transforms (basically most attributes and properties) ✓
** Time-based triggering ✓ ''(using script to trigger changes)''
** Event-based triggering ✓ ''(using script to trigger changes)''
** Inlined (for simple web pages) and non-inlined animations (to promote separation of content and presentation) ✓
** Linear and spline interpolation ''(up to the CSS animation proposal's definition)''
** Syndication: animation shouldn't use scripts that can't be trusted by syndicators ✓✘ ''(Somewhat.)''
** Quality: animation should adapt to the frame rate capabilities of the device, not be forced to use a particular frame rate by a script ✓

* '''Migrating from LaTeX to HTML.'''<br>Proposal: a tool? ([[LaTeX to HTML|Other ideas...]])<br>Priorities:
** Fidelity ✓ ''(Depends mostly on the tool, assuming CSS, SVG, and MathML support everything LaTeX does.)''

* '''Including XBL2 inline in a text/html document the same way CSS and JS can be included inline.'''<br>Proposal: ? ([[XBL2 in HTML|Other ideas...]])<br>Priorities:
** Expressiveness (anything expressed in XBL2 as text/xml should be possible in text/html) ✘ ''(Could be revisited later.)''

==Areas for research==

* What is the most widely known way of authoring mathematics?
* What human-editable source language are equations mostly serialised in today?

==Supporting data==
* 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]

[[Category:Feature Request]]

Drag'n'Drop Uploads

2008-12-01T11:27:57Z

Mabdul: adding Category:Feature Request

=== The problem ===
Web applications cannot accept files from user's machine as easily and intuitively as native OS applications - users can't drop images from desktop right into documents edited in WYSIWYG editors, on-line file browsers, asset management interfaces of CMSes.

Although browsers could allow <input type=file> controls to accept dropped files, drop zone would have to be limited to small area occupied by the control. This is not how applications usually work - they don't have area exclusively for dropping files, but entire window or regular UI controls react to dropped files.

There's nothing inherently wrong with having <input type=file> with file browser, some users may even prefer this type of UI, but depending on type of application/user preference such UI may feel inefficient and unintuitive.

=== Use cases ===
* Dropping image from local machine (desktop, file explorer/finder window, another application) into WYSIWYG (contentEditable) editor to have image uploaded to server and inserted into edited document right under cursor - just like you can with office suites.
* Dropping image into textarea that uses BBcode or Wiki syntax to have image uploaded and appropriate image embedding syntax automatically inserted.
* Adding attachments in a webmail
* Web-based file browser/asset management interface
* Drag'n'drop customization of images in page templates, forum avatars, etc.

== Proposed solution ==

=== The basic concept ===

A universal IDREF attribute that would connect particular element in document (''drop zone'') with a <code><input type=file></code> control.

<input type=file id=''uploader''>
<div dropped-files=''uploader''>drop your files here!</div>

In the above example, files is dropped into <code><div></code> would be "redirected" to the <code><input></code> element. <code><input></code> can use <code>max</code> attribute to allow multiple files to be dropped at once.

Drop zone doesn't have to be <div>:

<textarea dropped-files=''uploader''>write post and drop images to have [img]url[/img] added automagically!</textarea>

Algorithm also allows dropping files directly into <code><input></code>, without requiring any additional code.

<input type=file title="drop files here!">

Drop zones can be nested (deepest-nested takes precedence). For ease of implementation and compatibility with HTML4 documents, <code><form></code> can act as a drop zone (with least precedence).

=== The process ===

==== Finding related <input type=file> ====

These steps are supposed to allow dropping files directly into <code><input></code>, or into a designated drop zone. As a fallback a <code><form></code> can be assumed to be a drop zone.

When user drops file(s) into the document:

# Take element on which file(s) were dropped (''drop target'') - usually it will be target of <code>mouseup</code> event.
# If the element is <code><input type=file></code> '''proceed to the next section.'''
# If the element does not have <code>dropped-files</code> attribute, check its parent. Continue checking ancestors until the attribute is found or there are no more parent elements.
# If element with <code>dropped-files</code> attribute was found:
## Find element referenced by <code>dropped-files</code> attribute
## Verify that referenced element it's an <code><input type=file></code>
## If above conditions are met '''proceed to the next section.'''
## Otherwise ignore dropped files or perform browser's default action and abort these steps.
# Start again from the ''drop target''
# If the element is not <code><form></code>, check its parent. Continue checking ancestors until <code><form></code> is found or there are no more parent elements.
# If <code><form></code> is found:
## Find first <code><input type=file></code> that belongs to that form
## If element can be found, '''proceed to the next section.'''
# Otherwise ignore dropped files or perform browser's default action.

(this algorithm can be optimized to walk up the DOM tree only once)

==== The next section ====

# Synchronously fire <code>filesdropped</code> event on ''drop target''
# If <code>filesdropped</code> event was cancelled, ignore dropped files and abort these steps.
# Set value of <code><input></code> just as if files were chosen using regular method (including setting multiple files if <code>max</code> attribute permits) and fire <code>change</code> event on <code><input></code>.

=== Security ===

Dropping is limited to one DOM tree (does not cross frames). Scripts still can't set value of <input type=file>.

The only new risk is that script may know exactly when user has chosen a file and may start uploading it immediately (IIRC currently major browsers don't trigger <code>change</code> event on file controls).

Browsers which used to open files dropped into document area will probably have to ask user for confirmation when first file is dropped to prevent websites from stealing files from users unaware of the new feature.

=== Open Issues ===

==== Filesdropped Event ====
* It should reference relevant <code><input></code>
* Provide some information about dropped file(s) (file name, mime type, size?)
* If possible, provide information about exact place where event occurred (using <code>Range</code> object for WYSIWYG?)

==== Other issues ====
* How would script mark areas where files can't be dropped (temporarily/conditionally) allowing browser to dynamically change cursor? Is script fiddling with CSS cursor property and canceling <code>filesdropped</code> event enough?
* Since the solution requires form and <code><input></code> element, backwards compatibility can be maintained. The problem is script may rely on files being set via drag'n'drop and may not act properly when user uses file control directly.
* Many elements could reference single <code><input></code>. Is this desirable? Disallowing that might help backwards compatibility (it would be more likely that authors prepare separate <form>s pre-filled with necessary data), OTOH it would be easier for authors to have single uploader for multiple items on the page.
* Would it be possible to have previews of images and documents available prior upload? Import into <code><canvas></code> without upload?
* Should the form be submitted asynchronously and automatically? It would allow browser to save user's time by uploading immediately and in the background. There would be possibility of uploading multiple files at the same time (alternatively they could be queued/batched).
* If upload is async, script would have to receive information from the server once upload finishes (WYSIWYG editors would need to put placeholder in the document while file uploads and replace it with the real thing afterwards). Currently it can be hacked via <code><from replace=values></code> and hidden input element or <code><from target=hidden_iframe></code> and cross-frame scripts.

== Related implementations ==

IE supports [http://msdn2.microsoft.com/en-us/library/ms537658.aspx dataTransfer] object which can be used for handling drag'n'drop and clipboard copying of text and URLs. This interface could be reused+extended for files.

[[Category:Feature Request]]

User talk:Hixie

2008-12-01T11:26:24Z

Mabdul: New section: rel="nofollow"

Feature Proposals

2008-12-01T11:20:24Z

Mabdul: adding Category:Feature Request Category:Feature Request

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 ==
* [[Image Caption]]
* [[Layout tables]]
* [[Drag'n'Drop Uploads]]
* [[New Vocabularies]], [[Constraints for New Vocabularies]]
* [[Generic Metadata Mechanisms]]

== 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)

[[Category:Feature Request]]

User talk:Hixie

2008-11-04T18:09:03Z

Mabdul: New section: Runescape

Talk:FAQ

2008-11-04T18:06:44Z

Mabdul: two comments

== QuoteFix does not work for me ==

Therefore, I tend to say
<pre>
I want cats now.

Ian wrote:
What do you want?
When do you want it?
</pre>
The idea is to make the information as self-contained as possible. This does not give you a hint why I wrote it in the first place but at least the text contains a statement that is valid in isolation.

I would also complain that I lose track of who wrote what in an [http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20081102/f6d60788/attachment.htm interleaved discussion] too often. Is it just me?
--[[User:Yecril71pl|Yecril71pl]] 19:33, 30 October 2008 (UTC)
:I get the same problem. One of my prof. answered a mail and didn't see what he wrote. really crazy because i read only the half :( that is really bad! --[[User:Mabdul|Mabdul]] 18:06, 4 November 2008 (UTC)

== nonlogo ==

Why did you choose such an uninformative logo? --[[User:Yecril71pl|Yecril71pl]] 09:02, 1 November 2008 (UTC)
:have you a better one? *g* --[[User:Mabdul|Mabdul]] 18:06, 4 November 2008 (UTC)

HTML5

2008-11-04T17:58:46Z

Mabdul: adding cat Web Applications 1.0

HTML has served the Web community well, but it lacks some basic semantics necessary for modern Web applications. HTML 5 attempts to rectify this, while at the same time updating the HTML specifications to address issues raised in the past few years.

==Status==
HTML 5 is still in the draft stage and is undergoing heavy development. Major changes in the specification can be expected.

==Extensions==
The "meta" element in HTML 5 has some [http://whatwg.org/specs/web-apps/current-work/#meta predefined name keywords], but it can also be extended to support others. Those names must be registered on the [[MetaExtensions]] wiki page.

The "class" attribute in HTML 5 has some [http://whatwg.org/specs/web-apps/current-work/#class predefined values], but it can also be extended to support other class names. Those values may be registered on the [[ClassExtensions]] wiki page, though registration is not necessary to use non-standard values.

The "rel" attribute in HTML 5 has some [http://whatwg.org/specs/web-apps/current-work/#linkTypes predefined values], but it can also be extended to support other values. Those values must be registered on the [[RelExtensions]] wiki page.

==Contributor Proposals==
* [[User:Matthew_Raymond:vcalendar_and_vcard_elements|<vcard>, <vcalendar>, <vevent> and <vattr> elements]] by [[User:Matthew_Raymond|Matthew Raymond]]

==External Links==
* [http://whatwg.org/specs/web-apps/current-work/ HTML 5]

[[Category:Web Applications 1.0]]

WA1:Focus

2008-11-04T17:58:39Z

Mabdul: adding cat Web Applications 1.0

This section provides additional support related element focus and the use of the tab key to change focus between elements.

==Contributor Proposals==
There are no proposals at this time.

==Related Pages==
* [[Web Applications 1.0]]

==External Links==
* [http://whatwg.org/specs/web-apps/current-work/#focus Web Applications 1.0 - Focus]

[[Category:Web Applications 1.0]]

WA1:Structured Data

2008-11-04T17:58:37Z

Mabdul: adding cat Web Applications 1.0

This section mainly covers proposals related to calendars and business cards.

==Contributor Proposals==
There are no proposals at this time.

==Related Pages==
* [[Web Applications 1.0]]

==External Links==
* [http://whatwg.org/specs/web-apps/current-work/#structured Web Applications 1.0 - Structured data]

[[Category:Web Applications 1.0]]

WC1:CSS3, Focus and Key Handling

2008-11-04T17:56:32Z

Mabdul: adding cat Web Controls 1.0

Quoting directly from the spec: "..."

==Contributor Proposals==
There are no proposals at this time.

==Related Pages==
* [[Web Controls 1.0]]

==External Links==
* [http://whatwg.org/specs/web-controls/current-work/#x Web Controls 1.0 - ... (CSS3, Focus and Key Handling)]

[[Category:Web Controls 1.0]]

WC1:DOM Interfaces

2008-11-04T17:56:28Z

Mabdul: adding cat Web Controls 1.0

This section deals with assorted DOM interfaces related to the user interface.

==Contributor Proposals==
There are no proposals at this time.

==Related Pages==
* [[Web Controls 1.0]]

==External Links==
* [http://whatwg.org/specs/web-controls/current-work/#dom-interfaces Web Controls 1.0 - DOM Interfaces]

[[Category:Web Controls 1.0]]

WC1:Properties for Selection, Focus, and Editing

2008-11-04T17:56:25Z

Mabdul: adding cat Web Controls 1.0

This section contains CSS properties control features that are directly related to the DOM.

==Contributor Proposals==
There are no proposals at this time.

==Related Pages==
* [[Web Controls 1.0]]

==External Links==
* [http://whatwg.org/specs/web-controls/current-work/#properties Web Controls 1.0 - Properties for selection, focus, and editing]

[[Category:Web Controls 1.0]]

WF2:Fetching Data from External Resources

2008-11-04T17:52:57Z

Mabdul: adding cat wf2

This section covers the use of external data sources to fill forms and form controls.

==Contributor Proposals==
There are no proposals at this time.

==Related Pages==
* [[Web Forms 2.0]]

==External Links==
* [http://whatwg.org/specs/web-forms/current-work/#fetching-data Web Forms 2.0 - Fetching data from external resources]

[[Category:Web Forms 2.0]]

Web Forms 2.0

2008-11-04T17:51:54Z

Mabdul:

Web Forms 2.0 is an extension to the forms features found in [http://www.w3.org/TR/html401 HTML 4.01]'s forms chapter. The specification applies to both HTML and XHTML user agents, and provides new strongly-typed input fields, new attributes for defining constraints, a repeating model for declarative repeating of form sections, new DOM interfaces, new DOM events for validation and dependency tracking, and XML submission and initialization of forms. This specification also standardises and codifies existing practice in areas that have not been previously documented.

[http://www.w3.org/TR/html4 HTML4], [http://www.w3.org/TR/xhtml11/ XHTML 1.1] and the [http://www.w3.org/DOM/ DOM] are thus extended in a manner which has a clear migration path from existing HTML forms, leveraging the knowledge authors have built up with their experience with HTML so far.

== Status ==

Web Forms 2.0 has reached a relative stage of maturity, and major alterations of the specification are unlikely at this stage.

In due course Web Forms 2.0 will be integrated into [[HTML 5]].

== Sections ==

* [[WF2:Extensions to Form Control Elements|Extensions to Form Control Elements]]
* [[WF2:The Repetition Model for Repeating Form Controls|The Repetition Model for Repeating Form Controls]]
* [[WF2:The Forms Event Model|The Forms Event Model]]
* [[WF2:Form Submission|Form Submission]]
* [[WF2:Fetching Data from External Resources|Fetching Data from External Resources]]
* [[WF2:Extensions to the HTML Level 2 DOM Interfaces|Extensions to the HTML Level 2 DOM Interfaces]]
* [[WF2:Styling Form Controls|Styling Form Controls]]

== External Links ==
* [http://whatwg.org/specs/web-forms/current-work/ Web Forms 2.0]

[[Category:Web Forms 2.0|*]]

WF2:Styling Form Controls

2008-11-04T17:51:29Z