W3C home > Mailing lists > Public > www-style@w3.org > June 1998

Re: Selector "on presence of"

From: Daniel Glazman <Daniel.Glazman@der.edfgdf.fr>
Date: Tue, 9 Jun 1998 11:27:27 +0100 (WET DST)
Message-Id: <199806091027.LAA05781@cli51ak.der.edf.fr>
To: drand@sgi.com (Douglas Rand)
Cc: Daniel.Glazman@der.edf.fr, exxieh@bath.ac.uk, geier@psi5.com, www-style@w3.org
> > 2) performances : even my Pilot is able to browse the web and the very
> > first Sega or Nintendo is more powerful than my pc !
> Nope Daniel, performance is a major issue for all browsers,
> and forcing me to do a full search to satisfy a selector is not reasonable
> on both that basis,  as well as invalidating any ability to do progressive
> rendering.  I find that my browser is very much cpu bound in laying out and
> rendering a document.

When a document contains a table, browsers often stop the rendering
until they have loaded the entire contents of the table. Is that
the 'progressive rendering' you don't want to break ?-(

Seriously, powerful selectors are more interesting for industrial
content than they are for commercial stuff. I am ready to wait 1
second more in order to render a complex document with a complex style

I have been working two years with the P language which is very
powerful and very complex. Grif implemented it in Symposia in 1994 on
a PC which had nothing in common with the standard PCs we have
nowadays at home or at the office.
Amaya, which is a descendant of Grif, is mostly based on all the work
done for P handling and Amaya is a correct browser on my PC, with very
reasonable performances.

DOM will soon allow us to navigate in the entire parse tree and
manipulate styles. So we will write ugly things using script and
interpretation of this code will cost more performances than extended
selectors handling. It will be less human-readable, more fragile and
less portable because again of implementations.

This is what I call a major issue for industry. Not software industry,
real industry, the one which pays for software.

Received on Tuesday, 9 June 1998 05:39:12 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:26:47 UTC