1.0.9

[chachasikes]

• Accommodate main container wrapper needs for CAWeb interaction elements (shift our content into a div .ds-content-layout, which will be used for future design iterations as our Design System external div (preventing conflicts and div injections and changes from theme from slowing down iterations. (Note on implementing layouts like EveryLayout - working in a WordPress editing environment and creating editor parity with the output design benefits from having a reliable basis with minimal class conflicts.
• Merge link fix for Safari issue on hero links
• Temporary fix layout of breadcrumb on default Page type (currently no pages use the default, but we are trying to make sure the default renders similarly to Page layout and can revisit more post-launch)
• Unlink category link from Post pages, we are not using category paths on the site with current design.

[chachasikes]

@rkojik I tried an experiment with you in mind - implementing Every Layout's "Sidebar" and seeing how well it integrated in a WordPress environment. Learned some things (which probably won't surprise you) - but interesting anyways.:

• A page style needs a scope that doesn't conflict with WordPress containers

• Their class specifications, being wildcards, are a little cryptic and with evolving designs and layout needs, I wound up needing to be a little specific. I replaced some of their needs with a class "everylayout" which helped maintain their idea.

• Let's try another one on a future components.

• We are using the headless 🦉 ... I guess - there is theoretical CSS and then there is what happens in WP.

• Really want to have unified templates that headless can use that are also used in WordPress that don't require a lot of adaptation. I hope that having a base wrapper class for the design system helps.

cc @carterm @aaronhans @kkoryaka

Post launch, let's discuss more.

[rkojik]

@chachasikes awesome job! I'm definitely curious how we integrate (what I believe to be) best practices for front-end development with WordPress. One wouldn't think they conflict re: "there is theoretical CSS and then there is what happens in WP"... but as one of my favorite quotes from Troll Hunters (I watch too many kids shows) states, "don't think, become". I'm eager to deep dive that post launch!

[aaronhans]

@rkojik the problem with wordpress' divergence from frontend best practices is severe. This is just a small part of the list of blocking dependencies being loaded on a page.

Also when I audited the cdt.ca.gov site I was seeing slow TTFB so the performance budget gets blown even before you begin to struggle with the typical frontend bottleneck. The magnitude of this issue makes the headless approach more appealing. I am working on that already.

[rkojik]

@aaronhans oh no.... look at all those.

[chachasikes]

@rkojik A tiny example which is very common for PHP based CMS's is looking at the inheritance that happens with just an h1 element.

On GISTs, you have one CSS file, and some style declarations.

In an ecosystem (i.e. an open source CMS with a vast sea of plugins) - the theme, overrides, other plugins, WordPress core might all hook into, override, reset, rewrite, re-reset the h1 element on it's way to rendering. Our is touched 36 times through different class specifiers. This is a tiny example, but is multiplied by a full site. This is where design drag happens.

This is why I'm really interested to

• communicate our content template areas & protect them from inheritances
• link & clearly communicate CSS & markup that's used so that the CSS & HTML templating for the content can have (ideally) a 1:1 relationship with headless (build once, publish out) - through for early development we could have

Wordpress content template + stylesheets (global, page, content, pattern, block) Headless template + stylesheets (global, page, content, pattern, block)

[chachasikes]

The cruft Aaron is seeing is not yet optimized, but also WordPress - like many applications initially developed in the 2000's provides "everything" --- providing "everything" become a bottleneck on mobile devices.

A lot of PHP shops will cache, optimize, CDN and spend a lot of time removing those extra features to get reasonable performance bumps, but even with that, it's very rare to get down the network requests to be able to get optimal performance scores.