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

😨📖 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.”

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.

• ① Mozilla Developer Network (MDN) has become my go-to location for information about Open Web technologies, so my journey to see if text-transform could potentially support titlecase begins with a search for the feature in question on MDN. First, I want to see if the feature or a similar one was maybe already implemented, but mostly to get a spec link that I can dive into. (🔗 link)
• ② I want to understand the status quo of the feature as it is specified. At the end of the documentation page, I find links to the appropriate specs, typically I begin with the latest. (🔗 link)
• ③ Next, I find the details of the feature in question somewhere in the spec. Typically MDN already has the correct deep link, and if not, it is a Wiki that everyone signed in to MDN can edit 😉. (🔗 link)

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

• ④ As hard as it may initially seem if you are new to spec prose (I am), personally, I always strive to read (at least enough of) the spec to understand the complete background (your browser’s full text search feature helps). I fully reckon this is not everybody’s cup of tea, so feel free to skip this. Here, it turns out the CSS spec already says something about “titlecasing” (emphasis mine):

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

• ⑤ So it looks like the designers of CSS had at least thought about title casing, but decided against it. However, the spec did not give their reasons, so I go in search of the history and find the GitHub issues linked at the top in the spec’s front matter where discussions might have happened regarding this design decision. (🔗 link)
• ⑥ I search for the relevant keywords in closed and open issues (note that by default GitHub search covers just open issues). (🔗 link)
• ⑦ In this case, I do not find anything super promising ¯\_(ツ)_/¯ , so I go back to the appropriate spec options list from bullet ② and recall that the text-transform feature has been in earlier versions of CSS, that is, before CSS3. (🔗 CSS2 link, 🔗 CSS1 link)
• ⑧ By reading the older specs’ front matters, I realize that discussions happened on mailing lists before GitHub became a thing 😲. (🔗 link)
• ⑨ With the previous keywords and variations thereof (this is not fuzzy search), I search the mailing list archive for evidence of the discussion. (🔗 link)
• ⑩ I find an old discussion from 2015 where people talk about title capitalization. (🔗 link)
• ⑪ Next, I trace back the argumentation history by following the “Next in thread” navigation of the mailing list archive. (🔗 link)
• ⑫ After a while, I find Tab Atkins chime in the discussion at one point:

“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)

• ⑬ Ultimately, I read Tab’s final resolution:

“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.

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.

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.

Conclusion 🔗

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’”.

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.

🙏 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.