-
Notifications
You must be signed in to change notification settings - Fork 384
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Adapt heights, sizes and media attributes for SSR #4482
Conversation
Here's my plan for getting this merged:
|
Good find! Really interesting! I'm wondering whether it'd make sense to make this the default behavior for sizes (for transformed AMP) or whether there are cases where the behavior differs. |
'#__ID__:first-child{height:%s}', | ||
'@media %s{#__ID__:first-child{height:%s}}' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This won't work as expected, as the :first-child
is a pseudo-selector qualifying what it is attached to. So this would match elements that have ID of __ID__
which are the first-child position. So it needs rather to be:
'#__ID__:first-child{height:%s}', | |
'@media %s{#__ID__:first-child{height:%s}}' | |
'#__ID__>:first-child{height:%s}', | |
'@media %s{#__ID__>:first-child{height:%s}}' |
So it selects the first child of the element that has the ID.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, you are right. Will correct.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
... I just realized that it is not the height
that needs to be adapted for the sizer, I think, but the padding-top
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
... which can't be set as it is inlined by JS already. 🤔
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So, as the Optimizer is the one that inlined the padding-top
, I could skip that if I detect that I already had a heights
attribute that turned into CSS.
But at what point are we just plain "hacking" here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh, I could actually store the CSS and properly inline it onto the sizer. That way, I can omit adding it to the size-limited <style amp-custom>
as well.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm running in circles here. Inline styles don't allow for media queries. I will just skip adding the padding-top
in that case for now.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, I've got a working version now. Not the most elegant stuff, but it seems to work as expected.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm noticing differences in the rendering of the elements in with and without SSR here.
Given this post_content
:
<!-- wp:paragraph -->
<p>Heights:</p>
<!-- /wp:paragraph -->
<!-- wp:html -->
<amp-img alt="AMP" src="https://amp.dev/static/inline-examples/images/amp.jpg" width="320" height="256" heights="(min-width:500px) 200px, 80%">
</amp-img>
<!-- /wp:html -->
<!-- wp:paragraph -->
<p>Sizes:</p>
<!-- /wp:paragraph -->
<!-- wp:html -->
<amp-img alt="Hummingbird" src="https://amp.dev/static/inline-examples/images/hummingbird-wide.jpg" width="640" height="457" srcset="https://amp.dev/static/inline-examples/images/hummingbird-wide.jpg 640w,
https://amp.dev/static/inline-examples/images/hummingbird-narrow.jpg 320w" sizes="(min-width: 650px) 50vw, 100vw">
</amp-img>
<!-- /wp:html -->
<!-- wp:paragraph -->
<p>Media:</p>
<!-- /wp:paragraph -->
<!-- wp:html -->
<amp-img media="(min-width: 650px)" src="https://amp.dev/static/inline-examples/images/hummingbird-wide.jpg" width="640" height="457" layout="responsive">
</amp-img>
<amp-img media="(max-width: 649px)" src="https://amp.dev/static/inline-examples/images/hummingbird-narrow.jpg" width="320" height="229" layout="responsive">
</amp-img>
<!-- /wp:html -->
The sizes
and heights
don't seem to be working right:
Width | Without SSR | With SSR |
---|---|---|
600px | ||
700px |
The media
example is working, however.
This is using the Twenty Twenty theme.
I'm currently investigating the visual regression with SSR. What I can already see is that the SSR is somehow changing the images from |
The differences were due to the fact that the I resolved this by deferring the attribute removal via 8767882 With your post content, on my system it looks identical now. Please double-check on your end. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It works!
Based on the above issues I also created a new issue #4671, as I think we're at a point where that could drastically reduce peer review time without impacting general coding too much. |
Yes, great idea. That will be very useful. |
Summary
This PR adds logic to the
ServerSideRendering
transformer inampproject/optimizer
to adapt theheights
,sizes
andmedia
attributes on AMP elements and turn them into CSS. This is done so that they don't block server-side layout application.The PR also moves the
AMP_DOM_Utils::get_element_id()
toAmpProject\Dom\Document::getElementId()
and deprecates the previous method.Fixes #4439
Checklist