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
[whatwg] inconsistent canvas implementations of destination-in compositing
Firefox and chrome inconsistently handle destination-in compositing; I suspect this may be due to a missing specification in the standard. The inconsistency happens when I use the drawImage method to draw one canvas onto another while the globalCompositionOperation is set to destination-in . Under destination in, pixels in the destination canvas should be left alone where the source canvas has a set pixel and cleared where the source canvas has a cleared/transparent pixel. Both browsers do this properly inside the range of the source canvas. But if the source canvas has smaller dimensions than the destination canvas, they inconsistently handle parts of the destination canvas _outside_ the source canvas: firefox clears those pixels while chrome leaves them alone. I believe the standard isn't clear on what should happen in this case. I'd say that firefox's behavior is more consistent with the intent of destination-in, but obviously cross-platform consistency is the most important consideration. I enclose a small html document demonstrating the inconsistency. Just open it in firefox and chrome.
Re: [whatwg] creating a new file via the File API
Hi, What you're doing is certainly connected, but I don't think it solves the problem I outlined. Your approach allows specification of the download target as an attribute in html. That's useful, but what's still missing, and I consider important, is a way to connect the html document to the Save As dialog available on all OSes. input tags lead browsers to launch the Open File dialog, which lets the user naturally navigate their file system to select a file to open. Browsers also launch the analogous Save As dialog, but _only_ when you execute a download from a server. I think it's important to enter the same Save As dialog programmatically, for client-side generated content. I don't think this raises the security issues discussed at mozilla, because the user is engaged in the same interaction as they are on any other file download. On 12/18/2011 11:13 PM, Bronislav Klučka wrote: Hi, This is quite crucial functionality and sadly not being addressed as it would seem, because without it application cannot really be applications (all you can do is to prepare data, upload those data to server and let user download it manually by clicking somewhere, which is annoying, unnecessary, and quite frankly stupid) . but there is a way howto allow user to save file from javascript without flash http://www.webnt.cz/demos/034_a_download/ this demo (the generated files) allows you to download/drag'ndrop generated file using JS (no flash) it's working in Chrome only at this point FF team is having some security issues I've been discussing with them https://bugzilla.mozilla.org/show_bug.cgi?id=676619 B. On 16.12.2011 0:58, David Karger wrote: It isn't clear to me that a tag question can be addressed by an api answer. Even if there is an api for saving to file, isn't there value to being able to declare your intentions through a tag? The input type=file tag specifies that a user will be able to interact to specify a file through a dialog. There's absolutely no commitment that that file will actually be uploaded or input. That's up to the form or the javascript that handles the input. It seems entirely consistent to be able to permit specification of a brand new file in that dialog that input type=file is already creating. What some javascript _does_ with the specified file might need to be implemented using a filesaver api, but that's separate from the declaration of an interaction for specifying the file. On 12/15/2011 6:45 PM, whatwg-requ...@lists.whatwg.org wrote: On Mon, 15 Aug 2011, David Karger wrote: / // Apologies if I'm revisiting old territory. I've been doing work on pure // html/javascript applications that work entirely clientside // (http://projects.csail.mit.edu/exhibit/Dido). For persistence, they // read and write local files. There's already aninput type=file // interface for letting the user specify a file to be read. And I can use // the same interface, inappropriately, to let the user overwrite a // preexisting file. But things get much messier if I want to let the user // specify a _new_ file to be written, because the file-open dialog doesn't // offer users a way to specify a new filename. What I'd like to be able // to do is specify a tag, or a invoke some javascript method, that will // produce the save file dialog typical of most systems, with a graphical // directory browser but including the option to specify a new filename. // This problem isn't unique to me; a discussion on stackoverflow appears // at // http://stackoverflow.com/questions/2897619/using-html5-javascript-to-generate-and-save-a-file // where the proposed solution is to use flash---and that would be an // unfortunate loss of html5 purity. They also suggest the hack of using a // data: url but that has size limitations. // // Perhapsinput type=file could be given an attribute specifying // whether a new filename is permitted? / On Wed, 7 Sep 2011, Eric U wrote: / // This sounds like a job for the FileSaver interface. Currently no // browser implements it, but we at Chrome have been considering it. At // TPAC last year we discussed it a bit in the WebApps WG meeting; IIRC we // talked about letting it take a URL instead of or in addition to just a // Blob, for more general utility. // // I suggest you bring it up on public-webapps@, where that spec lives. // http://dev.w3.org/2009/dap/file-system/file-writer.html#idl-def-FileSaver / I agree that an API like FileSaver is the right way to do this. Using input type=file wouldn't really fit well because that's more for providing data for upload than providing a file for writing.
Re: [whatwg] creating a new file via the File API
When I run your example in chrome, all those links automatically download the file to the specified filename in my default download directory---none launch the file save dialog. Of course that's because of how my chrome defaults are set. And indeed I can right click and file-save-as. But it's going to be a problem if I want to put a save as button on the page---having that result in download to a default directory because that's how chrome defaults are set isn't going to be the right behavior from the user's perspective. Should there be a way to force open the save dialog, even if the default is to download to a fixed location? On 12/19/2011 12:35 AM, Bronislav Klučka wrote: hi, if you look at the generated files examples, what you can see there (again, only in chrome) is that 1/ I have some data in JS 2/ I create blobbuilder - blob - url to that blob 3/ I create a element with URL to that blob and download attribute 4/ I initiate click on that link programmaticaly the result is is that Save file dialog is opened and when save/ok button is hit, the blob data is stored in user selected file. Yes, I'm using download attribute, but URL is JS blob (local data). I do not see problem here. What are you missing? And yes, I also do not see security issues here, nothing user cannot do today with regular download or programmer by uploading data to server and then download them... B. On 19.12.2011 6:26, David Karger wrote: Hi, What you're doing is certainly connected, but I don't think it solves the problem I outlined. Your approach allows specification of the download target as an attribute in html. That's useful, but what's still missing, and I consider important, is a way to connect the html document to the Save As dialog available on all OSes. input tags lead browsers to launch the Open File dialog, which lets the user naturally navigate their file system to select a file to open. Browsers also launch the analogous Save As dialog, but _only_ when you execute a download from a server. I think it's important to enter the same Save As dialog programmatically, for client-side generated content. I don't think this raises the security issues discussed at mozilla, because the user is engaged in the same interaction as they are on any other file download. On 12/18/2011 11:13 PM, Bronislav Klučka wrote: Hi, This is quite crucial functionality and sadly not being addressed as it would seem, because without it application cannot really be applications (all you can do is to prepare data, upload those data to server and let user download it manually by clicking somewhere, which is annoying, unnecessary, and quite frankly stupid) . but there is a way howto allow user to save file from javascript without flash http://www.webnt.cz/demos/034_a_download/ this demo (the generated files) allows you to download/drag'ndrop generated file using JS (no flash) it's working in Chrome only at this point FF team is having some security issues I've been discussing with them https://bugzilla.mozilla.org/show_bug.cgi?id=676619 B. On 16.12.2011 0:58, David Karger wrote: It isn't clear to me that a tag question can be addressed by an api answer. Even if there is an api for saving to file, isn't there value to being able to declare your intentions through a tag? The input type=file tag specifies that a user will be able to interact to specify a file through a dialog. There's absolutely no commitment that that file will actually be uploaded or input. That's up to the form or the javascript that handles the input. It seems entirely consistent to be able to permit specification of a brand new file in that dialog that input type=file is already creating. What some javascript _does_ with the specified file might need to be implemented using a filesaver api, but that's separate from the declaration of an interaction for specifying the file. On 12/15/2011 6:45 PM, whatwg-requ...@lists.whatwg.org wrote: On Mon, 15 Aug 2011, David Karger wrote: / // Apologies if I'm revisiting old territory. I've been doing work on pure // html/javascript applications that work entirely clientside // (http://projects.csail.mit.edu/exhibit/Dido). For persistence, they // read and write local files. There's already aninput type=file // interface for letting the user specify a file to be read. And I can use // the same interface, inappropriately, to let the user overwrite a // preexisting file. But things get much messier if I want to let the user // specify a _new_ file to be written, because the file-open dialog doesn't // offer users a way to specify a new filename. What I'd like to be able // to do is specify a tag, or a invoke some javascript method, that will // produce the save file dialog typical of most systems, with a graphical // directory browser but including the option to specify a new filename. // This problem isn't unique
Re: [whatwg] creating a new file via the File API
It isn't clear to me that a tag question can be addressed by an api answer. Even if there is an api for saving to file, isn't there value to being able to declare your intentions through a tag? The input type=file tag specifies that a user will be able to interact to specify a file through a dialog. There's absolutely no commitment that that file will actually be uploaded or input. That's up to the form or the javascript that handles the input. It seems entirely consistent to be able to permit specification of a brand new file in that dialog that input type=file is already creating. What some javascript _does_ with the specified file might need to be implemented using a filesaver api, but that's separate from the declaration of an interaction for specifying the file. On 12/15/2011 6:45 PM, whatwg-requ...@lists.whatwg.org wrote: On Mon, 15 Aug 2011, David Karger wrote: / // Apologies if I'm revisiting old territory. I've been doing work on pure // html/javascript applications that work entirely clientside // (http://projects.csail.mit.edu/exhibit/Dido). For persistence, they // read and write local files. There's already aninput type=file // interface for letting the user specify a file to be read. And I can use // the same interface, inappropriately, to let the user overwrite a // preexisting file. But things get much messier if I want to let the user // specify a _new_ file to be written, because the file-open dialog doesn't // offer users a way to specify a new filename. What I'd like to be able // to do is specify a tag, or a invoke some javascript method, that will // produce the save file dialog typical of most systems, with a graphical // directory browser but including the option to specify a new filename. // This problem isn't unique to me; a discussion on stackoverflow appears // at // http://stackoverflow.com/questions/2897619/using-html5-javascript-to-generate-and-save-a-file // where the proposed solution is to use flash---and that would be an // unfortunate loss of html5 purity. They also suggest the hack of using a // data: url but that has size limitations. // // Perhapsinput type=file could be given an attribute specifying // whether a new filename is permitted? / On Wed, 7 Sep 2011, Eric U wrote: / // This sounds like a job for the FileSaver interface. Currently no // browser implements it, but we at Chrome have been considering it. At // TPAC last year we discussed it a bit in the WebApps WG meeting; IIRC we // talked about letting it take a URL instead of or in addition to just a // Blob, for more general utility. // // I suggest you bring it up on public-webapps@, where that spec lives. // http://dev.w3.org/2009/dap/file-system/file-writer.html#idl-def-FileSaver / I agree that an API like FileSaver is the right way to do this. Using input type=file wouldn't really fit well because that's more for providing data for upload than providing a file for writing. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
[whatwg] microdata: itemprop in col tag
One natural way to represent a collection of structured items is in an html table. this can coexist with microdata, by using tr itemscope and td itemprop tags. But by ignoring the structure of the table, this creates a lot of redundant attribute specification. It would yield cleaner markup if it were possible to use col itemprop=foo to indicate an item property that should be inherited by all cells in the given column. In other words, to assert that any td associated with a col should inherit the itemprop associated with that col . It would yield even cleaner markup if there were a way to indicate that every tr was a distinct itemscope (the common case). For example, to use table itemtype=bar to indicate that each row of the table scopes an item of type bar.Or perhaps table itemscope could be interpreted as asserting a distinct itemscope for each row without specifying a type. But even using just the col inheritance rule, while still placing itemscope in tr tags, would save a quadratic quantity of markup.
Re: [whatwg] namespaces in html5
? 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.
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
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
[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
