On 6/2/15 4:05 PM, Kelvin Poon wrote:
Hi public-webapps
We are exploring a new web API for content to be notified of clipboard
changes and would like to discuss it here.
The problem
For certain classes of web apps, it is necessary to determine when new
clipboard contents have been set,
On 5/28/15 2:04 PM, Travis Leithead wrote:
That sounds good to me (working the UI challenges for IME together with
grammar/spell checking). Is this a direction the current IME spec could
take--possibly with a big refactor to consider dropping the ClientRect
exposure--or would it be better to
https://www.w3.org/Bugs/Public/show_bug.cgi?id=28577
Anne ann...@annevk.nl changed:
What|Removed |Added
Status|NEW |RESOLVED
Hallvord,
The proposal isn't to remove support for copying/pasting images, but to
restrict web content from placing compressed image data in one of these
formats on the clipboard directly - there's no issue with content pasting
raw pixels from a canvas, for example, since scope for abusing that
What about JPEG 2000, Exif, TIFF, RIF, BMP, PM, PGM, PBM, PNM, HDR, EXR,
BPG, psd, xcf, etc.?
On Thu, Jun 11, 2015 at 12:53 AM Florian Bösch pya...@gmail.com wrote:
Wait, why are you talking about removing an ostensibly useful feature
(declaring a mimetype in a paste for certain mime types) because the end
result could land up in the users paste, where it could be pasted into
On Thu, Jun 11, 2015 at 8:32 PM, Daniel Cheng dch...@google.com wrote:
On Thu, Jun 11, 2015 at 11:13 AM Florian Bösch pya...@gmail.com wrote:
What about JPEG 2000, Exif, TIFF, RIF, BMP, PM, PGM, PBM, PNM, HDR, EXR,
BPG, psd, xcf, etc.?
I'm not sure what you're trying to say here.
What
On Thu, Jun 11, 2015 at 10:51 AM, Wez w...@google.com wrote:
Hallvord,
The proposal isn't to remove support for copying/pasting images, but to
restrict web content from placing compressed image data in one of these
formats on the clipboard directly - there's no issue with content pasting
Besides, if html clipboards will be crippled beyond usability by security
paranoia, you'll just use good'ol flash to copy your random bytes to the
clipboard again.
If you can't put an image/png into a clipboard from JS, you just put it
into an application/octet-stream, which many image editors will load just
happily. If that doesn't work, you just stick your PNG into a plain/text,
which many image editors will still load just fine.
I can make a plugins for legitimate text/image editors that would override
default behavior for paste operations to instead execute arbitrary
processes (e.g. recursively delete the entire working directory) unless the
parent application is well sandboxed.
Unless the vendors that establish a
Dare I say ecma-speak?
(Maybe I got stockholm-syndrome?)
On Thu, Jun 11, 2015 at 4:47 PM, Adam Klein ad...@chromium.org wrote:
On Thu, Jun 11, 2015 at 1:32 PM, Dimitri Glazkov dglaz...@google.com
wrote:
Folks,
Many specs nowadays opt for a more imperative method of expressing
normative
GitHub has been using tag extensions in a few places for progressive
enhancement. Form and button elements have been the most useful things
to extend the behavior of. is= syntax aside, I do agree extending
complex native element prototypes in general has alot of associated
undefined behavior. If
On Thu, Jun 11, 2015 at 1:32 PM, Dimitri Glazkov dglaz...@google.com
wrote:
Folks,
Many specs nowadays opt for a more imperative method of expressing
normative requirements, and using algorithms. For example, both HTML and
DOM spec do the run following steps list that looks a lot like
Some previous discussion: [1] especiallly [2]
In general I think this is a reasonable thing, but it requires a decent bit
more infrastructure to do things “safely”. For example, consider the definition
[3]. It's generic in its arguments, which I think is nice (but does not fit
with Web
I've seen this in some specs, and I found the JS code quite difficult to
understand. There's so much subtle behavior you can do, and it's easy to be
too fancy.
In the example in the color spec, why does undefined become 0 but not null?
Also the properties are actually doubles so there's missing
Folks,
Many specs nowadays opt for a more imperative method of expressing
normative requirements, and using algorithms. For example, both HTML and
DOM spec do the run following steps list that looks a lot like
pseudocode, and the Web components specs use their own flavor of
prose-pseudo-code.
I
On Thu, Jun 11, 2015 at 1:45 PM, Ian Fette (イアンフェッティ) ife...@google.com
wrote:
To be honest this always drove me nuts when we were trying to do
WebSockets. Having code is great for conformance tests, but a spec IMO
should do a good job of setting out preconditions, postconditions,
performance
On 6/11/15 4:32 PM, Dimitri Glazkov wrote:
I noticed that the CSS Color Module Level 4 actually does this, and it
seems pretty nice:
http://dev.w3.org/csswg/css-color/#dom-rgbcolor-rgbcolorcolor
I should note that the ES code there produces semantics that don't match
the IDL in this spec (or
To be honest this always drove me nuts when we were trying to do
WebSockets. Having code is great for conformance tests, but a spec IMO
should do a good job of setting out preconditions, postconditions,
performance guarantees (e.g. STL algorithms specifying runtime complexity)
and error handling.
On Thu, Jun 11, 2015 at 4:53 PM Domenic Denicola d...@domenic.me wrote:
Some previous discussion: [1] especiallly [2]
In general I think this is a reasonable thing, but it requires a decent
bit more infrastructure to do things “safely”. For example, consider the
definition [3]. It's generic
On Thu, Jun 11, 2015 at 1:41 PM, Boris Zbarsky bzbar...@mit.edu wrote:
On 6/11/15 4:32 PM, Dimitri Glazkov wrote:
I noticed that the CSS Color Module Level 4 actually does this, and it
seems pretty nice:
http://dev.w3.org/csswg/css-color/#dom-rgbcolor-rgbcolorcolor
I should note that the ES
On 06/11/2015 11:41 PM, Boris Zbarsky wrote:
I would actually prefer some sort of pseudocode that is _not_ JS-looking, just
so people don't accidentally screw this up.
This one please - otherwise it would be way too easy to think the algorithm
would run in the context of the page.
But
Wait, why are you talking about removing an ostensibly useful feature
(declaring a mimetype in a paste for certain mime types) because the end
result could land up in the users paste, where it could be pasted into
applications that're not equipped to handle random assemblages of bytes,
even though
On Tue, Jun 9, 2015 at 8:39 PM, Daniel Cheng dch...@google.com wrote:
Currently, the Clipboard API [1] mandates support for a number of formats.
Unfortunately, we do not believe it is possible to safely support writing a
number of formats to the clipboard:
- image/png
- image/jpg, image/jpeg
On a further note. If UAs (which are among the more prevalent applications
out there being used) intentionally disable declaring mime-types for some
classes of content, so that it can't be pasted into applications that might
not be equipped to handle those mimetypes, application programmers (such
Oh, also while you're on crippling things, please also exclude copying any
text that contains http://:; cause that borks skype.
27 matches
Mail list logo
