Re: CSS/XBL Dependencies

Ian Hickson wrote:
> Or, to take an example from the other thread, if authors start using
> bindings to override <select> elements to submit on a "change" event
> (something I think many authors would be eager to do), then users can
> override this behaviour with their own binding that doesn't submit until
> the user presses the submit button.

Suppose I write a page where <select> is bound via XBL
so it submits on change. In the form, I also have a
submit button for browsers without XBL. However, the
ideal design I want requires no submit button. Therefore,
I need to assign "display: none" to the submit button.

   - If the XBL binding is in a CSS sheet, then the "display:
     none" would get applied whether or not the UA supports
     the XBL binding. The form cannot be submitted.

   - If the XBL binding is in a special Binding Sheet along
     with the CSS for making the submit button "display:
     none", then only UAs with XBL support enabled will
     make the submit button disappear.
      ~ In an XBL-enabled UA, the binding takes effect, the
        "display: none" takes effect, and the form can be
      ~ In other UAs, the binding does not take effect, but
        the "display: none" also does not take effect, and
        the form can be submitted.

   - However, if the user overrides the binding on <select>
     with an !important rule but leaves general XBL and CSS
     support on, the form cannot be submitted.


This is an example of dependency between two CSS rules.
If one goes and the other stays, the result is worse than
having neither. It's a problem that shows up in pure CSS
as well, but not so severely. (You might wind up, for
example, with white text on a white background. This has
been brought up before. [1])

Does XBL have a way to avoid this situation?
The more general question would be "how can CSS's cascading
be adjusted to handle such dependencies?"

There's also the case where the binding is not overridden,
but scripting is disabled.



Received on Tuesday, 7 January 2003 23:27:52 UTC