Re: WebIDL Spec Status

[Glenn Adams]

On Mon, Jun 23, 2014 at 3:05 PM, Marcos  wrote:

>
>
> On June 23, 2014 at 4:07:09 PM, Glenn Adams (gl...@skynav.com) wrote:
> > What is the plan, i.e., schedule timeline, for moving WebIDL to REC? We
> > have now a two year old CR that appears to be stuck and a 2nd Edition
> that
> > I'm not sure has made it to FPWD.
> >
> > Given the high degree of dependency from other specs and implementations
> on
> > this work, we really need to find a way to wrap up this work or at least
> > publish something reasonably stable.
>
>
> IMO, we should just concede that this document needs to be a Living
> Standard (tm).


I don't mind there being a "living standard" form of the document. But that
is not sufficient. There must be some final REC version of some
edition/snapshot of this work that provides a non-movable mark for
real-world compliance testing and device certification.


> Trying to move this through the W3C process is clearly not working.


There is no reason it can't or shouldn't.


> Even if we were able to take the V1 bits to Rec (a lot of which is now
> obsolete), the V2 stuff is already widely supported and heavily relied on
> by browser vendors. IMO, it's a waste of everyone's time to try to maintain
> multiple versions.
>

I agree that the V1 CR should be abandoned or replaced with a completed
snapshot of V2. Though it would be useful to ask a wider community about
the value of moving some flavor of V1 to REC.


>
> --
> Marcos Caceres
>
>
>

RE: [editing] Changing Default Intentions

[Ben Peters]

On Fri, Jun 20, 2014 at 8:28 PM, Ryosuke Niwa  wrote:
> This means execCommand is available for other uses. Since it's a legacy API 
> that doesn't have the best shape, perhaps it is best to tie it to the legacy 
> behavior. So the image [1] now shows that execCommand (lower right) would 
> cause the browser to actually perform the command, not fire a CommandEvent. 
> In effect, execCommand('bold') is the default behavior for CommandEvent type 
> bold in contentEditable="true". In contentEditable="minimal" or equivalent, 
> CommandEvent type bold has no default. If a site wishes to use the built-in 
> bold, they can call execCommand('bold') in the CommandEvent, thereby 
> restoring contentEditable="true" behavior for that specific command.
>
>
> execCommand not triggering command event seems like a promising approach.  I 
> think we really need a concrete list of use cases here though.  It's hard to 
> design & evaluate proposals without having a list of concrete use cases 
> against which we're evaluating proposals.

Agreed. Better use cases and goals is my next project. Expect an update soon.

RE: Editing with native UI (was: [editing] CommandQuery Object and Event)

[Ben Peters]

> From: Robin Berjon [mailto:ro...@w3.org]
> 
> On 06/06/2014 18:39 , Ryosuke Niwa wrote:
> > On Jun 6, 2014, at 4:29 AM, Piotr Koszuliński
> >  wrote:
> >> 1. That we need any native UI related to cE at all. We don't. We can
> >> display our own toolbars, with our own buttons, with our own icons
> >> and implementing our own logic. So the easiest solution to the
> >> problem with irrelevant native UI is to not display it at all.
> >
> > You may not need native UI working at all in your app, but that
> > doesn't mean all other developers don't want it at all.  Furthermore,
> > enabled-ness of items in desktop browser's edit menu should reflect
> > the current state of the editor; otherwise, it would degrade the user
> > experience.
> >
> > Furthermore, we shouldn't design our API only for existing platforms.
> > We need to make it so that new, completely different paradigm of UIs
> > and devices could be built using new API we design.
> >
> > Another important use case for browsers to know the state of the
> > editor is for accessibility.  AT may, for example, want to enumerate
> > the list of commands available on the page for the user.
> 
> All of these are good points, but the fact remains that if a browser 
> unilaterally
> decides to exposes a new editing behaviour that I as author don't know
> about, it could very easily break my script.
> 
> Also, if the browser includes a "bold" command by default and I don't
> support bolding and therefore cancel the event, the user who has been
> relying on the native UI is getting the worst possible experience:
> native controls that do nothing at all.

This doesn't seem like an insurmountable problem. We can provide a way for 
sites to indicate that they support certain commands and not others, similar to 
queryCommandEnabled(), which has a return value that could be modified by 
javascript (perhaps by an event, say QueryCommandEvent). Then the browser could 
choose not to show buttons for commands that are disabled.

> Conversely, if I support something that the native UI does not expose (say,
> superscripting) it makes for a weird UI in which some things are exposed and
> others aren't.

Good point.

> There is an option that:
> 
>• Can be styled in the page according to author wishes.
>• Can interact with native controls.
>• Can integrate with accessibility.
> 
> It relies on using all bits of new stuff in HTML: commands, contextMenu, and
> friends. I would *strongly* suggest that contentEditable=minimal would
> *only* have native UI based on things specified with this and not anything
> else by default. Native UI atop custom editing is really a solution for 
> breakage.
> 
> We can also make it smart and able to tap into higher-level intention events
> such as knowing the platform's localised shortcut for a given action.
> 
> --
> Robin Berjon - http://berjon.com/ - @robinberjon

Re: IDBObjectStore/IDBIndex.exists(key)

[Marc Fawzi]

<<
We can do synchronous tests against the schema as it is feasible for 
implementations to maintain a copy of the current schema for an open connection 
in memory in the same thread/process as script. (Or at least, no implementer 
has complained.)
>>

Oh cool. So I could have a 3rd party component in my app that can then test the 
schema directly and run certain functions only if some combination of 
conditions are met and having those test be synchronous makes the tests simple. 
For example, does xyz object store exist and does it have the right indices. If 
so then the component would run. Else it wouldn't. 

I get the thing about the cost of looking up a value and why that has to be 
asynchronous.

Jonas,

I have no request per se, just super curious about the rationalizations  around 
v2 APIs, so I might have questions or curiosity that are expressed indirectly 
as suggestion. Sometimes I say naive things and other times the suggestions may 
be directly useful or bring up some other thoughts. I'll try to minimize the 
confusion. But do look out there: almost every front end developer I've talked 
to things IndexedDB is less than usable and the library makers haven't yet 
provided something both truly solid and worth throwing the native APIs for, so 
I'm trying to understand things better for myself so I can help build a better 
library but would rather have the IDB native API come to a point in its 
evolution where front end developers would be able to consume it directly with 
no intervening layer, and that's why  asking and making sometimes dumb and 
sometimes useful suggestions, to try and understand how the IDB designers 
think. If that actually makes any sense.


Sent from my iPhone

> On Jun 23, 2014, at 2:22 PM, Joshua Bell  wrote:
> 
> We can do synchronous tests against the schema as it is feasible for 
> implementations to maintain a copy of the current schema for an open 
> connection in memory in the same thread/process as script. (Or at least, no 
> implementer has complained.)

Re: IDBObjectStore/IDBIndex.exists(key)

[Joshua Bell]

On Mon, Jun 23, 2014 at 1:38 PM, Marc Fawzi  wrote:

> No, I was suggesting .exists() can be synchronous to make it useful
>
> I referred to it as .contains() too so sorry if that conflated them for
> you but it has nothing to do with the .contains Joshua was talking about.
>
> In short, an asynchronous .exists() as you proposed does seem redundant
>
> But I was wondering what about a synchronous .exists() (the same proposal
> you had but synchronous as opposed to asynchronous)
>
>
We can do synchronous tests against the schema as it is feasible for
implementations to maintain a copy of the current schema for an open
connection in memory in the same thread/process as script. (Or at least, no
implementer has complained.)

Actually hitting the backing store to look up a particular value may
require a thread/process hop, so must be an asynchronous operation.
Actually pulling the *data* across and decoding it is an added expense,
which is why count(), the proposed exists(), and key cursors exist as
optimizations over get() and regular cursors.





> Makes any sense?
>
> Sent from my iPhone
>
> > On Jun 23, 2014, at 1:28 PM, Jonas Sicking  wrote:
> >
> >> On Mon, Jun 23, 2014 at 1:03 PM, Marc Fawzi 
> wrote:
> >> Having said that, and speaking naively here, a synchronous .exists() or
> .contains() would be useful as "existence" checks shouldn't have to be
> exclusively asynchronous as that complicates how we'd write: "if this
> exists and that other thing doesn't exists then do xyz"
> >
> > Note that the .contains() discussion is entirely separate from the
> > .exists() discussion. I.e. your subject is entirely off-topic to this
> > thread.
> >
> > The .exists() function I proposed lives on IDBObjectStore and IDBIndex
> > and is an asynchronous database operation.
> >
> > The .contains() function that you are talking about lives on an
> > array-like object and just does some in-memory tests which means that
> > it's synchronous.
> >
> > So the two are completely unrelated.
> >
> > / Jonas
>

Re: IDBObjectStore/IDBIndex.exists(key)

[Jonas Sicking]

On Mon, Jun 23, 2014 at 1:38 PM, Marc Fawzi  wrote:
> No, I was suggesting .exists() can be synchronous to make it useful
>
> I referred to it as .contains() too so sorry if that conflated them for you 
> but it has nothing to do with the .contains Joshua was talking about.
>
> In short, an asynchronous .exists() as you proposed does seem redundant
>
> But I was wondering what about a synchronous .exists() (the same proposal you 
> had but synchronous as opposed to asynchronous)
>
> Makes any sense?

We can't make any database operations synchronous since that require
synchronous IO which is really bad for perf. It's also different from
all other database operations. So if that's your request then the
answer is definitely no.

/ Jonas


> Sent from my iPhone
>
>> On Jun 23, 2014, at 1:28 PM, Jonas Sicking  wrote:
>>
>>> On Mon, Jun 23, 2014 at 1:03 PM, Marc Fawzi  wrote:
>>> Having said that, and speaking naively here, a synchronous .exists() or 
>>> .contains() would be useful as "existence" checks shouldn't have to be 
>>> exclusively asynchronous as that complicates how we'd write: "if this 
>>> exists and that other thing doesn't exists then do xyz"
>>
>> Note that the .contains() discussion is entirely separate from the
>> .exists() discussion. I.e. your subject is entirely off-topic to this
>> thread.
>>
>> The .exists() function I proposed lives on IDBObjectStore and IDBIndex
>> and is an asynchronous database operation.
>>
>> The .contains() function that you are talking about lives on an
>> array-like object and just does some in-memory tests which means that
>> it's synchronous.
>>
>> So the two are completely unrelated.
>>
>> / Jonas

Re: WebIDL Spec Status

[Marcos]

On June 23, 2014 at 4:07:09 PM, Glenn Adams (gl...@skynav.com) wrote:
> What is the plan, i.e., schedule timeline, for moving WebIDL to REC? We
> have now a two year old CR that appears to be stuck and a 2nd Edition that
> I'm not sure has made it to FPWD.
>  
> Given the high degree of dependency from other specs and implementations on
> this work, we really need to find a way to wrap up this work or at least
> publish something reasonably stable.


IMO, we should just concede that this document needs to be a Living Standard 
(tm). Trying to move this through the W3C process is clearly not working. Even 
if we were able to take the V1 bits to Rec (a lot of which is now obsolete), 
the V2 stuff is already widely supported and heavily relied on by browser 
vendors. IMO, it's a waste of everyone's time to try to maintain multiple 
versions. 

-- 
Marcos Caceres

Re: IDBObjectStore/IDBIndex.exists(key)

[Marc Fawzi]

No, I was suggesting .exists() can be synchronous to make it useful

I referred to it as .contains() too so sorry if that conflated them for you but 
it has nothing to do with the .contains Joshua was talking about.

In short, an asynchronous .exists() as you proposed does seem redundant 

But I was wondering what about a synchronous .exists() (the same proposal you 
had but synchronous as opposed to asynchronous) 

Makes any sense?

Sent from my iPhone

> On Jun 23, 2014, at 1:28 PM, Jonas Sicking  wrote:
> 
>> On Mon, Jun 23, 2014 at 1:03 PM, Marc Fawzi  wrote:
>> Having said that, and speaking naively here, a synchronous .exists() or 
>> .contains() would be useful as "existence" checks shouldn't have to be 
>> exclusively asynchronous as that complicates how we'd write: "if this exists 
>> and that other thing doesn't exists then do xyz"
> 
> Note that the .contains() discussion is entirely separate from the
> .exists() discussion. I.e. your subject is entirely off-topic to this
> thread.
> 
> The .exists() function I proposed lives on IDBObjectStore and IDBIndex
> and is an asynchronous database operation.
> 
> The .contains() function that you are talking about lives on an
> array-like object and just does some in-memory tests which means that
> it's synchronous.
> 
> So the two are completely unrelated.
> 
> / Jonas

Re: IDBObjectStore/IDBIndex.exists(key)

[Jonas Sicking]

On Mon, Jun 23, 2014 at 1:03 PM, Marc Fawzi  wrote:
> Having said that, and speaking naively here, a synchronous .exists() or 
> .contains() would be useful as "existence" checks shouldn't have to be 
> exclusively asynchronous as that complicates how we'd write: "if this exists 
> and that other thing doesn't exists then do xyz"

Note that the .contains() discussion is entirely separate from the
.exists() discussion. I.e. your subject is entirely off-topic to this
thread.

The .exists() function I proposed lives on IDBObjectStore and IDBIndex
and is an asynchronous database operation.

The .contains() function that you are talking about lives on an
array-like object and just does some in-memory tests which means that
it's synchronous.

So the two are completely unrelated.

/ Jonas

WebIDL Spec Status

[Glenn Adams]

What is the plan, i.e., schedule timeline, for moving WebIDL to REC? We
have now a two year old CR that appears to be stuck and a 2nd Edition that
I'm not sure has made it to FPWD.

Given the high degree of dependency from other specs and implementations on
this work, we really need to find a way to wrap up this work or at least
publish something reasonably stable.

Regards,
Glenn

Re: IDBObjectStore/IDBIndex.exists(key)

[Marc Fawzi]

Joshua,

you're on, and I'll be happy to make suggestions once I've thought them 
through... At least to some extent :)

Jonas,

<<
There is a small performance difference between them though when
applied to indexes. Indexes could have multiple entries with the same
key (but different primaryKey), in which case count() would have to
find all such entries, whereas exists() would only need to find the
first.
>>

Isn't it also possible to open cursor on an index with IDBKeyRange.only(key) ? 
Wouldn't that confirm/deny existence and you may abandon the cursor/transaction 
after it. 

Having said that, and speaking naively here, a synchronous .exists() or 
.contains() would be useful as "existence" checks shouldn't have to be 
exclusively asynchronous as that complicates how we'd write: "if this exists 
and that other thing doesn't exists then do xyz" 

However, a good Promises implementation (see Dexie.js as a potential 
inspiration/candidate for such) may allow us to work with such asynchronous 
existence checks in a way that keeps the code complexity manageable.

Take all this with a grain of salt. I'm learning how to use IDB as I go and 
these are my mental notes during this process, so not always making total 
sense. 

Marc

Sent from my iPhone

> On Jun 23, 2014, at 12:21 PM, Jonas Sicking  wrote:
> 
> There is a small performance difference between them though when
> applied to indexes. Indexes could have multiple entries with the same
> key (but different primaryKey), in which case count() would have to
> find all such entries, whereas exists() would only need to find the
> first.

Re: IDBObjectStore/IDBIndex.exists(key)

[Jonas Sicking]

On Mon, Jun 23, 2014 at 9:59 AM, Joshua Bell  wrote:
> On Sat, Jun 21, 2014 at 9:45 PM, ben turner  wrote:
>>
>> I think this sounds like a fine idea.
>>
>> -Ben Turner
>>
>>
>> On Sat, Jun 21, 2014 at 5:39 PM, Jonas Sicking  wrote:
>>>
>>> Hi all,
>>>
>>> I found an old email with notes about features that we might want to put
>>> in v2.
>>>
>>> Almost all of them was recently brought up in the recent threads about
>>> IDBv2. However there was one thing on the list that I haven't seen brought
>>> up.
>>>
>>> It might be a nice perf improvement to add support for a
>>> IDBObjectStore/IDBIndex.exists(key) function.
>
> This sounds redundant with count().
>
> Was count() added to the spec after that note was written? (count() seems to
> be a relatively late addition, given that it occurs last in the IDLs)

Hmm.. good point. It is indeed very possible that I wrote that note
before we had count().

There is a small performance difference between them though when
applied to indexes. Indexes could have multiple entries with the same
key (but different primaryKey), in which case count() would have to
find all such entries, whereas exists() would only need to find the
first.

But most of the time count() probably does well enough.

/ Jonas

[Bug 26181] New: Spec should specify the presentation of the array returned by navigator.getGamepads() w.r.t "holes"

[bugzilla]

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

Bug ID: 26181
   Summary: Spec should specify the presentation of the array
returned by navigator.getGamepads() w.r.t "holes"
   Product: WebAppsWG
   Version: unspecified
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P2
 Component: Gamepad
  Assignee: t...@mielczarek.org
  Reporter: t...@mielczarek.org
QA Contact: public-webapps-bugzi...@w3.org
CC: m...@w3.org, public-webapps@w3.org

Currently the spec is silent about how the gamepad array should look in the
face of removing Gamepads.

What Firefox implements (I need to check other browsers) is like:


navigator.getGamepads() == []


navigator.getGamepads() == [Gamepad]


navigator.getGamepads() == [Gamepad, Gamepad]


navigator.getGamepads() == [null, Gamepad]

The intent is that the array is always at least max(Gamepad.index)+1 length,
and entries where there's no longer a Gamepad present are "holes". Firefox uses
null for their values, but Chrome and IE use undefined, so the spec should
clarify that. (undefined seems sensible)

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

[Bug 25914] No definition of parsing blob's scheme data

[bugzilla]

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

Arun  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |FIXED

--- Comment #29 from Arun  ---
(In reply to Anne from comment #28)
> Don't check for "parse error", see if the algorithm returns failure.


Done!


> Also, it may not return a host or port. You should probably check if it's a
> relative scheme.


It's true that it could be a relative scheme, so I check for a relative scheme
per your advice. But, it will never be a relative URL; that is, the recursive
invocation of the basic URL parser will never also be fed a base URL. So, host
will always be extractable, since the emitter methods (URL.createFor and
URL.createObjectURL) will always emit a full origin string, namely the
effective script origin specified by the settings object.

> 
> I think you probably just want to parse it and then say something like
> "return /parsedURL/'s origin".


Done! 

> But maybe I should just bite the bullet and define origin for all URL
> schemes we care about.


If you do this, some portions of this in File API might be made redundant.
We've already made the section on request-response informative; other sections
may follow suit.

Please give it a check: 
http://dev.w3.org/2006/webapi/FileAPI/#extractionOfOriginFromIdentifier

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

[Bug 25987] Blob URL parsing / fetching model

[bugzilla]

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

Bug 25914 Summary: No definition of parsing blob's scheme data
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25914

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |FIXED

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

Re: [editing] selection across editing host boundaries

[Johannes Wilm]

I filed bugs on this on both Firefox and Chrome in spring 2013. It was
briefly fixed in Chrome, but the fix was then retracted and we never heard
any more of it. It was also reported in Firefox by someone else in 2011. [1]

I also had some contact with Webkit people working in this area who
unfortunately didn't find the behavior to be problematic.

This is probably the main reason why at least I am wondering if editing
maybe just is an area that won't be of enough interest to browser makers to
ever fix and that it may therefore just make more sense to just ask them to
remove it and do everything in Javascript. But now it seeems this is about
to change, which would be really really good.

Use cases for this:

1. We use it for footnotes which we float of to the right of the text in a
[FOOTNOTE TEXT]. If one has
access to CSS regions, one can even float them to be under the text on each
page. The other  is used to draw the footnote number
in the main text. If one hits backspace behind it, the entire footnote
should disappear. as it is now, instead the "back wall" of the footnote is
removed  which means that the rest of the paragraph is being added to the
footnote.


2. Figures with captions:


  blablablabla
  


  
  blablablabla




1) See
https://code.google.com/p/chromium/issues/detail?id=242110

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

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


On Mon, Jun 23, 2014 at 6:03 PM, Robin Berjon  wrote:

> On 07/06/2014 15:15 , Xavier Morel wrote:
>
>> I've been working with @contenteditable and I've hit a case where
>> one browser family (Webkit) seems to behave very differently than the
>> others (tested: Firefox and MSIE). The situation is nested editing
>> hosts: when starting a selection from the inner editing host, the
>> selection stops at the host boundary in all cases. However when starting
>> the selection from the outer editing host and entering the inner one,
>>
>> * MSIE and Gecko treat the inner editing host as an opaque item (a
>>character, or a non-editable element embedded in the editable one),
>>either none of the inner host is selected or all of it is part of
>>the overall selection
>>
>> * Webkit-ish browsers (Safari and Chrome) on the other hand extend the
>>selection within the inner editing host (so the selection can be half
>> in
>>and half out)
>>
>> The issue is, in the case of webkit browsers, when an edition is then
>> performed they start moving stuff across the editing host boundary, and
>> text goes in or out of the inner host (depending on the direction of the
>> selection), generally ending up in an unrecoverable mess and panicking
>> the end user.
>>
>
> Urgh, that's horrible. Indeed, it needs to be fixed.
>
>
>  Now the use-case for the situation is the edition of a document (or
>> document section) in which sub-sections with differing edition
>> constraints are embedded e.g. content sections which may not be
>> formatted (even though the top-level may), sections which may only be
>> edited via a specific interface (e.g. embedded video + controls,
>> embedded slides or graph) or section with other edition restrictions
>> (e.g. only an enumerated set of values allowed), or even edition of more
>> "template"-oriented systems with restricted blocks (providing
>> template logic) containing free-form document sections[cke].
>>
>>  From my testing and use cases so far, I would say that the MSIE/Gecko
>> behaviour is sensible and has the advantage of being uniform, whether
>> a non-editable section contains editable descendants or not, it is
>> also significantly less likely to destroy user content. But I would
>> like to know what other people think of it, and whether an issue
>> should be opened on the webkit and chromium trackers.
>>
>
> I think that there are several distinct things that should help here.
>
> First, I believe that we should clearly define that when you have a
> selection that goes outside of a given editing host then the editing
> commands don't reach it. Put differently, you can only receive those events
> if you have focus, and you can only be focused if the current selection is
> *entirely* contained inside of you. A larger container might get keyboard
> events, but that's it.
>
> Second, I think that it would be helpful to put the selectability of some
> elements under user controls. (With which mechanism is another question. IE
> does it with an attribute, others through CSS. I don't think it's a styling
> decision.)
>
> As part of that it might be useful for non-editable islands/nested hosts
> to state how they should react to ensconcing selections. For instance, if I
> have a paragraph and a figure inside a section, I might refuse to carry out
> any editing action when I have a selection that goes from half of one to
> half of the other; but if both are fully selected as part of the section I
> might wish to delete them.
>
> I wonder if we could list a set 

Re: [editing] Leading with ContentEditable=Minimal

[Ryosuke Niwa]

> On Jun 22, 2014, at 9:19 PM, Julie Parent  wrote:
> 
> 
>> On Fri, Jun 20, 2014 at 8:47 PM, Ryosuke Niwa  wrote:
>> 
>>> On Jun 17, 2014, at 1:44 PM, Julie Parent  wrote:
>>> 
>>> 
 On Tue, Jun 17, 2014 at 12:22 PM, Olivier F  wrote:
> On Mon, Jun 16, 2014 at 5:48 PM, Julie Parent  wrote:
> 
>> On Mon, Jun 16, 2014 at 5:23 PM, Ben Peters  
>> wrote:
>> On Mon, Jun 16, 2014 at 5:12 PM, Julie Parent  wrote:
>> > If Intention events are (temporarily) moved out of scope,
>> 
>> I don’t think I’d say they’re out of scope, just that they will likely 
>> not be ready as quickly as we could do contentEditable=’minimal’. Do you 
>> agree with that?
> 
> Agreed in general, but it would depend on how contentEditable='min' is 
> actually defined. 
> 
>> > I think this leads us back to the question of what would 
>> > contentEditable='minimal' do exactly?  Enable collapsed selections and 
>> > default handling of cursor movement ... anything else?
>> 
>> Yes we need to define this default functionality. What does everyone 
>> think about this?
>> 
>> > If this is all it would do, then perhaps what we really want is an 
>> > explicit API to enable cursors?
>> 
>> I think we should still think of this as a path to a full story that 
>> includes Intention events. Are you saying that ultimately we would have 
>> something like this?
>> 
>> minimally editable content
>> 
>> Like all other content, this would also get drag/drop, clipboard, and 
>> selection events. We would need 3 specs for this- Selection API, minimal 
>> editing (cursor-only editing?), and CommandEvent.
> 
> Yes. I really like the idea of explicitly enabling what you want and of 
> separating the concepts.  Being able to turn on commandEvents independent 
> of a cursor seems useful.  An API like this leaves far fewer questions of 
> "what does it do?" than contentEditable="minimal".  What does 
> cursor="true" do? It turns on the ability for the user or developer to 
> place a cursor, and default movement.  It has nothing to do with dom 
> modification.  What does commandEvents="true" do? It enables dispatching 
> commandEvents.  No ambiguity.  However, this does make me think again 
> about using beforeinput/input events rather than adding new 
> CommandEvents, since those would include drag/drop and clipboard as well?
 
 I really like cursor=true. 
 
 I'm more confused about commandEvents=true as a separate attribute. 
 
 - Do CommandEvents make any sense without a cursor? In particular, how 
 does end-user focus an area that has commandEvents=true if there is no 
 cursor?
>>> 
>>> An app can have a cursor that isn't a native browser cursor.  For example, 
>>> Google Docs does not use native browser cursors and draws their own, so 
>>> that they can show multiple cursors for collaborators and control 
>>> selections entirely the way they want.  They have to use a hidden focused 
>>> contentEditable region in order to get all the events they need now, but it 
>>> would be a much nicer solution for them to simply enable the events.
>> 
>> How does that work in mobile?  iOS for example shows lollipops at the end of 
>> selections to trigger editing actions such as copy, paste, etc... if a web 
>> content was drawing its own cursor, then these UIs can't be shown for the 
>> user.  It seems to me that what they want is to use the native cursor and do 
>> every editing operation themselves.
> 
> The sad answer, at least for the Docs case I was referring to, is that they 
> aren't using web content on mobile, they are writing native apps.  Your point 
> is still valid, but I think the selection API would need to be significantly 
> extended in order for them to make use of it, rather than doing their own 
> thing.  In particular, they want to be able to draw multiple cursors (the 
> primary user selection and those of collaborators)

I don't think cursors for collaborators need to be drawn by the UA since users 
won't be interacting with those directly.

> and to control the granularity of selection movement throughout different 
> types of rich content, in a better way than you get by just using ce='false' 
> regions inside an editable regions.

Could you elaborate on what kind of granularity they need?

> It would be great to evolve to selection API to encompass these use cases as 
> well, but I think that is outside the scope of this discussion.

While we may not immediately satisfy all of their needs, we should still take 
their use cases into our consideration so that new API will be forward 
compatible with their use cases if any.

- R. Niwa

Re: IDBObjectStore/IDBIndex.exists(key)

[Joshua Bell]

On Sat, Jun 21, 2014 at 7:02 PM, Marc Fawzi  wrote:

> I think the same thought pattern can be applied elsewhere in the API
> design for v2.
>
> Consider the scenario of trying to find whether a given index exists or
> not (upon upgradeneeded). For now, we have to write noisy code like
> [].slice.call(objectStore.indexNames()).indexOf("someIndex")  Why couldn't
> indexNames be an array?
>

Technically, objectStoreNames() and indexNames() are specified to return a
DOMStringList, which is an array-like with a contains() method, so you can
write:

objectStore.indexNames().contains("someIndex")

... however, DOMStringList fell out of vogue pretty much as soon as it was
created. ISTR that Firefox just returns a JS Array here. But there's been
talk about adding contains() to Array.prototype:

http://esdiscuss.org/topic/array-prototype-contains

... which seems likely for ES7 in some form or another. Ideally we'd add
Array.prototype.contains() and then indexNames().contains() works
cross-browser (and we can delete DOMStringList from Chrome!).


>  and dare we ask for this to either return the index or null:
> objectStore.index("someIndex")  ? I understand the argument for throwing an
> error here but I think a silent null is more practical.
>

I don't think we can change that for compat reasons.

Aside: The API design definitely assumes "you know what you're doing", e.g.
introspecting a database schema is abnormal, since you (as the site author)
should of course know exactly what the schema is, except during upgrades
when you have the monotonically increasing version number to reason
against. Of course, the minute you build an abstraction layer on top of the
IDB API it's no longer abnormal and the API feels clunky.


> So yes, anything that makes the API easier to consume would be terrific.
>

More thoughts welcome!

I gave specific counters to your two concrete suggestions above, but please
don't let that stop you. These rough edges in the API should be smoothed
out!


> I had a very hard time until I saw the light. There's some solid thought
> behind the existing API, but it's also not designed for web development in
> terms of how it implements a good idea, not wether or not the idea is good.
> Sorry for the mini rant.
>

No need to apologize, it's appreciated. "v2" thinking needs to include
making the API more powerful, more usable, and more approachable.


> It took me a little too long to get this app done which is my first time
> using IndexedDB (with a half broken debugger in Chrome):
> https://github.com/idibidiart/AllSeeingEye
>
>
>
>
>
>
> On Sat, Jun 21, 2014 at 5:39 PM, Jonas Sicking  wrote:
>
>> Hi all,
>>
>> I found an old email with notes about features that we might want to put
>> in v2.
>>
>> Almost all of them was recently brought up in the recent threads about
>> IDBv2. However there was one thing on the list that I haven't seen brought
>> up.
>>
>> It might be a nice perf improvement to add support for a
>> IDBObjectStore/IDBIndex.exists(key) function.
>>
>> This would require less IO and less object creation than simply using
>> .get(). It is probably particularly useful when doing a filtering join
>> operation between two indexes/object stores. But it is probably useful
>> other times too.
>>
>> Is this something that others think would be useful?
>>
>> / Jonas
>>
>
>

Re: IDBObjectStore/IDBIndex.exists(key)

[Joshua Bell]

On Sat, Jun 21, 2014 at 9:45 PM, ben turner  wrote:

> I think this sounds like a fine idea.
>
> -Ben Turner
>
>
> On Sat, Jun 21, 2014 at 5:39 PM, Jonas Sicking  wrote:
>
>> Hi all,
>>
>> I found an old email with notes about features that we might want to put
>> in v2.
>>
>> Almost all of them was recently brought up in the recent threads about
>> IDBv2. However there was one thing on the list that I haven't seen brought
>> up.
>>
>> It might be a nice perf improvement to add support for a
>> IDBObjectStore/IDBIndex.exists(key) function.
>>
> This sounds redundant with count().

Was count() added to the spec after that note was written? (count() seems
to be a relatively late addition, given that it occurs last in the IDLs)

> This would require less IO and less object creation than simply using
>> .get(). It is probably particularly useful when doing a filtering join
>> operation between two indexes/object stores. But it is probably useful
>> other times too.
>>
>> Is this something that others think would be useful?
>>
>> / Jonas
>>
>
>

Re: [editing] Leading with ContentEditable=Minimal

[Julie Parent]

Well stated.  I like contentEditable=cursor.


On Mon, Jun 23, 2014 at 9:21 AM, Robin Berjon  wrote:

> On 17/06/2014 02:12 , Julie Parent wrote:
>
>> If Intention events are (temporarily) moved out of scope, I think this
>> leads us back to the question of what would contentEditable='minimal' do
>> exactly?  Enable collapsed selections and default handling of cursor
>> movement ... anything else?  If this is all it would do, then perhaps
>> what we really want is an explicit API to enable cursors?
>>
>
> The way I see it, that is indeed *all* it would do (and serve as a sanity
> flag so that browsers know how to handle this cleanly).
>
> It *is* an explicit API to enable cursors. It has the advantage of reusing
> an existing name so that we don't have to worry about what happens when you
> specify both; and it's declarative because that's what you want for such a
> case (notably so that CSS can style what's editable cleanly).
>
> We could rename it contentEditable=cursor if that's cleaner — the idea is
> the same (and I certainly won't argue bikeshedding :).
>
> --
> Robin Berjon - http://berjon.com/ - @robinberjon
>

Re: [editing] Leading with ContentEditable=Minimal

[Robin Berjon]

On 17/06/2014 02:12 , Julie Parent wrote:

If Intention events are (temporarily) moved out of scope, I think this
leads us back to the question of what would contentEditable='minimal' do
exactly?  Enable collapsed selections and default handling of cursor
movement ... anything else?  If this is all it would do, then perhaps
what we really want is an explicit API to enable cursors?


The way I see it, that is indeed *all* it would do (and serve as a 
sanity flag so that browsers know how to handle this cleanly).


It *is* an explicit API to enable cursors. It has the advantage of 
reusing an existing name so that we don't have to worry about what 
happens when you specify both; and it's declarative because that's what 
you want for such a case (notably so that CSS can style what's editable 
cleanly).


We could rename it contentEditable=cursor if that's cleaner — the idea 
is the same (and I certainly won't argue bikeshedding :).


--
Robin Berjon - http://berjon.com/ - @robinberjon

Re: [editing] CommandEvent and contentEditable=minimal Explainer

[Robin Berjon]

On 17/06/2014 02:39 , Julie Parent wrote:

I certainly understand the concern that it would be impossible to
properly catch and cancel all events.  But I think that is somewhat the
point - it forces browser vendors to get these parts right.  All changes
to an editable dom must fire an event before the modifications are made,
and must be cancelable. Further, I'd say that if the number of events
you would need to preventDefault on grows larger than selection,
command, and maybe clipboard then that implies that we are not building
the right APIs.


Apart from other problems with building on top of contentEditable=true 
(notably that you keep getting the native browser UI, which is likely 
very wrong) I'd be really worried that we'd be painting ourselves into a 
corner with this approach.


If we realise a year or two from now that the design we picked isn't 
ideal and that we'd really need a new event type, the reliance on 
"prevent everything I don't know about" could severely constrain our 
options, and force us to shoehorn new functionality into existing events 
just to make sure we don't break existing content.


I don't think that the (limited) benefits are really worth it.

--
Robin Berjon - http://berjon.com/ - @robinberjon

Editing with native UI (was: [editing] CommandQuery Object and Event)

[Robin Berjon]

On 06/06/2014 18:39 , Ryosuke Niwa wrote:

On Jun 6, 2014, at 4:29 AM, Piotr Koszuliński
 wrote:

1. That we need any native UI related to cE at all. We don't. We
can display our own toolbars, with our own buttons, with our own
icons and implementing our own logic. So the easiest solution to
the problem with irrelevant native UI is to not display it at all.


You may not need native UI working at all in your app, but that
doesn't mean all other developers don't want it at all.  Furthermore,
enabled-ness of items in desktop browser's edit menu should reflect
the current state of the editor; otherwise, it would degrade the user
experience.

Furthermore, we shouldn't design our API only for existing platforms.
We need to make it so that new, completely different paradigm of UIs
and devices could be built using new API we design.

Another important use case for browsers to know the state of the
editor is for accessibility.  AT may, for example, want to enumerate
the list of commands available on the page for the user.


All of these are good points, but the fact remains that if a browser 
unilaterally decides to exposes a new editing behaviour that I as author 
don't know about, it could very easily break my script.


Also, if the browser includes a "bold" command by default and I don't 
support bolding and therefore cancel the event, the user who has been 
relying on the native UI is getting the worst possible experience: 
native controls that do nothing at all.


Conversely, if I support something that the native UI does not expose 
(say, superscripting) it makes for a weird UI in which some things are 
exposed and others aren't.


There is an option that:

  • Can be styled in the page according to author wishes.
  • Can interact with native controls.
  • Can integrate with accessibility.

It relies on using all bits of new stuff in HTML: commands, contextMenu, 
and friends. I would *strongly* suggest that contentEditable=minimal 
would *only* have native UI based on things specified with this and not 
anything else by default. Native UI atop custom editing is really a 
solution for breakage.


We can also make it smart and able to tap into higher-level intention 
events such as knowing the platform's localised shortcut for a given action.


--
Robin Berjon - http://berjon.com/ - @robinberjon

Re: [editing] selection across editing host boundaries

[Robin Berjon]

On 07/06/2014 15:15 , Xavier Morel wrote:

I’ve been working with @contenteditable and I’ve hit a case where
one browser family (Webkit) seems to behave very differently than the
others (tested: Firefox and MSIE). The situation is nested editing
hosts: when starting a selection from the inner editing host, the
selection stops at the host boundary in all cases. However when starting
the selection from the outer editing host and entering the inner one,

* MSIE and Gecko treat the inner editing host as an opaque item (a
   character, or a non-editable element embedded in the editable one),
   either none of the inner host is selected or all of it is part of
   the overall selection

* Webkit-ish browsers (Safari and Chrome) on the other hand extend the
   selection within the inner editing host (so the selection can be half in
   and half out)

The issue is, in the case of webkit browsers, when an edition is then
performed they start moving stuff across the editing host boundary, and
text goes in or out of the inner host (depending on the direction of the
selection), generally ending up in an unrecoverable mess and panicking
the end user.


Urgh, that's horrible. Indeed, it needs to be fixed.


Now the use-case for the situation is the edition of a document (or
document section) in which sub-sections with differing edition
constraints are embedded e.g. content sections which may not be
formatted (even though the top-level may), sections which may only be
edited via a specific interface (e.g. embedded video + controls,
embedded slides or graph) or section with other edition restrictions
(e.g. only an enumerated set of values allowed), or even edition of more
“template”-oriented systems with restricted blocks (providing
template logic) containing free-form document sections[cke].

 From my testing and use cases so far, I would say that the MSIE/Gecko
behaviour is sensible and has the advantage of being uniform, whether
a non-editable section contains editable descendants or not, it is
also significantly less likely to destroy user content. But I would
like to know what other people think of it, and whether an issue
should be opened on the webkit and chromium trackers.


I think that there are several distinct things that should help here.

First, I believe that we should clearly define that when you have a 
selection that goes outside of a given editing host then the editing 
commands don't reach it. Put differently, you can only receive those 
events if you have focus, and you can only be focused if the current 
selection is *entirely* contained inside of you. A larger container 
might get keyboard events, but that's it.


Second, I think that it would be helpful to put the selectability of 
some elements under user controls. (With which mechanism is another 
question. IE does it with an attribute, others through CSS. I don't 
think it's a styling decision.)


As part of that it might be useful for non-editable islands/nested hosts 
to state how they should react to ensconcing selections. For instance, 
if I have a paragraph and a figure inside a section, I might refuse to 
carry out any editing action when I have a selection that goes from half 
of one to half of the other; but if both are fully selected as part of 
the section I might wish to delete them.


I wonder if we could list a set of use cases for this sort of 
interaction and figure out how best to handle them. It is related to 
something I've often wanted to do with editing. Assume you have two 
content items inside a section, and since they have different 
constraints they are editable separately (horrible markup just for 
example purposes):



  
A thing of beauty is a joy forever.
  
  
Time will say nothing
But I told you so
  


At this point, if I have my cursor right after the "y" of "say" in the 
first poem line and arrow up, I would like the cursor to go, roughly, 
after the "e" in "beauty". In existing systems it is far more likely to 
wind up right before "Time". Maybe that could be differentiated thusly:



  
A thing of beauty is a joy forever.
  
  
Time will say nothing
But I told you so
  


In other words, the presence of a containing host would influence the 
behaviour of cursors at (inner) editing boundaries. And as indicated 
above, my script could refuse to do anything for a selection from "joy" 
to "nothing" (since the operation might be meaningless across the nested 
contexts) but it might respond to deletion if both the p and div.poem 
are fully selected.



PS: I am not subscribed to the list, if anybody is interested and wants
 to reply or has further questions, I'd be grateful if you could CC
 me.


Maybe you'll be interested in signing up to the new public-editing-tf 
list which has much lower traffic.


--
Robin Berjon - http://berjon.com/ - @robinberjon

Re: Composition, IME, etc.

[Robin Berjon]

On 06/06/2014 19:13 , Ryosuke Niwa wrote:

On Jun 6, 2014, at 7:24 AM, Robin Berjon  wrote:

In order to handle them you have two basic options:

a) Let the browser handle them for you (possibly calling up some
platform functionality). This works as closely to user expectations
as a Web app can hope to get but how do you render it? If it
touches your DOM then you lose the indirection you need for
sensible editing; if it doesn't I don't know how you show it.

b) Provide the app with enough information to do the right thing.
This gives you the indirection, but "doing the right thing" can be
pretty hard.

I am still leaning towards (b) being the approach to follow, but
I'll admit that that's mostly because I can't see how to make (a)
actually work. If (b) is the way, then we need to make sure that
it's not so hard that everyone gets it wrong as soon as the input
is anything other than basic English.


I'm not convinced b is the right approach.


As I said though, it's better than (a) which is largely unusable.

That said, I have a proposal that improves on (b) and I believes 
addresses your concerns (essentially by merging both approaches into a 
single one).



If the browser doesn't know because the platform can't tell the
difference between Korean and Japanese (a problem with which
Unicode doesn't help) then there really isn't much that we can do
to help the Web app.


This predicates on using approach b.  I'm not convinced that that's
the right thing to do here.


No, it doesn't. If the browser has no clue whatsoever how to present 
composition then it can't offer the right UI itself any more than it can 
help the application do things well. I am merely ruling that situation, 
which you mentioned, out as unsolvable (by us).



However if the browser knows, it can provide the app with
information. I don't have enough expertise to know how much
information it needs to convey — if it's mostly style that can be
done (it might be unwieldy to handle but we can look at it).


The problem here is that we don't know if underlining is the only
difference input methods ever need.  We could imagine future new UI
paradigms would require other styling such as bolding text, enlarging
the text for easier readability while typing, etc...


I never said that the browser would only provide underlining 
information. I said it can convey *style*. If it knows that the specific 
composition being carried out requires bolding, then it could provide 
the matching CSS declaration. If there is an alien composition method 
that requires red blinking with a green top border, it could convey that.


Having said that, having the browser convey style information to the 
script with the expectation that the script would create the correct 
Range for the composition in progress and apply that style to it, even 
though possible, seems like a lot of hoops to jump through that are 
essentially guaranteed to be exactly the same in every single instance.


I think we can do better. It's a complicated-sounding solution but the 
problem is itself complex, and I *think* that it is doable and the best 
of all options I can think of.


To restate the problem:

  • We don't want the browser editing the DOM directly because that 
just creates madness
  • We want to enable any manner of text composition, from a broad 
array of options, while showing the best UI for the user.


These two requirements are at odds because rich, powerful composition 
that is great for the user *has* to rely on the browser, but the logical 
way for the browser to expose that is to use the DOM.


The idea to ally both is to use a "shadow text insertion point". 
Basically, it is a small DOM tree injected as a shadow at the insertion 
point (with author styles applied to it). The browser can do *anything* 
it wants in there in order to create a correct editing UI. While 
composition is ongoing, the script still receives composition events but 
can safely just ignore them for the vast majority of cases (since you 
can't generally usefully validate composition in progress anyway). When 
the composition terminates, the input event contains the *text* content 
of the shadow DOM, which is reclaimed.


I guess that the shadow text insertion point would participate in the 
tree in the same way that a pseudo-element does. (Yes, I realise this 
basically means "magic".)


I believe this works well for the insertion of new text; I need to mull 
it over further to think about editing existing content (notably the 
case that happens in autocorrect, predictive, and I believe Kotoeri 
where you place a cursor mid-word and it will take into account what's 
before it but not after). But I think it's worth giving it some thought; 
particularly because I don't see how we can solve this problem properly 
otherwise.


This has the advantage that it is also a lot simpler to handle for authors.

--
Robin Berjon - http://berjon.com/ - @robinberjon

DIsjoint ranges (was: contentEditable=minimal)

[Robin Berjon]

On 06/06/2014 18:52 , Ryosuke Niwa wrote:

On Jun 6, 2014, at 6:40 AM, Robin Berjon  wrote:

On 05/06/2014 09:02 , Ryosuke Niwa wrote:

I agree visual selection of bidirectional text is a problem
worth solving but I don't think adding a generic multi-range
selection support to the degree Gecko does is the right
solution.


I'd be interested to hear how you propose to solve it in another
manner. Also note that that's not the only use case, there are
other possibilities for disjoint selections, e.g. a table
(naturally) or an editable surface with a non-editable island
inside.


Supporting disjoint range is probably necessary but adding the
ability to manipulate each range separately seems excessive because
that'll lead to selections with overlapping ranges, ranges in
completely different locations that are not visually disjoint, etc...
We might need to do something like exposing readonly multi-range
selection.


Readonly multiranges may be an option, but I can think of some issues 
(which perhaps we can address).


Several people have mentioned the use case in which a script wants to 
observe selection changes in order to ensure that selections conform to 
certain constraints. Consider the following:


  abc 2 defg
  ABC 1 defg

Let's imagine that the script wishes to constrain the selection to only 
that second line, that the user clicks at 1 and drags towards 2. You'd 
want the script to constrain the range such that it just selects "ABC ". 
If you only cancel the selection change, presumably it doesn't select 
anything at all here (and I'm also presuming that with such a gesture 
you don't get a selection change event for each character in between the 
two drag points — that would be a lot).


What is weird in this scenario is that so long as the text is 
unidirectional you can manipulate the range, but the second "B" is a 
character in a different direction you can't. (And then again, *only* in 
browsers that support visually continuous selection across bidi 
boundaries — in others it would still work.)


I don't think that this variability is good; it is likely to surprise 
developers.


Another issue is that in some cases I believe that *visually* disjoint 
selections are the right thing to do. If you have an editing host that 
contains a readonly island, it should be possible for the author to make 
that island non-selectable so that you can select text from one side to 
the other but not the island itself. (Typically this enables the 
inlining of affordances.)


Reconsidering your objection, I wonder if it really is a problem? 
Overlapping ranges: well, it would be weird, but basically it strikes me 
as a "doctor it hurts when I do this" problem, unless I'm missing 
something. Ranges in completely different locations that are not 
visually disjoint: well, if you do that, maybe you have a reason? Just 
because you can do something stupid with an API doesn't mean that it's a 
stupid API.



For starters, most of author scripts completely ignore all but
the first range, and applying editing operations to a multi-range
selection is a nightmare.


I don't disagree that it can be hard to handle, but I'm not sure
that that's indicative of anything. Most scripts only handle one
selection because AFAIK only Gecko ever supported more than one.


Given Gecko itself doesn't handle applying editing operations to
multiple ranges well from what I've heard, I'm not certain we can
expect web developers to get them right especially in the context
where disjoint multi-range selection is needed; e.g. bidirectional
text, exotic layout model.


I don't think that what is supported in any browser today in terms of 
contentEditable should be seen as a limitation on what Web developers 
can achieve. I'm very much certain that they can do better.


Thinking about this some more, I wonder if the problem is not less 
common than I initially thought, though. If you consider the following text:


  ltr rtl ltr

You definitely need multiranges while the selection is in progress if 
you want visual continuity:


  [ltr rt]l ltr

But when both ends of the selection are in text with the same direction, 
you can revert to having a single range:


  [ltr rtl ltr]

The problem being less common does not decrease the need to support for 
it, but it does decrease the odds that people will shoot themselves in 
the foot over relatively common cases.


--
Robin Berjon - http://berjon.com/ - @robinberjon

Editing TF and list

[Robin Berjon]

Hi all,

this email is to announce the creation of the task force working on 
editing, jointly between WebApps and HTML, based on the decision made 
previously[0].


The mailing list's address is public-editing...@w3.org and signing up is 
at mailto:public-editing-tf-requ...@w3.org?subject=subscribe.


The rationale for having this specific list is in the "charter"[1]. 
Feedback and suggestions are welcome on that document, which is informal 
and mostly means to document the group's purpose.


I suggest that for a short while (~a week, mostly covering existing 
threads) people cross-post. After that, though, all discussion ought to 
have been redirected there.


Thanks!


[0] http://lists.w3.org/Archives/Public/public-webapps/2014AprJun/0842.html
[1] http://w3c.github.io/editing-explainer/tf-charter.html

--
Robin Berjon - http://berjon.com/ - @robinberjon

RfC: OASIS' Advanced Message Queuing Protocol (AMQP) WebSocket Binding (WSB) Version 1.0; deadline 19 July

[Arthur Barstow]

Below is an request for comments for OASIS' "Advanced Message Queuing 
Protocol (AMQP) WebSocket Binding (WSB) Version 1.0" Community 
Specification Draft:




If you have any comments, please submit them by July 19 and note:

[[


... send comments to the Technical Committee by using the “Send A 
Comment” button on the Technical Committee’s web page at 
https://www.oasis-open.org/committees/amqp-bindmap/

]]

The comment archive is 
.


Please do *not* send comments to public-webapps.

-Thanks, AB

 Original Message 
Subject: 	30-day Public Review for Advanced Message Queuing Protocol 
(AMQP) WebSocket Binding (WSB) Version 1.0 - ends July 19th

Resent-Date:Fri, 20 Jun 2014 04:37:35 +
Resent-From:public-webapps@w3.org
Date:   Thu, 19 Jun 2014 16:09:39 -0400
From:   Paul Knight 
To: 	tc-annou...@lists.oasis-open.org, memb...@lists.oasis-open.org, 
"amqp-bind...@lists.oasis-open.org" , 
a...@lists.oasis-open.org, amqp-bindmap-comm...@lists.oasis-open.org





OASIS members and other interested stakeholders,

The OASIS Advanced Message Queuing Protocol (AMQP) Bindings and Mappings 
(AMQP-BINDMAP) TC [1] members have recently approved a Committee 
Specification Draft (CSD) and submitted it for 30-day public review:


Advanced Message Queuing Protocol (AMQP) WebSocket Binding (WSB) Version 
1.0

Committee Specification Draft 01 / Public Review Draft 01
10 June 2014

Overview:

The AMQP WebSocket Binding specification defines a mechanism for 
tunneling an AMQP connection over a WebSocket transport. It is 
applicable as an approach for general firewall tunneling and for Web 
browser messaging scenarios.


TC Description:

The purpose of the AMQP Bindings and Mappings (AMQP-BINDMAP) TC is to 
define bindings of AMQP 1.0 core protocol to underlying transports other 
than TCP, to define mappings of the AMQP 1.0 core protocol to existing 
well-known programming APIs, and to define representations of the AMQP 
1.0 message format in existing well-known languages.


For more information, see the TC Charter and FAQ.

Public Review Period:

The public review starts 20 June 2014 at 00:00 GMT and ends 19 July 2014 
at 23:59 GMT.


This is an open invitation to comment. OASIS solicits feedback from 
potential users, developers and others, whether OASIS members or not, 
for the sake of improving the interoperability and quality of its 
technical work.


URIs:

The prose specification document and related files are available here:

Editable source (Authoritative):
http://docs.oasis-open.org/amqp-bindmap/amqp-wsb/v1.0/csprd01/amqp-wsb-v1..0-csprd01.doc 



HTML:
http://docs.oasis-open.org/amqp-bindmap/amqp-wsb/v1.0/csprd01/amqp-wsb-v1.0-csprd01.html 



PDF:
http://docs.oasis-open.org/amqp-bindmap/amqp-wsb/v1.0/csprd01/amqp-wsb-v1.0-csprd01.pdf

ZIP distribution file (complete):

For your convenience, OASIS provides a complete package of the prose 
document and related files in a ZIP distribution file. You can download 
the ZIP file here:


http://docs.oasis-open.org/amqp-bindmap/amqp-wsb/v1.0/csprd01/amqp-wsb-v1.0-csprd01.zip

Additional information about the specification and the OASIS Advanced 
Message Queuing Protocol (AMQP) Bindings and Mappings (AMQP-BINDMAP) TC 
can be found at the TC's public home page:


https://www..oasis-open.org/committees/amqp-bindmap/ 



Comments may be submitted to the TC by any person through the use of the 
OASIS TC Comment Facility which can be used by following the 
instructions on the TC's "Send A Comment" page, or directly at:


https://www.oasis-open.org/committees/comments/index.php?wg_abbrev=amqp-bindmap

Comments submitted by TC non-members for this work and for other work of 
this TC are publicly archived and can be viewed at:


https://lists.oasis-open.org/archives/amqp-bindmap-comment/

All comments submitted to OASIS are subject to the OASIS Feedback 
License, which ensures that the feedback you provide carries the same 
obligations at least as the obligations of the TC members. In connection 
with this public review of "Advanced Message Queuing Protocol (AMQP) 
WebSocket Binding (WSB) Version 1.0", we call your attention to the 
OASIS IPR Policy [2] applicable especially [3] to the work of this 
Technical Committee. All members of the TC should be familiar with this 
document, which may create obligations regarding the disclosure and 
availability of a member's patent, copyright, trademark and license 
rights that read on an approved OASIS specification.


OASIS invites any persons who know of any such claims to disclose these 
if they may be essential to the implementation of

RfC: LCWD of 'HTML Media Capture', 'Ambient Light Events' and 'Vibration API'; deadline 24 July

[Arthur Barstow]

WebApps has been asked to review three LCWDs published by DAPWG:

* HTML Media Capture  - 



* Ambient Light Events - 



*  Vibration API - 

Individual WG members are encouraged to provide individual feedback.

If anyone in WebApps wants to propose an official group response, please 
do so ASAP, in reply to this e-mail so the group can discuss it.


Comments should be sent to public-device-apis @ w3.org [1] by July 24. 
Presumably, DAPWG also welcomes data about "silent reviews", f.ex. "I 
reviewed section N.N of document X and have no comments".


-Thanks, AB

[1] 


On 6/19/14 3:25 PM, Frederick Hirsch wrote:

The Device APIs (DAP) working group has published new Last Call working drafts 
of the following three specifications, based on implementer feedback:

(1) HTML Media Capture  - 
http://www.w3.org/TR/2014/WD-html-media-capture-20140619/

Made security and privacy considerations section non-normative to address 
testability and implementation concerns.

(2) Ambient Light Events - http://www.w3.org/TR/2014/WD-ambient-light-20140619/

Removed the LightLevelEvent and updated the document correspondingly, in 
response to implementer feedback.

(3) Vibration API - http://www.w3.org/TR/2014/WD-vibration-20140619/

Changed a normative step to a note based on implementer feedback on testability.

The status section of each document summarizes the changes and provides a link 
to a red-line. The Working Group appreciates the feedback we have received from 
implementers. If you have any additional feedback please send it to the DAP 
public mailing list before the end of the Last Call period ( 24 July 2014 ). We 
would especially appreciate any comment from the Web Applications WG (WebApps).

Thank you

regards, Frederick

Frederick Hirsch, Nokia
Chair DAP
@fjhirsch

[Bug 26161] "Initially the XMLHttpRequest object must be in ..."

[bugzilla]

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

Anne  changed:

   What|Removed |Added

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

--- Comment #1 from Anne  ---
https://github.com/whatwg/xhr/commit/62abf343b334ee6344d34b8d00d310281df07c34

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

[Bug 26162] "The name XMLHttpRequest is historical and has n..."

[bugzilla]

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

Anne  changed:

   What|Removed |Added

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

--- Comment #1 from Anne  ---
https://github.com/whatwg/xhr/commit/62abf343b334ee6344d34b8d00d310281df07c34

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

[Bug 26163] Update references for RFCs 2616 and 2617

[bugzilla]

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

Anne  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #1 from Anne  ---


*** This bug has been marked as a duplicate of bug 25097 ***

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