Re: [whatwg] inverse property mechanism for Microdata?
On 17 March 2014 21:15, Ian Hickson i...@hixie.ch wrote: 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. Yes. I notice that the words we were playing with at schema.org relate to the underlying graph data model itemprop-inverse, -reverse etc., whereas your draft name, itemprop-up is about the markup hierarchy. 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. Yup, there are some cases where this can be addressed through the rigorous use of entity IDs in itemid, as you sketch below. That would be relatively new territory for schema.org and for publishers. Perhaps there is an attribute name we can find that would leave the door open to more use cases, e.g. itemprop-backwards rather than itemprop-up. It seems reasonable to try to address relationships between sibling elements too. Something like (trying out -backwards instead of -up, to allow for non-hierarchical usage): div itemid=bigshop itemscope itemtype=http://schema.org/LocalBusiness; h1span itemprop=name(Entity A) Beachwalk Beachwear Giftware/span/h1 /div div itemscope itemtype=http://schema.org/Pharmacy; meta itemprop-backwards=containedIn itemid=bigshop / h2span itemprop=nameTiny pharmacy store within a store/span/h2 /div ? Can we use itemid in that way, to give a property value too? I don't see itemid used much in the wild and the spec only mentions its use for the item having the property, rather than using when supplying the value of a property. 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
[whatwg] Canvas Path.addPath SVGMatrix not optimal?
Hi,
I just looked at the definition of Path.addPath[1]:
void addPath(Path path, SVGMatrix? transformation);
SVGMatrix is nullable but can not be omitted all together. Why isn’t it
optional as well? I think it should be optional, especially because creating an
SVGMatrix at the moment means writing:
var matrix =
document.createElementNS('http://www.w3.org/2000/svg','svg').createSVGMatrix();
Greetings,
Dirk
[1]
http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#path
[whatwg] Canvas Path.addPath SVGMatrix not optimal?
Hi,
I just looked at the definition of Path.addPath[1]:
void addPath(Path path, SVGMatrix? transformation);
SVGMatrix is nullable but can not be omitted all together. Why isn’t it
optional as well? I think it should be optional, especially because creating an
SVGMatrix at the moment means writing:
var matrix =
document.createElementNS('http://www.w3.org/2000/svg','svg').createSVGMatrix();
I would even argue that SVGMatrix should just be optional.
Greetings,
Dirk
[1]
http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#path
Re: [whatwg] Canvas Path.addPath SVGMatrix not optimal?
On Wed, Mar 19, 2014 at 4:46 PM, Dirk Schulze dschu...@adobe.com wrote:
Hi,
I just looked at the definition of Path.addPath[1]:
void addPath(Path path, SVGMatrix? transformation);
SVGMatrix is nullable but can not be omitted all together. Why isn’t it
optional as well? I think it should be optional, especially because
creating an SVGMatrix at the moment means writing:
var matrix = document.createElementNS('http://www.w3.org/2000/svg
','svg').createSVGMatrix();
Greetings,
Dirk
[1]
http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#path
I agree it should be optional, but just to play devil's advocate : you can
create an identity SVGMatrix with a simpler bit of code. Just do this right
after creating a canvas rendering context: var identity =
context.currentTransform;
-Justin
Re: [whatwg] Canvas Path.addPath SVGMatrix not optimal?
On Wed, Mar 19, 2014 at 2:22 PM, Justin Novosad ju...@google.com wrote:
On Wed, Mar 19, 2014 at 4:46 PM, Dirk Schulze dschu...@adobe.com wrote:
Hi,
I just looked at the definition of Path.addPath[1]:
void addPath(Path path, SVGMatrix? transformation);
SVGMatrix is nullable but can not be omitted all together. Why isn't it
optional as well? I think it should be optional, especially because
creating an SVGMatrix at the moment means writing:
var matrix = document.createElementNS('http://www.w3.org/2000/svg
','svg').createSVGMatrix();
Greetings,
Dirk
[1]
http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#path
I agree it should be optional, but just to play devil's advocate : you can
create an identity SVGMatrix with a simpler bit of code. Just do this right
after creating a canvas rendering context: var identity =
context.currentTransform;
Hi Justin,
did Blink already expose this property?
As currently specified, this must return a live SVGMatrix object, meaning
that as you change the CTM on the 2d context, your reference to the
SVGMatrix should change as well. [1]
It's unlikely that you actually want this...
This API should be renamed to get/setCurrentTransform() and return a copy.
1:
http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#dom-context-2d-currenttransform
Re: [whatwg] Support filters in Canvas
On Sat, Mar 15, 2014 at 12:03 AM, Dirk Schulze dschu...@adobe.com wrote:
Hi,
Apologize if it was already discussed but I couldn't find a mail to this
topic.
Yes, this was brought up a couple of times.
Last exchange was in Sept of 2012 (!):
http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2012-September/037432.html
In one of the early drafts of Filter Effects we had filter operation
support for HTML Canvas. We deferred it and IMO it makes more sense to have
it as part of the Canvas specification text.
I would suggest a filter attribute that takes a list of filter operations
similar to the CSS Image filter function[1]. Similar to shadows[2], each
drawing operation would be filtered. The API looks like this:
partial interface CanvasRenderingContext2D {
attribute DOMString filter;
}
A filter DOMString could looks like: contrast(50%) blur(3px)
With the combination of grouping in canvas[3] it would be possible to
group drawing operations and filter them together.
Filter functions include a reference to a filter element and a
specification of SVG filters[4]. I am unsure if a reference do an element
within a document can cause problems. If it does, we would just not support
SVG filter references.
Yes, I'd prefer if we supported just the CSS filter shorthands for now.
Re: [whatwg] Canvas Path.addPath SVGMatrix not optimal?
On Mar 19, 2014, at 10:48 PM, Rik Cabanier
caban...@gmail.commailto:caban...@gmail.com wrote:
On Wed, Mar 19, 2014 at 2:22 PM, Justin Novosad
ju...@google.commailto:ju...@google.com wrote:
On Wed, Mar 19, 2014 at 4:46 PM, Dirk Schulze
dschu...@adobe.commailto:dschu...@adobe.com wrote:
Hi,
I just looked at the definition of Path.addPath[1]:
void addPath(Path path, SVGMatrix? transformation);
SVGMatrix is nullable but can not be omitted all together. Why isn't it
optional as well? I think it should be optional, especially because
creating an SVGMatrix at the moment means writing:
var matrix = document.createElementNS('http://www.w3.org/2000/svg
','svg').createSVGMatrix();
Greetings,
Dirk
[1]
http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#path
I agree it should be optional, but just to play devil's advocate : you can
create an identity SVGMatrix with a simpler bit of code. Just do this right
after creating a canvas rendering context: var identity =
context.currentTransform;
Hi Justin,
did Blink already expose this property?
As currently specified, this must return a live SVGMatrix object, meaning that
as you change the CTM on the 2d context, your reference to the SVGMatrix should
change as well. [1]
It's unlikely that you actually want this...
This API should be renamed to get/setCurrentTransform() and return a copy.
It could be called getCTM() which SVG offers on SVGElements and also returns an
SVGMatrix object. But I agree that it would be easier if we return a copy
instead of a live object.
What does Blink do?
Greetings,
Dirk
1:
http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#dom-context-2d-currenttransform
