The purpose of WebPageElement and mainContentOfPage #1251
Ah, a topic dear to my heart. :)
I've lost count of how many times I've brought these up over the last couple of years.
When I just started out with schema.org (as a web dev) I thought these were important as they described elements on a page. And as such I submitted many ideas/markup examples in an attempt to make these work. A line of thought many web developers have (minus the effort of discussing them here) and thus many still add these to sites.
The problem everybody faces though is that there aren't any proper examples to be found on how to use them (largely caused by the fact this part of schema.org isn't complete enough to work) and thus they try to make it work to the best of their abillities (I absolutely recognize the SiteNavigationElement example + many url properties).
Though after a couple of years of discussing these on the mailing list I came to realise that describing webpage elements isn't all that interesting at all as it's about describing the real life entities a resource contains. And thus stopped using them, as well as stop writing 'proposals' to fix 'm.
So +1 to deprecating these from me (hoping we can put an end to folks wasting time and energy on marking up things that don't matter)
In general. I agree that many of the elements for marking up Web page structure information are confusion and hardly useful for a consumer of markup, because the same information can by and large be gained from analyzing the HTML tree.
Also, it is a frequent source of disappointment for site owners - they spend effort adding this type of markup, and learn sooner or later that it has no effect on search engines.
Before we deprecate it, though, the sponsors of schema.org should comment on whether they see use-cases beyond marking up HTML. For instance, I can imagine using these elements in JSON-LD for describing HTML templates, e.g. in tools that generate or customize HTML templates, or e.g. for mappings between MS Word documents and their HTML export.
"whether they see use-cases beyond marking up HTML. For instance, I can imagine using these elements in..."
Another reason to keep them is because there might be folks (other than me) that use 'm as part of a controlled library of terms for element tagging when A/B testing a websites frontend (I've done so in the past).
Though as far as I'm aware this isn't a very known/popular method.
@mfhepp In that use case....then it can just stay and Mozilla or whomever can do a quick mapping to it if they want via the new tag and using these Schema.org terms for the metadata content itself... https://developer.mozilla.org/en-US/docs/Web/HTML/Element/template
But I can also see this as not really bringing value to the table at all even with a mapping in place like that, so...
+1 for deprecating terms that describe page structure instead of describing content.
Current status: Neither
WebPageElementnor any of its sub-types (WPSideBar,WPHeader,WPFooter,WPAdBlock,Table,SiteNavigationElement) define any additional properties, and they don’t have any examples (except for a very simple one forTable).I have the impression that
WPSideBar,WPHeader,WPFooter, andSiteNavigationElementare quite often used, probably because it’s easy for template creators to add them: they don’t need to know what kind of content the authors will add; the page’s header will always be the header, etc.But I think all these
WebPageElementtypes (and the correspondingmainContentOfPageproperty) are not really useful, at least not for the typical web page:HTML5 conveys all this. The
navelement =SiteNavigationElement; thefooterelement =WPFooter; thetableelement =Tableetc., and themainelement for the main content (mainContentOfPage).There’s rarely the need to say something about these parts, e.g., the name of the navigation, or the author of a page footer, or the license of the page sidebar, etc. I wouldn’t be surprised if most occurrences don’t contain any property. And the actual content of these elements wouldn’t be captured on the level of JSON-LD/Microdata/RDFa, so what authors are conveying is nothing more than: There is a web page header. (or hopefully: This web page has a header.)
I often saw that the existing properties get used incorrectly, for example:
Authors use a
SiteNavigationElementfor each navigation link (not for the whole navigation) or a singleSiteNavigationElementwith multiplename/urlproperties (not for the name/URL of the navigation, but of the navigation entries).Authors provide the website title as
nameofWPHeader(because their CMS/Theme added it automatically) instead ofWebPage/WebSite.The
mainContentOfPageproperty expects aWebPageElementas value. I think this never really worked in practice, because authors want to say something about the entities like blog posts, articles, etc. that form the main content, not the actual HTML element that contains it. And after introducingmainEntity, I think there’s no need to have/redefinemainContentOfPageanymore .I think a rare case where these types could be useful for typical web pages is, for example, a table (as part of an article) that has a different author/license than the rest of the page. But there’s really no need to have it as
WebPageElementin that case, as such a table could also be part of e.g. a book, so the type should become more general if there’s need for it (similar toImageObject, which is not some kind ofWebPageElement).Am I missing something here, or are these types really not that useful for web pages?
If that’s true, are they primarily intended for non-Web contexts, e.g., for emails, and would they be useful there? Not my domain, I have no idea, but I can’t imagine a use case where these types could be useful.
I think what I’m getting at is … Should we deprecate
WebPageElement+mainContentOfPage? Or, at least, recommend not to use these terms in the typical Web context?