On 3/17/09 11:10 AM, L. David Baron wrote:
We could do that, but we'd have more rule hashes than one might think in
the UA level due to all the anon boxes that we treat as pseudo-elements
(most of which we do have rules for in ua.css). We'd also have a rule
hash per different made-up tree pseudo-element. It might be ok, though.
Instead, we could have all the pseudo-element rules in a separate
hash, where that hash contains either a simple list of rules, or a
rule hash. We'd switch from simple-list to rule-hash if we ever got
a rule that would hash as non-universal. This would mean the anon
boxes wouldn't get a rule hash.
(Still not sure about the tree pseudo elements, though.)
I went back to this today, and I think there's a fairly straightforward
approach here by just throwing away my attempts at minimal invasiveness.
The CSS parser knows whether its parsing a pseudo-element, an
anonymous box, or a tree thing. All the callers except
ReResolveStyleContext know what sort of pseudo they're looking for, and
ReResolveStyleContext could be taught to (either by looking it up, or by
flagging the type on the style context). Therefore, proposal:
1) Have an enum for pseudo type; the values should basically be one
per CSS pseudo-element, eAnonBox, eTreePseudo, eNotPseudo or the
like.
2) For CSS anon boxes, forbid having anything but the name of the
anon box in the selector. Make anything else a CSS parse error
(and possibly assertion). The only current consumer I can find
at a quick glance which has something else in there is
"select::-moz-scrolled-content", and that rule can just
be removed now that bug 456484 styles all -moz-scrolled-content
that way.
3) When parsing a "pseudo-element" selector, store the pseudo-type
in it. If we care, we can make sure it only takes up 16 bits
by making the member a PRUint16 so it packs well with mCombinator.
4) Change consumers to use separate APIs to get style for tree
pseudos, pseudo-elements, and anonymous boxes. The anonymous box
API should not take an element (since it wouldn't be used for
anything anyway).
5) When setting up the rule cascade, put all the eNotPseudo rules in
the rule hash as now. Have a simple atom-to-linked-list hashtable
for anonymous boxes. Do something sane for trees (either a
separate rule hash or whatever). Have an array of pointers to rule
hashes, allocated as needed, for the pseudo-elements, with just an
array index and rulehash lookup if it's not null, as needed.
6) Remove all the null-checks for the mContent of a RuleProcessorData,
since anonymous boxes will no longer use it and everything else
will have a non-null mContent.
If there are any obvious issues, please speak up; I think this is solid
enough to just go and do.
Oh, and I did some measurements today on the single-page html5 spec. On
m-c, going from display:none to display:block on its <html> element
(just the frame construction) takes 1760ms or so. With the patches in
bug 523148 and bug 523288 it's closer to 1410. Of that 1410, about
140ms are in pseudo-style probing; my quick hack to do a slightly faster
path for :before and :after brought that down to 70ms, but I think we
might be able to win more there...
-Boris
_______________________________________________
dev-tech-layout mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-tech-layout