| 12:49 | <domfarolino> | annevk: Would appreciate any thoughts on https://github.com/whatwg/html/issues/5236#issuecomment-591409073 |
| 13:00 | <annevk> | domfarolino: yeah that seems fine, since the intersection will happen in the render loop anyway |
| 13:00 | <annevk> | domfarolino: at the "update the rendering" point that is |
| 13:01 | <annevk> | domfarolino: and you don't want to force that to happen |
| 13:01 | <domfarolino> | annevk: yep cool thanks |
| 13:01 | <annevk> | domfarolino: so yeah, this seems very reasonable and maybe even mandated 🙂 |
| 13:01 | <annevk> | hsivonen: hey I've been looking a bit at the Encoding visualization stuff |
| 13:02 | <domfarolino> | annevk: Yeah, basically in Chrome it can't be done reliably without forcing layout which is terrible to do at that time, so I figured this was probably not just a chrome thing, and would also make the spec simpler |
| 13:03 | <annevk> | domfarolino: yup |
| 13:03 | <annevk> | hsivonen: I'm not sure I fully understand the patch |
| 13:04 | <domfarolino> | Unfortunately this brings to light that in-viewport loading=lazy experience a slight load delay comparing to in-viewport loading=eager, but yeah, no way to avoid that I guess |
| 13:11 | <annevk> | hsivonen: never mind, I see now |
| 13:29 | <zcorpan> | domfarolino: browsers could speculatively load (some) lazy images to avoid delays (e.g. for pages that just apply loading=lazy on all images), right? |
| 13:33 | <domfarolino> | zcorpan: Chrome is experimenting with doing this on Data Saver mode (where `loading` default is `lazy`), but I guess it technically violates the spec. Could be used to provide good data that we could safely change the spec default in the future without breaking the world tho |
| 13:33 | <domfarolino> | http://crbug.com/996963 |
| 13:36 | <zcorpan> | domfarolino: all speculative loads are technically violating the spec, but as long as it's a "background" fetch and doesn't change how the "real" load happens, I think it should be fine |
| 13:37 | <domfarolino> | zcorpan: Ah yeah that's right, I forgot that basically the "preload" scanner is essentially doing that. Good call |
| 13:49 | <annevk> | hsivonen: it's very hard to resist improving visualize.py |
| 13:50 | <annevk> | hsivonen: ended up reading about some proposal to have an https://en.wikipedia.org/wiki/Control_Pictures equivalent for C1 |
| 16:16 | <andreubotella> | what's the correct terminology for associated "fields" to a webIDL interface? |
| 16:17 | <annevk> | andreubotella: members ((static) attributes / methods) |
| 16:18 | <andreubotella> | annevk: I meant the spec-level associated variables. |
| 16:18 | <annevk> | andreubotella: oh, there's an IDL issue on formalizing them as internal slots |
| 16:18 | <annevk> | andreubotella: hasn't happened yet |
| 16:19 | <andreubotella> | annevk: I see |
| 16:19 | <andreubotella> | annevk: does "associated slot" work as a temporary reference? |
| 16:19 | <annevk> | andreubotella: it's often surprising how much basic infrastructure is lacking |
| 16:20 | <andreubotella> | I'm working on a PR to encoding#176, and a note talks about "not unsetting that flag", which happens to be an associated slot. |
| 16:20 | <andreubotella> | I'd change that to "variable", but it's not one. |
| 16:20 | <annevk> | andreubotella: X has an associated Y or X has an internal slot [[Y]] is the convention |
| 16:20 | <andreubotella> | annevk: right. thanks so much |
| 16:21 | <annevk> | andreubotella: for Encoding I'd follow established precedent there |
| 17:09 | <TabAtkins> | andreubotella: Call them "internal slots", mark them up as <dfn attribute>\[[foo]]</dfn>, and link to them as {{[[foo]]}}. |
| 17:17 | <andreubotella> | TabAtkins: That's more for Javascript-y internal slots, right? I was talking about values associated to webIDL interfaces. |
| 17:18 | <andreubotella> | Though I'm only treating them as separate concepts because I see streams#963 doing it. |
| 17:18 | <annevk> | andreubotella: the idea is to converge |
| 17:18 | <andreubotella> | I' |
| 17:18 | <annevk> | But local precedent still matters more for now |
| 17:18 | <andreubotella> | I see. |
| 17:19 | <andreubotella> | I've been watching that issue for a while, because I'd like to read the streams spec but I don't take long to give up. |
| 17:22 | <TabAtkins> | There's no real distinction between those two concepts of "slots", I think? |
| 17:24 | <andreubotella> | from that issue, it seems like one is more WebIDL-ey and the other more Javascript-y |
| 17:24 | <annevk> | No, that issue also calls it out as stylistic and not worth worrying too much over |
| 17:24 | <andreubotella> | That's fair |
| 17:24 | <annevk> | And that remark is from quite a while ago too |
| 17:25 | <annevk> | Definitely see new IDL stuff starting out with slots these days now and then |
| 17:28 | <andreubotella> | I consume a lot of web specs as a web dev, but I'm barely getting started into working on the specs, so I might've missed stuff |
| 19:10 | <Domenic> | I wish I had not brought the baroque [[slot]] notation to the web specs world and just stuck with "associated foo" everywhere :( |
| 22:14 | <gendarme> | hello, what kind of support is available on this channel? |
| 22:14 | <gendarme> | I am looking for what attributes are necessary for creating a "title page" in html |
| 22:36 | <zcorpan> | gendarme: this channel is more about web standards, not so much web dev. maybe try #html5 or stackoverflow.com |
| 22:37 | <gendarme> | ok, thanks zcorpan |