Closed Bug 21890 Opened 25 years ago Closed 24 years ago

Documents can style their scrollbars!

Categories

(Core :: XUL, defect, P3)

Product:
Core
Component:
XUL
Type:
defect

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: ian, Assigned: hyatt)

References

(
URL
)

Details

(Keywords: css-moz, css2, Whiteboard: [nsbeta3+])

Documents are able to style their scrollbars. As amusing as this is, I do not believe it is a good idea. :-) I can just imagine web authors the world over 'customising' the scrollbars for their site. Ouch. Anyway, a rather dramatic test case can be seen here: http://www.bath.ac.uk/%7Epy8ieh/m/widgets/15.html The problem is simply, I believe, that the scrollbars appear in the DOM. They should not. Currently the universal selector '*' selects them, this is clearly a Bad Thing.
Let me stress here that this is a Very Bad Thing because style rules that are not intended to do anything to scrollbars can instead make them invisible. (If this were a case of being able to *intentionally* style scrollbars, it wouldn't be *so* bad.)
In particular, for example: * { background: transparent; border: none; list-style: none; } ...will make a document's scrollbars vanish. The above rule is a perfectly legitimate rule for authors to include in their stylesheets.
assigning to evaughan for triage. Eric - your creation...It's ALIVE!!! cc hyatt and myself. BTW, my wife and I really like the scrollbars on the linked page :-)
They aren't in the DOM. They're in the frame tree (and thus pick up style). Also, this is exactly what you want for XUL... to be able to style even anonymous content. I'm not sure how to fix this. I can see cases where a Web page SHOULD be allowed to style the scrollbars that occur within its borders (maybe not the outermost one. For example, I think it's reasonable for a doc to be allowed to style the scrollbars on any <select> elements that it contains. One possible solution would be to assume that rules in style sheets loaded from HTML automatically get namespace to HTML if no namespace is explicitly specified. This would solve the problem and still allow someone to deliberately style the XUL scrollbars.
I believe Hyatt's suggested solution contradicts the css3-namespace draft - if not for HTML, then certainly for XHTML. See http://www.w3.org/TR/css3-namespace IMO, the style system needs to know not to apply universal selectors to scrollbar frames. (It knows not to apply them to generated content frames, so it shouldn't be too hard...)
Then I'm at a loss as to what to suggest.
trudelle wrote: > BTW, my wife and I really like the scrollbars on the linked page :-) Thanks. :-) I was quite pleased with them myself... hyatt: At the moment, only the _document_ scrollbars get styled. The scrollbars in, for example, the textarea at the end of that page are *not* styled. Why is that the case? I can see why letting the author style the scrollbars is a cool idea -- but it should *certainly* not be possible to do so accidentally by using the universal selector ('*'), and should also not be possible to style it without explicitly asking for them to be styled. If an XML document uses a 'thumb' element, and tries to style it, for example, the thumb of the scrollbar will get styled. This should not happen. An example of such a document: <doc> <images xmlns="some-thumbnail-namespace"> <thumb src="abc"/> <thumb src="def"/> <thumb src="ghi"/> </images> <imagelist xmlns="some-other-thumbnail-namespace"> <thumb href="abc"/> <thumb href="def"/> <thumb href="ghi"/> </imagelist> </doc> ...with this stylesheet: /* no namespace declarations so this rule applies to the <thumb> elements in both namespaces in the document. */ thumb { display: inline; border: thick teal solid; } ...would make the thumbnail scrollbars have big thick borders! Having said all that, I *do* support the idea that pages should be able to style their widgets, and that includes the scrollbars. How that is done without polluting the namespaces and things, I don't know. Any ideas David?
I just realized a good solution to this would be to make the scrollbar a pseudo-element (or set of pseudo-elements). Then xul.css could have selectors like :-moz-scrollbar :-moz-scrollbar-thumb etc... (where -moz- is the seemingly accepted (by the WG) way of indicating a proprietary extension to CSS.) This is something that could eventually be proposed for inclusion into CSS. It would also solve the problem of scrollbars being selected by the universal selector, and it would also allow document authors to style the scrollbars (even on a per-element basis). (Logically, I don't think scrollbars really belong as elements in an XUL namespace, anyway, since they occur on any element that has certain values for the 'overflow' property.)
Yep, that would be a very good way of doing it. Good thinking David! ;-)
trudelle - Did you mean to assign this to evaughan?
*** Bug 20734 has been marked as a duplicate of this bug. ***
Assignee: trudelle → evaughan
yup, thanks!
Status: NEW → ASSIGNED
Target Milestone: M15
Hmm this is a tough one. I have a little trouble with making them pseudo elements because I would like in the future to have their implementation be written entirely in javascript. So they would have a tag. You also need to be able to just instantiate scrollbars and slider and hook them up in XUL so you must have a tag. As soon as you do that you are back to sqare 1. So again don't universal selectors apply to widgets already? What if you go * { background: black; } doesn't that set the background of the widget black? If someone wants to play the "lets hide everthing" game the can already do that. What we should guarentee is that the main chrome used for navigation should never be styleable from the the page. If someone hides all the scrollbars then no one will use their page. Its as simple as that. You can't prevent someone from shooting themselfs in the foot. Scrollar will eventually be defined as follows: scrollbar { content: url(scrollbar.xul) behavior: url(scrollbar.htc) } The scrollbar can be completely implemented by a user in javascript or any other language we support. The default implementation would have a slider, scrollbar buttons, and a thumb. But someone may do something completely different if they wanted to. If don't want to build in assumptions about their structure only the XPCom interface. It would standarized.
The problem is that many of the style rules that can style scrollbars are desirable rules (in CSS2-conformant implementations, i.e., not the current implementation in Mozilla). If the scrollbars are stylable by the universal selector, it means the universal selector is permanently destroyed as a feature of CSS as long as Gecko exists. I don't think that's Gecko's mission. (The universal selector is a very important feature of CSS with respect to accessibility - it helps greatly in designing user stylesheets that can help make pages more accessible to users with poor vision.)
I actually don't think there's even a bug here.
Summary: Documents can style their scrollbars!!! → {css2}Documents can style their scrollbars!!!
Are you saying the behavior is changed? There most certainly was a bug a few days ago.
*** Bug 22870 has been marked as a duplicate of this bug. ***
Keywords: css2
Migrating from {css2} to css2 keyword. The {css1}, {css2}, {css3} and {css-moz} radars should now be considered deprecated in favour of keywords. I am *really* sorry about the spam...
> Dave, can you give an XBL example of how you would bind say a BEOS > created scrollbar (horizontal and vertical) to say a particular > <browser> tag. > <browser class="fubar" type="content-primary" id="content" > src="http://www.mozilla.org" flex="100%"/> > > browser.fubar{ > > overflow: auto; > behavior: url("chrome://global/content/htmlBindings.xml#beos"); > > } I doubt this works, since I think the scrollbar may actually be "inside" the window, which means it's actually styled by the src of the browser and not by the parent XUL itself. I think this is something we need to address, since that outermost scrollbar in a browser window is chrome and shouldn't really be stylable by the HTML document inside. In other words, weirdly enough, you'd probably put the behavior rule for scrollbar in a style sheet loaded by the HTML web page. :) This doesn't sound very correct, does it. ;) I believe evaughan has a bug on this issue "Documents can style their scrollbars". You might want to add my comments in this news post to that bug. Dave (hyatt@netscape.com)
BULK MOVE: Changing component from XUL to XP Toolkit/Widgets: XUL. XUL component will be deleted.
Component: XUL → XP Toolkit/Widgets: XUL
Summary: {css2}Documents can style their scrollbars!!! → Documents can style their scrollbars!!!
Summary: Documents can style their scrollbars!!! → Documents can style their scrollbars!
Removing some exclamation points from summary so notifications don't get snagged by spam filters!!!
I was going to report this as a bug. But found this bug report instead. I dont understand all of what is reported below. But I do thing it is a *bug* not a `feature'. Using mathml and its standard stylesheet, the scroll bars turn white, and are hard to see.
I agree with evaughan here. It's not the scrollbar's fault that makes "the universal selector permanently destroyed as a feature of CSS". Any style rule with the universal selector that makes the scrollbar invisible, will also make all <input>s and <textarea>s invisible, or at least completely unrecognisable as widgets. The problem is the lack of difference between widgets and text in CSS. I guess the universal selector is pretty unusable, because you'll never know what the heck you may change with it in the future. (the color of a NG iMac or "I did '* {display:none}' and my whole CSS-stylable house was gone!") Maybe ther needs to be a separate bug, but I think it must be possible to style scrollbars in textareas etc. which isn't possible right now. The same goes for framesets, frames and iframes. PS. [offtopic] door { border: 2cm oak inset; behavior: url(star-trek-slide.bhv); }
CSS is very clear that the universal selector matches all elements in the document tree. The scrollbars are not elements in the document tree (they are created when something has 'overflow: auto'.) If you want some of the properties on textareas, etc., to effect their scrollbars, then that could be OK (but I think it's a bad idea). If you want body { background: red; } to change the background color of both the body and the scrollbar, then that's OK (but it's a bad idea). If you want the scrollbar for an element to be matched by a pseudo-element, then that's OK (and perhaps a good idea). However, it is horribly against the idea of CSS to allow something to be matched by a universal selector that cannot be matched by a type selector for an element that exists in the document. This is a BUG. Period.
I have an idea. What if we say that - for all stylesheets loaded by HTML - that all rules are implicitly namespaced to HTML. It would be as if a @namespace appeared at the top of the stylesheets setting the default stylesheet namespace to HTML. Then you would STILL be able to style scrollbars, but only by explicitly defining the XUL namespace. Any rules used by normal Web developers would have no risk of impacting the scrollbars themselves.
That disagrees with the working draft http://www.w3.org/TR/css3-namespace/#tag-selector It also wouldn't help XHTML. I really think pseudo-elements are the logical way to go here, especially since such a solution would have a chance of being accepted by the CSS WG as part of CSS (minus the -moz- prefix). Scrollbars are a perfect example of what pseudo-elements are designed to do.
Pseudoelements are insufficient to style the scrollbars.
the problem with pseudo-elements and the scrollbar is that scrollbars are XBL, so they can have any XUL inside them. The only solution I can think of is a pseudo-element-function, but only as a last resort. Like this: :-moz-scrollbar(<selector>) examples: BODY:-moz-scrollbar(thumb) {/* style for the thumb */} BODY:-moz-scrollbar(box image) { /* style for an image inside a box, if this is the way someone makes the scrollbar */ } "However, it is horribly against the idea of CSS to allow something to be matched by a universal selector that cannot be matched by a type selector for an element that exists in the document. This is a BUG. Period." This is a problem with any XBL, not only the scrollbar. So maybe we need a general solution. I see a future for XBL. Anonymous content is a very cool way to style XML. Currently Mozilla wil style any anonymous content directly. Maybe this is not a good idea on the long run. Would :anonymous(<selector>) {} be a good idea?
I expect there are also issues with DOM compliance here. I tried to write a test case, but it crashed in JS code. I'll file a bug...
There are DOM problems that seem related to scrollbars. Should I add them to this bug or file a new one?
Never mind... I've only found some repaint bugs...
I've also been thinking about this bug recently, and the only solution I can see is the one suggested by sjoerd@heeten.nl. Basically, content that is _not_ present in the document and that was not created by the document interacting with its DOM should absolutely not be matched by any selectors that are valid W3C recommended CSS. What we need is a pseudo-element which will match XBL-created nodes. Such as: :-moz-xbl(scrollbar thumb) ...which will match what is _currently_ matched by scrollbar thumb This will probably require some not insignificant changes to the rule matching code so cc'ing Pierre.
Severity: minor → normal
Keywords: css2 → css1
OS: Windows 98 → All
Hardware: PC → All
The only problem is that there's no scrollbar element anywhere. Maybe we should not bind an imaginairy scrollbar element, but bind all scrollable boxes. This would also allow for different scrollingmethods, like a big scrollbarbutton at the full top and bottom of a box, like with menupopups. CSS would then be: box[overflowx=false]:-moz-xbl(scrollbar.vertical) {display:none} box[overflowy=false]:-moz-xbl(scrollbar.horizontal) {display:none} What do we do with frames? both frame:-moz-xbl(scrollbar) and body:-moz-xbl(scrollbar) should style the same scrollbar. (just like they share the marginwidth attribute f.e.) In some cases it would be very usefull if styles would be inherited, like with the file upload widget, which is in fact a collection of 2 widgets. It could be an extra atrribute for the content element in XBL, which would default to false/off.
A solution could be to extend the namespace spec and define namespaces that don't inherit from the universal selector (eg. "@namespace !required <name> <url>"). It would be relatively easy to implement but we need to thoroughly think about the consequences.
Namespaces might work, but it's a very crude hack, because the problem has nothing to do with namespaces. There is a problem with namespaces though, because the xul namespace is only introduced inside XBL, invisible for the main document and stylesheets. We could just reserve the 'xul' namespace for ourselves, in a Microsoftish way.
Hyatt, Do you have a fix for this?
Assignee: evaughan → hyatt
Status: ASSIGNED → NEW
*** Bug 28291 has been marked as a duplicate of this bug. ***
Status: NEW → ASSIGNED
Target Milestone: M15 → M17
Mass moving M17 bugs to M18
Target Milestone: M17 → M18
spam, open xptoolkit qa contact moving over to jrgm
QA Contact: paulmac → jrgm
I see nothing particularly wrong with either the pseudo-element idea or the namespaces-that-don't-match-the-universe-selector idea. The second is really just the first with a different, non-pure-CSS-like, and cleaner, syntax, though, isn't it? BTW, the following very useful and sensible rule shows even more clearly why it is vital that we fix this. Just add it to any complex page's stylesheet... *:hover { border: solid thick lime; background: #FFE; }
Keywords: css1 → css-moz, css2
So scrollbar elements should be in an undefined namespace that defaults to !required, because it also needs to work in current html only documents.
?? I don't understand your logic. I would just make the XUL namespace declaration in xul.css read: @namespace ! required (http://www. .... .is.only.xul); /* set default namespace to XUL and prevent it from matching the universal selector */ I don't see what you mean by "undefined" or "which defaults to". All of this idea is _designed_ to work with legacy documents.
If xul.css gets included in the UA default style sheet for HTML and XML, then it's fine.
mass-moving all bugs to m21 that are not dofood+, or nsbeta2+
Target Milestone: M18 → M21
Nominating nsbeta3, since serious standards-compliance issue.
Keywords: nsbeta3
How hard is it to add scrolling methods to the DOM? Letting people define their own scrollbars using dhtml and use these scrolling methods to apply them onto the frame, text area or DIV. This wouldnt be a bad idea. I do not know why the scroll methods for frames are removed from the Mozilla which broke down many NN 4.x supported dhtml enhanced sites, but putting those back can give users a chance to apply some neat visual effects. That way you do not need to worry all the implementation details. How many people really will care about the style of their web applications? not too many. By the way what happened to the layer tag. Will mozilla ever be backward compatible?
Never mind, I checked the test site of Ian. It looks abosuletly perfect. If we can do all this, nobody really needs those scroll methods. regards, Bora
If the scrollbar elements aren't in the DOM, then how are they picking up the style in the document? Style is normally determined before frame construction, since it determines which frames are created. So when the scrollbar frames are created, what tells them to use the stylesheet of the document?
As per meeting with ChrisD yesterday, taking QA.
Keywords: correctness
QA Contact: jrgm → py8ieh=bugzilla
nsbeta3-, future
Whiteboard: nsbeta3-
Target Milestone: M21 → Future
Eek! nsbeta3-??? This bug is currently affecting some existing content and more importantly is going to completely ruin the ability to use the universal selector in CSS. Simply adding the quite sensible rule: * { color: black; background: white; } ...kills our scrollbars. Worse: It makes creating new XML vocabularies a dangerous game! For example, while this bug exists in a shipping browser, no-one will be able to use and style an element called "thumb" without risking the sanity of the scrollbars in Mozilla. Even worse!! The incredibly simple rule: BODY DIV { position: absolute; top: 0; left: 0; } ...which can make perfect sense in an HTML document, makes all the text widgets of a document useless, by moving them to the upper left hand corner! (bug 46505) Assuming we are going to implement the change in the universal selector so that we can specify namespaces which do not match unless explicitly selected, then this will also help to fix bug 46505, where the anonymous content that is introduced in an INPUT element is matching an unrelated rule in the stylesheet. Reassigning to Pierre to implement our hack. The safest syntax we could use without endagering forwards-compatability with future standards is probably a new @rule that adds namespaces to a special list of black-listed namespaces that are not allowed to match the left hand side of the universal selector *|*. @-moz-hide-namespace url(namespace); We would then add this to ua.css or xul.css, like this: /* Prevent our internal namespaces from matching universal selector */ @-moz-hide-namespace url(http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul); @-moz-hide-namespace url(http://www.mozilla.org/xbl); ...followed by the existing @namespace rules. Any comments? This should go in ASAP because QA will need to have the time to ensure this does not cause any regressions. Clearing nsbeta3- to trigger re-evaluation in light of the above descriptions.
Assignee: pierre
Blocks: 46505
Status: ASSIGNED → NEW
Keywords: 4xp
Whiteboard: nsbeta3-
Ian is right. This problem makes the universal selector unusable in [user]/chrome/user.css and it causes big accessibility issues.
Status: NEW → ASSIGNED
Target Milestone: Future → M18
I investigated both ways to implement the hack ([Pierre Saslawsky 2000-03-15 01:06] and [Ian Hickson 2000-07-27 16:50]) but it is not very satisfying. I'm beginning to believe that [David Hyatt 1999-12-15 22:19] was correct. HTMLContentSink::ProcessStyleLink() and HTMLContentSink::ProcessSTYLETag() both load the stylesheet with kNameSpaceID_HTML and I think we should do the same thing in CSSLoaderImpl::LoadAgentSheet(). This raises two questions: - Why doesn't the default name space work? I somewhat suspect a problem in CSSStyleSheetInner::RebuildNameSpaces()... - Per [David Baron 1999-12-16 06:43], this method contradicts the spec. Why?
At one point I was wondering whether this could be solved by changing the parent style context used when constructing the scrollbars. I never got around to finishing my investigation. Pierre, are you saying something is wrong with our implementation of the namespaces draft? I haven't tested it much, so I'm not sure...
The implementation is correct from an external standpoint. The problem seems to be that default namespace (an internal feature) doesn't work. We currently set the default namespace to HTML - at no avail then - for linked and embedded stylesheets in HTML documents. The idea was to fix it, of course, and set the default namespace when loading agent sheets too. But I'm realizing as I'm writing this that it may not work very well for XML... I'll sleep on it.
I don't think Ians suggestion of hiding namespaces is the right way to go. That would only solve the problem of XUL getting style when link into a document though XBL. Theoretically HTML can be used in scollbars as well. I think the RightThing to do is to be able in the XBL file to tell how the linked content should be styled. The three basic alternatives are 1. Linked content isn't be affected at all by the original document style 2. Linked content will only inherit styles from it's "parent element" 3. Linked content is styled as if it belonged to the original document where 3 is how it behaves today. Actually it would be really cool if you could in the XBL file control exactly which CSS proerties get which of the above treatments. Guess it would be a fourth child of <binding>. For normal authors to be able to style their scrollbars we could have some special CSS syntax for styling linked content. Maybe something like: xul.scrollbar|thumb {background: gray;} I guess much of this requires very much coding but it could be something to aim for...
Jonas is right. We can't use namespace tricks to hide the generated elements. I therefore propose we fall back to the suggestion originally given by David and Sjoerd. Basically, content that is _not_ present in the document and that was not created by the document interacting with its DOM should absolutely not be matched by any selectors that are valid W3C recommended CSS. What we need is a pseudo-element which will match XBL-created nodes. Such as: :-moz-xbl(scrollbar thumb) ...which will match what is _currently_ matched by scrollbar thumb And similarly for elements that are created by, e.g., by <input>: input:-moz-xbl(div) ...which will match the <div> created inside <input> elements (see bug 46505).
We need a reasonable solution given the lack of time we have left before shipping. Every solution I've heard so far is too involved and too risky to contemplate right now. I cannot allow fundamental changes to the way XBL elements are matched or to the XBL syntax itself until after ship. It's just too risky.
Also, a point I think people are missing is that the scrollbars are not created using XBL. The content of the scrollbars themselves is XBL, but the creation of scrollbars is hardcoded in C++, and XBL doesn't get involved at all. You would have to patch the C++ anonymous content if you wanted to implement such a solution, as well as XBL.
David, I agree that what Jonas and Ian have proposed is unrealistic but you can't say that "every solution is too involved and too risky". I'll continue to look into making the default namespaces work (that should take care of most problems), and otherwise a hack to hide some namespaces from the universal selector.
If we need a quick solution, any hack in the C++ code of the scrollbar would solve this bug. The code should only accept style rules that explicitly uses 'scrollbar' in the selector. This would make things 'work as expected' for the first release (Mozilla or Netscape or both?). Also, preventing some namespaces to be selected by the universal selector, would probably be usefull for other purposes as well. (XML data islands f.e.) After 'shipping' work should be started on :-moz-xbl() IMHO, because elements that do not appear in the DOM tree should not be styled through normal element selectors, ever. For completeness the solution of Microsoft: "Viewlink provides the capability to encapsulate the CSS style settings in the document fragment. Generally, the CSS properties in the primary document and the document fragment are independent of one another, but it is also possible to control the inheritance of style settings from the primary document to the document fragment. The default setting for a viewlink is that CSS properties set at the master element are inherited by elements in the document fragment. The component author can override any CSS styles in the primary document by setting the corresponding styles explicitly in the HTC file; styles in the component file take precedence over any styles applied to the master element in the primary document. The ViewLink CSS Inheritance page provides detailed information on the inheritance of specific CSS properties. CSS inheritance is controlled by the Boolean viewInheritStyle property. If viewInheritStyle is set to TRUE, then inheritable CSS styles set in the primary document are inherited by the corresponding elements in the document fragment." After reading this 10 times, I've decided that I'll have to try some code to see what this really means. I don't think it'll help solve this bug.
[nsbeta3+].
Whiteboard: [nsbeta3+]
Sjgoerd, ViewLink's solution will only work with XBL when the anonymous content is self-contained. In Microsoft's world, there is no notion of interleaving the anonymous and explicit content, i.e., the ViewLink content is essentially a lightweight document in its own lightweight iframe. XBL is more flexible than this, since it actually allows explicit content to be placed within the anonymous content. Also, hacking of the scrollbar code needs to be specific to HTML, since someone using XUL can and should be allowed to style all scrollbars for example, even if they are anonymous content. I don't really agree with the use of a special selector just for XBL. The document can and should be allowed to apply styles to anonymous content without using a special selector, although we could perhaps have the XBL decide whether it will accept styles that come from parent documents (as viewlink does). Unfortunately this is also a pretty complicated problem. The best hack I can think of for HTML still is to just make sure all stylesheets loaded from HTML default to the HTML namespace. Doesn't solve XHTML, but IMO that can wait until 6.1.
Ok, so the ViewLink solution could conceivably be applied to XBL, although you'd run into the following problems. (1) All bindings would have to have their own style trees. They could not be held in the same style tree as everyone else. (2) XBL files would have to be capable of loading stylesheets and using them to resolve styles for their own little style trees. (3) A binding could specify, "Inherit my parent's stylesheets," in which case the sheets could be loaded into the binding's style tree and used along with the binding file's own stylesheets. Now you don't ever need an XBL selector and you can retain all the current functionality, so yes, I like Microsoft's solution to this problem and do think it's applicable to XBL. However, ideal though it might be, it's probably a week's worth of coding that I know I don't have time to do. :(
The interleaving especially would be tricky to do, since I just made a change to help attinasi keep the style tree and frame tree in sync. With this viewlink change, the style tree and frame tree would once more be out of sync (with frames in the same tree even pointing to different style trees).
Ok, guys. I've been studying the way styles are resolved using rules processors. I think I can implement the ViewLink solution in a way that will solve our problem. This will involve hacking on the style set. I'm going to go for it since this looks like fun and XBL really needs this anyway for other reasons. I will produce a patch in this bug when I've got something to show.
Assignee: pierre → hyatt
Status: ASSIGNED → NEW
Please don't take bugs off my list without checking me first. I was working on that one. Reassigned to myself.
Assignee: hyatt → pierre
Status: NEW → ASSIGNED
$#%&*@!#! silly textarea crashers #@$%!&*!@#! So anyway, David Hyatt, Ben Goodger and I were bouncing ideas last night and David suggested a slight change to the :-moz-xbl(...) idea. Instead of having the whole pseudo-element at the end of the selector containing the XBL selector to match, just have all the XBL's (anonymous) generated content be 'pseudo- elements' that match :-moz-xbl or :-moz-xbl-content or somesuch. Thus, to style the scrollbar thumb: thumb:-moz-xbl-content {...} or, assuming the thumb element used has a particular class instead of a particular GI: .thumb:-moz-xbl-content { } To match a thumb inside a scrollbar inside a particular div: div#id .scrollbar:-moz-xbl-contnet .thumb:-moz-xbl-content (Note that this stretches the rule about 'only one pseudo-element per selector.) To match the DIV in the INPUT element (which is in the HTML namespace): INPUT > html|DIV:-moz-xbl-content { ... } This has the advantage over the namespace hack that it does not prevent XUL content from containing stuff from other namespaces (e.g. SVG or HTML).
Right, although that could probably be futured if we can't get to it in time. The complete proposed solution goes something like this. (1) Enable XBL to include CSS files and expose those to the style set dynamically for a given content node. The style set has been really cleanly designed, and so this looks quite easy to do. (2) Add an attribute to XBL bindings that says whether or not they inherit styles from the nearest containing scope or not. By default they will, since most of the time you use XBL that's what you want. For scrollbars, we'll turn the inheritance off. That's it! Basically I'm proposing that the style set have a WalkRuleProcessors function that would talk to the nsIBindingManager to obtain any additional rule processors for a given content node. The binding manager would also indicate whether the normal author sheet rule processors should be used. I'm really advocating this solution because (a) I don't think it's nearly as hard as I thought it was going to be, mostly because the style set is designed really well for this already, and (b) it's a feature that people are clamoring for in XBL that Microsoft's HTCs already support.
And (3) would be to do the :moz-xbl thing for the case where the binding didn't inherit by default. This would give you a way of defining rules that would apply to the binding content only. Note that (3) could technically be futured, although it will mean that documents can't style their scrollbars at all.
If unknown CSS properties are available through the .style object, the scrollbar style-properties from IE5.5 could be implemented with XBL. about :-moz-xbl-content > (Note that this stretches the rule about 'only one pseudo-element per selector.) Ehm, :-moz-xbl-content is a very good idea, and is a pseudo-class, not a pseudo- element, so no problem here. > div#id .scrollbar:-moz-xbl-contnet .thumb:-moz-xbl-content I disagree. :-moz-xbl-content should be needed once to pierce into the anonymouse content. So div#id .scrollbar:-moz-xbl-content .thumb would match the thumb, but here: div#id .scrollbar:-moz-xbl-content .thumb-box:-moz-xbl-content :-moz-xbl-content is needed twice, because the .thumb-box is anonymous content of the .thumb. This: box:-moz-xbl-content would match any anonymous box and :-moz-xbl-content box would match ant anonymous box that's not a child of unanonymous content.
I really start to like the way this is heading :-) However I have another proposal for selectors to match binded content: scrollbar$thumb { ... } would match any thumb elemente binded though a scrollbar binding. Or combinded with namespaces: scollbar$xul|thumb { ... } match any thumb element in the xul namespace binded though a scrollbar binding. And last: textbox$* { ... } *$box { ... } *$* { ... } All elements within a textbox binding, all binded boxes and all binded elements. This could also be used together with microsofts HTC or w3c's BECSS bindings. (some other character could be used instead of a $) In other words a great (IMHO :) ) addition for CSS3 selectors. However, I see three problems with this for mozilla: 1. Matching a thumb element within a box element in a scrollbar binding would look something like this (according to CSS2 combinators): scrollbar$box scrollbar$thumb { ... } which could become quite lengthy after a while. 2. what happens to bindings within bindings. Does button$box match all button-bounded boxes or just buttonbindings from the original document? Do we have to use calender$button$box Which would further worsen point 1. 3. w3c might want to use the $ (or whatever we choose) to do something else (i.e. we might not be forwards compatible). We could use something like thumb:-moz- bind(scrollbar) but that would too add to point 1. I think that any solution to problem 1 would require a even bigger overhaul of selectors syntax. Maybe something like scrollbar$( box thumb ) { ... } and calender$ (button$ (box title) ) { ... } Which when I think about it dosn't neccesarily have to rule out my original '$ proposal'. Ofcource none of this is needed to fix this bug but would be cool :-) Don't know how hard any of this would be, just wanted to bounce my ideas. Also I still think we need my originally proposed three modes for inheritence 1. Linked content isn't be affected at all by the original document style. (scrollbars) 2. Linked content will only inherit styles from it's "parent element". (textboxes) 3. Linked content is styled as if it belonged to the original document. (most chrome) 2 is needed for beeing able to style background and fontfamily of textboxes (I think). As a last question. What should happen to the <children/> of the binding? Wouldn't all this affect the <button> html element?
I have this bug fixed on my machine. Awaiting final review and approval from pierre and attinasi.
Yeehaa! Back to hyatt.
Assignee: pierre → hyatt
Status: ASSIGNED → NEW
Fixed. Hallelujah!
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
VERIFIED Win2K and Linux Comm M18 trunk builds 2000090609. If there are new bugs please file them separately.
Status: RESOLVED → VERIFIED
I see no patch here, so I can't guess how this bug was fixed, and whether any new bugs were filed separately (they must have been filed enough separately not to appear in "this bug blocks" list!), and what selectors should be used nowadays to style the scrollbars. So I'm stalled with bug 77790, without any starting point to fix it from. Give me some clue. Please.
The bug was that scrollbars *could* be styled. This was a bad thing mostly becase of the way thay were styled. A lot of things would affect the scrollbar even though the author had no intention of doing so. And even if you did it intentionally it could change from version to version how they were styled.
Blocks: scrollbar-colors
You're right. The problem here was that scrollbar could (in year 2000 and earlier days) be styled unintentionally, by applying perfectly legitimate rules in stylesheets of web documents. However, it seems to me that this bug is overfixed, now there's no enough obvious way to style the scrollbar even when there's a real intention. This blocks bug 77790, and I've just added a dependency. However, I am not sure that it can change from version to version how they were styled. Internally it may change; but once bug 77790 is fixed, there'll always be an intermediate chrome layer of some XPI extension that will lay in between and translate external scrollbar-*-color CSS properties to internal way of styling scrollbars.
Component: XP Toolkit/Widgets: XUL → XUL
QA Contact: ian → xptoolkit.widgets
You need to log in before you can comment on or make changes to this bug.