| 03:36 | <Domenic> |
|
| 03:36 | <Domenic> | If someone introduces an IDL attribute, but also wants to trigger the underlying behavior without script, then they'd have to have it reflect a content attribute with the same name. Is that a good enough "justification" / reason for doing that. |
| 03:37 | <Domenic> | It seems like "wanting to do things that you can do with an IDL attribute, but without JS" is the big motivation for wanting to reflect an IDL attribute? el.setAttribute("foo", ""). With IDL attribute reflection: el.foo = true. |
| 10:34 | <zcorpan> | Thanks for the heads-up! |
| 10:41 | <zcorpan> | Eric Portis (he/him): I think the main issue is when the w and the image's actual width don't match. Let's say in your example "a" actual width is 4 pixels, then the layout width becomes 2px after loading the image, which would cause the next image to load, etc. |
| 10:43 | <zcorpan> | Eric Portis (he/him): a proposed alternative fix iirc was to stop the "loop" after the second load, but based on prior feedback about double downloads I think it's not acceptable to have double downloads even if it only happens sometimes |
| 10:46 | <zcorpan> | Eric Portis (he/him): the other reason is to make it look wrong when not using width/height attributes (or have dimensions with css). Otherwise people might omit dimensions and we would likely double-download in such cases without size containment |
| 10:48 | <zcorpan> | Eric Portis (he/him): I suspect size containment for images will be more annoying, and that's unfortunate but I hope acceptable! |
| 14:20 | <Dominic Farolino> |
This is the part I'm curious about. I just don't really know when you would "need" a content attribute vs just stick with JS API design on the element's IDL interface. If someone says "I want to introduce a new 'attribute' on this element", then they've two options: (1) content attribute with automatic IDL reflection, vs (2) just IDL attribute, for a JS API. I'm not clear on how to provide guidance to select between those two. I would need to ask them a question relating to "If you need/don't need a content attribute" above. So I guess I'd ask "Can this just be a JS API on the element's interface, or do you need it to also be a content attribute". But to "need a content attribute" (i.e., an IDL attribute alone is insufficient) means your design desires to trigger the attribute's behavior without script... I think.. like just from HTML. |
| 14:58 | <annevk> | Dominic Farolino: I think usually it would become pretty clear, pretty fast |
| 15:27 | <Eric Portis (he/him)> | zcorpan: Thanks! The incorrect w attribute thing makes sense; looks like you suggested a fix for exactly that here https://github.com/whatwg/html/issues/9448#issuecomment-1611905790 (damn my memory)... but... seems like containment just felt cleaner from a spec/implementation perspective. An explicit severing of any possible way intrinsic size will or could ever influence layout size. |
| 15:27 | <jarhar> | the current idea as i would like it is to do whats in the explainer here but reuse the select element instead of creating a selectlist element: https://open-ui.org/components/selectlist/ |
| 15:28 | <jarhar> | oh and it seems likely that we will reuse the datalist element instead of creating a listbox element |
| 15:28 | <jarhar> | so basically if you provide a child to a select element, that will be slotted in to the default button and replace it |
| 15:29 | <jarhar> | same with the datalist element replacing the native/default listbox |
| 16:49 | <zcorpan> | Eric Portis (he/him): right. Especially the case where the image's final width depends on the image's intrinsic height seems tricky to make stable without size containment |