from:"Léonie Watson"

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

2016-08-23 Thread 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: CfC: Pointer Lock to Proposed Recommendation; deadline August 20

2016-08-21 Thread 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

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

2016-08-19 Thread 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: CfC: Pointer Lock to Proposed Recommendation; deadline August 20

2016-08-17 Thread Léonie Watson

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,

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.

Thanks.

-xiaoqian

CFC to publish WebIDL-1 as a Proposed Recommendation

2016-08-16 Thread 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: Service Workers meeting info

2016-08-11 Thread 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

Re: CFC: Publish a FPWD of IndexedDB 2.0

2016-08-11 Thread 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: CFC on referencing the Image Description (longdesc) extension

2016-08-11 Thread 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: Leaving Mozilla

2016-08-09 Thread 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

2016-08-09 Thread 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/

CFC on referencing the Image Description (longdesc) extension

2016-08-05 Thread 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

2016-08-04 Thread 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

WPWG meetings at TPAC

2016-08-04 Thread 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

CFC: Publish a FPWD of IndexedDB 2.0

2016-08-03 Thread 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

Service Workers meeting info

2016-07-12 Thread 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?

2016-07-11 Thread 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: CFC: Republish Pointer Lock as CR

2016-06-25 Thread 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

2016-06-21 Thread 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

2016-06-21 Thread 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

2016-06-21 Thread 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

2016-06-17 Thread 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 <dylan.barr...@deque.com 
<mailto:dylan.barr...@deque.com> > wrote:

abstain

 

On Tue, Jun 14, 2016 at 1:47 AM, Michiel Bijl <mich...@agosto.nl 
<mailto:mich...@agosto.nl> > wrote:

Looks good, +1


—Michiel

 

On 13 Jun 2016, at 18:12, Léonie Watson <t...@tink.uk <mailto:t...@tink.uk> > 
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 <http://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

CFC: Republish Pointer Lock as CR

2016-06-13 Thread 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)

2016-06-13 Thread 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' <public-webapps@w3.org>
> 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: Request to move HTML5.1 to Candidate Recommendation (CR)

2016-06-03 Thread 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)

2016-06-02 Thread Léonie Watson

> From: mar...@marcosc.com [mailto:mar...@marcosc.com]
> Sent: 02 June 2016 17:15
> Can we please kindly stop the +1s spam? It greatly diminishes the value of
> this mailing list.

We mention in the CFC that positive responses are preferred and encouraged 
(which they are), so this is an appeal to everyone's good nature for a little 
patience and email filtering fu. Thank you.


Léonie.

-- 
@LeonieWatson tink.uk Carpe diem

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

2016-06-02 Thread Léonie Watson

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

+1 (as TPG WG participant, not chair).

Léonie.

-- 
@LeonieWatson tink.uk Carpe diem

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

2016-06-02 Thread Léonie Watson

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: Self-introduction from Wanming Lin

2016-05-31 Thread Léonie Watson

> From: Lin, Wanming [mailto:wanming@intel.com]
> Sent: 31 May 2016 08:46
> Hello WP,

Hello Wanming, and welcome.

[...]
> I am proud to represent my team to join in this group, I am a newbie but I
will
> try my best.
> Looking forward to working with you all.

Thank you. We are looking forward to working with you too. If you have any
questions, please let us know.

Léonie.

WP meetings at TPAC

2016-05-25 Thread Léonie Watson

Hello WP,

We have meeting space available throughout TPAC week [1]. The plan is to
focus on a different area of work each day, to help everyone schedule their
time a bit more easily.

We've posted meeting pages for each day:
https://github.com/w3c/WebPlatformWG/blob/gh-pages/Meetings.md

Monday 19th - Web Components
https://github.com/w3c/WebPlatformWG/blob/gh-pages/meetings/16-09-19WebComps
.md 

Tuesday 20th - Service Workers
https://github.com/w3c/WebPlatformWG/blob/gh-pages/meetings/16-09-20ServiceW
orkers.md 

Thursday 22nd - Editing and Selection
https://github.com/w3c/WebPlatformWG/blob/gh-pages/meetings/16-09-22EditingS
election.md 

Friday 23rd - HTML, Directory Upload, and WP plenary
https://github.com/w3c/WebPlatformWG/blob/gh-pages/meetings/16-09-23HTMLWP.m
d 

If you'll be at TPAC and expect to attend any of these meetings, please add
your name to the attendees list (or let us know so we can add your name).

We'll be shaping the agenda for each meeting as TPAC draws near, so posting
any possible agenda items would also be helpful.

Thanks, and as always if you have questions you know where to find us -
team-webplatf...@w3.org.

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



-- 
@LeonieWatson tink.uk Carpe diem


Léonie.
[1] https://www.w3.org/2016/09/TPAC/

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

2016-05-24 Thread Léonie Watson

With the subject line repaired this time...


> -Original Message-
> From: Léonie Watson [mailto:t...@tink.uk]
> Sent: 24 May 2016 18:54
> To: public-webapps@w3.org
> Subject: CFC
> 
> Hello WP,
> 
> At the AC meeting in March 2016 the WP co-chairs indicated that the
> Packaging on the Web specification [1] would benefit from further
incubation
> before continuing along the Recommendation track.
> 
> This is a CFC to publish Packaging on the Web as a W3C note. If the CFC
> passes, the transition of the specification to note status will be done
within
> the current WP WG charter.
> 
> If you have comments or concerns about this CFC, please send them to
> public-webapps@w3.org no later than 2nd June 2016. Positive responses are
> preferred and encouraged, but silence will be considered as agreement with
> the proposal.
> 
> Léonie on behalf of the WP chairs and team.
> [1] http://w3ctag.github.io/packaging-on-the-web/
> 
> --
> @LeonieWatson tink.uk Carpe diem
> 
> 
>

CFC

2016-05-24 Thread Léonie Watson

Hello WP,

At the AC meeting in March 2016 the WP co-chairs indicated that the
Packaging on the Web specification [1] would benefit from further incubation
before continuing along the Recommendation track.

This is a CFC to publish Packaging on the Web as a W3C note. If the CFC
passes, the transition of the specification to note status will be done
within the current WP WG charter.

If you have comments or concerns about this CFC, please send them to
public-webapps@w3.org no later than 2nd June 2016. Positive responses are
preferred and encouraged, but silence will be considered as agreement with
the proposal.

Léonie on behalf of the WP chairs and team.
[1] http://w3ctag.github.io/packaging-on-the-web/ 

-- 
@LeonieWatson tink.uk Carpe diem

RE: New Web Components editor

2016-04-26 Thread Léonie Watson

> From: Domenic Denicola [mailto:d...@domenic.me]
> Sent: 26 April 2016 19:06
> Thanks Léonie. One correction:
> 
> From: Léonie Watson [mailto:t...@tink.uk]
> 
> 
> > The WP co-chairs and team are happy to announce that Domenic Denicola
> > will be the new editor of the Custom Elements and Shadow DOM
> > specifications at W3C.
> 
> Custom Elements only; Shadow DOM remains in Hayato's capable hands.

Sorry about that. I've corrected Pub Status accordingly [1]. Thanks.

Léonie.
[1] https://www.w3.org/WebPlatform/WG/PubStatus 

-- 
@LeonieWatson tink.uk Carpe diem

CFC: Publish as W3C Notes

2016-04-26 Thread Léonie Watson

Hello,

At the AC meeting in March 2016 the WP co-chairs indicated that the
following two specifications would benefit from further incubation before
continuing along the Recommendation track:

Quota Management API [1]
Input Method Editor API [2]

This is a CFC to publish each of these specifications as a W3C note, under
the Software and Document License. Anyone wishing to take these ideas
further is then welcome to use the notes to seed incubation within WICG or
elsewhere.

If the CFC passes, the transition of each specification to note status will
be done within the current WP WG charter.

If you have comments or concerns about this CFC, please send them to
public-webapps@w3.org no later than Wednesday 4th May 2016. Positive
responses are preferred and encouraged, and silence will be considered as
agreement with the proposal.

Léonie on behalf of the WP chairs and team.
[1] https://w3c.github.io/quota-api/
[2] https://w3c.github.io/ime-api/
-- 
@LeonieWatson tink.uk Carpe diem

New Web Components editor

2016-04-26 Thread Léonie Watson

Hello,

The WP co-chairs and team are happy to announce that Domenic Denicola will
be the new editor of the Custom Elements and Shadow DOM specifications at
W3C.

With thanks to Google for their time and support, we're looking forward to
working with Domenic - and to the continued evolution of these
specifications.

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

-- 
@LeonieWatson tink.uk Carpe diem

[Web Components] Editor for Custom Elements

2016-04-06 Thread Léonie Watson

Hello WP,

We're looking for a new editor for the Custom Elements spec [1].

Dimitri Glazkov has stepped down as editor and will be greatly missed in the
role. Thank you for all your hard work Dimitri, you helped make Custom
Elements happen and it's very much appreciated.

Domenic Denicola briefly stepped into the role, but regretfully he has since
declined to work within the W3C community [2].

Which means we're looking for someone (or more than one someone) to edit
Custom Elements. Web Components are a key part of the Web Platform, so it's
an interesting time to be part of the group working on Custom Elements (and
Shadow DOM).

If you're interested, email team-webplatf...@w3.org and let us know.
Knowledge of the spec is a good thing, but don't worry if you don't have any
editing experience - we can get you up to speed.

Léonie.
[1] https://w3c.github.io/webcomponents/spec/custom/
[2]
https://github.com/w3c/webcomponents/commit/d95392f734895b2c72e1822f464dd70a
22b322a4#commitcomment-16991516 


-- 
@LeonieWatson tink.uk Carpe diem.

Last call for TPAC meeting space

2016-03-24 Thread Léonie Watson

Hello,

We need to request meeting space at TPAC by the end of this month. As Chaals
previously noted, we will be focusing meeting time on particular areas
rather than holding multiple plenary days [1].

If you would like time/space to meet to work on a particular spec, please
let us know how much time, roughly how many people, and any other meetings
we should try to avoid clashing with.

TPAC is in Lisbon 19th to 23rd September 2016. If you can send any requests
for meeting time/space by Monday 28th Mar, that would be appreciated.

Thanks much.

Léonie.
-- 
@LeonieWatson tink.uk Carpe diem

HTML editors meeting

2016-03-15 Thread Léonie Watson

Hello,

There will be an HTML editors meeting on 10 - 11 May 2016, at Microsoft in
Redmond. Info here:
https://github.com/w3c/WebPlatformWG/blob/gh-pages/meetings/10-11mayHTML.md 

If you are interested in joining the HTML editorial team, we would like to
hear from you. Whilst anybody can submit a PR proposing a change to the HTML
spec, the editorial team is responsible for reviewing PRs and merging them
into the spec when they are ready.

Léonie.

-- 
@LeonieWatson tink.uk Carpe diem.

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

2016-03-15 Thread Léonie Watson

For a telecon, we can create a WebEx instance if that would be useful? Let
me know the date/time (UTC), and we'll get it sorted.

For an F2F, we'll need to post notice of the date/venue at least eight weeks
in advance [1]. Let me know the date(s)/venue, and we can do that too.

Léonie.
[1] https://lists.w3.org/Archives/Public/public-webapps/2016JanMar/0043.html


> -Original Message-
> From: rn...@apple.com [mailto:rn...@apple.com]
> Sent: 14 March 2016 23:56
> To: t...@tink.uk; Chaals McCathie Nevile 
> Cc: public-webapps 
> Subject: Telecon / meeting on first week of April for Web Components
> 
> Hi all,
> 
> We've been making a good progress on shadow DOM and custom elements
> API but there seems to be a lot of open questions still.  I've asked a
couple of
> people involved in the discussion, and there seems to be an interest for
> having another tele-conference or an in-person meeting.
> 
> Can we schedule one in the second week of April (April 4th through 8th)?
> 
> - R. Niwa

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

2016-03-15 Thread Léonie Watson

Would a meeting at TPAC be useful too? It’s 19 to 23 september, in Lisbon 
Portugal.

 

We need to request meeting space by the end of this month. So if so, let us 
know how much time you think you’ll need, and roughly how many people you think 
might attend.

 

Thanks.

Léonie.

From: Dimitri Glazkov [mailto:dglaz...@google.com] 
Sent: 15 March 2016 04:30
To: Ryosuke Niwa <rn...@apple.com>
Cc: Léonie Watson <t...@tink.uk>; Chaals McCathie Nevile 
<cha...@yandex-team.ru>; public-webapps <public-webapps@w3.org>
Subject: Re: Telecon / meeting on first week of April for Web Components

 

I am game, per usual.

 

:DG<

 

On Mon, Mar 14, 2016 at 4:55 PM, Ryosuke Niwa <rn...@apple.com 
<mailto:rn...@apple.com> > wrote:

Hi all,

We've been making a good progress on shadow DOM and custom elements API but 
there seems to be a lot of open questions still.  I've asked a couple of people 
involved in the discussion, and there seems to be an interest for having 
another tele-conference or an in-person meeting.

Can we schedule one in the second week of April (April 4th through 8th)?

- R. Niwa

FW: New W3C publication requirements as of March 1

2016-02-19 Thread Léonie Watson

-Original Message-
From: Philippe Le Hegaret [mailto:p...@w3.org] 
Sent: 18 February 2016 22:03
To: Chairs ; spec-prod 
Subject: New W3C publication requirements as of March 1

All,

We adopted back in May 2015  [1] a project to update our style sheets used in 
W3C documents.

I'm pleased to report that, as of March 1st, the requirements for publications 
will mandate the use of the new style sheets for all W3C documents published on 
or after March 1st.

If you are currently using bikeshed or respec to generate your specifications, 
you can safely ignore the rest of this message since those tools will take care 
of the changes for you. Those tools will be switched on March 1st to produce 
the expected requirements. As such, if you would like to publish *on* March 
1st, you can either use the appropriate settings of the tool (such as the 
useExperimentalStyles parameter in respec) or delay your publication until 
March 3. (see at the bottom for requesting further help).

The new additional (or replaced) requirements are as follows:

---
1. You MUST use the following meta tag in your html/head:

2. The W3C style sheet is one of
   https://www.w3.org/StyleSheets/TR/2016/

  e.g.

  https://www.w3.org/StyleSheets/TR/2016/W3C-WD

3. You MUST use https://www.w3.org/StyleSheets/TR/2016/logos/W3C for the 
W3C logo (instead of https://www.w3.org/Icons/w3c_home )

4. Your table of contents MUST be contained in a nav element with id=toc
must be wrapped around entire toc section (incl. heading)

(use a div if you're still using HTML4 but we *strongly* advise you 
to change to HTML5 in the upcoming months)

5. You MUST include the following script element at the of your html/body

---

If you have questions or need help, please don't hesitate to follow up 
on this message but don't wait for the day of your publication to 
realize you need help please. A few of us are also on irc on the channel 
#pub and you're welcome to seek help there as well.

Bug reports on the style sheets must be reported to
   https://github.com/w3c/tr-design/issues

We do expect Groups to need extra help during the switch and it may take 
a few days to handle all requests, so I recommend that important timely 
publication be done outside of the week of March 1st if possible.

Those style sheets requirements will remain in place until December 
31st, 2016 and MAY get replaced after [2].

Thank you,

Philippe

[1] https://lists.w3.org/Archives/Public/spec-prod/2015AprJun/0018.html
[2] https://github.com/w3c/tr-design/blob/gh-pages/README.md

FW: HTML plan

2016-01-19 Thread Léonie Watson

-Original Message-
From: Léonie Watson [mailto:t...@tink.uk] 
Sent: 19 January 2016 19:21
To: public-h...@w3.org
Subject: HTML plan

Dear all,

We've put a new draft of the HTML specification into GitHub:
http://github.com/w3c/html. 

You can read the editor's draft:
http://w3c.github.io/html. 

It is based on the W3C HTML 5.1 build scripts, synchronised to the WHATWG
source from 12th January 2016.

We would like to check the interoperability of those changes, and work
towards a new Recommendation, with the understanding that anything which
isn't demonstrably interoperable when we publish will be removed from the
specification proposed as a Recommendation and incorporated into a later
update when it is.

We welcome all pull requests for outstanding issues, in particular to fix
important interoperability bugs such as those affecting web developers
working on production web sites. Pull requests with supporting data to
justify a change are actively encouraged. All you need is a GitHub account,
and if you are not a member of the Web Platform working group, please
remember we work to W3C's patent policy terms [1]. This means anyone can
easily help us improve the existing HTML spec by contributing corrections
and clarifications. 

If you want to add a new feature to HTML, we encourage you to develop a
specification in the Web Platform Incubator community group [2] (or
elsewhere if you like). Wherever you work on the proposal, you should
consider bringing it to the Web Platform working group when it has buy-in
from a sizeable community who are prepared to ship it in production, when it
is "reasonably clear" what the rough architecture is, but before you have
got every last detail sorted out. When a proposal has sufficient buy-in to
move it along the W3C Recommendation Track Process, bring it to this Working
Group for wider testing and review, and formal standardisation. See the
"intent to migrate" template [3] for the kind of questions the Working Group
will ask about new proposals.

When HTML5 was published W3C announced its intention to continue publishing
updates, based on interoperable deployment, every year or so.  We would like
to meet this goal and publish a new improved Working Draft rapidly, as a
first step towards meeting that commitment to the community.

The specification has been converted to be generated directly from the
source in GitHub, using Bikeshed [4]. Making bug fixes means editing HTML
source code. You should then run the Bikeshed processor to check for build
errors - this can be done locally, or online.

One of our first tasks will be to triage the outstanding bugs in Bugzilla
[5], fix and resolve any quick editorial issues, resolve feature requests
with a recommendation to take the idea to the Web Platform Incubator
community group, and migrate all other issues to GitHub. Please file new
issues in GitHub.

A year ago, there was a lot of discussion about modularising HTML and the
working group charter [6] calls this out as a deliverable, citing a proposal
that Robin Berjon worked on [7]. The feedback we have received on the
proposed split by chapter is that it doesn't provide the benefits that
modularisation promises. To do this properly will require refactoring of the
specification. We would still like to do this, but we recognise it is a lot
of work and there are drawbacks as well as benefits.

One approach to test modularisation is to encourage people working on a
specific section to split it out from the "main" HTML specification, move it
independently to Recommendation, so that it can be referenced normatively
from the base specification. This way we can get some experience of the
process without undertaking a massive project before we really know the
costs and benefits.

We welcome feedback from WG participants on this approach, and on the HTML
plan itself.

Finally, we also welcome expressions of interest from anybody who would like
to join the editing team - for which the reward is hard work and the
satisfaction of a job well done. While anybody can submit a pull request
proposing a change to the specification, the editors will work together to
review pull requests and integrate them when they are ready.

Regards,
Web Platform Working Group chairs and Team contacts

[1] W3C Patent Policy
http://www.w3.org/Consortium/facts#patpol

[2] Web Platform Incubator Community Group (WICG)
https://www.w3.org/community/wicg/

[3] Intent to Migrate
https://wicg.github.io/admin/intent-to-migrate.html

[4] Bikeshed
https://github.com/tabatkins/bikeshed

[5] Bugzilla bugs
http://tinyurl.com/nkjxluk
http://tinyurl.com/j78uzg3

[6] Web Platform Working Group Charter
http://www.w3.org/2015/10/webplatform-charter.html

[7] Robin Berjon's module proposal
http://darobin.github.io/breakup/specs/

--
@LeonieWatson tink.uk Carpe diem

Holding WP meetings

2016-01-12 Thread Léonie Watson

Hello WP,

Finding the balance between rapidity and process can be challenging. WP
continues the work mode established by WebApps, where flexible and agile
collaboration is encouraged, and the W3C process respected.

Whenever people meet (formally or informally) to discuss a spec, there is a
good chance useful things will come out of that meeting. There is also a
good chance that people unable to attend the meeting will have other useful
contributions to make. Having lots of smart people work this way is how we
build strong standards.

With this in mind, we ask everyone to do a few simple things when it comes
to organising F2F meetings...

- Ask one of the chairs to send out notice of the meeting at least 8 weeks
in advance, including date/time and location;
- Post the meeting logistics in the WP Github meetings space [1];
- Use IRC (#WebApps + RRSBot) to record minutes of the meeting, and post
them within 48h;
- Post any resolutions made during the meeting, and invite people to comment
within the next 10 days.

If the meeting is ad hoc, then post any outcomes of the discussion for
consideration by the WG at large.

We know that meeting administrivia sometimes feels like a chore that
detracts from the business of writing specs, so the chairs are happy to help
facilitate meetings and make them as simple as possible to run. Then
everyone can focus on getting the job done.

Regards,
Léonie, Ade, Chaals and Art (WP co-chairs)

[1] https://github.com/w3c/WebPlatformWG/tree/gh-pages/meetings


-- 
@LeonieWatson tink.uk Carpe diem

RE: Publish WD of HTML Accessibility API Mappings (AAM) 1.0

2015-12-02 Thread Léonie Watson

The WP WG approves publication of the HTML AAM WD.

Léonie, Ade, Chaals and Art (WP co-chairs)


> -Original Message-
> From: Léonie Watson [mailto:lwat...@paciellogroup.com]
> Sent: 19 November 2015 09:20
> To: public-webapps@w3.org
> Cc: 'Michael Cooper' <coo...@w3.org>
> Subject: PSA: Publish WD of HTML Accessibility API Mappings (AAM) 1.0
> 
> Hello WP,
> 
> This is notice of intent to publish a new Working Draft of HTML
Accessibility
> API Mappings on/around 19th November [1]. It is a joint publication of the
> Web Platform and ARIA WGs.
> 
> Léonie.
> [1] http://w3c.github.io/aria/html-aam/html-aam.html
> 
> --
> Senior accessibility engineer @LeonieWatson @PacielloGroup
> 
> 
>

RE: Meeting date, january

2015-11-30 Thread Léonie Watson

> From: Chaals McCathie Nevile [mailto:cha...@yandex-team.ru]
> Sent: 26 November 2015 01:55
> it appears that there are some people may not be able to attend a meeting
> on the 29th - although Apple has generously offered to host that day.
> 
> Is there anyone who would only be able to attend if we moved the meeting
> to the 25th?
> Conversely, would that shift cause problems for anyone (e.g. bought
> inflexible tickets, another clash, …)
> 
> By default, we won't move the meeting, but if there are a number of people
> affected and it makes sense, we could do so. If so, I'd like to make that
> decision early next week.

Either date is likely to be ok for me. A decision would be helpful in knowing 
this for certain though.

Léonie.


-- 
Senior accessibility engineer @LeonieWatson @PacielloGroup

PSA: Publish WD of HTML Accessibility API Mappings (AAM) 1.0

2015-11-19 Thread Léonie Watson

Hello WP,

This is notice of intent to publish a new Working Draft of HTML
Accessibility API Mappings on/around 19th November [1]. It is a joint
publication of the Web Platform and ARIA WGs.

Léonie.
[1] http://w3c.github.io/aria/html-aam/html-aam.html 

-- 
Senior accessibility engineer @LeonieWatson @PacielloGroup

RE: [Web Components] proposing a f2f...

2015-11-06 Thread Léonie Watson

Quick reminder to please complete the ballot on proposed F2F meeting times. The 
feeling seems to be to meet sooner rather than later, so getting a decision 
ASAP would probably be a good thing to do (especially for those of us with 
travel plans to make):
https://modernballots.com/elections/agkedja2 

Thanks.
Léonie.

-- 
Senior accessibility engineer @LeonieWatson @PacielloGroup

RE: Notes from the future of HTML session at TPAC

2015-10-28 Thread Léonie Watson

> From: Arthur Barstow [mailto:art.bars...@gmail.com]
> Sent: 28 October 2015 20:35
> 
> Thanks!
> 
> Would someone with write privs to these minutes please commit to at least
> identifying the folks attributed in the minutes (f.ex. who is "DS")? It
would
> also be useful if the "Present" list included any other attendee not
directly
> attributed.

With thanks to Karl for the info and Michael C for making the updates, it
should be sorted now. 


Léonie.

-- 
Senior accessibility engineer @PacielloGroup @LeonieWatson

RE: [Web Components] proposing a f2f...

2015-10-28 Thread Léonie Watson

> From: Chaals McCathie Nevile [mailto:cha...@yandex-team.ru]
> Sent: 28 October 2015 13:20
> it would be good to have a face to face meeting, and wrap up loose ends.
> At the TPAC meeting times suggested were December and late January.

[...]

> I would propose a day between 10 and 14 December as a starting point
> (based on my own availability - as one of the few people traveling
> internationally).

I'll be in the US anyway the w/c 14th December, so could reasonably make it to 
a Web Comps meeting beforehand.


Léonie.

-- 
Senior accessibility engineer @PacielloGroup @LeonieWatson

Notes from the future of HTML session at TPAC

2015-10-28 Thread Léonie Watson

Thanks to everyone for a useful and informative discussion. Minutes
available from the following palces:

Web:
http://www.w3.org/2015/10/28-html-minutes.html 

Text:
http://www.w3.org/2015/10/28-html-minutes.html,text 
Léonie

-- 
Senior accessibility engineer @PacielloGroup @LeonieWatson

RE: Shadow DOM and SVG use elements

2015-10-27 Thread Léonie Watson

> From: Travis Leithead [mailto:travis.leith...@microsoft.com]
> Sent: 24 October 2015 04:42
> Well, since SVG 'use' is mostly about replicating the composed tree
anyway,
> it seems that is should probably render the composed tree--e.g., this
seems
> natural, because use would "replicate" the host element, which would then
> render it's shadow DOM.

Thinking out loud here... There is a problem with the way  and 
work that may be relevant, or even resolvable here. SVG has little implicit
accessibility, so it has to be applied explicitly.

When you define something in  and duplicate it with , the
accessibility has to be applied inside the . When the accessibility
sits inside the  it creates problems. For example this would result in
duplicated ID values in the rendered document:




First rectangle







It isn't possible to apply more than basic accessibility to the 
element, and it doesn't seem to be possible to cross the streams to
reference things inside the  from outside.

Léonie.

-- 
Senior accessibility engineer @PacielloGroup @LeonieWatson

RE: Custom Elements: is=

2015-06-15 Thread Léonie Watson

From: Bruce Lawson [mailto:bru...@opera.com] 
Sent: 15 June 2015 09:46

On 14 June 2015 at 01:41, Patrick H. Lauke re...@splintered.co.uk wrote:
 it makes more sense to work on stylability of standard elements.

I'd like to keep the is= construct (or better name) in the knowledge that 
it's a stopgap for v1, and put our energies we're currently expending debating 
this into styling standard elements - which is currently being considered 
http://dev.w3.org/csswg/css-forms/

Will leaving is= (or whatever we call it) in situ create backward compatibility 
problems later on if/when it changes? 

That aside, concentrating efforts on styling native HTML elements makes a lot 
of sense.


Léonie

-- 
Léonie Watson - Senior accessibility engineer
@LeonieWatson @PacielloGroup PacielloGroup.com

RE: Custom Elements: is=

2015-06-13 Thread Léonie Watson

From: Bruce Lawson [mailto:bru...@opera.com] 
Sent: 13 June 2015 16:34

On 13 June 2015 at 15:30, Léonie Watson lwat...@paciellogroup.com wrote:
 why not use the extends= syntax you mentioned?

 my-button extends=button attributesPush/my-button

because browsers that don't know about web components wouldn't pay any 
attention to my-button, and render Push as plain text.

Of course! I should have thought of that.

Léonie.


-- 
Léonie Watson - Senior accessibility engineer
@LeonieWatson @PacielloGroup PacielloGroup.com

RE: Custom Elements: is=

2015-06-13 Thread Léonie Watson

From: Tobie Langel [mailto:to...@codespeaks.com] 
Sent: 12 June 2015 21:26

On Fri, Jun 12, 2015, at 19:41, Léonie Watson wrote:
 Is there a succinct explanation of why the is= syntax is disliked? The 
 info on the WHATWG wiki explains where is= breaks, but doesn’t offer 
 much on the syntax issue [1].

[...]

So in summary it's ugly, has a high cognitive load, doesn't express the 
developers intent (actually even expresses the opposite), is hard to spot when 
reading code, and is error prone.

Hope this helps. :)

It does, thank you.

At the risk of asking the obvious question, why not use the extends= syntax you 
mentioned?

my-button extends=button attributesPush/my-button

It follows the expected X extends Y convention, and makes it reasonably clear 
what the attributes have been applied to I think.

Léonie.

RE: Custom Elements: is=

2015-06-13 Thread Léonie Watson

From: Bruce Lawson [mailto:bru...@opera.com] 
Sent: 13 June 2015 14:57
Subject: Re: Custom Elements: is=

On 12 June 2015 at 21:26, Tobie Langel to...@codespeaks.com wrote:
 I'm also concerned developers will mistakenly write:

 my-button is=button

 As it is much closer in form to what they want to achieve (see the 
 extend=parent syntax I wrote earlier).

That's true (and I've done exactly this myself). But wouldn't

button extendedby=my-button

solve that?

I think the problem with this would be that it still turns the expected X 
extends Y convention on its head? It also appears as though the attributes 
relate to button rather than the element indicated in the extendedby= 
attribute.

Léonie.

-- 
Léonie Watson - Senior accessibility engineer
@LeonieWatson @PacielloGroup PacielloGroup.com

RE: Custom Elements: is=

2015-06-12 Thread Léonie Watson

Is there a succinct explanation of why the is= syntax is disliked? The info on 
the WHATWG wiki explains where is= breaks, but doesn’t offer much on the syntax 
issue [1].

 

Léonie.

[1] https://wiki.whatwg.org/wiki/Custom_Elements#Subclassing_existing_elements 

 

-- 

Léonie Watson - Senior accessibility engineer

@LeonieWatson @PacielloGroup PacielloGroup.com

RE: Making ARIA and native HTML play better together

2015-05-12 Thread Léonie Watson

 From: Maciej Stachowiak [mailto:m...@apple.com]
 Sent: 12 May 2015 03:34

  On May 7, 2015, at 12:59 AM, Domenic Denicola d...@domenic.me wrote:

  From: Anne van Kesteren ann...@annevk.nl

  On Thu, May 7, 2015 at 9:02 AM, Steve Faulkner
 faulkner.st...@gmail.com wrote:
  Currently ARIA does not do this stuff AFAIK.

  Correct. ARIA only exposes strings to AT. We could maybe make it do
 more, once we understand what more means, which is basically figuring out
 HTML as Custom Elements...

  These are my thoughts as well. The proposal seems nice as a convenient
 way to get a given bundle of behaviors. But we *really* need to stop
 considering these roles as atomic, and instead break them down into what
 they really mean.

  In other words, I want to explain the button behavior as something like:

  - Default-focusable

 This point isn’t correct for built-in buttons on all browsers and platforms. 
 For
 example, input type=button is not keyboard-focusable on Safari for Mac
 but it is mouse-focusable. Likewise in Safari on iOS (both if you connect a
 physical keyboard, and if you use the onscreen focus-cycle arrows in
 navigation view).

 This raises an interesting and subtle point. Built-in controls can add value 
 by
 being consistent with the platform behavior when it varies between
 platforms. Giving very low-level primitives results in developers hardcoding
 the behavior of their biggest target platform - generally Windows, but for
 some mobile-targeted sites it can be iOS. It’s hard to make low-level
 primitives that can sensibly capture these details. Sure, I guess we could 
 have
 a feature that’s default-focusable but only on platforms where that is true
 for controls you don’t type into”. That is pretty specific to particular 
 platform
 details though. Other platforms could make different choices. In fact, what
 controls fall in which focus bucket has changed over time in Safari.

Duplicating the platform specific behaviour makes sense - at least from a UX 
perspective. If it looks like a button, people will expect it to behave like a 
button - in the way they're used to dealing with buttons on their particular 
platform/browser/AT/whatever.

 Let’s say you really want to capture all the essences of buttonness in a
 custom control, but give it special appearance or behavior. I think two good
 ways the web platform could provide for that are:

 (1) Provide standardized cross-browser support for styling of form controls.
 (2) Allow custom elements to subclass button or input type=button (the
 latter is hard to define cleanly due to the way many form controls are all
 overloaded onto a single element).

It seems there is some agreement that #1 would be a good thing to do. One 
possible solution would be to revisit the appearance:; property [1], although 
here opinions differ. It's a conversation for CSS, but fragmenting this 
discussion right now seems like it might derail some useful thinking.

Léonie.

[1] https://wiki.csswg.org/spec/css4-ui?s[]=appearance 

-- 
Léonie Watson Senior accessibility engineer, TPG
@LeonieWatson @PacielloGroup PacielloGroup.com

RE: Custom Elements: is=

2015-05-06 Thread Léonie Watson

 From: Anne van Kesteren [mailto:ann...@annevk.nl]
 Sent: 06 May 2015 15:25
 Open issues are kept track of here:
 
   https://wiki.whatwg.org/wiki/Custom_Elements
 
 I think we reached rough consensus at the Extensible Web Summit that is=
 does not do much, even for accessibility. Accessibility is something we need
 to tackle low-level by figuring out how builtin elements work:
 
   https://github.com/domenic/html-as-custom-elements

If we use ARIA to feed accessibility information into the examples in this 
project, we should end up with some useful blueprints.
 
 And we need to tackle it high-level by making it easier to style builtin
 elements:
 
   http://dev.w3.org/csswg/css-forms/
 
 And if the parser functionality provided by is= is of great value, we should
 consider parsing elements with a hyphen in them differently.
 Similar to how script and template are allowed pretty much
 everywhere.
 
 Therefore, I propose that we move subclassing of builtin elements to v2,
 remove is= from the specification, and potentially open an issue on HTML
 parser changes.

My understanding is that sub-classing would give us the accessibility 
inheritance we were hoping is= would provide. Apologies if I've missed it 
somewhere obvious, but is there any information/detail about the proposed 
sub-classing feature available anywhere?

Léonie.


-- 
Léonie Watson - Senior accessibility engineer, TPG
@LeonieWatson @PacielloGroup

57 matches

Mail list logo