New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make all metadata optional in AMP. #593

Merged
merged 1 commit into from Oct 13, 2015

Conversation

Projects
None yet
8 participants
@cramforce
Member

cramforce commented Oct 13, 2015

Related to #499

@jmadler

This comment has been minimized.

Show comment
Hide comment
@jmadler

jmadler Oct 13, 2015

Contributor

Does the validator currently check against this requirement?

Contributor

jmadler commented Oct 13, 2015

Does the validator currently check against this requirement?

@cramforce

This comment has been minimized.

Show comment
Hide comment
@cramforce

cramforce Oct 13, 2015

Member

I don't believe it does. Labeled this issue to check.
On Oct 12, 2015 5:41 PM, "Jordan M. Adler" notifications@github.com wrote:

Does the validator currently check against this requirement?


Reply to this email directly or view it on GitHub
#593 (comment).

Member

cramforce commented Oct 13, 2015

I don't believe it does. Labeled this issue to check.
On Oct 12, 2015 5:41 PM, "Jordan M. Adler" notifications@github.com wrote:

Does the validator currently check against this requirement?


Reply to this email directly or view it on GitHub
#593 (comment).

@erwinmombay

This comment has been minimized.

Show comment
Hide comment
@erwinmombay

erwinmombay Oct 13, 2015

Member

reassigning to @powdercloud to answer the validator question

Member

erwinmombay commented Oct 13, 2015

reassigning to @powdercloud to answer the validator question

@kevinmarks

This comment has been minimized.

Show comment
Hide comment
@kevinmarks

kevinmarks Oct 13, 2015

What's the goal of requiring the article type here? In the search demo I can see that the image, headline published date and publisher logo were used to create the SERP previews, but not what role the explicit article type plays.
We've been looking into content-driven post type determination as part of the w3c SocialWG work - see http://indiewebcamp.com/post-type-discovery for current thinking.

Possibly more useful would be a deterministic algorithm for constructing SERP previews of that type, with examples drawn from existing pages.

kevinmarks commented Oct 13, 2015

What's the goal of requiring the article type here? In the search demo I can see that the image, headline published date and publisher logo were used to create the SERP previews, but not what role the explicit article type plays.
We've been looking into content-driven post type determination as part of the w3c SocialWG work - see http://indiewebcamp.com/post-type-discovery for current thinking.

Possibly more useful would be a deterministic algorithm for constructing SERP previews of that type, with examples drawn from existing pages.

@cramforce

This comment has been minimized.

Show comment
Hide comment
@cramforce

cramforce Oct 13, 2015

Member

How things get marked up to show up in Google Search is a Google issue. The
AMP project doesn't care. Stuff like that should be documented in a Google
help center article.

The reason why I think marking up the type is useful is that browsers could
use that to make similar heuristic decisions as AMP, so they could optimize
things and we no longer need AMP. Maybe we don't need it. I'd be fine to
drop the requirement, but I think it'd be a net win.
On Oct 12, 2015 9:24 PM, "Kevin Marks" notifications@github.com wrote:

What's the goal of requiring the article type here? In the search demo I
can see that the image, headline published date and publisher logo were
used to create the SERP previews, but not what role the explicit article
type plays.
We've been looking into content-driven post type determination as part of
the w3c SocialWG work - see http://indiewebcamp.com/post-type-discovery
for current thinking.

Possibly more useful would be a deterministic algorithm for constructing
SERP previews of that type, with examples drawn from existing pages.


Reply to this email directly or view it on GitHub
#593 (comment).

Member

cramforce commented Oct 13, 2015

How things get marked up to show up in Google Search is a Google issue. The
AMP project doesn't care. Stuff like that should be documented in a Google
help center article.

The reason why I think marking up the type is useful is that browsers could
use that to make similar heuristic decisions as AMP, so they could optimize
things and we no longer need AMP. Maybe we don't need it. I'd be fine to
drop the requirement, but I think it'd be a net win.
On Oct 12, 2015 9:24 PM, "Kevin Marks" notifications@github.com wrote:

What's the goal of requiring the article type here? In the search demo I
can see that the image, headline published date and publisher logo were
used to create the SERP previews, but not what role the explicit article
type plays.
We've been looking into content-driven post type determination as part of
the w3c SocialWG work - see http://indiewebcamp.com/post-type-discovery
for current thinking.

Possibly more useful would be a deterministic algorithm for constructing
SERP previews of that type, with examples drawn from existing pages.


Reply to this email directly or view it on GitHub
#593 (comment).

@tantek

This comment has been minimized.

Show comment
Hide comment
@tantek

tantek Oct 13, 2015

"The reason why I think marking up the type is useful is that browsers could use that to make similar heuristic decisions as AMP, so they could optimize things and we no longer need AMP. Maybe we don't need it. I'd be fine to drop the requirement, but I think it'd be a net win."

Key phrases you used:

  • "browsers could use"
  • "they [browsers] could optimize"
  • "maybe we don't need it"
  • "fine to drop the requirement"

Then why not drop the requirement until a browser implementer comes forward with a concrete use-case that needs it (rather than "could")? A simpler spec (fewer requirements) is a better spec.

And as @kevinmarks indicated, there's a good chance we can nullify any such direct need for explicit typing through a concrete Type Discovery algorithm, developed naturally based on (cited) real world publishing experience.

tantek commented Oct 13, 2015

"The reason why I think marking up the type is useful is that browsers could use that to make similar heuristic decisions as AMP, so they could optimize things and we no longer need AMP. Maybe we don't need it. I'd be fine to drop the requirement, but I think it'd be a net win."

Key phrases you used:

  • "browsers could use"
  • "they [browsers] could optimize"
  • "maybe we don't need it"
  • "fine to drop the requirement"

Then why not drop the requirement until a browser implementer comes forward with a concrete use-case that needs it (rather than "could")? A simpler spec (fewer requirements) is a better spec.

And as @kevinmarks indicated, there's a good chance we can nullify any such direct need for explicit typing through a concrete Type Discovery algorithm, developed naturally based on (cited) real world publishing experience.

@cramforce

This comment has been minimized.

Show comment
Hide comment
@cramforce

cramforce Oct 13, 2015

Member

No need to quote my words out of context. That comes across rather
impolite. If there are good arguments to fully drop the requirement I'm
very open to drop it.

If people would prefer to continue the right to not use semantic markup in
their pages that is fine with me.
On Oct 12, 2015 9:47 PM, "Tantek Çelik" notifications@github.com wrote:

"The reason why I think marking up the type is useful is that browsers
could use that to make similar heuristic decisions as AMP, so they could
optimize things and we no longer need AMP. Maybe we don't need it. I'd be
fine to drop the requirement, but I think it'd be a net win."

Key phrases you used:

  • "browsers could use"
  • "they [browsers] could optimize"
  • "maybe we don't need it"
  • "find to drop the requirement"

Then why not drop the requirement until a browser implementer comes
forward with a concrete use-case that needs it (rather than "could")? A
simpler spec (fewer requirements) is a better spec.

And as @kevinmarks https://github.com/kevinmarks indicated, there's a
good chance we can nullify any such direct need for explicit typing through
a concrete Type Discovery algorithm, developed naturally based on (cited)
real world publishing experience.


Reply to this email directly or view it on GitHub
#593 (comment).

Member

cramforce commented Oct 13, 2015

No need to quote my words out of context. That comes across rather
impolite. If there are good arguments to fully drop the requirement I'm
very open to drop it.

If people would prefer to continue the right to not use semantic markup in
their pages that is fine with me.
On Oct 12, 2015 9:47 PM, "Tantek Çelik" notifications@github.com wrote:

"The reason why I think marking up the type is useful is that browsers
could use that to make similar heuristic decisions as AMP, so they could
optimize things and we no longer need AMP. Maybe we don't need it. I'd be
fine to drop the requirement, but I think it'd be a net win."

Key phrases you used:

  • "browsers could use"
  • "they [browsers] could optimize"
  • "maybe we don't need it"
  • "find to drop the requirement"

Then why not drop the requirement until a browser implementer comes
forward with a concrete use-case that needs it (rather than "could")? A
simpler spec (fewer requirements) is a better spec.

And as @kevinmarks https://github.com/kevinmarks indicated, there's a
good chance we can nullify any such direct need for explicit typing through
a concrete Type Discovery algorithm, developed naturally based on (cited)
real world publishing experience.


Reply to this email directly or view it on GitHub
#593 (comment).

@tantek

This comment has been minimized.

Show comment
Hide comment
@tantek

tantek Oct 13, 2015

No need to tone-police. My point was your words justified the opposite of your conclusion.

The burden of proof of any feature (requirement) in a spec is for its existence, dropping is the default choice because simpler specs tend to be better, more secure, easier for authors etc.

Without a good real world use-case based argument for why any particular markup (semantic, meta, or otherwise) is needed, there's no justification for requiring it. Less is better. Otherwise it's just bloat.

tantek commented Oct 13, 2015

No need to tone-police. My point was your words justified the opposite of your conclusion.

The burden of proof of any feature (requirement) in a spec is for its existence, dropping is the default choice because simpler specs tend to be better, more secure, easier for authors etc.

Without a good real world use-case based argument for why any particular markup (semantic, meta, or otherwise) is needed, there's no justification for requiring it. Less is better. Otherwise it's just bloat.

@powdercloud

This comment has been minimized.

Show comment
Hide comment
@powdercloud

powdercloud Oct 13, 2015

Collaborator

The validator itself isn't checking, it just allows it. Reason being we're not parsing up the json thus far.

However de facto for the preview release I believe the articles do have the markup, and some other code (not the validator) is looking for this markup.

My hunch is that it's useful to put some markup about the articles into the spec (headline, author, etc.) because it lowers the barrier of entry for anyone to deliver these articles: No need for fancy detection algorithms or parsing stuff like headline, author, publishing date from the contents.

Collaborator

powdercloud commented Oct 13, 2015

The validator itself isn't checking, it just allows it. Reason being we're not parsing up the json thus far.

However de facto for the preview release I believe the articles do have the markup, and some other code (not the validator) is looking for this markup.

My hunch is that it's useful to put some markup about the articles into the spec (headline, author, etc.) because it lowers the barrier of entry for anyone to deliver these articles: No need for fancy detection algorithms or parsing stuff like headline, author, publishing date from the contents.

@cramforce

This comment has been minimized.

Show comment
Hide comment
@cramforce

cramforce Oct 13, 2015

Member

@tantek I will strictly enforce a be-excellent-to-each-other code-of-conduct on this open source project. You were escalating a discussion that really had nobody really disagreeing heavily with each other. I can be very much convinced to remove all semantic markup requirements from the AMP spec. I think your spec simplicity argument is great!

@powdercloud That hunch is a pretty good one, I think. Mandating baseline semantic markup helps smaller AMP consumers that cannot effectively mandate markup themselves (like Google, Bing, Yandex, Twitter Facebook) to get predictable structured data. I think practically speaking there are pretty good libraries that just extract from a page what they get get independent of whether the author used schema.org, OGP or Twitter cards, so it doesn't really matter all that much.

Member

cramforce commented Oct 13, 2015

@tantek I will strictly enforce a be-excellent-to-each-other code-of-conduct on this open source project. You were escalating a discussion that really had nobody really disagreeing heavily with each other. I can be very much convinced to remove all semantic markup requirements from the AMP spec. I think your spec simplicity argument is great!

@powdercloud That hunch is a pretty good one, I think. Mandating baseline semantic markup helps smaller AMP consumers that cannot effectively mandate markup themselves (like Google, Bing, Yandex, Twitter Facebook) to get predictable structured data. I think practically speaking there are pretty good libraries that just extract from a page what they get get independent of whether the author used schema.org, OGP or Twitter cards, so it doesn't really matter all that much.

@kevinmarks

This comment has been minimized.

Show comment
Hide comment
@kevinmarks

kevinmarks Oct 13, 2015

There are no public libraries I know of that parse schema.org; last time I asked danbri he said that they don't exist. https://twitter.com/danbri/status/616164347073662976
If you know of one I'd love to hear about it.

kevinmarks commented Oct 13, 2015

There are no public libraries I know of that parse schema.org; last time I asked danbri he said that they don't exist. https://twitter.com/danbri/status/616164347073662976
If you know of one I'd love to hear about it.

@cramforce

This comment has been minimized.

Show comment
Hide comment
@cramforce
Member

cramforce commented Oct 13, 2015

CC @danbri

@cramforce cramforce changed the title from Only require schema.org article type. Nothing else. to Make all metadata optional in AMP. Oct 13, 2015

@cramforce

This comment has been minimized.

Show comment
Hide comment
@cramforce

cramforce Oct 13, 2015

Member

Updated to remove all metadata requirements.

Member

cramforce commented Oct 13, 2015

Updated to remove all metadata requirements.

@cramforce cramforce assigned dvoytenko and unassigned powdercloud Oct 13, 2015

@danbri

This comment has been minimized.

Show comment
Hide comment
@danbri

danbri Oct 13, 2015

Contributor

Oh, how I have missed these debates!

Contributor

danbri commented Oct 13, 2015

Oh, how I have missed these debates!

@dvoytenko dvoytenko added LGTM and removed NEEDS REVIEW labels Oct 13, 2015

@dvoytenko

This comment has been minimized.

Show comment
Hide comment
@dvoytenko

dvoytenko Oct 13, 2015

Collaborator

LGTM

Collaborator

dvoytenko commented Oct 13, 2015

LGTM

cramforce added a commit that referenced this pull request Oct 13, 2015

Merge pull request #593 from cramforce/schema-org
Make all metadata optional in AMP.

@cramforce cramforce merged commit 0f031f1 into ampproject:master Oct 13, 2015

2 checks passed

cla/google All necessary CLAs are signed
continuous-integration/travis-ci/pr The Travis CI build passed
Details
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment