[xhr] responseType for sync requests in window context

[Jarred Nicholls]

Got some reports of broken C/C++ => JS compilers that relied on sync XHR to 
load resources into an ArrayBuffer (simulating fopen), e.g. Mandreel and 
Enscripten.

https://bugzilla.mozilla.org/show_bug.cgi?id=716765
https://bugs.webkit.org/show_bug.cgi?id=72154#c43

Is there additional scoping of the restriction we should consider?  Thoughts?

Jarred

Re: [editing] tab in an editable area WAS: [whatwg] behavior when typing in contentEditable elements

[Ojan Vafai]

On Tue, Jan 10, 2012 at 12:30 PM, Aryeh Gregor  wrote:

> On Fri, Jan 6, 2012 at 10:12 PM, Ojan Vafai  wrote:
> > We should make this configurable via execCommand:
> > document.execCommand("TabBehavior", false, bitmask);
>
> I'm leery of global flags like that, because they mean that if you
> have two editors on the same page, they can interfere with each other
> unwittingly.  useCss/styleWithCss is bad enough; I've seen author code
> that just sets useCss or styleWithCss before every single command in
> case something changed it in between.
>
> Could the author just intercept the keystroke and run
> document.execCommand("indent") themselves?  It's not as convenient, I
> admit.  Alternatively, perhaps the flag could be set per editing host
> somehow, and only function when that editing host has focus, although
> I'm not sure what API to use.
>

I agree the API is not the best. We should put execCommand, et. al. on
Element. That would solve the global flag thing for useCss/styleWithCss as
well. It's also more often what a website actually wants. They have a
toolbar associated with each editing host. They don't want a click on the
toolbar to modify content in a different editing host. This is a change we
should make regardless of what we decide for tabbing behavior IMO.

Calling indent doesn't actually match tabbing behavior (e.g. inserting a
tab/spaces or, in a table cell, going to the next cell), right? I guess
another way we could approach this is to add document.execCommand('Tab')
that does the text-editing tabbing behavior. I'd be OK with that (the
command name could probably be better).


> > The bitmask is because you might want a different set of behaviors:
> > -Tabbing in lists
> > -Tabbing in table cells
> > -Tabbing blockquotes
> > -Tab in none of the above insert a tab
> > -Tab in none of the above insert X spaces (X is controlled by the CSS
> > tab-size property?)
>
> Bitmasks are bad -- many JavaScript authors don't understand binary
> well, if at all.  Also, what are use-cases where you'd want to toggle
> indentation in all these cases separately?  More complexity without
> supporting use-cases is a bad idea -- browsers have enough trouble
> being interoperable as it stands, and more complexity just makes it
> harder.
>

The bitmask is not a great idea, but there are certainly editors that would
want tabbing in lists to work, but tab outside of lists to do the normal
web tabbing behavior. Maybe you're right that we should just have one
toggle though and if you want something more specific you do it in JS.

Historically, one of my biggest frustrations with contentEditable is that
you have to take it all or none. The lack of configurability is frustrating
as a developer. Maybe the solution is to come up with a lower level set of
editing primitives in place of contentEditable instead of trying to extend
it though.

Ojan

Re: Colliding FileWriters

[Eric U]

On Tue, Jan 10, 2012 at 1:08 PM, Jonas Sicking  wrote:
> Hi All,
>
> We've been looking at implementing FileWriter and had a couple of questions.
>
> First of all, what happens if multiple pages create a FileWriter for
> the same FileEntry at the same time? Will both be able to write to the
> file at the same time and whoever writes lasts to a given byte wins?

This isn't currently specified, and that's a hole we should fill.  By
not having it in the spec, my assumption would be that last-wins would
hold, but it would be good to clarify it if that's the behavior we
want.  It's especially important given that there's nothing like
fflush(), which would help users know what "last" meant.  Speaking of
which, should we add a flushing mechanism?

> This is different from how file systems normally work since as long as
> file is open for writing that tends to prevent other processes from
> opening the same file.

You're perhaps thinking of windows, where by default files are opened
in exclusive mode?  On other operating systems, and on windows when
you specify FILE_SHARE_WRITE in dwShareMode in CreateFile, multiple
writers can exist simultaneously.

> A second question is why is FileEntry.createWriter asynchronous? It
> doesn't actually do any IO and so it seems like it could return an
> answer synchronously.

FileWriter has a synchronous length property, just as Blob does, so it
needs to do IO at creation time to look it up.

> Is the intended way for this to work that FileEntry.createWriter acts
> as a choke point and ensures that only one active FileWriter for a
> given FileEntry exists at the same time. I.e. if one page creates a
> FileWriter for a FileEntry and starts writing to it, any other caller
> to FileEntry.createWriter will wait to fire it's callback until the
> first caller was done with its FileWriter. If that is the intended
> design I would have expected FileWriter to have an explicit .close()
> function though. Having to wait for GC to free a lock is always a bad
> idea.

Agreed re: GC, but currently in Chromium there is no choke point, and
one can create multiple writers, which can stomp on each others'
writes if that's what the user requests.  That being said, we don't
really hold files open right now, except during a write call.  In
between writes, we close the file, so while collisions are possible,
more likely one write will win entirely.  But we are opening the files
in shared mode.

> Would this also explain why FileEntry.getFile is asynchronous? I.e. it
> won't call it's callback until all current FileWriters have been
> closed?

Nope.  It's asynchronous because a File is a Blob, and has a
synchronous length accessor, so we look up the length when we mint the
File.  Note that the length can go stale if you have multiple writers,
as we want to keep it fast.

> These questions both apply to what's the intended behavior spec-wise,
> as well as what does Google Chrome do in the current implementation.

I'm personally OK with the current Chrome implementation, which does
no locking.  If users want transactional behavior, there are better
ways to get that via databases.  But I'm open to discussion.

Re: Pressing Enter in contenteditable: or or ?

[Charles Pritchard]

On Jan 10, 2012, at 12:50 PM, Ryosuke Niwa  wrote:

> On Tue, Jan 10, 2012 at 12:46 PM, Aryeh Gregor  wrote:
> On Tue, Jan 10, 2012 at 3:40 PM, Ryosuke Niwa  wrote:
> > Single br tag is shorter than pairs of div tags when serialized.
> 
> True, but only slightly, and the difference is even smaller if you use
>  instead of .  This isn't enough of a reason by itself to
> justify the extra complexity of another mode.  Are there other
> reasons?
> 
> p has default margins. That alone is enough for us not to adopt p as the 
> default paragraph separator. Also, unfortunately, there are many legacy 
> contents that rely on the fact webkit uses div as the paragraph separator so 
> we need a global or per editing-host switch regardless.
> 
> I almost want a global switch to toggle between legacy UA-specific behavior 
> and new spec-compliant behavior.
> 
> - Ryosuke
> 

I've got a similar issue with copy/paste of HTML. If a switch were around for 
contentEditable, I might route through it on copy events in the page to tidy up 
some of the raw HTML clipboard.

-Charles

Re: File modification

[Charles Pritchard]

On Jan 10, 2012, at 1:53 PM, Eric U  wrote:

> On Tue, Jan 10, 2012 at 1:29 PM, Charles Pritchard  wrote:
>> Modern operating systems have efficient mechanisms to send a signal when a 
>> watched file or directory is modified.
>> 
>> File and FileEntry have a last modified date-- currently we must poll 
>> entries to see if the modification date changes. That works completely fine 
>> in practice, but it doesn't give us a chance to exploit the efficiency of 
>> some operating systems in notifying applications about file updates.
>> 
>> So as a strawman: a File.onupdated event handler may be useful.
> 
> It seems like it would be most useful if the File or FileEntry points
> to a file outside the sandbox defined by the FileSystem spec.  Does
> any browser currently supply such a thing?  Chrome currently
> implements this [with FileEntry] only for ChromeOS components that are
> implemented as extensions.  Does any browser let you have a File
> outside the sandbox *and* update its modification time?
> 
> If you're dealing only with FileEntries inside the sandbox, there are
> already more efficient ways to tell yourself that you've changed
> something.
> 

Far as I can tell, File is live, and it's supposed to be live from .

For FileEntry-- I'd imagine we'll see cross-origin communication with the 
objects at some point. In those cases, onupdated would be simpler than an 
additional postMessage layer for update notifications.

Re: File modification

[Eric U]

On Tue, Jan 10, 2012 at 1:29 PM, Charles Pritchard  wrote:
> Modern operating systems have efficient mechanisms to send a signal when a 
> watched file or directory is modified.
>
> File and FileEntry have a last modified date-- currently we must poll entries 
> to see if the modification date changes. That works completely fine in 
> practice, but it doesn't give us a chance to exploit the efficiency of some 
> operating systems in notifying applications about file updates.
>
> So as a strawman: a File.onupdated event handler may be useful.

It seems like it would be most useful if the File or FileEntry points
to a file outside the sandbox defined by the FileSystem spec.  Does
any browser currently supply such a thing?  Chrome currently
implements this [with FileEntry] only for ChromeOS components that are
implemented as extensions.  Does any browser let you have a File
outside the sandbox *and* update its modification time?

If you're dealing only with FileEntries inside the sandbox, there are
already more efficient ways to tell yourself that you've changed
something.

Re: [editing] tab in an editable area WAS: [whatwg] behavior when typing in contentEditable elements

[Charles Pritchard]

On Jan 10, 2012, at 12:30 PM, Aryeh Gregor  wrote:

> On Fri, Jan 6, 2012 at 10:12 PM, Ojan Vafai  wrote:
>> There are strong use-cases for both. In an app like Google Docs you
>> certainly want tab to act like indent. In a mail app, it's more of a
>> toss-up. In something like the Google+ sharing widget, you certainly want it
>> to maintain normal web tabbing behavior. Anecdotally, gmail has an internal
>> lab to enable document-like tabbing behavior and it is crazy popular. People
>> gush over it.
> 
> Hmm, good point.  Google Docs definitely wants tab to indent.

Would users press Esc to get out of the tab lock?



> 
>> We should make this configurable via execCommand:
>> document.execCommand("TabBehavior", false, bitmask);
> 
> I'm leery of global flags like that, because they mean that if you
> have two editors on the same page, they can interfere with each other
> unwittingly.  useCss/styleWithCss is bad enough; I've seen author code
> that just sets useCss or styleWithCss before every single command in
> case something changed it in between.
> 
> Could the author just intercept the keystroke and run
> document.execCommand("indent") themselves?  It's not as convenient, I
> admit.  Alternatively, perhaps the flag could be set per editing host
> somehow, and only function when that editing host has focus, although
> I'm not sure what API to use.
> 
>> The bitmask is because you might want a different set of behaviors:
>> -Tabbing in lists
>> -Tabbing in table cells
>> -Tabbing blockquotes
>> -Tab in none of the above insert a tab
>> -Tab in none of the above insert X spaces (X is controlled by the CSS
>> tab-size property?)
> 
> Bitmasks are bad -- many JavaScript authors don't understand binary
> well, if at all.  Also, what are use-cases where you'd want to toggle
> indentation in all these cases separately?  More complexity without
> supporting use-cases is a bad idea -- browsers have enough trouble
> being interoperable as it stands, and more complexity just makes it
> harder.
> 


I don't like these being called "tab", but, the use cases for standard 
navigation mechanisms for lists and grids make some sense.

-Charles

File modification

[Charles Pritchard]

Modern operating systems have efficient mechanisms to send a signal when a 
watched file or directory is modified.

File and FileEntry have a last modified date-- currently we must poll entries 
to see if the modification date changes. That works completely fine in 
practice, but it doesn't give us a chance to exploit the efficiency of some 
operating systems in notifying applications about file updates.

So as a strawman: a File.onupdated event handler may be useful.

-Charles

Colliding FileWriters

[Jonas Sicking]

Hi All,

We've been looking at implementing FileWriter and had a couple of questions.

First of all, what happens if multiple pages create a FileWriter for
the same FileEntry at the same time? Will both be able to write to the
file at the same time and whoever writes lasts to a given byte wins?
This is different from how file systems normally work since as long as
file is open for writing that tends to prevent other processes from
opening the same file.

A second question is why is FileEntry.createWriter asynchronous? It
doesn't actually do any IO and so it seems like it could return an
answer synchronously.


Is the intended way for this to work that FileEntry.createWriter acts
as a choke point and ensures that only one active FileWriter for a
given FileEntry exists at the same time. I.e. if one page creates a
FileWriter for a FileEntry and starts writing to it, any other caller
to FileEntry.createWriter will wait to fire it's callback until the
first caller was done with its FileWriter. If that is the intended
design I would have expected FileWriter to have an explicit .close()
function though. Having to wait for GC to free a lock is always a bad
idea.


Would this also explain why FileEntry.getFile is asynchronous? I.e. it
won't call it's callback until all current FileWriters have been
closed?

These questions both apply to what's the intended behavior spec-wise,
as well as what does Google Chrome do in the current implementation.

/ Jonas

Re: Pressing Enter in contenteditable: or or ?

[Ryosuke Niwa]

On Tue, Jan 10, 2012 at 12:46 PM, Aryeh Gregor  wrote:
>
>  On Tue, Jan 10, 2012 at 3:40 PM, Ryosuke Niwa  wrote:
> > Single br tag is shorter than pairs of div tags when serialized.
>
> True, but only slightly, and the difference is even smaller if you use
>  instead of .  This isn't enough of a reason by itself to
> justify the extra complexity of another mode.  Are there other
> reasons?
>

p has default margins. That alone is enough for us not to adopt p as
the default paragraph separator. Also, unfortunately, there are many legacy
contents that rely on the fact webkit uses div as the paragraph separator
so we need a global or per editing-host switch regardless.

I almost want a global switch to toggle between legacy UA-specific behavior
and new spec-compliant behavior.

- Ryosuke

Re: [editing] Feedback Link?

[Aryeh Gregor]

On Sun, Jan 8, 2012 at 2:28 PM, Doug Schepers  wrote:
> In the status section of the HTML Editing APIs spec [1], you have detailed
> instructions for how people should provide feedback, but the links you
> provide are to the pubic-webapps archive and to your personal email, rather
> than a mailto link to the list.
>
> It might be handy provide an encoded mailto link to make it easier for
> people to start a discussion, like this:
>
>  href="mailto:public-webapps@w3.org?cc=a...@aryeh.name&subject=%5Bediting%5D%20";>discussion
> on the HTML Editing APIs specification ( href="http://www.w3.org/Search/Mail/Public/search?type-index=public-webapps&index-type=t&keywords=[editing]";>public-webapps
> archive)

Thanks for the suggestion!  I've made the change:

http://dvcs.w3.org/hg/editing/rev/d278ee615900
http://dvcs.w3.org/hg/editing/raw-file/tip/editing.html

Re: Pressing Enter in contenteditable: or or ?

[Aryeh Gregor]

On Fri, Jan 6, 2012 at 9:57 PM, Ojan Vafai  wrote:
> I'm OK with this conclusion, but I still strongly prefer "div" to be the
> "default single-line container name".

Why?  I don't like using  as a line separator at all, because
it's also used as a block-level wrapper, while  is specifically
meant to wrap lines and  is specifically meant to separate them.
I wish that UAs never generated  to wrap lines to start with --
it means that authors can't insert -wrapped editable content
without the risk that it will be interpreted as a line wrapper instead
of a block wrapper.

> Also, I'd really like the "default
> single-line container name" to be configurable in some way. Different apps
> have different needs and it's crappy for them to have to handle enter
> themselves just to get a different block type on enter.

What's a use-case for wanting div or br rather than p?

> Something like document.execCommand("DefaultBlock", false, tagName).

I really don't want more document-global flags.  If such a switch is
added, it should be per editing host.

> What
> values are valid for tagName are open to discussion. At a minimum, I'd want
> to see "div", "p" and "br". As one proof that this is valuable, the Closure
> editor supports these three with custom code and they are all used in
> different apps.

That's not proof that they're valuable, just that people will use them
if given the option.  What are examples of apps that use div and br?
Do you know why they use them?

> I'm tempted to say that any block type should be allowed,
> but I'd be OK with starting with the tree above. For example, I could see a
> use-case for "li" if you wanted an editable widget that only contained a
> single list.

As Simon says, making the list element itself contenteditable will
work for that use-case.  Then hitting Enter will make an  no
matter what.

On Tue, Jan 10, 2012 at 3:40 PM, Ryosuke Niwa  wrote:
> Single br tag is shorter than pairs of div tags when serialized.

True, but only slightly, and the difference is even smaller if you use
 instead of .  This isn't enough of a reason by itself to
justify the extra complexity of another mode.  Are there other
reasons?

[Bug 15509] New: Define HTTP handling of data URLs (and maybe other URLs)

[bugzilla]

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

   Summary: Define HTTP handling of data URLs (and maybe other
URLs)
   Product: WebAppsWG
   Version: unspecified
  Platform: PC
OS/Version: All
Status: NEW
  Severity: normal
  Priority: P2
 Component: XHR
AssignedTo: ann...@opera.com
ReportedBy: ann...@opera.com
 QAContact: member-webapi-...@w3.org
CC: m...@w3.org, public-webapps@w3.org


User agents start to allow fetching of data URLs in the context of
XMLHttpRequest. That has implications for
status/statusText/getResponseHeader()/getAllResponseHeaders(). Those
implications need to be defined. Ideally in the data URL standard just like
they are for blob URLs, but otherwise maybe in XMLHttpRequest for now.

Henri also suggested adding a note to those four members to point out this
issue to implementors.

-- 
Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

Re: Pressing Enter in contenteditable: or or ?

[Ryosuke Niwa]

On Sun, Jan 8, 2012 at 11:57 PM, Simon Pieters  wrote:

> On Sat, 07 Jan 2012 03:57:33 +0100, Ojan Vafai  wrote:
>
>> Different apps
>> have different needs and it's crappy for them to have to handle enter
>> themselves just to get a different block type on enter.
>>
>> Something like document.execCommand("**DefaultBlock", false, tagName).
>> What
>> values are valid for tagName are open to discussion. At a minimum, I'd
>> want
>> to see "div", "p" and "br".
>>
>
> What is the use case for "br" that "div" doesn't cover?


Single br tag is shorter than pairs of div tags when serialized.

 I'm tempted to say that any block type should be allowed,
>>
>
> I strongly disagree. Supporting any block type opens up for lots of bugs
> and weird cases. We should only support the types necessary to cover
> presented use cases.


Yeah, supporting arbitrary block element will complicate a lot of things
especially because people can add "display: inline" as a css rule or in
inline style declarations.

- Ryosuke

Re: [FileAPI] Blob protocol version - is this needed?

[Arun Ranganathan]

Greetings Adrian,

Sorry for the delay in responding to this email.  

Strictly speaking, we could remove the Blob Protocol Version (BLV) [1].  It 
isn't returned in getAllResponseHeaders.  BLV 's purpose was in case the 
protocol changes, and to differentiate between versions.  But the protocol is 
internally consumed within the UA.  I can remove it.

--Original Message--

The current spec defines the Blob Protocol Version [1]. Our current 
implementation
doesn't require a protocol version and the way protocol handlers are defined in
Internet Explorer does require this. I don't know if this is ever exposed in
the web platform. The spec says that this should be returned from XHR in
getAllResponseHeaders [2] but I don't think XHR actually returns this string 
there.

Please can someone help point me to where this is required? If it isn't
exposed anywhere I think we can remove this section.

Thanks,

Adrian

[1] http://dev.w3.org/2006/webapi/FileAPI/#ProtocolName
[2] http://dev.w3.org/2006/webapi/FileAPI/#ProtocolExamples

Re: [editing] tab in an editable area WAS: [whatwg] behavior when typing in contentEditable elements

[Aryeh Gregor]

On Fri, Jan 6, 2012 at 10:12 PM, Ojan Vafai  wrote:
> There are strong use-cases for both. In an app like Google Docs you
> certainly want tab to act like indent. In a mail app, it's more of a
> toss-up. In something like the Google+ sharing widget, you certainly want it
> to maintain normal web tabbing behavior. Anecdotally, gmail has an internal
> lab to enable document-like tabbing behavior and it is crazy popular. People
> gush over it.

Hmm, good point.  Google Docs definitely wants tab to indent.

> We should make this configurable via execCommand:
> document.execCommand("TabBehavior", false, bitmask);

I'm leery of global flags like that, because they mean that if you
have two editors on the same page, they can interfere with each other
unwittingly.  useCss/styleWithCss is bad enough; I've seen author code
that just sets useCss or styleWithCss before every single command in
case something changed it in between.

Could the author just intercept the keystroke and run
document.execCommand("indent") themselves?  It's not as convenient, I
admit.  Alternatively, perhaps the flag could be set per editing host
somehow, and only function when that editing host has focus, although
I'm not sure what API to use.

> The bitmask is because you might want a different set of behaviors:
> -Tabbing in lists
> -Tabbing in table cells
> -Tabbing blockquotes
> -Tab in none of the above insert a tab
> -Tab in none of the above insert X spaces (X is controlled by the CSS
> tab-size property?)

Bitmasks are bad -- many JavaScript authors don't understand binary
well, if at all.  Also, what are use-cases where you'd want to toggle
indentation in all these cases separately?  More complexity without
supporting use-cases is a bad idea -- browsers have enough trouble
being interoperable as it stands, and more complexity just makes it
harder.

[Bug 15134] Please explain what the proper behavior of getSelection on a display:none iframe is

[bugzilla]

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

Aryeh Gregor  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||WORKSFORME

--- Comment #1 from Aryeh Gregor  2012-01-10 20:15:11 UTC ---
Sorry for the long time to respond -- I was on vacation for a while, then spent
a while doing other things.

The editing spec says "Every browsing context has a selection."
  The HTML
spec says "When an iframe element is first inserted into a document, the user
agent must create a nested browsing context".

 Thus the spec implies that any iframe in a document has a selection.  Testing,
this is how IE9, Chrome 17 dev, and Opera Next 12.00 alpha behave.  Firefox
12.0a1 returns null from getSelection() if the iframe is display: none.  I
don't see any advantage to Gecko's behavior, so I'll stick with the behavior of
the majority of browsers -- display: none should make no difference.

Reopen if you don't think the spec is clear enough.

-- 
Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

Re: Speech Recognition and Text-to-Speech Javascript API - seeking feedback for eventual standardization

[Glen Shires]

Art,
Per #2 Editor commitment(s): we confirm that Bjorn Bringert, Satish Sampath
and Glen Shires volunteer as editors. If others would like to help, we
welcome them.

Per #4 Testing commitment(s): can you elaborate on what you would like to
see at this point?

Also, what is the next step?

On Mon, Jan 9, 2012 at 8:12 AM, Olli Pettay  wrote:

> On 01/09/2012 04:59 PM, Arthur Barstow wrote:
>
>> Hi All,
>>
>> As I indicated in [1], WebApps already has a relatively large number of
>> specs in progress and the group has agreed to add some new specs. As
>> such, to review any new charter addition proposals, I think we need at
>> least the following:
>>
>> 1. Relatively clear scope of the feature(s). (This information should be
>> detailed enough for WG members with relevant IP to be able to make an IP
>> assessment.)
>>
>> 2. Editor commitment(s)
>>
>> 3. Implementation commitments from at least two WG members
>>
> Is this really requirement nowadays?
> Is there for example commitment to implement
> File System API?
> http://dev.w3.org/2009/dap/**file-system/file-dir-sys.html
>
> But anyway, I'm interested to implement the speech API,
> and as far as I know, also other people involved with Mozilla
> have shown interest.
>
>
>
>
>> 4. Testing commitment(s)
>>
>> Re the APIs in this thread -> I think Glen's API proposal [2] adequately
>> addresses #1 above and his previous responses imply support for #2 but
>> it would be good for Glen, et al. to confirm. Re #3, other than Google,
>> I don't believe any other implementor has voiced their support for
>> WebApps adding these APIs. As such, I think we we need additional input
>> on implementation support (e.g. Apple, Microsoft, Mozilla, Opera, etc.).
>>
>
> It doesn't matter too much to me in which group the API will be developed
> (except that I'm against doing it in HTML WG).
> WebApps is reasonably good place (if there won't be any IP issues.)
>
>
>
>
> -Olli
>
>
>
>
>> Re the markup question -> WebAppsdoes have some precedence for defining
>> markup (e.g. XBL2, Widget XML config). I don't have a strong opinion on
>> whether or not WebApps should include the type of markup in the XG
>> Report. I think the next step here is for WG members to submit comments
>> on this question. In particular, proponents of including markup in
>> WebApps' charter should respond to #1-4 above.
>>
>> -AB
>>
>> [1] http://lists.w3.org/Archives/**Public/public-webapps/**
>> 2011OctDec/1474.html
>> [2]
>> http://lists.w3.org/Archives/**Public/public-webapps/**
>> 2011OctDec/att-1696/speechapi.**html
>>
>>
>>
>> On 1/5/12 6:49 AM, ext Satish S wrote:
>>
>>>
>>> 2) How does the draft incorporate with the existing 
>>> API[1]? It seems to me as if it'd be best to define both the attribute
>>> as the DOM APIs in a single specification, also because they share
>>> several events (yet don't seem to be interchangeable) and the
>>> attribute already has an implementation.
>>>
>>>
>>> The  API proposal was implemented as >> x-webkit-speech> in Chromium a while ago. A lot of the developer
>>> feedback we received was about finer grained control including a
>>> javascript API and letting the web application decide how to present
>>> the user interface rather than tying it to the  element.
>>>
>>> The HTML Speech Incubator Group's final report [1] includes a 
>>> element which addresses both these concerns and provides automatic
>>> binding of speech recognition results to existing HTML elements. We
>>> are not sure if the WebApps WG is a good place to work on
>>> standardising such markup elements, hence did not include in the
>>> simplified Javascript API [2]. If there is sufficient interest and
>>> scope in the WebApps WG charter for the Javascript API and markup, we
>>> are happy to combine them both in the proposal.
>>>
>>> [1] 
>>> http://www.w3.org/2005/**Incubator/htmlspeech/XGR-**htmlspeech/
>>> [2]
>>> http://lists.w3.org/Archives/**Public/public-webapps/**
>>> 2011OctDec/att-1696/speechapi.**html
>>>
>>>
>>>
>>> Thanks,
>>> Peter
>>>
>>> [1]
>>> http://lists.w3.org/Archives/**Public/public-xg-htmlspeech/**
>>> 2011Feb/att-0020/api-draft.**html
>>>
>>>
>>> On Thu, Jan 5, 2012 at 07:15, Glen Shires >> > wrote:
>>> > As Dan Burnett wrote below: The HTML Speech Incubator Group [1]
>>> has recently
>>> > wrapped up its work on use cases, requirements, and proposals
>>> for adding
>>> > automatic speech recognition (ASR) and text-to-speech (TTS)
>>> capabilities to
>>> > HTML. The work of the group is documented in the 

[Bug 15495] New: I need some way of recovering from longer but still temporary failures, without requiring a complete page refresh, and without requiring every all events of interest to be rebound,

[bugzilla]

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

   Summary: I need some way of recovering from longer but still
temporary failures, without requiring a complete page
refresh, and without requiring every all events of
interest to be rebound, or otherwise handled
differently from any other event. This isn't an issue
   Product: WebAppsWG
   Version: unspecified
  Platform: Other
   URL: http://www.whatwg.org/specs/web-apps/current-work/#top
OS/Version: other
Status: NEW
  Severity: normal
  Priority: P3
 Component: Server-Sent Events (editor: Ian Hickson)
AssignedTo: i...@hixie.ch
ReportedBy: contribu...@whatwg.org
 QAContact: member-webapi-...@w3.org
CC: m...@w3.org, public-webapps@w3.org


Specification: http://www.w3.org/TR/eventsource/
Multipage: http://www.whatwg.org/C#top
Complete: http://www.whatwg.org/c#top

Comment:
I need some way of recovering from longer but still temporary failures,
without requiring a complete page refresh, and without requiring every all
events of interest to be rebound, or otherwise handled differently from any
other event.

This isn't an issue with the WebSocket and XMLHttpRequest API's, as those
interfaces already require one to implement an event passing scheme on top,
making it trivial to replace the underlying WebSocket or XMLHttpRequest. 
While such a scheme could also be implemented on top of EventSource, it seems
silly to stackan different event source scheme on top of something called
"EventSource".

Posted from: 70.64.129.37
User agent: Mozilla/5.0 (X11; Linux i686) AppleWebKit/535.2 (KHTML, like Gecko)
Ubuntu/10.04 Chromium/15.0.874.106 Chrome/15.0.874.106 Safari/535.2

-- 
Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

[Bug 15494] New: author request headers: Content-Transfer-Encoding

[bugzilla]

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

   Summary: author request headers: Content-Transfer-Encoding
   Product: WebAppsWG
   Version: unspecified
  Platform: All
   URL: http://dvcs.w3.org/hg/xhr/raw-file/tip/Overview.html#t
he-setrequestheader%28%29-method
OS/Version: All
Status: NEW
  Severity: normal
  Priority: P3
 Component: XHR
AssignedTo: ann...@opera.com
ReportedBy: julian.resc...@gmx.de
 QAContact: member-webapi-...@w3.org
CC: m...@w3.org, public-webapps@w3.org


The list of "author request headers" mentions Content-Transfer-Encoding. This
is confusing as there is no such header field in HTTP (there is one in email,
though).

-- 
Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

Worry on Enum type - binding seems inconsistently defined

[Harald Alvestrand]

Hello,

the WebRTC WG is currently contemplating following the WebApps WG's 
advice on avoiding use of integers in APIs, and switching to enums 
whenever possible.
However, one detail makes the spec at this time a bit hard to 
understand: In section 3.5, the following is said:


Note

In the ECMAScript binding, assignment of an invalid string value to 
anattribute is 
ignored, while passing such a value as anoperation 
argument results in 
an exception being thrown.


However, in the ECMAScript binding, section 4.2.18, it says:


An ECMAScript value V is converted to an IDL enumeration type value as 
follows (where E is the enumeration):


1. Let S be the result of calling ToString(V).
2. If S is not one of E's enumeration values, then throw a TypeError.
3. Return the enumeration value of type E that is equal to S.

I'm not sure it says the same thing; more clarity on the expected 
behaviour would be useful.
(My personal opinion is that it's most useful if assigment throws an 
exception; silent failure is rarely the best option.)


Although other bindings don't really matter so much, I would also think 
that it was a Good Thing if the spec gave advice saying that all 
bindings should detect value errors at assignment time, and signal 
errors appropriately for that language, rather than leaving the decision 
to binding designers.


That's all my worry

Harald

Re: querySelectorAll() -- selecting _immediate_ children of element

[Roland Steiner]

This has actually been discussed quite a bit on this list, in various
contexts - for example see
http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/0277.html(except
that you have to substitute ":scope" for your proposed ":this").


Cheers,

- Roland


On Mon, Jan 9, 2012 at 23:46, Marat Tanalin | tanalin.com <
mtana...@yandex.ru> wrote:

> querySelector() and querySelectorAll() methods are exciting features, but
> they do not allow select _immediate_ children of reference element.
>
> To address this lack, we could use following syntax:
>
> var divs = refElement.querySelectorAll('> DIV');
>
> Here 'divs' variable contains list of DIV elements that are immediate
> children (not just descendant elements) of reference element (refElement).
>
> This syntax is extremely intuitive and BTW is supported in jQuery.
>
> Other combinators (e.g. adjacent-sibling combinator) would have sense too,
> for example:
>
> var span = h1.querySelector('+ H2 SPAN');
>
> 'span' variable here contains DOM reference to SPAN elements inside H2
> element which is next sibling of H1 element:
>
> ...
> ... ... ...
>
> But fundamental missing demanded feature is ability to select _child_
> elements of reference element ( querySelectorAll('> DIV') ).
>
> Since usecases are purely script-level, CSSWG has nothing to do with this
> syntax. From selectors perspective, there is nothing new here: we have
> reference element (in CSS, a selector is used in place of concrete
> element), standard selector (DIV), and standard combinator between them.
>
> An acceptable alternative to implied reference element would be using
> ':this' pseudoclass:
>
> var divs = refElement.querySelectorAll(':this > DIV');
> var span = h1.querySelector(':this + H2 SPAN');
>
> Furthermore, :this pseudoclass would give us additional possibilities such
> as selecting descendant elements via selectors _all_ parts of which matches
> to descendants of reference element.
>
> For example, following code will select all links that are descendants of
> _any_ paragraph (not necessarily descendants of reference element):
>
> refElement.querySelectorAll('P A');
>
> As opposed, this code:
>
> refElement.querySelectorAll(':this P A');
>
> would select links that are inside of paragraphs which _themselves_ are
> descendants of the reference element.
>
> Probably most DRY, usable, and flexible solution would be to allow both
> syntaxes: implied reference element to use with combinators (where :this
> would be just redundant), and explicit :this to use in conjunction with
> descendant selectors (where it really gives additional useful possibilities
> missing in current querySelector spec and implementations).
>
> Thanks.
>
> P.S. The proposal has been originally posted in public-script-coord (
> http://lists.w3.org/Archives/Public/public-script-coord/2012JanMar/0078.html) 
> but it seems public-webapps is probably more appropriate place for this.
>
>