Bruce Lawson's personal site

I met the TAG!

On Thursday, I travelled down to the swanky Mozilla offices in London to an open invitation to meet the W3C Technical Architecture Group (TAG), who were in town (presumably for this week’s Bilderberg meeting). I’ve met many of them before, and they’re all jolly good people, but I’d never met them as an entity.

I’d lugged my laptop down to take notes, as I’d anticipated some sort of relaxed presentation and then a public Q&A (by “relaxed” I mean, not live streamed and in front of the small 30-strong audience enjoying Google’s beer donation). It was unstructured, however, with TAG people mingling around and presumably answering the same questions repeatedly. (I’ve given this feedback to the co-chair, Dan Appelquist, already.)

I asked “What does the TAG do?” after Dan introduced the evening. Dan and TimBL answered that the TAG is an oversight body that ensures W3C specs kind of cohere, and kind of stay within the Architecture of the World Wide Web that TAG defined. Jo Rabin followed up with the question “how does TAG measure its success?” to which there was a less definite response. (However, the Web continues to do rather well, so arguably they haven’t broken anything.)

It’s good that the TAG want to meet developers. Tag member Jeni Tennison asked me what my pet peeve with the TAG is. I answered that there isn’t a representative of jobbing web developers on the team. Sure, there are some people who represent browser vendors on the team, but people like me don’t make web sites every day any more (if they ever did). I’m starting to feel that although lip service is paid to the needs of developers in the Priority of Constituencies, it’s pretty hard for a developer to get his/her voice heard.

Matt Marquis wrote recently

working in web standards is incredibly frustrating. It involves no small amount of interaction with people who seem to have graduated from the Hacker News Commenter School of Diplomacy. We “authors don’t hold much weight in standards discussions; at least, nowhere near as much as browser representatives do.

Now, do I think more full-time designers and web developers should get involved in standards, after all this glowing endorsement? Absolutely. The fact is, we don’t have the kind of voice we ought to have because we’re not there. “Author preference is very often used to argue for or against something in a standards discussion, but very few of us are around to agree or disagree. We’re a talking point more than we’re active participants.

The question is, what to do about it? Six years ago, the CSS Eleven announced with a fanfare that it was an organisation “committed to helping the W3C’s CSS Working Group to better deliver the tools that are needed to design tomorrow’s web”, made itself a lovely website and then promptly disappeared. I’ve certainly heard from developers and designers that it’s hard to do a full-time job, keep up with all the new developments and get actively involved in the time-consuming minutiae of standards development.

Perhaps we wound the Web Standards Project up too early. But I don’t think so. Perhaps we need someone embedded in the TAG who is paid by a benevolent employer to devote 50% of his/her time to standards while continuing to work. Perhaps we need someone paid by the W3C full-time to represent developers.

I don’t know. What do you think?

Buy "Calling For The Moon", my debut album of songs I wrote while living in Thailand, India, Turkey. (Only £2, on Bandcamp.)

26 Responses to “ I met the TAG! ”

Comment by Yoav Weiss

A few days back on the RICG’s IRC, following Mat’s post, we started contemplating the option of forming an organization that would represent Web developers in the standard process.(logs)
As Mat put it “Basically, devs need an RICG, but for everything”

The Priority of Constituencies that you mentioned states “users over authors over implementors over specifiers”.

All these different entities are represented in the standards process by browser vendors. Large Web entities, which can be considered as authors, can influence the standards by sending their people to attend the different working groups and give their opinion. Most Web developers, whose constraints are vastly different, cannot afford to.

I don’t think a TAG member that represents Web developers is the answer (In a way, most of the new members are, considering their background). I think that we need Web developers to get involved in the day to day work of the different working groups, tackle issues before they evolve, and do so in the long-run, in order to be considered as equals and be heard by the browser folks.

I’m still not sure what’s the best way to get there.

Comment by Karl

What do we think? hmmm. Putting my double hat of ex-w3c and technical director of a Web agency.

All Web developers are not equal. Some are part of a Web agency of 10 or more employees, others are alone trying to make a business. For those in Web agencies, they usually do not have that much time to worry about Web standards or imagining what would be cool. The businesses is driven by the salesperson and whatever the desire of the Web developer to do well in the case s/he knows the main objective is to deliver things according to the Photoshop mockups of the artistic director and the ahaha sound comments of the clients. Not that much space to breathe. Add to that the project manager who is suffocating the Dev to stay in the budget.

I’m not trying to be dark about anything, just trying to paint one of the social reality. Having a representative means someone who collects the feedback of developers, who don’t have time to give a damn about Web architecture.

Another issue is the English language. It is already hard to get involved, add a layer of languages and a bit of culture and you get something difficult to manage.

So what is the solution or is under an issue? w3c Would in general benefit to have more real Web evangelization as explaining the 101 of all technologies. Why is Web architecture is useful? I know why or at least I have my own idea but I’m not sure that most people get it. Then there are different classes of people interested. Someone working on a hateoaseoas API doesn’t have the same requirements than someone cutting a Photoshop layout or someone creating the front end for a Web app.


Comment by Jon Rimmer

I think there is a significant step up in terms of complexity from understanding web platform technologies well enough to use them, to understanding them well enough to contribute to their ongoing enhancement and standardisation, and it tends to be underestimated by many developers who want to get involved with the process. For example, you can get up and running using CSS to lay out and style a document in a few hours, and there are plenty of tutorials and books to help you, but to truly understand it, enough to contribute meaningfully to standards group discussions, requires close reading of specifications and parsing documents like Eric Meyer’s terse description of inline formatting. It takes a lot longer, and a lot more effort.

And that is just to grasp the actual mechanics of the technologies, the how of things work, there is a whole corpus of additional knowledge that also feeds into standardisation discussions about the why. Years of archived mailing list posts within working groups that lead to particular approaches being adopted or discarded; Historical accidents and backwards compatibility requirements that makes certain things necessary or unfeasible; Obscure and difficult but cross-cutting concerns like encoding, accessibility, internationalisation and security that turn even apparently basic areas of the platform into minefields for the unprepared, and sink seemingly great ideas; The realities of implementing things within a browser in terms of effort, complexity and performance.

It doesn’t help that many developers who decide to get involved do so from a position of frustration. They keep encountering areas of the web platform that don’t work well or match their expectations, and eventually their frustration boils over into a resolve to “do something”, by subscribing to a working group mailing list and pitching ideas. Unfortunately, this kind of motivation tends to quickly collide with the the difficulties I just mentioned. It’s easy to rage about lumbering standards groups and bad designs in a blog post, but it’s much harder to really fix these problems, particularly when you have a full time job to attend to, and the people you’re talking with have a ten year lead, or more, in their knowledge of standardisation and browser implementation. If a browser engineer or a spec editor tells you your idea is unfeasible for some obscure reason, how can you counter that? How can you know if it’s true or not? You can quickly feel like you’re playing a game where the odds are heavily stacked against you.

Engineers and editors in standards groups can also be unreceptive to contributions from developers. Developer advocates frequently enthuse their audiences to provide input to the standards groups, and editors and engineers repeat this mantra. But the problem is akin to the one developers ourselves face: We love to make a big deal about putting the users front and centre, until we’re faced with a list of crazy, contradictory or impractical requests and we’re forced to start saying well no, we can’t do this, because…. Users get pissed off because we seem to be ignoring them, in the same way we get pissed off with spec editors and browser vendors for ignoring us or not doing things the way we think they obviously should. As technical types, we’re not used to being on this side of a knowledge gap.

The W3C community groups were supposed to help address these problems, but as the responsive images debacle has shown, they aren’t there yet. My take on this, and bear in mind I don’t know everything about what went on, is that both sides need to do better at engaging the other. Spec editors and browser vendors need to keep up with and get involved with developer discussions in the community, wherever they are happening, and avoid unveiling new features like commandments from Mount Sinai. If developers want to design features, they need to ensure there is buy in from browser vendors from the beginning, and make sures lines of communication are also open. They also need to be prepared for the argument, compromise, obscure problems and generally ugly, messy nature of moving new features from a good idea to a standardised and widely implemented reality.

Comment by Matt Wilcox

It takes two side’s listening and talking to engage. From what I saw in the RICG there was plenty of that on one side, and virtually nothing on the other. It felt like for the majority of the time we were being treated as an annoying fly in the room. How are you supposed to do anything about that?

There also seems to be, in general, a NIH syndrome with any ‘group’, and that’s not restricted to the W3C etc. It’s assumed that ‘the other guys’ haven’t thought it all through, and boom you auto-dismiss it because your one insight that disproves an argument is taken to disprove the whole concept instead.

Fact is, achieving anything in a complex system requires compromise, and the web stack is very complex – but some compromises are just plain bad compromises.

Take the grid spec – how can any group have even *begun* to work on that without consulting an expert in grid systems first? The problem was an inability to use a common design tooling system ‘grids’ on websites. In looking for a solution, the group did not even look at what a grid *is* and how they are used. Presumably it was assumed grids are simple and not looked into any further than that. Now we’re at the end of the spec (practically) and to put it kindly, it bears less resemblance to something a designer would call a grid system than that designer might like. Despite feedback, two years ago, from professionals who use grid systems (reference: ).

If the developers of specs aren’t going to ask the right questions at the start, and aren’t going to act on the feedback of people who *are* experts in the area they’re trying to create solutions for, what is the point?

It’s not systems that are the problem, it’s attitudes.

For my part, I’ve been completely put off anything to do with the official groups. There are some great people in there, and I’ve no doubt most peoples motives are exemplary, and I appreciate their contributions and time. At the same time, I just don’t feel the right people are consulted, the right things are prioritised, and the right feedback sought, at the right times. So, essentially, management.

Comment by Andrew Betts

This discussion is a great example of why the FT started to get more involved. My impression exactly mirrors Jon’s – spec groups are largely dominated by those with the knowledge and time to see everything in the broadest context, and as a result developers who don’t have time to attain that status find it very hard to contribute an idea or suggestion that doesn’t come across as dumb. I find myself in this positon constantly.

Our answer was to start the Edge conference – which we seem to be in a good positon to do since as a big news org, all the browser vendors want to talk to us anyway. The developers we invite are those that are in that position of starting to experience frustration at the advanced end of using web technologies and have ideas for what would be better, but can’t engage WGs for the reasons we’ve established. I don’t think we did this especially well on the first go, but we’ve learned a lot in the process and are going for a second round in New York in September, so anyone who’s interested please head over to To be clear about our motivations, all proceeds of the conference are donated to local charities.

As the web platform gets increasingly complex and the web as a solution to everyday problems becomes ever more ubiquitous, we see a huge increase in the number of developers working with web technologies, and a corresponding increase in the gap between the entry level and the advanced ends of the skill spectrum. In short, there are way more developers, and those whose voices the standards groups would be well advised to listen to can easily get lost in the din created by the poorly informed. I don’t really know what the answer to this is, but Edge seems like a decent stab at doing something constructive.

Comment by Cliff Tyllick

Bruce, I haven’t worked on Web standards, but I have (tried) to represent working developers on a W3C working group. The experience was incredibly frustrating. Because my employer was not a member of the W3C, I was expected to compensate by putting in more work than were participants who represented members of the W3C–this in spite of the fact that the time I was donating was my personal time, not my employer’s. And in spite of the fact that when I attended face-to-face meetings, every nickel of the cost came out of my pocket and every hour of a workday spent was counted as my vacation.

In other words, whereas the participants representing members did so as part of their job, I did so as part of my life. But they were the elites, and I was their serf. My input on the types of materials developers need to better understand standards and guidelines was all but ignored. It couldn’t even have a place on the list of items to maybe consider to adding to the agenda after items already on the agenda were completed. I was actually told, “If you think it’s that important, do it yourself!”

Point of clarification: It’s inaccurate to say hat I thought it was important. In working on an open source project, I had heard individual developers ask for precisely the kind of documentation I was trying to get the working group to consider preparing. I was willing to work for years on projects already on the agenda if only I could get the promise of considering putting this project on the agenda, but I couldn’t even get that.

OK, so let’s total it up: *after* working a full-time job, I was expected to do twice as much work as the member-backed participants on projects important only to them, and then *after* doing all of this work deemed crucial by the member-backed participants–on my own, without the benefit of supporting work from other participants on this working group–I was supposed to do the project that would most help the individual working developers I was there to represent.

And whatever I produced through that effort would not bear the imprimatur of or be presented on Web servers owned and operated by the W3C.

I would have to continue to support it in every way on my own.

I’ve worked with a number of organizations that rely on volunteers to get their work done. That isn’t how the successful ones treat their volunteers. If the W3C is to get value from the participation of volunteers representing he interests of working stiffs, it met start by taking a page from those organizations.

Treat your volunteers’ hours as if they are gifts of gold. Make that trebly true for volunteers representing the working stiffs. Otherwise, we will have Web standards and supporting documents for the elites–paying lip service to the way the Web should work without doing anything to remove the real obstacles that prevent most developers from making it work that way.

Or, to use your words, all style, no substance.

Comment by Robin Berjon

So… basically that job would be 1) hang out with developers, 2) hack on random stuff to get a feel for what’s going on, and 3) rant to groups about how detached from reality they are (ok, maybe a bit more constructively than that)?

Where do I sign up?

Comment by bruce

@Anne, yes, so would I (I didn’t know Yehuda was on TAG before that evening).

@Robin that’s why I say “I don’t know [what the answer is]”. I tend to think that the set-up we have is the least worst of all other set-ups that I can imagine. But I know my imagination is limited; I’d like to know of someone can conceive of better. I’ve also wondered whether actually the W3C is an exemplar of how Western democracies will end up – lots of compromise, lots of corporate influence, but fundamentally decent and better than all alternatives. But I digress …

Comment by Robin Berjon

@Bruce I was only half joking actually, I think such a job could indeed be useful, and I don’t think that the useful setup would be all that different from that which I described (evidently, there’d be a need to actually publish about all that and the such).

And it would be a pretty sweet job to have, too 🙂

Comment by Alex Russell

Hey all,

I’ve chatted with Bruce since he wrote this, so I won’t take out my frustrations with some of the text here, but want instead of make a couple of points:

1.) We’ve actually succeeded in turning the TAG into an API review board. The Plan of Record that was set at the meeting that hosted this meetup is for the TAG to request that Chairs and Editors present (I won’t say “defend”, if only to avoid scaring them off) their specs to the TAG as early as possible so that we can help them ensure that their work products are layerable, extensible, encourage good URL use, etc.
2.) We’ve actually succeeded at electing more folks with a webdev background to the TAG than at any time in recent memory. You could make a credible case that I don’t count any more, but in my own defense, I’ll just say that I’m writing more JS and HTML than I am C++ these days.
3.) I feel for Cliff earlier up in the comments, but we all need to understand the limits of the institutions that we’re trying to steer. The W3C is _always going to be bad at some things_. That’s OK, it needs focus. What that focus should be is the debate I’d like for us to have, and, to the extent that the TAG has any voice at all, I’m hopeful that it can be a voice for developers.

The meetup was a (ham fisted?) first attempt to encourage the modern TAG to understand who the consumers of our platform are, what their problems really look like, and to the extent that overlaps with or and expands their experience, give those on the TAG who don’t have a webdev background more sympathy for the very real frustrations of those trying to build on the web platform today.

The TAG can’t fix most things, and it has no power to fix anything directly (it’s not a vendor, it ships no software), but it can be an advocate for web developers in an organization that is structurally devoid of that now.

I know I’m going to continue to help set our agenda in that direction. And if Bruce didn’t get my response to “how will you know you’ve succeeded?”, let me say it again here: we’ll have succeeded when what you learn about one bit of the modern web platform is portable to every other part. And that means affecting shipping browsers.


Comment by Bruce

Thanks Alex.

I think your frustration was with the fact that I didn’t know the direction of the TAG that you helpfully outlined above. Now I consider myself to be “nerd” end of the “Interested in Standardisation Politics” spectrum, so I’d counter with the suggestion that the TAG has hitherto over-estimated its ability to broadcast what it does to the relevant people. Hence my wish that there had been some kind of formal presentation by TAG on what it does, what its priorities are, what its mission is etc. I don’t think the meetup was ham-fisted; if nothing else, it shows the TAG could work on communicating better what you’ve expressed above. It also demonstrated the level of developer interest in what it does.

“it can be an advocate for web developers in an organization that is structurally devoid of that now” – great! How can we help?

Comment by Alex Russell

hey Bruce,

I agree that the TAG hasn’t been an effective communicator of its own work. Most of that has come in the form of Findings, published here:

I can very honestly tell you that I never read a single one of them before I decided to run for the TAG, and feel it’s perhaps the least effective thing the TAG can be spending its time on. That’s why we’ve spent months working to change the direction of this ship, closing up old work, tying up loose ends, etc.

I DO think there’s a set of meaningful documents the TAG can produce that will have impact: AWWW is an outdated example of this sort of thing, and we’ve agreed this year to try to modernize it a bit and give a start to something that’s targeted at standards developers who don’t know good from bad idiomatic web API design. A “What To Expect When You’re Expecting To Design A Web API”, if you will. Concrete guidance for C++ engineers who view the world of API design via IDL can have leverage, particularly when combined with the review process we’re setting up.

But the bigger thing we’re doing now is the reviews and 1:1 interventions in WGs to help them improve the overall quality of their products. Nobody (to a first approximation) gives a shit if the TAG produces a Finding about something, but everybody who uses IDB cares that its API is…problematic.

Almost all of that is interally-facing: stuff that the TAG says to/about W3C products that can have a real effect on the day-to-day lives of webdevs. But let me suggest that the work that has happened with Promises indicates that can have real, positive leverage. That was lead by TAG members acting in a platform-wide capacity and we’re going to use the TAG to help drive those wins home. Same for construcability, sane argument handling, subclassing, de-sugaring from high-to-low level platform semantics as a core bit of specs, etc. We’ve already challenged many WGs to do better, and it _is_ having an impact. Later this year, I hope we are able to bring the same firepower to bear on the question of a Streams API.

The way we interact with developers, I think, should be listening — at least for now. Yes, we’ll have accomplishments to show, but they will always be collaborations.

What can you do to help? First, there is unfinished business: the W3C needs to believe that its job is the care and feeding of the Web; not just to standardize what a dozen member organizations think might be a good idea. This takes many forms, and it’s going to require that the overall organization grow a sense of responsibility for the platform. I’m trying to turn the TAG around to be the tip of that spear, but we need a much larger movement behind us to help the W3C understand that it’s not OK to be spending time and effort on things that don’t matter to the web. Its “mission” makes no such distinctions today:

Fixing that means, probably, taking the loss of several members, and *that* means finding a way to replace the revenue (and/or trimming the overhead). I’ve often mentioned the idea of individual memberships, and I think that’s a way to kill several birds with one stone:

1.) It gives the W3C a more direct stake in the concerns of its largest constituency: web developers
2.) It provides a path for web developers to elect representatives
3.) It provides a way for the W3C’s coffers to sponsor the travel/time of the elected representatives of individual members

Today, the closest analogue to that is the JQuery Foundation which is sponsoring Yehuda Katz to participate in both TC39 and the TAG. But that’s far too little. We need more people with that sort of backing to be able to really change the makeup of the AC and to be able to engage in the processes in a sustained way. Since those folks don’t work for vendors, the sort of impact they can have will be different: they can do the most good by being data-driven stewards of web developer’s needs. Finding out what hurts most and advocating to vendors that those should be their highest priorities, and being able to spend the time working with them. These must be exceptional people, but we’ve seen it happen, and I think the W3C could do good here by reforming itself in ways that give developers a _structural_ voice.

Until that’s done, the TAG is your man in Havana. We’re the group that can do the listening, apply some pressure, and work to advocate to vendors; but it’s not going to be our natural strong-suit and not something we’ll ever be able to do in a full-throated way. The TAG will always do better on issues of technical architecture. Cataloguing areas for improvement is likely the next step for the TAG, e.g.:

To do more, we need a different way to distill our voices.

The Extensible Web Manifesto is a start. Convincing the W3C that it must pay attention to the web that exists and turn down activities that have no bearing on it requires political pressure. I don’t know how to create that, but I’d like to work with you to make it happen.


Comment by François REMY

I globally agree with Matt & Cliff comments. Even when authors try to get involved, the barrier is extremely high. From my own experience, asking little changes is often okay because it’s easy to convince the editors, but when your opinion conflicts with the one expressed by the spec editor, things get much more difficult.

Before even considering we may be right and that the changes we ask are worthwhile, we have to convince a sufficient amount of group members, and most of the times we’re not given the opportunity to do so. Generally, because you’re not there when decisions are made, your arguments never appear in the discussion while the few counter-arguments do show up.

That’s logical, I don’t think there’s a way against this, but this is the reason why most independent representatives drop out after some time. You have to be strong enough not to consider every failure to get your point through as a valid reason you’ll not be able to get the next one through, i.e. you can’t loose every time.

Comment by François REMY

Just rereading the previous post, and it seems it can appear more negative I wanted him to be. The basic idea was: “A petition with 150 000 signatures can’t make Google reconsider the Google Reader end-of-life” but, still, feedbacks made every day to guys working at Google can influence things on the long run.

So, my adivce to people who want to change how things work: this is a background work, you often don’t get big results immediately, but little by little you can get more consideration and weight.

Attempting to make big changes that conflict with an editor point of view can be really difficult but that’s okay. Being sufficiently considered as a person takes time, a lot of time. Just keep going 😉

Comment by Alex Russell


Trying to convince editors without having first convinced at least one vendor that you’re right is the path to nowhere. The standards process isn’t set up to invent or to fix, but to write down what is considered a consensus view to how something should be done. You can’t change the consensus by changing spec text. One flows from the other, and it’s pointless to try to lobby the spec process without winning arguments with vendors.

THAT is where I have been able to make change happen from; by going to work for a vendor. It’s also how folks like Yehuda Katz, Erik Avidsson, Rick Waldron, and other have been able to make real change happen: by patiently partnering with people who own implementations to explain and convince them of the urgency of real-world problems.

Don’t lobby editors, lobby vendors. They’ll change the editor’s mind for you.


Comment by chaals

Authors – “ordinary Web developers” – come in lots of flavours. Some work in small shops for hire. Some create their own particular project for a relatively small market. Some create projects that other people use (Yehuda would be an example). Some make massive projects that millions of people use… And these differences mean they are focused on slightly different things.

Most of them don’t have time to talk to the TAG (even if they belong to the subset who actually have the language skills and are luck enough to be where the TAG are). I’m pleased to hear that you want to update AWWW and document the sort of thing that developers should do.

Many developers will read stuff that is relevant, if it comes up on a search engine in their language. So having useful documents that get translated would be a great thing for the TAG to do.

Likewise as a Working Group chair I think it is really useful for the TAG to talk to Working Groups. Not as some Delphic council making obscure promises for futures that need to be interpreted by people who are made to feel stupid, but as people who can explain the important concepts in terms that make sense to humans (well, at least to standards folk). Argument from authority isn’t any better because it comes from the “new TAG” – but helpful explanation for the “masses” can really make a difference to the way the Web develops.

Which leads to a really critical question:

What is the Web?

Is it the set of pages that get picked up by search engines? Does it include pages you need to register for? What about pages that use a plugin to render important content? Or just to render advertising? What about apps that run on a browser engine (and therefore have a potentially huge influence in the way the browser itself develops, and therefore what can be done by public web pages)? What about intranets, that use a password, or firewall? What about China, or Thailand, or Australia, where the web is behind a filtering firewall? What about BML content in Japan, or i-mode content, or other stuff that starts in walled gardens but where the walls fall down?

I think this is a reasonably important question. I don’t know that there is a clear answer, but I think it is important that the TAG takes a large view. Not primarily because that allows W3C to recruit members from various industries, but because without doing that it is ignoring a lot of the contributors to what gets implemented – in other words, it is claiming to drive the train but pretending that it doesn’t matter what the stoker does…

Anyway, for all that it is clearly a fools’ errand for the TAG to try and do outreach to “Developers” with any sense of talking to most of them, it is good to know that they are listening and thinking about what matters to them. If the outreach improves, and the focus remains on the important work that the TAG should do, I think we will all be better off.

Comment by Alex Russell

Hi Chaals,

Great to hear you support the review/feedback work item for the TAG. Some members have been doing this on an ad-hoc basis for a while now, and it has gone relatively well, so I’m hopeful that a collaborative relationship with WGs can lead to more progress.

As for arguments-from-authority, we both know the TAG has precious little of that to argue with. Just enough to hang itself with. What it has more of now than in the past, and more than some WGs, is a global perspective, including the webdev perspective. The earlier those conversations happen, the more collaborative it can be, so while I’m frustrated in some ways that the web’s APIs have been left in this state, at least we now have a credible way to work towards something better.

I don’t think any of that demands that we define what the web is, though. Certainly not with any specificity.

We can chart out the “fixpoints” in the landscape of value creation that mark the pillars of value upon which the web has stood for so long without being dogmatic about any of them: URLs, links, declarative forms, HTTP, well-layered JS APIs. They’re all means to an end: creating a better world for more people. These are valuable because they have made lives better.

That’s the murky yard-stick: is someone asking for priority for their idea/perspective likely to improve a large amount of the web for many people? Do the issues raised affect many people? Do those people have other options? It’s a consequentialist view.

Lastly, I do not accept that the TAG can ever claim to drive the train. Nor would I. Instead, I can suggest it can do better or worse is setting standards for the creation and licensing of signaling equipment. It can demand they be polished, functional, etc. But we cannot drive trains. Nor should we try.


Comment by François REMY

@Alex: For sure, lobbying vendors is an interesting approach ^_^ but it requires much more real-life contacts than most developers could ever afford 😉

The other option I see is the “do it yourself” approach where you make a prollyfill for the feature to use it for yourself & get people to see what it would look like. But, at this time, this approach is also very tiresome.

Comment by Alex Russell


The time and effort required is a key reason I’m suggesting that developers need more focused representation. Folks who know the ins-and-outs, the people, and the non-obvious interests of the parties involved. That isn’t something you get without experience, and as a group, webdevs aren’t growing that experience in a focused, useful way. There are a few TAG members who represent that, but they’re the closest thing we have.

But lets be clear: that is a tactic that can work. This is in start contrats to asking a standards process to give you what you want without first convincing vendors, which if it ever works, will only ever be coincidence.

If we want to do better than placebo, we need to focus on things that DO work.


Comment by François REMY

Alex: representation is a strategy that can work, I agree with you, but I believe the most critical problem is the lack of tools that can provide high S/N communication channels (1) when discussing use cases (2) when deciding which proposals are best to solve the use cases.

Mails, chats, and anything that ends up being discussion instead of state editing do not scale well enough to enable this. This is why it’s so hard to get devs involved, because when they do, it generates noise and noise makes WG work less efficient.

Representatives lower the noise inside groups by creating filtering gates, but maintaining those gates is even costly in term of noise, you just moved the problem.

I believe is supposed to do what you would like (represent devs in groups) but the real-life effects remain to be seen. Lea Verou has been fighting for border-corner-shape with a lot of conviction, but I didn’t see much results in the way vendors were thinking about it.

So, to sum up, representation is great, but will not solve all problems 😉

Comment by Alex Russell

Solving the tools problem is the last thing to worry about.

You can solve the understanding gap, however, and to do so you put people in the same room with each other and you find ways to encourage mutual respect. That’s the place to start.

As for tools, the second-most-productive thing I’ve done so far is private Github repos, and it only works in a small group doing early design. The benefit is that you can coordinate easily without a lot of travel. The downside is that it’s much more lossy. And by the time you get to a WG situation, you must already have a design to be discussion or it’s DOOMED.

Again: focus on thing that can work, not things that you feel are somehow easy. The correlation is often quite low.

Comment by chaals

(Alex, sounds like we are on the same path with regards to what the TAG is and should be. Which seems like a good thing to me – YMMV 🙂 )

Leave a Reply

HTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong> . To display code, manually escape it.