[css-logical-1] flow-relative values should say what their computed values are

[dbaron]

The section on flow-relative values defines a bunch of new values for existing properties. However, it doesn't say how these values influence the computed values of the properties, and I think it should say so explicitly (especially since the properties' existing "Computed Value:" lines may be wrong).

In other words, it needs to be clear whether float: inline-start results in a computed value of inline-start or a computed value of left (or right, depending on writing mode). I tend to think the computed value should be left.

I got here from w3ctag/design-reviews#286.

[Loirooriol]

Note that text-align: start and end compute to themselves and not to left or right.

[Loirooriol]

I implemented float/clear: inline-{start,end} and resize: {block,inline} in Blink (behind a flag) so that they compute to the physical values. Because this matches Firefox and was simpler to implement.

If the opposite behavior is resolved, this WPT will need to be edited: web-platform-tests/wpt#12326

[fantasai]

They should definitely not compute through. As you point out, this would break inherited properties like text-align. It also would mean that the CSSOM privileges physical coordinates over logical ones, which would be unfair.

[css-meeting-bot]

The Working Group just discussed flow-relative values should say what their computed values are, and agreed to the following:

• RESOLVED: the flow relative keyword values compute to themselves, not to physical equivalents

The full IRC log of that discussion

<dael> Topic: flow-relative values should say what their computed values are
<dael> github: https://github.com//issues/2821
<dael> fantasai: This is that the values we spoke about compute to self, not left or right.
<dael> fantasai: This is necessary for text-align property so for consistancy we should do that for all p roperties and if we don't do that CSSOM physical coord won't align
<dael> dbaron: Flip side is that it means anybody looking at computed values to act on them has to do something more complicated. If a web page looks at computed value they need to consider 2x possibilities. They might not and therefore have bugs
<dael> fantasai: Yeah but you have to do for inherited prop s why treat non-inherited differently?
<dael> fantasai: You have to do that on inherited.
<dael> dbaron: Not as strong a case for not inherited ones
<dael> dbaron: [missed] or maybe not
<dbaron> s/[missed]/and I think there are more of them,/
<dael> fantasai: Consistancy and so author can work in logical coord if they want to. Make these computed v alues be what they are and if browser needs to worry it should add convenience to its code before reporting to the user
<dael> dbaron: In the CSSOM
<dbaron> s/In/what about/
<dael> Rossen: I think giving them all the values and having them make the choice what ot use would be better then the result of calc that will mask what value ended up computed and trying to piece that back to the value's origin. Esp. for inherited.
<dael> Rossen: I agree with dbaron it will require a bit more handling on user side but prob not that much
<dael> Rossen: We can always simplify later
<dael> dbaron: okay
<dael> Rossen: Other opinons or try to resolve?
<dael> fantasai: Also nec. if keeping previous resolution
<dael> Rossen: Yes, but we could revert.
<dael> Rossen: Objections to CSSOM exposes both logical and physical values and the resulting values are that of the cascade?
<dael> Rossen: Is that the summary?
<dael> fantasai: What..no. Resolution is that the flow relative keyword values compute to themselves, not to physical equivellents
<dael> Rossen: Objections to this?
<dael> RESOLVED: the flow relative keyword values compute to themselves, not to physical equivalents