Johannes Odland

Web Wish 24: ::first-letter

2024-12-24T09:30:00Z

Finding the wish for my 24th entry was no small task. But, I decided to focus on a long-standing wish of mine: making ::first-letter work with Norwegian typography.

::first-letter lets you select the first letter of an element – including associated punctuation. One of its major use cases is to allow authors to create drop caps and other types of enlarged initials.

However, typographical conventions vary across countries and languages. For instance, in Norwegian, a line can start with a guillemet («) or a quotation dash with an intervening white space (- ). These opening quotation marks should be included in ::first-letter alongside the following letter.

For a time, it seemed CSS would support this quotation dash convention, but it was later resolved to allow only typographic spaces in the ::first-letter, disallowing regular space and no-break space.

While there are many typographic spaces, none match the size of a regular space, which adjusts with the font's width. To my knowledge, no other space can substitute for a regular space (U+0020) or a no-break space (U+00A0).

So, for Christmas Eve I'm wishing for the CSS pseudo-elements specification to support quotation dashes with regular and no-break spaces.

Relevant issues and PRs:

[css-pseudo-4] Allow intervening space and no-break space in ::first-letter, preceding the letter

Web Wish 23: Children Changed Callback

2024-12-23T15:00:00Z

Handling nested custom elements can be frustrating.

When the parent element is connected, it might have all, some or none of its children connected, depending on how the custom element is constructed. More children can be added later by the parser or a script.

<script>
    class ChildCountComponent extends HTMLElement {
        connectedCallback() {
            console.log(`${this.localName} has ${this.children.length} children when connected`);
        }
    }
    customElements.define("component-a", class ComponentA extends ChildCountComponent {});
</script>
<component-a><p>Child</p></component-a>
<component-b><p>Child</p></component-b>
<script>
    customElements.define("component-b", class ComponentB extends ChildCountComponent {});
</script>

In the example above, <component-a> will have 0 children when connected, as the element is already defined when the parser encounters the element. <component-b> will have 1 child when connected, as the custom element is upgraded after the parser is done.

To handle all of these cases, you have to set up a MutationObserver and react to the addition (and removals) of child nodes. You could set a timeout, and pray the browser is done parsing the component when it yields. Risky business 😅.

Even if you manage handle the addition and removal of children, there's a remaining issue. If the child is a custom-element itself, can you be sure it's upgraded?

You could wait for customElements.whenDefined() if you control that child element yourself, but that doesn't work if the definition of that custom element is out of your control.

To make all of this a bit simpler, I wish for childChangedCallback() and childDefinedCallback() lifecycle callbacks.

Relevant issues and PRs:

– Need a callback for when children changed or parser finished parsing children

Web Wish 22: Flex-Wrap Balance

2024-12-22T15:00:00Z

When using flexbox to layout items in multiple rows, you easily end up with only one or a few items on the last row. All the remaining space is distributed to the last row.

A flex-container with no balancing.

If you're also using flex: auto on the items to make them fill the entire row, the items on that last row can end up awkwardly large.

A flex-container with no balancing and `flex: auto` on the items. The item on the last row is ends up filling the entire width of the container.

What if we could control this, similarly to how we control text wrapping with text-wrap: balance?

Then we could ensure a more even balancing, and that the last row does not end up with a single item.

A flex-container with balancing.

But, there's room to improve!

A normal pattern is to give the first items in a layout some extra focus. What if we could control how the wrapping algorithm distribute the extra space? Then we could control whether the remaining space would be distributed towards the start or the end of the cross axis.

A flex-container with balancing and control over distribution of the free space.

This would help immensely when setting up a product page or an image gallery.

For Christmas, I'm hoping the CSS working group will resolve to specify flex-wrap balancing.

Relevant issues and PRs:

[css-flexbox-2] Add flex-wrap: balance;

Web Wish 21: Has Slotted

2024-12-21T15:00:00Z

Need to style your web-component differently depending on whether a slot has a slotted element?

Right now you would need to listen to the slotchange event, and check if the slot has any assignedNodes, and set a class to style the element.

const slots = this.shadowRoot.querySelectorAll('slot')
for (const slot of slots) {
  slot.addEventListener('slotchange', () => {
    slot.classList.toggle('has-slotted', slot.assignedNodes().length > 0)
  })
}

slot:not(.has-slotted) {
  display: none;
}

It would be awesome if it was possible to style the slot based on whether it has slotted content, without waiting for the javascript to run.

slot:not(:has-slotted) {
  display: none;
}

There is an open issue for a :has-slotted pseudo-class, and things have been moving fast.

The CSS Scoping spec is now updated with a :has-slotted section, and there are prototypes in Chrome and in Firefox.

I hope the CSSWG keep up the momentum, so that we might soon have a :has-slotted pseudo-class, and perhaps, in time, a functional :has-slotted() pseudo-class.

Web Wish 20: Text Fill

2024-12-20T15:00:00Z

If you need a text with a fill, you can always put that fill in the background, clip the background to the text, and make the text transparent so that the clipped background becomes visible.

It works across all modern browsers.

background-image: linear-gradient(to bottom in oklch, blue, red);
background-clip: text;
color: transparent;

Text with a gradient background fill

But, if you use text-shadow on the element, you might be in for a surprise. The “text” you see is a clipped background, and the text-shadow will be painted on top of it.

background-image: linear-gradient(to bottom in oklch, blue, red);
background-clip: text;
color: transparent;
text-shadow: 1px 1px 0 black;

Text with a black text-shadow on top

The CSS Fill and Stroke Module defines a fill-image property that would let you fill the text properly, so that it would work in combination with the text-shadow property. As far as I know, none of the browsers implement this property for inline text elements.

Today I'm wishing for browser implementers to support the fill-* properties for inline text.

Relevant issues and PRs:

text-shadow paints on top of text styled with background-clip: text;

Web Wish 19: Display Invisible Characters

2024-12-19T15:00:00Z

Typography holds particular interest for me, coming from a small country where unique typographical conventions emerged alongside our journey to independence from a union with neighboring countries.

Maintaining those conventions is hard, as technology has continually eroded them.

Numbers, in Norwegian, should be formatted with space as a thousands separator. To ensure numbers are not broken across lines, a non-breaking space should be used.

But, non-breaking spaces are hard to enter and impossible to visually distinguish from regular spaces in an input field.

Similarly, it's impossible to verify that soft-hyphens are inserted at the correct positions. Without soft-hyphens, long compound words can be pushed entirely to the next line, disrupting the flow of text and making it harder to read.

Both of these are important characters when preparing Norwegian text for publication.

The core issue is that invisible characters are nearly undetectable during editing.

This issue has been solved in other tools, like Word, which allow toggling the visibility of invisible characters during editing. We should be able to solve it on the web as well.

Fortunately, there's a proposal for toggling the visibility of invisible characters using text-transform.

Example:

text-transform: visible-whitespace;

This holiday, I'm wishing for progress in standardizing a way to show these invisible characters in editors.

Web Wish 18: Sticky Next

2024-12-18T15:00:00Z

Sticky positioning lets you “stick” an element to a position relative to the scroll-port, instead of scrolling it out of the screen.

It's awesome.

But o, so limiting.

The element will only be “stuck” as far as is possible while staying within its containing block, which is the nearest block-level container. It would be great if we could choose a different containing block.

It's not really possible to configure how far inside that containing it should stay sticky. Or, it is, but the CSS working group has resolved to remove that option. It would be awesome if it was possible to configure the insets from the containing block, and not just the insets from the scroll-port.

It would also be awesome if we could let sticky elements stack against each other.

So, this year I'm hoping the CSS working group and browser implementors can start looking into how we can make sticky positioning even better.

Relevant issues and PRs:

– [css-position] Meta-issue: Unresolved sticky positioning use cases

Web Wish 17: Viewport Relative Lengths

2024-12-17T19:00:00Z

Viewport relative units come in really handy when you need to size elements relative to the viewport, say a hero element that should have the exact size of the viewport.

There's one catch though, the size of the viewport can change dynamically as mobile browser interfaces, like the address bar, expand and collapse as users scroll. If the elements on the page expand and collapse as a result, the layout of the page ends up unstable, and the user can experience bouncing around the page as he changes scroll direction.

This is why browsers made vh units stable, reflecting the size of the viewport with browser interfaces collapsed. This ensures that the layout does not shift unexpectedly, providing a smoother user experience.

This also prompted the CSS working group to standardize new viewport units. The new units include two stable sets: one for the large viewport with interfaces retracted (lv*), and one for the small viewport with user interfaces expanded (sv*). The final set of units allows authors to opt in to dynamic sizes (dv*).

Most of the major browsers support the new viewport units correctly, except for Firefox on iOS.

The new units were a big step forward, but there's still a challenge: inconsistent support in In App Browsers (IABs). Apps like social media, messaging platforms and other services often open links in IABs, to keep users within their ecosystems. Unfortunately many of these IABs fail to implement viewport units correctly.

In fact, the SFSafariViewController does not seem to handle the viewport units correctly. This is particularly problematic, since SFSafariViewController is widely used in popular apps like Slack.

This is a major frustration for authors that have to maintain fragile javascript workarounds to make sure their page layout doesn't break – and for users who experience broken pages as a result.

Today, I'm wishing for Apple and app developers to collaborate on fixing viewport units in IABs, making viewport-based layouts more reliable for authors and users alike.

Web Wish 16: Role Text Next

2024-12-16T15:00:00Z

How should CAT or IV be read by Assistive Technology (AT)? Should it be pronounced “C-A-T” and “I-V” or as “cat” and “Roman numeral four”?

Currently, this decision is left up to AT and browsers, which is practical and “safe”. As authors we can't predict if the content will be spoken aloud or rendered in braille.

However, the AT and the browser can't always infer the authors intent. For example, splitting cat into separate spans might be purely decorative, and “IV” could mean intravenous in stead of a numeral.

Say Hello (and Goodbye) to `role=text`

For a time there was a proposal to add role=text to ARIA. This role would flatten the accessibility tree, presenting the contents as plain text. Additionally, it would allow aria-label to override the presentation of the contents.

Both WebKit and Blink implemented support for role=text, and many sites started to rely on it. But in 2023 WebKit dropped support, and ARIA closed the re-add role=text issue shortly after.

Why `role=text` Failed

Many opposed role=text, and with good reason:

Flatting the accessibility hides the underlying structure, which can deny the users the ability to inspect the original content.
While breaking up IV into I V might help speech synthesis, it could confuse braille users by teaching incorrect spellings.
Often there's a better solution, such as using role=img in ♥︎ New York. Here role=img communicates that “love” is represented as an icon.

Today role=text is practically dead, though it's still behind a flag in WebKit, awaiting complete removal if there's no protests.

Exploring Alternatives

For a while there was an initiative to add a new aria-textseparation property that would let authors specify how text content should be separated from neighbouring elements. Unfortunately the proposal has been stagnant since 2019.

There has been some progress, though. ARIA 1.3 has added aria-braillelabel that allows us to provide a separate accessible name for Braille. There is also ongoing work to enable text-to-speach to pronounce words correctly.

The Remaining Issue

An unresolved problem involves text that is split into separate inline elements for presentational purposes.

Consider the following example:

<a href="#...">
  <span style="...">Fear the goverments</span>
  <span style="...">gift will be expencive</span>
</a>

Using VoiceOver on an iPhone, this will read as two separate elements:

“Fear the governments, link”
“gift will be expensive, link”.

Luckily, for anchor elements (and others with a role that accept aria-label) we can fix this:

<a href="#..." aria-label="Fear the governments gift will be expensive">...</a>`

However, if the text isn't part of an element that support aria-label, there is no way to tell AT whether to read the text continuously or with pauses.

It's important for AT users to inspect structural changes, but excessive detail can create noise. I see that in many cases AT users should be able to inspect that something is happening with the text, For instance:

<span>C</span><span>A</span><span>T</span>

This might be split for animation purposes, and would be invisible to users with prefers-reduced-motion: reduce. However, some AT would still read each characters separately, leading to a noisy experience.

Excessive verbosity can sometimes hinder more than help.

My holiday wish

This Holiday season, I'm wishing for a new solution to help AT interpret text that is split into individual elements. It seems like role=text wasn't the answer. aria-textseparation seems to have faded away. What we need is the next role=text.

Web Wish 15: Transparent Video

2024-12-15T17:45:00Z

Today's wish is pretty simple.

We use plenty of videos on our site that are not traditional youtube-style video. This can for example be infographics or other visualizations.

A common denominator is that the content should be able to be integrated seamlessly into the site. It is possible to embed a background color into the video. Unfortunately, the compressed colors will often stand out like a sore thumb, as they don't match the colors of the page.

Additionally, it should be possible to reuse the video in different sections of the page, and those sections might have different backgrounds.

To address this we need transparent video.

Unfortunately, there's no single codec that supports this across browsers and devices. Jake Archibald has described this issue in detail in Video with alpha transparency on the web.

This Christmas I'm wishing for browser developers to put transparent video on their roadmap.

Johannes Odland

Web Wish 24: ::first-letter

Web Wish 23: Children Changed Callback

Web Wish 22: Flex-Wrap Balance

Web Wish 21: Has Slotted

Web Wish 20: Text Fill

Web Wish 19: Display Invisible Characters

Web Wish 18: Sticky Next

Web Wish 17: Viewport Relative Lengths

Web Wish 16: Role Text Next

Say Hello (and Goodbye) to role=text

Why role=text Failed

Exploring Alternatives

The Remaining Issue

My holiday wish

Web Wish 15: Transparent Video

Say Hello (and Goodbye) to `role=text`

Why `role=text` Failed