Hello,
I'm investigating how to actually allow user to copy image data from web
application. I have encountered broken links in the specification:
http://dev.w3.org/2006/webapi/clipops/clipops.html#h2_apis-from-other-
specifications
Click setData and you'll be radirected on page that doesn't
Yves,
At TPAC, I mentioned wanting to help move along WebIDL v1 to REC. Can you
enumerate the next steps, and where I might be able to help? Thanks!
-Travis
On Mon, Dec 1, 2014 at 12:57 PM, Travis Leithead
travis.leith...@microsoft.com wrote:
At TPAC, I mentioned wanting to help move along WebIDL v1 to REC. Can you
enumerate the next steps, and where I might be able to help? Thanks!
Is there any actual value in doing this, since v2 has many
On Sun, Nov 30, 2014 at 4:28 AM, Jakub Mareda jmar...@seznam.cz wrote:
Hello,
I'm investigating how to actually allow user to copy image data from web
application. I have encountered broken links in the specification:
I believe so; this will give many specs a baseline WebIDL document to point to
in their references at the very least. Many specs don't rely on the more
advanced feature set being defined in WebIDL Second Edition.
However, let's not hijack this thread; I'd love to hear what the next steps are
Hello.
Thank you for your help. However the new spec you linked me to does not
contain anything I didn't know regarding my problem:
I'd quote the explanation of .setData
(https://html.spec.whatwg.org/#dom-datatransfer-setdata)
and whose data is the string given by the method's second
On 11/18/2014 03:18 PM, Sam Ruby wrote:
Meanwhile, I'm working to integrate the following first into the WHATWG
version of the spec, and then through the WebApps process:
http://intertwingly.net/projects/pegurl/url.html
Integration is proceeding, current results can be seen here:
On 12/1/14, 1:49 PM, Travis Leithead wrote:
I believe so; this will give many specs a baseline WebIDL document to point to
in their references at the very least. Many specs don't rely on the more
advanced feature set being defined in WebIDL Second Edition.
Here's the problem.
As of today,
Just in case I haven't formally said this elsewhere:
My personal feeling is that it's probably better to stay away from
speccing the behavior of file:// URLs.
There's very little incentive for browsers to align on how to handle
file:// handling. The complexities of different file system
What we really need to do is get some popular library or website to take a
dependency on mobile Chrome or mobile Safari's file URL parsing. *Then* we'd
get interoperability, and quite quickly I'd imagine.
From: Jonas Sickingmailto:jo...@sicking.cc
Sent:
On Mon, Dec 1, 2014 at 7:11 PM, Domenic Denicola d...@domenic.me wrote:
What we really need to do is get some popular library or website to take a
dependency on mobile Chrome or mobile Safari's file URL parsing. *Then* we'd
get interoperability, and quite quickly I'd imagine.
To my knowledge,
On Mon, Dec 1, 2014 at 7:58 PM, Sam Ruby ru...@intertwingly.net wrote:
On 12/01/2014 10:22 PM, Jonas Sicking wrote:
On Mon, Dec 1, 2014 at 7:11 PM, Domenic Denicola d...@domenic.me wrote:
What we really need to do is get some popular library or website to take
a
dependency on mobile Chrome
12 matches
Mail list logo
