Re: A Second Edition of Web Storage? [was: Re: Web Storage Rec errata?]

2015-05-12 Thread Arthur Barstow

Hi All,

Thanks for this analysis Xiaoqian.

Based on the differences, I think moving toward a 2nd edition REC seems 
reasonable.


Re the next publication step, it seems like the next publication should 
be a (4 week) wide review WD using Process-2014.


Re what to do with the 1st Edition errata document, rather than put 
changes in that doc, I think it would be more helpful to add a link to 
the latest ED and make sure the ED includes a summary list of changes 
since REC was published. (After the 2nd edition REC is published, the 
link could be changed to the new REC.)


Any objections to doing the above? If not, I'll start a CfC to see 
determine if we have broad consensus to proceed this way.


-Thanks, ArtB

On 5/8/15 12:58 PM, Xiaoqian Wu wrote:

Thanks for bringing this up, Anssi.

The diff between the REC and the latest Editor’s Draft[1] indicated at 
least two normative changes, so I’d like to propose a second edition 
of Web Storage. What do you say?


Here’s my analysis for the current mutex. All your comments are welcome.

* ED L174, L283
- WEBIDL Updated. The getter of the Storage interface and the key of 
the StorageEvent are Nullable;
- The test suite has been update for these changes[2][3] . These 
changes are widely implemented by the browsers.
- These changes are normative and should be accepted in the second 
edition.


* ED L187
- The supported property names on a Storage object should be in the 
order that the keys were last added to the storage area”(added).
- I wrote a test case[4] for this but the implementation doesn’t seem 
to follow this instruction. It’s more likely to be *in the order of 
keys that was defined by the user-agent*.
- Giving the fact this change is non-normative, we should either 
ignore it or update the instruction to be *in the order of keys that 
was defined by the user-agent*.


* ED L262
- Remove 4.3.1 (LocalStorage) Security.
- The former section claimed that user agents must throw a 
SecurityError whenever any of the members of a Storage object 
originally returned by the localStorage attribute are accessed by 
scripts whose effective script origin is not the same as the origin of 
the Document of the Window object on which the localStorage attribute 
was accessed.
- There was discussion[5] that this section wasn’t clear enough, 
dating back to 2012. I couldn’t find any related topics in the mailing 
list about why the editor removed this section after the Rec.
- My test case[6] indicates none of Chrome/Firefox/Safari throws the 
SecurityError in that case.

- This is a normative change and should be accepted in the second edition.

Other changes are more editorial and can be kept in the second 
edition, imo. Moreover, the archives of the Issue section need to be 
updated in the new document because the formal archives are no longer 
available.


A draft second edition of WebStorage[7](diff[8]) is available in 
GitHub. Please feel free to raise issues or PRs there.


FYI, according to the 2014 process document[9], to modify a Rec, we 
can either go through FPWD-CR-PR-REC, or if we can prove wide 
review for the changes, things will be easier, i.e., CR-PR-REC.


Thanks.

—
xiaoqian

[1] https://www.diffchecker.com/npgkwj7d
[2] https://github.com/w3c/web-platform-tests/pull/1784
[3] 
https://github.com/w3c/web-platform-tests/blob/master/webstorage/event_constructor.html
[4] 
https://github.com/siusin/web-platform-tests/blob/add_key_order_test/webstorage/keys_added_in_order.html

[5] https://bugzilla.mozilla.org/show_bug.cgi?id=762409#c17
[6] 
https://github.com/w3c/web-platform-tests/compare/master...siusin:localstorage_throws_securityerror

[7] https://github.com/w3c/webstorage
[8] https://www.diffchecker.com/dkbtofsi
[9] http://www.w3.org/2014/Process-20140801/#rec-modify

On 2015-4-30, at 8:02pm, Kostiainen, Anssi 
anssi.kostiai...@intel.com mailto:anssi.kostiai...@intel.com wrote:


Hi,

On 28 Apr 2015, at 15:46, Arthur Barstow art.bars...@gmail.com 
mailto:art.bars...@gmail.com wrote:


On 4/21/15 5:39 AM, Kostiainen, Anssi wrote:

Hi,

Is there a plan to publish an errata to sync the Web Storage Rec 
[1] with the latest? I counted 8 commits cherry picked into the 
Editor's Draft since Rec [2].


If no errata publication is planned, I'd expect the Rec to clearly 
indicate its status.


Re the priority of this issue, is this mostly a truth and beauty 
process-type request or is this issue actually creating a 
problem(s)? (If the later, I would appreciate it, if you would 
please provide some additional context.)


It was creating problems. Our QA was confused which spec was the 
authoritative one, and wrote tests (additional ones, on top of the 
w-p-t tests) against the Rec spec. These tests failed since Blink is 
compliant with the latest, not the Rec. More context at: 
https://crosswalk-project.org/jira/browse/XWALK-3527


The main thing blocking the publication of errata is a commitment 
from someone to actually do the work. I also think Ian's 

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: A Second Edition of Web Storage? [was: Re: Web Storage Rec errata?]

2015-05-12 Thread Arthur Barstow

On 5/12/15 7:57 AM, cha...@yandex-team.ru wrote:
I don't think we need a CfC to publish a WD, right? We should just 
publish it, and then open a CfC on the plan to move to 2nd edition 
with these changes incorporated, and asking if there are other changes 
we should include before we move ahead.


Yes, our SOP is not to do a CfC for a `plain` WD publication but I 
understood a `wide review WD` as a signal the spec is feature complete 
and the next step is CR+. Thus in this case, it seems like a single CfC 
to capture that, plus the other stuff I mentioned should be sufficient.


-AB





Re: A Second Edition of Web Storage? [was: Re: Web Storage Rec errata?]

2015-05-12 Thread chaals
12.05.2015, 13:35, Arthur Barstow art.bars...@gmail.com:
 Hi All,

 Thanks for this analysis Xiaoqian.

 Based on the differences, I think moving toward a 2nd edition REC seems
 reasonable.

 Re the next publication step, it seems like the next publication should
 be a (4 week) wide review WD using Process-2014.

 Re what to do with the 1st Edition errata document, rather than put
 changes in that doc, I think it would be more helpful to add a link to
 the latest ED and make sure the ED includes a summary list of changes
 since REC was published. (After the 2nd edition REC is published, the
 link could be changed to the new REC.)

 Any objections to doing the above? If not, I'll start a CfC to see
 determine if we have broad consensus to proceed this way.

I don't think we need a CfC to publish a WD, right? We should just publish it, 
and then open a CfC on the plan to move to 2nd edition with these changes 
incorporated, and asking if there are other changes we should include before we 
move ahead.

If there are no other changes people come up with, we make a CR in a few weeks. 
If there are, we need to get them reviewed - if they make sense we have a WD 
and then a CfC on whether to take that to Rec.

A couple of weeks for the CfC to give people time to check, plus a few days 
delay for publishing, seems a reasonable buffer for review, and we should be 
clear that if people need more time to check they should ask for it during the 
initial period of the CfC.

cheers

 -Thanks, ArtB

 On 5/8/15 12:58 PM, Xiaoqian Wu wrote:
  Thanks for bringing this up, Anssi.

  The diff between the REC and the latest Editor’s Draft[1] indicated at
  least two normative changes, so I’d like to propose a second edition
  of Web Storage. What do you say?

  Here’s my analysis for the current mutex. All your comments are welcome.

  * ED L174, L283
  - WEBIDL Updated. The getter of the Storage interface and the key of
  the StorageEvent are Nullable;
  - The test suite has been update for these changes[2][3] . These
  changes are widely implemented by the browsers.
  - These changes are normative and should be accepted in the second
  edition.

  * ED L187
  - The supported property names on a Storage object should be in the
  order that the keys were last added to the storage area”(added).
  - I wrote a test case[4] for this but the implementation doesn’t seem
  to follow this instruction. It’s more likely to be *in the order of
  keys that was defined by the user-agent*.
  - Giving the fact this change is non-normative, we should either
  ignore it or update the instruction to be *in the order of keys that
  was defined by the user-agent*.

  * ED L262
  - Remove 4.3.1 (LocalStorage) Security.
  - The former section claimed that user agents must throw a
  SecurityError whenever any of the members of a Storage object
  originally returned by the localStorage attribute are accessed by
  scripts whose effective script origin is not the same as the origin of
  the Document of the Window object on which the localStorage attribute
  was accessed.
  - There was discussion[5] that this section wasn’t clear enough,
  dating back to 2012. I couldn’t find any related topics in the mailing
  list about why the editor removed this section after the Rec.
  - My test case[6] indicates none of Chrome/Firefox/Safari throws the
  SecurityError in that case.
  - This is a normative change and should be accepted in the second edition.

  Other changes are more editorial and can be kept in the second
  edition, imo. Moreover, the archives of the Issue section need to be
  updated in the new document because the formal archives are no longer
  available.

  A draft second edition of WebStorage[7](diff[8]) is available in
  GitHub. Please feel free to raise issues or PRs there.

  FYI, according to the 2014 process document[9], to modify a Rec, we
  can either go through FPWD-CR-PR-REC, or if we can prove wide
  review for the changes, things will be easier, i.e., CR-PR-REC.

  Thanks.

  —
  xiaoqian

  [1] https://www.diffchecker.com/npgkwj7d
  [2] https://github.com/w3c/web-platform-tests/pull/1784
  [3]
  
 https://github.com/w3c/web-platform-tests/blob/master/webstorage/event_constructor.html
  [4]
  
 https://github.com/siusin/web-platform-tests/blob/add_key_order_test/webstorage/keys_added_in_order.html
  [5] https://bugzilla.mozilla.org/show_bug.cgi?id=762409#c17
  [6]
  
 https://github.com/w3c/web-platform-tests/compare/master...siusin:localstorage_throws_securityerror
  [7] https://github.com/w3c/webstorage
  [8] https://www.diffchecker.com/dkbtofsi
  [9] http://www.w3.org/2014/Process-20140801/#rec-modify
  On 2015-4-30, at 8:02pm, Kostiainen, Anssi
  anssi.kostiai...@intel.com mailto:anssi.kostiai...@intel.com wrote:

  Hi,
  On 28 Apr 2015, at 15:46, Arthur Barstow art.bars...@gmail.com
  mailto:art.bars...@gmail.com wrote:

  On 4/21/15 5:39 AM, Kostiainen, Anssi wrote:
  Hi,

  Is there a plan to publish an errata to sync the 

Re: A Second Edition of Web Storage? [was: Re: Web Storage Rec errata?]

2015-05-12 Thread chaals
In this case we don't know if the spec is feature complete. We just know there 
are things that need to be done.

If they turn out to be all that needs to be done the thing is feature complete, 
and we ask for CR. If not, we hope to discover so now.

But then, it's not a big deal either way. It just feels odd calling a draft a 
wide review draft, as if we didn't want that on other drafts. And fails to 
match what the Process requests of Working drafts which is that they all 
identify which bits they particularly want reviewed - changes, the whole 
thing, missing bits, …

cheers

12.05.2015, 14:05, Arthur Barstow art.bars...@gmail.com:
 On 5/12/15 7:57 AM, cha...@yandex-team.ru wrote:
  I don't think we need a CfC to publish a WD, right? We should just
  publish it, and then open a CfC on the plan to move to 2nd edition
  with these changes incorporated, and asking if there are other changes
  we should include before we move ahead.

 Yes, our SOP is not to do a CfC for a `plain` WD publication but I
 understood a `wide review WD` as a signal the spec is feature complete
 and the next step is CR+. Thus in this case, it seems like a single CfC
 to capture that, plus the other stuff I mentioned should be sufficient.

 -AB

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



Re: A Second Edition of Web Storage? [was: Re: Web Storage Rec errata?]

2015-05-12 Thread Kostiainen, Anssi
Hi,

 On 08 May 2015, at 19:58, Xiaoqian Wu xiaoq...@w3.org wrote:
 
 Thanks for bringing this up, Anssi.
 
 The diff between the REC and the latest Editor’s Draft[1] indicated at least 
 two normative changes, so I’d like to propose a second edition of Web 
 Storage. What do you say?
 
 Here’s my analysis for the current mutex. All your comments are welcome.

[...]

Thanks for the analysis. We'll review. If a Second Edition would allow us to 
fix the /TR then that sounds good.

Thanks,

-Anssi