New Vocabularies

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

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 ✓

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