Re: XBL2 Comments

A couple of notes just so I don't forget.

Jonas Sicking wrote:
>  >> 4.7.3
>  >> The dual meaning of the :bound-element pseudo class seems like a bad
>  >> idea from a usability point of view. It also makes it impossible to
>  >> match a bound element inside a shadow tree. Why not split it up into 
>  >> two selectors?
>  >> What is the usecase for matching all xbl-bound elements in general?
>  >
>  > It isn't clear that matching a bound element in general is a useful
>  > thing. That this is possible at all is mostly the result of defining
>  > what should happen in the absense of a bound element, rather than the
>  > result of an actual use case.
> 
> I suggest we remove that feature since it seems just to add unnecessary 
> bloat to implementations. Additionally, it seems harder for authors to 
> use the selector since something like
> :bound-element{border: red}
> would not only add a border to the bound element that the current 
> binding is attached to, but also add borders to all bound elements in 
> the bindings shadow tree.

Hixie pointed out to me that there is no dual meaning. :bound-element 
simply means one thing when used in a bindings <style> and another thing 
elsewhere. However I still don't see the use for the "other" use and I 
think it should simply not match anything when used somewhere else.

Even if it was useful to match all elements with bindings, the current 

[XBL Primer] Comments

Re: [XBL Primer] Comments

Hi Jose,

On 4/4/07, José Manuel Cantera Fonseca <jmcf <at> tid.es> wrote:
>
>  Commenting:
> http://dev.w3.org/cvsweb/2006/waf/XBLPrimer/Overview.src.html?rev=1.16
>
>  + There are some typos in the document
>
>  + Abstract
>
>  "This document provides you with the practical knowledge ..."
>
>  Shouldn't it say "This document provides the practical knowledge ..."
> Perhaps for you native speakers it sounds ok but for me no, I don't know ...

To me it reads ok. It's just written in an informal voice; that's
intentional. If we find that people find this style irritating, then
we can change the tone.

>  + Status of document
>
>  "Implementors should be aware that this specification is not stable ...
>  "This document was produced ...
>
>  Is this really needed for a W3C Note? This is not the XBL 2 spec ....

It might not look like it now, but this ain't no W3C Note; It's going
down the rec track. This was agreed to at the last face to face
meeting in Boston. There is precedence for this (xml schema, rdf,
etc).

>  + Table of contents
>  It would be good to have it completed, although some of the contents were
> empty. This would give the reader an overview of the whole document and what
> the editors are planning to do for the next versions

Agreed. We will have a better idea after the next face 2 face meeting
(April 17th)... also I need to run the CSS processor over the document
to get the proper ToC. However, I won't process it until the document
is much more mature because the processor makes a mess.

>  + Use of the word XBL. It should be used consistently over the whole
> document i.e. it should be used XBL 2 everytime or there should be a
> statement saying that "hereinafter when the 'XBL' word is appearing we are
> talking about 'XBL 2'"

Agreed. I will change everything to "XBL".

>  + Introduction
>  Perhaps the statement "The move in web development towards avoiding the
> table element for layout has led developers to consider how to exploit other
> HTML elements, CSS, and ECMAScript to achieve complex layouts." should not
> be the first in this paragraph and should be used as an example of highly
> accessible content i.e avoiding usage of tables for layout

I don't understand. Can you please elaborate?

>  + XBL concepts
>  The content under this section hasn't any concepts ...



>  + Working example.
>
>  In the text it is mentioned "Log on· as legend, but in the markup example
> appears "Log in" in the legend tag. In the next step (adding divs and CSS)
> in the figure appears login instead of log on :)

Yes, I have to take another screen-shot of the image. It's on my todo list.

>  You don't have put a label for the submit input, this occasionates that a
> default label is put in the submit button and that label depends on the
> browser language, so in my browser, which is configured in Spanish, I see a
> Spanish label intermixed with the English labels of the other fields.

Ah, of course! I will fix that. I should get into the practice of
putting my system language into Spanish to test stuff.

>  In the div example the CSS is not shown. This can be misleading

Still working that out.

>  I don't see the need of duplicating the effort creating one XML version and
> another HTML version of the example. One practical way to face this
> difference would be to work in XHTML (the more general option) and provide
> an specific example wrt attaching the XBL via CSS (which is also permitted
> in XHTML) and say "this is the way how an HTML document would be bound to an
> XBL binding"

Yeah, I figured that too... I will dump the XHTML examples and only do
HTML. When I first wrote this, I thought XHTML still had a future

>  + Creating an XBL document and attaching it to another document
>
>  It seems that this section looses the continuity with the example,
> shouldn't be the continuation of the example?

Yes, I agree the linking is very weak here. I will fix that soon, but
the current example my be dumped because I am starting to think that
XBL adds little value to it.

>  + Attaching XBL using ...
>
>  I'm missing the example of attaching XBL by means of CSS

We will add that into the example.

>  The example stops "violently", why the first example is not completed with
> the actual binding used to resolve the problem?

I think there is a note there about that in the document. However,
that example may be dropped.

>  + Recap of terminology
>
>  Shouldn't it be in chapter 1? under the concepts section?

Those sections will be similar to each other. Some people might not
want to read the tutorial in chapter 1 and might just want to jump to
the more advanced examples in part 2...

>  + The <xbl> element
>
>  "XBL elements that are not inside an XBL declaration are treated as
> arbitrary XML, even is the elements are scoped through a namespace" What are
> you trying to mean? Does it make sense to have XBL elements outside an XBL
> declaration?. if it is an obscure feature it shouldn't be mentioned in a
> primer

I will clarify this in the primer a bit... however, it means that you
can't do the following:
<widget xmlns="http://e.com/ui"
        xmlns:html="http://www.w3.org/1999/xhtml"
	xmlns:xbl="http://www.w3.org/ns/xbl">
   <xbl:script>
   	alert("this will never work..");
   </xbl:script>
   <html:script>
   	alert("but this will!");
   </html:script>
</widget>

>  + The content element
>
>  The examples are not read properly. They are confusing. The purpose of the
> example, the problem to solve and the binding used is not explained clearly

Yes, this section is fairly poor ATM.

>  + Rest of the document. Examples are missing

Lachlan Hunt has just joined the working group to help us come up with
good examples.

>  Could it make sense to have a complete example, use case that illustrates
> the usage of the prefetch, resources, style, etc, at the same time?

We can definitely have that. Please send us more requests or send us
usage examples.

Thanks for the comments!

Kind regards,
--

-- 
Marcos Caceres
http://datadriven.com.au

[read access] Shaping the future of secure Ajax mashups

A relevant article in the context of the Read Access spec:

  Shaping the future of secure Ajax mashups
  <http://www-128.ibm.com/developerworks/xml/library/x-securemashups/>

The above article mentions a couple techniques to address cross- 
domain data access including the WHAT WG's Cross-document messaging  
i.e.:

   <http://www.whatwg.org/specs/web-apps/current-work/ 
#crossDocumentMessages>

and the <module> element.

Does anyone know if the <module> element and/or the Cross-document  
messaging mechanism are in scope (i.e. in plan) for the W3C's HTML WG?

Regards,

Art Barstow
---

Re: [XBL Primer] Comments

Hi Marcos,

See inline my answers to your questions

Marcos Caceres escribió:
>
> Hi Jose,
>
> On 4/4/07, José Manuel Cantera Fonseca <jmcf <at> tid.es> wrote:
>>
>>  Commenting:
>> http://dev.w3.org/cvsweb/2006/waf/XBLPrimer/Overview.src.html?rev=1.16
>>
>>  + There are some typos in the document
>>
>>  + Abstract
>>
>>  "This document provides you with the practical knowledge ..."
>>
>>  Shouldn't it say "This document provides the practical knowledge ..."
>> Perhaps for you native speakers it sounds ok but for me no, I don't 
>> know ...
>
> To me it reads ok. It's just written in an informal voice; that's
> intentional. If we find that people find this style irritating, then
> we can change the tone.
>
>>  + Status of document
>>
>>  "Implementors should be aware that this specification is not stable ...
>>  "This document was produced ...
>>
>>  Is this really needed for a W3C Note? This is not the XBL 2 spec ....
>
> It might not look like it now, but this ain't no W3C Note; It's going
> down the rec track. This was agreed to at the last face to face
> meeting in Boston. There is precedence for this (xml schema, rdf,
> etc).
>
>>  + Table of contents
>>  It would be good to have it completed, although some of the contents 
>> were
>> empty. This would give the reader an overview of the whole document 
>> and what
>> the editors are planning to do for the next versions
>
> Agreed. We will have a better idea after the next face 2 face meeting
> (April 17th)... also I need to run the CSS processor over the document
> to get the proper ToC. However, I won't process it until the document
> is much more mature because the processor makes a mess.
>
>>  + Use of the word XBL. It should be used consistently over the whole
>> document i.e. it should be used XBL 2 everytime or there should be a
>> statement saying that "hereinafter when the 'XBL' word is appearing 
>> we are
>> talking about 'XBL 2'"
>
> Agreed. I will change everything to "XBL".
>
>>  + Introduction
>>  Perhaps the statement "The move in web development towards avoiding the
>> table element for layout has led developers to consider how to 
>> exploit other
>> HTML elements, CSS, and ECMAScript to achieve complex layouts." 
>> should not
>> be the first in this paragraph and should be used as an example of 
>> highly
>> accessible content i.e avoiding usage of tables for layout
>
> I don't understand. Can you please elaborate?
Counterproposal for that text:

"The move in Web 2.0 technologies towards having highly accessible 
content that is both adaptive
and provides an engaging user experience has led developers to consider 
how to exploit other HTML elements, CSS, and ECMAScript to achieve it.
 One example of this is the deprecation in the usage of the table 
element for layout.
 However, a new problem has emerged where by web documents are now 
heavily 'polluted' the semantically-neutral
div element and complex JavaScript and CSS that is hard for authors to 
maintain."

>
>>  + XBL concepts
>>  The content under this section hasn't any concepts ...
>
> 
>
>>  + Working example.
>>
>>  In the text it is mentioned "Log on· as legend, but in the markup 
>> example
>> appears "Log in" in the legend tag. In the next step (adding divs and 
>> CSS)
>> in the figure appears login instead of log on :)
>
> Yes, I have to take another screen-shot of the image. It's on my todo 
> list.
>
>>  You don't have put a label for the submit input, this occasionates 
>> that a
>> default label is put in the submit button and that label depends on the
>> browser language, so in my browser, which is configured in Spanish, I 
>> see a
>> Spanish label intermixed with the English labels of the other fields.
>
> Ah, of course! I will fix that. I should get into the practice of
> putting my system language into Spanish to test stuff.
>
>>  In the div example the CSS is not shown. This can be misleading
>
> Still working that out.
>
>>  I don't see the need of duplicating the effort creating one XML 
>> version and
>> another HTML version of the example. One practical way to face this
>> difference would be to work in XHTML (the more general option) and 
>> provide
>> an specific example wrt attaching the XBL via CSS (which is also 
>> permitted
>> in XHTML) and say "this is the way how an HTML document would be 
>> bound to an
>> XBL binding"
>
> Yeah, I figured that too... I will dump the XHTML examples and only do
> HTML. When I first wrote this, I thought XHTML still had a future
>
ok
>>  + Creating an XBL document and attaching it to another document
>>
>>  It seems that this section looses the continuity with the example,
>> shouldn't be the continuation of the example?
>
> Yes, I agree the linking is very weak here. I will fix that soon, but
> the current example my be dumped because I am starting to think that
> XBL adds little value to it.
maybe you are right  I was trying to develop the example on my own and I 
have found some issues, I will try to develop it completely and see if 
it really makes sense
>
>>  + Attaching XBL using ...
>>
>>  I'm missing the example of attaching XBL by means of CSS
>
> We will add that into the example.
>
>>  The example stops "violently", why the first example is not 
>> completed with
>> the actual binding used to resolve the problem?
>
> I think there is a note there about that in the document. However,
> that example may be dropped.
>
>>  + Recap of terminology
>>
>>  Shouldn't it be in chapter 1? under the concepts section?
>
> Those sections will be similar to each other. Some people might not
> want to read the tutorial in chapter 1 and might just want to jump to
> the more advanced examples in part 2...
>
>>  + The <xbl> element
>>
>>  "XBL elements that are not inside an XBL declaration are treated as
>> arbitrary XML, even is the elements are scoped through a namespace" 
>> What are
>> you trying to mean? Does it make sense to have XBL elements outside 
>> an XBL
>> declaration?. if it is an obscure feature it shouldn't be mentioned in a
>> primer
>
> I will clarify this in the primer a bit... however, it means that you
> can't do the following:
> <widget xmlns="http://e.com/ui"
>        xmlns:html="http://www.w3.org/1999/xhtml"
>     xmlns:xbl="http://www.w3.org/ns/xbl">
>   <xbl:script>
>       alert("this will never work..");
>   </xbl:script>
>   <html:script>
>       alert("but this will!");
>   </html:script>
> </widget>
>
>>  + The content element
>>
>>  The examples are not read properly. They are confusing. The purpose 
>> of the
>> example, the problem to solve and the binding used is not explained 
>> clearly
>
> Yes, this section is fairly poor ATM.
>
>>  + Rest of the document. Examples are missing
>
> Lachlan Hunt has just joined the working group to help us come up with
> good examples.
>
>>  Could it make sense to have a complete example, use case that 
>> illustrates
>> the usage of the prefetch, resources, style, etc, at the same time?
>
> We can definitely have that. Please send us more requests or send us
> usage examples.
>
> Thanks for the comments!
>
> Kind regards,

XBL2 and tabbing

Hi all,

I was recently talking to Alex Vincent about how tabbing should work in
XBL1. Currently it is something of a mess and not something I think we
should pay attention to. However I do think that we should define how
XBL2 interacts with tabbing.

Section 6.10 sort of mentions what should happen;

"When the user tabs such that the file control should become focused,
the user agent determines if any shadow content should also become
focused, using the tab order specified by the shadow content elements.
It then generates a focus event on the text field inside the file
control. As this event flows across shadow scopes, it is retargeted to
be a focus event on the file control itself."

But first of all this is located in a very illogical place, and second,
the language used isn't very normative.

What I think should happen is this:

When a bound element gets focus, for example by the user tabbing to the
bound element, or using some API such as HTMLInputElement.focus, the
implementation looks though the shadow content of the binding and
focuses the first focusable per the following algorithm:

1. Start with the most derived binding.
2. Use the nodes in the shadow tree of the binding to create a list
    of focusable[a] elements sorted in tabbing order[b]. Make sure
    to consider <inherited> elements as focusable when creating this
    list.
3. Remove all but the first <inherited> elements from the list.
4. If there is an inherited binding with a shadow tree, and there is an
    <inherited> element in the list, create a list of focusable elements
    for that binding according to steps 2-4 and replace the <inherited>
    element with that list.

If the resulting list is non-empty the first element in the list is 
focused along with the bound element. Note that focusing the inner 
element can recursively the same process if that element has bindings 
attached to it.

If the list is empty only focus the bound element.

[a] We should define focusable here such that it matches what users can
tab to today. This means that an element who has visibility:hidden is
not focusable, and an element that has, or has an ancestor that has,
display:none, is not focusable.

[b] The order of this list typically both takes into account any 
explicit tab ordering defined on the elements, such as using the 
tabindex attribute on HTML elements, and the order of the elements in 
the DOM.

Further, when tabbing use the following steps:

1. Create a list of the currently focused elements. The first element in
    the list should be the element in the bound document that currently
    has focus. The second element in the list is the element in the most
    derived binding with a shadow tree that has focus, and so on.
2. If the list is only one item long use the normal tab mechanism for
    the UA and stop.
3. Select the last element in the list and remove it from the list.
4. For the new last element in the list, create a sorted list of
    focusable elements using the above steps.
5. Find the selected element in that list. If the selected element is
    not last in the list, focus the element after it and stop.
6. Restart at step 2 using the new list of focused elements.

The result of this is that when tabbing and the focused element has 
bindings containing multiple focusable elements, those elements are 
first cycled through before focus moves to the next focusable element in 
the bound document. Another result is that tab indexes are local to each 
binding.

What do other people think?

Best Regards
/ Jonas Sicking

Re: XBL2 and tabbing

On Wed, 11 Apr 2007 05:27:57 +0200, Jonas Sicking <jonas <at> sicking.cc> wrote:
> What do other people think?

If we're going to define the focus model in more detail I think we should  
try to cater for non-tabbing navigation as well, such as spatial  
navigation. I haven't looked in detail at your proposal though to see  
whether or not that's addressed. Just mentioning it here for future  
reference.

--

-- 
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>

Re: XBL2 and tabbing

Aqui esta una grande oportunidad de hacer dinero en tiempo libre, accesible desde Thu, 12 Apr 2007 08:04:51 -0600

[XBL Primer] new scenarios

Hi all,
A few of us have been discussing the XBL Primer and we have come up
with some additional scenarios which we feel may introduce features of
XBL that will be of most value to web developers. WAF meeting this
week in Brisbane (Australia) to discuss the following scenarios in
details, so any feedback we received in the next few days will be part
of our decision-making process.

Please note that the order in which the following scenarios will
actually appear in the spec is still under discussion.

1.  Creating a multi-column layout with XBL: The purpose of this
scenario is to demonstrate XBL's ability to reorder content, as we
believe content reordering will be a fairly common use-case. Apart
from introducing developers to bindings, this scenario introduces
loading and applying custom style sheets. This particular scenario may
also focus on dynamically adapting content for mobile devices through
XBL (however, the likelihood that XBL will be implemented on a mobile
device in the near future is rather optimistic:)).

Elements/concepts:
	* binding attachment
	* xbl element
	* template element
	* content element
	* div element
	* resource(s) element
	* style element

2. Form controls: performing form validation and enhancing
presentation/user experience. We assume that form validation will
likely be one of the most common use cases of XBL. We are thinking of
extending the login widget example that is currently in the Primer
with richer presentation and user feedback.

We will probably create another form validation scenario that shows
validation on a more complex form (I personally want to demonstrate
how to use XBL with XHR). We are contemplating examples using both
HTML and Web Forms 2. However, we are still trying to identify
non-trivial gaps in Web Forms 2 that XBL can fill, so input is here is
very welcomed.

Elements/concepts:
* implementation
* scripts
* inheritance
* event forwarding
* fallback content
* handler(s) elements
* key, mouse, and DOM events
* xbl:psudo
* prefetch

3. Enhancing user experience: We have been considering creating an
example that shows how to take existing content and enhancing its
presentation/experience with XBL. The scenario we have been discussing
focuses around a sample document that contains various <cite> elements
and a bibliography marked-up using a <dl>. We essentially want to do
something like display the bibliographical information for a reference
when the user mouses over a citation.

Main elements/concepts:
	* enhancing presentation without changing the content
        * content reordering
	* events
	* Author sheets

4. Re-purposing content to increase accessibility: the scenario would
be one where stock quotes, or some other symbolic data, are
represented in a more accessible way (eg. spoken or graphically). The
idea would be to pull in data, say using XHR or HTML5's event-source,
and to (re)present the data using text-to-speech (either using Aural
CSS or voiceXML), SVG, or Canvas.

Main elements/concepts:
	Accessibility
	XBL media independence

The technical details of this particular scenario are obviously yet to
be fully sketched out.

5. Language reference (as an Appendix): The language reference will
cover the elements/attributes in the spec, but in terms that
developers (like me) can more easily understand. Essentially, we want
to create a reference that developers can use in everyday work
situations. It will also have examples in HTML (possibly HTML5)
instead of XML. There is debate within the working group about wether
the Primer should include a language reference. I personally feel it
does no harm having it as long as it is informative, accurate, and
contains applicable usage examples. Please let us know if this is a
section that is desired/helpful.

Again, we would really appreciate more public feedback regarding the Primer.

Kind regards,
--

-- 
Marcos Caceres
http://datadriven.com.au