Hi,
Would the CSS community and working group object to the XBL2 specification
including the following two CSS features?
First, a 'binding' property, defined to take a list of one or more <url>s
or the keyword 'none', which would act as a binding mechanism to specify
one or more XBL bindings to apply to an element.
Second, a pseudo-class ':xbl-bound-element' that matches an XBL bound
element.
The proposed processing model for these features is described in the XBL
specification, which you can find at either of these locations:
http://dev.w3.org/cvsweb/~checkout~/;%20charset=utf-8
Currently the features using the "-xbl-" vendor prefix. It would be nice
to not require this.
FWIW, I am not aware of any conflicts between these XBL features and the
CSS2.1 or Selectors specifications. (The fact that I'm one of the editors
of all three makes that statement slightly more relevant! :-) )
Please let me know if there are any objections. The current plan is for
XBL2 to go to Last Call sometime around mid-September.
Cheers,

Mon, 14 Aug 2006 00:50:30 -0700, Ian Hickson <ian (AT) hixie (DOT) chwrote:
Second, a pseudo-class ':xbl-bound-element' that matches an XBL bound
element.

Can't we make that ':bound-element'? And let other binding languages, if
ever, reuse that pseudo-class just as they can reuse the proposed
'binding' property? Would make sense to me.

Mon, 14 Aug 2006, Anne van Kesteren wrote:

Mon, 14 Aug 2006 00:50:30 -0700, Ian Hickson <ian (AT) hixie (DOT) chwrote:
Second, a pseudo-class ':xbl-bound-element' that matches an XBL bound
element.

Can't we make that ':bound-element'? And let other binding languages, if
ever, reuse that pseudo-class just as they can reuse the proposed
'binding' property? Would make sense to me.

I would be fine with that, if the rest of the community is ok with it.

Mon, 14 Aug 2006, Anne van Kesteren wrote:

Mon, 14 Aug 2006 00:50:30 -0700, Ian Hickson <ian (AT) hixie (DOT) chwrote:
Second, a pseudo-class ':xbl-bound-element' that matches an XBL bound
element.

Can't we make that ':bound-element'? And let other binding languages, if
ever, reuse that pseudo-class just as they can reuse the proposed
'binding' property? Would make sense to me.

I would be fine with that, if the rest of the community is ok with it.

Wed, 16 Aug 2006 11:41:23 -0700, Matthew Raymond
<mattraymond (AT) earthlink (DOT) netwrote:
Thought:

| ::bound-element(xbl2) { /* For XBL 2.0. */ }
| ::bound-element(-moz-xbl) { /* For Mozilla XBL 1.0. */ }
| ::bound-element(-ms-htc) { /* For Microsoft HTML Components. */ }
| ::bound-element() { /* For ANY binding language. */ }

As in "::bound-element(binding-language)" to indicate which one
you're binding to, with the default being any language if no value is
specified.

For one, it shouldn't be a pseudo-element. And what's the use of doing it
per binding language? Why would styling be any different? And why would
you want to have multiple binding languages

Wed, 16 Aug 2006, fantasai wrote:

Well, either both things should get "namespaced" nor neither of them
should.

Mm, does the spec address these?

:bound-element { binding: none; }

Same as:

:hover { display: none; }

foo { binding: something-with-value-pseudo; }
::value { binding: something-else; }

Same as:

foo { binding: something-with-foo; }

in the something-with-foo binding's stylesheet.

::value { binding: something-with-value-pseudo; }

Same again.

# each time a binding is applied it can change the computed values of
# properties of elements that are descendants of the bound element

By "properties" do you mean just "CSS properties", or does that include
the 'binding' property as well?

'binding' is a CSS property (assuming that the community has no
objections).

I'm not convinced that XBL binding statements should be mixed
indiscriminately with the rest of CSS.

People seem in two minds about this; Daniel, for example, posted on this
thread with a very passionate plea to indeed mix them.

The XBL binding process happens before CSS styling takes effect.

This is a misunderstanding.

I don't mind putting these bindings in a text/css file, but I would like
to see them explicitly separated out from the rest of the CSS rules,
perhaps in an @rule that is always placed before any regular CSS rules.

That seems overly complex for no good reason. (Where I don't consider
theoretical purity "good".)

Wed, 16 Aug 2006, Matthew Raymond wrote:

Thought:

| ::bound-element(xbl2) { /* For XBL 2.0. */ }
| ::bound-element(-moz-xbl) { /* For Mozilla XBL 1.0. */ }
| ::bound-element(-ms-htc) { /* For Microsoft HTML Components. */ }
| ::bound-element() { /* For ANY binding language. */ }

As in "::bound-element(binding-language)" to indicate which one
you're binding to, with the default being any language if no value is
specified.

What's the use case?

Wed, 16 Aug 2006, Matthew Raymond wrote:

Good point. For the moment, I can't think of a use case, except to
correct rendering problems for proprietary binding language
implementations, which seems kinda weak to me.

So, a general guideline when coming up with stuff first come up with a
use case (a "problem"), then try to invent something (find a "solution").

It tends to make better specs. :-)

fantasai wrote:
I don't mind putting these bindings in a text/css file, but I would
like to see them explicitly separated out from the rest of the CSS
rules, perhaps in an @rule that is always placed before any regular
CSS rules.

@import "foo";
@bindings {
input.special { binding: url("mybinding"); }
}

I somewhat agree with Ian that this adds too much complexity, but it has
given me an idea.

It would be useful to be able to import bindings from CSS, much like the
<?xbl?PI does. The benefit of this would be that, unlike the PI, it
could be used in HTML. Presently, the only way to import a binding into
HTML is to call document.loadBindingDocument(); in a script.

What about using this?

@binding url(/binding/example.xbl);
@binding "/binding/example.xbl"

perhaps just extending @import to support importing bindings.

IM the binding property is simple and well-specified. I don't
really see a need for additional complexity in the CSS syntax.

dave

Aug 16, 2006, at 8:26 PM, Lachlan Hunt wrote:

fantasai wrote:
>I don't mind putting these bindings in a text/css file, but I
>would like to see them explicitly separated out from the rest of
>the CSS rules, perhaps in an @rule that is always placed before
>any regular CSS rules.
>@import "foo";
>@bindings {
>input.special { binding: url("mybinding"); }
>}
>
I somewhat agree with Ian that this adds too much complexity, but
it has given me an idea.

It would be useful to be able to import bindings from CSS, much
like the <?xbl?PI does. The benefit of this would be that,
unlike the PI, it could be used in HTML. Presently, the only way
to import a binding into HTML is to call
document.loadBindingDocument(); in a script.

What about using this?

@binding url(/binding/example.xbl);
@binding "/binding/example.xbl"

perhaps just extending @import to support importing bindings.

Wed, 16 Aug 2006 20:33:45 -0700, David Hyatt <hyatt (AT) apple (DOT) comwrote:
IM the binding property is simple and well-specified. I don't really
see a need for additional complexity in the CSS syntax.

Note that he's proposing an additional feature, as I understand it. I
suppose that doing @binding url() will load the binding document and than
for each binding associate it with the element given in element=""
attribute.

dave

Aug 16, 2006, at 8:26 PM, Lachlan Hunt wrote:
>
>>
>fantasai wrote:
I don't mind putting these bindings in a text/css file, but I would
like to see them explicitly separated out from the rest of the CSS
rules, perhaps in an @rule that is always placed before any regular
CSS rules.
@import "foo";
@bindings {
input.special { binding: url("mybinding"); }
}
>>
>I somewhat agree with Ian that this adds too much complexity, but it
>has given me an idea.
>>
>It would be useful to be able to import bindings from CSS, much like
>the <?xbl?PI does. The benefit of this would be that, unlike the PI,
>it could be used in HTML. Presently, the only way to import a binding
>into HTML is to call document.loadBindingDocument(); in a script.
>>
>What about using this?
>>
>@binding url(/binding/example.xbl);
>@binding "/binding/example.xbl"
>>
>perhaps just extending @import to support importing bindings.
>>
>Hunt
>http://lachy.id.au/
>>
>

Anne van Kesteren wrote:
Wed, 16 Aug 2006 20:33:45 -0700, David Hyatt <hyatt (AT) apple (DOT) comwrote:
>IM the binding property is simple and well-specified. I don't really
>see a need for additional complexity in the CSS syntax.

Note that he's proposing an additional feature, as I understand it. I
suppose that doing @binding url() will load the binding document and
than for each binding associate it with the element given in element=""
attribute.

Yes, that's correct. I have no problem with the 'binding' property,
though I did share Fantasai's concerns about the loops caused by using
:bound-element { binding:none; }.

Ian Hickson wrote:
Wed, 16 Aug 2006, fantasai wrote:
>Mm, does the spec address these?
>
>:bound-element { binding: none; }

Same as:

:hover { display: none; }

Doesn't :bound-element suffer from the same problem as the oft requested
:column pseudo-classed, based on the the display: table-*; properties?
You said it yourself in July last year:

| The problem is that a cell *is not a cell yet* when doing selector
| matching. Short of doing selector matching twice (once for one set of
| properties, and then again for another set, with a required layout
| pass in between the two steps) you simply cannot have selectors that
| depend on properties. And as I explained a few days ago, doing the
| two-pass selector matching simply isn't an option, as it would be a
| performance nightmare.

Why doesn't this same argument apply to 'binding' and :bound-element?

Thu, 17 Aug 2006, Lachlan Hunt wrote:

It would be useful to be able to import bindings from CSS, much like the
<?xbl?PI does.

This will probably in due course be possible using <link rel="bindings">.
It can't really be done through CSS due to problems that causes with the
processing model. (It shouldn't really be done using <linkeither, which
is why the XBL2 spec doesn't say that yet; I need to resolve some problems
and will probably add something to HTML5 to do it.)

Thu, 17 Aug 2006, Lachlan Hunt wrote:

| The problem is that a cell *is not a cell yet* when doing selector
| matching. Short of doing selector matching twice (once for one set of
| properties, and then again for another set, with a required layout
| pass in between the two steps) you simply cannot have selectors that
| depend on properties. And as I explained a few days ago, doing the
| two-pass selector matching simply isn't an option, as it would be a
| performance nightmare.

Why doesn't this same argument apply to 'binding' and :bound-element?

Because the bound element is bound asynchronously. It isn't the 'binding'
property that makes the element be a bound element, it's the actual
binding. It's much more like the ":hover { display: none; }" case that I
mentioned, where the fact that the element no longer matches :hover is a
side-effect, not a direct effect, of the 'display' property.

Monday 14 August 2006 09:50, Ian Hickson wrote:

Would the CSS community and working group object to the XBL2
specification including the following two CSS features?

I don't mind adding some more behavior to CSS. (E.g., I'd like to have
collapse/expand for the <nlelement of XHTML2; :hover is not enough
for that.) But I do worry that the behavior added via an XBL binding is
procedural (through JavaScript) instead of declarative and especially
that it makes XBL and JavaScript requirements for implementing CSS.

Currently, CSS requires only some image format (which one isn't
specified, but pretty much every implementation supports JPEG and PNG):
no need for a JavaScript interpreter, no need for an XML parser nor an
XBL interpreter.

My preferred solution is to list the behaviors that are most needed
(collapsing elements, various hyperlink behaviors) and add just those.
Maybe something like 'p:activated {content: "Click to collapse me"}'.

If somebody wants other behaviors, he probably meant to write a program
rather than a document.

There currently is no good language for writing programs on the Web,
other than Java, but that is about to change. (This for the people on
www-style, the people on public-appformats of course already know :-) )
There are two new WGs in W3C, the WebAPI WG and the Web Applications
Formats WG, that are working on a language for client-side Web
applications. Such a language will (should) be much easier to use than
the triple HTML/CSS/XBL, in which XBL is only needed because HTML and
CSS aren't designed for application UIs.

So, rather than trying to "fix" HTML and CSS with XBL (and introducing
dependencies), I propose to skip XBL and instead work directly on this
new language for applications, which doesn't need HTML and CSS at all.

Bert

PS. For the people on public-appformats, here are some of my ideas on a
language for client-side Web applications, written for a workshop two
years ago:

Thu, 17 Aug 2006, Bert Bos wrote:

I don't mind adding some more behavior to CSS. (E.g., I'd like to have
collapse/expand for the <nlelement of XHTML2; :hover is not enough
for that.) But I do worry that the behavior added via an XBL binding is
procedural (through JavaScript) instead of declarative and especially
that it makes XBL and JavaScript requirements for implementing CSS.

My proposal would be to put the 'binding' property in the XBL
specification, rather than in the CSS specifications, thus making it only
a requirement if you implement XBL.

Also, note that XBL doesn't require JavaScript; for example you could use
Java with XBL.

My preferred solution is to list the behaviors that are most needed
(collapsing elements, various hyperlink behaviors) and add just those.
Maybe something like 'p:activated {content: "Click to collapse me"}'.

There has been a proposal in XBL3 for a fixed set of bindings, the problem
is that there is such a long tail that this wouldn't adequately solve the
problem XBL set out to solve.

If somebody wants other behaviors, he probably meant to write a program
rather than a document.

Certainly XBL1's main use case was for programs; indeed XBL1 was used
almost exclusively in a programming environment, without any documents
involved (it was used to implement the XUL programming language).

So, rather than trying to "fix" HTML and CSS with XBL (and introducing
dependencies), I propose to skip XBL and instead work directly on this
new language for applications, which doesn't need HTML and CSS at all.

While I understand that you do not feel XBL is the right solution, the
real question is that assuming that XBL does continue along the REC track,
do you, and other members of the CSS community, agree with the XBL
specification introducing a new property and related pseudo-class to the
CSS namespace. Currently it appears the majority of the community is in
favour or at least neutral on the matter.

Cheers,

Thursday 17 August 2006 22:06, Ian Hickson wrote:
Thu, 17 Aug 2006, Bert Bos wrote:
I don't mind adding some more behavior to CSS. (E.g., I'd like to
have collapse/expand for the <nlelement of XHTML2; :hover is not
enough for that.) But I do worry that the behavior added via an XBL
binding is procedural (through JavaScript) instead of declarative
and especially that it makes XBL and JavaScript requirements for
implementing CSS.

My proposal would be to put the 'binding' property in the XBL
specification, rather than in the CSS specifications, thus making it
only a requirement if you implement XBL.

It doesn't matter what spec you put it in, it's still in CSS. (It's also
not very user-friendly to put a part of CSS in a spec that is published
by another WG than the CSS WG, but we can maybe solve that with a good
catalog of properties.)

Sure, there can be profiles of CSS. Printers don't do :hover and they
won't do XBL either. But the general principle is that an
implementation on a platform that could do feature X, *should* do
feature X. features aren't good.

There has been a proposal in XBL3 for a fixed set of bindings, the
problem is that there is such a long tail that this wouldn't
adequately solve the problem XBL set out to solve.

Is that list (however incomplete) available somewhere? There are a
handful of hypertext behaviors that CSS really should have supported
long ago (expand/collapse, tooltip, pop-up) but I have a hard time
coming up with more. Add the sequential styles from Presentation
Levels, the tab and directional navigation from UI and the
link/visited, active and hover that we already have, that makes
something on the order of ten behaviors. Not a prohibitively long list.

Transition effects between pages have been suggested, but there is SMIL
if you want those. And if you want strange effects in a page, I think
it is acceptable when that requires a transclusion (a Java applet, a
bit of SVG, etc.)

While I understand that you do not feel XBL is the right solution,
the real question is that assuming that XBL does continue along the
REC track, do you, and other members of the CSS community, agree with
the XBL specification introducing a new property and related
pseudo-class to the CSS namespace. Currently it appears the majority
of the community is in favour or at least neutral on the matter.

The problem is that it is not neutral for CSS. If you were to propose a
new image format called PLNG and wanted to allow 'background:
url(myimage.plong)' that would be no problem. No change to the CSS
validator or to any CSS parser. And if PLNG turned out to be a
disaster, CSS would be unaffected.

Not so with the 'binding' property. It permanently changes CSS. The
validator has to accept it, CSS parsers have to handle it, if only to
handle inheritance. And when XBL is replaced by something else, it will
still continue to be a part of CSS.

Does it really have to be in CSS? Can't you make another language to
express the binding between XBL files and HTML elements? Why isn't that
binding in the XBL file itself? (In fact, isn't it already? <binding
e="div.foo"/>, so why do you need CSS?)

I can't put XBL and CSS in the same model of Web architecture in my
mind. They may exist in parallel for a while, but I believe XBL is a
temporary hack (more temporary than CSS at least) and so I'd rather not
make any permanent dependencies from CSS on XBL.

Bert

Thu, 17 Aug 2006 14:44:15 -0700, Bert Bos <bert (AT) w3 (DOT) orgwrote:
>My proposal would be to put the 'binding' property in the XBL
>specification, rather than in the CSS specifications, thus making it
>only a requirement if you implement XBL.
>
It doesn't matter what spec you put it in, it's still in CSS. (It's also
not very user-friendly to put a part of CSS in a spec that is published
by another WG than the CSS WG, but we can maybe solve that with a good
catalog of properties.)

Sure, there can be profiles of CSS. Printers don't do :hover and they
won't do XBL either. But the general principle is that an
implementation on a platform that could do feature X, *should* do
feature X. features aren't good.

FWIW, you need XBL for the property to be useful. It makes no sense for a
UA to support binding while not supporting XBL so it kind of makes sense
to have it in the XBL specification, imho. course, having an overview
of all CSS properties (and other stuff like selectors etc.) including the
necessary pointers would be quite useful.

Thu, 17 Aug 2006, Bert Bos wrote:
Thursday 17 August 2006 22:06, Ian Hickson wrote:
Thu, 17 Aug 2006, Bert Bos wrote:
I don't mind adding some more behavior to CSS. (E.g., I'd like to
have collapse/expand for the <nlelement of XHTML2; :hover is not
enough for that.) But I do worry that the behavior added via an XBL
binding is procedural (through JavaScript) instead of declarative
and especially that it makes XBL and JavaScript requirements for
implementing CSS.

My proposal would be to put the 'binding' property in the XBL
specification, rather than in the CSS specifications, thus making it
only a requirement if you implement XBL.

It doesn't matter what spec you put it in, it's still in CSS. (It's also
not very user-friendly to put a part of CSS in a spec that is published
by another WG than the CSS WG, but we can maybe solve that with a good
catalog of properties.)

Sure, there can be profiles of CSS. Printers don't do :hover and they
won't do XBL either. But the general principle is that an implementation
on a platform that could do feature X, *should* do feature X.
features aren't good.

By that arguement, any browser that supports CSS should also support SVG.
I'm not sure I agree with your premise.

There has been a proposal in XBL3 for a fixed set of bindings, the
problem is that there is such a long tail that this wouldn't
adequately solve the problem XBL set out to solve.

Is that list (however incomplete) available somewhere?

Not firmly, no. The widgets found in HTML4 and XForms would be the start
of such a list, but then that immediately shows why such a list would
probably be inadequate: despite the fact that HTML4 and XForms both have,
e.g., a submission button, the binding for one and the binding for the
other would be radically different in implementation.

XBL is (in part) an element-level UA-agnostic plugin architecture for Web
browsers, much like the Netscape Plugin API but more generic.

There are a handful of hypertext behaviors that CSS really should have
supported long ago (expand/collapse, tooltip, pop-up) but I have a hard
time coming up with more. Add the sequential styles from Presentation
Levels, the tab and directional navigation from UI and the link/visited,
active and hover that we already have, that makes something on the order
of ten behaviors. Not a prohibitively long list.

Ironically, none of those bindings would be on my initial list of
important bindings. :-) I agree they are things that would be useful,
though, which demonstrates the "long tail" aspect I mentioned.

While I understand that you do not feel XBL is the right solution, the
real question is that assuming that XBL does continue along the REC
track, do you, and other members of the CSS community, agree with the
XBL specification introducing a new property and related pseudo-class
to the CSS namespace. Currently it appears the majority of the
community is in favour or at least neutral on the matter.

The problem is that it is not neutral for CSS. If you were to propose a
new image format called PLNG and wanted to allow 'background:
url(myimage.plong)' that would be no problem. No change to the CSS
validator or to any CSS parser. And if PLNG turned out to be a
disaster, CSS would be unaffected.

Not so with the 'binding' property. It permanently changes CSS. The
validator has to accept it, CSS parsers have to handle it, if only to
handle inheritance. And when XBL is replaced by something else, it will
still continue to be a part of CSS.

Indeed, that is why the Web Application Formats working group is making
this request.

Does it really have to be in CSS? Can't you make another language to
express the binding between XBL files and HTML elements? Why isn't that
binding in the XBL file itself? (In fact, isn't it already? <binding
e="div.foo"/>, so why do you need CSS?)

Implementation experience with Mozilla and IE strongly suggests that a
CSS-based binding mechanism would be very useful.

There are several use cases for bindings; some are always applicable (e.g.
an <inputin HTML is always something you submit; if you implemented
HTML4 Forms using XBL, you wouldn't ever not want the <inputto take part
in the form submission model), some are presentational (e.g. using XBL to
rearrange content or to make new interfaces for widgets depends on the
alternate stylesheet set selected).

For the latter use case, a hook from within CSS seems necessary.

I can't put XBL and CSS in the same model of Web architecture in my
mind. They may exist in parallel for a while, but I believe XBL is a
temporary hack (more temporary than CSS at least) and so I'd rather not
make any permanent dependencies from CSS on XBL.

the contrary, if XBL is seen as a way to implement other languages,
like XForms, HTML4, XHTML2, or various Semantic Web things, using Java as
the implementation language, and CSS as the presentation layer, it seems
to me that the two languages would cooperate hand-in-hand.

Similarly, if one considers XBL to be useful merely for content reordering
in conjunction with CSS, then again it would seem that the two languages
could be expected to have a similar lifespan.

If one considers XBL to be a "macro language" for use with, e.g., SVG,
where it can be used to define new elements that "expand" into complex
shapes (in the spirit of the <svg:useelement or XML entities, but with
significantly more flexibility), then the use of CSS as a hook language
becomes even more important and again, one would find the two used hand-
in-hand during their entire lifetime.

I tend to agree with Bert here.

Tying together given versions of CSS and XBL at specific design
points is likely to turn into a maintainance problem long-term.

Bert Bos writes:

Thursday 17 August 2006 22:06, Ian Hickson wrote:
Thu, 17 Aug 2006, Bert Bos wrote:
I don't mind adding some more behavior to CSS. (E.g., I'd like to
have collapse/expand for the <nlelement of XHTML2; :hover is not
enough for that.) But I do worry that the behavior added via an XBL
binding is procedural (through JavaScript) instead of declarative
and especially that it makes XBL and JavaScript requirements for
implementing CSS.
>
My proposal would be to put the 'binding' property in the XBL
specification, rather than in the CSS specifications, thus making it
only a requirement if you implement XBL.

It doesn't matter what spec you put it in, it's still in CSS. (It's also
not very user-friendly to put a part of CSS in a spec that is published
by another WG than the CSS WG, but we can maybe solve that with a good
catalog of properties.)

Sure, there can be profiles of CSS. Printers don't do :hover and they
won't do XBL either. But the general principle is that an
implementation on a platform that could do feature X, *should* do
feature X. features aren't good.

There has been a proposal in XBL3 for a fixed set of bindings, the
problem is that there is such a long tail that this wouldn't
adequately solve the problem XBL set out to solve.

Is that list (however incomplete) available somewhere? There are a
handful of hypertext behaviors that CSS really should have supported
long ago (expand/collapse, tooltip, pop-up) but I have a hard time
coming up with more. Add the sequential styles from Presentation
Levels, the tab and directional navigation from UI and the
link/visited, active and hover that we already have, that makes
something on the order of ten behaviors. Not a prohibitively long list.

Transition effects between pages have been suggested, but there is SMIL
if you want those. And if you want strange effects in a page, I think
it is acceptable when that requires a transclusion (a Java applet, a
bit of SVG, etc.)

While I understand that you do not feel XBL is the right solution,
the real question is that assuming that XBL does continue along the
REC track, do you, and other members of the CSS community, agree with
the XBL specification introducing a new property and related
pseudo-class to the CSS namespace. Currently it appears the majority
of the community is in favour or at least neutral on the matter.

The problem is that it is not neutral for CSS. If you were to propose a
new image format called PLNG and wanted to allow 'background:
url(myimage.plong)' that would be no problem. No change to the CSS
validator or to any CSS parser. And if PLNG turned out to be a
disaster, CSS would be unaffected.

Not so with the 'binding' property. It permanently changes CSS. The
validator has to accept it, CSS parsers have to handle it, if only to
handle inheritance. And when XBL is replaced by something else, it will
still continue to be a part of CSS.

Does it really have to be in CSS? Can't you make another language to
express the binding between XBL files and HTML elements? Why isn't that
binding in the XBL file itself? (In fact, isn't it already? <binding
e="div.foo"/>, so why do you need CSS?)

I can't put XBL and CSS in the same model of Web architecture in my
mind. They may exist in parallel for a while, but I believe XBL is a
temporary hack (more temporary than CSS at least) and so I'd rather not
make any permanent dependencies from CSS on XBL.

Bert
--
Bert Bos ( W 3 C ) http://www.w3.org/
http://www.w3.org/people/bos W3C/ERCIM
bert (AT) w3 (DOT) org 2004 Rt des Lucioles / BP 93
+33 (0)4 92 38 76 92 06902 Sophia Antipolis Cedex, France

Thu, 17 Aug 2006, T.V Raman wrote:

Tying together given versions of CSS and XBL at specific design points
is likely to turn into a maintainance problem long-term.

The property is actually language-version independent; in fact other
people on this thread have even suggested that the proposed features could
be used with other binding languages in due course. I agree it would be a
bad idea to tie specific versions together like this; hopefully this
clarification alleviates the concern.

It doesn't quite allay the concern -- it might be "language
version independent" as seen today but it'll effectively
dictate how future versions of CSS evolve -- in the name of
"backward compatibility".

I would express an equivalent concern over the way CSS selectors
are presently tied into XBL -- it's also not clear in that
instance which version of CSS is being "bound" to.

Ian Hickson writes:

Thu, 17 Aug 2006, T.V Raman wrote:
>
Tying together given versions of CSS and XBL at specific design points
is likely to turn into a maintainance problem long-term.

The property is actually language-version independent; in fact other
people on this thread have even suggested that the proposed features could
be used with other binding languages in due course. I agree it would be a
bad idea to tie specific versions together like this; hopefully this
clarification alleviates the concern.

--
Ian Hickson U+1047E )\,,'``. fL
http://ln.hixie.ch/ U+263A /, _ \ _\ ;`._ ,.
Things that are impossible just take longer. `(,_'--(,_'`-.;.'

Thu, 17 Aug 2006, T.V Raman wrote:

It doesn't quite allay the concern -- it might be "language version
independent" as seen today but it'll effectively dictate how future
versions of CSS evolve -- in the name of "backward compatibility".

I'm not sure I follow; could you give an example of how CSS might be
prevented from evolving? The property is merely specified as taking a list
of <uritokens, much the same as today's 'icon' property; wouldn't that
have the same problems?

I would express an equivalent concern over the way CSS selectors are
presently tied into XBL -- it's also not clear in that instance which
version of CSS is being "bound" to.

Much as with XBL's use of XML, there is no particular version being
required. This is similar to how HTML UAs don't require a particular
version of JavaScript, the DM, CSS, etc, or how CSS itself is independent
of the exact version of media queries that is used with it.

This allows all these technologies to develop in parallel, with UAs
supporting the versions that the market demand pushes them to support.

Cheers,

Ian Hickson writes:
This allows all these technologies to develop in parallel, with UAs
supporting the versions that the market demand pushes them to support.

Which effectively makes interoperability impossible,
since each vendor will go off and support his favorite version
snapshot -- and claim "that's the market demand" and in
practice everyone will try to be bug-compatible with the majority
market-holder. That is of course the status-quo but if it is
the status-quo -- then one needn't bother with specs anyway
Cheers,
--
Ian Hickson U+1047E )\,,'``. fL
http://ln.hixie.ch/ U+263A /, _ \ _\ ;`._ ,.
Things that are impossible just take longer. `(,_'--(,_'`-.;.'