Re: [whatwg] namespaces in html5
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-seriesDate/th
th data-graphs-series-kind=y logDate/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 attributeswe 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
Re: [whatwg] namespaces in html5
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-seriesDate/th
th data-graphs-series-kind=y logDate/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 usemeta to include page-wide information. You can link to other
resources usinglink rel ora 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 attributeswe 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
Re: [whatwg] namespaces in html5
On Fri, 20 Jan 2012, David Karger wrote: 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. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] namespaces in html5
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 attributeswe 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?
Re: [whatwg] namespaces in html5
On Mon, 18 Jul 2011 16:22:42 +0200, David Karger kar...@mit.edu wrote: 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 attributeswe 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? You could use data-exhibit-* as the specification suggests. Potentially including the ability for the web author to override the exhibit constant. -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] namespaces in html5
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) 2. there's no way to guarantee someone else won't use the same data-exhibit prefix, causing incompatibilities (functionality; major) On Monday, July 18, 2011 5:28:44 PM, Anne van Kesteren wrote: On Mon, 18 Jul 2011 16:22:42 +0200, David Karger kar...@mit.edu wrote: 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 attributeswe 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 concer ns 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? You could use data-exhibit-* as the specification suggests. Potentially including the ability for the web author to override the exhibit constant.
Re: [whatwg] namespaces in html5
On Mon, 18 Jul 2011 16:33:47 +0200, David Karger kar...@mit.edu 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) It is custom data implemented by a JavaScript library. Seems like a perfect fit. 2. there's no way to guarantee someone else won't use the same data-exhibit prefix, causing incompatibilities (functionality; major) exhibit plus the ability for authors to configure that word should be enough to prevent problems. But I doubt you will get prefix clashes in practice. -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] namespaces in html5
On Mon, Jul 18, 2011 at 7:33 AM, David Karger kar...@mit.edu 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) 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. 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. 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. ~TJ
Re: [whatwg] namespaces in html5
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. 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. On 7/18/2011 8:53 PM, Tab Atkins Jr. wrote: On Mon, Jul 18, 2011 at 7:33 AM, David Kargerkar...@mit.edu 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) 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. 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. 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. ~TJ
Re: [whatwg] namespaces in html5
On Mon, Jul 18, 2011 at 10:33 AM, David Karger kar...@mit.edu 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) It's data in the sense that it's being used to just store some info in the DOM without asking the browser to do anything extra with it. 2. there's no way to guarantee someone else won't use the same data-exhibit prefix, causing incompatibilities (functionality; major) There's also no way to guarantee someone else won't use the same URL for their namespace. But in either case, they almost certainly won't. If you're really paranoid, feel free to stick a GUID or domain name or something inside the names of all your data attributes. But the probability data-exhibit-* will ever collide with anything is already negligible. On Mon, Jul 18, 2011 at 2:23 PM, David Karger kar...@mit.edu wrote: 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. 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. I don't get how you're using these attributes. Do you expect browsers, search engines, or other consumers of HTML to treat them differently from any unrecognized attribute? Or do you intend that the attributes only be used by the scripts/stylesheets/etc. provided by your own site? If your use-case is the former, then you should propose the attributes for standardization. If the latter, it's exactly what data-* was designed for.
Re: [whatwg] namespaces in html5
On Mon, Jul 18, 2011 at 11:23 AM, David Karger kar...@mit.edu wrote: 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. As far as I can tell, the exhibit attributes are designed solely to be read by the exhibit JS library which creates special views of the data. The site embeds that library, and so it's part of the site. The restrictions there are meant to restrict things like, for example, embedding Microformats data with data-* attributes, with the intention that they'll be read by spiders and other things outside of the page author's control. ~TJ
[whatwg] namespaces in html5
Dear whatwg, 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? thanks David Karger
Re: [whatwg] namespaces in html5
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. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
