Engaging in Web Standards—The “Compatible with Most Web Developers” Approach

Thomas Steiner
Feb 5 · 8 min read

😨📖 tl;dr: Whether you want to add something new to an already existing feature or propose a completely new one, it all starts with finding out in what organization the standardization process for this kind of feature happens and where this organization’s discussions take place. This post suggests a possible approach to engaging in standardization work in a meaningful way for regular web developers whose day job is not standards by following along a step-by-step real-world example that takes you through the journey and encourages you to make your voice heard.

At Google, we have a humbling 👌(!) team of amazing Google Developer Experts that specialize on Web Technologies. The other day, one of them on a mailing list suggested the following feature (paraphrased from the email thread): “Consider adding support for a titlecase keyword for the CSS text-transform property”. They explained:

“Some time ago, I wanted to unify the capitalization of all titles in my app and thought of using CSS text-transform. It supports capitalize, uppercase, and lowercase [among others]. Upon further investigation, I found not all words are capitalized in English in title case. For example, ‘a’, ‘an’, ‘the’, ‘and’, ‘in’, ‘of’, ‘as’, ‘to’, etc. are not capitalized. So using the capitalize keyword of CSS text-transform does not match the English convention, and developers need to write the conversion by hand.”

At first sight, text-transform: titlecase sounds like a reasonable thing for CSS to have. It would take a heading markup like <h1>Ten things CSS can do, the eighth will make you cry</h1> and render it as…

Ten Things CSS Can Do, the Eighth Will Make You Cry

Note how the article “the” is lower case, everything else upper case. According to the (randomly chosen) title casing service that I have used to do the conversion, this style is called Associated Press (AP) Style. Just sad 😕 that the AP Stylebook Twitter account some time ago tweeted the following:

🤔 This already smells like trouble. Are there no simple rules after all maybe? The person who suggested the feature continued their email (again paraphrased and emphasis mine):

“I am not familiar with the W3C standards process, this is just a suggestion I thought of. Most web developers don’t participate in the standards development process. I think they just don’t know how to provide feedback.”

World Wide Web Consortium (W3C) logo

Contributing to Web Standards as Someone Who Self-Identifies as “Most Web Developers”

It would probably get a [citation needed] tag on Wikipedia, but the statement stands: “Most web developers just do not know how to provide feedback”. I (Tom, Google Web Developer Advocate 🥑) thought maybe I could attempt to address this challenge and try to come up with an answer. While I am definitely not the most authoritative source for standards works, I have landed a few minor changes in various W3C specs. With that out of the way, let me guide you through my personal approach to potentially landing a feature request like “correct” title case support.

Understanding the Status Quo of Existing Features

There is a clear use case (“correct” title capitalization) and an existing CSS feature (text-transform) that somewhat does the desired thing, but not exactly. Now where to go from here as someone who self-identifies as “most web developers” and who is new to standards?

⚠️ Note: The bullet list below is modeled along the running example of text-transform, follow the 🔗 link after each bullet to see where I am at in my process. This is not meant to be a generic “contributing to standards” guide, but with the help of a concrete example shows how one possible approach can look like.

☝️Side Note: My colleague Surma has written an excellent guide on how to read web specs at the example of WebVR.

“Authors should not expect capitalize to follow language-specific 👉 titlecasing conventions (such as skipping articles in English) […]”—(🔗 link)

“It’s a ton of effort and complication for something that won’t even work for most content (since most content isn’t language-tagged), and so not really worth pursuing.”—(🔗 link)

“I agree that that’s not great, but as others in this thread have said, it’s really not possible to do better without very high levels of domain knowledge, and even then manual tweaks are necessary (for example, for acronyms that look like real words). CSS’s auto-capitalization is pretty dumb; don’t rely on it if you want high-quality capitalization.”—(🔗 link)

So in this case, there is a clear and reasonable explanation why we can’t have (what initially seemed like) nice things. This is what makes standards work so fascinating to me. Someone somewhere on this planet 🌍🌎🌏 will definitely think of—or have thought of in the past—something that I would have never realized myself. Standards are about finding a compromise—and finding one might take a while sometimes.

Challenging the Status Quo of Existing Features

Now this does not mean that the discussion has to stop here, there can always be a “bullet ⑭” (to symbolically continue the numbering scheme from above), where I disagree and bring forward a counter argument for the use case behind text-transform: titlecase, but maybe for the sake of the running example in 2019 not in CSS land, but in the form of a to-be-newly-proposed property Intl.TitleFormat in the Internationalization API, which brings me to the next parts on suggesting new JavaScript and Web Platform features.

⚠️ Note: I am not actually arguing for Intl.TitleFormat, this is an illustrative example to show how to propose new JavaScript and Web Platform features.

Ecma International, Technical Committee 39 (TC39) logo

New JavaScript Features

If an idea is about new JavaScript features like the fictive (at least at the time of writing 🙂) proposed property Intl.TitleFormat from the running example around title capitalization, you are dealing with Ecma International, Technical Committee 39 (TC39). Proposals go through a four-stage process which is documented in the TC39 process document. Personally, I cannot really say too much about this, as I have not followed the process yet, but again—as a first step—I always search through the list of existing proposals to see if maybe someone else has had the same or a similar idea in the past. If the idea is new, I make the case for the addition, describe the shape of a solution, and identify challenges by following the creating a new proposal guidelines.

Web Incubator Community Group (WICG) logo

New Web Platform Features

If an idea does not fall in the category of things that already exist (like adding new allowed keywords to a CSS property or proposing a new property for an existing JavaScript API), but is more exploratory (like, say, suggesting a whole new API for getting the list of installed fonts, so I can not only capitalize titles following preferred title case rules, but also performantly format them in function of the user’s installed fonts), I check if the Web Incubator Community Group (WICG) is the right forum for the proposal. The group runs a discussion forum where one can get initial feedback on an idea. As a first step, I also always search the forum to see if maybe someone else has thought about my feature before. After posting an idea or chiming in on someone else’s idea, I will then be pointed in the right direction regarding next steps.


With all that said, do not let yourself be discouraged from engaging in web standards work. In many cases, searching for past discussions (bullet ⑤ above) will already reveal something useful, and you can then engage in the discussion by commenting on GitHub. Do your own research and due diligence, and you should be good to go. All of us are learners, me included. What approach works best for you? Do you work on standards and are you aware of a better way? I would definitely love to learn from you!

For another take on getting started with standards work, I also highly recommend watching my colleague Mariko Kosaka’s talk “What is/Who Makes ‘The Platform’”.

Mariko Kosaka’s talk “What is/Who Makes ‘The Platform’” on YouTube

For yet another take (and probably the most holistic one) ranging from identifying the issue to writing a Web Platform Test to proposing the actual spec change, watch Jake Archibald’s and Surma’s episode Changing Web Standards of their HTTP 203 series, embedded below.

Jake Archibald and Surma on “Changing Web Standards” on YouTube

🙏 Acknowledgements

I would like to thank Jake Archibald (💯), as well as Sam Dutton, Sam Thorogood, Phil Walton, Yoav Weiss, and Rowan Merewood for their helpful comments and for reviewing this article.

Dev Channel

Developers Channel - the thoughts, opinions and musings from members of the Chrome team.

Thomas Steiner

Written by

Web Developer Advocate at Google

Dev Channel

Developers Channel - the thoughts, opinions and musings from members of the Chrome team.

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade