- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 31 Jan 2018 19:40:53 -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.
=========================================
CSS Grid & Flexbox
------------------
- RESOLVED: Both flexbox and grid items top and bottom margin and
padding percent resolves against the available inline
direction.
CSS Grid 2
----------
- RESOLVED: Add the feature proposed in issue #1116 to Grid L2.
- RESOLVED: Publish FPWD for Grid L2
Writing Modes
-------------
- RESOLVED: Accept proposal in issue #2239 (Also consider max-height
as a limit on the height of the orthogonal flow)
CSS Sizing
----------
- RESOLVED: Computed value of min width and min height is auto even
if it's internally resolved to 0 for layout purposes.
CSS Cascade
-----------
- RESOLVED: From CSS 2, 2.1 and, 2.2 section 3.2 remove the
paragraph beginning "UA must allow the user to specify a
file..." https://www.w3.org/TR/CSS2/conform.html#conformance
- RESOLVED: No change to section 6.4
https://www.w3.org/TR/CSS2/cascade.html#cascade
Selectors
---------
- leaverou compiled a list of options for issue #2143:
https://github.com/w3c/csswg-drafts/issues/2143#issuecomment-360586470
and discussion will continue on github.
- RESOLVED: Publish a new WD for Selectors adding the open items as
issues.
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2018Jan/0102.html
Present:
Rachel Andrew
Rossen Atanassov
Brian Birtles
Tantek Çelik
Dave Cramer
Alex Critchfield
Benjamin De Cock
Elika Etemad
Javier Fernandez
Simon Fraser
Tony Graham
Dael Jackson
Brad Kemper
Liam Quin
Chris Lilley
Thierry Michel
Michael Miller
Anton Prowse
Manuel Rego
Melanie Richards
Florian Rivoal
Lea Verou
Eric Willigers
Regrets:
David Baron
Vladimir Levantosky
Peter Linss
Dirk Schulze
Jen Simmons
Scribe: dael
Rossen: I think we have enough people.
Rossen: Let's get started.
Rossen: As usual I'd like to call for any additional items or
changes to make to the agenda.
CSS Grid & Flexbox
==================
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.
Rossen: 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
Rossen: That means we can resolve unless there's additional feedback
or objections.
Rossen: Current proposal: both flexbox and grid items top and bottom
margin and padding % resolves against the available inline
direction.
Rossen: Any thoughts? Comments? Objections?
RESOLVED: Both flexbox and grid items top and bottom margin and
padding percent resolves against the available inline
direction.
CSS Grid
========
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 property that takes values to
be put in between. 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 there's no way to get that.
fantasai: This proposal has a possible value where it means go look
at the other direction and use it over here multiplied by
a number.
Rossen: Do we have javifernandez? Or anyone from Igalia?
<lajava> yes
Rossen: 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 ambiguity as to
how this could be helpful.
fantasai: What proposal does is what was requested. I'm happy to
entertain other syntactic 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 proportions 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 percentage of some kind that just doesn't say so.
fantasai: We could use percent also.
florian: Percent isn't used there?
fantasai: Just alignment keywords. We could add percent to them in
the future for the percentage 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 percent.
Rossen: I would stay away from percentage as well.
fantasai: This effectively represents an aspect ratio of sorts.
florian: Fair enough.
florian: I don't mind. I just thought Tab felt introducing unitless
things makes other things 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.
Rossen: I'd like to hear if there are other thoughts or proposals.
If there are additional syntax issues we can deal separately.
Rossen: I'm not hearing pushback on the proposed way to solve and
impl.
Rossen: 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.
Rossen: Are there any objections or additional comments?
RESOLVED: Add the feature proposed in issue #1116 to Grid L2
<rego> lajava, is having problems with the mic
<fantasai> rego, maybe type in comment into IRC and we'll relay?
<lajava> yes, sorry, nothing urgent that can't be discussed offline
<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
<rego> but as we don't have a better proposal, I believe current one
is fine as stating point
<lajava> my concerns are specially related to the fact that Content
Distribution increase the size of the container, instead of
using the available space (even causing overflow)
<fantasai> lajava, rego: These are good points, let's work through
them in WD.
<fantasai> lajava, rego: If we can't solve before subgrid needs to
ship, we can drop to the next level :)
<rego> :-)
<lajava> fantasai: sounds good
Publication
-----------
fantasai: Do we want to do FPWD?
Rossen: Exactly. We can proceed to now resolve on FPWD for grid.
Which will be potentially contain all the L1 delta including
subgrid and this new grid gutter feature
Rossen: I believe that's everything in L2, right?
<Chris> so is the document ready to go for fpwd or does it need
edits first?
<Chris> I prefer that we are ready to go before resolving to request
the transition
fantasai: Yeah, this is all I intend for L2. We should focus on
subgrid and this feature was straightforward.
Rossen: Yeah. On our end we reviewed and we're fine with FPWD.
Rossen: If there are no obj we'll resolve.
<tantek> ship it
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
RESOLVED: Publish FPWD for Grid L2
Rossen: Congrats and thank you.
CSS Writing Modes
=================
Should max-height also limit orthogonal flows?
----------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/2239
fantasai: We use the...if you have orthogonal flow we need to come
up with a height constraint on vertical text so there's a
line length.
fantasai: By default we use a combo of containing block if it's
defined or nearest scrollport or initial containing block.
fantasai: Scrollport we only use if its fixed height.
fantasai: For containing block we forgot to look at max height.
fantasai: Proposal is to modify spec to look at max height when
there's and auto and a max.
fantasai: There is one impl already.
florian: We have 1 1/2 impl. Blink and Webkit do it.
Rossen: From impl PoV it sounds reasonable.
Rossen: We might already support this. It's been a while since I
played with orthogonal flows. But it makes perfect sense.
Rossen: 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 language to word it such that the
used content box height will be defined rather then auto.
I'm saying this because 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.
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
orthogonal flows.
Rossen: Agree.
Rossen: Something like content box height would be defined. There's
a combo of max and min height to make a limit.
fantasai: Sounds good.
Rossen: I just 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 height 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.
Rossen: I didn't know how to clearly define it so I said used height
but that's weak.
florian: Your point should be equally 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.
RESOLVED: 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 consistency 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.
fantasai: 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.
fantasai: 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.
Rossen: Anyone from FF that wants to chime in? Seems Gecko is the
only one that may need to do work.
Rossen: Objections?
Rossen: I don't hear objections, 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 simpler 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
consistent. For flex there's a complex set of conditions
for when auto behaves as 0. only with overflow visible and
main axis. Seems simpler 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.
<birtles> I believe dholbert is checking now
<dholbert> not listening, but just noticing the discussion in IRC.
Are we just talking about getComputedStyle basically? (
not about actual layout behavior?)
<fantasai>x dholbert: yeah
<dholbert> fantasai: OK, I don't have strong opinions then
<rego> dholbert, yep only about getComputedStyle()
Rossen: tantek Anything else you want?
tantek: I'm trying to understand, but no reason to object. I see
dholbert is checking.
<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.
Rossen: Sounds like we have 3 impl shipping the proposed behavior.
Rossen: I'm going to call for objections. Any objections?
RESOLVED: compute min-width/min-height: auto to zero
[Note: this was minuted wrong. Please see lower in minutes for the correction]
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 to specific syntax which implies you have to be
able to edit and put syntax in UA stylesheet.
Chris: Since fantasai said you can wrap a div instead of putting it
in the stylesheet so that's solved.
Chris: But this is testing functionality I can't find anywhere.
There's nothing that says the UA stylesheet has to be
something physical nor something editable by the user.
Chris: They're relying on non-required features.
Chris: 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. Especially
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. Cascade talks
user and user agent.
fantasai: 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 elegant. 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 substantial repercussions. 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 defined stylesheet.
But we don't plan on shipping it as actual CSS.
Rossen: Other reason is if you have different user agents referring
to same engine you should have, at least our design
principle, is they all have basically same stylesheet.
Rossen: User stylesheets we deprecated before edge. We had support
in ie9 and 10. I think we deprecated in 11. There was no use.
Rossen: 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.
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 want to
require this of browsers, but css should define how it
works.
<fantasai> +1 to Florian
<Rossen> +1 to florian
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.
<Chris> also https://www.w3.org/TR/UAAG20/#gl-style-sheets-config
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.
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 paragraph that was the user must have
ability to spec a file representing user stylesheet.
<fantasai> https://www.w3.org/TR/CSS2/conform.html#conformance
fantasai: I would remove that second paragraph after bullet list ^
<fantasai> no changes proposed to
https://www.w3.org/TR/CSS2/cascade.html#cascade
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.
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
beginning "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..."
Rossen: 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
RESOLVED: 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.
florian: 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 resolution. Objections?
<liam> ok with no change
RESOLVED: No change to section 6.4
CSS Sizing
==========
Computing min-width/min-height: auto to zero
--------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/2230
Rossen: Resolution was we compute auto in the case of auto.
tantek: That wasn't what was scribed.
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.
tantek: I'd like that as an updated resolution in the minutes.
RESOLVED: 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.
Rossen: We have 5 minutes. Preference on topic?
Selectors
=========
fantasai: I'd like to propose we update WD of selectors? Item #6
needs more discussion but it is marked as an issue.
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 pseudo class :is . There
was concern that that's the 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
https://github.com/w3c/csswg-drafts/issues/2143#issuecomment-360586470
leaverou: Hoping we could do a straw poll and decide on name.
leaverou: I think best is to mix them into one pseudo class of :is.
:matches was implemented 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 existence 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.
Publication
-----------
Rossen: 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.
<fantasai> Issues marked in the draft:
https://drafts.csswg.org/selectors-4/#issues-index
RESOLVED: 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.
Rossen: That's the top of the hour. Any other publication
resolutions? I don't see any.
Rossen: Let's end here.
Rossen: Next week is an APAC time zone friendly call. Keep that in
mind. We'll be at 4pmPT.
Rossen: Have a good rest of the day and we'll chat next week.
Received on Thursday, 1 February 2018 00:41:48 UTC