On Thu, Jun 11, 2015 at 10:41 PM, Boris Zbarsky 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 code th
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 usuall
On Thu, Jun 11, 2015 at 1:45 PM, Ian Fette (イアンフェッティ)
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 guarantees (e
On Thu, Jun 11, 2015 at 4:53 PM Domenic Denicola 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 in its argu
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
On Thu, Jun 11, 2015 at 1:41 PM, Boris Zbarsky 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 code the
Dare I say ecma-speak?
(Maybe I got stockholm-syndrome?)
On Thu, Jun 11, 2015 at 4:47 PM, Adam Klein wrote:
> On Thu, Jun 11, 2015 at 1:32 PM, Dimitri Glazkov
> wrote:
>>
>> Folks,
>>
>> Many specs nowadays opt for a more imperative method of expressing
>> normative requirements, and using algo
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 IDL---wh
On Thu, Jun 11, 2015 at 1:32 PM, Dimitri Glazkov
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
> pseudocode, and t
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. W
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 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 i
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 10:51 AM, Wez 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
> raw pixels f
On Thu, Jun 11, 2015 at 8:32 PM, Daniel Cheng wrote:
>
> On Thu, Jun 11, 2015 at 11:13 AM Florian Bösch 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 about raster image formats
On Thu, Jun 11, 2015 at 12:53 AM Florian Bösch 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
> applications that're
What about JPEG 2000, Exif, TIFF, RIF, BMP, PM, PGM, PBM, PNM, HDR, EXR,
BPG, psd, xcf, etc.?
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 to
https://www.w3.org/Bugs/Public/show_bug.cgi?id=28577
Anne changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
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 lightn
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, e
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 p
Oh, also while you're on crippling things, please also exclude copying any
text that contains "http://:"; cause that borks skype.
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 a
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
27 matches
Mail list logo