[Bug 22194] New: Clarificaiton of 'enabled' property behavior

[bugzilla]

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

Bug ID: 22194
   Summary: Clarificaiton of 'enabled' property behavior
Classification: Unclassified
   Product: WebAppsWG
   Version: unspecified
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P2
 Component: IME API
  Assignee: ko...@google.com
  Reporter: ko...@google.com
QA Contact: public-webapps-bugzi...@w3.org
CC: m...@w3.org, public-webapps@w3.org

Even though the spec assumes that the 'enabled' property associated with
the context can be used to detect whether the IME is turned on or not,
but for some cases it may not work as intended.

On Chromium (and possibly other browsers) a real IME context is shared in a
browser, and the state of the IME may change on focus change.

To illustrate this, if a page has one input field which has focus and
IME is turned on, context.enabled is expected to return true.
But once outside of the input field is clicked, the browser turns off IME.
A naive implementation of .enabled property will return false in that case,
but the state of IME will be restored when the input field gets focus again,
and .enabled returns true.

Webapps developers may assume that the state won't change on focus change.

Possible solutions:

1. Do not change the spec.

Users of the API will accept the behavior as is and let the behavior
implementation dependent.

2. Hold the .enabled state within context and restore when it gets focus

Retain the state and change the state only when the field has focus,
and once it loses focus and gets focus again, then restore the state.

This may be an expected behavior of most developers.

3. Remove .enabled from the spec

As .enabled may not be implemented on Mac/Android, it may be a good
idea to abandon .enabled and focus on having 'inputmode' attribute.
Microsoft's proposal also dropped .enabled (for the reason that
it won't support the case for non-editable element, though).

4. none of the above

Any other ideas?

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

Re: [editing] nested contenteditable

[河内 隆仁]

+Ryosuke - he is actively working on editing in WebKit.


On Wed, May 29, 2013 at 2:27 AM, Travis Leithead <
travis.leith...@microsoft.com> wrote:

>  As far as I know, there is no actively maintained editing spec at the
> moment. Aryeh’s document is a great start but by no means should it be
> considered complete, or the standard to which you should target an
> implementation… I think we would [currently] prefer to discuss specific
> issues here on the mailing list until a regular editor can be found—so
> thanks for bringing this up!
>
> ** **
>
> By the way, what you suggest sounds reasonable for the behavior.
>
> ** **
>
> *From:* johannesw...@gmail.com 
> [mailto:johannesw...@gmail.com]
> *On Behalf Of *Johannes Wilm
> *Sent:* Tuesday, May 28, 2013 6:36 AM
> *To:* public-webapps@w3.org; ro...@w3.org; Alex Mogilevsky; Travis
> Leithead; a...@aryeh.name; yo...@chromium.org
> *Subject:* [editing] nested contenteditable
>
> ** **
>
> Hey,
>
> is there any progress on finding out who is to maintain this spec:
> https://dvcs.w3.org/hg/editing/raw-file/tip/editing.htm ? Is Aryeh still
> a fulltime student?
>
> ** **
>
> There is an effort at Chromium to make deletion of non-editable
> subelements work according to the spec, but the spec doesn't seem to
> anything about this. 
>
> ** **
>
> See: https://code.google.com/p/chromium/issues/detail?id=238000
> 
>
> ** **
>
> ** **
>
> Who could we ask to get the sepcification updated with information about
> this? 
>
> ** **
>
> Our current suggestion is that backspacing/deleting into it selects it,
> and a second hit on backspace/delete will remove it. The most important to
> me though is to have clarity on this.
>
> ** **
>
> ** **
>
> -- 
>
> Johannes Wilm
>
> Fidus Writer
>
> http://www.fiduswriter.com
>



-- 
Takayoshi Kochi

[Bug 21993] Change .getInputContext() to .inputMethodContext

[bugzilla]

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

Takayoshi Kochi  changed:

   What|Removed |Added

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

--- Comment #2 from Takayoshi Kochi  ---
Changed Editor's draft to .inputMethodContext.

https://dvcs.w3.org/hg/ime-api/raw-file/default/Overview.html

Reopen this or file a new bug if this doesn't work.

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

[editing] nested contenteditable

[Johannes Wilm]

Hey,
is there any progress on finding out who is to maintain this spec:
https://dvcs.w3.org/hg/editing/raw-file/tip/editing.htm ? Is Aryeh still a
fulltime student?

There is an effort at Chromium to make deletion of non-editable subelements
work according to the spec, but the spec doesn't seem to anything about
this.

See: https://code.google.com/p/chromium/issues/detail?id=238000


Who could we ask to get the sepcification updated with information about
this?

Our current suggestion is that backspacing/deleting into it selects it, and
a second hit on backspace/delete will remove it. The most important to me
though is to have clarity on this.


-- 
Johannes Wilm
Fidus Writer
http://www.fiduswriter.com

[editing] deletion and moving caret across stub and contenteditable=false elements (was: Re: [editing] nested contenteditable)

[Johannes Wilm]

Ok, great!

Then I have three other, slightly related suggestions which I would be
interested in hearing your opinion about:

1. How should the stub elements images, canvas elements and inline SVGs be
treated in a contenteditable environment?

My suggestion is that they are treated the same: as if they were individual
letters. That means that moving the cursor across them (hitting right or
left while it the caret is directly to the right or left of it) should move
the cursor all the way across them, but no further. The caret should be
able to go between two stub elements, and before a stub element at the very
start of a paragraph and after a stub element at the very end of a
paragraph.

This is already the current behavior for  -elements in IE10, Chrome
and FF.

Chrome fails at inline SVG elements, but handles canvas elements this way
already.
FF fails at canvas elements but handles inline SVG elements this way
already.
IE10 fails moving across canvas elements, but handles SVG elements this way
already.

See the first three examples of these bug reports:

https://bugzilla.mozilla.org/show_bug.cgi?id=873883
https://code.google.com/p/chromium/issues/detail?id=242110

2. How should contenteditable=false elements be handled that do not have a
nested contenteditable=true inside of them?

I suggest that they are handled the same way as those that do have a
contenteditable=true element inside of them wen it comes to
backspace/delete: if the caret is on one side of the element and the
backspace (when caret is on right side)/delete key (when caret is on left
side) is hit, they are selected entirely (as described in my previous
email). A second hit will remove them entirely. This is the way this
specification draft suggests handling tables.


3. What should happen if the caret moves across contenteditable=false
WITHOUT nested contenteditable=true elements?

I suggest that it should behave like stub elements (point 1).

This is already the behavior of Chrome.
FF moves across them, but jumps an extra letter.
IE10 jumps to the start of the contenteditable element.

The behavior of IE10 and FF does not seem sensible.

4. What should happen if the caret moves across contenteditable=false WITH
nested contenteditable=true elements?

I suggest the caret should move inside the nested elements asmit has been
described in previous specs.

None of the browsers seem to work very well with that scenario currently.

*) tested with Chrome 29, FF 21, IE 10.0.9200.16580


On Tue, May 28, 2013 at 1:27 PM, Travis Leithead <
travis.leith...@microsoft.com> wrote:

>  As far as I know, there is no actively maintained editing spec at the
> moment. Aryeh’s document is a great start but by no means should it be
> considered complete, or the standard to which you should target an
> implementation… I think we would [currently] prefer to discuss specific
> issues here on the mailing list until a regular editor can be found—so
> thanks for bringing this up!
>
> ** **
>
> By the way, what you suggest sounds reasonable for the behavior.
>
> ** **
>
> *From:* johannesw...@gmail.com 
> [mailto:johannesw...@gmail.com]
> *On Behalf Of *Johannes Wilm
> *Sent:* Tuesday, May 28, 2013 6:36 AM
> *To:* public-webapps@w3.org; ro...@w3.org; Alex Mogilevsky; Travis
> Leithead; a...@aryeh.name; yo...@chromium.org
> *Subject:* [editing] nested contenteditable
>
> ** **
>
> Hey,
>
> is there any progress on finding out who is to maintain this spec:
> https://dvcs.w3.org/hg/editing/raw-file/tip/editing.htm ? Is Aryeh still
> a fulltime student?
>
> ** **
>
> There is an effort at Chromium to make deletion of non-editable
> subelements work according to the spec, but the spec doesn't seem to
> anything about this. 
>
> ** **
>
> See: https://code.google.com/p/chromium/issues/detail?id=238000
> 
>
> ** **
>
> ** **
>
> Who could we ask to get the sepcification updated with information about
> this? 
>
> ** **
>
> Our current suggestion is that backspacing/deleting into it selects it,
> and a second hit on backspace/delete will remove it. The most important to
> me though is to have clarity on this.
>
> ** **
>
> ** **
>
> -- 
>
> Johannes Wilm
>
> Fidus Writer
>
> http://www.fiduswriter.com
>



-- 
Johannes Wilm
Fidus Writer
http://www.fiduswriter.com

Re: [webcomponents]: First sketch of element

[Dimitri Glazkov]

I fixed bug 22079 in https://dvcs.w3.org/hg/webcomponents/rev/879790e093f8.

The gist of the change:
* when parser sees declarations, it adds them into a queue
* the queue is emptied at a microtask checkpoint.
* weee!

:DG<

On Tue, May 21, 2013 at 1:02 PM, Dimitri Glazkov  wrote:
> As promised in 
> http://lists.w3.org/Archives/Public/public-webapps/2013AprJun/0685.html,
> I sketched out custom element declarative syntax using the "last
> completion value" idea:
>
> https://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/custom/index.html#declaring-custom-elements
>
> Please look it over. I am sure there are bugs. Think of them as prizes
> for the first-graders' egg hunt. Of course, if you're a fourth-grader,
> you'll spot the eggs away. But you won't scream in delight. Because
> you're cool now.
>
> As I was writing this down, I ran into the following issues:
>
> https://www.w3.org/Bugs/Public/show_bug.cgi?id=22077: How to process
> "constructor name" of element declaration?
>
> https://www.w3.org/Bugs/Public/show_bug.cgi?id=22079: How to transfer
> callbacks when declarations are being processed by parser?
>
> https://www.w3.org/Bugs/Public/show_bug.cgi?id=22126: Should 
> support declaring SVG elements?
>
> Bugs 22077 and 22079 are rather disturbing to me. I would rather not
> introduce more places where parser runs script.
>
> :DG<

Re: Re: Re: Re: Re: [XHR] anonymous flag

[Jonas Sicking]

On Tue, May 28, 2013 at 7:07 AM, Hallvord Reiar Michaelsen Steen
 wrote:
> I wrote:
>
>> I would like to see some real code evidence that omitting Origin:
>> and Referer: is necessary too. In theory sites might use them as
>> "credentials" as you say, but in practise I don't see how that can
>> work and be safe on the web.
>>
>
>> If we ship XHR with an "anonymous" flag removing Origin: and Referer:
>> and call it a security feature, wouldn't that *encourage* sites to
>> validate requests by Origin: and Referer:? Aren't we basically pushing
>> snake oil security measures if we do so?
>
>
>
> I hereby propose that we drop the {anonymous:true} constructor argument and 
> the "anonymous flag", and instead modify withCredentials to take three 
> values: "samedomain" (default), "always" and "never". For backwards 
> compatibility with earlier versions of the spec, setting withCredentials=true 
> maps to "always" and withCredentials=false maps to "samedomain".
>
>
> This seems easier to understand, easier to implement, and handles all use 
> cases of practical significance.

I'm opposed to this change. Trying to modify a boolean value into a
tristate can't be done fully backwards compatibly. Specifically, I
don't see a way to define this new behavior in such a way that reading
from withCredentials behaves in a backwards compatible way. At least
not while keeping the API sane.

I'd instead prefer to define a new property.

/ Jonas

RE: [editing] nested contenteditable

[Travis Leithead]

As far as I know, there is no actively maintained editing spec at the moment. 
Aryeh's document is a great start but by no means should it be considered 
complete, or the standard to which you should target an implementation... I 
think we would [currently] prefer to discuss specific issues here on the 
mailing list until a regular editor can be found-so thanks for bringing this up!

By the way, what you suggest sounds reasonable for the behavior.

From: johannesw...@gmail.com 
[mailto:johannesw...@gmail.com] On Behalf Of Johannes Wilm
Sent: Tuesday, May 28, 2013 6:36 AM
To: public-webapps@w3.org; 
ro...@w3.org; Alex Mogilevsky; Travis Leithead; 
a...@aryeh.name; 
yo...@chromium.org
Subject: [editing] nested contenteditable

Hey,
is there any progress on finding out who is to maintain this spec: 
https://dvcs.w3.org/hg/editing/raw-file/tip/editing.htm ? Is Aryeh still a 
fulltime student?

There is an effort at Chromium to make deletion of non-editable subelements 
work according to the spec, but the spec doesn't seem to anything about this.

See: https://code.google.com/p/chromium/issues/detail?id=238000


Who could we ask to get the sepcification updated with information about this?

Our current suggestion is that backspacing/deleting into it selects it, and a 
second hit on backspace/delete will remove it. The most important to me though 
is to have clarity on this.


--
Johannes Wilm
Fidus Writer
http://www.fiduswriter.com

Re: Re: Re: Re: Re: [XHR] anonymous flag

[Hallvord Reiar Michaelsen Steen]

I wrote: 

> I would like to see some real code evidence that omitting Origin:
> and Referer: is necessary too. In theory sites might use them as
> "credentials" as you say, but in practise I don't see how that can
> work and be safe on the web.
>  

> If we ship XHR with an "anonymous" flag removing Origin: and Referer:
> and call it a security feature, wouldn't that *encourage* sites to
> validate requests by Origin: and Referer:? Aren't we basically pushing
> snake oil security measures if we do so?



I hereby propose that we drop the {anonymous:true} constructor argument and the 
"anonymous flag", and instead modify withCredentials to take three values: 
"samedomain" (default), "always" and "never". For backwards compatibility with 
earlier versions of the spec, setting withCredentials=true maps to "always" and 
withCredentials=false maps to "samedomain". 


This seems easier to understand, easier to implement, and handles all use cases 
of practical significance.



Anne: if you want rewrite proposals as pull requests, let me know ;-)

-- 
Hallvord R. M. Steen
Core tester, Opera Software

RfC: 2nd Last Call of "Vibration API"; deadline June 13

[Arthur Barstow]

[ Bcc: public-script-coord ]

WebApps was asked to review DAPWG's Vibration API second LCWD 
.


Individual WG members are encouraged to provide individual feedback.

If anyone in WebApps wants to propose an official WG response, please do 
so ASAP, in reply to this email so the WG can discuss it.


Comments should be sent to public-device-a...@w3.org by June 13.

-Thanks, ArtB

 Original Message 
Subject: 	2nd Last Call of "Vibration API" published by DAP - comment 
requested by 13 June 2013

Date:   Thu, 23 May 2013 13:54:20 -0400
From:   Hirsch Frederick (Nokia-CIC/Boston) 
To: Chairs Chairs 
CC: 	ext Dominique Hazael-Massieux , ext Paul Cotton 
, Maciej Stachowiak , ext 
Charles McCathie Nevile , "Barstow Art 
(Nokia-CIC/Boston)" , "ru...@intertwingly.net" 
, Anne van Kesteren , Justin 
Lebar , "ext Kostiainen, Anssi" 
, "Hirsch Frederick (Nokia-CIC/Boston)" 





Art, Chaals, Paul, Maciej, Sam

The Device API Working Group [1] has published  a second Last Call working draft of the 
"Vibration API" specification  today, 23 May 2013 [2] and requests review 
comments from your groups (Web Applications WG, HTML WG). We are also interested in 
comments from others. The changes, based on review feedback during CR, are noted in the 
status section.

The draft is available at  http://www.w3.org/TR/2013/WD-vibration-20130523/

The Last Call period ends 13 June 2013 (3 weeks) - please send comments to the DAP public 
mailing list with "[vibration]" at the start of the Subject line. Indications 
of support for the change are welcome.

Thanks

regards, Frederick

Frederick Hirsch, Nokia
Chair, W3C DAP Working Group

[1] http://www.w3.org/2009/dap/

[2] http://www.w3.org/News/2013#entry-9836