Add support for :-moz-bound-element matching the bound element in scoped stylesheets

RESOLVED FIXED in mozilla0.9

Status

()

RESOLVED FIXED
18 years ago
18 years ago

People

(Reporter: hyatt, Assigned: hyatt)

Tracking

Trunk
mozilla0.9
x86
Windows 2000
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [xbl1.0])

Attachments

(2 attachments)

(Assignee)

Description

18 years ago
If XBL-scoped stylesheets could use a pseudoclass to refer to the bound element,
then stylesheets could be written that could apply to any tag, thus allowing us
to reuse the same stylesheets for both XBL-based HTML form controls and
XBL-based XUL widgets.
(Assignee)

Updated

18 years ago
Status: NEW → ASSIGNED
Summary: Add support for the :xbl-bound-element pseudoclass → Add support for the :-moz-xbl-bound-element pseudoclass
Whiteboard: [xbl1.0]
Target Milestone: --- → mozilla0.9
(Assignee)

Updated

18 years ago
Summary: Add support for the :-moz-xbl-bound-element pseudoclass → Add support for the :-moz-xbl-root pseudoclass
(Assignee)

Updated

18 years ago
Summary: Add support for the :-moz-xbl-root pseudoclass → Add support for :root matching the bound element in scoped stylesheets
(Assignee)

Updated

18 years ago
Summary: Add support for :root matching the bound element in scoped stylesheets → Add support for :-moz-bound-element matching the bound element in scoped stylesheets
(Assignee)

Comment 1

18 years ago
As requested, cc'ing pierre for review.  This patch enhances the scoped
stylesheet support a bit and involves a minimal patch to the style system.  I
don't think it will conflict with your style context work, so I'm submitting it
for review now.
(Assignee)

Comment 2

18 years ago
Created attachment 27418 [details] [diff] [review]
The patch.
(Assignee)

Comment 3

18 years ago
Looking for sr from either attinasi or brendan.  

Comment 4

18 years ago
I am worried about the extra work being done in the SelectorMatchesData
constructor - can we cache the styleset and pass it into the SelectorMatchesData
ctor instead of having to get it from the presContent->presShell? The
StyleContext also has a reference to the style set, although it is currently not
exposed. Building SelectorMatchesData instances has to be as fast as possible!

Also, should the additions to the SelectorMatchesData class be #ifdef'd? Do we
want to carry around the mStyleRuleSupplier if no XUL is being compiled in?
(Assignee)

Comment 5

18 years ago
This is XBL, not XUL,so no #ifdefs.  This is for HTML as well.  (In fact all my
tests are HTML.)  I'll see what I can do about passing the styleset in.
(Assignee)

Comment 6

18 years ago
I don't believe this patch would cause any kind of slowdown.  It only has to
fill in two pointers (with two addrefs) to get to the styleset from the pres
context.  

Easiest thing to do is to back this up with some numbers, so I'll run jrgm's
tests and let you know the results.
(Assignee)

Comment 7

18 years ago
Ok, I have a clever solution.  The selector matches data lazily initializes the
style rule supplier member variable.  This way, you only obtain the style rule
supplier if/when you encounter the :-moz-bound-element pseudo.  

Patch forthcoming.
(Assignee)

Comment 8

18 years ago
Created attachment 27483 [details] [diff] [review]
Patch #2 to nsCSSStyleSheet.cpp (the rest is the same)
(Assignee)

Comment 9

18 years ago
Ready for another r/sr.

Comment 10

18 years ago
Very nice, David. And sorry to confuse the XUL #ifdef ;)

sr=attinasi pending Pierre's r=
(Assignee)

Comment 11

18 years ago
Fixed.
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.