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 MathML in text/html by hard-coding a bunch of MathML element tag names in the parser (Other ideas...)
Priorities:
- 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.
Proposal: a tool? (Other ideas...)
Priorities:
- Fidelity

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

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