The CSS working group meeting is now over, and so I've now flown
over to the bay area for the workshop. I'm
staying at dbaron's, who
kindly offered to let me use his couch. We have both been asked to
give short presentations at the workshop next week, so I've been
thinking about some things to help underscore our point about how
backwards compatibility is a requirement, at least for solutions that
are to come in the near future.
I think the best way to explain it is to use examples.
CSS2
Look around the Web. What parts of CSS2 are used? (Not counting
those that were already in CSS1.)
The answer is "absolute positioning". Pretty much none of the
other new features from CSS2 are used. Why? Because of those new
features, pretty much only absolute positioning is supported by
Windows IE6.
Many sites still use HTML table elements for layout. Why? Because
the CSS2 table model isn't supported by Windows IE6. Authors often
ask how to do things like fixed positioning, but lose interest when
they are told Windows IE6 does not support them.
XHTML
Many pages on the Web claim to be XHTML (according to their
DOCTYPE) but they are almost all sent as text/html
instead of the more correct application/xhtml+xml,
despite all browsers except Windows IE6 supporting the latter.
PNG
Authors use PNG. Authors don't often use PNGs with eight bit
alpha channels. Windows IE6 only supports PNG that don't have eight
bit alpha channels. Authors frequently ask how to use semi-transparent bitmaps with their site designs, but again lose interest when told that Windows IE6 won't render them correctly.
Flash is frequently used on the Web
Windows IE6 ships with a binary plugin for rendering Macromedia
Flash files. Flash is very widely used on the Web, especially for
application-like content, in particular games and interactive
multimedia.
SVG is rarely used on the Web
Windows IE6 does not ship with a binary plugin for rendering SVG
files, although one is available at no cost. SVG is rarely used on
the Web, at least compared to Flash.
Non-standard features
Many pages depend on features that aren't in the
specs, but are implemented in IE, despite the features being
available in the specs using other methods, and despite those other methods being implemented in
IE. For example,
document.all is used all over the place despite its
standards-compliant equivalent getElementById being
implemented in Windows IE6.
Similarly many pages use offsetTop,
innerHTML, and the like, which has forced other browser
vendors to implement support for those features.
I think these examples demonstrate quite strongly the need for any
successful solution to be one that can be deployed in Windows IE6.
Adding new functionality to Windows IE6 without using binary plugins
is quite possible, as demonstrated by the quite impressive IE7 project.
The long term solution would be to move users from the dead IE
platform and the proprietary Windows platform to the actively
developed, open, and standards-based alternatives. Once users are
using products with (relatively) rapid update cycles, it will be
possible to introduce more radical new technologies, and expect to see
them adopted by authors.
However, moving users to a different platform is an entirely
different problem than providing authors with new technologies. Users
use Windows because vendors use Windows as their default operating
system. Users use Windows IE6 because Windows uses IE6 as its default
Web browser. Very few users ever change either of these, much like
very few users ever change their preferences, mostly because they
simply are not aware that the alternatives exist.
Therefore before we can create a long term solution for authors
developing Web applications we need operating system manufacturers and
Web browser manufacturers to significantly step up their marketing
campaigns and significantly increase the effectiveness of their
lobbying of vendors. Until that happens, there is not much point
inventing new languages, since they won't be used in the near future,
and will probably no longer be adequate when they can be.
However, in the meantime, authors still want to write Web
applications, and the currently deployed standards are inadequate.
Since completely new standards won't cut it (as discussed above); this
leaves us with the solution we (Opera and Mozilla) have been
advocating: updating HTML and the DOM.
It's that time of year again. The quarterly trip. This time I'm
going first to Boston for the May 2004 CSS working group face-to-face,
and then on to the bay area to eat Grandma's Especial and (probably
more to the point) to attend a workshop on Web Applications and
Compound Document.
A pretty standard trip: an SAS flight from Oslo to London Heathrow
on a 737-800 (with, as most of the SAS fleet, a small poem-like
writing at the entrance: On a round planet, / your destination /
will always / bring you home) followed by the normal paperwork at
Heathrow before boarding the 777 to take me to Boston.
Heathrow is such a mess. Seriously. Imagine one of those science
fiction movies where the city is dark and bustling with non-descript
industrial activity: things barely working due to a long slide into
disrepair, kept working by patching as little as possible, as cheaply
as possible. Corridors lead nowhere; derelict equipment lies unused in
passenger waiting lounges; "temporary" structures have become part of
some of the permanent structures; toilets are concealed behind load
bearing columns that look as if they were added as an afterthought
during construction (or even later) when the building threatened to
collapse (mind you, given recent events, I suppose that could be
worse); signs clarify other signs; the public announcement system
regularly informs passengers that everyone else in the terminal is
intent on stealing their baggage, or maybe giving some to them, and
that one must thus be vilgilant at all times... When we landed we had
to actually step onto the runway to get into the terminal because for
some reason our gate had no extending arm thingy.
It continuously amazes me how the British can have such an
obsession with doing things cheaply. "Maintenance", in the
UK, seems to mean "repair", not "preventing failure". Things that are
functional are good enough. There was a television screen at our gate,
showing BBC News 24's coverage of some royal wedding or other. It was
a pretty good quality large widescreen plasma display with a
pseudo-surround-sound system. But of course the picture was delivered
via analogue cable, in 4:3 ratio and stretched to fit the 16:9 frame,
an affront to the televison's abilities (and to BBC News 24's
producers, since they have been broadcasting in 16:9 for years).
Anywhere else, the technicians would have refused to even install such
a system; a plasma TV needs a digital feed, not coax. In Britain? Coax
is cheaper.
While I'm whining, I think I'll transition smoothly to a critique
of Along Came Poly, one of the films we were provided
with on the American Airlines entertainment system. A mediocre movie,
which could have been saved by featuring more of one of the
characters, a ferret, but which unfortunately utterly failed to use
even a fraction of its potential.
First of all, I must emphatically point out that ferrets do
not sound like squeaky toys. They are in fact largely silent.
It's one of the features that makes them look so innocent and
mischievous at the same time. They make a sound when you step on them
or drop them (a kind of indignant "epp epp epp!") and occasionally let
out muted cries while fighting, but that's it.
Secondly they never stand still (except when they're looking at you
waiting for you to either feed them or play with them). If you put a
ferret in a harness on a leash and attach the leash to the door
handle, one of three things will happen within about twenty seconds.
First, and most likely, the ferret will somehow manage to get the
leash off the door handle and start exploring the surroundings,
especially any dark and inaccessible places. Second, less likely but
still quite common, the ferret will magically get out of its harness
and again start exploring. Don't ask how they manage to get out of
their harness. It is a perennial mystery. I'm not a ferret expert but
my understanding is that the leading theory is that they possess short
range teleporting technology of some sort. The third possibility is
that the ferret will begin exploring with the leash still attached to
the door handle, and, through climbing atop nearby boxes or through
nearby pipes, will manage to either entangle itself in a knot that
will take significant effort to undo, or will slip and end up dangling
in mid air. (I'm sure more ferrets get killed by curiosity than
cats.)
What will never happen is them just standing there
patiently waiting for whatever humans have in mind for them. So you
would never find a ferret sitting in the middle of a hallway.
Thirdly, ferrets don't run into walls. They run along walls. If
they find a wall, they run towards it then follow it to find out where
it leads. They follow walls almost as religiously as they explore
holes.
And finally, ferrets sleep. As far as I can tell most
ferrets spend no more than thirty minutes awake per day. No movie that
purports to show someone, whose first guess when he sees a ferret is
to think it is a rat, dating a ferret feeder (you don't own ferrets
anymore than you would own a cat), could possibly omit the line "do
these things do anything but sleep?". Well, I mean, obviously it
could, since this one did, but such an omission would always be a
major error.
I arrived in Boston having read about half of Peter F. Hamilton's
latest book, Pandora's Star. This is a nearly 900 page
book, part one of the Commonwealth Saga. I absolutely
loved his first saga, the Night's Dawn Trilogy. So far
this book is promising to be just as good.
Getting to Boston itself from the airport was quite easy, due to
convenient public transport. Unfortunately, Boston reminds me
of Heathrow. It's American, of course, so it's on a bigger
scale. But it has all the same features of looking temporary. A few
months ago I heard that The Big
Dig was complete, but it seems that they forgot to let the crew
know.
I went for a long two and a half hour walk around the city to see
what it was like. One of the most confusing things I came across was a
couple of big old iron pipes coming out of the ground and spewing
dirty steam. Why would there be steam underground? And why would you
want to release it all over the place?
For dinner, I had a burrito. Europeans don't know how to make
burritos. They try to serve them on a plate with garnishes, or with
the rice on the outside, or with sauce poured over the burrito. That
would be like serving a ploughman's lunch as individual parts around a
plate (mind you, I've had that done too). Burritos should be
self-contained. Just one big lump of goodness filling a
leak-proof yet edible wrapper.
It was a good burrito.
The next day, today, I woke up refreshed, watched Finding
Nemo on TV (Pixar rocks), then walked around Boston some more.
Some of us working group type people are planning to meet for dinner
tonight. In the meantime I think I'll sit down at Boston Common and
read my book.
The W3C is having a workshop on the
topic of Web Applications and Compound Documents in a few weeks, which
I will be attending. It looks like it could be fun.
Everyone who wants to attend had to write a position paper. We
(Opera) got together with our Mozilla friends to write ours —
you can see our
position paper on the position
papers page.
It was interesting to compare the papers that were submitted. A
large number of them suggested that the best basis for Web
applications was SVG, many of
the others suggested XForms.
Our own position was that any successful framework would
have to be backwards compatible with the existing Web
content, and would have to be largely implementable in
Windows IE6 without using binary plug-ins (for example using scripted
HTCs). We were the only ones to even remotely suggest that the
solution should be based on HTML.
It is going to be very interesting to see how this unfolds. For us
(the Web browser vendors: Opera, Mozilla, and Apple), the "backwards
compatible" requirement is not really negotiable, because it is quite
clear that solutions that don't work in the market leader's browser
won't be accepted by mainstream Web developers. I think a lot of
people in the W3C world are having difficulty accepting this,
especially given that Microsoft have basically said that IE has been
end-of-lined (it is my understanding that IE in the next version of
Windows will have no changes to its HTML/CSS/DOM/XML implementations
and still no support for XHTML, and Microsoft have also stated that
there will be no new separately-downloadable versions of IE available
anyway, so even if they did upgrade it, it would only be used by those
who upgraded their operating system).
It's almost sad, in a way. I was in a W3C meeting yesterday where
one of the participants said, in response to "well we have to be
backwards compatible with IE on this", something along the lines of
"what? I thought we could ignore IE now that Microsoft have said it
will no longer be developed".
Another theme I noticed in some of the other position papers was
the suggestion that the way to handle mobile devices (phones, PDAs)
was to make "mobile profiles": smaller versions of the specifications
that mobile vendors would implement in their devices.
This strikes me as rather fundamentally missing the point.
All these technologies are supposed to be
device-independent, so if they aren't suitable for mobile
devices, the problem is with the technology itself, not with the lack
of a profile. Having a profile merely results in a fragmentation of the Web
— instead of simply writing a Web document or application once
and having it run everywhere, it requires that authors decide what
devices they are going to target, and limits them to the features
those devices are supposed to support, or requires that they write
several different versions.
Opera is one of the few vendors to have a single solution that it
deploys across both the desktop world and the mobile world — if
something works in Opera on the desktop, then it will almost certainly
work in equivalent versions of Opera on small devices. (The
"equivalent versions" bit is unfortunately more relevant than one
might first think. The desktop version's rendering engine has in the
past been several versions ahead of the version usually used by
devices. We're working to reduce that gap, though.)
Having a single solution obviously means that we're always
concerned with implementability. If we can't fit the implementation
for a technology into our devices, then we won't implement it on the
desktop either. This was one of our major complaints about XForms
— it has so many dependencies (e.g. XPath) and reuses so few of
the technologies we already implement (e.g. JavaScript, HTML) that we
simply couldn't fit an implementation of XForms into our browser while
still being able to browse the Web.
Something else that we (Opera and Mozilla) mentioned in our
position paper was that we thought the development process for
Web application technologies ought to be completely open.
Mozilla obviously want this because they live in the Free software
world, where everything is done in the open, and where that policy has
reaped them many benefits (in fact the only other position paper to
mention that the process should be open was RedHat's,
presumably for the same reason). As far as Opera goes, we want an open
process because our experience with the Web Forms 2 work I've been
doing is that developing core Web technologies in the open is
far more productive than creating the technologies mostly
behind closed doors, getting input from the real world only every few
weeks or months.
In my opinion, the way to go for Web applications is the creation
of a public mailing list dedicated to the creation of extensions to
HTML and the DOM that address the needs of Web authors, and to have
someone edit a spec that brings the ideas that are discussed together.
A good start for this would be the Web Forms 2
and Server
Sent Events specs I've been writing.
My prediction: after the workshop, the W3C will set up a working
group to address Web applications. Their charter will be to create two
profiles that specify which parts of SVG and XForms should be
implemented and used on desktop computers and on mobile devices. There
will be a number of implementations from plug-in vendors, as well as
several standalone browsers that can host applications written to
these profiles. Books will be written, several industries will
announce their commitment to this technology, and a couple of
companies will be founded based around the business model of
supporting the technology in some way (e.g. providing authoring tools,
selling Web application browsers, or creating customised software to
convert applications written using these profiles to HTML+JS that can
be displayed in IE6). About ten years from now, the de facto Web
application standard will be Microsoft's Avalon and the .NET
framework. (See Microsoft's
position paper if you doubt that this is what Microsoft has
planned for us.)
Someone suggested to me recently that it would be
quite cool if there was a way in which servers could
dispatch DOM events straight into a Web page so that
script in the page could then react to them, updating
the page and so forth.
At the moment pages fake this by opening an
iframe to a page that the server keeps
open, slowly trickling script blocks
into it, and having the browser execute them as it
finds them.
This is pretty ugly, but it works. So here is a
proposal for a cleaner, declarative way to do this.
To specify an event source in an HTML document authors use a new
(empty) element event-source, with an attribute
src="" that takes a URI to open as a stream and, if the
data found at that URI is of the appropriate type, treat as an event
source.
The event stream MIME type is application/x-dom-event-stream.
The event stream is always be encoded as UTF-8. Line are always be
terminated by a single U+000A line feed character.
The event stream format is (in pseudo-BNF):
<stream> ::= <event>*
<event> ::= [ <comment> | <field> ]+ <newline>
<comment> ::= ';' <data> <newline>
<field> ::= <name> [ ':' <space>? <data> ]? <newline>
<name> ::= one or more UNICODE characters other than ':' and U+000A
<data> ::= zero or more UNICODE characters other than U+000A
<space> ::= a single U+0020 character (' ')
<newline> ::= a single U+000A character
The stream is parsed by reading everything line by line, in blocks
separated by blank lines (blank lines are those consisting of just
a single lone line feed character). Comment lines (those starting
with the character ';' not proceeded by any other characters) are
ignored.
For each non-blank, non-comment line, the field name is first
taken. This is everything on the line up to but not including the
first colon (':') or the line feed, whichever comes first. Then, if
there was a colon, the data for that line is taken. This is
everything after the colon, ignoring a single space after the colon
if there is one, up to the end of the line. If there was no colon
the data is the empty string.
Examples:
Field name: Field data
This is a blank field
1. These two lines: have the same data
2. These two lines:have the same data
1. But these two lines: do not
2. But these two lines: do not
If a field name occurs multiple times, the data values for those
lines are concatenated with a newline between them.
For example, the following:
Test: Line 1
Foo: Bar
Test: Line 2
...is treated as having two fields, one called Test with the
value Line 1\nLine 2 (where \n represents a newline), and one
called Foo with the value Bar.
(Since any random stream of characters matches the above
format, there is no need to define any error handling.)
Once the fields have been parsed, they are interpreted as follows
(these are case sensitive exact comparisons):
Event is the name of the event. For example, load,
DOMActivate, updateTicker.
Namespace is the DOM3 namespace for the event. For normal DOM
events this would be http://www.w3.org/2001/xml-events.
If it isn't specified the event namespace is null.
Class is the interface used for the event, for instance
Event, UIEvent, MutationEvent, KeyboardEvent, etc. If it
is not specified it is defaulted based on the event name as
follows:
If Namespace is http://www.w3.org/2001/xml-events or null
and the Event field exactly matches one of the events
specified by DOM3 Events in section 1.4.2 "Complete list of
event types", then the Class defaults to the interface
relevant for that event type.
For example:
Event: click
...would cause Class to be treated as MouseEvent.
If Namespace is uuid:755e2d2d-a836-4539-83f4-16b51156341f or
null and the Event doesn't match any of the known events,
then the RemoteEvent interface (described below) is used.
Otherwise, if the UA doesn't have special knowledge of which
class to use for the given event in the given namespace, then
the Event interface is used.
Bubbles specifies whether the event is to bubble. If it is
specified and has the value No, the event does not bubble. If
it is specified and has any other value (including no or
No\n) then the event bubbles. If it is not specified it is
defaulted based on the event name as follows:
If Namespace is http://www.w3.org/2001/xml-events
or null and the Event field exactly matches one of the events
specified by DOM3 Events in section 1.4.2 "Complete list of event types", then whether
the event bubbles depends on whether the DOM3 Events spec specifies
that that event should bubble or not.
For example:
Event: load
...would cause Bubbles to be treated as No.
Otherwise, if the UA doesn't have special knowledge of which
class to use for the given event in the given namespace, then
the event bubbles.
Cancelable specifies whether the event may have its default
action prevented. If it is specified and has the value No, the
event may not have its default action prevented. If it is
specified and has any other value (including no or No\n)
then the event may be cancelled. If it is not specified it is
defaulted based on the event name as follows:
If Namespace is http://www.w3.org/2001/xml-events
or null and the Event field exactly matches one of the events
specified by DOM3 Events in section 1.4.2 "Complete list of event types", then whether
the event is cancelable depends on whether the DOM3 Events spec
specifies that that event should be cancelable or not.
For example:
Event: load
...would cause Cancelable to be treated as No.
Otherwise, if the UA doesn't have special knowledge of which
class to use for the given event in the given namespace, then
the event may be cancelled.
Target is the element that the event is to be dispatched on.
If its value starts with a # character then the remainder of
the value represents an ID, and the event must be dispatched on
the same node as would be obtained by the getElementById()
method on the ownerDocument of the event-source element
responsible for the event being dispatched.
For example,
Target: #test
...would target the element with ID test.
If the value does not start with a # but has the literal value
Document, then the event is dispatched at the ownerDocument of
the event-source element responsible for the event being dispatched.
Otherwise, the event is dispatched at the event-source element
itself.
Other fields depend on the interface specified (or possibly
implied) by the Class field. If the specified interface has an
attribute that exactly matches the name of the field, and the
value of the field can be converted (using the type conversions
defined in ECMAScript) to the type of the attribute, then it
must be used. Any attributes (other than the Event interface
attributes) that do not have matching fields are initialised to
zero, null, false, or the empty string.
For example:
; ...some other fields...
Class: MouseEvent
button: 2
...would result in a MouseEvent event that had button set to
2 but screenX, screenY, etc, set to 0, false, or null as
appropriate.
If a field does not match any of the attributes on the event, it
is ignored.
Once a blank line is reached, an event of the appropriate type is
synthesized and dispatched to the appropriate node as described by
the fields above. No event is dispatched until a blank line has
been received.
The RemoteEvent interface is defined as follows:
interface RemoteEvent : Event {
readonly attribute DOMString data;
void initRemoteEvent(in DOMString typeArg,
in boolean canBubbleArg,
in boolean cancelableArg,
in DOMString dataArg);
void initRemoteEventNS(in DOMString namespaceURI,
in DOMString type,
in boolean canBubbleArg,
in boolean cancelableArg,
in DOMString dataArg);
};
Events that use the RemoteEvent interface never have any default
action associated with them.
The event-source element may also have an
onevent="" attribute. If present, the attribute is
treated as script representing an event handler registered as
non-capture listener of events with name event and
the namespace uuid:755e2d2d-a836-4539-83f4-16b51156341f
or null, that are targetted at or bubble through the element.
The following event description, once followed by a blank line:
Event: stock change
data: YHOO
data: -2
data: 10
...would cause an event stock change with the interface
RemoteEvent to be dispatched on the event-source element, which
would then bubble up the DOM, and whose data attribute would
contain the string YHOO\n-2\n10 (where \n again represents a
newline).
This could be used as follows:
<event-source src="http://stocks.example.com/ticker.php" id="stock">
<script type="text/javascript">
document.getElementById('stock').addEventListener('stock change',
function () {
var data = event.data.split(' ');
updateStocks(data[0], data[1], data[2]);
}, false);
</script>
...where updateStocks is a function defined as:
function updateStocks(symbol, delta, value) { ... }
I've never written any Flash content, or, as far as I can recall, ever used Flash on any of my sites, and I don't even have the Flash plug-in installed here, since Flash is a proprietary language and thus inherently evil and should never be sent over the wire, but, someone asked how to get around the fact that embed is not a valid element in HTML4 Strict, given that tutorialsalwaysencourage people to use one object element for IE and then a nested embed element for everything else, so I wrote a sample page to do just that.