- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Thu, 25 Oct 2018 09:16:34 +0000
- To: public-houdini-archive@w3.org
The Houdini Task Force just discussed `Resolve values to a px with external information`. <details><summary>The full IRC log of that discussion</summary> <TabAtkins> Topic: Resolve values to a px with external information<br> <TabAtkins> https://github.com/w3c/css-houdini-drafts/issues/798<br> <TabAtkins> github: https://github.com/w3c/css-houdini-drafts/issues/798<br> <heycam> TabAtkins: if all of the units you have in a math value are compatible with pixels e.g. then you can always resolve them to a single px<br> <heycam> ... if you have combinatons of values that aren't directly resolvable, there's no way to resolve them<br> <heycam> ... since the custom layout API works mostly in px values, it would be useful to give people more direct control over how they can simplify them down to px<br> <TabAtkins> https://github.com/w3c/css-houdini-drafts/issues/798#issuecomment-415555133<br> <heycam> ... so we add an options bag to the to and toSum functions<br> <heycam> ... giving extra information for resolving the values<br> <heycam> ... in particular, the element being resolved on (for ems etc.), the property it's on (so font-size can properly resolve to parent element), and what a % should resolve to<br> <heycam> ... going with this explicit % resolution thing to avoid some problems with some properties resolving %s against different sizes<br> <heycam> ... this makes it more explicit with cases like the layout API, where you have an available space, and you can just pass that in rather than finding a property to pretend it's being resolved as<br> <heycam> ... I think that lets us resolve all the units<br> <heycam> ... in particular, a comment further down suggests that we don't have a default value, so if you don't pass an element, resolve like MQs do, with no context<br> <heycam> ... right now, if you call to() without this information and it needs it, it throws<br> <heycam> emilio: the layout API doesn't have access to any element, right?<br> <heycam> TabAtkins: yes<br> <heycam> emilio: can we instead pass what the function depends on explicitly? what's the expected thing if you pass an element to there, I assume you have to do style updates etc.?<br> <heycam> ... what happens if that element's not in the flat tree etc.?<br> <heycam> ... would be nice to be more explicit about which data you're depending on<br> <heycam> ... then people can use the no context thing without having magic<br> <heycam> TabAtkins: there's a lot of information. which font's being used. it's possible to enumerate this<br> <heycam> emilio: instead of getting a font and doing font matching, you may as well .... I guess there's no way to get ex height without script<br> <heycam> TabAtkins: a possibility is to allow you to pass an element, but also enumerate all the things that the various relative units can depend on<br> <heycam> ... and if you don't pass a unit, that's the info you have to work with<br> <heycam> ... and if you use a unit but no way to determine what that is, continue to throw<br> <heycam> emilio: if you need to download fonts to make this work....<br> <heycam> TabAtkins: that's what we have to do<br> <heycam> ... normally you wait for a computed value, which triggers all that<br> <heycam> emilio: that only happens if you actually lay out the element<br> <heycam> TabAtkins: and the assumption here is you are doing something layouty but not with an element<br> <heycam> emilio: let's say you call this function from a layout worklet with a given font<br> <heycam> ... does the layout trigger the font load somewhere?<br> <heycam> TabAtkins: good question<br> <heycam> ... possibly<br> <heycam> emilio: does it do it sync? probably not<br> <heycam> ... you can't make it sync<br> <heycam> TabAtkins: I think then we should remove the element resolver, figure out what relative units we can easily resolve on, e.g. asking for font-size, other font relative ones are a bit hard for now<br> <heycam> ... and then if you try to use an ex unit to px, we just throw<br> <heycam> ... then we can remove the property too<br> <heycam> fremy: if you still want the behavior to pass an element, you can have another element, and ti returns the properties you would fill in<br> <heycam> TabAtkins: one of those dictionaries<br> <heycam> dbaron: I'm not convinced you canremove the property<br> <heycam> ... if you're doing it from the element, you still need to know font-size / line-height behave differently for em and lh units<br> <heycam> TabAtkins: I'm suggesting that just like the 100% line, where you explicitly indicate what the resolves to, you just supply what them resolves to<br> <heycam> ... and then also supply a function that can extract that from an element automatically<br> <heycam> fremy: CSSNumericValue -- is that calc or more stuff?<br> <heycam> TabAtkins: everything<br> <heycam> fremy: can just create a 1em and call to<br> <heycam> emilio: layout API functions could need 1vmax, you need to expose viewport size to those functions<br> <heycam> ... not sure if you want to?<br> <dbaron> The function to extract from an element automatically would need a property.<br> <heycam> iank_: no access to viewport info<br> <heycam> iank_: it's not necessary<br> <heycam> ... the side effect of exposiong that info is that when you resize that viewport, you'd need to call every layout function<br> <heycam> ... since it's a side input<br> <heycam> TabAtkins: this would be an implicity dependency<br> <heycam> ... unless we made it explicit somehow<br> <heycam> fremy: we could add a function in the worklet, before calling it viewport sizes are 0, and only after you can use it...<br> <heycam> TabAtkins: we have a case for later registrationt of dependencies<br> <heycam> iank_: probably you want to do this in the layout registration dictionry<br> <heycam> ... you don't know which global scope you're doing to run it in<br> <heycam> fremy: the other option is to create custom properties that would be 1vmin, etc., type them to be lengths, then you'll get the value<br> <heycam> ... it's a big handwavy but it does work<br> <heycam> iank_: if this becomes a common pattern, in layout options, say that resolve vw/vh against the real thing<br> <heycam> ... but part of the precedent for resolving to 0 is what happens when you set a font-size in an offscreen canvas context, it resolves to 0<br> <heycam> TabAtkins: that's different from how MQs work<br> <heycam> iank_: not saying that's good or bad but that's the precedent<br> <heycam> TabAtkins: I think that's all the feedback I need; I will come back with a more mature proposal in the future<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/css-houdini-drafts/issues/798#issuecomment-432976756 using your GitHub account
Received on Thursday, 25 October 2018 09:16:36 UTC