Re: [Shadow] URL-based shadows?

2015-03-21 Thread Ryosuke Niwa 

> On Mar 20, 2015, at 2:34 PM, Travis Leithead  
> wrote:
> 
>> Ryosuke Niwa [mailto:rn...@apple.com] wrote:
>> 
>>> Travis wrote:
>>> 2.&4. I keep running into trouble when thinking about a declarative model 
>>> for web components because declarative models are based on persistent 
>>> objects in the DOM, and those persistent objects are fully mutable. In 
>>> other words, you have to either accept and spec accordingly what happens 
>>> when key attributes are changed (e.g., your "defines" and "interface" 
>>> attributes), or you have to limit mutability such that changes are only 
>>> read-once (for example). I prefer to let frameworks write the declarative 
>>> syntactic sugar in the case of web components, and steer clear of 
>>> declarative models unless the mutability works in favor of the proposal.
>> 
>> This approach works for same-origin use cases but we couldn’t come up with a 
>> good imperative API for cross-origin scenarios.
> 
> Focusing on the imperative API for cross-origin scenarios sounds like a 
> useful endeavor to continue. Can you refer me to older proposals to review?

I don't recall any public proposal made.

>>> 3. I don't have an opinion here yet. It seems like limiting to custom 
>>> elements makes shadow dom easier to implement. But I can also imagine cases 
>>> where the component really wants to hook up to an element like  or 
>>>  in order to extend its host's feature set.
>> 
>> That use case comes up frequently on this list but I think that needs to be 
>> addressed by CSS-based decorators.  If we let custom “appearance” add a JS 
>> API, then UA wouldn’t be able to rip it apart for accessibility or for new 
>> platforms.
> 
> Can you clarify what you mean by that last sentence? I don't follow...?


Let me restate what I tried to say:

I think the reason attaching a shadow DOM on input and select elements come up 
as a use case is because people think it's a mechanism by which we can replace 
the appearance of those from control elements while preserving semantics and 
keeping them accessible.  Some people have also argued that such an approach 
will let future platforms to ignore the shadow DOM and use a more 
platform-appropriate appearance instead.

However, I'd argue that's a fraud concept because we can't assume the ARIA role 
of the shadow DOM to be that of the host element since the shadow DOM can 
contain multiple "controls" that the user needs to interact with; e.g. 
input[type=date], for example, may show a calendar widget with a control to 
select year, month, etc... inside its shadow DOM.  We can't ignore the shadow 
DOM entirely either if it's interacting with scripts since the rest of the page 
can make depend on the side effects of shadow DOM being there; e.g. updating 
some global state or sanitizing the value.  It's particularly problematic in 
the case the author intended the shadow DOM to extend the builtin elements 
because that's precisely when the author assumes the script that attached the 
shadow DOM to be doing extra work or even providing extra methods and 
properties on the element via custom elements.

- R. Niwa

Re: Proposal for a Permissions API

2015-03-21 Thread Florian Bösch 
Time to revise this topic. Two data points:

1) Particularly with pointerlock (but also with other permission prompts
that sneak up on the user) I often get the complaint from users along the
lines of "I tried your stuff, but it didn't work." or "I tried your stuff,
but it asked me to do X, I don't think it works".

2) MRI scans show that user attention dramatically drops when presented
with a security prompt:
http://arstechnica.com/security/2015/03/mris-show-our-brains-shutting-down-when-we-see-security-prompts/

Permission/Security prompts are bad UX. Particularly the kind you need to
prompt the user with along the way. And within that, even worse are the
ones that pop up again and again (like the fullscreen popup).

On Wed, Oct 1, 2014 at 7:34 PM, Jeffrey Yasskin  wrote:

> On Wed, Sep 3, 2014 at 3:29 AM, Mounir Lamouri  wrote:
> > On Wed, 3 Sep 2014, at 04:41, Jonas Sicking wrote:
> >> I'm generally supportive of this direction.
> >>
> >> I'm not sure that that the PermissionStatus thing is needed. For
> >> example in order to support bluetooth is might be better to make the
> >> call look like:
> >>
> >> permissions.has("bluetooth", "fitbit").then(...);
> >
> > That's more Permission than PermissionStatus, right?
> >
> > What you proposed here would probably be something like that in WebIDL:
> > Promise<> has(PermissionName name, any options);
> >
> > But really, we could make that option bag be a dictionary because it
> > gives good context about what you are passing like what does "fitbit"
> > means here? Is that a black listed device or a white listed one? The one
> > you want to target?
> >
> > I agree that it might be unusual to have a required "name" than might
> > often be used alone but it makes the API way more javascript-y and self
> > explanatory. IMO, this call is nicer to read than the one you wrote
> > above:
> >   permissions.has({ name: 'bluetooth', devices: 'fitbit' });
> > because I understand what the call is trying to do. In addition, as you
> > pointed, it gives a lot of flexibility.
>
> Belatedly, I'd like to suggest a slightly different model. Instead of
> trying to stuff arbitrary queries into the permissions.has() call,
> maybe expose the current permissions as data, and let the application
> inspect them using custom code. This is likely to work better for
> Bluetooth, since we're planning to have pages request devices by the
> Services they expose, not their deviceIds, and a page may want to
> check for either an available device exposing some services, or that a
> device they've already opened hasn't been revoked.
>
> Getting permission revocation to update a UI correctly is also an
> interesting problem. You could expose an event on permission change,
> but given that templating frameworks are moving toward
> Object.observe() to update themselves in response to model object
> changes, that would require developers to write extra code to
> propagate the permission changes into their models.
>
> So what if navigator.permissions just _was_ a suitable model object?
> Make it, say, a Map from permission-name to an object defined by the
> permission's standard, and extend Map to expose enough synthetic
> change records that Object.observe(a_map) is useful.
>
> Jeffrey
>
>

Re: CfC: publish Proposed Recommendation of Web Messaging; deadline March 28

2015-03-21 Thread Jonas Sicking 
On Sat, Mar 21, 2015 at 5:52 AM, Arthur Barstow  wrote:
>
> 2. ; this test
> failure (which passes on IE) is considered an implementation bug
> (MessageChannel and MessagePort are supposed to be exposed to Worker) that
> is expected to be fixed.

I'm not sure that we can really consider lack of support in Workers "a
bug". Worker support is generally non-trivial since it requires making
an API work off the main thread.

That said, mozilla has patches for worker support in progress right
now, so hopefully Firefox can serve as second implementation here
soon.

/ Jonas

[Bug 25968] Needs clearer definition of virtual keyboard's KeyboardEvent.code value if it doesn't emulate physical key event completely

2015-03-21 Thread bugzilla 
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25968

Arthur Barstow  changed:

   What|Removed |Added

 CC||public-webapps@w3.org
  Component|DOM3 Events |UI Events

--- Comment #3 from Arthur Barstow  ---
Bulk move of all D3E bugs to the UI Events component.

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

[Bug 25844] Clarify or change the use of "default action" to avoid confusion

2015-03-21 Thread bugzilla 
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25844

Arthur Barstow  changed:

   What|Removed |Added

 CC||public-webapps@w3.org
  Component|DOM3 Events |UI Events

--- Comment #3 from Arthur Barstow  ---
Bulk move of all D3E bugs to the UI Events component.

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

[Bug 27129] [D3E-key]: Separator

2015-03-21 Thread bugzilla 
https://www.w3.org/Bugs/Public/show_bug.cgi?id=27129

Arthur Barstow  changed:

   What|Removed |Added

 CC||public-webapps@w3.org
  Component|DOM3 Events |UI Events

--- Comment #2 from Arthur Barstow  ---
Bulk move of all D3E bugs to the UI Events component.

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

[Bug 27827] Need to remove input/beforeinput event info from D3E and point to input event spec

2015-03-21 Thread bugzilla 
https://www.w3.org/Bugs/Public/show_bug.cgi?id=27827

Arthur Barstow  changed:

   What|Removed |Added

 CC||public-webapps@w3.org
  Component|DOM3 Events |UI Events

--- Comment #2 from Arthur Barstow  ---
Bulk move of all D3E bugs to the UI Events component.

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

[Bug 26611] [Proposal] Add "Zoom" event

2015-03-21 Thread bugzilla 
https://www.w3.org/Bugs/Public/show_bug.cgi?id=26611

Arthur Barstow  changed:

   What|Removed |Added

 CC||public-webapps@w3.org
  Component|DOM3 Events |UI Events

--- Comment #7 from Arthur Barstow  ---
Bulk move of all D3E bugs to the UI Events component.

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

[Bug 28029] Mouse coordinates represented in CSS pixels do not account for retina displays with window.devicePixelRatio > 1.

2015-03-21 Thread bugzilla 
https://www.w3.org/Bugs/Public/show_bug.cgi?id=28029

Arthur Barstow  changed:

   What|Removed |Added

 CC||public-webapps@w3.org
  Component|DOM3 Events |UI Events

--- Comment #10 from Arthur Barstow  ---
Bulk move of all D3E bugs to the UI Events component.

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

[Bug 27558] Specify MouseEvent.which

2015-03-21 Thread bugzilla 
https://www.w3.org/Bugs/Public/show_bug.cgi?id=27558

Arthur Barstow  changed:

   What|Removed |Added

 CC||public-webapps@w3.org
  Component|DOM3 Events |UI Events

--- Comment #1 from Arthur Barstow  ---
Bulk move of all D3E bugs to the UI Events component.

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

[Bug 27333] Most user agents (Chrome, Firefox) seem to distinguish between space and enter. Enter submits the form, even for radio buttons, space selects the checkbox.

2015-03-21 Thread bugzilla 
https://www.w3.org/Bugs/Public/show_bug.cgi?id=27333

Arthur Barstow  changed:

   What|Removed |Added

 CC||public-webapps@w3.org
  Component|DOM3 Events |UI Events

--- Comment #6 from Arthur Barstow  ---
Bulk move of all D3E bugs to the UI Events component.

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

[Bug 28119] Reference to createEvent("FocusEvent")

2015-03-21 Thread bugzilla 
https://www.w3.org/Bugs/Public/show_bug.cgi?id=28119

Arthur Barstow  changed:

   What|Removed |Added

 CC||public-webapps@w3.org
  Component|DOM3 Events |UI Events

--- Comment #2 from Arthur Barstow  ---
Bulk move of all D3E bugs to the UI Events component.

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

[Bug 27996] [D3E-code] KeyboardEvent code spec should have featurephone section

2015-03-21 Thread bugzilla 
https://www.w3.org/Bugs/Public/show_bug.cgi?id=27996

Arthur Barstow  changed:

   What|Removed |Added

 CC||public-webapps@w3.org
  Component|DOM3 Events |UI Events

--- Comment #1 from Arthur Barstow  ---
Bulk move of all D3E bugs to the UI Events component.

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

[Bug 25485] D3E and corelation with DOM4(W3C)/DOM(WHATWAG) and DOM3 Core

2015-03-21 Thread bugzilla 
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25485

Arthur Barstow  changed:

   What|Removed |Added

 CC||public-webapps@w3.org
  Component|DOM3 Events |UI Events

--- Comment #6 from Arthur Barstow  ---
Bulk move of all D3E bugs to the UI Events component.

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

[Bug 25927] Specify the Event Loop integration for various non-deprecated events, incl. hit testing

2015-03-21 Thread bugzilla 
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25927

Arthur Barstow  changed:

   What|Removed |Added

 CC||public-webapps@w3.org
  Component|DOM3 Events |UI Events

--- Comment #3 from Arthur Barstow  ---
Bulk move of all D3E bugs to the UI Events component.

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

[Bug 25967] Testing DOM L3 Events

2015-03-21 Thread bugzilla 
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25967

Arthur Barstow  changed:

   What|Removed |Added

 CC||public-webapps@w3.org
  Component|DOM3 Events |UI Events

--- Comment #1 from Arthur Barstow  ---
Bulk move of all D3E bugs to the UI Events component.

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

[Bug 27337] For synthetic activation, should the original event still be dispatched?

2015-03-21 Thread bugzilla 
https://www.w3.org/Bugs/Public/show_bug.cgi?id=27337

Arthur Barstow  changed:

   What|Removed |Added

 CC||public-webapps@w3.org
  Component|DOM3 Events |UI Events

--- Comment #3 from Arthur Barstow  ---
Bulk move of all D3E bugs to the UI Events component.

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

[Bug 26141] [D3E-Key] Needs more explicit explanation of "MediaSelect", "LaunchMediaPlayer" and "MediaApps"

2015-03-21 Thread bugzilla 
https://www.w3.org/Bugs/Public/show_bug.cgi?id=26141

Arthur Barstow  changed:

   What|Removed |Added

 CC||public-webapps@w3.org
  Component|DOM3 Events |UI Events

--- Comment #3 from Arthur Barstow  ---
Bulk move of all D3E bugs to the UI Events component.

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

[Bug 27825] DOM Level 3 KeyboardEvent key Values specification does not include core key values

2015-03-21 Thread bugzilla 
https://www.w3.org/Bugs/Public/show_bug.cgi?id=27825

Arthur Barstow  changed:

   What|Removed |Added

 CC||public-webapps@w3.org
  Component|DOM3 Events |UI Events

--- Comment #1 from Arthur Barstow  ---
Bulk move of all D3E bugs to the UI Events component.

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

[Bug 26227] Define that click doesn't fire on disabled elements

2015-03-21 Thread bugzilla 
https://www.w3.org/Bugs/Public/show_bug.cgi?id=26227

Arthur Barstow  changed:

   What|Removed |Added

 CC||public-webapps@w3.org
  Component|DOM3 Events |UI Events

--- Comment #2 from Arthur Barstow  ---
Bulk move of all D3E bugs to the UI Events component.

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

[Bug 25928] Converge with CSSOM-View

2015-03-21 Thread bugzilla 
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25928

Arthur Barstow  changed:

   What|Removed |Added

 CC||public-webapps@w3.org
  Component|DOM3 Events |UI Events

--- Comment #2 from Arthur Barstow  ---
Bulk move of all D3E bugs to the UI Events component.

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

[Bug 26218] When .getModifierState("OS") should be true?

2015-03-21 Thread bugzilla 
https://www.w3.org/Bugs/Public/show_bug.cgi?id=26218

Arthur Barstow  changed:

   What|Removed |Added

 CC||public-webapps@w3.org
  Component|DOM3 Events |UI Events

--- Comment #8 from Arthur Barstow  ---
Bulk move of all D3E bugs to the UI Events component.

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

CfC: publish Proposed Recommendation of Web Messaging; deadline March 28

2015-03-21 Thread Arthur Barstow 
As previously mentioned on [p-w], the test results for Web Messaging 
[All] indicate significant interoperability with only two tests that 
have less than two passes [<2]. The two tests, including a short 
analysis of the failure, are:


1. ; this test 
failure (which passes on Firefox) can be considered more of a Web IDL 
implementation issue and thus not a significant interop issue.


2. ; this 
test failure (which passes on IE) is considered an implementation bug 
(MessageChannel and MessagePort are supposed to be exposed to Worker) 
that is expected to be fixed.


Cindy created a Draft PR [PR] that includes Hixie's updates since the 
[CR] was published (but not the PortCollection interface [PC] which is 
not broadly implemented). Overall, we consider the changes since the CR 
as non-substantive bug fixes and clarifications that align the spec with 
current implementations, and that the test suite tests the updated spec. 
See [Diff] for all of changes between the CR and the draft PR and note 
the draft PR's status section includes a short summary of the changes.


As such, this is a Call for Consensus to publish a Proposed 
Recommendation of Web Messaging using the [PR] as the basis. Agreement 
with this CfC means you consider the test results shows interoperability 
and the changes since CR are not substantive.


If you have any comments or concerns about this CfC, please reply to 
this e-mail by March 28 at the latest. Positive response is preferred 
and encouraged, and silence will be considered as agreement with the 
proposal. If there are no non-resolvable objections to this proposal, 
the motion will carry and we will request the PR be published.


-Thanks, ArtB

[p-w] 


[All] 
[<2] 
[PR] 
[CR] 
[PC] 
[Diff]