[Bug 26713] New: DOMFocusIn/DOMFocusOut in ShadowDOM spec should be renamed to focusin/focusout
https://www.w3.org/Bugs/Public/show_bug.cgi?id=26713 Bug ID: 26713 Summary: DOMFocusIn/DOMFocusOut in ShadowDOM spec should be renamed to focusin/focusout Product: WebAppsWG Version: unspecified Hardware: PC OS: All Status: NEW Severity: normal Priority: P2 Component: Component Model Assignee: dglaz...@chromium.org Reporter: ko...@google.com QA Contact: public-webapps-bugzi...@w3.org CC: m...@w3.org, public-webapps@w3.org http://w3c.github.io/webcomponents/spec/shadow/#retargeting-focus-events mentions DOMFocusIn/Out events, but according to the latest DOM L3 Events spec: https://dvcs.w3.org/hg/dom3events/raw-file/tip/html/DOM3-Events.html#event-type-DOMFocusIn Warning! The DOMFocusIn event type is defined in this specification for reference and completeness, but this specification deprecates the use of this event type in favor of the related event types focus and focusin. So I suppose we should rename these events as focusin/focusout. -- You are receiving this mail because: You are on the CC list for the bug.
Re: [xhr]
On Tue, Sep 2, 2014 at 2:54 AM, Robert Hanson hans...@stolaf.edu wrote: I respectively request that the wording of the warning on the pages https://dvcs.w3.org/hg/xhr/raw-file/default/xhr-1/Overview.html and http://xhr.spec.whatwg.org/ be changed from Warning: Developers must not pass false for the async argument when the JavaScript global environment is a document environment as it has detrimental effects to the end user's experience. User agents are strongly encouraged to warn about such usage in developer tools and may experiment with throwing a InvalidAccessError exception when it occurs so the feature can eventually be removed from the platform. to Note: Developers should not pass false for the async argument when the JavaScript global environment is a document environment as it has detrimental effects to the end user's experience. Developers are advised that passing false for the async argument may eventually be removed from the platform. Sorry. As with showModalDialog() we would really like to make this feature disappear. I realize this makes some forms of code generation harder, but hopefully you can find a way around that in time. Synchronous networking on the UI thread is a no-go. -- http://annevankesteren.nl/
Proposal for a Permissions API
TL;DR:
Permissions API would be a single entry point for a web page to check if
using API /foo/ would prompt, succeed or fail.
You can find the chromium.org design document in [1].
# Use case #
The APIs on the platform are lacking a way to check whether the user has
granted them. Except the Notifications API, there is no API that I know
of that expose such information (arguably, somehow, the Quota API does).
The platform now has a lot of APIs using permissions which is expressed
as permission prompts in all browsers. Without the ability for web pages
to know whether a call will prompt, succeeded or fail beforehand,
creating user experience on par with native applications is fairly hard.
# Straw man proposal #
This proposal is on purpose minimalistic and only contains features that
should have straight consensus and strong use cases, the linked document
[1] contains ideas of optional additions and list of retired ideas.
```
/* Note: WebIDL doesn’t allow partial enums so we might need to use a
DOMString
* instead. The idea is that new API could extend the enum and add their
own
* entry.
*/
enum PermissionName {
};
/* Note: the idea is that some APIs would extend this dictionary to add
some
* API-specific information like a “DOMString accuracy” for an
hypothetical
* geolocation api that would have different accuracy granularity.
*/
dictionary Permission {
required PermissionName name;
};
/* Note: the name doesn’t matter, not exposed. */
enum PermissionState {
// If the capability can be used without having to ask the user for a
yes/no
// question. In other words, if the developer can’t ask the user in
advance
// whether he/she wants the web page to access the feature. A feature
using a
// chooser UI is always ‘granted’.
“granted”,
// If the capability can’t be used at all and trying it will be a
no-op.
“denied”,
// If trying to use the capability will be followed by a question to
the user
// asking whether he/she wants to allow the web page to be granted the
// access and that question will no longer appear for the subsequent
calls if
// it was answered the first time.
“prompt”
};
dictionary PermissionStatus : Permission {
PermissionState status;
};
/* Note: the promises would be rejected iff the Permission isn’t known
or
* misformatted.
*/
interface PermissionManager {
PromisePermissionStatus has(Permission permission);
};
[NoInterfaceObject, Exposed=Window,Worker]
interface NavigatorPermissions {
readonly attribute PermissionManager permissions;
};
Navigator implements NavigatorPermissions;
WorkerNavigator implements NavigatorPermissions;
```
The intent behind using dictionaries is to simplify the usage and
increase flexibility. It would be easy for an API to inherit from
Permission to define new properties. For example, a Bluetooth API could
have different permissions for different devices or a Geolocation API
could have different level of accuracies. See [1] for more details.
WDYT?
[1]
https://docs.google.com/a/chromium.org/document/d/12xnZ_8P6rTpcGxBHiDPPCe7AUyCar-ndg8lh2KwMYkM/preview
-- Mounir
Re: [xhr]
02.09.2014, 10:55, Anne van Kesteren ann...@annevk.nl: On Tue, Sep 2, 2014 at 2:54 AM, Robert Hanson hans...@stolaf.edu wrote: I respectively request that the wording of the warning [...] Warning: Developers must not pass false for the async argument when the JavaScript global environment is a document environment as it has detrimental effects to the end user's experience. User agents are strongly encouraged to warn about such usage in developer tools and may experiment with throwing a InvalidAccessError exception when it occurs so the feature can eventually be removed from the platform. [change] to Note: Developers should not pass false for the async argument when the JavaScript global environment is a document environment as it has detrimental effects to the end user's experience. Developers are advised that passing false for the async argument may eventually be removed from the platform. Sorry. As with showModalDialog() we would really like to make this feature disappear. I realize this makes some forms of code generation harder, but hopefully you can find a way around that in time. Perhaps we should set some sense of expectation about *when* it won't work. Different parts of the Web move on different timelines. It may be simple to remove it from modern browsers, but this will simply motivate organisations who depend on a system that uses synch XHR to stop updating until they can find a way around. Understanding a bit better what happens in user-land would be very helpful, because giving people really good reasons to opt out of auto-upgrade and stick with the past is a bad idea... Synchronous networking on the UI thread is a no-go. It's certainly an anti-pattern, given the thread constraints we have. But so is pushing big chunks of the real world to use old systems - because if they stop upgrading for one important problem, we revive the IE6 problem. While I doubt we'll get a genuine flag day, it should be feasible to get a sense of who suffers from the change, and when we can break the web without causing too much serious fallout. (My 2 kopecks) chaals
Re: Blocking message passing for Workers
On Sat, 9 Aug 2014, Alan deLespinasse wrote: Thanks. Apparently I did a lousy job of searching for previous discussions. I just found this later, longer thread: http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/0965.html http://lists.w3.org/Archives/Public/public-webapps/2012JanMar/0678.html (same thread, different year, so they're not linked) Has anything changed since that thread? It seems like the discussion stalled in early 2012. But I'm glad to find that other people want the same thing. I just noticed this thread. For what it's worth, I don't follow this list very closely. If you would like to request a new API for Workers, the best place to do it is the WHATWG mailing list or in the W3C Bug database: https://www.w3.org/Bugs/Public/enter_bug.cgi?assigned_to=ian%40hixie.chblocked=bug_file_loc=bug_severity=normalbug_status=NEWcomment=component=HTMLcontenttypeentry=contenttypemethod=autodetectcontenttypeselection=text%2Fplaindata=dependson=description=form_name=enter_bugkeywords=maketemplate=Remember%20values%20as%20bookmarkable%20templateop_sys=otherpriority=P3product=WHATWGqa_contact=contributor%40whatwg.orgrep_platform=Othershort_desc=target_milestone=---version=unspecified HTH, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Concerning the Working Draft on Service Workers
In the document: http://www.w3.org/TR/service-workers/ Should: Existing palyground services (e.g. github.io) now work with HTTPS read as: Existing playground services (e.g. github.io) now work with HTTPS -Brent
Re: Concerning the Working Draft on Service Workers
Seems likely :) I'd recommend reading the editor's draft, which is more up to date: https://slightlyoff.github.io/ServiceWorker/spec/service_worker/ On 2 September 2014 18:45, Brent Shambaugh brent.shamba...@gmail.com wrote: In the document: http://www.w3.org/TR/service-workers/ Should: Existing palyground services (e.g. github.io) now work with HTTPS read as: Existing playground services (e.g. github.io) now work with HTTPS -Brent
Re: Proposal for a Permissions API
On Tue, Sep 2, 2014 at 6:51 AM, Mounir Lamouri mou...@lamouri.fr wrote:
# Straw man proposal #
This proposal is on purpose minimalistic and only contains features that
should have straight consensus and strong use cases, the linked document
[1] contains ideas of optional additions and list of retired ideas.
```
/* Note: WebIDL doesn't allow partial enums so we might need to use a
DOMString
* instead. The idea is that new API could extend the enum and add their
own
* entry.
*/
enum PermissionName {
};
/* Note: the idea is that some APIs would extend this dictionary to add
some
* API-specific information like a DOMString accuracy for an
hypothetical
* geolocation api that would have different accuracy granularity.
*/
dictionary Permission {
required PermissionName name;
};
/* Note: the name doesn't matter, not exposed. */
enum PermissionState {
// If the capability can be used without having to ask the user for a
yes/no
// question. In other words, if the developer can't ask the user in
advance
// whether he/she wants the web page to access the feature. A feature
using a
// chooser UI is always 'granted'.
granted,
// If the capability can't be used at all and trying it will be a
no-op.
denied,
// If trying to use the capability will be followed by a question to
the user
// asking whether he/she wants to allow the web page to be granted the
// access and that question will no longer appear for the subsequent
calls if
// it was answered the first time.
prompt
};
dictionary PermissionStatus : Permission {
PermissionState status;
};
/* Note: the promises would be rejected iff the Permission isn't known
or
* misformatted.
*/
interface PermissionManager {
PromisePermissionStatus has(Permission permission);
};
[NoInterfaceObject, Exposed=Window,Worker]
interface NavigatorPermissions {
readonly attribute PermissionManager permissions;
};
Navigator implements NavigatorPermissions;
WorkerNavigator implements NavigatorPermissions;
```
The intent behind using dictionaries is to simplify the usage and
increase flexibility. It would be easy for an API to inherit from
Permission to define new properties. For example, a Bluetooth API could
have different permissions for different devices or a Geolocation API
could have different level of accuracies. See [1] for more details.
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 said, I don't mind the PermissionsStatus construct. It certainly
reduces the risk that we paint ourselves into a corner.
/ Jonas
Re: Proposal for a Permissions API
On 9/2/14, 9:51 AM, Mounir Lamouri wrote:
required PermissionName name;
Glad to see required being put to good use. ;)
interface PermissionManager {
IDL nit: This needs Exposed=(Window,Worker)
[NoInterfaceObject, Exposed=Window,Worker]
And parens.
-Boris
IndieUI Teleconference Agenda; 3 September at 21:00Z for 60 minutes
As before I'm cross-posting this IndieUI agenda As part of IndieUI's continuing open invitation continuing our conversation about working jointly. Allow me to invite you to the next Indie-UI teleconference as detailed below. Please feel free to join us on this call, or any following call. What: IndieUI Task Force Teleconference When: Wednesday 3 September 2:00 PMSan Francisco -- U.S. Pacific (Daylight) Time (PDT: UTC -7) 4:00 PMAustin -- U.S. Central (Daylight) Time (CDT: UTC -5) 5:00 PMBoston -- U.S. Eastern (Daylight) Time (EDT: UTC -4) 10:00 PMLondon -- British (Summer) Time (BST: UTC +1) 11:00 PMParis -- Central European Time (CET: UTC +2) 5:00 AMBeijing -- China Standard Time (Thursday, 4 September CST: UTC +8) 6:00 AMTokyo -- Japan Standard Time (Thursday, 4 September JST: UTC +9) 7:00 AMMelbourne -- Australian Eastern (Standard) Time (Thursday 4 September AEST: UTC +10) Where: W3C Teleconference--See Below * Time of day conversions Please verify the correct time of this meeting in your time zone using the Fixed Time Clock at: http://timeanddate.com/worldclock/fixedtime.html?msg=IndieUI+Teleconferenceiso=20140903T1700p1=43ah=1 ** Preliminary Agenda for IndieUI Task Force Teleconference 3 September 2014 Meeting: IndieUI Task Force Teleconference Chair: Michael_Cooper agenda+ preview agenda with items from two minutes agenda+ Editor's Report agenda+ Checkin with Web Apps' Editing TF [See below] agenda+ Testing Conversation; Polyfills agenda+ Requirements Use Cases Progress agenda+ TPAC Planning http://www.w3.org/2014/11/TPAC/ agenda+ User Context Issues Actions https://www.w3.org/WAI/IndieUI/track/products/3 agenda+ Events Issues Actions https://www.w3.org/WAI/IndieUI/track/products/2 agenda+ Other Business agenda+ Be Done Resource: IndieUI Minutes http://www.w3.org/2014/08/20-indie-ui-minutes.html Resource: Web Apps Editing TF Explainer: http://w3c.github.io/editing-explainer/commands-explainer.html Resource: For Reference Home Page: http://www.w3.org/WAI/IndieUI/ Email Archive: http://lists.w3.org/Archives/Public/public-indie-ui/ Resource: Teleconference Logistics Dial the Zakim bridge using either SIP or the PSTN. PSTN: +1.617.761.6200 (This is a U.S. number). SIP: za...@voip.w3.org You should be prompted for a pass code, This is 46343# (INDIE#) Alternatively, bypass the Zakim prompts and SIP directly into our teleconference. SIP: 0046...@voip.w3.org Instructions for connecting using SIP: http://www.w3.org/2006/tools/wiki/Zakim-SIP Place for users to contribute additional VoIP tips. http://www.w3.org/2006/tools/wiki/Zakim-SIP-tips IRC: server: irc.w3.org, channel: #indie-ui. During the conference you can manage your participation with Zakim commands as follows: 61# to mute yourself 60# to unMute yourself 41# to raise your hand (enter speaking queue) 40# to lower your hand (exit speaking queue) The system acknowledges these commands with a rapid, three-tone confirmation. Mobile phone users especially should use the mute function if they don't have a mute function in their phone. But the hand-raising function is a good idea for anyone not using IRC. * IRC access An IRC channel will be available. The server is irc.w3.org, The port number is 6665 (Note this is not the normal default) and The channel is #indie-ui. * Some helpful Scribing and Participation Tips http://www.w3.org/WAI/PF/wiki/Teleconference_cheat_sheet For more on the IRC setup and the robots we use for agenda and speaker queuing and for posting the log to the web, see: - For RRSAgent, that captures and posts the log with special attention to action items: http://www.w3.org/2002/03/RRSAgent - For Zakim, the IRC interface to the bridge manager, that will maintain speaker and agenda queues: http://www.w3.org/2001/12/zakim-irc-bot - For a Web gateway to IRC you can use if your network administrators forbid IRC, see: http://www.w3.org/2001/01/cgi-irc - For more on W3C use of IRC see: http://www.w3.org/Project/IRC/ -- Janina Sajka, Phone: +1.443.300.2200 sip:jan...@asterisk.rednote.net Email: jan...@rednote.net The Linux Foundation Chair, Open Accessibility: http://a11y.org The World Wide Web Consortium (W3C), Web Accessibility Initiative (WAI) Chair, Protocols Formats http://www.w3.org/wai/pf IndieUI http://www.w3.org/WAI/IndieUI/
Re: Proposal for a Permissions API
Hi Mounir,
Have you considered making this return a promise, as per Nikhil's proposal:
https://github.com/w3c/push-api/issues/3#issuecomment-42997477
p.s. I will bring your idea to the trust permissions in the open web
platform meeting, we're holding in Paris this week, see:
http://www.w3.org/2014/07/permissions/
Cheers,
Dave
On 02/09/14 14:51, Mounir Lamouri wrote:
TL;DR:
Permissions API would be a single entry point for a web page to check if
using API /foo/ would prompt, succeed or fail.
You can find the chromium.org design document in [1].
# Use case #
The APIs on the platform are lacking a way to check whether the user has
granted them. Except the Notifications API, there is no API that I know
of that expose such information (arguably, somehow, the Quota API does).
The platform now has a lot of APIs using permissions which is expressed
as permission prompts in all browsers. Without the ability for web pages
to know whether a call will prompt, succeeded or fail beforehand,
creating user experience on par with native applications is fairly hard.
# Straw man proposal #
This proposal is on purpose minimalistic and only contains features that
should have straight consensus and strong use cases, the linked document
[1] contains ideas of optional additions and list of retired ideas.
```
/* Note: WebIDL doesn’t allow partial enums so we might need to use a
DOMString
* instead. The idea is that new API could extend the enum and add their
own
* entry.
*/
enum PermissionName {
};
/* Note: the idea is that some APIs would extend this dictionary to add
some
* API-specific information like a “DOMString accuracy” for an
hypothetical
* geolocation api that would have different accuracy granularity.
*/
dictionary Permission {
required PermissionName name;
};
/* Note: the name doesn’t matter, not exposed. */
enum PermissionState {
// If the capability can be used without having to ask the user for a
yes/no
// question. In other words, if the developer can’t ask the user in
advance
// whether he/she wants the web page to access the feature. A feature
using a
// chooser UI is always ‘granted’.
“granted”,
// If the capability can’t be used at all and trying it will be a
no-op.
“denied”,
// If trying to use the capability will be followed by a question to
the user
// asking whether he/she wants to allow the web page to be granted the
// access and that question will no longer appear for the subsequent
calls if
// it was answered the first time.
“prompt”
};
dictionary PermissionStatus : Permission {
PermissionState status;
};
/* Note: the promises would be rejected iff the Permission isn’t known
or
* misformatted.
*/
interface PermissionManager {
PromisePermissionStatus has(Permission permission);
};
[NoInterfaceObject, Exposed=Window,Worker]
interface NavigatorPermissions {
readonly attribute PermissionManager permissions;
};
Navigator implements NavigatorPermissions;
WorkerNavigator implements NavigatorPermissions;
```
The intent behind using dictionaries is to simplify the usage and
increase flexibility. It would be easy for an API to inherit from
Permission to define new properties. For example, a Bluetooth API could
have different permissions for different devices or a Geolocation API
could have different level of accuracies. See [1] for more details.
WDYT?
[1]
https://docs.google.com/a/chromium.org/document/d/12xnZ_8P6rTpcGxBHiDPPCe7AUyCar-ndg8lh2KwMYkM/preview
-- Mounir
--
Dave Raggett d...@w3.org http://www.w3.org/People/Raggett
Re: {Spam?} Re: [xhr]
cha...@yandex-team.ru wrote: Sorry. As with showModalDialog() we would really like to make this feature disappear. I realize this makes some forms of code generation harder, but hopefully you can find a way around that in time. Perhaps we should set some sense of expectation about*when* it won't work. Different parts of the Web move on different timelines. Right. Also (I am a WHATWG cofounder) it is overreach to promise obsolescence on any timeline on the Web. Robert should not worry about real browser implementors breaking content by removing sync XHR -- to do so would be to lose market share. In this light, WHATWG should avoid making indefinite-timescale, over-ambitious assertions. The W3C was rightly faulted when we founded the WHATWG for doing so. /be
Re: Proposal for a Permissions API
I welcome this proposal because the permission dialog creep is certainly
worrying.
Opponents of some kind of permission management have pointed out that
collated dialogs tend to just get ignored by users and blindly approved (as
an example they list Android permission handling).
While that may be true to some extent, this, for me isn't really about
educating users. Popping up a series of permission dialogs isn't any better
than a collated dialog (just more annoying to the user).
It's becoming sort of a dire situation, because permissions are required
today for:
- Geo location API
- Push API
- Notifications API
- Ability to store more than 5mb with WebSQL/IndexedDB/Filesystem
- Use a webcam
- Go into fullscreen
- Capture the mouse pointer
- Clipboard API
- WebVR HMD access
- and many more
Additionally, there are APIs which currently do not ask for permission for
UX reasons, and implement different means to get permission. For instance
the gamepad API, which derives permission from the user interacting with a
gamepad compatible device. These may benefit from a unified permission API.
There are also some challenges in permission handling due to legacy, where
the individualized way that apps handle permissions can create
incompatibilities. For instance, the fullscreen API polls the user for
permission, but it goes into fullscreen even so, but the user has to
dismiss the dialog with yes or no, in case of yes the dialog vanished, in
case of no, fullscreen is exited. The reason for this behavior has to do
with two contradictory requirements: Fullscreen (as in video for instance)
is a very common operation and it would be annoying from a UX point of view
to make a user poll a requirement to be able to enter it. However
fullscreen is also a security risk, because a malicious developer could
pretend to be the browser (by placing appropriate window decorations) and
then trick the user to enter confidential details.
As a short requirement I think these tasks should be taken over by a
permission framework:
- Dialog for the user to manage permissions (and their persistence)
- query of the list of permissions that can be requested of the current
context
- query the status of the permissions of the current context
- poll the user for a set of new permissions
- get notified when permissions change during the runtime of a context
outside of polling the user
- Dialog for the user to grant permissions when requested, either all in
one go, or individually, including the option to remember the choice.
- get notified of the permissions status as a consequence of a user poll
- a way to reconcile the particular idiosyncracies that currently exist
in the variety of permission handling into a cohesive behavior that does
not invalidate the original decision to implement the permission for a
particular API in that fashion (otherwise the authors of these APIs will
revolt, as often the solution that was arrived at was hard fought).
On Tue, Sep 2, 2014 at 11:10 PM, Dave Raggett d...@w3.org wrote:
Hi Mounir,
Have you considered making this return a promise, as per Nikhil's proposal:
https://github.com/w3c/push-api/issues/3#issuecomment-42997477
p.s. I will bring your idea to the trust permissions in the open web
platform meeting, we're holding in Paris this week, see:
http://www.w3.org/2014/07/permissions/
Cheers,
Dave
On 02/09/14 14:51, Mounir Lamouri wrote:
TL;DR:
Permissions API would be a single entry point for a web page to check if
using API /foo/ would prompt, succeed or fail.
You can find the chromium.org design document in [1].
# Use case #
The APIs on the platform are lacking a way to check whether the user has
granted them. Except the Notifications API, there is no API that I know
of that expose such information (arguably, somehow, the Quota API does).
The platform now has a lot of APIs using permissions which is expressed
as permission prompts in all browsers. Without the ability for web pages
to know whether a call will prompt, succeeded or fail beforehand,
creating user experience on par with native applications is fairly hard.
# Straw man proposal #
This proposal is on purpose minimalistic and only contains features that
should have straight consensus and strong use cases, the linked document
[1] contains ideas of optional additions and list of retired ideas.
```
/* Note: WebIDL doesn’t allow partial enums so we might need to use a
DOMString
* instead. The idea is that new API could extend the enum and add their
own
* entry.
*/
enum PermissionName {
};
/* Note: the idea is that some APIs would extend this dictionary to add
some
* API-specific information like a “DOMString accuracy” for an
hypothetical
* geolocation api that would have different accuracy granularity.
*/
dictionary Permission {
required PermissionName name;
};
/* Note: the name
