Re: [whatwg] URL spec and IDN
On Wed, Feb 19, 2014 at 11:53 PM, Joshua Cranmer pidgeo...@verizon.net wrote: I've noted that the URL specification is currently rather vague when it comes to IDN, and has some uncertain comments about issues related to IDNA2003, IDNA2008, and UTS #46. Yeah, it is a clusterfuck. I'm working with the guys behind UTS #46 on cleaning it up, but due to vacation et al it's taking some time. Roughly speaking, in my experience, there are three kinds of labels: A-labels, U-labels, and displayable U-labels. A-labels are the Punycode-encoded version of the labels used for DNS (normalized to ASCII lower-case, naturally). U-labels are the results of converting an A-label to Unicode. Displayable U-labels are A-labels converted to U-labels only if they do not contain a Unicode homograph attack. My drawing a distinction between the displayable U-label and the regular kind is out of concern that the definition of displayable may change over time (e.g., certain script combinations are newly permitted/prohibited), whereas the U-label derived from an A-label should be constant. Agreed. At some point we should make this clearer in the specification. Given these three kinds of labels, it ought to be possible (IMO) to convert a generic domain in any (i.e., unnormalized) format. The specification currently provides for a domainToASCII and a domainToUnicode function which naturally map to producing A-labels and U-labels, but contains a note suggesting that they shouldn't be implemented due to the IDNA clusterfuck. The way to a displayable U-label would seem to me to come most naturally via |new URL(http://; + domain).host|. No, we should have a dedicated domainToUI() or some such. A parsed URL contains A-labels. We might want to have something similar for URLs themselves. To convert percent-encoding and such. Looking at the spec, it's not clear if the host, href, and other methods are supposed to return U-labels or A-labels (or some potential mix of the two). It's A-labels, see http://url.spec.whatwg.org/#concept-host-parser for details. I'm guessing the reason why the domainTo* methods are unspecified are due to inconsistent handling of IDNA2008 by current web browsers, ... Right. * Chrome's documentation calls out ignoring STD3 rules (i.e., permitting more ASCII characters) and disallowing unassigned code points. IE's documentation does not suggest what they do here. You want to allow e.g. _ as that is used by subdomains. However, if you ignore STD3, you need additional checks later on to prevent reparsing issues. The URL Standard calls out the specific code points that are problematic here. 1. Expressly identify how to normalize and process an IDN address under IDNA2008 + UTR #46 + other modifications that reflects reality. I'm not qualified to know what happens at precise edge cases here. Yeah this is the plan, once UTR #46 has some changes I proposed. See http://www.unicode.org/review/pri264/ if you're interested. 2. Resolve that URL should reflect U-labels as much as possible while placing the burden of avoiding Unicode homograph attacks on the browser implementors rather than JS consumers of the API. Currently it's A-labels. Mostly because all other parts of the URL are ASCII too. -- http://annevankesteren.nl/
Re: [whatwg] Checksum for external resources
On Tue, Mar 11, 2014 at 2:23 PM, Eduardo Robles Elvira edu...@agoravoting.com wrote: I propose that external resources can be hashed. Before you jump on me, I know that this has been proposed in the past but I think it's that time of the year to propose it again. You want to look at http://w3c.github.io/webappsec/specs/subresourceintegrity/ I think. -- http://annevankesteren.nl/
Re: [whatwg] Checksum for external resources
On 17/03/14 12:37, Anne van Kesteren wrote: On Tue, Mar 11, 2014 at 2:23 PM, Eduardo Robles Elvira edu...@agoravoting.com wrote: I propose that external resources can be hashed. Before you jump on me, I know that this has been proposed in the past but I think it's that time of the year to propose it again. You want to look at http://w3c.github.io/webappsec/specs/subresourceintegrity/ I think. Hello Anne: Thanks! It's exactly what I wanted, with the same examples and rationale and the same kind of solution but already written as a much more formal and more elaborated proposal. Regards, -- Eduardo Robles Elvira, +34 668 824 393, https://agoravoting.com
[whatwg] type=month-day
As a heads up, Mozilla is considering an experimental implementation of month-day (mobile only so far) for entering birthdays and such: https://bugzilla.mozilla.org/show_bug.cgi?id=974341 However, it might be even better for birthdays if the year part became optional rather than always omitted. Original motivation is here http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-August/027725.html by Tantek Çelik. Do other vendors have any thoughts here? -- http://annevankesteren.nl/
Re: [whatwg] Notifications: createTime property
On Fri, Feb 14, 2014 at 10:25 PM, Michael Henretty michael.henre...@gmail.com wrote: Also, most (if not all) platforms will timestamp the notification message anyway for use in its display. Here it would be nice if both the platform and originating content had access to this same timestamp data, so that any displayed dates or date logic could be in sync. Are there drawbacks/complexities I'm not thinking about here? It seems like just keeping around another field on the notification. Seems alright to me. Any thoughts from other vendors? -- http://annevankesteren.nl/
Re: [whatwg] [Canvas] Behavior on non-invertable CTM
On Fri, Mar 14, 2014 at 4:50 PM, Ian Hickson i...@hixie.ch wrote: On Fri, 7 Feb 2014, Justin Novosad wrote: Current text: If the point (x0, y0) is equal to the point (x1, y1), or if the point (x1, y1) is equal to the point (x2, y2), or if both radiusX and radiusY are zero, then the method must add the point (x1, y1) to the subpath, and connect that point to the previous point (x0, y0) by a straight line. With arcTo, the first point (x0, y0) may have been added to the current subpath using a different CTM. So to bring it into the local space of the current primitive, we need an invertible CTM. What I don't understand is why you can't draw the curve in the transformed space instead of the 1:1 coordinate space. You have to transform it eventually, right? And the points will end up simply transformed. So you can easily compare the points in the transformed space. All the transforms are affine, so what's a straight line isn't impacted. Can't you just draw the transformed arc instead of first drawing the circular arc and then transforming it? Maybe what I'm saying is obviously dumb for some reason, but I'm not understanding why, if so... (not that I'm a graphics guy, obviously. Hmmm, I gave this a bit more thought... To apply the construction algorithm in transformed space, the ellipse parameters (radiusX, radiusY, rotation) would have to be transformed. Transforming the parameters would be intractable under a projective transform (e.g. perspective), but since we are limitted to affine transforms, it can be done. Now, in the case of a non-invertible CTM, we would end up with radiusX or radiusY or both equal to zero. And what happens when you have that? Your arcTo just turned into lineTo(x1, y1). Tada! -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] [Canvas] Behavior on non-invertable CTM
On Mar 17, 2014, at 3:49 PM, Justin Novosad ju...@google.com wrote: On Fri, Mar 14, 2014 at 4:50 PM, Ian Hickson i...@hixie.ch wrote: On Fri, 7 Feb 2014, Justin Novosad wrote: Current text: If the point (x0, y0) is equal to the point (x1, y1), or if the point (x1, y1) is equal to the point (x2, y2), or if both radiusX and radiusY are zero, then the method must add the point (x1, y1) to the subpath, and connect that point to the previous point (x0, y0) by a straight line. With arcTo, the first point (x0, y0) may have been added to the current subpath using a different CTM. So to bring it into the local space of the current primitive, we need an invertible CTM. What I don't understand is why you can't draw the curve in the transformed space instead of the 1:1 coordinate space. You have to transform it eventually, right? And the points will end up simply transformed. So you can easily compare the points in the transformed space. All the transforms are affine, so what's a straight line isn't impacted. Can't you just draw the transformed arc instead of first drawing the circular arc and then transforming it? Maybe what I'm saying is obviously dumb for some reason, but I'm not understanding why, if so... (not that I'm a graphics guy, obviously. Hmmm, I gave this a bit more thought... To apply the construction algorithm in transformed space, the ellipse parameters (radiusX, radiusY, rotation) would have to be transformed. Transforming the parameters would be intractable under a projective transform (e.g. perspective), but since we are limitted to affine transforms, it can be done. Now, in the case of a non-invertible CTM, we would end up with radiusX or radiusY or both equal to zero. And what happens when you have that? Your arcTo just turned into lineTo(x1, y1). Tada! Why does radiusX or radiusY need to be zero? Because you define it that way for a non-invertible matrix? That makes sense for scale(0,0). What about infinity or NaN? If Ian didn’t update the spec then this is still undefined and therefore up to the UA to decide. Greetings, Dirk -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] [Canvas] Behavior on non-invertable CTM
On Mon, Mar 17, 2014 at 8:45 AM, Justin Novosad ju...@google.com wrote: On Mon, Mar 17, 2014 at 11:35 AM, Dirk Schulze dschu...@adobe.com wrote: Hmmm, I gave this a bit more thought... To apply the construction algorithm in transformed space, the ellipse parameters (radiusX, radiusY, rotation) would have to be transformed. Transforming the parameters would be intractable under a projective transform (e.g. perspective), but since we are limitted to affine transforms, it can be done. Now, in the case of a non-invertible CTM, we would end up with radiusX or radiusY or both equal to zero. And what happens when you have that? Your arcTo just turned into lineTo(x1, y1). Tada! Why does radiusX or radiusY need to be zero? Because you define it that way for a non-invertible matrix? That makes sense for scale(0,0). What about infinity or NaN? If Ian didn't update the spec then this is still undefined and therefore up to the UA to decide. Oh yeah, I was totally forgetting about singularities caused by non-finite values. Could we just the same agree to resolve that case by treating arcTo as lineTo(x1, y1) in the case of a non-invertible CTM? Or do you think there is a more logical thing to do? Make a clean cut and define that drawing operators are ignored when there's a non-invertible matrix.
Re: [whatwg] [Canvas] Behavior on non-invertable CTM
On Mon, Mar 17, 2014 at 12:59 PM, Rik Cabanier caban...@gmail.com wrote: On Mon, Mar 17, 2014 at 8:45 AM, Justin Novosad ju...@google.com wrote: On Mon, Mar 17, 2014 at 11:35 AM, Dirk Schulze dschu...@adobe.com wrote: Hmmm, I gave this a bit more thought... To apply the construction algorithm in transformed space, the ellipse parameters (radiusX, radiusY, rotation) would have to be transformed. Transforming the parameters would be intractable under a projective transform (e.g. perspective), but since we are limitted to affine transforms, it can be done. Now, in the case of a non-invertible CTM, we would end up with radiusX or radiusY or both equal to zero. And what happens when you have that? Your arcTo just turned into lineTo(x1, y1). Tada! Why does radiusX or radiusY need to be zero? Because you define it that way for a non-invertible matrix? That makes sense for scale(0,0). What about infinity or NaN? If Ian didn’t update the spec then this is still undefined and therefore up to the UA to decide. Oh yeah, I was totally forgetting about singularities caused by non-finite values. Could we just the same agree to resolve that case by treating arcTo as lineTo(x1, y1) in the case of a non-invertible CTM? Or do you think there is a more logical thing to do? Make a clean cut and define that drawing operators are ignored when there's a non-invertible matrix. I could totally go for that, but you are talking about going back on the spec of a feature that has shipped, as opposed to clarifying edges cases. Maybe that would be fine in this case though...
Re: [whatwg] [Canvas] Behavior on non-invertable CTM
On Mon, Mar 17, 2014 at 10:18 AM, Justin Novosad ju...@google.com wrote:
On Mon, Mar 17, 2014 at 12:59 PM, Rik Cabanier caban...@gmail.com wrote:
On Mon, Mar 17, 2014 at 8:45 AM, Justin Novosad ju...@google.com wrote:
On Mon, Mar 17, 2014 at 11:35 AM, Dirk Schulze dschu...@adobe.com
wrote:
Hmmm, I gave this a bit more thought... To apply the construction
algorithm in transformed space, the ellipse parameters (radiusX,
radiusY,
rotation) would have to be transformed. Transforming the parameters
would
be intractable under a projective transform (e.g. perspective), but
since
we are limitted to affine transforms, it can be done. Now, in the
case
of
a non-invertible CTM, we would end up with radiusX or radiusY or both
equal
to zero. And what happens when you have that? Your arcTo just
turned
into
lineTo(x1, y1). Tada!
Why does radiusX or radiusY need to be zero? Because you define it that
way for a non-invertible matrix? That makes sense for scale(0,0). What
about infinity or NaN? If Ian didn't update the spec then this is still
undefined and therefore up to the UA to decide.
Oh yeah, I was totally forgetting about singularities caused by
non-finite
values. Could we just the same agree to resolve that case by treating
arcTo as lineTo(x1, y1) in the case of a non-invertible CTM? Or do you
think there is a more logical thing to do?
Make a clean cut and define that drawing operators are ignored when
there's a non-invertible matrix.
I could totally go for that, but you are talking about going back on the
spec of a feature that has shipped, as opposed to clarifying edges cases.
Maybe that would be fine in this case though...
I'm unsure if anyone has shipped that part of the spec. There's certainly
no interop...
Looking at the implementation in Blink and WebKit, all of the drawing
methods and fill/stroke/clip start with:
if (!isTransformInvertible())
return;
At first glance, Firefox seems to do what the spec says (which results in
slow double transforming of all coordinates) but then they punt as well:
Matrix inverse = mTarget-GetTransform();
if (!inverse.Invert()) {
NS_WARNING(Could not invert transform);
return;
}
So, what we could say is:
- when drawing paths, ignore all calls if the matrix is non-invertible
(WebKit and Blink do this)
- when filling/stroking/clipping, ignore all calls if the matrix is
non-invertible (Firefox, WebKit and Blink do this)
Re: [whatwg] Proposal: Locale Preferences API
On Tue, 17 Dec 2013, Mark Callow wrote: On 2013/10/15 6:24, Marcos Caceres wrote: On Friday, July 26, 2013 at 8:14 PM, Marcos Caceres wrote: This document proposes an extension to HTML's `Navigator` interface to enable dynamic localization of content. The idea is to expose to script the language tags that represents the user's locale preferences (akin to the language tags that are normally sent with HTTP's `Accept-Languages` header). My question is will anyone use it? In my experience most web sites ignore the Accept-Languages header. I am continually being served pages in Japanese even though English is the top language in my accept list. It's a good question. There are only two reasons I can think of for this happening: * sites are choosing the language based on the location of my IP address. This is almost certainly the cause. * sites are choosing the language based on my OS locale setting. though I'm pretty sure I've been served Japanese pages on systems where it is not set to JA plus I don't know if that is visible to either server or application. I don't think this is visible to the page currently, except indirectly via navigator.language, so if your browser is configured to only report English, that's all the page should see. The feature requested in this thread did end up being added to the spec: http://whatwg.org/html#language-preferences It's basically just an array version of navigator.language, and the spec suggests using the same list as for Accept-Language, so it doesn't really provide anything new, it's just more convenient. It's true that Accept-Language doesn't seem to have been widely used. The feature was primarily added due to requests from implementors. I don't know what we can do to cause authors to rely on this API and its siblings rather than on IP geolocation. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] inverse property mechanism for Microdata?
Hi Ian, HTML people, On 31 January 2014 23:45, Ian Hickson i...@hixie.ch wrote: On Fri, 31 Jan 2014, Dan Brickley wrote: We'd (schema.org 'we') like to make a public proposal to update Microdata with a syntax for expressing inverse properties/relationships. [...] Here's an example with 'containedIn'. The idea is that we want to express that the LocalBusiness (i.e. Place) Entity B is 'containedIn' Entity A. The example I show here expresses the reverse, incorrectly. So we're looking for a change to the markup that would turn this example into one that said The LocalBusiness Entity B is containedIn the LocalBusiness Entity A: div itemscope itemtype=http://schema.org/LocalBusiness; h1span itemprop=name(Entity A) Beachwalk Beachwear Giftware/span/h1 span itemprop=description A superb collection of fine gifts and clothing to accent your stay in Mexico Beach./span Phone: span itemprop=telephone850-648-4200/span div itemprop=containedIn itemscope itemtype=http://schema.org/LocalBusiness; h2span itemprop=name(Entity B) The tiny store within a store/span/h2 span itemprop=description A superb collection of tiny clothes, from the store within the store./span Phone: span itemprop=telephone123-456-7890/span /div /div This is actually possible today: div itemscope itemtype=http://schema.org/LocalBusiness; id=a itemprop=containedIn h1span itemprop=name(Entity A) Beachwalk Beachwear Giftware/span/h1 span itemprop=description A superb collection of fine gifts and clothing to accent your stay in Mexico Beach./span Phone: span itemprop=telephone850-648-4200/span div itemscope itemref=a itemtype=http://schema.org/LocalBusiness; h2span itemprop=name(Entity B) The tiny store within a store/span/h2 span itemprop=description A superb collection of tiny clothes, from the store within the store./span Phone: span itemprop=telephone123-456-7890/span /div /div The trick here is to turn the inner item into the top-level microdata item, and use itemref= to have that inner item point to the outer item. You're right; it is indeed possible. However it is perhaps a little too clever. I've tried it on a few colleagues, and it didn't 'click' with anyone yet. We discussed this (and the -inv suggestion) at schema.org again, and the consensus there was that we'd like to have the search engines proceed with accepting an experimental/proposed 'inverse itemprop' attribute, rather than work around its absence. (This works great unless you want two items to refer to the same third item using different properties, but that's something microdata can't do in general, since it's based on a tree structure, not a graph structure. To address that particular problem, you need a vocabulary that defines how itemid= works; at that point, you can just have the same underlying item represented as multiple microdata items in the document by having all the items share the same ID. But how exactly that is to be interpreted is something the vocabulary has to define.) One response is that the markup could be reorganized. That's basically what the above does, but without moving the elements around in the DOM. (itemref= is basically all about making the microdata model work around constraints coming from the author's preferred DOM.) (Yup.) Another reasonable response to this is 'well, perhaps you should have a property (instead or in addition) called geospatiallyContains, or containerOf or contains, or rev_containedIn for this usage scenario'? That is another option, similar to the parenthetical itemid= note above -- you could just have the vocabulary define that for every property whose value is an item, the item type that that property can point to has another property with the same name plus a fixed suffix, like -inv, that inverses the relationship. That would make the above look like: div itemscope itemtype=http://schema.org/LocalBusiness; h1span itemprop=name(Entity A) Beachwalk Beachwear Giftware/span/h1 span itemprop=description A superb collection of fine gifts and clothing to accent your stay in Mexico Beach./span Phone: span itemprop=telephone850-648-4200/span div itemprop=containedIn-inv itemscope itemtype=http://schema.org/LocalBusiness; h2span itemprop=name(Entity B) The tiny store within a store/span/h2 span itemprop=description A superb collection of tiny clothes, from the store within the store./span Phone: span itemprop=telephone123-456-7890/span /div /div This is easier to understand than itemref, but still involves creating 100s of additional properties instead of just one new piece of syntax. We have tried this and in a few cases we have included pairs of inverse properties in schema.org, e.g. we have alumni and an inverse, alumniOf. In designing schemas we have found it consistently
Re: [whatwg] [Canvas] Behavior on non-invertable CTM
On Mon, Mar 17, 2014 at 2:06 PM, Rik Cabanier caban...@gmail.com wrote:
Make a clean cut and define that drawing operators are ignored when
there's a non-invertible matrix.
I could totally go for that, but you are talking about going back on the
spec of a feature that has shipped, as opposed to clarifying edges cases.
Maybe that would be fine in this case though...
I'm unsure if anyone has shipped that part of the spec. There's certainly
no interop...
Plenty of browser have shipped drawing paths to canvas. I agree about the
no interop part. It is the main reason I think it may still be acceptable
to redefine the spec.
Looking at the implementation in Blink and WebKit, all of the drawing
methods and fill/stroke/clip start with:
if (!isTransformInvertible())
return;
At first glance, Firefox seems to do what the spec says (which results in
slow double transforming of all coordinates) but then they punt as well:
Matrix inverse = mTarget-GetTransform();
if (!inverse.Invert()) {
NS_WARNING(Could not invert transform);
return;
}
So, what we could say is:
- when drawing paths, ignore all calls if the matrix is non-invertible
(WebKit and Blink do this)
- when filling/stroking/clipping, ignore all calls if the matrix is
non-invertible (Firefox, WebKit and Blink do this)
Yes, but there is still an issue that causes problems in Blink/WebKit:
because the canvas rendering context stores its path in local
(untransformed) space, whenever the CTM changes, the path needs to be
transformed to follow the new local spcae. This transform requires the CTM
to be invertible. So now webkit and blink have a bug that causes all
previously recorded parts of the current path to be discarded when the CTM
becomes non-invertible (even if it is only temporarily non-invertible, even
if the current path is not even touched while the matrix is
non-invertible). I have a fix in flight that fixes that problem in Blink by
storing the current path in transformed coordinates instead. I've had the
fix on the back burner pending the outcome of this thread.
Re: [whatwg] [Canvas] Behavior on non-invertable CTM
On Mar 17, 2014, at 9:23 PM, Justin Novosad ju...@google.com wrote:
On Mon, Mar 17, 2014 at 2:06 PM, Rik Cabanier caban...@gmail.com wrote:
Make a clean cut and define that drawing operators are ignored when there's a
non-invertible matrix.
I could totally go for that, but you are talking about going back on the spec
of a feature that has shipped, as opposed to clarifying edges cases. Maybe
that would be fine in this case though...
I'm unsure if anyone has shipped that part of the spec. There's certainly no
interop...
Plenty of browser have shipped drawing paths to canvas. I agree about the no
interop part. It is the main reason I think it may still be acceptable to
redefine the spec.
Looking at the implementation in Blink and WebKit, all of the drawing methods
and fill/stroke/clip start with:
if (!isTransformInvertible())
return;
At first glance, Firefox seems to do what the spec says (which results in
slow double transforming of all coordinates) but then they punt as well:
Matrix inverse = mTarget-GetTransform();
if (!inverse.Invert()) {
NS_WARNING(Could not invert transform);
return;
}
So, what we could say is:
- when drawing paths, ignore all calls if the matrix is non-invertible
(WebKit and Blink do this)
- when filling/stroking/clipping, ignore all calls if the matrix is
non-invertible (Firefox, WebKit and Blink do this)
Yes, but there is still an issue that causes problems in Blink/WebKit:
because the canvas rendering context stores its path in local (untransformed)
space, whenever the CTM changes, the path needs to be transformed to follow
the new local spcae. This transform requires the CTM to be invertible. So
now webkit and blink have a bug that causes all previously recorded parts of
the current path to be discarded when the CTM becomes non-invertible (even if
it is only temporarily non-invertible, even if the current path is not even
touched while the matrix is non-invertible). I have a fix in flight that
fixes that problem in Blink by storing the current path in transformed
coordinates instead. I've had the fix on the back burner pending the outcome
of this thread.
Are you sure about this? The path should stay untouched during the time the CTM
is not invertible. At least in WebKit I can not remember that I see the path
discarded. As Rik quoted in the code snippet, we just return silently and do
not touch the path and avoid daring operations.
Greetings,
Dirk
Re: [whatwg] [Canvas] Behavior on non-invertable CTM
On Mon, Mar 17, 2014 at 1:23 PM, Justin Novosad ju...@google.com wrote:
On Mon, Mar 17, 2014 at 2:06 PM, Rik Cabanier caban...@gmail.com wrote:
Make a clean cut and define that drawing operators are ignored when
there's a non-invertible matrix.
I could totally go for that, but you are talking about going back on
the spec of a feature that has shipped, as opposed to clarifying edges
cases. Maybe that would be fine in this case though...
I'm unsure if anyone has shipped that part of the spec. There's certainly
no interop...
Plenty of browser have shipped drawing paths to canvas. I agree about the
no interop part. It is the main reason I think it may still be acceptable
to redefine the spec.
Sure, but no one implemented transforming of the path as the spec
describes. At the time the drawing operation happens, all browsers have the
path in the local CTM.
Looking at the implementation in Blink and WebKit, all of the drawing
methods and fill/stroke/clip start with:
if (!isTransformInvertible())
return;
At first glance, Firefox seems to do what the spec says (which results in
slow double transforming of all coordinates) but then they punt as well:
Matrix inverse = mTarget-GetTransform();
if (!inverse.Invert()) {
NS_WARNING(Could not invert transform);
return;
}
So, what we could say is:
- when drawing paths, ignore all calls if the matrix is non-invertible
(WebKit and Blink do this)
- when filling/stroking/clipping, ignore all calls if the matrix is
non-invertible (Firefox, WebKit and Blink do this)
Yes, but there is still an issue that causes problems in Blink/WebKit:
because the canvas rendering context stores its path in local
(untransformed) space, whenever the CTM changes, the path needs to be
transformed to follow the new local spcae. This transform requires the CTM
to be invertible. So now webkit and blink have a bug that causes all
previously recorded parts of the current path to be discarded when the CTM
becomes non-invertible (even if it is only temporarily non-invertible, even
if the current path is not even touched while the matrix is
non-invertible).
This was something that was introduced by the Blink team after they
branched.
WebKit doesn't do this flagging so if a non-invertible matrix is reset, the
old path will still be around.
I have a fix in flight that fixes that problem in Blink by storing the
current path in transformed coordinates instead. I've had the fix on the
back burner pending the outcome of this thread.
That seems like an expensive solution because this causes the coordinates
to be transformed twice.
Why not store the matrix that was applied to the path coordinates and use
that to undo the transformation?
Re: [whatwg] inverse property mechanism for Microdata?
On Mon, 17 Mar 2014, Dan Brickley wrote: We discussed this (and the -inv suggestion) at schema.org again, and the consensus there was that we'd like to have the search engines proceed with accepting an experimental/proposed 'inverse itemprop' attribute, rather than work around its absence. So the idea here that the itemprop-up (or whatever -- it would be good to get a more intuitive name, not sure what to call it though) would have to be specified in conjunction with the itemscope= attribute on a top-level microdata item whose element had an ancestor that itself creates an item, and would actually specify a property on the inner item, whose value was the outer item? This is what the example would look like if I'm understanding this right: div itemscope itemtype=http://schema.org/LocalBusiness; h1span itemprop=name(Entity A) Beachwalk Beachwear Giftware/span/h1 span itemprop=description A superb collection of fine gifts and clothing to accent your stay in Mexico Beach./span Phone: span itemprop=telephone850-648-4200/span div itemscope itemtype=http://schema.org/LocalBusiness; itemprop-up=containedIn h2span itemprop=name(Entity B) The tiny store within a store/span/h2 span itemprop=description A superb collection of tiny clothes, from the store within the store./span Phone: span itemprop=telephone123-456-7890/span /div /div It's not too bad, I guess. My main concern is that this seems to solve a very narrow use case for non-tree structures, but doesn't take into account the many, many other non-tree structures. For example, consider the case of a TV Episode with an Actor: div itemscope itemtype=http://schema.org/Episode; ... div itemprop=actor itemscope itemtype=http://schema.org/Person; ... /div /div ...now suppose it's marked up the other way around: div itemscope itemtype=http://schema.org/Person; ... div itemprop-up=actor itemscope itemtype=http://schema.org/Episode; ... /div /div So far so good. But what if there's two episodes with two actors, and the page just lists both episodes and both actors, and wants to cross-reference both episodes to both actors? itemprop-up (or whatever we call it) can't help there. itemref= can help in some simple cases, but as you pointed out, it soon gets out of hand. Microdata actually already has a solution to this. The vocabulary can define an ID for each item using itemid=, and can define multiple items having the same ID as being the same conceptual item. Thus: !-- first episode -- div itemscope itemtype=http://schema.org/Episode; ... div itemprop=actor itemscope itemtype=http://schema.org/Person; itemid=http://.../person/123;/div div itemprop=actor itemscope itemtype=http://schema.org/Person; itemid=http://.../person/456;/div /div !-- second episode -- div itemscope itemtype=http://schema.org/Episode; ... div itemprop=actor itemscope itemtype=http://schema.org/Person; itemid=http://.../person/123;/div div itemprop=actor itemscope itemtype=http://schema.org/Person; itemid=http://.../person/456;/div /div !-- actors -- div itemscope itemtype=http://schema.org/Person; itemid=http://.../person/123; ... /div div itemscope itemtype=http://schema.org/Person; itemid=http://.../person/456; ... /div This also enables the data to be spread across multiple pages without confusion. (This is similar to how RDF uses identifiers for everything -- essentially, in RDF terms, this turns the microdata item from a bnode into a node with a global identifier.) Your example would become: div itemscope itemtype=http://schema.org/LocalBusiness; itemid=... h1span itemprop=name(Entity A) Beachwalk Beachwear Giftware/span/h1 span itemprop=description A superb collection of fine gifts and clothing to accent your stay in Mexico Beach./span Phone: span itemprop=telephone850-648-4200/span div itemscope itemtype=http://schema.org/LocalBusiness; div itemprop=containedIn itemscope itemtype=http://schema.org/LocalBusiness; itemid=.../div h2span itemprop=name(Entity B) The tiny store within a store/span/h2 span itemprop=description A superb collection of tiny clothes, from the store within the store./span Phone: span itemprop=telephone123-456-7890/span /div /div Is this not suitable for schema.org? Or is it just too much markup? That is another option, similar to the parenthetical itemid= note above -- you could just have the vocabulary define that for every property whose value is an item, the item type that that property can point to has another property with the same name plus a fixed suffix, like -inv, that inverses the relationship. [...] This is
Re: [whatwg] [Canvas] Behavior on non-invertable CTM
On Mon, Mar 17, 2014 at 1:47 PM, Justin Novosad ju...@google.com wrote: I have a fix in flight that fixes that problem in Blink by storing the current path in transformed coordinates instead. I've had the fix on the back burner pending the outcome of this thread. That seems like an expensive solution because this causes the coordinates to be transformed twice. Why not store the matrix that was applied to the path coordinates and use that to undo the transformation? Dirk and I looked over the WebKit code and it's actually already doing this. If we decide that the right thing is to do nothing when when the CTM is non-invertible, then sure, we can just do that. The idea of storing the current path in transformed coordinates was to also support drawing with a non-invertible CTM, like Firefox does, which is what Ian stated was the correct behavior earlier in this thread. yeah, but then FF bails at draw time anyway. IMO no author relies on behavior when there's a non-invertible matrix so we should just implement the simplest and most efficient solution. See why I kept the fix on the backburner? :-) :-P yes
Re: [whatwg] [Canvas] Behavior on non-invertable CTM
On Mon, Mar 17, 2014 at 2:18 PM, Rik Cabanier caban...@gmail.com wrote: On Mon, Mar 17, 2014 at 1:47 PM, Justin Novosad ju...@google.com wrote: I have a fix in flight that fixes that problem in Blink by storing the current path in transformed coordinates instead. I've had the fix on the back burner pending the outcome of this thread. That seems like an expensive solution because this causes the coordinates to be transformed twice. Why not store the matrix that was applied to the path coordinates and use that to undo the transformation? Dirk and I looked over the WebKit code and it's actually already doing this. Good, maybe that can be the reference then. If we decide that the right thing is to do nothing when when the CTM is non-invertible, then sure, we can just do that. The idea of storing the current path in transformed coordinates was to also support drawing with a non-invertible CTM, like Firefox does, which is what Ian stated was the correct behavior earlier in this thread. yeah, but then FF bails at draw time anyway. Only if the CTM is still non-invertible at draw time. If the CTM was transiently non-invertible during the path construction, FF produces results consistent with applying the transform to the points used to construct the path, which is technically compliant with the current wording of the spec.
Re: [whatwg] [Canvas] Behavior on non-invertable CTM
On Mon, Mar 17, 2014 at 2:30 PM, Justin Novosad ju...@google.com wrote: On Mon, Mar 17, 2014 at 2:18 PM, Rik Cabanier caban...@gmail.com wrote: On Mon, Mar 17, 2014 at 1:47 PM, Justin Novosad ju...@google.com wrote: I have a fix in flight that fixes that problem in Blink by storing the current path in transformed coordinates instead. I've had the fix on the back burner pending the outcome of this thread. That seems like an expensive solution because this causes the coordinates to be transformed twice. Why not store the matrix that was applied to the path coordinates and use that to undo the transformation? Dirk and I looked over the WebKit code and it's actually already doing this. Good, maybe that can be the reference then. If we decide that the right thing is to do nothing when when the CTM is non-invertible, then sure, we can just do that. The idea of storing the current path in transformed coordinates was to also support drawing with a non-invertible CTM, like Firefox does, which is what Ian stated was the correct behavior earlier in this thread. yeah, but then FF bails at draw time anyway. Only if the CTM is still non-invertible at draw time. If the CTM was transiently non-invertible during the path construction, FF produces results consistent with applying the transform to the points used to construct the path, which is technically compliant with the current wording of the spec. That's correct. If someone did this in Firefox: ctx.setTransform(1,1,1,1,0,0); ctx.moveto(0,0); ctx.lineTo(10,0); ctx,setTransform(1,0,0,1,0,0); ctx.fill(); the end result would be a line from (0,0) to (10, 10). (IE does this as well). Nothing draws in Safari and Chrome currently.
Re: [whatwg] Canvas and Paths
On Mon, 10 Mar 2014, Tab Atkins Jr. wrote: This is also my question. Given that generating a path for a particular context isn't a magic bullet *anyway* (because the details of the context can change), I don't understand why caching isn't the answer. On Mon, 10 Mar 2014, Rik Cabanier wrote: At usage time, the path could be retargeted to a new backend. If the backend changes, knowing the backend at creation time doesn't help. If it doesn't, then the cost seems to be the same either way. I don't think that should be done as a cached copy since that would require too many resources. I will see if this is an acceptable solution for mozilla. How many resources could a path possibly take? On Mon, 10 Mar 2014, Justin Novosad wrote: Isn't caching ideal for that situation? In the case of re-targeting, you can either replace the cached encoding, or append the new encoding to a collection of cached encodings. Both of those options seem more effective than to stick to an encoding type that was baked-in at construction time. It may also be great to have a heuristic to chose whether to discard the previously cached re-encoding. Something like: if we are re-encoding because the destination backing type changed due to a resize, then discard previous encodings; if re-encoding because the path is drawn to multiple canvases, then retain multiple cached encodings. That makes sense to me. FYI The Firefox people agreed to a solution that retargets the path if its backend doesn't match with the canvas context backend. There's no need to change to current API.
