Re: [HTML Imports]: Sync, async, -ish?
On Tue, Jan 28, 2014 at 5:11 PM, Jake Archibald jaffathec...@gmail.comwrote:
(I'm late to this party, sorry)
I'm really fond of the link rel=import elements=x-foo, x-bar
pattern, but I yeah, you could end up with a massive elements list.
How about making link[rel=import] async by default, but make elements with
a dash in the tagname display:none by default?
On a news article with components, the news article would load, the
content would be readable, then the components would appear as they load.
Similar to images without a width height specified.
As with images, the site developer could apply styling for the component
roots before they load, to avoid/minimise the layout change as components
load. This could be visibility:hidden along with a width height (or
aspect ratio, which I believe is coming to CSS), or display:block and
additional styles to provide a view of the data inside the component that's
good enough for a pre-enhancement render.
This gives us:
* Performance by default (we'd have made scripts async by default if we
could go back right?)
* Avoids FOUC by default
* Can be picked up by a preparser
* Appears to block rendering on pages that are build with a root web
component
Thoughts?
Cheers,
Jake.
I think that there are clearly use cases where either way feels right.
It's considerably easier to tack on a pattern that makes async feel sync
than the reverse. I'd like to suggest that Jake's proposal is -almost-
really good. As an author, I'd be happier with the proposal if there were
just a little bit of sugar that made it very very easy to opt in and I
think that this lacks that only in that it relies either on a root level
component or some script to tweak something that indicates the body
visibility or display. If we realize that this is going to be a common
pattern, why not just provide the simple abstration as part of the system.
This could be as simple as adding something to section 7.2[1] which says
something like
The :unresolved pseudoclass may also be applied to the body element. The
body tag is considered :unresolved until all of the elements contained in
the original document have been resolved. This provides authors a simple
means to additionally manage rendering FOUC including and all the way up to
fully delaying rendering of the page until the Custom Element dependencies
are resolved, while still defaulting to asyc/non-blocking behavior.
Example:
-
/* Apply body styles like background coloring,
but don't render any elements until it's all ready...
*/
body:unresolved * {
display: none;
}
WDYT?
[1] -
http://w3c.github.io/webcomponents/spec/custom/#unresolved-element-pseudoclass
--
Brian Kardell :: @briankardell :: hitchjs.com
Re: [HTML Imports]: Sync, async, -ish?
On 28 January 2014 18:19, Ryosuke Niwa rn...@apple.com wrote: How about making link[rel=import] async by default, but make elements with a dash in the tagname display:none by default? Is it really the right thing to do in all cases? Nope, but no default is. The default shouldn't be slow for the user. script's default is terrible, and we're still fighting its default with education. img's default however is pretty good. Isn't it better to delegate this to the component author? Yep, you can get the blocking behaviour back. In fact, you can display:none body until all your components are there if you want, but that's the bar you should have to jump over to create something that results in the user looking at a blank screen during loading. But that would mean that document authors need to be aware of exact dimensions, styles, theme, etc... of each component they use on the page, and add relevant CSS rules. In addition, each component then needs to cancel/override those rules when they get instantiated. Nope, in some cases appearing would be fine. In others you can reserve space. In others you can show the inner data without interaction. If you really must, you can show a blank screen until everything has loaded. * Performance by default (we'd have made scripts async by default if we could go back right?) * Avoids FOUC by default Could you clarify how this proposal avoids FOUC? If unresolved elements were to be initially display: none and turns into display: block/inline later, then that would most likely cause a reflow/relayout of the page and causes a FOUC. You never see a flash of unstyled content. Content is only shown once its styles are ready. Basically, html imports are taking cues from script, and script's default behaviour is a mistake. If we must follow the behaviour of something legacy, it should be img. Don't block rendering, show on load, allow the user to do something more blocking if they must.
Re: [HTML Imports]: Sync, async, -ish?
:unresolved { display: none; } plus lazyload (
https://dvcs.w3.org/hg/webperf/raw-file/tip/specs/ResourcePriorities/Overview.html#attr-lazyload)
would allow devs to create the non-blocking behaviour. But this is the
wrong way around. Devs should have to opt-in to the slow thing and get the
fast thing by default.
On 29 January 2014 08:02, Brian Kardell bkard...@gmail.com wrote:
On Tue, Jan 28, 2014 at 5:11 PM, Jake Archibald jaffathec...@gmail.comwrote:
(I'm late to this party, sorry)
I'm really fond of the link rel=import elements=x-foo, x-bar
pattern, but I yeah, you could end up with a massive elements list.
How about making link[rel=import] async by default, but make elements
with a dash in the tagname display:none by default?
On a news article with components, the news article would load, the
content would be readable, then the components would appear as they load.
Similar to images without a width height specified.
As with images, the site developer could apply styling for the component
roots before they load, to avoid/minimise the layout change as components
load. This could be visibility:hidden along with a width height (or
aspect ratio, which I believe is coming to CSS), or display:block and
additional styles to provide a view of the data inside the component that's
good enough for a pre-enhancement render.
This gives us:
* Performance by default (we'd have made scripts async by default if we
could go back right?)
* Avoids FOUC by default
* Can be picked up by a preparser
* Appears to block rendering on pages that are build with a root web
component
Thoughts?
Cheers,
Jake.
I think that there are clearly use cases where either way feels right.
It's considerably easier to tack on a pattern that makes async feel sync
than the reverse. I'd like to suggest that Jake's proposal is -almost-
really good. As an author, I'd be happier with the proposal if there were
just a little bit of sugar that made it very very easy to opt in and I
think that this lacks that only in that it relies either on a root level
component or some script to tweak something that indicates the body
visibility or display. If we realize that this is going to be a common
pattern, why not just provide the simple abstration as part of the system.
This could be as simple as adding something to section 7.2[1] which says
something like
The :unresolved pseudoclass may also be applied to the body element. The
body tag is considered :unresolved until all of the elements contained in
the original document have been resolved. This provides authors a simple
means to additionally manage rendering FOUC including and all the way up to
fully delaying rendering of the page until the Custom Element dependencies
are resolved, while still defaulting to asyc/non-blocking behavior.
Example:
-
/* Apply body styles like background coloring,
but don't render any elements until it's all ready...
*/
body:unresolved * {
display: none;
}
WDYT?
[1] -
http://w3c.github.io/webcomponents/spec/custom/#unresolved-element-pseudoclass
--
Brian Kardell :: @briankardell :: hitchjs.com
Re: [HTML Imports]: Sync, async, -ish?
On Wed, Jan 29, 2014 at 12:09 PM, Jake Archibald jaffathec...@gmail.comwrote:
:unresolved { display: none; } plus lazyload (
https://dvcs.w3.org/hg/webperf/raw-file/tip/specs/ResourcePriorities/Overview.html#attr-lazyload)
would allow devs to create the non-blocking behaviour. But this is the
wrong way around. Devs should have to opt-in to the slow thing and get the
fast thing by default.
Isn't that what I suggested? I suggested that it be asyc, just as you said
- and that all we do is add the ability to use the :unresolved pseudo class
on the body. This provides authors as a simple means of control for opting
out of rendering in blocks above the level of the component without
resorting to the need to do it via script or a root level element which
serves no other real purpose. This level of ability seems not just simpler,
but probably more desirable - like a lot of authors I've done a lot of work
with things that pop into existence and cause relayout -- often the thing I
want to block or reserve space for isn't the specific content, but a
container or something. Seems to me with addition of a body level
:unresolved you could answer pretty much any use case for partial rendering
from just dont do it all the way to screw it, the thing pops into
existence (the later being the default) very very simply - and at the
right layer (CSS).
Re: [HTML Imports]: Sync, async, -ish?
My bad, many apologies. I get what you mean now.
However, if web components are explaining the platform then body is
:resolved by browser internals (I don't know if this is how :resolved works
currently). Eg, imagine select as a built-in component which is resolved
and given a shadow DOM by internals.
On 29 January 2014 09:19, Brian Kardell bkard...@gmail.com wrote:
On Wed, Jan 29, 2014 at 12:09 PM, Jake Archibald
jaffathec...@gmail.comwrote:
:unresolved { display: none; } plus lazyload (
https://dvcs.w3.org/hg/webperf/raw-file/tip/specs/ResourcePriorities/Overview.html#attr-lazyload)
would allow devs to create the non-blocking behaviour. But this is the
wrong way around. Devs should have to opt-in to the slow thing and get the
fast thing by default.
Isn't that what I suggested? I suggested that it be asyc, just as you
said - and that all we do is add the ability to use the :unresolved pseudo
class on the body. This provides authors as a simple means of control for
opting out of rendering in blocks above the level of the component without
resorting to the need to do it via script or a root level element which
serves no other real purpose. This level of ability seems not just simpler,
but probably more desirable - like a lot of authors I've done a lot of work
with things that pop into existence and cause relayout -- often the thing I
want to block or reserve space for isn't the specific content, but a
container or something. Seems to me with addition of a body level
:unresolved you could answer pretty much any use case for partial rendering
from just dont do it all the way to screw it, the thing pops into
existence (the later being the default) very very simply - and at the
right layer (CSS).
[quota-api] Heads-up: TAG review started
Hi All - just a heads-up the TAG has started to review the Quota API: https://github.com/w3ctag/spec-reviews/issues/21 Thanks Domenic! Looking forward to the feedback. -AB
[quota-api] Seeking Implementation plans for Firefox, IE, Webkit, etc.
Hi All, In case folks missed it, on January 16, Hiroki Nakagawa submitted an Intent to Implement and Ship Quota Management API (unprefixed) e-mail to the [blink-dev] list. If anyone has implementation/ship data for Firefox, IE, WebKit, etc., please let us know. -Thanks, AB [blink-dev] https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/ciicp7mJolQ
RE: [quota-api] Heads-up: TAG review started
Hi guys! Just so you know my review notes are very preliminary and I wanted to run them by other TAG members before presenting them in any official capacity; don't take them too seriously yet :)
Re: [HTML Imports]: Sync, async, -ish?
On Wed, Jan 29, 2014 at 12:30 PM, Jake Archibald jaffathec...@gmail.comwrote:
My bad, many apologies. I get what you mean now.
However, if web components are explaining the platform then body is
:resolved by browser internals (I don't know if this is how :resolved works
currently). Eg, imagine select as a built-in component which is resolved
and given a shadow DOM by internals.
7.2 of custom elements states:
The :unresolved pseudoclass *must* match all custom
elements whose created callback has not yet been invoked.
I suppose this leaves wiggle room that it may actually in theory match on
native elements as well. As you say, this is a nice explanation maybe for
all elements - though - it doesn't seem remarkable what a custom element
would have something a native wouldn't. Either way, I think my proposal
holds up in basic theory, the only caveat is whether the thing on body is
just a specialized meaning of resolved that only applies to custom
elements, or whether you need a specific name for that thing, right? It's
really entirely bikesheddable what that thing should be called or maps to -
there must be a name for the document is done upgrading elements that we
in the tree at parse - I dont think that is DOMContentLoaded, but
hopefully you take my point. If we could agree that that solution works,
we could then have a cage match to decide on a good name :)
On 29 January 2014 09:19, Brian Kardell bkard...@gmail.com wrote:
On Wed, Jan 29, 2014 at 12:09 PM, Jake Archibald
jaffathec...@gmail.comwrote:
:unresolved { display: none; } plus lazyload (
https://dvcs.w3.org/hg/webperf/raw-file/tip/specs/ResourcePriorities/Overview.html#attr-lazyload)
would allow devs to create the non-blocking behaviour. But this is the
wrong way around. Devs should have to opt-in to the slow thing and get the
fast thing by default.
Isn't that what I suggested? I suggested that it be asyc, just as you
said - and that all we do is add the ability to use the :unresolved pseudo
class on the body. This provides authors as a simple means of control for
opting out of rendering in blocks above the level of the component without
resorting to the need to do it via script or a root level element which
serves no other real purpose. This level of ability seems not just simpler,
but probably more desirable - like a lot of authors I've done a lot of work
with things that pop into existence and cause relayout -- often the thing I
want to block or reserve space for isn't the specific content, but a
container or something. Seems to me with addition of a body level
:unresolved you could answer pretty much any use case for partial rendering
from just dont do it all the way to screw it, the thing pops into
existence (the later being the default) very very simply - and at the
right layer (CSS).
--
Brian Kardell :: @briankardell :: hitchjs.com
Re: [quota-api] Seeking Implementation plans for Firefox, IE, Webkit, etc.
Hi, we don't have any exact data, but we (mozilla) do plan to implement it AFAIK. Jan On 29/01/14 09:47, Arthur Barstow wrote: Hi All, In case folks missed it, on January 16, Hiroki Nakagawa submitted an Intent to Implement and Ship Quota Management API (unprefixed) e-mail to the [blink-dev] list. If anyone has implementation/ship data for Firefox, IE, WebKit, etc., please let us know. -Thanks, AB [blink-dev] https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/ciicp7mJolQ
Re: [HTML Imports]: Sync, async, -ish?
I'm not excited about making render blocking easier, but I think you're
right.
However, this is all premature detail while the behaviour is blocking-first.
On 29 January 2014 09:53, Brian Kardell bkard...@gmail.com wrote:
On Wed, Jan 29, 2014 at 12:30 PM, Jake Archibald
jaffathec...@gmail.comwrote:
My bad, many apologies. I get what you mean now.
However, if web components are explaining the platform then body is
:resolved by browser internals (I don't know if this is how :resolved works
currently). Eg, imagine select as a built-in component which is resolved
and given a shadow DOM by internals.
7.2 of custom elements states:
The :unresolved pseudoclass *must* match all custom
elements whose created callback has not yet been invoked.
I suppose this leaves wiggle room that it may actually in theory match on
native elements as well. As you say, this is a nice explanation maybe for
all elements - though - it doesn't seem remarkable what a custom element
would have something a native wouldn't. Either way, I think my proposal
holds up in basic theory, the only caveat is whether the thing on body is
just a specialized meaning of resolved that only applies to custom
elements, or whether you need a specific name for that thing, right? It's
really entirely bikesheddable what that thing should be called or maps to -
there must be a name for the document is done upgrading elements that we
in the tree at parse - I dont think that is DOMContentLoaded, but
hopefully you take my point. If we could agree that that solution works,
we could then have a cage match to decide on a good name :)
On 29 January 2014 09:19, Brian Kardell bkard...@gmail.com wrote:
On Wed, Jan 29, 2014 at 12:09 PM, Jake Archibald jaffathec...@gmail.com
wrote:
:unresolved { display: none; } plus lazyload (
https://dvcs.w3.org/hg/webperf/raw-file/tip/specs/ResourcePriorities/Overview.html#attr-lazyload)
would allow devs to create the non-blocking behaviour. But this is the
wrong way around. Devs should have to opt-in to the slow thing and get the
fast thing by default.
Isn't that what I suggested? I suggested that it be asyc, just as you
said - and that all we do is add the ability to use the :unresolved pseudo
class on the body. This provides authors as a simple means of control for
opting out of rendering in blocks above the level of the component without
resorting to the need to do it via script or a root level element which
serves no other real purpose. This level of ability seems not just simpler,
but probably more desirable - like a lot of authors I've done a lot of work
with things that pop into existence and cause relayout -- often the thing I
want to block or reserve space for isn't the specific content, but a
container or something. Seems to me with addition of a body level
:unresolved you could answer pretty much any use case for partial rendering
from just dont do it all the way to screw it, the thing pops into
existence (the later being the default) very very simply - and at the
right layer (CSS).
--
Brian Kardell :: @briankardell :: hitchjs.com
Re: Custom element callbacks timing
On Tue, Jan 28, 2014 at 3:44 PM, Dominic Cooney domin...@google.com wrote:
The first one is when the browser is about to return to script. An example
is:
script
x.setAttribute('a', 'b');
// before here
...
/script
If x is a Custom Element with an attributeChangedCallback, setAttribute will
queue an attributeChangedCallback; when returning to script x's callback
queue will be processed. Of course there are APIs, like setting innerHTML,
which can queue work for 1 element.
Okay. I think I'd like it to be way more explicit that a bunch of
methods and getters will now run callbacks just before returning.
Dimitry showed that in Chrome this is done through IDL annotations. So
maybe this new callback mechanism should be described as part of IDL.
Before the value from IDL is handed to JavaScript, it would run these
callbacks. Having it defined as part of those algorithms would make me
much more comfortable than the language hack the specification has
today.
--
http://annevankesteren.nl/
[Bug 24445] New: [Streams API] The Promise returned by write() method should tell the result of the write()
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24445 Bug ID: 24445 Summary: [Streams API] The Promise returned by write() method should tell the result of the write() Product: WebAppsWG Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P2 Component: Streams API Assignee: tyosh...@google.com Reporter: tyosh...@google.com QA Contact: public-webapps-bugzi...@w3.org CC: m...@w3.org, public-webapps@w3.org Currently, we're using the Promise returned by the write() method for pacing write speed, i.e. just for flow control. As we've changed the Streams API to be more generic one, correlating error and each write() operation now is more meaningful. We already have awaitSpaceAvailable(). Let's just leave the functionality of flow control to it and have the Promise returned by the write() method be fulfilled only when that write() operation is finished. Not when the WritableStream can accept (buffer) more write() operations. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 23973] [Streams API] Introduce in-band error signaling
https://www.w3.org/Bugs/Public/show_bug.cgi?id=23973 Takeshi Yoshino tyosh...@google.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Takeshi Yoshino tyosh...@google.com --- ED has the feature now. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 24022] [Streams API] Lazily encode write()-en DOMString
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24022 Takeshi Yoshino tyosh...@google.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Takeshi Yoshino tyosh...@google.com --- ED has this feature now. This also requires https://www.w3.org/Bugs/Public/show_bug.cgi?id=24445 so that the writer can identify which write() operation was actually bad. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 24023] [Streams API] Returned promise of write() should be fulfilled with current available space size rather than how many bytes were written
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24023 Takeshi Yoshino tyosh...@google.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Takeshi Yoshino tyosh...@google.com --- (In reply to Takeshi Yoshino from comment #2) (In reply to Takeshi Yoshino from comment #1) What we really should do is - consult dataSink (application specific logic) to determine how large (size, cost) a certain object is. dataSink (possibly asynchronously) computes the cost of a certain object written to it. pendingWriteQueue is built based on that cost. Non real application, generic consumer such as ByteStream introduced in the spec doesn't know how to compute cost for given object. So, it needs to be educated via e.g. write()'s second argument as I proposed in https://www.w3.org/Bugs/Public/show_bug.cgi?id=23977 . Pasted wrong bug. This is the right one. https://www.w3.org/Bugs/Public/show_bug.cgi?id=24445 This comment is just a mistake. Please ignore. Anyway, as https://www.w3.org/Bugs/Public/show_bug.cgi?id=24445 is changing the role of the Promise returned by the write() method, this bug is obsolete. -- You are receiving this mail because: You are on the CC list for the bug.
RE: [promises] Guidance on the usage of promises for API developers
I've incorporated most [1] of the feedback on-list into the latest draft [2]. It now includes an abstract, sections on when to use promises and when not to use them, and revised and reorganized guidance, shorthands, and examples sections. I haven't gotten to fixing everything mentioned [3]; in particular the async algorithm-writing advice hasn't been fixed yet [4]. But I'd love another round of feedback and suggestions. I'm particularly interested in what people think of the new examples [5], `delay(ms)` and `validatedDelay(ms)`; I fleshed them out with more rigor and some JavaScript code illustrating the correspondence. (The others are still a bit crusty.) I'd also love to hear what other examples could be added to help illustrate interesting or important concepts. [1]: https://github.com/w3ctag/promises-guide/issues?page=1state=closed [2]: https://github.com/w3ctag/promises-guide [3]: https://github.com/w3ctag/promises-guide/issues?page=1state=open [4]: https://github.com/w3ctag/promises-guide/issues/7 [5]: https://github.com/w3ctag/promises-guide#examples -Original Message- From: Arthur Barstow [mailto:art.bars...@nokia.com] Sent: Tuesday, January 14, 2014 07:33 To: public-webapps Subject: [promises] Guidance on the usage of promises for API developers FYI. (If you want to followup, please reply on www-tag @ w3.org) Original Message Subject:Guidance on the usage of promises for API developers Resent-Date:Mon, 13 Jan 2014 22:50:19 + Resent-From:www-...@w3.org Date: Mon, 13 Jan 2014 22:49:30 + From: ext Domenic Denicola dome...@domenicdenicola.com To: www-...@w3.org www-...@w3.org In the past, the TAG has discussed producing a document on how to use promises in spec text. There's even a placeholder on GitHub [1]. In the process of writing the ES6 promises spec, I ended up producing such a document myself [2]. It feels like an OK start to me, with some great feedback from Marcos incorporated a month ago. I'd be happy to push this document forward as a more official TAG work product. Presumably we'd move it to its own repository and all that. But first, I'd love to solicit feedback from spec authors and readers on what's currently there, and what you think should be there. Is it clear? Is it useful? For those writing specs using promises, have they found its guidance helpful, or have they found other tips that would be good to include? Several of the guidance points were drawn from finding mistakes in existing drafts that use promises; are there more drafts we should review? Feedback much appreciated, either here, or as an issue on the spec repository where the document currently lives [3]. (Note that I'm mostly concerned with content for now; we can worry about formatting later.) [1]: https://github.com/w3ctag/promises-spec-text [2]: https://github.com/domenic/promises-unwrapping/blob/master/docs/writing-specifications-with-promises.md [3]: https://github.com/domenic/promises-unwrapping/issues/new
Re: [promises] Guidance on the usage of promises for API developers
New texts look nice. Two comments... - XMLHttpRequest.send() is a good example, but as we go through multiple states and invokes onreadystatechange multiple times, I prefer not just quoting onreadystatechange but point the one-and-done aspect of XHR by using phrase like which triggers onreadystatechange with readyState of DONE - Could you please refrain from pointing the streams API or list both in the doc until we finish the discussion now we have?
[Bug 24445] [Streams API] The Promise returned by write() method should tell the result of the write()
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24445 Takeshi Yoshino tyosh...@google.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Takeshi Yoshino tyosh...@google.com --- Fixed in ED. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 23974] [Streams API] Don't inherit object URL feature
https://www.w3.org/Bugs/Public/show_bug.cgi?id=23974 Takeshi Yoshino tyosh...@google.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 23763] Separate MIME type from Stream or not
https://www.w3.org/Bugs/Public/show_bug.cgi?id=23763 Takeshi Yoshino tyosh...@google.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Takeshi Yoshino tyosh...@google.com --- Separated type from the core ReadableStream so that the base interfaces can be used out of browser world. -- You are receiving this mail because: You are on the CC list for the bug.
