Re: Progress of css3-userint?

Ian Hickson <ian@hixie.ch> wrote:

>> ...sections 5.2 - 5.4, which don't belong in a styling language IMO...

> As the editor of the "Advanced UI" spec (aka "UI2"), I am curious as to
> where you believe such properties actually belong.

I would ask why they *do* belong in CSS. The chief traits of CSS are:

 * it defines what a document looks like
 * it allows the author and the user to compromise on how the document
   should be styled
 * it allows groups of related document parts to be styled together
   conveniently through the mechanisms of inheritance and cascade

None of these apply to behavioural properties such as those proposed in
userint-20000216 5.2-5.4.

Are the properties even intended to be used by document authors, or are
they simply there to make XHTML slightly more like generic XML, for the
benefit of browser implementors? Or are they intended to make defining
new applications of XML with forms capabilities easier?

The former case seems disastrous: you end up with documents containing
forms that can only work when the correct stylesheet is applied, and
not overridden by the author in any way. Specifying an
<input type="radio">'s 'toggle-group' [1] in a stylesheet means the form
simply won't work in a non-CSS user agent, quite unnecessarily.

If the properties are not meant for document authors, why make them
available to authors? It will only encourage misuse. Even in this case,
the full behavioural properties of forms (how they work, how they are
submitted) will never be modellable in CSS.

In the latter case, isn't the idea to have all future XML-based forms
capabilities supplied by XForms anyway?

> Could you explain what alternative ideas you have?

Scripting seems the obvious approach. Attach a behaviour to form field
elements (via XBL or other means) which can handle clicks and keypresses
and know what to do with them. [2] One could even build the submission
process and link behaviour out of scripting attached to those elements,
removing the need for any special-casing at all. (This would be
'user-scripting', not turned off when 'author-scripting' is disabled.)

Whatever the solution, it should be tied to the language at use -
XHTML now, XForms later - and not to the single document in question.

As far as I can tell, the attraction of using CSS in this case is that
it can leverage W3C Selectors as a mechanism for choosing the elements
to affect. This is also the idea behind XBL's 'binding' property and
BeCSS's 'behavior' property, both of which I find extremely dangerous
from a security point of view, as well as not really being anything to
do with styling. I do not want hidden scripting lurking in my
stylesheets.

It would be useful to have a mechanism for binding behaviour to elements
that match a selector without having to put it in a stylesheet, where it
patently does not belong.

Having said all this, I must emphasise that I do agree in spirit
with the rest of the css3-userint spec, which concerns itself with
presentation. Though I might quibble with minor details [3], it's
clearly heading in the right direction, and I hope a new revision
will be available soon.

Thanks to yourself and Tantek for keeping us in touch!

[1] - I notice in the Base Style Sheet, toggle-group is applied to
      checkbox as well as radio; is this a simple mistake or has
      something been redefined?

[2] - One would probably want to add the facility to call some
      built-in handler code rather than having to rely on JavaScript
      code and DOM manipulation for each keypress in a text field, for
      efficiency's sake and to allow for things that cannot be expressed
      in DOM scripting, such as drag-and-drop of selected text outside
      the browser.

[3] - Namely, the incredibly ugly "height: attr(size)em". Apart from
      the nastiness of the implication that the attr() is replaced
      before parsing the rest of the value as a length (which
      could be relieved by introducing a limited form of CSS
      expressions[4]), it wouldn't even work for values of
      line-height other than '1em', which is not the default
      value for line-height. The only way around this I can think
      of for the moment would be to introduce a new unit which is
      relative to the computed line height, or to interpret unitless
      values of 'height' that way.[5]

[4] - eg. "height: 1em*attr(size)". I think there's a lot to be
      said for CSS expressions, if well-defined and limited to
      properties currently defined as <length>. As well as the
      expected operators +, -, * and / (the latter two being slightly
      limited as one of their operands must be a unitless number, not
      a length), it would also be useful to have 'maximum of a and b'
      and 'minimum of a and b' operators, and a 'round down to the
      nearest multiple of' operator. These could obsolete min-width
      etc. properties and make their advantages available to any
      of the other properties. For example, one could ask for fonts
      at 0.75em but no smaller than 9px by saving something like
      "font-size: 0.75em>9px;", '>' being an operator returning
      the greater of its operands. But anyway, that's wandering
      way off topic.

[5] - also related to <select> elements: there is currently no way to
      scroll elements to ensure that the selected option(s) are currently
      displayed, which would make select-one controls pretty useless.
      It would be useful in general to have CSS and/or DOM control
      over the scrolling of elements with overflow.

[6] - enough already!

-- 
Andrew Clover
mailto:and@doxdesk.com
http://and.doxdesk.com/

Received on Monday, 8 April 2002 10:45:04 UTC