Re: [whatwg] Sandboxed IFrames and downloads.
Ping. Is this a terrible idea? :) -- Mike West mk...@google.com, Developer Advocate Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany Google+: https://mkw.st/+, Twitter: @mikewest, Cell: +49 162 10 255 91 On Sat, Feb 2, 2013 at 7:11 PM, Mike West mk...@google.com wrote: It's currently possible to force a download by serving a file with a Content-Disposition: attachment; filename=... header. Notably, this mechanism can be used to download a file with minimal user interaction by including the resource to be downloaded in an IFrame. This holds even for sandboxed IFrames, as demonstrated by http://lcamtuf.coredump.cx/sandboxed.html (clicking that link will download a file, fair warning). It seems consistent with the general thought behind the `sandbox` attribute that it should control downloads as well as the bits it already locks down. I'd propose adjusting the spec to include a sandboxed downloads flag, which, when present, would block all downloads from inside the frame (or, perhaps only require user confirmation?). This restriction could be lifted via an 'allow-downloads' keyword, if present in the sandbox attribute's token list. WDYT? -- Mike West mk...@google.com, Developer Advocate Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany Google+: https://mkw.st/+, Twitter: @mikewest, Cell: +49 162 10 255 91
Re: [whatwg] inputmode feedback
Hello Mounir, On Thu, Feb 14, 2013 at 4:29 AM, Mounir Lamouri mou...@lamouri.fr wrote: Regarding the three Japanese specific types, it is not clear if inputmode is the best way to solve the use cases intended to be solved. Actually, 'kana' and 'katakana' are trying to give a hint about the script that has to be used which seems to be orthogonal with the other types. We could allow inputmode to have a set of values but that would make the behaviour way more complex so I wonder if we couldn't try to solve that problem with another attribute like inputscript. three Japanese specific types? 'kana', 'katakana', and 'full-width-latin? I agree that it is weird 'kana' and 'katakana' are listed as inputmode attribute, and 'inputscript' sounds more reasonable place where they should be listed. As you probably know, there is also 'ime-mode' CSS style which IE/FF implements (and still proposed in CSS3 UI at http://www.w3.org/TR/css3-ui/#ime-mode), which makes this more complex to use. People may want to control IME input mode like the way Flash can, http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/flash/system/IME.html but it it is unfortunate that controlling IME from web apps is so distributed (CSS, input attribute, DOM lv3 compositionevent and IME API). That said, even though authors of web apps may want to force the IME mode or its script mode for user's sake, it may cause user's confusion as they are so accustomed to change mode manually where such mode is required. So if a web app sets some mode, the user may toggle it back to unintended mode and get frustrated. -- Takayoshi Kochi
Re: [whatwg] inputmode feedback
On Wed, Feb 13, 2013 at 11:29 AM, Mounir Lamouri mou...@lamouri.fr wrote: Hi, Mozilla did implement an inputmode attribute for the input element a few months ago and the HTML specification has been updated after that to introduce that attribute. Given that the specification and our implementation was not matching, we decided to delay the release of that feature [1] and not advertise it. We unfortunately had to push a x-inputmode attribute in Firefox OS because our UI needed that feature but we expect to replace this with a proper inputmode implementation as soon as possible. Basically, the Mozilla's inputmode attribute is describing behaviour, the allowed value are mostly self-explanatory: auto, uppercase, lowercase, titlecase, autocapitalized, digit and numeric. What's the difference between auto and autocapitalized? To conclude, Mozilla is interested in implementing this set of keywords: verbatim, text, name, prose and digit (or numeric). I have to say, these feel a lot less understandable than the types currently implemented in x-inputmode. Using semantic names might give us the warm fuzzies, but is there really any semantic use we will get out of these that we wouldn't by using lowercase, titlecase or autocapitalized? I take it verbatim and name would disable any spelling corrections, and name would also titlecase? But the difference between text and prose seems really hard to understand. I can't even understand the actual behavioral difference (which is what authors actually care about) reading the spec, much less guessing by the name. / Jonas
Re: [whatwg] Assigning media resources represented as DOM objects to a media element
On Thu, Jan 24, 2013 at 2:49 AM, Robert O'Callahan rob...@ocallahan.org wrote: On Thu, Jan 24, 2013 at 9:44 PM, Anne van Kesteren ann...@annevk.nl wrote: On Wed, Jan 23, 2013 at 4:19 AM, Robert O'Callahan rob...@ocallahan.org wrote: I think this would be a worthwhile addition to the Web platform. It's somewhat ironic this happened, especially with Mozilla leading! I advocated this approach from the start: http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/1515.html http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/1576.html Heh. I apologize on Jonas' behalf :-). I don't think that I've argued against it. What I've argued against is having this be the *only* way to read out of a blob and into things that traditionally use URLs. I.e. I've just been arguing that we need createObjectURL as well. Also, for what it's worth, I'm holding out hope that we can change createObjectURL to be autorevoking by default. That's what the latest drafts are saying and no implementation has objected, despite repeated pokings. / Jonas
Re: [whatwg] Assigning media resources represented as DOM objects to a media element
On Fri, Feb 15, 2013 at 2:43 AM, Robert O'Callahan rob...@ocallahan.org wrote: On Fri, Feb 15, 2013 at 10:50 PM, Jonas Sicking jo...@sicking.cc wrote: Also, for what it's worth, I'm holding out hope that we can change createObjectURL to be autorevoking by default. That's what the latest drafts are saying and no implementation has objected, despite repeated pokings. Has any implementation actually taken the plunge? It's a fairly recent change to the spec, so no. I think we should give it a try in Firefox. / Jonas
Re: [whatwg] Enabling LCD Text and antialiasing in canvas
On Thu, Feb 14, 2013 at 10:21 PM, Robert O'Callahan rob...@ocallahan.orgwrote: On Thu, Feb 14, 2013 at 11:59 PM, Stephen White senorbla...@chromium.orgwrote: I think this is difficult to do in the general case, such as putImageData() or drawImage() or patterns, since you would need to examine all the pixels of the source image to determine if they contain non-1 alpha. This would be cost-prohibitive. If it's just for the purposes of optimization, you could be conservative and simply clear the flag when there's the potential for (but not certainty of) non-1 alpha. But if you're also using that flag to allow subpixel AA, the behaviour becomes quite unpredictable for the web developer and hard to spec crisply. What if we just said a) non-over operators clear the subpixel AA flag b) putImageData clears the subpixel AA flag Both of these are infrequently used AFAIK. Authors could work around most cases of b) by doing putImageData to another canvas and compositing it into the destination with 'over'. Even with these constraints, I don't think we can guarantee that it's safe to use LCD AA text. Once you've drawn with LCD AA text, even if it's safe at the time of drawing, there's no guarantee that it will be safe later. For instance, if you then drawImage() that canvas rotated into another canvas, or even just full-page-zoom it, you'll see colour fringing. Or apply CSS 2D or 3D transforms. There are also existing apps which use canvas for 2D text glyphs, and then transform and place them rotated in WebGL. Those will show colour fringing. Even within canvas, there may be a way to break it if the LCD AA text is drawn first and a dest-alpha compositing mode is used overtop (I haven't verified this though). So I'm starting to think that LCD AA text really has to be opt-in, to avoid breaking existing content. By opting it, you're agreeing that these artifacts are acceptable for your app. For example, you know that even if you're going to do a canvas-to-canvas draw, you're always going to draw at 1:1 scale and no rotation. Stephen How bad would that be? Would it help if we added an attribute to the canvas to let authors detect whether the subpixel AA flag is set? Rob -- Wrfhf pnyyrq gurz gbtrgure naq fnvq, “Lbh xabj gung gur ehyref bs gur Tragvyrf ybeq vg bire gurz, naq gurve uvtu bssvpvnyf rkrepvfr nhgubevgl bire gurz. Abg fb jvgu lbh. Vafgrnq, jubrire jnagf gb orpbzr terng nzbat lbh zhfg or lbhe freinag, naq jubrire jnagf gb or svefg zhfg or lbhe fynir — whfg nf gur Fba bs Zna qvq abg pbzr gb or freirq, ohg gb freir, naq gb tvir uvf yvsr nf n enafbz sbe znal.” [Znggurj 20:25-28]
Re: [whatwg] Enabling LCD Text and antialiasing in canvas
On Sat, Feb 16, 2013 at 2:35 AM, Stephen White senorbla...@chromium.orgwrote: On Thu, Feb 14, 2013 at 10:21 PM, Robert O'Callahan rob...@ocallahan.orgwrote: On Thu, Feb 14, 2013 at 11:59 PM, Stephen White senorbla...@chromium.org wrote: I think this is difficult to do in the general case, such as putImageData() or drawImage() or patterns, since you would need to examine all the pixels of the source image to determine if they contain non-1 alpha. This would be cost-prohibitive. If it's just for the purposes of optimization, you could be conservative and simply clear the flag when there's the potential for (but not certainty of) non-1 alpha. But if you're also using that flag to allow subpixel AA, the behaviour becomes quite unpredictable for the web developer and hard to spec crisply. What if we just said a) non-over operators clear the subpixel AA flag b) putImageData clears the subpixel AA flag Both of these are infrequently used AFAIK. Authors could work around most cases of b) by doing putImageData to another canvas and compositing it into the destination with 'over'. Even with these constraints, I don't think we can guarantee that it's safe to use LCD AA text. Once you've drawn with LCD AA text, even if it's safe at the time of drawing, there's no guarantee that it will be safe later. For instance, if you then drawImage() that canvas rotated into another canvas, or even just full-page-zoom it, you'll see colour fringing. Or apply CSS 2D or 3D transforms. There are also existing apps which use canvas for 2D text glyphs, and then transform and place them rotated in WebGL. Those will show colour fringing. Even within canvas, there may be a way to break it if the LCD AA text is drawn first and a dest-alpha compositing mode is used overtop (I haven't verified this though). So I'm starting to think that LCD AA text really has to be opt-in, to avoid breaking existing content. By opting it, you're agreeing that these artifacts are acceptable for your app. For example, you know that even if you're going to do a canvas-to-canvas draw, you're always going to draw at 1:1 scale and no rotation. When you talk about LCD AA, do you talk about this? http://en.wikipedia.org/wiki/Subpixel_rendering If so, I don't think it would ever be safe to draw in such a way with canvas as you can't expect an author to align canvas pixels with LCD pixels. I assumed that we were just talking about regular pixel AA like we (=adobe) do in our graphics products for line art. How bad would that be? Would it help if we added an attribute to the canvas to let authors detect whether the subpixel AA flag is set? Rob -- Wrfhf pnyyrq gurz gbtrgure naq fnvq, “Lbh xabj gung gur ehyref bs gur Tragvyrf ybeq vg bire gurz, naq gurve uvtu bssvpvnyf rkrepvfr nhgubevgl bire gurz. Abg fb jvgu lbh. Vafgrnq, jubrire jnagf gb orpbzr terng nzbat lbh zhfg or lbhe freinag, naq jubrire jnagf gb or svefg zhfg or lbhe fynir — whfg nf gur Fba bs Zna qvq abg pbzr gb or freirq, ohg gb freir, naq gb tvir uvf yvsr nf n enafbz sbe znal.” [Znggurj 20:25-28]
Re: [whatwg] Enabling LCD Text and antialiasing in canvas
As an other alternative, we could also introduce a 'matteColor' attribute. It's default would be 'transparent'. If it's set to a css color, the canvas will be matted to that color. In addition if you use putImageData or a compositing operator that changes alpha, you always matte with that color afterwards (if needed). This is actually pretty close to the 'opaque' keyword except - it's on the canvas context - you can specify a color - it doesn't force reallocation of the canvas On Fri, Feb 15, 2013 at 2:44 PM, Rik Cabanier caban...@gmail.com wrote: On Fri, Feb 15, 2013 at 2:21 PM, Robert O'Callahan rob...@ocallahan.orgwrote: On Thu, Feb 14, 2013 at 11:59 PM, Stephen White senorbla...@chromium.org wrote: I think this is difficult to do in the general case, such as putImageData() or drawImage() or patterns, since you would need to examine all the pixels of the source image to determine if they contain non-1 alpha. This would be cost-prohibitive. If it's just for the purposes of optimization, you could be conservative and simply clear the flag when there's the potential for (but not certainty of) non-1 alpha. But if you're also using that flag to allow subpixel AA, the behaviour becomes quite unpredictable for the web developer and hard to spec crisply. What if we just said a) non-over operators clear the subpixel AA flag b) putImageData clears the subpixel AA flag Both of these are infrequently used AFAIK. Authors could work around most cases of b) by doing putImageData to another canvas and compositing it into the destination with 'over'. Yes, that's pretty much my proposal. Except putImageData could detect it but that might be too hard for authors to figure out. How bad would that be? Would it help if we added an attribute to the canvas to let authors detect whether the subpixel AA flag is set? I think that would be very helpful. So, if you clear (or matte) the canvas, the flag becomes true but if you do an operator that removes alpha, it will become false. Rob -- Wrfhf pnyyrq gurz gbtrgure naq fnvq, “Lbh xabj gung gur ehyref bs gur Tragvyrf ybeq vg bire gurz, naq gurve uvtu bssvpvnyf rkrepvfr nhgubevgl bire gurz. Abg fb jvgu lbh. Vafgrnq, jubrire jnagf gb orpbzr terng nzbat lbh zhfg or lbhe freinag, naq jubrire jnagf gb or svefg zhfg or lbhe fynir — whfg nf gur Fba bs Zna qvq abg pbzr gb or freirq, ohg gb freir, naq gb tvir uvf yvsr nf n enafbz sbe znal.” [Znggurj 20:25-28]
Re: [whatwg] Sandboxed IFrames and downloads.
On Fri, 15 Feb 2013, Mike West wrote: Ping. Is this a terrible idea? :) Sorry for the delay in answering e-mails. Since last quarter I mostly responded to e-mails while neglecting the bug stream, this quarter I'm mostly focusing on the bugs and neglecting the e-mails. All e-mails with substantive feedback (such as yours) sent to this list will eventually get a response. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Enabling LCD Text and antialiasing in canvas
On Sat, Feb 16, 2013 at 4:35 AM, Stephen White senorbla...@chromium.orgwrote: Even with these constraints, I don't think we can guarantee that it's safe to use LCD AA text. Once you've drawn with LCD AA text, even if it's safe at the time of drawing, there's no guarantee that it will be safe later. For instance, if you then drawImage() that canvas rotated into another canvas, or even just full-page-zoom it, you'll see colour fringing. Or apply CSS 2D or 3D transforms. There are also existing apps which use canvas for 2D text glyphs, and then transform and place them rotated in WebGL. Those will show colour fringing. This came up on the list earlier. Even within canvas, there may be a way to break it if the LCD AA text is drawn first and a dest-alpha compositing mode is used overtop (I haven't verified this though). I don't think that's a problem. All destination alpha values will be 1 even after the subpixel AA test is painted, and you'll treat it as normal. So I'm starting to think that LCD AA text really has to be opt-in, to avoid breaking existing content. By opting it, you're agreeing that these artifacts are acceptable for your app. For example, you know that even if you're going to do a canvas-to-canvas draw, you're always going to draw at 1:1 scale and no rotation. It's difficult to know that on a mobile browser or any other browser where you have some kind of fast zoom UI. The suggestion on the list earlier was to keep two versions of the canvas buffer: one with grayscale AA, another with subpixel AA, and composite with the subpixel AA buffer when we can do that safely, otherwise use the grayscale AA version. In many implementations there would be a performance hit for this, so it would make sense to have authors opt-in to that performance hit. Rob -- Wrfhf pnyyrq gurz gbtrgure naq fnvq, “Lbh xabj gung gur ehyref bs gur Tragvyrf ybeq vg bire gurz, naq gurve uvtu bssvpvnyf rkrepvfr nhgubevgl bire gurz. Abg fb jvgu lbh. Vafgrnq, jubrire jnagf gb orpbzr terng nzbat lbh zhfg or lbhe freinag, naq jubrire jnagf gb or svefg zhfg or lbhe fynir — whfg nf gur Fba bs Zna qvq abg pbzr gb or freirq, ohg gb freir, naq gb tvir uvf yvsr nf n enafbz sbe znal.” [Znggurj 20:25-28]
Re: [whatwg] Assigning media resources represented as DOM objects to a media element
On Sat, Feb 16, 2013 at 3:46 AM, Glenn Maynard gl...@zewt.org wrote: a) This isn't the case. The tricky bit was defining precisely when autorevocation happens; this has been resolved (the global script clean-up jobs list). There's a remaining piece ( https://www.w3.org/Bugs/Public/show_bug.cgi?id=17765), but while it'll take some thought to do that in a clean way (so it can be applied to different APIs concisely), there's nothing magic there. Serves me right for checking the latest published version instead of the real spec... Sorry. It may be that there's nothing magic there, but in comment #17 Ian seems less than enthusiastic (this is nuts, IMHO). Even if you get past that, you still have the problem that revoked URLs are useless. It's impossible to do something equivalent to video2.src = video1.src (which works today). Also, getting access to the underlying source object is a valuable feature, especially for MediaStream and MediaSource objects which have interesting APIs on them. Rob -- Wrfhf pnyyrq gurz gbtrgure naq fnvq, “Lbh xabj gung gur ehyref bs gur Tragvyrf ybeq vg bire gurz, naq gurve uvtu bssvpvnyf rkrepvfr nhgubevgl bire gurz. Abg fb jvgu lbh. Vafgrnq, jubrire jnagf gb orpbzr terng nzbat lbh zhfg or lbhe freinag, naq jubrire jnagf gb or svefg zhfg or lbhe fynir — whfg nf gur Fba bs Zna qvq abg pbzr gb or freirq, ohg gb freir, naq gb tvir uvf yvsr nf n enafbz sbe znal.” [Znggurj 20:25-28]
Re: [whatwg] Enabling LCD Text and antialiasing in canvas
On Fri, Feb 15, 2013 at 2:37 PM, Robert O'Callahan rob...@ocallahan.orgwrote:
On Sat, Feb 16, 2013 at 4:35 AM, Stephen White
senorbla...@chromium.orgwrote:
Even with these constraints, I don't think we can guarantee that it's
safe to use LCD AA text. Once you've drawn with LCD AA text, even if it's
safe at the time of drawing, there's no guarantee that it will be safe
later. For instance, if you then drawImage() that canvas rotated into
another canvas, or even just full-page-zoom it, you'll see colour fringing.
Or apply CSS 2D or 3D transforms. There are also existing apps which use
canvas for 2D text glyphs, and then transform and place them rotated in
WebGL. Those will show colour fringing.
This came up on the list earlier.
Even within canvas, there may be a way to break it if the LCD AA text is
drawn first and a dest-alpha compositing mode is used overtop (I haven't
verified this though).
I don't think that's a problem. All destination alpha values will be 1
even after the subpixel AA test is painted, and you'll treat it as normal.
I was thinking something like this:
- draw subpixel AA text over an opaque background
- draw a partially-transparent rect with destination-atop mode over the
subpixel AA text
Now some of the subpixel AA text is still there, but the destination alpha
is non-1, so things will go bad when you composite into the page. (At
least I think it will.. Porter-Duff makes my head spin sometimes.)
So I'm starting to think that LCD AA text really has to be opt-in, to
avoid breaking existing content. By opting it, you're agreeing that these
artifacts are acceptable for your app. For example, you know that even if
you're going to do a canvas-to-canvas draw, you're always going to draw at
1:1 scale and no rotation.
It's difficult to know that on a mobile browser or any other browser where
you have some kind of fast zoom UI.
The suggestion on the list earlier was to keep two versions of the canvas
buffer: one with grayscale AA, another with subpixel AA, and composite with
the subpixel AA buffer when we can do that safely, otherwise use the
grayscale AA version. In many implementations there would be a performance
hit for this, so it would make sense to have authors opt-in to that
performance hit.
It would also be a needless performance hit if the developer knew that they
always wanted subpixel AA, and that their app would never fringe.
Rob
--
Wrfhf pnyyrq gurz gbtrgure naq fnvq, “Lbh xabj gung gur ehyref bs gur
Tragvyrf ybeq vg bire gurz, naq gurve uvtu bssvpvnyf rkrepvfr nhgubevgl
bire gurz. Abg fb jvgu lbh. Vafgrnq, jubrire jnagf gb orpbzr terng nzbat
lbh zhfg or lbhe freinag, naq jubrire jnagf gb or svefg zhfg or lbhe fynir
— whfg nf gur Fba bs Zna qvq abg pbzr gb or freirq, ohg gb freir, naq gb
tvir uvf yvsr nf n enafbz sbe znal.” [Znggurj 20:25-28]
So let me take a stab at a brief summary of the proposals so far, and the
pros and cons of each (correct me if I missed anything):
moz-opaque
pro: fairly easy to implement
pro: no performance hit over regular rendering
pro: many opportunities for optimization
pro: catches all in-canvas cases of color fringing
con: does not handle any out-of-canvas color fringing
con: opt-in
automatic opacity detection
pro: catches most (all?) cases of in-canvas color fringing
pro: some opportunties for optimization (must be conservative in some
cases)
con: does not catch color fringing on CSS transforms, canvas - WebGL, etc
context attribute (something like: context.textAntialising = { 'none',
'grayscale', 'subpixel' })
pro: very easy to implement
pro: no performance hit
con: does not catch any cases of color fringing; completely up to web
developer
con: opt-in
deferred canvas rendering (collect commands into a buffer, flush buffer
only when compositing canvas to page, and decide on subpixel AA at that
point)
pro: catches all cases of color fringing
con: in some cases, requires an infinite buffer (e.g., a canvas that never
clears, and only accumulates drawing frame-to-frame means you must
accumulate commands indefinitely)
con: difficult to implement (e.g., canvas-to-canvas drawImage(), etc)
con: may introduce performance hit due to re-rendering with and without
subpixel AA (in cases where you would rather have just gone without)
two buffers (one grayscale, one LCD AA)
pro: handles all cases of color fringing
pro: moderately easy to implement
con: RAM (or VRAM) usage is doubled
con: possibly-unnecessary performance hit
con: must be opt-in
