Re: complexity

Hi,

On Thu, Apr 08, 2004 at 09:29:51AM +0000, Ian Hickson wrote:

> > For HTML and CSS, the problem is that the people who come up with
> > the implementations don't have to write a complete and concise
> > specification,
> 
> This may have been true in the past.
> 
> At the moment, the active members of the CSS working group consist
> almost entirely of implementors (engineers and QA) and people who have
> a lot of contact with real world authors, or are such authors
> themselves, and who in addition understand both the concepts of
> separation of form and content and the concepts of reducing complexity
> and indirection in specifications.
> 
> I like to think it shows.

CSS is actually a funny example. CSS2 is an extremly evident case of a
completely crazy standard. CSS 2.1 tries to set things straight; but
it's still much too complex, and doesn't really follow the agenda set
out in the preamble. (Only things consistently supported by existing
clients...)

> There is also a lot of focus on re-using existing W3C technologies and
> not reinventing them -- for example some groups are reluctant to use
> their own attributes for links, instead using XLink -- which leads to
> compromise solutions being propagated into other specifications in the
> name of unity and reuse.

XHTML 2 is an example of this: Using XForms and XInclude seems so easy,
they are already there... People only seem to forget that all the
infrastructure behind this (complete DOM handling, XPath etc.) is
terribly complex, and would bloat a simple browser (i.e. one that
doesn't have CSS and scripting and thus has to implement these things
anyways) by a factor of 3-5 at least. Without any measurable benefit to
users/authors.

> > Generally standardisation is done after the fact.
> 
> In the groups I'm involved in or peripheral to, this is not really the
> case. In particular the CSS, XHTML, SVG, and XForms groups all tend to
> write specifications before (or in tandem with) implementations.

Add XSL, XInclude, XSD, SMIL, PNG... Even XML is bloated by provisions
that are completely useless in at least 99% of use cases!

The problem is precisely that these specs are written in advance, trying
to cover all possible and impossible uses and boarder cases, instead of
focusing on what is really necessary, and without seriously considering
practical implications.

> > CSS is funny in that it was created as part of trying to clean up
> > HTML but is being driven by marketing driven feature creep.
> 
> There's actually very little marketing force behind CSS right now.

Indirect marketing force. Authors want to do silly things like
:first-letter, and marketing wants to satisfy these silly wishes...

> And the CSS group is the only group to be truly looking for dual
> interoperable implementations before releasing a CR spec to PR, which
> is making it even harder for the specs to be poor.

Well, this should help a lot; but it doesn't really solve the problem.
What does it help when Mozilla and Opera prove that something is
possible, if no other browser (except maybe IE, if they wanted to) is
able to implement it?

Also note that both Mozilla and recent Opera version have terribly slow
layout engines. An *efficient* implementation can be more complex by
another order of magnitude easily.

-antrik-

Received on Friday, 9 April 2004 09:35:43 UTC