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

Thomas Steiner
Feb 5 · 8 min read

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:

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?

  • ② 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)
  • ⑥ 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:

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.

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.

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!

Mariko Kosaka’s talk “What is/Who Makes ‘The Platform’” on YouTube
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.