Re: [whatwg] URL standard: Query string parsing; host parsing
On 2013-03-13 21:24, Boris Zbarsky wrote: On 3/13/13 4:23 PM, Julian Reschke wrote: Under RFC 3986, it would resolve to jar:http://example.com/Bar.class If you assume that this is a hierarchical scheme and that the hierarchy is in some particular place, no? Why is that assumption being made? No such assumption was made. Just following the algorithm in the spec. Looks like a broken scheme to me. I'm not going to try to claim jar: is a wonderful thing. It is what it is. It needs to not break. Is it used outside Java applet scenarios? BTW: this shows why formal registration and review of URI schemes is a *feature*. Best regards, Julian
[whatwg] Worker + CanvasPathObject
I can see efforts in exposing canvases within a worker [1]. Does that mean the following APIs are exposed and available within a worker as well? - CanvasPathObject [2] - SVGMatrix See: Path#addPath [3] Greetings Tobi [1] http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#proxying-canvases-to-workers [2] http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#path-objects [3] http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#dom-path-addpath
[whatwg] [canvas] Which interfaces/constructors available in workers?
The new canvas proxy stuff is supposed to make canvas work in workers, but I don't see any normative text that makes the necesary interfaces and constructors actually available in workers. The spec needs to explicitly say that CanvasRenderingContext2D, e.g., is to be available in workers. -- Simon Pieters Opera Software
Re: [whatwg] URL standard: Query string parsing; host parsing
On Wed, Mar 13, 2013 at 11:58 PM, Bjoern Hoehrmann derhoe...@gmx.net wrote: http:test is already absolute, so per RFC 3986 the absolute form is http:test regardless of the base reference. The relevant case there is rather when the base scheme is http, because then some implemen- tations treat the string as relative reference, as noted in RFC 3986. Some browsers end up handling the absolute reference http:test as if it was http://test/;, but that has nothing to do with how you turn relative references into absolute references. Fair enough. I guess the main difference for relative references is that they only work for certain schemes and that the file URL scheme has even more special rules. -- http://annevankesteren.nl/
Re: [whatwg] URL standard: Query string parsing; host parsing
On 3/14/13 4:12 AM, Julian Reschke wrote: Is it used outside Java applet scenarios? It's certainly used all over in Firefox chrome. BTW: this shows why formal registration and review of URI schemes is a *feature*. Indeed. -Boris
Re: [whatwg] Enabling LCD Text and antialiasing in canvas
On Wed, Mar 13, 2013 at 10:28 PM, Gregg Tavares g...@google.com wrote: On Wed, Mar 13, 2013 at 1:18 PM, Robert O'Callahan rob...@ocallahan.orgwrote: On Thu, Mar 14, 2013 at 8:04 AM, Gregg Tavares g...@google.com wrote: It seems like an opaque canvas should be an orthogonal issue to subpixel-aa. Subpixel AA seems like it should be a Canvas2DRenderingContext setting though maybe with a name like ctx.antialiasingRenderQuality = With options of none grayscale bestForDeviceIfAxisAlignedAndNotScaledOrBlended My mistake. They should be none alpha bestForDeviceIfNotCanvasIsNotRotatedAndCanvasIsNotScaledAndCanvasIsOpaque Don't forget AndCanvasIsNotFilteredAndCanvasIsNotDrawnViaWebGLThroughAShaderWhichModifiesFragmentColour. :) (And actually, this name sort of leads me to believe the opposite: that the API will take care of these cases for me, and I don't have to worry about them.) Naming aside, this is basically the proposal from message #1 in this thread (and mine from partway through). The objections were that this is a footgun with which web developers should not be trusted. For the record, I don't agree with that assessment. However, since it seemed that moz-opaque had at least some chance of being implemented by other browser vendors, and provides a generally useful optimization, I was pursuing that approach instead. Stephen ;-) Yes, I know that's a horrible name but it spells out the limitation of the higher quality aa needed on some devices. A dev can opt in (Since the default is alpha which is what happens today). If they opt in (a) it will look good if they follow the rules and (b) as the world transitions to HD-DPI it will end up being alpha so it's forward compatible. Ugh! This would let the developer choose. It would be clear what the limits are, when to use it, and would let the developer choose what they need, even in an opaque canvas. Then we would need to come up with a spec for what happens when you composite subpixel AA over non-opaque pixels, including how the per-channel alpha values are combined to form a single alpha value. IIRC in some cases (D2D) you just can't do it. If we said that in a non-opaque canvas, subpixel AA is treated as grayscale, that would be OK. sure. 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 Wed, Mar 13, 2013 at 2:48 PM, Gregg Tavares g...@google.com wrote:
Sorry for only mentioning this so late but is there any chance to steer
this to be more inline with WebGL?
WebGL already has the option to have an opaque canvas using context
creation parameters. In WebGL it's
gl = canvas.getContext(webgl, {alpha: false});
If we go forward with an opaque attribute now you have 2 conflicting
settings.
canvas.opaque = true;
gl = canvas.getContext(webgl, {alpha: true});
Who wins that conflict? Yea, I know we could come up with rules. ( the 2
settings, etc...)
But, there are other context creation attributes we'd like to see on a 2d
canvas. One that comes to mind is 'preserveDrawingBuffer'.
preserveDrawingBuffer: false in WebGL means that the canvas is double
buffered. This is a performance win since most browsers using GPU
compositing need to copy the contents of the canvas when compositing.
Setting preseverDrawingBuffer: false (which is the default in WebGL) means
the browser can double buffer and avoid the copy. We'd like to see that
same attribute for 2D canvas/contexts to get the same perf benefit for
canvas games, etc.
So, given we want more creation attributes and given WebGL already has a
way to declare opaqueness why not follow the existing method and add
context creation parameters to 2d canvas to solve this issue rather than
make a new and conflicting 'opaque' attribute?
I have no major objections to this approach, so long as it doesn't make
this change contingent on a WebGL spec change. In particular, it's
tempting to unify the IDL between Canvas WebGL (although it may not be
necessary -- I'm far from an IDL expert.) Here, let me show you my
ignorance: can we create a
interface Canvas2DContextAttributes {
attribute boolean alpha;
}
which has no relation to WebGLContextAttributes?
Then we get at least the duck typing such that
ctx = canvas.getContext('2d', {alpha: false });
and
ctx = canvas.getContext('webgl', {alpha: false });
both work, although one is coerced into a WebGLContextAttributes and the
other to a Canvas2DContextAttributes.
Does that make sense?
Stephen
Re: [whatwg] Why are we merging Document and HTMLDocument again?
On Tue, Mar 5, 2013 at 8:42 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 3/5/13 3:30 PM, Ian Hickson wrote: I'd be fine with having a Document descendant that is used for Documents that have global scopes / browsing contexts / the works, and one that is used for Documents that don't (e.g. createDocument(), XHR); would that address this issue? It's one way to address it, yes... Just to be clear, this works for Mozilla, as long as it's clearly defined and other vendors are on board. Arv? -- http://annevankesteren.nl/
Re: [whatwg] Enabling LCD Text and antialiasing in canvas
On 3/14/13 10:34 AM, Stephen White wrote:
can we create a
interface Canvas2DContextAttributes {
attribute boolean alpha;
}
which has no relation to WebGLContextAttributes?
Yes.
Then we get at least the duck typing such that
ctx = canvas.getContext('2d', {alpha: false });
and
ctx = canvas.getContext('webgl', {alpha: false });
both work, although one is coerced into a WebGLContextAttributes and the
other to a Canvas2DContextAttributes.
And this would work, yes.
-Boris
[whatwg] Fetch: HTTP Authentication
So if the server replies with status 401 and a WWW-Authenticate header that is properly formatted (I did not do detailed syntax checks but e.g. WWW-Authenticate: basicerror does not work) is present, we prompt the user. We do this for img, script, new Worker(), XMLHttpRequest, workers' importScripts() (including shared workers!), ... We do not prompt for cross-origin requests when CORS is opted into. Is there anything we should do here? Prompting the end user for requests they did not explicitly initiate via navigation seems very confusing. On the other hand maybe creating a divergence here is not worth it at this point. -- http://annevankesteren.nl/
Re: [whatwg] Fetch: HTTP Authentication
On 14/03/2013 15:59 , Anne van Kesteren wrote: So if the server replies with status 401 and a WWW-Authenticate header that is properly formatted (I did not do detailed syntax checks but e.g. WWW-Authenticate: basicerror does not work) is present, we prompt the user. We do this for img, script, new Worker(), XMLHttpRequest, workers' importScripts() (including shared workers!), ... We do not prompt for cross-origin requests when CORS is opted into. Is there anything we should do here? Prompting the end user for requests they did not explicitly initiate via navigation seems very confusing. On the other hand maybe creating a divergence here is not worth it at this point. People who don't rely on this will never have their users see the prompts, so it's hardly harming them. People who *do* rely on this (assuming they exist — in this case they probably do somewhere) will find their services broken if we change it. So on the face of things, I get the impression that there's zero cost in keeping things the way they are, and risk in changing them. I think that the lack of interoperability, and the complete inanity of prompting in browsers where it happens, is more problematic in the case of unsafe redirects. -- Robin Berjon - http://berjon.com/ - @robinberjon
Re: [whatwg] Fetch: HTTP Authentication
On Thu, Mar 14, 2013 at 4:34 PM, Robin Berjon ro...@w3.org wrote: On 14/03/2013 15:59 , Anne van Kesteren wrote: Is there anything we should do here? Prompting the end user for requests they did not explicitly initiate via navigation seems very confusing. On the other hand maybe creating a divergence here is not worth it at this point. People who don't rely on this will never have their users see the prompts, so it's hardly harming them. People who *do* rely on this (assuming they exist — in this case they probably do somewhere) will find their services broken if we change it. So on the face of things, I get the impression that there's zero cost in keeping things the way they are, and risk in changing them. Sure, I meant for new contexts and maybe some existing contexts, such as workers. Also, for shared workers it's not entirely clear which browsing context you'd prompt in if an importScript() or same-origin XMLHttpRequest happened. I think that the lack of interoperability, and the complete inanity of prompting in browsers where it happens, is more problematic in the case of unsafe redirects. There should simply be no prompting there, it makes no sense. -- http://annevankesteren.nl/
Re: [whatwg] Fetch: HTTP Authentication
On 14/03/2013 16:57 , Anne van Kesteren wrote: On Thu, Mar 14, 2013 at 4:34 PM, Robin Berjon ro...@w3.org wrote: People who *do* rely on this (assuming they exist — in this case they probably do somewhere) will find their services broken if we change it. So on the face of things, I get the impression that there's zero cost in keeping things the way they are, and risk in changing them. Sure, I meant for new contexts and maybe some existing contexts, such as workers. Oh, yes, agreed — for anything new this is madness. And I doubt anything recent relies on it, either. Also, for shared workers it's not entirely clear which browsing context you'd prompt in if an importScript() or same-origin XMLHttpRequest happened. I think that's definitely a bug. I think that the lack of interoperability, and the complete inanity of prompting in browsers where it happens, is more problematic in the case of unsafe redirects. There should simply be no prompting there, it makes no sense. It's not just madness, it's different madness everywhere :) -- Robin Berjon - http://berjon.com/ - @robinberjon
Re: [whatwg] Fetch: HTTP Authentication
On Thu, Mar 14, 2013 at 11:34 AM, Robin Berjon ro...@w3.org wrote: People who don't rely on this will never have their users see the prompts, so it's hardly harming them. It harmed me slightly just a couple days ago. I moved a page that makes an XHR request from one server to another. The XHR request on the new server accidentally pointed to an unrelated resource that was password-protected. When I loaded the page, I got a password prompt for a resource I absolutely knew didn't require a password, which, until I figured out what was going on, made me worry that my server had been compromised or that some kind of MITM was taking place. I don't know if it's possible or impossible to change this (probably not, at least for XHR initiated from the UI thread), or if it's worth trying, but weird behavior is always harmful, and XHR causing user prompting is definitely weird. There definitely shouldn't be prompting for anything taking place in a worker. -- Glenn Maynard
Re: [whatwg] Mutation Observer arguments format
The old API is confusing. We can do better, so we should. On Tue, Mar 12, 2013 at 6:22 AM, Olli Pettay olli.pet...@helsinki.fiwrote: On 03/12/2013 12:34 PM, Anne van Kesteren wrote: On Tue, Mar 12, 2013 at 12:41 AM, Alex Russell slightly...@google.com wrote: Thoughts? My main thought is that it's a pita to change the API at this time now it's unprefixed everywhere and we've been encouraging developers to use it in favor of mutation events. If Adam/Rafael/Olli/Jonas are willing to update WebKit/Gecko though I guess I don't really care. We could keep the old behavior and extend it to support types. But since the change isn't backward compatible (scripts using types wouldn't work in older browsers), I'd like to understand the need for the change. -Olli
Re: [whatwg] Fetch: HTTP Authentication
* Anne van Kesteren wrote: So if the server replies with status 401 and a WWW-Authenticate header that is properly formatted (I did not do detailed syntax checks but e.g. WWW-Authenticate: basicerror does not work) is present, [...] Julian Reschke covers this on http://greenbytes.de/tech/tc/httpauth/. -- Björn Höhrmann · mailto:bjo...@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/
