Re: Selector for parent/predecessor?

Mark Birbeck wrote:
> Maybe they should improve the code, then.

They have been.  There's been very obvious progress on user-facing issues in the 
last several years (for example, popup blocking is now standard in all 
browsers).  Progress in web-developer-facing issues hasn't been as obvious, or 
as uniform, but it's there.

> I don't understand why browser implementers are suddenly given such
> special status.

What special status?  From the CSS Working Group's point of view, the browsers 
are who will implement their specifications... or not implement them.  So the 
working group cares about implementor feedback  That's part of the point of 
having a standard working group.

> I don't see the same moaning going on in other areas of software.

I don't see people making random unreasonable demands in public in other areas 
of software and demanding public responses; this happens with web browsers all 
the time.  More on this below.

> People write high-speed 3D graphics games, produce films,
> devise speech and mapping software, get satellites and ships into
> space and back...and whilst all of this innovation is going on in
> other areas, browsers basically haven't changed in years.

In my opinion, there are several things going on here.  First, with the 
exception of Opera browsers are free; this has historically somewhat limited the 
resources available to work on them (for example, there was a time in the recent 
past when there were all of 10 paid employees working on Mozilla, of whom only 
3-4 were working on Gecko).  Second, a significant fraction of browser 
implementor time is spent on reverse-engineering and bug-compatibility; sad, but 
unfortunately needed to render the Web, thanks to the way the HTML and early CSS 
specs are written.  Third, a fair amount of effort is expended in making sure 
that future specs do not suffer from these problems.  See 
http://dbaron.org/log/2006-08#e20060818a for some background on this.

> And worse, without exception, their producers spend most of their time trying to
> explain why they *don't* have security features, or tabbed browsing,
> or proper XHTML support, or decent CSS selectors...the list goes on.

As a "producer" of a web browser (or rather someone who spends time working on 
one), I resent this claim.  Most of my time is most emphatically NOT spent on 
such issues, except while reviewing certain W3C specifications.

> Imagine if the same thing happened in the world of life-support
> machines or car manufacture, with vendors claiming that performance
> wouldn't have been that great if they had coped with very high-speed
> heartbeats or breaking on bends in the road.

Imagine if people demanded that cars have full kitchens built into them and 
still do 0-60 in 4 seconds with an automatic transmission (because drivers don't 
know how to use manual ones), and even if the driver happens to leave the 
parking brake on.  Note that no single person would be demanding all of these at 
once; that would be silly and completely unreasonable.  Different people would 
be demanding different parts of it.  More on this below.

That said, though, I find your examples interesting.  Let's actually examine them.

Life-support machines are not designed for use by the masses, or expected to 
deal with essentially randomly generated data in sane ways (as web browsers are 
routinely required to do for security purposes, say).  Life support machines are 
designed with specific narrow goals in mind: As long as the input stays within a 
defined range, do certain well-defined things; once it goes outside that range, 
ring for help.  This is not a difficult problem on the conceptual level, though 
there are some nasty details there for sure.  ;)

As for car manufacture, let's go back to my example above, where people are 
demanding that cars are both able to do 0-60 in 4 seconds and have a kitchen 
inside them.  The car world solves these contradictory demands by 
differentiation -- RVs have kitchens inside, while cars focusing on performance 
worry about acceleration.  Both implement the basic features of a car (being 
able to go on a road, being able to handle a certain speed range that modern 
drivers expect, and so forth).  Both charge extra for the vehicle for the extra 
effort involved in the non-basic features.  In the web browser world, this sort 
of differentiation doesn't work so well.  There are browsers focused on 
performance at the expense of features in a way (lynx comes to mind), but no one 
uses them, because web sites actually require features from browsers.  Worse 
yet, for any given feature that's been standardized (or even just implemented in 
one browser) you start having web sites that depend on that feature and either 
break in other browsers (common case) or "look worse" (very good designer case). 
  In either case, there ends up being intense pressure on all other broser 
makers to implement this feature.

So the upshot is that the manufactureres of browsers people actually use can 
tell that browser users want to have their cake and eat it too; this means 
having to constantly make tradeoffs between performance and features, while 
working to improve both at the same time.  This is much harder than being able 
to focus on one or the other.

> 'You really must see it
> from our point of view', they might say...we can't be spending all of
> our time writing efficient code.

The problem is not efficient code; we're all spending our time doing that.  The 
problem is that the way you develop software, typically, is:

1)  Decide what you need it to do
2)  Design
3)  Implement
4)  Test

Once this is done, the question is what happens if the set of things you need it 
to do starts mutating (which is the case we're considering here).  Depending on 
the design, some mutations are not a big deal; they can be implemented without 
requiring changes in the design.  Other mutations are a problem in that they 
violate basic assumptions or invariants of the existing design and require 
either a new design altogether or a very costly and complicated layer on top of 
the existing design.  Oh, and as part of the nature of the web people expect you 
to deal with the changes in what your software does without regressing in any 
way how your software handles all the tasks it used to do.  This part I've 
already described above.

> The reality, which people can choose to ignore if they like, is that
> all of the innovation is taking place amongst programmers who are
> working around the limitations of browsers!

Please do read David Baron's blog post I cited above.

> browsers are years out of date,

Compared to what?

> and don't provide the features that authors need.

This part I think people generally agree with; this is why things like Web Forms 
2 are being worked on.  Again, see above for some background on what's been 
happening between the browser makers and the W3C over the last few years.

-Boris

Received on Tuesday, 22 August 2006 14:35:56 UTC