| 09:17 | <nicolas____> | hi all, |
| 09:17 | <nicolas____> | already answered question I guess but: |
| 09:17 | <nicolas____> | how mature are the web components ? |
| 09:17 | <nicolas____> | custom elements and template are in v1 and in "living standard" but what does that imply and how likely are they to change ? |
| 09:17 | <nicolas____> | i don't know the w3c process but what does the version 1 imply ? does it ensure that every new versions will ensure backward compatibily ? |
| 09:17 | <nicolas____> | shadow dom seems to still changing, where can I find information about how mature to use it is ? |
| 09:17 | <nicolas____> | thanks in advance, |
| 09:17 | <nicolas____> | If anyone has a website explaining how mature are webcomponents, I'll be very grateful |
| 09:19 | <annevk> | nicolas____: "v1" is a Google designation as they implemented an earlier proposal (they call "v0") that ended up being revised |
| 09:19 | <annevk> | nicolas____: everything that's implemented by Chrome/Firefox/Safari is stable |
| 09:24 | <nicolas____> | thanks for the quick answer, |
| 09:24 | <nicolas____> | when you say what is implemented is stable, does that mean that w3c specifications on webcomponents won't move or that will move but with no breaking changes ? |
| 10:40 | <annevk> | nicolas____: it's mostly in WHATWG specifications |
| 10:40 | <annevk> | nicolas____: and things will evolve, but backwards compatibility is extremely important for things deployed across multiple user agents |
| 11:34 | <nicolas____> | annevk ok so to sum up, |
| 11:34 | <nicolas____> | custom element and template are part of of the living standard so they won't change a lot, |
| 11:34 | <nicolas____> | shadow dom is still in working draft , so it might change a lot but since it was widely deployed among the user agents, |
| 11:34 | <nicolas____> | user agents will ensure backwards compatibilty |
| 11:55 | <annevk> | nicolas____: shadow trees are part of the DOM standard, they are here to stay |
| 13:49 | <annevk> | domfarolino: I pushed another loading=lazy review just now |
| 13:50 | <annevk> | domfarolino: we had a power outage here yesterday and I ended up forgetting it |
| 14:26 | <Domenic> | We need to delete the W3C shadow DOM and custom elements documents |
| 14:27 | <Domenic> | I think they are causing the confusion above |
| 14:33 | <domfarolino> | annevk: np thanks. Regarding in-parallel observation, a while ago I was wondering if we should use an intersection observer from the spec since it has good infra to get notified when an intersection happens. Doing something as part of update the rendering sounds good too, but as you mentioned doing that in a follow-up seems fine |
| 14:59 | <annevk> | domfarolino: assuming some commitment to get to the follow-up, yeah |
| 15:24 | <domfarolino> | annevk: we’d also have to make sure attribute mutation is updated (that is, loading=lazy +> loading=eager also resumes updating-the-image-data |
| 15:48 | <domfarolino> | ...algorithm) |
| 15:58 | <annevk> | domfarolino: I'm not sure I understand |
| 16:12 | <domfarolino> | annevk: You suggested possibly adding something to "update the rendering", that would determine if an image intersects the viewport, and if so, resume #updating-the-image-data? Is this right? |
| 16:14 | <annevk> | domfarolino: I guess I see what you mean now |
| 16:14 | <annevk> | makes sense |
| 18:19 | <Domenic> | I don't understand why request upload streaming is so scary. It seems extremely hypothetical that there will be some exploitable issue in a behind-a-firewall server that can be triggered just by using Transfer-Encoding: chunked. |