[Bug 23787] Clarify that which HTTP entity body is referred in ProgressEvent spec

[bugzilla]

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

Takeshi Yoshino  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |---

--- Comment #4 from Takeshi Yoshino  ---
Thanks for the update, Anne, but the new text needs one fix.

http://xhr.spec.whatwg.org/

> To fire an upload progress event named e means to fire an event named e with 
> an event using the ProgressEvent interface that also meets these conditions:
> 
> Initialize the loaded attribute to the length of request's body.
> If the length of response's body is known through the Content-Length header, 
> set the lengthComputable attribute value to true and the total attribute 
> value to the length.

"response" in the 2nd bullet point should be "request".

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

Sync IO APIs in Shared Workers

[Jonas Sicking]

Hi all,

There has been some amount of debate about the virtue of sync IO APIs
in workers. Or sync APIs in workers in general.

One of the arguments made against sync APIs in workers made in [1] is
that even for workers, it is often important to keep code responsive
in order to react to actions taken by the user.

I.e. while locking up a worker thread for an extended period of time
won't cause problems like stuttered scrolling or UI that doesn't
visually react when you click them, you can still end up with apps
that seem unresponsive since the main thread is waiting to get back an
answer from a worker thread that is busy.

I honestly don't know what the right answer is. On one hand I could
definitely see code which does sync IO in a worker in order to search
for local data as the user types in a textbox, for example to
implement autocomplete. In such an instance it's very easy to
accidentally create unresponsive UI since it's not possible to abort
the current search when the user types another key.

On the other hand, having a worker which uses sync IO to synchronize
local data with data from a server can produce significantly simpler
code than doing the same thing with async IO. And this worker might
never need to react to user actions and thus it's no problem to not
handle incoming messages with low latency.

I also don't buy the argument that we can make async programming so
convenient that there's little cost to async APIs compared to sync
APIs. As we add convenience methods like task.js to make async code
look like sync code, the more we're creating an environment where
multiple code paths are running in parallel in the same heap. I.e. the
more we make it look like C-style threading. Yes, the differences are
there and they are important. But as the differences between async and
sync code gets smaller, the hazards get more real.

One thing that we so far have not seemed to consider is fixing the
problems with sync code raised in [1] and elsewhere.

We could enable sync IO APIs in workers while still allowing the
worker thread to remain responsive to messages from the main thread.
One solution is the API in [2]. Using that API the main thread can
send a error-response to a sync request for IO before the IO has
finished.

Another solution would be to use real sync IO APIs, but expose an
object in the parent thread which allows the parent to abort the
current operation.

Something else that could improve responsiveness while still allowing
people to write synchronous code is the ability to check if there are
pending messages on a channel without having to return to the event
loop. That way the code can keep running until there's a message to
process, and only return to the event loop when there is.

I'm not sure if any of these ideas will work in practice. Or if they
helpful but insufficient to solve the problem. More research is
needed.

The problem of unresponsive workers is arguably worse for
SharedWorkers. For shared workers a long running request from one
window will block processing for all windows.

One possible action here would be to disallow sync APIs in shared
workers for now. This way we can use dedicated workers as a test bed
to see if sync APIs are a problem, and if they are, if that problem
can be fixed.

The only browser shipping SharedWorkers is Chrome (not sure if Opera
does too?), so if the Blink developers are willing to remove it from
there, then this would be doable. Firefox has an implementation of
SharedWorkers too, but it's not yet shipping. I think we'd be willing
to turn off sync APIs in them before shipping.

[1] http://infrequently.org/2013/05/the-case-against-synchronous-worker-apis-2/
[2] http://lists.w3.org/Archives/Public/public-webapps/2013OctDec/0142.html

/ Jonas

Re: [HTML Imports]: Sync, async, -ish?

[Daniel Buchner]

> I don't see this solution scaling at all.
>
> Imports are a tree. If you have any import that includes any other import,
> now the information about what tags to "wait" for has to be duplicated
> along every node in that tree.
>
> If a library author chooses to make any sort of "all-in-one" import to
> reduce network requests, they will have an absurdly huge list.
>
> For example:
>
> Brick
>
> 
>
> or
>
> Polymer
>
>  elements="polymer-ajax polymer-anchor-point polymer-animation
> polymer-collapse polymer-cookie polymer-dev polymer-elements
> polymer-expressions polymer-file polymer-flex-layout polymer-google-jsapi
> polymer-grid-layout polymer-jsonp polymer-key-helper polymer-layout
> polymer-list polymer-localstorage polymer-media-query polymer-meta
> polymer-mock-data polymer-overlay polymer-page polymer-scrub
> polymer-sectioned-list polymer-selection polymer-selector
> polymer-shared-lib polymer-signals polymer-stock polymer-ui-accordion
> polymer-ui-animated-pages polymer-ui-arrow polymer-ui-breadcrumbs
> polymer-ui-card polymer-ui-clock polymer-ui-collapsible polymer-ui-elements
> polymer-ui-field polymer-ui-icon polymer-ui-icon-button
> polymer-ui-line-chart polymer-ui-menu polymer-ui-menu-button
> polymer-ui-menu-item polymer-ui-nav-arrow polymer-ui-overlay
> polymer-ui-pages polymer-ui-ratings polymer-ui-scaffold polymer-ui-sidebar
> polymer-ui-sidebar-header polymer-ui-sidebar-menu polymer-ui-splitter
> polymer-ui-stock polymer-ui-submenu-item polymer-ui-tabs
> polymer-ui-theme-aware polymer-ui-toggle-button polymer-ui-toolbar
> polymer-ui-weather polymer-view-source-link">
>
>
That's tad hyperbolic Other Daniel (I kid, I kid), you could just as soon
use an "all" value to block until all custom elements were ready. The
blocking-tag-name-list may be a poor idea, I have no illusions otherwise -
I don't even like it! --> To be honest, I believe all these one-off
deviations from developer expectations are the wrong answer. I'd much
rather stick with a sync loading import that offered an 'async' attribute
to force async loading, regardless of whether a script tag came after it or
not.

How about we review the use-cases again to get our bearings:

   1. Loading a bundle custom elements for the page
   2. Loading just custom elements required for the first view and load the
   rest async
   3. Loading template elements for use in the page's lifecycle
   4. Loading a random HTML file for random uses

#1 is probably going to be the most common use-case. Regardless of what you
elect to do with load juggling, developers are going to do whatever they
need to to ensure they aren't FUC'd. Hell, if you shake that beehive
enough, they'll just start using a 

Re: [HTML Imports]: Sync, async, -ish?

[Steve Souders]

DanielF: You would only list the custom tags that should be treated as
blocking. If *every* tag in Brick and Polymer should be blocking, then we
have a really big issue because right now they're NOT-blocking and there's
nothing in Web Components per se to specify a blocking behavior.

JJB: Website owners aren't going to be happy with either situation:
  - If custom tags are async (backfilled) by default and the custom tag is
a critical part of the page, subjecting users to a page that suddenly
changes layout isn't good.
  - If custom tags (really HTML imports) are sync (block rendering) by
default, then users stare at a blank screen during slow downloads.

I believe we need to pick the best default while also giving developers the
ability to choose what's best for them. Right now I don't see a way for a
developer to choose to have a custom element block rendering, as opposed to
be backfilled later. Do we think this is important? (I think so.) If so,
what's a good way to let web devs make custom elements block?

-Steve



On Thu, Nov 21, 2013 at 3:07 PM, John J Barton
wrote:

> Ok, so my 2 cents: it's ok but it gives a very Web 1.0 solution. We had to
> invent AJAX so developers could control the user experience in the face of
> significant network delay. As I said earlier, most apps will turn this
> problem over to the design team rather than cause users to leave while the
> browser spins waiting for the page to render.
>
>
> On Thu, Nov 21, 2013 at 3:01 PM, Daniel Buchner wrote:
>
>> Yes, that's the primary motivation. Getting FUC'd is going to be a
>> non-starter for serious app developers. We were just thinking of ways to
>> satisfy the use-case without undue burden.
>>
>
>

Re: [HTML Imports]: Sync, async, -ish?

[John J Barton]

Ok, so my 2 cents: it's ok but it gives a very Web 1.0 solution. We had to
invent AJAX so developers could control the user experience in the face of
significant network delay. As I said earlier, most apps will turn this
problem over to the design team rather than cause users to leave while the
browser spins waiting for the page to render.


On Thu, Nov 21, 2013 at 3:01 PM, Daniel Buchner  wrote:

> Yes, that's the primary motivation. Getting FUC'd is going to be a
> non-starter for serious app developers. We were just thinking of ways to
> satisfy the use-case without undue burden.
>

Re: [HTML Imports]: Sync, async, -ish?

[Daniel Freedman]

I don't see this solution scaling at all.

Imports are a tree. If you have any import that includes any other import,
now the information about what tags to "wait" for has to be duplicated
along every node in that tree.

If a library author chooses to make any sort of "all-in-one" import to
reduce network requests, they will have an absurdly huge list.

For example:

Brick



or

Polymer




On Thu, Nov 21, 2013 at 2:21 PM, Daniel Buchner  wrote:

> Steve and I talked at the Chrome Dev Summit today and generated an idea
> that may align the stars for our async/sync needs:
>
> 
>
> The idea is that imports are always treated as async, unless the developer
> opts-in to blocking based on the presence of specific tags. If the parser
> finds custom elements in the page that match user-defined "elements" tag
> names, it would block rendering until the associated link import has
> finished loading and registering the containing custom elements.
>
> Thoughts?
>
> - Daniel
>
>
> On Wed, Nov 20, 2013 at 11:19 AM, Daniel Buchner wrote:
>
>>
>> On Nov 20, 2013 11:07 AM, "John J Barton" 
>> wrote:
>> >
>> >
>> >
>> >
>> > On Wed, Nov 20, 2013 at 10:41 AM, Daniel Buchner 
>> wrote:
>> >>
>> >> Dimitri: right on.
>> >>
>> >> The use of script-after-import is the forcing function in the blocking
>> scenario, not imports.
>> >
>> > Yes.
>> >>
>> >> Let's not complicate the new APIs and burden the overwhelming use-case
>> to service folks who intend to use the technology in alternate ways.
>> >
>> > I  disagree, but happily the current API seems to handle the
>> alternative just fine. The case Steve raise is covered and IMO correctly,
>> now that you have pointed out that link supports load event. His original
>> example must block and if he wants it not to block it's on him to hook the
>> load event.
>> >>
>> >> For my bit, as long as the size of the components I include are not
>> overly large, I want them to load before the first render and avoid getting
>> FUCd or having to write a plethora of special CSS for the not-yet-upgraded
>> custom element case.
>> >
>> > According to my understanding, you are likely to be disappointed: the
>> components are loaded asynchronously and on a slow network with a fast
>> processor we will render page HTML before the component arrives.  We should
>> expect this to be the common case for the foresable future.
>> >
>>
>> There is, of course, the case of direct document.register() invocation
>> from a script tag, which will/should block to ensure all elements in
>> original source are upgraded. My only point, is that we need to be
>> realistic - both cases are valid and there are good reasons for each.
>>
>> Might we be able to let imports load async, even when a script proceeds
>> them, if we added a *per component type* upgrade event? (note: I'm not
>> talking about a perf-destroying per component instance event)
>>
>> > jjb
>> >>
>> >> Make the intended/majority case easy, and put the onus on the less
>> common cases to think about more complex asset arrangement.
>> >>
>> >> - Daniel
>> >>
>> >> On Nov 20, 2013 10:22 AM, "Dimitri Glazkov" 
>> wrote:
>> >>>
>> >>> John's commentary just triggered a thought in my head. We should stop
>> saying that HTML Imports block rendering. Because in reality, they don't.
>> It's the scripts that block rendering.
>> >>>
>> >>> Steve's argument is not about HTML Imports needing to be async. It's
>> about supporting legacy content with HTML Imports. And I have a bit less
>> sympathy for that argument.
>> >>>
>> >>> You can totally build fully asynchronous HTML Imports-based
>> documents, if you follow these two simple rules:
>> >>> 1) Don't put scripts after imports in main document
>> >>> 2) Use custom elements
>> >>>
>> >>> As an example:
>> >>>
>> >>> index.html:
>> >>> 
>> >>> ...
>> >>> 
>> >>> ..
>> >>>
>> >>> my-ad.html:
>> >>> 

Re: [HTML Imports]: Sync, async, -ish?

[Daniel Buchner]

Yes, that's the primary motivation. Getting FUC'd is going to be a
non-starter for serious app developers. We were just thinking of ways to
satisfy the use-case without undue burden.

Re: [HTML Imports]: Sync, async, -ish?

[John J Barton]

I guess this is designed to solve the flash of unstyled content problem by
blocking rendering of tags dependent upon unloaded custom elements?



On Thu, Nov 21, 2013 at 2:21 PM, Daniel Buchner  wrote:

> Steve and I talked at the Chrome Dev Summit today and generated an idea
> that may align the stars for our async/sync needs:
>
> 
>
> The idea is that imports are always treated as async, unless the developer
> opts-in to blocking based on the presence of specific tags. If the parser
> finds custom elements in the page that match user-defined "elements" tag
> names, it would block rendering until the associated link import has
> finished loading and registering the containing custom elements.
>
> Thoughts?
>
> - Daniel
>
>
> On Wed, Nov 20, 2013 at 11:19 AM, Daniel Buchner wrote:
>
>>
>> On Nov 20, 2013 11:07 AM, "John J Barton" 
>> wrote:
>> >
>> >
>> >
>> >
>> > On Wed, Nov 20, 2013 at 10:41 AM, Daniel Buchner 
>> wrote:
>> >>
>> >> Dimitri: right on.
>> >>
>> >> The use of script-after-import is the forcing function in the blocking
>> scenario, not imports.
>> >
>> > Yes.
>> >>
>> >> Let's not complicate the new APIs and burden the overwhelming use-case
>> to service folks who intend to use the technology in alternate ways.
>> >
>> > I  disagree, but happily the current API seems to handle the
>> alternative just fine. The case Steve raise is covered and IMO correctly,
>> now that you have pointed out that link supports load event. His original
>> example must block and if he wants it not to block it's on him to hook the
>> load event.
>> >>
>> >> For my bit, as long as the size of the components I include are not
>> overly large, I want them to load before the first render and avoid getting
>> FUCd or having to write a plethora of special CSS for the not-yet-upgraded
>> custom element case.
>> >
>> > According to my understanding, you are likely to be disappointed: the
>> components are loaded asynchronously and on a slow network with a fast
>> processor we will render page HTML before the component arrives.  We should
>> expect this to be the common case for the foresable future.
>> >
>>
>> There is, of course, the case of direct document.register() invocation
>> from a script tag, which will/should block to ensure all elements in
>> original source are upgraded. My only point, is that we need to be
>> realistic - both cases are valid and there are good reasons for each.
>>
>> Might we be able to let imports load async, even when a script proceeds
>> them, if we added a *per component type* upgrade event? (note: I'm not
>> talking about a perf-destroying per component instance event)
>>
>> > jjb
>> >>
>> >> Make the intended/majority case easy, and put the onus on the less
>> common cases to think about more complex asset arrangement.
>> >>
>> >> - Daniel
>> >>
>> >> On Nov 20, 2013 10:22 AM, "Dimitri Glazkov" 
>> wrote:
>> >>>
>> >>> John's commentary just triggered a thought in my head. We should stop
>> saying that HTML Imports block rendering. Because in reality, they don't.
>> It's the scripts that block rendering.
>> >>>
>> >>> Steve's argument is not about HTML Imports needing to be async. It's
>> about supporting legacy content with HTML Imports. And I have a bit less
>> sympathy for that argument.
>> >>>
>> >>> You can totally build fully asynchronous HTML Imports-based
>> documents, if you follow these two simple rules:
>> >>> 1) Don't put scripts after imports in main document
>> >>> 2) Use custom elements
>> >>>
>> >>> As an example:
>> >>>
>> >>> index.html:
>> >>> 
>> >>> ...
>> >>> 
>> >>> ..
>> >>>
>> >>> my-ad.html:
>> >>> 

Re: [HTML Imports]: Sync, async, -ish?

[Daniel Buchner]

Steve and I talked at the Chrome Dev Summit today and generated an idea
that may align the stars for our async/sync needs:



The idea is that imports are always treated as async, unless the developer
opts-in to blocking based on the presence of specific tags. If the parser
finds custom elements in the page that match user-defined "elements" tag
names, it would block rendering until the associated link import has
finished loading and registering the containing custom elements.

Thoughts?

- Daniel


On Wed, Nov 20, 2013 at 11:19 AM, Daniel Buchner  wrote:

>
> On Nov 20, 2013 11:07 AM, "John J Barton" 
> wrote:
> >
> >
> >
> >
> > On Wed, Nov 20, 2013 at 10:41 AM, Daniel Buchner 
> wrote:
> >>
> >> Dimitri: right on.
> >>
> >> The use of script-after-import is the forcing function in the blocking
> scenario, not imports.
> >
> > Yes.
> >>
> >> Let's not complicate the new APIs and burden the overwhelming use-case
> to service folks who intend to use the technology in alternate ways.
> >
> > I  disagree, but happily the current API seems to handle the alternative
> just fine. The case Steve raise is covered and IMO correctly, now that you
> have pointed out that link supports load event. His original example must
> block and if he wants it not to block it's on him to hook the load event.
> >>
> >> For my bit, as long as the size of the components I include are not
> overly large, I want them to load before the first render and avoid getting
> FUCd or having to write a plethora of special CSS for the not-yet-upgraded
> custom element case.
> >
> > According to my understanding, you are likely to be disappointed: the
> components are loaded asynchronously and on a slow network with a fast
> processor we will render page HTML before the component arrives.  We should
> expect this to be the common case for the foresable future.
> >
>
> There is, of course, the case of direct document.register() invocation
> from a script tag, which will/should block to ensure all elements in
> original source are upgraded. My only point, is that we need to be
> realistic - both cases are valid and there are good reasons for each.
>
> Might we be able to let imports load async, even when a script proceeds
> them, if we added a *per component type* upgrade event? (note: I'm not
> talking about a perf-destroying per component instance event)
>
> > jjb
> >>
> >> Make the intended/majority case easy, and put the onus on the less
> common cases to think about more complex asset arrangement.
> >>
> >> - Daniel
> >>
> >> On Nov 20, 2013 10:22 AM, "Dimitri Glazkov" 
> wrote:
> >>>
> >>> John's commentary just triggered a thought in my head. We should stop
> saying that HTML Imports block rendering. Because in reality, they don't.
> It's the scripts that block rendering.
> >>>
> >>> Steve's argument is not about HTML Imports needing to be async. It's
> about supporting legacy content with HTML Imports. And I have a bit less
> sympathy for that argument.
> >>>
> >>> You can totally build fully asynchronous HTML Imports-based documents,
> if you follow these two simple rules:
> >>> 1) Don't put scripts after imports in main document
> >>> 2) Use custom elements
> >>>
> >>> As an example:
> >>>
> >>> index.html:
> >>> 
> >>> ...
> >>> 
> >>> ..
> >>>
> >>> my-ad.html:
> >>> 

[Bug 23780] Check XMLHttpRequest and Notification don't break given the new script settings object stuff

[bugzilla]

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

Anne  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |---

--- Comment #10 from Anne  ---
Reopening per comment 8 to phrase the requirements a bit differently.

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

CfC: publish Candidate Recommendation of File API; deadline November 28

[Arthur Barstow]

Hi All,

Arun completed processing the comments [Comments] for the Last Call 
version of File API [LCWD]. Although the comments resulted in changes to 
the spec (see [Diff]), no new features were added and the changes are 
considered bug fixes. The most significant change is the Constructor 
APIs in Section 7 - see [Section-7].


Arun proposes the spec be advanced to Candidate Recommendation and this 
is a Call for Consensus (CfC) to publish a CR  using the following 
version as the basis:


  

This CfC satisfies: a) the group's requirement to "record the group's 
decision to request advancement" to CR; and b) "General Requirements for 
Advancement on the Recommendation Track" as defined in the Process 
Document 
.


Note the Status of the Document section and References in the Draft CR 
need some changes.


I propose 3 months as the minimal amount of time before we are ready to 
advance the spec to Propose Recommendation  and I propose we re-use the 
CR exit criteria we used for the IDB CR:


[[
During the Candidate Recommendation period, which ends @T+3months, the 
WG will complete its test suite. Before this specification exits 
Candidate Recommendation, two or more independent implementations must 
pass each test, although no single implementation must pass each test. 
The group will also create an Implementation Report.

]]

If anyone has feedback regarding features that could be marked "at 
risk", please speak up during this CfC.


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


-Thanks, ArtB

[Comments] 
[LCWD] 
[Section-7] 

[Diff] 

[Bug 21264] referrer source is wrong

[bugzilla]

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

Bug 21264 depends on bug 23780, which changed state.

Bug 23780 Summary: Check XMLHttpRequest and Notification don't break given the 
new script settings object stuff
https://www.w3.org/Bugs/Public/show_bug.cgi?id=23780

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |---

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

Re: [FileAPI] LC Comment Tracking

[Arun Ranganathan]

Art,

All LC commentary (http://www.w3.org/wiki/Webapps/LCWD-FileAPI-20130912) has 
been addressed and I think the draft is ready to be published as CR status.

The draft is: http://dev.w3.org/2006/webapi/FileAPI/

-- A*

On Nov 8, 2013, at 10:15 AM, Arun Ranganathan wrote:

> Hi Art,
> 
> On Nov 7, 2013, at 9:40 AM, Arthur Barstow wrote:
> 
>> 
>> Since it appears you will not be at WebApps' f2f meeting next week, I would 
>> appreciate it if you would please summarize the status of the comment 
>> processing, your next steps, etc. I am especially interested in whether or 
>> not you consider any of the bug fixes you applied as "substantive" and/or 
>> add a new feature (which would require a new LC).
> 
> 
> Most LC commentary that was substantive became a spec bug; I've fixed most 
> such spec. bugs, and the contributor/commentor has been notified.
> 
> In my opinion, the biggest change is to the File constructor.  This is 
> https://www.w3.org/Bugs/Public/show_bug.cgi?id=23479.  I don't think this is 
> a new feature, since the previous document pushed to "/TR" had a constructor, 
> athough a different signature.
> 
> Other changes include moving Blob URL to be redefined in terms of terminology 
> in the WHATWG URL spec, in lieu of ABNFs.
> 
> If you provide a dial-in on the day that you discuss File + FileSystem, I can 
> try and dial in, but this depends on time.  There will be others present from 
> Mozilla  :)  The LC commentary is tracked at 
> http://www.w3.org/wiki/Webapps/LCWD-FileAPI-20130912
> 
> -- A*
> 
> 
> 
>> -Thanks, ArtB
>> 
>> [1] 
>> 
>> 
>> On 9/12/13 10:39 AM, ext Arthur Barstow wrote:
>>> [ Bcc public-sysapps ; comments from SysApps are welcome ]
>>> 
>>> This is a Request for Comments for the 12 September 2013 Last Call
>>> Working Draft of File API:
>>> 
>>> 
>>> 
>>> The comment deadline is October 24 and all comments should be sent to
>>> the public-webapps@w3.org list with a subject: prefix of "[FileAPI]".
>>> 
>>> The spec's bug list is [Bugs] and the few `approved` tests we have can
>>> be run in a browser at [Tests].
>>> 
>>> -Thanks, ArtB
>>> 
>>> [Bugs] 
>>> [Tests] 
>>> 
>>> 
>> 
>> 
> 
>