17. What the W3C TAG is, how standards are made, and why gray is darker than darkgray
Lea Verou, Bruce Lawson, Vadim Makeev
- 01:44 Lea’s hats in 19.3 seconds
- 11:16 What is the W3C TAG
- 24:05 CSSWG, TC39, and others
- 33:36 WHATWG, W3C, and WebDX
- 46:19 Family, SVG, and named colors
Transcript
Intro
Bruce: Hello and welcome to The F-Word, a podcast about the magical and glamorous world of web standards, browsers and everything in between. I’m Bruce Lawson and I’m coming to you from Birmingham, UK.
Vadim: I’m Vadim and I’m coming to you from Berlin, Germany.
Bruce: And we have a v special guest today. Somebody known to you all on the Twitters and the conference circuit and an old friend of both mine and Vadim. So, mesdames et messieurs, พี่กับน้อง, I would like to introduce you to our guest, Ms. Lea Verou.
Lea: Hello, everyone. Thank you for having me, Bruce and Vadim.
Bruce: You’re very welcome. Have you ever listened to one of our podcasts before?
Lea: I’ve listened to parts of some of the podcasts, but I don’t think I have the attention span to listen to a whole podcast start to finish.
Bruce: Ah, okay. So you’ve probably zoned out when we do the ritual humiliation of the guests. So you’ve not known that’s gonna come about. Oh dear. Oh well. So where are you, Lea, at the moment? Are you in the States or Greece? You divide your time between them, I think.
Lea: I do, yes. I do divide my time between them. I’m currently in Cambridge, Massachusetts in the US.
Bruce: I’m sorry?
Lea: I’m currently in Cambridge, Massachusetts in the US.
Bruce: I heard you, I was just expressing sympathy. That’s the US mate.
Lea: Oh yeah.
Bruce: I could see from Vadim’s face, he could see the lead into that crappy joke coming up already. He sort of had the sad look that crosses Vadim’s face when he can see I’m going in for a joke.
Lea’s hats in 19.3 seconds
Bruce: So Lea, for the three or four people in the universe who haven’t yet had the pleasure of making your acquaintance or seeing your work. Tell us in 19.3 seconds and no more everything people need to know about you.
Lea: Are you keeping count? Because I tend to speak a lot.
Bruce: Go for it.
Lea: Anyway, so I tend to wear many hats. Officially my day job is human computer interaction research and teaching at MIT. Human computer interaction is just the fancy academic word for user experience and usability just because academics like having separate words for everything. I’ve also had a very active role in developing several web standards. I’ve been active in the CSS Working Group for several, like over a decade at this point. I co-edited several CSS specifications and I’ve also been an elected TAG member. And I’ve also started several open source projects over the years. Some of them have become popular. Like, I think the most popular one is Prism, which is used for syntax highlighting all over the web. It has like almost a billion NPM downloads at this point.
Bruce: I didn’t know that was you actually. I know you and I know that and I’d never put the two and two together, well.
Lea: I was the sole maintainer for a few years, but at this point it has a really nice team of maintainers who are all like incredibly capable people. I’ve had an advisory role in the project for like the last few years.
Bruce: I like advisory roles. It’s kind of, you can get the glory and boss other people about, but don’t have to do anything else, which is good.
Lea: Well, you can’t really boss people around on open source projects because they’re all volunteers and they can fuck off any moment if you don’t treat them well.
Bruce: Why none of my open source projects have done anything, I think. So I remember when you and I met, a very, very long time ago, not long after Queen Victoria’s funeral actually, and I introduced you at some event in some rather mundane studio or something in London. Is it fair to say that you are a designer primarily who kind of got interested in the coding and then branched out? Or did you always start off as a polymath? What was your journey to these glamorous heights that you’re on now?
Lea: So how far back do you want me to go? I actually got interested in coding when I was like 11 or 12, depending on how you count. And what really got me into it was that other people get into programming because they like solving problems or they like taking things apart and seeing how they work. For me, it was always like, I like the idea of making tools that people use. When I was introduced to programming, it blew my mind because I was thinking, “Whoa, I can make things that people use that actually look professional.” Because until that point, I was making things with my hands, like purses and notepads and wallets and that sort of thing, and they looked very amateurish because I was a kid. And I was like, “Whoa, with programming, I can actually make things that look professional if I try hard enough.” And this sort of like, if I try hard enough, I will get users, was the carrot that like kept me going throughout my entire teenage years.
And eventually like it became what I did for a living. When I was actually, when I actually started working, uh, like, you know, actually getting paid for what I do. I did start from graphic design, which was just, I guess, serendipity. Like, you know, I got interested in graphic design because of this project we had with a friend of mine, which eventually turned into a company. I was doing both the coding and the graphic design. I guess I realized I really enjoy the graphic design aspect. I started learning more about it, like being involved in graphic designer circles, practicing, eventually getting projects. And for two years or so, I was primarily a designer.
I did some coding projects, but most of my clients and most of my projects at the time were either graphic design, like corporate identity, marketing materials, posters, that sort of thing, or a few small web design projects.
Vadim: I remember back in the beginning of the 2000s or middle of the 2000s we were all webmasters and we were doing everything for starting from design to PHP on back end. So I’ve been doing almost the same thing like working in a small studio and doing everything that’s available.
I think I met you back in Oslo back in 2009 or something like that and I saw you some of your talks later like on CSS and SVG and you became known, widely known as a CSS magician, one of the first, one of the few first people who would unveil some secret parts of CSS. We can jump to this part. How did you become publicly known with your skills and your front end?
Lea: So part of it is that I have this bad habit that every time I use something, anything, a product, the technology, whatever, if I stay with it long enough, I come up with ways to improve it. And of course that extends to CSS as well. So as I was using CSS as a developer in my startup at the time, back in Greece, I started coming up with tips and tricks that I could use that I haven’t seen published anywhere. I started making tools primarily for myself, but that I thought might be useful for other people. I started coming up with ways to improve the syntax of CSS altogether and publishing them, posting them in the mailing list. Back then the CSS Working Group was using a mailing list. And I guess they liked my suggestions because at some point they invited me over as an invited expert.
And I’ve stayed with the CSS Working Group ever since. I was releasing more open source projects around not just CSS, but like web technologies in general. Some tools were more geared around JavaScript as well. Some tools were more related to UI. Eventually my project started getting traction as well. And I think what was sort of my break in this circuit was when I got invited for FrontTrends in 2010. At the time I was like terrified. I was like, is this, is this a hoax? Why would somebody invite me to a conference? And I saw the list of the other speakers and I was like, I know these people. Like surely that that is not a hoax. If it’s a hoax, it’s a very elaborate one.
And of course then like panic set in. Even though I’m an extrovert, I identify as a shy extrovert. Like I love human interaction, but I’m actually, I get, I can also get very nervous and very shy. So I’m not a natural public speaker. Like I don’t, it does not come naturally to me. It terrifies me. So my initial reaction after I realized that this was for reals was panic. Like, fuck, fuck, fuck. I can’t do this. But I pushed myself. I was like, no, Lea, this is good for you. You have to do it. It was just like that. Like I basically forced myself to say yes and actually do it. I didn’t, I hadn’t even attended a conference at the time.
So I bought a ticket for Fronteers because I didn’t want the first conference I attend to also be the first conference I speak at. And Fronteers was like two weeks before at Front-Trends at the time. I attended, it blew my mind. I met so many people that I was, that I only had heard of at the time, like PPK or Christian Heilmann, or the two I remember when I was, I was really looking up to them and I was meeting them in person finally, and I basically went home after this conference entirely redid my slides because my slides at the time were like death by PowerPoint. I entirely redid everything. I introduced like live demos so that I could show instead of tell.
Vadim: Oh yeah. Famous live demos. I remember your talks. Like you were just coding on your slides.
Lea: That started from that talk at Front-Trends. I mean, it became more elaborate later in the at Front-Trends talk. It was like, it’s just an editable style element that, that just had content editable and I was editing it and people loved it. I thought, I remember, I thought I was doing terribly at the time. It was a two hour talk. My first talk was a two hour talk with a break in between. And for the first hour, like, you know, I’ve seen some people sort of being sleepy in the audience and I was like paying so much attention to like what the audience looked like and I saw some people sleeping and I was like, Oh my God, I’m, I’m screwing this up. I’m doing so badly. And then. Well, during the break, I logged onto Twitter and it was like a flood of tweets about how amazing that talk was and how it blew their minds. And like the organizers were like, this is like the most like talk at the conference like people are tweeting like crazy about it. And I was shocked because I thought I was doing really badly. And then I had to go and do it for another hour, but at least I was, I was more confident, I guess, after that break.
Bruce: Whoa. You checked the Twitters midway through a talk. Nerves of steel. It takes me about hours after I finish a talk before I can even bear to see what people have said. I mind you at least everyone was lovely to you.
Lea: People are, people are often assholes on Twitter, but in terms of like talk feedback, I haven’t really seen that sort of thing. Personally, it’s the first thing I want to do after a talk, like go onto Twitter and see what people are saying. It’s like a huge dopamine hit to see people liking your talk and saying good things and saying how they learn stuff. And it’s something you don’t really get from academia, from teaching in a university setting. You don’t get this kind of connection, I guess, with the audience, the audience being really, really appreciative of what you’re trying to do and being really excited about what they’re learning.
Bruce: It’s been a while since I was in academia, but I can’t imagine it’s changed much since my day in which I’d show up with a hangover and some middle aged man with leather on the sleeves of his ancient coat would basically read out from a handout. And then we’d all go home and it used to annoy me. But yeah, I mean checking the Twitter is always the first thing I want to do when I finish the talk, but I don’t dare to.
What is the W3C TAG
Bruce: Enough about me. So now you are an elected member of the TAG. I don’t know much about what the TAG actually does and I’m aware it’s not that much of a high-profile organization, you know, it’s sort of like the the NSA of the W3C if you will. So would you mind just telling us what the TAG is and how you became involved and kind of what it does? And maybe your niche within it.
Lea: We should probably start by saying that TAG stands for Technical Architecture Group. It is a special working group within W3C. Its mission on a very high level is to document the architecture of the web and assist the community in interpreting it. But what does this mean in practice? What does the TAG actually do? In practice, this is realized through two parallel but very connected efforts, design reviews and principles documents. So design reviews are basically anybody that wants to extend the web platform with a new feature has to request a review from the TAG.
We review these proposals on the basis of several different factors such as API design, security and privacy, accessibility, consistency with the rest of the platform. It’s lots of different things. In fact, Google has TAG review as part of its shipping process. For something to ship in Blink, Chromium, they need to request a TAG review.
And also for a W3C specification to advance, they also need to request a TAG review. part of the horizontal review stage. But also we compile our experience from these design reviews into several principles documents. We have the design principles, which is sort of like API design for the web. We have our ethical design principles, which are about respecting end users and authors and not violating security and privacy and things like that. And we also periodically have one-off findings that are about specific things.
Like for example, the two recent findings we’ve been working on is one about eliminating third-party cookies from the web, like what would the web look like and guidance for people trying to come up with solutions to this problem and another one was about the sustainability of bundling and caching, where we expressed several… And I was actually involved in the second one. I was one of the editors, Sangwan being another one, which is about concerns we have about how bundling is seen as a required part of deploying anything to the web platform and also the sustainability of double keyed caching. Are you familiar with what double keyed caching is?
Bruce: I am not at all. Please tell us.
Lea: So until recently we used to tell developers that if they use a library from a CDN, then they get to benefit by the library potentially already being cached because another website was including it from the CDN. This has not been true for several years. The reason was that the browsers at some point decided that this makes users prone to timing attacks because the theory being that if a resource loads too fast, meaning that it’s cached, that means that the user had already visited certain websites that linked to this resource. In theory, by triangulating all the different resources and figuring out what is cached, they could figure out maybe which websites they’ve been to. The solution that browsers came up with was to basically partition cache by origin. So even if 100 websites are linking to the same jQuery version, you will download it 100 separate times.
I mean, this does protect the privacy of users, but it also introduces other problems such as in, I’m sure you know this very well, Bruce, like in several countries, people pay by the megabyte and they cannot afford to just have everything being downloaded over and over again and we urge browser vendors to consider other solutions to this that do not involve this kind of bandwidth bloating, like maybe smart delays or something like that. I mean, sure. Have the resources pretend to be downloaded from scratch, but like don’t actually download them. Like there must be a better solution to this than actually having to redownload the entire resource.
Vadim: Yeah. The same goes to Google Fonts or any kind of shared resources. Yeah. It might take like hundreds of kilobytes of useless download. Back in my days, I remember it was a good practice to link something from CDN because it’s already cached. These days it’s anti-pattern.
Lea: Yeah, exactly, exactly. And I think it’s kind of a shame that it’s an anti-pattern. I think there are huge benefits to that. And also being able to link to libraries from CDNs also offers a smoother learning curve for people that are new to web development. It’s not a great story to tell novices that to develop any web application now you have to install NPM and build tools. And I’ve been seeing this a lot because not just in our students, but also in academia, there’s a lot of people that they might be amazing computer scientists, but they’re not used to doing a lot of web development work. And when you explain to them how much upfront cost there is, how much effort they need to put into just deploying the simplest of websites, they’re shocked that they have to do all this. And even things that we don’t even consider, like install Node, install NPM, of course everybody has these tools. Well, people who are new to this industry don’t necessarily like it. It’s yet another step that they have to do and understand.
Bruce: I mean I do (not right now because I’m between jobs) but I do this stuff day in day out and it still shocks me you know like the tiniest feature like download this stuff from NPM and I see all this all these matrix like screen of things appearing on my computer from who knows where, Who knows what they’re doing? Who knows what’s in them? I don’t even know where they live, where they might be in my computer. It gives me a bit of anxiety. But tell me (off topic, but on topic, but tangentially) why did the smart delay thing not get implemented? Because that sounds a real sensible thing. You know, just pretend that you’re downloading 100 kilobytes, so the timing attack can’t happen, but don’t actually download it. What was the problem there?
Lea: I’m not 100% sure that this has even been considered, but I think it might be the difficulty of actually emulating a delay that truly looks organic. But I mean, these are smart people, surely this is not an insurmountable problem. I’m sure it was just a quick solution to just limit resources to their domains. Then you can implement something later once you figure out what to do, and they never did. And I guess if you’re someone working in a country with huge bandwidth where it’s basically unlimited and you don’t pay by the kilobyte and internet speeds are really fast, it’s not something you really consider. It’s not top of mind that increasing bandwidth like this is a problem.
Bruce: Hang on, are you by any chance implying that the people who run and control the internet might all be rich people with top of the range computers that might actually be from their employers on super fast broadband who don’t actually consider people in the rest of the world?
Vadim: No way. No.
Lea: Don’t attribute to malice what can be explained by just forgetfulness, I guess. If something is not top of mind, then it’s often easy to forget it. It’s often easy to just not think about it. I do think that in general, even people who live in these areas and who are generally affluent, they do want to not inconvenience people in the developing world, it’s something that they need to consciously remember.
Bruce: No, I reluctantly have to say, I believe you’re right. It’s like, I mean, I work in accessibility and, uh, over my four or five decades on this marvelous blue marble of ours, I’ve come to realize that most people in the world are not actually evil and don’t want to exclude somebody with disabilities. It’s just, if you’re in your early twenties on super fast stuff and you don’t have a disability, you don’t know somebody who does, it’s actually quite hard for you to put yourself in the position of this person who’s, you know, for you completely beyond your realm of experience. And so, you know, when I’m doing accessibility audits, I always try not to say, “This contravenes WCAG 9.7.3.2.4.” I always try and say, you know, “My neighbor Jane, who has perfect eyesight but terrible arthritis, doesn’t use a mouse, but she’s not a screen reader user.” And then people go, “Oh, yeah, actually, I hadn’t thought of that.” And then once they thought of it, it lingers in their brain for a while because most people are not evil. Present company excepted, of course.
Bruce: Talking of not being evil, what you were saying about the TAG’s mission, making sure security, internationalization, accessibility, consistency, looking after the users, it sounds to me almost like you are the crack squad who are enforcing those HTML design principles that luminaries like Håkon and van Kesteren and Chaals McCathie-Neville wrote at the time when the WG was just beginning, you know, with the document with the marvelous priority of constituencies in it.
Vadim: Like users come first and then come the next parties.
Lea: Yeah, the priority of constituencies is one of the design principles, But the design principles are not exactly an extension of that old HTML design principles document, although we have folded a lot of these in. But some of the principles from that document actually fit better in ethical design principles. Some of them are more about API design, so they became part of the design principles document. I think at this point we’ve probably incorporated the spirit of all of them in some form in one of our documents, but they are a separate document.
Bruce: So you’re like the enforcers of niceness.
Lea: Well, we don’t actually have any official power. Companies come to us for review because they want to get our review. I mean, Google does have this rule that anybody that wants to ship to Blink needs to ask for TAG review. But the rule is just that they have to ask for TAG review. The rule is not that they have to pass TAG review. And we have seen things shipping in Chrome that Google has felt very strongly about. And they did not actually pass TAG review. We had concerns, we closed the review with concerns or even as entirely as unsatisfied and they still shipped. I mean, they do take it seriously. They do try to iterate. We’ve had a lot of cases where we worked together with the implementers, refined the proposal, eliminated a lot of the issues. Like the success stories are more, are far more than these, but there are cases where things shipped anyway.
Bruce: But you’re not actually empowered to go and just like beat somebody up if they don’t listen to you.
Lea: No, we do not. And also right now we get more review requests from certain working groups than others. Like we don’t get as many reviews from TC39 specifications, although I’m actually working to change that. And we have been discussing with TC39 that maybe TAG review could be added as part of the review process for stage two proposals, and also I’ve been trying to get TC39 to collaborate more closely with us on the web platform design principles because we’re developing this document that is basically API design for the web platform. And I realized at some point that we’ve been getting a lot more feedback from people developing browser APIs than people developing actual JavaScript APIs that span the entire ecosystem, not necessarily just the browser, but also like JavaScript runtimes, things like that. And given that developers use both of these together and they don’t even necessarily understand the difference. I mean, do developers understand the difference between say the temporal API and like the URL object? They just see them both as APIs that are part of the web platform. So it’s important that they are consistent with each other. So I think it’s very important to try to collaborate more closely with TC39.
Bruce: Just going to point out to listeners, if they’re unfamiliar, that TC39 is actually the gang of people who standardize JavaScripts who are not at the W3C. I think they’re IETF and TC39 actually stands for “Talk Crap 39”.
CSSWG, TC39, and others
Vadim: It’s good that you mentioned TC39 because I think recently you posted somewhere that you’re joined or yet you got invited to being a part of TC39.
Lea: Yes, I joined TC39 being sponsored by OpenJS Foundation. Although I’m still learning the ropes, like I don’t have much insight. I primarily joined because we needed to collaborate with TC39 on TAG stuff, and we needed to solicit their feedback on certain things. And there were certain private repos that are only visible to TC39 delegates. So I was talking with Jordan and he was like, well, you should get invited to TC39 and so that we could collaborate.
Vadim: But you’re definitely not a new person in CSS Working Group. You have a lot of experience. So tell us more about how CSS Working Group works, what’s your role there, and how, even if you’re just trying the ropes in TC39, I wonder if you can already compare them, how they’re different. I mean, they definitely have a lot of differences, but I’m just curious in terms of releasing new features or reviewing new features.
Lea: The way the CSS Working Group works is we have a GitHub repo where we post issues and proposals, bugs we found in specs, things like that. And then we meet once a week to talk about these and resolve on some of them. We also meet a few times a year in person, although this has changed after the pandemic and we’re still not back to the pre-pandemic levels of face-to-face meetings. And sometimes occasionally we might do breakouts on specific topics. Like we had one recently on scroll animations, we’ve had a few on nesting, but for most of our work, the entire working group is there, or at least the active members are there. We don’t really do breakouts on a regular basis. Some people have suggested we move to a breakouts based model. I was one of them.
Uh, but the problem is in the CSS Working Group, we have certain members that are involved in everything and they are actually editing almost every single spec in the group. A breakout-based model would either exclude them from certain parts of CSS or just dramatically increase their workload if these meetings are separate and they have to join all of them and their workload is already huge. On the other hand, the counterargument to that is that we should move towards a model where the weight of the work is not carried primarily by two people because it’s not right for them and it’s a little bit dangerous for the group as well.
Vadim: Let me guess, it’s Tab Atkins and Fantasai?
Lea: Yes. Yes. I mean, they’re both brilliant. Like they’re some of the smartest people I have ever met and they are so knowledgeable in this stuff, but they are spread out so thinly because they do so much work. Especially Tab is also active in specs outside of the CSS Working Group as well. Like he’s in TC39, he’s in the WHATWG, he’s like sort of everywhere.
Bruce: Yeah. I mean for sure if Tab and Elika were like riding a tandem bicycle and fell down a hole the CSS would just finish wouldn’t it?
Lea: I’m not sure it would exactly finish but it would definitely be in a very dire position.
Vadim: But apart from this backbone of CSS like Elika and TAB what kind of people are there in working group? I mean I’m sure there are many people from Google, Apple, Mozilla representatives. I mean they get paid to be there but what about invited experts like yourself or any other kind of people?
Lea: There are a few invited experts. I think at this point, there might be about 10 or 15 of us. Some invited experts have funding or sometimes it varies. Like at some point I got funding from Google for some of the standards work I was doing, although most of my standards work has been unpaid. And I think this is the case for many of them. Also, indeed, it’s very hard to find time for standards if you are not paid to do it because, you know, it actively hurts your performance at your actual job. I mean, one of the reasons I took like nine years to finish my PhD is because I’ve been so involved in these communities and doing all this unpaid work. Which is meaningful work and it’s important for the web and I’m happy to do it. But it does take a toll on you.
Bruce: Yeah. You, presumably you’ve got, you got funding because you did lots of unpaid work and people could see that, you know, you were cool and groovy and new stuff. and people wanted to fund you. But what happens if you are the new Lea Verou, but you’re not in Greece and able to come to Poland and do conferences? You’re in Sri Lanka or Nepal or Uganda. Is there a chance for those people to get funding? Is it kind of ad hoc or is there a mechanism by which the big companies pull some money and actively scout for new talent? Should there be?
Lea: So the Google UI fund was created partly to help with things like that. I mean, it was, it also aims to fund open source projects and things like that, but an explicit goal of that is funding spec work. That is also how some of my spec work was funded. Although my understanding is that it can’t be used to fund travel by itself. It could be used to cover travel in addition to other spec work. It’s nice to have initiatives like that, but it’s not sustainable on its own. And like, this is a huge problem. The fact that a lot of spec work is on a volunteer, unpaid basis, or even in the TAG, which the TAG is basically the web platform’s review board, you would expect that companies would do anything they could to make sure that this work is sustainable for the few people that are on the TAG. The reality is that a lot of TAG members cannot even fund their travel. Recently we had a face-to-face meeting in Tokyo and we got like less than half of the TAG, I think, because a lot of people couldn’t find funding.
Personally, my TAG travel is funded by OpenJS and I’m very grateful to them because like a lot of it tends to be very expensive. Other people who are sort of very talented and offer a lot to the TAG, but are not as prominent in the developer community don’t get this benefit, don’t get anybody funding them. But also if you’re employed somewhere and you’re doing this as an extra, most employers do not value this kind of work. You’re actively working against your performance review by devoting time to standards work in most positions. There are very few positions that actually encourage and value standards work. There’s very few positions where succeeding in that kind of work is part of your KPIs. Usually it’s just work that takes time away from other activities that could actually advance your career. And I find that this is a very sad reality.
Vadim: I remember one story a couple of years ago, I think Fronteers, this community from Netherlands, tried to appoint Rachel Andrew as their community representative to W3C or CSS Working Group, not sure how it ended up, but they tried.
Bruce: I’m pretty sure they did appoint her at least for a year or something. She certainly went and repped Fronteers. It was at a time of quite a lot of turmoil. I can’t remember what was going on in the CSS Working Group, but they really needed a Rachel to get involved. I mean, actually, Lea, what you said, that’s a really interesting insight, because the cynic in me has often thought, you know, a lot of these working groups are filled by people from the big browsers because they want to dominate. But what you’re saying is it’s actually, very well could be, because actually they are some of the very few companies in the world where the activities of the standards organizations and standards committees are almost completely aligned with the activities of the organization. So therefore it’s not actually a sinister thing. It’s just a reality of alignments of incentive, if you like.
Lea: I do think that this is largely correct. I mean, we do have a lot of browser implementers in working groups as well. Don’t get me wrong. Like, invited experts are a small percentage. But in general, most people in these working groups do genuinely seem to want what’s best for the web. I mean, opinions about what that is obviously differ, but it’s very rare to see people overtly acting with different motivations. One thing that helps with diversity in the TAG is that, and in the AB as well actually, is that you cannot have two people from the same company. If someone changes affiliation, they have to leave and run again for election. The process mandates that there can never be two people from the same company, unless like one of them is just finishing their term.
I mean, this is generally a good rule because otherwise I would easily imagine like Google dominating these groups. But also like sometimes it can be a problem because there’s a lot of talent with people in the same organization. Like, so someone gets hired by Google and now has to step down from the TAG or from the AB and sometimes this is unfortunate because there are very few people in the world that have this kind of expertise that these groups need. So when we lose one it’s painful.
WHATWG, W3C, and WebDX
Vadim: Do you have any experience working with WHATWG? Like that’s another working group working on the third and one of the last parts of the web. That’s historically separate from W3C?
Lea: Yeah, WHATWG works on the HTML specification and several other browser APIs like the DOM API. My understanding, and I’m not 100% sure about the inner workings of WHATWG, I’ve never actually participated.
I mean, we’re often in contact with WHATWG. We often review specifications from there. They are very active in our design principles repo. We get their perspective on things. It is unclear to me how someone gets involved at WHATWG that doesn’t actually work for a browser, which could entirely just be my lack of information, right?
I’m not saying there is no process for it, but my impression is that WHATWG is primarily browser vendors collaborating on certain specifications.
Bruce: Lest our listenership think this is a terribly sinister way to run a working group being a bunch of browser vendors, that’s exactly how what WG was set up way back in the Carboniferous era when W3C said that everything needs to go to XML.
Lea: Right. At the time W3C was acting like a bunch of academics on an ivory tower. It has changed a lot since then, and that is not the culture at W3C anymore. But at the time, the philosophy was let’s just create an amazing version of HTML that is pure and lovely and beautiful. And let’s just not worry about these petty things like backwards compatibility, because what matters is to just have this beautiful language.
And I mean, a part of me gets it because like they had some really beautiful ideas and what HTML5 ended up is far less beautiful, but you know, having ideas that no browser is willing to implement, it’s basically intellectual masturbation. They’re just pointless documents if nobody wants to implement them. Like specs don’t mean anything until they have implementations.
Bruce: Yeah. And that’s why WHATWG was set up, because individuals, not even representatives of the browsers in Opera and Firefox, and pretty soon afterwards Apple, just got together to work out how they could meaningfully extend HTML while keeping it backwards compatible.
It worries me sometimes, because now our chums on TC39 and ECMA basically rule the world of JavaScript or ECMAScript (or even ActionScript as I like to call it). And now our friends at WHATWG have got control of HTML back. Is the W3C’s purview influence diminished or diminishing? Or do you see the three pillars of the web, you know, JavaScript, CSS, and HTML as mutually supportive and equally valuable and equally playing the part?
Lea: I think that I see them more as the three pillars that are equally important and collaborating. There are even people who are in more than one of these groups. The CSS Working Group is generally like a well-oiled machine. It works really well. It’s very organized. It’s fairly large. We maintain a huge number of specs. Like at this point, the specs that could, that CSS consists of are over a hundred, I think.
I mean, definitely W3C’s purview has diminished since they lost HTML and since WHATWG had to be founded to basically save HTML. And eventually they also lost the DOM. There are still several APIs being developed at W3C and obviously CSS as well.
Bruce: And of course SVG. And I believe we both know a gentleman who’s intimately involved with SVG and was at the beginning and still is.
Lea: Right. That was going to be the next thing I mentioned. SVG is still at W3C.
Vadim: All kind of community groups, usually under W3C, like WebDX, this new one or some others.
Lea: Yeah, WebDX is a great effort. I was recently participating in WebDX because I’m going to lead State of HTML this year, which is a new survey. I’m sure you’ve heard of state of JavaScript and state of CSS. Google is funding the effort to also have a state of HTML to sort of ask questions about all these little gaps. And the WebDX group is very involved in that effort. We’ve had several calls trying to flesh out things about the survey.
Vadim: Is it the same platform that’s running state of JS and CSS?
Lea: Yes, yes. Sasha is behind that as well.
Vadim: Oh, yeah. Good, good.
Bruce: I’m a massive noob. What is WebDX?
Lea: DX stands for Developer Experience. Basically user experience where the user is a developer. And obviously it’s not just that the user happens to be a developer, it’s that the tool is also related to development. So when we’re talking about things like the usability of CSS or HTML or JavaScript APIs, like this is DX, or when we’re talking about sort of the usability of developer tools, like all of that is, or APIs or libraries, like all of these are DX.
So far the community group devotes a lot of time in like documentation, communicating certain things to developers. like in the recent meeting Baseline was also discussed. And yes, there’s a lot of community groups that do really valuable things.
Another community group I was involved with in the beginning was the Web Components Community Group, which actually started from a blog post of mine where I wrote about the failed promise of Web Components and then I was approached by several people in the Web Components Community and they were like, “Let’s start a community group to fix these things.” And I thought that’s a great idea.
That’s where the Web Components Community Group came from. And now it’s active in like so many different initiatives. Unfortunately, I haven’t been able to find the time to be actively involved anymore. And I sort of like watch from the sidelines. I’m really happy that something like that came out of that blog post.
Vadim: I mean, it was strong wording, like failed promise. I have to do something about it.
Bruce: I think I’ve noticed quite a bit in the last couple of years, the working groups are given an increasing amount of thought into things like giving stuff, consistent names, making sure there’s consistency across APIs. I forget the exact specifics, but sort of naming things similarly across Grid and Flexbox, for example. So the same sort of concept doesn’t have a wildly different name compared with which spec it’s in.
And I think that’s really good because it is so important. If developers are constantly thinking, why the hell is that name this in that spec and the same kind of thing, justifying content is named differently than that. It just makes them grumpy. But it’s not just making them grumpy, it makes people think this is not a platform, this is a sort of loose agglomeration of specs that’s just been randomly thrown up against the wall. Whereas it’s entirely legitimate to say that the Web we know it now is a loose collection of specs that have been thrown against the wall over the last 30 years, there really has been an effort, I think, a laudable effort to think about naming, API consistency. So hurrah for the WebDX people.
Lea: Yeah, absolutely. And indeed consistency is a big part of usability. Unfortunately sometimes it’s not as straightforward as you might expect to decide which direction to go to be consistent because often there are multiple different precedents, especially since the web platform was developed over so many years from so many different groups, not necessarily always with the same amount of care as we have now.
Bruce: And a lot of the times they were drunk when they did it back in the old days.
Lea: There are such instances. I’ve heard some stories. But often you get many different precedents and you don’t know which one to go with.
Sometimes there’s also the dilemma of, you know, we have a precedent here, but it’s terrible. Do we choose to be consistent with the terrible precedent or do we choose to do a new thing which is inconsistent with the past but it’s actually more usable?
Bruce: Got an example of that?
Lea: Like for example there’s a bunch of newer DOM APIs that actually were inspired from jQuery. I don’t know if people have heard of them like before and after() and replaceWith() and remove() and all of these.
These are a vast departure from the previous DOM APIs which required references of like a lot more nodes in the tree and you could argue that they’re actually inconsistent with with the existing DOM APIs.
Vadim: Which is a good thing.
Lea: But exactly. Here, it’s a good thing because they were designed from the ground up to match how JavaScript developers want APIs to work, whereas the previous ones were designed to match Java.
And this is not even the best example, but it’s one that I could remember off the top of my head.
This comes up a lot, and there’s also external consistency and internal consistency, as we say in usability. Internal consistency is like being consistent with your own system, external consistency is being consistent with the rest of the world, other systems out there that do similar things. And sometimes this can be in conflict.
Like when we added LAB colors to CSS, do you choose to be consistent with CSS or do you choose to be consistent with color science? And these do not necessarily lead to the same design decisions.
Like in terms of how you pass parameters, do you use percentages for lightness for the L coordinate, things like that. Like, you know, we had a lot of disagreements in the working group based on where somebody was coming from, like the color science people were suggesting one thing, then the people whose background was primarily CSS were suggesting a different thing.
There’s no obvious decision in these dilemmas. It’s just, you have to weigh the trade-offs. Sometimes you have to do the research to see what developers expect and what developers find most ergonomic and decide on a case by case basis.
Like when it comes to deciding between internal and external consistency, a good rule of thumb is are your users likely to be primarily people who are using this system only and have never experienced this technology outside of this? Or are they primarily people who have experienced the technology outside of this space and they are now using the system?
Like, using the example I mentioned earlier, are people who are going to use LAB colors in CSS, mostly CSS developers or mostly color scientists who are using CSS?
And I think, you know, the answer to that, right? It’s CSS developers. So we chose to err on the side of being consistent with the rest of CSS.
Vadim: There’s a similar story with SVG filter naming. They definitely come from some computer science, some graphic libraries, but it’s impossible to remember those names in this syntax. So that’s one of the reasons why developers prefer to use graphic editors instead of manually writing SVG, for example. Bad design.
Lea: Well, also because SVG was never written to be hand-authored. That is unfortunately a mistake in the design of SVG that initially they were expecting SVG to be generated by tools. They were not expecting people to hand-author it.
And I think this should actually be a design principle that like any text-based syntax will be hand authored by people. Even if you think it’s never going to be hand authored by people, it will be. People are going to learn it and hand-author it.
The only chance this is not going to happen is if it’s a binary format, but as long as they can read the code, they will try to modify the code.
Vadim: It’s good that they didn’t make it binary. So thank you for that, at least.
Bruce: One should always assume that somewhere in the world, somebody will be hand authoring it because tools, we’re all used to everything being free, but not all tools are free and it would be a tragedy if the only way to author SVG would be some $49 tool from Adobe or some $49 tool from a company that then went bust and so the tool died and there was no real way of authoring that would be that’d be dreadful you know.
I speak as somebody who view-sourced and fucked about in notepad and then reopen the file in the browser to see what would happen and I don’t know if people still do that but if we stop the ability to do that then there won’t be anybody doing that so…
Vadim: They still do, they still do.
Bruce: Good! Everybody should have the same pain that I had. You’ll know this as being being a parent, Lea, it’s like you know you start protecting them, and you think: you can have pain like I did. Rite of passage.
Lea: I think I would try to eliminate my daughter’s pain.
Bruce: Ah, yeah. But you wait till they hit puberty, then you wish pain on the buggers.
Lea: I’ve heard this before. We’ll see.
Family, SVG, and named colors
Bruce: Talking of which, I mean, you mentioned you don’t have enough time and you can’t clone yourself, but you’ve done the next best thing and produced a small human. So when should we expect Zoe’s first spec?
Lea: Well, I mean, I have been trying to show her CSS. She does get quite excited. Like if she sees me coding something and I show her like, look at what mommy can make with code. Like I recently made her this app to help her with reading where she like presses each Greek letter and hears my voice pronouncing it.
I’ve actually made her a bunch of apps. I wish I can release them one day, but they’re so rough around the edges I’m embarrassed to.
Like I’ve written her another app where you write words in either English or Greek and then if you press enter and if the word is correct, then you get pictures of that thing, like it fetches them from Unsplash.
The goal is to encourage motivation to actually like write the word or read the word so that she gets the pictures. Cause she really likes seeing all the pictures and like, you know, sometimes we do it as a reading exercise. Like, you know, I might write a word and if she reads the word correctly, I will press enter and she will see all the pictures and it also translates the word to the other language because she’s bilingual, so she speaks both Greek and English fluently.
Vadim: Who needs toys if you have like CSS engineer mom?
Lea: I’ve also made her a game where like she moves the cursor around to like go to a circle and then like the circle disappears and she gets like another circle that is slightly smaller and the game becomes progressively more difficult because the circles become smaller, which I made for her to teach her how to use a mouse.
Unfortunately Macs still don’t have touch screens, which is hilarious to see how she expects everything to have a touch screen.
Bruce: I shit you not, I’m nearly a hundred and I found myself trying to swipe up on a printed book. So I can only imagine that every child in the universe now thinks that if it’s vaguely made of glass, you should be able to control it with your finger.
While I’m being intrusive about your personal life here, Lea, so given that your husband is one of the godfathers or the godfather of SVG, do you have spec wars when he’s writing SVG and you’re writing CSS and you’re like, “Hey Zoe, come and look at this stuff”?
Lea: So actually, Chris is not involved in SVG any longer. Part of it was that browser vendors have a lot of pushback against improving their SVG implementations, which is really unfortunate, but it is what it is.
I think part of it is just that browser developers are not interested. And the way a lot of browser companies operate is that engineer input is important for the roadmaps, which is great in general, like developing a product and allowing engineers to have input into the product is a fantastic idea. But it does mean that because none of them is interested in implementing SVG, their SVG implementations kind of stagnate and don’t develop much.
And as you can imagine, if you are the person that started SVG, that can be extremely demoralizing. So in the last few years, he’s primarily working on CSS, web fonts, web audio, and he’s not actually actively…
Oh, PNG as well. He was one of the authors of PNG and now he was involved in the new version of PNG that’s about to come out, I think, which introduces APNG and HDR support in PNG, very exciting things.
So he just chose to put his energy into things that he feels would have more of an impact and I can’t fault him.
Bruce: No, no. Yeah, absolutely.
Vadim: I’ve been trying to bring browsers’ attention to SVG over and over again, and there seems to be reluctance.
Lea: Yeah, they are trying to incorporate parts of SVG into CSS. And who knows, maybe eventually if they incorporate all of SVG into CSS and HTML, they might have more interest in developing it further. Who knows?
But to answer your original question and like the spirit of your question, yes, we do often disagree because like we do work on CSS together and we are interested in some of the same areas of CSS, specifically color. We are both editors of CSS Color.
I joined, I think on CSS Color 4, whereas he’s always been involved in CSS color. Like he’s the resident color expert at W3C, but we have co-edited specs together. It’s generally a nice collaboration.
I would say we’ve released a library that we coded together and we had a very nice separation of roles. The library is called Color.js. It is a color manipulation library for JavaScript. It does a bunch of things, color manipulation, gamut mapping, interpolation, like gradients, that sort of thing.
It’s designed to be color space agnostic. So it can support literally any color space in theory. And part of it was a kitchen sink so we could experiment with the design of the native color API that we’re also working on.
And we had a very nice separation of duties. Like I was the API design person for this library and he did like a lot of the math and the color science part, because he knows that far better than me.
And this library has been used in like browser test suites at this point. It’s been used to develop a lot of the examples in the specs. Like it’s sort of fairly widely used in the spec world in the sort of people working in these technologies, in these standards.
Vadim: Also in developer tools like PostCSS, I’ve seen a number of plugins using it to fall back new colors to old or vice versa.
Lea: Yes. I think we even collaborated with some of the developers of these tools to make Color.js more suitable. Like when we originally launched, it was a, an object oriented API that was designed to be like as usable as possible, but we got the feedback that people wanted a tree shaking, a tree-shakable API, even though that wouldn’t necessarily have the same ergonomics, but it would help them reduce bundle size. And we ended up basically offering both.
Bruce: So why in CSS, if I say something is color: gray it’s a darker gray than if I say color: darkgray.
Lea: Oh, I love that question. So that actually gets you back far before my time. I’ve only read about this. When CSS started having colors, I think in CSS1, it got the, how many was it, 16 colors that HTML supported. There’s a list of these somewhere in Wikipedia.
I think there were white, black, red, blue, olive, I think.
Vadim: Cyan, magenta, something like this.
Lea: Orange was actually added later.
Vadim: Who needs orange anyway?
Bruce: It’s vastly overrated.
Vadim: True.
Lea: Like, you know, there was a version, I think it was CSS 2, I can’t remember. But at some point later, orange was added, just orange. And then when CSS was modularized and we got like a CSS Color 3 module, we got a slew of named colors that actually came from a different source. They came from X11. X11 is this old operating system.
Vadim: Right. So you merged two systems.
Lea: That’s what happened. Right. I mean, these names are wildly inconsistent with each other and with everything else. Like, you know, you have things like, I think there are versions of colors that you have light something and you don’t actually have the something by itself. There are weird names like Indian red or Peru or blanched almond and…
Bruce: Goldenrod.
Lea: Goldenrod yellow. I think there’s light goldenrod yellow, but there’s no goldenrod yellow. Like, they have some variations but not others. I can’t remember the exact details. And yes, one of the most weird things about them is exactly what you mentioned, that gray is actually darker than dark gray. We already had gray from the initial set of 16 colors and we couldn’t change it.
Vadim: Yeah, that’s the thing with the web, you cannot undo.
Bruce: Well, I suggest we do. I will buy you a large bunch of nice lilies and a good bottle of red wine if you will go and deprecate those named colors.
Lea: There are a lot of thoughts about having a more intuitive system. So far, we don’t really have anything in the spec right now. At some point, there used to be a proposal about a better system where it was basically sort of an English-based HSL-like syntax, which was removed because it had the same problems as HSL.
It is definitely a direction that we want to go. Like there needs to be a good way to define human readable names for colors.
I suppose there is less of a pressing need right now because of CSS variables, because you can always define colors that have nice readable names and just reference them throughout your CSS. But there’s definitely interest in this.
Vadim: Create your dark gray and light gray, like proper ones in CSS variables and leave Lea alone, Okay.
Bruce: I will cease holding you personally responsible for a naming convention before any of us were born, probably.
Thank you very much for sharing your knowledge. keep on TAGging, I suppose as it’s Memorial Day over in your neck of the woods, I should say thank you for your service, being the stormtroops of the TAG and enforcing nice design principles, and all the other stuff you’ve done, thank you, and give our love to Chris and Zoe.
Lea: Will do, thank you so much for having me.
Bruce: It’s been a delight. So, dear listeners, all three of you, we draw a close to this edition of The F-Word. Thank you very much to Lea Verou and thank you for listening. Of course most of the things that we’ve referenced will be in the show notes so until next time it’s goodbye from Birmingham.
Vadim: Cheers from Berlin
Lea: And cheers from Massachusetts.
Bruce Keep on webbing!