w3c / microdata

Moved to https://html.spec.whatwg.org/multipage/microdata.html
15 stars 19 forks source link

Reusing components in different contexts #86

Open simlawr opened 6 years ago

simlawr commented 6 years ago

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's itemscope, is problematic for this kind of code reuse.

For example, a component that displays the name, image and description of a person:

<div itemscope itemtype="http://schema.org/Person">
  <h1 itemprop="name">…</h1>
  <img itemprop="image" src="…" alt="…">
  <p itemprop="description">…</p>
</div>

This could be used in several different contexts, such as the author of an article:

<div itemscope itemtype="http://schema.org/Article">
  <div itemprop="author" itemscope itemtype="http://schema.org/Person">…</div>
</div>

Also, as a performer at, or an attendee to, an event:

<div itemscope itemtype="http://schema.org/Event">
  <div itemprop="performer" itemscope itemtype="http://schema.org/Person">…</div>
</div>

<div itemscope itemtype="http://schema.org/Event">
  <div itemprop="attendee" itemscope itemtype="http://schema.org/Person">…</div>
</div>

In each context the component is used a different value for itemprop is required. If, the component were to include itemprop="author" in its definition, it would not be possible to reuse the component in a context where itemprop="performer" or itemprop="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.

chaals commented 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.

simlawr commented 6 years ago

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.

simlawr commented 6 years ago

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.

simlawr commented 5 years ago

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.