Working together for standards The Web Standards Project

You’ve heard it’s coming in 2012. Or maybe 2022. It’s certainly not ready yet, but some parts are already in browsers now so for the standards-savvy developers, the future is worth investigating today. Ian “Hixie” Hickson, editor of the HTML 5 specification, hopes that the spec will go to Last Call Working Draft in October this year.

Accessibility Task Force member, Bruce Lawson, interviews Hixie on how the specification for the next generation of the Web’s markup language is shaping up. Disclosure of affiliations: both work for browser vendors—Bruce for Opera, Hixie for Google (and previously, Opera and Netscape).

Bruce

The spec now known as HTML 5 began with a "guerilla" group called WHATWG. How and why did the WHATWG begin?

Hixie

The short answer is the W3C told us to.

The long answer: Back in 2003, when XForms was going through its final
stages (the "Proposed Recommendation" vote stage), the browser vendors
were concerned that it wouldn’t take off on the Web without being made a
part of HTML, and out of that big discussion (which unfortunately is
mostly hidden behind the W3C‘s confidentiality walls) came a proof of
concept showing that it was possible to take some of XForms’ ideas and put
then into HTML 4. We originally called it "XForms Basic", and later renamed
it "WebForms 2.0". This formed the basis of what is now HTML 5.

In 2004, the W3C had a workshop, the "The W3C Workshop on Web Applications
and Compound Documents", where we (the browser vendors) argued that it was
imperative that HTML be extended in a backwards-compatible way. It was a
turning point in the W3C‘s history—you could tell because at one point
RedHat, Sun, and Microsoft, arch-rivals all, actually agreed on something,
and that never happens.

The outcome of that workshop was that the W3C concluded that HTML was
still dead, as had been decided in a workshop in 1998, and that if we
wanted to do something like HTML 5, we should go elsewhere. So we announced
a mailing list, and did it there.

At the time I was working for Opera Software, but "we" in this case was
Opera and Mozilla acting together (with Apple cheering us from the
sidelines).

Bruce

How did you become editor?

Hixie

I was at the right place at the right time and everyone else was too busy.

Bruce

How do you personally go about editing the spec and incorporating
feedback? What are your processes?

Hixie

This has varied over the years, as we’ve gone from a nascent organisation
with a few dozen people to a well-established project with a mailing list
with 900+ subscribers. Mostly it’s all down to managing e-mail. When
someone writes feedback on the spec, whether by sending an e-mail to one
of the mailing lists I’m on, or by blogging somewhere, or twittering, I
log their feedback in a folder on my IMAP server. Feedback gets
categorised into either feedback I can work on right away, or feedback
that I can’t deal with yet for whatever reason. An example of the latter
would be requests relating to mutation events, because I’m waiting for
DOM3 Events to update how mutation events work.

Then, I just go through all the feedback I have, e-mail by e-mail, more or
less in the order that I received them, sending replies and fixing the
spec to address the issues that were raised.

This has some disadvantages, for example there’s a big delay in between
when someone spots an error and when I fix it. It also has some really
important advantages. If I respond to feedback on something I wrote
straight after writing it, I sometimes find that I have an attachment to
that section, so if someone suggests a total replacement, I tend to not
like their idea. But if I have a delay, I find my attachment has gone
away, and I’m eager to replace my old stupid idea with their better one.
(Assuming it’s better, anyway!)

Bruce

What’s the hardest thing to do?

Hixie

There are a few things that are hard. One is saying "no" to people who have
clearly spent the time to come up with a good idea. The sad truth is that
I reject almost everything that I and anyone else thinks of, because if I
didn’t, the spec would be a thousand times more bloated than it is now. We
get proposals for all kinds of things, and we have to have a very high bar
for what goes in. There’s also the danger that if we add too many things
to the spec too quickly, the browser vendors will each implement their own
bit and it’ll be a big mess that won’t help Web authors.

So I have to make judgements about what is worth adding and what isn’t,
and that’s hard. I’ve upset a lot of people by rejecting their ideas,
because they take it personally. On the other hand, some of the most
productive members of the community now are people who’ve had many of
their ideas rejected, but they stuck around long enough to see a few of
their ideas make it in. The best way to get an idea into the spec is to
find something in the spec that’s just clearly wrong, which is something
that a lot of the most active people do a lot, too!

Something else that’s hard is making up new features. The bulk of HTML 5 is
actually just defining how browsers already do things, which, although
complicated and sometimes unbelievably arcane, is, at the end of the day,
pretty easy to spec: you test the browsers, and you write what they do.
Rinse, repeat, until the spec covers every possible case.

Making up new features, though, means actually thinking about what should
happen, what is the most understandable solution, figuring out how things
should fit together, and so on. It’s often tempting to make something that
is theoretically neat, but which doesn’t fit in with the rest of the
language, too. After all, that’s where all this came from—we don’t want
to create a new XForms, a really well-designed technology that doesn’t fit
into the way people write pages.

What’s in the spec?

Bruce

You’ve said that HTML 5 is in "direct competition with other technologies intended for applications deployed over the Web, in particular Flash and Silverlight". Why is it so important to do so, and isn’t it a lost cause given that those techologies are already out there while HTML 5 is not yet complete?

Hixie

HTML 4 is also in direct competition with proprietary technologies, and
it’s winning, hands-down. HTML5 is just continuing the battle, because if
we don’t keep up, then the proprietary technologies will gain ground.

Bruce

What are the main philosophies of HTML 5?

Hixie

Backwards-compatibility, incremental baby steps, defining error handling.
Those are the main philosophies.

Bruce

What else did WHATWG try to achieve with this new iteration of HTML?

Hixie

We started from trying to put features from XForms into HTML 4, and we
quickly also took the opportunity to fix some of the things in HTML 4 that
were either too vague or disagreed with reality (that is, where the
browsers all did one thing but the spec said another). It turns out that HTML 4 is so vague that this is a pretty big task—it even involved
defining the whole HTML parsing model, including error handling, which is
a huge job (it took me the better part of a month to write the first
draft, and we were tweaking it for about a year before it become more or
less stable).

Something else we’ve tried to do is make things simpler. We’ve simplified
the syntax (e.g. the rules about what can be quoted, what strings are
valid ids, etc, are much simpler now). We’ve made things which people
used to do in JavaScript have shortcuts, so now you can just say autofocus="" to focus a form field when the page loads, instead of using control.focus(), which allows the browser to do clever things like not
actually focus the control if the user is already typing elsewhere.

Bruce

Does HTML 5 legitimise tag soup? Does "paving the cowpaths" perpetuate
bad markup?

Hixie:

No, HTML 5 actually makes the rules for markup even stricter than HTML 4 in
many ways, both for authors (the rules are simpler, but stricter, than HTML 4′s) and for implementers (gone are the days where they can just do
whatever they want when handling parse errors, now every browser has to
act the same).

Hopefully, we’ve managed to make the rules on what is valid syntax more
understandable, which should help with getting more good markup. We’ve
also made it possible to write clearer validators, so I have high hopes.

Bruce

Does including JavaScript and DOM APIs in the HTML 5 spec dilute the
message about separating behaviour and structure?

Hixie

I didn’t know about a message about separating behaviour and structure, I
must have missed that memo! HTML 5 takes a pretty hard line on separating
style and presentation from structure and semantics; there are no more font tags. Separating the logic and behaviour from the structure and
semantics of an HTML document isn’t as important, generally, as far as I
can tell.

The main advantage of defining the HTML DOM APIs and the HTML elements in
the same specification is that we don’t let stuff fall through the cracks.
In practice, browsers implement the HTML elements as DOM nodes, there’s no
difference. When we separate the two in the specs, therefore, we introduce
a conceptual gap where there isn’t one in reality. The DOM2 HTML spec, for
instance, doesn’t say what happens when you change the type attribute of
an input element from text to checkbox on the fly, and the HTML 4
spec doesn’t mention that changing attributes on the fly is possible, so
in the HTML 4 / DOM2 HTML era, there’s a big hole there. In HTML 5, this is
all defined together, so we can tighten this up and make sure there are no
gaps.

Bruce

Why no native support for microformats/ RDFa in HTML 5?

Hixie

Microformats is natively supported in HTML5, just like it was in HTML 4,
because Microformats use the built-in extension mechanisms of HTML.

We considered RDFa long and hard (in fact this is an issue that’s a hot
topic right now), but at the end of the day, while some people really like
it, I don’t think it strikes the right balance between power and ease of
authoring. For example, it uses namespaces and prefixes, which by and
large confuse authors to no end. Just recently though I proposed something
of a compromise which takes some of RDFa‘s better ideas and puts them into HTML 5, so hopefully that will take care of the main needs that caused
people to invent RDFa. We’ll see.

About browsers

Bruce

Do the browser makers have too much influence on the spec?

Hixie

The reality is that the browser vendors have the ultimate veto on
everything in the spec, since if they don’t implement it, the spec is
nothing but a work of fiction. So they have a lot of influence—I don’t
want to be writing fiction, I want to be writing a spec that documents the
actual behaviour of browsers.

Whether that’s too much, I don’t know. Does gravity have too much
influence on objects on earth? It’s just the way it is.

Bruce

One of the chairs of the W3C working group is a Microsoft employee. Is that giving too much power to one browser vendor, or a good thing,
given that Microsoft’s browsers still dominate and their buy-in on any spec is
therefore essential?

Hixie

Personally I would like Microsoft to get more involved with HTML 5. They’ve
sent very little feedback over the years, far less than the other browser
vendors. Even when asking them about their opinion on features they are
implementing I rarely get any feedback. It’s very sad. If I e-mail them a
question about how I can best help them, I usually get no reply; at best
I’ll get a promise that they’ll get back to me, but that’s it.

Accessibility

Bruce

There has been a lot of spirited debate (ahem) about accessibility in
the development of HTML 5. How does the spec deal with the requirements
of people with disabilities?

Hixie

Universal access—the requirement that anyone be able to use information
on the Web—is a fundamental cornerstone of HTML‘s design, just like
security, privacy, and so on. In general, we try to design features so
that they Just Work for everyone, regardless of how you are accessing the
Web. For example, in HTML 5 we’ve added new input controls like calendars.
These will Just Work with screen readers once browsers support them,
authors don’t have to do anything special.

Bruce

Does your personal support of humanitarian eugenics affect your opinion of giving
extra "help" for people with disabilities?

Hixie

You’ve been reading too much of our pet troll’s blog! ;-)

[Bruce's note: this refers to Mr Last Week, mysterious author of the blog Last Week in HTML 5, which lampoons the HTML 5 Working Group in very funny, frequently foul-mouthed manner.]

People with disabilities are just as important to me in my work on HTML 5 as is anyone else.

Bruce

You wrote to ask screenreader vendors to participate in
the specification process. Did they ever reply?

Hixie

A couple did, but only to say they had little time for the standards
process, which was quite disappointing. Since then, though, Apple has
ramped up their efforts on their built-in Mac OS X screen reader software,
and we do get a lot of feedback from Apple. So at least one screen
reader vendor is actively involved.

Bruce

HTML 5 and WAI-ARIA appear to do the same thing in some places.
How should developers handle this?

Hixie

When there’s a built-in way to do something, using that is the simplest
and most reliable solution. So for example, if you want to have a
checkbox, using the input element with its type attribute set to checkbox is the simplest solution—it’ll work for everyone, with or
without JavaScript, with or without a screen reader, and so on. ARIA is
useful when HTML doesn’t let you do what you want and you find yourself
hacking around with many nested divs, scripting your own controls and so
forth.

Bruce

Can we expect ARIA-specific constructs which have no equivalent in HTML 5, such as live regions, to be allowed under the rules of HTML 5 so it will all validate?

Hixie

Yes, the plan is to make sure ARIA and HTML5 work well together. Right now
I’m waiting for ARIA to be complete (there are a number of last call
comments that they haven’t yet replied to), and for the ARIA
implementation rules to be clearer (it’s not yet obvious as I understand
it what should happen when ARIA says a checkbox is a radio button, for
instance). Once that is cleared up, I expect HTML 5 will give a list of
conformance criteria saying where ARIA attributes can be used and saying
how they should be implemented in browsers.

Why, when, how, who?

Bruce

Why would we content authors want to move to HTML 5? What’s in it
for us?

Hixie

Today is probably too early to start using HTML 5.

Long term, content authors will find a variety of new features in HTML 5.
We have a bunch of new structural elements like section, article, footer, and so on. We have new elements for embedded media, like video and audio. We have new input controls, like the calendars I mentioned,
but also fields for URLs, e-mail addresses, telephone numbers, and for
color selection. We have control over autocomplete values in text fields,
as well as field validation so that you can say which fields are required.
We have context menus, pushState() so you can update the URL in Ajax
applications, and offline application cache manifests so that your users
can take your applications offline. The list goes on.

There’s also the benefits that come from using an HTML 5 validator. HTML 5
is much more precise about many things than HTML 4, so the validators will
be more useful in catching real errors. The embed element is no longer
invalid.

Bruce

Are there advantages for end-users, too?

Hixie

A more powerful HTML means more powerful Web applications. Just like XMLHttpRequest resulted in more interactive apps, HTML 5 will result in
a richer and more consistently reliable experience. I hope!

Bruce

What’s the the timeline? When can we start using HTML 5?

Hixie

The plan is to have the spec mostly finished by October 2009. A lot
depends on the browser vendors, though. I don’t know when things will be
implemented widely enough that authors can use them reliably everywhere.
Some features, like canvas and video, are getting implemented in most
browsers as we speak. Others will take longer.

Bruce

What can standards-savvy WaSP readers do to get involved with the specification process?

Hixie

There are a number of ways of taking part. What we need most of all these
days is technical review of the specification text, calling out places
where I screwed up, where the spec defines something that’s not easy to
use for Web authors, where the spec contradicts itself, typos, spelling
mistakes, grammar errors, errors in examples, you name it.

I posted a blog entry recently detailing how people can send feedback. You can join the W3C HTML Working Group or the WHATWG. There are also lots of other things people can do—write demos, write tutorials, edit other related specs, write articles introducing parts of
the spec on the blog, write test cases… Anyone who wants to help out but doesn’t know where to start should drop
me an e-mail at [email protected].

Bruce

Will there ever be an HTML 6, or is it a convenient fiction to park
out-of-scope discussions?

Hixie

I’m sure there will be an HTML 6, and 7, and 8, and probably many more,
until someone comes up with something so radically better that we stop
evolving the Web as we know it.

I expect work on HTML 6 will start even before HTML 5 is completely done, in
fact. Putting the finishing touches on HTML 5 will be a long and tedious
job involving writing a massive test suite. HTML 4 never had a serious test
suite created (it was too vague as a specification to really be properly
tested), so we have to start from scratch with HTML 5. The HTML 6 team will
at least be able to build on what we’ve done with HTML 5, I’m jealous!

Actually if it was up to me, after HTML 5 I would probably transition HTML to an incremental model. Once we have a basic spec that is well-defined
and has been proven, instead of releasing a frozen snapshot every few
years, I’d prefer a model where we can slowly evolve the language, call it
"HTML Current" or something, without having to worry about versioning it.
To some extent that’s what we’re doing with HTML 5, but I think formalising
it would really help.

Having versions of specs doesn’t make sense when you have multiple
implementations that are all evolving as well. No browser is ever going to
be exactly HTML 5, they’ll all be subsets or supersets. So why bother with
versioning the spec?

It’s a very unusual idea in the standards world, so I don’t expect us to
do this. But I do think it’d be the best way forward.

Bruce

Would you like to be the HTML 6 editor?

Hixie

Too early to tell! It’s been a lot of fun working on HTML 5, it’s quite
challenging and you have to deal with all kinds of issues from the deeply
technical to the highly political. I might want a change of pace when
we’re done with HTML 5, though.

Bruce

What’s your fave feature that didn’t get into HTML 5 that you’d put
into HTML 6?

Hixie

In-window modal dialogs or dialog box—the kind of prompt you get when the
computer asks you a question and won’t let you do anything else until you
answer the question. For instance, the window that comes up when you say
"Save As…" is usually a modal dialog.

Right now people fake it with divs and
complicated styles and script. It would be neat to just be able to say
"make this section a modal dialog". Like showModalDialog(), but within
the page instead of opening a new window with a new page.

I’d add it to HTML 5, but there are so many new features already that we
need to wait for the browsers to catch up.

Bruce

Finally, is it true that you and Mr Last Week are the same person, like Edward
Norton and Brad Pitt in "Fight Club"?

Hixie

Oh, no. Our pet troll is a phenomenon all to himself.

Bruce

Thanks for your time.

Your Replies

#1 On May 13th, 2009 8:42 am Keith replied:

It would be funny if it were to come out in 2012, on the day before the end of the world.

#2 On May 13th, 2009 9:55 am Phil Houghton replied:

I think if we’re talking about conflating structure and behaviour then surely we’re already in the realm of redefining what we mean by “Hyper-Text” and therefore should be defining the spec as something other than HTML?

The concept of paving the cow path is a most welcome one but perhaps we need to recognise that the cows have been trampling over the idea of a simple online document format for years now and signpost the paving with something that reaches beyond that idea. (While allowing for an underpass for the hedgehogs of simple semantics!)

#3 On May 13th, 2009 10:32 am John Dowdell replied:

“If we don’t keep up, then the proprietary technologies will gain ground.”

Try speaking without the label “proprietary”, and instead describe the specific outcomes you fear so much, that you will sacrifice HTML’s practicality in return.

I don’t think that a variety of slowly-updated browser brands can realistically provide content creators and consumers with the same reliable functionality that a common cross-browser extension can. And yet there is talk of war, of fighting rather than cooperation. Something is wrong at a very deep level there.

I want to see Flash continue to provide all browsers with identical high-end functionality, uniting audiences for content developers, innovating fastest while enfranchising all browser choices. The browsers actually “gain ground” when Flash does.

jd/adobe

#4 On May 13th, 2009 11:06 am Jason Grant replied:

This is a very useful contextual insight into HTML5 and its progress.

Writing the spec for it must be a very energy consuming matter, so all respect to Hixie for working on it.

#5 On May 13th, 2009 3:31 pm Stephane Deschamps replied:

@John Dowdell: I would say it’s one of the main problems with the web. Most clients/projects don’t see that one of the most interesting uses of Flash and HTML is exactly that: a mix of both, a hybrid thing (think Google Finance here, think EasyYouTube).

Using tools for what they’re good at and mixing them in the process is not that common. So at the end of the day people fight a fight of “I want HTML” – “no, I want Flash”. So HTMLers resolve to be radical and tell projects and clients that it’s either one or the other, because most of the time you eiher have a good Flash artist or a good HTML developer, but not both for budget questions etc.

At the end of the day, though, I’ll always find HTML more reliable than Flash. I don’t have a machine too powerful, or a big broadband connection. I *do* surf with Flash sometimes, never without HTML.

#6 On May 13th, 2009 4:10 pm Ian Hickson replied:

@Phil Houghton: Actually the HTML5 spec was originally called “Web Applications 1.0″ (you can see the remnants of this in the URL to the spec: http://www.whatwg.org/specs/web-apps/current-work/multipage/). The name changed when the W3C changed their minds and asked us to work with them again.

#7 On May 13th, 2009 5:31 pm Matt Robin replied:

So that’s October this year. Maybe, perhaps, if the browser vendors are up to speed on it. So it might not be October then, HTML 6 possibly to start in development…

Good interview because I think it nicely clarifies HTML 5′s status at the moment.
I liked the bit about ‘showModalDialog()’ – that actually does sound good/useful.
I also favour the ‘HTML Current’ naming suggestion, versioning has always been a bit clunky for something as broadly-used as the Web (although that might not have been anticipated when first specs of HTML were originally being written of course!)

Here’s to October then! :)

#8 On May 14th, 2009 12:38 pm EM replied:

@John Dowdell: I fear what has already happened — lock-in to whichever vendors Adobe decides to support. I fear a terrible Flash plugin on Linux that crashes my browser all the time. I fear not being able to use Flash on computing devices of the future unless Adobe decides they aren’t against Adobe’s interests.

#9 On May 15th, 2009 11:40 am WaSP Member blawson replied:

There’s an article by John Dowdell of Adobe that takes issue with Hixie’s statements that’s worth a read: Building upon untested assumptions.

#10 On May 15th, 2009 12:55 pm Rimantas replied:

I still hope to see the day the Flash dies.

#11 On May 15th, 2009 5:51 pm John Dowdell replied:

To “EM” (of the closed identity ;-)

You fear things which have not happened, and which (considering history of PostScript, PDF, and SWF) are not likely to happen. Such theoreticals are difficult for others to meaningfully address.

Like HTML, Flash Flex and AIR enfranchise Linux use. It’s not an iTunes “control” type of model. I’d urge you to reconsider your fears.

jd/adobe

#12 On May 22nd, 2009 12:09 pm Jethro Larson replied:

Regarding RDFa: I agree on XML namespaces being confusing. They’ve been a source of endless problems in my experience. They’re one of the last things that turn XML from a human-readable language into something far more sinister.

#13 On May 26th, 2009 2:00 pm Max Howell replied:

Proprietary technologies evolve fastest. They react to the market. They erupt forwards and improve things, in general.

After a while though, a proper, thought out, standards driven replacement can emerge. And it will be better than the rapidly developed, almost-designed, proprietary product it replaces.

Flash has served us well. And thanks for that. But the web will now evolve quicker with some parts replaced by HTML 5.

I suggest, John Dowdell, you start looking to the next thing that you can advance the web with.

#14 On May 26th, 2009 3:06 pm Stefanie replied:

I never knew that Ian is into eugenics. How sad.

But thinking of himself as an “benevolent dictator” it shoudn’t have surprised me.

#15 On May 26th, 2009 4:24 pm Hamranhansenhansen replied:

> I think if we’re talking about conflating
> structure and behaviour

Structure and behavior is already conflated in HTML 4. You can separate them as much as you like in your own applications. HTML 5 is not forcing your hand either way.

> [Flash]

I started working with Flash in 1997 and it frustrates me that things I could do then easily in Flash are still either hard to do or basically impossible on the Web.

However, Flash is not now and has never been part of the World Wide Web. The Web is an application of the Internet, same as Flash. They’re peers. The browser and Flash Player are 2 separate apps pretending to be one because Windows still doesn’t have its own MPEG-4 player.

WebKit is just a few megabytes, and it runs on Intel, PowerPC, and ARM with industry-leading performance. And it’s free and open source and used by Apple, Google, Nokia, Blackberry, Palm, and others. Mobiles have MPEG-4 decoder chips. There is no need for Flash on mobiles. If there was, it would already be there.

#16 On May 27th, 2009 10:09 am Sandra replied:

Flash is a “common cross-browser extension”? Sure, a common, non-free implementantation (with variants and ports between browsers and platform).

If Gnash or other non-Flash flash implementations were to take off, we’d see the same slowdown as between browser implementors today.

I don’t have Flash installed. I will install a good HTML 5 implementation.

I don’t want to lock my works in a platform that’s basically controlled by a single restricted-use, restricted-modification implementation. If Flash were DSFG-free, it’d be back in the running.

#17 On May 30th, 2009 5:27 pm Dominic Shiells replied:

With the spec is there any examples of the code to see how it is used in a practical format!
Dom

#18 On June 4th, 2009 8:49 am Schoschie replied:

Dammit, now you spoiled Fight Club for me.

#19 On June 27th, 2009 5:59 am Christian replied:

The main thing that I miss about HTML5 is extensibility. Everything is either baked in and bloats the main spec or has to rely on clumsy, underspecified class-attribute hacks.

XML may not be perfect and the convention of using URLs as namespace identifiers must have created confusion without end. But at least XHTML has an extension mechanism – only that Microsoft never started supporting it. Why is there no consideration to do something similar with non-XML HTML5? Is using divs with strange attributes really better than using additional vocabularies in HTML? (RDFa is also a hack in this respect IMO, but at least it can accomodate extension vocabularies in a decentralized and conflict-free fashion. Before tossing that out of the window, an attempt should be made of doing namespaces in a clearer fashion, if URNs are considered to be too complicated).

I really don’t understand this whole aspect of HTML5. Yes, the W3C XHTML stuff was over-engineered and sometimes far away from reality. Yes, they put the bar a bit too high and so the transition never happened.

But baking every possible use case into one core vocabulary won’t do either.

#20 On June 28th, 2009 8:18 am Yazgunu replied:

I still hope to see the day the Flash dies.

#21 On July 4th, 2009 11:59 am joooc replied:

I like the idea of non-version HTML standard. A lot of web apps doesn’t use versions anymore (they just simply update on the run).

However I’m scared about possible mess generated by various browsers and their implementation of the most recent rules … on the other hand it should be less work to do it step by step so they can better react … sounds interesting.

Looking forward for my first HTML 5 valid web page ;-)

#22 On July 9th, 2009 11:16 pm Bevan replied:

Nice Interview, great sharing about HTML

Bevanwistar

#23 On July 11th, 2009 4:54 pm Proxy replied:

Sounds useful, i´ll try the new specification. What about XHTML? Will core elements of XHTML get integrated into HTML 5 specs?

#24 On August 6th, 2009 6:05 am Goyax replied:

It is very important that the new standard and the team behind it (for example the Microsoft employee sitting on one of the chairs of the W3C) is able to connect browser vendors more and involve them that far, so web-developpers are not forced anymore to keep an eye on every single browser implementation. The success of the www is that all applications in it (talking about applications means even a simple html-only-page) are usable on so many diffenrent devices and operating systems. Eliminating differences between the browser implementations will speed up the evolution of the www.

Return to top

Post a Reply

Comments are closed.