Re: [whatwg] Enabling LCD Text and antialiasing in canvas
On Sat, Feb 23, 2013 at 2:59 AM, Stephen White wrote: > On Thu, Feb 21, 2013 at 7:01 PM, Rik Cabanier wrote: > >> >> >> On Fri, Feb 22, 2013 at 10:33 AM, Robert O'Callahan > > wrote: >> >>> I think Rik is convincing me that we shouldn't expose mozOpaque or any >>> other explicit subpixel AA control to the Web. It will be very easy for Web >>> authors to test it in one place and discover that it works without >>> realizing that they're causing problems for some users. >>> >>> I think a fully automatic solution that tries to use subpixel AA but is >>> always able to render grayscale AA if needed is the way to go. Possibly >>> with an author hint to suggest opting into a more expensive rendering path. >> >> > Here are the problems I see with that approach: > > 1) In order to avoid a performance hit for existing content, it still > requires a spec change (the hint) > What is the performance hit? > 2) Even with the hint, when the author knows they want LCD AA, they still > incur a performance penalty of drawing to two buffers. > Why are there 2 buffers? You just draw on top of the existing content. It is up to the author to ensure correct output. > 3) It still can't handle all cases, such as canvas -> WebGL, which will > have to remain grayscale-only, even when the author knows it would be safe > for their application. > That is OK. A UA is not required to implement this. > > Also, what form should this authoring hint take? Is it going to > explicitly call out LCD AA? In that case, how is it better than an opt-in > canvas attribute? If it doesn't explicitly call out LCD AA, but that's the > only effect it has, what should it be called? > > I also have concerns that the knowledge of when it's safe to use the LCD > AA buffer is going to spread throughout the browser codebase, even in areas > which currently have no knowledge of canvas, in order to handle all the > special cases. This may just be an implementation detail (and may be > avoidable, this is TBD), but it does have the potential to introduce > dependencies or complicate implementation. > > >>> >> Great! I think matteColor (or matteStyle to be more consistent) can >> easily be implemented. We can optimize rendering later. >> > >> So, if a mattecolor is set the UA can assume that: >> > > Maybe I'm missing something, but if we're going down the automatic road, > why do we need a new function/attribute? Why not simply detect when a > canvas-sized fillRect() has been performed with an opaque fillStyle? This > would also allow optimization of existing content. > > Stephen > > - all compositing operation within the canvas can ignore background alpha >> - the canvas can be copied directly to the screen (unless another effect >> is applied to the canvas element or its ancestor) >> >> If mattecolor is set, the UA should matte with that color. If a >> compositing operation (that introduces alpha) is used, the matte operation >> needs to be repeated. >> > I experimented with adding MatteStyle for Core Graphics in mozilla and webkit and got the basics of it working. So, it's definitely possible to add to the browsers.
Re: [whatwg] Enabling LCD Text and antialiasing in canvas
On Fri, Feb 22, 2013 at 7:59 AM, Stephen White wrote: > On Thu, Feb 21, 2013 at 7:01 PM, Rik Cabanier wrote: > >> >> >> On Fri, Feb 22, 2013 at 10:33 AM, Robert O'Callahan > > wrote: >> >>> I think Rik is convincing me that we shouldn't expose mozOpaque or any >>> other explicit subpixel AA control to the Web. It will be very easy for Web >>> authors to test it in one place and discover that it works without >>> realizing that they're causing problems for some users. >>> >>> I think a fully automatic solution that tries to use subpixel AA but is >>> always able to render grayscale AA if needed is the way to go. Possibly >>> with an author hint to suggest opting into a more expensive rendering path. >> >> > Here are the problems I see with that approach: > > 1) In order to avoid a performance hit for existing content, it still > requires a spec change (the hint) > 2) Even with the hint, when the author knows they want LCD AA, they still > incur a performance penalty of drawing to two buffers. > 3) It still can't handle all cases, such as canvas -> WebGL, which will > have to remain grayscale-only, even when the author knows it would be safe > for their application. > > Also, what form should this authoring hint take? Is it going to > explicitly call out LCD AA? In that case, how is it better than an opt-in > canvas attribute? If it doesn't explicitly call out LCD AA, but that's the > only effect it has, what should it be called? > > I also have concerns that the knowledge of when it's safe to use the LCD > AA buffer is going to spread throughout the browser codebase, even in areas > which currently have no knowledge of canvas, in order to handle all the > special cases. This may just be an implementation detail (and may be > avoidable, this is TBD), but it does have the potential to introduce > dependencies or complicate implementation. > Since this is a feature for advanced users, we should let them handle all the cases. (I would even allow subpixel AA on a transparent canvas) Handling all the edge cases in the browser will be extremely difficult (if it's even possible) and will just frustrate those advanced users since it will get in their way. > > >>> >> Great! I think matteColor (or matteStyle to be more consistent) can >> easily be implemented. We can optimize rendering later. >> > >> So, if a mattecolor is set the UA can assume that: >> > > Maybe I'm missing something, but if we're going down the automatic road, > why do we need a new function/attribute? Why not simply detect when a > canvas-sized fillRect() has been performed with an opaque fillStyle? This > would also allow optimization of existing content. > Doesn't that seem slightly hacky? So, if the canvas detects that you did a fillrect with a constant color, it should assume that it's opaque? This seems confusing from an author's perspective. In addition, compositing modes that introduce alpha will turn the bit off again and there would be no way to turn it back on. > > - all compositing operation within the canvas can ignore background alpha >> - the canvas can be copied directly to the screen (unless another effect >> is applied to the canvas element or its ancestor) >> >> If mattecolor is set, the UA should matte with that color. If a >> compositing operation (that introduces alpha) is used, the matte operation >> needs to be repeated. >> >> Rik >> > >
Re: [whatwg] inputmode feedback
On Wed, 20 Feb 2013, Ryosuke Niwa wrote: > > Why is name not an input type? There's a section that discusses it a bit: http://whatwg.org/html#the-difference-between-the-field-type,-the-autofill-field-name,-and-the-input-modality -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] HTTP Forms extension specification
On Fri, Feb 22, 2013 at 4:37 PM, Anne van Kesteren wrote: > On Fri, Feb 22, 2013 at 2:29 PM, Cameron Jones wrote: > > The HTTP headers are restricted using a copy-paste of those in XHR which > is > > included in the form submission process. Happy to hear any suggestions to > > improve the structure or general authoring. > > You are not making the same checks as > http://xhr.spec.whatwg.org/#the-setrequestheader%28%29-method does. > E.g. I could inject a header value in your algorithm that is CRLF > followed by "Referer: mahahah". > > Ahh, yes i see the referencesi'll fix that now. Thanks, cam
Re: [whatwg] HTTP Forms extension specification
On Fri, Feb 22, 2013 at 2:29 PM, Cameron Jones wrote: > The HTTP headers are restricted using a copy-paste of those in XHR which is > included in the form submission process. Happy to hear any suggestions to > improve the structure or general authoring. You are not making the same checks as http://xhr.spec.whatwg.org/#the-setrequestheader%28%29-method does. E.g. I could inject a header value in your algorithm that is CRLF followed by "Referer: mahahah". Not really convinced by the use cases, but maybe someone else is. -- http://annevankesteren.nl/
Re: [whatwg] Enabling LCD Text and antialiasing in canvas
On Thu, Feb 21, 2013 at 7:01 PM, Rik Cabanier wrote: > > > On Fri, Feb 22, 2013 at 10:33 AM, Robert O'Callahan > wrote: > >> I think Rik is convincing me that we shouldn't expose mozOpaque or any >> other explicit subpixel AA control to the Web. It will be very easy for Web >> authors to test it in one place and discover that it works without >> realizing that they're causing problems for some users. >> >> I think a fully automatic solution that tries to use subpixel AA but is >> always able to render grayscale AA if needed is the way to go. Possibly >> with an author hint to suggest opting into a more expensive rendering path. > > Here are the problems I see with that approach: 1) In order to avoid a performance hit for existing content, it still requires a spec change (the hint) 2) Even with the hint, when the author knows they want LCD AA, they still incur a performance penalty of drawing to two buffers. 3) It still can't handle all cases, such as canvas -> WebGL, which will have to remain grayscale-only, even when the author knows it would be safe for their application. Also, what form should this authoring hint take? Is it going to explicitly call out LCD AA? In that case, how is it better than an opt-in canvas attribute? If it doesn't explicitly call out LCD AA, but that's the only effect it has, what should it be called? I also have concerns that the knowledge of when it's safe to use the LCD AA buffer is going to spread throughout the browser codebase, even in areas which currently have no knowledge of canvas, in order to handle all the special cases. This may just be an implementation detail (and may be avoidable, this is TBD), but it does have the potential to introduce dependencies or complicate implementation. >> > Great! I think matteColor (or matteStyle to be more consistent) can easily > be implemented. We can optimize rendering later. > > So, if a mattecolor is set the UA can assume that: > Maybe I'm missing something, but if we're going down the automatic road, why do we need a new function/attribute? Why not simply detect when a canvas-sized fillRect() has been performed with an opaque fillStyle? This would also allow optimization of existing content. Stephen - all compositing operation within the canvas can ignore background alpha > - the canvas can be copied directly to the screen (unless another effect > is applied to the canvas element or its ancestor) > > If mattecolor is set, the UA should matte with that color. If a > compositing operation (that introduces alpha) is used, the matte operation > needs to be repeated. > > Rik >
Re: [whatwg] HTTP Forms extension specification
On Fri, Feb 22, 2013 at 10:05 AM, Anne van Kesteren wrote: > On Thu, Feb 21, 2013 at 7:42 PM, Cameron Jones wrote: > > I've just committed an initial draft of HTTP extensions for Forms: > > > > http://cameronjones.github.com/form-http-extensions/index.html > > > > The document can be considered within the public domain for integration. > > I'd recommend making CC0 the license then, rather than CCA. > Done, and spelling fixed. > > Motivation would also useful. It's not entirely clear to me why this > complexity is warranted. The motivations are the same which support declarative over imperative programming, access to the HTTP protocol methods and headers (ETags, versioning), greater flexibility over payload binding and the ability to avoid using cookies for session continuation. The access to HTTP Auth provides greater security over non-HTTPS than is currently possible while retaining the ability to style forms for login\logout which users have come to expect. This is all in the absence of requiring JavaScript to be on. For a (slightly inflamed from a rant-able persona, so please read with potential sensitivities off) further examination of the use cases and rationale, the specification is the reification of the proposal i wrote last year: http://www.w3.org/wiki/User:Cjones/ISSUE-195 > And the complexity seems lacking, e.g. you're > not putting the necessary restrictions on header names and values as > far as I can tell. > > The HTTP headers are restricted using a copy-paste of those in XHR which is included in the form submission process. Happy to hear any suggestions to improve the structure or general authoring. Thanks, Cameron Jones
Re: [whatwg] HTTP Forms extension specification
On Thu, Feb 21, 2013 at 7:42 PM, Cameron Jones wrote: > I've just committed an initial draft of HTTP extensions for Forms: > > http://cameronjones.github.com/form-http-extensions/index.html > > The document can be considered within the public domain for integration. I'd recommend making CC0 the license then, rather than CCA. Motivation would also useful. It's not entirely clear to me why this complexity is warranted. And the complexity seems lacking, e.g. you're not putting the necessary restrictions on header names and values as far as I can tell. (Spelling: HTTP, XMLHttpRequest, JavaScript, my name is with a lowercase v if you include the first name.) -- http://annevankesteren.nl/
