Open simlawr opened 6 years ago
(components have been around the web since last century, but yeah...)
The use case makes sense, but I am not sure what we might change in microdata to help. It seems more obvious to me to use the mechanisms for using variables in templates that are associated with component systems. So you might have in your examples itemprop={{roletype}}
to be filled based on the component's role or some other contextual information.
This is a practical solution that would work in many situations but some methods of including code do not allow for variable passing. The markup generated by content management systems is an example of where it may not be possible to pass through the required itemprop
attribute.
Might something like the following be a possible solution?
<body itemscope itemtype="http://schema.org/Blog">
<div itemprop="blogPost" itemtype="http://schema.org/BlogPosting">
<article itemscope itemtype="http://schema.org/BlogPosting">…</article>
</div>
</body>
An itemprop
could define itself to be of an itemtype
without creating a new item. The parser then looks for a descendant itemscope
with a matching itemtype
and associates it with the itemprop
.
This would allow the <article>
code to be reused in many different contexts.
RDFa solves this problem through use of a rel
attribute on a parent node, for example:
<body vocab="http://schema.org/" typeof="Blog">
<div rel="blogPost">
<article typeof="BlogPosting">…</article>
</div>
</body>
An explanation of how to use this syntax can be found in the RDFa 1.1 Primer.
It's commonplace to create reusable code fragments and more recently frameworks, such as React and AngularJS, have popularised the idea of components. The requirement for an
itemprop
attribute to be on the same element as a sub-item'sitemscope
, is problematic for this kind of code reuse.For example, a component that displays the name, image and description of a person:
This could be used in several different contexts, such as the author of an article:
Also, as a performer at, or an attendee to, an event:
In each context the component is used a different value for
itemprop
is required. If, the component were to includeitemprop="author"
in its definition, it would not be possible to reuse the component in a context whereitemprop="performer"
oritemprop="attendee"
was needed.Further, components are by design supposed to be independent of their parent. The very requirement for a parent's
itemprop
attribute to be in component, creates an unwanted dependency.