W3C home > Mailing lists > Public > www-style@w3.org > February 2017

[CSSWG] Minutes Seattle F2F 2017-01-11 Part V: Backgrounds

From: Dael Jackson <daelcss@gmail.com>
Date: Mon, 13 Feb 2017 20:20:52 -0500
Message-ID: <CADhPm3shyhGhZgUd_kQ4FE8S6ns93GuZ5EW-xvfORXa11bp8bg@mail.gmail.com>
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.


  - 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
  - RESOLVED: three-value <position> removed except for

  - 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


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
  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

  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 |
  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
  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
  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.

  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

  gregwhitworth: Would like to have better understanding of web
                 compat situation.
  gregwhitworth: We haven't gotten bugs, and Mozilla hasn't gotten
  zcorpan: Removal threshold isn't really just a number, depends on
  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:
  <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
  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,
  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
  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 -
            - 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-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
  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


  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:
  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;">
        <td style="width: 55px; padding-top: 13px;"><a
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
target="_blank" style="color: #4453ea;">www.avast.com</a>
</table><a href="#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2" width="1"
Received on Tuesday, 14 February 2017 01:21:58 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:52:56 UTC