Re: [whatwg] namespaces in html5
Ian Hickson
>
> [...] 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.
HTML has a number of features intended for such things. The class
attribute, for example, could be used to flag a table as something that
should get a graph:
<table class="graph-me">...</table>
Specific annotations for the graphing script can be included in data-*=""
attributes; for example, this:
<table class="graph-me" data-graphs-type="xy">
<thead>
<th data-graphs-series-kind="x time-series">Date</th>
<th data-graphs-series-kind="y log">Date</th>
...might be how you mark up the top of a table that's going to be drawn as
an X-Y plot with a time-based x axis and a logarithmic y axis.
You can use <meta> to include page-wide information. You can link to other
resources using <link rel> or <a rel>. You can embed raw data using
<script type>, for example, assuming the type was registered:
<script type="text/graph-data">
{ type: 'xy', x: 'time-series', y: 'log',
data: [...] }
</script>
If the data structure is more like nested name-value lists than tabular,
you could use microdata to mark it up, with the script then using the
microdata DOM API to present the data.
In short, there are a huge number of ways to approach this.
We are also working on further options. The component work in the Web Apps
working group is developing mechanisms for encapsulating widget
definitions, so that your script could bind directly to the data in the
page. This same work will likely involve introducing author-extensible CSS
properties for styling purposes, as well.
> 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.
Treat the five characters "data-" as an opaque string. data-* attributes
are for use by scripts for any purposes that the script wants.
Personally I would recommend against putting presentational information in
the markup -- whether you use XML namespaces, data-* attributes, or
non-conforming attributes of your own invention. The right place for
styling information is CSS. On the long run, as mentioned above, I expect
we'll provide explicit hooks in CSS for authors to put custom style
information for this purpose (the equivalent of data-* attributes but for
properties). Unfortunately we're not there yet.
> 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?
Just use the format data-exhibit-foo="".
> 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'
That's what data-library-name="value" attributes are for. They exactly fit
the described requirements.
On Mon, 18 Jul 2011, Anne van Kesteren wrote:
>
> You could use data-exhibit-* as the specification suggests. Potentially
> including the ability for the web author to override the "exhibit"
> constant.
Indeed. That's exactly what data-*="" is for: passing data to a script
library.
On Mon, 18 Jul 2011, David Karger wrote:
>
> Yes, we could, but it doesn't address the two objections I raised to data-
> prefix:
> 1. it isn't actually a data attribute, so prefixing with data seems odd
> (appearance; minor)
This is a non-issue. The attributes could be called carrot-*="" or
socialism-*="" or presentation-*="", what matters is what their definition
says, not what they are called. (Most users of HTML don't speak English as
their first language...)
> 2. there's no way to guarantee someone else won't use the same
> data-exhibit prefix, causing incompatibilities (functionality; major)
This is, in practice, a trivial problem. It turns out that there are
relatively few libraries, and so the odds of two libraries picking the
same short string library name and then being used by the same person is
very low. (It's about the same risk as two people picking the same library
name. Does the lack of namespacing for library names cause you a problem?)
On Mon, 18 Jul 2011, Tab Atkins Jr. wrote:
>
> You seem to have mentally associated the data-* attributes with
> Microdata. There is no connection between them. In fact, it's
> impossible for Microdata to use the data-* attributes at all.
Indeed.
> data-* attributes are for private script data that is, for whatever
> reason, more convenient to attach directly to a DOM node than to hold in
> a JS structure. Wanting the data's link to DOM nodes to survive
> serialization is a good reason.
Indeed.
> > 2. there's no way to guarantee someone else won't use the same
> > data-exhibit prefix, causing incompatibilities (functionality; major)
>
> In practice, the risk of prefix collisions has turned out to be minimal
> in many real-world collections, such as jQuery plugins. We expect the
> same to apply here. For maximum robustness, simply write your library
> with the ability to accept a different prefix, so that if a collision
> does occur the author can work around it.
Indeed.
On Mon, 18 Jul 2011, David Karger wrote:
> The html5 spec states that
> >
> > Custom data attributes
> > <http://dev.w3.org/html5/spec/elements.html#custom-data-attribute> are
> > intended to store custom data private to the page or application, for
> > which there are no more appropriate attributes or elements.
> >
> > These attributes are not intended for use by software that is
> > independent of the site that uses the attributes.
> >
> and further
> >
> > It would be inappropriate, however, for the user to use _generic
> > software not associated with_ that music site to search for tracks of
> > a certain length by looking at this data.
> >
> > This is because these attributes are intended for use by the site's
> > own scripts, and are not a generic extension mechanism for
> > publicly-usable metadata.
>
> As I interpret these words, data- attributes are intended to be
> delivered by a server for use by the javascript code that server
> delivers with the page.
Right.
> The exhibit attributes are not associated with any server, and are not
> associated with any particular data items being delivered by any server.
> Rather, they are part of "generic software not associated with" the
> server (see quote above) and handle _presentation_ of the content on
> the page.
>
> So, while it might be technically valid to use data- prefixes, it
> doesn't seem to fit the intention.
Is the exhibit JavaScript library not being delivered with the page?
--
Ian Hickson U+1047E )\._.,--....,'``. fL
http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
David Karger
On 01/20/2012 02:24 PM, Ian Hickson wrote:
Thanks for taking the time to look at this.
> On Mon, 18 Jul 2011, David Karger wrote:
>> [...] 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.
> HTML has a number of features intended for such things. The class
> attribute, for example, could be used to flag a table as something that
> should get a graph:
>
> <table class="graph-me">...</table>
>
> Specific annotations for the graphing script can be included in data-*=""
> attributes; for example, this:
>
> <table class="graph-me" data-graphs-type="xy">
> <thead>
> <th data-graphs-series-kind="x time-series">Date</th>
> <th data-graphs-series-kind="y log">Date</th>
>
> ...might be how you mark up the top of a table that's going to be drawn as
> an X-Y plot with a time-based x axis and a logarithmic y axis.
yes, this is exactly how we do it, currently using an ex: prefix on the
attributes to make sure we don't collide with anything else
>
> You can use<meta> to include page-wide information. You can link to other
> resources using<link rel> or<a rel>. You can embed raw data using
> <script type>, for example, assuming the type was registered:
>
> <script type="text/graph-data">
> { type: 'xy', x: 'time-series', y: 'log',
> data: [...] }
> </script>
>
> If the data structure is more like nested name-value lists than tabular,
> you could use microdata to mark it up, with the script then using the
> microdata DOM API to present the data.
again, this is in fact what we do (both link and embed methods). but
these aren't the parts that we are struggling to address properly via html5
>
> In short, there are a huge number of ways to approach this.
>
> We are also working on further options. The component work in the Web Apps
> working group is developing mechanisms for encapsulating widget
> definitions, so that your script could bind directly to the data in the
> page. This same work will likely involve introducing author-extensible CSS
> properties for styling purposes, as well.
>
>
>> 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.
> Treat the five characters "data-" as an opaque string. data-* attributes
> are for use by scripts for any purposes that the script wants.
Perhaps this is hair-splitting, but I agree completely if we are talking
about a script running and, for example, binding temporary data to a
particular node.
However, in our use case, it is in a sense "coincidence" that our tags
are being examined by a script. The _purpose_ of our tags is to provide
the same kind of semantic structuring as <img> or <author> or <navbar>
tags: specifying that certain elements, such as a map or a facet, should
appear on the page. It is conceivable that there might be several
different scripts, and perhaps some native extensions, that are all able
to interpret these tags and do something useful with them on the page.
>
> Personally I would recommend against putting presentational information in
> the markup -- whether you use XML namespaces, data-* attributes, or
> non-conforming attributes of your own invention. The right place for
> styling information is CSS. On the long run, as mentioned above, I expect
> we'll provide explicit hooks in CSS for authors to put custom style
> information for this purpose (the equivalent of data-* attributes but for
> properties). Unfortunately we're not there yet.
I don't think of <map> as presentational information, any more than I
think of <img>. I agree that certain _attributes_ of the map, such as
marker colors, should ultimately be put in css.
>
>
>> 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?
> Just use the format data-exhibit-foo="".
Yes, and what happens when someone else decides that exhibit is a neat
name and they want to use it too? This is the biggest problem I see.
I'd be happy to use any technical solution, and find it worrisome that
instead the spec is relying on a "good behavior" solution.
I could hack it myself, by putting a namespace argument to the script
<script src="script.js?namespace=exhibit"> that would tell the script to
look for tags prefixed with the given namespace. That way someone
encountering a collision could change the namespace. But it seems a
horrible hack to implement this script by script.
>
>
>> 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'
> That's what data-library-name="value" attributes are for. They exactly fit
> the described requirements.
I agree that they technically solve the first three, although I'm
skeptical that was the original intent (if the data- prefix just means
"anything we want to add outside the html spec" then why not just allow
any tag, without a prefix, which accomplishes the same thing?). I
disagree about bullet 4; I don't think relying on people to politely
avoid choosing the same library name is an effective long-term solution.
>
>
> On Mon, 18 Jul 2011, Anne van Kesteren wrote:
>> You could use data-exhibit-* as the specification suggests. Potentially
>> including the ability for the web author to override the "exhibit"
>> constant.
> Indeed. That's exactly what data-*="" is for: passing data to a script
> library.
>
>
> On Mon, 18 Jul 2011, David Karger wrote:
>> Yes, we could, but it doesn't address the two objections I raised to data-
>> prefix:
>> 1. it isn't actually a data attribute, so prefixing with data seems odd
>> (appearance; minor)
> This is a non-issue. The attributes could be called carrot-*="" or
> socialism-*="" or presentation-*="", what matters is what their definition
> says, not what they are called. (Most users of HTML don't speak English as
> their first language...)
If that's the case, why have a prefix at all? Just allow arbitrary
tags. Or maybe the prefix should just be "-"
Ian Hickson
>
> However, in our use case, it is in a sense "coincidence" that our tags
> are being examined by a script. The _purpose_ of our tags is to provide
> the same kind of semantic structuring as <img> or <author> or <navbar>
> tags: specifying that certain elements, such as a map or a facet, should
> appear on the page. It is conceivable that there might be several
> different scripts, and perhaps some native extensions, that are all able
> to interpret these tags and do something useful with them on the page.
Ah, ok. What you're doing then is simply creating a new language. Write a
spec, and within your community that spec will define what is valid.
> > Just use the format data-exhibit-foo="".
>
> Yes, and what happens when someone else decides that exhibit is a neat
> name and they want to use it too? This is the biggest problem I see.
That's an academic problem. It doesn't happen often enough in practice to
worry about.
> I agree that they technically solve the first three, although I'm
> skeptical that was the original intent (if the data- prefix just means
> "anything we want to add outside the html spec" then why not just allow
> any tag, without a prefix, which accomplishes the same thing?).
Because then it would limit the space within which the language itself can
be extended in the future.