Skip to content
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

Enable amp-autocomplete in AMP4Email with doc level opt-in #27174

Merged
merged 11 commits into from
Mar 27, 2020

Conversation

caroqliu
Copy link
Contributor

@caroqliu caroqliu commented Mar 10, 2020

Related to: #24881

  • Requires data-amp-autocomplete-opt-in in the document <html> tag for email documents to mimic experiment language
  • Adds validation rules

@amp-owners-bot
Copy link

amp-owners-bot bot commented Mar 10, 2020

Hey @ampproject/wg-caching, these files were changed:

extensions/amp-autocomplete/validator-amp-autocomplete.protoascii
validator/engine/validator_test.js
validator/testdata/amp4email_feature_tests/amp-autocomplete.html
validator/testdata/amp4email_feature_tests/amp-autocomplete.out
validator/validator-main.protoascii

@caroqliu caroqliu requested a review from dreamofabear March 10, 2020 15:31
@caroqliu caroqliu requested a review from Gregable March 11, 2020 15:37
@Gregable
Copy link
Member

I'm OK with this change for the validator. However, I'd like to loop in @kristoferbaxter on the addition of a new attribute to the <html> tag. He expressed some concerns about this recently, I think he has more context than myself.

@zhangsu
Copy link
Member

zhangsu commented Mar 18, 2020

Just one thought (sorry that it came late): what documentation do we have to avoid confusing developers when they discover that they can start using amp-autocomplete in the playground but nothing seems to work, both in the playground and in any email client?

@caroqliu
Copy link
Contributor Author

@zhangsu Thanks for bringing this up. Talked with @sebastianbenz and there is currently no support for format-specific experimental flagging. For now I've added a warning at the top of the documentation file that will only be displayed for email.

@caroqliu caroqliu requested a review from sebastianbenz March 19, 2020 14:43
Copy link
Contributor

@sebastianbenz sebastianbenz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Doc update LGTM

Copy link
Member

@zhangsu zhangsu left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks! @bill97819 FYI

@kristoferbaxter
Copy link
Contributor

When adding new attributes that are not part of the existing HTML specification, we should prefix them to avoid making it harder for the HTML specification to change.

In this case we should look at using a data- attribute prefix, as described here.

Copy link
Contributor

@kristoferbaxter kristoferbaxter left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Moving to a data- attribute will avoid making it harder for the HTML specification to change.

@caroqliu
Copy link
Contributor Author

@kristoferbaxter @Gregable Would it be possible to use a data- prefixed attribute that is explicitly disallowed in the validator? All data-* attributes are validated and this attribute should not be.

@dreamofabear
Copy link

@samouri did this recently in amp-script:

# This attribute should always be invalid. See https://github.com/ampproject/amphtml/pull/27076
name: "data-ampdevmode"
value: "false"
blacklisted_value_regex: "false"

# This attribute should always be invalid. See https://github.com/ampproject/amphtml/pull/27174
name: "data-amp-autocomplete-opt-in"
value: "false"
blacklisted_value_regex: "false"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a clever solution. Can you leave a comment here explaining what this is doing and why, because I suspect it'll be confusing to someone reading it in isolation.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This amp-autocomplete-opt-in only applies to AMP4email even though it is defined on the html element shared across the various AMP flavors, correct?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is only relevant to the AMP4Email format, yes.

@caroqliu caroqliu requested a review from Gregable March 26, 2020 18:20
@@ -215,6 +216,14 @@ export class AmpAutocomplete extends AMP.BaseElement {

/** @override */
buildCallback() {
const doc = this.element.ownerDocument;
const isEmail = doc && isAmp4Email(doc);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

When will doc be falsy?

Copy link
Contributor Author

@caroqliu caroqliu Mar 26, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It could be null if this.element is itself a document. The syntax is more for the signature of isAmp4Email, so we would still need a type assertion:
isAmp4Email(/** @type {!Document} */ (doc))

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

10 participants