New Vocabularies

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

Requirements met

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

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)