Re: CfC: publish LCWD of Screen Orientation API; deadline September 18

[Jonas Sicking]

On Thu, Sep 11, 2014 at 3:52 PM, Jonas Sicking  wrote:
> Also, I can't find any normative definition of if orientation.angle
> should increase or decrease if the user rotates a device 90 degrees
> clockwise?

My bad, I see it now. Given how easy this is to get wrong, it might be
worth adding this information more explicitly at the definition of the
'angle' property, or the 'current orientation angle' concept, rather
than just buried inside an algorithm.

/ Jonas

Re: CfC: publish LCWD of Screen Orientation API; deadline September 18

[Jonas Sicking]

On Thu, Sep 11, 2014 at 2:19 PM, Arthur Barstow  wrote:
> Mounir and Marcos would like to publish a LCWD of The Screen Orientation API
> and this is a Call for Consensus to do using the latest ED (not yet in the
> LCWD template) as the basis:
>
>   

Sorry, my first comment is a naming bikeshed issue. Feel free to
ignore as it's coming in late, but I hadn't thought of it until just
now.

It's somewhat inconsistent that we use the term "natural" to indicate
"the most natural direction based on hardware", but we use the term
"primary" when indicating "the most natural portrait/landscape
direction based on hardware".

Why do we use "primary" for one and "natural" for the other?

Second, I'm still very worried that people will interpret
screen.orientation.angle=0 as portrait. I don't expect to be able to
convince people here to remove the property. However I think it would
be good to at least make it clear in the spec that the .angle property
can not be used to detect portrait vs. landscape.

A informative note in the description of the angle property saying
something like:

"The value of this property is relative to the "natural" angle of the
hardware. So for some devices angle will be 0 when the device is in
landscape mode, and on other devices when the device is in portrait
mode. Thus this property can not be used to detect landscape vs.
portrait. The primary use case for this property is to enable doing
conversions between coordinates relative to the screen and coordinates
relative to the device (such as the ones returned from the
DeviceOrientationEvent interface).

In order to check if the device is in portrait or landscape mode,
instead use the orientation.type property."

Also, I can't find any normative definition of if orientation.angle
should increase or decrease if the user rotates a device 90 degrees
clockwise?

/ Jonas

CfC: publish LCWD of Screen Orientation API; deadline September 18

[Arthur Barstow]

Mounir and Marcos would like to publish a LCWD of The Screen Orientation 
API and this is a Call for Consensus to do using the latest ED (not yet 
in the LCWD template) as the basis:


  

The spec has three open Issues, all labeled Future + Enhancement and the 
Editors propose these Issues not be addressed for this first version of 
the spec:


  

This CfC satisfies the group's requirement to "record the group's 
decision to request advancement" for this LCWD. Note the Process 
Document used by this group states the following regarding the 
significance/meaning of a LCWD:


[[
http://www.w3.org/2005/10/Process-20051014/tr.html#last-call

Purpose: A Working Group's Last Call announcement is a signal that:

* the Working Group believes that it has satisfied its relevant 
technical requirements (e.g., of the charter or requirements document) 
in the Working Draft;


* the Working Group believes that it has satisfied significant 
dependencies with other groups;


* other groups SHOULD review the document to confirm that these 
dependencies have been satisfied. In general, a Last Call announcement 
is also a signal that the Working Group is planning to advance the 
technical report to later maturity levels.

]]

If you have any comments or concerns about this CfC, please send them to 
public-webapps @ w3.org by September 18 at the latest. Positive response 
is preferred and encouraged and silence will be considered as agreement 
with the proposal.


The proposed review period is 4 weeks.

Assuming this CfC passes, if there are any specific groups (e.g. 
script-coord, TAG, WAI, Privacy IG, Security IG, Mobile IG, etc.) or 
external SDOs we should explicitly ask to review the LCWD, please let us 
know.


-Thanks, AB

[Bug 25310] Move the HTML specification monkey patching to the HTML specification

[bugzilla]

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

Mounir Lamouri  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |MOVED

--- Comment #2 from Mounir Lamouri  ---
This bug moved here:
https://github.com/w3c/screen-orientation/issues/69

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

Re: publishing new WD of URL spec

[Glenn Adams]

On Thu, Sep 11, 2014 at 2:20 PM, Robin Berjon  wrote:

> On 11/09/2014 00:14 , Glenn Adams wrote:
>
>> WHATWG specs are not legitimate for reference by W3C specs. Their IPR
>> status is indeterminate and they do not follow a consensus process.
>>
>
> This is blatant trolling as well as factually wrong in every single
> statement that it makes.
>

I would say something impolite and vulgar at this point. But you've already
pulled down this thread to the gutter Robin by resorting to name calling,
so I won't do that.


>
> I would invite all of you to not feed this thread as it can't possibly
> lead anywhere useful.


You mean, don't feed it like you are doing?

As a W3T member, I would think it your duty to stay out of the fray. Best
listen to your duty.


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

Re: PSA: publishing new WD of URL spec

[Boris Zbarsky]

On 9/11/14, 12:52 PM, Mark Baker wrote:

On Thu, Sep 11, 2014 at 12:13 PM, Anne van Kesteren  wrote:

In which case the WHATWG version wouldn't be "canonical" anymore anyway.


It would be for implementers.


Only those implementers that can afford to staff a team to keep up
with a moving target. That's not all potential implementers.


Mark, the options are to have a team do that or to have a team to 
reverse-engineer the other implementations.  Assuming you want to be 
interoperable with said implementations, of course.


Tracking a well-written spec is _usually_ simpler than 
reverse-engineering other implementations...


-Boris

Re: PSA: publishing new WD of URL spec

[Anne van Kesteren]

On Thu, Sep 11, 2014 at 6:52 PM, Mark Baker  wrote:
> Only those implementers that can afford to staff a team to keep up
> with a moving target. That's not all potential implementers.

What do you mean moving target? In general we only change
specifications if there's something wrong or if there is a new feature
the community would like to add. "Living Standard" does not mean core
algorithms are constantly changing. It just means they are maintained,
as all software has to be.


-- 
http://annevankesteren.nl/

Re: PSA: publishing new WD of URL spec

[Mark Baker]

On Thu, Sep 11, 2014 at 12:13 PM, Anne van Kesteren  wrote:
>> In which case the WHATWG version wouldn't be "canonical" anymore anyway.
>
> It would be for implementers.

Only those implementers that can afford to staff a team to keep up
with a moving target. That's not all potential implementers.

Re: PSA: publishing new WD of URL spec

[Marcos Caceres]

On September 11, 2014 at 11:56:36 AM, Robin Berjon (ro...@w3.org) wrote:
> Hi Marcos,
>  
> On 11/09/2014 17:19 , Marcos Caceres wrote:
> > Only once I have clear answers to the following (and see actual proof).
> > I know you already addressed some of this in your previous email to
> > Dominic.
>  
> I will address your points below, but I will repeat what I told Domenic:
> I don't think progress can be made by talking about stuff in the
> abstract. I believe in iterated progress. To put it differently, I think
> this should be a living commitment to a better relationship and not some
> finalised thing before any action is taken.
>  
> Based on that I would like to get, and I think it is quite reasonable,
> agreement that we can go ahead and publish something better than what
> there was before (surely better than what *is* there) and iterate on
> that (as fast as possible) to get it all good.
>  
> Makes sense?

Yes. Let's iterate - and like you said, no talk. Put it on on GH and let's have 
a look . 

> > 1. How will the spec be kept up to date? i.e., what technical means will
> > be put in place by the w3c to assure that the latest is always on TR.
>  
> As announced on spec-prod and discussed with CSS recently, Philippe has
> been working on an automated publisher. My understanding is that he
> hopes to have a prototype by TPAC, and to ship in early 2015 (likely
> with some guinea pigs having earlier access).

This is strict prerequisite to me lifting the objection. 

Note however, that Anne may still object irrespective of all this. Note also 
that Hixie pretty much said the same thing.  

> Please provide input to that project (in its own thread).
>  
> > 2. How will the W3C determine when a spec is ready for LC/CR?
>  
> Is there any reason to use anything other than tests + implementations?

See Boris' emails about WebPerf. 

I'm also worried about arbitrary random cut off dates, ala "Plan 2014". Such 
things deeply undermine and circumvent the whole point of the W3C process. 

> > 3. How will the W3C cope with changes occurring to the living document
> > after CR? (See Boris' emails)
>  
> I have been advocating a software model for specs for so long that
> you're probably tired of hearing it; but I think we can apply the
> release/development branching here.

I hope so, but not if we need to go through years long process of FPWD, WD, 
LC/CR, bla bla bla of a V2. while a stale V1 "REC" version sits on TR.   

> > 4. Will the W3C prevent search engines from finding the copy/pasted
> > document? Particularly any static snapshots.
>  
> Why would you restrict that to imported snapshots?
>  
> We're looking at blanket-preventing that for dated TR; anyone can add
> robots noindex to TR drafts. I'm certainly happy to do that for
> URL, DOM, and likely a bunch of others when they next get published.

This would be greatly helpful. 

> > 5. What indicators (e.g., the big red box) will be put into the spec to
> > indicate that the WHATWG version is the canonical version?
>  
> Do you want something better than the big red box?

I don't know yet - I need to see the big red box that would accompany the spec. 
  

> > 6. Out of respect for both the Editor and the WHATWG as a standards
> > consortium, how will the W3C attribute authorship of the documents and
> > well as show that the document originates from the WHATWG?
>  
> So what's been done for DOM and URL has been to just list those editors.
> I'd be happy to remove the snapshotting editors but I think that's not
> possible *yet* if the original authors aren't on the WG.
>  
> Apart from that, it should be included in the SotD and in the big red box.
>  
> So?

For picture, the RICG requested that the RICG's logo be included. See right 
side of:

http://www.w3.org/TR/2013/WD-html-picture-element-20130226/

 It would be nice if the WHATWG logo was also included? 

Re: PSA: publishing new WD of URL spec

[Anne van Kesteren]

On Thu, Sep 11, 2014 at 5:58 PM, Julian Reschke
 wrote:
> It's my understanding that the intent is to actually make technical changes,
> as indicated in:
>
>> This specification documents current RFC 3986 and RFC 3987 handling in
>> contemporary Web browser implementations. As a consequence, this
>> specification is not compatible with those RFCs. It is published for the
>> purpose of providing a stable reference for the HTML5 specification and
>> reflecting current Web browser HTML5 implementations. The W3C Technical
>> Architecture Group expects to continue the work on the URL specification and
>> produce a future version that will attempt to re-align the URL specification
>> with an updated version of RFC 3986 while preserving interoperability.
>
> In which case the WHATWG version wouldn't be "canonical" anymore anyway.

It would be for implementers. Seems ill-advised to implement something
that contains contradictory goals and is bound to be incompatible with
deployed content.


-- 
http://annevankesteren.nl/

Re: PSA: publishing new WD of URL spec

[Julian Reschke]

On 2014-09-11 17:19, Marcos Caceres wrote:

...
5. What indicators (e.g., the big red box) will be put into the spec to
indicate that the WHATWG version is the canonical version?
...


It's my understanding that the intent is to actually make technical 
changes, as indicated in:



This specification documents current RFC 3986 and RFC 3987 handling in 
contemporary Web browser implementations. As a consequence, this specification 
is not compatible with those RFCs. It is published for the purpose of providing 
a stable reference for the HTML5 specification and reflecting current Web 
browser HTML5 implementations. The W3C Technical Architecture Group expects to 
continue the work on the URL specification and produce a future version that 
will attempt to re-align the URL specification with an updated version of RFC 
3986 while preserving interoperability.


In which case the WHATWG version wouldn't be "canonical" anymore anyway.

Best regards, Julian

Re: PSA: publishing new WD of URL spec

[Robin Berjon]

Hi Marcos,

On 11/09/2014 17:19 , Marcos Caceres wrote:

Only once I have clear answers to the following (and see actual proof).
I know you already addressed some of this in your previous email to
Dominic.


I will address your points below, but I will repeat what I told Domenic: 
I don't think progress can be made by talking about stuff in the 
abstract. I believe in iterated progress. To put it differently, I think 
this should be a living commitment to a better relationship and not some 
finalised thing before any action is taken.


Based on that I would like to get, and I think it is quite reasonable, 
agreement that we can go ahead and publish something better than what 
there was before (surely better than what *is* there) and iterate on 
that (as fast as possible) to get it all good.


Makes sense?


1. How will the spec be kept up to date? i.e., what technical means will
be put in place by the w3c to assure that the latest is always on TR.


As announced on spec-prod and discussed with CSS recently, Philippe has 
been working on an automated publisher. My understanding is that he 
hopes to have a prototype by TPAC, and to ship in early 2015 (likely 
with some guinea pigs having earlier access).


Please provide input to that project (in its own thread).


2. How will the W3C determine when a spec is ready for LC/CR?


Is there any reason to use anything other than tests + implementations?


3. How will the W3C cope with changes occurring to the living document
after CR? (See Boris' emails)


I have been advocating a software model for specs for so long that 
you're probably tired of hearing it; but I think we can apply the 
release/development branching here.



4. Will the W3C prevent search engines from finding the copy/pasted
document? Particularly any static snapshots.


Why would you restrict that to imported snapshots?

We're looking at blanket-preventing that for dated TR; anyone can add 
 robots noindex to TR drafts. I'm certainly happy to do that for 
URL, DOM, and likely a bunch of others when they next get published.



5. What indicators (e.g., the big red box) will be put into the spec to
indicate that the WHATWG version is the canonical version?


Do you want something better than the big red box?


6. Out of respect for both the Editor and the WHATWG as a standards
consortium, how will the W3C attribute authorship of the documents and
well as show that the document originates from the WHATWG?


So what's been done for DOM and URL has been to just list those editors. 
I'd be happy to remove the snapshotting editors but I think that's not 
possible *yet* if the original authors aren't on the WG.


Apart from that, it should be included in the SotD and in the big red box.

So?

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

Re: User Intentions Explainer (was: List of Intentions)

[Ryosuke Niwa]

On Sep 9, 2014, at 6:31 AM, Johannes Wilm  wrote:

> Absolutely. if this division means we can get into a saner place faster (and 
> with a higher likelihood that it will actually happen) then I am all for it.
> 
> Of course the long-term future of the web should be taken into consideration 
> as well, and as I understand it, this could be part of the second part then.
> 
> On Tue, Sep 9, 2014 at 1:28 PM, Piotr Koszuliński 
>  wrote:
> I'm not sure if I remember correctly, but I believe that after long 
> discussions we left the question "what should contenteditable=minimal be?" 
> unanswered. First the intention events lists should be created, so we can see 
> what needs to be handled. And this is what Ben Peters is working on.
> 
> Still we may also take in consideration that there are limited resources 
> available for working on the specs. Therefore the whole work could be 
> separated into two *independent* topics:
>  1. Intention events + execCommand.
>  2. contenteditable=“minimal”
> 
> That's what I was proposing as well - to have the base (which consists mainly 
> of fixed selection API and intention events) ready as soon as possible, so 
> hopefully browser makers can start implementing it and then we, editor 
> makers, can start using it. This part will already improve the current 
> situation a lot, but it's itself pretty hard as we can see. Then, if anyone 
> will be still interested, a specification for default browser's actions can 
> be created. It's a huge task and there are a lot of controversial topics like 
> the famous delete/backspace behaviour when merging blocks and that's why I 
> would not recommend starting these discussions right now.

Could you clarify what use cases could be addressed by implementing 1?

Since I consider the lack of concrete use cases to be one of the reasons the 
last few iterations/attempts to implement something like these have failed, I 
would really like to have a list of concrete use cases that are to be addressed 
by each specification listed above.

- R. Niwa

PSA: publishing new WD of URL spec

[Marcos Caceres]

On Thursday, September 11, 2014, Robin Berjon > wrote:

> On 10/09/2014 18:48 , Marcos Caceres wrote:
>
>> This is a formal objection to publication of this specification.
>> The rationale for the objection was already sent to the wwwprocess list.
>>
>
> Would you lift yours if Domenic lifted his?


Only once I have clear answers to the following (and see actual proof). I
know you already addressed some of this in your previous email to Dominic.

1. How will the spec be kept up to date? i.e., what technical means will be
put in place by the w3c to assure that the latest is always on TR.

2. How will the W3C determine when a spec is ready for LC/CR?

3. How will the W3C cope with changes occurring to the living document
after CR? (See Boris' emails)

4. Will the W3C prevent search engines from finding the copy/pasted
document? Particularly any static snapshots.

5. What indicators (e.g., the big red box) will be put into the spec to
indicate that the WHATWG version is the canonical version?

6. Out of respect for both the Editor and the WHATWG as a standards
consortium, how will the W3C attribute authorship of the documents and well
as show that the document originates from the WHATWG?

(Ps: Your claim about 12 step programs have been debunked by science. See
[1] :))

[1]
http://www.npr.org/2014/03/23/291405829/with-sobering-science-doctor-debunks-12-step-recovery

Re: publishing new WD of URL spec

[Robin Berjon]

Hi Domenic,

I agree with everything that you have said.

I would like to follow your lead in offering a way forward towards a 
resolution here.


Before I dive into the details, however, I would like to offer a mode of 
work. We can talk and talk and talk about the details until we're all 
blue in the face, but if it's only talking we'll likely run out of 
energy and hit walls because, let's face it, talking about this stuff 
isn't all that interesting.


Instead, I would like for us to work on reaching that amicable situation 
by doing things. That means that instead of freezing everything we ship 
a WD that may not be perfect but improves things, and we do that again, 
and again (and to EDs too where needed) until we're all happy.


Does that sound like a plan?

On 10/09/2014 23:58 , Domenic Denicola wrote:

My arguments against publishing this specification include that
copying the spec from the WHATWG is an unnecessarily combative way of
working with another standards body, especially with regard to the
URL Standard wherein we/they have been trying hard to address the
issues of IP coverage and stable references on the W3C's terms. I
would rather see this talked through and agreement come to regarding
how the W3C can work to reference WHATWG specs in the same way that
they reference Ecma or IETF specs.


I agree entirely. I would be happy to be able to reference WHATWG 
specifications, and I think we can get there.


People cite issues with doing that, but I do not believe that they stand 
up to careful examination.


The patent issue is of concern, but it is not without solutions.

The claim that WHATWG doesn't follow a consensus model is simply not 
true (despite what the WHATWG wiki says about that). There are 
exceptions and violations, but overall I see a lot of consensus going on 
there. That's certainly the case for the likes of URL, DOM, Streams...


The bigger part of the problem is social. There is a lot of invidious 
history. We can get to a point at which we get better IP commitments but 
that requires people to act in a collaborative manner.



On the technical side, I argue that previous efforts to copy WHATWG
specs, even well-intentioned ones like the DOM, have led to
out-of-date snapshots permeating the internet, and causing developer
and implementer confusion. (See links in [1]; see also the contrast
between one implementer's policies at [2] and another's at [3].) We
can't even fall back to "never look at TR because it is always out of
date; use ED instead!" because in the case of e.g. DOM "4", the ED is
five months out of date.


Here is my proposal to fix that for URL (and if we agree, I'll fix it 
for DOM too):


  - Remove the ED by using any branch other than gh-pages. No ones 
needs that anyway.


  - Include  to the TR snapshots.

  - Include a very visible warning in the TR snapshot telling people to 
go to the (real) ED.


I would like to get to a point where we can just reference WHATWG specs 
(it would certainly make my life much easier), but while we figure out a 
way of making TR snapshots roughly functional I'd like to try that now 
(if only so we can get a feel for snapshotting properly).


I *think* that the above proposals, which are implementable right away, 
address your concerns. WDYT?


In addition to the above I would like, as we might have to stick with 
the TR snapshotting for a little while until we figure out a better way, 
to include WHATWG co-branding on the TR version. I can't commit to doing 
that immediately as it's something I need buy-in for, but there's 
precedent (http://www.w3.org/TR/2010/REC-webcgm21-20100301/).



I acknowledge that Dan is going to great lengths to make sure that
this copying is done "right", insofar as it can be. E.g., he is
copying not plagiarizing; he is stating that he wants feedback to
flow through the upstream version instead of diverging; and he says
that he will add more clear signposting to the document to help
direct implementers and developers to the upstream version. However,
I think this plan is merely a band-aid on a larger problem, akin to
feeding the W3C's spec-copying addiction with a nicotine patch
instead of a full-on cancer stick. An improvement, but I'd really
prefer we break the addiction entirely.


Agreed, but to thread your metaphor there's a reason you have 12-step 
programmes and going cold turkey is considered a bad idea (in fact it 
can be fatal in some addictions). I say let's do this in an n-steps way.



There are a number of remedies that would address this formal
objection. The most preferable would be for the W3C to work amicably
with the WHATWG to figure out a way to treat them and their specs as
legitimate, instead of constantly copying them.


+1. I would like that discussion to:

  - be in public
  - not be on a technical list
  - not be on a generic process list (because it should be focused)
  - be strict about banning trolls

If you agree that's something we ought to do, I'm happy to set u

Re: PSA: publishing new WD of URL spec

[Robin Berjon]

On 10/09/2014 18:48 , Marcos Caceres wrote:

This is a formal objection to publication of this specification.
The rationale for the objection was already sent to the wwwprocess list.


Would you lift yours if Domenic lifted his?

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

Re: publishing new WD of URL spec

[Robin Berjon]

On 11/09/2014 00:14 , Glenn Adams wrote:

WHATWG specs are not legitimate for reference by W3C specs. Their IPR
status is indeterminate and they do not follow a consensus process.


This is blatant trolling as well as factually wrong in every single 
statement that it makes.


I would invite all of you to not feed this thread as it can't possibly 
lead anywhere useful.


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

Re: File API: reading a Blob

[Aymeric Vitte]

But I suppose that should be one of the first use case for Google to 
introduce streams with MSE, no?


To be more clear about what I mean by "back pressure for things coming 
from outside of the browser":


- XHR: the Streams API should define how xhr gets chunks using Range 
according to the flow and adapt accordingly transparently for the users


- WebSockets: use something like bufferedAmount but that can be notified 
to the users, so the users can adapt the flow, currently bufferedAmount 
is not extremely usefull since you might need to do some polling to 
check it.



Le 11/09/2014 08:36, Takeshi Yoshino a écrit :
On Thu, Sep 11, 2014 at 8:47 AM, Aymeric Vitte > wrote:


Does your experimentation pipe the XHR stream to MSE? Obviously
that should be the target for yt, this would be a first real
application of the Streams API.


It's not yet updated to use the new Streams. Here's our layout test 
for MSE. responseType = 'legacystream' makes the XHR return the old 
version of the stream.


https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/LayoutTests/http/tests/media/media-source/mediasource-append-legacystream.html&q=createMediaXHR&sq=package:chromium&type=cs&l=12

You can find the following call in the file.

sourceBuffer.appendStream(xhr.response);


Because the Streams API does not define how to apply back pressure
to XHR, but does define how to apply back pressure between XHR and
MSE.

Probably the spec should handle on a per case basis what should be
the behavior in term of back pressure for things coming from
outside of the browser (xhr, websockets, webrtc, etc , not
specified as far as I know) and for things going on inside the
browser (already specified)

Le 08/09/2014 06:58, Takeshi Yoshino a écrit :

On Thu, Sep 4, 2014 at 7:02 AM, Aymeric Vitte
mailto:vitteayme...@gmail.com>> wrote:

The fact is that most of the W3C groups impacted by streams
(File, indexedDB, MSE, WebRTC, WebCrypto, Workers, XHR,
WebSockets, Media Stream, etc, I must forget a lot here) seem
not to care a lot about it and maybe just expect streams to
land in the right place in the APIs when they are available,
by some unknown magic.

I still think that the effort should start from now for all
the APIs (as well as the implementation inside browsers,
which apparently has started for Chrome, but Chrome was
supposed to have started some implementation of the previous
Streams APIs, so it's not very clear), and that it should be
very clearly synchronized, disregarding vague assumptions
from the groups about low/high level and Vx releases, eluding
the issue.


Chrome has an experimental implementation [1] of the new Streams
API [2] integrated with XHR [3] behind a flag.

We receive data from the browser process over IPC (both network
and blob case). The size of data chunks and arrival timing depend
on various factors. The received chunks are passed to the
XMLHttpRequest class on the same thread as JavaScript runs. We
create a new instance of ReadableStream [4] on arrival of the
first chunk. On every chunk arrival, we create an ArrayBuffer
from the chunk and then call [[enqueue]](chunk) [5] equivalent
C++ function to put it into the ReadableStream.

The ReadableStream is available from the "response" attribute in
the LOADING and DONE state (if no error). The chunks pushed to
the ReadableStream become available for read immediately.

Any problem occurs while loading data from network/blob, we call
[[error]](e) [6] equivalent C++ function with an exception as
defined in the XHR spec for sync XHR.

Currently, XMLHttpRequest doesn't exert any back pressure. We
plan to do something not to read too much data from disk/network.
It might be worth specifying something about the flow control in
the abstract read from blob/network operation at standard level.

[1]

https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/LayoutTests/http/tests/xmlhttprequest/response-stream.html
[2] https://github.com/whatwg/streams

[3] https://github.com/tyoshino/streams_integration/
[4] https://github.com/whatwg/streams#readablestream
[5] https://github.com/whatwg/streams#enqueuechunk
[6] https://github.com/whatwg/streams#errore


-- 
Peersm :http://www.peersm.com

torrent-live:https://github.com/Ayms/torrent-live
node-Tor :https://www.github.com/Ayms/node-Tor
GitHub :https://www.github.com/Ayms




--
Peersm : http://www.peersm.com
torrent-live: https://github.com/Ayms/torrent-live
node-Tor : https://www.github.com/Ayms/node-Tor
GitHub : https://www.github.com/Ayms

Re: Web Components: two questions

[Hayato Ito]

On Thu Sep 11 2014 at 4:04:27 PM Hayato Ito  wrote:

> On Thu Sep 11 2014 at 3:25:01 PM Ondřej Žára 
> wrote:
>
>> > 1) Are form elements (input, select, textarea) inside a shadow dom
>> > considered when submitting a form?
>> >
>> >
>> > The Shadow DOM spec doesn't say anything about this. Therefore,
>> > form elements should be in the same node tree.
>> >
>> > For example, suppose a  element is in the node tree A. In this
>> > case, form elements in node tree B,  where A != B,  are not considered
>> > at all when submitting the form.
>>
>> I am not sure I am able to fully interpret your response: do you imply
>> that an  field inside a shadow dom inside a 
>>
>> (diagram:
>>
>> 
>> |
>>[shadow root]
>> |
>>   
>>
>> )
>>
>> shall get submitted?
>>
>>
> No, the  is not considered.
>
>
>> This might pose some backwards incompatibility for tools that
>> automatically aggregate input values (for e.g. xhr-based submit) by
>> executing form.querySelectorAll("input, select, textarea"). An input
>> inside a shadow root (not visible to a querySelectorAll from the outside
>> world) will get ommited.
>>
>>
> This sounds an orthogonal problem, doesn't that?
> querlySelectorAll() can't select nodes in other node trees in any cases.
>
>
Correction.
If we use `/deep/` (or  `::shadow') in the selector, we can. :)



>
>
>>
>> Sincerely,
>> O. Zara
>>
>>
>> >
>> > A composed tree shouldn't have any effect on submitting a from.
>> >
>> > 2) I am having troubles with lifecycle callback of custom elements
>> that
>> > are cloned from within a  element. More specifically, nor
>> > createdCallback nor attachedCallback are fired when an element in
>> > question is cloned from template.content or appended to an active
>> > document. Is this a specified behavior? How do I properly initialize
>> > custom elements that "live" inside a  ?
>> >
>> >
>> > Thanks a lot,
>> > sincerely,
>> > Ondrej Zara
>> >
>> >
>> >
>> >
>> > --
>> > *RNDr. Ondřej Žára*
>> > Programátor UI senior
>> >
>> > https://twitter.com/0ndras
>> > ondrej.z...@firma.seznam.cz 
>> > > > >
>> > http://www.seznam.cz/
>> >
>> > Seznam.cz, a.s., Radlická 3294/10, 150 00 Praha 5
>> > 
>> >
>> >
>>
>> --
>> *RNDr. Ondřej Žára*
>> Programátor UI senior
>>
>> https://twitter.com/0ndras
>> ondrej.z...@firma.seznam.cz 
>> http://www.seznam.cz/
>>
>> Seznam.cz, a.s., Radlická 3294/10, 150 00 Praha 5 
>>
>>

Re: Web Components: two questions

[Ondřej Žára]

The short answer to whether  inside shadow root under a 
will be sent or not is "No".

The "node tree" mentioned in Hayato's mail means that  and 
belong to different trees.


Sweet, thanks for explanation.

(Now only the second question remains...)


Sincerely,
O. Zara





 2) I am having troubles with lifecycle callback of custom
elements that
 are cloned from within a  element. More
specifically, nor
 createdCallback nor attachedCallback are fired when an
element in
 question is cloned from template.content or appended to an
active
 document. Is this a specified behavior? How do I properly
initialize
 custom elements that "live" inside a  ?


 Thanks a lot,
 sincerely,
 Ondrej Zara




 --
 *RNDr. Ondřej Žára*
 Programátor UI senior

https://twitter.com/0ndras
ondrej.z...@firma.seznam.cz 
>
 __se__znam.cz 
 >>
http://www.seznam.cz/

 Seznam.cz, a.s., Radlická 3294/10, 150 00 Praha 5
 



--
*RNDr. Ondřej Žára*
Programátor UI senior

https://twitter.com/0ndras
ondrej.z...@firma.seznam.cz 
>
http://www.seznam.cz/

Seznam.cz, a.s., Radlická 3294/10, 150 00 Praha 5






--
Takayoshi Kochi


--
*RNDr. Ondřej Žára*
Programátor UI senior

https://twitter.com/0ndras
ondrej.z...@firma.seznam.cz 
http://www.seznam.cz/

Seznam.cz, a.s., Radlická 3294/10, 150 00 Praha 5 

Re: Web Components: two questions

[Hayato Ito]

On Thu Sep 11 2014 at 3:25:01 PM Ondřej Žára 
wrote:

> > 1) Are form elements (input, select, textarea) inside a shadow dom
> > considered when submitting a form?
> >
> >
> > The Shadow DOM spec doesn't say anything about this. Therefore,
> > form elements should be in the same node tree.
> >
> > For example, suppose a  element is in the node tree A. In this
> > case, form elements in node tree B,  where A != B,  are not considered
> > at all when submitting the form.
>
> I am not sure I am able to fully interpret your response: do you imply
> that an  field inside a shadow dom inside a 
>
> (diagram:
>
> 
> |
>[shadow root]
> |
>   
>
> )
>
> shall get submitted?
>
>
No, the  is not considered.


> This might pose some backwards incompatibility for tools that
> automatically aggregate input values (for e.g. xhr-based submit) by
> executing form.querySelectorAll("input, select, textarea"). An input
> inside a shadow root (not visible to a querySelectorAll from the outside
> world) will get ommited.
>
>
This sounds an orthogonal problem, doesn't that?
querlySelectorAll() can't select nodes in other node trees in any cases.



>
> Sincerely,
> O. Zara
>
>
> >
> > A composed tree shouldn't have any effect on submitting a from.
> >
> > 2) I am having troubles with lifecycle callback of custom elements
> that
> > are cloned from within a  element. More specifically, nor
> > createdCallback nor attachedCallback are fired when an element in
> > question is cloned from template.content or appended to an active
> > document. Is this a specified behavior? How do I properly initialize
> > custom elements that "live" inside a  ?
> >
> >
> > Thanks a lot,
> > sincerely,
> > Ondrej Zara
> >
> >
> >
> >
> > --
> > *RNDr. Ondřej Žára*
> > Programátor UI senior
> >
> > https://twitter.com/0ndras
> > ondrej.z...@firma.seznam.cz 
> >  > >
> > http://www.seznam.cz/
> >
> > Seznam.cz, a.s., Radlická 3294/10, 150 00 Praha 5
> > 
> >
> >
>
> --
> *RNDr. Ondřej Žára*
> Programátor UI senior
>
> https://twitter.com/0ndras
> ondrej.z...@firma.seznam.cz 
> http://www.seznam.cz/
>
> Seznam.cz, a.s., Radlická 3294/10, 150 00 Praha 5 
>
>

Re: Web Components: two questions

[河内 隆仁]

Ondrej,

The short answer to whether  inside shadow root under a  will
be sent or not is "No".

The "node tree" mentioned in Hayato's mail means that  and 
belong to different trees.
Only elements in the same tree as  will be considered for submission.

So you don't have to worry about backward compatibility.


On Thu, Sep 11, 2014 at 3:24 PM, Ondřej Žára 
wrote:

> 1) Are form elements (input, select, textarea) inside a shadow dom
>> considered when submitting a form?
>>
>>
>> The Shadow DOM spec doesn't say anything about this. Therefore,
>> form elements should be in the same node tree.
>>
>> For example, suppose a  element is in the node tree A. In this
>> case, form elements in node tree B,  where A != B,  are not considered
>> at all when submitting the form.
>>
>
> I am not sure I am able to fully interpret your response: do you imply
> that an  field inside a shadow dom inside a 
>
> (diagram:
>
> 
>|
>   [shadow root]
>|
>  
>
> )
>
> shall get submitted?
>
> This might pose some backwards incompatibility for tools that
> automatically aggregate input values (for e.g. xhr-based submit) by
> executing form.querySelectorAll("input, select, textarea"). An input inside
> a shadow root (not visible to a querySelectorAll from the outside world)
> will get ommited.
>
>
> Sincerely,
> O. Zara
>
>
>
>> A composed tree shouldn't have any effect on submitting a from.
>>
>> 2) I am having troubles with lifecycle callback of custom elements
>> that
>> are cloned from within a  element. More specifically, nor
>> createdCallback nor attachedCallback are fired when an element in
>> question is cloned from template.content or appended to an active
>> document. Is this a specified behavior? How do I properly initialize
>> custom elements that "live" inside a  ?
>>
>>
>> Thanks a lot,
>> sincerely,
>> Ondrej Zara
>>
>>
>>
>>
>> --
>> *RNDr. Ondřej Žára*
>> Programátor UI senior
>>
>> https://twitter.com/0ndras
>> ondrej.z...@firma.seznam.cz 
>> > >
>> http://www.seznam.cz/
>>
>> Seznam.cz, a.s., Radlická 3294/10, 150 00 Praha 5
>> 
>>
>>
>>
> --
> *RNDr. Ondřej Žára*
> Programátor UI senior
>
> https://twitter.com/0ndras
> ondrej.z...@firma.seznam.cz 
> http://www.seznam.cz/
>
> Seznam.cz, a.s., Radlická 3294/10, 150 00 Praha 5 
>
>
>


-- 
Takayoshi Kochi