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

<scribe> ScribeNick: dael

Rossen_: We'll be starting in a couple minutes

<dbaron> Regrets from me; currently mid-TAG-meeting

Rossen_: I think we have enough people.
... Let's get started.
... As usual I'd like to call for any additional items or changes to make to the agenda.

[css-flexbox][css-grid] Choose a single option for resolving padding and margin percent values of grid/flex items

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

Rossen_: This is back from last week. Spec one option to resolve padding and margins for grid and flex items.
... We discussed last week. I pinged dholbert and Mats on the thread. dholbert responded from Gecko and acknowledged they will change their behavior and they linked to a bug
... That means we can resolve unless there's additional feedback or objections.
... Current prop: both flexbox and grid items top and bottom margin and padding % resolves against the available inline direction.
... Any thoughts? Comments? Objections?

RESOLUTION: Both flexbox and grid items top and bottom margin and padding percent resolves against the available inline direction.

[css-grid-1][css-grid-2] Basic support for "equal gutter" with justify-content on grid items

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

Rossen_: This is, if I recall, the newly added functionality to Grid L2.

fantasai: There is a justify-content prop that takes values to be put inbetween. You can center tracks, space them to the left or right, kinda like flex items. When people have a grid they want to auto-distribute, but have equal spacing in both axes. Right now no way to get that.
... This proposal has a possible value where it means go look at the other direction and use it over here multiplied by a number.

<lajava> yes

Rossen_: Do we have javifernandez?
... I see they've made comments on the issue.

<lajava> rego and me are attending from igalia

Rossen_: I read through them. Seems there could be ambig as to how this could be helpful.

fantasai: What proposal does is what was requested. I'm happy to entertain other syntatic options, but we should solve the problem. What happens in each case should be worked through. Stretch shouldn't be allowed in combo.

Rossen_: And from your proposed solutions you had 2 options. 1 to introduce a new syntax and the other was define what happens if axis is auto size and space is justified instead of copied. Which of the two proposals do you want to discuss?

fantasai: I'm happy to entertain either. I think the proposal without syntax don't allow different propostions and would also change existing behavior so probably not the way we can go as TabAtkins noted last March.

florian: The unitless number one seemed to make sense to me. I think TabAtkins has reservations about unitless numbers because they don't meshed will with typedOM.

fantasai: In this case it's a multiplier and I don't know what unit we'd want to introduce.

florian: It's a % of some kind that just doesn't say so.

fantasai: We could use % also.

florian: % Isn't used there?

fantasai: Just alignment keywords. We could add % to them in the future for the % of the amount from start to end. For that reason if we go in that direction it might be a good idea to not use %.

Rossen_: I would stay away from % as well.

fantasai: This effectively represents an aspect ratio of sorts.

florian: Fair enough.
... I don't mind. I just thought tab felt introducing unitless things makes other hthings worse.

fantasai: If someone doesn't like this proposal and wants to work on an alternate that's fine, but I don't have another alternative.

<florian> it seems sensible to me.

Rossen_: I think this is a reasonable starting point. By the time we're done we might change, but as a starting point the proposed solution addresses this feature request.
... I'd like to hear if there are other thoughts or proposals. If there are additional syntax issues we can deal separetely.
... I'm not hearing pushback on the proposed way to solve and impl.
... Are there any or any objections?

<rachelandrew> +1 to adding the feature

Rossen_: There's a fair interest in this feature. Others last week gave thumbs up. I think it's reasonable to accept as level 2.
... Are there any objections or additional comments?

RESOLUTION: Add the feature proposed in issue #1116 to Grid L2

<rego> lajava, is having problems with the mic

fantasai: Do we want to do FPWD?

<fantasai> rego, maybe type in comment into IRC and we'll relay?

<lajava> yes, sorry, nothing urgent that can't be dicussed offline

Rossen_: Exactly. We can proceed to now resolve on FPWD for grid. Which will be potentially all the L1 delta incl subgrid and this new grid gutter feature
... I believe that's everything in L2, right?

<Chris_> so is the document ready to go for fpwd or does it need edits first?

<rego> we don't have a better proposal, but we've some doubts regarding how it'll work for grid containers with "height: auto", if after alignment it'll overflow or if it'll change the height of the container

fantasai: Yeah, this is all I intend for L2. We should focus on subgrid and this feature was straightfoward.

<rego> but as we don't have a better proposal, I believe current one is fine as strating point

Rossen_: Yeah. On our end we reviewed and we're fine with FPWD.

<Chris_> I prefer that we are ready to go before resolving to request the transition

<lajava> my concerns are specially related to the fact tha Content Distibution increase the size of the contauner, instead of using the available space (even causing overflow)

<tantek> ship it

Rossen_: If there are no obj we'll resolve.

Chris_: The doc is ready to go as is now? features we want are in?

fantasai: Yes, just need to be regenerated.

Rossen_: There's no features we don't want. I had reservations last week, but we reviewed and we're good.

Chris_: +1

RESOLUTION: Publish FPWD for Grid L2

<fantasai> lajava, rego: These are good points, let's work through them in WD.

Rossen_: Congrats and thank you.

[css-writing-modes] Should max-height also limit orthogonal flows?

<fantasai> lajava, rego: If we can't solve before subgrid needs to ship, we can drop to the next level :)

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

<rego> :-)

<lajava> fantasai: sounds good

fantasai: We use the...if you have orthogonal flow we need to come up with a height contraint on vertical text so there's a line length.
... By default we use a combo of containing block if it's defined or nearest scrollport or initial containg block.
... Scrollport we only use if its fixed height.
... For contianing block we forgot to look at max height.
... Proposal is to modify spec to look at max height when there's and auto and a max.
... There is one impl already.

florian: We have 1 1/2 impl. Blink and Webkit do it.

Rossen_: From impl PoV it sounds reasonable.
... We might already support this. It's been a while since I played with orthogonal flows. But it makes perfect sense.
... Other thoughts, ideas, obj on having max-height be a constraint?

florian: I'm in favor we should look in all cases, not some.

fantasai: Agree.

<rego> +1

Rossen_: Would be good when we spec lang to word it such that the used content box height will be defined rather then auto. I'm saying this b/c we don't want to have to come back and say min-height also needs to be looked at in case it's bigger. Would be better to define it as defined not auto.

<liam> presnet+

fantasai: Yeah. We need to make sure we word for all cases. We can't use used height because if it's auto it depends on this ortogonal flows.

Rossen_: Agree.
... Something like content box height would be defined. There's a combo of max an dmin height to make a limit.

fantasai: Sounds good.

Rossen_: I jsut don't want to ignore min height in this or have it sound like only max applies.

fantasai: Good point.

florian: Rossen_ to make sure I follow you say if min ehight is large it could come into account but smaller doesn't matter.

Rossen_: If there's something that will define a limit, such as max or min height. Min height only pushes the limit if it exists. Provided a limit exists and you have to look at min height it's used. I don't want us to forget about min height which is pushing the limit.
... I didn't know how to clearly define it so I said used height but that's weak.

florian: Your point should be equalliy valid for containing block as scope. But yeah, I agree.

<fantasai> sgtm, I'll make the edits and Florian will review ;)

Rossen_: I think we have enough in the discussion that will go into the minutes. Anything else to add?

florian: Good to resolve

RESOLUTION: Accept proposal in issue #2239

[css-sizing] Computing min-width/min-height: auto to zero

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

fantasai: I noticed we don't have consistancy on if the min height or min width go to auto or 0 on flex items. Spec isn't clear. WE should do something to make spec clear.
... I think it's in our best interest to compute to auto as many places as possible. Given blink is always auto we should go ahead and do that.
... This would change flexbox and grid spec to clarify that. min-width and min-height computes to auto

Rossen_: I thought we had a resolution. I believe in edge we're always doing auto so you can round to computed value and be able to round trip.

fantasai: The cases where it goes to 0 it would round trip. Flex items the only dimension were auto isn't 0 is the main axis. IN the cross axis it doesn't have any effect. It's effectively 0 not computed to 0.

Rossen_: In other cases you'll have wrong behavior if you round trip to 0.

fantasai: Those cases are already auto.

Rossen_: Okay.
... Anyone from FF that wants to chime in? Seems Gecko is the only one that may need to do work.
... Objections?
... I don't hear obj, but there isn't large representation from Gecko. If they have additional comments the issue is there.

tantek: Is the main argument round tripping?

fantasai: Main argument is to have a simplier rule for auto. If we were going back in time we'd have auto always go to auto and never 0 so in layout modes with another meaning it's consistant. For flex there's a complex set of conditions for when auto behaves as 0. only with overflow visible and main axis. Seems simplier to compute to auto.

Rossen_: We've added a whole bunch of magic into auto for flex. We don't want to expose parts of the magic sometimes. We just want it to be always auto.

<fantasai> dholbert: yeah

<dholbert> fantasai: OK, I don't have strong opinions then

Rossen_: tantek Anything else you want?

tantek: I'm trying to understand, but no reason to object. I see dholbert is checking.

<rego> dholbert, yep only about getComputedStyle()

<dholbert> fantasai: ...except I'd prefer to avoid introducing "this property's *computation* [as visible through inheritance etc] depends on that property's computed value on the same element" special cases

fantasai: Argument to compute to 0 is the author gets that result immediately when we can reliably get 0. Case to compute to auto is we can make it a simple rule. You could prob. argue in either direction.

Rossen_: I'm not hearing pushback.
... Sounds like we have 3 impl shipping the proposed behavior.
... I'm going to call for objections. Any objections?

RESOLUTION: compute min-width/min-height: auto to zero

[css-cascade] User stylesheets, UA stylesheets - still something we expect to be real?

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

Chris_: I guess there are 2 parts to this. First is I was trying to remove fonts 3 test failures. 2 tests said you have to set UA stylesheet o specific syntax which implies you have to be able to edit and put syntax in UA stylesheet.
... Since fantasai said you can wrap a div instead of putting it in the stylesheet so that's solved.
... But this is testing functionality I can't find anywhere. There's nothing that says the UA stylesshet has to be something phsyical nor something editable by the user.
... They're relying on non-required features.
... User stylesheets there's a requirements to support. Edge doesn't do it. Chrome took it out. We've had this model since CSS 1. Do we still believe in it or do we want to allow the browsers to inject and we shouldn't test for it. Esp. UA stylesheet.

fantasai: I don't know anywhere in the spec the UA stylesheet editable. User stylesheet is a file you can choose.

Chris_: Right.

fantasai: There's also that we have spec sections conflicting.

florian: How?

<fantasai> https://www.w3.org/TR/CSS2/cascade.html#cascade

fantasai: one impl one thing, the other different. Casecade talks user and user agenda.
... User may be able to spec style info for a particular doc. It's all mays.

<fantasai> https://www.w3.org/TR/CSS2/conform.html#conformance

fantasai: Chris_ pointed out there's a section on the conformance with musts saying UA must allow the user to select a stylesheet.

<fantasai> “UAs must allow users to specify a file that contains the user style sheet.”

florian: That doesn't seem very elegent. Spec saying how a UA must behavior is reasonable. But saying it must provide some UI level feature, file access is a UI level requirement.

fantasai: That's in 3.2.

Chris_: An additional complication were UA a11y guidelines require it to be modifiable. That's various legal standards. modifying or changing this has substanital reprecussions. Assuming it works also has repercussions.

Rossen_: As an impl who is shipping this. UA stylesheet since the first time I impl this in IE8 there was no conformance requirement that the user stylesheet has to be on disk nor using it as such and paying the performance costs.

<fantasai> *please* can we not confound UA and user in this discussion?

Rossen_: This as a UA impl leads to the conclusion this better be a static compiled ready to go stylesheet. This is the reason we don't have an actual file on the system. But we do have one that's loaded and compiled.

<smfr> webkit also compiles the UA style sheet at build time

<fantasai> The UA stylesheet and user stylesheet are really different concepts

Rossen_: So there is the concept of user agent def. stylesheet. But we don't plan on shipping it as actual CSS.
... Other reason is if you have differener user agents referring to same engine you should have, at least our design principle, is they all have basically same stylesheet.
... User stylesheets we deprecated before edge. We had support in ie9 and 10. I think we deprecated in 11. There was no use.
... Since then things changed. In particular extensions allow the addition of stylesheets only that can be used to modify and tailor UX in more ways then a single stylesheet. In terms of extensibility one of our principles was to encourage this to be exposed through extensions rather then dropping a style sheet.

<fantasai> +1 to Florian

<Rossen_> +1 to florian

florian: Pretty much agreeing with you. I think the right division is the css specs should define how user stylesheets work, but stay out of the must impl. If other specs wand to require this of browsers, but css should define how it works.

Rossen_: Agree.

<Chris_> https://www.w3.org/WAI/UA/TS/html401/cp0414/0414-USER-STYLE.html

<Chris_> Checkpoint 4.14 Choose style sheets (Priority 1 )

<Chris_> Provision 2 : Allow the user to choose from and apply at least one user style sheet.

dauwhe: I want to reiterate the importance of the end use affecting presentation of content. This becomes a huge issue on digital books. There's an aria personalization task force so might be good to coordination. I don't want to see this die.

fantasai: Yeah.

<Chris_> also https://www.w3.org/TR/UAAG20/#gl-style-sheets-config

<Rossen_> dholbert: I will, thx for pointing out

<dholbert> Rossen_: thanks

fantasai: I think propose edits would be leave the cascade 6.4 section in place. It describes that a use could do a css syntax or through an interface. I think we should remove from conformance the paragragh that wasy the user must have ability to spec a file rep. user stylesheet.

<fantasai> https://www.w3.org/TR/CSS2/conform.html#conformance

fantasai: I would remove tha second paragraph after bullet list ^

florian: I don't think removing the must decreases the chance of impl. It's important to define how to do it and let market pressure push to impl.

<fantasai> no changes proposed to https://www.w3.org/TR/CSS2/cascade.html#cascade

Rossen_: Chris_ back to you.

Chris_: I wanted clarity. I didn't have an aim in mind. I like what florian said we shouldn't spec UI behavior.

fantasai: Proposal for edits. Sound good?

Chris_: I like what you suggested.

fantasai: proposed resolution: From section 3.2 remove the paragraph begining UA must allow users to spec a file. No changes to section 6.4

<fantasai> https://www.w3.org/TR/CSS2/conform.html#conformance 3.2

<fantasai> https://www.w3.org/TR/CSS2/cascade.html#cascade 6.4 (no change)

Rossen_: One at a time. From CSS 2 section 3.2 remove the paragraph beginning "UA must allow the user to specify a file..."
... Objections?

<Chris_> https://www.w3.org/TR/CSS22/conform.html#conformance

Chris_: Question. That link goes to css2 which points to 2.1 and 2.2 I want to make sure we're updating those.

fantasai: Yes, we can update both of those. Might as well edit all.

<Chris_> +1

RESOLUTION: From CSS 2, 2.1 and, 2.2 section 3.2 remove the paragraph beginning "UA must allow the user to specify a file..."

Rossen_: Second was additional resolution of no change for css cascade section 6.4

fantasai: CSS 2.

Rossen_: Sorry. I'm looking at links and got confused.

florian: Question.
... If this would induce process churn I'm happy no change. If it would it would be nice to mention it may be done with an extension as well as a file.

fantasai: It's already there.

florian: Given the example of extensions is nice, but only if it doesn't make process change.

Chris_: It's easy to put that in 2.2

fantasai: I feel like the text is close enough.

florian: Sure.

Rossen_: Back to proposed no change rsolution. Objections?

RESOLUTION: No change to section 6.4

end

tantek: I heard you/rossen say impl say is computing auto to auto, but minutes say auto to 0.

Rossen_: resolution was we compute auto in the case of auto.

tantek: That wasn't what was scribed.

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

Rossen_: The resolution was supposed to be computed value of min width and min height is auto even if it's internally resolved to 0 for layout purposes.

tantek: That makes sense to me.
... I'd like that as an updated resolution in the minutes.

RESOLUTION: computed value of min width and min height is auto even if it's internally resolved to 0 for layout purposes

fantasai: I updated the issue

<tantek> for grid & flex items only

tantek: grid and flex only?

fantasai: Yeah. If it's anything else file that separate.

end

Rossen_: We have 5 minutes. Preference on topic?

fantasai: I'd like to propose we update WD of selectors? Item #6 needs more discussion but it is marked as an issue.

[selectors4] Name the "functional pseudo-class like :matches() with 0 specificity"

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

<leaverou> https://github.com/w3c/csswg-drafts/issues/2143#issuecomment-360586470

leaverou: We resolved a month ago to add a pseudoclass :is . There was consern that that's logical opposite of not. Proposal is we could rename matches to is, we could rename matches, we could combine both properties. There were a bunch of proposals for different names. I made a table with proposals ^
... Hoping we could do a straw poll and decide on name.
... I think best is to mix them into one pseucoclass of :is. Matchs was impl but it's not used and is only in Safari. The argument was that it’s "rude" to rename

<fantasai> I don't think we can close on this fairly in the next 4 minutes...

<fantasai> 3 minutes

florian: rude isn't the best word, but there is inertia there and it's a lot to change.

smfr: I don't have a feel for how much matches is used.

<bradk> This could be a 30 minute discussion

fantasai: We have 2 minutes. I'd like us to defer this since there has been a lot of interesting discussion. And we should have info on existance of matches.

leaverou: I won't be able to be in next week, so defer 2 weeks.

fantasai: Sure.

Rossen_: This topic will take time. Let's point everyone to the issue so it's discussed.
... fantasai you wanted an updated WD?

fantasai: Yeah, to selectors. There's a handful of open issues that are significant and they're marked in the draft. I'd like to update the W3.org.

RESOLUTION: Publish a new WD for Selectors adding the open items as issues.

Rossen_: This topic should continue being discussed in the issue and once we're ready to resolve we'll bring it back. A couple of weeks from now sounds reasonable on timeframe.

<fantasai> Issues marked in the draft: https://drafts.csswg.org/selectors-4/#issues-index

Rossen_: That's the top of the hour. Any other publication resolutions? I don't see any.
... Let's end here.

end

Rossen_: Next week is an APAC time zone friendly call. Keep that in mind. We'll be at 4pmPT.
... Have a good rest of the day and we'll chat next week.

<Rossen_> trackbot, end meeting

- DRAFT -

Cascading Style Sheets (CSS) Working Group Teleconference

31 Jan 2018

Attendees

Contents