Re: Proposal: CSS WG / WebApps Joint Meeting for Shadow DOM Styling

[John Daggett]

Late Tuesday afternoon would be a good fit for me.

On Tue, Sep 29, 2015 at 8:49 AM, Ryosuke Niwa  wrote:

> Hi,
>
> Attending the recent meeting for shadow DOM styling [1] convinced me to
> join CSS WG, and further that we need a joint meeting between CSS WG and
> WebApps WG on this topic during TPAC to iron out the details.
>
> Can we have a joint meeting (of one or two hours) on Monday (10/26) or
> Tuesday (10/27) for this?
>
> [1] https://www.w3.org/wiki/Webapps/WebComponentsSeptember2015Meeting
>
> - R. Niwa
>
>
>

Re: [XHR] Error type when setting request headers.

[Ms2ger]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Yves,

On 09/29/2015 03:25 PM, Yves Lafon wrote:
> Hi, In XHR [1], setRequestHeader is defined by this: [[ void
> setRequestHeader(ByteString name, ByteString value); ]] It has a
> note: [[ Throws a SyntaxError exception if name is not a header
> name or if value is not a header value. ]]
> 
> In WebIDL [2], ByteString is defined by the algorithm [[ • Let x be
> ToString(V). • If the value of any element of x is greater than
> 255, then throw a TypeError. • Return an IDL ByteString value whose
> length is the length of x, and where the value of each element is
> the value of the corresponding element of x. ]] So what should be
> thrown when one does
> 
> var client = new XMLHttpRequest(); client.open('GET', '/glop'); 
> client.setRequestHeader('X-Test', '小');
> 
> TypeError per WebIDL or SyntaxError per XHR? I think it should be
> TypeError, and SyntaxError for code <256 that are not allowed, but
> implementations currently use SyntaxError only.
> 
> [1] https://xhr.spec.whatwg.org/ [2]
> https://heycam.github.io/webidl/#es-ByteString
> 

This is perfectly explicit from the WebIDL specification. It defines
that `setRequestHeader` is a JavaScript function that does argument
conversion and validation (using the quoted algorithm in this case),
and only after that succeeded, invokes the algorithm defined in the
relevant specification (in this case XHR).

This implies in particular that a TypeError will be thrown here.
Indeed, the Firefox Nightly I'm running right now implements this
behaviour.

HTH
Ms2ger
-BEGIN PGP SIGNATURE-

iQEcBAEBAgAGBQJWCqLDAAoJEOXgvIL+s8n26GQH/RPt+Nxxnmg0BXfIOySWeunn
2FHMlGiydCT5eek7oLvMhH3o2wyfgExEJrQyc9/emR+08sAlBZRRf5XkS+s+A8gQ
XMcHhv054bJ5zd1EV6t2V6E01PSIgQ0dUp5XtKF8xJR/J6opUodvm25jPGvomg7H
W4KelDI7LleeIAgKP7TLzLSsSmGS4/3QkjmleEB04Tso81IR3nXmpU75fYcsoDDg
ODJaNAtzauE9cMX6lXf9aEV2bnPGlgy9Ke5/Q8xYdadqy0xD44NFSGJNdQGzL/7P
Iy5ImE6uipky/O8vUUMCG7jdMYOJRGv3TiGyEMijAEsJOjpoN9ay3xdo1SHXO0A=
=U0HA
-END PGP SIGNATURE-

Re: Proposal: CSS WG / WebApps Joint Meeting for Shadow DOM Styling

[Alan Stearns]

On 9/28/15, 4:49 PM, "rn...@apple.com on behalf of Ryosuke Niwa" 
 wrote:

>Hi,
>
>Attending the recent meeting for shadow DOM styling [1] convinced me to join 
>CSS WG, and further that we need a joint meeting between CSS WG and WebApps WG 
>on this topic during TPAC to iron out the details.
>
>Can we have a joint meeting (of one or two hours) on Monday (10/26) or Tuesday 
>(10/27) for this?
>
>[1] https://www.w3.org/wiki/Webapps/WebComponentsSeptember2015Meeting
>
>- R. Niwa

Chaals, Art,

Do you have a time preference for this? We’ve got one vote for Tuesday 
afternoon, but I think Monday afternoon could work as well.

I see that the WebApps WG has a larger person-estimate on the schedule page - 
if that translates to a larger room, the CSSWG people could troop over to you. 
Or we could host interested people in the CSSWG room. What do you think?

Ryosuke,

We now have “Shadow DOM Styling” on the CSSWG agenda for TPAC [1]. It would 
help if you could add more detail on the particular issues you’d like ironed 
out.

Thanks,

Alan

[1] https://wiki.csswg.org/planning/tpac-2015

Re: Proposal: CSS WG / WebApps Joint Meeting for Shadow DOM Styling

[Arthur Barstow]

On 9/29/15 11:19 AM, Alan Stearns wrote:

On 9/28/15, 4:49 PM, "rn...@apple.com on behalf of Ryosuke Niwa" 
 wrote:


Hi,

Attending the recent meeting for shadow DOM styling [1] convinced me to join 
CSS WG, and further that we need a joint meeting between CSS WG and WebApps WG 
on this topic during TPAC to iron out the details.

Can we have a joint meeting (of one or two hours) on Monday (10/26) or Tuesday 
(10/27) for this?

[1] https://www.w3.org/wiki/Webapps/WebComponentsSeptember2015Meeting

- R. Niwa

Chaals, Art,

Do you have a time preference for this? We’ve got one vote for Tuesday 
afternoon, but I think Monday afternoon could work as well.


Based on earlier feedback, Chaals added a two hour slot on Tuesday 
afternoon 
.



I see that the WebApps WG has a larger person-estimate on the schedule page - 
if that translates to a larger room, the CSSWG people could troop over to you. 
Or we could host interested people in the CSSWG room. What do you think?


Meeting in WebApps room should be fine.

-AB



Ryosuke,

We now have “Shadow DOM Styling” on the CSSWG agenda for TPAC [1]. It would 
help if you could add more detail on the particular issues you’d like ironed 
out.

Thanks,

Alan

[1] https://wiki.csswg.org/planning/tpac-2015

Re: Proposal: CSS WG / WebApps Joint Meeting for Shadow DOM Styling

[Chaals McCathie Nevile]

I added a note (as a question) to the meeting wiki page:  
https://www.w3.org/wiki/Webapps/October2015Meeting


cheers

On Tue, 29 Sep 2015 11:12:16 +0500, John Daggett   
wrote:



Late Tuesday afternoon would be a good fit for me.

On Tue, Sep 29, 2015 at 8:49 AM, Ryosuke Niwa  wrote:

Hi,



Attending the recent meeting for shadow DOM styling [1] convinced me to  
join CSS WG, and further >>that we need a joint meeting between CSS WG  
and WebApps WG on this topic during TPAC to iron out >>the details.




Can we have a joint meeting (of one or two hours) on Monday (10/26) or  
Tuesday (10/27) for this?




[1] https://www.w3.org/wiki/Webapps/WebComponentsSeptember2015Meeting



- R. Niwa












--
Charles McCathie Nevile - web standards - CTO Office, Yandex
 cha...@yandex-team.ru - - - Find more at http://yandex.com

Re: Indexed DB + Promises

[Jonas Sicking]

On Tue, Sep 29, 2015 at 10:51 AM, Domenic Denicola  wrote:
> This seems ... reasonable, and quite possibly the best we can do. It has a 
> several notable rough edges:
>
> - The need to remember to use .promise, instead of just having functions 
> whose return values you can await directly

One way that we could solve this would be to make IDBRequest a
thenable. I.e. put a .then() function directly on IDBRequest.

> - The two-stage error paths (exceptions + rejections), necessitating 
> async/await to make it palatable

I'd be curious to know if, in the case of IDB, this is a problem in
practice. I do agree that it's good for promise based APIs to only
have one error path, but IDB is pretty conservative about when it
throws.

Do people actually wrap their IDB calls in try/catch today?

Certainly throwing at all isn't perfect, but is it a big enough
problem that it warrants using a library?

> - The waitUntil/IIAFE pattern in the incrementSlowly example, instead of a 
> more natural `const t = await openTransaction(); try { await 
> useTransaction(t); } finally { t.close(); }` structure

I'm actually quite concerned about using a t.close() pattern. It seems
to make it very easy to end up with minor bugs which totally hang an
application because a transaction is left open.

But maybe developers prefer it strongly enough that they'll use a
library which provides it.

> I guess part of the question is, does this add enough value, or will authors 
> still prefer wrapper libraries, which can afford to throw away backward 
> compatibility in order to avoid these ergonomic problems?

Yeah, I think this is a very good question. I personally have no idea.

/ Jonas

RE: Indexed DB + Promises

[Domenic Denicola]

This seems ... reasonable, and quite possibly the best we can do. It has a 
several notable rough edges:

- The need to remember to use .promise, instead of just having functions whose 
return values you can await directly
- The two-stage error paths (exceptions + rejections), necessitating 
async/await to make it palatable
- The waitUntil/IIAFE pattern in the incrementSlowly example, instead of a more 
natural `const t = await openTransaction(); try { await useTransaction(t); } 
finally { t.close(); }` structure

I guess part of the question is, does this add enough value, or will authors 
still prefer wrapper libraries, which can afford to throw away backward 
compatibility in order to avoid these ergonomic problems? From that 
perspective, the addition of waitUntil or a similar primitive to allow better 
control over transaction lifecycle is crucial, since it will enable better 
wrapper libraries. But the .promise and .complete properties end up feeling 
like halfway measures, compared to the usability gains a wrapper can achieve. 
Maybe they are still worthwhile though, despite their flaws. You probably have 
a better sense of what authors have been asking for here than I do.

Minor usability suggestions:

- Maybe tx.waitUntil could return tx.complete? That would shorten the 
incrementSlowly example a bit.
- .promise is a pretty generic name. For operations, .ready or .complete or 
.done might be nicer. (Although nothing sticks out as perfect.) For cursors, 
I'd suggest something like .next or .nextReady or similar.

From: Joshua Bell [mailto:jsb...@google.com] 
Sent: Monday, September 28, 2015 13:44
To: public-webapps@w3.org
Subject: Indexed DB + Promises

One of the top requests[1] we've received for future iterations of Indexed DB 
is integration with ES Promises. While this initially seems straightforward 
("aren't requests just promises?") the devil is in the details - events vs. 
microtasks, exceptions vs. rejections, automatic commits, etc.

After some noodling and some very helpful initial feedback, I've got what I 
think is a minimal proposal for incrementally evolving (i.e. not replacing) the 
Indexed DB API with some promise-friendly affordances, written up here:

https://github.com/inexorabletash/indexeddb-promises

I'd appreciate feedback from the WebApps community either here or in that 
repo's issue tracker.

[1] https://www.w3.org/2008/webapps/wiki/IndexedDatabaseFeatures