Cascading Style Sheets (CSS) Working Group Teleconference -- 24 Jan 2018

<scribe> scribenick: dael

<smfr> 🎁+

<smfr> who’s the heavy breather

astearns: Let's get going.
... There are a couple added. FPWD for Grid 2 and discussion about banner on drafts.
... Anything else to add?

<fantasai> related to FPWD is https://github.com/w3c/csswg-drafts/issues/1116

Rossen_: I wanted to add if we have time to ask on the padding and margin % issue for grid and flex. If not we can discuss next week.

astearns: Let's do that after fxtf priority issues.

Rossen_: That's fine.

[unminuted topic]

<dauwhe> +1 to static banner

<alex_antennahouse> +1 static banner or removal

<Rossen_> +1 static banner

<fantasai> particularly the overlay state persists per day

<tantek> +1 ok with either, happy to go with rest of group consensus

Grid L2 FPWD

astearns: We have content thanks to fantasai . A bit of the subgrid prop.

<Vlad> +1 to static banner, +1 if it can be made dismissable

fantasai: Grid 2 prop has had the subgrid text that was removed for 1 and per axis sub grid. I've added a diff against grid. I've integrated the duel axis proposal into the main body. THat's what in the draft.

<fantasai> https://drafts.csswg.org/css-grid-2/#alignment

fantasai: There's a 2nd section that's aspect ratio controlled gutters. HIghly desired. When you have justify content settin gyoru gaps to take whatever is left you want the same amount of gap in the other axis, but there's no way to say that. THis prop add a number to align-content adjust where you can take what is in the other axis.
... Do we want this also in fpwd?

Chris: [missed]
... If we can get the stuff into fpwd that's good because we get patient out because elsewise we have to wait until CR> I prefer as much as possible in fpwd.

Rossen_: I haven't had a chance to review the stuff that came out of grid 1. This isn't an ED yet. I think we should do ED first and then do FPWD. I'd prefer first level doesn't have added, at least not until we can review.
... I would support fpwd in the form we agreed on in Tokyo. I'd be fine with that. Then if we need to add anything else we can do that.

astearns: It is an ED in our repo and it is in grid 2

<Chris> fair enough, if there is not consensus on a feature it should not be in the fpwd

<Rossen_> https://drafts.csswg.org/css-grid-2/

Rossen_: I'm looking at the one in css drafts ^

fantasai: What we have is an outstanding resolution to publish subgrid as fpwd with the per axis proposal in as an issue. Only Q is do we want the gutter stuff as well.

Rossen_: And that's what I was commenting on.

astearns: You'd prefer not gutter?

<tantek> +1 to including the gutter stuff

Rossen_: Not in first public.
... Or at least we'll need time to review and go from there.

fantasai: That's fine.

Rossen_: I haven't had a chance to review.

<rachelandrew> +1 to include the gutter stuff

astearns: Chris point is reviewing and getting commitement at fpwd is preferable to putting in later and only getting legal at CR

Rossen_: Yes and to do that we have to reivew.

fantasai: We can come back next week if that's easier.

Rossen_: Sure. I cannot vote yes right now today.

tantek: Understandable

<Chris> rossen, how long to review (a week, a month ...)

astearns: To complicate things I'd like the styling grid area stuff in too.

fantasai: I would too but that's much more complicated. WE should continue to work, but until there's a solid proposal...this stuff is a lot more ready to go. There isn't a whole lot here and it could go quickly. Subgrid is the #1 thing we need to fix. It's needed and an a11y issue.

<Chris> to clarify, if we don't have consensus on features I am fine with a fpwd without them.

fantasai: Then for the styling I would want to work on that but it involves pseudo elements and more interactions and there isn't a solid prop. THerefore I don't think it should go in here, it would hold everything else up.
... If there's a solid proposal i"m happy, but I want to get subgrid to CR in 6 months.

<Chris> alan +1

astearns: I have no heard anyone is actively working on impl subgrid. So taking it to CR without impl starting is premature. If I'm wrong, I'd be happy.

Rossen_: There will be a lot more interest from impl on subgrid to address all the issues fantasai raised, esp. a11y where the styling is just another feature.

tantek: First, I'm okay waiting a week if that's enough time for Rossen_. Rossen_ is that enough time to come up with obj.?
... THat's what I understood.
... Second: A lot of the feedback that caused us to move subgrid out was from Moz so you can count that as impl interest.
... Once we have fpwd the momentum will build and I"m hoping for additional impl interest

astearns: Let's take a week to allow Rossen_ and others to review and do fpwd next week.

[css-fonts-3] Default feature list should not require a list of features to turn on

github: https://github.com/w3c/csswg-drafts/issues/1267

myles: I closed the issue no change.

Chris: Okay, because an hour ago I was arguing osx was wrong.

myles: We can take it offline, but no change.

Update WebIDL definition(s) to use new mixin syntax

github: https://github.com/w3c/fxtf-drafts/issues/233

astearns: First is webIDL defintions?

<krit> https://www.w3.org/TR/geometry-1/#DOMRectList

krit: Yes and this is geometry interface modal. It doesn't have an active editor. The spec removed the no interface term and therefore all interfaces need updating. Usually no interface was used for mixins.
... In the future authors should always use sequences of DOM. THe question is why it's a no interface in the first place. THe suggestion was to remove the object.
... Done in FF already.
... My guess is we didn't want JS to create new DOM rec lists with this.

<Chris> sounds good to me

krit: Web IDL pointed out it should be safe to remove it. I'm asking for approval to change the spec and remove the no interface object from the spec.

<frremy> sounds good to me

astearns: Obj/comments to removing no interface object?

Chris: sgtm

<Rossen_> +1

RESOLUTION: Remove no itnerface object from geometry interface

[filter-effects] blur() to take two parameters

github: https://github.com/w3c/fxtf-drafts/issues/229

krit: Currently takes one arguement, prop is to take 2 so you can blur in horiz and veritical with a different setting. I think this is good, but browsers don't impl. Move to level 2 or are browsers interested?
... I propose moving it to L2.

Chris: Agree. Since they all do 1 param it's better to move it and get impl interest first.

smfr: I agree. For webkit I'm happy to impl it in L2.

krit: Maybe we can also reolve to put it into L2?

astearns: Do we have a L2?

krit: Yes.

astearns: Great.
... Obj to adding a second param to blur() in L2 of filter-effects?

Rossen_: What was the only impl?

krit: There is none. It's a proposal from a dev.

Rossen_: Okay.

dbaron: One thing to do is if it's in L2 to point out it's the new feature in a list that's elsewise the same.

krit: It's already a diff spec so yes.

RESOLUTION: add a second param to blur() in L2 of filter-effects

[css-masking] Add mask-position-{x,y}

github: https://github.com/w3c/fxtf-drafts/issues/103

krit: One prop atm. There was a proposal to add -x and -y. It's in webkit, I believe. Request was to spec. We agreed to algn as much as possible to background spec. If background won't do position-x and -y then mask won't. Same for mask-repeat.

fantasai: Background-position-x and -y is in L4 which isn't fpwd but it was resolved to add.

krit: and repeat?

fantasai: I don't think so.

krit: Then since this is CR it's prob. best not to add yet.

<Chris> agree, better not to add them *yet*

fantasai: I think we had a discussion about repeat and we weren't going to add unless required for compat since there wasn't a use case.

<Chris> yeah it is more alignment between masking and backgrounds

krit: My concern isn't them having it, but how we handle for masking spec. Since the spec is in CR I don't want to add features that aren't in L4.

fantasai: I would agree. Adding mask-position-x and -y to L2 might make sense. L1 should stay.

krit: We don't have a L2 yet. Should we wait or create the L2 already and put the properties in there?

astearns: I have a question about background-position-x/y. Have blink and webkit already impl it?

krit: as far as I know yes. For mask it was a webkit prefix.

astearns: Right.
... For myself I would like to have a next level of masking with these features since mask-position-x/y is in a couple engines and maybe a third.

krit: THen we need to resolve to have level 2 and then move it.

astearns: I think first step is have a resolution to put it into the next level. Once an ED has these features we can have another call.

<Chris> +1 to ED

krit: I wasn't asking for fpwd, just an ED for L2.

<AmeliaBR> +1 to having a level 2 of Masking

astearns: Fair.
... Any objections to creating an ED for Masking L2?

RESOLUTION: create an ED for Masking L2?

astearns: Obj to putting mask-position-x/y into that draft?

RESOLUTION: put mask-position-x/y into that draft

[filter-effects] Make grayscale() work without parameters

github: https://github.com/w3c/fxtf-drafts/issues/1

AmeliaBR: The shorthand functions as currently defined all have required parameters. For the one prompting this, though it applies to a few, to get a grayscale filter you have to say 100%, That wasn't how it worked in webkit prefixed and when I checked it last June even without hte prefix safari & chrome support a number of functions without param
... Confusing part is the way the functions are defined in some there is an obvious do this all the way, like gray scale 100% is all the way gray scale. Other functions have two possible directions. You can make something lighter or darker. For those 100% is no effect.
... That's the baseline and you need more or less than 100%.

<Chris> Agree with AmeliaBR grayscale() equivalent to grayscale(100%) and same for sepia and invert

AmeliaBR: I think that's why this spec was defined as it was. For the effects like grayscale where there is a clear apply this completely it's a nice author convenience to not have the 100% on greyscale. We also have existing differences in impl.

krit: I'd like to add webkit and blink do support none arguments for everything except drop shadow. It's convenient to have no argument for some fucntions. The toher kinds of functions if you don't specify it's no effect. If there's no value for opacity you don't get opacity
... Do we agree sepia, grayscale and intvert don't need a scale and would result in complete change. And if yes do we want the others to not require a param is that no effect?

Chris: It seems obvious that if there's no param it does the obvious thing. Only down side is the knock on items for interpolation. It's not clear that's been sorted, but if we can do that yes.

AmeliaBR: I've never tested safari and chrome for transitions. I'm assuming they treat greyscale no param as 100%. There would be text about serialization.

leaverou: I would agree to sensible defaults. I seem to recall being confused on grayscale no param, but I jsut tried it on chrome so perhaps it's been fixed.

krit: Also possible to keep as is on L1 and think about good options for L2.
... To chris we think about different initial for normal and interpolation so differing between two initial values is fine.

smfr: I'd prefer we spec L1 in terms of what browsers impl. So I'm fine having no arguments in L1. I don't htink animations would be a problem, so I don't see anything tricky there.

<fantasai> +1 to smfr

krit: Only webkit and blink support without arguments with the exception of drop shadow.

smfr: But if spec requires arguments there's compat issues. It seems harmless to allow no arguments then require and later on allow optional.

fantasai: I would agree we should allow no argument where there is an obvious default. I'm less convinced for all the others.

AmeliaBR: I think it would be best ot resolve soon b/c we do have browser issues. If the end is allow some and not others I'd like to see impl match asap.
... Otherwise...right now the other ones are no effect independantly but if they're in a filter list, like a transition, there's a question as to if that's a valid parsing sequence. You could suddenly break a site so we want to resolve asap.

krit: And it's a Q if safari webkit and blink are willing to change if we change requirements.

smfr: I think that's too much of a compat risk.

krit: In this cas eit makes sense to make arguments optional and we need to decide what happens for those that it's no obvious. Most are no effect. Brightness it will use 0 and I'm not sure that's preferred and if content relies on that.
... smfr would you be willing the change brightness to no effect if ther'es no argument.

smfr: I don't know. I'm not sure if brightness [missed]

AmeliaBR: Logically brightness should behave like contrast or saturate because you can increase and decrease. Brightness 100% is no effect. I'm not sure why no param as 0 was impl.

<fantasai> +1

smfr: I don't feel too strongly. But brightness without arguments doesn't seem common.

krit: Would you change brightness w/o arguements to no effect?

smfr: I think so.

krit: Drop shadow asside we agree we'd have arguments on filter functions be option. specia graysale and invert it would be the complete effect and for the others no effect.

smfr: sgtm

astearns: Obj?

RESOLUTION: Allow filter functions to work without params. Drop shadow aside arguments on filter functions be optional. sepia graysale and invert it would be the opposite and for the others no effect.

astearns: Chris added a needs test case.

krit: Agree

end

astearns: fxtf issues #221 ad #178 need people who understand color to look. Please do.

Issue #2085

<astearns> https://github.com/w3c/csswg-drafts/issues/2085

github: https://github.com/w3c/csswg-drafts/issues/2085

Rossen_: We discussed ~1 month ago. I raised it before we locked down flexbox and grid. I wanted one behvaior for resolving hte block level padding and margins. Current spec allows to resolve those from corrisponding inline or block axis.
... In a little more css2.1 terms top and bottom margins resolve to either height or width. FF and Edge impl that we resolve from the same direction as the padding and margin. Webkit & Blink impl the similar behavior to block. They resolve from width. THat enables the hack to have the aspect ratio on elements other than replaced.

<Rossen_> https://www.bloomberg.com/pursuits/travel

Rossen_: We've gone by for a couple years. Now that grid picking up we're seeing pretty bad compat issues

<Rossen_> https://thepeachtruck.com/blogs/the-peach-truck-kitchen

<Rossen_> https://maps.google.com/localguides/event/summit

Rossen_: here's a couple. If you have FF or Edge you can compare.
... A month ago we left that rachelandrew would write a blog. She did. Thank you.
... We got back quite a bit of opinions. They are kind of split. To summerize about 1/2 the people want to be able to spec on value and expect that padding and margin is the same.

<astearns> lost rossen

<Rossen_> getting back

<fantasai> https://wiki.csswg.org/planning/berlin-2018

fantasai: While we wait. If you're planning to come to Berlin please put yourself on the wiki. If you're interested in air BnB let florian or I know.

Rossen_: I'm back.
... Second part of the group advocated for keeping the behavior symetric
... They basically wer emotivated beuase they don't want to learn the wacky way of resolving against something not the same.
... We are where we are. I listed some of those bad compat issues.
... One other point brought up is at this point there's quite a bit of usage in Chrome so this won't be easy for Chrome to back away unless they want the compat issues we have.
... Given where we are and the community is split I think the better service to the web is align on something which is at least consistant. For that reason I'm going to go and impl this behavior in the next version to Edge, to align to Chrome and Webkit, provided we can resolve to go with that.

<tantek> I thought we were going to give more time for a proposal for the aspect ratio stuff first?

<tantek> so we could eliminate that as an excuse

Rossen_: Last time we chatted TabAtkins was, I believe, also fine with going down to one behavior as long as there's impl interest. I'm committing to changing Edge so the only thing wuld be for FF to catch up.
... But we are not going to continue to put our users through this suboptimal experience.
... So I'm sorry I couldn't hold up for the new comers to CSS. It is what it is. So for UX we'll align with Chrome and Webkit.
... I want to put it back on the WG to resolve on one behavior and I mostly want to hear from FF since they'll be the only ones left with the different behavior.

dbaron: I'd want to hear Mats' comments. I haven't spoken to him on this for a bit.

tantek: I'd like to hear from dholbert as well before FF has an opinion.

Rossen_: I don't mind if we hold back, but at this point we're going to ship to be interop with webkit and blink behavior on our next version.
... So this will put more pressure on your folks. But that doesn't mean you have to agree right now. Please chat.

fantasai: One pattern I saw in the comments is a lot from the group supporting assymetic is that it initially doesn't make sense, but it is more useful more of the time in the end.
... I found that convincing.

<tantek> basically this is about giving in to compat right?

Rossen_: I also found it convincing. But given that everyone can only use that it's hard to argue the opposite.

rachelandrew: From talking to people I htink what you see if existing web dev think it's sensible and new people will find it strange. But I can understand the compat issue.

tantek: Only the oldest behavior...those of us that have been around 15-20 years would say that. Anyone who used positioning or flexbox/grid would see it as weird and different.

rachelandrew: Yeah. I'm jsut telling you what I'm hearing.

<Rossen_> +1 to tantek - this is exactly why I was fighting for so long and hard on the issue

tantek: I want to go on record to say I'm a little disappointed because this is an ex where the WG essentially failed by evidence of we're in a compat issue. It's not the first time, but I wanted to call it out. Every time we resolve to do it some way because a number of browsers do something and then websites depend on it and then we hit a threashold where other browsers are compelled to change.
... I fully sympathize. But this a compat forced change. I don't think this is good for the model.

astearns: I would agree.
... Given that the discussion was evenly split and that we are going in the compat direction it seems this will end up with another switch like box sizing where people can opt into the more sane way.
... We're nearly out oftime. Rossen_ do you want to put your intent in and tag dholbert and Mats?

Rossen_: I will. Iw anted the minutes into the issue before I do it. If we can resolve sooner rathr then later so we can make the spec changes that owuld be great.

tantek: I'd like to call this out as a meta issue for the F2F which is when we don't act on some ambig we spec due to compat. I feel this is the latest data point.

astearns: Can you put it on the F2F agenda?

tantek: Yep.

astearns: Thanks everyone for calling in.

end

<dbaron> regrets for next week from me as well (TAG face-to-face meeting in London)

<tantek> astearns: done: https://wiki.csswg.org/planning/berlin-2018#agenda-items

<astearns> tantek: thanks!

<astearns> trackbot, end meeting

- DRAFT -

Cascading Style Sheets (CSS) Working Group Teleconference

24 Jan 2018

Attendees

Contents