New Vocabularies

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

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

• Putting an equation in a Web page.
  Proposal: allow the 34 Presentational MathML 2.0 elements to be used in text/html by hard-coding those tag names in the parser, with end tags made optional where possible (Other ideas...)
  Priorities:
  • Maintainability ✓ (Somewhat: MathML is pretty verbose, but omitting end tags helps a lot; disallowing Content MathML helps too.)
  • Searchability ✓ (Somewhat: more complex maths might be better handled if Content MathML was available.)
  • 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: allow SVG in text/html by hard-coding a bunch of SVG element tag names and attributes in the parser (Other ideas...)
  Priorities:
  • Compatibility with existing graphics packages
  • 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)
  • 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
  • Event-based triggering
  • Inlined (for simple web pages) and non-inlined animations (to promote separation of content and presentation) ✓
  • Linear and spline interpolation
  • Syndication: animation shouldn't use scripts that can't be trusted by syndicators ✓
  • 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: ? (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)

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