Skip to content

Tag: css

come on, safari

I’m nearing the end of the first phase of a website redesign, teaching myself new CSS, and sprinkling in some JS. Of the things I’m learning, I’m also rediscovering some old Safari linear-gradient issues and seeing some new Safari positioning bugs.

You can follow along if you view the CodePen titled “color-scheme, light-dark, Safari bug”.

The original point of the above pen is to verify linear gradient issues with Safari.

Webkit-based linear-gradient issues are well documented, they behave differently because of the transparent color values. You can see this by switching the theme mode from light to dark, or dark to light. I keep running into linear gradient issues in Safari because I infrequently use them with transparent values and forget they’re still an issue.

CodePen screenshot after switching pen from light mode to dark mode, showing linear gradients that are not ideal
CodePen screenshot after switching the theme mode from light to dark, showing linear gradients that are not ideal. It also shows that the aspect ratio isn’t a square as it should be.

Try the above pen in Firefox or any Chromium browser and the linear gradients are consistently working when switching between dark and light mode.

I found 3 more issues having created this:

  1. In .square, Webkit doesn’t seem to center things consistently using just place-items: center. I am forced to add place-content: center to make the content “this is a square” center consistently with the other modern browsers
  2. aspect-radio: 1 / 1 doesn’t actually work right for the content area of .square. It’s elongated into a rectangle.
  3. Adding position: fixed to .square, which is already centered using the place-* rules breaks the positioning only on Webkit. I am forced to use older positioning methods, i.e. left, top, and transform.

sad twentytwentyfive

Quoted GitHub – WordPress/twentytwentyfive by WordPress (GitHub)

Twenty Twenty-Five is built as a block theme. The theme aims to ship with as little CSS as possible: our goal is for all theme styles to be configured through theme.json and editable through Global Styles.

This makes me sad.

In a different system, a configuration file like theme.json would be considered a design token where a design system will automatically generate a JSON file full of tokens to be used in a component library or website. The potential for design tokens are quite high, but sadly they’re less practical without tools that are configured to both generate the design token file or system and give easy access for developers to use them. Right now, it’s still piecemeal and there’s not a great workflow in many systems.

Modern WordPress development is abstracting a subset of CSS to a JSON file, for the ease of builders and publishers. The developers who build Block Themes are kind of being forced against the grain of the web in the development phase. Developers consumed by a Javascript-centric system, this might make a lot more sense. But, for those of us who want to build using the technology that browsers provide, this is very unappealing and backwards.

This is just another reason I can’t see how much longer WordPress will be serious going forward. Maybe the update to React 19 in Gutenberg will change things, considering that it makes Web Components a first class integration, also considering the possibility of using React Server Components. But, I haven’t seen anything that gives me an indication either of these are being really thought out.

This quote was from the TwentyTwentyFive Github Repo.

4 replies

CSS based design

I am officially hooked! I don’t know when it happened, but I am so in love with web standards. Or obsessed. Or I have been smitten. Not sure which, if not all of these, really describes me best. Either way, web standards are the best thing to happen to the Internet since graphical designs became available.

Web Standards