A user account is required in order to edit this wiki, but we've had to disable public user registrations due to spam.

To request an account, ask an autoconfirmed user on Chat (such as one of these permanent autoconfirmed members).

Feature Proposals: Difference between revisions

From WHATWG Wiki
Jump to navigation Jump to search
(Added Guidelines)
Line 3: Line 3:
== Guidelines ==
== Guidelines ==


Before proposing a feature, there are a number of questions you should try to answer.
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.


* What is the [[Problem Solving|problem you are trying to solve]]?
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.
* What is the feature you are suggesting to help solve it?
* What is the processing model for that feature, including error handling? This should be very clear, including things such as event timing if the feature involves events, how to create graphs representing the data in the case of semantic proposals, etc.
* Why do you think browsers would implement this feature?
* Why do you think authors would use this feature?
* What evidence is there that this feature is desparately needed?
 
If you want to add a feature request, you should probably start by coping the [[Problem Solving]] template page on a new page and fill as much information as you can.


== Document Markup ==
== Document Markup ==

Revision as of 06:16, 17 November 2006

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

DOM Scripting

Security

Other

This list of features needs to be sorted out. They've come from all the feedback provided on blogs over the past few weeks.

  • Don’t render quotation marks around q elements.
  • Make form validation easier
    • required attribute
    • maxlength attribute for textarea
    • pattern attribute
    • min
    • max
  • New Form Controls
    • Search fields
    • Combo boxes
    • Date/Time
    • E-mail
    • Int
    • Long
    • Unsigned
    • Float
    • Number
    • Currency
    • URL
  • WYSIWIG Editor (contentEditable)
  • Placeholder attribute
  • Captions for images
  • Bring back the start and value attributes for ordered lists.
  • Bring back the menu element
  • Require XHTML-link syntax for HTML
  • Caption/label/list header for lists
  • Include the role attribute.
  • Allow href 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).”
  • <blink>!!!
  • Fix the object element.
  • Unify img, object, embed and iframe into a single element
  • Headers and footers
  • A mechanism to include content from an external source (e.g. <include>, perhaps like XInclude)
  • A <corner> element (presumably for making rounded corners)
  • Markup for advertisements
  • Easier column layouts
  • A <foot> 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 keygen element)