CSS on dynamic DOM

[Maksim Orlovich]

> On Thursday 23 March 2006 18:05, Maksim Orlovich wrote:
>> A couple comments w/o having access to source tree and net at once, e.g.
>> w/o being able to test it (and please keep in mind I've been working a
>> bit
>> on making selector matching more efficient):
>>
>> 0. This is very nice to see, great work overall.
>> 1. Why do you need attribute dependencies?
> Because attributes change, and CSS can depend on them. The d2c test is a
> test
> of this.

I know that. I just mistakenly thought that we did setChanged() on
attribute changes. Which, of course, we don't, excepty for ID and name on
HTML elements. (See HTMLElementImpl::parseAttribute --- may want to remove
it).

>
>> 2. in ElementImpl::attributeChanged you -Force- a recalc for
>> id/classname.
>> That's super-duper expensive. I guess the reason is that you skip the
>> attribute dependency stuff for id/classname, so this is really a
>> disguised
>> #1.
> I think this is already done somewhere else. I just need to find it and
> disable it.

See the above stuff.

> Id and Class are some really significant attributes to change.
> In
> the neighbourhood of replacing the item, so I think a restyle is okay.
>
>> 3. Worse, in ElementImpl::attributeChanged you call restyleDependent
>> which
>> forces a recalcStyle immediately. Any reason not to rely on proper lazy
>> restyling to get it right? Right now you may be recomputing stuff over
>> and
>> over again while a node is being yanked around.
>>
> The code is not finished. I just wanted some comments, because it might be
> a
> little expensive, and not something any of the big browser does right.

Let me rephrase my viewpoint, now I understand the attribute thing:
why not just call setChanged on nodes the dependency is on, and let lazy
styling take care of doing recalcStyle just once on the whole affected
mess?
If there is a risk of circularity, the changed bit can work like a mark
bit just as well.

And yes, performance is a concern, especially since I am not sure Q*Dict
is fast enough --- don't forget to give them some decent size, BTW. (There
are also ways of engineering e.g. resetDependencies to be very quick,
which may or may not be needed..) But there can be an upside: may be the
new system can be used for descendant selectors as well, removing the
horrid forcing-Force path, that's super-expensive?

> I've already improved the code a little so the dynamicDomRestyler now also
> handles the restyles on close() needed for :last-child selectors. This
> removes the three ugly bools in elementImpl and thereby saves 32 bytes per
> Element.

Great.