Steve and I talked at the Chrome Dev Summit today and generated an idea
that may align the stars for our async/sync needs:
link rel=import elements=x-foo, x-bar /
The idea is that imports are always treated as async, unless the developer
opts-in to blocking based on the presence of specific
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 dan...@mozilla.com wrote:
Steve and I talked at the Chrome Dev Summit today and generated an idea
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.
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
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
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
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
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,
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
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
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
https://www.w3.org/Bugs/Public/show_bug.cgi?id=23780
Anne ann...@annevk.nl changed:
What|Removed |Added
Status|RESOLVED|REOPENED
https://www.w3.org/Bugs/Public/show_bug.cgi?id=23787
Takeshi Yoshino tyosh...@google.com changed:
What|Removed |Added
Status|RESOLVED|REOPENED
13 matches
Mail list logo
