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.