Skip to content

🖍 Styles from ampshared.css can apply unexpectedly to img elements on “pre-valid” AMP pages #34402

@westonruter

Description

@westonruter

Description

In two cases recently, users of the AMP plugin for WordPress have reported issues with ampshared.css applying position:relative to img elements in part unexpectedly, although also expectedly since the pages are not valid AMP. However, the pages are using img elements in a way that they should eventually be valid once #30442 is realized and img is valid AMP.

SSR'ed amp-img > img which has width & height

An amp-img > img element gets a fill layout with absolute positioning inside of its statically-sized container. As such, the img does not need a width or height. When AMP Optimizer does SSR, the img may be prerendered as a hero, in which case the page will have the img in the original markup without waiting for the AMP runtime to create it lazily. A problem arises when optimization layers like Mod_Pagespeed may see such img elements and automatically add width and height attributes in a well-intentioned attempt to reduce CLS (see apache/incubator-pagespeed-mod#2067). This causes two problems in AMP:

  1. The validator doesn't allow width and height attributes on SSR'ed hero img elements, resulting in an invalid AMP page.
  2. The ampshared.css stylesheet has two rules with selectors containing [width][height][sizes] which inadvertently gives the element position:relative, which has the effect of hiding the image when intrinsic layout is applied since the sizer pushes it into the overflow.

issue1

Native non-AMP img elements with width, height, and sizes attributes

Similarly to the above, when a non-AMP img is used on the page and it has width, height, and sizes attributes then the aforementioned CSS rules will give the element positoin:relative when it may be needing absolute positioning. This issue will become more and more common once amp-img is deprecated, as img[loading=lazy][decoding=async][width][height][sizes] elements will start appearing on AMP pages much more often.

For example, consider the Cover Block in WordPress which has an image positioned absolutely with a fill layout and some text overlaying it. In the following example, the fill layout is broken because relative positioning is being applied.

issue2

Conclusion

The two problematic CSS selectors in ampshared.css are:

  • [width][height][sizes]:not([layout]):not(.i-amphtml-element)
  • [width][height][sizes]:not([layout]):not(.i-amphtml-layout-responsive)

The latter was introduced in #28115 while the former is much older, originating in #12077.

Reproduction Steps

See test case: https://ampshared-img-styling-issues.glitch.me/

Relevant Logs

No response

Browser(s) Affected

Chrome, Firefox, Safari, Edge, UC Browser

AMP Version Affected

2104302228000

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions