WordPress / wporg-showcase-2022

The official theme of the WordPress.org showcase.
https://wordpress.org/showcase/
20 stars 5 forks source link

Q/A of the work in progress #151

Closed jasmussen closed 1 year ago

jasmussen commented 1 year ago

I did a quick review of the showcase work in progress and have a couple of notes. A lot of the feedback here is likely given on work already in progress and is prematurely given, apologies if that's the case. Mainly wanted to capture all of it.

Screenshot 2023-09-18 at 21 25 57

On focusing the search field, we should either make the entire field have a white background (including the loupe), or not change the gray backround color to white.

Main showcase feature

I recognize the following is challenging, but it's also important to get right. The shape of the top header area as it scales responsively, and how the dots appear behind the main feature, should be a bit more rigid. From the mockups, very wide, wide, and normal desktop widths:

Screenshot 2023-09-14 at 11 06 02 Screenshot 2023-09-14 at 11 06 06 Screenshot 2023-09-14 at 11 06 11

Note in those three how the framed/featured site always sits in exactly the same place on top of the dots. On the website, the dots tile and get cropped, as the featured image scales fluidly and the height of the main box remains fixed:

gif

We might need to employ some aspect-ratio magic on the main header feature, so that the ratio between dots and featured site frame remain locked in how they scale. Note as part of that how the padding in the main feature box also changes between the monitor and desktop landing sizes:

monitor desktop

Let me know if you have a path forward here, otherwise I'll try and dive into a codepen, see if we can get this right, it's an important detail.

Subheader links

The mockups use titlecase and have different phrasing and order:

Screenshot 2023-09-14 at 11 11 34

The desktop uses sentence case and sort "All sites" first:

Screenshot 2023-09-14 at 11 11 38

If we have a separate rule to use sentence case for all such links, fine to be consistent here, but we can hopefully fix the verbiage and order.

Filter bar

Screenshot 2023-09-14 at 11 13 51

The Popular tags, Flavors and Categories have a 16px font size, and should be 14 like Search. Ideally we also sort Flavors last.

The whole filter bar should also be 40px tall. Right now the search field is 37.5px and the tag buttons are 44px tall:

Screenshot 2023-09-14 at 11 31 24

This is okay to correct across any site that uses this componentry.

Main index page tags

Is it possible to limit the display of tags on this page to at most 3?

Screenshot 2023-09-14 at 11 15 19

Ideally that could help us avoid the eliding (...) of the text tht happens.

There's also a typo in "Hospitatlity", and some of the tags are lowercase:

Screenshot 2023-09-14 at 11 15 13

Tag review

As per the typo above, here's the current list of tags:

Arts
Bars
Cuisine
Design
Dining
e-commerce
Enterprise
Exercise
Eyeglasses
Eyewear
Fashion
Fitness
home decor
Hospitatlity
Hotels
household cleaners
interior design
Lifestyle
MadeInJapan
Minimalism
Pressable
quartz
Restaurants
Software
Sunglasses
Sustainability
Technology

A few corrections, and I'm assuming here we go with sentence case, if we need to be title-case I'll defer to @thetinyl.

Thumbnail

Screenshot 2023-09-14 at 11 26 00

Can you add a small easeInOut transition, perhaps 0.2s in duration, to fade in the the border color? If you need to turn that off for accessibility, here's a good mixin:

@media (prefers-reduced-motion: reduce) {
    transition-duration: 0s;
    transition-delay: 0s;
    animation-duration: 1ms;
    animation-delay: 0s;
}

Filter dropdown

Screenshot 2023-09-14 at 11 33 45 Screenshot 2023-09-14 at 11 34 19

The token shown on category links looks good, by the way!

Screenshot 2023-09-14 at 11 58 40

Submit a site

Feels close, nice work. Can we use a "centered column" template instead of having the title on the left? There's also a dot pattern at the top that would be good to add:

Screenshot 2023-09-14 at 11 41 08

The footer should also be the dark version, not the light version:

Screenshot 2023-09-14 at 11 43 03

All sites

Very close, nice!

Screenshot 2023-09-14 at 11 44 17

The gap is 60, in the mockups it's 50.

Pagination looks good, but the spacing isn't entirely right (it's wider in the mockups):

Screenshot 2023-09-14 at 11 44 39

There is a dots banner at the bottom missing:

Screenshot 2023-09-14 at 11 44 48

The 70 sites token, and the sort button on the right are misaligned. This is likely because the Sort button is 16px font size, which should be 14 as mentioned for the filter bar:

Screenshot 2023-09-14 at 11 44 55

Some of the thumbnails didn't load for me, or were missing:

Screenshot 2023-09-14 at 11 58 53

This could be related to legacy content, just want to note for awareness.

Indiviual sites

Tonal web

Screenshot 2023-09-14 at 11 52 09

Tonal figma

Screenshot 2023-09-14 at 11 52 20

Coming along really well, nice.

It seems we haven't designed a quote style, is this inherited from News?

Screenshot 2023-09-14 at 12 07 22

It looks good enough, but we might separately want to update this to be same font+size as the body, no left padding, and a light gray left border instead.

A couple of responsive things

On the homepage, the last row shows 2 items on the wide breakpoint:

Screenshot 2023-09-14 at 12 01 22

and one item on the desktop breakpoint:

Screenshot 2023-09-14 at 12 01 28

If we showed 12 items instead of 11, it seems like it would line up with full rows across both breakpoints.

There's a missing max-width on the "view all links" and the footer CTAs. Here on a wide screen it goes edge to edge:

Screenshot 2023-09-14 at 12 03 29

In the mockups, this is bounded to 1920:

Screenshot 2023-09-14 at 12 03 44

View all sites

Again a case of deciding if we capitalize or not (mockups suggeset "View All Sites") so just want to make sure we decide here and stick with it.

It would be nice if through flex magic we could avoid the text ever wrapping (white-space: nowrap) until the mobile breakpoint where they stack. Mockup:

Screenshot 2023-09-14 at 12 05 16

Desktop breakpoint:

Screenshot 2023-09-14 at 12 05 27

Some copy considerations

I'll defer to @thetinyl if she has any input, but just reviewing a few of the 87 sites, there are a couple of things.

Noma:

Noma Projects is the beginning of a myriad of projects that will have food, deliciousness, and education at its core. From special pantry products to new media endeavors to environmental programs, Noma Projects aims to transform the restaurant’s collective knowledge, craft, and spirit into an engine for creative output and positive change.Source: noma.dk

The Line Hotels:

Qualtrics

Caesarstone

Tonal

RollingStone

WhiteHouse

Meta Newsroom

TechCrunch

Method

This might be an older submission, the screenshot is very out of date, but I wanted to bring it up because in the copy, under "source: Wikipedia", the link links to _wp_link_placeholder and thus, is broken.

I'm happy to review additional sites, but this is a good starting point/pattern, and there may be a better/separate place to do this, so I'll stop here for now.

thetinyl commented 1 year ago

@jasmussen Fortunately, there's a handy section in the Brand Writing Guide that covers web formatting for WP.org. The default should be sentence case for titles/headlines, CTAs, tags, etc. 👍

e-commerce → E-commerce Eyeglasses → can we delete in favor of Eyewear? home decor → Home decor Hospitatlity → Hospitality household cleaners → Household cleaners? Maybe delete? interior design → Interior design MadeInJapan → Can we delete this? It only has one site in it. quartz → Quartz, maybe delete? Sunglasses → Maybe delete since there's only one in it? Eyewear may be the catchall.

I'm on board with all of these suggestions for initial launch. That being said, there may have been a strategy behind having so many same-same, but different tags (ex: eyewear, eyeglasses, sunglasses) that I'm not aware of, so I'll look into that further.

but just reviewing a few of the 87 sites, there are a couple of things.

I can do a QA/copyediting pass on the individual site pages along with addressing your notes.

I like the "Why is it in the showcase" section. That section seems unique to this particular page, do we need it in other places too? The only gotcha is that it seems to answer a question I didn't have, so I'm mainly curious if we need to keep the heading or maybe just remove it?

Right now this is an assumption, but there is a required question on the Submit a site form that asks about why a site is being submitted to show case ("What makes this site unique or interesting?"). So for future sites, we should have this information for all that come in. I'm just not sure if we have it for legacy sites, which would explain why some of these pages have that information and others don't. I definitely agree that it should be consistent in how it appears across each site page (where currently applicable).

jasmussen commented 1 year ago

That being said, there may have been a strategy behind having so many same-same, but different tags (ex: eyewear, eyeglasses, sunglasses) that I'm not aware of, so I'll look into that further.

To clarify, I don't necessarily mind a larger amount of tags if it helps as a taxonomy across the depth of the archive. The main aspect where it would be good to build confidence is in the case where a particular tag is used only ever for a single site, in that case it seems less useful as a navigational aid.

but there is a required question on the Submit a site form that asks about why a site is being submitted to show case ("What makes this site unique or interesting?")

Ah yes, good point. I think the reasoning is valid enough, whether it is something that is used only to decide whether a site is worth adding, or whether it's also included in the prose.

There's likely a bit of an editorial responsibility as to what subsequently happens, and it might make sense to have either some content guidelines, or just an excellent post to point to as a "template" or sites. What do you think?

ryelle commented 1 year ago

On focusing the search field, we should either make the entire field have a white background (including the loupe), or not change the gray backround color to white.

The entire input is white, the issue is that's a button next to it, not part of the search. I mentioned this issue in the PR where I implemented this design. I think it would make more sense to leave the entire thing grey, otherwise you get this floating button/text effect:

Focus on input Focus on button
Screenshot 2023-09-14 at 11 51 39 AM Screenshot 2023-09-14 at 11 51 25 AM

Main index page tags

Should this be a content rule- limit chosen tags to <=3, or just the display here restricted in code?

Tag review

This is a content change, so I'll leave that to @thetinyl — these can be changed directly on the site, whatever you decide.

Submit a site

This page hasn't even been addressed yet. You can see the issue is still open here.

Some of the thumbnails didn't load for me, or were missing:

The loading ones are still being processed by mshots. The should show up on the next page load. The white image for "The National Puerto Rican Day Parade" seems to be what mshots sees, so if we want to keep that site it should get a custom image.

We decided separately that it's okay for colors to be auto deduced, but for Tonal specifically, let's update to use #d3c0b7 as the header BG color.

Okay, I assumed marketing or design would go in and change those colors once I added the UI. Do you need me to change that? and for any other site or just Tonal?

It seems we haven't designed a quote style, is this inherited from News?

Probably, feel free to create a new issue on the parent theme to style it differently (unless you want a custom style for showcase, in which case create it on showcase 🙂 )

On the homepage, the last row shows 2 items on the wide breakpoint:

This is also a content issue- there are only 11 items in the "Featured" category. Once the content is updated and 12 items are picked, it should line up in 2 and 3 column layouts.

It would be nice if through flex magic we could avoid the text ever wrapping (white-space: nowrap) until the mobile breakpoint where they stack.

I'll have to look at how this works on the main site, IIRC it was built this way to ensure the arrow was always the full width across and didn't break off the screen. Changing it will also affect the homepage, since it's the same pattern.

Pulling all this together into an actionable-for-dev list, this is what I've got:

jasmussen commented 1 year ago

The entire input is white, the issue is that's a button next to it, not part of the search.

Right, thanks for the clarification. It seems that wp-block-search__inside-wrapper would be the colored container whose background should be updated, and since it's a parent to the focused item, that's non trivial. Keeping it gray even on focus (i.e. removing the white from the focus style) could work too, contrast seems to still work. And if we can't, that's okay too.

Should this be a content rule- limit chosen tags to <=3, or just the display here restricted in code?

I'm happy to defer to content authors on the amount of tags to show. This is mainly an inquiry, can we restrict it just in code? If yes, then that would be great.

Okay, I assumed marketing or design would go in and change those colors once I added the UI. Do you need me to change that? and for any other site or just Tonal?

I'm happy to do it, I don't know if Lauren will be involved with some of the copy work, if yes she could do it too. Forgive me if you've shared this already, and I couldn't find it in the wiki, how do I do this?

This is also a content issue- there are only 11 items in the "Featured" category. Once the content is updated and 12 items are picked, it should line up in 2 and 3 column layouts.

Fantastic, thank you for the clarification.

This is also a content issue- there are only 11 items in the "Featured" category. Once the content is updated and 12 items are picked, it should line up in 2 and 3 column layouts.

👍 👍

Thanks for tackling this. The following are less important in prioritiy, in case it helps triage:

Animate the border color on thumbnail hover Remove underline on view tags (parent theme) Pagination feedback

StevenDufresne commented 1 year ago

Should this be a content rule- limit chosen tags to <=3, or just the display here restricted in code?

I'm happy to defer to content authors on the amount of tags to show. This is mainly an inquiry, can we restrict it just in code? If yes, then that would be great.

I would limit it in code so we don't implement a limitation that leads to sparse archives or make content authors decide which categories are the most fitting.

I also find the truncation distracting on mobile, and maybe should consider only showing 2 on mobile.

400w
jasmussen commented 1 year ago

We can also include a blanket 2-tag limitation.

ndiego commented 1 year ago

Just wanted to note that "View all sites" no longer has left/right padding.

image
ryelle commented 1 year ago

I moved the tags conversation into a new issue: https://github.com/WordPress/wporg-showcase-2022/issues/158 — I've left it as "in discussion" in case anyone wants to add to it, but I'll probably move it to "to do" with the approach in my comment tomorrow.

ryelle commented 1 year ago

I moved the tags conversation into a new issue: https://github.com/WordPress/wporg-showcase-2022/issues/158 — I've left it as "in discussion" in case anyone wants to add to it, but I'll probably move it to "to do" with the approach in my comment tomorrow.

Just wanted to note that "View all sites" no longer has left/right padding.

Yeah… I accidentally introduced that with the constrained width change

Forgive me if you've shared this already, and I couldn't find it in the wiki, how do I do this?

That page is very out of date. The UI in the editor should be explaination enough, but just in case I've also updated the wiki page.

jasmussen commented 1 year ago

Note that I realize I shared the wrong screenshot of the search field. What I meant to share was this:

Screenshot 2023-09-18 at 21 25 57

Sorry about the detour, but it seems like you captured it right, and that the solution, probably, is to not change the bg color on focus.

thetinyl commented 1 year ago

@jasmussen Thanks again for your notes above, I believe most (if not all) have been addressed for the 12 featured sites. In terms of the orphaned words, I'm not quite sure what the best way to fix those would be, as they'll be dependent on a visitor's screen size, right? With the responsiveness?

The UI in the editor should be explaination enough, but just in case I've also updated the wiki page.

Also, TIL that we can control the colors. How fun! Thanks @ryelle for updating the Wiki. I took a quick look at them based on Joen's notes and it looks like all the color changes (for the featured sites, at least) were applied.

ryelle commented 1 year ago

@jasmussen I've updated the site hero dots, I think I've got it as close to what you're describing as possible given how browsers scale. I tried a few other approaches (border-image, 3 separate backgrounds using ::before & ::after, various positioning and repeat rules…), and each had issues with cutting off dots or skewing the dots. The solution I landed on shows a single frame of dots around left, top, right sides, and does not skew or cut off any dots. On small screens, it only shows the line of dots above the screenshot.

If that's still not what you expected, a codepen or some changes from your browser's inspector would be helpful.

ndiego commented 1 year ago

I found a few more items in testing:

jasmussen commented 1 year ago

Thank you all for looking, what a huge improvement this did, both contentwise and design wise. This is getting very close, so nice to see.

I'm not quite sure what the best way to fix those would be, as they'll be dependent on a visitor's screen size, right? With the responsiveness?

Indeed, I do believe that @adamwoodnz had some ideas for a code snippet that would (potentially?) work across wp.org to automatically fix orphans across breakpoints. I wouldn't say this is something we have to do for launch, this is more of a less-urgent enhancement that would be nice to roll out across.

However until then, I think we can leverage the fact that on the desktop view, there's a max-width of 680px, so we can at least optimize for this one breakpoint and make sure that the view which presumably is used the most often, looks good. Here's the Noma example:

noma desktop before

That "combination" will always be orphaned on this breakpoint, but we could change it to the following and it would be balanced at least in this view:

noma desktop after

☝️ please don't take the above edit as anything but a quick experiment, I'll naturally defer to you, Lauren, on the exact copy.

And yes, to your point, even that copy can be orphaned, here a breakpoint somewhere between tablet and desktop:

noma after, orphaned

But it still feels worth it to optimize it for the stable-width desktop breakpoint, IMO. I didn't find that many orphans at that size, so it shouldn't be too big of a lift, hopefully.

jasmussen commented 1 year ago

I've updated the site hero dots, I think I've got it as close to what you're describing as possible given how browsers scale.

Thanks, this is really close, and it might just be good. I still want to try and take a stab in a codepen, see if the aspect ratio idea can work for us, but I appreciate your efforts here 🙏

I'll return with an update in a bit.

jasmussen commented 1 year ago

@ryelle I ended up creating this codepen with caveats:

I think it uses mostly the same approach that you, insofar as it uses absolute positioning to place the feature image on top of the dots background. I fiddled a bit with the clamp values for the inner padding (--hero-padding in the codepen) and did not get them just right, but hopefully they get the general behavior across.

The main place where the codepen diverges a little bit from what's shipping is that it applies an aspect-ratio combined with a min-height and a max-width to fluidly scale the overall height of the feature area, like so:

scaling fluidly

By changing that height fluidly, it avoids this awkward case on the current staging site, where suddenly there's a ton of whitespace above a bottom-aligned feature:

Screenshot 2023-09-19 at 14 35 15

My hope is that the aspect ratio pieces can be mostly copied over from the codepen 🤞 — let me know if this is helpful!

ndiego commented 1 year ago

I am noticing that the background color in Showcase for the header/footer and homepage top section is #1e1e1e (Charcoal) while similar redesigned sections in other areas of the site, like Developer Resources and Patterns, are #23282d (Charcoal 2). The current site header/footer are also #23282d (Charcoal 2). Should we standardize on #23282d?

jasmussen commented 1 year ago

I think charcoal was intentionally chosen here, as the reduced saturation and lightness works well putting the focus on the site itself. But good attention to detail.

Reminds me, as I was web-inspecting the site, I noticed that the breadcrumb bar is 57px tall. It should be exactly 60px, across every breadcrumb bar in fact. Depending on where that component lives, it may be showcase specific, or it may be parent page specific, but wanted to note it. Let me know if this needs a separate issue.

ndiego commented 1 year ago

I think charcoal was intentionally chosen here, as the reduced saturation and lightness works well putting the focus on the site itself. But good attention to detail.

Sounds good. We may want to choose a different background color for the primary nav dropdown then. It looks good with #23282d but feels too close to #1e1e1e.

image
thetinyl commented 1 year ago

I think we can leverage the fact that on the desktop view, there's a max-width of 680px, so we can at least optimize for this one breakpoint and make sure that the view which presumably is used the most often, looks good.

@jasmussen This makes sense. I've looked at all the featured showcase pages and gave the remaining widows some company based on the suggested max-width.

ryelle commented 1 year ago

I've addressed all the items I pulled out in the checklist. I think it was all straightforward, the only thing that didn't work out was the "View all sites" wrapping— if it does not wrap, there's not enough space for the arrow on a mid-sized screen, causing a horizontal overflow scroll. I've tweaked it so that it won't wrap on Showcase above 1100px wide (previously it wrapped at 1280ish). If that needs to be tweaked more, @jasmussen, can you create an issue on the parent theme and consider how it will apply to that pattern as a whole?

We may want to choose a different background color for the primary nav dropdown then. It looks good with #23282d but feels too close to #1e1e1e.

The global header lives in wporg-mu-plugins, and those colors are set as custom properties here. @ndiego Do you want to create a new issue on the wporg-mu-plugins repo to discuss this? or does it need to happen before final showcase review?

I noticed that the breadcrumb bar is 57px tall. It should be exactly 60px, across every breadcrumb bar in fact.

Showcase doesn't have breadcrumbs, but I'm guessing you meant the local nav bar. I've updated the padding to make it 60px exactly.

ndiego commented 1 year ago

The global header lives in wporg-mu-plugins, and those colors are set as custom properties here. @ndiego Do you want to create a new issue on the wporg-mu-plugins repo to discuss this? or does it need to happen before final showcase review?

The color of the dropdown looks good on all sites except on Showcase (IMO). I don't think any modifications need to be made to the base colors, just how we handle the colors on Showcase. I'm not sure what the best course of action here is, so defer to @jasmussen and @marko-srb.

Showcase Other Pages
image image
ryelle commented 1 year ago

Right, the charcoal-1 header is a variation of the global header, and the colors used in it are controlled there. Changing the dropdown color for charcoal-1, even if it's currently only used on showcase, would need to happen in wporg-mu-plugins, in the file I linked.

ndiego commented 1 year ago

Right, the charcoal-1 header is a variation of the global header, and the colors used in it are controlled there.

Oh gotcha, sorry I misunderstood that this was a variation. I'll add an issue over there in a bit.

jasmussen commented 1 year ago

When the background is charcoal-1, the dropdown is charcoal. We can invert that so when the background is charcoal, the dropdown is charcoal-1. Would that work?

ndiego commented 1 year ago

When the background is charcoal-1, the dropdown is charcoal. We can invert that so when the background is charcoal, the dropdown is charcoal-1. Would that work?

I added an exploration here: https://github.com/WordPress/wporg-mu-plugins/issues/451

ryelle commented 1 year ago

@jasmussen Thanks for the codepen, it was helpful to see your take on it. I've updated the site hero again, and it appears to be centered correctly now. I also updated the style for when it switches to a single column.

I think that addresses all of the dev tasks in this issue, is that correct?

jasmussen commented 1 year ago

Glad it helped! That said, I'm still seeing this happen (a lot of whitespace above the feature image around the tablet breakpoint), and no aspect-ratio applied. Let me know if I'm seeing a cached version or something.

Screenshot 2023-09-20 at 08 43 39

I think that addresses all of the dev tasks in this issue, is that correct?

Nice! Huge improvement across. Lots of good details. A few small things, that I would say are not blocking. In the Figma, the gap between submenu items is 24px. I know that's off-grid, I wonder if it's a piece that Francisco missed. We can go with the 20px gap for now and revisit when he's back to see if it's 20 or 30 or indeed 24. But if it's easy, might want to go with 24 for now, and then correct across the componentry at a later time.

Screenshot 2023-09-20 at 08 48 40 Screenshot 2023-09-20 at 08 44 35

In the super detail territory, there seems to be an errant margin in the filter dropdown inner part, just on the taglist not no the button combo. See the yellow in this screenshot:

Screenshot 2023-09-20 at 08 51 00

Compare with:

Screenshot 2023-09-20 at 08 51 12

I didn't immediately find anything else, and the only important thing is still the header piece. Can the aspect-ratio trick help here?

jasmussen commented 1 year ago

Just to better illustrate the issue with the whitespace above the feature, here is the desired state, where the top row of dots is always aligning with the top footprint of the "Showcase" heading:

Screenshot 2023-09-20 at 08 57 53

On one of the between mobile and desktop breakpoints, I'm seeing the feature with dots being attached to the bottom of the feature area, thus disconnecting the dots with the showcase heading:

Screenshot 2023-09-20 at 08 57 05

This is why I think the aspect-ratio change is likely necessary, so that the overall height of the feature are can still enable the positioning we are looking for.

ryelle commented 1 year ago

no aspect-ratio applied.

It’s applied to the cover block itself because it did not work with the display of the columns block. As you mentioned in your codepen, that CSS was not handling mid & small screens well. I grabbed what was helpful, and ended up with the aspect-ratio on the cover instead.

But if it's easy, might want to go with 24 for now, and then correct across the componentry at a later time.

I’d rather not create an exception to the component behavior until we know it’s intentional, so let’s wait for @fcoveram’s input.

In the super detail territory, there seems to be an errant margin in the filter dropdown inner part

That'll be fixed shortly :)

Just to better illustrate the issue with the whitespace above the feature, here is the desired state, where the top row of dots is always aligning with the top footprint of the "Showcase" heading:

This is more helpful, that was not clear before. I'll see what I can do.

jasmussen commented 1 year ago

It’s applied to the cover block itself because it did not work with the display of the columns block. As you mentioned in your codepen, that CSS was not handling mid & small screens well. I grabbed what was helpful, and ended up with the aspect-ratio on the cover instead.

Understood, but we'll almost certainly need to revisit this again, though, because we need to avoid those dots going under that red line.

ryelle commented 1 year ago

Here's the latest— I've got the margin and padding scaling a bit in that problem zone (1280-1180 wide), so the meta column is never taller than the screenshot. I also updated the spacer a bit to scale as well, so that it should always be aligned.

Here's a video (the red line just for illustration, of course), this is also live on staging if you want to test it.

https://github.com/WordPress/wporg-showcase-2022/assets/541093/a9d3ec0e-83d2-4837-ab99-d341caa80423

adamwoodnz commented 1 year ago

I do believe that @adamwoodnz had some ideas for a code snippet

We used this function on WP20 to prevent widows in titles, and selectively for other content strings, examples.

jasmussen commented 1 year ago

Wow. This is good. Let the record show that I officially owe you a milkshake, or beverage of your choice. Thank you @ryelle, from my perspective this works.

ndiego commented 1 year ago

Looks great @ryelle 💪

ryelle commented 1 year ago

I think we're done with everything here, then! New issues can be opened for anything else 🙂

fcoveram commented 1 year ago

To the space between local nav links

In the Figma, the gap between submenu items is 24px. I know that's off-grid, I wonder if it's a piece that Francisco missed. We can go with the 20px gap for now and revisit when he's back to see if it's 20 or 30 or indeed 24. But if it's easy, might want to go with 24 for now, and then correct across the componentry at a later time.

Yes. I missed that change, sorry for that. 20px looks too tight next to the global header.