New Vocabularies

This page summarises the problems discussed in the e-mails that ended up in the html-parsing-rules-namespaces-discussion folder. See New Vocabularies Solution for notes on the solution being developed.

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

WIP

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

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

• Writing highly interactive, graphically intensive sites.
  Proposal: SVG, SVG's SMIL, and scripting (Other ideas...)
  Priorities:
  • Searchability ✓
  • Accessibility ✓

Rejected requirements

• 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

• Animation is a desired capability for web authors of Rich Internet Applications. Of the top Ajax Javascript toolkits listed on Wikipedia, all support some level of animation, each in a different, and possibly incompatible, way:
  • Backbase
  • dojo
  • ext
  • jQuery
  • Mootools
  • prototype (weak)
  • script.aculo.us
  • YUI