A while back, Henri Sivonen stumbled upon a diagram on the W3C site of the technology stack, a curvy-block Venn-diagram overview of the different technologies from W3C and where they fit into the Big Picture. It’s an attractive diagram, but it oversimplifies things, and shows a decidedly W3C bias toward the Web. It’s clearly been used past its expiration date, and those who consume it might feel a bit queasy.
Henri strongly criticized this depiction. He rightfully points out that HTML is not included in this vision (showing XHTML only, which looks a bit silly these days), but then complains that HTML5 and XHR are not included in the diagram. But of course, HTML5 isn’t even in Last Call yet, much less a W3C Recommendation, so it doesn’t really belong in that particular diagram (oddly, Henri credits XMLHTTPRequest to WHATWG, rather than its originator, Microsoft).
To his credit, Henri put his money where his mouth is, and took the trouble to make a diagram of the Web stack the way he sees it, which presumably better reflects the “real Web”. It omits many of the W3C technologies, and inserts some of the more common ones that aren’t from W3C (most notably Javascript). It’s a good diagram, but oversimplifies the landscape dramatically. He follows the W3C diagram in putting “Internet” at the base of the stack, but doesn’t correct it to include such ubiquitous technologies as email or chat (XMPP, IRC, etc.) even though those are often part of browser-based technologies (GMail, et al). Of course, he deliberately omits intranets-connected devices, even though that’s part of the browser world, because the official doctrine of the WHATWG is that the intranets (including those that are partly open, such as at universities) are “not the Web”. I will also quibble that he overlaps Accessibility only with HTML, not with SVG. But most glaringly, he includes Ogg Vorbis and Ogg Theora, though they aren’t (yet!) really used on the Web, and omits the dominant technologies in that space, MP3 and Flash (and more specifically, H.264). He covers himself here by saying that this is for a “contemporary browser”, with the insinuation that it doesn’t include plugins, though to users and authors that is a pale distinction. He also neglects PDF (ISO 32000), which is all too prevalent on the Web, and which several browsers do render (if I recall correctly). So, it’s not really a picture of the real-world Web stack, either.
The Frames remind us, in their song in “God Bless Mom”:
You’ll see how hard it can be
To keep your side of the deal,
And you’ll see how hard it can be
To keep one foot in the real.
So, his diagram is flawed. So what? Why am I picking on it? I’m not, really… it’s a good diagram, and it serves a certain purpose. I’m picking on that purpose itself. Henri was quick to criticize the W3C diagram (on a page where nobody can comment, I note), not because it wasn’t accurate, but because it advanced his agenda to do so (just as the W3C was advancing its agenda by making the original diagram).
Data visualization, like statistics or slogans, has a way of territorializing the map, in a kind of graphical gerrymandering. I’m sure that Henri didn’t mean to make such glaring omissions, but I’m equally sure that the creator of the original W3C diagram didn’t have sinister motives either. People get busy, and reuse what they have to hand that meets their needs, even when it’s sometimes not quite correct.
I really respect Henri, but what he fails to understand here, or at least to admit, is that different data visualizations are best suited for different audiences and different purposes. He’s shown a clear bias in his diagram toward depicting the “Open Web Stack” (a bias I have to admit I share) and toward desktop browsers (which I find too narrow), with a Web developer audience. That’s perfectly cromulent. But his diagram is not at all suited toward showing the different work going on at W3C, and where it fits in the larger Internet, in an executive summary. Both the offending W3C diagram and Henri’s own diagram are gross oversimplifications… which is the point of data visualizations. The map is not the territory. If I were to make a diagram that encompasses the Web tech landscape, it would include both W3C technologies and technologies from other sources, and code the origins with styling; it would clearly indicate which technologies are open (that is, not proprietary), which are under development and which are stable, and link each node to the definitive resource for that tech; it would not stack them up in a neat little box, but would show the interconnections via lines. And it would serve a different purpose than either of these other diagrams.
Why was only XHTML included in that W3C diagram, and not HTML? Wishful thinking. Say it enough times, and it just might come true, and a picture is worth a thousand words. We’re all dreaming the Web we want into reality, every day. I’m tired of the false dichotomy that’s too often drawn between W3C and its members and participants. How about we lay off the divisive rhetoric?
“But of course, HTML5 isn’t even in Last Call yet, much less a W3C Recommendation, so it doesn’t really belong in that particular diagramâ€
RDFa wasn’t a REC, either, when it was added to the W3C’s Techonology Stack diagram.
“(oddly, Henri credits XMLHTTPRequest to WHATWG, rather than its originator, Microsoft).â€
The XHR spec was “brought from the WHATWG to the W3Câ€. The XHR idea came from Microsoft, of course.
“To his credit, Henri put his money where his mouth is, and took the trouble to make a diagram of the Web stack the way he sees itâ€
I made a diagram for browser technology. First, I wrote “It is interesting how little the graphic has in common with a stack one might draw for a contemporary Web browser rendering a Web document (such as this one) or a Web application.†and then I titled the later post “Browser Technology Stackâ€.
“which presumably better reflects the ‘real Web’â€
Now you are presuming. 🙂
“It omits many of the W3C technologies, and inserts some of the more common ones that aren’t from W3C (most notably Javascript).â€
The conclusions I’d draw:
1) The W3C works on a lot of things that are not browser technology. Further, most W3C work is not browser technology.
2) Browsers contain non-W3C technology, too.
“It’s a good diagram, but oversimplifies the landscape dramatically.â€
It’s a 2D diagram, so there’s no way to put e.g. Canvas 2D API between JavaScript and Visual Rendering without overlapping something else.
“He follows the W3C diagram in putting “Internet†at the base of the stack, but doesn’t correct it to include such ubiquitous technologies as email or chat (XMPP, IRC, etc.) even though those are often part of browser-based technologies (GMail, et al).â€
GMail implement email technologies itself. A browser that is used to access Gmail and is used as the VM for GMail’s client-side code doesn’t itself implement email technologies.
You are right that email, XMPP and IRC are also layered on top of The Internet, but they are not a core part of Web browsers. Some browsers also support those applications of the Internet. Others don’t.
I did, however, omit feeds because I focused on what goes on in a normal browsing context (used as HTML5 term of the art here).
“Of course, he deliberately omits intranets-connected devices, even though that’s part of the browser world, because the official doctrine of the WHATWG is that the intranets (including those that are partly open, such as at universities) are ‘not the Web’.â€
What boxes should I have added so that the boxes would have been browser technologies but intranet-specific?
“I will also quibble that he overlaps Accessibility only with HTML, not with SVG.â€
SVG has relatively little to do with accessibility in browsers, and the 2D simplification in the diagram is limiting.
“But most glaringly, he includes Ogg Vorbis and Ogg Theora, though they aren’t (yet!) really used on the Web, and omits the dominant technologies in that space,â€
Yeah, that was deliberately controversial when Safari uses MP4/H.264/AAC instead of Ogg/Theora/Vorbis.
“Flashâ€
I think you are showing a bias towards the desktop. 🙂 Mobile Safari and Opera Mini don’t have Flash.
“with the insinuation that it doesn’t include pluginsâ€
I think NPAPI could be part of the diagram, yeah. It doesn’t fit nicely anywhere. Just like Canvas 2D doesn’t fit nicely and the fix of XSLT isn’t quite nice.
“He also neglects PDF (ISO 32000), which is all too prevalent on the Web, and which several browsers do render (if I recall correctly).â€
Safari on Mac (at least) supports PDF, yes. Most browsers don’t. Maybe in the future PDF support becomes part of browsers more generally.
“So, it’s not really a picture of the real-world Web stack, either.â€
It’s a diagram of what’s in browsers.
“I really respect Henri, but what he fails to understand here, or at least to admit, is that different data visualizations are best suited for different audiences and different purposes.â€
The purpose of one diagram seemed to be to list W3C technologies first and try to fit them into one picture of “the Web†second. The purpose of the other diagram is to visualize the rought relations of technologies implemented in browsers.
“He’s shown a clear bias in his diagram toward depicting the ‘Open Web Stack’ (a bias I have to admit I share) andâ€
I didn’t use the term “Open Web Stackâ€, FWIW.
“toward desktop browsers (which I find too narrow)â€
The technologies supported in Fennec, Mobile Safari and Opera Mini are pretty similar to the diagram I drew. You’d only need to drop boxes in the video and accessibility departments.
“But his diagram is not at all suited toward showing the different work going on at W3C, and where it fits in the larger Internet, in an executive summary.â€
It isn’t meant to do either of those things. In fact, it partly shows what’s not going on in the W3C (and goes on in ECMA, ISO, IETF, Unicode Consortium and Xiph).
“How about we lay off the divisive rhetoric?â€
You think drawing a diagram of browser technology is divisive? Maybe the Theora part was provocative, but otherwise, how?
“…but I’m equally sure that the creator of the original W3C diagram didn’t have sinister motives either.â€: thanks for the vote of confidence:-)
There no doubt that the diagram is out of date. I did it a long time ago when I was still in charge of the W3C Offices, but since I moved to another position I hardy ever touched it. That being said, the problem I see with the whole discussion is that the issues around the diagram are completely taken out of context. I never claimed that this diagram depicts ‘the Web’ (whatever different people consider under that term) and I do not think anybody meant to use it that way either. I created it to give an overview of what W3C works on. So Javascript or PDF were not included because those are not W3C activities (which is not a judgment, just stating facts). And yes, the diagram should be updated to include HTML but, back in cca. 2004-5 when I did it then, well, the only running W3C activity was XHTML.
So no, I did not have any sinister motives 🙂
Hi, Henri-
Thanks for responding. Just a few follow-ups:
“most W3C work is not browser technology”
That largely depends on what you consider should go into a browser; there are several technologies that I think browsers are ignoring today (SCXML, SMIL, and others). By the same token, I think there are some W3C technologies that should work toward becoming more browser-friendly. As a developer, I want to see a broader scope for browsers, and a narrower scope for W3C; there will never be complete overlap, but it could be a better balance.
“I think you are showing a bias towards the desktop. 🙂 Mobile Safari and Opera Mini don’t have Flash.”
Bite your tongue! 🙂 Some mobile browsers don’t have Flash, but a large number of mobile devices do. (Although I suspect the market penetration is far small than is often claimed.)
“I didn’t use the term “Open Web Stackâ€, FWIW.”
No, but that’s the rough equivalent of the technologies you’ve chosen. Nothing wrong with that, but it’s a pretty clear relationship.
“It’s a diagram of what’s in browsers.”
Well, some of what’s in some browsers. 🙂
“divisive rhetoric”
Your critique is not particularly divisive by itself. However, it is part of a larger pattern among WHATWG folks of setting up W3C as “the other”, when in fact, all the major browser vendors are part of what makes up W3C, and help dictate what goes on there. Certainly, W3C deals with stuff outside the browser realm, but it also devotes considerable resources to browser technologies. (Almost everything I do is browser-related, along with most people in the Interaction Domain, and a lot of the work in the other domains.)
“the 2D simplification in the diagram is limiting”
Absolutely. There’s only so much you can simply and usefully depict in such a diagram, including the W3C diagram. Your critique of Ivan’s diagram was not on the terms for which it was being used, but on the terms you wanted to set. It’s a bit of a strawman in this respect, so I wanted to clarify how the different diagrams carved up the Web differently, but don’t necessarily contradict one another.
Hi, Ivan-
Yes, we really need to update that diagram, because right now it’s still on the site. I know that there is talk in the Team about making a new one (which I’ve said needs to be done since before I came on the Team), but I guess it’s a matter of time and resources.
(Disclaimer: at one point, I took on the task to fix the diagram, but it really needs more than just changing “XHTML” to “X/HTML”, and I got pulled away onto other things.)
I’d love to have a diagrammatic view of Web technologies, and where each of the W3C techs fit within that… something along the lines I describe above. Maybe I will find time to do it this summer.
As for sinister motives… well, I defended you to Henri, but I secretly have my doubts about what twisted triples roil around your mind.
“That largely depends on what you consider should go into a browser; there are several technologies that I think browsers are ignoring today (SCXML, SMIL, and others).â€
Speaking for myself only, I think trying to develop technology that “should†go into browsers without the buy-in of a couple of browser vendors is a recipe for failure to develop technology that is suitable for browsers.
“Some mobile browsers don’t have Flash, but a large number of mobile devices do. (Although I suspect the market penetration is far small than is often claimed.)â€
The numbers are generally claimed on the basis of units shipped with Flash Lite. I have one of those devices (an S60 phone), and I can say with confidence that having Flash Lite on the device is utterly useless when it doesn’t work for presenting .swf files found when browsing the Web with the browser that came with the device.
(Aside: Similarly useless numbers are often cited for SVG. The same phone comes with a standalone SVG viewer but the bundled browser doesn’t support SVG.)
I also happen to have a device that came with a non-Lite version of Flash (Nokia N800), but devices like that are rare.
“Your critique is not particularly divisive by itself. However, it is part of a larger pattern among WHATWG folks of setting up W3C as ‘the other’â€
I think it’s a bit rich to accuse me of divisive rhetoric when you say “the official doctrine of the WHATWG†(I am not aware of the WHATWG having official doctrines) and imply things about what I might have implied by using a phrase like “sinister motivesâ€.
One point in my original blog post was that when the W3C decided to work on HTML again in 2006 and started the WG in 2007 (and took XHR into the precursor of Web Apps earlier), a PR page updated in 2008 but left with a stale diagram makes it seem that the W3C hasn’t fully embraced the recommencement of work on HTML. I don’t think the PR page gives a divisive appearance on purpose or due to “sinister motives‖just by failure to update.
(HTML5 not being further along on the REC track is a bad rationalization for not having “HTML†there, because the W3C has enough HTML RECs to put “HTML†on a diagram and, as Anne pointed out on IRC, WICD was a WD when it was added to the stack.)
Hi, Henri-
HTML5 wasn’t even a FPWD when that diagram was last updated (and everyone agrees it’s long out of date, something I believe the W3C Comm Team is working on). That said, of course I agree that HTML should have never been left off that diagram (it should have been “X/HTML” at the very least). I suspect it was as much a matter of trying to present a tidy picture as anything.
And, yes, I’m being tongue-in-cheek when I use words like “sinister”, and refer to the WHATWG’s “official doctrine”… but I’ve seen and heard the phrases “not the real Web”, “not Web-facing”, and so forth (with regards to intranets) too often from prominent people in the WHATWG for that bit not to have the kernel of truth. Whether it’s official or not, it’s effectively the party line. Again, I’m not accusing you personally of being divisive… it’s the effect that’s built up in the aggregate, and I’m hardly alone in noting it. And drawing that sharp line between what’s in browsers today and what isn’t (yet) in browsers underscores that false dichotomy.
But I think all of this steers the conversation away from my point. I agree that the diagram needs updating, especially now that HTML5 is getting more mature. But making the right diagram for the purpose is far from trivial.
“Flash Lite on the device is utterly useless when it doesn’t work for presenting .swf files found when browsing the Web with the browser that came with the device.”
True, if that mobile browser isn’t open enough to support third-party, cross-browser plugins, then it would be harder to see the real Web of today, agreed. 😉
That’s one reason why the partnerships at Open Screen Project are so important — unites the various competing browser brands and walled-gardens with common advanced functionality accessible to all creators, all consumers.
(Doug, great points there about the map altering the territory, thanks!)
jd/adobe
Hi, JD-
Well, this is a bit off-topic from my original point, but… I watched the video about the Open Screen Project, and I while certainly agree with the philosophy of making developers’ and users’ lives easier by providing a consistent platform across the classic “3 screens”, I’m not so sure I agree with Adobe’s means. That page says,
That’s an awful lot of “®” symbols for something labeled “Open”. Why doesn’t Adobe simply better enable their excellent authoring tools to produce the content consumed by the rest of the world, including all the major desktop browsers (Chrome, Firefox, IE, Opera, and Safari), and most of the emerging mobile platforms (Apple, Google, Microsoft, Mozilla, Nokia, Palm, RIM, etc.), which targeting the open Web stack of HTML, CSS, Javascript, Canvas, SVG, et al. I think you would be doing the world a great service if you started putting your effort into the universal platform, and concentrated your energy on continuing to differentiate yourselves with kickass authoring tools, rather than trying to make a constrained single-vendor end-user platform.
(Obviously, this is my own opinion, not necessarily that of W3C.)
That’s an awful lot of “®†symbols for something labeled “Openâ€.
Yup, and necessary too… Adobe controls the governance of SWF, protecting it from fragmentation. There’s more reason for this than there is for Apple controlling the governance of Webkit…. 😉
Adobe Dreamweaver is there to pick up the pieces of HTML fragmentation across different browser brands and versions. Meanwhile Flash provides predictable advanced capability across all the different browser brands you mention.
(btw, I still appreciate the map-vs-territory observations. 8)
jd/adobe
Hi, JD-
I’m not sure how true that is… Google, Nokia, and other players (including the original KHTML/FLOSS folks) are also pouring resources into WebKit. Apple only controls Safari.
Speaking of diagrams, that’s something I’d really like to see… a chart showing how much code each organization is putting into WebKit, with one bar per company, broken down into bands by technology area (HTML, CSS, DOM/APIs, SVG, Canvas, etc.)… that might be pretty revealing of an organization’s interest.
So are W3C and other standards bodies. 🙂
I do appreciate authoring tools like Dreamweaver, as well as script libraries like dojo, Raphaël, etc. that are smoothing out the authoring quirks of the browsers.
To clarify, you mean across the desktop versions of those browsers, right? And as Henri said, the integration story on mobile devices (in many ways, the future of the Web) is not as compelling. But SVG+HTML works on at least Opera and iPhone (as I noted before) today, and support is increasing.
Thanks! I’ve always loved that kind of catchphrase (“The map is not the territory”, “Ceci n’est pas une pipe”), but politics has taught me that Orwell was right… you can change reality by changing the perception of reality. This can be for good or ill. Here’s yet another popular quote, from Margaret Mead: “Never doubt that a small, group of thoughtful, committed citizens can change the world. Indeed, it is the only thing that ever has.”