-
Notifications
You must be signed in to change notification settings - Fork 3.9k
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
Conversation
Hey @ampproject/wg-caching, these files were changed:
|
extensions/amp-autocomplete/validator-amp-autocomplete.protoascii
Outdated
Show resolved
Hide resolved
extensions/amp-autocomplete/validator-amp-autocomplete.protoascii
Outdated
Show resolved
Hide resolved
validator/testdata/amp4email_feature_tests/amp-autocomplete.out
Outdated
Show resolved
Hide resolved
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 |
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 |
@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. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Doc update LGTM
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks! @bill97819 FYI
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 |
There was a problem hiding this 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.
@kristoferbaxter @Gregable Would it be possible to use a |
@samouri did this recently in amp-script: amphtml/extensions/amp-script/validator-amp-script.protoascii Lines 196 to 199 in 0acc235
|
# 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" |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
@@ -215,6 +216,14 @@ export class AmpAutocomplete extends AMP.BaseElement { | |||
|
|||
/** @override */ | |||
buildCallback() { | |||
const doc = this.element.ownerDocument; | |||
const isEmail = doc && isAmp4Email(doc); |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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))
Requested changes have been addressed
Related to: #24881
data-amp-autocomplete-opt-in
in the document<html>
tag for email documents to mimic experiment language