Fans of HTML will be either thrilled or annoyed by the news that there
will soon be two independently maintained standards claiming to be the
authoritative definition of HTML. The Web Hypertext Application
Technology Working Group (WHATWG), a team comprised of representatives
from various browser makers, announced that it is
terminating its collaboration with the World Wide Web Consortium (W3C)
on the standardization of HTML 5. In WHATWG's account of the split, it
is continuing to develop the "living standard" of HTML, while W3C's
HTML 5 specification is a frozen "snapshot" of HTML. Based on the public statements and history
between the two groups, the underlying issue has more to do with the
standardization process than it does with technical differences
between their versions of HTML. Nevertheless, competition over
who has the right to declare their vision of HTML the official
standard will likely cause headaches for web developers.
WHATWG founder and chief public spokesman Ian Hickson posted
the news to the WHATWG mailing list on July 19. Hickson (who is a Google
employee) had been the primary editor for both the WHATWG and for
W3C's HTML Working Group. According to the announcement, Hickson will
continue to be the lead editor of WHATWG's HTML work, but leave the
W3C editor position. WHATWG will formally be a W3C "community group"
(CG), and will continue to use a W3C-hosted issue tracker. On the
latter point, however, Hickson and the W3C did go through the existing
bugs filed against the previously-unified HTML specification and clone
separate copies, one for each of the now distinct specifications.
upshot is that WHATWG now regards its version of HTML as the
definitive standard, which will continue to evolve, without declaring
numbered versions. Hickson concluded "My hope is that the net
effect of all this will be that work on the HTML Living Standard will
accelerate again, resuming the pace it had before we started working
with the W3C working group."
Hickson cited two reasons for the split. First, the W3C separated out
several parts of the HTML 5 specification into distinct
sub-specifications (such as the 2D canvas element,
postMessage, and server-sent events). The result, he said, was
"an increasing confusion of versions" of the
specification, in response to which WHATWG "went
back to just having a single spec on the WHATWG side which contains
everything I work on." Second is a divergence between the
WHATWG and W3C processes. Attempting to explain what that means,
Hickson described WHATWG's process as "fixing
bugs as we find them, adding new features as they become necessary and
viable, and generally tracking implementations." In contrast,
he said, the W3C HTML working group is focused on "creating a
snapshot developed according to the venerable W3C process."
What, work in a group?
To the untrained ear, those reasons might sound like WHATWG simply
does not want to participate in a standards process at all. But there is
more pointed criticism of the W3C on the WHATWG site, which
calls the term HTML 5 a "buzzword" and enumerates several specific
differences between the two standards, linking most of those to W3C
HTML working group decisions that WHATWG evidently found disagreeable.
The decisions that WHATWG critiques date back to mid-2010, although
many of them seem to be connected to the working group's recent
attempts to finalize HTML 5 over the course of 2011-2012 — such
as disagreements over the actual wording of the specification and its
inline advice (as opposed to, say, contradicting definitions of HTML
elements or attributes).
WHATWG's disinterest in finalizing the standard was also evident in a
Hickson made in January 2011. That post announced that WHATWG's version of HTML would
drop version numbers altogether, on the grounds that "the
technology is not versioned and instead we just have a living document
that defines the technology ." The HTML "Living Standard"
terminology persists in the group's current communication. W3C, in
contrast, is still moving forward with finalizing the HTML 5
specification and its successors. In an April message
to the HTML Working Group list, Maciej Stachowiak said the W3C has
begun to extend the HTML Working Group's charter to tackle "HTML.Next"
and will proceed to examine proposals, including "the WHATWG
HTML specification, which we anticipate will be one such
Viewed in that sense, the split between the two groups is not so much a
forking of HTML into separate proposals as W3C's HTML 5 is a "frozen
branch" of WHATWG's trunk. Or it would be, were it not for both
groups' claims to represent the official standard for HTML. Hickson
made this claim explicitly in his email, calling WHATWG's HTML Living
Standard the "canonical description of HTML and related
technologies." W3C's claim to ownership is less overt, but the
group and its founder Tim Berners-Lee have written and formalized HTML
since its inception in the 1990s. The first draft
was written in 1993, with subsequent revisions published as IETF RFCs
before the W3C process took over.
WHATWG was founded by a group of browser makers who felt that W3C's
process was too slow and bureaucratic, so perhaps it is miraculous
that the two groups were able to collaborate so successfully as long
as they did. In any case, the practical question is what the split
means for HTML developers — and, by extension, web users.
The great thing about standards is ...
The principal reason for concern is that if the two specifications drift in
different directions, web developers could be
forced to add even more workarounds to match both, or else sites
could be branded "WHATWG HTML compatible" or "W3C HTML compatible," reminiscent of a
return to the dark days of serious browser incompatibilities. In addition,
WHATWG's "living standard" approach has its own critics, principally
on the grounds that a constantly-in-flux document makes for a poor standard. A commenter named Mike asked
on the 2011 blog post "How do you make a test suite and a
browser compatibility chart for a “living standard”? It sounds like
HTML is becoming a sort of Wikipedia revision style chaotic
nightmare." Similarly, Jukka Korpela said:
“Living specification” sounds like a draft that may and will change at
any moment and is probably not even complete at any moment of time but
is still called a “specification”, since that sounds cool,
technological, and impressive.
I can’t believe I feel the need to explain such a trivial thing, but
really, a “specification” is a complete, consistent, stable, and
published normative description. It can be cited and referred to as a
requirement, e.g. in contracts and product descriptions. Typos,
apparent mistakes etc. can and should be corrected, but the content is
not changed as you go just because someone or some committee changes
its mind. The specification definitely does not “live”; its life is in
serving various purposes _as it is_. Development work takes place
elsewhere and may eventually lead to a new specification.
So “living specification” is about as oxymoronic as you can get.
Indeed, the current
presentation of WHATWG's incarnation of HTML does sport a
Wikipedia-style "last updated" timestamp at the top (the last update
was July 24, 2012 as of press time), plus floating tooltip-style
markers that point out certain paragraphs as "ready for first
implementations" from the margins — both features that hardly
inspire confidence in the specification's stability.
Steve Faulkner replied
to Hickson on the WHATWG list and took direct issue with WHATWG's
assertion of canonical-ness. "The claim that HTML the living
standard is canonical appears to imply that the requirements and
advice contained within HTML the living standard is more correct than
what is in the HTML5 specification." In particular, Faulkner
pointed out that WHATWG's specification, like W3C's, cover only
browser implementations and not authoring recommendations (which
tackle critical issues like accessibility in addition to stylistic
advice). On that front, Faulkner said, the W3C's specification has
the "more accurate set of
requirements and advice, that takes into account current implementation
realities, thus providing [authors] with more practical advice and thus end
users with a better experience."
Hickson and WHATWG have not responded publicly to Faulkner's message,
but perhaps that is to be expected. It seems clear that WHATWG's
primary motivation is continuing to add to HTML and related
technologies as quickly and as often as its members wish. Of course,
that highlights another thorny issue. As a standards-setting
organization, WHATWG is not particularly accountable; membership is by
invitation-only and Hickson can only be removed as HTML editor by the
members. Other members of the public are welcome to join the mailing
lists as "contributors," however. W3C may not be particularly
democratic either, but its flavor of bureaucracy is more diffuse, with
various working groups, interest groups, coordination groups, and
The H postulated
in 2011 that the seeds for the divergence of the two groups could be
traced back to WHATWG's dislike of W3C's HTML 5 logo and related
branding effort. One would hope that a core web technology like HTML
would be above that level of triviality, but the alternative reasons
given in public are not much more satisfying. With any luck, though, the web will
eventually route around the damage — one way or another.
Comments (26 posted)
As with most conferences, Akademy offered a wide variety of
interesting talks. Some of those talks have already been covered over the
last few weeks, but there is still a bit more to say about Akademy. It was
an energetic conference, in a beautiful city.
Akademy was broken up into a two-day conference portion followed by five
days of meetings, workshops, hackfests, and BoFs. Most of the latter
sessions are difficult to write about, particularly if one is helping out
on a nearly full day workshop on one
of those days. But a couple of the talks from the first two days stand
out. In some ways, they complement each other well; one looks at some
of the successes the KDE project has had, while the other looks at ways its
governance could be improved.
In the community keynote, Agustin Benito Bethencourt gave several examples
of "success stories" that make him optimistic for the future of KDE. It is
important to focus on successes because, in uncertain times in the software
industry, those stories give the project "confidence in what the future
us as a community and as a free software project". He
started with the example of the idea that the Qt framework should be free.
When he first attended Akademy in 2005, many people were talking about a
free Qt, but most people outside of the KDE community never thought it
would happen. But inside KDE, "the idea remained strong", and it did
Now Qt has an open governance model, which
came about because the KDE community "helped by pushing", he said. It is
an example of "active patience", where KDE continued "making good stuff"
and pushing for a more open Qt development model, which led to the desired
outcome. In the future, if the project can confidently "keep
pushing in the
same direction", similar results can be achieved.
The KDE development process is unique, and there are "very few big
companies that are as efficient as we are", Bethencourt said. Companies
often say that KDE isn't succeeding, but they can rarely match it in the
ability to develop new code. It is important for the project to recognize
that and "to keep the efficiency that we have".
Another good sign for the future is how good KDE has gotten at incubating
businesses. There are more and more freelancers and entrepreneurs in the
community, with KDE-related companies springing up frequently. KDE
provides the "right ecosystem", so the limits on what can be done simply
disappear. It is important to "keep that wheel rolling", he
said. Developers, translators,
and designers will be building more new companies, and the project will be
even more business-friendly in the future.
The project has always had a vision of where it is going, which is
important. He recalled the days when the discussions about KDE 4 started,
and when it was released he put it on a laptop. It worked, but was not
perfect—over time that changed. The project has "a clear vision of
where we want to go and we deliver after some time and work", Bethencourt
said. That makes others want to "develop under our umbrella". Having a
vision and sticking to it "will bring in outside energy".
The project also has longevity going for it. It is very difficult for a
software business or a project to keep going for a long time, and KDE has been
"innovating for the last 15 years". What KDE is doing now is "very
different from what we were doing before", but that is a strength. There
will be more changes over the coming years and if it keeps that "innovation
mode", KDE has a bright future ahead of it. There is very little that can
stop KDE from being here in another 15 years, he said—other than
limitations that come from within the project itself.
Is life peachy?
Mirko Böhm started his talk with a reference to Mathias Klang's keynote that had come just
before. Klang mentioned the "anti-homeless" benches that were installed in
Tokyo to make it nearly impossible for anyone to sleep on them. Böhm said
that he thinks KDE has some of those park benches, metaphorically, in that
the project's governance is designed to keep in people that the project
likes, but makes it "hard for those we don't [like] to join us". He wanted
attendees to start thinking about "where in KDE those park benches are".
Böhm has been contributing to KDE since 1997 and was a KDE e.V. board
member from 1999 until 2006. He helped organize last year's Desktop
Summit, and is currently doing research on free software and
intellectual property issues at Technical University Berlin.
He has heard the claim that KDE is good at sticking its head in the sand.
To illustrate, he put up a flowchart with a bubble that asked "Is life
peachy?". If the
answer is "yes", then "go do something" (e.g. write code), but if the
answer is "no", "stick
head in the sand", then "go do something". That is obviously not the
right way to approach things, as there needs to be a way to take
action to fix the problems. Changing the "stick head in sand" bubble to
"change something" and
re-routing back to the question is a better way. In order to decide what
the "something" is that needs change, one must first observe and then
reflect on the problems.
"Is life peachy at KDE?", he asked. For the most part, it is. KDE is the
largest meritocratic volunteer-driven free software project; other
large projects are mostly not run by volunteers, he said. KDE has an
"outstanding product", with a fairly stable contributor base. "As a
community, we are pretty healthy." The KDE code of conduct has been copied by
other organizations and the project serves as a role model for other
communities in free software.
Most folks want to stop at that point with the idea that "everything's
fine"—except that it isn't, Böhm said. There are a number of areas
aren't "peachy". To start with, users are complaining about a lack of
technical improvements in areas they care about. At times, the feedback that they
are providing "does not lead to tangible improvements".
There are also complaints about a lack of transparency in the governance of
the project. Böhm is concerned that contributors are leaving for
"non-technical reasons". It doesn't worry him if someone leaves because
they graduate and get a job, but if they are "trying to make a difference,
but can't" and leave because of that, it's a problem. Similarly, the project suffers
from a failure to integrate a commercial ecosystem; it is "good at pissing
off companies" so that they leave. That also leads to problems getting
vendors to pick up KDE and ship it with their products or distributions.
When making a software product, what matters in the end is that someone is
using it, he said.
Böhm and Sebastian Kügler recently scored the project using the Open
Governance Index (OGI) to try to get a sense of where it ranks. They found
that KDE ranked second in openness, behind Eclipse, but ahead of projects
like the Linux kernel, WebKit, Mozilla, and others. That shows that the
doing well, overall, but "we could do better", he said. His goal would be
for KDE to rank first.
There are positive points about the KDE community, but some reflection on
them is needed. It is a meritocracy with self-directed contributors. That
means that whoever does the coding work makes the decisions. But it leaves those
who don't contribute code without a voice in the decision-making. That may
not be quite right, he said, as there are others that make non-code
contributions who may deserve a voice.
KDE e.V. is not "just" a support organization, but is set up to "support
and foster the development of KDE". It does a good job of that, but there
are some problems. Only individuals are allowed to be members, not
companies or organizations. Those entities can sponsor KDE e.V., but they
get no vote. People can only become members of KDE e.V. by invitation,
which may leave out people new to the project at times. However, those requirements
(individual-only, invite-only) are necessary to protect the assets of KDE
e.V. as it is set up such that each member becomes a shareholder in the
One of the bigger problems that he sees with KDE e.V. is that it is "secret
by default". That leads to downgrades in the OGI score, but it also may
impression that the project is being run by a secret cabal. It is often
said that KDE e.V. makes "no important decisions", but he doesn't agree.
Akademy was held in Estonia because KDE e.V. decided it would be, for
example, and the organization decides on who gets funding for things like
sprints as well. Böhm believes that the "secret by default" approach is
hurting the KDE community.
Some reflection on the role of commercial contributors is also needed.
Currently, there are only individual contributors, mostly volunteers. That
can be contrasted with Android, where there are few or no volunteers. But
in order to use all of the available effort, there needs to be some thought
about how to involve
companies in the community. KDE is just about the only
community where companies have no voice, he said, which is "not all
it may be part of why KDE is still around after all these years.
That is "enough reflection", Böhm said, and proceeded to outline some
proposed actions to rectify some of the problems he observed. First off, he
would like to see KDE stop sticking its head in the sand and try to
address problems that crop up. Every year at Akademy, it would be good to
see improvements in the areas that have been identified. For example, he
proposed that there be a corporate liaison for KDE e.V. to work with
companies. He also proposed that users get a voice. There is a KDE
e.V. user working group that is being formed, but it should be made more formal
in order to give users some say.
The Community Code of Conduct
should also be extended, he said. It currently lists the responsibilities
of contributors, without covering the rights of contributors. Those two
things "normally go hand in hand". Contributors' rights would cover things
like the ability to influence development, which is something that is not
true for companies that contribute today.
The right to be treated as an
"equal among peers" is another right that should be enumerated. Currently,
there is something of a divide between technical contributors and
non-technical contributors that could be addressed by this right.
There is an overall need to minimize discrimination within the community between
various sub-groups: technical vs. non-technical, volunteer vs. companies,
users vs. contributors vs. KDE e.V members, and so on.
He also proposed that KDE e.V. adopt an "open by default" approach. Always
defaulting to secret discussions on a closed mailing list, even for topics that
have no need for secrecy, results in less open governance. That is bad for
KDE, he said. Next year at Akademy, he hopes to have a similar talk, but
one that looks at what has been accomplished in these and other areas.
Well-organized, interesting, and fun
Overall, Akademy was very well done. The talks were engaging, and the
location was stunning. It is always nice to get a feel for what is
happening in a large development project like KDE, and Akademy provided a
great way to do that. KDE is a vibrant project and its conference
reflected that. Once again, thanks to KDE e.V. for travel assistance so
that I could go and have an interesting—and fun—trip to Tallinn.
Comments (1 posted)
Page editor: Jonathan Corbet
Next page: Security>>