- From: Dael Jackson <daelcss@gmail.com>
- Date: Mon, 13 Feb 2017 20:20:52 -0500
- To: www-style@w3.org
========================================= These are the official CSSWG minutes. Unless you're correcting the minutes, Please respond by starting a new thread with an appropriate subject line. ========================================= Backgrounds ----------- - There was a proposal to remove the 3 value syntax from object-position, transform-origin, perspective-origin, offset-position, mask-position, components of shape functions and radial gradients (basically everything except background-position). - RESOLVED: three-value <position> removed except for background-position - The Chrome team will investigate if repeat-x/y properties can be removed. If not, they may have to be added to the spec ( possibly without logical equivalents). - RESOLVED: Add background-repeat-x/y longhands and mask-repeat-x/y longhands, mark them deprecated, and deal with the shorthand weirdness, possibly like dbaron proposed. Note, this resolution was rescinded in https://lists.w3.org/Archives/Public/www-style/2017Jan/0064.html ===== FULL MINUTES BELOW ====== Agenda: https://wiki.csswg.org/planning/seattle-2017 Backgrounds and Borders ======================= Scribe: zcorpan Background-repeat-x/y and mask-repeat-x/y ----------------------------------------- <smfr> https://github.com/w3c/csswg-drafts/issues/116 and https://github.com/w3c/fxtf-drafts/issues/99 dbaron: Two constraints dbaron: Would not like us to be in a situation where some impls are shipping things and the WG refuses to spec. dbaron: Would like us to have both or neither. They should match each other. Florian: Is there agreement in impl? dbaron: No. dbaron: Some impl have background-repeat-x/y but not mask-repeat-x/y. dbaron: I've written tests. dbaron: Tests with and without -webkit- prefixes <astearns> https://dbaron.org/css/test/2017/background-repeat-x-y <astearns> https://dbaron.org/css/test/2017/mask-repeat-x-y dbaron: Some impl have masking only with -webkit- prefixes. Florian: Does anyone object to having x/y everywhere? fremy: Not if we define serializer. dbaron: We need to treat it as one of the "used to be a longhand that is now a shorthand". dbaron: Background-repeat takes 4 values: repeat | space | round | no-repeat dbaron: -x/y takes 2 values repeat and no-repeat. Florian: Mask should work the same. dbaron: Yes. dbaron: My impression is that those shipping x/y would not like to remove. dbaron: It's above blink's removal threshold. dbaron: Since it exists it's easier to just do it. astearns: There's no reason to cascade independently astearns: but these things exist, so... TabAtkins: Authors have requested them and given use cases for it TabAtkins: using spites. dbaron: background-position-x/y is for that, not -repeat. TabAtkins: Right. but should be consistent. astearns: Argument against? astearns: Summoning fantasai. fantasai: We already put it in the draft. we resolved at tpac. dbaron: Thinking of background-position-x/y? fantasai: oh... yeah astearns: Browsers have repeat-x/y. Should spec them. fantasai: WHYY?? fantasai: Would need logical equivalents for these as well. astearns: Have we added logical props for background-repeat? astearns: Anyone impl? fantasai: No. astearns: So just add x/y. Wait with adding logical. fantasai: We're adding all variants in logical. fantasai: Point in level 4 is to add logical equivalents for everything that was in level 3. i18n has been requesting parity for years. Florian: For the things that had use cases having equivalents make sense. Florian: For things that are just necessary for web compat we might not need logical equivalents. dbaron: If you just have the physical then you can't represent the logical keywords in the subproperties of the shorthand -- even if you have them it's not immediately clear to me how you do it. astearns: Proposal would be to add x/y longhands astearns: for background-repeat. astearns: Shorthand that used to be a longhand. astearns: Is that something that we should resolve on separately or should we combine mask? dbaron: Would prefer to change them together. astearns: Makes sense to me. Florian: Depends on whether we spec this because we really want it or something that should be discouraged. astearns: but there were use cases for sprites. fantasai: But that's just position? fantasai: Use case for repeat? jensimmons: People will discover and find uses. gregwhitworth: Who ships? astearns: Edge and chromium dbaron: See tests above. <rachelandrew> http://csswizardry.com/2016/12/css-shorthand-syntax-considered-an-anti-pattern/ jensimmons: People don't understand how the cascade works. fantasai: By not having these separate things people can more easily stay out of trouble. astearns: Except when it's shipping in half of the engines... dbaron: Blink and webkit myles: Our code *attempts* to make it work... myles: dbaron's examples don't work. dbaron: no-repeat is a correct value per the code? smfr: Lemme check. smfr: Yes. astearns: So... it's only implemented in blink. but usage is high... gregwhitworth: Would like to have better understanding of web compat situation. gregwhitworth: We haven't gotten bugs, and Mozilla hasn't gotten bugs. zcorpan: Removal threshold isn't really just a number, depends on impact. dbaron: If blink folks can look into removing ... zcorpan: If it wouldn't break site, could remove something with higher use. tantek: Exposed in the DOM? smfr: Unclear. dbaron: This doesn't do anything when you specify it... Florian: TabAtkins do you object to removing? TabAtkins: I'm not going to remove them myself. Florian: Can you find out if it's removable. dbaron: My worry is that we will discuss this every 2 years until we have a compat problem jensimmons: Is it really a compat problem if only one impl has it? tantek: ya shane: We will look into whether it can be removed. fantasai: So this is under investigation... shane: Feature detection doesn't look at serialization astearns: So moving along. <RachelNabors> Background repeat example: https://codepen.io/rachelnabors/pen/AvGhp <RachelNabors> Line 55 of CSS RachelNabors: The example shows me using background-repeat-x RachelNabors: I found out later that it didn't work in Firefox when a student pointed it out to me RachelNabors: but it sounded natural at the time. 3-value <position> ------------------ fantasai: There was an issue in transforms about transform-origin should accept position syntax that is in background. fantasai: One problem is L3 syntax for position has 2 value syntax and 3 value syntax and 4 value syntax. fantasai: 3 is a degenerate form of 4. fantasai: You can't unambiguously parse transform-origin because it has an extra value for z. fantasai: One idea is how often do we need the 3 value syntax? not useful in most cases. fantasai: Likely can't remove for background-position fantasai: but for other cases we can disallow 3 value. fantasai: Would allow us to be consistent. smfr: So could have a 5 argument value astearns: I would be in favor. astearns: Also remove from shape functions. TabAtkins: Yes. Kill it. fantasai: I'd take this from V&U spec where it's defined as ???. fantasai: Everyone is referencing V&U. astearns: Argument against... if anyone is using 3 value syntax they will be confused if it doesn't work Scribe: fantasai astearns: Need to figure out where / how common it's being used. zcorpan: I can check httparchive. smfr: So you're saying we'd preserve the 3-value syntax for background-position, but not anywhere else? smfr: I think we've shipped it, but didn't use the same parsing in transforms. smfr: So should be fine. smfr: Would actually allow us to share more parsing code, and make Transforms spec easier. smfr: Which properties? fantasai: Properties affected would be object-position, transform-origin, perspective-origin, offset-position, mask-position astearns: And some components of shape functions. fantasai: And radial gradients. astearns: *if* we can get usage numbers, some of these might have to go with <'background-position'> and be grandfathered in. fantasai: Yeah. astearns: How about we take a break, come back and resolve on this, then go on to next thing. <br duration=15min> Scribe: fremy <zcorpan> data from httparchive - https://gist.github.com/zcorpan/55646974aa7b8202f38bcf6f8fa9f9a0 - 37 resources (out of ~500,000 pages) using 3 value syntax in background-position <fantasai> zcorpan, https://www.w3.org/TR/css-images/#radial-gradients and object-position <zcorpan> 0 results for radial-gradient - SELECT page, url, REGEXP_EXTRACT(LOWER(body), r'(\bradial-gradient\((?:[^\) a]+|a[^t\)])at\s(?:\d+(?:\.\d+)(?:[ a-z]+)|top|left|bottom|right)\s+(?:\d+(?:\.\d+)(?:[ a-z]+)|top|left|bottom|right)\s+(?:\d+(?:\.\d+)(?:[ a-z]+)|top|left|bottom|right)\s*,[^\)]+\))') AS match <zcorpan> 0 results for object-position fantasai: object-position isn't used very often. fantasai: So the proportion of 3-values there is not very relevant. astearns: Proposed resolution is to drop the 3-values except for background-position. fantasai: Because that creates an ambiguity otherwise. fantasai: transform-origin: x y z fantasai: but this cannot be a position because position currently allows three values. fantasai: If <position> does not accept an odd number of values (3), then transform-origin will always be unambiguous fantasai: and transform-origin would start accepting 4+1 values. fantasai: background-position needs legacy support though. astearns: What about one value? fantasai: In case of doubt, second is y not the next value Bert: Do not like it, but not really want to object. astearns: Any objection? [no objection] RESOLVED: three-value <position> removed except for background-position background-repeat-x/-y ---------------------- shane: We had a resolution to add in 2013. shane: Usage was low then. shane: It no longer is. <astearns> https://bugs.chromium.org/p/chromium/issues/detail?id=376179 <astearns> old resolution: https://lists.w3.org/Archives/Public/www-style/2014Apr/0188.html shane: Removing them now would be hard. shane: Tab convinced me that there would be breakage if we removed. shane: I think we're stuck with them in Blink, so they should be speced and others should implement. astearns: We can add them as legacy things without adding the logical version and the mask-repeat version astearns: or we can add everything astearns: or we can throw our hands up in the air and punt. <tantek> did anyone mention deprecation as an option? astearns: fantasai, you used to be for it... fantasai: I don't remember. <dbaron> quoting from those April 2014 minutes: <dbaron> > fantasai: I'm okay if we add logical keywords at the same time so we can make sure they work out correctly. * fantasai thinks that sounds like reluctant acquiescence fremy: I am not sure why we removed from our implementation. tantek: astearns's first option should use the word deprecation. Florian: Can we make logical direction keywords work with the -x and -y longhands <dauwhe> background-position: repeat(x + iy) astearns: I don't think it would be hard dbaron: Shorthands don't store things dbaron: but we could store "repeat-block" in both -x and -y. dbaron: You can store the repeat-block on both background-repeat-x and -y, and it means either repeat or no-repeat based on the directionality. fremy: Can we punt? shane: It doesn't help. tantek: Agreed. astearns: Straw poll: option 1: just add -x and -y deprecated, or option 2: add everything: logical longhands, and mask dbaron: option 3: add -x and -y deprecated and add to mask as well dbaron: In our case the implementation is shared, so I would really like to keep them the same. shane: I'd be ok with having -x and -y on mask. astearns: Poll is between option 2 and 3, option 1 is excluded Option 2: Add background-repeat-x/y and logical longhands and mask. Option 3: Add background-repeat-x/y, mark deprecated, and add to mask. <dbaron> seems like about 9 in favor of option 3, and 0 in favor of option 2 <Rossen> ... and many abstained astearns: Proposed resolution is to add background-repeat-x/y longhands and mask-repeat-x/y longhands, mark them deprecated, and deal with the shorthand weirdness, possibly like dbaron proposed RESOLVED: Add background-repeat-x/y longhands and mask-repeat-x/y longhands, mark them deprecated, and deal with the shorthand weirdness, possibly like dbaron proposed.<div id="DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2"><br /> <table style="border-top: 1px solid #D3D4DE;"> <tr> <td style="width: 55px; padding-top: 13px;"><a href="https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=icon" target="_blank"><img src="https://ipmcdn.avast.com/images/icons/icon-envelope-tick-round-orange-animated-no-repeat-v1.gif" width="46" height="29" style="width: 46px; height: 29px;" /></a></td> <td style="width: 470px; padding-top: 12px; color: #41424e; font-size: 13px; font-family: Arial, Helvetica, sans-serif; line-height: 18px;">Virus-free. <a href="https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=link" target="_blank" style="color: #4453ea;">www.avast.com</a> </td> </tr> </table><a href="#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2" width="1" height="1"></a></div>
Received on Tuesday, 14 February 2017 01:21:58 UTC