- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Thu, 25 Oct 2018 10:06:04 +0000
- To: public-houdini-archive@w3.org
The Houdini Task Force just discussed `Layout precision`. <details><summary>The full IRC log of that discussion</summary> <TabAtkins> Topic: Layout precision<br> <heycam> github: https://github.com/w3c/css-houdini-drafts/issues/817<br> <TabAtkins> github: https://github.com/w3c/css-houdini-drafts/issues/830<br> <heycam> iank_: I wanted to write down the problem clearly<br> <heycam> ... as specced now, with availableInlineSize: 10.13, the internal representations in each engine will be different<br> <heycam> ... I believe Blink/WebKit will be 10.125, Gecko will be 10.133, Edge will be 10.13<br> <heycam> ... similarly, say that child is auto sized, the value that you will get out in JS will be 10.125 for Blink/WebKit, some ugly values near 10.33333 for the others<br> <heycam> iank_: this is exposed right now<br> <heycam> ... if you set width:10.13px on an element, and you call getClientRects, you will get similar issues<br> <dbaron> Some of the ugliness is something that we could fix (by going directly from fixed-point to double rather than fixed-point to float to double)<br> <heycam> ... part of me thinks this is a non-issue<br> <heycam> iank_: the thing I worry about with rounding is that you'll get potential tearing<br> <glazou> LEAVEROU !!!<br> <heycam> ... imagine if you're doing a flexbox-like thing<br> <heycam> ... where you're distributing available space between children<br> <heycam> ... with the current API you won't get any subpixel tear, but if you round inputs and outputs you will<br> <heycam> ... you'll have to define the whole layout tree working on rounded precision mode<br> <heycam> eae: when you say rounding, you mean rounding to ints or to these values?<br> <heycam> iank_: if you round to int values, going in and out of the engine, you might see tearing<br> <heycam> ... if you're distributing some fractional space in a flexbox-like thing you can't do that<br> <heycam> ... also you'd need to specify the whole subtree works in rounded int precision<br> <heycam> smfr: what do you mean by tearing?<br> <heycam> iank_: if you try to position the two fragments side by side, you'd get a gap<br> <heycam> ... similarly, the second class there is if you happen to be distribtuing some space that wouldn't get a gap, the element might be smaller<br> <heycam> bz: to be clear, the container being smaller than the elements is a problem anyway<br> <heycam> ... even with floats<br> <heycam> iank_: the conversion to the js float thing, it's still possible to get tears accidentally<br> <heycam> ... but because the JS repr is high enough, converting from the internal fractional to JS to the internal fractional will result in the same fractional value<br> <heycam> chrishtr: what about pixel snapping?<br> <heycam> iank_: we only do that at paint<br> <heycam> ... we don't pixel snap any of the layout<br> <heycam> TabAtkins: yes we do<br> <heycam> ... border widths e.g.<br> <heycam> eae: borders are very special<br> <heycam> emilio: device pixels<br> <heycam> dbaron: there's a small class of things where you care about the with of the thing being the same across repeated occurrences<br> <heycam> ... borders, column rules, probably line heights as well<br> <heycam> ... but for most other things we don't do internal snapping<br> <heycam> ... you round to internal repr then snap edges to the nearest pixels<br> <heycam> iank_: the pixel snapping borders we can repr that value in the LayoutEdges object<br> <heycam> bz: presumably this is snapped to dev pixels here<br> <heycam> iank_: yes<br> <heycam> chrishtr: Blink currently snaps to CSS px<br> <heycam> eae: not really<br> <heycam> chrishtr: in cases where the device pixel ratio is incorporated into zoom it's device pixels<br> <heycam> ... long term intention is to use device pixels<br> <heycam> smfr: someone mentioned pixel snapping in border would happen at layout time? isn't purely a paint time operation?<br> <heycam> dbaron: for us it's a computed value time thing<br> <heycam> Rossen: for us it's also style<br> <heycam> ... it matters for lower values, 1, 2, 3, px<br> <heycam> ... but over 13, 14px it doesn't really matter<br> <heycam> dbaron: but it does matter for not getting the 1px gaps that you do the snapping before the layout calcs based on it<br> <heycam> ... if you do layout calcs based on a non pixel snapped border, then snap it later, you'll sometimes get 1px gaps or overlaps<br> <heycam> Rossen: so we'll do the layout with fractional border sizes<br> <heycam> ... then snap during paint<br> <heycam> dbaron: but you need to snap all the things next to that border during paint too or they won't line up<br> <heycam> Rossen: no they won't<br> <heycam> dbaron: then your system is more complex then ours<br> <dbaron> s/more complex then ours/different in more complex ways from ours/<br> <heycam> chrishtr: is the intention to spec the rounding?<br> <heycam> iank_: no<br> <heycam> chrishtr: or just things that UAs may do?<br> <heycam> iank_: my preference is to allow the UA to do internal rounding to the fractional repr and back<br> <heycam> ... main thing I want to avoid is the 1px tearing in alyouts<br> <heycam> chrishtr: it should at least be said if the left/right edge of things are the same number, there should not be a tear<br> <heycam> eae: can probably find a way to spec that<br> <heycam> chrishtr: you'd have to say the rounding and layout is the same, and that pixel snapping at paint time preserves that consistency<br> <heycam> iank_: yep<br> <heycam> Rossen: does that work for you Simon?<br> <heycam> smfr: yes I think so<br> <heycam> ... WebKit does some snapping of border widths as well<br> <heycam> ... I'm trying to understand when you're laying out fragments iteratively, does the browser tell you how much space is left? a floating point input<br> <heycam> ... with custom layout, call layoutnextfragment 3 times<br> <heycam> ... each time an input is the remaining space?<br> <heycam> iank_: no you need to do that yourself<br> <heycam> ... so you'll have some available size, layout first child, subtract the size of it in the JS double<br> <heycam> smfr: was concerned about the conversions between jS doubles and the quantized values internally<br> <heycam> iank_: since it's handled by script it's always the JS doubles<br> <heycam> smfr: trying to think of cases where the rounding woul hurt you<br> <heycam> ... maybe comvining custom paint and layout<br> <heycam> ... you ask for a certain with with double precision<br> <heycam> ... then in paint ...<br> <heycam> iank_: I think previously you've brought up trying to fit into the one fractional unit, and some engines will leave a tiny fractional unit over<br> <heycam> ... in one you go into the next line, in another you'll have a skinny box for some reason<br> <heycam> ... I think it's a super edge case<br> <heycam> fremy: my impression is that the only case where this could be an issue is where you do the data sharing between custom layout<br> <heycam> ... you could share with full precision, and on the other side of the API you'd get it<br> <heycam> ... but I also don't expect this to be a problem<br> <TabAtkins> Found that the internal->JS->internal conversion is always accurate up to (10^15)px; at 10^16 there's a few rounding errors with Microsoft's precision.<br> <TabAtkins> http://software.hixie.ch/utilities/js/live-dom-viewer/saved/6318<br> <heycam> smfr: as a data point, this same problem also happens in media timing values<br> <heycam> ... currently they're all floating point, but there've been discussions about turning them into a rational type<br> <heycam> ... they're trying to solve some similar way here<br> <heycam> iank_: I think there's been talk in JS previously about having value types<br> <heycam> TabAtkins: they're not ready yet<br> <heycam> iank_: they've been vapourware for a while<br> <heycam> ... but the intention would be to work in that fractional type<br> <heycam> ... we shouldn't depend on that<br> <heycam> ... could imaging a future where JS does get that fractional type, see if it's compatible to change to that<br> <heycam> ... or otherwise add an option to opt in to it<br> <heycam> fremy: this transformation is a rounding<br> <heycam> iank_: it's a rounding to the fracctional repr<br> <heycam> fremy: can we floor rather thatn round?<br> <heycam> ... otherwise if you divide by 7, all your 7 column objects, you give them avail size / 7<br> <heycam> ... then you have a layout where each gets the size they can. if each is rounded up, the sum will be bigger than 100% and you'll wrap<br> <heycam> ... better to floor<br> <heycam> ... you make sure the sum will all fit<br> <heycam> TabAtkins: flooring starts loosing this internal -> JS double -> internal relationship more quickly<br> <heycam> eae: you can have a situation where you have a lot of space at the end<br> <heycam> ... which is also not desirable<br> <heycam> fremy: people writing the layout will pay attention to this<br> <heycam> smfr: has anyone tried using the prototpye to see if it's a problem?<br> <heycam> fremy: the prototype is only in one browser<br> <heycam> smfr: still possible to make layouts with hairline gaps<br> <heycam> fremy: I've not tried but I guess it's possible<br> <heycam> iank_: we can see if people run into it<br> <heycam> ... so far surmar and fremy haven't run into it<br> <heycam> smfr: your masonry layout wasn't trying to fit something into something with a border, not obvious there's a gap<br> <heycam> iank_: we can experiment with prototypes with borders to see if we can get hairline gaps<br> <heycam> fremy: grid has the opportunity to ahve these options, but you can position things at particular points, no wrapping<br> <heycam> ... even with 7 column grids, you place them before sizing, so it doesn't matter<br> <heycam> ... we should try the flexbox-like thing<br> <heycam> iank_: I think the action item on us is to play with our impl to see if we can break<br> <heycam> ... but sounds like people are relatively fine with the float repr and rounding to fractional units internally<br> <heycam> ... we can report back to the group<br> <TabAtkins> <br dur=1hr><br> <heycam> github: end topic<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/830#issuecomment-432992989 using your GitHub account
Received on Thursday, 25 October 2018 10:06:07 UTC