- 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