Re: [Clipboard] Web API for clipboard changes.
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.g. in order to fetch and display them, to update context menus, or synchronize the content with another application or device. The problem is that the web standard currently provides no explicit notifications when new content is copied from another application to the clipboard. As a result, these web apps typically re-fetch the clipboard every time they regain focus, and only act on the contents if they have changed since last time (e.g. passing it to a remote system, updating context menu, etc). This polling mechanism is generally inefficient, especially when the clipboard contains a large image file. We currently have interest from Citrix and Chrome Remote Experience teams in improving Chrome's clipboard support. The proposal Google propose to update the W3C Clipboard API and events specification http://www.w3.org/TR/clipboard-apis/with an onClipboardChangedevent on the document object. The user agent should only signal the event if 1. a frame re-gains focus AND 2. the clipboard has changed since it last had focus. In addition, the user agent should not signal clipboard change events while a frame has focus. This will relieve the web app from the burden of filtering out notifications in response to clipboard changes generated by the app itself. We think this new API will avoid fetching large clipboard content repeatedly and unnecessarily for clipboard changes. Does the community think this API would be useful? Hallvord, All - do you have any feedback for Kevlin? We can go into more details and work on a detailed design together if the community is interested. Kelvin, if there is a resource that includes details, please let us know. (I suppose another option is a Pull Request but it might make sense to first wait for some feedback from the group.) -Thanks, ArtB
Re: [ime-api] [blink-dev] Removing IME API code from Blink
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 publish as Note the current approach and start a new spec? Perhaps it doesn't really matter as the above is a process question, and what is really needed is someone to start suggesting some concrete proposals here--I've been pretty much ignoring this spec for the past year, and I don't see that changing in the near future. It's still something I'd like to see moved forward, I just don't believe I have the time to move it substantially forward at the present moment :) Given this, it seems like the SoTD section should include some type of large-ish warning/note that include text along the lines of `no one is actively working on this spec nor its implementation` + `help wanted`. Also, if the spec's [Issues] and [Bugs] haven't properly captured the ClientRect exposure issue, perhaps one should be created (and/or the spec updated to reflect this). On the other hand, if you propose to formally stop work on the spec as it is now, then it would be appropriate to have a CfC to publish a WG Note (and if/when there is a firm commitment to do some type of followup work, a new spec can be created). WDYT? -Thanks, ArtB [Issues] https://github.com/w3c/ime-api/issues [Bugs] https://www.w3.org/Bugs/Public/buglist.cgi?component=IME%20APIlist_id=57282product=WebAppsWGresolution=--- -Original Message- From: Ryosuke Niwa [mailto:rn...@apple.com] Sent: Wednesday, May 27, 2015 7:00 PM To: Travis Leithead Cc: Arthur Barstow; public-webapps Subject: Re: [ime-api] [blink-dev] Removing IME API code from Blink On May 27, 2015, at 11:46 AM, Travis Leithead travis.leith...@microsoft.com wrote: I believed the use-cases for avoiding UI clashes between site-driven auto-complete lists and IME auto-complete boxes is still a valid use case, and I think the spec is still valid to try to push to recommendation. However, I'd also like to follow up on usage of the ms- prefixed API so that I can get an idea of what its real usage is. I agree avoiding UI clashes between auto-completions of IME and web page is a great use case but I'm not convinced that exposing ClientRect for IME is the right API as many Web developers aren't even aware of UI challenges IME imposes. For example, a similar UI challenge emerges when dealing with auto-corrections in grammar/spell checking features as well. It would be ideal if IME and spell/grammar corrections are handled in a similar manner so that Web apps supporting either feature will just work with both features. - R. Niwa
[Bug 28577] [XMLHttpRequest] Throwing SecurityError on open() call for some kind of simple errors
https://www.w3.org/Bugs/Public/show_bug.cgi?id=28577 Anne ann...@annevk.nl changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WORKSFORME -- You are receiving this mail because: You are on the CC list for the bug.
Re: Clipboard API: remove dangerous formats from mandatory data types
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 compromise the recipient is extremely limited by comparison to JPEG, PNG or GIF. The UA is still at liberty to synthesize these formats itself, based on the raw imagery provided by the content, to populate the clipboard with formats that other applications want. HTH, Wez On 10 June 2015 at 23:31, Hallvord Reiar Michaelsen Steen hst...@mozilla.com wrote: 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 - image/gif Hi Daniel, copying images to the clipboard is an important use case. Do you have any suggestions for how we could meet this use case in a safer way? For example, would it be safe and easy to add a little bit of magic to make clipboardData.items.add(canvasElement) put a PNG on the clipboard? Perhaps copying a rendered imgElement should work too? -Hallvord
Re: Clipboard API: remove dangerous formats from mandatory data types
What about JPEG 2000, Exif, TIFF, RIF, BMP, PM, PGM, PBM, PNM, HDR, EXR, BPG, psd, xcf, etc.?
Re: Clipboard API: remove dangerous formats from mandatory data types
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 applications that're not equipped to handle random assemblages of bytes, even though they are specifically written to handle random assemblages of bytes... There is empirical evidence that this is not true for many image decoders. On Thu, Jun 11, 2015 at 1:00 AM Florian Bösch pya...@gmail.com wrote: 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 as adobe, gimp etc.) will do something else: - The first 4 bytes of a PNG: \89PNG - Bytes 9 trough 13 of a JPEG: JFIF - etc. Every notable non text format in common use today contains magic headers that make it easy to identify what a file is without having the mimetype or file extension. Omission of metadata information is - not going to address your security concern since applications do routinely read in random bytes and figure out what they are - it's not going to make applications behave any more securely (or reliably) as it'll promote even more of them to resort to guessing because information is omitted The clipboard is a key-value store of flavors of data (in this case, MIME types) to their corresponding data. We're not omitting metadata; we'd block image/png written by web content from being mapped to its native clipboard flavor (ATOMs on Windows, UTI on OS X, MIME types on Linux). Apps don't read text data from the clipboard and then try to interpret it as a PNG, because no one ever tries writing a PNG into the text clipboard flavor: pasting in an app that wasn't expecting this (i.e. all of them) would result in a bunch of gibberish. On Thu, Jun 11, 2015 at 5:33 AM James M. Greene james.m.gre...@gmail.com wrote: 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 lightning fast sanity check for a subset of binary data types, I really don't believe this is a positive change. While we're on it, how about the good ole harbinger of the unknown: application/octet-stream? Where do we reasonably draw the line? Will that MIME type be blocked? Doesn't seem like there would be any reasonable way to scrub it. Sincerely, James M. Greene Well... sure, if you have a plugin, you can do anything. People (should) expect plugins to be able to run arbitrary code... because that's what they are. The point is we don't want pasting an image to be able to do anything to your system. People would be unpleasantly surprised if pasting an image results in arbitrary code execution. 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.
Re: Clipboard API: remove dangerous formats from mandatory data types
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 about raster image formats the browser doesn't happen to implement.
Re: Clipboard API: remove dangerous formats from mandatory data types
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 raw pixels from a canvas, for example, since scope for abusing that to compromise the recipient is extremely limited by comparison to JPEG, PNG or GIF. The UA is still at liberty to synthesize these formats itself, based on the raw imagery provided by the content, to populate the clipboard with formats that other applications want. I don't think the clipboard should forbid inserting image data, there's so many ways to compromise desktop software. ex. pasting text/html into Mail.app might even do it. This API shouldn't be trying to prevent that. - E
Re: Clipboard API: remove dangerous formats from mandatory data types
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.
Re: Clipboard API: remove dangerous formats from mandatory data types
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.
Re: Clipboard API: remove dangerous formats from mandatory data types
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 lightning fast sanity check for a subset of binary data types, I really don't believe this is a positive change. While we're on it, how about the good ole harbinger of the unknown: application/octet-stream? Where do we reasonably draw the line? Will that MIME type be blocked? Doesn't seem like there would be any reasonable way to scrub it. Sincerely, James M. Greene On Jun 11, 2015 3:14 AM, Florian Bösch pya...@gmail.com wrote: Oh, also while you're on crippling things, please also exclude copying any text that contains http://:; cause that borks skype.
Re: Writing spec algorithms in ES6?
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 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 wonder if it would be good the pseudo-code would actually be ES6, with comments where needed? 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 WDYT? I love the idea of specifying algorithms in something other than English. But I'm afraid that ECMAScript is not a good language for this purpose, for the same reasons Boris cites in his response (which arrived as I was typing this). - Adam -- erik
Re: Custom Elements: is=
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 is= is going to be dropped, we'll probably revert back to annotating these elements with special class names or data- attributes and avoid custom elements for these use cases. On Tue, Jun 9, 2015 at 9:05 AM, Alice Boxhall aboxh...@google.com wrote: On Tue, Jun 9, 2015 at 8:13 AM, Anne van Kesteren ann...@annevk.nl wrote: On Sun, May 10, 2015 at 12:34 AM, Alice Boxhall aboxh...@google.com wrote: - In the time between v1 and v2 (however long that ends up being) we are left without any way to solve this problem, assuming we don't come up with something else for v1. If developers start using custom elements where they would previously have used a native element, this could well result in a regression in accessibility for the web as a whole for this period, and we will be stuck with the legacy of code written during this period for much longer as well. I don't see how it is a regression compared to the current situation. Exactly: this describes the current situation, which I think is unsatisfactory. - I realise that to some extent developers already aren't using native elements, in part because of the styling issues we've discussed which also affect is=. My concern here is that custom elements will further legitimise this habit, which we've been making some recent progress in changing - we stand to backslide on that effort. Having is= would allow us to roll it into the use native elements where possible message rather than diluting it with unless you're using a custom element in which case here's a checklist which you're not going to look at of everything it should do until we come up with an alternative. Most examples of custom elements to date are not actually with is=, simply because custom tag names are much more appealing. The ergonomics don't back up the message. Polymer have a whole suite of elements which use is=: https://elements.polymer-project.org/browse?package=gold-elements When you refer to ergonomics, are you talking purely about the syntax? Or about the set of issues involved in using native elements compared to (lower case c) custom elements: essentially, whether or not you're ceding some control over styling and behaviour to the browser? - v1 sets the stage for people to develop habits and expectations about how custom elements work. New features tend to be slowly adopted, by both browser vendors and (partly as a consequence) developers, so even if we do come up with something for v2, it will be even longer before it becomes mainstream (and as I mentioned earlier we will still be stuck with code written to v1 for much longer again). I don't see how it will be longer. is= is not getting acceptance as-is. So all this would result in is not getting custom elements across browsers until v2 is done. I think Dimitri responded to this better than I could. Here's where we differ, because: - I don't think it's a wart. I've given this a great deal of thought and I keep ending up back at the current syntax when I try to think of reasonable alternatives, even assuming we could magically fix all the implementation issues with any alternative proposal. I think if we figured out how the behavior of current elements is composed and how to address the styling problem we'd be much closer to an agreement. And I think everyone agrees those need to be solved, so I'm a bit lost as to why we don't focus on those. I agree that those problems need to be solved (in particular, the styling issue also comes into play when using is=), but I think that these are multiple pieces of the same puzzle. The primitives are critical for creating novel types of elements, which won't be able to benefit from type extensions in any case. Styling is critical for getting people to use native elements with or without type extensions. Allowing developers to extend native types means that users benefit from not relying on custom element developers who just want to create a button with some fancy rendering (beyond what can be achieved using CSS alone), or custom behaviour, remembering to re-implement all of the accessibility affordances which are built in to an HTML button. It also means that developers benefit from not having to do the extra legwork for accessibility. We see time after time after time that accessibility is fighting an uphill battle because it isn't on developers' radars as a priority for v1. This causes constant regressions in functionality for people who rely on assistive technology. The promise of the HTML platform is that it should be accessible if we use the native elements as
Re: Writing spec algorithms in ES6?
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 pseudocode, and the Web components specs use their own flavor of prose-pseudo-code. I wonder if it would be good the pseudo-code would actually be ES6, with comments where needed? 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 WDYT? I love the idea of specifying algorithms in something other than English. But I'm afraid that ECMAScript is not a good language for this purpose, for the same reasons Boris cites in his response (which arrived as I was typing this). - Adam
RE: Writing spec algorithms in ES6?
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---whatever). However, it's susceptible to author code overriding Array.prototype.join. Similarly, [4] relies upon the author-modifiable Math.max and Math.min, not to mention the author-modifiable Math binding. I go into these issues in a bit more detail in [5], although that's from an implementation perspective. Regardless, it at least opens with another good example. If we wanted to make this feasible---and I think that would be a good thing---I think at a minimum we'd need: - JS bindings for all the ES abstract operations, so you could do e.g. max(...) or DefinePropertyOrThrow(...) instead of Math.max(...) and Object.defineProperty(...) - Some way of expressing private state in ES. (Maybe WeakMaps are sufficient, semantically, but syntactically they are awkward.) - Some kind of Record type, as well as some kind of List type, corresponding to those in the ES spec. Trying to use just objects or arrays will fail in the face of modifications to Object.prototype and Array.prototype. (Boris goes over this in [2]) It's a decent bit of work... [1]: https://esdiscuss.org/topic/for-of-loops-iteratorclose-and-the-rest-of-the-iterations-in-the-spec [2]: https://esdiscuss.org/topic/for-of-loops-iteratorclose-and-the-rest-of-the-iterations-in-the-spec#content-26 [3]: http://dev.w3.org/csswg/css-color/#dom-rgbcolor-stringifiers [4]: http://dev.w3.org/csswg/css-color/#dom-hslcolor-hslcolorrgb [5]: https://docs.google.com/document/d/1AT5-T0aHGp7Lt29vPWFr2-qG8r3l9CByyvKwEuA8Ec0/edit#heading=h.9yixony1a18r
Re: Writing spec algorithms in ES6?
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 type coercion in that pseudo code I think. On Thu, Jun 11, 2015 at 1:50 PM, Erik Arvidsson a...@google.com wrote: 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 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 wonder if it would be good the pseudo-code would actually be ES6, with comments where needed? 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 WDYT? I love the idea of specifying algorithms in something other than English. But I'm afraid that ECMAScript is not a good language for this purpose, for the same reasons Boris cites in his response (which arrived as I was typing this). - Adam -- erik
Writing spec algorithms in ES6?
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 wonder if it would be good the pseudo-code would actually be ES6, with comments where needed? 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 WDYT? :DG
Re: Writing spec algorithms in ES6?
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 guarantees (e.g. STL algorithms specifying runtime complexity) and error handling. When you just list code for what the function means, that leaves alternate implementations rather ambiguous as to what is a spec violation and what is not. For instance, stringifiers - what if an implementation rounds things to some finite precision rather than multiplying by 100 and spewing out some arbitrary length percentage? is this correct? Or do you have to just use the code in the spec as given? And if you use the code in the spec as given and everyone implements in exactly the same way, why not just publish a library for it and say to heck with the spec? IMHO, the imperative/algorithmic style is necessary to get you to the point where the guts of behavior can be completely described using preconditions/postconditions and abstract concepts, which is where the meat of the specification really should be. When we haven't been that precise, we have observable implementation differences. (Um, yeah, so I'd say that stringifier spec is imprecise and we'll have compat issues) I just did a rework of the IDB v2 editor's draft and probably 90% of the spec is basically an additional layer of bindings between WebIDL/ECMAScript and the the core concepts of the spec. That 90% was previously written as blocks of prose rather than imperative algorithms and behavior does differ among implementations. Fortunately, that mostly applies to edge cases (bad inputs, getters/setters). Maybe it's just IDB, but the remaining 10%of the spec is where all the fun implementation-specific optimizations happen and is 90% of the actual code, it's just short in the spec because it can be described in abstract terms. 2015-06-11 13:32 GMT-07:00 Dimitri Glazkov dglaz...@google.com: 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 wonder if it would be good the pseudo-code would actually be ES6, with comments where needed? 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 WDYT? :DG
Re: Writing spec algorithms in ES6?
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 is complete nonsense, depending on how literally you choose to read it). So there are basically at least two problems here: 1) You have to clearly delineate when you're working with JS values and when you're working with IDL values, to the extent that these are not the same thing. 2) You have to clearly delineate which bits of JS run in the page global and which bits run in some other clean global and which bits run in the page global but have access to some clean intrinsics somehow. I would actually prefer some sort of pseudocode that is _not_ JS-looking, just so people don't accidentally screw this up. -Boris
Re: Writing spec algorithms in ES6?
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. When you just list code for what the function means, that leaves alternate implementations rather ambiguous as to what is a spec violation and what is not. For instance, stringifiers - what if an implementation rounds things to some finite precision rather than multiplying by 100 and spewing out some arbitrary length percentage? is this correct? Or do you have to just use the code in the spec as given? And if you use the code in the spec as given and everyone implements in exactly the same way, why not just publish a library for it and say to heck with the spec? 2015-06-11 13:32 GMT-07:00 Dimitri Glazkov dglaz...@google.com: 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 wonder if it would be good the pseudo-code would actually be ES6, with comments where needed? 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 WDYT? :DG
Re: Writing spec algorithms in ES6?
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 in its arguments, which I think is nice (but does not fit with Web IDL---whatever). However, it's susceptible to author code overriding Array.prototype.join. Similarly, [4] relies upon the author-modifiable Math.max and Math.min, not to mention the author-modifiable Math binding. Yep. The correct way to use these is to normatively reference the Well-Known Intrinsic Objects Table[0] in ES2015, and cite any extensions. This is how Ecma 402 and the new SIMD spec ensure object integrity when referring to built-ins. Rick [0] https://people.mozilla.org/~jorendorff/es6-draft.html#sec-well-known-intrinsic-objects
Re: Writing spec algorithms in ES6?
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 code there produces semantics that don't match the IDL in this spec (or is complete nonsense, depending on how literally you choose to read it). Yes, the code currently there is... loose. There's a lot of problems trying to map IDL directly into ES without a lot of boilerplate. So there are basically at least two problems here: 1) You have to clearly delineate when you're working with JS values and when you're working with IDL values, to the extent that these are not the same thing. 2) You have to clearly delineate which bits of JS run in the page global and which bits run in some other clean global and which bits run in the page global but have access to some clean intrinsics somehow. I would actually prefer some sort of pseudocode that is _not_ JS-looking, just so people don't accidentally screw this up. I actually rather like using JS code for these; it's familiar and easy to read. But yeah, Domenic outlines some of the things we'd have to change before this was actually useful. I wrote Color the way I did because writing math in prose is *incredibly* awkward, but writing it in ES-ese is *even more incredibly awkward*. So for now, I opted for the insufficient third alternative of JS, if we handwave and pretend all the obvious problems don't occur. ~TJ
Re: Writing spec algorithms in ES6?
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 usually the algorithms in HTML and DOM specs are quite easy to follow. The issues in readability, IMO, come from using tons of (usually spec-internal) links in algorithms, but I don't know how to solve that issue. Perhaps some tool to actually inline the relevant text from the linked place to the algorithm definition - or at least have some option to do that. -Olli
Re: Clipboard API: remove dangerous formats from mandatory data types
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 they are specifically written to handle random assemblages of bytes... Wouldn't you have to remove ctrl+c, right-click - copy-image etc. from the UA as well?
Re: Clipboard API: remove dangerous formats from mandatory data types
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 - image/gif Hi Daniel, copying images to the clipboard is an important use case. Do you have any suggestions for how we could meet this use case in a safer way? For example, would it be safe and easy to add a little bit of magic to make clipboardData.items.add(canvasElement) put a PNG on the clipboard? Perhaps copying a rendered imgElement should work too? -Hallvord
Re: Clipboard API: remove dangerous formats from mandatory data types
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 as adobe, gimp etc.) will do something else: - The first 4 bytes of a PNG: \89PNG - Bytes 9 trough 13 of a JPEG: JFIF - etc. Every notable non text format in common use today contains magic headers that make it easy to identify what a file is without having the mimetype or file extension. Omission of metadata information is - not going to address your security concern since applications do routinely read in random bytes and figure out what they are - it's not going to make applications behave any more securely (or reliably) as it'll promote even more of them to resort to guessing because information is omitted
Re: Clipboard API: remove dangerous formats from mandatory data types
Oh, also while you're on crippling things, please also exclude copying any text that contains http://:; cause that borks skype.
