Re: Shadow DOM and Fallback contents for images

2013-10-15 Thread Hajime Morrita
The text in shadows are select-able, and it behaves kind of like iframes as
Ryosuke mentioned.

I'm not sure if these are clear from the current draft, but points are:

- Users can select a part of the shadow tree.

- If selected range is in a shadow tree, it isn't accessible (in API sense)
outside the shadow. For one outside the shadow, that is
document.getSelection(), the selection is represented as a range which
selects the shadow host. Inside shadow, that is ShadowRoot.getSelection(),
the selection points the node inside the shadow. This is how encapsulation
works with Shadow DOM.
  It's just about API. The UA knows what part of the text is selected. Thus
things like clipboards should work as expected.

- The selection cannot cross the shadow boundary. Both ends of the
selection should be in a same tree. I think this restriction is mainly for
simplicity.

Does this make sense?




On Mon, Oct 14, 2013 at 1:19 PM, Jonas Sicking jo...@sicking.cc wrote:

 On Sun, Oct 13, 2013 at 9:11 PM, Ryosuke Niwa rn...@apple.com wrote:
  On Oct 11, 2013, at 10:52 PM, Jonas Sicking jo...@sicking.cc wrote:
 
  On Fri, Oct 11, 2013 at 10:23 PM, Ryosuke Niwa rn...@apple.com wrote:
  On Oct 7, 2013, at 1:38 PM, Jonas Sicking jo...@sicking.cc wrote:
 
  On Oct 7, 2013 6:56 AM, Hajime Morrita morr...@google.com wrote:
 
  Hi,
 
  I'm sorry that I didn't notice that you were talking about UA shadow
 DOM.
  It's an implementation detail and the standard won't care about that.
 
  That being said, it might be a good exercise to think about
 feasibility to
  implement img-like custom element which supports alternate text.
 
  1. Selections – Which the specification is clear. It will not allow
 the
  selection range cannot span across different node trees. This again
 would
  hinder seamless experience with selection.
 
 
  Is this needed to implement alt text? Try this on Firefox:
  http://jsfiddle.net/8gkAV/2/ .
  The caret just skips the alt-text.
 
  I think we generally consider that a bug.
 
  I think this is a desirable behavior since the img element is
 atomic.  I
  don't think we want to let the user start editing the alt text since
 the
  user can't stylize the alt anyway.
 
  Note that this part is about selection, not editing. I don't see any
  reason to treat the alt text different from any other text. I.e. that
  the user can select character-by-character by default, but that this
  can be overridden by the author if desired.
 
  If I'm not mistaken, how alternative text is presented is up to UA
 vendors.  Given that, I don't think we should mandate one way or another
 with respect to this behavior.
 
  A more important question is what happens to selection inside a shadow
 DOM created by the author.
 
  2. Editing – The spec says that the contenteditable attribute should
 not
  be propagated from the shadow host to the shadow root. Does this
 mean that
  and Shadow DOM cannot participate in editing? This I find is
 limiting to use
  shadow DOM to represent fallback content
 
  This is same as 1) above. The caret skips the alt-text.
 
  I think these are desirable behavior because, if Shadow DOM is
 editable in
  @contentEditable subtree by default, the component author (who added
 the
  shadow DOM) has to make the element definition ready for editing.
 
  Selection and editing are related but different.
 
  Text displayed on screen should by default always be selectable. The
 fact
  that it isn't in canvas for example is a bad thing.
 
  It is fine to enable the author to opt out of making the selection
  selectable, but the default should be that it is selectable
 
  Ugh, my text here is gibberish :)
 
  I think I intended to say:
 
  It is fine to enable the author to opt out of making the shadow
  content selectable, but the default should be that it is selectable.
 
  I don't think that's what the spec currently says.  The way I
 interpret it,
  selection should work as if it's in a separate iframe. So the text
 will be
  selectable but the selection can only extend within the shadow DOM
 inside
  the shadow DOM, and selection will treat its shadow host as an
 atomic unit
  outside of it.
 
  Sounds like we should change the spec. Unless we have a good reason to
  treat selection as atomic?
 
  One good reason is that the editing specification needs to be aware of
 shadow DOM and various operations such as deletion and copy needs to take
 care of the shadow DOM boundaries.  e.g. what should UA copy if selection
 ends points are in two different shadow trees.
 
  Requiring each selection end to be in the same shadow tree solves this
 problem.

 Again, most selections are not related to editing.

 I think that if we made all text inside shadow content only selectable
 as a whole, that would make shadow content a second class citizen in
 the page. The result would be that authors actively avoid putting text
 inside shadow content since the user experience would be so
 surprising.

 As a user, I'm always annoyed 

Re: [gamepad] Seeking status and plans

2013-10-15 Thread Arthur Barstow

On 10/10/13 2:12 PM, ext Ted Mielczarek wrote:

Thanks for the nudge! My work on the spec (and the Firefox
implementation) fell by the wayside for many months, but I found some
time to work on my implementation recently. We (Mozilla) are shipping a
very-close-to-spec implementation in Nightly builds, and it's available
behind a preference in our current release (Firefox 24).

I'd actually like to ship our implementation in release soon, I just
have a few minor implementation bugs (with significant impact) to fix as
well as one possible breaking spec change[1]. With those in order I'd be
pretty happy to ship. We'd be shipping unprefixed, as is our new policy.

It's my understanding that Google has been shipping a prefixed
implementation that's also pretty close to the spec for some time now,
but that Scott suffers from the same Gamepad is not really my full-time
job problem that I do. He'd be more equipped to talk about this than I
am, certainly.

In terms of feature-completeness I think the spec is basically done.
Aside from that one breaking change I'd like to make I don't think
there's anything else we want to address right now that couldn't be done
in a future release of the spec. We've wanted to keep the scope small
from the beginning and I think we did okay. It definitely needs some
more work (mostly polishing of the text, fixing the existing bugs), but
we could certainly get out a new WD with the most recent text.


Thanks for this update Ted. Scott - please let us know if you have any 
additional status to share.


Since 21388 is now Resolved/Fixed, based on what you say above it seems 
like the next step should be to have a 1-week pre-LC call for 
comments. Then, assuming no major issues are raised, I would start a 
CfC to publish a LCWD.


However, I noticed 4 open bugs [Bugs]. What is the plan for these (f.ex. 
are they deferred to the next version)?


One reason groups publish a LCWD is to use it as a signal that broader 
review of the spec is desired, and in this case, perhaps we can ask 
Marcos to help us reach out to the developer community he mentioned in 
[Dev].


-Thanks, ArtB

[Dev] 
http://lists.w3.org/Archives/Public/public-webapps/2013OctDec/0181.html




-Ted

1. https://www.w3.org/Bugs/Public/show_bug.cgi?id=21388






Re: [gamepad] Seeking status and plans

2013-10-15 Thread Marcos Caceres



On Tuesday, October 15, 2013 at 12:47 PM, Arthur Barstow wrote:

 One reason groups publish a LCWD is to use it as a signal that broader 
 review of the spec is desired, and in this case, perhaps we can ask 
 Marcos to help us reach out to the developer community he mentioned in 
 [Dev].

 
I've pinged the developer, as he works for Moz. I can reach out to a few other 
devs too. If anyone knows folks working with this API, please let me know.   
 




Re: [gamepad] Seeking status and plans

2013-10-15 Thread Ted Mielczarek
On 10/14/2013 3:34 PM, Marcos Caceres wrote:
 Hi All, 
 The Gamepad API was briefly discussed at the LXJS conference.

 See:
 http://www.youtube.com/watch?v=ekvaKmVfjtct=5m30s

 It seems at least one developer is very unhappy with it. 

 Have we received any other feedback from developers about it? Has any effort 
 been made to reach out to other developers to get feedback? 

Thanks for the pointer. I watched that portion of the video and it's not
very constructive feedback. I'll reach out to him (considering he's a
coworker) and see if I can find out more specifics.

We heard from quite a few developers while implementing the first draft
of the API and they were overwhelmingly in favor of the current design.
I haven't heard much in the way of feedback from developers actually
testing the implementation we've shipped, so it's possible there are
issues with it in practice. I'd definitely like to hear more we declare
things finished.

-Ted




Re: Shadow DOM and Fallback contents for images

2013-10-15 Thread Ryosuke Niwa
On Oct 13, 2013, at 9:19 PM, Jonas Sicking jo...@sicking.cc wrote:

 On Sun, Oct 13, 2013 at 9:11 PM, Ryosuke Niwa rn...@apple.com wrote:
 On Oct 11, 2013, at 10:52 PM, Jonas Sicking jo...@sicking.cc wrote:
 
 On Fri, Oct 11, 2013 at 10:23 PM, Ryosuke Niwa rn...@apple.com wrote:
 On Oct 7, 2013, at 1:38 PM, Jonas Sicking jo...@sicking.cc wrote:
 
 On Oct 7, 2013 6:56 AM, Hajime Morrita morr...@google.com wrote:
 
 Hi,
 
 I'm sorry that I didn't notice that you were talking about UA shadow DOM.
 It's an implementation detail and the standard won't care about that.
 
 That being said, it might be a good exercise to think about feasibility to
 implement img-like custom element which supports alternate text.
 
 1. Selections – Which the specification is clear. It will not allow the
 selection range cannot span across different node trees. This again would
 hinder seamless experience with selection.
 
 
 Is this needed to implement alt text? Try this on Firefox:
 http://jsfiddle.net/8gkAV/2/ .
 The caret just skips the alt-text.
 
 I think we generally consider that a bug.
 
 I think this is a desirable behavior since the img element is atomic.  I
 don't think we want to let the user start editing the alt text since the
 user can't stylize the alt anyway.
 
 Note that this part is about selection, not editing. I don't see any
 reason to treat the alt text different from any other text. I.e. that
 the user can select character-by-character by default, but that this
 can be overridden by the author if desired.
 
 If I'm not mistaken, how alternative text is presented is up to UA vendors.  
 Given that, I don't think we should mandate one way or another with respect 
 to this behavior.
 
 A more important question is what happens to selection inside a shadow DOM 
 created by the author.
 
 2. Editing – The spec says that the contenteditable attribute should not
 be propagated from the shadow host to the shadow root. Does this mean 
 that
 and Shadow DOM cannot participate in editing? This I find is limiting to 
 use
 shadow DOM to represent fallback content
 
 This is same as 1) above. The caret skips the alt-text.
 
 I think these are desirable behavior because, if Shadow DOM is editable in
 @contentEditable subtree by default, the component author (who added the
 shadow DOM) has to make the element definition ready for editing.
 
 Selection and editing are related but different.
 
 Text displayed on screen should by default always be selectable. The fact
 that it isn't in canvas for example is a bad thing.
 
 It is fine to enable the author to opt out of making the selection
 selectable, but the default should be that it is selectable
 
 Ugh, my text here is gibberish :)
 
 I think I intended to say:
 
 It is fine to enable the author to opt out of making the shadow
 content selectable, but the default should be that it is selectable.
 
 I don't think that's what the spec currently says.  The way I interpret it,
 selection should work as if it's in a separate iframe. So the text will be
 selectable but the selection can only extend within the shadow DOM inside
 the shadow DOM, and selection will treat its shadow host as an atomic 
 unit
 outside of it.
 
 Sounds like we should change the spec. Unless we have a good reason to
 treat selection as atomic?
 
 One good reason is that the editing specification needs to be aware of 
 shadow DOM and various operations such as deletion and copy needs to take 
 care of the shadow DOM boundaries.  e.g. what should UA copy if selection 
 ends points are in two different shadow trees.
 
 Requiring each selection end to be in the same shadow tree solves this 
 problem.
 
 Again, most selections are not related to editing.

As far as I know, the most common use case of selecting anything on a Web page 
is copying it to somewhere else.

 I think that if we made all text inside shadow content only selectable
 as a whole, that would make shadow content a second class citizen in
 the page. The result would be that authors actively avoid putting text
 inside shadow content since the user experience would be so
 surprising.

What are concrete examples of components for which users have to select text 
across the shadow boundary?

- R. Niwa




Re: [gamepad] Seeking status and plans

2013-10-15 Thread Marcos Caceres


On Tuesday, October 15, 2013 at 4:01 PM, Ted Mielczarek wrote:

 On 10/14/2013 3:34 PM, Marcos Caceres wrote:
  Hi All, 
  The Gamepad API was briefly discussed at the LXJS conference.
  
  See:
  http://www.youtube.com/watch?v=ekvaKmVfjtct=5m30s
  
  It seems at least one developer is very unhappy with it. 
  
  Have we received any other feedback from developers about it? Has any 
  effort been made to reach out to other developers to get feedback? 
 Thanks for the pointer. I watched that portion of the video and it's not
 very constructive feedback. I'll reach out to him (considering he's a
 coworker) and see if I can find out more specifics.
 
 We heard from quite a few developers while implementing the first draft
 of the API and they were overwhelmingly in favor of the current design.
 I haven't heard much in the way of feedback from developers actually
 testing the implementation we've shipped, so it's possible there are
 issues with it in practice. I'd definitely like to hear more we declare
 things finished.
 


Ok, great. Let me know if I can do anything to help. 

-- 
Marcos Caceres