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

RE: XBL2 review

From: Doug Schepers <doug.schepers@vectoreal.com>
Date: Mon, 21 Aug 2006 17:06:10 -0400
To: "'Mihai Sucan'" <mihai.sucan@gmail.com>, "'Web API WG'" <public-webapi@w3.org>
Cc: <public-appformats@w3.org>
Message-Id: <20060821210616.EE85211F1F8@postalmail-a4.dreamhost.com>

Hi, Mihai-

Comments about XBL2 should be directed to public-appformats@w3.org, not


Mihai Sucan wrote:
| Hello!
| I have reviewed the XBL2 draft (21 august 2006 draft, 
| directly from the  
| CVS) and I have the following comments to make:
| 0. General things
| a)
| <style> in <resources>
| How's this supposed to work? Is the provided style applied as if the  
| shadow content is a document by itself? Or is the style added to the  
| entire owning document, just like adding a new <style> in 
| header? Or... is  
| the <style> applied as if the bound element is a document by itself?
| b)
| All in all I like XBL2, it's a very good initiative and makes web  
| developers feel less "guilty" when they want to do extremely 
| complicated  
| designs and "widgets" in a site. The reason is rather 
| simplistic: one has  
| only to write a clean markup for the page and use an XBL 
| binding to add  
| all the cruft.
| A general concern applies, as with CSS 3-stuff, SVG and newer 
| technologies  
| which are not implemented in the dominant web browser (I 
| shall not name  
| it, for the sake of helping the world forget its name :) ). 
| For now and,  
| sadly, for a long time, such technologies are confined to 
| cutting-edge web  
| sites, or to Intranet applications with a limited target audience.
| Further comments will *probably* follow.
| 1. Introduction
| In the example I see <style> in <resources>. Why no type="text/css"?
| Bad phrasing:
| <The result of applying the XBL binding above to the HTML 
| given able using  
| the CSS given above is to equivalent to the result one would 
| get if one  
| simply placed the div element with class="nav" before the div 
| element with  
| class="main", but the effect is achieved without needing any 
| changes to  
| the markup.>
| I don't understand what's exactly meant. Please rephrase.
| 1.2.1. Attributes Containing Selectors
| <Note: This specification does not specify what level of 
| Selectors support  
| is required.>
| Why?
| If one UA claims support for XBL2 the author can't rely on 
| the support of  
| CSS 3 Selectors, practically rendering XBL2 support useless if no  
| Selectors are supported. XBL2 specification should provide a list of  
| required Selectors for claiming conformance. If not, we will 
| endup with  
| UAs doing something similar to IE 6: they added support for 
| PNG, but they  
| missed one of the "coolest" feature in PNG (transparencies).
| 2.3. The implementation element
| I personally don't exactly understand the syntax used in the 
| provided  
| example:"set memory(value)" and "get memory()". Why a space? 
| Can somebody  
| explain that?
| 2.9. The div element
| I don't see the real use for the state attribute. There are 
| other ways to  
| do the same, and there's no real imperative need for yet-another  
| attribute. It's defined as a stylistic hook, same as class. It's a  
| duplicate attribute.
| 2.13. The style element
| This should have a type attribute. The style-type attribute 
| of xbl element  
| would be only the "default type". Why not allow multiple 
| types of styles  
| in a single binding?
| 2.14. The prefetch element
| Suggestion: new attribute "condition". This should be an ECMAScript  
| expression which if evaluates to true, the file is loaded. 
| Some may want  
| to prefetch some images based on various conditions.
| 2.15. The script element
| This should have a type attribute. The script-type attribute of xbl  
| element would be only the "default type". Why not allow 
| multiple types of  
| scripts in a single binding?
| 4.5. Binding Attachement Model
| Why is the UA allowed to *act* as if it does the steps 
| listed? What does  
| acting mean in this context?
| 5. Shadow Content
| Recommended rephrasing from:
| <If a binding element that had no template element has a 
| template element  
| added, then a shadow tree must be generated.>
| ... to:
| <A shadow tree must be generated when a template element is 
| added to a  
| binding element that had no template element.>
| 5.4. Processing content elements
| The example starts with <Imagine the following simple 
| document>. I am not  
| sure if that's appropriate, because I won't imagine anything. 
| The provided  
| example is result of what the author imagined. If I have to imagine  
| something, I'd imagine something else.
| I'd suggest switching from "imagination examples" to just 
| examples: "Given  
| the following document", then "Having the X element bound to...".
| 5.7.4. The matching pseudo-elements
| Until reaching this chapter I believed I can assign any 
| pseudo-element,  
| for use within CSS. Quite an interesting concept, at first.
| Reading this chapter I reached the conclusion this is much 
| like the state  
| attribute for the div element. Instead of using the provided list of  
| psuedo-elements, one can use class names 
| (icon/value/choices...). Even the  
| provided example emphases that, for me, at least.
| 6.4. ECMAScript bindings
| <First, if this is the first time the binding defined by that 
| binding  
| element is used since that binding document was loaded, then, 
| if that  
| element contains an implementation element, then the first 
| such element  
| must have its code compiled and run (see below), and the 
| return value of  
| that script, if any, must be forever associated with that 
| binding element  
| as that binding's implementation prototype object.>
| This very lengthy phrase is hard for one to understand. I 
| recommend a  
| better wording. I have no suggestion, since a correct 
| rephrasing requires  
| accurate understand, and I myself don't feel confident enough to say  
| "yeah, I know what he meant".
| -- 
| http://www.robodesign.ro
| ROBO Design - We bring you the future
Received on Monday, 21 August 2006 21:06:57 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:16:21 UTC