Re: [csswg-drafts] [css-overflow-3] 'overflow' 2-value syntax is in wrong order

The CSS Working Group just discussed `'overflow' 2-value syntax is in wrong order`.

<details><summary>The full IRC log of that discussion</summary>
&lt;dael> Topic: 'overflow' 2-value syntax is in wrong order<br>
&lt;dael> github: https://github.com/w3c/csswg-drafts/issues/2988<br>
&lt;dael> astearns: IRC chat above about it<br>
&lt;dael> fantasai: Looks like waiting on majidvp making change in Blink which requires him doing some research<br>
&lt;dael> florian: What are we blocked on majidvp for?<br>
&lt;astearns> majidvp> fantasai: no new update. I have not had a chance to work on this since last update. My next step was to look at the mobile data from httparchive. Pending that does not raise a red flag we can try to fix this in Blink.<br>
&lt;dael> TabAtkins: He's an interested impl who understand problem and wants to fix.<br>
&lt;dael> florian: He's attempting to do what we spec and if he succeeds that overrules the concerns?<br>
&lt;dael> TabAtkins: I believe so. I think only concern is compat so us being happy avoids that<br>
&lt;dael> emilio: Compat concern, but also shorthands that expand to multiple longhands. Don't know if Blink plans to impl, but need to do more off spec work.<br>
&lt;dael> TabAtkins: Yes, that's discussion from TPAC. That's a larger issue that needs to be resolved in sensible way.<br>
&lt;dael> TabAtkins: We already have a number of proerties with this problem, so we need to solve for all<br>
&lt;dael> emilio: Cannot fix this without figuring out whole thing<br>
&lt;dael> TabAtkins: We've already got margin-start and margin-left<br>
&lt;dael> emilio: margin shorthand is only physical<br>
&lt;dael> TabAtkins: Yes, but need to worry about shorthand intereaction with both. Same thing you've got here.<br>
&lt;dael> emilio: It's another level of interaction<br>
&lt;dael> TabAtkins: I don't understand how different<br>
&lt;dael> florian: Same as having the extra keyword on shorthands to say. We don't have that<br>
&lt;dael> TabAtkins: If you set margin and margin-inline-start and ask for margin, we don't know what it should return<br>
&lt;dael> emilio: We do<br>
&lt;dael> florian: Margin is shorthand of physical only.<br>
&lt;dael> fantasai: It's impl that way. If you replace margin with physical shorthands you get corrent. gCS it's mapped across both<br>
&lt;dael> emilio: gCS is different b/c knows writing mode. Issue is specified style. This would be a case where there is no answer<br>
&lt;dael> TabAtkins: If overflow 2 value is logical and margin is phsyical it's congruint<br>
&lt;dael> emilio: When you spec overflow it maps to 4 properties. Overflow shorthand can take different prop<br>
&lt;dael> florian: Shorthand to longhand is parse time, but need to parse on computed value<br>
&lt;dael> TabAtkins: Way we're talking is it's parse time. Overfloew 2 value expands to logicial long hands.<br>
&lt;dael> emilio: But only when in 2 value<br>
&lt;dael> TabAtkins: When in 1 doesn't matter<br>
&lt;dael> emilio: Does matter because then you need to return something for physical for compat<br>
&lt;dbaron> I guess you can't hear me?<br>
&lt;dael> TabAtkins: Same problem as margin. Set margin-start and margin below it blows away margin-start<br>
&lt;dael> emilio: It's about setting, not getting.<br>
&lt;dael> emilio: I filed a bunch of issues about serialization not round tripping. I'm pretty sure a shorthand that expands to multiple prop is a new problem<br>
&lt;RRSAgent> I have made the request to generate https://www.w3.org/2018/11/14-css-minutes.html tantek<br>
&lt;dael> dbaron: Example of something where behavior now isn't spec: If we assume that we haven't intro logical. If stylesheet says overflow-x:visitible and overflow-y:visible if you call on overflow you get visible<br>
&lt;dael> dbaron: If you have overflow-x:visitible and overflow-y:visible overflow-block:visitible and overflow-start:visible what do you get?<br>
&lt;RRSAgent> I'm logging. I don't understand 'make minutes public', tantek.  Try /msg RRSAgent help<br>
&lt;emilio> dbaron++<br>
&lt;dael> dbaron: Point isn't what answers are it's that answers aren't obvious in spec now<br>
&lt;dael> TabAtkins: So it's legacy behavior running into this. I missed that.<br>
&lt;dael> dbaron: I don't think it's legacy. I don't know any impl that has impl both logicila and physical shorthands.<br>
&lt;dael> TabAtkins: Blink has logical of block<br>
&lt;dael> dbaron: Longahnds, but shorthands aren't mapped. I think that's b/c there's so many spec issues in OM<br>
&lt;dbaron> s/call on/call getPropertyValue on/<br>
&lt;dael> emilio: Have logical long hands and shorthands, but they only map to logical long hands<br>
&lt;dael> TabAtkins: In cases right now where single property has both logical and physical underneath it only maps...I think we wanted the logical longhand to be ignored from shorthand after<br>
&lt;dael> TabAtkins: While there are legacy issues with overflow in particular, the issue in general applies to all of our logical and physical properties.<br>
&lt;dael> TabAtkins: I completely agree let's define that<br>
&lt;tantek> regrets+<br>
&lt;RRSAgent> I have made the request to generate https://www.w3.org/2018/11/14-css-minutes.html tantek<br>
&lt;dael> florian: majidvp experiment may provide feedback<br>
</details>


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/2988#issuecomment-438758638 using your GitHub account

Received on Wednesday, 14 November 2018 18:01:04 UTC