-
Notifications
You must be signed in to change notification settings - Fork 3.4k
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
Try more universal rich text controls #2085
Conversation
This reverts commit e9cd340.
One thing to look out for in reviews:
|
Just catching up on this topic! |
Yeah I was trying to find folks that could potentially help us out from other team to see what kind of impact on the rendering this has. We'll keep you posted once we can test more and confirm whether or not it's a concerning hit on performance 👍 |
Alrighty, I've explored/tested render times and it didn't to be an issue. I tried with a little over 20 sections that had
I'll re review the PR either today or next week so we can finally get it into the theme 👍 |
@ludoboludo @kjellr Yup I agree - after Ludo ran many tests with storefront renderer using a LOT of inline-richtext settings I don't see any performance impacts on rendering time. We can keep an eye on lighthouse scores and real user metrics but I really doubt we'll see any impact, especially since most pages and sections will be cached. |
Wonderful, thank you both! |
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.
Looking good, a couple small comments for nitpicks. But otherwise good.
Co-authored-by: Ludo <ludo.segura@shopify.com>
Co-authored-by: Ludo <ludo.segura@shopify.com>
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.
@ludoboludo any idea why the PR is failing tests all of a sudden? Not much has changed in the PR lately. 🤔 Edit: All set, just needed to be re-run. thanks! 🙌 |
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.
LGTM with comments addressed
🎩 on os2-demo store on Chrome and looks great
@media screen and (max-width: 749px) { | ||
.banner:not(.slideshow) .rte a, | ||
.banner:not(.slideshow) .inline-richtext a:hover, | ||
.banner:not(.slideshow) .rte a:hover { | ||
color: currentColor; | ||
} | ||
} |
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.
Nit: Does this need to be in a media query? If it's true all the way from 0 - 749px then it should be outside of a media query.
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 doesn't technically need to. But in this case, we have multiple rules that are inherited correctly on desktop by default.
We could definitely remove the max-width
media query here, but then we'd need to take corrective action on 750 and above to replicate the way it would've normally appeared. This doubled the CSS rules, and seemed heavy-handed to me (especially considering there are lots of other (max-width: 749px)
breakpoints used in this file already).
Basically, it's a choice between this:
@media screen and (max-width: 749px) {
.banner:not(.slideshow) .rte a,
.banner:not(.slideshow) .inline-richtext a:hover,
.banner:not(.slideshow) .rte a:hover {
color: currentColor;
}
}
... or this:
.banner:not(.slideshow) .rte a,
.banner:not(.slideshow) .inline-richtext a:hover,
.banner:not(.slideshow) .rte a:hover {
color: currentColor;
}
@media screen and (min-width: 750px) {
.banner:not(.slideshow) .rte a,
.banner:not(.slideshow) .rte a:hover {
color: rgba(var(--color-link),var(--alpha-link));
}
.banner:not(.slideshow) .inline-richtext a:hover {
color: var(--color-link);
}
inherit
doesn't work in this case, so you're stuck specifying the same variables that are assigned in the original rules from component-rte.css
and base.css
. All in all, I felt that just using the max-width
rule was simpler. Happy to change if you feel strongly though.
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.
Thanks for looking into this. In general I think we should pick either min-width
or max-width
and stick to it but we already do this all over the CSS. I won't be a stickler here.
assets/base.css
Outdated
color: rgb(var(--color-link)); | ||
text-decoration-thickness: 0.2rem; | ||
} | ||
|
||
.inline-richtext a, |
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 think this is always going to override the rule on line 734. Can you delete the rule above or combine?
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.
That's true! Writing it this way was more concise, but it required an override and was perhaps more difficult to interpret overall. I've tidied this up 00292c9.
sections/image-banner.liquid
Outdated
<h2 class="banner__heading {{ block.settings.heading_size }}" {{ block.shopify_attributes }}> | ||
<span>{{ block.settings.heading | escape }}</span> | ||
<h2 class="banner__heading inline-richtext {{ block.settings.heading_size }}" {{ block.shopify_attributes }}> | ||
<span>{{ block.settings.heading }}</span> |
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.
Question: Why do you need the span
elements here and below? Let's remove unless necessary.
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 don't think we need the span
element here, since it doesn't serve any sort of purpose inside of the h2
.
For semantic reasons, the text below should be wrapped in something other than a div
— the inline richtext control doesn't provide outer tags. I guess a paragraph tag makes the most sense? I've made that change in c5535db and also expanded it to cover the slideshow slide, since that has basically the same markup and purpose. These updates result in no visual changes.
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.
One comment but can be tackled as a follow up. I created a PR to change the rich text heading to a inline_richtext
type. So it could be done/looked into there 👍
@@ -1,4 +1,5 @@ | |||
{{ 'section-image-banner.css' | asset_url | stylesheet_tag }} | |||
{{ 'component-rte.css' | asset_url | stylesheet_tag }} |
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.
Thank you for helping get this out the door! 👏 |
* shopify/main: update version and release notes (Shopify#2327) add zoom on hover and show spinner when image loading (Shopify#2314) Try more universal rich text controls (Shopify#2085) Hosted video support in video section (Shopify#2248)
* Update image-banner.liquid * Update main-product.liquid * Update collapsible-content.liquid * Update multicolumn.liquid * Update collection-list.liquid * Update featured-collection.liquid * Update main-list-collections.liquid * Update featured-blog.liquid * Update featured-product.liquid * Update footer.liquid * Update newsletter.liquid * Update slideshow.liquid * Revert "Update image-banner.liquid" This reverts commit e9cd340. * Fix image banner implementation. * Update collage.liquid * Update collapsible_tab in Main Product Section * Update image-with-text.liquid * Update product-recommendations.liquid * Update contact-form.liquid * Update video.liquid Update video.liquid * Update collapsible-content.liquid * Add a little bit of inline rte CSS. To ensure links appear correctly. * Update rich-text heading to use inline RTE instead of normal RTE. * Remove paragraphs. * Remove paragraph tags from homepage rich text heading. * Move inline rte code inside of the main rte css file. * Remove unintentional whitespace changes. * Whitespace update. * Code cleanup. * re add classes in icon with text snippet after rebase * Move link styles to base.css * Remove unnecessary asset loading. * Use RTE styles for the slideshow subhead instead. * Slideshow and image banner special cases. * Remove richtext from collapsible row. * Tidying up. * Remove component-rte.css from collage.liquid It doesn't use a richtext component. * Load the rte styles in slideshow.liquid. * Remove unnecessary rule. * Update classname to inline-richtext. * Revert back to the existing richtext field in rich-text.liquid heading. * Use inline-heading class for richtext heading. To retain the same hover color as other headings. * Fix link color inconsistencies. * Move banner--desktop-transparent styles. * Combine CSS Rules. Co-authored-by: Ludo <ludo.segura@shopify.com> * Combine CSS rules. Co-authored-by: Ludo <ludo.segura@shopify.com> * Update wrapper tags for Image Banner & Slideshow. * Remove duplicate calls to component-rte.css * Reformat link color rules to be more readable. --------- Co-authored-by: Ludo <ludo.segura@shopify.com>
PR Summary:
This PR swaps
text
input settings out forinline_richtext
controls in the following places:Collapsible content > HeadingCollapsible content > Row nameMain Product > Collapsible Tab > HeadingScreenshot
🎥 Demo video
09-54-vty50-ilg03.mp4
Why are these changes introduced?
We currently don't universally allow merchants to perform simple inline text formatting (bold, italic, etc.). This is only turned on for a seemingly-random subset of different Sections and Blocks. This PR is an attempt to make those controls more universal.
Fixes #2086 (and also attempts to fix that problem for other similar situations).
What approach did you take?
In general, I manually added various sections to my store and swapped out
text
inputs forrichtext
orinline_richtext
whenever there wasn't a clear reason to avoid doing so.Visual impact on existing themes
Based on my testing, I'm pretty sure this should have no impact — it only adds functionality.
Demo links
Demo Store
Decision Log
inline_richtext
in collapsible row headings.inline_richtext
in collapsible row headings.inline_richtext
in collapsible row headings withinmain-product.liquid
.inline_richtext
functionality out of here too.richtext
field for Rich Text Section's Heading block to useinline_richtext
instead.richtext
in the Image Banner and SlideShow Slide description fields.richtext
here to align with the Image with Text Section's handling of this area, but ran into bugs that would require more intense work. Upgrading to justinline_richtext
is straightforward and introduces none of these issues, so we'll take this as a first step.Checklist