Re: Selector for parent/predecessor?

[Ahem, sorry Boris, I sent you by mistake a preliminary version of
this email. Please discard it]

On 8/21/06, Boris Zbarsky <bzbarsky@mit.edu> wrote:
>
> Implementing a parent selector involves knowing all the children of an element
> by the time you're ready to style it.  Hence the incremental load problems.

IANAI (I Am Not An Implementor), but I don't really see how this is
any different from having to know the entire content of the element
before rendering it. And by judging from what I see in Opera or
Mozilla, dynamic/progressive restyling is not really a problem, just
like dynamic/progressive content addition isn't. (I rarely if ever use
Internet Explorer, so I cannot discuss its functionality, especially
for IE7)

You want an example? Head over to my blog:
http://oblomov.ilcannocchiale.it : due to the very strong limitations
of the blog platform I'm using, I've had to implement my own style by
doing an enormous amount of element juggling with JS: and *after* all
the juggling is done I add a <style>...</style> element to my document
with all the CSS I'm interested in ... and *poof* the page gets
rendered correctly.

Even without considering these extreme cases, a lot of complex pages
with no JS code require some rendering box shuffling and restyling
*while loading*, and both Opera and SeaMonkey seem to handle them
pretty well.

So please help me get something right: Opera and SeaMonkey already
handle similar situations (and the other stuff is really not any
different). Plus,  as Allan Sandfeld Jensen mentions:

> Not really. It would only take me a few hours to implement it in KHTML. A 40
> line recursive function could do it. The dynamic restyling framework I wrote
> to correctly track the current child to parent or uncle relationships can
> easily track cousin to cousin relationships as well.

so I guess Konqueror would not have any problem with that either.

So not only I still don't see the validity of such an objection on a
purely technical reaso. Even worse, I don't understand /who/ is
objecting, given what Allan Sandfeld Jensen says and that Opera and
Mozilla SeaMonkey already seem to handle current dynamic/progressive
(re)styling rather well ... are they complaining about there being
/more/ need for it? Who else is left?

-- 
Giuseppe "Oblomov" Bilotta

Received on Monday, 21 August 2006 06:13:29 UTC