55929 - Anonymous content should be able to style real children

Status: RESOLVED WONTFIX

(Core :: XBL, defect, P3)

Description

[Hixie (not reading bugmail)]

STEPS TO REPRODUCE
   1. View http://www.hixie.ch/tests/adhoc/xbl/002.html
   or
   1. Set some explicit style on an element, eg:
         h1 { font-weight: bold }
      ...(as happens with many elements in ua.css).
   2. Make that element a child of an element you are binding, eg:
         <div style="-moz-binding: url(...)"> <h1> ... </h1> </div>
      ...with the binding inserting another element around the <children/>.
   3. In the same stylesheet, make h1 inherit the style, eg:
         h1 { font-weight: inherit; }
   4. Observe the style of the element.

ACTUAL RESULTS
   Inheritance is ignored!!! The element in the case above would be bold.

EXPECTED RESULTS
   The cascaded value of the property (namely, 'inherit') should be used, and
   it should inherit from its anonymous content parent.

See the self explanatory testcase. This is quite a serious bug, since it means
that you cannot use elements that are mentioned in ua.css (most of the HTML
elements, for instance) with XBL by styling their parent.

Comment 1

[Hixie (not reading bugmail)]

As per our discussion, the bug is actually simply that the child element
is not matching the rule at all.

We need to change XBL so that children nodes of elements that are bound have 
multiple parents: the real, DOM parent, and each parent that inserted it as
a child. For example, if you have:

   <select>
     <option> 1 </option>
     <option> 2 </option>
   </select>

...and you bind <select> to:

   <div>
     <children/>
   </div>

...and bind <div> to:

   <span>
     <children/>
   </span>

...then the following rules should all match the (same!) option element:

   select > option
   select > div > option
   select > div > span > option

...assuming the current 'cut off' model (namely, that we don't).

Test cases:
   http://www.hixie.ch/tests/adhoc/xbl/005.html (anonymous content model case)
   http://www.hixie.ch/tests/adhoc/xbl/003.html (real content model case)
   http://www.hixie.ch/tests/adhoc/xbl/002.html (inheritance)

Comment 2

[David Hyatt]

I still feel like we need a different syntax though.  It doesn't feel right that 
the > selector would apply across scopes.  Just posting some ideas Hixie and I 
discussed into the bug as well...

>> - a new combinator that would handle crossing scopes.
:xbl - a pseudo that would match anonymous content

Comment 3

[Hixie (not reading bugmail)]

The problem with the rules being blocked off is that suddenly elements that
have known semantics lose their style. For example, in the case above, if
the <span> element was styled as have a blue border, then the following 
document:

   <p> <span> hello </span> </p> <div> world </div>

...would get a blue border around the hello, but not around the world. Fine,
you say, except when the binding is not just introducing an element, but an
element with important semantics such as <select>. There it is imperative that
we resolve the style from the author stylesheet, otherwise we would miss any
bindings, resulting in a document with some <select>s using a *totally*
different style than others. (This does make sense, if you don't believe me have
a look at my whiteboard. Oh no wait, I can't make head or tail of the 
scribblings on there at the moment... :-/)

[BTW: ua.css _always_ applies, as does userX.css, since they are from a 
different part of the cascade. You cannot block those off.)

Anyway, the problem is that there are still cases where even taking all that
into account, you still want to block off style: for example, to prevent
the universal selector from styling scrollbars, or an honest "div" rule from
styling an <input>. (For the record: both of those have occured, just search
Bugzilla for the dupes.)

And so we come to the problem: how to make it possible for documents to style
their scrollbars and inputs, without letting the universal selector do it.

And my answer (and one of the ideas Dave and I threw about today) is that you
only allow the author to override the binding, and then insert another 
stylesheet from within the binding.

For example, in the case of the <input>, you would do this (yes, this assumes
that we go to XBL widgets):

   input[type="text"] { -moz-binding: url(myInput.xml); }

...then in myInput.xml link to a stylesheet that styles your input, and say
that your binding extends the default input binding (no codelevel example, since
the syntax escapes me right now. Hyatt: Mail me your spec draft!!!).

So in summary: some bindings will block off style resolution, and to cross
scopes and style them anyway you bind a new XBL fragment that extends the 
existing one. This solves another problem -- how to know what the content will
actually be. Because if you don't explicitly pick it, you cannot guarentee what
frames you will be styling.

Off-topic rambling: the scrollbars are currently done in the C++ code. How 
would this work as an XBL solution: 

   ::viewport, textarea {
      -moz-binding { url(scrolledContent.xml); }
   }

...where scrollContent.xml creates content like this:

   <row> <cell><children/></cell> <cell><scrollbar type="vertical"/></cell>
   <row> <cell colspan="2"> <scrollbar type="horizontal"/> </cell> </row>

Would something like that work? If so, then it would allow authors to restyle
their scrollbars, and users to override this by making the relevant binding
bang-important, so everyone is happy... (this assumes that our implementation
makes the content a child of the ::viewport, I have no idea if this is true.)

Comment 4

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

How do you plan to implement 'overflow: auto' with such a scrollbars proposal?

I'm uncomfortable with applying rules from an author's stylesheet to anonymous
content that we generate.  What if the author indents all DIVs, and we create
DIVs in the middle of SELECTs?  Perhaps it would be better to:

 * do selector matching based on stylesheets linked from whatever created the
element (the document for normal content, the XBL for anonymous content, and of
course ua.css would be linked from both)

 * let inheritance run its course on the newly created tree, with the anonymous
content

Does that make sense?  I still don't know much about XBL...

Comment 5

[David Hyatt]

Hixie's point is that there are times when you want author stylesheets to affect
anonymous content.  Consider the case where I've customized the <select> on my
Web page so that any <select> widgets encountered will be green and puffy
(totally different from the default in ua.css).

Now I use an XBL widget that just happens to contain a table of <select>s.  Just
because the <select> widgets used by the composite XBL widget are anonymous,
that doesn't mean they shouldn't pick up the style specified by the author
stylesheet.  If they don't pick up the author styles, the widgets will clash
with the rest of the page.

If these XBL widgets have to be restyled or altered in order to be placed into
different Web pages, we've screwed up, because the XBL won't be reusable. I
think reusability is a fundamental goal of a language like XBL, so this doesn't
sit well.

In the current implementation the binding gets to decide whether to cut its
anonymous content off from the author sheets.  I do it with a boolean on the
binding.  It would probably be better to have some kind of new CSS property that
specified this, so that the author sheet that picks the binding could decide
whether or not it wants to let its styles apply to the binding.

One wacky idea (I think it is flawed, but I'll throw it out here anyway) I had
was to note the level in the sheet cascade at which the binding was applied, and
disallow any rules from later sheets to style anonymous content generated by the
binding.  For example, if the binding is attached through ua.css, author sheets
won't be able to style its content.  If the binding is attached through an
author sheet, then author sheets could style its content.  I think this is too
complex though.

Comment 6

[Hixie (not reading bugmail)]

> What if the author indents all DIVs, and we create DIVs in the middle of 
> SELECTs?  

There are two solutions (IMHO we should allow both):
   1. block all styles, and thus get control over what elements you are 
      introducing. This is the preferred solution for XBL that styles 
      the final bits of a document -- individual widgets like menu lists,
      buttons, text fields. (Note: Probably _not_ <select>s and file inputs,
      since they are usually made from individual widgets like menu lists, 
      buttons, and text fields!)
   2. use an element in your own namespace for the anonymous nodes that you
      don't want styled, and be ready to get styled by universal selectors.
      This means marking the rules you consider important with bang-important.


> How do you plan to implement 'overflow: auto' with such a scrollbars proposal?

Good point. Ok, so my suggestion only works for ::viewport. Forget TEXTAREA.
Anyway, let's move discussion about how to implement that into another bug or
into mail. (I suppose you could implement it for TEXTAREA using some JS in
the binding, using GetComputedStyle and so on.)


> One wacky idea [...]

er, no.


> It would probably be better to have some kind of new CSS property that [...]

I dunno. I think it's pretty much an attribute of the binding -- either it 
defines a 'node' (e.g., button, text field) where the implementation will be
very specific to some styles that it embeds, or it is a composite thing a bit
like a macro -- e.g., replacing <h1/> with <h1/> <ul/>. (This last case is what
I am using XBL for in "My First XBL", http://www.hixie.ch/, which is the basis 
for most of my current adhoc testing.)

I personally think doing it as an attribute of the <binding> is more sensible.
If the author wants to override it, he can always bind to a new XBL file which
extends the previous one and only changes the scope attribute.

Comment 7

[Peter Trudelle]

rtm-/future

Comment 8

[David Hyatt]

Hixie and I had an idea of using two different attributes on the <binding> to
refine how styling works.

applyauthorstyles would be used to determine whether or not the author sheets
would be walked when resolving style on an element.

styleexplicitcontent would be used to enable a binding to style the explicit
children of the bound element.

Comment 9

[Hixie (not reading bugmail)]

summary:
   need to implement |applyauthorstyles|
   need to implement |styleexplicitchildren|
   need to make selector matching check for all parents (anonymous and explicit)

Should they be split into separate bugs? What's the ETA on this? Do you need
more test cases? This is blocking my hixie.ch work... ;-)

Comment 10

[Greg K.]

Reconfirmed using FizzillaCFM/2002070913. Setting All/All.

Comment 11

[Justin Wood (:Callek)]

   need to implement |applyauthorstyles|
   need to implement |styleexplicitchildren|

Would this be a new property or a new addition to -moz-binding: 
such as:

`-moz-binding: url(...) [ applyAuthorStyles | styleExplicitChildren ]`

Comment 13

[Declan Naughton]

(In reply to comment #9)
> summary:
>    need to implement |applyauthorstyles|
>    need to implement |styleexplicitchildren|
>    need to make selector matching check for all parents (anonymous and explicit)
> 
> Should they be split into separate bugs? What's the ETA on this? Do you need
> more test cases? This is blocking my hixie.ch work... ;-)

This was a good plan. Any chance of it finally happening for 1.9? XBL 2.0 isn't making 1.9 afaik, and hopefully it's implementation will _obey_ the spec (somehow, applyauthorstyles and styleexplicitchildren made their way in :S ).

Comment 14

[Michael Kohler [:mkohler]]

This is a mass change. Every comment has "assigned-to-new" in it.

I didn't look through the bugs, so I'm sorry if I change a bug which shouldn't be changed. But I guess these bugs are just bugs that were once assigned and people forgot to change the Status back when unassigning.

Comment 15

[Boris Zbarsky [:bzbarsky]]

XBL is now disabled in Firefox (Bug 1583314) and is in the process of being removed from Gecko (Bug 1566221), so closing bugs requesting changes to its implementation as wontfix.