OK, per Ian's suggestion I'm starting a new thread on a problem that I'd
hoped html5 would solve for us. As far as I know the problem still
exists so I'm going to raise it here. I'm coming late to the discussion
so will surely retread old territory (for example,
http://www.pacificspirit.com/blog/2008/03/13/namespaces_in_html_readings);
my apologies for that.
I am one of the PIs on the SIMILE project (http://simile.mit.edu/) that
developed the Exhibit data visualization framework
(http://simile-widgets.org/exhibit). The goal of Exhibit is to make it
easy for non-programmers to embed interactive data visualizations in
their web pages. Our approach is to leverage the willingness of many
non-programmers to author html (a key contributor to the early growth of
the web). To do so, Exhibit extends the html vocabulary with attributes
that describe data, visualizations of that data, and interactions with
that data. For example, a tag of the form <div ex:role="view"
ex:viewclass="timeline"> embeds a simile timeline in the html document,
while <div ex:role="facet"> embeds a facet that can be used to filter
the data being viewed in the timeline. Exhibit offers a javascript
library that interprets these tags and implements the requested widgets
on the client side.
You will note that our special attributes use an "ex:" prefix. This
decision was taken in 2006, when it appeared that prefix-based
namespaces were in HTML's future. It addressed our concern that the new
attributes we defined should not collide with those defined by other
projects. Now that namespaces apparently will not be part of html5, we
are wondering how we can properly offer our extended html vocabulary.
In particular, seems highly desirable for us to be able to write Exhibit
pages using html that will validate. Below I'll outline some of the
characteristics of our desired solution, while emphasizing that we'd be
happy to adopt _any_ solution with these characteristics, and are not
wedded to namespaces.
I first justify our approach of html vocabulary extension. A programmer
can argue that a better approach is to offer our javascript library with
a good api, and allow programmers to invoke our widgets programmatically
in script tags. This works fine for programmers, but excludes the large
population of users who are afraid of programming but are willing to
fiddle with html. These users were a potent force in the early days of
the web and we believe they continue to play an important role. They
may not even "know" html; the simplicity and regularity of the syntax
allows them to copy, paste, and even modify page elements they like
without fully understanding them. Specifying data interactions in the
more restricted html syntax instead of programmatic javascript also
opens up the possibility for more effective semantics; for example, it
is easier for a browser to offer an accessible version of a
data-filtering facet if it is explicitly named as a facet rather than
being arbitrary embedded javascript code.
If we accept the need for html language extensibility, there are several
potential approaches. One is html polyglot. Permitting a blended
html/xml representation, polyglot would allow us to extend the
vocabulary via xml namespaces. But polyglot fails to meet our need in
fatal ways. Polyglot restricts the html that can be used, for example
excluding the use of <noscript> tags. Such tags are essential when
using Exhibit, since we want to offer some information presentation for
the case when our visualization javascript is unable to execute. More
generally, polyglot appears to demand much more rigid fidelity to
precise html/xml syntax, for example demanding tbody and colgroup tags
where they are optional in html. This is something that the novice
"programmers" we are targeting are particularly bad at. One of the real
accomplishments of html has been the great efforts of the browser
developers to robustly handle invalid html. We want to continue to
benefit from that effort instead of having pages fail because xml
parsing is performed much more rigidly than html parsing.
Another approach would be to use the catchall html5 data- prefix for
attributes. We could certainly prefix all of our specialized attributes
with the data- prefix, which would turn those attributes valid for
html. This solution is unsatisfactory for two reasons. The first is
that our attributes are not data attributes----we are not using
microformat-oriented data attributes; rather, we are using attributes
that describe visualizations. data- seems a poor choice of prefix. The
second problem that concerns me is attribute collisions. If we use an
attribute like data-role="view", how long will it be before an exhibit
author runs into a situation where a different javascript library is
using the same data-role attribute for a different purpose, which would
make the two libraries incompatible with one another?
In 2006, the predicted namespace prefixes seemed an obvious solution to
our problem: we would define a namespace for our Exhibit framework, and
our javascript would only pay attention to attributes from that
namespace. I have no specific loyalty to namespaces, but I am really
hopeful that html5 will offer us a solution that reflects the issues I
outlined above, namely:
* allow extension of them html5 vocabulary with attributes Exhibit will
use to anchor visualizations,
* such that the resulting html will validate,
* without requiring rigid obedience to the challenging html polyglot
syntax, which is beyond the capabilities of our target novice web authors
* and protecting us from a future in which collisions on choice of
attribute names make our library/vocabulary incompatible with others'
On 7/18/2011 8:46 AM, Ian Hickson wrote:
On Mon, 18 Jul 2011, David Karger wrote:
I wish to submit a comment regarding the (non) use of namespaces in
html5. But I hope you might help me track down the relevant issue off
which to hang that comment. Some time ago I found a lengthy discussion
of whether html5 should use namespaces, with an over-simplified summary
being "we haven't seen any important use cases for them, so let's not
bother". I would like to respond to that discussion by proposing a use
case, but I cannot find it. Searching the bugzilla database has failed.
Would you happen to recall participating in this discussion and know
where it is?
You can just post a new thread here.
I recommend describing the problem you wish to address separately from
your preferred solution. Also I recommend using a word other than
"namespaces" to describe your preferred solution, as that word is usually
used in the Web context to refer to some specific designs with known
problems, and it is likely that you actually want something different.
