Closed Bug 312509 Opened 19 years ago Closed 6 years ago

[meta] External CSS should not style XBL binding innards.

Categories

(Core :: XBL, defect)

Product:
Core
Component:
XBL
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WONTFIX

People

(Reporter: pythonesque+bugzilla, Assigned: pythonesque+bugzilla)

Details

(Keywords: meta) 

There should be a way to limit a CSS selector string to styling only the
children in the anonymous content of a single XBL widget.

To clarify, currently we have can either style using child selectors (>) and be
broken whenever anyone changes the widget structure even slightly, or we can use
descendent selectors and wreak havoc on things outside the widget.  The proposed
selector would simply limit the effects of any styles applied by it to elements
within the widget's anonymous content.  It would also be limited to a single
binding instance, to further limit its effects.

At this point, I was thinking that the selector should (A) only style classes,
and (B) not be a simple operator.  Though there are probably better ways
syntactically to do this, I thought that treating it as a pseudo-element was
appropriate: "::-moz-binding-content(className)".

Implementing something like this would help solve a lot of XBL structural
dependency problems (or at least reduce them), as well as make changes to the
XBL structure more plausible (e.g. if this were in use, the patch for bug 243078
would have had a much better chance of getting in).  If any drivers think this
should be WONTFIX, though, please tell me soon so I don't waste any time working
on it.
Are we talking about scoped stylesheets?  Or sheets outside the XBL binding that
want to style the innards of the binding?
The idea was for stylesheets outside the XBL wanting to apply stuff to the
innards of the binding without relying on a specific structure, instead only the
class (or some other identifier if deemed better).
Why are stylesheets outside of XBL _ever_ styling the innards of bindings? 
Isn't this why we have scoped stylesheets?
I'm not sure I know exactly what you mean by 'scoped stylesheets' [1], but as
far as I can see CSS outside of the bindings must be able to apply /some/
effects to the inner content. The current place I have in mind is where
browser.css enforces a maximum size on the images displayed next to bookmark
menu items.

You are welcome to fix the current places in our CSS where the innards are
directly styled, if that is your stance on the issue. This bug was only an idea
to clean up the existing "looking inside" that is done, and make it much more
resiliant to changes in the XBL.

[1] My assumption, for lack of any finable definition, is a stylesheets that is
attached to the XBL binding inside <resources/>, and only applies to the
anonymous content of the binding.
> I'm not sure I know exactly what you mean by 'scoped stylesheets'

The stylesheets in the <resources> section.

> CSS outside of the bindings must be able to apply /some/ effects to the inner
> content

Why?  I agree that it should be possible to affect the behavior of the binding
from outside in ways that the binding allows.  Direct application of CSS is not
really a good way of doing that, though, since as you pointed out it requires
making assumptions about the internal structure of the binding.  It sounds like
this bug is a proposal to be able to make fewer assumptions, but imo the right
thing to do is to not make any assumptions at all.

> The current place I have in mind is where browser.css enforces a maximum size
> on the images displayed next to bookmark menu items.

The binding should be exposing an API for this, imho.
(In reply to comment #5)
> ...but imo the right thing to do is to not make any assumptions at all.
> The binding should be exposing an API for this, imho.

Can you suggest a way to do that? Myself and Joshua did discuss this
possibility, before falling back to the classname association, but we couldn't
see a way to do it that didn't have its own problems. Two of the ideas were:
  1. Have some equivelant to xbl:inherits, which lets you pick which anonymous
     element properties set on the bound element apply to.
  2. Similar, but specify custom property names that apply as standard
     properties on designated anonymous elements.
How about if you create chrome://browser/content/bookmarks.xml that would extend
the global menu{item} bindings by tweaking the content and adding a new scoped
stylesheet which would handle the drag effects, image size etc.
> Can you suggest a way to do that?

There are several possible ways depending on what's desired.  Most simply, the
binding could expose a property that you could set.  That might not work so well
for theming, though, which I assume is what's desired?

If you want things to work with theming, the simplest thing to do, imo, is to
have the scoped stylesheet for the binding import a skin sheet so as to allow
themes to insert styles specifically into this one binding.  Then have
documentation as to what classes the binding will set on which parts of itself, say.

I can try to come up with something more convoluted if those don't work, but
then you'd have to explain your use case.
Hm, I was going to write another response, but that sounds good.

So basically the issue, as you see it, is currently in two parts:

  1. Fix all the actual cases where internal XBL content is styled by external
CSS by replacing them with extra scoped stylesheets (I don't *think* it should
be necessary to create entire new widgets for most of this stuff, Neil, and I
want to deal with more than just the bookmarks anyway).
  2. Add an overridable scoped stylesheet reference so that themes wouldn't need
a new selector to make the widgets work properly, plus documentation.

If Silver doesn't disagree, then, this would become something of a meta-bug for
fixing each of the widgets that are currently being badly styled for each of
those two points.  Sounds good to me, and it would help keep this working for
theme authors (which was the main thrust of my original reply).  We should come
up with a list of the places that this happens, then file a bunch of bugs for
the affected widgets.  I should be able to get around to this soonish.
Yeah, that sounds about right.  Thanks for taking this on!
Assignee: general → pythonesque+bugzilla
Severity: enhancement → normal
Keywords: css-moz → meta
Summary: [RFE] CSS Selector for XBL Anonymous Content → External CSS should not style XBL binding innards.
Apart from that not helping any of the issues that currently exist...

As an example, menu.xml already loads chrome://global/skin/menu.css, which as
far as I understand is what you just proposed adding.

The problems exposed in the current setup are that the theme's menu.css has to
know the exact internal structure of the binding, which the original suggestion
here would help. The other problem I know of is things like messengercompose.css
or addBookmark.css (or browser.css), where some CSS (in the theme) is only
attached to one window, but wishes to style the binding in some way.

Can you explain how what you proposed will help in any of those cases?
Silver and I went over the scoped stylesheet code, and as well as we could make
out it does "smart scoping".  That is, from what we could see, scoped stylesheet
selectors can see external content, but only the XBL bindings' inner contents
are actually styled.

The purpose of this bug was to make the XBL bindings more resilient to change as
well as to get rid of the bad references.  As it is, the scoped stylesheets use
child selectors, which doesn't help at all.  Is there a pressing reason why this
is the case?
Also, how do we deal with app-specific bindings under the proposed plan?  We
can't just import everything in browser/ or communicator/.  In these cases (e.g.
smilies in Thunderbird) there is no way that I know of to import the correct
stylesheet for the given application, so that while themes could override it the
application could not.  This is more critical than ever given that we're
supposed to be transferring to XULRunner, and shouldn't be introducing any more
dependencies on Firefox or Thunderbird.  Under these circumstances, external
styling of the widget CSS is necessary.  So the original idea may still be
required, at least some of the time.  Please tell me if I'm mistaken about this
being an issue.
Bz, see previous comments.
> The problems exposed in the current setup are that the theme's menu.css has to
> know the exact internal structure of the binding, which the original suggestion
> here would help.

How?  That is, how is ::-moz-binding-content(className) as you proposed
different from just using .className in the scoped stylesheet?

> where some CSS (in the theme) is only attached to one window, but wishes to
> style the binding in some way.

My point is that bindings that want to allow their insides to be styled should
import a theme sheet that would then style them...  If someone wants to style a
binding that doesn't really want to be styled, then things will sometimes break,
yes.  But that's because the binding author is making that decision.

> That is, from what we could see, scoped stylesheet selectors can see external
> content, but only the XBL bindings' inner contents are actually styled.

That is correct.

> Is there a pressing reason why this is the case?

You mean existing scoped stylesheets?  Probably no good reason...

> there is no way that I know of to import the correct stylesheet for the given
> application

Sounds like we need a resource URI for this, in the gre resource section? 
Benjamin, what do you think?  Or am I misunderstanding the issue here?
QA Contact: ian → xbl
The meta keyword is there, the bug doesn't depend on other bugs and there is no activity for 12 months.
:bgrins, maybe it's time to close this bug?
Flags: needinfo?(bgrinstead)
Summary: External CSS should not style XBL binding innards. → [meta] External CSS should not style XBL binding innards.
Resolving this, as we've now removed all XBL stylesheets (Bug 1470830). That work covers (1) in Comment 9, and (2) is a wontfix at this point - we're planning to use Shadow DOM for anonymous content and we've got Bug 1505489 on file to implement the CSS Shadow Parts spec for chrome which will let document sheets override anonymous nodes as needed.
Status: NEW → RESOLVED
Closed: 6 years ago
Flags: needinfo?(bgrinstead)
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.