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

New Vocabularies: Difference between revisions

From WHATWG Wiki
Jump to navigation Jump to search
No edit summary
 
(30 intermediate revisions by 2 users not shown)
Line 1: Line 1:
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.
This page summarises the ''problems'' discussed in the e-mails that ended up in the [http://www.whatwg.org/issues/#html-parsing-rules-namespaces-discussion html-parsing-rules-namespaces-discussion] folder.


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


* '''Migrating from LaTeX to HTML.'''<br>Priorities:
* '''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:
** Fidelity
** 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 ✘


* '''Writing a document by hand, with inline diagrams imported from a graphics package.'''<br>Priorities:
* '''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:
** Compatibility with existing graphics packages
** Without trampling on the toes of others ✓‬
** Scriptable (retained-mode, with DOM support, without requiring cross-frame scripting)
** Without being beholden to an external entity to provide the enhancements for the author on a timescale that is useful to the author ✓‬
** Round-tripping (the ability to take image fragments from a Web page and edit them)
** 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>Priorities:
See: http://www.whatwg.org/specs/web-apps/current-work/#embedding
** Maintainability
** Good caching behaviour


* '''Mixing vector graphics, mathematics, and other features.'''<br>Priorities:
* '''Putting an equation in a Web page.'''<br>Proposal: make &lt;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:
** Diagrams that include typographically-correct mathematics
** Maintainability ✘‬ ''(MathML is too verbose to solve this; making the syntax less verbose makes it even more complicated)''
** Formulae that include vector graphics
** Searchability ✓
** Formulae and diagrams that contain form controls
** 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.)''


* '''Animating Web page content (hypertext, vector graphics) without using script.'''<br>Priorities:
* '''Writing a document by hand, with inline diagrams imported from a graphics package.'''<br>Proposal: make &lt;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:
** Set or animate sizes, positions, opacities, colors, transforms (basically most attributes and properties)
** Compatibility with existing graphics packages ✓✘ ''(if they support SVG export)''
** Time-based triggering, event-based triggering
** Scriptable (retained-mode, with DOM support, without requiring cross-frame scripting) ✓
** Inlined (for simple web pages) and non-inlined animations (to promote separation of content and presentation)
** 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.)''
** Linear and spline interpolation
** Ease of implementation (are UAs willing to implement new formats?)
** Resistance to errors (e.g. not brittle in the face of syntax errors) ✓


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


* '''Writing applications that contain graphics that represent custom data, while including that data for script manipulation.'''<br>Priorities:
* '''Mixing vector graphics, mathematics, and other features.'''<br>Proposal: MathML, SVG, and HTML ([[Mixed namespaces|Other ideas...]])<br>Priorities:
** Embedding custom non-visible data in an HTML document for scripting purposes
** Diagrams that include typographically-correct mathematics ✓
** Ability to avoid ID clashes in multiple-document transclution
** Formulae that include vector graphics ✓
** Forward compatible (so that future extensions don't introduce name clashes)
** Formulae and diagrams that contain form controls ✓


* '''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>Priorities:
* '''Writing highly interactive, graphically intensive sites.'''<br>Proposal: SVG, SVG's SMIL, and scripting ([[Interactive Sites|Other ideas...]])<br>Priorities:
** Without trampling on the toes of others
** Searchability ✓
** Without being beholden to an external entity to provide the enhancements for the author on a timescale that is useful to the author
** 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==
==Areas for research==
Line 64: Line 77:
** [http://wiki.script.aculo.us/scriptaculous/show/VisualEffects script.aculo.us]
** [http://wiki.script.aculo.us/scriptaculous/show/VisualEffects script.aculo.us]
** [http://developer.yahoo.com/yui/animation/ YUI]
** [http://developer.yahoo.com/yui/animation/ YUI]
[[Category:Proposals]]

Latest revision as of 12:12, 26 January 2011

This page summarises the problems discussed in the e-mails that ended up in the html-parsing-rules-namespaces-discussion folder.

Specified

  • Writing applications that contain graphics that represent custom data, while including that data for script manipulation.
    Proposal: data-foo="" on any element; element.dataset[foo] for DOM access. (Other ideas...)
    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.
    Proposal: div and span elements, class and data-foo="" on any element, along with JS, CSS, and, eventually, XBL2 (Other ideas...)
    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.
    Proposal: make <math> enter a new insertion mode in which non-HTML elements end up in the MathML namespace (Other ideas...)
    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 title attribute and CSS.)
  • Writing a document by hand, with inline diagrams imported from a graphics package.
    Proposal: make <svg> enter a new insertion mode in which non-HTML elements end up in the SVG namespace (Other ideas...)
    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.
    Proposal: img elements with external SVG (Other ideas...)
    Priorities:
    • Maintainability ✓
    • Good caching behaviour ✓
  • Mixing vector graphics, mathematics, and other features.
    Proposal: MathML, SVG, and HTML (Other ideas...)
    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.
    Proposal: SVG, SVG's SMIL, and scripting (Other ideas...)
    Priorities:
    • Searchability ✓
    • Accessibility ✓

Rejected requirements

  • Animating Web page content (hypertext, vector graphics).
    Proposal: Use the CSS animation proposal (Other ideas...)
    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.
    Proposal: a tool? (Other ideas...)
    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.
    Proposal: ? (Other ideas...)
    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