Re: [whatwg] Enabling LCD Text and antialiasing in canvas
On Sun, Mar 17, 2013 at 1:40 PM, Robert O'Callahan wrote: > On Sat, Mar 16, 2013 at 5:52 PM, Gregg Tavares wrote: > >> Let me ask again in a different way ;-) Specifically about LCD style >> antialiasing. >> >> What about a context attribute "antialiasRenderingQualityHint" for now >> with >> 2 settings "default" and "displayDependent" >> >>context.antialiasRenderingQualityHint = "displayDependent" >> > > How would this interact with canvas opacity? E.g. if the author uses > displayDependent and then draws text over transparent pixels in the canvas, > what is the UA supposed to do? > Whatever the UA wants. It's a hint. From my POV, since the spec doesn't say anything about anti-aliasing then it really doesn't matter. My preference, if I was programming a UA, would be if the user sets "displayDependent" and the UA is running on a lo-dpi machine I'd unconditionally render LCD-AA with the assumption that the canvas is composited on white. If they want some other color they'd fill the canvas with as solid color first. Personally I don't think that needs to be specced, but it would be my suggestion. As I mentioned, even without this hint the spec doesn't prevent a UA from unconditionally using LCD-AA. Very few developers are going to run into issues. Most developers that use canvas aren't going to set the hint. Most developers that use canvas dont' make it transparent nor do they CSS rotate/scale them. For those few developers that do happen to blend and/or rotate/scale AND set the hint they'll get probably get some fringing but there (a) there was no guarantee they wouldn't already have that problem since as pointed out, the spec doesn't specify AA nor what kind, and (b) if they care they'll either stop using the hint or they'll search for "why is my canvas fringy" and the answer will pop up on stackoverlow and they can choose one of the solutions. > > 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, Mar 16, 2013 at 5:52 PM, Gregg Tavares wrote: > Let me ask again in a different way ;-) Specifically about LCD style > antialiasing. > > What about a context attribute "antialiasRenderingQualityHint" for now with > 2 settings "default" and "displayDependent" > >context.antialiasRenderingQualityHint = "displayDependent" > How would this interact with canvas opacity? E.g. if the author uses displayDependent and then draws text over transparent pixels in the canvas, what is the UA supposed to do? 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] Fetch: crossorigin="anonymous" and XMLHttpRequest
On Sun, Mar 17, 2013 at 2:16 AM, Anne van Kesteren wrote:
> On Sun, Mar 17, 2013 at 1:10 AM, Jonas Sicking wrote:
>> On Mon, Mar 11, 2013 at 4:31 AM, Anne van Kesteren wrote:
>>> Preceded the specification? I doubt that. When was it added? The
>>> specification was done start of 2010 somewhere based on the
>>> requirements coming from UMP:
>>> http://lists.w3.org/Archives/Public/public-webapps/2010JanMar/0340.html
>>
>> I see that my attempt at focusing on the important issues failed.
>> Would you like to debate whether the new syntax constitutes a new
>> feature or would you like to debate the technical issues of whether we
>> want the a) and b) behavior?
>
> I tried to address both by pointing to UMP which wants both a) and b).
> The alternative would be to use which
> exhibits the same behavior given the unique origin (that also blocks
> Referer). I believe at least Maciej expressed interest in supporting
> the UMP use case.
But *why* does UMP want this behavior? What's the use case?
I think there is value in indicating which webpage is making the
request. The problem that I understood UMP wanting to solve was the
confused deputy problem where it looked like the user was making the
request rather than the webpage.
> If anon:true means no more than withCredentials=false we should call
> it withCredentials instead as EventSource does at the moment. Although
> given XMLHttpRequest already has withCredentials there would be
> nothing new in that addition and generally we've refrained from adding
> such duplicate features.
In the Firefox implementation { anon:true } does for all requests what
withCredentials=false does for cross-origin requests.
/ Jonas
Re: [whatwg] Priority between and content-disposition
On Sun, Mar 17, 2013 at 6:46 AM, Julian Reschke wrote: > 1) Content-Disposition: inline >> 2) Content-Disposition: inline; filename="B.txt" >> 3) Content-Disposition: attachment; filename="B.txt" >> >> People generally seem to have a harder time with getting header data >> right, than getting markup right, and so I think that in all cases we >> should display the "save as" dialog (or display equivalent download >> UI) and suggest the filename "A.txt". >> > > I agree that people have problems getting headers right, but in all the > cases above, it seems they have set the header on purpose, no? > > My recollection was that a/@download was mainly added for cases where the > header field couldn't be set at all... > When I use #2, I'm just setting the filename. "inline" is only there because it has to be; there's no way of saying "Content-Disposition: don't care; filename=foo". "inline" is the default. I think @download should be able to force a download regardless of whether a C-D header exists: treat the default C-D as "inline", and don't change behavior just because a header states the default. I don't know if it should be able to override a C-D filename parameter. I can't think of any case where this is useful, so if it helps get this feature available cross-origin then that's fine. (Half of the point of this feature is to allow adjusting filenames on external content servers which you don't have much control over.) -- Glenn Maynard
Re: [whatwg] Priority between and content-disposition
On 2013-03-17 02:49, Jonas Sicking wrote: It's currently unclear what to do if a page contains markup like if the resource at audio.wav responds with either 1) Content-Disposition: inline 2) Content-Disposition: inline; filename="B.txt" 3) Content-Disposition: attachment; filename="B.txt" People generally seem to have a harder time with getting header data right, than getting markup right, and so I think that in all cases we should display the "save as" dialog (or display equivalent download UI) and suggest the filename "A.txt". I agree that people have problems getting headers right, but in all the cases above, it seems they have set the header on purpose, no? My recollection was that a/@download was mainly added for cases where the header field couldn't be set at all... > ... Best regards, Julian
Re: [whatwg] Fetch: crossorigin="anonymous" and XMLHttpRequest
On Sun, Mar 17, 2013 at 1:10 AM, Jonas Sicking wrote: > On Mon, Mar 11, 2013 at 4:31 AM, Anne van Kesteren wrote: >> Preceded the specification? I doubt that. When was it added? The >> specification was done start of 2010 somewhere based on the >> requirements coming from UMP: >> http://lists.w3.org/Archives/Public/public-webapps/2010JanMar/0340.html > > I see that my attempt at focusing on the important issues failed. > Would you like to debate whether the new syntax constitutes a new > feature or would you like to debate the technical issues of whether we > want the a) and b) behavior? I tried to address both by pointing to UMP which wants both a) and b). The alternative would be to use which exhibits the same behavior given the unique origin (that also blocks Referer). I believe at least Maciej expressed interest in supporting the UMP use case. If anon:true means no more than withCredentials=false we should call it withCredentials instead as EventSource does at the moment. Although given XMLHttpRequest already has withCredentials there would be nothing new in that addition and generally we've refrained from adding such duplicate features. -- http://annevankesteren.nl/
