Re: [HTML Imports]: Sync, async, -ish?
On Jan 28, 2014, at 2:11 PM, Jake Archibald wrote: > I'm really fond of the 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? Is it really the right thing to do in all cases? Isn't it better to delegate this to the component author? I have a trouble believing that we can impose one default behavior on all web components without providing abilities for web components to override those defaults. > 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. 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. > * 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. - R. Niwa
Re: Custom element callbacks timing
My understanding is that these callbacks can be invoked at roughly two
points in time:
The first one is when the browser is about to return to script. An example
is:
x.setAttribute('a', 'b');
// before here
...
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.
The second one is when performing a microtask checkpoint. An example is:
If X-A has a Custom Element definition, the parser will queue an upgrade
step. At the next microtask checkpoint that element's callback queue will
be processed.
If you're having a discussion about callbacks in the context of microtasks,
that latter case, plus Mutation Observers, are probably of interest to you.
HTH,
Dominic
On Wed, Jan 29, 2014 at 7:41 AM, Anne van Kesteren wrote:
> Can someone explain me, ideally in terms of examples, when these
> callbacks are invoked:
>
> http://w3c.github.io/webcomponents/spec/custom/#enqueuing-and-invoking-callbacks
> Are these different from microtasks? The way the specification reads
> at the moment suggests they are. If that is the case I'd prefer we
> have some more high-level discussion about introducing a new point
> when we want to call callbacks for DOM methods.
>
>
> --
> http://annevankesteren.nl/
>
>
--
Email SLA •
Google+
Custom element callbacks timing
Can someone explain me, ideally in terms of examples, when these callbacks are invoked: http://w3c.github.io/webcomponents/spec/custom/#enqueuing-and-invoking-callbacks Are these different from microtasks? The way the specification reads at the moment suggests they are. If that is the case I'd prefer we have some more high-level discussion about introducing a new point when we want to call callbacks for DOM methods. -- http://annevankesteren.nl/
Re: [HTML Imports]: Sync, async, -ish?
(I'm late to this party, sorry) I'm really fond of the 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.
Re: Do we need a rendering spec?
+CSS WG Hi Dimitri, You wrote, to the WebApps WG: > As HTML imports [1] are implemented across browsers, there’s a potential > for diversity of opinion in how rendering of documents with imports > occurs. What blocks rendering? What doesn’t? To prevent the inevitable > pain of converging on a de-facto standard behavior, it would be > super-nice to have precise documentation of when the rendering engine > should start (and stop) rendering the document. > > The specific problem we (the imports people) are interested in is “when > do things first appear on screen?”, and we could definitely hack up some > vague informative prose in the HTML Imports spec in the short term. > > But long-term, do we (the W3C people) want a rendering spec? When this has come up in the past, the CSS WG has chosen not to do this. If you think the platform needs such a spec, I encourage you to engage with the layout and rendering experts of the CSS WG to make your case. Ted P.S. For folk who don't follow public-webapps, the thread is here: http://lists.w3.org/Archives/Public/public-webapps/2014JanMar/0101.html
Re: CFCs for ordinary drafts, was CFC for Re: "W3C" XHR, was Re: [admin] Draft of updated charter available for review
On 1/27/14 10:48 AM, ext Marcos Caceres wrote: I'm wondering if we can change the group's work mode to not requiring CFCs for ordinary working drafts? Unless I'm not getting something, they seem to add an unnecessary delay to getting stuff published. Hi Marcos, Strictly speaking there is no requirement to record the group's consensus to publish a *plain* WD. However, given WebApps does [for all practical purposes] all of its technical work asynchronously and has a very broad set of specs, at least some [perhaps the majority?] of members don't follow every spec in detail (f.ex. tracking a spec's check-ins). As such, I think a CfC for these WDs is useful since it provides a heads-up to members the Editor(s) has made sufficient updates that they would like to publish a new TR. I (personally) don't follow every commit for every spec and tend to think the principle of least surprise suggests it wouldn't be especially inclusive for an Editor to unilaterally decide to publish a new TR. That said, I'm certainly open for ways to reduce overhead and delays although in this case, since the XHR spec work started in 2006, I'm not sure a few days to give people a chance to review/comment before publishing a new WD really does constitute a [significant] "delay". (FYI, a quick scan of the group's mail archives shows about 12 CfC for plain WDs in 2013 among the group's 4K+ emails.) If there is consensus a 7-day CfC to publish a plain WD is problematic, the duration of the CfC could be reduced. Another option would be for the Editor(s) to issue some type of "Intent to Publish new WD" and give people a few days for comments. Perhaps there are other options too but I do think we should have an expectation that group members are at least given a heads-up before a new WD is published. Feedback from others is definitely encouraged! -Thanks, AB
