- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 14 Nov 2018 18:00:55 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `'overflow' 2-value syntax is in wrong order`. <details><summary>The full IRC log of that discussion</summary> <dael> Topic: 'overflow' 2-value syntax is in wrong order<br> <dael> github: https://github.com/w3c/csswg-drafts/issues/2988<br> <dael> astearns: IRC chat above about it<br> <dael> fantasai: Looks like waiting on majidvp making change in Blink which requires him doing some research<br> <dael> florian: What are we blocked on majidvp for?<br> <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> <dael> TabAtkins: He's an interested impl who understand problem and wants to fix.<br> <dael> florian: He's attempting to do what we spec and if he succeeds that overrules the concerns?<br> <dael> TabAtkins: I believe so. I think only concern is compat so us being happy avoids that<br> <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> <dael> TabAtkins: Yes, that's discussion from TPAC. That's a larger issue that needs to be resolved in sensible way.<br> <dael> TabAtkins: We already have a number of proerties with this problem, so we need to solve for all<br> <dael> emilio: Cannot fix this without figuring out whole thing<br> <dael> TabAtkins: We've already got margin-start and margin-left<br> <dael> emilio: margin shorthand is only physical<br> <dael> TabAtkins: Yes, but need to worry about shorthand intereaction with both. Same thing you've got here.<br> <dael> emilio: It's another level of interaction<br> <dael> TabAtkins: I don't understand how different<br> <dael> florian: Same as having the extra keyword on shorthands to say. We don't have that<br> <dael> TabAtkins: If you set margin and margin-inline-start and ask for margin, we don't know what it should return<br> <dael> emilio: We do<br> <dael> florian: Margin is shorthand of physical only.<br> <dael> fantasai: It's impl that way. If you replace margin with physical shorthands you get corrent. gCS it's mapped across both<br> <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> <dael> TabAtkins: If overflow 2 value is logical and margin is phsyical it's congruint<br> <dael> emilio: When you spec overflow it maps to 4 properties. Overflow shorthand can take different prop<br> <dael> florian: Shorthand to longhand is parse time, but need to parse on computed value<br> <dael> TabAtkins: Way we're talking is it's parse time. Overfloew 2 value expands to logicial long hands.<br> <dael> emilio: But only when in 2 value<br> <dael> TabAtkins: When in 1 doesn't matter<br> <dael> emilio: Does matter because then you need to return something for physical for compat<br> <dbaron> I guess you can't hear me?<br> <dael> TabAtkins: Same problem as margin. Set margin-start and margin below it blows away margin-start<br> <dael> emilio: It's about setting, not getting.<br> <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> <RRSAgent> I have made the request to generate https://www.w3.org/2018/11/14-css-minutes.html tantek<br> <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> <dael> dbaron: If you have overflow-x:visitible and overflow-y:visible overflow-block:visitible and overflow-start:visible what do you get?<br> <RRSAgent> I'm logging. I don't understand 'make minutes public', tantek. Try /msg RRSAgent help<br> <emilio> dbaron++<br> <dael> dbaron: Point isn't what answers are it's that answers aren't obvious in spec now<br> <dael> TabAtkins: So it's legacy behavior running into this. I missed that.<br> <dael> dbaron: I don't think it's legacy. I don't know any impl that has impl both logicila and physical shorthands.<br> <dael> TabAtkins: Blink has logical of block<br> <dael> dbaron: Longahnds, but shorthands aren't mapped. I think that's b/c there's so many spec issues in OM<br> <dbaron> s/call on/call getPropertyValue on/<br> <dael> emilio: Have logical long hands and shorthands, but they only map to logical long hands<br> <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> <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> <dael> TabAtkins: I completely agree let's define that<br> <tantek> regrets+<br> <RRSAgent> I have made the request to generate https://www.w3.org/2018/11/14-css-minutes.html tantek<br> <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