| 12:51 | <krijn_> | Wow, is this thing still on? :) |
| 12:56 | <annevk> | krijn_: nog steeeds ja 😊 |
| 13:11 | <krijn_> | I think I've found a weird use case for img/srcset/sizes, that hasn't been discussed in https://github.com/whatwg/html/issues/2973 or https://github.com/ResponsiveImagesCG/picture-element/issues/86 yet. But I can't imagine I'm the first to bump into this, so I thought I'd ask the smart people.. |
| 13:12 | <krijn_> | Is work on h descriptors still being done? |
| 13:12 | <annevk> | zcorpan: ^ |
| 13:12 | <annevk> | yoav: ^ |
| 13:13 | <krijn_> | Like reading my mind :) |
| 13:16 | <krijn_> | The GitHub issue mentions `object-fit: contain`, but I'm now running into an issue with `object-fit: scale-down` on a `width: 100%; height: [calc/vh];` image, and I can't come up with the correct sizes attribute. Possibly because it doesn't exist, more likely because I'm too dumb. |
| 13:18 | <krijn_> | (Is it still ok to ask plain old HTML questions? Or should everything be padded with React boilerplate nowadays?) |
| 14:01 | <jgraham> | Hasn't HTML been replaced by hooks? ;) |
| 14:03 | <krijn_> | Hooks, hooks.. Rings a bell |
| 14:04 | <yoav> | hey krijn_! |
| 14:04 | <krijn_> | Long time! |
| 14:04 | <yoav> | indeed!! |
| 14:06 | <yoav> | h descriptors for srcset and height-limited sizes are both things that you'd need for height limited images, but also things we never specified and implemented... |
| 14:07 | <krijn_> | Yeah, that's what I found out ;'( |
| 14:08 | <krijn_> | So what's best in that case? Just add the largest known image width to the sizes attribute? |
| 14:08 | <krijn_> | Kind of defeats the point of using srcset in the first place, I guess |
| 14:09 | <yoav> | Might be interesting to file an issue against HTML (not React nor Hooks!) to document what you're unable to do, so that we can try to get folks to invest time in solving that |
| 14:09 | <krijn_> | Would https://github.com/whatwg/html/issues/2973 be the right issue? |
| 14:09 | <krijn_> | I'm not sure if adding h descriptors would be enough in my case |
| 14:09 | <yoav> | oh, yeah. That'd indeed be the issue to pile on to |
| 14:10 | <krijn_> | object-fit: scale-down; makes it a whole lot more complicated |
| 14:13 | <yoav> | Is it because your potential display dimensions can be either based on the container or on the image? |
| 14:13 | <krijn_> | Yep |
| 14:14 | <yoav> | yeah, I can see how that complicates things |
| 14:15 | <krijn_> | Dm'd you a link, np if you don't have the time to look into it :) |
| 15:15 | <annevk> | littledan: how about no primordials, gotta build your realm up from scratch |
| 15:15 | <littledan> | annevk: We could do that too; that's the current proposal, but it sounded like Mozilla and Chrome were unhappy about that |
| 15:16 | <annevk> | littledan: I thought the current proposal did have encodeURI, Array, and friends |
| 15:16 | <littledan> | or do you mean nothing at all, not even JS globals? |
| 15:16 | <littledan> | some of the JS globals are pointed to by JS syntax. Array is one of these |
| 15:18 | <annevk> | Ah yeah, anyway, going more minimal might be an interesting alternative |
| 15:18 | <annevk> | And is kinda what we wanted for worklets in the past |
| 15:19 | <annevk> | We still do I suppose, but it's too late now |
| 15:20 | <andreubotella> | looking at it from the perspective of something like jsdom, how would you even create an Array global in a new realm? |
| 15:21 | <andreubotella> | well, I guess you could implement everything in user-land, at a runtime cost |
| 15:22 | <jgraham> | The alternate point of view is Web Extensions and WebDriver where we want to allow extensions/test authors to create an isolated realm with access to the DOM but without needing to worry about the behaviour of content script (e.g. changing the prototypes, or adding expandos or global variables or whatever) |
| 15:22 | <jgraham> | So that's a kind of maximalist use case where you want pretty much everything the document realm can access |
| 15:22 | <annevk> | Array might be over the top, but there's a lot of primordials you don't really need to be there (including all the new library kind of things) |
| 15:31 | <annevk> | jgraham: that's pretty interesting too; I guess what you really want is some kind of control over what gets exposed there, but that will get complicated quickly if you want to go beyond minimal/maximal |
| 15:50 | <littledan> | if you have a Realm through the Realm API, then you can either do something like `realm.globalThis.Array`, or `(await realm.import(module { export default Array }).default` |
| 15:51 | <littledan> | or, `realm.globalThis.eval("Array")` |
| 15:51 | <littledan> | those are sort of the three ways to get at things within the context of Realms |
| 15:51 | <littledan> | I imagine they'd all be usable from something like jsdom |
| 15:52 | <littledan> | I imagine this API would work for extensions as well |
| 15:52 | <annevk> | I think the question was in response to my suggestion |
| 15:52 | <littledan> | oops |
| 15:53 | <littledan> | annevk: I could see going this minimalist route, but I don't know if everyone would be convinced that we can exclude Web APIs from the minimal set |
| 15:54 | <littledan> | it seemed like there was particular interest in including a separate copy of Web APIs by default; maybe I misunderstood |
| 15:54 | <annevk> | littledan: I'm not aware of all the sides here, but I think Domenic's point was that it was jarring that TextEncoder would not be there, but i18n APIs would be, for instance |
| 15:55 | <annevk> | littledan: similar to atob() vs encodeURI() |
| 15:55 | <littledan> | sure, I can see that point. I think it would also be *slightly* faster to create a Realm if there is less in it |
| 15:55 | <annevk> | littledan: I imagine if there was something more principled, such as all features needed for parsing, that objection would fade, but who knows |
| 15:57 | <annevk> | Mark would prolly appreciate not having Date in there |
| 15:59 | <littledan> | there's a lot of APIs to consider. It's an interesting thing to think through, where the line should go |
| 16:00 | <littledan> | I can think of a bunch of different reasonable policies |
| 16:00 | <littledan> | One possible dividing line would be, "does this do I/O", but that is also vague |
| 16:07 | <andreubotella> | either way, having a subset of the web APIs available in a realm would mean creating a new global from the point of view of WebIDL's "Exposed" attribute |
| 16:08 | <littledan> | Yes, it seems straightforward from that perspective |
| 22:39 | <MikeSmith> | TabAtkins: about ::file-selector-button, do you know if there’s a reason the spec update for it has not been made yet? |
| 22:39 | <MikeSmith> | https://github.com/w3c/csswg-drafts/issues/5049#issuecomment-729255718 |