The tag 'amp-story >> amp-video' may only appear as a descendant of tag 'amp-story'.

Hi there,

I’m not sure if my issue qualifies as a bug, sorry if this is not the proper place to tell you about it.

The thing is, when I try to pass the AMP validator and my code has an amp-video in it, I get this error:

Should I say I’m not using an amp-story component on my site, and after checking the amp-video docs didn’t find anything indicating I should, so I currently don’t know how to solve this issue.

Could you shed some light on this?

Thanks!

[Gregable]

@honeybadgerdontcare , the specificity changes fix this.

Short answer is that we have a fix ready for this bad error message (should land in github soon). The actual issue is that the autoplay attribute doesn’t allow a true value. The correct usage is just to add the autoplay attribute with no value. You can use autoplay="" if you want. Same with loop.

Long answer:

The validator potentially has multiple rules for each tag we encounter on an AMP page. Approximately speaking, these rules (represented as a TagSpec) are OR’ed together. That is, if any one of the rules match, the encountered tag is valid. That’s great, except sometimes neither rule matches. Then the validator has to guess which one matched ‘better’ in order to produce error messages.

For <amp-video> tags, we recently introduced a 2nd rule, specific to amp story videos. It’s the same as the original rule, except requires autoplay. We also added a new constraint to both rules. The old rule cannot match inside an amp-story tag and the new rule only matches inside an amp-story tag. This combination produces the validation behavior we want.

So, the validator now sees two possible rules, neither of which match.

For the old rule, it sees the two errors:

Invalid value 'true' for attribute 'autoplay'.
Invalid value '1' for attribute 'loop'.

For the new rule, it sees the error:

May only appear as a descendant of 'amp-story'.

Note in the 2nd case, we suppress attribute errors if there is an ancestor error, since the attribute errors are typically red herrings in these cases. (There are lots of hand-tune choices in this to get good errors).

The validator then prefers the rule with fewer errors. Since the new rule only produces 1 error, the validator picks it, leading to this.

The new change modifies our priorities to look for a more specific error first, and to break ties based on number of errors. Previously specificity broke ties on number of errors. It’s a small tweak, but fixes this case and a few others like it. Attribute errors are considered more specific than ancestor errors.

[orballo]

Thanks for your explanation.