[whatwg] multiple itemtypes in microdata?
In the user feedback from the schema.org proposal, which uses microdata as its syntax, we have seen several use cases that would seem to require multiple itemtypes per itemscope. Currently the microdata spec only allows one itemtype which defines the meaning of the vocabulary for subsequent itemprops. Allowing an arbitrary list of itemtypes would not be desirable because then a user agent would have to have knowledge of the type vocabularies in order to parse the page. We suggest that itemtype be changed to allow multiple space separated types (just like itemprop), but only if the origin domain of the types is the same. This would allow a vocabulary provider to allow multiple types and to take responsibility for what the property vocabulary definition is in the context of more than one type. -jg
[whatwg] A web standards based model for Augmented Reality
Hi, my name is Rob Manson and I'm one of the co-founders of http://ARStandards.org and an Invited Expert on the W3C Points of Interest Working Group http://www.w3.org/2010/POI/ I've recently published an outline for a web standards based model for AR that is obviously closely related to all the work going on at the whatwg. So I thought I'd send this off to this list looking for feedback and constructive criticism. http://robman.com.au/a-web-standards-based-model-for-ar-in Obviously some of the test elements are based on APIs that are still forming or are not yet widely adopted. I'm ok with that 8) In fact I'm hoping that by raising this as a "big hairy audacious goal" that we can use it as a thought experiment to validate some of the plans for these APIs as they evolve (e.g Audio Data vs Web Audio and WebRTC). I think the functional needs for AR are very clear and they introduce some unique and exciting new use cases for API developers to take into account. So, I'd really appreciate any comments you have...both positive and negative. Currently we're working on breaking each of the test elements out into wiki pages so people can contribute to the discussion and development of each of these. We'll also put the test onto github, etc. too. We're also looking for some great demos to include. We need a multitouch friendly js game if you know of one. And the gyro and motion examples obviously haven't been plugged in yet. Plus none of the browsers in the wild really support the required audio and video APIs yet. I'll look forward to hearing what you think... roBman
Re: [whatwg] drawing with singular transforms and zero-sized gradients
On Mon, Jun 27, 2011 at 2:11 PM, Boris Zbarsky wrote: > On 6/26/11 8:18 PM, Robert O'Callahan wrote: > >> Gradients already aren't continuous where the start and end points are >> equal. I think it would be OK to draw nothing as Aryeh suggests. At >> least it's easy to spec and implement, and I doubt authors will care >> (they haven't cared about the browser behaviors so far AFAIK). >> > > OK, fair. Do we think float round-off errors won't bite us much here? > No more than they would for other discontinuous cases like gradients with equal start and end points. Rob -- "If we claim to be without sin, we deceive ourselves and the truth is not in us. If we confess our sins, he is faithful and just and will forgive us our sins and purify us from all unrighteousness. If we claim we have not sinned, we make him out to be a liar and his word is not in us." [1 John 1:8-10]
Re: [whatwg] drawing with singular transforms and zero-sized gradients
On 6/26/11 8:18 PM, Robert O'Callahan wrote: Gradients already aren't continuous where the start and end points are equal. I think it would be OK to draw nothing as Aryeh suggests. At least it's easy to spec and implement, and I doubt authors will care (they haven't cared about the browser behaviors so far AFAIK). OK, fair. Do we think float round-off errors won't bite us much here? -Boris
Re: [whatwg] drawing with singular transforms and zero-sized gradients
Gradients already aren't continuous where the start and end points are equal. I think it would be OK to draw nothing as Aryeh suggests. At least it's easy to spec and implement, and I doubt authors will care (they haven't cared about the browser behaviors so far AFAIK).
Re: [whatwg] drawing with singular transforms and zero-sized gradients
On 6/26/11 6:14 PM, Aryeh Gregor wrote: So this is probably my pure math background showing through rather than a very useful contribution to the discussion. If the API were designed for mathematicians, now . . . The argument could still be made that we want behavior to be continuous -Boris
Re: [whatwg] drawing with singular transforms and zero-sized gradients
On Fri, Jun 24, 2011 at 10:52 PM, Robert O'Callahan wrote: > That's true if you call fillRect(), or fill() on a path that you've emitted > while the current matrix is singular; the rectangle or path collapses to a > single point (or line). I think it's completely clear browsers should draw > nothing in those cases. > > However, my testcase emits a path while the matrix is non-singular, so the > canvas-space path is definitely not collapsed to a point or line, then makes > the matrix singular just for the fill operation. The question is then how > the singular matrix affects the way the source color, gradient or pattern > fills a non-empty path. I'm thinking of the source color, gradient, or pattern conceptually filling the plane (possibly almost all transparent in the case of a pattern), then being transformed by the matrix, then being clipped to fill the shape before being painted. Thus in my mind it's still being collapsed before being painted, even if it's just a solid color. That way a solid color is conceptually the same as a gradient with all color stops the same, or a solid-colored image. It seems like a useful invariant if the different styles behave the same reliably when they should logically be the same. That way authors can learn about patterns first (which is very concrete -- "give it an image"), then understand gradients and solid colors as special cases of patterns, and be consistently right. Authors might be surprised by the behavior in this particular case, but it's a fairly pathological case anyway, and it doesn't seem worthwhile to trade away consistency to get more intuitive behavior in this special case. I guess one big problem with this approach is you have a singularity at determinant zero, and that's really awkward because you can't rely on floating-point equality comparisons unless you allow some tolerance for rounding error, and in that case equality is no longer transitive. By my theory, a transformation matrix with determinant zero should result in solid colors doing nothing, but one with determinant e for any e > 0 should result in the color being painted. This is obviously bad. So this is probably my pure math background showing through rather than a very useful contribution to the discussion. If the API were designed for mathematicians, now . . . On Fri, Jun 24, 2011 at 11:00 PM, Robert O'Callahan wrote: > If you set up a path covering the entire canvas, call ctx.scale(e, e) for > infinitesimal e, and then fill with an image pattern, conceptually you're > scaling the image to be incredibly small and then repeating it a very large > number of times to fill the canvas. So I guess the logical behavior for e=0 > would be to compute the average color of the image pixels and do a solid > fill with that color, which would give you that consistency you're asking > for. But is that worth implementing? No-one does that today. What does everyone do today instead? I'm guessing canvas doesn't currently define how you should apply the transformation matrix precisely, and in particular how to handle cases like this with subpixel detail. The same issue should arise for gradients with very small stops (as Tab points out), or ones with large stops that are scaled down a lot. If e were exactly zero, though, the logical behavior in my interpretation would be to paint nothing for any operation whatsoever, since the determinant is zero. But again, that's problematic.