Re: CFC: Request to move HTML5.1 to Candidate Recommendation (CR)

+1 On 2 June 2016 at 13:48, Léonie Watson wrote: > Hello WP, > > This is a call for consensus to request that W3C publish the current HTML > Working Draft (WD) as a Candidate Recommendation (CR). It has been posted > to > public-webapps@w3.org as the official email for this WG. >

Re: CFC: Request to move HTML5.1 to Candidate Recommendation (CR)

+1 for moving HTML5.1 to CR

Re: Request to move HTML5.1 to Candidate Recommendation (CR)

On Thu, 02 Jun 2016 18:14:38 +0200, wrote: Can we please kindly stop the +1s spam? It greatly diminishes the value of this mailing list. For the purpose of progressing a spec, the only thing that matters is objections. Hi Marcos, If there are no objections, then the

RE: Request to move HTML5.1 to Candidate Recommendation (CR)

> From: mar...@marcosc.com [mailto:mar...@marcosc.com] > Sent: 02 June 2016 17:15 > Can we please kindly stop the +1s spam? It greatly diminishes the value of > this mailing list. We mention in the CFC that positive responses are preferred and encouraged (which they are), so this is an appeal to

Re: Request to move HTML5.1 to Candidate Recommendation (CR)

> On 3 Jun 2016, at 2:28 AM, John Foliot wrote: > > Hi Marcos, > > While it may feel spammy to you, this is a long-standing part of the W3C > Consensus process, and generally speaking all CfCs include the following: > > "Positive responses are preferred and

Re: Request to move HTML5.1 to Candidate Recommendation (CR)

Hi Marcos, While it may feel spammy to you, this is a long-standing part of the W3C Consensus process, and generally speaking all CfCs include the following: "Positive responses are preferred and encouraged, silence will be considered as assent." On the surface, and in principle, I disagree

Re: Request to move HTML5.1 to Candidate Recommendation (CR)

Can we please kindly stop the +1s spam? It greatly diminishes the value of this mailing list. For the purpose of progressing a spec, the only thing that matters is objections. > On 3 Jun 2016, at 12:36 AM, Mona Rekhi wrote: > > +1 > > Mona Rekhi > SSB BART

RE: Request to move HTML5.1 to Candidate Recommendation (CR)

+1 Mona Rekhi SSB BART Group -Original Message- From: Léonie Watson [mailto:t...@tink.uk] Sent: Thursday, June 02, 2016 8:48 AM To: 'public-webapps WG' Subject: CFC: Request to move HTML5.1 to Candidate Recommendation (CR) Hello WP, This is a call for

Re: CFC: Request to move HTML5.1 to Candidate Recommendation (CR)

aye - (as TPG WG person) -- Regards SteveF Current Standards Work @W3C On 2 June 2016 at 13:48, Léonie Watson wrote: > Hello WP, > > This is a call for consensus to request that W3C publish the current

Re: CFC: Request to move HTML5.1 to Candidate Recommendation (CR)

On Thu, 02 Jun 2016 14:48:10 +0200, Léonie Watson wrote: Hello WP, This is a call for consensus to request that W3C publish the current HTML Working Draft (WD) as a Candidate Recommendation (CR). +1 Please do. chaals - Yandex hat on, chair hat off -- Charles McCathie Nevile

Re: Request to move HTML5.1 to Candidate Recommendation (CR)

+1 JF On Thu, Jun 2, 2016 at 8:48 AM, Katie Haritos-Shea GMAIL wrote: > +1 to publish WD > > ​ > > > > * katie * > > Katie Haritos-Shea > Principal ICT Accessibility Architect (WCAG/Section 508/ADA/AODA) > > Cell: 703-371-5545 | ryla...@gmail.com | Oakton, VA | LinkedIn

RE: Request to move HTML5.1 to Candidate Recommendation (CR)

+1 to publish WD ​ * katie * Katie Haritos-Shea Principal ICT Accessibility Architect (WCAG/Section 508/ADA/AODA) Cell: 703-371-5545 | ryla...@gmail.com | Oakton, VA | LinkedIn Profile | Office: 703-371-5545 -Original Message- From: Léonie Watson [mailto:t...@tink.uk]

RE: Request to move HTML5.1 to Candidate Recommendation (CR)

> From: Léonie Watson [mailto:t...@tink.uk] > Sent: 02 June 2016 13:48 > This is a call for consensus to request that W3C publish the current HTML > Working Draft (WD) as a Candidate Recommendation (CR). It has been > posted to public-webapps@w3.org as the official email for this WG. +1 (as TPG

CFC: Request to move HTML5.1 to Candidate Recommendation (CR)

Hello WP, This is a call for consensus to request that W3C publish the current HTML Working Draft (WD) as a Candidate Recommendation (CR). It has been posted to public-webapps@w3.org as the official email for this WG. Please reply to this thread on public-webapps@w3.org no later than end of day

Re: Self-introduction from Wanming Lin

Welcome Wanming! On Tue, 31 May 2016 09:46:15 +0200, Lin, Wanming wrote: Hello WP, My name is Wanming Lin, many thanks Wayne for inviting me join in WP WG. I work for Intel OTC Web QA team which focuses on testing work for advanced Web technologies especially for

RE: Self-introduction from Wanming Lin

> From: Lin, Wanming [mailto:wanming@intel.com] > Sent: 31 May 2016 08:46 > Hello WP, Hello Wanming, and welcome. [...] > I am proud to represent my team to join in this group, I am a newbie but I will > try my best. > Looking forward to working with you all. Thank you. We are looking

Self-introduction from Wanming Lin

Hello WP, My name is Wanming Lin, many thanks Wayne for inviting me join in WP WG. I work for Intel OTC Web QA team which focuses on testing work for advanced Web technologies especially for latest W3C standard Web APIs. We started to contribute Web API test cases to W3C upstream since early

Re: [Service Workers] meeting july/august?

On Wed, May 25, 2016 at 9:19 PM, Chaals McCathie Nevile < cha...@yandex-team.ru> wrote: > Hi folks, > > at the last meeting people suggested another meeting in July/August. > Should we be trying to schedule one? > We'd actually already been discussing this between the last participants. Our

Re: Clipboard API: Proposal for asynchronous API

Hi Gary, good work! Some questions that have come up in discussion with developers at Mozilla: 1) The existing DataTransfer API is purposefully designed to be used for both copy/paste and drag-and-drop. If we add navigator.clipboard to add asyncness to clipboard-style usage of the API, what about

[Service Workers] meeting july/august?

Hi folks, at the last meeting people suggested another meeting in July/August. Should we be trying to schedule one? The Editing folks are meeting in California 29 July. Something just before that would be very convenient for *me*. Others of course may have unaccountably different

WP meetings at TPAC

Hello WP, We have meeting space available throughout TPAC week [1]. The plan is to focus on a different area of work each day, to help everyone schedule their time a bit more easily. We've posted meeting pages for each day: https://github.com/w3c/WebPlatformWG/blob/gh-pages/Meetings.md Monday

About the packaging spec Re: CFC

Hi Marcos, On Wed, 25 May 2016 00:52:07 +0100, wrote: On 25 May 2016, at 3:54 AM, Léonie Watson wrote: At the AC meeting in March 2016 the WP co-chairs indicated that the Packaging on the Web specification [1] would benefit from further incubation

Re: [webvr] [gamepad] Missing VRPose for tracked controllers

Apologies if this comes across twice - the mailing list rejected my first attempt :-) Do we need to know if a given Gamepad is orientation only versus position+orientation? I'm seeing a lot of devices that only know their orientation and we could detect this by a 0,0,0 position, but having a flag

Re: [webvr] [gamepad] Missing VRPose for tracked controllers

Am 24.05.16 um 20:50 schrieb Brandon Jones: > Position/Orientation/Acceleration can always be reported as NULL, so > that's what I would expect from controllers that don't support a > particular pose value. That's a bit of a pain to use for feature > detection purposes, though, so maybe a more

Re: CFC

> On 25 May 2016, at 3:54 AM, Léonie Watson wrote: > > Hello WP, > > At the AC meeting in March 2016 the WP co-chairs indicated that the > Packaging on the Web specification [1] would benefit from further incubation > before continuing along the Recommendation track. > > This

RE: CFC: Convert Packaging on the Web to a W3C note

With the subject line repaired this time... > -Original Message- > From: Léonie Watson [mailto:t...@tink.uk] > Sent: 24 May 2016 18:54 > To: public-webapps@w3.org > Subject: CFC > > Hello WP, > > At the AC meeting in March 2016 the WP co-chairs indicated that the > Packaging on the Web

Re: [webvr] [gamepad] Missing VRPose for tracked controllers

On Tue, May 24, 2016 at 8:50 PM, Brandon Jones wrote: > > but Yaw probably just initializes to whatever position the user started > with. > Applications for these kinds of controllers usually have some "reset forward" thing. Sometimes the settings of the device do (as is the

Re: [webvr] [gamepad] Missing VRPose for tracked controllers

Position/Orientation/Acceleration can always be reported as NULL, so that's what I would expect from controllers that don't support a particular pose value. That's a bit of a pain to use for feature detection purposes, though, so maybe a more explicit caps would be nice? As for determining what

Re: [webvr] Re: [gamepad] Missing VRPose for tracked controllers

Brandon Jones (Google) has made some experimental WebVR Chromium builds that include support for the HTC Vive VR motion controls. We would like to propose this as a standard and update to the GamePad API. Brandon has started a thread on w3.org that gives some background:

CFC

Hello WP, At the AC meeting in March 2016 the WP co-chairs indicated that the Packaging on the Web specification [1] would benefit from further incubation before continuing along the Recommendation track. This is a CFC to publish Packaging on the Web as a W3C note. If the CFC passes, the

Re: [gamepad] Missing VRPose for tracked controllers

Hello, Am 24.05.2016 um 09:38 schrieb Florian Bösch: > You should discuss this on the WebVR ML as well, it's the main > communication channel for that, and since it has impact on their > spec it should be coordinated. I looked at the archive and saw that Brandon Jones already made a good

Re: [webvr] Re: [gamepad] Missing VRPose for tracked controllers

You should discuss this on the WebVR ML as well, it's the main communication channel for that, and since it has impact on their spec it should be coordinated. On Tue, May 24, 2016 at 9:22 AM, Sven Neuhaus wrote: > Hello Florian, > > Thanks for pointing out the WebVR spec draft.

[webvr] Re: [gamepad] Missing VRPose for tracked controllers

Hello Florian, Thanks for pointing out the WebVR spec draft. The WebVR draft dated April 1st contains a Gamepad interface expansion (§2.11), however it only extends it by a DisplayId. It should also add a VRPose for tracked controllers. I think adding a VRPose could have benefits for non-VR

Re: [gamepad] Missing VRPose for tracked controllers

The WebVR API models HMD pose and will model the gesture controllers. https://mozvr.com/webvr-spec/ On Tue, May 17, 2016 at 9:41 AM, Sven Neuhaus wrote: > Hello, > > I read the gamepad API description at > https://developer.mozilla.org/en-US/docs/Web/API/Gamepad > > I think the

[gamepad] Missing VRPose for tracked controllers

Hello, I read the gamepad API description at https://developer.mozilla.org/en-US/docs/Web/API/Gamepad I think the gamepad API should support a VRpose for gamepad controllers like the ones included with the HTC Vive and the upcoming Oculus Touch controllers. I suggest that you add a getPose()

Clipboard API: Proposal for asynchronous API

I just sent a proposal to the WICG for an asynchronous Clipboard API: https://discourse.wicg.io/t/proposal-modern-asynchronous-clipboard-api/1513 (yes, I know. Not the first time something like this has been proposed )

Re: Clipboard API: remove dangerous formats from mandatory data types

Relevant to this thread - I've just reported an issue on making the DataTransfer API safer: https://github.com/whatwg/html/issues/1244 Input there would be great. I'm planning to look at how to add this to the spec, but I'm not sure what exactly it should say. I would still like comments from

TPAC 2016 Registration Now Open

As a reminder, the Web Platform Working Group will meet as follows: [[ 19 September: Web Components. (TPAC 2016, Lisbon, Portugal) 20 September: Service Workers. (TPAC 2016, Lisbon, Portugal) 22 September: Editing and Selection. (TPAC 2016, Lisbon, Portugal) 23 September: HTML, Directory

Re: CFC: Publish as W3C Notes

On Tue, 26 Apr 2016 19:05:52 +0100, Léonie Watson wrote: At the AC meeting in March 2016 the WP co-chairs indicated that the following two specifications would benefit from further incubation before continuing along the Recommendation track: Quota Management API [1] Input Method

Introducing myself

Hi :) As per the newbie guide, I’d like to introduce myself. I am Michiel Bijl, co-editor of the ARIA Authoring Practices and Accessibility Engineer at TPG. The reason I joined the WA WG is to help out with improving it and its accessibility. I am sure I’ll learn a thing or two along the way

RE: Publish as W3C Notes

Publish as note and Incubate +1 -Original Message- From: Léonie Watson [mailto:t...@tink.uk] Sent: Tuesday, April 26, 2016 11:06 AM To: public-webapps@w3.org Subject: CFC: Publish as W3C Notes Hello, At the AC meeting in March 2016 the WP co-chairs indicated that the following two

RE: New Web Components editor

> From: Domenic Denicola [mailto:d...@domenic.me] > Sent: 26 April 2016 19:06 > Thanks Léonie. One correction: > > From: Léonie Watson [mailto:t...@tink.uk] > > > > The WP co-chairs and team are happy to announce that Domenic Denicola > > will be the new editor of the Custom Elements and Shadow

CFC: Publish as W3C Notes

Hello, At the AC meeting in March 2016 the WP co-chairs indicated that the following two specifications would benefit from further incubation before continuing along the Recommendation track: Quota Management API [1] Input Method Editor API [2] This is a CFC to publish each of these

New Web Components editor

Hello, The WP co-chairs and team are happy to announce that Domenic Denicola will be the new editor of the Custom Elements and Shadow DOM specifications at W3C. With thanks to Google for their time and support, we're looking forward to working with Domenic - and to the continued evolution of

Re: [gamepad] New feature proposals: pose, touchpad, vibration

Hi Brandon, > On 22 Apr 2016, at 08:14, Brandon Jones wrote: [...] > Finally, I'd like to propose that we add gamepad vibration controls. This has > been talked about in the past as well, and the thinking has typically been > that the Gamepad API may want to try and use

Re: [XHR] null response prop in case of invalid JSON

On Mon, Apr 25, 2016 at 8:10 PM, Kirill Dmitrenko wrote: > I've found in the spec of XHR Level 2 that if a malformed JSON's received > from a server, the response property would be set to null. But null is a > valid JSON, so, if I understand correctly, there is no way to

[XHR] null response prop in case of invalid JSON

Hi! I've found in the spec of XHR Level 2 that if a malformed JSON's received from a server, the response property would be set to null. But null is a valid JSON, so, if I understand correctly, there is no way to distinct a malformed JSON response from a response containing only 'null', which

Re: [gamepad] New feature proposals: pose, touchpad, vibration

Regarding the vibration portion of the API, I'm still not sure how much control we should provide. Don't want to get too closely tied to any specific native implementation. To that end I've put together a brief document comparing the APIs that I'm aware of:

Re: [custom-elements] Prefix x- for custom elements like data- attributes

On Mon, Apr 25, 2016 at 1:06 PM, Bang Seongbeom wrote: > It would be good to restrict custom element's name to start with like > 'x-' for the future standards. User-defined custom attributes; data > attributes are also restricted its name to start with 'data-' so we

Re: [custom-elements] Prefix x- for custom elements like data- attributes

On Mon, Apr 25, 2016 at 10:06 AM, Bang Seongbeom wrote: > It would be good to restrict custom element's name to start with like > 'x-' for the future standards. User-defined custom attributes; data > attributes are also restricted its name to start with 'data-' so we

[custom-elements] Prefix x- for custom elements like data- attributes

It would be good to restrict custom element's name to start with like 'x-' for the future standards. User-defined custom attributes; data attributes are also restricted its name to start with 'data-' so we can define easily new standard attribute names ('aria-*' or everything except for

Re: [gamepad] New feature proposals: pose, touchpad, vibration

Lots of good feedback! Replies inline. > Do we want to know the value of the press? Does the API for the Steam Controller, for example, return the force of the press as a float? > Likewise, Pointer Events have "pressure" GamepadButton already has a "value" property, which I think would be

RE: [gamepad] New feature proposals: pose, touchpad, vibration

From: Brandon Jones [mailto:bajo...@google.com] > readonly attribute Float32Array? position; Just as a quick API surface comment, Float32Array? is not a very good way of representing a vector (or quaternion). You want either separate x/y/z/w properties, or to use a DOMPoint(ReadOnly). Web

Re: [gamepad] New feature proposals: pose, touchpad, vibration

On Mon, Apr 25, 2016 at 4:31 AM, Chris Van Wiemeersch wrote: > > If you take a look at all the content libraries out there for the Gamepad > API, there's a ridiculous amount of logic and special casing web developers > are having to do just between the Firefox and Chrome

Re: [gamepad] New feature proposals: pose, touchpad, vibration

On 25/04/2016 03:31, Chris Van Wiemeersch wrote: Do we want to know the value of the press? Does the API for the Steam Controller, for example, return the force of the press as a float? The reason I ask is because with Touch events, there's a `force` property on the `Touch` interface:

Re: [gamepad] New feature proposals: pose, touchpad, vibration

Do we want to know the value of the press? Does the API for the Steam Controller, for example, return the force of the press as a float? The reason I ask is because with Touch events, there's a `force` property on the `Touch` interface: https://developer.mozilla.org/en-US/docs/Web/API/Touch/force

Re: [Custom Elements] Not requiring hyphens in names.

On Fri, Apr 22, 2016 at 8:24 PM, Anne van Kesteren wrote: > On Sat, Apr 23, 2016 at 3:08 AM, /#!/JoePea wrote: > > I really believe that we should be allowed to name our elements with any > > name we wish, and that they should override native elements (that

Re: [Custom Elements] Not requiring hyphens in names.

On Sat, Apr 23, 2016 at 3:08 AM, /#!/JoePea wrote: > I really believe that we should be allowed to name our elements with any > name we wish, and that they should override native elements (that is future > proof), and that overriding should be on some type of encapsulated basis

Re: [Custom Elements] Not requiring hyphens in names.

Thanks for the link! ​I really believe that we should be allowed to name our elements with any name we wish, and that they should override native elements (that is future proof), and that overriding should be on some type of encapsulated basis (for example, override within a shadow root and it

[gamepad] New feature proposals: pose, touchpad, vibration

I'd like to propose the addition of several new features to the Gamepad API, primarily born from needs that have been identified while developing the WebVR spec , but which also cover topics that have been under discussion in the past but deemed lower priority

Re: [Custom Elements] Not requiring hyphens in names.

Just FYI, the idea of allowing non-hyphen elements if they contain non-ASCII characters which probably won't collide with future HTML elements was posted in the discussion: https://github.com/w3c/webcomponents/issues/239#issuecomment-190603674 On Fri, Apr 15, 2016 at 7:01 AM, /#!/JoePea

Re: [Custom Elements] Not requiring hyphens in names.

On Wed, Apr 13, 2016 at 1:09 PM, Tab Atkins Jr. wrote: > That means we lose the lingua franca that HTML provides; two > independent libraries can't ever depend on the core HTML elements, > because the other library might have overridden some of them. Based on my idea of

Re: [Custom Elements] Not requiring hyphens in names.

On Wed, Apr 13, 2016 at 12:33 PM, /#!/JoePea wrote: > What if custom Elements simply override existing ones then? > > ```js > shadowRoot.registerElement('div', MyElement) > ``` That means we lose the lingua franca that HTML provides; two independent libraries can't ever depend

Re: [Custom Elements] Not requiring hyphens in names.

What if custom Elements simply override existing ones then? ```js shadowRoot.registerElement('div', MyElement) ``` If overriding native elements was documented, it'd be fine. By default, a blank document or shadow root has no elements registered, so would use the native DIV. But, why not let

Re: [Custom Elements] Not requiring hyphens in names.

I personal don't mind the hyphenation requirement for custom elements. Tab Atkins brings up a great point about ensuring that new elements will be able to be added to spec without worry of name conflicts with existing custom elements on the page. It's much more future proof, in my opinion. On

Re: [Custom Elements] Not requiring hyphens in names.

On Wed, Apr 13, 2016 at 11:12 AM, /#!/JoePea wrote: > I personally don't like this limitation. I think Custom Elements would > be better if we could create elements that have > , with the possible exception that we can't override the > native elements. This would prevent

[Custom Elements] Not requiring hyphens in names.

I personally don't like this limitation. I think Custom Elements would be better if we could create elements that have , with the possible exception that we can't override the native elements. Based on my previous email about registering elements on shadow roots, I think being able to choose

[Bug 13913] Attributes don't have an order

https://www.w3.org/Bugs/Public/show_bug.cgi?id=13913 Anne changed: What|Removed |Added Status|REOPENED|RESOLVED

Re: [service worker] f2f meeting notes, next meeting details

Hello, here are the day 2 meeting notes from the service worker F2F in Redmond,. The attendees are CC'd if there are any corrections that need to be made or if anyone has any questions or concerns that they would like to raise. = Service Worker F2F

[Bug 13913] Attributes don't have an order

https://www.w3.org/Bugs/Public/show_bug.cgi?id=13913 Bug 13913 depends on bug 17871, which changed state. Bug 17871 Summary: Element attributes should not be required to be stored in an ordered list https://www.w3.org/Bugs/Public/show_bug.cgi?id=17871 What|Removed

[Bug 24732] Remove DOMError from FileAPI

https://www.w3.org/Bugs/Public/show_bug.cgi?id=24732 Aryeh Gregor changed: What|Removed |Added Status|NEW |RESOLVED

Re: [Custom Elements] They are globals.

On Mon, Apr 11, 2016 at 4:44 PM, Ryosuke Niwa wrote: > You'd have to instead write it as "new SomeClass(this.shadowRoot)" and then > (1) needs to be modified as: `super(..arguments)` to pass the argument along > to the HTMLElement constructor. For sure, similar to the examples

Re: [service worker] f2f meeting notes, next meeting details

Hello, here are the day 1 meeting notes from the service worker F2F. The attendees are CC'd if there are any corrections that need to be made or if anyone has any questions or concerns that they would like to raise. = Service Worker F2F April 11, 2016

Re: [Custom Elements] They are globals.

> On Apr 11, 2016, at 2:29 PM, /#!/JoePea wrote: > > What if custom elements can be registered on a shadow-root basis, so > that the author of a Custom Element (one that isn't registered by > default) can register a bunch of elements that it's shadow root will > use, passing

Re: [Custom Elements] They are globals.

I get what you mean about the behaviors defined from classes that exist in the scope, in React. The really great thing about React is the ability to compose a class by using multiple classes to return the render spec. One of React's strong-points at a high level is it offers encapsulation where

Re: [Custom Elements] More ES6-like API

Thanks Ryosuke! That's looking a lot better. /#!/JoePea On Mon, Apr 11, 2016 at 10:28 AM, Ryosuke Niwa wrote: > That's exactly what we're doing. The latest spec uses ES6 class constructor > to define custom elements. See an example below this section in DOM spec: >

RE: [Custom Elements] They are globals.

I think you are being misled by a superficial similarity with React's JSX. JSX's `` desugars to `React.createElement(Foo)`, which creates a `` element with some of its behavior derived from the `Foo` class, found in JavaScript lexical scope. The `Foo` token has no impact on the DOM tree.

Re: [Custom Elements] They are globals.

> On Apr 11, 2016, at 9:02 AM, /#!/JoePea wrote: > > Is it possible to take an approach more similar to React where Custom > Elements aren't registered in a global pool? What if two libraries we'd like > to use define elements of the same name, and we wish to import these

Re: [Custom Elements] More ES6-like API

That's exactly what we're doing. The latest spec uses ES6 class constructor to define custom elements. See an example below this section in DOM spec: https://dom.spec.whatwg.org/#concept-element-custom-element-state - R. Niwa > On Apr 10, 2016, at 7:58 PM, /#!/JoePea wrote:

[Custom Elements] They are globals.

Hello, Is it possible to take an approach more similar to React where Custom Elements aren't registered in a global pool? What if two libraries we'd like to use define elements of the same name, and we wish to import these via `import` and not modify the source code of our dependencies? I don't

Re: [Custom Elements] Extension of arbitrary elements at runtime.

Hello Brian The purpose of the motor-scene and motor-node elements is that they will be easy to apply 3D transforms to (and WebGL soon), with easing for example. I suppose a better approach for augmenting and existing DOM could be to simply apply the transforms via selectors instead of trying to

Re: [Custom Elements] Extension of arbitrary elements at runtime.

On Sun, Apr 10, 2016 at 11:11 PM, /#!/JoePea wrote: > The is="" attribute lets one specify that some element is actually an > extended version of that element. > > But, in order for this to work, the Custom Element definition has to > deliberately extend that same basic

[Bug 24106] FKA: No defined way to get keyboard focus into and out of a shadow DOM component

https://www.w3.org/Bugs/Public/show_bug.cgi?id=24106 Bug 24106 depends on bug 23870, which changed state. Bug 23870 Summary: FKA: No defined way to get keyboard focus into and out of a shadow DOM component https://www.w3.org/Bugs/Public/show_bug.cgi?id=23870 What|Removed

[Bug 9514] [Selection] Specify Selection.modify()

https://www.w3.org/Bugs/Public/show_bug.cgi?id=9514 Ryosuke Niwa changed: What|Removed |Added Status|ASSIGNED|RESOLVED

[Custom Elements] Extension of arbitrary elements at runtime.

The is="" attribute lets one specify that some element is actually an extended version of that element. But, in order for this to work, the Custom Element definition has to deliberately extend that same basic element type or else it won't work. It'd be nice if a Custom Element definition could

Re: [service worker] f2f meeting notes, next meeting details

On Fri, 08 Apr 2016 07:01:14 +0200, Matt Falkenhagen wrote: 2016-02-10 0:21 GMT+09:00 Chaals McCathie Nevile : There will be another face to face meeting to discuss service workers, hosted by Microsoft in Seattle or Redmond, on 11-12 April. Right

Re: [service worker] f2f meeting notes, next meeting details

2016-02-10 0:21 GMT+09:00 Chaals McCathie Nevile : > There will be another face to face meeting to discuss service workers, > hosted by Microsoft in Seattle or Redmond, on 11-12 April. Right now there > is a stub page for the meeting: >

[Bug 29506] Support for a system-wide configuration file to specify permissions for web-applications

https://www.w3.org/Bugs/Public/show_bug.cgi?id=29506 Anne changed: What|Removed |Added Status|REOPENED|RESOLVED

[Bug 29506] Support for a system-wide configuration file to specify permissions for web-applications

https://www.w3.org/Bugs/Public/show_bug.cgi?id=29506 sworddrag...@aol.com changed: What|Removed |Added Status|RESOLVED|REOPENED

[Bug 29506] Support for a system-wide configuration file to specify permissions for web-applications

https://www.w3.org/Bugs/Public/show_bug.cgi?id=29506 Anne changed: What|Removed |Added Status|REOPENED|RESOLVED

[Bug 29506] Support for a system-wide configuration file to specify permissions for web-applications

https://www.w3.org/Bugs/Public/show_bug.cgi?id=29506 sworddrag...@aol.com changed: What|Removed |Added Status|RESOLVED|REOPENED CC|

RE: [Web Components] Editor for Custom Elements

From: Philippe Le Hegaret [mailto:p...@w3.org] > But I hope you realize that coming in the W3C community, working with them > for while, and then take things away to continue the work elsewhere is > received as not working in good faith with the W3C community. This is not a > judgment of

Re: [Web Components] Editor for Custom Elements

On 04/06/2016 03:34 PM, Domenic Denicola wrote: From: Léonie Watson [mailto:t...@tink.uk] Domenic Denicola briefly stepped into the role, but regretfully he has since declined to work within the W3C community [2]. That is not at all an accurate description of what has happened. I've very

RE: [Web Components] Editor for Custom Elements

From: Léonie Watson [mailto:t...@tink.uk] > Domenic Denicola briefly stepped into the role, but regretfully he has since > declined to work within the W3C community [2]. That is not at all an accurate description of what has happened. I've very much enjoyed working with the W3C community on the

Re: [Web Components] Editor for Custom Elements

On Wed, Apr 6, 2016 at 9:17 PM, Léonie Watson wrote: > Which means we're looking for someone (or more than one someone) to edit > Custom Elements. Web Components are a key part of the Web Platform, so it's > an interesting time to be part of the group working on Custom Elements (and

[Web Components] Editor for Custom Elements

Hello WP, We're looking for a new editor for the Custom Elements spec [1]. Dimitri Glazkov has stepped down as editor and will be greatly missed in the role. Thank you for all your hard work Dimitri, you helped make Custom Elements happen and it's very much appreciated. Domenic Denicola briefly

[Web Components] Minutes - Shadow DOM teleconf April 5

Available at https://www.w3.org/2016/04/05-webapps-minutes.html or as text below. Thanks to Jan Miksovsky for logistics, and in particular for scribing! [1]W3C [1] http://www.w3.org/ - DRAFT - Web Components Teleconference 05

Re: Telecon / meeting on first week of April for Web Components

Thanks to everyone who participated in the call. (Special thanks to those calling from Tokyo!) Minutes for the meeting are at https://www.w3.org/2016/04/05-webapps-minutes.html .

Re: Telecon / meeting on first week of April for Web Components

On Tue, Apr 5, 2016 at 6:55 PM, Xiaoqian Wu wrote: > I’m unfamiliar with WebEx. If Chaals or someone wants to make a strong push > to use that, please set up the call and send out instructions for joining. FYI: we're using Hangouts. If anyone cannot join please tell us on IRC

Re: Telecon / meeting on first week of April for Web Components

> On 6 Apr 2016, at 12:29 AM, Jan Miksovsky wrote: > > I’m unfamiliar with WebEx. If Chaals or someone wants to make a strong push > to use that, please set up the call and send out instructions for joining. We’ve scheduled a WebEx call for this Telecon, in case you

<    1   2   3   4   5   6   7   8   9   10   >