[Master feature] Make stories respect responsive units#15955

newmuis · 2018-06-11T18:51:52Z

The fact that the amp-story desktop UI shows up to three amp-story-page elements in view at once can be problematic for designing responsively, because the size of the amp-story-page differs from the size of the viewport, so common responsive practices that are based on the viewport dimensions won't work (e.g. media queries, and the viewport units vw/vh/vmin/vmax).

We can resolve this by rewriting these styles at runtime to refer to the size of the amp-story-page rather than the viewport, but this becomes problematic once there are multiple possible amp-story elements in the document (as will be possible if/when the standalone attribute becomes optional). As such, it becomes important to have scoping for a story's styles, so that we can determine which sizing to use for a given selector.

Proposal

Design

tl;dr: The design is to achieve style isolation by having publishers create <style> tags that are scoped to the <amp-story> that they affect and enforcing the isolation by using JavaScript to modify the selectors at runtime.

Validation changes

If standalone attribute is missing on amp-story, id is required

Runtime changes

In amp-story buildCallback:
- Apply an attribute identifying the story to each amp-story-page, per the page initialization section
- Modify the <style> tag that matches this story's id, per the style modifications section
At ad injection time
- Assume ads must be standalone
- Apply an attribute identifying the sponsored story (using an auto-generated id like i-amphtml-story-id-ad-1) to each amp-story-page, per the page initialization section
- Modify the <style amp-custom> tag from the ad fetch per the style modifications section

Page initialization

When a page is initialized, we should apply an attribute to the page that identifies the story from which it originates, in the format of .i-amphtml-story-id-${id}. For example, given the following <amp-story> tag:

<amp-story id="foo">
  <amp-story-page id="p1">…</amp-story-page>
  <amp-story-page id="p2">…</amp-story-page>
  <amp-story-page id="p3">…</amp-story-page>
</amp-story>

We would transform this to:

<amp-story id="foo">
  <amp-story-page id="p1" class="i-amphtml-story-id-foo">…</amp-story-page>
  <amp-story-page id="p2" class="i-amphtml-story-id-foo">…</amp-story-page>
  <amp-story-page id="p3" class="i-amphtml-story-id-foo">…</amp-story-page>
</amp-story>

Style modifications

Preface each selector with one that matches the class format specified in the page initialization section above (.i-amphtml-story-id-${id}).
For example, given the following <style> tag:

<style amp-story="foo">
  div {
    background-color: yellow;
  }
</style>

We would transform this to:

<style amp-story="foo">
  .i-amphtml-story-id-foo div {
    background-color: yellow;
  }
</style>

Replace all vw/vh/vmin/vmax with the px values based on the size of the amp-story-page element
- Optionally, update on resize
- Use pixel values instead of percentage, because we don't know how deeply-nested the target of the rule is
- There is already some code to convert viewport units in the AMP runtime
TODO(newmuis): Somehow, make media queries compare against the size of the amp-story-page element instead of the viewport

Examples

Example 1

Publisher-authored DOM:

<html ⚡>
  <head>
    <style amp-custom>
      p {
        background: red;
      }
    </style>
  </head>
  <body>
    <amp-story standalone>
      <amp-story-page id="p1">
        <p id="hello-world">
          Hello world!
        </p>
      </amp-story-page>
    </amp-story>
  </body>
</html>

DOM after `amp-story` build:

<html ⚡>
  <head>
    <style amp-custom amp-story="standalone">
      .i-amphtml-story-id-standalone p {
        background: red;
      }
    </style>
  </head>
  <body>
    <amp-story standalone>
      <amp-story-page id="p1" class="i-amphtml-story-id-standalone">
        <p id="hello-world">
          Hello world!
        </p>
      </amp-story-page>
    </amp-story>
  </body>
</html>

Notes:

Because of the presence of the standalone attribute on the amp-story tag, all amp-custom styles for this document are assumed to be for the story present in the document. Because the id was absent in the publisher DOM, it is auto-generated. The id is applied to both the story and the styles.

Result:

p#hello-world will have a red background.

Example 2

Publisher-authored DOM:

<html ⚡>
  <head>
    <style amp-custom>
      p {
        background: green;
      }
    </style>
    <style amp-story="s1">
      p {
        background: orange;
      }
    </style>
    <style amp-story="s2">
      p {
        background: blue;
      }
    </style>
  </head>
  <body>
    <p id="intro">
      Lorem ipsum...
    </p>
    <amp-story id="s1">
      <amp-story-page id="s1p1">
        <p id="hello-world">
          Hello world!
        </p>
      </amp-story-page>
    </amp-story>
    <p id="middle">
      Etiam a tempor...
    </p>
    <amp-story id="s2">
      <amp-story-page id="s2p1">
        <p id="goodbye-world">
          Goodbye world!
        </p>
      </amp-story-page>
    </amp-story>
  </body>
</html>

DOM after `amp-story` build:

<html ⚡>
  <head>
    <style amp-custom>
      p {
        background: green;
      }
    </style>
    <style amp-story="s1">
      .i-amphtml-story-id-s1 p {
        background: orange;
      }
    </style>
    <style amp-story="s2">
      .i-amphtml-story-id-s2 p {
        background: blue;
      }
    </style>
  </head>
  <body>
    <p id="intro">
      Lorem ipsum...
    </p>
    <amp-story id="s1">
      <amp-story-page id="s1p1" class="i-amphtml-story-id-s1">
        <p>Hello world!</p>
      </amp-story-page>
    </amp-story>
    <p id="middle">
      Etiam a tempor...
    </p>
    <amp-story id="s2">
      <amp-story-page id="s2p1" class="i-amphtml-story-id-s2">
        <p>Goodbye world!</p>
      </amp-story-page>
    </amp-story>
  </body>
</html>

Notes:

Because there is no standalone attribute on the amp-story tag, an id is specified on each of the stories. An accompanying <style> tag is found and these styles will be used for each story respectively.

Result:

p#intro will have a green background.
p#hello-world will have an orange background.
p#middle will have a green background.
p#goodbye-world will have a blue background.

Alternatives considered

Wrapping the contents of each amp-story-page in an iframe

Pros

Provides style isolation
Provides JS isolation
Allows analytics to work by just creating a new analytics config at runtime and injecting it into the frame

Cons

Causes serious problems due to unexpectedly reparenting other AMP components
Requires injecting amp-custom styles, amp-runtime styles, and amp-extension="*" styles into every frame
Requires amp-story extension to block the initialization of other AMP extensions, which goes against AMP principles
Potentially very expensive and unlikely to work on lower-end devices

Wrapping the contents of each amp-story-page in a shadow root

Pros

Provides style isolation

Cons

Messes up styles that are reliant on the host context (e.g. amp-story h1), since the styles would need to be rewritten with an understanding of which parts of the selector refer to things in the host context and which parts of the selector refer to things in the shadow DOM
Requires injecting amp-custom styles, amp-runtime styles, and amp-extension="*" styles into every frame

Dynamically insert/remove `<style>` tags, keeping only one active

Pros

It's easy, I guess

Cons

It doesn't really solve the problem because this applies at the document level rather than the amp-story-page level; if there are two content pages visible and one ad page visible, which style tag gets inserted?
Could cause a lot of relayout

The text was updated successfully, but these errors were encountered:

newmuis · 2018-06-14T21:37:05Z

One issue that this has is that it will not work for selectors that select elements that are ancestors of the amp-story-page, or the amp-story-page itself.

One way around this is to include the original style and an inverted variant of the selector. For example, the selector p would become .i-amphtml-story-id-foo p, p .i-amphtml-story-id-foo. This works, but may be computationally expensive, particularly for styles that were already inefficient (like those containing *). We could potentially just rewrite problematic selectors further (i.e. * .i-amphtml-story-id-foo is equivalent to .i-amphtml-story-id-foo based on assumptions we can make about the document).

newmuis · 2018-06-14T22:16:55Z

This option also breaks, because we'd need to have a deeper understanding of the hierarchy of the document. For example amp-story p would, by default, become .i-amphtml-story-id-foo amp-story p, amp-story p .i-amphtml-story-id-foo, and neither of those selectors are correct (the closest "intended" variant of the selector would be amp-story .i-amphtml-story-id-foo p).

Another option is to do nothing beyond the original proposal and require publishers to write their style in a way that is compatible (i.e. always specify styles on amp-story-page elements or their descendants). This may be more correct semantically, especially if we would like to consider treating pages as a unit and/or splicing pages from one story into another story. However, it is also more difficult to warn publishers about. One way to warn is that in development mode, we could query for the selectors at runtime and assert that they are not targeting anything that is an ancestor of amp-story-page, but even this is not foolproof, as what gets matched by a selector can depend on a number of factors (e.g. viewport size)

jaygray0919 · 2018-06-17T13:16:12Z

Would you consider amp-specific directives. For example, you have amp-img as the amp-specific implementation of img. Perhaps you implement amp-p for a paragraph. etc. As authors, we are 'thinking' amp-story: how to compose content to fit the design. We may wish to reuse content from another source ( text and images another page, etc.) but know that the source content has to be designed to fit the amp-story design.

newmuis · 2018-06-20T16:35:53Z

After today's design review (#15347), the feedback is to continue with the approach of dynamically rewriting the <style> tag within the document, but resolve my comments above by not doing any scoping at all and solving that problem separately, relying strictly on shadow DOM. For now, we will assume all stories to be standalone as well.

@jaygray0919, I don't think we would want to go the route of rolling a new component for each HTML element, but rather (where possible) we'd like to make existing HTML components work as well as possible in our system. As such, we want to respect existing responsive design techniques, as well as enabling reasonable defaults (like making the font-size responsive by default).

erwinmombay · 2018-08-21T02:23:45Z

This is a high priority issue but it hasn't been updated in awhile. @newmuis Do you have any updates?

newmuis · 2018-08-21T16:55:55Z

em and rem are now defined (at the story level) to be responsive to the size of the page, but the amp-story-responsive-units experiment to enable rewriting of publisher-specified responsive styles, media queries, and srcset rules using viewport-based units is still in progress.

ampprojectbot · 2018-09-11T06:42:47Z

This is a high priority issue but it hasn't been updated in awhile. @newmuis Do you have any updates?

ampprojectbot · 2018-11-08T03:17:12Z

This is a high priority issue but it hasn't been updated in awhile. @newmuis Do you have any updates?

ampprojectbot · 2018-11-28T04:45:54Z

This is a high priority issue but it hasn't been updated in awhile. @newmuis Do you have any updates?

newmuis · 2018-11-30T04:26:00Z

This experiment has launched, but there is a bug causing it to not be surfaced (the custom styles are placed on the <amp-story> element, while the base font size is specified on the <html> element). We'll need to fix this issue, and roll it out carefully as a new experiment, so as to minimize breakage of existing stories.

jaygray0919 · 2018-11-30T08:59:30Z

Thanks for update. We have several stories pending the implementation of this feature so will be ready to test when you signal the next release. We also experience problems with some SVGs and will test those conditions in next release.

newmuis · 2018-11-30T16:22:38Z

@jaygray0919 sounds good. Please feel free to file a separate issue for the SVG questions you may have.

ampprojectbot · 2019-01-09T10:20:56Z

This is a high priority issue but it hasn't been updated in awhile. @newmuis Do you have any updates?

ampprojectbot · 2019-02-13T04:24:25Z

This is a high priority issue but it hasn't been updated in awhile. @newmuis Do you have any updates?

newmuis · 2019-02-25T03:32:38Z

Ultimately, we took a different approach here, but this was implemented in #16378 and #20981 should put it into effect on all stories using 1.0.

newmuis added P1: High Priority Type: Feature Request WG: stories labels Jun 11, 2018

newmuis added this to the Sprint H2 June 2018 milestone Jun 11, 2018

newmuis self-assigned this Jun 11, 2018

This was referenced Jun 12, 2018

Design Review 2018-06-14 00:00 UTC (cancelled) #15346

Closed

Design Review 2018-06-20 15:30 UTC (document-level experiments, making stories respect responsive units, extension versioning) #15347

Closed

newmuis mentioned this issue Jun 26, 2018

✨ Initial pass at rewriting viewport units in amp-story #16378

Merged

newmuis modified the milestones: Sprint H2 June 2018, Prioritized FRs Jul 2, 2018

newmuis added the Type: Roadmap Highlight label Jul 2, 2018

newmuis changed the title ~~Make stories respect responsive units~~ [Master feature] Make stories respect responsive units Jul 2, 2018

jasti removed the Type: Roadmap Highlight label Jul 16, 2018

newmuis closed this as completed Feb 25, 2019

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[Master feature] Make stories respect responsive units#15955

[Master feature] Make stories respect responsive units #15955

newmuis commented Jun 11, 2018 •
edited

Loading

newmuis commented Jun 14, 2018 •
edited

Loading

newmuis commented Jun 14, 2018 •
edited

Loading

jaygray0919 commented Jun 17, 2018

newmuis commented Jun 20, 2018

erwinmombay commented Aug 21, 2018

newmuis commented Aug 21, 2018

ampprojectbot commented Sep 11, 2018

ampprojectbot commented Nov 8, 2018

ampprojectbot commented Nov 28, 2018

newmuis commented Nov 30, 2018

jaygray0919 commented Nov 30, 2018

newmuis commented Nov 30, 2018

ampprojectbot commented Jan 9, 2019

ampprojectbot commented Feb 13, 2019

newmuis commented Feb 25, 2019

[Master feature] Make stories respect responsive units#15955

[Master feature] Make stories respect responsive units #15955

Comments

newmuis commented Jun 11, 2018 • edited Loading

Proposal

Design

Validation changes

Runtime changes

Page initialization

Style modifications

Examples

Example 1

Publisher-authored DOM:

DOM after amp-story build:

Notes:

Result:

Example 2

Publisher-authored DOM:

DOM after amp-story build:

Notes:

Result:

Alternatives considered

Wrapping the contents of each amp-story-page in an iframe

Pros

Cons

Wrapping the contents of each amp-story-page in a shadow root

Pros

Cons

Dynamically insert/remove <style> tags, keeping only one active

Pros

Cons

newmuis commented Jun 14, 2018 • edited Loading

newmuis commented Jun 14, 2018 • edited Loading

jaygray0919 commented Jun 17, 2018

newmuis commented Jun 20, 2018

erwinmombay commented Aug 21, 2018

newmuis commented Aug 21, 2018

ampprojectbot commented Sep 11, 2018

ampprojectbot commented Nov 8, 2018

ampprojectbot commented Nov 28, 2018

newmuis commented Nov 30, 2018

jaygray0919 commented Nov 30, 2018

newmuis commented Nov 30, 2018

ampprojectbot commented Jan 9, 2019

ampprojectbot commented Feb 13, 2019

newmuis commented Feb 25, 2019

newmuis commented Jun 11, 2018 •
edited

Loading

DOM after `amp-story` build:

DOM after `amp-story` build:

Dynamically insert/remove `<style>` tags, keeping only one active

newmuis commented Jun 14, 2018 •
edited

Loading

newmuis commented Jun 14, 2018 •
edited

Loading