Any military is comprised of individuals, grouped into successively larger units.  While all of these units are striving for a single overarching goal, they don’t share consciousness and so, regardless of how well trained they are or how much intelligence they have, there is an inevitable amount of uncertainty which is impossible to remove.  This concept is sometimes termed “The Fog of War” and one very unfortunate result is that sometimes same-side damage is caused by an ally.  This is often referred to as “Friendly Fire” or “Blue on Blue”.  In this post, I’ll explain how these same concepts apply in the DOM and talk about how we can avoid danger..

Any large company tends to organize things a bit like a military – individuals in units of units cooperating toward a common goal. If they’re using something like a CMS, one team might define some general layouts for reuse.  Another team creating content and still other teams creating reusable/shared ‘widgets’ which are all assembled together (often dynamically) to create a whole page.

One instance of this might look like the figure below:

A common layout containing a company-wide standard header, main content with social sharing buttons, an aside/secondary content with shared ‘widgets’ and footer.

What’s interesting about this is that, at an observable level, only the third-party social sharing buttons are not created and maintained by the company itself and need to be treated as a potentially hostile actor.  All of the other pieces are allies in the task of presenting and managing the DOM and any distinction in how they are created, organized and maintained is, at some level, artificial and purely organizational.  Anyone who has worked in this sort of model will have experienced “The Fog of DOM“.  That is, preventing accidental violence against your allies is really hard – it’s simply too easy to accidentally select and operate on elements that aren’t “yours“.  Specifically, it’s not a security concern, it’s a cooperation/coordination concern: The fact that all operate on the same DOM and make use of selectors means that unless there is perfect coordination, even careful use of a selector in a page can easily harm components and vice versa: Friendly fire.

What’s perhaps most surprising is that you don’t actually need a large organization to experience this problem yourself, you just have to want to reuse code that you aren’t developing all at once.

Why is it so damned hard?

Primarily, I think that the answer has a lot to do with how the Web has evolved.  First, there was just markup and so this wouldn’t have been much of a problem even if these approaches/large teams existed way back then.  Then came JavaScript which had its own default global issues, but at least you could scope your code. Then came real DOM and we could start doing some interesting things.  CSS’s aim was to allow you to write rules that allowed you to make broad, sweeping statements like “All paragraphs should have a 1em margin” and then override with more specific statements like “All paragraphs inside a section with the class `suggestions` should have a 2em left margin.”  Within the context of what we were doing, this was clearly useful and over time we’ve used selectors to identify elements in JavaScript as well and our projects continued to get bigger, more complex and more ambitious.

Now, while there are some actions I can take to prevent my component from affecting the page that hosts it, it’s incredibly hard to prevent the outer page from accidentally selecting/impacting elements inside components.  One mistake on either end could spell problems and since they are maintained separately, by different teams, keeping them constantly in check involves an incredible degree of coordination and in the end any shortcomings in coordination usually mean investigation, hackery and guesswork to resolve.

Note again:  This isn’t about security.  I’m not concerned that my co-workers could steal my data, it’s their data too.  My users are their users, my company is their company.  We are allies.  It just needs to be plausible for us to easily collaborate and work together toward a common goal without a high chance of hurting our collaborators.  It still needs to be possible from the hosting page to say “Yes, I mean all buttons should be blue”, it’s just that it shouldn’t be the only (nor necessarily the default) position because it means it’s impossibly easy to harm your allies.

In short:  What the current design means for us, in many cases, is that it’s incredibly hard to “say what you mean” in such a way that it’s likely to avoid the most basic kinds of friendly fire. We have gobs and gobs of selectors stated as document-wide rules which become implausibly hard to reason about.  This makes them hard to write and debug.  Most sites today have hundreds of selectors, many have thousands – any of which could, theoretically apply in many many permutations.  So even if you manage to “get it right” for the time being, when you do have something that suddenly causes unexpected pain (and you will), it’s even more difficult to find out what’s causing it and why because it requires resolving all of those conflicts by resolving the rules in your head without creating others.

Is it “fixable”?

So, is it plausible to imagine a better future?  Is it possible to “fix” this problem, or at least make it very markedly better without completely re-inventing things?  There have been numerous proposals to do so over the years, all of them failed to gain enough traction to cross the finish line.  There were efforts in XBL in the early 2000’s, proposals to allow externally linked CSS mounted/scoped to an element in 2005,  and what would become known as “scoped CSS” is discussed and in drafts in 2006.  This proposal was actually eventually implemented in Chrome behind a flag and then removed.  Removed in part it doesn’t answer all of the questions that another proposal, Shadow DOM did.

We seem to tend to shift back and forth between answers too ambitious or too minimal, and once again, there’s a struggle with agreement.  And so, there’s an effort to step back and see if there is something less ambitious but that we actually can get agreement on. Currently there’s a debate about it going on pulling in two possible directions:  On one side is a group which posits that this is something that should be handled by CSS, on the other is a group which argues that it shouldn’t.  I am in the latter camp, and I’d like to explain why.

Key to both proposals is “isolation” – some kind of boundary at which authors can safely talk and reason about things ‘within a part of a tree’ without implying things outside that part unless they explicitly intend to do so.

Option A: “Handle it with CSS”

This approach suggests that something, perhaps a new @rule could be used to identify ‘isolation points’ via selectors and that subsequent rules could identify an isolation point for which they were relevant.  In fact, however, I believe this creates more questions and problems than it does answers and actually increases the authors’ cognitive load.  This raises some interesting follow up questions for me:

• Since selectors operate off the whole document, what if I specify that both .foo and .bar should be isolated (and my rules are in that order), and a .bar occurs inside a .foo? Is it isolated as part of the .bar isolation, or only the .foo isolation?
• Imagining I successfully identified an element as being isolated – would rules loaded or specified inside that element (by <link> or <style> or script) be scoped to that element automatically?
• Combine the above to questions and it seems that any answers inevitably create a radically new concept in CSS that affects how selector matching is done. While @rules are indeed ‘different’ by nature, at least historically they don’t seem to raise these kinds of issues.  If the new @rule ignores all boundaries to create a new isolation, it does so without any kind of combinator explaining that and it means that the default thing is still sort of an act of violence and you just have to manage avoiding harm through coordination.  If it doesn’t then within your ‘component’ (whether it is a true Web Component or not) you have something conceptually very new and it’s possible to ‘lose’ isolation by something as simple as a class change which seems to largely describe the situation we’re in today.
• What about the non-CSS end of things?  JavaScript uses selectors too, and has the same kinds of friendly fire issues.  With CSS at least I have dev tools to analyze what rules are in play. When I use a selector via querySelectorAll or something will it be context dependent?  If it uses the same selector matching as CSS, this is a new kind of problem.  It’s never been possible for CSS to affect what kinds of selectors match in DOM, and since it is not reflected in the DOM tree, understanding why this matches or doesn’t requires explanation.  If matching works differently in JavaScript, well, that is kind of confusing and leaves an important part of the problem unchanged.
• Would this be readable or writable or deletable through JavaScript?  In other words, could JavaScript create an isolation boundary – are we explaining and exposing magic or creating new magic? If they aren’t creatable through JavaScript, it feels like we are going in the wrong direction and even if they aren’t, they’re based on selectors.  In other words, there is a backdoor into it because they are very easily mutable.  This is either new vector for friendly fire or just a continuation of the one we have depending on how you look at it – either way it seems bad.
• It’s abstract rules.  As I said, at a certain point, it becomes incredibly hard to reason about rules and their permutations – especially when they are super mutable as anything defined by selectors would inherently be.  The bigger the variance and the more you attempt to break up the work, the harder it is to manage them, and when a problem does happen – how will you debug and understand it?

Option B: A New DOM Concept

The DOM is built of nodes with parent and child pointers.  Pretty much everything about selector matching is already built on this concept. If you can imagine a new kind of Node which simply connected a subtree with links that aren’t parent/child, this is a kind of a game-changer. For purposes here, let’s just call it a “MountNode” to avoid conflation with all the bits of Shadow DOM which is essentially this plus more.  Imagine that you’d connect this new MountNode to a hostElement and it would contain a mounted subtree.  Instead of the MountNode being just another child of the hostElement then, it is linked through the hostElement’s .mountPoint property instead.  And instead of the MountNode having a .parentElement, it has a link back through the .hostElement property.  Just something simple like this gets you some interesting effects and offers advantages that none of the other historic approaches (except Shadow DOM) provided:

• Everything that authors understand about trees more or less remains intact, with the slight caveat that there is a new kind of Node (not Element).
• DOM inspectors can show this (see Chrome’s representation of “Shadow Root”) and you can easily explain what’s going on.  All of the selector APIs (JavaScript and CSS) work the same way.
• A mount isn’t linked with parent/child nodes so all existing matching schemes work pretty much “as is” without change because they use parent/child traversal.
• Its intuitive then to create a combinator in CSS which allows you to select the mount explicitly because that’s just what combinators do today, tell you what to consider during the tree-walking.
• It’s minimal “new magic”.  We don’t create new things where CSS affects DOM, we don’t raise questions about matching or mutability of boundaries – it’s just a new, foundational piece of DOM that in all other respects works just the way it always has and allows us to experiment with and build higher-level answers.

This last point is especially important to me.  Is it possible to involve CSS and answer all of the questions in a sane way?  To be entirely honest, I don’t know.  What I do know, however, is that today this would involve a lot of speculation, decisions and bikeshedding.  I think this is better vetted in the community – and that any standards org is just as likely (maybe more) to get it wrong as they are to get it right.  Small improvements can have outsized impacts and provide a grounds upon which we can continue to “build” an explainable and layered platform, so I lean toward one that starts low and imperative, with DOM and provides a tool that can be used to solve both the stylistic and imperative ends of it.

What do you think?  Share your thoughts at www-style@w3.org.

Many thanks to all my friends who proofread this at some phase of evolution over the past several weeks and helped me (hopefully) give it fair and thoughtful treatment: Chris Wilson, Sylvain Galineau, Brendan Eich, François Remy, Léonie Watson and Coralie Mercier.  

About a week ago, I blogged about our need to involve the community in new ways on Medium, proposing “Chapters” – local meetups with the idea toward 

1. Bring people together in local forums to discuss developing standards 
2. Create a ‘safer’ and ‘easier’ place for lesser skilled developers to learn with mentoring 
3. Get help reviewing both standards and human documentation around them
4. To enlist help in looking at/reviewing and developing prollyfills and tests with an eye toward the standard
5. To ask introduce people to new technology and get them to try to use it 
6. Most importantly perhaps, to help figure out a way to coalesce this feedback and information and feed it back into standards bodies to manage noise and channels productively.

In this time, we put together a pilot on short notice in Burlington, Vermont (US) and last night, we had our first meeting at the University of Vermont (UVM) – 20 people turned out, including: A W3C Team Member, Darrel Miller who drove all the way from Montreal, UVM 5 students and numerous professionals with varying interests and skills.  UVM’s CS Department graciously sponsored food as well.  I just wanted to take a few minutes and record my own thoughts about what happened, as this is a pilot we hope to emulate in other parts of the world – it’s worth capturing to make those better.

First, I’m fairly introverted and not especially social in real life – I hadn’t expected to be ‘speaking’ as much as just facilitating getting people organized into some groups and helping discussions get rolling.  In retrospect, it’s fairly obvious that I should have expected to do a lot more organization on the first night.  Some people really didn’t know a lot about standards, the interests and skill levels were very diverse (that’s a great thing), it wasn’t clear to some what the goals were (not such a great thing), etc.   Such a diverse audience turned out to be a little rougher than I imagined –  I think if I were going to do it again, I’d plan to have a half hour to 45 minutes just to introduce things and then hope that’s all you need, but be prepared for another 30-45 minutes worth of questions.  In our case, despite a few attempts, I didn’t leave the front of the room for the entire 2.5 hours, which seemed to me like it must have been painful to the audience.  In other words, don’t expect a lot of concrete discussions as much as organization, goal and process agreement, information trading the first night.  Also, tell people to bring laptops and make sure there is wifi in the room that they can access… whoops.  

Despite the hiccups – I’m hopeful that people weren’t too bored and return, maybe even bring a friend.  The good news, even afterward, it seemed that there was genuine interest… Pleasantly, I got a few communications and a hand full of people who stuck around afterward to tell me that they are excited to be involved – so the group will go on, it remains to be seen how the next few will go, but I expect good things once we start digging into it.

If you were in attendance last night and have any thoughts you’d like to share for posterity or have thoughts/advice to others setting up a similar group, feel free to share in the comments.

The W3C Technical Architecture Group (TAG) is in the midst of a special election. If you’re reading this then you probably know that this is something of a pet topic for me, and that I think that reforming the TAG and AB is critical to real change in web standards. Generally, I explain who I think the candidates we need are and ask for developers to help make some noise, reach out to anyone they know and help get them elected. If you’re only interested in who I think is the best choice, I suppose you can cut to the chase, but I have some more to say in this election too, so as long as you’re here….

Why an election

First, why are we having an election at all? What makes it “special”? A special election is held when a seat opens up for some unexpected reason, off the normal cycle. In this case, it’s made necessary by the change of employment by one of it’s elected members. According to the rules, no member organization may have more than one representative in each of the elected bodies (TAG and AB). I’m pointing this out because on several occasions throughout the history of these groups, this same thing has happened: Elected folk change employers. Why? It’s simple really… Because the biggest employers with focus on standards belong to W3C and because we tend to try to elect smart folks who are well-respected in the community, it’s plain to see why this occasionally happens. This time, at least it’s led to some good discussion about whether the rule is actually what’s best for the Web, or whether we should make changes. I think we should. In the very least, a simple ‘confirmation’ vote should precede a special election: the rules are there for the people, and when they have implications that make virtually nobody happy, that’s a bad rule.

But that’s where we are: An election to fill a single seat. We have 4 nominees to fill the seat of Alex Russell, who, ironically, isn’t the one who switched employers but rather the one who had the shortest duration of term remaining with that member org (Google).

The nature of TAG is, at least theoretically, such that all nominees are technically qualified, and that the task is rather to choose who you think is the best choice for TAG at this time. There is a reason I’m bringing this up as well: How votes are cast and counted has been a topic of discussion for some time, and this election provides a perfect illustration of why it matters….

Travis Leithead

Mark Nottingham

I believe that two candidates are much better choices at this juncture in time than the other two, namely, both Travis Leithead and Mark Nottingham seem like excellent choices to me. They are well known to developers, have good cross-interests with important groups that we need in discussions and seem like they bring the best set of necessary assets as we work to flesh out an extensible platform with a long term vision of standards development that helps them compete and evolve with changing pressures.

But wait, there’s more!

The benefits that any nominee brings to the table can be subtle, but very real. Each AC gets only one vote, and that doesn’t have a lot of expressive power. I think that Travis Leithead has a slight edge in terms of what he brings, but I think that Mark Nottingham stands a slightly better chance of election by merit of his past service and visible social presence. So if I encourage ACs to vote for Travis, because, for example, bringing an inspired Microsoft player to the table is a great thing at this juncture and has virtuous ripple effects, each AC who does is potentially a vote Mark doesn’t get which he otherwise would. The number of ACs who cast votes in the first place is incredibly small, so losing just a couple can easily mean that neither of my preferred candidates get elected, a result that makes me notably less happy than if my “just barely second choice” candidate won. This is the case for preferential voting, it allows me to say ”I prefer this guy most” and “then this guy above others” and so on. The net result is that generally, more people are more happy with the results and spend less time agonizing over the choice.

In a funny way, while the system itself doesn’t work this way, it’s possible to achieve a similar result by way of a compact amongst ACs. If 5 or 6 like-minded ACs discussed who to vote for, and voted together you could avoid most of the incidental effects where neither our collective first, nor second (nor maybe even third) choice is elected.

So, please, encourage any AC you might know to vote responsibly and not only support the candidates I mentioned, but the reforms discussed above as well.

On September 11, 2014, Berlin will host the second ever Extensible Web Summit. You can get a (free) ticket from Lanyard and it’s scheduled to coincide with JS Conf EU 2014, so if you are going to be in the area I’d highly encourage you to attend if possible for something very different and important.

A little over a year ago, we sat down and authored The Extensible Web Manifesto which observes failings in how we historically create Web standards and proposes an alternative vision to correct these and make/keep the Web a compelling, competitive and adaptable platform for decades to come. Key among these ideas is the need to involve developers and harness the power of the community itself. 9 months later we held the very first Extensible Web Summit in San Francisco, California.  Unlike many conferences, the summit sets out with a different goal: To bring together developers, library authors, browser implementors and standards writers to discuss and solve problems, hear perspectives, help set priorities, etc. While there were a few quick lightning talks at the opening, the agenda, groups, etc were entirely decided by participants and run bar-camp style.

If you’re curious about how the first one went, here are a few links to posts which themselves have some additional links you can follow.

If you write or use libraries, if you have ever had thoughts, ideas or complaints about Web APIs, if are interested in standards, or you’d like to meet the folks who write the specs or implement in the browsers, if you develop for the Web in any significant way – you should come. Not only that, but I’d encourage you to really participate. At the first summit, several people seemed a little intimidated at first because of the presence of “giants” like Sir Tim Berners-Lee. Don’t be.  These people are all pleasantly human, just like you.  Several good things came out of the first one and with some practice and increased attendance and participation, we gain even more. So, go if you can – and tell someone else about it either way.

If you follow me (or many of my friends) on twitter or on G+ (or even on Facebook which I don’t really use) then you’ve probably seen lots of posts about W3C elections.  The funny thing about elections, unlike most of my other projects, is that they have a hard deadline and (I think) a potentially much bigger impact than anything else I’d be working on, so I find myself especially motivated to do what I think it is I need to do. As a result, they tend to dominate my streams for a while.  Over the last few elections, we’ve been gaining steam and more and more people are asking questions about it. That’s great, but since it’s hard to respond individually (or in 140 characters), I thought it would be worth putting together a FAQ which I (or others if they are so inclined) can point people to to explain the madness.

Who the freak is TAG?

TAG is the W3C Technical Architecture group.  It is one of only two groups in the W3C which is composed by election rather than appointment by groups who (generally) pay to belong to W3C (the other is the Advisory Board, or AB).  These two groups are also unique in two ways: First, in the sense that their charters cut across the spectrum of W3C,  second they are small – only 9 members in each and they are mostly elected.

Mostly Electeded?

Tim Berners-Lee (the creator of the Web) is the chair of the TAG and he gets to appoint 3 others.  You don’t even have to be a member of W3C to serve, you just need one to nominate you.

Is this a new thing?

Actually, no.  It’s been around for a long time (since 2001) – you’ve just likely never heard of it.

Why haven’t i heard of them before?

A few reasons: First (most importantly I think) is the fact that they’ve never done anything visible that you’d care about.  It’s mostly been a somewhat academic exercise at very high levels that produce documents and notes you will probably never read.  It’s helped a bit to steer things though which I address more in another section below. Second, you (probably) don’t get a vote (yet) – so traditionally, no one has bothered to tell you.  Seems pointless, right? Before you throw your hands up and close this window, keep reading – there is a rationale here.

Wait… If they don’t do anything I care about… Why should I care?

Simply put, because they could. In developer terms, its a bit like “discovering ajax” – there’s a great tool with a lot of potential just lying there dormant – waiting for someone to tap it and use it to do great things.

An honest history of why standards are in the shape they are in would be a lengthy post of it’s own (there are already several good ones), but these things we know: We don’t want to go down roads of the past and we do want to reform things that aren’t working well. We want to help blaze a bright new future. The candidates I support have a vision and common outlook (see The Extensible Web Manifesto for the thrust), and TAG is one of the tools that we can use to help realize it.

Wait… We need less appeal to authority, not, more…isn’t TAG problematic in this regard?

I don’t think so for a few reasons: As I said, historically TAG has been kind of a non-issue. What’s more, the candidates I support are made up of people with a common vision that swings the pendulum in a new direction in which there is, by design, less appeal to authority.

Things are what they are and we don’t get to pick where we start – recognizing current realities and operating within current structures to help drive things in a better way and (hopefully) bring some reform along the way just seems more logical than pretending reality doesn’t exist or needlessly tilting at windmills: W3C has a lot of things going for it. Additionally, it comes down to what powers TAG actually has…

Yeah… What powers does TAG have?

Power is a funny word – all organizations (including governments) have only the powers constituencies give them. The TAG doesn’t have a lot of official formal powers, but that doesn’t actually reflect the reality of things. By way of a somewhat US-centric analogy (the same holds in many counties, this just happens to be mine and serves as a decent example): The US president has comparatively weak formal powers – our congress maintains the power of the purse, to declare war and the ability to make and change laws. Our judiciary has the power to enforce and interpret laws. But if you think it doesn’t make much difference in practice who the president is, you really don’t pay attention. The president has a big influence on just about all these areas, in practice. But, and this is key: Their ability to do so is somewhat limited by their ability to mobilize popular support. Support provides political capital. While limited in official powers, in many ways, these powers are enough to let them help set the agenda. The bully pulpit lets them carry the voices of many in a powerful way. This is what I see as TAGs strength, and why I think the next item is key.

I am a developer, what can I do?

Most people reading this are likely average developers, and they don’t get to cast a vote (yet). However, if this its you – you can still raise your voice. Speak up and let the people who can vote know where we stand. If electors see a surge of support for a positive movement, we are likely to swing some votes our way. This matters more than you could imagine as there is actually low turnout – a (comparatively) few really involved companies with heavy interest tend to always show up and walk away with it. There is a great untapped wealth of organizations who are entitled a vote but don’t exercise their right to do do. If you know someone from a member organization, talk to them directly. If not, just show your support – as a community we are remarkably interconnected via social media. Just because you aren’t a member doesn’t mean that your message won’t reach them. What’s more, your voice helps empower our candidates described as in the political analogy above.

Why would an AC listen to me? They represent their organization…

For two important reasons: First, they are supposed to base their vote on what’s good for the Web at large and not just their company/organization. I believe that most ACs will act in good faith if presented with a compelling case, but maybe I am native in that. The second reason is more practical: Developers are the ones that make their organizations possible. Developers like you are the engine that drives their success. Their incentive to make you happy by representing you (assuming you are asking for something reasonable) is probably even stronger than that of a representative politician- business competition is strong. Even if they don’t vote your way, no organization wants to be out campaigning hard against developers. It seems to me, organizations will want to be on the right side of history, not the ones waving their hand and saying “let them eat cake”.

The vision the candidates I support isn’t just “reasonable” – its really good.

I think that the combination of these factors is healthy -there are good incentives for ACs to have a look at their platform and vision. Once they do, I honestly think most will become supporters themselves. A good movement is contagious.

I am an AC Representative – what can I do

If you are a W3C AC Representative, you can cast your vote! More still, tell another AC about why you did and encourage them to as well.

You keep saying I don’t get a vote yet – what’s that all about?

There have been informal proposals about changing the rules in a way that would let developers have some kind of more direct voice in the election process That’s where the other group, the AB comes in. That’s their job: Rules and process. It’s another post entirely- but if you’d like to see those sorts of reform as well – we’ll need to work together as a community.

Don’t let this happen to our Web…

Prologue
Long, long ago, in a galaxy far, far away…

It is a period of technical upheaval.  The plans for galactic XML domination have been thwarted and a breakaway group has taken over much of HTML base.  New technologies threaten the future stability of the Web.  Developers have begun challenging the status quo and established institutions.

The universe of Web standards stands poised on the brink of collapse and civil war.  A group of rebel developers with plan are building an alliance in an attempt to restore order to the force, establish a bright future and #extendthewebforward…

And they need your help…

Help me … You’re my only hope.

Let me cut to the chase: The Web needs your help. Here’s the TL;DR: The W3C has a group of 9 members called the Technical Architecture Group – I’ll explain what it is and why you should care later in the post, but the takeaway is that most of the members of this very small (9 member) group are elected and there is an election going on right now. I think the outcome really matters and that your involvement is key and that we need to help get Dave Herman and Domenic Denicola (more about them below the fold). Let me explain…

We can make a difference

Never underestimate the power of the force.

Historically, TAG hasn’t mattered much. It’s charter gives it a unique role, but chances are you probably have never heard of it. Almost exactly 1 year ago we ran a slate of “different” candidates for the TAG – well known, active, open-source developers who have been working tirelessly with standards bodies to solve real problems that matter. The aim was to give this group of representatives popular support and use TAGs charter to help drive things in a better direction, and carry our collective voices across the spectrum of standards bodies and working groups that we are currently not a part of – to reform Web standards.

So, for the first time in W3C history we ran a popular campaign via social media asking developers to voice their support – to lobby publicly and privately.  While you don’t get a vote (yet), the W3C members who do heard your voice and filled all of the open slots with our reformist candidates.  The chair seems to have also heard your voice as he appointed two additional candidates to co-chair.  Later, one of our candidates changed employers and according to the rules was ineligible to continue to serve (no organization can have more than one TAG member – good rule), so we ran another – and he won too.  We ran 4 candidates for the Advisory Board and 3 of the 4 won there too.

What’s it gotten us?

Here are a sampling of the ways our TAG members have helped us so far in less than a year:

• Re-focused the TAG on things we care about.  Chances are that you’ve never read or heard of a single thing that’s come out of TAG since its inception – but you’ve probably heard of lots of stuff they are talking about now.
• They helped to envision, co-authored and bring together a wide and diverse group of signatories for The Extensible Web Manifesto – an architectural plan that layers and moves exclusive power to innovate out of browsers and hopes to change the way we develop and think about standards themselves.
• Championing these ideas in the TAG, which has now essentially adopted them as guiding principles.
• TAG members are helping to coordinate the first Extensible Web Summit.
• Opened up collaboration between groups and helped coordinate common visions and APIs – helping either directly or indirectly on just about every interesting new thing:  Service Workers, Promises, Streams, Archives as first class citizens, Web Components, ES6 Modules, Web Audio, etc. etc. etc.
• They have helped make TAG a known entity by talking about it and involving developers in the discussions – TAG has had two public forums, has a twitter account and posts things to GitHub.

The Rebel Alliance

I’m excited that we have gotten two excellent candidates nominated and here’s why I will be doing everything I can to support these Jedi warriors in The Cause.

Dave Herman: Nominated by Mozilla.

Dave Herman is from Mozilla Research – he is an original co-signer of extensiblewebmanifesto.org and has been with us all along. Everything his group does is conceptually extensible web. He is on TC-39, the committee in charge of JavaScript, and he is the co-creator of asm.js and advocate/developer of many polyfills and prollyfills. His group is working on Servo, a parallel process rendering engine, so his group has a lot of feedback and thoughts of efficient APIs that can make the Web more competitive too.

Domenic Denicola: Nominated by JQuery

Domenic Denicola is also an original co-signer of  extensiblewebmanifesto.org and an active open source developer who has been increasingly involved in efforts – as a developer – with all of the major standards bodies. He has been an influential force in helping drive work on ideas like Streams and Promises and has also authored/advocated a number of polyfills and prollyfills, and this year has given several great conference talks evangelizing the extensible web and helping explain how to be involved with standards as a developer. He was nominated by jQuery.

This is your Web.

As the creator of the Web (and director of W3C) famously said, “This is for everyone”.

Aren’t you everyone? You are.

But historically speaking, you’ve had comparatively no real voice in the important decisions – so here is your chance:  Act.  Help us reform the W3C – let’s get these guys elected and start building a Web that is built to adapt, last and evolve.

Making your voice heard matters – and it’s so easy to click “Retweet” or “Like” or “+1” or 100 other things that help grow the movement . Write a post, make a video, send an email to a member you know.

Let’s make our collective voices heard and let the W3C know that we want representation that will help us #extendthewebforward.

Here’s a confession: I have a love/hate relationship with DOM related APIs.

You see, I love having a standard surface and that we have helped improve it in a lot of ways – there are some really great improvements.  But I still hate the reality of working with it sometimes. Originally I thought that it was merely because we know a lot of common usage patterns and while they are entirely accomplishable with existing APIs they currently tend to require a lot of boilerplate.  As I use them I often feel a dissonance between how simple the thing i am trying to describe is conceptually versus how much it really takes to accomplish — and how much that boilerplate can differ depending on which APIs i am dealing with.  Some of it is just sugar, sure, but recently I am thinking there might be more to it…

It’s frustrating when I see developers I know try to stick to native but eventually go and grab jQuery just for its DOM goodness, but – I kinda get it and it makes me think that maybe we’re missing something kind of fundamental.  Maybe not, but I’d like to throw it out there and see.  I’m happy to be wrong.

First, let me describe the more generalized problem as I see it, using the DOM APIs as an example:

• Even as fundamentally new capabilities arrive, we are constantly attempting to simultaneous align the new trajectory of the bright and glorious future with the very real requirement of “Don’t break the Web”. 
• The combination of these competing factors mean that legacy inevitably co-exists with things that have a different (hopefully better) new view on the world, but, at least for the near future (pronounced “years”) cannot completely eliminate the legacy.  In the case of DOM APIs, Arrays of Elements will live along side and cooperate with live NodeLists and Elements and jQuery array likes for years to come, and we’re still tweaking…
• The crux then is that the true state of affairs is that developers work with APIs that are in a state of perpetual transition between the mediocre past and the increasingly better future.  

 Just add this, over there…

A developer knows that conceptually we want to “just add this thing over here” in the DOM tree.  Seems simple enough.  But:  Given the state of things, Is the thing we want to add an Element? An Array of Elements? A node list?  Or, god forbid, a fragment of HTML serialization? Worse still is if that serialization is something that requires context (a table row, for example).  Or – is it some new thing?  Think about it – how you approach the problem is affected by which of these “over here” is.

Yikes.

Yes, It’s all accomplishable. Yes, and it’s way better than where we were 5 years ago.  But it leaves developers wanting and leaves a lot of room for error.  I have to use Array.prototype to turn something that is *almost* an array into an array, I have to worry about whether I am talking about a single element or an array of elements, or a NodeList.  It all seems unnecessarily complex and error prone at some level.

It sees that sometimes, as in this case, perhaps we could recognize that this will be a common evolutionary step and perhaps we could stabilize continuity by way of a unifying API based on the common concepts?  

And if you think about it, it’s sort of the one thing core thing that jQuery does that still isn’t currently a proposed standard.

A proposal to get things started…

Let’s imagine that we create a new unification API based on the common concepts:  Select one or more points in the DOM to modify and then perform modification on them.  Let’s call them DOMModificationTargets in keeping with the generally unfriendly tradition – aliases and bike-shedding a better name are easy.

DOMModificationTargets is a constructible abstraction with an underlying array that allows you to perform common patterns of DOM operations on All of the Things…

// A dead-simple unified API for conceptually similar 
// past, present and future APIs... It always freezes and
// exposes an underlying array
class DOMModificationTargets {

  // Create targets object via Any of the Things...
  DOMModificationTargets constructor(string markup);
  DOMModificationTargets ,constructor(Node node);
  DOMModificationTargets constructor(array elements);
  DOMModificationTargets constructor(NodeList list);

  // Perform conceptually common modifications on them...
  DOMModificationTargets append(string markup);
  DOMModificationTargets append(Node node);
  DOMModificationTargets append(array elements);
  DOMModificationTargets append(NodeList list);

  DOMModificationTargets prepend(string markup);
  DOMModificationTargets prepend(Node node);
  DOMModificationTargets prepend(array elements);
  DOMModificationTargets prepend(NodeList list);

  DOMModificationTargets replace(string markup);
  DOMModificationTargets replace(Node node);
  DOMModificationTargets replace(array elements);
  DOMModificationTargets replace(NodeList list);
  
  DOMModificationTargets replaceWith(String markup);
  DOMModificationTargets replaceWith(Node node);
  DOMModificationTargets replaceWith(array elements);
  DOMModificationTargets replaceWith(NodeList list);

  DOMModificationTargets addClass(string className);
  DOMModificationTargets removeClass(string className);
  DOMModificationTargets toggleClass(string className);
  DOMModificationTargets setAttribute(string name, string value);
  DOMModificationTargets removeAttribute(string name);

  array collection;

}

I’ve created a quick prollyfill for this on github with a demo – the source is a mere 200 lines of JavaScript.

Given that the underlying operations are the same, it would even be easy to add an extension pattern to this for prollyfilling future API types.

It it worth something to think that occasionally we should look at conceptually unifying/adapter APIs?  What do you think?