[Bug 23878] Define a fetch registry

[bugzilla]

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

Anne  changed:

   What|Removed |Added

 Resolution|--- |MOVED
  Flags|needinfo?(i...@hixie.ch) |
 Status|NEW |RESOLVED

--- Comment #22 from Anne  ---
https://github.com/whatwg/fetch/issues/81 is the successor to this issue.

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

[Bug 24072] Clarify handling of neutered objects

[bugzilla]

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

Anne  changed:

   What|Removed |Added

 Resolution|--- |WORKSFORME
 Status|NEW |RESOLVED

--- Comment #14 from Anne  ---
The ArrayBuffer part of this bug are actually issues with IDL:

  https://github.com/heycam/webidl/issues/151
  https://www.w3.org/Bugs/Public/show_bug.cgi?id=28798

At this point I think we should not throw for detached buffers. That will
likely cause breakage.

The Blob's close() method does not appear to be implemented:

  https://github.com/w3c/FileAPI/issues/10

So I'm not sure what we're planning on doing there. But it seems that if it's
ever implemented, making all callsites throw is going to be difficult to get
right.

With that I'm closing this bug as I don't think there's anything to be done
here in Fetch and XMLHttpRequest.

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

[Bug 26153] Allow ArrayBuffer as argument to send()

[bugzilla]

https://www.w3.org/Bugs/Public/show_bug.cgi?id=26153
Bug 26153 depends on bug 24072, which changed state.

Bug 24072 Summary: Clarify handling of neutered objects
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24072

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |WORKSFORME

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

Re: CfC: FPWD for Input Events

[chaals]

With expressions of support, and no objections, this Call for Consensus passes.

Thanks - I'll work with Johannes and the Team Contacts to get this published as 
soon as we can...

cheers

14.08.2016, 14:31, "cha...@yandex-team.ru" :
> Hi,
>
> This is a Call for Consensus on the proposition "Publish the Input Events 
> specification at https://w3c.github.io/input-events/ as a First Public 
> Working Draft".
>
> Please reply before the end of the day on 22 August, either in this email 
> thread or by adding a +1 or -1 to the proposal which is the first comment in 
> https://github.com/w3c/input-events/issues/1
>
> For the chairs, with thanks to Johannes and the people working on editing
>
> chaals
>
> --
> Charles McCathie Nevile - web standards - CTO Office, Yandex
> cha...@yandex-team.ru - - - Find more at http://yandex.com

--
Charles McCathie Nevile - web standards - CTO Office, Yandex
cha...@yandex-team.ru - - - Find more at http://yandex.com

Re: CFC to publish WebIDL-1 as a Proposed Recommendation

[Léonie Watson]

On 16/08/2016 07:46, Léonie Watson wrote:

This is a Call For Consensus (CFC) to publish WebIDL-1 as a Proposed
Recommendation (PR) [1].


This CFC received positive messages of support and no objections, and so 
it passes.



Thank you to Yves and Travis for their work on this specification.

Léonie.

--
@LeonieWatson tink.uk Carpe diem

Re: customized built-in element questions

[Dominic Cooney]

On Sun, Aug 21, 2016 at 12:02 PM, Mark Giffin  wrote:

> I have two questions I cannot seem to find the answer to in the Custom
> Elements spec,
> https://www.w3.org/TR/2016/WD-custom-elements-20160721/
>
> 1. Can I use the is= syntax for more than one customized built-in element,
> like ?


No.

It's an interesting possibility, but there's a practical problem with it,
which is: What prototype does the button get? big-button's, or red-button's?

If you write that today, what happens is the whole value is treated as a
potential name. There are lots of ways to create elements, but take create
an element for a token
,
which is used by parsing, for example. Step 3 takes the value of the entire
attribute but since "big-button red-button" isn't a valid name (it contains
a space) step 4 will never find a matching definition.

2. Is the is= syntax for using a customized built-in element likely to be
> deprecated sometime soon? I have heard only rumors.
>

I work on Chrome. Here are our plans at the moment:

- We have implemented the "autonomous custom elements" parts of this spec
(that is the  part, not the is="..." part); you can try it
today by enabling Experimental Web Platform Features in chrome://flags in
Chrome 54 or later. Feedback  welcome.
- We are debating whether to ship this now; you can follow the process
 in this
thread

.
- We implemented an earlier version of this spec, including "is". It uses
document.registerElement to define custom elements. We plan to remove this,
but we have a process for that too
 and we
probably can't remove it this year.
- We are implementing the "new" is="..." stuff right now. You should be
able to play with it behind a flag in a couple of months.


> Thanks,
> Mark
>

Re: [Custom Elements] Should I write v1 Custom Elements in a way backwards compatible with v0 API?

[Dominic Cooney]

I implemented custom elements in Chrome (twice.) This looks reasonable to
me.

The exact timing of createdCallback and constructor running, and errors
around element creation, are different. If authors stick to the
restrictions of custom elements "v1" they should be fine, because they're
more restrictive than v0.

On Sun, Aug 21, 2016 at 11:13 AM, /#!/JoePea  wrote:

> Due to the renaming of some class methods (attached/detached to
> connected/disconnected) and removal of createdCallback in favor of
> constructors (which is a good thing!), I find myself writing my
> WebComponent base class (class-factory mixin) as follows.
>
> My question is, should I be doing what I'm doing, or do you recommend
> something else? Note that the attached/detachedCallback methods simply call
> the connected/disconnectedCallback methods, and also note what I've done
> with `createdCallback` and the `constructor` due to the differences between
> v0 and v1. Subclasses of my WebComponent base class still use
> `createdCallback` rather than a constructor in order to be backwards
> compatible.
>
> The code is as follows, with parts removed for brevity in order to show
> just the parts dealing with the v0/v1 APIs directly and how backwards
> compatibility is maintained:
>
> // Very very stupid hack needed for Safari in order for us to be able
> to extend
> // the HTMLElement class. See:
> // https://github.com/google/traceur-compiler/issues/1709
> if (typeof window.HTMLElement != 'function') {
> const _HTMLElement = function HTMLElement(){}
> _HTMLElement.prototype = window.HTMLElement.prototype
> window.HTMLElement = _HTMLElement
> }
>
> // XXX: Maybe we can improve by clearing items after X amount of time?
> const classCache = new Map
>
> function hasHTMLElementPrototype(constructor) {
> if (!constructor) return false
> if (constructor === HTMLElement) return true
> else return hasHTMLElementPrototype(constructor.prototype)
> }
>

I'm not sure this is right. Would it be simpler anyway to just say
constructor && (constructor === HTMLElement || constructor.prototype
instanceof HTMLElement)?


> /**
>  * Creates a WebComponent base class dynamically, depending on which
>  * HTMLElement class you want it to extend from. Extend from
> WebComponent when
>  * making a new Custom Element class.
>  *
>  * @example
>  * import WebComponent from './WebComponent'
>  * class AwesomeButton extends WebComponent(HTMLButtonElement) { ... }
>  *
>  * @param {Function} elementClass The class that the generated
> WebComponent
>  * base class will extend from.
>  */
> export default
> function WebComponentMixin(elementClass) {
> if (!elementClass) elementClass = HTMLElement
>
> if (!hasHTMLElementPrototype(elementClass)) {
> throw new TypeError(
> 'The argument to WebComponentMixin must be a constructor
> that extends from or is HTMLElement.'
> )
> }
>
> // if a base class that extends the given `elementClass` has
> already been
> // created, return it.
> if (classCache.has(elementClass))
> return classCache.get(elementClass)
>
> // otherwise, create it.
> class WebComponent extends elementClass {
>
> // constructor() is used in v1 Custom Elements instead of
> // createdCallback() as in v0.
> constructor() {
> super()
>
> // If the following is true, then we know the user should
> be using
> // `document.registerElement()` to define an element from
> this class.
> // `document.registerElement()` creates a new constructor,
> so if the
> // constructor here is being called then that means the
> user is not
> // instantiating a DOM HTMLElement as expected because it
> is required
> // that the constructor returned from
> `document.registerElement` be used
> // instead (this is a flaw of Custom Elements v0 which is
> fixed in v1
> // where class constructors can be used directly).
> if (document.registerElement && !customElements.define) {
>
> // TODO: link to docs.
> throw new Error(`
> You cannot instantiate this class directly without
> first registering it
> with \`document.registerElement(...)\`. See an
> example at http://
> `)
>
> }
>
> // Throw an error if no Custom Elements API exists.
> if (!document.registerElement && !customElements.define) {
>
> // TODO: link to docs.
> throw new Error(`
> Your browser does not support the Custom Elements
> API. You'll
>   

Re: CfC: Pointer Lock to Proposed Recommendation; deadline August 20

[Léonie Watson]

On 14/08/2016 00:01, Xiaoqian Wu wrote:

This is a Call for Consensus to publish a Proposed Recommendation of
Pointer Lock 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.


This CFC received no objections, and so it passes.

Thanks to Vincent and Xiaoqian for their work on the Pointer Lock spec.

Léonie.


--
@LeonieWatson tink.uk Carpe diem

[Custom Elements] Should I write v1 Custom Elements in a way backwards compatible with v0 API?

[/#!/JoePea]

Due to the renaming of some class methods (attached/detached to
connected/disconnected) and removal of createdCallback in favor of
constructors (which is a good thing!), I find myself writing my
WebComponent base class (class-factory mixin) as follows.

My question is, should I be doing what I'm doing, or do you recommend
something else? Note that the attached/detachedCallback methods simply call
the connected/disconnectedCallback methods, and also note what I've done
with `createdCallback` and the `constructor` due to the differences between
v0 and v1. Subclasses of my WebComponent base class still use
`createdCallback` rather than a constructor in order to be backwards
compatible.

The code is as follows, with parts removed for brevity in order to show
just the parts dealing with the v0/v1 APIs directly and how backwards
compatibility is maintained:

// Very very stupid hack needed for Safari in order for us to be able
to extend
// the HTMLElement class. See:
// https://github.com/google/traceur-compiler/issues/1709
if (typeof window.HTMLElement != 'function') {
const _HTMLElement = function HTMLElement(){}
_HTMLElement.prototype = window.HTMLElement.prototype
window.HTMLElement = _HTMLElement
}

// XXX: Maybe we can improve by clearing items after X amount of time?
const classCache = new Map

function hasHTMLElementPrototype(constructor) {
if (!constructor) return false
if (constructor === HTMLElement) return true
else return hasHTMLElementPrototype(constructor.prototype)
}

/**
 * Creates a WebComponent base class dynamically, depending on which
 * HTMLElement class you want it to extend from. Extend from
WebComponent when
 * making a new Custom Element class.
 *
 * @example
 * import WebComponent from './WebComponent'
 * class AwesomeButton extends WebComponent(HTMLButtonElement) { ... }
 *
 * @param {Function} elementClass The class that the generated
WebComponent
 * base class will extend from.
 */
export default
function WebComponentMixin(elementClass) {
if (!elementClass) elementClass = HTMLElement

if (!hasHTMLElementPrototype(elementClass)) {
throw new TypeError(
'The argument to WebComponentMixin must be a constructor
that extends from or is HTMLElement.'
)
}

// if a base class that extends the given `elementClass` has
already been
// created, return it.
if (classCache.has(elementClass))
return classCache.get(elementClass)

// otherwise, create it.
class WebComponent extends elementClass {

// constructor() is used in v1 Custom Elements instead of
// createdCallback() as in v0.
constructor() {
super()

// If the following is true, then we know the user should
be using
// `document.registerElement()` to define an element from
this class.
// `document.registerElement()` creates a new constructor,
so if the
// constructor here is being called then that means the
user is not
// instantiating a DOM HTMLElement as expected because it
is required
// that the constructor returned from
`document.registerElement` be used
// instead (this is a flaw of Custom Elements v0 which is
fixed in v1
// where class constructors can be used directly).
if (document.registerElement && !customElements.define) {

// TODO: link to docs.
throw new Error(`
You cannot instantiate this class directly without
first registering it
with \`document.registerElement(...)\`. See an
example at http://
`)

}

// Throw an error if no Custom Elements API exists.
if (!document.registerElement && !customElements.define) {

// TODO: link to docs.
throw new Error(`
Your browser does not support the Custom Elements
API. You'll
need to install a polyfill. See how at http://
`)

}

// otherwise the V1 API exists, so call the
createdCallback, which
// is what Custom Elements v0 would call by default.
Subclasses of
// WebComponent should put instantiation logic in
createdCallback
// instead of in a custom constructor if backwards
compatibility is
// to be maintained.
this.createdCallback()
}

createdCallback() {
// code removed for brevity...
}

connectedCallback() {
// code removed for brevity...
}
attachedCallback() { 

Re: CfC: Pointer Lock to Proposed Recommendation; deadline August 20

[Léonie Watson]

Quick reminder that this CFC closes tomorrow, Saturday 20th August. Thanks.

Léonie.

--
@LeonieWatson tink.uk Carpe diem

On 14/08/2016 00:01, Xiaoqian Wu wrote:

Hello, Web Platform WG,

This is a Call for Consensus to publish a Proposed Recommendation of
Pointer Lock 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.

The test results for Pointer Lock [All] indicate significant
interoperability, with only one test that have less than two passes [<2].
; this test failure
can be considered more of a Web IDL implementation issue. The group
believes it will get better over time as WebIDL compliance progresses.

The current [OPEN ISSUES], #5 is about adding pointerlock to the
permissions enum, will be fixed the next version. Another issue is
about pointerlockchange and the accessibility tree (#1), which is
resolved by a magnification software note added to pointerlockchange and
pointerlockerror Events.

Changes since the CR publication includes:
* Specify movementX/Y to be 0 after gaps in mouse input.

We consider the change since the CR as non-substantive. See [Diff] for
all of changes between the CR and the draft PR.

If you have any comments or concerns about this CfC, please reply to
this e-mail by August 20 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 on August
25 2016.

Thanks.

-xiaoqian

[PR] http://w3c.github.io/pointerlock/publish/index-2016-PR.html
[All] http://w3c.github.io/test-results/pointerlock/all.html
[<2] http://w3c.github.io/test-results/pointerlock/less-than-2.html
[OPEN ISSUES] https://github.com/w3c/pointerlock/issues
[Diff]
https://github.com/w3c/pointerlock/commits/gh-pages/index.html
http://services.w3.org/htmldiff?doc1=https%3A%2F%2Fwww.w3.org%2FTR%2F2016%2FCR-pointerlock-20160705%2F=http%3A%2F%2Fw3c.github.io%2Fpointerlock%2Fpublish%2Findex-2016-PR.html

RE: [fileapi] Pull Request on GitHub

[Adrian Bateman]

> On Wed, Aug 17, 2016 at 11:38:59, Marijn Kruisselbrink wrote:
> Sorry about that. Somehow that PR slipped through the cracks. I've commented
> on the PR.
> 
> Anybody knows what the deal is with the ipr check? What makes it fail, and if
> it fails who is supposed to do what to not make it fail?

This happens when someone who is not a recognized (by the tool) member of
the WG makes a pull request.

Since this looks like only editorial changes, we'll mark it as non-substantive.

Cheers,

Adrian.

Re: [fileapi] Pull Request on GitHub

[Marijn Kruisselbrink]

On Tue, Aug 16, 2016 at 11:43 AM, Arun Ranganathan 
wrote:

> I won't be editing it either.
>
> On Tue, Aug 16, 2016 at 4:44 AM, Marcos Caceres 
> wrote:
>
>> On August 16, 2016 at 6:31:31 PM, Zhen Zhang (izgz...@gmail.com) wrote:
>> > Hi,
>> >
>> > I have a PR on GitHub regarding some issues of wording in current File
>> API spec: https://github.com/w3c/FileAPI/pull/42
>> > , but nobody ever responded me there.
>> > I wonder if I should discuss the patch somewhere else?
>>
> Sorry about that. Somehow that PR slipped through the cracks. I've
commented on the PR.

Anybody knows what the deal is with the ipr check? What makes it fail, and
if it fails who is supposed to do what to not make it fail?

It seems that no one has touched that API for about 8 months.
>>
> Not sure where you're getting 8 months from? I definitely still have
catching up with outstanding issues to do, but I have been doing work on
the API significantly more recent than 8 months.


> Marijn, are you still editing that document? I guess Jonas won't be,
>> but not sure about Arun.
>>
> Yes, I'm still editing that document. Just haven't had time yet to fully
catch up with outstanding issues/comments.

WG Decision on referencing the Image Description (longdesc) extension

[Adrian Bateman]

The chairs have published details of the Working Group decision
on referencing the Image Description (longdesc) extension in HTML.
In short, most of the CfC carried without objection but there were
some objections related to the longdesc examples.

For convenience, the decision text is pasted below but the full text
including links is posted at [1].

Thanks to everyone who participated in the CfC discussion.

Adrian, on behalf of the WPWG chairs.

[1] 
https://github.com/w3c/WebPlatformWG/blob/gh-pages/decisions/imagedesc-08-2016.md


Working Group Decision on referencing the Image Description (longdesc) 
extension in HTML

Question before the working group

The HTML 5.1 draft added normative references to the Image Description 
(longdesc) Recommendation including IDL definitions. The CfC issued on 5 August 
2016 proposed:

1. Remove the longdesc attribute from the table of attributes in HTML core.
2. Remove the IDL information for the longdesc attribute from HTML core.
3. Keep the longdesc examples in HTML core.
4. Create a WG Note listing known extension specifications.
5. Include a link to the HTML Extension Specifications Note from HTML core 
(probably in the index).

Consensus

There were expressions of support and no objections for #1, #2, #4, and #5. 
These steps reflect the consensus of the group.

Objections

There was disagreement on #3 namely whether to keep non-normative examples for 
longdesc in the specification. In summary, the concerns raised here are:

* Some people indicated that the HTML 5.1 spec should not include examples for 
technology that is not normatively defined in the spec itself.

* Some people indicated that non-normative examples necessarily rely on 
technology that is not defined in the spec, though no examples were cited.

* Some people indicated that editors should have editorial freedom over 
non-normative text including examples.

Separately, a concern was raised that whatever decision was taken for longdesc 
should also apply to other features such as RDFa and the rev attribute.

Decision of the Working Group

Principles

The Working Group has not yet chosen an approach for how to modularise the HTML 
specification. This topic will be discussed at TPAC 2016. Until this is 
decided, the chairs intend to implement the following principles:

* The Working Group SHOULD NOT incorporate features from HTML Extension 
Specifications that have independently reached Recommendation status into the 
main HTML Specification.

* The Working Group SHOULD maintain a list of applicable HTML Extension 
specifications as a Working Group Note.

In addition:

* The Working Group provides editors the freedom to enhance specifications with 
non-normative text that improves readability and makes documents easier to 
understand without seeking approval from the working group. However, members of 
the Working Group MAY express an opinion on this text and seek consensus to 
change it.

Summary of Arguments

In the judgement of the chairs, the strongest argument for not incorporating 
longdesc in informative examples is that the feature does not exist in the HTML 
5.1 specification and isn't necessary for the rest of the example to be valid. 
It may be true that some examples rely on technology not defined in HTML 5.1 
but in general this should only be done when it is necessary for the example to 
be easily comprehended.

In this case, the weakest argument for leaving the informative examples intact 
was that this is a decision left to the editorial team. While we don't intend 
to micro-manage the great editorial work contributed by the editors, in this 
instance the argument to avoid technology defined elsewhere if feasible is more 
persuasive.

By applying the principles above, we must consider whether other parts of the 
HTML 5.1 draft also incorporate features from other W3C Recommendations. The 
chairs agree that the RDFa examples are part of a Recommendation and must also 
be removed.

The rev attribute was previously described in HTML 5.0 and the HTML 5.1 draft 
defines this content attribute in a more formal way. The rev attribute does not 
need to be removed.

Decision

The Web Platform Working Group adopts parts #1, #2, #4, and #5 of the CfC 
proposal. Further, the Web Platform Working Group rejects #3 and adopts the 
decision to remove longdesc from the examples in HTML 5.1. This reverts the 
document to the same state as HTML 5.0 for this issue.

The Web Platform Working Group will also apply this decision to RDFa and will 
remove the RDFa examples.

Next steps

The chairs will ask the editors to remove the longdesc content that was added 
through PR #441 and PR #449 and the similar RDFa content.

The chairs and Team will work with the editors will to create a Working Group 
Note listing the applicable HTML extension specifications.

Appealing this Decision

If anyone feels they have not received due process, or that their concerns have 
not being duly considered in the course of 

Re: CfC: Pointer Lock to Proposed Recommendation; deadline August 20

[Léonie Watson]

+1

Great for this to be progressing.

Léonie.

--
@LeonieWatson tink.uk Carpe diem

On 14/08/2016 00:01, Xiaoqian Wu wrote:

Hello, Web Platform WG,

This is a Call for Consensus to publish a Proposed Recommendation of
Pointer Lock 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.

The test results for Pointer Lock [All] indicate significant
interoperability, with only one test that have less than two passes [<2].
; this test failure
can be considered more of a Web IDL implementation issue. The group
believes it will get better over time as WebIDL compliance progresses.

The current [OPEN ISSUES], #5 is about adding pointerlock to the
permissions enum, will be fixed the next version. Another issue is
about pointerlockchange and the accessibility tree (#1), which is
resolved by a magnification software note added to pointerlockchange and
pointerlockerror Events.

Changes since the CR publication includes:
* Specify movementX/Y to be 0 after gaps in mouse input.

We consider the change since the CR as non-substantive. See [Diff] for
all of changes between the CR and the draft PR.

If you have any comments or concerns about this CfC, please reply to
this e-mail by August 20 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 on August
25 2016.

Thanks.

-xiaoqian

[PR] http://w3c.github.io/pointerlock/publish/index-2016-PR.html
[All] http://w3c.github.io/test-results/pointerlock/all.html
[<2] http://w3c.github.io/test-results/pointerlock/less-than-2.html
[OPEN ISSUES] https://github.com/w3c/pointerlock/issues
[Diff]
https://github.com/w3c/pointerlock/commits/gh-pages/index.html
http://services.w3.org/htmldiff?doc1=https%3A%2F%2Fwww.w3.org%2FTR%2F2016%2FCR-pointerlock-20160705%2F=http%3A%2F%2Fw3c.github.io%2Fpointerlock%2Fpublish%2Findex-2016-PR.html

Re: [fileapi] Pull Request on GitHub

[Arun Ranganathan]

I won't be editing it either.

On Tue, Aug 16, 2016 at 4:44 AM, Marcos Caceres  wrote:

> On August 16, 2016 at 6:31:31 PM, Zhen Zhang (izgz...@gmail.com) wrote:
> > Hi,
> >
> > I have a PR on GitHub regarding some issues of wording in current File
> API spec: https://github.com/w3c/FileAPI/pull/42
> > , but nobody ever responded me there.
> > I wonder if I should discuss the patch somewhere else?
>
> It seems that no one has touched that API for about 8 months.
>
> Marijn, are you still editing that document? I guess Jonas won't be,
> but not sure about Arun.
>
>

CFC to publish WebIDL-1 as a Proposed Recommendation

[Léonie Watson]

Hello WP,

This is a Call For Consensus (CFC) to publish WebIDL-1 as a Proposed 
Recommendation (PR) [1].


Some editorial changes were made to the specification during the 
Candidate Recommendation (CR) period, but none that affects conformance. 
The CR implementation

report is available [2].

We are still exploring different ways of responding to a CFC. Please 
choose one of the following methods:


1. Reply by email to this thread (on public-webapps@w3.org).
2. Reply or +1 on Github [3].

There is no need to use more than one method. The WP chairs will collate 
the results across all channels.


Please respond by end of day on Monday 22nd August. Positive responses 
are encouraged, but silence will be taken as consent with the proposal.


Thanks
Léonie on behalf of the WP chairs and team
[1]
https://ylafon.github.io/webidl/publications/pr-20160809.html
[2]
https://www.w3.org/WebPlatform/WG/implementations/webidl-1/report/all.html
[3] https://github.com/w3c/WebPlatformWG/issues/61
--
@LeonieWatson tink.uk Carpe diem

Re: [fileapi] Pull Request on GitHub

[Marcos Caceres]

On August 16, 2016 at 6:31:31 PM, Zhen Zhang (izgz...@gmail.com) wrote:
> Hi,
>
> I have a PR on GitHub regarding some issues of wording in current File API 
> spec: https://github.com/w3c/FileAPI/pull/42
> , but nobody ever responded me there.
> I wonder if I should discuss the patch somewhere else?

It seems that no one has touched that API for about 8 months.

Marijn, are you still editing that document? I guess Jonas won't be,
but not sure about Arun.

[fileapi] Pull Request on GitHub

[Zhen Zhang]

Hi,

I have a PR on GitHub regarding some issues of wording in current File API 
spec: https://github.com/w3c/FileAPI/pull/42 
, but nobody ever responded me there.
I wonder if I should discuss the patch somewhere else?

Thanks you,

- Zhen

CfC: FPWD for Input Events

[chaals]

Hi,

This is a Call for Consensus on the proposition "Publish the Input Events 
specification at https://w3c.github.io/input-events/ as a First Public Working 
Draft".

Please reply before the end of the day on 22 August, either in this email 
thread or by adding a +1 or -1 to the proposal which is the first comment in 
https://github.com/w3c/input-events/issues/1

For the chairs, with thanks to Johannes and the people working on editing

chaals

--
Charles McCathie Nevile - web standards - CTO Office, Yandex
cha...@yandex-team.ru - - - Find more at http://yandex.com

CfC: Pointer Lock to Proposed Recommendation; deadline August 20

[Xiaoqian Wu]

Hello, Web Platform WG,

This is a Call for Consensus to publish a Proposed Recommendation of Pointer 
Lock 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.

The test results for Pointer Lock [All] indicate significant interoperability, 
with only one test that have less than two passes [<2].
; this test failure can be 
considered more of a Web IDL implementation issue. The group believes it will 
get better over time as WebIDL compliance progresses.

The current [OPEN ISSUES], #5 is about adding pointerlock to the permissions 
enum, will be fixed the next version. Another issue is about pointerlockchange 
and the accessibility tree (#1), which is resolved by a magnification software 
note added to pointerlockchange and pointerlockerror Events.

Changes since the CR publication includes:
* Specify movementX/Y to be 0 after gaps in mouse input.

We consider the change since the CR as non-substantive. See [Diff] for all of 
changes between the CR and the draft PR.

If you have any comments or concerns about this CfC, please reply to this 
e-mail by August 20 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 on August 25 2016.

Thanks.

-xiaoqian

[PR] http://w3c.github.io/pointerlock/publish/index-2016-PR.html
[All] http://w3c.github.io/test-results/pointerlock/all.html
[<2] http://w3c.github.io/test-results/pointerlock/less-than-2.html 

[OPEN ISSUES] https://github.com/w3c/pointerlock/issues
[Diff]
https://github.com/w3c/pointerlock/commits/gh-pages/index.html
http://services.w3.org/htmldiff?doc1=https%3A%2F%2Fwww.w3.org%2FTR%2F2016%2FCR-pointerlock-20160705%2F=http%3A%2F%2Fw3c.github.io%2Fpointerlock%2Fpublish%2Findex-2016-PR.html
 

[Bug 26917] For any chunk, progress event should be fired at least in 50ms since the arrival of the chunk

[bugzilla]

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

Anne  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |WORKSFORME

--- Comment #9 from Anne  ---
If you still want to change this, let's discuss it on GitHub.

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

[Bug 12837] Define unloading document cleanup steps

[bugzilla]

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

Anne  changed:

   What|Removed |Added

 Resolution|--- |WORKSFORME
 Status|NEW |RESOLVED

--- Comment #22 from Anne  ---
Demos still work for me.

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

[Bug 25589] To improve readability, set response to null rather than network error

[bugzilla]

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

Anne  changed:

   What|Removed |Added

 Resolution|--- |WONTFIX
 Status|NEW |RESOLVED

--- Comment #1 from Anne  ---
No longer convinced this is worth it.

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

[Bug 28505] Synchronous XHR removal makes patching Error.prepareStackTrace impossible

[bugzilla]

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

Anne  changed:

   What|Removed |Added

 Resolution|--- |INVALID
 Status|NEW |RESOLVED

--- Comment #2 from Anne  ---
If this continuous to be a problem, please contribute to this thread on GitHub:
https://github.com/whatwg/xhr/issues/20

Thanks!

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

Re: Service Workers meeting info

[Léonie Watson]

On 11/08/2016 11:41, Jake Archibald wrote:

Notes were taken in IRC, here's a
log https://gist.github.com/jakearchibald/c65009efa2ed9dbe3ad38f5fef5a4ef1. 
Here's
my run-down of the
headlines https://jakearchibald.com/2016/service-worker-meeting-notes/.


Thanks Jake. Both added to the WP meetings page [1].

Léonie.
[1] https://github.com/w3c/WebPlatformWG/blob/gh-pages/Meetings.md



--
@LeonieWatson tink.uk Carpe diem

[Bug 20322] Upload progress events vs CORS

[bugzilla]

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

Anne  changed:

   What|Removed |Added

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

--- Comment #22 from Anne  ---
I just went with what implementations do for now:
https://github.com/whatwg/xhr/commit/667d4f3604aaee4e24bde33ed487cf8a98274e70

Basically always require listeners upfront...

I also submitted a correction for Hallvord's test based on what implementations
do today: https://github.com/w3c/web-platform-tests/pull/3451

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

Re: CFC: Publish a FPWD of IndexedDB 2.0

[Léonie Watson]

With thanks to everyone who responded. This CFC received only positive 
responses, and so passes without objection.


Léonie.


--
@LeonieWatson tink.uk Carpe diem

On 03/08/2016 15:46, Léonie Watson wrote:

Hello WP,

This is a Call For Consensus (CFC) to publish a First Public Working
Draft (FPWD) of IndexedDB 2.0 [1].

We are still exploring different ways of responding to a CFC. Please
choose one of the following methods:

1. Reply by email to this thread (on
public-webapps@w3.org).

2. Reply or +1 on Github:
https://github.com/w3c/IndexedDB/issues/84

There is no need to use more than one method. The WP chairs will collate
the results across all channels.

Please respond by end of day on Wednesday 10th August. Positive
responses are encouraged, but silence will be taken as consent with the
proposal.

Thanks
Léonie on behalf of the WP chairs and team
[1]
http://w3c.github.io/IndexedDB/

Re: Service Workers meeting info

[Jake Archibald]

Notes were taken in IRC, here's a log
https://gist.github.com/jakearchibald/c65009efa2ed9dbe3ad38f5fef5a4ef1. Here's
my run-down of the headlines
https://jakearchibald.com/2016/service-worker-meeting-notes/.

On Tue, 12 Jul 2016 at 11:52 Léonie Watson  wrote:

> Hello WP,
>
> Information for the meeting on 28/29 July is here:
>
> https://github.com/w3c/WebPlatformWG/blob/gh-pages/meetings/16-07-28-29SW.md
>
>
> If you plan to attend, it would be helpful if you could create a PR to
> add yourself to the attendees list (or let me know and I'll add you).
>
> Thanks.
> Léonie.
>
>
> It looks like the meeting info is complete on this page, except for --
> @LeonieWatson tink.uk Carpe diem
>
>

Re: CFC on referencing the Image Description (longdesc) extension

[Léonie Watson]

A quick reminder that this CFC closes at the end of day tomorrow (Friday 
12th August).


Thanks.
Léonie.

--
@LeonieWatson tink.uk Carpe diem

On 05/08/2016 18:17, Léonie Watson wrote:

Hello WP,

This is a Call For Consensus (CFC) on the following proposal for
referencing the Image Description (longdesc) extension specification
[1]. The CFC is posted to public-webapps@w3.org because this is the
official WP email list, and copied to public-h...@w3.org.

The proposal:

1. Remove the longdesc attribute from the table of attributes in HTML core.
2. Remove the IDL information for the longdesc attribute from HTML core.
3. Keep the longdesc examples in HTML core **.
4. Create a WG Note listing known extension specifications ***.
5. Include a link to the HTML Extension Specifications Note from HTML
core (probably in the index).

** Examples throughout the HTML specification are informative, and we
include informative examples and information for other specifications
and extensions
elsewhere in HTML core.

*** We anticipate that the Note will be updated as we identify new/other
extension specifications.

We are still exploring different ways of responding to a CFC. Please
choose one of the following methods:

1. Reply by email to this thread.
2. Reply or +1 to the original proposal comment on Github [2].

There is no need to use more than one method. The WP chairs will collate
the results across all channels.

Please respond by end of day on Friday 12th August. Positive responses
are encouraged, but silence will be taken as consent with the proposal.

Thanks
Léonie on behalf of the WP chairs and team
[1]  https://www.w3.org/TR/html-longdesc/
[2] https://github.com/w3c/html/issues/507#issuecomment-237068400

RE: CFC: Publish a FPWD of IndexedDB 2.0

[Ali Alabbas]

+1

> On Tue, Aug 09, 2016 at 08:07:10, Alexander Schmitz wrote:
> 
> +1
> 
> Alexander Schmitz
> jQuery Foundation
> 
> On Tue, Aug 9, 2016 at 8:45 AM, Dylan Barrell   > wrote:
> 
> 
>   +1
> 
>   On Tue, Aug 9, 2016 at 5:06 AM, Léonie Watson   > wrote:
> 
> 
>   Quick reminder that this CFC closes at the end of day
> tomorrow (Wednesday 10th August). Thanks.
> 
>   Léonie.
> 
>   --
>   @LeonieWatson tink.uk   Carpe diem
> 
> 
>   On 03/08/2016 15:46, Léonie Watson wrote:
> 
> 
>   Hello WP,
> 
>   This is a Call For Consensus (CFC) to publish a First
> Public Working
>   Draft (FPWD) of IndexedDB 2.0 [1].
> 
>   We are still exploring different ways of responding to
> a CFC. Please
>   choose one of the following methods:
> 
>   1. Reply by email to this thread (on
>   public-webapps@w3.org
>  ).
> 
>   2. Reply or +1 on Github:
>   https://github.com/w3c/IndexedDB/issues/84
> 
> 
>   There is no need to use more than one method.
> The WP chairs will collate
>   the results across all channels.
> 
>   Please respond by end of day on Wednesday 10th
> August. Positive
>   responses are encouraged, but silence will be taken
> as consent with the
>   proposal.
> 
>   Thanks
>   Léonie on behalf of the WP chairs and team
>   [1]
>   http://w3c.github.io/IndexedDB/
> 
> 
> 
> 
> 
> 
> 
>   --
> 
>   Download the aXe browser extension for free:
> 
> 
>   Firefox:
> https://addons.mozilla.org/en-US/firefox/addon/axe-devtools
> 
>   Chrome:
> https://chrome.google.com/webstore/detail/axe/lhdoppojpmngadmnindne
> jefpo
> kejbdd?hl=en-US
>  ejefp
> okejbdd?hl=en-US>
> 
> 
>   Life is ten percent what happens to you and ninety percent how you
> respond to it. - Lou Holtz
> 
> 
> 

Re: CFC: Publish a FPWD of IndexedDB 2.0

[Dylan Barrell]

+1

On Tue, Aug 9, 2016 at 5:06 AM, Léonie Watson  wrote:

> Quick reminder that this CFC closes at the end of day tomorrow (Wednesday
> 10th August). Thanks.
>
> Léonie.
>
> --
> @LeonieWatson tink.uk Carpe diem
>
> On 03/08/2016 15:46, Léonie Watson wrote:
>
>> Hello WP,
>>
>> This is a Call For Consensus (CFC) to publish a First Public Working
>> Draft (FPWD) of IndexedDB 2.0 [1].
>>
>> We are still exploring different ways of responding to a CFC. Please
>> choose one of the following methods:
>>
>> 1. Reply by email to this thread (on
>> public-webapps@w3.org).
>>
>> 2. Reply or +1 on Github:
>> https://github.com/w3c/IndexedDB/issues/84
>>
>> There is no need to use more than one method. The WP chairs will collate
>> the results across all channels.
>>
>> Please respond by end of day on Wednesday 10th August. Positive
>> responses are encouraged, but silence will be taken as consent with the
>> proposal.
>>
>> Thanks
>> Léonie on behalf of the WP chairs and team
>> [1]
>> http://w3c.github.io/IndexedDB/
>>
>
>


-- 
Download the aXe browser extension for free:

Firefox: https://addons.mozilla.org/en-US/firefox/addon/axe-devtools
Chrome:
https://chrome.google.com/webstore/detail/axe/lhdoppojpmngadmnindnejefpokejbdd?hl=en-US

Life is ten percent what happens to you and ninety percent how you respond
to it. - Lou Holtz

Re: Leaving Mozilla

[Léonie Watson]

On 06/08/2016 02:12, Jonas Sicking wrote:

A little over a month ago I got married. My wife and I are planning on
doing an extended honeymoon, starting now and ending sometime early next
year.


Congratulations!

[...]


Working on the web with you all has been an amazing experience. Please
keep moving the web forward and make it a pleasant experience for all
developers to build amazing and beautiful content that is enjoyable for
users to take part of.


Thank you for all the hard work you have put into making this happen 
Jonas. It is much appreciated, and I hope we'll see you back here 
sometime after your honeymoon adventures.


Léonie on behalf of the WP chairs and team.



--
@LeonieWatson tink.uk Carpe diem

Re: CFC: Publish a FPWD of IndexedDB 2.0

[Léonie Watson]

Quick reminder that this CFC closes at the end of day tomorrow 
(Wednesday 10th August). Thanks.


Léonie.

--
@LeonieWatson tink.uk Carpe diem

On 03/08/2016 15:46, Léonie Watson wrote:

Hello WP,

This is a Call For Consensus (CFC) to publish a First Public Working
Draft (FPWD) of IndexedDB 2.0 [1].

We are still exploring different ways of responding to a CFC. Please
choose one of the following methods:

1. Reply by email to this thread (on
public-webapps@w3.org).

2. Reply or +1 on Github:
https://github.com/w3c/IndexedDB/issues/84

There is no need to use more than one method. The WP chairs will collate
the results across all channels.

Please respond by end of day on Wednesday 10th August. Positive
responses are encouraged, but silence will be taken as consent with the
proposal.

Thanks
Léonie on behalf of the WP chairs and team
[1]
http://w3c.github.io/IndexedDB/

Re: CFC on referencing the Image Description (longdesc) extension

[Mona Rekhi]

+1

via CloudMagic 
Email
On Fri, Aug 05, 2016 at 1:21 PM, L?onie Watson 
> wrote:


Hello WP,

This is a Call For Consensus (CFC) on the following proposal for
referencing the Image Description (longdesc) extension specification
[1]. The CFC is posted to public-webapps@w3.org because this is the
official WP email list, and copied to public-h...@w3.org.

The proposal:

1. Remove the longdesc attribute from the table of attributes in HTML core.
2. Remove the IDL information for the longdesc attribute from HTML core.
3. Keep the longdesc examples in HTML core **.
4. Create a WG Note listing known extension specifications ***.
5. Include a link to the HTML Extension Specifications Note from HTML
core (probably in the index).

** Examples throughout the HTML specification are informative, and we
include informative examples and information for other specifications
and extensions
elsewhere in HTML core.

*** We anticipate that the Note will be updated as we identify new/other
extension specifications.

We are still exploring different ways of responding to a CFC. Please
choose one of the following methods:

1. Reply by email to this thread.
2. Reply or +1 to the original proposal comment on Github [2].

There is no need to use more than one method. The WP chairs will collate
the results across all channels.

Please respond by end of day on Friday 12th August. Positive responses
are encouraged, but silence will be taken as consent with the proposal.

Thanks
L?onie on behalf of the WP chairs and team
[1]  https://www.w3.org/TR/html-longdesc/
[2] https://github.com/w3c/html/issues/507#issuecomment-237068400
--
@LeonieWatson tink.uk Carpe diem

Re: CFC on referencing the Image Description (longdesc) extension

[John Foliot]

Despite lingering concerns about removing a valid attribute from the table
of attributes in the document, in the interest of cooperation and
collaborative consensus building I will agree with this CfC.

JF

On Fri, Aug 5, 2016 at 12:17 PM, Léonie Watson  wrote:

> Hello WP,
>
> This is a Call For Consensus (CFC) on the following proposal for
> referencing the Image Description (longdesc) extension specification [1].
> The CFC is posted to public-webapps@w3.org because this is the official
> WP email list, and copied to public-h...@w3.org.
>
> The proposal:
>
> 1. Remove the longdesc attribute from the table of attributes in HTML core.
> 2. Remove the IDL information for the longdesc attribute from HTML core.
> 3. Keep the longdesc examples in HTML core **.
> 4. Create a WG Note listing known extension specifications ***.
> 5. Include a link to the HTML Extension Specifications Note from HTML core
> (probably in the index).
>
> ** Examples throughout the HTML specification are informative, and we
> include informative examples and information for other specifications and
> extensions
> elsewhere in HTML core.
>
> *** We anticipate that the Note will be updated as we identify new/other
> extension specifications.
>
> We are still exploring different ways of responding to a CFC. Please
> choose one of the following methods:
>
> 1. Reply by email to this thread.
> 2. Reply or +1 to the original proposal comment on Github [2].
>
> There is no need to use more than one method. The WP chairs will collate
> the results across all channels.
>
> Please respond by end of day on Friday 12th August. Positive responses are
> encouraged, but silence will be taken as consent with the proposal.
>
> Thanks
> Léonie on behalf of the WP chairs and team
> [1]  https://www.w3.org/TR/html-longdesc/
> [2] https://github.com/w3c/html/issues/507#issuecomment-237068400
> --
> @LeonieWatson tink.uk Carpe diem
>
>


-- 
John Foliot
Principal Accessibility Strategist
Deque Systems Inc.
john.fol...@deque.com

Advancing the mission of digital accessibility and inclusion

Leaving Mozilla

[Jonas Sicking]

Hi All,

A little over a month ago I got married. My wife and I are planning on
doing an extended honeymoon, starting now and ending sometime early next
year.

I'm not certain where we'll end up after the honeymoon, or what either of
us will work with. Because of this, my last day at Mozilla was Wednesday
Aug 3rd.

Working on the web with you all has been an amazing experience. Please keep
moving the web forward and make it a pleasant experience for all developers
to build amazing and beautiful content that is enjoyable for users to take
part of.

I'll unsubscribe to this and other w3c lists shortly, but if you want to
reach me I'll still be on this email address.

For those who are interested, here's a video of, not my wife's and my first
dance, but of our first circus performance .

/ Jonas

CFC on referencing the Image Description (longdesc) extension

[Léonie Watson]

Hello WP,

This is a Call For Consensus (CFC) on the following proposal for 
referencing the Image Description (longdesc) extension specification 
[1]. The CFC is posted to public-webapps@w3.org because this is the 
official WP email list, and copied to public-h...@w3.org.


The proposal:

1. Remove the longdesc attribute from the table of attributes in HTML core.
2. Remove the IDL information for the longdesc attribute from HTML core.
3. Keep the longdesc examples in HTML core **.
4. Create a WG Note listing known extension specifications ***.
5. Include a link to the HTML Extension Specifications Note from HTML 
core (probably in the index).


** Examples throughout the HTML specification are informative, and we 
include informative examples and information for other specifications 
and extensions

elsewhere in HTML core.

*** We anticipate that the Note will be updated as we identify new/other 
extension specifications.


We are still exploring different ways of responding to a CFC. Please 
choose one of the following methods:


1. Reply by email to this thread.
2. Reply or +1 to the original proposal comment on Github [2].

There is no need to use more than one method. The WP chairs will collate 
the results across all channels.


Please respond by end of day on Friday 12th August. Positive responses 
are encouraged, but silence will be taken as consent with the proposal.


Thanks
Léonie on behalf of the WP chairs and team
[1]  https://www.w3.org/TR/html-longdesc/
[2] https://github.com/w3c/html/issues/507#issuecomment-237068400
--
@LeonieWatson tink.uk Carpe diem

Re: Meeting between Web platform and ARIA at TPAC

[Chaals McCathie Nevile]

Hi Rich

Cc+ Adrian - co-chair of the WG

On Thu, 04 Aug 2016 16:00:18 +0200, Rich Schwerdtfeger  
 wrote:



Leonie, Charles,

I would like to request a 90 minute meeting on Friday at TPAC.


We generally don't have more than 60 minutes for meeting sessions. You're  
requesting a joint session with the ARIA WG, right?


I've put a marker into the agenda for now:  
https://github.com/w3c/WebPlatformWG/blob/gh-pages/meetings/16-09-23TPAC-4.md


Of critical importance is the discussion regarding the requirements  
around Web Components. Some issues I know we need to discuss are:


1. ARIA 2.0 extensibility
2. ARIA  2.0 needed semantics


Can you provide a bit more framing information for these questions? What  
do you think WP can help with?


3. Ability to reference elements inside a web component and from within  
the web component to outside the web component.


This sounds like it should be brought up directly in the Web Components  
work. We don't expect many, if any, of the people most involved in that to  
be there on Friday, having set aside a full day for the topic on the  
Monday.


Again, framing the issue in more detail in advance would be helpful. Is  
there a requirement to do this, a use case, do you want it to be  
impossible, or what? It would probably be a good idea to check the issues  
currently filed, and if there isn't an issue (open or closed) that matches  
this, then file one - or if there is one already explain your use cases /  
requirements there.


cheers

Chaals

--
Charles McCathie Nevile - web standards - CTO Office, Yandex
cha...@yandex-team.ru - - - Find more at http://yandex.com

Re: Meeting between Web platform and ARIA at TPAC

[Léonie Watson]

On 04/08/2016 15:00, Rich Schwerdtfeger wrote:

I would like to request a 90 minute meeting on Friday at TPAC.


Thanks Rich.

We've taken a different approach to meeting at TPAC this year. Instead 
of the whole WG meeting on each of the four meeting days, each day is 
focused on a specific area of work - to help people manage their time 
across different WGs.


Web Components meet on Monday at TPAC [1]. Your request just prompted me 
to send out a reminder for agenda items - so we'll start to get a better 
idea of availability etc.


Léonie
[1] 
https://github.com/w3c/WebPlatformWG/blob/gh-pages/meetings/16-09-19TPAC-1.md

--
@LeonieWatson tink.uk Carpe diem

RE: Meeting between Web platform and ARIA at TPAC

[Siegman, Tzviya - Hoboken]

I will be there as well.
Tzviya

Tzviya Siegman
Information Standards Lead
Wiley
201-748-6884
tsieg...@wiley.com

From: Shane McCarron [mailto:sh...@spec-ops.io]
Sent: Thursday, August 04, 2016 12:18 PM
To: Brian Kardell
Cc: Rich Schwerdtfeger; Léonie Watson; Chaals McCathie Nevile; ARIA Working 
Group; public-webapps WG
Subject: Re: Meeting between Web platform and ARIA at TPAC

I will like to attend this as well if I can dodge the other bullets that day.

On Thu, Aug 4, 2016 at 10:26 AM, Brian Kardell 
> wrote:


On Thu, Aug 4, 2016 at 10:00 AM, Rich Schwerdtfeger 
> wrote:
Leonie, Charles,

I would like to request a 90 minute meeting on Friday at TPAC. Of critical 
importance is the discussion regarding the requirements around Web Components. 
Some issues I know we need to discuss are:

1. ARIA 2.0 extensibility
2. ARIA  2.0 needed semantics
3. Ability to reference elements inside a web component and from within the web 
component to outside the web component.

Best,
Rich

Rich Schwerdtfeger


I'll be at TPAC and would really love to be there for this if that is possible.

--
Brian Kardell :: @briankardell



--
Shane McCarron
Projects Manager, Spec-Ops

Re: Meeting between Web platform and ARIA at TPAC

[Shane McCarron]

I will like to attend this as well if I can dodge the other bullets that
day.

On Thu, Aug 4, 2016 at 10:26 AM, Brian Kardell  wrote:

>
>
> On Thu, Aug 4, 2016 at 10:00 AM, Rich Schwerdtfeger 
> wrote:
>
>> Leonie, Charles,
>>
>> I would like to request a 90 minute meeting on Friday at TPAC. Of
>> critical importance is the discussion regarding the requirements around Web
>> Components. Some issues I know we need to discuss are:
>>
>> 1. ARIA 2.0 extensibility
>> 2. ARIA  2.0 needed semantics
>> 3. Ability to reference elements inside a web component and from within
>> the web component to outside the web component.
>>
>> Best,
>> Rich
>>
>> Rich Schwerdtfeger
>>
>>
> I'll be at TPAC and would really love to be there for this if that is
> possible.
>
> --
> Brian Kardell :: @briankardell
>



-- 
Shane McCarron
Projects Manager, Spec-Ops

WPWG meetings at TPAC

[Léonie Watson]

Hello WP,

Instead of asking the whole WG to meet on all four meeting days at TPAC, 
we had requests from editors and other active contributors to focus each 
day on a different area of work [1].


Monday - Web Components
Tuesday - Service Workers
Thursday - Editing TF and Selection API
Friday - HTML, IndexedDB, Directory Upload, HTML and WP general business.

We are starting to receive requests from other WGs to meet with the 
relevant people within WPWG [2]. It would help enormously if we knew 
what availability each WP group has for such meetings.


If each group within WP can add agenda items to the relevant meeting 
page (either by PR or by letting me know), that would be much 
appreciated. Thanks already to the IndexedDB editors for doing this!


Léonie.

[1] https://github.com/w3c/WebPlatformWG/blob/gh-pages/Meetings.md
[2] 
https://lists.w3.org/Archives/Public/public-webapps/2016JulSep/0027.html

Meeting between Web platform and ARIA at TPAC

[Rich Schwerdtfeger]

Leonie, Charles,

I would like to request a 90 minute meeting on Friday at TPAC. Of critical 
importance is the discussion regarding the requirements around Web Components. 
Some issues I know we need to discuss are:

1. ARIA 2.0 extensibility
2. ARIA  2.0 needed semantics
3. Ability to reference elements inside a web component and from within the web 
component to outside the web component.

Best,
Rich

Rich Schwerdtfeger

CFC: Publish a FPWD of IndexedDB 2.0

[Léonie Watson]

Hello WP,

This is a Call For Consensus (CFC) to publish a First Public Working 
Draft (FPWD) of IndexedDB 2.0 [1].


We are still exploring different ways of responding to a CFC. Please 
choose one of the following methods:


1. Reply by email to this thread (on
public-webapps@w3.org).

2. Reply or +1 on Github:
https://github.com/w3c/IndexedDB/issues/84

There is no need to use more than one method. The WP chairs will collate 
the results across all channels.


Please respond by end of day on Wednesday 10th August. Positive 
responses are encouraged, but silence will be taken as consent with the 
proposal.


Thanks
Léonie on behalf of the WP chairs and team
[1]
http://w3c.github.io/IndexedDB/
--
@LeonieWatson tink.uk Carpe diem

Type correction Re: New editors for Clipboard API spec

[Chaals McCathie Nevile]

On Sun, 31 Jul 2016 02:16:17 +0200, Chaals McCathie Nevile  
 wrote:



Hi,

I'm happy to announce


Grisha *Lyukshin*. Sorry Grisha

and Gary Kačmarčik as the new editors of the Clipboard API  
specification, and to thank them for

volunteering,


cheers


--
Charles McCathie Nevile - web standards - CTO Office, Yandex
 cha...@yandex-team.ru - - - Find more at http://yandex.com

Fwd: Minutes / results of editing meeting

[Chaals McCathie Nevile]

FYI

--- Forwarded message ---
From: "Chaals McCathie Nevile" 
To: "public-editing...@w3.org" 
Cc:
Subject: Minutes / results of meeting
Date: Sat, 30 Jul 2016 23:51:18 +0200

Hi folks,

Detailed minutes are at http://www.w3.org/2016/07/29-editing-minutes.html

Gary produced a summary of what we said and decided at
https://docs.google.com/document/d/1XxIEF0So-kMF5mcJ03Yj0zsYMFRHEgXw1fV1K5FOwuQ

And Grisha filed issues, and what we decided on them, in the issue tracker
https://github.com/w3c/editing

Thanks to Ojan and Google for hosting.

cheers


--
Charles McCathie Nevile - web standards - CTO Office, Yandex
 cha...@yandex-team.ru - - - Find more at http://yandex.com

New editors for Clipboard API spec

[Chaals McCathie Nevile]

Hi,

I'm happy to announce Grisha Lyushkin and Gary Kačmarčik as the new editors
of the Clipboard API specification, and to thank them for volunteering, as
well as Hallvord for the work he put into it until now.

cheers

--
Charles McCathie Nevile - web standards - CTO Office, Yandex
   cha...@yandex-team.ru - - - Find more at http://yandex.com

Re: Draft recharter proposal

[Chaals McCathie Nevile]

On Fri, 29 Jul 2016 18:29:44 +0200, Olli Pettay  wrote:


On 07/29/2016 06:13 PM, Chaals McCathie Nevile wrote:

Hi folks,

our charter expires at the end of September. I've produced a draft  
version of a new charter, for people to comment on:

http://w3c.github.io/charter-html/group-charter.html

Feel free to raise comments as issues:  
https://github.com/w3c/charter-html/issues/new


As per the change section:

New deliverables:
Microdata

Removed as deliverables:
Streams; URL; XHR1

Marked as deliverables to be taken up if incubation suggests likely  
success:
Background Synchronisation; Filesystem API; FindText API; HTML Import;  
Input Methods; Packaging; Quota API



Given what has been happening with directory upload stuff recently,  
Filesystem stuff is a bit controversial.
(Gecko and Edge implementing https://wicg.github.io/entries-api/, or  
something quite similar. The draft doesn't quite follow browsers.

  Entries API is a subset of what Blink has been shipping.)
But I think some way better API than the old Chrome-only API should be  
implemented for Filesystem in general, and at that point also

better stuff for directory upload, *and* for directory download.
I'd consider the callback based, awkward to use Blink API a legacy thing.


Filesystem is a bit controversial - there have been a number of proposals  
over most of a decade now. The idea is that if we have one that matches  
something browsers do and want to continue with, and we maintain it, that  
would be a helpful thing to do.


I thought it is pretty much agreed that HTML Import is deprecated, or  
something to not to do now.


At any rate, I believe there is not enough apparent interest to rate it as  
a definite work item.


Both of those are in a section of things the group *may* do, if there is  
reason to expect success, but I think that could be made much clearer in  
the document.


Microdata has very wide ongoing usage, and it would be helpful to have  
something clearer than the current W3C Note - which includes things  
that don't
work - for people to refer to. So I'm proposing to do the editing,  
along with Dan Brickley from Google, and to work roughly on the basis  
we use in
HTML of specifying what actually works, rather than adding in what we  
would like.



So the only implementation of HTML Microdata API in browsers was removed  
recently
https://bugzilla.mozilla.org/show_bug.cgi?id=909633 because exposing the  
API caused web pages to break.


Yes, removing the API from the spec is one of the things we expect to do.  
Browsers generally do nothing with microdata as far as I know, which is  
fine. It's not particularly directed at them anyway. It's used by search  
engines, and put into massive numbers of web sites for that purpose.


cheers, and thanks for the comments.

Chaals

--
Charles McCathie Nevile - web standards - CTO Office, Yandex
 cha...@yandex-team.ru - - - Find more at http://yandex.com

Re: Draft recharter proposal

[Olli Pettay]

On 07/29/2016 06:13 PM, Chaals McCathie Nevile wrote:

Hi folks,

our charter expires at the end of September. I've produced a draft version of a 
new charter, for people to comment on:
http://w3c.github.io/charter-html/group-charter.html

Feel free to raise comments as issues: 
https://github.com/w3c/charter-html/issues/new

As per the change section:

New deliverables:
Microdata

Removed as deliverables:
Streams; URL; XHR1

Marked as deliverables to be taken up if incubation suggests likely success:
Background Synchronisation; Filesystem API; FindText API; HTML Import; Input 
Methods; Packaging; Quota API



Given what has been happening with directory upload stuff recently, Filesystem 
stuff is a bit controversial.
(Gecko and Edge implementing https://wicg.github.io/entries-api/, or something 
quite similar. The draft doesn't quite follow browsers.
 Entries API is a subset of what Blink has been shipping.)
But I think some way better API than the old Chrome-only API should be 
implemented for Filesystem in general, and at that point also
better stuff for directory upload, *and* for directory download.
I'd consider the callback based, awkward to use Blink API a legacy thing.


I thought it is pretty much agreed that HTML Import is deprecated, or something 
to not to do now.




Microdata has very wide ongoing usage, and it would be helpful to have 
something clearer than the current W3C Note - which includes things that don't
work - for people to refer to. So I'm proposing to do the editing, along with 
Dan Brickley from Google, and to work roughly on the basis we use in
HTML of specifying what actually works, rather than adding in what we would 
like.



So the only implementation of HTML Microdata API in browsers was removed 
recently
https://bugzilla.mozilla.org/show_bug.cgi?id=909633 because exposing the API 
caused web pages to break.




-Olli





cheers

Chaals

Draft recharter proposal

[Chaals McCathie Nevile]

Hi folks,

our charter expires at the end of September. I've produced a draft version  
of a new charter, for people to comment on:  
http://w3c.github.io/charter-html/group-charter.html


Feel free to raise comments as issues:  
https://github.com/w3c/charter-html/issues/new


As per the change section:

New deliverables:
Microdata

Removed as deliverables:
Streams; URL; XHR1

Marked as deliverables to be taken up if incubation suggests likely  
success:
Background Synchronisation; Filesystem API; FindText API; HTML Import;  
Input Methods; Packaging; Quota API


Microdata has very wide ongoing usage, and it would be helpful to have  
something clearer than the current W3C Note - which includes things that  
don't work - for people to refer to. So I'm proposing to do the editing,  
along with Dan Brickley from Google, and to work roughly on the basis we  
use in HTML of specifying what actually works, rather than adding in what  
we would like.


cheers

Chaals

--
Charles McCathie Nevile - web standards - CTO Office, Yandex
 cha...@yandex-team.ru - - - Find more at http://yandex.com

Re: Service Worker issues

[Ben Kelly]

On Thu, Jul 28, 2016 at 4:13 PM, Tab Atkins Jr. 
wrote:

> > caches.open("blog - 2016-06-10 14:14:23 -0700").then(c => c.keys())
> > Promise { : "pending" }
>
> Note that this test will *not* tell you whether or not c.keys()
> returns a promise; the .then callback is allowed to return a
> non-promise, and .then() always returns a promise regardless.  You
> have to log the return value of c.keys() directly.
>

caches.open("blog - 2016-06-10 14:14:23 -0700").then(c =>
console.log(c.keys()))
Promise { : "pending" }
Promise { : "pending" }

Re: Service Worker issues

[Tab Atkins Jr.]

> caches.open("blog - 2016-06-10 14:14:23 -0700").then(c => c.keys())
> Promise { : "pending" }

Note that this test will *not* tell you whether or not c.keys()
returns a promise; the .then callback is allowed to return a
non-promise, and .then() always returns a promise regardless.  You
have to log the return value of c.keys() directly.

~TJ

Re: Service Worker issues

[Ben Kelly]

On Wed, Jul 27, 2016 at 11:57 AM, Sam Ruby  wrote:

> The following is a mix of spec and implementation issues that I
> encountered in my as-of-yet unsuccessful attempt to make use of service
> workers in the ASF Board Agenda tool.
>

First, let me say thank you for the feedback!  Its very helpful to hear
from developers.


> 1) the "offline fallback" use case for Service Workers involves
> intercepting fetch requests, issuing the request, and then recovering from
> any errors that may occur.  Unfortunately, issuing the event.request will
> not faithfully reproduce the original navigate request, in particular,
> credentials are not included.
>

Yes, there have been a lot of bugs that fall into this category.  Its
re-creating the Response object from the browser native network stack is
particularly prone to missing information.

If you can be more specific about the type of request you are seeing this
with we can write a WPT test and make sure it doesn't regress.


> 3) event.request.headers.get("Authorization") is available on Firefox but
> not on Chrome.
>

Is this Authorization header on the original request being set by the
browser or manually in an XHR/fetch?

Looking at the spec the service worker should probably *not* see
Authorization headers added by the browser.  That's supposed to happen
after the service worker interception.


> 4) cache.keys() is supposed to return a promise.  On both Firefox and
> Chrome, cache.keys() returns an empty array instead.  cache.matchAll() can
> be used to get all of the responses, but not the keys.
>

Can you share the code you are using?  It returns a promise in our tests
and in my quick check in the console:

caches.open("blog - 2016-06-10 14:14:23 -0700").then(c => c.keys())
Promise { : "pending" }


> 5) calling registration.unregister() followed by
> navigator.serviceWorker.getRegistrations() will still return a list
> containing the now unregistered service worker in both Firefox and Chrome.
>

Are you waiting for the promise returned by unregister() to resolve?


> 6) EventSource is available to service workers in Chrome but not in
> Firefox.  Using importScripts in an attempt to load the Yaffle polyfill
> doesn't work.
>

We have a bug filed for this:

https://bugzilla.mozilla.org/show_bug.cgi?id=1267903

Thanks again.

Ben

Service Worker issues

[Sam Ruby]

The following is a mix of spec and implementation issues that I 
encountered in my as-of-yet unsuccessful attempt to make use of service 
workers in the ASF Board Agenda tool.


1) the "offline fallback" use case for Service Workers involves 
intercepting fetch requests, issuing the request, and then recovering 
from any errors that may occur.  Unfortunately, issuing the 
event.request will not faithfully reproduce the original navigate 
request, in particular, credentials are not included.


2) passing credentials: 'include' on fetch requests within a service 
worker will succeed if the browser has access to the credentials (e.g. 
due to prompting the user earlier in the browser session).  If the 
credentials are not present, Firefox will prompt for this information. 
Chrome will not.  This is a showstopper for offline access to an 
authenticated web page with Chrome.


3) event.request.headers.get("Authorization") is available on Firefox 
but not on Chrome.


4) cache.keys() is supposed to return a promise.  On both Firefox and 
Chrome, cache.keys() returns an empty array instead.  cache.matchAll() 
can be used to get all of the responses, but not the keys.


5) calling registration.unregister() followed by 
navigator.serviceWorker.getRegistrations() will still return a list 
containing the now unregistered service worker in both Firefox and Chrome.


6) EventSource is available to service workers in Chrome but not in 
Firefox.  Using importScripts in an attempt to load the Yaffle polyfill 
doesn't work.


Advice on how to proceed with these issues (filing bugs on the spec 
and/or one or more implementations, perhaps?) would be greatly appreciated.


Thanks!

- Sam Ruby

Re: Call for Consensus: Publish HTML 5.2 FPWD?

[Chaals McCathie Nevile]

On Tue, 05 Jul 2016 16:15:32 +0200, Chaals McCathie Nevile  
 wrote:



This is a call for consensus on the proposition:

Publish the current editors' draft of HTML 5.2 -  
https://w3c.github.io/html/ - as a First Public Working Draft.


With a positive response and no objections, the call for consensus passes.  
We will prepare a draft and Transition request, and hope to make the  
publication next week.



You can provide a response in this email thread.

You can provide a comment or thumbs-up in the issue in the HTML repo -  
https://github.com/w3c/html/issues/515


Most responses were in fact on the HTML repo.

You can provide a comment or thumbs-up in the issue in the WebPlatformWG  
repo - https://github.com/w3c/WebPlatformWG/issues/43


Thanks all

Chaals for the chairs and editors

--
Charles McCathie Nevile - web standards - CTO Office, Yandex
 cha...@yandex-team.ru - - - Find more at http://yandex.com

Review request: Wake Lock API

[Chaals McCathie Nevile]

Hello all,

The Device & Sensors Working Group has asked us to review the Wake Lock
API, on it way to Candidate Recommendation status:
https://www.w3.org/TR/wake-lock/

Their specific question is whether the API "fits" with the rest of the Web
Platform. Please provide feedback before the end of August, preferably as
issues in the github repository:  https://github.com/w3c/wake-lock/issues

Alternatively, comments can be made by email to the public mailing list
public-device-a...@w3.org with a subject prefixed with [wake-lock]

Unless somebody specifically asks for feedback to be endorsed by this  
group, comments should be made in a personal capacity.


cheers

Chaals

--
Charles McCathie Nevile - web standards - CTO Office, Yandex
   cha...@yandex-team.ru - - - Find more at http://yandex.com

Service Workers meeting info

[Léonie Watson]

Hello WP,

Information for the meeting on 28/29 July is here:
https://github.com/w3c/WebPlatformWG/blob/gh-pages/meetings/16-07-28-29SW.md 



If you plan to attend, it would be helpful if you could create a PR to 
add yourself to the attendees list (or let me know and I'll add you).


Thanks.
Léonie.


It looks like the meeting info is complete on this page, except for --
@LeonieWatson tink.uk Carpe diem

RE: Call for Consensus: Publish HTML 5.2 FPWD?

[Katie Haritos-Shea GMAIL]

+1 to publish

​



* 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 | @ryladog


-Original Message-
From: Léonie Watson [mailto:t...@tink.uk] 
Sent: Monday, July 11, 2016 6:15 AM
To: Chaals McCathie Nevile ; public-webapps WG 

Subject: Re: Call for Consensus: Publish HTML 5.2 FPWD?

Reminder that this CFC closes on Thursday 14th July (end of day). If you can 
take a few minutes to respond through one of the three proposed channels, it 
will help us identify the work mode that suits the WG best. 
Thanks.

Léonie.

On 05/07/2016 15:15, Chaals McCathie Nevile wrote:
> This is a call for consensus on the proposition:
>
> Publish the current editors' draft of HTML 5.2 - 
> https://w3c.github.io/html/ - as a First Public Working Draft.
>
> Silence will be considered assent, but positive responses are preferred.
> In an effort to find a smoother way to assess consensus, there are 
> three possible mechanisms for feedback, and you should pick the one 
> you find most convenient:
>
> You can provide a response in this email thread.
>
> You can provide a comment or thumbs-up in the issue in the HTML repo -
> https://github.com/w3c/html/issues/515
>
> You can provide a comment or thumbs-up in the issue in the 
> WebPlatformWG repo - https://github.com/w3c/WebPlatformWG/issues/43
>
> There is no need to use more than one of these mechanisms, as the 
> chairs will collate the results.
>
> If many people use the issues instead of email, we will likely propose 
> a change to the work mode for assessing consensus.
>
> There will be a separate thread on the merits of any procedural change 
> - please *only* reply to this thread to support or oppose the FPWD 
> publication.
>
> cheers
>
> Chaals, for the chairs
>

Re: Call for Consensus: Publish HTML 5.2 FPWD?

[Dylan Barrell]

+1 to publish

On Mon, Jul 11, 2016 at 6:14 AM, Léonie Watson  wrote:

> Reminder that this CFC closes on Thursday 14th July (end of day). If you
> can take a few minutes to respond through one of the three proposed
> channels, it will help us identify the work mode that suits the WG best.
> Thanks.
>
> Léonie.
>
>
> On 05/07/2016 15:15, Chaals McCathie Nevile wrote:
>
>> This is a call for consensus on the proposition:
>>
>> Publish the current editors' draft of HTML 5.2 -
>> https://w3c.github.io/html/ - as a First Public Working Draft.
>>
>> Silence will be considered assent, but positive responses are preferred.
>> In an effort to find a smoother way to assess consensus, there are three
>> possible mechanisms for feedback, and you should pick the one you find
>> most convenient:
>>
>> You can provide a response in this email thread.
>>
>> You can provide a comment or thumbs-up in the issue in the HTML repo -
>> https://github.com/w3c/html/issues/515
>>
>> You can provide a comment or thumbs-up in the issue in the WebPlatformWG
>> repo - https://github.com/w3c/WebPlatformWG/issues/43
>>
>> There is no need to use more than one of these mechanisms, as the chairs
>> will collate the results.
>>
>> If many people use the issues instead of email, we will likely propose a
>> change to the work mode for assessing consensus.
>>
>> There will be a separate thread on the merits of any procedural change -
>> please *only* reply to this thread to support or oppose the FPWD
>> publication.
>>
>> cheers
>>
>> Chaals, for the chairs
>>
>>
>


-- 
Download the aXe browser extension for free:

Firefox: https://addons.mozilla.org/en-US/firefox/addon/axe-devtools
Chrome:
https://chrome.google.com/webstore/detail/axe/lhdoppojpmngadmnindnejefpokejbdd?hl=en-US

Life is ten percent what happens to you and ninety percent how you respond
to it. - Lou Holtz

Re: Quick update on WebIDL "Level 1"

[marcos]

> On 11 Jul 2016, at 10:45 PM, Yves Lafon  wrote:
> 
> The goal of publishing this as a REC is not to have a final document nor to 
> please only
> the lawyers. The goal is to provide a document that contains the parts of the 
> WebIDL
> syntax that are implemented, and the associated implemented ES-binding, as a 
> guide
> for spec authors that are not following the main WebIDL spec evolutions (as 
> not everybody 
> has your knowledge of what is or is not usable in WebIDL).

Yes, but that's precisely the point. If something is not interoperable in the 
spec, then it should be fixed. Now we are back at Domenic's email. No spec 
editors should be, or will be, referencing v1. It's simple pointless to think 
otherwise. Look, all browser vendors already implement promise-using 
WebIDL-based APIs, which means that they've already had to implement v2 
features. 

I think a large segment of the WG has made it pretty clear that's it harmful to 
pretend that WebIDL 1 has any value to anyone but patent lawyers. Technically, 
it's just going to be bit-rotting trash sitting on TR (as you even acknowledge 
below). 

> 
> The -1 spec explicitly states that people wanting to implement WebIDL are 
> invited to read
> the main WebIDL specification (that, ideally, should be automatically 
> published as /TR/WebIDL ) because yes
> WebIDL-1 is _not_ the WebIDL specification, just a frozen snapshot of what 
> was implemented as the 
> time of publication, not more than that, and bound to be replaced by a 
> subsequent level later on.

Yes, but it's grossly obsolete and no one but patent lawyers should be, or will 
be, looking at it. So why bother putting it on TR? 

You can't seriously say that anyone writing specs would be using it to 
implement against - not even as joke. It has zero value from a technical 
perspective - yet huge value from an IPR perspective. 

I'm all for getting the IPR protection, but let's stop with putting useless 
things on TR. 

Re: Quick update on WebIDL "Level 1"

[Yves Lafon]

> On 10 Jul 2016, at 16:35, Marcos Caceres  wrote:
> 
> On July 9, 2016 at 6:24:56 AM, Domenic Denicola (d...@domenic.me) wrote:
>> From: Travis Leithead [mailto:travis.leith...@microsoft.com]
>> 
>>> The purpose of the “Level 1” document is to serve as a stable reference for 
>>> W3C specs that
>> link to WebIDL. It contains a subset of the WebIDL syntax that is considered 
>> stable (as
>> verified by interoperable tests). Implementations should not use the Level 1 
>> document
>> as a guide, but instead track changes to the editors draft. We expect to 
>> follow-up Level
>> 1 with a Level 2 as additional editor’s draft syntax and behavior 
>> stabilizes, are implemented
>> as part of other specs, and shown to be interoperable.
>> 
>> Why is it acceptable for specs to reference a version of Web IDL that nobody 
>> should implement?
> 
> This is a totally valid question, but we've had this debate 1001
> times. Perhaps a better question is: how can we get patent protection
> (making this subset of WebIDL royalty free for society), but without
> harming the ecosystem by confusing implementers and developers by
> publishing on the "/TRash" space (as most of us now unfortunately
> referring to it).
> 
> We need a way to clearly indicate that, for a subset of documents,
> RECs on TR represent a royalty free set of ideas (as kindly and
> honorably granted by the W3C Membership) - and should only be referred
> to by patent lawyers and government officials. That it's for those
> groups should be stated and promoted proudly, not disparagingly. And,
> that implementers should be looking at the living document instead.
> The value of TR need not be diminished - in fact: it should be
> correctly used to published the documents that enshrine the royalty
> free status of particular specifications.

The goal of publishing this as a REC is not to have a final document nor to 
please only
the lawyers. The goal is to provide a document that contains the parts of the 
WebIDL
syntax that are implemented, and the associated implemented ES-binding, as a 
guide
for spec authors that are not following the main WebIDL spec evolutions (as not 
everybody 
has your knowledge of what is or is not usable in WebIDL).

The -1 spec explicitly states that people wanting to implement WebIDL are 
invited to read
the main WebIDL specification (that, ideally, should be automatically published 
as /TR/WebIDL ) because yes
WebIDL-1 is _not_ the WebIDL specification, just a frozen snapshot of what was 
implemented as the 
time of publication, not more than that, and bound to be replaced by a 
subsequent level later on.

> Perhaps we need a new space just for documents that represent and
> agree to set of royalty free ideas? (i..e, if it's a REC, it does into
> this new space - and gets clearly marked for the appropriate target
> audience, which is not implementers or developers - but patent lawyers
> and government officials)...
> 
> I think we've also had this debate 10001 times too... but we need to
> do something folks, as the division between the forks and the reality
> of how web specs are developed is hurting everyone :(
> 
> Kind regards,
> Marcos
> 

-- 
Baroula que barouleras, au tiéu toujou t'entourneras.

~~Yves

Re: Call for Consensus: Publish HTML 5.2 FPWD?

[Léonie Watson]

Reminder that this CFC closes on Thursday 14th July (end of day). If you 
can take a few minutes to respond through one of the three proposed 
channels, it will help us identify the work mode that suits the WG best. 
Thanks.


Léonie.

On 05/07/2016 15:15, Chaals McCathie Nevile wrote:

This is a call for consensus on the proposition:

Publish the current editors' draft of HTML 5.2 -
https://w3c.github.io/html/ - as a First Public Working Draft.

Silence will be considered assent, but positive responses are preferred.
In an effort to find a smoother way to assess consensus, there are three
possible mechanisms for feedback, and you should pick the one you find
most convenient:

You can provide a response in this email thread.

You can provide a comment or thumbs-up in the issue in the HTML repo -
https://github.com/w3c/html/issues/515

You can provide a comment or thumbs-up in the issue in the WebPlatformWG
repo - https://github.com/w3c/WebPlatformWG/issues/43

There is no need to use more than one of these mechanisms, as the chairs
will collate the results.

If many people use the issues instead of email, we will likely propose a
change to the work mode for assessing consensus.

There will be a separate thread on the merits of any procedural change -
please *only* reply to this thread to support or oppose the FPWD
publication.

cheers

Chaals, for the chairs

RE: Quick update on WebIDL "Level 1"

[Marcos Caceres]

On July 9, 2016 at 6:24:56 AM, Domenic Denicola (d...@domenic.me) wrote:
> From: Travis Leithead [mailto:travis.leith...@microsoft.com]
>
> > The purpose of the “Level 1” document is to serve as a stable reference for 
> > W3C specs that
> link to WebIDL. It contains a subset of the WebIDL syntax that is considered 
> stable (as
> verified by interoperable tests). Implementations should not use the Level 1 
> document
> as a guide, but instead track changes to the editors draft. We expect to 
> follow-up Level
> 1 with a Level 2 as additional editor’s draft syntax and behavior stabilizes, 
> are implemented
> as part of other specs, and shown to be interoperable.
>
> Why is it acceptable for specs to reference a version of Web IDL that nobody 
> should implement?

This is a totally valid question, but we've had this debate 1001
times. Perhaps a better question is: how can we get patent protection
(making this subset of WebIDL royalty free for society), but without
harming the ecosystem by confusing implementers and developers by
publishing on the "/TRash" space (as most of us now unfortunately
referring to it).

We need a way to clearly indicate that, for a subset of documents,
RECs on TR represent a royalty free set of ideas (as kindly and
honorably granted by the W3C Membership) - and should only be referred
to by patent lawyers and government officials. That it's for those
groups should be stated and promoted proudly, not disparagingly. And,
that implementers should be looking at the living document instead.
The value of TR need not be diminished - in fact: it should be
correctly used to published the documents that enshrine the royalty
free status of particular specifications.

Perhaps we need a new space just for documents that represent and
agree to set of royalty free ideas? (i..e, if it's a REC, it does into
this new space - and gets clearly marked for the appropriate target
audience, which is not implementers or developers - but patent lawyers
and government officials)...

I think we've also had this debate 10001 times too... but we need to
do something folks, as the division between the forks and the reality
of how web specs are developed is hurting everyone :(

Kind regards,
Marcos

Re: Quick update on WebIDL "Level 1"

[Chaals McCathie Nevile]

On Fri, 08 Jul 2016 22:21:10 +0200, Domenic Denicola  wrote:


From: Travis Leithead [mailto:travis.leith...@microsoft.com]

The purpose of the “Level 1” document is to serve as a stable reference  
for W3C specs that link to WebIDL. It contains a subset of the WebIDL  
syntax that is considered stable (as verified by interoperable tests).  
Implementations should not use the Level 1 document as a guide, but  
instead track changes to the editors draft. We expect to follow-up  
Level 1 with a Level 2 as additional editor’s draft syntax and behavior  
stabilizes, are implemented as part of other specs, and shown to be  
interoperable.


Why is it acceptable for specs to reference a version of Web IDL that  
nobody should implement?


That's not what Travis describes. To restate his message above, the Level  
1 spec is "what people already implement". The Level 2 editor's draft is  
"what you should look at if you want to make a new implementation with all  
the new stuff - but be aware that some if it is up for debate and might  
change".


cheers

--
Charles McCathie Nevile - web standards - CTO Office, Yandex
 cha...@yandex-team.ru - - - Find more at http://yandex.com

Quick update on WebIDL "Level 1"

[Travis Leithead]

While editing work continues on the "second edition" of WebIDL here: 
http://heycam.github.io/webidl/, we have been fine-tuning the "Level 1" CR 
snapshot [1] to replace and supersede the 2012 version [2].

The "Level 1" editors are making final tweaks to the draft and tests, and hope 
to be ready to transition to Proposed Recommendation status by the end of July.

The purpose of the "Level 1" document is to serve as a stable reference for W3C 
specs that link to WebIDL. It contains a subset of the WebIDL syntax that is 
considered stable (as verified by interoperable tests). Implementations should 
not use the Level 1 document as a guide, but instead track changes to the 
editors draft. We expect to follow-up Level 1 with a Level 2 as additional 
editor's draft syntax and behavior stabilizes, are implemented as part of other 
specs, and shown to be interoperable.

-Travis & Yves

[1] https://cdn.rawgit.com/ylafon/webidl/post-cr/l1-respec.html
[2] http://www.w3.org/TR/WebIDL/

Re: Thank you Hallvord (looking for Clipboard API editor…)

[Grisha Lyukshin]

Hi Chaals,


I am interested.


I will little 'r' you for details.


Thank you.


--grisha


Sent from Outlook


From: Chaals McCathie Nevile 
Sent: Wednesday, July 06, 2016 3:24:12 PM
To: public-webapps WG
Subject: Thank you Hallvord (looking for Clipboard API editor…)

Dear all,

part of this mail is to thank Hallvord Steen for his efforts in this group
over a number of years. As a result of changed employment he is stepping
down as a member and in particular as editor of the Clipboard APIs
specification, which is just one part of the contribution he has made that
will be missed.

The other purpose of the mail is to note that we are therefore looking for
a new editor for Clipboard APIs. If anyone wants to do this, please let me
know and I will happily work with you if there is anything about editing a
W3C specification that you are not sure about.

Thank you Hallvord, all the best, and I hope we see you back in the
Working Group at some stage.

cheers

Chaals

--
Charles McCathie Nevile - web standards - CTO Office, Yandex
  cha...@yandex-team.ru - - - Find more at http://yandex.com

Thank you Hallvord (looking for Clipboard API editor…)

[Chaals McCathie Nevile]

Dear all,

part of this mail is to thank Hallvord Steen for his efforts in this group  
over a number of years. As a result of changed employment he is stepping  
down as a member and in particular as editor of the Clipboard APIs  
specification, which is just one part of the contribution he has made that  
will be missed.


The other purpose of the mail is to note that we are therefore looking for  
a new editor for Clipboard APIs. If anyone wants to do this, please let me  
know and I will happily work with you if there is anything about editing a  
W3C specification that you are not sure about.


Thank you Hallvord, all the best, and I hope we see you back in the  
Working Group at some stage.


cheers

Chaals

--
Charles McCathie Nevile - web standards - CTO Office, Yandex
 cha...@yandex-team.ru - - - Find more at http://yandex.com

Re: Call for Consensus: Publish HTML 5.2 FPWD?

[Richard Schwerdtfeger]

Hi Charles, 

I see this is designed to provide semantic-level scripting and markup for 
accessibility: "This specification is limited to providing a semantic-level 
markup language and associated semantic-level scripting APIs for authoring 
accessible pages on the Web ranging from static documents to dynamic 
applications.”

Can you point to sections on this in the FPWD?

Thanks,

Rich

> On Jul 5, 2016, at 9:15 AM, Chaals McCathie Nevile  
> wrote:
> 
> This is a call for consensus on the proposition:
> 
> Publish the current editors' draft of HTML 5.2 - https://w3c.github.io/html/ 
> - as a First Public Working Draft.
> 
> Silence will be considered assent, but positive responses are preferred. In 
> an effort to find a smoother way to assess consensus, there are three 
> possible mechanisms for feedback, and you should pick the one you find most 
> convenient:
> 
> You can provide a response in this email thread.
> 
> You can provide a comment or thumbs-up in the issue in the HTML repo - 
> https://github.com/w3c/html/issues/515
> 
> You can provide a comment or thumbs-up in the issue in the WebPlatformWG repo 
> - https://github.com/w3c/WebPlatformWG/issues/43
> 
> There is no need to use more than one of these mechanisms, as the chairs will 
> collate the results.
> 
> If many people use the issues instead of email, we will likely propose a 
> change to the work mode for assessing consensus.
> 
> There will be a separate thread on the merits of any procedural change - 
> please *only* reply to this thread to support or oppose the FPWD publication.
> 
> cheers
> 
> Chaals, for the chairs
> 
> -- 
> Charles McCathie Nevile - web standards - CTO Office, Yandex
> cha...@yandex-team.ru - - - Find more at http://yandex.com
> 

Call for Consensus: Publish HTML 5.2 FPWD?

[Chaals McCathie Nevile]

This is a call for consensus on the proposition:

Publish the current editors' draft of HTML 5.2 -  
https://w3c.github.io/html/ - as a First Public Working Draft.


Silence will be considered assent, but positive responses are preferred.  
In an effort to find a smoother way to assess consensus, there are three  
possible mechanisms for feedback, and you should pick the one you find  
most convenient:


You can provide a response in this email thread.

You can provide a comment or thumbs-up in the issue in the HTML repo -  
https://github.com/w3c/html/issues/515


You can provide a comment or thumbs-up in the issue in the WebPlatformWG  
repo - https://github.com/w3c/WebPlatformWG/issues/43


There is no need to use more than one of these mechanisms, as the chairs  
will collate the results.


If many people use the issues instead of email, we will likely propose a  
change to the work mode for assessing consensus.


There will be a separate thread on the merits of any procedural change -  
please *only* reply to this thread to support or oppose the FPWD  
publication.


cheers

Chaals, for the chairs

--
Charles McCathie Nevile - web standards - CTO Office, Yandex
 cha...@yandex-team.ru - - - Find more at http://yandex.com

Re: CFC: Republish Pointer Lock as CR

[Léonie Watson]

On 21/06/2016 13:14, Léonie Watson wrote:

Important: This CFC is extended for 48 hours. Please provide comments by
end of day on Thursday 23^rd June 2016.


With thanks to those who responded, this CFC passes. We will begin the 
process of transitioning Pointer Lock to CR.


Léonie.

--
@LeonieWatson tink.uk Carpe diem

RE: CFC: Republish Pointer Lock as CR

[Léonie Watson]

From: Léonie Watson [mailto:t...@tink.uk] 
Sent: 21 June 2016 11:18

Yes, CR requires at least two implementations in shipping browsers. Once 
Pointer Lock is at Recc, hopefully the Shadow DOM content will be stable enough 
to include in Pointer Lock next.

 

Correction: A CR doesn’t require 2+ implementations, but we do have to 
demonstrate that the spec has received wide review. The implementations are 
needed to exit CR as we move to PR though. Sorry, my fault for not paying 
attention!

 

We plan to move Pointer Lock to CR, then to Recc within a few weeks. It seems 
like the most painless way to do things.

 

The alternative was to include the Shadow DOM features but mark them as “at 
risk” during the CR. Given that Shadow DOM is still not stable, it’s likely 
we’d have to take those features out again for PR – which seems like extra work 
for the editor.

 

Instead we encourage the editors to publish a WD of Pointer Lock 2 as soon as 
there is concensus on the Shadow DOM content.

 

 

 

HTH

Léonie.

RE: CFC: Republish Pointer Lock as CR

[Léonie Watson]

 

 

From: Takayoshi Kochi [mailto:ko...@google.com] 
“I'm fine without Shadow DOM changes, because no one yet implemented the 
intended change to the spec yet,

and so it could be immature to include in a "CR".   (Does CR require at least 2 
implementors exist?)”

 

Yes, CR requires at least two implementations in shipping browsers. Once 
Pointer Lock is at Recc, hopefully the Shadow DOM content will be stable enough 
to include in Pointer Lock next.

 

 

Thanks for your help with this.

 

 

 

-- 

@LeonieWatson tink.uk Carpe diem

 

Léonie.

RE: CFC: Republish Pointer Lock as CR

[Léonie Watson]

Important: This CFC is extended for 48 hours. Please provide comments by end of 
day on Thursday 23rd June 2016.

 

From: Vincent Scheib [mailto:sch...@google.com] 
Sent: 21 June 2016 05:09
“I've discussed more with Xiaoqian and Léonie and support a CR now with this 
proposal:

 

Move to a CR for the v1 Pointer Lock specification without Shadow DOM changes, 
and a note on accessibility. Implementations are nearly consistent for v1 and 
it can move to a published status sooner. We can follow up with a v2 requiring 
more implementation work afterwards.”

 

Thanks Vincent.

 

Per the note above, this CFC [1] is extended for 48 hours to give WG members 
more time to respond now we have clarified the path.

 

Léonie.

[1] https://lists.w3.org/Archives/Public/public-webapps/2016AprJun/0127.html 

 

 

 

-- 

@LeonieWatson tink.uk Carpe diem

 

 

Re: CFC: Republish Pointer Lock as CR

[Takayoshi Kochi]

I'm fine without Shadow DOM changes, because no one yet implemented the
intended change to the spec yet,
and so it could be immature to include in a "CR".   (Does CR require at
least 2 implementors exist?)

On Tue, Jun 21, 2016 at 1:09 PM, Vincent Scheib  wrote:

> I've discussed more with Xiaoqian and Léonie and support a CR now with
> this proposal:
>
> Move to a CR for the v1 Pointer Lock specification without Shadow DOM
> changes, and a note on accessibility. Implementations are nearly consistent
> for v1 and it can move to a published status sooner. We can follow up with
> a v2 requiring more implementation work afterwards.
>
>


-- 
Takayoshi Kochi

Re: CFC: Republish Pointer Lock as CR

[Vincent Scheib]

I've discussed more with Xiaoqian and Léonie and support a CR now with this
proposal:

Move to a CR for the v1 Pointer Lock specification without Shadow DOM
changes, and a note on accessibility. Implementations are nearly consistent
for v1 and it can move to a published status sooner. We can follow up with
a v2 requiring more implementation work afterwards.

[selectors-api] typo in specification

[Kirill Topolyan]

Hello.

At the moment I'm translating "Selectors API Level 1" [1] and it seems I have 
noticed a typo in the original document.

[1] https://www.w3.org/TR/selectors-api/

Section 6.4:
"If result is invalid ([SELECT], section 12), raisea a SYNTAX_ERR exception 
([DOM-LEVEL-3-CORE], section 1.4) and abort this algorithm."

Probably it meant "raise a SYNTAX_ERR" instead "raisea a SYNTAX_ERR"?

Best regards,
Kirill, http://topolyan.com/

RE: CFC: Republish Pointer Lock as CR

[Léonie Watson]

 

 

From: Vincent Scheib [mailto:sch...@google.com] 
Sent: 16 June 2016 12:34
“An accessibility review and handling of this [accessibility issue #1] are 
still needed and will likely cause a CR cycle. To avoid unnecessary work I 
propose CR to be deferred until that work is complete.”

 

I think the issue can be resolved with an informative note in the spec. It’s a 
question of what the browser does in accessibility terms once a 
pointerlockchange event has been fired.

 

Will post this to the GH issue in a moment… but don’t believe this should hold 
up the CFC.

 

Léonie.

 

 

 

 

[accessibility issue #1] https://github.com/w3c/pointerlock/issues/1

 

On Tue, Jun 14, 2016 at 2:57 PM, Dylan Barrell  > wrote:

abstain

 

On Tue, Jun 14, 2016 at 1:47 AM, Michiel Bijl  > wrote:

Looks good, +1


—Michiel

 

On 13 Jun 2016, at 18:12, Léonie Watson  > 
wrote:

 

Hello WP,

This is a Call For Consensus (CFC) to request that W3C republish Pointer
Lock as a Candidate Recommendation (CR). Extensions to the MouseEventInit
Dictionary [1] constitute substantive changes to the specification that were
made after the current CR was published in 2013 [2].

Please reply to this CFC no later than 21st June 2016. Positive responses
are preferred and supporting comments (beyond just +1) are encouraged, but
silence will be considered as consent.

Thank you.

Léonie on behalf of the WP chairs and team, and Pointer Lock editor.
[1]
https://w3c.github.io/pointerlock/#extensions-to-the-mouseeventinit-dictiona
ry 
[2] http://www.w3.org/TR/2013/CR-pointerlock-20131217/ 
-- 
@LeonieWatson tink.uk   Carpe diem




 





 

-- 

Download the aXe browser extension for free:

 

Firefox: https://addons.mozilla.org/en-US/firefox/addon/axe-devtools

Chrome: 
https://chrome.google.com/webstore/detail/axe/lhdoppojpmngadmnindnejefpokejbdd?hl=en-US

 

Life is ten percent what happens to you and ninety percent how you respond to 
it. - Lou Holtz

 

 

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

[Michiel Bijl]

Woohoo!

—Michiel

> On 13 Jun 2016, at 18:11, Léonie Watson  wrote:
> 
> Hello WP,
> 
> This CFC passed with many expressions of support. Thank you to everyone who
> responded and gave feedback.
> 
> Léonie on behalf of the WP chairs and team, and HTML editors
> 
> 
>> -Original Message-
>> From: Léonie Watson [mailto:t...@tink.uk]
>> Sent: 02 June 2016 13:48
>> To: 'public-webapps WG' 
>> Subject: 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 on 10 June. Positive responses are preferred and encouraged, silence
>> will be considered as assent.
>> 
>> The current HTML5.1 WD [1] improves upon HTML5. It includes updates that
>> make it more reliable, more readable and understandable, and a better
>> match for reality. Substantial changes between HTML5 and HTML5.1 can be
>> found in the spec [2].
>> 
>> When a specification moves to CR it triggers a Call For Exclusions, per
> section
>> 4 of the W3C Patent Policy [3]. No substantive additions can be made to a
>> specification in CR without starting a new Call for Exclusions, so we will
> put
>> HTML5.1 into "feature freeze". It is possible to make editorial updates as
>> necessary, and features marked "At Risk" may be removed if found not to be
>> interoperable.
>> 
>> The following features are considered "at risk". If we cannot identify at
> least
>> two shipping implementations, they will be marked "at risk" in the CR and
>> may be removed from the Proposed Recommendation.
>> 
>> keygen element. [issue 43]
>> label as a reassociatable element [issue 109] Fixing requestAnimationFrame
>> to 60Hz, not implementation-defined [issues 159/375/422]
>> registerContentHandler [Issue 233] inputmode attribute of the input
>> element [issue 269] autofill of form elements [issue 372] menu, menuitem
>> and context menus. [issue 373] dialog element [issue 427] Text tracks
>> exposing in-band metadata best practices [Issue 461] datetime and
>> datatime-local states of the input element [Issue 462]
>> 
>> Please share implementation details for any of these features on Github.
> To
>> mark other features "at risk", please identify them by 10th June (ideally
> by
>> filing an issue and providing a test case).
>> 
>> At the same time we move HTML5.1 into CR, we plan to continue updating
>> the Editor's Draft, and in the next few weeks we expect to post a Call for
>> Consensus to publish it as the First Public Working Draft of HTML5.2, so
>> improving HTML will continue without a pause. It also means that changes
>> that didn't make it into
>> HTML5.1 will not have long to wait before being incorporated into the
>> specification.
>> 
>> Léonie on behalf of the WP chairs and team, and HTML editors.
>> [1] https://www.w3.org/TR/html51/
>> [2] https://www.w3.org/TR/html51/changes.html#changes
>> [3] https://www.w3.org/Consortium/Patent-Policy-20040205/#sec-Exclusion
>> 
>> [issue 43] https://github.com/w3c/html/issues/43
>> [issue 109] https://github.com/w3c/html/issues/109
>> [issues 159/375/422] https://github.com/w3c/html/issues/159 and links
>> [issue 233] https://github.com/w3c/html/issues/233
>> [issue 269] https://github.com/w3c/html/issues/269
>> [issue 372] https://github.com/w3c/html/issues/372
>> [issue 373] https://github.com/w3c/html/issues/373
>> [issue 427] https://github.com/w3c/html/issues/427
>> [Issue 461] https://github.com/w3c/html/issues/461
>> [Issue 462] https://github.com/w3c/html/issues/462
>> 
>> 
>> --
>> @LeonieWatson tink.uk Carpe diem
>> 
>> 
>> 
> 
> 
> 

Re: CFC: Republish Pointer Lock as CR

[Takayoshi Kochi]

I'm working on updating text to incorporate Shadow DOM in pointer lock
spec.
https://github.com/w3c/webcomponents/issues/192

On Thu, Jun 16, 2016 at 2:06 PM, Vincent Scheib  wrote:

> Shadow dom concepts will also be incorporated.
>
> On Thu, Jun 16, 2016 at 1:43 PM, Chaals McCathie Nevile <
> cha...@yandex-team.ru> wrote:
>
>> On Thu, 16 Jun 2016 12:33:30 +0200, Vincent Scheib 
>> wrote:
>>
>> An accessibility review and handling of this [accessibility issue #1] are
>>> still needed and will likely cause a CR cycle. To avoid unnecessary work
>>> I propose CR to be deferred until that work is complete.
>>>
>>> [accessibility issue #1] https://github.com/w3c/pointerlock/issues/1
>>>
>>
>> Agreed, that makes good sense. I'll try to help that get done as fast as
>> we can.
>>
>> cheers
>>
>>
>> On Tue, Jun 14, 2016 at 2:57 PM, Dylan Barrell 
>>> wrote:
>>>
>>> abstain

 On Tue, Jun 14, 2016 at 1:47 AM, Michiel Bijl 
 wrote:

 Looks good, +1
>
> —Michiel
>
> On 13 Jun 2016, at 18:12, Léonie Watson  wrote:
>
> Hello WP,
>
> This is a Call For Consensus (CFC) to request that W3C republish
> Pointer
> Lock as a Candidate Recommendation (CR). Extensions to the
> MouseEventInit
> Dictionary [1] constitute substantive changes to the specification that
> were
> made after the current CR was published in 2013 [2].
>
> Please reply to this CFC no later than 21st June 2016. Positive
> responses
> are preferred and supporting comments (beyond just +1) are encouraged,
> but
> silence will be considered as consent.
>
> Thank you.
>
> Léonie on behalf of the WP chairs and team, and Pointer Lock editor.
> [1]
>
>
> https://w3c.github.io/pointerlock/#extensions-to-the-mouseeventinit-dictiona
> ry
> [2] http://www.w3.org/TR/2013/CR-pointerlock-20131217/
> --
> @LeonieWatson tink.uk Carpe diem
>
>
>
>
>
>

 --
 Download the aXe browser extension for free:

 Firefox: https://addons.mozilla.org/en-US/firefox/addon/axe-devtools
 Chrome:

 https://chrome.google.com/webstore/detail/axe/lhdoppojpmngadmnindnejefpokejbdd?hl=en-US

 Life is ten percent what happens to you and ninety percent how you
 respond
 to it. - Lou Holtz



>>
>> --
>> Charles McCathie Nevile - web standards - CTO Office, Yandex
>>  cha...@yandex-team.ru - - - Find more at http://yandex.com
>>
>>
>


-- 
Takayoshi Kochi

Re: CFC: Republish Pointer Lock as CR

[Vincent Scheib]

Shadow dom concepts will also be incorporated.

On Thu, Jun 16, 2016 at 1:43 PM, Chaals McCathie Nevile <
cha...@yandex-team.ru> wrote:

> On Thu, 16 Jun 2016 12:33:30 +0200, Vincent Scheib 
> wrote:
>
> An accessibility review and handling of this [accessibility issue #1] are
>> still needed and will likely cause a CR cycle. To avoid unnecessary work
>> I propose CR to be deferred until that work is complete.
>>
>> [accessibility issue #1] https://github.com/w3c/pointerlock/issues/1
>>
>
> Agreed, that makes good sense. I'll try to help that get done as fast as
> we can.
>
> cheers
>
>
> On Tue, Jun 14, 2016 at 2:57 PM, Dylan Barrell 
>> wrote:
>>
>> abstain
>>>
>>> On Tue, Jun 14, 2016 at 1:47 AM, Michiel Bijl  wrote:
>>>
>>> Looks good, +1

 —Michiel

 On 13 Jun 2016, at 18:12, Léonie Watson  wrote:

 Hello WP,

 This is a Call For Consensus (CFC) to request that W3C republish Pointer
 Lock as a Candidate Recommendation (CR). Extensions to the
 MouseEventInit
 Dictionary [1] constitute substantive changes to the specification that
 were
 made after the current CR was published in 2013 [2].

 Please reply to this CFC no later than 21st June 2016. Positive
 responses
 are preferred and supporting comments (beyond just +1) are encouraged,
 but
 silence will be considered as consent.

 Thank you.

 Léonie on behalf of the WP chairs and team, and Pointer Lock editor.
 [1]


 https://w3c.github.io/pointerlock/#extensions-to-the-mouseeventinit-dictiona
 ry
 [2] http://www.w3.org/TR/2013/CR-pointerlock-20131217/
 --
 @LeonieWatson tink.uk Carpe diem






>>>
>>> --
>>> Download the aXe browser extension for free:
>>>
>>> Firefox: https://addons.mozilla.org/en-US/firefox/addon/axe-devtools
>>> Chrome:
>>>
>>> https://chrome.google.com/webstore/detail/axe/lhdoppojpmngadmnindnejefpokejbdd?hl=en-US
>>>
>>> Life is ten percent what happens to you and ninety percent how you
>>> respond
>>> to it. - Lou Holtz
>>>
>>>
>>>
>
> --
> Charles McCathie Nevile - web standards - CTO Office, Yandex
>  cha...@yandex-team.ru - - - Find more at http://yandex.com
>
>

Re: CFC: Republish Pointer Lock as CR

[Chaals McCathie Nevile]

On Thu, 16 Jun 2016 12:33:30 +0200, Vincent Scheib   
wrote:



An accessibility review and handling of this [accessibility issue #1] are
still needed and will likely cause a CR cycle. To avoid unnecessary work  
I propose CR to be deferred until that work is complete.


[accessibility issue #1] https://github.com/w3c/pointerlock/issues/1


Agreed, that makes good sense. I'll try to help that get done as fast as  
we can.


cheers


On Tue, Jun 14, 2016 at 2:57 PM, Dylan Barrell 
wrote:


abstain

On Tue, Jun 14, 2016 at 1:47 AM, Michiel Bijl  wrote:


Looks good, +1

—Michiel

On 13 Jun 2016, at 18:12, Léonie Watson  wrote:

Hello WP,

This is a Call For Consensus (CFC) to request that W3C republish  
Pointer
Lock as a Candidate Recommendation (CR). Extensions to the  
MouseEventInit

Dictionary [1] constitute substantive changes to the specification that
were
made after the current CR was published in 2013 [2].

Please reply to this CFC no later than 21st June 2016. Positive  
responses
are preferred and supporting comments (beyond just +1) are encouraged,  
but

silence will be considered as consent.

Thank you.

Léonie on behalf of the WP chairs and team, and Pointer Lock editor.
[1]

https://w3c.github.io/pointerlock/#extensions-to-the-mouseeventinit-dictiona
ry
[2] http://www.w3.org/TR/2013/CR-pointerlock-20131217/
--
@LeonieWatson tink.uk Carpe diem








--
Download the aXe browser extension for free:

Firefox: https://addons.mozilla.org/en-US/firefox/addon/axe-devtools
Chrome:
https://chrome.google.com/webstore/detail/axe/lhdoppojpmngadmnindnejefpokejbdd?hl=en-US

Life is ten percent what happens to you and ninety percent how you  
respond

to it. - Lou Holtz





--
Charles McCathie Nevile - web standards - CTO Office, Yandex
 cha...@yandex-team.ru - - - Find more at http://yandex.com

Re: CFC: Republish Pointer Lock as CR

[Vincent Scheib]

An accessibility review and handling of this [accessibility issue #1] are
still needed and will likely cause a CR cycle. To avoid unnecessary work I
propose CR to be deferred until that work is complete.

[accessibility issue #1] https://github.com/w3c/pointerlock/issues/1

On Tue, Jun 14, 2016 at 2:57 PM, Dylan Barrell 
wrote:

> abstain
>
> On Tue, Jun 14, 2016 at 1:47 AM, Michiel Bijl  wrote:
>
>> Looks good, +1
>>
>> —Michiel
>>
>> On 13 Jun 2016, at 18:12, Léonie Watson  wrote:
>>
>> Hello WP,
>>
>> This is a Call For Consensus (CFC) to request that W3C republish Pointer
>> Lock as a Candidate Recommendation (CR). Extensions to the MouseEventInit
>> Dictionary [1] constitute substantive changes to the specification that
>> were
>> made after the current CR was published in 2013 [2].
>>
>> Please reply to this CFC no later than 21st June 2016. Positive responses
>> are preferred and supporting comments (beyond just +1) are encouraged, but
>> silence will be considered as consent.
>>
>> Thank you.
>>
>> Léonie on behalf of the WP chairs and team, and Pointer Lock editor.
>> [1]
>>
>> https://w3c.github.io/pointerlock/#extensions-to-the-mouseeventinit-dictiona
>> ry
>> [2] http://www.w3.org/TR/2013/CR-pointerlock-20131217/
>> --
>> @LeonieWatson tink.uk Carpe diem
>>
>>
>>
>>
>>
>
>
> --
> Download the aXe browser extension for free:
>
> Firefox: https://addons.mozilla.org/en-US/firefox/addon/axe-devtools
> Chrome:
> https://chrome.google.com/webstore/detail/axe/lhdoppojpmngadmnindnejefpokejbdd?hl=en-US
>
> Life is ten percent what happens to you and ninety percent how you respond
> to it. - Lou Holtz
>
>

Re: [Service Workers] meeting july/august?

[Ben Kelly]

On Thu, May 26, 2016 at 4:59 PM, Ben Kelly  wrote:

> 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 current plan is:
>
>   July 28, 29
>   Mozilla office in Toronto
>
> The w3c/webplatformwg page for the meeting should be up soon.
>

FYI, the meeting page is available here:

https://github.com/w3c/WebPlatformWG/blob/gh-pages/meetings/16-07-28-29SW.md

Sorry I forgot to post the link once it went live.

Ben

Re: CFC: Republish Pointer Lock as CR

[Dylan Barrell]

abstain

On Tue, Jun 14, 2016 at 1:47 AM, Michiel Bijl  wrote:

> Looks good, +1
>
> —Michiel
>
> On 13 Jun 2016, at 18:12, Léonie Watson  wrote:
>
> Hello WP,
>
> This is a Call For Consensus (CFC) to request that W3C republish Pointer
> Lock as a Candidate Recommendation (CR). Extensions to the MouseEventInit
> Dictionary [1] constitute substantive changes to the specification that
> were
> made after the current CR was published in 2013 [2].
>
> Please reply to this CFC no later than 21st June 2016. Positive responses
> are preferred and supporting comments (beyond just +1) are encouraged, but
> silence will be considered as consent.
>
> Thank you.
>
> Léonie on behalf of the WP chairs and team, and Pointer Lock editor.
> [1]
>
> https://w3c.github.io/pointerlock/#extensions-to-the-mouseeventinit-dictiona
> ry
> [2] http://www.w3.org/TR/2013/CR-pointerlock-20131217/
> --
> @LeonieWatson tink.uk Carpe diem
>
>
>
>
>


-- 
Download the aXe browser extension for free:

Firefox: https://addons.mozilla.org/en-US/firefox/addon/axe-devtools
Chrome:
https://chrome.google.com/webstore/detail/axe/lhdoppojpmngadmnindnejefpokejbdd?hl=en-US

Life is ten percent what happens to you and ninety percent how you respond
to it. - Lou Holtz

Re: CFC: Republish Pointer Lock as CR

[Michiel Bijl]

Looks good, +1

—Michiel

> On 13 Jun 2016, at 18:12, Léonie Watson  wrote:
> 
> Hello WP,
> 
> This is a Call For Consensus (CFC) to request that W3C republish Pointer
> Lock as a Candidate Recommendation (CR). Extensions to the MouseEventInit
> Dictionary [1] constitute substantive changes to the specification that were
> made after the current CR was published in 2013 [2].
> 
> Please reply to this CFC no later than 21st June 2016. Positive responses
> are preferred and supporting comments (beyond just +1) are encouraged, but
> silence will be considered as consent.
> 
> Thank you.
> 
>   Léonie on behalf of the WP chairs and team, and Pointer Lock editor.
> [1]
> https://w3c.github.io/pointerlock/#extensions-to-the-mouseeventinit-dictiona
> ry 
> [2] http://www.w3.org/TR/2013/CR-pointerlock-20131217/ 
> -- 
> @LeonieWatson tink.uk Carpe diem
> 
> 
> 

Re: [clipboard] Add RTF to the "mandatory data types" list?

[Hallvord Reiar Michaelsen Steen]

On Mon, Apr 20, 2015 at 11:01 PM James M. Greene 
wrote:

>> That behavior is really all I wanted, i.e. "don't let the browser
>> discard/ignore valid RTF clipboard data".

On Wed, May 6, 2015 at 8:18 PM, Daniel Cheng  wrote:
> I don't think I would feel comfortable with allowing web pages to place
> unsanitized RTF in the system clipboard. This would allow webapps to trigger
> exploits such as CVE-2014-1761.

Just to conclude here: I've been convinced that the possibility of
targeting exploits at local applications are too severe to allow JS to
write stuff labelled as RTF to clipboards. The plan is that RTF will
be considered a "custom" type so scripts can set (and get) RTF data,
but native applications will not see said data if they look for "RTF"
content on the clipboard.

I have not entirely made up my mind on how exposing RTF that other
applications have written to the clipboard to JS will work (the
"paste" / "read from clipboard" use case), but I think we'll just
expose it as usual in the items list with the RTF MIME type.
-Hallvord

RE: Republish Pointer Lock as CR

[Travis Leithead]

+1 in favor of supporting a republishing as CR.

-Original Message-
From: Léonie Watson [mailto:t...@tink.uk] 
Sent: Monday, June 13, 2016 9:13 AM
To: 'public-webapps WG' 
Subject: CFC: Republish Pointer Lock as CR

Hello WP,

This is a Call For Consensus (CFC) to request that W3C republish Pointer Lock 
as a Candidate Recommendation (CR). Extensions to the MouseEventInit Dictionary 
[1] constitute substantive changes to the specification that were made after 
the current CR was published in 2013 [2].

Please reply to this CFC no later than 21st June 2016. Positive responses are 
preferred and supporting comments (beyond just +1) are encouraged, but silence 
will be considered as consent.

Thank you.

Léonie on behalf of the WP chairs and team, and Pointer Lock editor.
[1] 
https://w3c.github.io/pointerlock/#extensions-to-the-mouseeventinit-dictionary
[2] http://www.w3.org/TR/2013/CR-pointerlock-20131217/
--
@LeonieWatson tink.uk Carpe diem

CFC: Republish Pointer Lock as CR

[Léonie Watson]

Hello WP,

This is a Call For Consensus (CFC) to request that W3C republish Pointer
Lock as a Candidate Recommendation (CR). Extensions to the MouseEventInit
Dictionary [1] constitute substantive changes to the specification that were
made after the current CR was published in 2013 [2].

Please reply to this CFC no later than 21st June 2016. Positive responses
are preferred and supporting comments (beyond just +1) are encouraged, but
silence will be considered as consent.

Thank you.

Léonie on behalf of the WP chairs and team, and Pointer Lock editor.
[1]
https://w3c.github.io/pointerlock/#extensions-to-the-mouseeventinit-dictiona
ry 
[2] http://www.w3.org/TR/2013/CR-pointerlock-20131217/ 
-- 
@LeonieWatson tink.uk Carpe diem

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

[Léonie Watson]

Hello WP,

This CFC passed with many expressions of support. Thank you to everyone who
responded and gave feedback.

Léonie on behalf of the WP chairs and team, and HTML editors


> -Original Message-
> From: Léonie Watson [mailto:t...@tink.uk]
> Sent: 02 June 2016 13:48
> To: 'public-webapps WG' 
> Subject: 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 on 10 June. Positive responses are preferred and encouraged, silence
> will be considered as assent.
> 
> The current HTML5.1 WD [1] improves upon HTML5. It includes updates that
> make it more reliable, more readable and understandable, and a better
> match for reality. Substantial changes between HTML5 and HTML5.1 can be
> found in the spec [2].
> 
> When a specification moves to CR it triggers a Call For Exclusions, per
section
> 4 of the W3C Patent Policy [3]. No substantive additions can be made to a
> specification in CR without starting a new Call for Exclusions, so we will
put
> HTML5.1 into "feature freeze". It is possible to make editorial updates as
> necessary, and features marked "At Risk" may be removed if found not to be
> interoperable.
> 
> The following features are considered "at risk". If we cannot identify at
least
> two shipping implementations, they will be marked "at risk" in the CR and
> may be removed from the Proposed Recommendation.
> 
> keygen element. [issue 43]
> label as a reassociatable element [issue 109] Fixing requestAnimationFrame
> to 60Hz, not implementation-defined [issues 159/375/422]
> registerContentHandler [Issue 233] inputmode attribute of the input
> element [issue 269] autofill of form elements [issue 372] menu, menuitem
> and context menus. [issue 373] dialog element [issue 427] Text tracks
> exposing in-band metadata best practices [Issue 461] datetime and
> datatime-local states of the input element [Issue 462]
> 
> Please share implementation details for any of these features on Github.
To
> mark other features "at risk", please identify them by 10th June (ideally
by
> filing an issue and providing a test case).
> 
> At the same time we move HTML5.1 into CR, we plan to continue updating
> the Editor's Draft, and in the next few weeks we expect to post a Call for
> Consensus to publish it as the First Public Working Draft of HTML5.2, so
> improving HTML will continue without a pause. It also means that changes
> that didn't make it into
> HTML5.1 will not have long to wait before being incorporated into the
> specification.
> 
> Léonie on behalf of the WP chairs and team, and HTML editors.
> [1] https://www.w3.org/TR/html51/
> [2] https://www.w3.org/TR/html51/changes.html#changes
> [3] https://www.w3.org/Consortium/Patent-Policy-20040205/#sec-Exclusion
> 
> [issue 43] https://github.com/w3c/html/issues/43
> [issue 109] https://github.com/w3c/html/issues/109
> [issues 159/375/422] https://github.com/w3c/html/issues/159 and links
> [issue 233] https://github.com/w3c/html/issues/233
> [issue 269] https://github.com/w3c/html/issues/269
> [issue 372] https://github.com/w3c/html/issues/372
> [issue 373] https://github.com/w3c/html/issues/373
> [issue 427] https://github.com/w3c/html/issues/427
> [Issue 461] https://github.com/w3c/html/issues/461
> [Issue 462] https://github.com/w3c/html/issues/462
> 
> 
> --
> @LeonieWatson tink.uk Carpe diem
> 
> 
> 

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

[Alexander Schmitz]

+1
Alexander Schmitz
jQuery Foundation


On Mon, Jun 6, 2016 at 8:31 AM, Ian Pouncey  wrote:
> +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.
>>
>> Please reply to this thread on public-webapps@w3.org  no later than end of
>> day on 10 June. Positive responses are preferred and encouraged, silence
>> will be considered as assent.
>>
>> The current HTML5.1 WD [1] improves upon HTML5. It includes updates that
>> make it more reliable, more readable and understandable, and a better
>> match
>> for reality. Substantial changes between HTML5 and HTML5.1 can be found in
>> the spec [2].
>>
>> When a specification moves to CR it triggers a Call For Exclusions, per
>> section 4 of the W3C Patent Policy [3]. No substantive additions can be
>> made
>> to a specification in CR without starting a new Call for Exclusions, so we
>> will put HTML5.1 into "feature freeze". It is possible to make editorial
>> updates as necessary, and features marked "At Risk" may be removed if
>> found
>> not to be interoperable.
>>
>> The following features are considered "at risk". If we cannot identify at
>> least two shipping implementations, they will be marked "at risk" in the
>> CR
>> and may be removed from the Proposed Recommendation.
>>
>> keygen element. [issue 43]
>> label as a reassociatable element [issue 109]
>> Fixing requestAnimationFrame to 60Hz, not implementation-defined [issues
>> 159/375/422]
>> registerContentHandler [Issue 233]
>> inputmode attribute of the input element [issue 269]
>> autofill of form elements [issue 372]
>> menu, menuitem and context menus. [issue 373]
>> dialog element [issue 427]
>> Text tracks exposing in-band metadata best practices [Issue 461]
>> datetime and datatime-local states of the input element [Issue 462]
>>
>> Please share implementation details for any of these features on Github.
>> To
>> mark other features "at risk", please identify them by 10th June (ideally
>> by
>> filing an issue and providing a test case).
>>
>> At the same time we move HTML5.1 into CR, we plan to continue updating the
>> Editor's Draft, and in the next few weeks we expect to post a Call for
>> Consensus to publish it as the First Public Working Draft of HTML5.2, so
>> improving HTML will continue without a pause. It also means that changes
>> that didn't make it into
>> HTML5.1 will not have long to wait before being incorporated into the
>> specification.
>>
>> Léonie on behalf of the WP chairs and team, and HTML editors.
>> [1] https://www.w3.org/TR/html51/
>> [2] https://www.w3.org/TR/html51/changes.html#changes
>> [3] https://www.w3.org/Consortium/Patent-Policy-20040205/#sec-Exclusion
>>
>> [issue 43] https://github.com/w3c/html/issues/43
>> [issue 109] https://github.com/w3c/html/issues/109
>> [issues 159/375/422] https://github.com/w3c/html/issues/159 and links
>> [issue
>> 233] https://github.com/w3c/html/issues/233
>> [issue 269] https://github.com/w3c/html/issues/269
>> [issue 372] https://github.com/w3c/html/issues/372
>> [issue 373] https://github.com/w3c/html/issues/373
>> [issue 427] https://github.com/w3c/html/issues/427
>> [Issue 461] https://github.com/w3c/html/issues/461
>> [Issue 462] https://github.com/w3c/html/issues/462
>>
>>
>> --
>> @LeonieWatson tink.uk Carpe diem
>>
>>
>>
>>
>

[clipboard][DnD][DataTransfer] custom types and security

[Hallvord Reiar Michaelsen Steen]

Hi public-webapps, or the sub-set of your that are interested in
clipboard and DnD stuff: we've started an interesting thread regarding
DataTransfer, custom types and security here

https://github.com/whatwg/html/issues/1244

and implementor input is especially welcome. Allow me to paste parts
of my last comment, explaining a tricky issue I'd like a wider review
of:

Regarding the custom types: obviously, if we want to enable
interoperability between the same web apps running in different
browser engines, we need to spec a shared clipboard format for custom
data. This implies that other native software will also see a "Web
browser custom data" clipboard entry (by any description after some
bikeshedding) and potentially grow features that start making use of
said "Web browser custom data" on paste/drop.

If this is considered an extremely rare use case we should not cater
for, and custom data on the real OS clipboard is considered too risky,
we can of course spec that the browsers should keep custom data
somewhere internally and augment the DataTransfer object with the
internally stored custom data as if it were on the clipboard on the
next paste (unless the OS clipboard's contents changed meanwhile).
This seems harder to test and harder to get right, but it is a
judgement call.

-Hallvord

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

[Ian Pouncey]

+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.
>
> Please reply to this thread on public-webapps@w3.org  no later than end of
> day on 10 June. Positive responses are preferred and encouraged, silence
> will be considered as assent.
>
> The current HTML5.1 WD [1] improves upon HTML5. It includes updates that
> make it more reliable, more readable and understandable, and a better match
> for reality. Substantial changes between HTML5 and HTML5.1 can be found in
> the spec [2].
>
> When a specification moves to CR it triggers a Call For Exclusions, per
> section 4 of the W3C Patent Policy [3]. No substantive additions can be
> made
> to a specification in CR without starting a new Call for Exclusions, so we
> will put HTML5.1 into "feature freeze". It is possible to make editorial
> updates as necessary, and features marked "At Risk" may be removed if found
> not to be interoperable.
>
> The following features are considered "at risk". If we cannot identify at
> least two shipping implementations, they will be marked "at risk" in the CR
> and may be removed from the Proposed Recommendation.
>
> keygen element. [issue 43]
> label as a reassociatable element [issue 109]
> Fixing requestAnimationFrame to 60Hz, not implementation-defined [issues
> 159/375/422]
> registerContentHandler [Issue 233]
> inputmode attribute of the input element [issue 269]
> autofill of form elements [issue 372]
> menu, menuitem and context menus. [issue 373]
> dialog element [issue 427]
> Text tracks exposing in-band metadata best practices [Issue 461]
> datetime and datatime-local states of the input element [Issue 462]
>
> Please share implementation details for any of these features on Github. To
> mark other features "at risk", please identify them by 10th June (ideally
> by
> filing an issue and providing a test case).
>
> At the same time we move HTML5.1 into CR, we plan to continue updating the
> Editor's Draft, and in the next few weeks we expect to post a Call for
> Consensus to publish it as the First Public Working Draft of HTML5.2, so
> improving HTML will continue without a pause. It also means that changes
> that didn't make it into
> HTML5.1 will not have long to wait before being incorporated into the
> specification.
>
> Léonie on behalf of the WP chairs and team, and HTML editors.
> [1] https://www.w3.org/TR/html51/
> [2] https://www.w3.org/TR/html51/changes.html#changes
> [3] https://www.w3.org/Consortium/Patent-Policy-20040205/#sec-Exclusion
>
> [issue 43] https://github.com/w3c/html/issues/43
> [issue 109] https://github.com/w3c/html/issues/109
> [issues 159/375/422] https://github.com/w3c/html/issues/159 and links
> [issue
> 233] https://github.com/w3c/html/issues/233
> [issue 269] https://github.com/w3c/html/issues/269
> [issue 372] https://github.com/w3c/html/issues/372
> [issue 373] https://github.com/w3c/html/issues/373
> [issue 427] https://github.com/w3c/html/issues/427
> [Issue 461] https://github.com/w3c/html/issues/461
> [Issue 462] https://github.com/w3c/html/issues/462
>
>
> --
> @LeonieWatson tink.uk Carpe diem
>
>
>
>
>

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

[Adrian Roselli]

+1

On Fri, Jun 3, 2016 at 12:10 PM, Dylan Barrell 
wrote:

> +1
>
> On Fri, Jun 3, 2016 at 9:57 AM, Joanmarie Diggs  wrote:
>
>> +1
>>
>> --joanie
>>
>> On 06/02/2016 08:48 AM, 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.
>> >
>> > Please reply to this thread on public-webapps@w3.org  no later than
>> end of
>> > day on 10 June. Positive responses are preferred and encouraged, silence
>> > will be considered as assent.
>> >
>> > The current HTML5.1 WD [1] improves upon HTML5. It includes updates that
>> > make it more reliable, more readable and understandable, and a better
>> match
>> > for reality. Substantial changes between HTML5 and HTML5.1 can be found
>> in
>> > the spec [2].
>> >
>> > When a specification moves to CR it triggers a Call For Exclusions, per
>> > section 4 of the W3C Patent Policy [3]. No substantive additions can be
>> made
>> > to a specification in CR without starting a new Call for Exclusions, so
>> we
>> > will put HTML5.1 into "feature freeze". It is possible to make editorial
>> > updates as necessary, and features marked "At Risk" may be removed if
>> found
>> > not to be interoperable.
>> >
>> > The following features are considered "at risk". If we cannot identify
>> at
>> > least two shipping implementations, they will be marked "at risk" in
>> the CR
>> > and may be removed from the Proposed Recommendation.
>> >
>> > keygen element. [issue 43]
>> > label as a reassociatable element [issue 109]
>> > Fixing requestAnimationFrame to 60Hz, not implementation-defined [issues
>> > 159/375/422]
>> > registerContentHandler [Issue 233]
>> > inputmode attribute of the input element [issue 269]
>> > autofill of form elements [issue 372]
>> > menu, menuitem and context menus. [issue 373]
>> > dialog element [issue 427]
>> > Text tracks exposing in-band metadata best practices [Issue 461]
>> > datetime and datatime-local states of the input element [Issue 462]
>> >
>> > Please share implementation details for any of these features on
>> Github. To
>> > mark other features "at risk", please identify them by 10th June
>> (ideally by
>> > filing an issue and providing a test case).
>> >
>> > At the same time we move HTML5.1 into CR, we plan to continue updating
>> the
>> > Editor's Draft, and in the next few weeks we expect to post a Call for
>> > Consensus to publish it as the First Public Working Draft of HTML5.2, so
>> > improving HTML will continue without a pause. It also means that changes
>> > that didn't make it into
>> > HTML5.1 will not have long to wait before being incorporated into the
>> > specification.
>> >
>> > Léonie on behalf of the WP chairs and team, and HTML editors.
>> > [1] https://www.w3.org/TR/html51/
>> > [2] https://www.w3.org/TR/html51/changes.html#changes
>> > [3] https://www.w3.org/Consortium/Patent-Policy-20040205/#sec-Exclusion
>> >
>> > [issue 43] https://github.com/w3c/html/issues/43
>> > [issue 109] https://github.com/w3c/html/issues/109
>> > [issues 159/375/422] https://github.com/w3c/html/issues/159 and links
>> [issue
>> > 233] https://github.com/w3c/html/issues/233
>> > [issue 269] https://github.com/w3c/html/issues/269
>> > [issue 372] https://github.com/w3c/html/issues/372
>> > [issue 373] https://github.com/w3c/html/issues/373
>> > [issue 427] https://github.com/w3c/html/issues/427
>> > [Issue 461] https://github.com/w3c/html/issues/461
>> > [Issue 462] https://github.com/w3c/html/issues/462
>> >
>> >
>>
>>
>>
>
>
> --
> Download the aXe browser extension for free:
>
> Firefox: https://addons.mozilla.org/en-US/firefox/addon/axe-devtools
> Chrome:
> https://chrome.google.com/webstore/detail/axe/lhdoppojpmngadmnindnejefpokejbdd?hl=en-US
>
> Life is ten percent what happens to you and ninety percent how you respond
> to it. - Lou Holtz
>
>

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

[Dylan Barrell]

+1

On Fri, Jun 3, 2016 at 9:57 AM, Joanmarie Diggs  wrote:

> +1
>
> --joanie
>
> On 06/02/2016 08:48 AM, 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.
> >
> > Please reply to this thread on public-webapps@w3.org  no later than end
> of
> > day on 10 June. Positive responses are preferred and encouraged, silence
> > will be considered as assent.
> >
> > The current HTML5.1 WD [1] improves upon HTML5. It includes updates that
> > make it more reliable, more readable and understandable, and a better
> match
> > for reality. Substantial changes between HTML5 and HTML5.1 can be found
> in
> > the spec [2].
> >
> > When a specification moves to CR it triggers a Call For Exclusions, per
> > section 4 of the W3C Patent Policy [3]. No substantive additions can be
> made
> > to a specification in CR without starting a new Call for Exclusions, so
> we
> > will put HTML5.1 into "feature freeze". It is possible to make editorial
> > updates as necessary, and features marked "At Risk" may be removed if
> found
> > not to be interoperable.
> >
> > The following features are considered "at risk". If we cannot identify at
> > least two shipping implementations, they will be marked "at risk" in the
> CR
> > and may be removed from the Proposed Recommendation.
> >
> > keygen element. [issue 43]
> > label as a reassociatable element [issue 109]
> > Fixing requestAnimationFrame to 60Hz, not implementation-defined [issues
> > 159/375/422]
> > registerContentHandler [Issue 233]
> > inputmode attribute of the input element [issue 269]
> > autofill of form elements [issue 372]
> > menu, menuitem and context menus. [issue 373]
> > dialog element [issue 427]
> > Text tracks exposing in-band metadata best practices [Issue 461]
> > datetime and datatime-local states of the input element [Issue 462]
> >
> > Please share implementation details for any of these features on Github.
> To
> > mark other features "at risk", please identify them by 10th June
> (ideally by
> > filing an issue and providing a test case).
> >
> > At the same time we move HTML5.1 into CR, we plan to continue updating
> the
> > Editor's Draft, and in the next few weeks we expect to post a Call for
> > Consensus to publish it as the First Public Working Draft of HTML5.2, so
> > improving HTML will continue without a pause. It also means that changes
> > that didn't make it into
> > HTML5.1 will not have long to wait before being incorporated into the
> > specification.
> >
> > Léonie on behalf of the WP chairs and team, and HTML editors.
> > [1] https://www.w3.org/TR/html51/
> > [2] https://www.w3.org/TR/html51/changes.html#changes
> > [3] https://www.w3.org/Consortium/Patent-Policy-20040205/#sec-Exclusion
> >
> > [issue 43] https://github.com/w3c/html/issues/43
> > [issue 109] https://github.com/w3c/html/issues/109
> > [issues 159/375/422] https://github.com/w3c/html/issues/159 and links
> [issue
> > 233] https://github.com/w3c/html/issues/233
> > [issue 269] https://github.com/w3c/html/issues/269
> > [issue 372] https://github.com/w3c/html/issues/372
> > [issue 373] https://github.com/w3c/html/issues/373
> > [issue 427] https://github.com/w3c/html/issues/427
> > [Issue 461] https://github.com/w3c/html/issues/461
> > [Issue 462] https://github.com/w3c/html/issues/462
> >
> >
>
>
>


-- 
Download the aXe browser extension for free:

Firefox: https://addons.mozilla.org/en-US/firefox/addon/axe-devtools
Chrome:
https://chrome.google.com/webstore/detail/axe/lhdoppojpmngadmnindnejefpokejbdd?hl=en-US

Life is ten percent what happens to you and ninety percent how you respond
to it. - Lou Holtz

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

[Joanmarie Diggs]

+1

--joanie

On 06/02/2016 08:48 AM, 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.
> 
> Please reply to this thread on public-webapps@w3.org  no later than end of
> day on 10 June. Positive responses are preferred and encouraged, silence
> will be considered as assent.
> 
> The current HTML5.1 WD [1] improves upon HTML5. It includes updates that
> make it more reliable, more readable and understandable, and a better match
> for reality. Substantial changes between HTML5 and HTML5.1 can be found in
> the spec [2].
> 
> When a specification moves to CR it triggers a Call For Exclusions, per
> section 4 of the W3C Patent Policy [3]. No substantive additions can be made
> to a specification in CR without starting a new Call for Exclusions, so we
> will put HTML5.1 into "feature freeze". It is possible to make editorial
> updates as necessary, and features marked "At Risk" may be removed if found
> not to be interoperable.
> 
> The following features are considered "at risk". If we cannot identify at
> least two shipping implementations, they will be marked "at risk" in the CR
> and may be removed from the Proposed Recommendation.
> 
> keygen element. [issue 43]
> label as a reassociatable element [issue 109]
> Fixing requestAnimationFrame to 60Hz, not implementation-defined [issues
> 159/375/422]
> registerContentHandler [Issue 233]
> inputmode attribute of the input element [issue 269]
> autofill of form elements [issue 372]
> menu, menuitem and context menus. [issue 373]
> dialog element [issue 427]
> Text tracks exposing in-band metadata best practices [Issue 461]
> datetime and datatime-local states of the input element [Issue 462]
> 
> Please share implementation details for any of these features on Github. To
> mark other features "at risk", please identify them by 10th June (ideally by
> filing an issue and providing a test case).
> 
> At the same time we move HTML5.1 into CR, we plan to continue updating the
> Editor's Draft, and in the next few weeks we expect to post a Call for
> Consensus to publish it as the First Public Working Draft of HTML5.2, so
> improving HTML will continue without a pause. It also means that changes
> that didn't make it into
> HTML5.1 will not have long to wait before being incorporated into the
> specification.
> 
> Léonie on behalf of the WP chairs and team, and HTML editors.
> [1] https://www.w3.org/TR/html51/ 
> [2] https://www.w3.org/TR/html51/changes.html#changes
> [3] https://www.w3.org/Consortium/Patent-Policy-20040205/#sec-Exclusion 
> 
> [issue 43] https://github.com/w3c/html/issues/43
> [issue 109] https://github.com/w3c/html/issues/109
> [issues 159/375/422] https://github.com/w3c/html/issues/159 and links [issue
> 233] https://github.com/w3c/html/issues/233
> [issue 269] https://github.com/w3c/html/issues/269
> [issue 372] https://github.com/w3c/html/issues/372
> [issue 373] https://github.com/w3c/html/issues/373
> [issue 427] https://github.com/w3c/html/issues/427
> [Issue 461] https://github.com/w3c/html/issues/461 
> [Issue 462] https://github.com/w3c/html/issues/462 
> 
> 

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

[Léonie Watson]

> From: Sangwhan Moon [mailto:sangw...@iki.fi]
> Sent: 03 June 2016 02:45
> I believe Marcos is raising a valid concern here - while I'm not in full
> agreement that only objections matter, most of the people get enough mail
> already and it does make it easy to get important feedback lost in a chain of
> +1 mails. (and when it piles up, it's just something you zip through and mark
> as read, now repeat time spent doing that multiplied by subscribers of this
> ML...)

In the interests of holding a useful discussion, without creating more email on 
this thread, comments, ideas and suggestions are welcome here:
https://github.com/w3c/WebPlatformWG/issues/38 

Léonie.

-- 
@LeonieWatson tink.uk Carpe diem

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

[Zero]

+1 for moving HTML5.1 to CR.

Best Regards,
Shaohang Yang

-邮件原件-
发件人: Léonie Watson [mailto:t...@tink.uk] 
发送时间: 2016年6月2日 20:48
收件人: 'public-webapps WG'
主题: 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 on 10 June. Positive responses are preferred and encouraged, silence
will be considered as assent.

The current HTML5.1 WD [1] improves upon HTML5. It includes updates that
make it more reliable, more readable and understandable, and a better match
for reality. Substantial changes between HTML5 and HTML5.1 can be found in
the spec [2].

When a specification moves to CR it triggers a Call For Exclusions, per
section 4 of the W3C Patent Policy [3]. No substantive additions can be made
to a specification in CR without starting a new Call for Exclusions, so we
will put HTML5.1 into "feature freeze". It is possible to make editorial
updates as necessary, and features marked "At Risk" may be removed if found
not to be interoperable.

The following features are considered "at risk". If we cannot identify at
least two shipping implementations, they will be marked "at risk" in the CR
and may be removed from the Proposed Recommendation.

keygen element. [issue 43]
label as a reassociatable element [issue 109] Fixing requestAnimationFrame
to 60Hz, not implementation-defined [issues 159/375/422]
registerContentHandler [Issue 233] inputmode attribute of the input element
[issue 269] autofill of form elements [issue 372] menu, menuitem and context
menus. [issue 373] dialog element [issue 427] Text tracks exposing in-band
metadata best practices [Issue 461] datetime and datatime-local states of
the input element [Issue 462]

Please share implementation details for any of these features on Github. To
mark other features "at risk", please identify them by 10th June (ideally by
filing an issue and providing a test case).

At the same time we move HTML5.1 into CR, we plan to continue updating the
Editor's Draft, and in the next few weeks we expect to post a Call for
Consensus to publish it as the First Public Working Draft of HTML5.2, so
improving HTML will continue without a pause. It also means that changes
that didn't make it into
HTML5.1 will not have long to wait before being incorporated into the
specification.

Léonie on behalf of the WP chairs and team, and HTML editors.
[1] https://www.w3.org/TR/html51/
[2] https://www.w3.org/TR/html51/changes.html#changes
[3] https://www.w3.org/Consortium/Patent-Policy-20040205/#sec-Exclusion 

[issue 43] https://github.com/w3c/html/issues/43
[issue 109] https://github.com/w3c/html/issues/109
[issues 159/375/422] https://github.com/w3c/html/issues/159 and links [issue
233] https://github.com/w3c/html/issues/233
[issue 269] https://github.com/w3c/html/issues/269
[issue 372] https://github.com/w3c/html/issues/372
[issue 373] https://github.com/w3c/html/issues/373
[issue 427] https://github.com/w3c/html/issues/427
[Issue 461] https://github.com/w3c/html/issues/461
[Issue 462] https://github.com/w3c/html/issues/462 


-- 
@LeonieWatson tink.uk Carpe diem

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

[Sangwhan Moon]

> On Jun 3, 2016, at 01:35, Chaals McCathie Nevile  
> wrote:
> 
> 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 +1's indeed don't matter. But if there 
> is one or more, then having some measure of the overall consensus of the 
> group is important.
> 
> It's why we've got the arrangement that except where progressing makes a 
> significant difference, we do it automatically and allow for objection as the 
> exception case. Moving to CR potentially binds members to patent commitments, 
> which matters to some members as well as to many people "out there in the 
> wild", and requires that we demonstrate agreement of the group.
> 
> So I'm sorry for the extra mail, but in this case I'm afraid it's part of 
> running the W3C process. If everything goes smoothly, you can expect this for 
> HTML twice more in the next year: once to move to Proposed Recommendation, 
> and once to move 5.2 to First Public Working Draft.

I believe Marcos is raising a valid concern here - while I'm not in full 
agreement that only objections
matter, most of the people get enough mail already and it does make it easy to 
get important feedback
lost in a chain of +1 mails. (and when it piles up, it's just something you zip 
through and mark as read,
now repeat time spent doing that multiplied by subscribers of this ML...)

Having a platform where the chairs/staff can get a quick overview of the 
consensus stats sounds a
like it could save time in the even anyone needs the consensus statistics. (As 
mentioned in a earlier
reply, WBS could work, even if it's not a great tool per se.)

Sangwhan

>>> On 3 Jun 2016, at 12:36 AM, Mona Rekhi  wrote:
>>> 
>>> +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 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 on 10 June. Positive responses are preferred and encouraged, silence 
>>> will be considered as assent.
>>> 
>>> The current HTML5.1 WD [1] improves upon HTML5. It includes updates that 
>>> make it more reliable, more readable and understandable, and a better match 
>>> for reality. Substantial changes between HTML5 and HTML5.1 can be found in 
>>> the spec [2].
>>> 
>>> When a specification moves to CR it triggers a Call For Exclusions, per 
>>> section 4 of the W3C Patent Policy [3]. No substantive additions can be 
>>> made to a specification in CR without starting a new Call for Exclusions, 
>>> so we will put HTML5.1 into "feature freeze". It is possible to make 
>>> editorial updates as necessary, and features marked "At Risk" may be 
>>> removed if found not to be interoperable.
>>> 
>>> The following features are considered "at risk". If we cannot identify at 
>>> least two shipping implementations, they will be marked "at risk" in the CR 
>>> and may be removed from the Proposed Recommendation.
>>> 
>>> keygen element. [issue 43]
>>> label as a reassociatable element [issue 109] Fixing requestAnimationFrame 
>>> to 60Hz, not implementation-defined [issues 159/375/422] 
>>> registerContentHandler [Issue 233] inputmode attribute of the input element 
>>> [issue 269] autofill of form elements [issue 372] menu, menuitem and 
>>> context menus. [issue 373] dialog element [issue 427] Text tracks exposing 
>>> in-band metadata best practices [Issue 461] datetime and datatime-local 
>>> states of the input element [Issue 462]
>>> 
>>> Please share implementation details for any of these features on Github. To 
>>> mark other features "at risk", please identify them by 10th June (ideally 
>>> by filing an issue and providing a test case).
>>> 
>>> At the same time we move HTML5.1 into CR, we plan to continue updating the 
>>> Editor's Draft, and in the next few weeks we expect to post a Call for 
>>> Consensus to publish it as the First Public Working Draft of HTML5.2, so 
>>> improving HTML will continue without a pause. It also means that changes 
>>> that didn't make it into
>>> HTML5.1 will not have long to wait before being incorporated into the 
>>> specification.
>>> 
>>> Léonie on behalf of the WP chairs and team, and HTML editors.
>>> [1] https://www.w3.org/TR/html51/
>>> [2] https://www.w3.org/TR/html51/changes.html#changes
>>> [3] 

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

[Alex Danilo]

+1 for moving HTML5.1 to CR.

Alex

On 3 June 2016 at 05:30, Gez Lemon  wrote:

> +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.
>>
>> Please reply to this thread on public-webapps@w3.org  no later than end
>> of
>> day on 10 June. Positive responses are preferred and encouraged, silence
>> will be considered as assent.
>>
>> The current HTML5.1 WD [1] improves upon HTML5. It includes updates that
>> make it more reliable, more readable and understandable, and a better
>> match
>> for reality. Substantial changes between HTML5 and HTML5.1 can be found in
>> the spec [2].
>>
>> When a specification moves to CR it triggers a Call For Exclusions, per
>> section 4 of the W3C Patent Policy [3]. No substantive additions can be
>> made
>> to a specification in CR without starting a new Call for Exclusions, so we
>> will put HTML5.1 into "feature freeze". It is possible to make editorial
>> updates as necessary, and features marked "At Risk" may be removed if
>> found
>> not to be interoperable.
>>
>> The following features are considered "at risk". If we cannot identify at
>> least two shipping implementations, they will be marked "at risk" in the
>> CR
>> and may be removed from the Proposed Recommendation.
>>
>> keygen element. [issue 43]
>> label as a reassociatable element [issue 109]
>> Fixing requestAnimationFrame to 60Hz, not implementation-defined [issues
>> 159/375/422]
>> registerContentHandler [Issue 233]
>> inputmode attribute of the input element [issue 269]
>> autofill of form elements [issue 372]
>> menu, menuitem and context menus. [issue 373]
>> dialog element [issue 427]
>> Text tracks exposing in-band metadata best practices [Issue 461]
>> datetime and datatime-local states of the input element [Issue 462]
>>
>> Please share implementation details for any of these features on Github.
>> To
>> mark other features "at risk", please identify them by 10th June (ideally
>> by
>> filing an issue and providing a test case).
>>
>> At the same time we move HTML5.1 into CR, we plan to continue updating the
>> Editor's Draft, and in the next few weeks we expect to post a Call for
>> Consensus to publish it as the First Public Working Draft of HTML5.2, so
>> improving HTML will continue without a pause. It also means that changes
>> that didn't make it into
>> HTML5.1 will not have long to wait before being incorporated into the
>> specification.
>>
>> Léonie on behalf of the WP chairs and team, and HTML editors.
>> [1] https://www.w3.org/TR/html51/
>> [2] https://www.w3.org/TR/html51/changes.html#changes
>> [3] https://www.w3.org/Consortium/Patent-Policy-20040205/#sec-Exclusion
>>
>> [issue 43] https://github.com/w3c/html/issues/43
>> [issue 109] https://github.com/w3c/html/issues/109
>> [issues 159/375/422] https://github.com/w3c/html/issues/159 and links
>> [issue
>> 233] https://github.com/w3c/html/issues/233
>> [issue 269] https://github.com/w3c/html/issues/269
>> [issue 372] https://github.com/w3c/html/issues/372
>> [issue 373] https://github.com/w3c/html/issues/373
>> [issue 427] https://github.com/w3c/html/issues/427
>> [Issue 461] https://github.com/w3c/html/issues/461
>> [Issue 462] https://github.com/w3c/html/issues/462
>>
>>
>> --
>> @LeonieWatson tink.uk Carpe diem
>>
>>
>>
>>
>>
>
>
> --
> _
> Senior Accessibility Engineer
> The Paciello Group
>
> This message is intended to be confidential and may be legally privileged.
> It is intended solely for the addressee. If you are not the intended
> recipient, please delete this message from your system and notify us
> immediately. Any disclosure, copying, distribution or action taken or
> omitted to be taken by an unintended recipient in reliance on this message
> is prohibited and may be unlawful.
>

[Bug 23780] Check XMLHttpRequest and Notification don' t break given the new script settings object stuff

[bugzilla]

https://www.w3.org/Bugs/Public/show_bug.cgi?id=23780
Bug 23780 depends on bug 18242, which changed state.

Bug 18242 Summary: Not clear what "script that invoked the method" means 
exactly in the case of e.g. a.setTimeout(b.postMessage, 0) // called from c
https://www.w3.org/Bugs/Public/show_bug.cgi?id=18242

   What|Removed |Added

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

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