Public mailing list of the Web Application Formats Working Group. ()

Aaron Boodman | 20 May 2013 22:00

The JavaScript context of a custom element

Hello public-webapps,

I have been following along with web components, and am really excited about the potential.

However, I just realized that unlike the DOM and CSS, there is no real isolation for JavaScript in a custom element. In particular, the global scope is shared.

This seems really unfortunate to me, and limits the ability of element authors to create robustly reusable components.

I would like to suggest that custom elements have the ability to ask for a separate global scope for their JavaScript. This would be analogous to what happens today when you have multiple script-connected frames on the same origin.

Has there been any thought along these lines in the past?

Thanks,

- a

headers

bugzilla | 20 May 2013 06:10

[Bug 22094] New: Add 'target' in InputMethodContext

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

            Bug ID: 22094
           Summary: Add 'target' in InputMethodContext
    Classification: Unclassified
           Product: WebAppsWG
           Version: unspecified
          Hardware: All
                OS: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: IME API
          Assignee: mike <at> w3.org
          Reporter: kochi <at> google.com
        QA Contact: public-webapps-bugzilla <at> w3.org
                CC: mike <at> w3.org, public-webapps <at> w3.org

As described in Microsoft's IME API proposal
https://dvcs.w3.org/hg/ime-api/raw-file/tip/proposals/IMEProposal.html

add 'target' property which is a back pointer to the associated input element.

--

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

headers

bugzilla | 20 May 2013 05:50

[Bug 22093] New: Consider adding candidatewindowshow/update/hide events and getCandidateWindowClientRect()

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

            Bug ID: 22093
           Summary: Consider adding candidatewindowshow/update/hide events
                    and getCandidateWindowClientRect()
    Classification: Unclassified
           Product: WebAppsWG
           Version: unspecified
          Hardware: All
                OS: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: IME API
          Assignee: mike <at> w3.org
          Reporter: kochi <at> google.com
        QA Contact: public-webapps-bugzilla <at> w3.org
                CC: mike <at> w3.org, public-webapps <at> w3.org

Add candidatewindow{show,update,hide} events on InputMethodContext
as described in
https://dvcs.w3.org/hg/ime-api/raw-file/tip/proposals/IMEProposal.html
as well as getCandidateWindowClientRect() for the API to be useful.

interface InputMethodContext : EventTarget {
    ...snip...
    ClientRect         getCandidateWindowClientRect ();
                attribute EventHandler  oncandidatewindowshow;
                attribute EventHandler  oncandidatewindowupdate;
                attribute EventHandler  oncandidatewindowhide;
};

The use case is to align/position search suggest UI dropdown when
candidate window UI appears.

--

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

headers

Kyaw Tun | 20 May 2013 05:14

Re: [IndexedDB] Inform script of corruption recovery

It will be good, if we can provide data priority per database and/or per object store.

Web app already assume Indexeddb data is temporary, recovery process are in place at the beginning after database is successfully open. So silently drop all data and set version to 0 is good way to go. I think detail reason are not necessary.

After opening, database should not corrupt. But quota exceed error do happen. It is very difficult and messy to handle that issue.

If these corruption happen, data are lost according to their priority will be good enough for most situation. It is easy for both sides (developer and browser implementation).

Kyaw

headers

Kyaw Tun | 20 May 2013 03:37

[IndexedDB] IDBRequest.onerror for DataCloneError and DataError

Sorry for reposting again for http://lists.w3.org/Archives/Public/public-webapps/2013AprJun/0422.html Perhaps I am not well explain enough.

In put and add method of object store and index, DataCloneError and

DataError are immediately throw before executing IDBRequest. It seems good

that exception are throw immediately, but in practical use case, these

exception are in async workflow (inside transaction callback). Exception

break the async workflow, (of course, it depending on usage design pattern).

DataCloneError and DataError are preventable in most situation. But sometimes tricky. We even want database to handle these errors like database constraint. The logic will be much simpler if DataCloneError and DataError cause to invoke IDBRequest.onerror rather than exception.

headers

Ben Kelly | 17 May 2013 23:37

[IndexedDB] request feedback on IDBKeyRange.inList([]) enhancement

Hello all,

Recently I've been working on a mobile application that makes heavy use of IndexedDB.  In particular, there
are times when this app must query a potentially large, non-consecutive list of keys.  Currently (to my
knowledge) the IndexedDB API requires that this be done via separate get() calls.  Due to some performance
issues I investigated enhancing the IndexedDB API to allow the list of keys to be queried in a single
request.  The resulting changes seem to show significant performance improvement on the mozilla mobile platform.

I would like to get your feedback and input on this API change.

The enhancement essentially adds an inList() function to IDBKeyRange.  Similar to the other factory
methods on IDBKeyRange, this returns an object which can be used to query a matching set of keys.  The
inList() function takes an array of keys to match against.  In practice it would look like the following:

  var keyRange = IDBKeyRange.inList(['key-1', 'key-2', 'key-3']);
  var request = index.openCursor(keyRange);

Duplicate keys in the list are ignored.  The order of the results would be controlled by the normal cursor
ordering mechanisms.

I've written a rough proof-of-concept for the mozilla platform here:

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

I realize there has been some discussion of this topic in the past.  In particular, Ben Turner referred me to:

  https://www.w3.org/Bugs/Public/show_bug.cgi?id=16595
  https://docs.google.com/a/mozilla.com/document/d/1vvC5tFZCZ9T8Cwd2DteUvw5WlU4YJa2NajdkHn6fu-I/edit

From these links it sounds like there has been a lack of interest, but no strong objection.  Since there
appears to be some legitimate benefit from the API enhancement I thought I would send it out to the list for
feedback.  I have to admit I'm new to the standardization process, though.  I apologize for the noise if this
is essentially a non-starter.

Any feedback is greatly appreciated.  Thank you!

Ben Kelly

headers

bugzilla | 17 May 2013 18:42

[Bug 19771] Need way to determine what keys are supported on device.

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

Gary Kacmarcik <garykac <at> google.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |garykac <at> google.com,
                   |                            |public-webapps <at> w3.org
          Component|DOM3 Events                 |UI Events
           Assignee|travil <at> microsoft.com        |garykac <at> google.com

--- Comment #2 from Gary Kacmarcik <garykac <at> google.com> ---
We're trying to do something similar with queryKeyCaps in UI Events.

Since this certainly won't be part of D3E at this point, I'm changing the
component to "UI Events" so we can consider it for that spec.

--

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

headers

Arthur Barstow | 17 May 2013 01:29

RfC: LCWD of Indexed Database; deadline June 7

This is a Request for Comments for the 16 May 2013 Last Call Working 
Draft of Indexed Database:

<http://www.w3.org/TR/2013/WD-IndexedDB-20130516/>

The comment deadline is June 7 and all comments should be sent to the 
public-webapps <at> w3.org list.

-Thanks, AB

headers

Takeshi Yoshino | 16 May 2013 18:58

Overlap between StreamReader and FileReader

StreamReader proposed in the Streams API spec is almost the same as FileReader. By adding the maxSize argument to the readAs methods (new methods or just add it to existing methods as an optional argument) and adding the readAsBlob method, FileReader can cover all what StreamReader provides. Has this already been discussed here?

I heard that some people who had this concern discussed briefly and were worrying about derailing File API standardization.

We're planning to implement it on Chromium/Blink shortly.

headers

bugzilla | 16 May 2013 11:42

[Bug 22059] New: Composition dictionary should be changed

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

            Bug ID: 22059
           Summary: Composition dictionary should be changed
    Classification: Unclassified
           Product: WebAppsWG
           Version: unspecified
          Hardware: All
                OS: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: IME API
          Assignee: mike <at> w3.org
          Reporter: kochi <at> google.com
        QA Contact: public-webapps-bugzilla <at> w3.org
                CC: mike <at> w3.org, public-webapps <at> w3.org

As the spec dropped Javascript IME spec, Composition dictionary
doesn't have to be a separate dictionary but can be a part of
InputMethodContext.

In 20130404 WD:
dictionary Composition {
    readonly attribute Node  text;
    readonly attribute Range caret;
};

In Microsoft's proposal
https://dvcs.w3.org/hg/ime-api/raw-file/default/proposals/IMEProposal.html

interface InputMethodContext : EventTarget {
    ...
    readonly    attribute DOMString     compositionText;
    readonly    attribute unsigned long compositionStartOffset;
    readonly    attribute unsigned long compositionEndOffset;
    ....
};

The rationale for this is "
For composition dictionary in current proposal, we can see exposing IME clauses
as child nodes of text node, and making them real DOM nodes with styles being
useful for a JS-based IME as the IME needs to tell the web application how to
render the composition, but if JS IME is not a goal, is there any other
scenarios that will benefit from this? If not, how about a simple design that
expose the text being composed as DOMString?

For caret range, if it’s for enabling JS-based IME, then exposing the caret
ranges of IME clauses is helpful, but if it’s not for JS IME, is there any
other usage? We understand that web applications want to know about the whole
string of the tentative composition, but we are not sure in which case they
want to know how the whole tentative composition string is divided into several
parts. Another issue is that the range type only tells the start and end
offsets of the composition from its immediate parent. Web application usually
wants to know the offset from the beginning of the text field so that it could
combine the composition alternate with the text before it to create a full text
string. But the beginning of the text field can be up in the parent tree if
it’s a contentEditable element and requires JavaScript code to trace up in the
parent tree to get the right offset.

So instead of a dictionary type for composition, we suggest compositionText,
compositionStartOffset and compositionEndOffset as a simpler design. Please let
us know if you have scenarios that need to be the other way."

--

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

headers

bugzilla | 16 May 2013 11:42

[Bug 22058] New: "error" event should fire before final readystatechange event

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

            Bug ID: 22058
           Summary: "error" event should fire before final
                    readystatechange event
    Classification: Unclassified
           Product: WebAppsWG
           Version: unspecified
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: XHR
          Assignee: annevk <at> annevk.nl
          Reporter: hallvord <at> opera.com
        QA Contact: public-webapps-bugzilla <at> w3.org
                CC: mike <at> w3.org, public-webapps <at> w3.org

#request-error part of spec:

Step 6: Fire an event named readystatechange. 

.
.

Step 9: Fire a progress event named event. // this fires the actual 'error'
event

This seems to be an order of events that isn't really user-friendly. 

Given a typical XHR-using script has logic like this:

if readystatechange fires with readyState === 4
  report "success", handle response data

if error event fires
  report failure

this typical XHR user would end up running the "success" code first, then the
"failure" code. This seems less than ideal.. Is there any reason we can't move
the "fire error" step to before the "fire readystatechange" step?

--

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

Mon	Tue	Wed	Thu	Fri	Sat	Sun

		1	2	3	4	5
6	7	8	9	10	11	12
13	14	15	16	17	18	19
20	21	22	23	24	25	26
27	28	29	30	31

321	May 2013
437	April 2013
448	March 2013
423	February 2013
192	January 2013
116	December 2012
313	November 2012
312	October 2012
262	September 2012
367	August 2012
259	July 2012
392	June 2012
595	May 2012
403	April 2012
395	March 2012
492	February 2012
450	January 2012
463	December 2011
686	November 2011
596	October 2011
620	September 2011
642	August 2011
529	July 2011
644	June 2011
364	May 2011
410	April 2011
420	March 2011
392	February 2011
312	January 2011
288	December 2010
443	November 2010
373	October 2010
469	September 2010
324	August 2010
334	July 2010
368	June 2010
439	May 2010
433	April 2010
269	March 2010
376	February 2010
341	January 2010
459	December 2009
615	November 2009
425	October 2009
603	September 2009
436	August 2009
456	July 2009
734	June 2009
208	May 2009
454	April 2009
401	March 2009
317	February 2009
279	January 2009
193	December 2008
128	November 2008
216	October 2008
211	September 2008
241	August 2008
300	July 2008
130	June 2008
151	May 2008
98	April 2008
69	March 2008
286	February 2008
338	January 2008
72	December 2007
57	November 2007
86	October 2007
53	September 2007
28	August 2007
51	July 2007
34	June 2007
66	May 2007
27	April 2007
36	March 2007
132	February 2007
295	January 2007
148	December 2006
81	November 2006
137	October 2006
114	September 2006
177	August 2006
10	July 2006
32	June 2006
10	May 2006