Add meta for property and itemprop.

[sunshineo]

We have 3 popular set of meta format: "name", "property" and "itemprop".
Currently only name is set. This change allows all 3 to be set at the same time.
It is very important because facebook use "property" and google use "itemprop" (from schema.org)

[vinaygopinath]

Hi there, thanks for your contribution!

A few thoughts:

1. In the spirit of Don't Repeat Yourself (DRY), I think it would make more sense to create a single function _getOrCreateMetaTag(tagName: string, attributeName: string) and do something like this

this.document.querySelector(`meta[${attributeName}='${tagName}']`);

2. Creating duplicates of the same set of tags is not something everybody would want. I think this should be an opt-in feature, maybe with a flag like enableMetaProperty. This would enable doing this:

   setTitle(title?: string, titleSuffix?: string) {
      const titleElements = [_getOrCreateMetaTag('title', 'name'), _getOrCreateMetaTag('og:title', 'name')];
      if (this.metaConfig.enableMetaProperty) {
         titleElements.push(_getOrCreateMetaTag('title', 'property'));
         titleElements.push(_getOrCreateMetaTag('og:title', 'property'));
      }
      //let titleStr = ....;
     titleElements.forEach((titleElement: HTMLElement) => {
        titleElement.setAttribute('content', titleStr);
     });

3. I can't seem to find any documentation supporting the use of "itemprop" for titles and other page-level meta tags. I'd like to make sure that this is a recommended practice before including it in ng2-meta. As I understand it, schema.org properties are meant for annotating rich content/structured data within the page for search engines.

Thanks for creating a PR

[sunshineo]

@vinaygopinath I'm not an expert. I prefer something that just works without the need to config, opt in or deeply understand all 3 tagging systems. What's the down side of just slap all of them on there?

[vinaygopinath]

I think ng2-meta, as an open-source library, should be maintainable, customizable to the needs of different developers and follow best practices. Creating multiple functions that essentially do the same thing, forcing the creation of meta tags that some folks might not want and using schema.org attributes in ways that might not be recommended would defeat those intentions.

What's the downside if we "slap all of them on there"? It'll be harder to maintain this code (Why is there duplicated code?), someone might create an issue to disable some tags (I don't use schema.org/microdata attributes. How can I disable them?) and sites would fail w3c validation.

Having said that, if it's important for you to quickly implement this within your site, I encourage you to use your fork in your project via npm or other package managers.

[sunshineo]

@vinaygopinath My comment about "slap all of them" is for all 3 types of tags. The duplicated code part I agree should be written better and not duplicate. It's about by default having all types of tags a website could want VS by default just have 1 set. Is your concern about "some folks might not want some tags" even valid? I cannot think of such a scenario. And if it happens some time, how frequent? IMHO, we cover the use cases for majority people, which is slap all the tags you can think of on the html, I don't care. And then maybe provide a way for a very small percentage of particular user to remove unwanted tags.