Re: Pressing Enter in contenteditable: or or ?

[Hallvord R. M. Steen]

On Wed, 11 Jan 2012 18:31:26 +0100, Ryosuke Niwa  wrote:


Actually, applying p {margin:0} looks quite trivial.


The problem is that many existing contents don't have that css rule and  
we obviously don't want to create markup like   
for it is too verbose.


Probably a stupid question, but one I've always wanted to ask: couldn't we  
default to a different, smaller, possibly 0 margin for P when in editable  
content?


--
Hallvord R. M. Steen, Core Tester, Opera Software
http://www.opera.com http://my.opera.com/hallvors/

Re: Pressing Enter in contenteditable: or or ?

[Simon Pieters]

On Wed, 11 Jan 2012 16:39:48 +0100, Aryeh Gregor  wrote:


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

p has default margins. That alone is enough for us not to adopt p as
the default paragraph separator.


On Wed, Jan 11, 2012 at 5:15 AM, Simon Pieters  wrote:
Sure, but some apps like to send their stuff in HTML email to clients  
that

don't support styling, or some such.


I used to think that this was a strong argument, but then I realized
 and  and  have default margins too.  So if you
want it to look right, you'll have to use a stylesheet.  Also, it's
worth pointing out that recent versions of Word have margins by
default when you hit Enter.

But Simon makes a good point: for the e-mail use-case, styling might
not be available.  So this is a decent reason to support .


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.


This is also a good reason -- it lets preexisting apps that expect
 opt into that behavior in new browsers, instead of being
rewritten to support .

Okay, so what API should we use?  I'd really prefer this be
per-editing host.  In which case, how about we make it a content
attribute on the editing host?  It can be a DOMSettableTokenList.
Maybe something like

  

where the attribute is a whitespace-separated list of tokens.  To
start with, we can maybe have tab-indent (hitting Tab indents) and
div-separator (hitting Enter produces div).  Does this sound like a
good approach?  If so, what should we call the attribute?


Currently the editing options available, other than enabling and disabling  
contenteditable, use the execCommand API. I don't see why we should switch  
to attributes for new editing options. To make editing options per editing  
host, I prefer this proposal:


[[

Ojan suggested in the other thread that we instead allow calling
execCommand() on Element, and have the result restricted to that
Element.  That solves the global-flags problem too, and doesn't
require new attributes.  So you'd do

 div.execCommand("tabindent", false, "true");

or whatever.  Someone could still call
document.execCommand("tabindent", false, "false"), but that would be
overridden if it was called on the editing host.  I filed a bug on it:

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

Does that sound good too?

]]


 And should
it imply contenteditable=true, or should the author have to specify
that separately?


The latter IMHO.


Also: are there any good use-cases for ?


I still haven't seen any.


Allowing  instead
of  adds basically no extra complexity, but allowing  would
make things significantly more complicated.



On Wed, 11 Jan 2012 21:15:18 +0100, Ryosuke Niwa  wrote:


> Should enter behave like shift+enter when br is the default
> paragraph separator?

Default paragraph separators are used in a couple of other places too,
so it would be a little more work than that.


Indeed, e.g. shift+enter doesn't break out of lists, so it's not  
equivalent. Making it equivalent would be adding some complexity.



But I just looked, and
it wouldn't be as bad as I thought.  So this is doable if people have
any good use-cases.



Great.


So what's the use case? :-) If none are presented, I object to adding it  
based on the Avoid Needless Complexity and Solve Real Problems design  
principles.


--
Simon Pieters
Opera Software

Re: File modification

[Jonas Sicking]

On Wed, Jan 11, 2012 at 12:35 PM, Charles Pritchard  wrote:
> On 1/11/2012 12:27 PM, Eric U wrote:
>>
>> On Wed, Jan 11, 2012 at 12:22 PM, Charles Pritchard
>>  wrote:
>>>
>>> On 1/11/2012 9:00 AM, Glenn Maynard wrote:


 This isn't properly specced anywhere and may be impossible to implement
 perfectly, but previous discussions indicated that Chrome, at least,
 wanted
 File objects loaded from input elements to only represent access for the
 file as it is when the user opened it.  That is, the File is immutable
 (like
 a Blob), and if the underlying OS file changes (thus making the original
 data no longer available), attempting to read the File would fail.
  (This
 was in the context of storing File in structured clone persistent
 storage,
 like IndexedDB.)

>>> Mozilla seems to only take a snapshot when the user opens the file.
>>> Chrome
>>> goes in the other direction, and does so intentionally with FileEntry.
>>> I'd prefer everyone follow Chrome.
>>
>> We do so with FileEntry, in the sandbox, because it's intended to be a
>> much more powerful API than File, and the security aspects of it are
>> much simpler.  When the user drags a File into the browser, it's much
>> less clear that they intend to give the web app persistent access to
>> that File, including all future changes until the page is closed.  I
>> don't think we'd rush to make that change to the spec.  And if our
>> implementation isn't snapshotting currently, that's a bug.
>
>
> In my reading of the spec, UAs explicitly instructed not to implement a
> snapshot.

If so that's a bug in the spec.

File and Blob objects are intended to contain constant data. For a
file object returned from  I would expect the
implementation to make all reads fail if the data changes on disk. I
know we don't do this in Firefox right now, but I consider that a bug.

/ Jonas

CfC: to add Speech API to Charter; deadline January 19

[Arthur Barstow]

Glen Shires and some others at Google proposed [1] that WebApps add 
Speech API to WebApps' charter and they put forward the Speech 
Javascript API Specification [2] as as a starting point. Members of 
Mozilla and Nuance have voiced various levels of support for this 
proposal. As such, this is a Call for Consensus to add Speech API to 
WebApps' charter.


Positive response to this CfC is preferred and encouraged and silence 
will be considered as agreeing with the proposal. The deadline for 
comments is January 19 and all comments should be sent to public-webapps 
at w3.org.


-AB

[1] http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/1696.html
[2] 
http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/att-1696/speechapi.html

[Bug 15532] New: Collapsing or extending to a ProcessingInstruction should be OK

[bugzilla]

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

   Summary: Collapsing or extending to a ProcessingInstruction
should be OK
   Product: WebAppsWG
   Version: unspecified
  Platform: All
   URL: http://dvcs.w3.org/hg/editing/raw-file/tip/selecttest/
collapse.html
OS/Version: All
Status: NEW
  Severity: normal
  Priority: P2
 Component: HTML Editing APIs
AssignedTo: a...@aryeh.name
ReportedBy: stig...@opera.com
 QAContact: sideshowbarker+html-editing-...@gmail.com
CC: m...@w3.org, public-webapps@w3.org


Created attachment 1065
  --> https://www.w3.org/Bugs/Public/attachment.cgi?id=1065
Test patch, PI

In the selecttest/collapse.html and selecttest/extend.html tests there are a
few tests that expect the browser to throw an INVALID_NODE_TYPE_ERR when trying
to collapse or extend to a PI.
According to the Selection [1] and Range [2] specs, it is not illegal to do
that, so I think the tests are wrong.

Patch attached.

[1]
http://dvcs.w3.org/hg/editing/raw-file/tip/editing.html#dom-selection-collapse
http://dvcs.w3.org/hg/editing/raw-file/tip/editing.html#dom-selection-extend

[2]
http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#concept-range-bp-set

-- 
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 15533] New: Index check in selection.extend() should be done before node type test.

[bugzilla]

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

   Summary: Index check in selection.extend() should be done
before node type test.
   Product: WebAppsWG
   Version: unspecified
  Platform: All
OS/Version: All
Status: NEW
  Severity: normal
  Priority: P2
 Component: HTML Editing APIs
AssignedTo: a...@aryeh.name
ReportedBy: stig...@opera.com
 QAContact: sideshowbarker+html-editing-...@gmail.com
CC: m...@w3.org, public-webapps@w3.org


Created attachment 1066
  --> https://www.w3.org/Bugs/Public/attachment.cgi?id=1066
Test patch, index

According to the Selection spec for extend [1], the checking of offset compared
to parentNode's length should be done before setting the new boundary points
for the range [2] which would trigger the node type exception for doctype.

In the selecttest/extend.html tests there are a few tests that expect the
browser to throw an INVALID_NODE_TYPE_ERR, where in fact the INDEX_SIZE_ERR
exception should be checked and thrown first.

Patch attached.

[1]
http://dvcs.w3.org/hg/editing/raw-file/tip/editing.html#dom-selection-extend

[2]
http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#concept-range-bp-set

-- 
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 Thu, Jan 12, 2012 at 1:58 AM, Hallvord R. M. Steen wrote:

> On Wed, 11 Jan 2012 18:31:26 +0100, Ryosuke Niwa  wrote:
>
>  Actually, applying p {margin:0} looks quite trivial.
>>>
>>
>> The problem is that many existing contents don't have that css rule and
>> we obviously don't want to create markup like  for
>> it is too verbose.
>>
>
> Probably a stupid question, but one I've always wanted to ask: couldn't we
> default to a different, smaller, possibly 0 margin for P when in editable
> content?


We could but then existing mail clients, Web UAs, etc... will continue to
have those margins. Given many websites store markups generated by UAs in
contenteditable to be rendered by other UAs, adding such a style doesn't
solve anything in my opinion.

- Ryosuke

Re: String to ArrayBuffer

[Henri Sivonen]

On Thu, Jan 12, 2012 at 1:12 AM, Kenneth Russell  wrote:
> The StringEncoding proposal is the best path forward because it
> provides correct behavior in all cases.

Do you mean this one? http://wiki.whatwg.org/wiki/StringEncoding

I see the following problems after a cursory glance:
 1) It doesn't support streaming encoding/decoding.
 2) BINARY and ISO-8859-1 are defined as functionally equivalent. It
would be better to keep BINARY and get rid of real ISO-8859-1, because
normally the Web platform doesn't support real ISO-8859-1 and
ISO-8859-1 is an alias for Windows-1252.
 3) UTF-16 is supported, which is bad, because it's a terrible idea to
use UTF-16 for interchange.
 4) It says "Browsers MAY support additional encodings." This is a
huge non-interoperability loophole. The spec should have a small and
fixed set of supported encodings that everyone MUST support and
supporting other encodings should be a "MUST NOT".

What's the motivation for supporting encodings other than UTF-8 and BINARY?

-- 
Henri Sivonen
hsivo...@iki.fi
http://hsivonen.iki.fi/

Re: File modification

[Glenn Maynard]

Side-effects of event registration are outside of the DOM event model.  UAs
can do whatever transparent optimizations they want, of course, but  APIs
shouldn't *depend* on that for efficient implementations.

Occasional polling definitely has significant overhead (directories may
have tens of thousands of files, be on network shares, etc), and should be
widely avoided.

I also wonder whether change notifications work over eg. NFS.  It would be
bad if this feature only sometimes worked (especially if it breaks on major
but less used configurations like NFS), since once deployed, apps will be
designed around it.
 On Jan 11, 2012 12:22 PM, "Charles Pritchard"  wrote:

> On 1/11/2012 9:00 AM, Glenn Maynard wrote:
>
>>
>> This isn't properly specced anywhere and may be impossible to implement
>> perfectly, but previous discussions indicated that Chrome, at least, wanted
>> File objects loaded from input elements to only represent access for the
>> file as it is when the user opened it.  That is, the File is immutable
>> (like a Blob), and if the underlying OS file changes (thus making the
>> original data no longer available), attempting to read the File would fail.
>>  (This was in the context of storing File in structured clone persistent
>> storage, like IndexedDB.)
>>
>>
> Mozilla seems to only take a snapshot when the user opens the file. Chrome
> goes in the other direction, and does so intentionally with FileEntry.
> I'd prefer everyone follow Chrome.
>
> The spec on this could be nudged slightly to support Chrome's existing
> behavior.
>
> From drag&drop:
> http://www.whatwg.org/specs/**web-apps/current-work/**multipage/dnd.html
> "The files attribute must return a live FileList sequence...".
>
> http://www.whatwg.org/specs/**web-apps/current-work/**
> multipage/infrastructure.html#**live
> "If a DOM object is said to be live, then the attributes and methods on
> that object must operate on the actual underlying data, not a snapshot of
> the data."
>
> Drag&drop continues:
> "for a given FileList object and a given underlying file, the same File
> object must be used each time."
>
> Given that the underlying file can change, and the FileList sequence is
> live, it seems reasonable that subsequent reads of FileList would access a
> different File object when the underlying file has changed.
>
> FileList.onchanged would be appropriate. File.onupdated would not be
> appropriate. Entry.onupdated would be appropriate.
>
>  I have one major technical concern: monitoring files for changes isn't
>> free.  With only a DOM event, all instantiated Files (or Entries) would
>> have to monitor changes; you don't want to depend on "do something if an
>> event handler is registered", since that violates the principle of event
>> handler registration having no other side-effects.  Monitoring should be
>> enabled explicitly.
>>
>> I also wonder whether this could be implemented everywhere, eg. on mobile
>> systems.
>>
>>
> At this point, iOS still doesn't allow  nor
> dataTransfer of file. So, we're looking far ahead.
>
> A system may send a FileList.onchanged() event when it notices that the
> FileList has been updated. It can be done on access of a live FileList when
> a mutation is detected. It could be done by occasional polling, or it could
> be done via notify-style OS hooks. In the first case, there is no
> significant overhead. webkitdirectory returns a FileList object that can be
> monitored via directory notification hooks; again, if the OS supports it.
>
> Event handlers have some side effects, but not in the scripting
> environment. onclick, for example, may mean that an element responds to
> touch events in the mobile environment.
>
>
> -Charles
>
>
>

Re: File modification

[Glenn Maynard]

FYI, I don't think this is clear for File from the spec.  It's even more
important if File objects are stored in History or IndexedDB; that it
should be a *shallow* copy, with enough information stored to invalidate it
if the underlying file changes, doesn't seem to be specified.  (As far as I
know, nobody implements that yet; being able to eg. retain open files in
History states would be extremely useful.)

Allowance should be made for the fact that this is just best-effort; if
another application modifies blocks of the file in-place without changing
the mtime or size of the file, there's usually no reasonable way for a
browser to detect it.
On Jan 12, 2012 12:30 AM, "Jonas Sicking"  wrote:

> On Wed, Jan 11, 2012 at 12:35 PM, Charles Pritchard  wrote:
> > On 1/11/2012 12:27 PM, Eric U wrote:
> >>
> >> On Wed, Jan 11, 2012 at 12:22 PM, Charles Pritchard
> >>  wrote:
> >>>
> >>> On 1/11/2012 9:00 AM, Glenn Maynard wrote:
> 
> 
>  This isn't properly specced anywhere and may be impossible to
> implement
>  perfectly, but previous discussions indicated that Chrome, at least,
>  wanted
>  File objects loaded from input elements to only represent access for
> the
>  file as it is when the user opened it.  That is, the File is immutable
>  (like
>  a Blob), and if the underlying OS file changes (thus making the
> original
>  data no longer available), attempting to read the File would fail.
>   (This
>  was in the context of storing File in structured clone persistent
>  storage,
>  like IndexedDB.)
> 
> >>> Mozilla seems to only take a snapshot when the user opens the file.
> >>> Chrome
> >>> goes in the other direction, and does so intentionally with FileEntry.
> >>> I'd prefer everyone follow Chrome.
> >>
> >> We do so with FileEntry, in the sandbox, because it's intended to be a
> >> much more powerful API than File, and the security aspects of it are
> >> much simpler.  When the user drags a File into the browser, it's much
> >> less clear that they intend to give the web app persistent access to
> >> that File, including all future changes until the page is closed.  I
> >> don't think we'd rush to make that change to the spec.  And if our
> >> implementation isn't snapshotting currently, that's a bug.
> >
> >
> > In my reading of the spec, UAs explicitly instructed not to implement a
> > snapshot.
>
> If so that's a bug in the spec.
>
> File and Blob objects are intended to contain constant data. For a
> file object returned from  I would expect the
> implementation to make all reads fail if the data changes on disk. I
> know we don't do this in Firefox right now, but I consider that a bug.
>
> / Jonas
>

[Bug 15532] Collapsing or extending to a ProcessingInstruction should be OK

[bugzilla]

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

Aryeh Gregor  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #1 from Aryeh Gregor  2012-01-12 15:24:17 UTC ---
Thanks!  Accepted:

http://dvcs.w3.org/hg/editing/rev/9ca0bc5d4285

These checks date back from before DOM4 declared ProcessingInstructions to be
CharacterData.  They weren't allowed as Range endpoints because they were an
annoying special case.  Now they're allowed just like Text and Comment, with no
extra spec effort, but the tests weren't updated.

-- 
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.

Testing Expectations (was: Speech Recognition and Text-to-Speech Javascript API - seeking feedback for eventual standardization)

[Doug Schepers]

Hi, folks-

On 1/11/12 9:40 AM, Arthur Barstow wrote:

On 1/10/12 11:25 AM, ext Glen Shires wrote:

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


At this point, I think a `warm fuzzy` like "if/when the spec advances to
Candidate Recommendation, we will contribute to a test suite that is
sufficient to exit the CR" would be useful.


I agree with this general sentiment, but I'd like to offer a different 
priority to tests.


Technically, the W3C Process does not require a test suite, but 
pragmatically, it's the best way to indicate conformance and 
implementability, and to promote interoperability.


Modern expectations (e.g. in the last 4-6 years) about the specification 
process include early prototyping and implementation feedback well 
before CR phase, with real-world webapps depending upon these early 
implementations, so we need interoperability fairly early on.


The infrastructure and methodology for creating and maintaining tests 
(at W3C and in implementation projects) has improved dramatically in the 
last few years as well, so it's easier to do.


As such, the creation of tests should not be left to CR... there should 
be a plan in place (e.g. a person, and a loose policy, like "as we 
implement, we'll make tests and contribute them to the WG"), and a 
person responsible for collecting and maintaining the tests (i.e. making 
sure that the tests are adapted to meet the changing spec).


Regards-
-Doug

Selection of a document that doesn't have a window

[Aryeh Gregor]

What does document.implementation.createHTMLDocument("").getSelection() return?

* IE9 returns a Selection object unique to that document.
* Firefox 12.0a1 and Opera Next 12.00 alpha return the same thing as
document.getSelection().
* Chrome 17 dev returns null.

I prefer IE's behavior just for the sake of simplicity.  If we go with
Gecko/WebKit/Opera, we have to decide how to identify which documents
get their own selections and which don't.  The definition should
probably be something like "documents that are returned by the
.document property of some window", but I have no idea if that's a
sane way to phrase it.

So should the spec follow IE?  If not, what definition should we use
to determine which documents get selections?

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

[Aryeh Gregor]

On Wed, Jan 11, 2012 at 3:09 PM, Charles Pritchard  wrote:
> The reason is listed in WCAG2 section 2.1.2 and CR5.
> http://www.w3.org/TR/WCAG/
>
> The items suggest that a standard means of moving focus be maintained. Users
> should be given simple instructions on how to move focus if the keyboard is
> trapped.
>
> When the tab key is trapped, I recommend having the escape key move focus
> and untrap tab. That said, that can interfere with full screen mode, which
> may also use escape with varying success.

What do programs like Word do?  Do they allow the user to escape the
page and use tab to navigate the UI somehow?

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

[Tab Atkins Jr.]

On Thu, Jan 12, 2012 at 8:41 AM, Aryeh Gregor  wrote:
> On Wed, Jan 11, 2012 at 3:09 PM, Charles Pritchard  wrote:
>> The reason is listed in WCAG2 section 2.1.2 and CR5.
>> http://www.w3.org/TR/WCAG/
>>
>> The items suggest that a standard means of moving focus be maintained. Users
>> should be given simple instructions on how to move focus if the keyboard is
>> trapped.
>>
>> When the tab key is trapped, I recommend having the escape key move focus
>> and untrap tab. That said, that can interfere with full screen mode, which
>> may also use escape with varying success.
>
> What do programs like Word do?  Do they allow the user to escape the
> page and use tab to navigate the UI somehow?

Usually in desktop programs Alt is the escape sequence, taking you to
the menu bar where you can tab (or sometimes arrow) your way around.
Obviously this doesn't work for webpages, since Alt would take you to
the *browser's* menu bar.

~TJ

Re: Testing Expectations

[Arthur Barstow]

On 1/12/12 11:06 AM, ext Doug Schepers wrote:

Hi, folks-

On 1/11/12 9:40 AM, Arthur Barstow wrote:

On 1/10/12 11:25 AM, ext Glen Shires wrote:

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


At this point, I think a `warm fuzzy` like "if/when the spec advances to
Candidate Recommendation, we will contribute to a test suite that is
sufficient to exit the CR" would be useful.


As such, the creation of tests should not be left to CR... 


Yes, good point Doug.

-AB
there should be a plan in place (e.g. a person, and a loose policy, 
like "as we implement, we'll make tests and contribute them to the 
WG"), and a person responsible for collecting and maintaining the 
tests (i.e. making sure that the tests are adapted to meet the 
changing spec).

Re: String to ArrayBuffer

[Glenn Adams]

On Thu, Jan 12, 2012 at 3:49 AM, Henri Sivonen  wrote:

> On Thu, Jan 12, 2012 at 1:12 AM, Kenneth Russell  wrote:
> > The StringEncoding proposal is the best path forward because it
> > provides correct behavior in all cases.
>
> Do you mean this one? http://wiki.whatwg.org/wiki/StringEncoding
>
> I see the following problems after a cursory glance:
>  4) It says "Browsers MAY support additional encodings." This is a
> huge non-interoperability loophole. The spec should have a small and
> fixed set of supported encodings that everyone MUST support and
> supporting other encodings should be a "MUST NOT".
>

In practice, it will be impractical if not impossible to enforce such a
dictum "MUST NOT support other encodings". Implementers will support
whatever they like when it comes to character encodings, both for
interchange, runtime storage, and persistent storage.

Regarding use of the word "support" in the context of character encodings,
it would be useful if folks would explicitly qualify support as applying to
one of these three uses (interchange, runtime storage, persistent storage).

[Bug 15533] Index check in selection.extend() should be done before node type test.

[bugzilla]

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

Aryeh Gregor  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #1 from Aryeh Gregor  2012-01-12 17:13:08 UTC ---
Actually, it seems like I should just reference DOM4's "set the start or end"
algorithm for simplicity.  This results in throwing InvalidNodeTypeError first.
 This:

  document.createRange().setStart(document.doctype, -13);

throws InvalidNodeTypeError in Firefox 12.0a1 and Chrome 17 dev, per DOM4; and
IndexSizeError in IE9 and Opera Next 12.00 alpha, not per DOM4.  We should be
consistent and throw InvalidNodeTypeError for extend() just like setStart().

I've changed the spec to reference DOM4's algorithm, which I believe makes the
tests correct:

http://dvcs.w3.org/hg/editing/rev/0ef300a5c14f

Please tell me if this isn't satisfactory.  Thanks!

-- 
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: String to ArrayBuffer

[Tab Atkins Jr.]

On Thu, Jan 12, 2012 at 8:59 AM, Glenn Adams  wrote:
> On Thu, Jan 12, 2012 at 3:49 AM, Henri Sivonen  wrote:
>> On Thu, Jan 12, 2012 at 1:12 AM, Kenneth Russell  wrote:
>> > The StringEncoding proposal is the best path forward because it
>> > provides correct behavior in all cases.
>>
>> Do you mean this one? http://wiki.whatwg.org/wiki/StringEncoding
>>
>> I see the following problems after a cursory glance:
>>  4) It says "Browsers MAY support additional encodings." This is a
>> huge non-interoperability loophole. The spec should have a small and
>> fixed set of supported encodings that everyone MUST support and
>> supporting other encodings should be a "MUST NOT".
>
>
> In practice, it will be impractical if not impossible to enforce such a
> dictum "MUST NOT support other encodings". Implementers will support
> whatever they like when it comes to character encodings, both for
> interchange, runtime storage, and persistent storage.

Actually, such requirements often work relatively well.  Many
implementors recognize the pain caused by race-to-the-bottom support
for random encodings.

~TJ

Re: File modification

[Charles Pritchard]

On Jan 12, 2012, at 6:58 AM, Kyle Huey  wrote:

> On Thu, Jan 12, 2012 at 3:45 PM, Glenn Maynard  wrote:
> FYI, I don't think this is clear for File from the spec.  It's even more 
> important if File objects are stored in History or IndexedDB; that it should 
> be a *shallow* copy, with enough information stored to invalidate it if the 
> underlying file changes, doesn't seem to be specified.  (As far as I know, 
> nobody implements that yet; being able to eg. retain open files in History 
> states would be extremely useful.
> 
> Gecko nightlies are capable of storing File objects in IndexedDB,  We are 
> doing "deep" copies (what is retrieved from the database is always a copy of 
> the file as it was when it was placed in the database).

Oh I'm glad to see this one! Is it Blob and File that can be put into IDB? How 
do I create a new File (with a name field) from a Blob?

-Charles

Re: String to ArrayBuffer

[Glenn Adams]

On Thu, Jan 12, 2012 at 10:10 AM, Tab Atkins Jr. wrote:

> On Thu, Jan 12, 2012 at 8:59 AM, Glenn Adams  wrote:
> > On Thu, Jan 12, 2012 at 3:49 AM, Henri Sivonen  wrote:
> >> On Thu, Jan 12, 2012 at 1:12 AM, Kenneth Russell 
> wrote:
> >> > The StringEncoding proposal is the best path forward because it
> >> > provides correct behavior in all cases.
> >>
> >> Do you mean this one? http://wiki.whatwg.org/wiki/StringEncoding
> >>
> >> I see the following problems after a cursory glance:
> >>  4) It says "Browsers MAY support additional encodings." This is a
> >> huge non-interoperability loophole. The spec should have a small and
> >> fixed set of supported encodings that everyone MUST support and
> >> supporting other encodings should be a "MUST NOT".
> >
> >
> > In practice, it will be impractical if not impossible to enforce such a
> > dictum "MUST NOT support other encodings". Implementers will support
> > whatever they like when it comes to character encodings, both for
> > interchange, runtime storage, and persistent storage.
>
> Actually, such requirements often work relatively well.  Many
> implementors recognize the pain caused by race-to-the-bottom support
> for random encodings.


I speak of enforcement. Will there be test cases to check for support of a
random encoding not included in a blessed list? I suspect not.

Re: File modification

[Charles Pritchard]

On 1/12/2012 12:30 AM, Jonas Sicking wrote:

On Wed, Jan 11, 2012 at 12:35 PM, Charles Pritchard  wrote:

On 1/11/2012 12:27 PM, Eric U wrote:

On Wed, Jan 11, 2012 at 12:22 PM, Charles Pritchard
  wrote:

On 1/11/2012 9:00 AM, Glenn Maynard wrote:


This isn't properly specced anywhere and may be impossible to implement
perfectly, but previous discussions indicated that Chrome, at least,
wanted
File objects loaded from input elements to only represent access for the
file as it is when the user opened it.  That is, the File is immutable
(like
a Blob), and if the underlying OS file changes (thus making the original
data no longer available), attempting to read the File would fail.
  (This
was in the context of storing File in structured clone persistent
storage,
like IndexedDB.)


Mozilla seems to only take a snapshot when the user opens the file.
Chrome
goes in the other direction, and does so intentionally with FileEntry.
I'd prefer everyone follow Chrome.

We do so with FileEntry, in the sandbox, because it's intended to be a
much more powerful API than File, and the security aspects of it are
much simpler.  When the user drags a File into the browser, it's much
less clear that they intend to give the web app persistent access to
that File, including all future changes until the page is closed.  I
don't think we'd rush to make that change to the spec.  And if our
implementation isn't snapshotting currently, that's a bug.


In my reading of the spec, UAs explicitly instructed not to implement a
snapshot.

If so that's a bug in the spec.

File and Blob objects are intended to contain constant data. For a
file object returned from  I would expect the
implementation to make all reads fail if the data changes on disk. I
know we don't do this in Firefox right now, but I consider that a bug.


The FileList object is what we're looking at.  Yes, File and Blob should 
be constant data.


When the underlying File data changes, the FileList object should point 
to the new file or otherwise not return the item in the list.


Yes, Firefox has a bug: it is not creating a new File object when 
FileList is accessed for a modified file.

It's not throwing an error on when the old File object is used.

This seems like a relatively easy fix to FileList and the File object.


-Charles

Re: String to ArrayBuffer

[Tab Atkins Jr.]

On Thu, Jan 12, 2012 at 9:54 AM, Charles Pritchard  wrote:
> I don't see it being a particularly bad thing if vendors expose more
> translation encodings. I've only come across one project that would use
> them. Binary and utf8 handle everything else I've come across, and I can use
> them to build character maps for the rest, if I ever hit another strange
> project that needs them.

As always, the problem is that if one browser supports an encoding
that no one else does, then content will be written that depends on
that encoding, and thus is locked into that browser.  Other browsers
will then feel competitive pressure to support the encoding, so that
the content works on them as well.  Repeat this for the union of
encodings that every browser supports.

It's not necessarily true that this will happen for every single
encoding.  History shows us that it will probably happen with at least
*several* encodings, if nothing is done to prevent it.  But there's no
reason to risk it, when we can legislate against it and even test for
common things that browsers *might* support.

~TJ

Re: File modification

[Charles Pritchard]

On 1/12/2012 6:34 AM, Glenn Maynard wrote:


Side-effects of event registration are outside of the DOM event 
model.  UAs can do whatever transparent optimizations they want, of 
course, but  APIs shouldn't *depend* on that for efficient 
implementations.


Occasional polling definitely has significant overhead (directories 
may have tens of thousands of files, be on network shares, etc), and 
should be widely avoided.


I also wonder whether change notifications work over eg. NFS.  It 
would be bad if this feature only sometimes worked (especially if it 
breaks on major but less used configurations like NFS), since once 
deployed, apps will be designed around it.




On NFS and directories where directory notification is not available: 
send an onchanged event to FileList when an underlying File object 
changes upon access of its entry in FileList.


That is... as I'm looping through FileList grabbing files, it may 
invalidate a File object. FileList has now "changed".

I won't know until the next event loop. That's good enough.

Re: File modification

[Glenn Maynard]

That's not good enough for many use cases.  For example, a notepad app that
saves to disk wants to update the display if another program modifies the
file.  You don't want that to be delayed until you scan the directory; you
want the event pushed at you immediately  when it happens.  This is how I
imagine most use cases looking.
On Jan 12, 2012 10:16 AM, "Charles Pritchard"  wrote:

> On 1/12/2012 6:34 AM, Glenn Maynard wrote:
>
>>
>> Side-effects of event registration are outside of the DOM event model.
>>  UAs can do whatever transparent optimizations they want, of course, but
>>  APIs shouldn't *depend* on that for efficient implementations.
>>
>> Occasional polling definitely has significant overhead (directories may
>> have tens of thousands of files, be on network shares, etc), and should be
>> widely avoided.
>>
>> I also wonder whether change notifications work over eg. NFS.  It would
>> be bad if this feature only sometimes worked (especially if it breaks on
>> major but less used configurations like NFS), since once deployed, apps
>> will be designed around it.
>>
>>
> On NFS and directories where directory notification is not available: send
> an onchanged event to FileList when an underlying File object changes upon
> access of its entry in FileList.
>
> That is... as I'm looping through FileList grabbing files, it may
> invalidate a File object. FileList has now "changed".
> I won't know until the next event loop. That's good enough.
>
>
>
>
>

Re: File modification

[Charles Pritchard]

You're at the mercy of many types of latency with web apps.

For the high-importance notepad case, you're talking about one file. I can poll 
every second from my web app and back off when the screen is idle, with current 
code in Chrome. Hooking into OS level file notification would give better 
results, and help me back off the polling. And if it's on NFS, and there's no 
update signal, looping through FileList would still get me my event.

NFS and thousands of files are an extreme case. But they can be managed and an 
update event would improve that management.

-Charles



On Jan 12, 2012, at 10:20 AM, Glenn Maynard  wrote:

> That's not good enough for many use cases.  For example, a notepad app that 
> saves to disk wants to update the display if another program modifies the 
> file.  You don't want that to be delayed until you scan the directory; you 
> want the event pushed at you immediately  when it happens.  This is how I 
> imagine most use cases looking.
> 
> On Jan 12, 2012 10:16 AM, "Charles Pritchard"  wrote:
> On 1/12/2012 6:34 AM, Glenn Maynard wrote:
> 
> Side-effects of event registration are outside of the DOM event model.  UAs 
> can do whatever transparent optimizations they want, of course, but  APIs 
> shouldn't *depend* on that for efficient implementations.
> 
> Occasional polling definitely has significant overhead (directories may have 
> tens of thousands of files, be on network shares, etc), and should be widely 
> avoided.
> 
> I also wonder whether change notifications work over eg. NFS.  It would be 
> bad if this feature only sometimes worked (especially if it breaks on major 
> but less used configurations like NFS), since once deployed, apps will be 
> designed around it.
> 
> 
> On NFS and directories where directory notification is not available: send an 
> onchanged event to FileList when an underlying File object changes upon 
> access of its entry in FileList.
> 
> That is... as I'm looping through FileList grabbing files, it may invalidate 
> a File object. FileList has now "changed".
> I won't know until the next event loop. That's good enough.
> 
> 
> 
> 

Re: CfC: to add Speech API to Charter; deadline January 19

[Marcos Caceres]

On Thursday, 12 January 2012 at 12:31, Arthur Barstow wrote:

> Glen Shires and some others at Google proposed [1] that WebApps add 
> Speech API to WebApps' charter and they put forward the Speech 
> Javascript API Specification [2] as as a starting point. Members of 
> Mozilla and Nuance have voiced various levels of support for this 
> proposal. As such, this is a Call for Consensus to add Speech API to 
> WebApps' charter.
> 
> Positive response to this CfC is preferred and encouraged and silence 
> will be considered as agreeing with the proposal. The deadline for 
> comments is January 19 and all comments should be sent to public-webapps 
> at w3.org (http://w3.org).
> 


FWIW, I support the addition of this API.



-- 
Marcos Caceres
http://datadriven.com.au

Re: File modification

[Kyle Huey]

On Thu, Jan 12, 2012 at 3:45 PM, Glenn Maynard  wrote:

> FYI, I don't think this is clear for File from the spec.  It's even more
> important if File objects are stored in History or IndexedDB; that it
> should be a *shallow* copy, with enough information stored to invalidate it
> if the underlying file changes, doesn't seem to be specified.  (As far as I
> know, nobody implements that yet; being able to eg. retain open files in
> History states would be extremely useful.
>
Gecko nightlies are capable of storing File objects in IndexedDB,  We are
doing "deep" copies (what is retrieved from the database is always a copy
of the file as it was when it was placed in the database).

- Kyle

Re: String to ArrayBuffer

[Charles Pritchard]

On Jan 12, 2012, at 9:17 AM, Glenn Adams  wrote:

> 
> 
> On Thu, Jan 12, 2012 at 10:10 AM, Tab Atkins Jr.  wrote:
> On Thu, Jan 12, 2012 at 8:59 AM, Glenn Adams  wrote:
> > On Thu, Jan 12, 2012 at 3:49 AM, Henri Sivonen  wrote:
> >> On Thu, Jan 12, 2012 at 1:12 AM, Kenneth Russell  wrote:
> >> > The StringEncoding proposal is the best path forward because it
> >> > provides correct behavior in all cases.
> >>
> >> Do you mean this one? http://wiki.whatwg.org/wiki/StringEncoding
> >>
> >> I see the following problems after a cursory glance:
> >>  4) It says "Browsers MAY support additional encodings." This is a
> >> huge non-interoperability loophole. The spec should have a small and
> >> fixed set of supported encodings that everyone MUST support and
> >> supporting other encodings should be a "MUST NOT".
> >
> >
> > In practice, it will be impractical if not impossible to enforce such a
> > dictum "MUST NOT support other encodings". Implementers will support
> > whatever they like when it comes to character encodings, both for
> > interchange, runtime storage, and persistent storage.
> 
> Actually, such requirements often work relatively well.  Many
> implementors recognize the pain caused by race-to-the-bottom support
> for random encodings.
> 
> I speak of enforcement. Will there be test cases to check for support of a 
> random encoding not included in a blessed list? I suspect not.

If it is an issue, an array of strings from a getSupportedEncodings method 
would solve that one.

I don't see it being a particularly bad thing if vendors expose more 
translation encodings. I've only come across one project that would use them. 
Binary and utf8 handle everything else I've come across, and I can use them to 
build character maps for the rest, if I ever hit another strange project that 
needs them.

-Charles

RE: to add Speech API to Charter; deadline January 19

[Young, Milan]

I've made the point a few times now, and would appreciate a response.
Why are we preferring to seed WebApps speech with [2] when we already
have [3] that represents industry consensus as of a month ago (Google
not withstanding)?  Proceeding with [2] would almost surely delay the
resulting specification as functionality would patched and haggled over
to meet consensus.

My counter proposal is to open the HTML/speech marriage in WebApps
essentially where we left off at [3].  The only variants being: 1)
Dropping the markup bindings in sections 7.1.2/7.1.3 because its primary
supporter has since expressed non-interest, and 2) Spin the protocol
specification in 7.2 out to the IETF.  If I need to formalize all of
this in a document, please let me know.

Thank you

[3] http://www.w3.org/2005/Incubator/htmlspeech/XGR-htmlspeech/



-Original Message-
From: Arthur Barstow [mailto:art.bars...@nokia.com] 
Sent: Thursday, January 12, 2012 4:31 AM
To: public-webapps
Cc: public-xg-htmlspe...@w3.org
Subject: CfC: to add Speech API to Charter; deadline January 19

Glen Shires and some others at Google proposed [1] that WebApps add
Speech API to WebApps' charter and they put forward the Speech
Javascript API Specification [2] as as a starting point. Members of
Mozilla and Nuance have voiced various levels of support for this
proposal. As such, this is a Call for Consensus to add Speech API to
WebApps' charter.

Positive response to this CfC is preferred and encouraged and silence
will be considered as agreeing with the proposal. The deadline for
comments is January 19 and all comments should be sent to public-webapps
at w3.org.

-AB

[1]
http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/1696.html
[2]
http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/att-1696/s
peechapi.html

Re: File modification

[Arun Ranganathan]

On Jan 12, 2012, at 6:58 AM, Kyle Huey < m...@kylehuey.com > wrote: 

> > On Thu, Jan 12, 2012 at 3:45 PM, Glenn Maynard < gl...@zewt.org >
> > wrote:
> 

> > > FYI, I don't think this is clear for File from the spec. It's
> > > even
> > > more important if File objects are stored in History or
> > > IndexedDB;
> > > that it should be a *shallow* copy, with enough information
> > > stored
> > > to invalidate it if the underlying file changes, doesn't seem to
> > > be
> > > specified. (As far as I know, nobody implements that yet; being
> > > able
> > > to eg. retain open files in History states would be extremely
> > > useful.
> > 
> 
> > Gecko nightlies are capable of storing File objects in IndexedDB,
> > We
> > are doing "deep" copies (what is retrieved from the database is
> > always a copy of the file as it was when it was placed in the
> > database).
> 

> Oh I'm glad to see this one! Is it Blob and File that can be put into
> IDB? How do I create a new File (with a name field) from a Blob?
Charles: see the thread on making Blobs constructable -- follow 
http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/0439.html 

The File API specification should do a better job describing what happens to a 
File if the underlying resource changes. We use the word immutable, but I think 
we have to make this substantially clearer. 

-- A* 

Re: Selection of a document that doesn't have a window

[Boris Zbarsky]

On 1/12/12 10:58 AM, Aryeh Gregor wrote:

* Firefox 12.0a1 and Opera Next 12.00 alpha return the same thing as
document.getSelection().


In Gecko, this is arguably an implementation bug.  It returns the 
selection associated with a particular Window object.  Which Window that 
is depends on how the document was created; I don't know that there's 
any such concept in the spec.



Gecko/WebKit/Opera, we have to decide how to identify which documents
get their own selections and which don't.  The definition should
probably be something like "documents that are returned by the
.document property of some window", but I have no idea if that's a
sane way to phrase it.


Documents that have a non-null defaultView?  Note that this may not be 
equivalent to your formulation, by the way


-Boris

Re: File modification

[Charles Pritchard]

On 1/12/12 12:53 PM, Arun Ranganathan wrote:
On Jan 12, 2012, at 6:58 AM, Kyle Huey > wrote:



On Thu, Jan 12, 2012 at 3:45 PM, Glenn Maynard mailto:gl...@zewt.org>> wrote:

FYI, I don't think this is clear for File from the spec. 
It's even more important if File objects are stored in

History or IndexedDB; that it should be a *shallow* copy,
with enough information stored to invalidate it if the
underlying file changes, doesn't seem to be specified. 
(As far as I know, nobody implements that yet; being able

to eg. retain open files in History states would be
extremely useful.


Gecko nightlies are capable of storing File objects in
IndexedDB,  We are doing "deep" copies (what is retrieved from
the database is always a copy of the file as it was when it
was placed in the database).


Oh I'm glad to see this one! Is it Blob and File that can be put
into IDB? How do I create a new File (with a name field) from a Blob?


Charles: see the thread on making Blobs constructable -- follow 
http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/0439.html


http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/0918.html

Seems like the consensus was to stay away from Blob to File methods. 
FileEntry and [a download] being the heirs apparent.


The File API specification should do a better job describing what 
happens to a File if the underlying resource changes.  We use the word 
immutable, but I think we have to make this substantially clearer.


My take on a File object that's been modified is that the file no longer 
exists.
"User agents MUST process reads on files that no longer exist at the 
time of read as errors"
"A file may change on disk since the original file selection, thus 
resulting in an invalid read."


FileList is live; and UAs can go several ways with it. They can return 
new File objects, with updated information (yes, please); or they can 
otherwise cut out modified files or later, throw the security error as 
specified:  "Post-selection file modifications occur when a file changes 
on disk after it has been selected. In such cases, user agents MAY throw 
a SecurityError for synchronous read methods, or return a SecurityError 
DOMError for asynchronous reads.".


It's a consideration, anyway. I don't think people expect that, if they 
select a file for uploading, then modify the file before hitting submit, 
that they'll no longer upload a file. It would, I suppose, "disappear" 
from the Chosen file option.


There is a significant difference between selecting files and mounting a 
directory for persistent access. In one of them, the files are listed 
and new files are not added. So I may select a single file, and it'll 
show up in input type=file, or I'll see a count of the files I selected. 
With mounting a directory, I'm given continued access to poll for new 
files. I think that's enough of a distinction to keep the current 
behavior of allowing persistent access to selected files via FileList.


If it's not enough of a distinction, I'd like more semantics added to 
requestFileSystem to re-establish the persistent selection of files.


-Charles

Re: File modification

[Glenn Maynard]

I don't follow.  Either the user always has to poll the Entry to trigger
the event, or you never have to.  The former defeats the purpose of having
an event (optimized by OS change notifications, low-overhead and
instantaneous); the latter may not be possible (NFS).  You can't have a web
API where you only sometimes have to do something.

(I think CIFS does support change notifications, based on UI observations.
I wonder if this will show up in NFS.  I know that file changes show up
immediately in Windows file explorer windows over CIFS, but not NFS.)
On Jan 12, 2012 10:51 AM, "Charles Pritchard"  wrote:

> You're at the mercy of many types of latency with web apps.
>
> For the high-importance notepad case, you're talking about one file. I can
> poll every second from my web app and back off when the screen is idle,
> with current code in Chrome. Hooking into OS level file notification would
> give better results, and help me back off the polling. And if it's on NFS,
> and there's no update signal, looping through FileList would still get me
> my event.
>
> NFS and thousands of files are an extreme case. But they can be managed
> and an update event would improve that management.
>
> -Charles
>
>
>
> On Jan 12, 2012, at 10:20 AM, Glenn Maynard  wrote:
>
> That's not good enough for many use cases.  For example, a notepad app
> that saves to disk wants to update the display if another program modifies
> the file.  You don't want that to be delayed until you scan the directory;
> you want the event pushed at you immediately  when it happens.  This is how
> I imagine most use cases looking.
> On Jan 12, 2012 10:16 AM, "Charles Pritchard"  wrote:
>
>> On 1/12/2012 6:34 AM, Glenn Maynard wrote:
>>
>>>
>>> Side-effects of event registration are outside of the DOM event model.
>>>  UAs can do whatever transparent optimizations they want, of course, but
>>>  APIs shouldn't *depend* on that for efficient implementations.
>>>
>>> Occasional polling definitely has significant overhead (directories may
>>> have tens of thousands of files, be on network shares, etc), and should be
>>> widely avoided.
>>>
>>> I also wonder whether change notifications work over eg. NFS.  It would
>>> be bad if this feature only sometimes worked (especially if it breaks on
>>> major but less used configurations like NFS), since once deployed, apps
>>> will be designed around it.
>>>
>>>
>> On NFS and directories where directory notification is not available:
>> send an onchanged event to FileList when an underlying File object changes
>> upon access of its entry in FileList.
>>
>> That is... as I'm looping through FileList grabbing files, it may
>> invalidate a File object. FileList has now "changed".
>> I won't know until the next event loop. That's good enough.
>>
>>
>>
>>
>>

Re: to add Speech API to Charter; deadline January 19

[Satish S]

(Sorry if reply got posted twice, my mail app messed up formatting the
first time)

Milan,

It looks like we agree on several things:

*  That we'd like to see the JavaScript Speech API included in the
   WebApps' charter.
*  That we believe the wire protocol is best suited for another
   organization, such as IETF.
*  That we believe the markup bindings may be excluded.

Our only difference seems to be whether to start with the extensive
Javascript API proposed in [1] or the simplified subset of it proposed in
[2], which supports the majority of use cases in the XG’s Final Report.

Art Barstow asked for “a relatively specific proposal” and provided some
precedence examples regarding the level of detail. [3]

Olli Pettay wrote in [4] “Since from practical point of view the
API+protocol XG defined is a huge thing to implement at once, it makes
sense to implement it in pieces.”

Starting with a baseline that supports the majority of use cases will
accelerate implementation, interoperability testing, standardization and
ultimately developer adoption.

Cheers
Satish

[1] http://www.w3.org/2005/Incubator/htmlspeech/XGR-htmlspeech/
[2]
http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/att-1696/speechapi.html
[3] http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/1474.html
[4] http://lists.w3.org/Archives/Public/public-webapps/2012JanMar/0068.html


On Thu, Jan 12, 2012 at 5:46 PM, Young, Milan wrote:

> I've made the point a few times now, and would appreciate a response.
> Why are we preferring to seed WebApps speech with [2] when we already
> have [3] that represents industry consensus as of a month ago (Google
> not withstanding)?  Proceeding with [2] would almost surely delay the
> resulting specification as functionality would patched and haggled over
> to meet consensus.
>
> My counter proposal is to open the HTML/speech marriage in WebApps
> essentially where we left off at [3].  The only variants being: 1)
> Dropping the markup bindings in sections 7.1.2/7.1.3 because its primary
> supporter has since expressed non-interest, and 2) Spin the protocol
> specification in 7.2 out to the IETF.  If I need to formalize all of
> this in a document, please let me know.
>
> Thank you
>
> [3] http://www.w3.org/2005/Incubator/htmlspeech/XGR-htmlspeech/
>
>
>
> -Original Message-
> From: Arthur Barstow [mailto:art.bars...@nokia.com]
> Sent: Thursday, January 12, 2012 4:31 AM
> To: public-webapps
> Cc: public-xg-htmlspe...@w3.org
> Subject: CfC: to add Speech API to Charter; deadline January 19
>
> Glen Shires and some others at Google proposed [1] that WebApps add
> Speech API to WebApps' charter and they put forward the Speech
> Javascript API Specification [2] as as a starting point. Members of
> Mozilla and Nuance have voiced various levels of support for this
> proposal. As such, this is a Call for Consensus to add Speech API to
> WebApps' charter.
>
> Positive response to this CfC is preferred and encouraged and silence
> will be considered as agreeing with the proposal. The deadline for
> comments is January 19 and all comments should be sent to public-webapps
> at w3.org.
>
> -AB
>
> [1]
> http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/1696.html
> [2]
> http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/att-1696/s
> peechapi.html
>
>
>

Re: to add Speech API to Charter; deadline January 19

[Satish S]

Milan,
It looks like we fundamentally agree on several things:
*  That we'd like to see the JavaScript Speech API included in the
WebApps' charter.*  That we believe the wire protocol is best suited
for another organization, such as IETF.*  That we believe the markup
bindings may be excluded.
Our only difference seems to be whether to start with the extensive
Javascript API proposed in [1] or the simplified subset of it proposed
in [2] which supports majority of the use cases in the XG’s Final
Report.

Art Barstow asked for “a relatively specific proposal” and provided
some precedence examples regarding the level of detail. [3]
Olli Pettay wrote in [4] “Since from practical point of view the
API+protocol XG defined is a huge thing to implement at once, it makes
sense to implement it in pieces.”
Starting with a baseline that supports the majority of use cases will
accelerate implementation, interoperability testing, standardization
and ultimately developer adoption.
Cheers
Satish

[1] http://www.w3.org/2005/Incubator/htmlspeech/XGR-htmlspeech/[2]
http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/att-1696/speechapi.html[3]
http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/1474.html[4]
http://lists.w3.org/Archives/Public/public-webapps/2012JanMar/0068.html
On Thu, Jan 12, 2012 at 5:46 PM, Young, Milan  wrote:
>
> I've made the point a few times now, and would appreciate a response.
> Why are we preferring to seed WebApps speech with [2] when we already
> have [3] that represents industry consensus as of a month ago (Google
> not withstanding)?  Proceeding with [2] would almost surely delay the
> resulting specification as functionality would patched and haggled over
> to meet consensus.
>
> My counter proposal is to open the HTML/speech marriage in WebApps
> essentially where we left off at [3].  The only variants being: 1)
> Dropping the markup bindings in sections 7.1.2/7.1.3 because its primary
> supporter has since expressed non-interest, and 2) Spin the protocol
> specification in 7.2 out to the IETF.  If I need to formalize all of
> this in a document, please let me know.
>
> Thank you
>
> [3] http://www.w3.org/2005/Incubator/htmlspeech/XGR-htmlspeech/
>
>
>
> -Original Message-
> From: Arthur Barstow [mailto:art.bars...@nokia.com]
> Sent: Thursday, January 12, 2012 4:31 AM
> To: public-webapps
> Cc: public-xg-htmlspe...@w3.org
> Subject: CfC: to add Speech API to Charter; deadline January 19
>
> Glen Shires and some others at Google proposed [1] that WebApps add
> Speech API to WebApps' charter and they put forward the Speech
> Javascript API Specification [2] as as a starting point. Members of
> Mozilla and Nuance have voiced various levels of support for this
> proposal. As such, this is a Call for Consensus to add Speech API to
> WebApps' charter.
>
> Positive response to this CfC is preferred and encouraged and silence
> will be considered as agreeing with the proposal. The deadline for
> comments is January 19 and all comments should be sent to public-webapps
> at w3.org.
>
> -AB
>
> [1]
> http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/1696.html
> [2]
> http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/att-1696/s
> peechapi.html
>
>

Re: String to ArrayBuffer

[Charles Pritchard]

On 1/12/2012 10:03 AM, Tab Atkins Jr. wrote:

On Thu, Jan 12, 2012 at 9:54 AM, Charles Pritchard  wrote:

I don't see it being a particularly bad thing if vendors expose more
translation encodings. I've only come across one project that would use
them. Binary and utf8 handle everything else I've come across, and I can use
them to build character maps for the rest, if I ever hit another strange
project that needs them.

As always, the problem is that if one browser supports an encoding
that no one else does, then content will be written that depends on
that encoding, and thus is locked into that browser.  Other browsers
will then feel competitive pressure to support the encoding, so that
the content works on them as well.  Repeat this for the union of
encodings that every browser supports.

It's not necessarily true that this will happen for every single
encoding.  History shows us that it will probably happen with at least
*several* encodings, if nothing is done to prevent it.  But there's no
reason to risk it, when we can legislate against it and even test for
common things that browsers *might* support.



Count me as agnostic. I'm fine with simple. I'd like to see MS and Apple 
chime in on this issue.


Here's the "worst case" as I understand it being presented:
http://www.php.net/manual/en/mbstring.supported-encodings.php
http://php.net/manual/en/function.mb-convert-encoding.php


-Charles

Re: Pressing Enter in contenteditable: or or ?

[Aryeh Gregor]

On Thu, Jan 12, 2012 at 4:58 AM, Hallvord R. M. Steen
 wrote:
> Probably a stupid question, but one I've always wanted to ask: couldn't we
> default to a different, smaller, possibly 0 margin for P when in editable
> content?

As Markus says: it breaks WYSIWYG.  The idea of contenteditable is you
can write a blog post or something in a contenteditable area, then
post the resulting HTML to your web page in non-editable form and have
it look the same.  Having contenteditable behave differently means
that you write the post, get it looking the way you want it -- and
then suddenly when you post it, it looks different for no obvious
reason.

On Thu, Jan 12, 2012 at 5:50 AM, Simon Pieters  wrote:
> Currently the editing options available, other than enabling and disabling
> contenteditable, use the execCommand API. I don't see why we should switch
> to attributes for new editing options. To make editing options per editing
> host, I prefer this proposal:
>
> . . .

As do I -- I suggested new attributes before I saw Ojan's suggestion.

> Indeed, e.g. shift+enter doesn't break out of lists, so it's not equivalent.
> Making it equivalent would be adding some complexity.

Good point.  I didn't think of that.

> So what's the use case? :-) If none are presented, I object to adding it
> based on the Avoid Needless Complexity and Solve Real Problems design
> principles.

Agreed.  That some authors are using it is not a strong enough reason
to support it.

Re: Selection of a document that doesn't have a window

[Ojan Vafai]

Can you do anything useful with a selection on a document that doesn't have
a window? If so, the IE9 behavior makes sense. If not, I prefer the WebKit
behavior.

For phrasing it, could you define it in terms of document.defaultView? In
other words that document.getSelection is just "return document.defaultView
? document.defaultView.getSelection() : null".

On Thu, Jan 12, 2012 at 7:58 AM, Aryeh Gregor  wrote:

> What does document.implementation.createHTMLDocument("").getSelection()
> return?
>
> * IE9 returns a Selection object unique to that document.
> * Firefox 12.0a1 and Opera Next 12.00 alpha return the same thing as
> document.getSelection().
> * Chrome 17 dev returns null.
>
> I prefer IE's behavior just for the sake of simplicity.  If we go with
> Gecko/WebKit/Opera, we have to decide how to identify which documents
> get their own selections and which don't.  The definition should
> probably be something like "documents that are returned by the
> .document property of some window", but I have no idea if that's a
> sane way to phrase it.
>
> So should the spec follow IE?  If not, what definition should we use
> to determine which documents get selections?
>
>

[Bug 14985] Specify how autoincrement + empty keypath works

[bugzilla]

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

Israel Hilerio [MSFT]  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 CC||isra...@microsoft.com
 Resolution|FIXED   |

--- Comment #2 from Israel Hilerio [MSFT]  2012-01-13 
01:01:11 UTC ---
Section 3.1.5 needs to be updated to reflect the fact that a valid key path
can't be an empty string.  Currently it says:

"A valid key path is either the empty string, a JavaScript identifier, or
multiple Javascript identifiers separated by periods"

-- 
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: Selection of a document that doesn't have a window

[Simon Pieters]

On Thu, 12 Jan 2012 16:58:58 +0100, Aryeh Gregor  wrote:

What does document.implementation.createHTMLDocument("").getSelection()  
return?


* IE9 returns a Selection object unique to that document.
* Firefox 12.0a1 and Opera Next 12.00 alpha return the same thing as
document.getSelection().
* Chrome 17 dev returns null.

I prefer IE's behavior just for the sake of simplicity.  If we go with
Gecko/WebKit/Opera, we have to decide how to identify which documents
get their own selections and which don't.  The definition should
probably be something like "documents that are returned by the
.document property of some window", but I have no idea if that's a
sane way to phrase it.


HTML uses this concept in lots of places, e.g.
http://www.whatwg.org/specs/web-apps/current-work/#cookie-free-document-object

"A Document that has no browsing context."


So should the spec follow IE?  If not, what definition should we use
to determine which documents get selections?



--
Simon Pieters
Opera Software