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
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"
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,
s 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 is
log that
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
One natural way to represent a collection of structured items is in an
html table. this can coexist with microdata, by using
and 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 u
but that has size limitations.
Perhaps could be given an attribute specifying
whether a new filename is permitted?
-David Karger
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 Karger wrote:
Yes, we could, but it doesn't address the two objections I raised to data-
ng 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 wrote:
Another approach would be to use the catchall html5 data- prefix for
attributes. We could certainly prefix all of our specialized
attr
ies 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 re
sion and know
where it is?
thanks
David Karger
11 matches
Mail list logo
