The Web Witch's Blog

Pushing the future of the platform forward with The Web We Want

2020-01-14T00:00:00Z

Last year I joined my co-worker Aaron Gustafson in kicking off an initiative called The Web We Want that focuses on identifying pain points or gaps in the web platform as identified by developers and web designers.

This project has become something I'm incredibly passionate about. It's a cross-platform effort with many browser vendors involved and looking at the problems that have been submitted so far.

But we're not done yet! I'm looking forward to running this at a few events this year. I'll be at the SFHTML5 meetup in March and Smashing Conf San Francisco in April to moderate the session.

The most important part of this initiative, for me, is community participation. This year I would love to see more of the community and event attendees presenting their submissions in the session.

We've successfully presented on behalf of folks who couldn't attend – we definitely don't want the inability to attend an event to be a reason why a submission isn't shared – but the most compelling submissions have been the ones where a community member was able to present their idea either in person or via a recorded video.

These are ultimately your pain points and you know them well and seeing the thoughtfulness that has gone into each video or in-person presentation has been incredibly rewarding and inspiring. There's a lot of passion in this community and I love to see it.

How does The Web We Want work? #

We would love to see more participation this year: more submissions and more videos or in-person submissions. I'll break down how the process goes leading up to a session, to the session and what happens after.

1. Think of a problem or feature gap in the web platform #

Start off by thinking of something you constantly have to hack around. Do you have to build something custom when you think there should be a native way or element for that thing? Maybe there's a feature missing in the browser DevTools that isn't there. Maybe there's an API you've thought of. Whatever it is: it can be extremely broad or very specific. Browser vendors want to know!

Need some ideas? Here are some of the submissions from past events:

2. Submit your idea #

Head on over to the Web We Want website and fill out the form. If you're interested in having your idea shared at a specific event, select that from the dropdown or select "I'm not attending an event, but am open to my submission being shared at one."

Once you've submitted, it may take a few days, but you'll get an email either letting you know if we need more information before we can post up the "want" on the website or a confirmation or rejection with more details.

To avoid getting rejected, my biggest tip is this:

Avoid broad and general complaints like:

"Fewer differences between browsers"
"Just have great tools"

These don't focus on specific problem areas and we can't do a whole lot with it. I'll say we've had to reject very few of the items submitted. So thank you the web community for submitting what you have so far.

3. Leading up to and at a live session #

Depending on the number of submissions for an event session and who is running the event session, we'll assess the "wants" submitted and if the conference audience is the right audience for the "wants" submitted. Someone will reach out a week or two in advance of the event to see if you're coming to the event or will be able to provide a pre-recorded video presentation. We're looking for a presentation that is 3-5 minutes about the problem or feature gap you submitted.

This is a great opportunity to dip your toes into public speaking if you've been thinking about it!

At the event, the session has a few different components:

A panel of 3 industry experts
4-6 lightning presentations about each individual "want" that was selected
Community voting and the judges' choice

I've emceed a few of the sessions so far and it's been a blast. I introduce the session, our panel of industry experts and then we kick off the lightning presentations.

In between each of the presentations, our panel of judges will discuss the problem or feature gap presented and offer their thoughts on each one. (There have been some great and thoughtful discussions that have occurred during the events so far.)

At the end of the session, the judges deliberate to pick which of the problems or feature gaps they think is most pressing for browser vendors and/or standards bodies to work on.

The session audience also gets a chance to vote on what they think is most pressing so we end up having a community winner and a judges' pick winner.

4. After the event #

After the event session, we take the two winning items back to the appropriate folks: browser vendors or standards groups. Some other work needs to take place before we do anything on the browser vendor side and that's where we're at now with the winning wants from last year.

We're working to validate these problem spaces and gather more data before creating a backlog for our engineering teams. We're hoping that later this year we'll start to see some of these things be worked on by teams.

5. I submitted something and it didn't win or it didn't get presented, now what? #

If you're incredibly keen to present and will be at one of our upcoming events but didn't specify that event, please reach out to me on Twitter or shoot me an email.

If you presented your idea and it didn't win, that's still okay! Aaron setup a voting mechanism on the website so folks are able to upvote the items that are most important to them. We'll be keeping a close eye on this overtime to track those upvotes.

The Future of the Web Platform #

I've been on the browser team nearly 4 years already and I've slowly gotten involved with working with web community. I can only speak for what I've seen on the Edge team, but with our work on adopting Chromium over the last year, we have become so much more focused on feedback from the community.

The beautiful thing about The Web We Want is that it's a cross-browser and standards group effort. This is a collective effort by the folks who build the browser to listen to where those who build for the web think we should be focusing our time.

And if you're thinking, I want to be more involved though! Rachel Andrew has a great source for getting involved with the web platform. There are so many different ways to get involved.

Do you host a meetup or a conference? #

One final note, if you run a conference or a meetup and are interested in running this community focused session, please reach out! We'd be happy to see how we can support running The Web We Want in more locations.

The Web We Want Survey Results

2020-05-14T00:00:00Z

14 May 2020

At the end of July 2019, we kicked off our first live Web We Want session. At the start, we only had a handful of submissions and one person willing to record their lightning talk for the session we ran at An Event Apart D.C. We've come quite a ways since then with over 250 submissions to the website.

Myself and Aaron Gustafson have run 5 sessions at conferences and successfully onboarded community members to run an additional 3 sessions at events themselves, resulting in 8 sessions between July 2019 and February 2020.

To start diving into the various Wants that have been submitted, the Web We Want team is initially focusing on the 12 winning Wants from the 6 events that were run last year to start to dig into which of them are the most important problems or areas we should focus on.

Since the Wants fall into different areas and teams, the surveys were divided into three categories: DevTools, HTML/CSS/Layout, and General Browser for more miscellaneous/broader requests.

Each survey asked the following questions for each want:

On a scale of 1 to 10, 1 being "not useful at all", and 10 be "extremely useful", rate each want on how useful you think it is.
Please rank each want from your favorite to least favorite.

A few things to note here:

I started to include a question about the types of roles people consider themselves to be in after the first survey. This can (maybe) help provide more insight into why certain things I was expecting to rank highly, didn't. So that information is missing from the first survey about developer tooling wants.

For the scale of “not useful at all” to “extremely useful”, this formula uses an NPS or Net Promoter Score, which is usually used to help gauge customer loyalty but in this context is more focused on customer attitudes.

DevTools Survey Results #

There were 60 respondents to the DevTools survey and these were the 4 Wants:

Scoring how useful each submission would be #

It would be useful if Browser DevTools put accessibility tooling in a more prominent and easily findable location.

It would be useful if Browser DevTools were able to save the current debugger state to a file in order to load and restore the file back into the DevTools to start debugging from the same place.

It would be useful if the Browser DevTools had a source order viewer built in to identify rearranged content that would cause accessibility problems for screen readers.

It would be useful if Browser emulators did a better job of emulating interaction on mobile devices.

Please rank each of the items from favorite to least favorite. #

These were the results, in order of ranking:

I want accessibility tools front & center
1st choice: 48.3%
2nd choice: 21.7%
3rd choice: 20%
4th choice: 10%
I want improved behavior of browser emulators to match interaction on mobile devices
1st choice: 36.7%
2nd choice: 35%
3rd choice: 18.3%
4th choice: 10%
I want a source order viewer for rearranged content
1st choice: 1.6%
2nd choice: 30%
3rd choice: 36.7%
4th choice: 31.7%
I want to be able to save/load debugger state
1st choice: 13.3%
2nd choice: 13.3%
3rd choice: 25%
4th choice: 48.4%

Notable Verbatims #

A few quotes from survey takers that I thought were worth calling out.

It would be great if all emulation were in the same place. Device, css prefers color scheme query, high contrast, dual screen, responsive mode, etc.

I’m all good, just so glad you’re interested in making the tools better

General Browser Survey Results #

There were 67 respondents to the General Browser survey and these were the 3 Wants:

49% said they were full-stack developers
39% said they were front-end developers
7% said they were in other roles: accessibility consultant, architect, JavaScript developer, Head of Engineering, and "tired old user"
4% said they were designers

Scoring how useful each submission would be #

It would be useful is there was a standard API for event throttling and debouncing.

It would be useful if browsers could localize data like date formatting, currency, time and weight depending on a user's preferences.

It would be useful if browsers could automatically fix fixable accessibility issues such as lack of focus indicators, lack of readability because of low contrast text, etc.

Please rank each of the items from favorite to least favorite. #

These were the results, in order of ranking:

I want browsers to localize data like dates and numbers
1st choice: 29.8%;
2nd choice: 47.8%;
3rd choice: 22.4%;
I want browser to fix automatically fixable accessibility problems automatically
1st choice: 37.3%;
2nd choice: 26.9%;
3rd choice: 35.8%;
I want a standard API for event throttling and debouncing
1st choice: 32.8%;
2nd choice: 25.4%;
3rd choice: 41.8%;

Notable Verbatims #

Accessibility was the hot topic in the survey comments.

Accessibility isn't hard - I see no point in automatically fixing it. Please add support for focus-visible, the element() CSS function, subgrid, gap for flexbox, Web Share API level 2, constructable stylesheets, and CSS modules!

The accessibility thing sounds nice in theory but I guess I'd need to see the implementation? I'd like to think my sites are pretty accessible to begin with, and if it ended up being something I had to test against as a developer to make sure it wasn't breaking anything in the design then I'm not sure how it's helping me.

Please give more focus on accessibility - it would really help all the users while others are like functional/perf related.

If we're going to have good built-in date formatting, we need better date WIDGETS with it. Everyone rolls their own datetime widgets now because of the lackluster browser implementations.

HTML/CSS/Layout Survey Results #

There were 104 respondents to the HTML/CSS/Layout and these were the 5 wants:

48% said they were front-end developers
40% said they were full-stack developers
5% said they were designers
4% said they were in other roles such as Accessibility consultant, UI Engineer, and a Project Manager
3% said they were back-end developers

Scoring how useful each submission would be #

It would be useful if browsers had better native form control and functionality like a date picker, time picker, dropdowns with values fetched from a server, and better handling of large dropdowns with filters.

It would be useful if I could flow content dynamically from one container to another depending on the available viewport by using CSS.

It would be useful if HTML had a semantic <sidenote> element for content such as clarification of words or notes to accompany an article that may keep away from the main story. A footnote tailor for the web and web layouts.

It would be useful if the web had better text justification (text-align) for layouts, with better hyphenation and advanced line breaking.

It would be useful if I could style SVG completely with CSS and not have to rely on JavaScript for things like repositioning and resizing.

Please rank each of the items from favorite to least favorite. #

These were the results, in order of ranking:

I want better HTML forms
1st choice: 67.3%;
2nd choice: 11.5%;
3rd choice: 5.8%;
4th choice: 7.7%;
5th choice: 7.7%;
I want better justification (text-align)
1st choice: 12.5%;
2nd choice: 27.9%;
3rd choice: 28.9%;
4th choice: 16.3%;
5th choice: 14.4%;
I want SVG to be fully styled from CSS
1st choice: 9.6%;
2nd choice: 27.9%;
3rd choice: 33.7%;
4th choice: 11.5%;
5th choice: 17.3%
I want the ability to flow content dynamically from one container to another using CSS
1st choice: 8.6%;
2nd choice: 22.1%;
3rd choice: 21.2%;
4th choice: 33.7%;
5th choice: 14.4%;
I want semantic HTML sidenotes
1st choice: 1.9%;
2nd choice: 10.6%;
3rd choice: 10.6%;
4th choice: 30.7%;
5th choice: 46.2%;

Notable verbatims: #

Y'all want container queries. This is a really complex problem and there are a lot of posts out there about it already so I'm not going to dive into this problem here.

It would be great if CSS could be applied to the native controls (such as a date picker, time picker, etc), similarly to how we can use appearance: none; on a button to style it in any way we’d like.

Container queries is what we want 😊

Container queries would be a 10.

ELEMENT QUERIES ABOVE EVERYTHING

So what's next? #

To be totally honest, this isn’t a straightforward answer as it depends on the Want. Generally DevTools features can be easier to prototype and test and start getting feedback on, but when it comes to web platform features, things are going to take longer especially if standards groups have to be involved.

Recently, I’ve been involved in conversations with team members working on other browsers, as has my co-worker Aaron, about the Web We Want and how we integrate the submissions with other signals from the web community. We're still smoothing out the process, so if you have feedback on how you'd like to see browsers work with the feedback, feel free to engage with us on GitHub or Twitter.

The point I want to highlight here is we are working with other browser vendors to look over everything that has been submitted and are assessing whether it's something already being worked on by browsers, if it's something browsers could work on without standards groups, or if there are already proposals in standards groups that are in the works (here’s a great example of that in action over on the Web We Want GitHub repository.

A great example of something that's already being worked on is the HTML Controls submission (and there were actually a few other submissions on HTML Controls as well). There is a standards initiative called Open UI that's working toward making controls more customizable and extensible, starting with <select>. Even though this problem space is being worked on, the submissions here are still important as it provides additional evidence that browsers are working on fixing the right problems.

The Web We Want In The Time Of COVID #

For the moment, our in-person sessions are on hold, but we're looking into ways to keep the community engaged and active in this intiative so stay tuned for developments there.

We're still taking submissions to the Web We Want, so if you have a problem or feature gap in the web platform, let us know and submit issues on the Web We Want website or upvote submissions. Issues are now being tracked in GitHub in an attempt to allow more engagement and discussion from the community and browser and standards folks. There is no want too small or too big, so let us know and help to move the web platform forward!

What the heck is an Origin Trial?

2020-10-28T00:00:00Z

28 October 2020

My role of the Edge Developer Experiences Ecosystem team tends to revolve around gathering developer feedback. I run an initative called The Web We Want, I setup a new UserVoice page for Edge specific feedback (which I won't link to as it's being deprecated and replaced), and I pay attention to what gets tweeted to me and make sure to tag the right folks so that feedback gets filed. Nevermind all the other places I'm looking: in Standards group forums, Slack groups, blog comments.

There's a lot of places to leave feedback, and when I think about the type of feedback I'm focused on gathering, it's about things that don't have an implementation or solution yet.

Which leads me to browser Origin Trials.

What's a browser Origin Trial? #

Origin Trials are a way for developers to test and use experimental web platform features for a limited amount of time in exchange for feedback. Feedback is key in origin trials as browsers are granting developers access to ensure that the feature makes sense and is usable. It's an iterative and open process and allows the engineers building the platform feature a chance to incorporate feedback and make changes to the feature.

So often in the past, web platform features were developed without input and this offers developers anywhere a chance to try out some new bleeding edge web tech and provide feedback on how it works.

How do I use an Origin Trial? #

Microsoft Edge and Google Chrome both offer Origin Trials for developers.

At this particular moment you might be thinking, wait, Edge and Chrome both have Origin Trials? Aren't they both Chromium browsers? Will the Origin Trials be the same?

And the answers to that are yes, yes, and no.

The Origin Trial program launched back in May during Build for Microsoft Edge and we have platform features, like web primitives for dual screen devices, that our team would be working on and not Chrome. So the sets are different.

Origin Trial Process #

To get started developers should find an Origin Trial they're interested in experimenting with and register for it. You'll register the origin you want to use the experimental feature on and you'll be issued a token.

You'll then have to add some code to your website one of two ways to use the token provided to you.

Option 1: Using a Tag

<meta http-equiv="origin-trial" content="your-token-gues-here">

Option 2: Add Origin-Trial to your HTTP server response headers, example:

Origin-Trial: your-token-goes-here

And that will activate your origin trial. There are some more guidelines about allowed origins, subdomains, URL paths and query params in the Edge Origin Trial Documentation as well as a walkthrough on how to register or unregister an origin trial. Chrome also has a getting started guide for their origin trials though the process should be the same.

Submitting feedback and trial expiration #

At their core, origin trials are provided so developers can try out new APIs before they are shipped and provide feedback about the experience of using the API and browser vendors can then assess and incorporate that feedback if they decide to do so.

These features are not necessarily complete when they're in an origin trial and may or may not be available in other browsers so trials are time-boxed to 6 weeks for two reasons:

If developers would like to continue to utlize the trial they have to provide feedback at the end of the 6 weeks. Again, feedback is key so renewal of the origin trial is based on providing feedback.
This prevents developers from baking is not complete or may need to be revised heavily.

Even if an origin trial is successful, the API will have a period between the end of the origin trial and the feature landing where it will not be available to developers. Most likely there will be improvements to be made before the feature lands.

Provide a fallback #

Origin trials offer a chance to use some cutting edge web platform technology on your website, because of the nature of this kind of tech, the feature may or may not be available in other browsers so always provide a fallback so that your experience doesn't break for your customers who may be using different browsers.

You should provide a fallback anyway due to the limited duration of an origin trial. Maybe you try out a feature and realize it's not what you need.

The edge of the web (no pun intended) #

Origin trials provide a unique opportunity to flip on an experimental feature for all the visitor's to an origin. No one has to turn on any experimental flags to get a feature to work, it just works (again, for a limited time). And it provides a chance for developers to provide critical feedback to API authors.

As I've immersed myself further into the world of the web platform, one constant I seem to hear is that developers want to know what browser vendors / API authors are doing. They don't want these things developed behind closed doors and they want to be able to provide feedback.

Well that moment is here. There are a multitude of ways to get involved, but origin trials provide a very hands on way to do so.

Personally, I'd want to go try out the dual-screen and foldable device primitives available in Edge. As someone with a background in design, the idea of getting to tinker with these CSS and JavaScript primitives to provide an enhanced experience for those on dual-screen devices is exciting.

So go explore! See if there's something experimental Chrome or Edge is working on that you can use and give it a whirl. Be involved in moving the platform forward with us.

Web We Want Progress Update - November 2020

2020-11-13T00:00:00Z

13 November 2020

We've been driving the Web We Want for over a year now, asking developers what they think is missing from the web platform or DevTools.

Before COVID-19, we had run 9 WWW sessions at events with plans to do more. Behind the scenes we’ve been working out a plan on how to evolve this session for the current virtual situation we’re in and still be meaningful.

Stay tuned for news to come there but for now I wanted to provide a brief update on some of the Wants that had been submitted and their current status.

Landed features & in-progress work #

Developers want a source order viewer for rearranged content: The Source Order Viewer was presented at the Web We Want session at Smashing Conf NYC last October and was the Judge's Pick. This feature has landed in Edge Canary.
Developers want accessibility tools front & center: the DevTools team took this as an opportunity to surface accessibility hints in the Issues panel of the browser DevTools.
Developers want a 3D Viewer like in Firefox DevTools: This feature was in-progress when the Web We Want submission came in and is now available in the Edge DevTools.
Developers want better HTML Form Controls: We've received numerous submissions about improving HTML Controls. Edge, Chrome and Salesforce are working alongside the Open UI initiative to drastically overhaul and improve styling controls which is a validated (and large) pain point for developers.

Developers want the ability to flow content dynamically from one container to another using CSS: This proposal relates to CSS Regions, a spec under the W3C that hasn't been updated since 2014 might be worth a revisit with the advent of dual screen devices.
Developers want state-based pseudo-classes for media elements: This want is currently a part of the Selectors Level 4 specification which has been updated as recently as September 2020.
Developers want an overhaul of the Date object: There is a TC39 proposal that provides standard objects and functions for working with dates and times.
Developers want container queries: A continually hot topic of discussion in the web community. The spec hasn't been updated since February 2018, but this is something developers continue to ask for frequently. As of November 5, 2020, the Chrome team has set out an intent to prototype.
Developers want multi-line truncation via CSS : This is currently being addressed in the CSS Overflow Module Level 3 spec, which has been updated as recently as September 2020 but prioritization among browsers for landing this feature is unclear.
Developers want the ability to specify 'line-spacing' instead of 'line-height': The CSS Inline Layout Module Level 3 specification addresses this issue with 'leading-trim'. Microsoft Design is sponsoring the authoring of this spec.

A better way for discussion #

We’ve made some updates as well to allow for a more collaborative environment with the submitted Wants. All of them have been moved to GitHub Discussions in the Web We Want repo where we can add supporting documentation and have a discussion with community members about implementation or standards work already in progress.

We’d love for more community involvement to help drive some of these things. If you’re interested in contributing to an explainer or being involved in the development and future of something, head on over and browse submissions and start a discussion. We’re listening!

Other ways to participate #

Though submissions aren’t being driven by the normal events we would be at, this initiative is still taking submissions.

You can participate by letting us know what you want for the web and filling out the form on the site or by going through the submitted Wants and upvoting what you want to see in browsers or DevTools. We’re paying attention to those upvotes.

We have some more surveys in the works to help prioritize submissions as well. So if you’d like to stay up to date on those and the latest news with the Web We Want, give us a follow on Twitter.

This is a community effort and we’re thrilled to have some features landing in browsers and others in the works through standards groups. Progress is real and happening and I’m so excited to continue to drive this effort.

An Intro to Trigonometric CSS Functions

2023-01-04T00:00:00Z

While perusing the December 2022 post from web.dev about what's new in the web platform, the addition of Trigonometric CSS functions in Firefox caught my eye.

Geometry and trigonometry were my two best math areas in school (I am not an Algebra person and generally did not enjoy math class), so I wanted to a quick look at these functions and what problems they solve for the web platform. When would developers use them?

Trigonometric CSS Functions Overview #

As of December 2022, Firefox and Safari are the two mainstream browsers that support Trigonometric CSS Functions. These include cos(), sin(), tan(), asin(), acos(). atan(), and atan2().

Support in Chromium is estimated to ship in version 111.

Basic use cases per the MDN documentation #

cos(): can be used to keep the size of a rotated box
sin(): can be used to size boxes and as an animation-duration value
tan(): can be used to draw parallelograms
asin(): can be used to rotate elements
acos(): can be used to rotate elements
atan(): can be used to rotate elements
atan2(): can be used to rotate elements and accepts two values as parameters

The MDN docs highlight the differences between the 4 functions for rotating elements. For example, atan() returns the inverse tangent of two values between -infinity and infinity, whereas sin() returns the sine of a number that has a value between -1 and 1.

What problems do they solve for developers? #

At first glance, the use cases for these functions don't seem incredibly compelling to me. The MDN documentation use cases for rotating a shape or defining widths of elements don't seem that useful for a developer. We can already do those things and the examples with these functions seem long winded.

So I went and found the CSSWG GitHub discussion to dig into the "why?"

The main takeaway: these additions to CSS mean more complex animations that can be built with CSS and not JavaScript. This animation example from Ana Tudor is a good example. Trigonometric computations are done in JavaScript to achieve a seamless animation effect where the points line up exactly as they rotate and when the orange shapes skew on each rotation.

Another possible use case that came up elsewhere was using these to create charts and graphs in CSS, but this raises a question around responsiveness and scaling those angles and curves, though responsive skewing is mentioned in the GitHub issue.

Update January 6, 2023

This GitHub issue explains some more use cases for trigonometric functions.

I was surprised to see complex layouts on the list, but when discussing this with Jhey he mentioned using sin() to lay things out on a curve which could introduce some interesting layout possibility!

Here's a demo from Jhey (again, you'll need a browser that supports this feature or Chrome or Edge Canary with the experimental web platform features flag turned on.)

See the Pen Image Layout with CSS Trigonometric Functions ✨ [Tap to toggle] by Jhey (@jh3y) on CodePen.

Closing thoughts #

The addition of more math functions to CSS reduces some reliance on JavaScript which I view as a win. The primary use case for these seems to be easier shape creation and more options for building complex animations.

If you're building and maintaining an average website, I don't see these being overly useful, but I'd love to know if you have a use case for these functions. Let me know on Twitter or Mastodon.

Resources: #

CSS Values and Units Modules Level 4: Trigonometric Functions
Part 1: in CSS and JavaScript: Introduction to Trigonometry by Michelle Barker
Part 2: Trigonometry in CSS and JavaScript: Getting Creative with Trigonometric Functions by Michelle Barker
Part 3: Trigonometry in CSS and JavaScript: Beyond Triangles by Michelle

Want to keep in touch? Sign up for my newsletter to stay up to date with my book (including sales), upcoming projects and events, and other bits about cool things on the web.

A love note to CSS

2023-01-11T00:00:00Z

I was designing a little basic one page checklist for PWA design best practices based off a talk I gave last year (and will give again this year). I may have overdesigned it a bit but I wanted the headings to sit on top of the containing box's top border.

I positioned those headings with position: absolute; so they were removed from the layout of the rest of the content and therefore couldn't affect anything below them. Two of my headings span two lines on small devices and this was making the content too tight together. Adding a different CSS variable for spacing was changing all of the margins on the <article> elements which I didn't want for the top one. Hmph.

But wait.

h2.section-header.long + article will target the <article> elements after any <h2> elements with the .section-header and .long classes.

And there we go. More space on small screens just where I need it.

Update #

Jhey just showed me the <legend> element, which didn't come to mind when building this but would work because I have a set of sectioned checkboxes. I haven't checked to see how easy it is to style but my point still stands that CSS is powerful.

Greater styling control over type with CSS `initial-letter`

2023-01-12T00:00:00Z

Today we're taking a look at another new addition to CSS that's about to land in browsers: initial-letter. This property is still experimental with support in Safari but it is supported in Chromium Canary browsers. It is a bit buggy at times and I encountered issues with DevTools crashing on me so it's still obviously experimental.

What is `initial-letter` and what does it do? #

The CSS property initial-letter brings more control and styling over the first letter in a block of text...meaning we can get a little bit more fancy with our typography without hacky tricks.

Initial-letter is a property that applies to the pseudo element ::first-letter. It lets you control the size of the first letter with a number that indicates how many lines tall the letter should be, and another value, an integer that can be added to indicate how many lines down the letter should sink.

For example, let's say we want our letter to be 3 line lengths tall. We would write the following:

p::first-letter {
  initial-letter: 3;
}

And in turn this would render the letter 3 lines tall:

Let's bring in the second value to change where the letter is. The letter will still be 3 lines tall but we want it to sink to the fourth line.

p::first-letter {
  initial-letter: 3 4;
}

Pretty neat and it only takes a line of code!

What does this solve for developers? #

The power of this property lies in the ability to remove hacks around styling and positioning the first letter of a block of text. There's no wrapping of your first letter in a <div> or anything like that. The ability to size based on line height scales the letter nicely too.

More examples #

Let's look at a more styled demo. You can find the source code on my demo page: CSS initial-letter demo.

Technically we are able to size the first letter based on line height with font-size: 2lh; or however many lines you'd like the letter to be tall. But we get the following with that declaration:

It doesn't quite look right especially when I want to create a really illustration focused first letter. The same thing happens if I try a value of 4lh...

It may be 4 lines high but it continues to create a massive gap below the first line. It doesn't align well with the rest of the type either.

When I use initial letter to handle my sizing though, I get the following design with a letter that aligns nicely to the left of the normal sized text and is actually positioned as 4 lines tall.

The important bits of CSS for the above display are as follows:

  initial-letter: 4 6;
  padding: 2.2rem 2.6rem;
  font-weight: 900;
  margin-right: .5rem;

I've added some padding and font weight to control the styling of the first letter a bit more.

You can inspect the demo for the full set of styles. I would like to note that outlining your letter doesn't appear to work if you have initial-letter applied, which seems like a miss in functionality. I've achieved the outline effect with a text shadow for this demo.

I added an SVG background for the illuminated text treatment, and there's probably some neat animation effects you could apply.

Other notes #

This is just the start of initial-letter, per the Chromium issue, there are still items in the works:

Following CSS properties are not implemented yet:

initial-letter-align
initial-letter-wrap

And following features are not implemented yet:

multi-character initial letters (such as for first word or first phrase styling)
inside-positioned ::marker pseudo-elements
inline-level boxes that are placed at the start of the first line
atomic inline

So stay tuned for more to come.

Browser support #

As of right now, initial-letter is supported in Safari, though caniuse says the implementation is incomplete, and it is coming soon to Chromium.

I'm working in Edge Canary (Chromium) with the experimental web platform feature flag turned on, and the feature just shipped in the beta version of Chrome 110.

Firefox doesn't appear to be support at all though there was a little bit of movement on the Gecko issue for it, but anything beyond that doesn't seem to be clear. Hopefully it will be prioritized as this feature brings some easy to implement capabilities for good typography on the web.

Resources #

Here's my demo page link
A basic codepen
MDN Docs

Serving less data with the `prefers-reduced-data` media query

2023-04-16T00:00:00Z

I want to take a quick look at another experimental CSS feature today that's focused on tailoring what gets served to a user based on their preferences, but this time it's performance based.

Similar to media queries like prefers-reduced-motion and prefers-color-scheme, the media query prefers-reduced-data would allow developers to serve up a separate set of styles for those who want to limit the amount of data that gets downloaded. There are a multitude of reasons someone may want to reduce the amount of data being downloaded (Read: Location, Privilege and Performant Websites).

It's a CSS media query so it gets inserted into a CSS stylesheet and can either be set to to prefers-reduced-data: no-preference or prefers-reduced-data: reduce. Immediately the two resource consuming items that can be controlled via CSS that come to mind are fonts and images.

You can serve up smaller or no images, and you can limit the fonts and font styles that are pulled in. At first I thought these would be the main items you'd want to use the media query. But if you're just serving up smaller sized images, this begs the question, shouldn't you be doing that anyway? Everyone would benefit from smaller image sizes.

The other use case I can imagine is on the extreme end, and is influenced by NPR's text only website they provide for people. You could provide an extremely stripped down version of a website, for the purpose of highlighting the essential content without having to maintain another URL.

In some ways, this seems like a useful media query, but at the same time I'm prompted to ask: does it fully solve the problem of serving less data consuming experiences to those who want that option? Or are there already other ways to do this effectively outside of a media query?

Browser support #

Whether this really solves the problem of serving less data remains to be seen. The media query is not currently supported in any browser. There had been a little bit of activity on the issue last year but there hasn't been much movement since.

In the Chrome DevTools though, you can emulate the media query.

Information and discussion #

Here's the Chrome Status link for the feature. If this is something you want to see in browsers and want to help signal that desire and have a discussion around it, I'd suggest submitting the idea to the Web We Want to track it there (the initiative is starting to kick back up again!).

Mozilla Developer Documentation: Here

Designing for Dual Screen and Foldable Devices With CSS

2023-05-11T00:00:00Z

With the announcement of Google's Pixel Fold, I thought its an apt time to revisit what technologies are available for designing and developing experiences that adapt to a foldable device.

Let's ignore the naysayers who vehemently don't want to design for a new form factor, while also ignoring the price of Goggle's first generation device and just focus on what's possible right now.

CSS Media Queries for Viewport Segments #

There are two media queries for targeting your foldable device.

@media (horizontal-viewport-segments: <count>) { }
@media (vertical-viewport-segments: <count>) { }

The horizontal-viewport-segments query targets the device when it is being held like a book and the two screens are side-by-side.

And vertical-viewport-segments targets the device when the two screens are stacked on top of each other and fold like a laptop. I've found this mode useful when using my Surface Duo with PowerPoint. I can access my speaker notes on the bottom screen and my presentation is on the top screen. Pretty snazzy.

CSS Environment Variables #

In order to get the geometry of each display, a handful of environment variables have been created for dual screen devices.

env(viewport-segment-width <x> <y>);
env(viewport-segment-height <x> <y>);
env(viewport-segment-top <x> <y>);
env(viewport-segment-left <x> <y>);
env(viewport-segment-bottom <x> <y>);
env(viewport-segment-right <x> <y>);

The x and y positions represent the two-dimensional grid created by hardware features that separate each viewport segment, with the coordinates 0,0 starting at the top-left segment.

]

Environment variables are cool because they will calculate dimensions by the device and make the adjustments for you meaning you don't have to create designs for every unique device out there. There are a number of foldable devices already and they all have different screen and hinge dimensions.

This set of environment variables also lets you place and position content across the two screens.

In my demo, I've built a recipe page that changes to a two column layout when on a dual screen device. I'm using CSS Grid and I can use the environment variables as grid column or row values.

@media (horizontal-viewport-segments: 2) { 

    .container {
        grid-template-columns: env(viewport-segment-width 0 0), 1fr;
    }

}

This line of code means that the first grid column will take up the entirety of left display when the device is held in the vertical position (like a book), and the second grid column will take up the remaining width of the display space available, which is the display on the right.

If you wanted to be more explicit, you could write:

@media (horizontal-viewport-segments: 2) { 

    .container {
        grid-template-columns: env(viewport-segment-width 0 0) env(viewport-segment-width: 1 0);
    }

}

Again, this means that each column takes up a display. Pretty sweet.

When should you include a dual screen mode in your product? #

Back to the naysayers. When I first started talking about dual screen design, so many people reacted negatively. And honestly, no one is forcing you to create a website or app that adapts when it's spanned across two displays.

With the Surface Duo, you can utilize the browser in one display pane and it displays like a normal responsive website. Not every site or app does need a dual screen mode, but its best to find out what kind of devices your customers are using and whether or not a dual screen mode is worth the investment. As always, use data to guide your decisions.

The forecast for foldables shipped in 2023 is expected to be above 21 million devices (source). Compared to the mobile device market, its just a sliver, but that's still millions of foldables being used out there.

The other reason I'd create an app or website that adapts for a foldable device? If I wanted to stand out.

The Pixel Fold reinforces that foldables are here to stay, so why not delight your users?

Browser Support #

The media queries and environment variables are currently supported in Microsoft Edge Stable.

Unfortunately, Chrome Stable doesn't appear to have the same support yet which seems like a huge miss for the Pixel Fold & Chrome teams. You can enable the experimental web platform flag under chrome://flags and test in Chrome with the Surface Duo emulator.

Closing #

This article is just an overview and reminder that these capabilities exist for foldable web and app experiences. The space is ripe for innovation in design and layout on the web (and for native apps) as new foldable devices ship, but without the browser and OS support, companies won't be able to get devs and designers to take building foldable experiences seriously.

If your'e still interested exploring what's possible with dual screen layouts, I've a much more in depth article over on Smashing Magazine that walks through the recipe demo I made for the web. So download Microsoft Edge and happy building.

Building better websites with the Chromium DevTools Issues Panel

2023-06-19T00:00:00Z

What feels like a very long time ago, I was leading the design, UX and front-end development for the open source project webhint.io. Webhint is a linting tool that helps improve your website’s accessibility, performance, security, and interop between browsers.

Sometime within the last two years, the web UI for webhint was retired, but there’s still a VS Code extension and a CLI tool, it is also the basis for what is now the Issues panel in the Chromium browser DevTools.

Accessing the Issues panel #

The browser DevTools are packed full of web development tools beyond the defaults that are shown when you open them up.

To access the Issues panel, find the 3 dots in the UI that open up a new menu. I’m in the Microsoft Edge developer tools, and this icon is located in the upper right hand corner.

Find the “More Tools” menu item and that will bring up a complete list of all the tools available in the browser in alphabetical order. Find the “Issues” panel in the list.

After you click on the Issues tool, it will show up in the bottom pane of the UI and if there’s anything amiss with the code you’re inspecting and it falls under one of the rules the Issues tool is checking for, it’ll appear there.

Filtering issues by severity and browser #

In the top toolbar of the lower pane, you can adjust your preferences for what kind of Issues you want to show up and for a handful of desktop and mobile browsers.

The different severity levels you can filter for are tips, info, warnings and errors. And the browsers you can target are Edge, Chrome, Firefox, Safari, Internet Explorer (support may be gone but it still lives on), and Opera on desktop. On mobile you can target Safari iOS, Chrome for Android, Firefox for Android, Samsung Internet, and Android Webview.

Expanding the issue will give you a description of what’s being reported, the resource that’s affected and a link out to some documentation so you can better understand what’s being reported and why you should care about it. It’s up to you to decide from there whether you’d like to fix it or not, but the issues reported on are there to help improve the code you’ve written and make the site a better experience.

Linting in your browser #

This tool brings linting straight to your browsers so you can get an idea of what needs to be worked on, if anything, in your codebase. If you need more robust linting though, you can use the webhint.io CLI to customize even further.

Happy building!

This article originally appeared on dev.to in November 2022

Follow me on Twitter or Mastodon for tech, travel and musings. I run The Web We Want, a place for web developers and designers to submit the things they need from browsers and the web platform to make their jobs easier. Author of Design for Developers. Subscribe to my newsletter to stay up to date with me, get interesting web platform and design related links, and occasional deals on my book and other merch sent to your inbox.

When to use CSS text-wrap: balance; vs text-wrap: pretty;

2023-10-20T00:00:00Z

At the start of the year I had written about how I wanted to spend this year writing about new CSS features landing in browsers. Life happened and it was in my best interest to do things off the web and away from my computer. But I'm picking this back up again because I'm genuinely back in a space to be exploring and creating things again. I wanted to start this little post off like this for anyone else who is struggling with burnout. It's okay to take a break. It's beneficial for your brain and the rest of you. Side projects will always be there to work on.

Now onto good ol' text-wrap.

I was looking into text-wrap and doing some research on the difference between when to use balance and when to use pretty (both are still experimental, but available in Chrome, Edge and Opera.)

text-wrap: balance; #

There is a limit on the number of lines that text-wrap: balance; will apply to but it is dependent on how many lines there are based on the width of your text. Balance will only apply to less than six lines.

In the demo below, if you open the code on Codepen in a supported browser, remove text-wrap while the width is 300px, you'll see text-wrap has no effect. If you change the width to 600px, add text-wrap: balance; back to the CSS - you'll see it does have an effect.

See the Pen CSS Text Wrap: Balance Limit by Stephanie Stimac 🔮 (@seaotta) on CodePen.

With text-wrap: balance;, because there's a limit to how many lines the browser will wrap, this should only be used on headlines, headings, and subheadings. Applying it to large paragraphs will have no effect and comes at a performance cost because the browser is trying to calculate optimal balance even though it won't apply anything.

The example above shows a comparison of a headline without balance applied and a headline with it applied. The first example doesn't look balanced, whereas the second one does.

text-wrap: pretty; #

Text wrap pretty is the opposite of balance and can be used on entire blocks of text but you're only really going to see a difference on the last four lines of text. It's primary use is to prevent orphans - or one word - on their own line.

The browser makes calculations to make adjustments for you. "To balance between the typographic benefits and the performance impacts, it adjusts the last 4 lines of paragraphs that meet certain conditions." Chrome Platform Status.

The differences are subtle when text-wrap: pretty; is applied.

In the image above, the paragraph on the left does not have pretty applied and there is one word on the last line. In the paragraph on the right, with text-wrap: pretty; applied, there are two words on the last line and you can see the slight adjustments to the last three lines to make that second word wrap.

Very subtle, but it provides a solution to avoid any hacks around trying to get rid of those orphan words that visually look out of place on their own line.

Support for pretty is again quite sparse, with only Chromium browser support. Hopefully Firefox and Safari will ship these to help improve typography on the web.

Balance and Pretty #

Use text-wrap: balance; on headings and subheadings. And use text-wrap: pretty; on paragraphs of text to get rid of orphans on the last line. Despite the Chromium-only support, these would be a good candidate for progressive enhancement. It won't negatively affect the experience if someone is not in a supported browser, but it will some visual balance to the page for those in a browser where supported.

Here's the link out to MDN for text-wrap.

Follow me on Mastodon, on Twitter or Instagram and yes I'm on Threads too. I run The Web We Want, a place for web developers and designers to submit the things they need from browsers and the web platform to make their jobs easier.

Author of Design for Developers.

Subscribe to my newsletter to stay up to date with me, get interesting web platform and design related links.

CSS Media Query for Scripting Support

2023-12-04T00:00:00Z

Chrome 120 was released last week and in this version, we got the CSS Media Query for scripting support. Simply, this media query allows you to test whether scripting language are available and tailor page content and styles depending on support.

Media query syntax #

There are three values to choose from for the media query: none, initial-only, and enabled.

The value none means that the user agent won't run scripts for the current document, either because it doesn't support it or support isn't active for scripting.

The value initial-only means that scripting is available during the initial page load, but not after.

The value enabled means scripting is supported and active for the current document and the "lifetime" of the document.

Code Example #

The CSS media query means you can change the styling and content of the page based on a class name. You could have three different sets of content built out in your HTML, and depending on the status of scripting you can show one of those content sets while hiding the other two.

<div class="no-scripting">
No scripting so here's a specific set of content and styles 
</div>

@media (scripting: none) {
    .no-scripting {
        display: flex;
        color: green;
    }

    .initial-scripting {
        display: none;
    }

    .full-scripting {
        display: none:
    }
}

Support #

The CSS media query for scripting support is available in Chrome as of November 29, 2023, and was already available in Firefox and Safari (both released earlier this year in May and September, respectively). Support is coming in Microsoft Edge and Opera, where the feature is currently in preview. There is no apparent signal from Samsung Internet, with no support at all for the feature.

Closing #

This seems like a pretty great feature for progressive enhancement even at the most basic level. You can ensure your users who have JavaScript support disabled get a good experience fairly easily. With nearly full major browser support, this is a great addition to the web platform.

Happy coding!

Edit after publishing: There is indeed a <noscript> tag, but the intention with this media query "isn't to replace noscript. Its just to allow you to style elements based on the script state." - Source Link

CSS Media Query Support for Video Elements

2023-12-06T00:00:00Z

I've been digging around on web platform status pages to see what's come out and what's planned for web developers. You can take the girl out of browser work but you can't take browser work out of the girl. Or something like that.

Here's another media query that recently was reintroduced and brings back support for video <source> elements. It just shipped in Chrome 120, as well as Firefox 120 which included a patch for it. It's also supported in Safari. Additional Chromium browsers such as Microsoft Edge and Opera should receive the update from Chrome.

This gives us another option for responsive HTML video and has web performance benefits.

A Brief Code Example #

You can offer alternative source files depending on the media condition.

<video controls>
  <source src="video-large.webm" media="(min-width: 900px)" />
  <source src="video-medium.webm" media="(min-width: 600px)" />
  <source src="video.webm" />
</video>

This is just a brief code example of how it looks. Scott Jehl wrote a great in depth article with all the details. He's also responsible for the Firefox patch.

Thanks Scott!

My first two weeks at Igalia

2024-03-22T00:00:00Z

After my first two weeks at Igalia, while everything is new, it also feels as if I've come back home after 2 years away from the web platform space.

There is so much new information about web platform projects to digest and I've been slowly figuring out how things work around here.

Igalia is a flat structure cooperative, which is really cool, but also really new to me and also feels incredibly empowering. In case you don't know what Igalia does, we're an open source consultancy. Meaning you can hire us to build stuff for the web platform (and many other areas).

You know CSS Grid? That piece of layout that changed the way we build websites? Igalia led the role in the development of that.

So for so many reasons I'm excited to be here. I spent almost 7 years on the Microsoft Edge web platform team and then later developer experiences. I have a little bit of insight into how browser features get prioritized and there often are not enough people to prioritize features that don't add immediate business value to the rest of the browser company. Igalia solves that problem and those features that companies want implemented end up benefiting developers everywhere. Again, look at CSS Grid.

I have had some really interesting conversations with Brian Kardell about big problems like how we currently fund the web ecosystem and the wheels are spinning on how to turn this into a conference talk.

Resurrecting the Web We Want #

I've also been thinking about the Web We Want project. I had wanted to stay involved when I left Microsoft but it became too much and though our committee still meets, it's effectively on pause.

I want to give the site a visual refresh and I have a few other strategic ideas swirling around. It is a valuable resource of developer wants for the web platform and DevTools and I want it to continue on. Now that I'm back in the web platform, I want to breathe some new life into this project and believe it's incredibly important developers are heard.

What I'll be working on #

I'm a web platform PM so I get to help drive all sorts of work. I'm excited to dive into Servo, a modern memory safe browser built on Rust, and Wolvic, Igalia's open source browser for XR.

While I'm be primarily focused on the PM side of projects, I'm also looking forward to dipping my toes back into developer comms and marketing/advocacy work.

Good stuff all around. I am so thrilled to be a part of company that has a set of values I align with and does work that I'm truly interested in being a part of. Excited for what's to come this year.

Find me on Mastodon, Twitter, Instagram (personal), Instagram (tech) YouTube or Subscribe to my newsletter.

The Curious Case of the CSS Monochrome Media Query

2024-03-29T00:00:00Z

I make a habit of browsing web platform features to see what's new and interesting and moving along in the browser space. It also leads to discovering things that have been around a while that I haven't heard of before.

In one such instance, this is how I discovered @media(monochrome). I found this media query particularly relevant with what seems to be an onslaught of e-ink devices making their way into the market. Someone tweeted about their Boox Palma, and it seems in this instance, a media query to target monochrome UI just makes sense.

I tried testing the monochrome media query on my Kindle browser with this quick demo*. If the device is monochrome, that message should change to say your device supports monochrome.

My Kindle didn't though. It said it wasn't a monochrome device which is obviously wrong and boils down to the browser. (This person also tried the same on their Kindle and got the same result).

I don't know what browser my Kindle has, though the device is at least 4 years old and no more than 5. Googling brought up some obscure Stack Overflow threads about the Kindle browser not being modern enough to support media queries. But according to caniuse.com, this feature was supported as far back as Chrome version 4.

Curious.

In 2022, a WebKit bug that had been opened since 2013 was fixed. This must have relevance somewhere in order to make a fix to match the spec.

But there is very little information on it otherwise. A few mentions of using it for print layouts, but there's a media query to target print layouts already. Most sites that have posted about it are just regurgitating the very minimal information the spec provides.

Does it even actually work as intended? There doesn't seem to be a way to test without a monochrome device. But which types of monochrome devices it supports isn't documented anywhere.

In theory, it seems like it would be the perfect CSS feature to provide designs tailored to a monochrome device and these e-ink phones are slowly starting to appear. If you have an e-ink device with a modern browser and click the demo link I've shared above, I'd be much obliged to know which message you get.

*It was a very quick demo, and therefore it says "dual screen device demo in the meta information so just ignore that please

Exploring the Immersive Web with Wolvic

2024-05-01T00:00:00Z

When I was interviewing for a role with Microsoft Edge in early 2016, I got to my final interview in the loop and I can still remember sitting across from my soon-to-be manager when he asked about the future of the web.

HoloLens had been announced, so I must have had that in my mind because I answered with a question.

"What if you could crawl into a web page?" And began to describe what it would look like to crawl into a news article to be immersed in a visual representation of the story you were reading.

I got the job and joined the land of browser work and discovered an entire career path that changed my life. I didn't do anything with browsers in VR while I was at Microsoft.

Eight years later, I powered on a Meta Quest 3 in my little home office, fumbled through the setup, downloaded Igalia's open source browser Wolvic and crawled in a browser. Jhey was outside when I was suddenly immersed in a browser cityscape and very loudly exclaimed, "holy shit" and laughed.

I entered an art exhibition and then crawled into a painting. Exploring art in the 3D. "This is so cool." And that's what I kept repeating.

Hello Wolvic #

So, why exactly do I have an XR headset, and what does this have to do with your career? One of the projects I am slowly ramping up on at Igalia is Wolvic. Wolvic used to be Firefox Reality but Igalia took over stewardship of the project in 2022 and have been working on developing it since. It's the only open source browser available on several devices.

From a product perspective, this is a really cool space for me to flex some product management chops and think about user growth and how to make getting started with Wolvic easier. Then there's the project management side of things and finding partnerships for companies interested in developing the browser.

What could you use a VR headset for? #

I was sharing my first experience with my friends and one of them works for a telecommunications company. "I spend so much time in Google Earth exploring and drawing lines on maps between points. It would be pretty fun to do in VR."

That sounds pretty practical to me. Being "in" a view is completely different from viewing something on your normal computer monitor.

I'm pondering all the different use cases now, things I'd never thought of before. It's pretty cool.

Immersed in the Web #

I am sure I will be blogging more about Wolvic and building an XR browser. I'm excited to explore this space...a space I imagined eight years ago. It feels a little full circle and that's pretty neat for me.

Wolvic is Open Source & if you're interested in helping to fund the project or use it, here are a few links:

You can download Wolvic from the Meta App store. It's also available on Pico & Huawei devices.

If you're an XR developer, please let us know if you have any feedback for Wolvic. You can follow the project on GitHub.

More to come but for now I just wanted to say....this is SO freaking cool. Stay tuned for some posts and videos on YouTube.

Breaking down basics: What's a web engine?

2024-07-08T00:00:00Z

The `
` and `
` elements are getting an upgrade

2024-11-01T00:00:00Z

Form controls are notoriously difficult to style, something the web community has been talking about for years. In 2019, when I was still at Microsoft, I had been working with Greg Whitworth to start evangelizing the work that was being planned for <select>, as well as the Open UI community group that would help bring this plan to life.

There's a lot that has happened in that five years, and more still to come. Most recently I've seen work being done to improve the customizability of the <details> and <summary> elements. More stylable accordions. Exciting!

Why `<details>` is hard to work with #

The <details> element is a disclosure widget, which is a piece of UI that has a brief summary or heading and a control to expand the UI to show more details.

When you use <details> however, you don't have a lot of control over customizing it (like a lot of HTML Controls). The little triangle to indicate whether it's open or closed is not easily replaced. Styling or customizing <details> just isn't easy, which in turn means developers end up building a custom component for their accordions.

This ends up creating a lot of unnecessary work. Using existing HTML elements means you get all the security, accessibility and performance benefits that have already been baked in. The browser takes care of all that for you. Rebuilding from scratch means you've got to worry about adding all that back in, especially the accessibility bits.

But you can't style it how you want to, so you end up building it from scratch anyway. Rinse. Repeat. A tale as old as time.

Proposed updates #

There's quite a bit being proposed to help make <details> more customizable and interoperable between browsers (because no one likes it when browsers make things behave/display differently!)

A few highlights:

Remove CSS display property restrictions so you can use other display types like flex & grid.
Specify the structure of the shadow tree more clearly (this helps with flex/grid).
Add pseudo-elements to give access to more parts leading to more stylability
Better ability to animate these elements through additional changes (these are a part of a separate work stream but will benefit these elements).
Improve ::marker styling

The exciting news is items 1 & 3 in the list above should be shipping in Chrome 131 Stable next week (first week of November 2024). This will bring a new ::details-content pseudo-element to the web, allowing more access to parts of <details>.

A Nod to Open UI #

Much of this work to improve form controls is started within the Open UI community group. The community there has been working for years to make progress in this space and getting all the browser vendors to agree and work together is often a difficult and time-consuming task. Cheers to all you do.

You can pay for that: How web browser features get built

2024-12-06T00:00:00Z

As I have spent the last 6 months starting to explore the rather precarious position we've placed web ecosystem in, with regard to how browsers are maintained and funded, I thought I'd dive into another angle: The ways that web platform features get prioritized and built.

I worked on Microsoft Edge, so I have direct experience working on a browser team. My current work is at Igalia, which is an open source consultancy that is hired by companies to work on many things across technology. My team, the web platform team, implements web platform features and APIs, and works on their specifications. Yes. You can pay for browser features to be built and for specifications to be written/updated/continued. We'll talk about both.

Browser vendors #

Browser vendors are the companies that develop, maintain and distribute a web browser. Some browser vendors are also stewards of a whole engine/browser (blink, WebKit and gecko). Google, Apple, Mozilla, Microsoft, Opera, Vivaldi, etc are all browser vendors. Google, Apple and Mozilla are engine stewards.

There are many teams that make up an entire browser team. A browser is so much more than just the web platform too. There is quite a lot of thought and design that goes into even the smallest user experience updates.

General consumer facing features, which typically have a UI component, tend to often get prioritized over more "hidden" web platform features for developers. The general consumer base is larger than the developer base. The goal is more market share (more people using your browser) which helps bring money to the browser vendor.

The web platform team works on browser features and specifications and making sure the implementation matches the spec, so you don't get different behavior in different browsers. But they're also there to enable what we'll refer to as "first party" needs.

First Party Development #

First party refers to groups within the same company as the browser vendor. Microsoft Office/Microsoft 365 is an example of a first party within Microsoft with web platform needs. Subsequently, their needs for the web will get prioritized.

Surface Duo is another example. I spent a lot of time talking about the web platform primitives and design considerations for dual screen devices. Having layout capabilities that adapted to this new form factor was incredibly important so the specification and implementing those features were also prioritized.

In my experience, first party development is typically prioritized above all else as you're enabling/enhancing another product in the company. Especially if those products are money-makers. These are also broader company strategic initiatives and very visible ways to make impact.

Come yearly review time, these things matter for compensation and bonuses. It is all deeply intertwined in company politics. These are things that make the company money and make the business case for having a browser. Bill Gates' The Internet Tidal Wave memo from 1995 even points out how access to the internet through PCs is vital for the business. Enhancing user experience and moving the web forward will be what wins consumers over.

External Companies and Third Party Development #

Another scenario is when an external, or third party, company has needs for the web platform. My experience with this while working at a browser vendor company is more limited. Third party can also mean general web developers. It was much harder to get the needs of the general web development community prioritized when first party often takes priority.

I truthfully can't remember whether it was/is possible for third parties to ask Microsoft to work on enabling certain features. I mean, of course you can ask, but I'm not sure how often an agreement would be made. With a relatively small team working on enabling web platform features, this probably wasn't/isn't a common scenario unless there's some big underlying strategic initiative that would benefit the browser and company. This type of contract could entirely have been outside my sphere of work.

The trouble with being a third party is that it's not as easy to align priorities or business cases. In fact, you might even be a competitor. Regardless, since resources are finite, it's likely that it's difficult to convince vendors to pay attention to your specific needs. At the end of the day, practically speaking, funding is required to advance features, fix bugs, etc.

Consultancies #

Guess what? Yes! You can hire experts to implement web browser features and/or give you that attention and priority! Do you need a new feature implemented or spec'd? A consultancy can help. Do you need bugs that are affecting your organization fixed? A consultancy can help.

If you have a need for a web platform feature, there are consultancies available for hire to help write and edit the specifications, work with standards groups, write web platform tests and get that feature shipped (or ready to be shipped).

I work for Igalia, and you can hire us for many things across many technologies and areas including web platform development.

In fact, we've been pivotal in moving forward a whole lot of things in the Web Platform, including features like CSS Grid, :has, container queries, MathML, classes in JavaScript, scroll snap, list-stlye-type: <string>...the list does go on and on. We work on lots of specifications and implementations for the web platform.

Instead of waiting or relying on a browser vendor to implement the features you need, which could potentially be years or even possibly never, you can hire experts like Igalia to do this work.

Why should I hire a consultancy to build web platform features? #

The most obvious answer is: It works. We've helped a lot of happy customers do amazing things.

Aside from needing features more quickly, hiring a consultancy like Igalia has advantages. We are experts in these processes and the dynamics of working in standards bodies, and our strength comes from not only our technical expertise, but our ability to navigate between the three main browser vendors with web engines to ensure feature design is agreed upon. This is a lot of work and often times it can be slow because there are only a handful of people at browser vendor companies who are responsible for reviewing patches, proposed features, design documents, etc etc.

Let's say you are a customer with a web platform need. You most likely have a backlog of work for your engineering team. There could be a few different scenarios that prevent you from internally prioritizing the web platform need: No one on the engineering team has the technical background for the type of work you need done, someone might have the technical background but not enough time to manage the entire process of spec writing, test writing and implementation, or maybe the team just doesn't have the capacity based on broader company priorities and product roadmaps.

When you hire a consultancy to do this work, then your product engineering team can spend time on the product work and roadmap while we work on the spec, implementation and coordinating among browser vendors. This stuff takes a lot of time, because it's the nature of the work, and it's our area of expertise.

Funding specific features #

There have also been instances where specific features have been funded by the community or donors, primarily driven by a want for better support and not by a business need, even though there most likely are business needs for such feature improvements out there somewhere.

The MathML work Igalia has been doing is an example of that. Igalia also ran an open prioritization experiment where the community collectively selected and funded a feature.

Sometimes there are really vital features the web needs, but for whatever reason, they're not a priority. With that being said, if anyone's interested in helping to advance and improve SVG, drop Igalia an email. We'd love to work on it.

Closing #

I have encountered many people since starting at Igalia earlier this year, who didn't know you could hire someone to build a browser feature, or work on a specification, or fix browser bugs. You can even hire us to work on improving a novel web browser engine (say hello to Servo), because you might need a web browser solution that is more lightweight than the major open source options.

Or maybe you need a browser for your Extended Reality/Virtual Reality device. With 50% of Meta Quest users spending time in the browser, it would be a missed opportunity to not offer the same on your device. This is where we come in with Wolvic. It's designed with browsing in XR in mind, and you don't have to build a browser from the ground up.

There are so many benefits to hiring someone to work on The Web in whatever way you may need. It also means the web platform can advance more quickly (in browser timescales anyway) because more people outside of browser vendors are working on things.

And that's good for the overall health of the web ecosystem.

Note: Thank you to my colleague Brian Kardell for reviewing & editing this post, which had been taking up a lot of space in my mind for a long while.

The Web Witch's Blog

Pushing the future of the platform forward with The Web We Want

How does The Web We Want work? #

1. Think of a problem or feature gap in the web platform #

2. Submit your idea #

3. Leading up to and at a live session #

4. After the event #

5. I submitted something and it didn't win or it didn't get presented, now what? #

The Future of the Web Platform #

Do you host a meetup or a conference? #

The Web We Want Survey Results

DevTools Survey Results #

Scoring how useful each submission would be #

Please rank each of the items from favorite to least favorite. #

Notable Verbatims #

General Browser Survey Results #

Scoring how useful each submission would be #

Please rank each of the items from favorite to least favorite. #

Notable Verbatims #

HTML/CSS/Layout Survey Results #

Scoring how useful each submission would be #

Please rank each of the items from favorite to least favorite. #

Notable verbatims: #

So what's next? #

The Web We Want In The Time Of COVID #

What the heck is an Origin Trial?

What's a browser Origin Trial? #

How do I use an Origin Trial? #

Origin Trial Process #

Submitting feedback and trial expiration #

Provide a fallback #

The edge of the web (no pun intended) #

Web We Want Progress Update - November 2020

Landed features & in-progress work #

Standards related Wants #

A better way for discussion #

Other ways to participate #

An Intro to Trigonometric CSS Functions

Trigonometric CSS Functions Overview #

Basic use cases per the MDN documentation #

What problems do they solve for developers? #

Closing thoughts #

Resources: #

A love note to CSS

Update #

Greater styling control over type with CSS `initial-letter`

What is initial-letter and what does it do? #

What does this solve for developers? #

More examples #

Other notes #

Browser support #

Resources #

Serving less data with the `prefers-reduced-data` media query

Browser support #

Information and discussion #

Designing for Dual Screen and Foldable Devices With CSS

CSS Media Queries for Viewport Segments #

CSS Environment Variables #

When should you include a dual screen mode in your product? #

Browser Support #

Closing #

Building better websites with the Chromium DevTools Issues Panel

Accessing the Issues panel #

Filtering issues by severity and browser #

Linting in your browser #

When to use CSS text-wrap: balance; vs text-wrap: pretty;

text-wrap: balance; #

text-wrap: pretty; #

Balance and Pretty #

CSS Media Query for Scripting Support

Media query syntax #

Code Example #

Support #

Closing #

CSS Media Query Support for Video Elements

A Brief Code Example #

My first two weeks at Igalia

Resurrecting the Web We Want #

What I'll be working on #

The Curious Case of the CSS Monochrome Media Query

What is `initial-letter` and what does it do? #

The `
` and `
` elements are getting an upgrade

Why `<details>` is hard to work with #