[gamepad] Reasoning behind GamepadButton struct

2014-02-20 Thread Brandon Jones
I've been working with the Gamepad API implementation in Chrome recently,
trying to bring it up-to-date with the latest editors draft of the spec (
https://dvcs.w3.org/hg/gamepad/raw-file/default/gamepad.html). While
generally I feel like it's a good update to the working draft I'm puzzled
by the decision to change the gamepad buttons from an array of floats to an
array of GamepadButton structures.

Specifically, it appears to add complexity to the interface and
implementation without providing new information to developers. I can see
that if a piece of hardware provided custom deadzones on axes which would
eventually be interpreted as buttons that it may be convenient to use that
to determine the pressed state, but no hardware I know of actually does
so. (XInput suggests a trigger deadzone of 30/255, but that's an arbitrary
guideline and probably works well for most similar hardware.) If there is
concern about input noise providing false positives presses for these
types of buttons it would seem pretty trivial for the browser
implementation to apply the deadzone internally, and only provide non-zero
values above the desired threshold.

I recognize that Mozilla has already implemented the API as described in
the editors draft, and I don't want to place additional burden on them to
change it unnecessarily. I'm happy to update Chrome's implementation to
match, but I want to ensure this is the right direction before I do. It's
also worth noting that many of the existing web apps that use the API
(though they are admittedly few) expect the buttons to be exposed as
floats, and as such updating Chrome's implementation will break these use
cases. (New fields like mapping and connected, on the other hand, can
be exposed without requiring changes from the app).

I apologize if this has been addressed before, as I've only recently
started working on the implementation and am not familiar with the full
spec history. I haven't seen this particular point discussed in the
archives, however, so I figured it was worth bringing up.

--Brandon Jones


Re: [gamepad] Reasoning behind GamepadButton struct

2014-02-20 Thread Ted Mielczarek
On 2/20/2014 1:35 PM, Brandon Jones wrote:
 I've been working with the Gamepad API implementation in Chrome
 recently, trying to bring it up-to-date with the latest editors draft
 of the spec
 (https://dvcs.w3.org/hg/gamepad/raw-file/default/gamepad.html). While
 generally I feel like it's a good update to the working draft I'm
 puzzled by the decision to change the gamepad buttons from an array of
 floats to an array of GamepadButton structures.

 Specifically, it appears to add complexity to the interface and
 implementation without providing new information to developers. I can
 see that if a piece of hardware provided custom deadzones on axes
 which would eventually be interpreted as buttons that it may be
 convenient to use that to determine the pressed state, but no
 hardware I know of actually does so. (XInput suggests a trigger
 deadzone of 30/255, but that's an arbitrary guideline and probably
 works well for most similar hardware.) If there is concern about input
 noise providing false positives presses for these types of buttons
 it would seem pretty trivial for the browser implementation to apply
 the deadzone internally, and only provide non-zero values above the
 desired threshold.

I made this change to support two major use cases:
1) Analog buttons with known (or at least recommended) threshold values
(like the XINPUT_GAMEPAD_TRIGGER_THRESHOLD you mentioned). While it's
possible for applications to use an estimate here, it felt better to
allow implementations to use API-provided information when available.
2) Controllers with both analog and digital sensors on buttons. The
DualShock 3 (and presumably DualShock 4) controllers are like this--they
have a separate digital switch and analog sensor on most buttons, so you
do legitimately have separate pressed and value for each button. Not
supporting this means you're throwing away one of the values.

FWIW it looks like Apple has codified this in their Game Controller
framework for iOS/OS X 10.9 as well[1], their GCControllerButtonInput
class has pressed and value members.


 I recognize that Mozilla has already implemented the API as described
 in the editors draft, and I don't want to place additional burden on
 them to change it unnecessarily. I'm happy to update Chrome's
 implementation to match, but I want to ensure this is the right
 direction before I do. It's also worth noting that many of the
 existing web apps that use the API (though they are admittedly few)
 expect the buttons to be exposed as floats, and as such updating
 Chrome's implementation will break these use cases. (New fields like
 mapping and connected, on the other hand, can be exposed without
 requiring changes from the app).
Right, which is why I felt like now was the time to make this change,
before anyone shipped a non-prefixed version of the API. I didn't want
to worry about making a non-backwards compatible change in the future
when we had consumers of an unprefixed API. Anyone using Chrome's
existing prefixed API will have to change to support the non-prefixed
version anyway, and it's not much more work to support the GamepadButton
change[2].


 I apologize if this has been addressed before, as I've only recently
 started working on the implementation and am not familiar with the
 full spec history. I haven't seen this particular point discussed in
 the archives, however, so I figured it was worth bringing up.

My coworker Alan sent a mail about the remaining things we wanted to
clean up in the spec a while ago, and I filed a spec bug on this
issue[4], and we didn't get any feedback either way so I proceeded with
it. Unfortunately we haven't got a lot of feedback on the spec in
general, I'm hoping that will change as we get more consumers.
(Hopefully they don't ask for breaking changes, though!)

Thanks for taking on the task of making Chrome's implementation match
the latest spec, it's appreciated!

-Ted

1.
https://developer.apple.com/library/ios/documentation/GameController/Reference/GCControllerButtonInput_Ref/Reference/Reference.html#//apple_ref/doc/c_ref/GCControllerButtonInput
2. https://github.com/luser/gamepadtest/blame/master/gamepadtest.js#L70
3. http://lists.w3.org/Archives/Public/public-webapps/2013AprJun/0958.html
4. https://www.w3.org/Bugs/Public/show_bug.cgi?id=21388



[Bug 24704] @contenteditable, new lines and new paragraphs.

2014-02-20 Thread bugzilla
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24704

Ian 'Hixie' Hickson i...@hixie.ch changed:

   What|Removed |Added

 CC||i...@hixie.ch,
   ||public-webapps@w3.org
  Component|HTML|HTML Editing APIs
   Assignee|i...@hixie.ch|a...@aryeh.name
Product|WHATWG  |WebAppsWG
   Target Milestone|Unsorted|---
 QA Contact|contribu...@whatwg.org  |sideshowbarker+html-editing
   ||-a...@gmail.com

-- 
You are receiving this mail because:
You are on the CC list for the bug.



Form submission participation (was Re: Goals for Shadow DOM review)

2014-02-20 Thread Edward O'Connor
+public-webapps, -www-tag in replies to avoid cross-posting

Hi,

Domenic wrote, to www-tag:

 [C]an shadow DOM be used to explain existing elements, like video or
 input type=range, in terms of a lower-level primitive?

 As of now, it seems like it cannot, for two reasons:

 1. Native elements have extra capabilities which are not granted by
 shadow DOM, or by custom elements. For example, they can participate
 in form submission.

Authors need to be able to participate in form submission, but this is
independent of Custom Elements.

Web applications often maintain state in JS objects that have no direct
DOM representation. Such applications may want such state to be
submittable.

Existing form elements map one field name to many values. People often
build custom controls precisely because those controls hold more
complex values that would be better represented as many names to many
values. Subclassing existing form elements don't get you this.

And inheriting from HTMLInputElement is insane (not because inheriting
is insane, but because HTMLInputElement is insane), so that's not really
how we want author-defined objects to become submittable.

Given the above I don't think we should try to solve the how authors
can participate in form submission problem by enabling the subclassing
of existing form elements. Instead, we should define a protocol
implementable by any JS object, which allows that JS object to expose
names and values to the form validation and submission processes.

Something like this:

  function Point(x, y) {
this.x = x;
this.y = y;
  }
  Point.prototype.formData = function() {
return {
  x: this.x,
  y: this.y
};
  }

  var theForm = document.querySelector(#my-form);

  var p = new Point(4,2);

  theForm.addParticipant(p);
  theForm.submit();

This is obviously a super hand-wavy strawman and would need to be
fleshed out. Thoughts?


Ted



Re: Form submission participation (was Re: Goals for Shadow DOM review)

2014-02-20 Thread Charles Pritchard

 On Feb 20, 2014, at 2:09 PM, Edward O'Connor eocon...@apple.com wrote:
 
 +public-webapps, -www-tag in replies to avoid cross-posting
 
 Hi,
 
 Domenic wrote, to www-tag:
 
 [C]an shadow DOM be used to explain existing elements, like video or
 input type=range, in terms of a lower-level primitive?
 
 As of now, it seems like it cannot, for two reasons:
 
 1. Native elements have extra capabilities which are not granted by
 shadow DOM, or by custom elements. For example, they can participate
 in form submission.
 
 Authors need to be able to participate in form submission, but this is
 independent of Custom Elements.
 
 Web applications often maintain state in JS objects that have no direct
 DOM representation. Such applications may want such state to be
 submittable.
 
 Existing form elements map one field name to many values. People often
 build custom controls precisely because those controls hold more
 complex values that would be better represented as many names to many
 values. Subclassing existing form elements don't get you this.
 
 And inheriting from HTMLInputElement is insane (not because inheriting
 is insane, but because HTMLInputElement is insane), so that's not really
 how we want author-defined objects to become submittable.
 
 Given the above I don't think we should try to solve the how authors
 can participate in form submission problem by enabling the subclassing
 of existing form elements. Instead, we should define a protocol
 implementable by any JS object, which allows that JS object to expose
 names and values to the form validation and submission processes.
 
 Something like this:
 
  function Point(x, y) {
this.x = x;
this.y = y;
  }
  Point.prototype.formData = function() {
return {
  x: this.x,
  y: this.y
};
  }
 
  var theForm = document.querySelector(#my-form);
 
  var p = new Point(4,2);
 
  theForm.addParticipant(p);
  theForm.submit();
 
 This is obviously a super hand-wavy strawman and would need to be
 fleshed out. Thoughts?
 
 
 Ted
 


Sounds like a great idea; can that kind of thinking also be applied to 
HTMLMediaElement interfaces  for custom video/audio handling with play/pause 
buttons?

There are some tricks with streams but it'd be really nice to be able to 
essentially use video controls with custom elements backed by media sources 
like SVG and Canvas.

Not to derail the conversation... I think you're absolutely on the right track.


-Charles


Re: Form submission participation (was Re: Goals for Shadow DOM review)

2014-02-20 Thread Jonas Sicking
On Thu, Feb 20, 2014 at 2:09 PM, Edward O'Connor eocon...@apple.com wrote:
 +public-webapps, -www-tag in replies to avoid cross-posting

 Hi,

 Domenic wrote, to www-tag:

 [C]an shadow DOM be used to explain existing elements, like video or
 input type=range, in terms of a lower-level primitive?

 As of now, it seems like it cannot, for two reasons:

 1. Native elements have extra capabilities which are not granted by
 shadow DOM, or by custom elements. For example, they can participate
 in form submission.

 Authors need to be able to participate in form submission, but this is
 independent of Custom Elements.

 Web applications often maintain state in JS objects that have no direct
 DOM representation. Such applications may want such state to be
 submittable.

 Existing form elements map one field name to many values. People often
 build custom controls precisely because those controls hold more
 complex values that would be better represented as many names to many
 values. Subclassing existing form elements don't get you this.

 And inheriting from HTMLInputElement is insane (not because inheriting
 is insane, but because HTMLInputElement is insane), so that's not really
 how we want author-defined objects to become submittable.

 Given the above I don't think we should try to solve the how authors
 can participate in form submission problem by enabling the subclassing
 of existing form elements. Instead, we should define a protocol
 implementable by any JS object, which allows that JS object to expose
 names and values to the form validation and submission processes.

 Something like this:

   function Point(x, y) {
 this.x = x;
 this.y = y;
   }
   Point.prototype.formData = function() {
 return {
   x: this.x,
   y: this.y
 };
   }

   var theForm = document.querySelector(#my-form);

   var p = new Point(4,2);

   theForm.addParticipant(p);
   theForm.submit();

 This is obviously a super hand-wavy strawman and would need to be
 fleshed out. Thoughts?

Something like this seems awesome! I like that the .addParticipant
function can enable random JS objects to participate in submission. A
couple of comments though:


I'm not sure if we should return a dictionary or an array. Keep in
mind that a form control can have multiple values. This is something
used by both input multiple and select multiple. Also keep in mind
that order matters as many servers are sensitive to order.

So we could either do `return { x: [5, 6, 7] }` where enumeration
order determines submission order, or we could do `return [[x, 5],
[x, 6], [x, 7]]`.

Or, given that normally a single form control only has a single name
and 0 to many values, we could do `return { name: x, value: [5, 6,
7] }`.


The other thing is that it would be great if elements that wanted to
participate in submission didn't have to manually call addParticipant.
This could be done by having the form element attempt check for a
.formData property on any descendant that was added, and add any
elements that has such a property as a participant automatically.

We could even make the built-in form controls like input and
select have a .formData() function which returns data in whatever
format we decide is the right one.

This way custom elements could very easily and automatically
participate in submission by simply declaring a .formData property.

The only tricky part is that form.controls is a live array. I don't
see a way of making form.controls contain custom elements without
synchronously running getters whenever an element is added as a
descendant of a form, which is not something we want to do. But live
arrays are evil anyway so we can probably just ignore integration with
that and instead add a form.getParticipants() function which returns a
non-live array of all participants.

/ Jonas



RE: Form submission participation (was Re: Goals for Shadow DOM review)

2014-02-20 Thread Domenic Denicola
From: Jonas Sicking jo...@sicking.cc

 I'm not sure if we should return a dictionary or an array. Keep in mind that 
 a form control can have multiple values. This is something used by both 
 input multiple and select multiple. Also keep in mind that order matters 
 as many servers are sensitive to order.

I wonder if the existing `FormData` objects have something to say here? Could 
we use them? Are they constructible yet? (Are the constructors as easy to use 
as the syntaxes you propose?) Presumably the spec for those encapsulates most 
of the complexities involved here already.

 The other thing is that it would be great if elements that wanted to 
 participate in submission didn't have to manually call addParticipant. This 
 could be done by having the form element attempt check for a .formData 
 property on any descendant that was added, and add any elements that has such 
 a property as a participant automatically.

I really like this idea and the subsequent paragraphs in which you flesh it 
out. Makes great sense to me.



Re: Form submission participation (was Re: Goals for Shadow DOM review)

2014-02-20 Thread Edward O'Connor
Hi Jonas,

You wrote:

 I'm not sure if we should return a dictionary or an array.

Yeah, it should be an array.

 The other thing is that it would be great if elements that wanted to
 participate in submission didn't have to manually call addParticipant.

Yes.

 This could be done by having the form element attempt check for a
 .formData property on any descendant that was added, and add any
 elements that has such a property as a participant automatically.

That doesn't handle this case:

formp contenteditable/form

I'd like a way to declaratively say that that contenteditable
participates with name foo.

The obvious thing would be to literally add name=foo, but that doesn't
work because of

forma name=foo/a/form

so we'd need a different attribute name. participant=foo or something.

 We could even make the built-in form controls like input and
 select have a .formData() function which returns data in whatever
 format we decide is the right one.

Right. toFormData() or the like, parallel to toJSON().

 The only tricky part is that form.controls is a live array. I don't
 see a way of making form.controls contain custom elements without
 synchronously running getters whenever an element is added as a
 descendant of a form, which is not something we want to do. But live
 arrays are evil anyway so we can probably just ignore integration with
 that and instead add a form.getParticipants() function which returns a
 non-live array of all participants.

Yeah, I think we just say that form.controls is the legacy feature that
only exposes built-in controls. form.getParticipants() works for me.


Ted



[Bug 24756] New: [imports]: Cascading order for stylesheets of imported documents should be stated more clearly

2014-02-20 Thread bugzilla
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24756

Bug ID: 24756
   Summary: [imports]: Cascading order for stylesheets of imported
documents should be stated more clearly
   Product: WebAppsWG
   Version: unspecified
  Hardware: PC
OS: Linux
Status: NEW
  Severity: normal
  Priority: P2
 Component: Component Model
  Assignee: dglaz...@chromium.org
  Reporter: morr...@google.com
QA Contact: public-webapps-bugzi...@w3.org
CC: m...@w3.org, public-webapps@w3.org
Blocks: 20683

This is follow-up for Bug 24616.

The spec states how it should be ordered [1] but it should be clearer.
Basically,

A) The imported style has tree order, 
   The tree order in the import referrer is defined by the location
   of link rel=import.
B) If there are multiple link to the same document, the first one should win.

A) is for developer ergonomics. link rel=stylesheet works in this way,
   so import is better to follow the same pattern
B) is for eliminating duplication. The first wins rule is same as
   what it does for script

[1]
https://github.com/w3c/webcomponents/commit/600f7bf2f06b2cb5f712fc5dc928085682502941

-- 
You are receiving this mail because:
You are on the CC list for the bug.



[Bug 24616] [imports]: Stylesheets in imported documents should be loaded

2014-02-20 Thread bugzilla
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24616

Morrita Hajime morr...@google.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #3 from Morrita Hajime morr...@google.com ---
Closing as it is dumped into the ToT [1].

We certainly need more polish though. I'll do it by filing finer-grained bugs
(starting from Bug 24756), so that it makes the point clear.

[1] http://w3c.github.io/webcomponents/spec/imports/#style-imports

-- 
You are receiving this mail because:
You are on the CC list for the bug.



Re: Form submission participation (was Re: Goals for Shadow DOM review)

2014-02-20 Thread Jonas Sicking
On Thu, Feb 20, 2014 at 2:51 PM, Edward O'Connor eocon...@apple.com wrote:
 This could be done by having the form element attempt check for a
 .formData property on any descendant that was added, and add any
 elements that has such a property as a participant automatically.

 That doesn't handle this case:

 formp contenteditable/form

 I'd like a way to declaratively say that that contenteditable
 participates with name foo.

 The obvious thing would be to literally add name=foo, but that doesn't
 work because of

 forma name=foo/a/form

 so we'd need a different attribute name. participant=foo or something.

Is it really going to be a common case to want to submit a
contenteditable declaratively? I feel like in most cases using
contenteditable requires writing heaps of javascript. In part because
contenteditable implementations generally sucks and there's been a
historical lack of specs, but also because in many cases you don't
want a freeform HTML editor, but rather an editor of some other data
model that your page contains.

For example the contenteditable i'm typing in right now in gmail
attempts to implement en email editor, not a generic HTML editor.

In these cases you'd likely also want to submit something other than
the serialization of the markup in the contenteditable element.

However, if we do want to allow script-less form submission of
contentediable then I think having a participant=foo attribute would
work. We could define that when that attribute is set .formData goes
from returning null to returning a function. It's a bit weird but it'd
work. I assume that the function would return something like { name:
this.participant, value: this.innerHTML }?

 The only tricky part is that form.controls is a live array. I don't
 see a way of making form.controls contain custom elements without
 synchronously running getters whenever an element is added as a
 descendant of a form, which is not something we want to do. But live
 arrays are evil anyway so we can probably just ignore integration with
 that and instead add a form.getParticipants() function which returns a
 non-live array of all participants.

 Yeah, I think we just say that form.controls is the legacy feature that
 only exposes built-in controls. form.getParticipants() works for me.

Agreed. form.controls is pretty crappy anyway in that it's live and
that it doesn't include input type=image elements for webcompat
reasons (stemming from an old Netscape bug :))

/ Jonas



Decoupling style scoped from Shadow DOM

2014-02-20 Thread Erik Bryn
Hi everyone,

First time caller, long time listener.

From what I understand, the browser vendors seem to be bundling style
scoped with the Shadow DOM spec. I'd like to start a discussion around
decoupling the two and asking that vendors prioritize shipping style
scoped over Shadow DOM as a whole. As a web developer and JS framework
author, the single most important feature that I could use immediately and
I believe is totally uncontroversial is style scoped.

Thoughts?

Thanks,
- Erik


Re: Decoupling style scoped from Shadow DOM

2014-02-20 Thread Hajime Morrita
Here is my understanding:

Firefox has already shipped style scoped without Shadow DOM and I guess
there is no dependency from scoped style to shadow DOM as the former is
done before the later is started.

WebKit situation was similar. style scoped was done before Shadow DOM,
and style scoping for Shadow DOM was done on top of style scoped
internals. There was no dependency from style scoped to Shadow DOM. And
it seems both style scoped and non-builtin part of Shadow DOM was removed
since then.

In Blink, Shadow DOM styling and style scoped kind of share the
underlying plumbing. But it is more like that both depend on same
lower-level mechanism for style scoping of DOM subtree. There is no direct
dependency between both.

So these two are almost orthogonal from implementation perspective, as are
their specs.

--
morrita



On Thu, Feb 20, 2014 at 6:05 PM, Erik Bryn e...@erikbryn.com wrote:

 Hi everyone,

 First time caller, long time listener.

 From what I understand, the browser vendors seem to be bundling style
 scoped with the Shadow DOM spec. I'd like to start a discussion around
 decoupling the two and asking that vendors prioritize shipping style
 scoped over Shadow DOM as a whole. As a web developer and JS framework
 author, the single most important feature that I could use immediately and
 I believe is totally uncontroversial is style scoped.

 Thoughts?

 Thanks,
 - Erik




-- 
morrita