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 ri
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
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 pref
(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 articl
+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
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 r
