Re: [whatwg] Blurry lines in 2D Canvas (and SVG)
On Thu, Jul 25, 2013 at 12:24 AM, Rik Cabanier caban...@gmail.com wrote: Yes, that's what I had in mind: the developer detects the device pixel ratio and scales up the canvas so the pixels match. That reduces to the simple case, then. The pixel ratio gets out of the picture entirely if you adjust the canvas so it's rendered 1:1 to pixels, so the rules for getting hard edges are the same (half-pixels for strokes, integer pixels for fills). -- Glenn Maynard
Re: [whatwg] Proposal: Adding methods like getElementById and getElementsByTagName to DocumentFragments
On 7/24/13 5:51 PM, James Greene wrote: While I'm not familiar with the spec for DocumentFragments, I've always consider them to be more equivalent to a detached element node than a document node. Fwiw, Element has a getElementsByClassName and getElementsByTagName. And SVGElement has getElementById. -Boris
Re: [whatwg] Proposal: Adding methods like getElementById and getElementsByTagName to DocumentFragments
On 7/24/13 5:39 PM, Ryosuke Niwa wrote: Indeed. Note that querySelector implementations in WebKit and Blink optimize #foo, .foo, etc... so that they're equally if not faster than getElementsById, getElementsByClassName, etc... I have a hard time reconciling that claim with either code-inspection of WebKit code, general considerations of what it takes to implement these methods, or the numbers I see in Chrome on http://jsperf.com/queryselector-vs-dom Now I realize that for querySelectorAll vs getElementsByClassName that microbenchmark largely shows the reuse same list vs have to create a new list difference, but real-life code would show such a difference too, in many cases. -Boris
Re: [whatwg] Proposal: Adding methods like getElementById and getElementsByTagName to DocumentFragments
On 7/24/13 10:42 PM, Jussi Kalliokoski wrote: Argh, I had forgotten about live NodeLists. OK, this is a reason that resonates with me and justifies calling these methods obsolete. Too bad these methods are so badly flawed Fwiw, I think the performance impact of live NodeLists is ... unclear. Their existence does mean that you have to deal with DOM mutations changing the lists, but them being live also means you can make the list getters much faster in cases when the caller doesn't actually want the entire list. -Boris
Re: [whatwg] URL: file URL C| quirk
On 7/4/2013 5:18 AM, Anne van Kesteren wrote: Both Gecko and Chromium have a quirk with C| and similar patterns (drive letter followed by |). They treat it similarly to C:. However, Internet Explorer does not do this. Should we remove this quirk? In my testing IE does treat C| as C: _if_ the scheme is qualified, as in: file://c|/foo/bar I know that including the scheme is a slightly different test case than your original, but in case it's helpful see: http://web.lookout.net/2011/06/some-browsers-convert-pipe-to-colon-in.html thanks, Chris Weber
Re: [whatwg] Blurry lines in 2D Canvas (and SVG)
On Thu, Jul 25, 2013 at 7:05 AM, Glenn Maynard gl...@zewt.org wrote: On Thu, Jul 25, 2013 at 12:24 AM, Rik Cabanier caban...@gmail.com wrote: Yes, that's what I had in mind: the developer detects the device pixel ratio and scales up the canvas so the pixels match. That reduces to the simple case, then. The pixel ratio gets out of the picture entirely if you adjust the canvas so it's rendered 1:1 to pixels, so the rules for getting hard edges are the same (half-pixels for strokes, integer pixels for fills). Unfortunately, no. Let's say you have a device pixel ratio of 1.1 and a canvas of 100x100px. The underlying canvas bitmap should now be created as 110 x 110 pixels and your content should be scaled by 1.1. This will make everything blurry :-(
Re: [whatwg] Blurry lines in 2D Canvas (and SVG)
On chrome android I see the opposite - the left rests are sharp, the middle ones fuzzy. Sounds like tests needed. On Jul 23, 2013 5:18 PM, David Dailey ddai...@zoominternet.net wrote: Hi Rik, Just affirming what you've said in SVG: http://cs.sru.edu/~ddailey/svg/edgeblurs.svg The middle rects are crisp, having been merely translated leftward and downward by half a pixel. Zooming in from the browser rectifies the problem (as expected) after a single tick. I remember folks discussing sub-pixel antialiasing quite a bit on the SVG lists circa fall/winter 2011. It seemed to cause some troubles for D3. Is that the same issue? Cheers David -Original Message- From: whatwg-boun...@lists.whatwg.org [mailto:whatwg-boun...@lists.whatwg.org] On Behalf Of Rik Cabanier Sent: Tuesday, July 23, 2013 7:19 PM To: wha...@whatwg.org Subject: [whatwg] Blurry lines in 2D Canvas (and SVG) All, we've noticed that if you draw lines in canvas or SVG, they always end up blurry. For instance see this fiddle: http://jsfiddle.net/V92Gn/128/ This happens because you offset 1 pixel and then draw a half pixel stroke on each side. Since it covers only half the pixel, the color gets mapped to 50% gray. You can work around this by doing an extra offset of half the devicepixelratio, but ideally this should never happen. Is this behavior specified somewhere? Is there a way to turn this off?
Re: [whatwg] Blurry lines in 2D Canvas (and SVG)
On Thu, Jul 25, 2013 at 2:36 PM, Rik Cabanier caban...@gmail.com wrote: On Thu, Jul 25, 2013 at 7:05 AM, Glenn Maynard gl...@zewt.org wrote: On Thu, Jul 25, 2013 at 12:24 AM, Rik Cabanier caban...@gmail.comwrote: Yes, that's what I had in mind: the developer detects the device pixel ratio and scales up the canvas so the pixels match. That reduces to the simple case, then. The pixel ratio gets out of the picture entirely if you adjust the canvas so it's rendered 1:1 to pixels, so the rules for getting hard edges are the same (half-pixels for strokes, integer pixels for fills). Unfortunately, no. Let's say you have a device pixel ratio of 1.1 and a canvas of 100x100px. The underlying canvas bitmap should now be created as 110 x 110 pixels and your content should be scaled by 1.1. This will make everything blurry :-( If you have a pixel ratio of 1.1 (100 CSS pixels = 110 device pixels), and you're displaying in a 100x100 box in CSS pixels, then you create a canvas of 110x110 pixels, so the backing store has the same resolution as the final device pixels. If you don't do that--if you create a 100x100 backing store and then display it in 100x100 CSS pixels--then nothing Canvas can do will prevent it from being blurry, because the backing store is being upscaled by 10% after it's already been drawn. -- Glenn Maynard
Re: [whatwg] Proposal: Adding methods like getElementById and getElementsByTagName to DocumentFragments
On Thu, Jul 25, 2013 at 9:05 AM, Boris Zbarsky bzbar...@mit.edu wrote: On 7/24/13 10:42 PM, Jussi Kalliokoski wrote: Argh, I had forgotten about live NodeLists. OK, this is a reason that resonates with me and justifies calling these methods obsolete. Too bad these methods are so badly flawed Fwiw, I think the performance impact of live NodeLists is ... unclear. Their existence does mean that you have to deal with DOM mutations changing the lists, but them being live also means you can make the list getters much faster in cases when the caller doesn't actually want the entire list. And, as importantly, it also means that for multiple consecutive calls to get the list, say inside of a loop, can return the same result object. I.e. you don't have to re-walk the DOM for every iteration through the loop. / Jonas
Re: [whatwg] Blurry lines in 2D Canvas (and SVG)
On Thu, Jul 25, 2013 at 1:28 PM, Glenn Maynard gl...@zewt.org wrote: On Thu, Jul 25, 2013 at 2:36 PM, Rik Cabanier caban...@gmail.com wrote: On Thu, Jul 25, 2013 at 7:05 AM, Glenn Maynard gl...@zewt.org wrote: On Thu, Jul 25, 2013 at 12:24 AM, Rik Cabanier caban...@gmail.comwrote: Yes, that's what I had in mind: the developer detects the device pixel ratio and scales up the canvas so the pixels match. That reduces to the simple case, then. The pixel ratio gets out of the picture entirely if you adjust the canvas so it's rendered 1:1 to pixels, so the rules for getting hard edges are the same (half-pixels for strokes, integer pixels for fills). Unfortunately, no. Let's say you have a device pixel ratio of 1.1 and a canvas of 100x100px. The underlying canvas bitmap should now be created as 110 x 110 pixels and your content should be scaled by 1.1. This will make everything blurry :-( If you have a pixel ratio of 1.1 (100 CSS pixels = 110 device pixels), and you're displaying in a 100x100 box in CSS pixels, then you create a canvas of 110x110 pixels, so the backing store has the same resolution as the final device pixels. You still need the scale though, otherwise the canvas content isn't zoomed (which is what the user requested) If you don't do that--if you create a 100x100 backing store and then display it in 100x100 CSS pixels--then nothing Canvas can do will prevent it from being blurry, because the backing store is being upscaled by 10% after it's already been drawn. Correct. Any scaling to the Canvas bitmap is not something that you can control when you draw the pixels.
Re: [whatwg] URL resolution of fragment urls in html5 webapps
On Thu, Jul 18, 2013 at 8:42 AM, Igor Minar imi...@google.com wrote: On Thu, Jul 18, 2013 at 2:13 AM, Jonas Sicking jo...@sicking.cc wrote: On Wed, Jul 10, 2013 at 10:24 AM, Alex Russell slightly...@google.com wrote: hey Igor, Was just discussing this with Rafael, and it seems like the core issue you're flagging is that if a document has a base element, all #anchor navigations (which would otherwise be document relative) are now full-page navigations to the URL specified in the base, not the document's natural URL. Is that right? If so, we might be able give you some control over this in the Navigation Controller (although it's not currently scoped as many folks didn't want to contemplate in-document navigation for the time being). But perhaps we don't need to do that: is the current behavior the same across browsers? If it's not, we might be able to change the spec. If it is, it'll be harder. I really don't want to add something to the navigation controller specifically for this unless we can show that this is a common use case. Navigation controller is hairy enough as it is without trying to toss in edge cases into it in at least the first version. Igor: I don't quite understand the problem that you are running in to. Can you provide an example which includes URLs of the initial document url, the url that you pass to pushState (including if it's relative or absolute), the value in base (again, including if it's relative or absolute). pushState is actually not even needed to reproduce the same problem. It's enough when the base[href] doesn't match the url of the current document. Check out this simple document: - code+preview: http://plnkr.co/edit/TtH7rjQVKU6qN0QOxULW?p=preview - preview only: http://run.plnkr.co/bY3fF8OOXKq5MrSu/ pushState is just an easy way how you can get into situation where the url of the current document changes, and base[href] prevents all in-document links to resolve correctly. I still don't understand how pushState plays into this. And the example doesn't use pushstate so it doesn't help with answering that question. Note that pushState also should update the page's baseURI. But yes, base can easily mess up all your #foo links. / Jonas / Jonas On Wed, Jul 10, 2013 at 7:11 AM, Igor Minar imi...@google.com wrote: The current url resolution as described http://www.whatwg.org/specs/web-apps/current-work/#resolving-urlsin the spec results in some unhelpful behavior when the following combination of web technologies are used in a client-side web app: - a combination of path-relative urls (a href=relative/url/to/somewherelink/a) and fragment/anchor urls (a href=#anchorUrllink/a) - history.pushState - used for deep-linking - base[href] - used to properly resolve the relative urls to the root of the application in various deployment environments Once history.pushState is used to change location.href, the path-relative urls resolve correctly as expected against the base[href], but anchor urls that are only useful if resolved against the current document.baseURI also unsurprisingly resolve against the base[href]. This behavior makes them unsuitable for this kind of applications which is a big loss in developers toolbox and in fact breaks existing web features like svg that depend on anchor urls to reference nodes in the current document. Does anyone have thoughts on how one could build a client-side app that can be deployed in various contexts without any special server-side templating or build-time pre-processing? The base element looks like a perfect solution for this, if only it didn't break anchor urls.
Re: [whatwg] Blurry lines in 2D Canvas (and SVG)
On Thu, Jul 25, 2013 at 3:49 PM, Rik Cabanier caban...@gmail.com wrote: You still need the scale though, otherwise the canvas content isn't zoomed (which is what the user requested) (We were talking about device pixel ratios, not zooming--user zooming scales the backing store, which is what we can't do anything about.) I think we're misunderstanding each other, but I'm not sure where. If you're on a 1.1x device, a 100x100 CSS pixel (px) box has 110x100 physical pixels. To draw cleanly into that box, you create a canvas with a 110x110 pixel backing store, and display it in the 100x100px region, eg. canvas width=110 height=110 style=width: 100px; height: 100px; You don't do any scaling within the 2d canvas itself, you just draw to it like a 110x110-pixel canvas. -- Glenn Maynard
Re: [whatwg] URL resolution of fragment urls in html5 webapps
On Thu, Jul 25, 2013 at 3:09 PM, Jonas Sicking jo...@sicking.cc wrote: On Thu, Jul 18, 2013 at 8:42 AM, Igor Minar imi...@google.com wrote: On Thu, Jul 18, 2013 at 2:13 AM, Jonas Sicking jo...@sicking.cc wrote: On Wed, Jul 10, 2013 at 10:24 AM, Alex Russell slightly...@google.com wrote: hey Igor, Was just discussing this with Rafael, and it seems like the core issue you're flagging is that if a document has a base element, all #anchor navigations (which would otherwise be document relative) are now full-page navigations to the URL specified in the base, not the document's natural URL. Is that right? If so, we might be able give you some control over this in the Navigation Controller (although it's not currently scoped as many folks didn't want to contemplate in-document navigation for the time being). But perhaps we don't need to do that: is the current behavior the same across browsers? If it's not, we might be able to change the spec. If it is, it'll be harder. I really don't want to add something to the navigation controller specifically for this unless we can show that this is a common use case. Navigation controller is hairy enough as it is without trying to toss in edge cases into it in at least the first version. Igor: I don't quite understand the problem that you are running in to. Can you provide an example which includes URLs of the initial document url, the url that you pass to pushState (including if it's relative or absolute), the value in base (again, including if it's relative or absolute). pushState is actually not even needed to reproduce the same problem. It's enough when the base[href] doesn't match the url of the current document. Check out this simple document: - code+preview: http://plnkr.co/edit/TtH7rjQVKU6qN0QOxULW?p=preview - preview only: http://run.plnkr.co/bY3fF8OOXKq5MrSu/ pushState is just an easy way how you can get into situation where the url of the current document changes, and base[href] prevents all in-document links to resolve correctly. I still don't understand how pushState plays into this. it's just an easy way how to get baseURI out of sync with the URI of the current document. as I said before, pushState is not even required to get into this situation. my demo app above proves that. And the example doesn't use pushstate so it doesn't help with answering that question. Note that pushState also should update the page's baseURI. it doesn't if base[href] is present. and that's the problem for html5 apps but again, the problem is more generic it just happens that html5 apps are the most affected. But yes, base can easily mess up all your #foo links. my point is that it shouldn't. fragment urls should always resolve the the uri of the current document which in all of these cases is different from baseURI. /i / Jonas / Jonas On Wed, Jul 10, 2013 at 7:11 AM, Igor Minar imi...@google.com wrote: The current url resolution as described http://www.whatwg.org/specs/web-apps/current-work/#resolving-urlsin the spec results in some unhelpful behavior when the following combination of web technologies are used in a client-side web app: - a combination of path-relative urls (a href=relative/url/to/somewherelink/a) and fragment/anchor urls (a href=#anchorUrllink/a) - history.pushState - used for deep-linking - base[href] - used to properly resolve the relative urls to the root of the application in various deployment environments Once history.pushState is used to change location.href, the path-relative urls resolve correctly as expected against the base[href], but anchor urls that are only useful if resolved against the current document.baseURI also unsurprisingly resolve against the base[href]. This behavior makes them unsuitable for this kind of applications which is a big loss in developers toolbox and in fact breaks existing web features like svg that depend on anchor urls to reference nodes in the current document. Does anyone have thoughts on how one could build a client-side app that can be deployed in various contexts without any special server-side templating or build-time pre-processing? The base element looks like a perfect solution for this, if only it didn't break anchor urls.
Re: [whatwg] URL resolution of fragment urls in html5 webapps
On Thu, Jul 25, 2013 at 4:04 PM, Igor Minar imi...@google.com wrote: On Thu, Jul 25, 2013 at 3:09 PM, Jonas Sicking jo...@sicking.cc wrote: On Thu, Jul 18, 2013 at 8:42 AM, Igor Minar imi...@google.com wrote: On Thu, Jul 18, 2013 at 2:13 AM, Jonas Sicking jo...@sicking.cc wrote: On Wed, Jul 10, 2013 at 10:24 AM, Alex Russell slightly...@google.com wrote: hey Igor, Was just discussing this with Rafael, and it seems like the core issue you're flagging is that if a document has a base element, all #anchor navigations (which would otherwise be document relative) are now full-page navigations to the URL specified in the base, not the document's natural URL. Is that right? If so, we might be able give you some control over this in the Navigation Controller (although it's not currently scoped as many folks didn't want to contemplate in-document navigation for the time being). But perhaps we don't need to do that: is the current behavior the same across browsers? If it's not, we might be able to change the spec. If it is, it'll be harder. I really don't want to add something to the navigation controller specifically for this unless we can show that this is a common use case. Navigation controller is hairy enough as it is without trying to toss in edge cases into it in at least the first version. Igor: I don't quite understand the problem that you are running in to. Can you provide an example which includes URLs of the initial document url, the url that you pass to pushState (including if it's relative or absolute), the value in base (again, including if it's relative or absolute). pushState is actually not even needed to reproduce the same problem. It's enough when the base[href] doesn't match the url of the current document. Check out this simple document: - code+preview: http://plnkr.co/edit/TtH7rjQVKU6qN0QOxULW?p=preview - preview only: http://run.plnkr.co/bY3fF8OOXKq5MrSu/ pushState is just an easy way how you can get into situation where the url of the current document changes, and base[href] prevents all in-document links to resolve correctly. I still don't understand how pushState plays into this. it's just an easy way how to get baseURI out of sync with the URI of the current document. as I said before, pushState is not even required to get into this situation. my demo app above proves that. And the example doesn't use pushstate so it doesn't help with answering that question. Note that pushState also should update the page's baseURI. it doesn't if base[href] is present. and that's the problem for html5 apps but again, the problem is more generic it just happens that html5 apps are the most affected. So it sounds like you are saying that: * Pages that use base href are affected * Pages that use pushState are affected if they also use base href Seems to me like the problem is more with base href than with pushState :) But yes, base can easily mess up all your #foo links. my point is that it shouldn't. fragment urls should always resolve the the uri of the current document which in all of these cases is different from baseURI. I could see the advantages with that, but it sounds awfully inconsistent. I'm not convinced that everyone that uses base href want that. In particular, both a href and base href are *really* old, so chances are that there are tons of pages out there that use both of them. So the risk of breakage of existing content seems huge. / Jonas /i / Jonas / Jonas On Wed, Jul 10, 2013 at 7:11 AM, Igor Minar imi...@google.com wrote: The current url resolution as described http://www.whatwg.org/specs/web-apps/current-work/#resolving-urlsin the spec results in some unhelpful behavior when the following combination of web technologies are used in a client-side web app: - a combination of path-relative urls (a href=relative/url/to/somewherelink/a) and fragment/anchor urls (a href=#anchorUrllink/a) - history.pushState - used for deep-linking - base[href] - used to properly resolve the relative urls to the root of the application in various deployment environments Once history.pushState is used to change location.href, the path-relative urls resolve correctly as expected against the base[href], but anchor urls that are only useful if resolved against the current document.baseURI also unsurprisingly resolve against the base[href]. This behavior makes them unsuitable for this kind of applications which is a big loss in developers toolbox and in fact breaks existing web features like svg that depend on anchor urls to reference nodes in the current document. Does anyone have thoughts on how one could build a client-side app that can be deployed in various contexts without any special server-side
Re: [whatwg] URL resolution of fragment urls in html5 webapps
On Thu, Jul 25, 2013 at 4:14 PM, Jonas Sicking jo...@sicking.cc wrote: On Thu, Jul 25, 2013 at 4:04 PM, Igor Minar imi...@google.com wrote: On Thu, Jul 25, 2013 at 3:09 PM, Jonas Sicking jo...@sicking.cc wrote: On Thu, Jul 18, 2013 at 8:42 AM, Igor Minar imi...@google.com wrote: On Thu, Jul 18, 2013 at 2:13 AM, Jonas Sicking jo...@sicking.cc wrote: On Wed, Jul 10, 2013 at 10:24 AM, Alex Russell slightly...@google.com wrote: hey Igor, Was just discussing this with Rafael, and it seems like the core issue you're flagging is that if a document has a base element, all #anchor navigations (which would otherwise be document relative) are now full-page navigations to the URL specified in the base, not the document's natural URL. Is that right? If so, we might be able give you some control over this in the Navigation Controller (although it's not currently scoped as many folks didn't want to contemplate in-document navigation for the time being). But perhaps we don't need to do that: is the current behavior the same across browsers? If it's not, we might be able to change the spec. If it is, it'll be harder. I really don't want to add something to the navigation controller specifically for this unless we can show that this is a common use case. Navigation controller is hairy enough as it is without trying to toss in edge cases into it in at least the first version. Igor: I don't quite understand the problem that you are running in to. Can you provide an example which includes URLs of the initial document url, the url that you pass to pushState (including if it's relative or absolute), the value in base (again, including if it's relative or absolute). pushState is actually not even needed to reproduce the same problem. It's enough when the base[href] doesn't match the url of the current document. Check out this simple document: - code+preview: http://plnkr.co/edit/TtH7rjQVKU6qN0QOxULW?p=preview - preview only: http://run.plnkr.co/bY3fF8OOXKq5MrSu/ pushState is just an easy way how you can get into situation where the url of the current document changes, and base[href] prevents all in-document links to resolve correctly. I still don't understand how pushState plays into this. it's just an easy way how to get baseURI out of sync with the URI of the current document. as I said before, pushState is not even required to get into this situation. my demo app above proves that. And the example doesn't use pushstate so it doesn't help with answering that question. Note that pushState also should update the page's baseURI. it doesn't if base[href] is present. and that's the problem for html5 apps but again, the problem is more generic it just happens that html5 apps are the most affected. So it sounds like you are saying that: * Pages that use base href are affected * Pages that use pushState are affected if they also use base href correct Seems to me like the problem is more with base href than with pushState :) yes But yes, base can easily mess up all your #foo links. my point is that it shouldn't. fragment urls should always resolve the the uri of the current document which in all of these cases is different from baseURI. I could see the advantages with that, but it sounds awfully inconsistent. I'm not convinced that everyone that uses base href want that. In particular, both a href and base href are *really* old, so chances are that there are tons of pages out there that use both of them. So the risk of breakage of existing content seems huge. As mentioned before, IE8 and 9 resolve urls just as I'm proposing, so I don't think that there are cross browser compatible apps that depend on the more consistent but less useful url resolution. /i / Jonas /i / Jonas / Jonas On Wed, Jul 10, 2013 at 7:11 AM, Igor Minar imi...@google.com wrote: The current url resolution as described http://www.whatwg.org/specs/web-apps/current-work/#resolving-urls in the spec results in some unhelpful behavior when the following combination of web technologies are used in a client-side web app: - a combination of path-relative urls (a href=relative/url/to/somewherelink/a) and fragment/anchor urls (a href=#anchorUrllink/a) - history.pushState - used for deep-linking - base[href] - used to properly resolve the relative urls to the root of the application in various deployment environments Once history.pushState is used to change location.href, the path-relative urls resolve correctly as expected against the base[href], but anchor urls that are only useful if resolved against the current document.baseURI also
Re: [whatwg] Blurry lines in 2D Canvas (and SVG)
On Thu, Jul 25, 2013 at 3:59 PM, Glenn Maynard gl...@zewt.org wrote: On Thu, Jul 25, 2013 at 3:49 PM, Rik Cabanier caban...@gmail.com wrote: You still need the scale though, otherwise the canvas content isn't zoomed (which is what the user requested) (We were talking about device pixel ratios, not zooming--user zooming scales the backing store, which is what we can't do anything about.) I think we're misunderstanding each other, but I'm not sure where. If you're on a 1.1x device, a 100x100 CSS pixel (px) box has 110x100 physical pixels. To draw cleanly into that box, you create a canvas with a 110x110 pixel backing store, and display it in the 100x100px region, eg. canvas width=110 height=110 style=width: 100px; height: 100px; You don't do any scaling within the 2d canvas itself, you just draw to it like a 110x110-pixel canvas. We're getting a bit off track here :-) No, you need to scale, otherwise the content of your canvas won't scale up. For instance, if you have a 100x100 device pixel rect, it has to become a 110x110 device pixel rect if you zoom by 10%
