Re: Comments on XBL 2.0 Revision 1.43

On Wed, 17 May 2006, Arthur Barstow wrote:
> 
> The W3C's Web Application Formats (WAF) Working Group ([1]) has reviewed 
> Revision 1.43 of Mozilla's:
> 
>  XBL 2.0
>  http://www.mozilla.org/projects/xbl/xbl2.html
> 
> Attached are our comments/issues/questions for this Revision.

Thanks!

| 1.1. Terminology and Conventions
| 
| ISSUE-A The definition of compound document must be consistent with the 
| CDF WG's definition.

Fixed (removed mention of compound documents).


| ISSUE-B Why does the specification state that in addition to following 
| error handling rules UAs may abort all processing? Once documents are out 
| there that rely on error handling (they shouldn't of course) UAs that 
| abort all processing may have to revert that just because other UAs don't.

It's basically allowed for conformance checkers or other server-side
tools that are not expected to handle any random content but only
content from the tools' own users.


| 1.2.1. Attributes Containing Selectors
| 
| ISSUE-C If this specification says nothing at all about the level of 
| Selector support that is required, will that result in interoperablity 
| issues (e.g. partial and different levels of selector support)?

No more so than the HTML world currently has. In practice we can't
require a particular subset of Selectors, since Selectors will evolve
independently.


| This appears to violate Selectors specification section 12.

I'll forward this to the CSS group.


| 2. XBL Elements
| 
| ISSUE-D Need to clarify absent in the second paragraph e.g. does it mean 
| ignore?

I couldn't work out why this was unclear.


| ISSUE-E To clarify the following sentence and CSS code, replace the 
| sentence and CSS code with something like Elements in the XBL Namespace 
| should have the display property set to none by default..
| 
|   XBL user agents should act as if they had the following rules in
|   their UA  style sheet:
| 
|       @namespace xbl url(http://www.mozilla.org/xbl2);
|       xbl|* { display: none; }

Clarified.


| ISSUE-F Need to clarify rendered in this context. Also, what does this 
| imply regarding style sheets?
| 
|    That is to say, XBL elements should not be rendered.

Clarified.


| 2.3. The implementation Element
| 
| ISSUE-G Does on first use in the description of the implementation element 
| imply that if I modify it, bind it to some other element, that element 
| won't have the modifications?

Yes. The sentence immediately after the one that says "first use" now
mentions this explicitly.


| ISSUE-H Vendor specific attributes should be in a namespace.

Why? We want the vendors to actually follow the spec, making it harder
to extend the spec would just make vendors ignore the spec and then we
wouldn't be able to distinguish the extensions at all.


| 2.7. The xbl:inherits Attribute
| 
| ISSUE-I The definition of xbl:inherits should be expanded to include 
| intrinsic properties of the bound element into account, such as language, 
| base URI, etc.

Done.


| 2.10. The handler Element
| 
| ISSUE-J Why does the handler element not have a src attribute to 
| facilitate script re-use?

Because in practice you only want one JS file, not one per handler. To
do this, you would define the functions in the implementation, and
then invoke the functions from the handlers.


| 2.13. The prefetch Element
| 
| ISSUE-K This functionality of the prefetch element does not seem essential 
| to XBL. Perhaps it should be specified in a separate (modular) 
| specification.

Perhaps. This doesn't seem particularly useful, though, as then we'd
have to define how everything works together (i.e. how the element
should only work when the binding is used).


| 3.2.1. XForms Actions
| 
| ISSUE-L Since the XForms reference is non-normative, this section should 
| be non-normative.

Fixed.


| 4.1.1. Importing binding documents
| 
| ISSUE-M the use of PIs is discouraged by some communities (i.e. the W3C's 
| TAG). Can this PI's functionality be replaced by some other syntax - as 
| the SVG WG did with the import element of sXBL?

The sXBL element idea doesn't work, that's why it was replaced by a
PI. The thing is you need to know what you import before you create
the root element, since the root element itself might be bound, and
this must support the case of bindings having immutable interfaces.


| ISSUE-N Need to clarify if using -xbl-binding or addBinding() does not 
| result in the rest of the binding document being applied if there is a 
| match. For example,if addBinding() is called and an XBL document is 
| fetched <binding element="'> on some of the other bindings don't 
| automatically match anything in the document.

Clarified.


| 4.2. Attachment using CSS
| 
| ISSUE-O the Note: in this section needs clarification in particular attach 
| versus fetch versus import.

The spec doesn't require that a binding document be imported for its
bindings to be used, only that it be imported for the element=""
attribute to take effect. I've tried to make this clearer.


| 4.6. Binding Inheritance
| 
| ISSUE-P to clarify the figure, add code that results in what the figure 
| shows.

I'm not sure that would be an obvious help, since it would require at
least nine separate bindings and four binding attachment
points. However, adding examples is definitely something that needs
to be done.


| 5.1. Rules for Shadow Content Generation
| 
| ISSUE-Q The following paragraph needs clarification because a binding 
| element may have at most one template element and the text implies 
| otherwise.
| 
|    The bindings in the bound element's list of bindings are first
|    checked to  see if any have shadow content templates. If any do,
|    then the most derived such template is the primary generating
|    binding. Otherwise, there isn't one.

That paragraph doesn't seem to make that implication so I assume you
are talking about another one, but I couldn't work out which paragraph
that might be.


| ISSUE-R The processing model for the inherited described in this section 
| is difficult to follow.

Yes, we need more examples.


| 5.3. Attribute Forwarding
| 
| ISSUE-S It seems parts of this section are XML 1.0 specific by referring 
| to Namespaces in XML 1.0. This might be a more general issue with what 
| happens when binding an XML 1.0 binding document to an XML 1.1 bound 
| document.

I couldn't work out what it was that referred to XML 1.0.


| ISSUE-T It is unclear if it is good for 'text' or any value not mentioned 
| here being processed as normal. May also want to have an "extension" at 
| some point and not want older implementations to forward an attribute if 
| they don't recognize it. Perhaps the spec should say something about types 
| starting with 'xbl' MUST be ignored and not processed?

Or just that any type other than "text" and "url" must be treated as
an error and ignored... Yeah, that's probably a good idea. Fixed.
(This change will appear on the Web site in the coming days.)


| 5.4. Processing content Elements
| 
| ISSUE-U The processing model for content elements in section 2.5 should be 
| combined with the processing model in this section (i.e. consolidate the 
| model in one location of the document).

There is no processing model in 2.5, just an introductory description.


| 5.7.3. The :-xbl-bound-element Pseudo-Class
| 
| ISSUE-V Should add a forward reference to section 5.10.

Why?


| 5.7.4. Matching Pseudo-Elements
| 
| ISSUE-W If the CSS parser does not support these pseudo elements, does the 
| XBL User Agent need to support them?

I don't understand what the question means.


| 6.1. The XBLImplementation Interface
| 
| ISSUE-X Need an example on how this interface is used. For example is this 
| something the author has to create?

I agree that we need more examples.


| 7.3. Mouse Event Handler Filters
| 
| ISSUE-Y Need to add a Device Independence disclaimer/warning about this 
| functionality.
| 
| 7.4. Key Event Handler Filters
| 
| ISSUE-Z Need to add a Device Independence disclaimer/warning about this 
| functionality.
| 
| 7.7. Modifiers
| 
| ISSUE-AA Need to add a Device Independence disclaimer/warning about this 
| functionality.
| 
| 7.10. Mouseover and Mouseout Events
| 
| ISSUE-AB Need to add a Device Independence disclaimer/warning about this 
| functionality.

I don't understand what is being requested here.

Thanks for your comments! I look forward to working more closely with
the WAF group in the near future.

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

Received on Wednesday, 17 May 2006 23:33:29 UTC