W3C home > Mailing lists > Public > public-appformats@w3.org > August 2006

Re: Decouple XBL2 From CSS

From: Ian Hickson <ian@hixie.ch>
Date: Sat, 5 Aug 2006 22:06:54 +0000 (UTC)
To: Mark Birbeck <mark.birbeck@x-port.net>
Cc: public-appformats@w3.org
Message-ID: <Pine.LNX.4.62.0608052139560.5340@dhalsim.dreamhost.com>

On Sat, 5 Aug 2006, Mark Birbeck wrote:
> 
>  <br:bindings
>    xmlns:br="http://www.x-port.net/bindingresolver/"
>    xmlns:xf="http://www.w3.org/2002/xforms"
>  >
>    <br:binding
>     match="xf:output[contains(@mediatype, 'image/')]/xf:pe--value"
>     binding="image.xbl#html-img"
>    />
>  </br:bindings>

   <bindings xmlns="...xbl..." xmlns:xf="http://www.w3.org/2002/xforms">
    <binding element="xf|output[mediatype*="image/"]::value"/ ...>
   </bindings>

Note that using Selectors you can use pseudo-elements without extending 
the selection language at all. (What if you actually wanted to select an 
element in the XForms namespace with the name <pe--value> ?)


> This is not unlike using an <img> tag with attribute value templates:
> 
>  <img src="{a}" />

   <img xbl:inherits="src=a#url"/>

(This even takes care of URL resolution in the face of differing xml:base 
attributes, which is likely to be a common case.)


>  <br:binding match="xf:hint" binding="xf-hint.xbl" />
>  <br:binding match="xf:help" binding="xf-help.xbl" />

   <binding element="xf:hint" .../>
   <binding element="xf:help" .../>


> Sometimes we want to use a set of binding objects only if the client 
> application supports certain functionality. In formsPlayer we can 
> currently test for installed features using 'feature strings', so to 
> make use of a set of SVG widgets only if the client application actually 
> supports SVG, we do this:
> 
>  <br:bindings feature="org.w3c.svg" version="1.0">

In practice, this only works when targeting a single UA only. You need 
only look at the mess of SVG feature strings, or even worse, the mess of 
DOM feature strings, to see the disaster that this kind of thing becomes 
when you have multiple UAs involved.

There's no technical reason why you couldn't use a CSS stylesheet with 
media queries to do feature string comparison. The CSS working group 
decided not to bother adding the feature, however, despite being asked to 
add this feature at least once a month, because it simply wouldn't work.


>    <br:binding
>     match="xf:range[@class='thermometer']/xf:pe--value"
>     binding="thermometer.xbl"
>    />

   <binding element="xf:range.thermometer::value" .../>

Note that the XPath version wouldn't match a case like:

   <xf:range class="main thermometer"/>


>    <br:binding
>     match="xf:select1[@class='map-of-usa']/xf:pe--value"
>     binding="map-of-usa.xbl"
>    />

   <binding element="xf:select1.map-of-usa::value" .../>


>    <br:binding
>     match="xf:label[@class='aeroplane']/xf:pe--value"
>     binding="aeroplane.xbl"
>    />

   <binding element="xf:label.aeroplane::value" .../>


>  <xf:output ref="a" mediatype="application/x-mplayer2">
> [...]
> The problem with this is that we've now made our form use a very
> specific bit of mark-up that requires that a particular plug-in has
> been installed. Ideally we want our mark-up to look more like this:
>
>  <xf:output ref="a" mediatype="image/video">
>    <xf:label>A video:</xf:label>
>    <xf:hint>This is a video of us on holiday</xf:hint>
>  </xf:output>

I know this isn't an XForms discussion, but just as an aside, in Web Forms 
2.0, this would just be:

   <label>A video:
    <input type="file" accept="video/*" name=a
           title="This is a video of us on holiday">
   </label>


>  <br:bindings feature="com.microsoft.mediaplayer">
>    <br:binding
>     match="xf:output[contains(@mediatype,'application/video')]/xf:pe--value"
>     binding="video.xbl#mshtml-mediaplayer"
>    />
>  </br:bindings>
>  <br:bindings feature="com.real.realplayer">
>    <br:binding
>     match="xf:output[contains(@mediatype,'application/video')]/xf:pe--value"
>     binding="video.xbl#mshtml-realplayer"
>    />
>  </br:bindings>
> 
> (The server would still have to do some work...but you can't have everything!)

You can do this without feature strings by using a single template and 
then using the fallback feature of <html:object>, by the way. (Or just 
replying on the UA's built in MIME type dispatcher.)


> One final thing to point out is that XPath is set to be used to provide 
> more dynamic kinds of information, and this is largely because it has a 
> simple function extension mechanism.

So do Selectors. Anyone can invent new selectors and add them using the 
-vendor-feature syntax. For example, Mozilla has added :-moz-any-link.

Of course, such extensions won't interoperate across different vendors, 
and that's why we discourage extensions. Personally I consider the fact 
that XPath extensions are so encouraged to be a strong reason to avoid 
using XPath in an XBL context.


>    <br:binding
>     match="xf:output[dcn:search('battery') &lt; 20]/xf:pe--value"
>     binding="battery.xbl#verylow"
>    />
> 
> Driving a widget from the battery level of a computer is somewhat
> contrived, and I only use this since it's an example from the working
> draft, but it does illustrate the point.

Let's come up with a less contrived example -- using a different widget 
based on the screen resolution. Since this is now a presentational binding 
(it depends on the presentation), we put the binding mechanism in a 
stylesheet, and use media queries:

   /* ... */
   @media screen and (min-resolution: 100dpi) {
     xf|output::value { -xbl-binding: url(highres.xml#output); }
     /* other high res bindings */
   }
   @media screen and (max-resolution: 100dpi) {
     xf|output::value { -xbl-binding: url(lowres.xml#output); }
     /* other low res bindings */
   }

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Saturday, 5 August 2006 22:07:04 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:10:20 GMT