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>
— 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)
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.
I suggest using HTMLâs existing mechanisms for extension if you plan on being good citizens. Youâve rejected
data-
attributes, saying:âŚ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â
.Citation needed.
If nothing else, how about having a consistent coding style? Youâve currently got the attribute
amp-custom
on thestyle
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 ofamp-
:amp-custom
amp-placeholder
amp-layout
amp-type
amp-shortcode
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 aplaceholder
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.:
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 inamp-anim
element, but the idea is to extend this support to all elements and we should be almost there.