Re: Progress of css3-userint?

Andrew Clover wrote:
 > Ian Hickson <> 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.

I'm not saying they do. I'm asking where you think they do.

 > The chief traits of CSS are:
 > * it defines what a document looks like

And, through :active and :hover, how the document acts.

 > * it allows the author and the user to compromise on how the document should
 > be styled

Very much so.

 > * it allows groups of related document parts to be styled together
 > conveniently through the mechanisms of inheritance and cascade

Very much so.

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

The second and third definitely do.

The first, given that some limited dynamic functionality is already in CSS (in
some form since CSS1), seems to also include more thorough UI-related styling.

 > 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?

Primarily the first and last.

 > The former case seems disastrous: you end up with documents containing forms
 > that can only work when the correct stylesheet is applied,

Only if the author is sending documents in unknown markup languages, a practice 
that is very much frowned upon in a public medium like the web.

 > and not overridden by the author in any way.

They can absolutely be overridden by authors (and users). That's one of the 
great values of CSS.

 > 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.

Why would it not work? Just because CSS can be used doesn't mean that the
<input> element loses all its intrinsic meaning.

 > If the properties are not meant for document authors, why make them available
 > to authors

A valid question. Some people (I'm leaving this explicitly vague) would like,
for various reasons, to share a common UI-describing language that is not
controlled by one entity. (So, e.g., XUL is no good because it is
Mozilla-specific). A convenient place to develop this is the W3C. One could make
the argument that these CSS features should not be usable by web authors.

It actually turns out, though, that these features can be useful. For example a 
<select> with a list of countries can be rendered as a drop down list, but it 
should also be possible for web authors to change that behaviour so that the 
<select> renders as a map.

 > Even in this case, the full behavioural properties of forms (how they work,
 > how they are submitted) will never be modellable in CSS.

Don't bet on it. As Tantek said, there are two UI specs being developed, one
based on the published UI spec, and one that goes _much_ further, the Advanced
UI module (UI2). The intent of the second is very much to model forms (along
with support from XForms and the DOM of couse).

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

Ah, but how is XForms styled?

 > Scripting seems the obvious approach.

Scripting is a big part of UI2.

 > Attach a behaviour to form field elements (via XBL or other means)

But how do you attach the XBL to your form control? IE and Mozilla currently do 
that through CSS.

 > which can handle clicks and keypresses and know what to do with them. [2]
 > [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 [...]

And that facility is in the form of CSS properties and DOM methods.

 > 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 is exactly the intent of UI2.

 > 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,

Please explain what the security implications are. Since both IE and Mozilla use 
this technique, your concerns are very relevant.

 > as well as not really being anything to do with styling.

I disagree. Whether a <select> element looks like a drop down or a map is very 
much styling. It's styling that requires script backup, but it is still styling.

 > 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.

Where would you suggest?

 > [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?

I believe toggle-group has been dropped altogether.

 > [3] - Namely, the incredibly ugly "height: attr(size)em"

That is going to be revisited.

It will probably look like 'attr(size, em)'.

 > 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]

An interesting idea. I suggest you propose this more formally in a separate post.

 > [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.

UI2 will have DOM methods for this purpose.

Ian Hickson
``The inability of a user agent to implement part of this specification due to
the limitations of a particular device (e.g., non interactive user agents will
probably not implement dynamic pseudo-classes because they make no sense
without interactivity) does not imply non-conformance.'' -- Selectors, Sec13

Received on Monday, 8 April 2002 14:29:41 UTC