Several editorial fixes to XBL

All the comments below have been fixed. Please let me know if I made any 
mistakes, missed anything, or if you are not happy with the fixes.

Thanks to Marcos, Cyril, and Cameron for their detailed review.


On Fri, 3 Nov 2006, Marcos Caceres wrote:
> 
> Under the definition of the extends attribute (section 2.2), the term 'in
> error' is not linked to its definition.

On Fri, 3 Nov 2006, Marcos Caceres wrote:
>
> In the binding section (2.2), can you please change the words "prettier 
> presentation" to "richer presentation" or preferably "enhancing 
> aesthetics". The connotations of 'pretty' in that context make it seem 
> as if making things more aesthetically pleasing has no functional value, 
> which from an interface design perspective is completely untrue. I 
> personally find such statements 'harmful' to interface designers;-)

On Fri, 3 Nov 2006, Marcos Caceres wrote:
> 
> The content element in example 3 in section 2.5 is not closed. Search for:
> <content includes="ui|listitem" apply-binding-sheets="true">
> should be:
> <content includes="ui|listitem" apply-binding-sheets="true"/>

On Fri, 3 Nov 2006, Marcos Caceres wrote:
> 
> In section 2.8, it reads :
> "xbl:pseudo attribute must be a a valid pseudo-element"
> Should read:
> "xbl:pseudo attribute must be  a valid pseudo-element"

On Sat, 4 Nov 2006, Marcos Caceres wrote:
> 
> in section 2.13, it reads: "ancestors of the bound eleent", should read 
> "ancestors of the bound element"

On Tue, 7 Nov 2006, Marcos Caceres wrote:
> 
> in section 3.6, it reads:
> A bound element is in a document if it has a Document node as an ancestor, of it is...
> 
> Should read:
> A bound element is in a document if it has a Document node as an ancestor, *or* it is...

On Sat, 4 Nov 2006, Marcos Caceres wrote:
> 
> In section 2.6 it reads, "The id attribute assigns a name to an 
> element." I find this assertion inaccurately as names usually things 
> given to things liberally without regard for uniqueness. Given that "id" 
> is short of identifier anyway, I personally think that statement should 
> read:
> 
> "The id attribute assigns an identifier to an element."
>
> If the change is accepted, then the proceeding sentence would also need 
> to change from:
>
> "The given name must be unique in the binding document."
> 
> To:
> 
> "The given identifier must be unique in the binding document."

On Sat, 4 Nov 2006, Marcos Caceres wrote:
> 
> In sections 3.1, 3.5, 7.5, you talk about an "Event interface" but you 
> don't provide any IDL or a reference to that interface (i know you are 
> talking about DOM3, you don't make this clear in the document... 
> however, you do make it clear for other event types, such as 
> MutationEvent, TextEvent , KeyboardEvent etc...).

On Tue, 7 Nov 2006, Marcos Caceres wrote:
> 
> In Section 3.7, it currently reads,
> Consider a case where seven bindings are defined, "a", which inherits 
> from "b", which inherits from "c", "d", which stands alone, and "e", 
> which inherits from "f" which inherits from "g".
> 
> I think the following makes it easier to read: 
> Consider a case where seven bindings are defined, "a", which inherits 
> from "b" which inherits from "c"; "d", which stands alone; and "e", 
> which inherits from "f" which inherits from "g".
> 
> ... or maybe you could put them into a list structure:
> 
> Consider a case where seven bindings are defined: 
>  * "a", which inherits from "b" which inherits from "c"; 
>  * "d", which stands alone; 
>  * and "e", which inherits from "f" which inherits from "g".
> 
> For me, either of the above two options makes it easier to follow.

On Tue, 7 Nov 2006, Marcos Caceres wrote:
> 
> In section 3.7.2, it reads: 
> If this element is attached to an element using addBinding that already 
> has a binding chain of:
> 
> it should read: 
> If binding d1 is attached to an element using addBinding that already 
> has a binding chain of:

On Fri, 10 Nov 2006, Marcos Caceres wrote:
> 
> In section 4.3, it reads:
> When specified on the left-hand side of the pair it indicates that the 
> value of the attribute on the right-hand side are to be be 
> represented...
> 
> Should read:
> When specified on the left-hand side of the pair it indicates that the 
> value of the attribute on the right-hand side are to be represented...

On Fri, 10 Nov 2006, Marcos Caceres wrote:
> 
> Header 4.4.1 should be removed, as it is inconsistent with the rest of 
> the sections in the spec (ie, other sections don't start with an 
> 'introduction' heading).

On Wed, 29 Nov 2006, Marcos Caceres wrote:
>
> In section 4.9.1, it reads:
> 
> Shadow content is not considered part of an document
> 
> Should read:
>
> Shadow content is not considered part of a document

On Wed, 6 Dec 2006, Cyril Concolato wrote:
> 
> In Section 2.13, please replace "see below" with an appropriate link.

On Thu, 7 Dec 2006, Cameron McCormack wrote:
> 
>   The editor guarentees that all feedback sent to the above lists will
>   receive responses before this specification advances to the next stage
>   of the W3C process.
> 
> s/guarentees/guarantees/
> 
> Also:
> 
>   …and to allow for implementations in a broader range of Web browsers.
> 
> s/implementations/implementation/

On Thu, 7 Dec 2006, Cameron McCormack wrote:
>
> 2.1 The xbl Element
> 
> The example in this section has an extends="validityImplementor" 
> attribute.  This should be extends="#validityImplementor", since section 
> 2.2 says that this attribute is a URI.

On Thu, 7 Dec 2006, Cameron McCormack wrote:
> 
> 2.10 The handlers Element
> 
>   The following example shows how handlers can be used with any old
>   event listener mechanism.
> 
> This language is a bit informal.  (This is the case with a few of the 
> example sections in this document.)  Suggest s/ old//.

On Thu, 7 Dec 2006, Cameron McCormack wrote:
>
> 3.3.2 Processing Model
> 
>   In either case, for each element…
> 
> s/either/any/

On Thu, 7 Dec 2006, Cameron McCormack wrote:
> 
> 3.6 Handling Insertion and Removal from the Document
> 
>   A bound element is in a document if it has a Document node as an
>   ancestor, of it is in a shadow tree and that shadow tree’s bound
>   element is itself in a document
> 
> s/of/or

On Thu, 7 Dec 2006, Cameron McCormack wrote:
>
> 4.10 Binding Style Sheets
> 
>   When multiple bindings are applied to the same bound element, the
>   sheets from each binding all contribute to the final set of style
>   sheets to apply; the style sheets of the most derived binding being
>   walked first.
> 
> s/;/,/

On Thu, 7 Dec 2006, Cameron McCormack wrote:
> 
> 7.3 The XBLContentElement Interface
> 
> The two paragraphs after the example should be within the example
> section.

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