Re: Progress of css3-userint?

Ian Hickson <> wrote:

>> I would ask why they *do* belong in CSS.

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

XForms. And XLink for the behaviour of <a>. A web browser might want
to have some sort of internal generalisation so that both legacy
[X]HTML form elements and XForms-in-XML use the same code, but
I see no reason why this generalisation should become a W3

>> * it defines what a document looks like

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

These define how the document looks when in certain states; it does not
attempt to describe how it gets into those states, which is how I would
define 'how it acts'. There is nothing like -

  a {
    when-mousedown: go-into-active-state;
    when-click: follow-link-attr(href);

and neither should there be.

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

> The second [author-user compromise] and third [inheritance/cascade]
> definitely do.

How? A user stylesheet alters all <input> elements so that they're
read-only? A document specifies that all <div>s contained in a certain
<form> inherit the editability of their parents (although they can
never become successful controls)?

Can you give me a compelling use case where author-user compromise,
inheritance, or cascading between multiple sheets could possibly be
relevant to the properties outlined in 5.2-5.4?

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

Then what is the point? If it's a known language (or uses XForms, effectively
a known language), the UA will already know which elements are form controls
and can make them editable automatically.

It was my impression that the idea of XForms was to take over and
define form-field-like behaviour for all XML documents as a property of
elements in the XForms namespace. (Is this wrong?)

>> [toggle-group is silly]

> Just because CSS can be used doesn't mean that the <input> element loses
> all its intrinsic meaning.

So why provide it? Stylesheets are supposed to contain style. Toggle groups
are not style - they are behavioural content, essential to the purpose of
the document. It's taken us a long time to get all the style out of (HTML)
content. Let's not start putting content in the style.

[no, I'm not talking about the 'content' property, which, when used properly,
adds only style to a document - of course it is possible to abuse it...]

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

XForms already addresses this kind of question with its separation of model
and view. I see no reason it needs to be in CSS too. The only advantage of
having the view in the stylesheet would be to allow view-switching through
alternative stylesheets. But this can already be done by providing two views
onto the same model in XForms, and changing the visibility of each view
(this would also allow both views to be visible at once, which could be

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

I would very much hope that form encoding/submission syntax, links, image
maps etc. don't end up as functions of CSS. These are nothing whatsoever
to do with style, however convenient it may be to browser authors to put
them there.

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

Appearance of XForms controls is already addressed by CSS, including the
rest of the the userint draft that I have no problem.

What is the point of copying all form behaviour from XForms into CSS? You
are generalising a single case.

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

I think this is a mistake. more:

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

The implication is the styling is now exactly as dangerous as scripting. A
web site cannot permit user-submitted content with styles in, because those
styles can now contain (links to) active scripting, allowing various
cross-site-scripting exploits, cookie-stealing, etc. This was not the
case with CSS1 and CSS2, and authors have built sites with the (fair)
assumption that styling does not contain scripting.

I would like to be able to build (for example) a webmail system that can allow
users to read HTML mail. (HTML mail is daft, but that's not going to stop
people sending it, unfortunately.) If CSS contains scripting, I cannot do
this without including a full CSS parser to detect script-introducing
properties like 'behaviour'. And I have to keep up with the standard, updating
my code to take note of any new script-introducing CSS constructs that get
added to the spec. Not only that, but I have to account for all browser
CSS quirks. (For example:

  div { \behaviour: url(...); }

would normally be allowed through, as the backslash escape introduces a
0xBE character (VULGAR FRACTION THREE QUARTERS), and three-quarters-haviour
is not a known-dangerous property. However IE5/Win, which does not grok
backslash escapes, will ignore the leading backslash and use the property

This is just one example, and this sort of thing is already happening thanks
to IE's idiotic 'dynamic expressions' feature, which is not only broken by
design but also allows JavaScript to be executed from *any* CSS property;
plus the IE way allows javascript: pseudo-URLs in CSS properties that take a
URI. Almost every web forum system that allows the user to post markup is
currently vulnerable to JavaScript injection through various means, many
of them CSS-based.

The only sane solution for site authors is to say that stylesheets contain
only style, not scripting or links to scripting. This is what most people
would expect.

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

I wouldn't be so bold as to produce a proper proposal now, but a couple of
general approaches that come to mind are -

1. Binding sheets. Using a format that is basically the same as CSS,
   this takes advantage of W3 Selectors to connect behaviour to elements.

   input[type=password] { binding: url(behaviors:xforms/secret.xbl); }

   (behaviors: or something like that being an internal resource URI
   for getting at built-in behaviours.) 'binding' and any other properties
   used binding sheets *would not be available in standard document CSS*,
   and CSS properties would not be avilable in binding sheets. A possible
   alternative would be to skip the binding and bind events -

   input [type=password] { click: defaultHandlers.fieldClick; ... }

2. A per-language script. For each XHTML document loaded, a script hook
   could be called which would scan the document for elements and bind
   behaviours to them using document.addBinding or standard DOM2 event
   listeners. A useful method for this and plenty of other scripting
   activities would be 'document.getElementsBySelector'.

     var els= document.getElementsBySelector('input[type=password]');
     for (i= els.length; i-->0;)
       document.addBinding(els[i], '...');

   or with Events -

     var els= document.getElementsBySelector('input[type=password]');
     for (i= els.length; i-->0;) {
       els[i].addEventListener('click', defaultHandlers.fieldClick);
       els[i].addEventListener('keypress', defaultHandlers.fieldTextType);

   To deal with the problem of progressive loading, so the hook didn't
   have to be called repeatedly, a function could either use standard
   DOM Mutation Events to monitor each new element and possibly add
   behaviour to it (could be a bit slow), or there could be a method
   to monitor incoming elements for a selector match -

     function newSecret(el) {
       document.addBinding(el, '...');
     document.addNewElementListener('input[type=password]', newSecret);

   again, something like addNewElementListener would also be useful for
   general scripting purposes. Or there could even be a totally specific

    document.addBindingBySelector('input[type=password]', '...');

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

Okay, that's definitely an improvement. You'd also have to define -

  input[type=text(...etc...)][size] { width: attr(size, en); }
  input[type=submit(...etc...)][size] { width: attr(size, px); }

>> a new unit which is relative to the computed line height, or [...]

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

Hmm. I'm a bit wary of proposing significant changes to CSS to support
the legacy styling of HTML forms! I mean, <input size>, <select size>
and <textarea rows, cols> are completely presentational (even if they
are not deprecated), and none of the other presentational attributes
of HTML have been deemed worthy of emulation through CSS's base style

I'll leave it for now as a line-heights unit is probably not very
useful for anything other than hacking form field [size].

>> [control of scrolling]

> UI2 will have DOM methods for this purpose.

Great! I shall look forward to that.


Andrew Clover

Received on Sunday, 14 April 2002 13:31:58 UTC