amphtml: don't use contents as fallback

specifically

<amp-twitter width=390 height=50
    layout="responsive"
    data-tweetid="651787425052692481">
<blockquote class="twitter-tweet" data-conversation="none" lang="en">
<p lang="en" dir="ltr">
<a href="https://twitter.com/kevinmarks">@kevinmarks</a> a documentation bug! Will fix immediately. Related Github issue 
<a href="https://t.co/J8Kglgh2ki">https://t.co/J8Kglgh2ki</a></p>
&mdash; Malte Ubl (@cramforce) <a href="https://twitter.com/cramforce/status/651787425052692481">October 7, 2015</a></blockquote>
</amp-twitter>

displays the blockquote fallback under the decorated tweet.

Why not just support the same blockquote markup as using

<script async src="//platform.twitter.com/widgets.js" charset="utf-8"></script> 

does?

About this issue

  • Original URL
  • State: closed
  • Created 9 years ago
  • Comments: 32 (14 by maintainers)

Most upvoted comments

Riiiiiight. You just make up attributes. Attributes that already exist in other contexts in HTML. 😕

Um. At some point, you may have to stop referring to AMP HTML as a subset of HTML and just say it’s a different language, because, well, if you invent attributes like this, it is.

We just follow precedent because we want to be good citizens.

I suggest using HTML’s existing mechanisms for extension if you plan on being good citizens. You’ve rejected data- attributes, saying:

We use non-data- attribute for framework attribute because data- attributes are reserved for the application and extended element configuration.

…but what you are doing is extended element configuration. That is exactly what you are doing.

At the very least, you could use class=“placeholder”.

We generally reserve the right to use bare attributes in AMP. That seems to be in idiomatic in the web components world. Disagreement should be uttered there.

Citation needed.

If nothing else, how about having a consistent coding style? You’ve currently got the attribute amp-custom on the style element …but plain ol’ placeholder on other elements. If you’re going to mint attributes, how about making them consistent by always having a prefix of amp-:

  • amp-custom
  • amp-placeholder
  • amp-layout
  • amp-type
  • amp-shortcode

Data- is for apps.

Whaa…? Where did this come from? And what’s the definition of an app?

I’m guessing that something that requires JavaScript in order to parse custom elements in order to display an image leans heavily towards the app end of the spectrum.

You understand that because AMP HTML bans any JavaScript other than its own, there’s literally no way that a data- attribute could possibly conflict with anything (“in AMP no other JS could conflict”) but then say “Only future extensions to HTML” …like, what? HTML gaining a placeholder attribute? Which it already has?

That’s exactly the reason why it’s safer not to create new attributes willy-nilly.

Be conservative in what you send.

You are an app. You don’t work unless your js is included, and your required markup is actively hostile to pages working on their own.

How about we use the “placeholder” system for this? It’s still a bit new, but I think it could work very well here. E.g.:

<amp-twitter ...> 
  <blockquote placeholder>
  </blockquote>
</amp-twitter>

It currently requires the child to have a placeholder attribute. The placeholder elements are shown in the “unresolved” and “unbuilt” states automatically. Basically, placeholders are kept around and displayed until the element itself is ready to hide it. It’s currently supported in amp-anim element, but the idea is to extend this support to all elements and we should be almost there.