Re: CSS 4?

Ian Hickson wrote:
> On Sun, 26 Oct 2003, Dylan Schiemann wrote:
> 
>>>BECSS bindings and similar technologies are designed to add stylistic
>>>(albeit quite involved) look and feel to documents.
>>>
>>>They are not designed to add semantics to the document.
>>
>>Yes, but the flexibility of XBL seems to encourage it (the script
>>element for example).
> 
> 
> No more so than the flexibility of class attributes encourages its own
> abuse, IMHO.

For annoying abusive cases, I feel that this obfuscates the fact that it 
is JavaScript that is causing the annoying behavior.

>>>For example, BECSS-like technologies could be used to bind the logic to
>>>XForms controls. No new semantics -- the XForms controls already have the
>>>XForms semantcs -- but a look and feel (and in this case logic) that
>>>implements those semantics.
>>
>>Sure, but why do this through css, and not through the dom using
>>addBinding()
> 
> Because (and this is the litmus test that proves the binding is
> presentational and not semantic) you want different bindings depending on
> the media type of the document. And even on the same media, you want to be
> able to use different bindings for different alternate stylesheets. For
> example a "cute" stylesheet could use a binding which showed bouncing
> bunnies next to :invalid form fields, and hovering on the bunnies could
> cause the bunnies to walk into the form field and "fix" the error; while a
> "business" stylesheet could use a binding that should showed a red border
> and displayed a dialog box when the user exit the field.
> 
> Both cases are conveying the same _semantics_, which were originally set
> out in the XForms specification. However, they are giving the user a
> different presentation, look, and feel. They are thus stylistic.

In the non-annoying case, sure.

>>(besides the obvious fact that it is often easier to describe a set of
>>elements through css selectors than through DOM, though maybe DOM XPath
>>resolves this?  maybe DOM Style/CSS needs to be fixed to be able to
>>select the same things as css selectors?  getElementsByCSSSelector ?)
> 
> 
> It's also a lot easier to do:
> 
>    <style type="text/css">
>     @namespace url(http://example.net/);
>     section { binding: url(bindings#collapsable-sections); }
>    </style>
> 
> ...than:
> 
>    <script type="text/javascript">
>     var sections = document.getElementsByTagNameNS('http://example.net/',
>                                                    'section');
>     for (var index = 0; index < sections.length; ++index)
>        sections.addBinding('bindings#collapsable-sections');
>    </script>

Perhaps it could be simplified to something like

     <script type="text/javascript">
      var sections = document.getElementsByTagNameNS('http://example.net/',
                                                     'section');
      document.addBinding(sections,'bindings#collapsable-sections');
     </script>

or

     <script type="text/javascript">
document.addBindingByNS('http://example.net/','section','bindings#collapsable-sections');
     </script>

or

     <script type="text/javascript">
document.getElementsByTagNameNS('http://example.net/','section').addBinding('bindings#collapsable-sections');
     </script>


>>Seems that using uri for 'content' is comparable depending on what is
>>allowed in uri (which isn't clear in css2.1 in my opinion).  For
>>example, could the uri be a document fragment?  If so, could it contain
>>a stylesheet to define style rules for the inserted content?
> 
> 
> The result of:
> 
>    div { content: url(http://example.com/#test); }
> 
> ...is _visually_ equivalent to:
> 
>    <iframe src="http://example.com/#test"/>
> 
> ...although of course the semantics are very different.

interesting.  I had not realized content could allow so much to be 
added.  Makese sense... just never considered it.

>>I agree that it is nice to have this.  What happens when bindings are
>>added using the addBinding method?  Is this the equivalent of adding a
>>statement at the end of the stylesheet?  Can a binding be added/removed
>>using the DOM 2 CSS StyleSheet interface's insertRule/deleteRule instead
>>of DocumentXBL's addBinding?  I guess my real question here is how do
>>DocumentXBL and StyleSheet interact?
> 
> 
> The above should all be explained at:
> 
>    http://www.w3.org/TR/xbl/
> 
> If it isn't, it would be defined before such a spec went to REC.

It wasn't clear after a quick read.  For example, I read this "A binding 
attached through CSS cannot be removed using removeBinding.", but wonder 
what would happen if I used deleteRule.  I'm assuming that it would 
remove the binding, and fire any binding related events, but it is 
unclear how the interaction with DOM 2 CSS works from the spec.

>>Say for the sake of argument that I were to define an xml syntax lxbl
>>(lesser xbl) whose sole purpose was to list pairs of event type and
>>event handlers (in other words a small subset of xbl).  Would it make
>>sense to use css to bind these defintions to selectors?  I would say no,
>>that it should be done through the DocumentLXBL interface, or through
>>some other css-like document that supports selectors, but that isn't
>>css.  At least that would feel "cleaner" to me.
> 
> 
> Well, if the language was designed to do stylistic things, then it would
> make sense to have CSS bind to it.
> 
> For example, a binding which handled onmousemove and changed the style of
> the element based on the position of the pointer with respect to the
> element, would be purely stylistic, and so would belong in CSS. If, on the
> other hand, the binding defined the form validation logic for an onsubmit
> event, then it would make sense for it to either be defined directly
> within the document, or have the external logic bound to the form using
> inline script. (Note that the first example is basically a fancy :hover,
> while the second is a fancy onsubmit="" handler. The bindings logically
> belong in the same place as their simpler cousins.)

So css selectors then are only to be used for style?  I thought that one 
of the goals of css selectors was to create a general selection 
mechanism.  If that's the case, then where would one use such a 
selection mechanism for non-styling purposes.

>>Whatever, though, I think I'm in the minority on this.
> 
> 
> Being in the minority isn't a problem, if you're right! In this particular
> case, I'm not convinced that you are, though. :-)

I'm not convinced that I'm right either.  I just feel that the lines of 
style and structure are being blurred.  My secondary points are 
wondering if selectors can/should be used for other purposes and how, 
and the interaction of DOM XBL with DOM CSS.

-Dylan

--
Dylan Schiemann
http://www.dylanschiemann.com/
http://www.sitepen.com/

Received on Wednesday, 29 October 2003 16:15:05 UTC