Re: [whatwg] Blurry lines in 2D Canvas (and SVG)

[Glenn Maynard]

On Thu, Jul 25, 2013 at 12:24 AM, Rik Cabanier  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

[Boris Zbarsky]

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

[Boris Zbarsky]

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

[Boris Zbarsky]

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

[whatwg] [CSSWG][css-counter-styles] LCWD of CSS Counter Styles

[Tab Atkins Jr.]

The CSS WG has published a Last Call Working Draft of CSS Counter
Styles Level 3:

http://www.w3.org/TR/css-counter-styles-3/

This specification better defines the existing 'list-style-type'
values that were introduced in CSS 2 and 2.1, and defines a few new
styles for certain complex numbering systems that were not well served
previously.

Additionally, it defines the @counter-style rule, which allows authors
to define their own counter styles for use in 'list-style-type' andthe
 "counter()" and "counters()" functions.  The I18N Working Group is
now maintaining a list of example counter styles for many of the
world's numbering systems at
.

The CSSWG would appreciate feedback on this module, particularly on
the aspects changed since the previous working draft:

* technical feedback on any mistakes in the algorithms in the specs,
or the predefined counter styles
* feedback on the new 'pad' and 'speak-as' descriptors

Significant changes are listed at:

  http://www.w3.org/TR/2013/WD-css-counter-styles-3-20130718/#changes

Please send any comments to this mailing list, , and
please, prefix the subject line with

[css-counter-styles]

(as I did on this message).

For the CSS WG,
Tab Atkins

Re: [whatwg] URL: file URL "C|" quirk

[Chris Weber]

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)

[Rik Cabanier]

On Thu, Jul 25, 2013 at 7:05 AM, Glenn Maynard  wrote:

> On Thu, Jul 25, 2013 at 12:24 AM, Rik Cabanier  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)

[Kevin Marks]

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"  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)

[Glenn Maynard]

On Thu, Jul 25, 2013 at 2:36 PM, Rik Cabanier  wrote:

> On Thu, Jul 25, 2013 at 7:05 AM, Glenn Maynard  wrote:
>
>> On Thu, Jul 25, 2013 at 12:24 AM, Rik Cabanier 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 :-(
>

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

[Jonas Sicking]

On Thu, Jul 25, 2013 at 9:05 AM, Boris Zbarsky  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)

[Rik Cabanier]

On Thu, Jul 25, 2013 at 1:28 PM, Glenn Maynard  wrote:

> On Thu, Jul 25, 2013 at 2:36 PM, Rik Cabanier  wrote:
>
>> On Thu, Jul 25, 2013 at 7:05 AM, Glenn Maynard  wrote:
>>
>>> On Thu, Jul 25, 2013 at 12:24 AM, Rik Cabanier 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
>> :-(
>>
>
> 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

[Jonas Sicking]

On Thu, Jul 18, 2013 at 8:42 AM, Igor Minar  wrote:
>
>
>
> On Thu, Jul 18, 2013 at 2:13 AM, Jonas Sicking  wrote:
>>
>> On Wed, Jul 10, 2013 at 10:24 AM, Alex Russell 
>> 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  element, all #anchor
>> > navigations (which would otherwise be document relative) are now
>> > full-page
>> > navigations to the URL specified in the , 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  (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,  can easily mess up all your #foo links.

/ Jonas

>>
>>
>> / Jonas
>>
>> > On Wed, Jul 10, 2013 at 7:11 AM, Igor Minar  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 (> >> href="relative/url/to/somewhere">link) and fragment/anchor urls (> >> href="#anchorUrl">link)
>> >> - 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)

[Glenn Maynard]

On Thu, Jul 25, 2013 at 3:49 PM, Rik Cabanier  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.



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

[Igor Minar]

On Thu, Jul 25, 2013 at 3:09 PM, Jonas Sicking  wrote:

> On Thu, Jul 18, 2013 at 8:42 AM, Igor Minar  wrote:
> >
> >
> >
> > On Thu, Jul 18, 2013 at 2:13 AM, Jonas Sicking  wrote:
> >>
> >> On Wed, Jul 10, 2013 at 10:24 AM, Alex Russell 
> >> 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  element, all
> #anchor
> >> > navigations (which would otherwise be document relative) are now
> >> > full-page
> >> > navigations to the URL specified in the , 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  (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,  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 
> 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 ( >> >> href="relative/url/to/somewhere">link) and fragment/anchor urls
> ( >> >> href="#anchorUrl">link)
> >> >> - 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

[Jonas Sicking]

On Thu, Jul 25, 2013 at 4:04 PM, Igor Minar  wrote:
>
> On Thu, Jul 25, 2013 at 3:09 PM, Jonas Sicking  wrote:
>>
>> On Thu, Jul 18, 2013 at 8:42 AM, Igor Minar  wrote:
>> >
>> >
>> >
>> > On Thu, Jul 18, 2013 at 2:13 AM, Jonas Sicking  wrote:
>> >>
>> >> On Wed, Jul 10, 2013 at 10:24 AM, Alex Russell 
>> >> 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  element, all
>> >> > #anchor
>> >> > navigations (which would otherwise be document relative) are now
>> >> > full-page
>> >> > navigations to the URL specified in the , 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  (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  are affected
* Pages that use pushState are affected if they also use 

Seems to me like the problem is more with  than with pushState :)

>> But yes,  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 
want that. In particular, both  and  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 
>> >> > 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 (> >> >> href="relative/url/to/somewhere">link) and fragment/anchor urls
>> >> >> (> >> >> href="#anchorUrl">link)
>> >> >> - 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
>> >> >> 

Re: [whatwg] URL resolution of fragment urls in html5 webapps

[Igor Minar]

On Thu, Jul 25, 2013 at 4:14 PM, Jonas Sicking  wrote:

> On Thu, Jul 25, 2013 at 4:04 PM, Igor Minar  wrote:
> >
> > On Thu, Jul 25, 2013 at 3:09 PM, Jonas Sicking  wrote:
> >>
> >> On Thu, Jul 18, 2013 at 8:42 AM, Igor Minar  wrote:
> >> >
> >> >
> >> >
> >> > On Thu, Jul 18, 2013 at 2:13 AM, Jonas Sicking 
> 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  element, all
> >> >> > #anchor
> >> >> > navigations (which would otherwise be document relative) are now
> >> >> > full-page
> >> >> > navigations to the URL specified in the , 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  (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  are affected
> * Pages that use pushState are affected if they also use 
>

correct


> Seems to me like the problem is more with  than with pushState
> :)
>

yes


>
> >> But yes,  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 
> want that. In particular, both  and  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 
> >> >> > 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 ( >> >> >> href="relative/url/to/somewhere">link) and fragment/anchor
> urls
> >> >> >> ( >> >> >> href="#anchorUrl">link)
> >> >> >> - history.pushState - used for deep-linking
> >> >> >> - base[href] - used to properly resolve the relative 

Re: [whatwg] Blurry lines in 2D Canvas (and SVG)

[Rik Cabanier]

On Thu, Jul 25, 2013 at 3:59 PM, Glenn Maynard  wrote:

> On Thu, Jul 25, 2013 at 3:49 PM, Rik Cabanier  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.
>
> 
>
> 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%