- From: Dael Jackson <daelcss@gmail.com>
- Date: Thu, 20 Jun 2019 05:20:38 -0400
- 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.
=========================================
Writing Modes
-------------
- Coming out of the F2F there is a push to get Writing Modes to REC
status. Before next week's telecon, there will be follow-up done
to check into getting Mozilla to conform to a change in the spec.
CSS Display
-----------
- RESOLVED: Republish Display
CSS Grid
--------
- RESOLVED: Accept change in
https://github.com/w3c/csswg-drafts/commit/5a43ab7210d08c9a012a7697eb39a382f8133079
(Issue #3694: How to distribute space using flex ratios
when the sum is 0?)
- RESOLVED: Accept change in https://github.com/w3c/csswg-drafts/issues/3693
("Maximize Tracks" shouldn't distribute equally for
flexible tracks)
- RESOLVED: Accept proposal in https://github.com/w3c/csswg-drafts/issues/3683
(Don't expand flexible tracks under a min-content
constraint)
Color Adjust
------------
- The group will wait a few more weeks to see if anyone has a
concrete proposal to handle the concerns in issue #3880 (Combine
forced-color-adjust and color-adjust properties somehow?). If
there's no proposal the group will close the issue no change.
- RESOLVED: Computed value of color-scheme will match its specified
value (Issue #3848: Disallow repetition of color-scheme
keywords?)
- Before deciding if multiple color-scheme <meta> values should take
the first or the last value (Issue #3846) TabAtkins will
investigate if other <meta>s do first or last. This will allow
the group to see if this is something that can be standardized
so authors don't have to try and remember which <meta>s behave
which way.
CSS Lists
---------
- The group generally agreed that option/optgroup should be able to
set counters (Issue #4004) though there were concerns about how
it would interact with things like display:none. TabAtkins and
fantasai will come up with proposed spec text for the group to
review and debate.
CSS Inline
----------
- The group would like `text` of `leading-trim` to be interoperable
(Issue #3978) but there were concerns that browsers aren't using
the same tables for calculations so interoperability may not be
possible.
- At a higher level there is a desire to make new font functions
handled the same for all browsers and OSs even if older values
cannot be.
- The group ran out of time so discussion will continue in the
GitHub issue
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2019Jun/0002.html
Present:
Rachel Andrew
Rossen Atanassov
Tab Atkins
Amelia Bellamy-Royds
Christian Biesinger
Benjamin De Cock
Elika Etemad
Koji Ishii
Dael Jackson
Brad Kemper
Rune Lillesveen
Chris Lilley
Peter Linss
Myles Maxfield
Anton Prowse
Florian Rivoal
Alan Stearns
Lea Verou
Eric Willigers
Regrets:
David Baron
Oriol Brufau
Dave Cramer
Brian Kardell
Manuel Rego Casasnovas
Melanie Richards
Jen Simmons
Greg Whitworth
Scribe: dael
Writing Modes
=============
astearns: We've got all writing modes folks. At F2F I was told it
was a week to get writing modes to rec
florian: It was a full time week of work, not a calendar week. Also
with some assumptions that need to be verified
florian: Assumptions are there's one thing that needs to be checked
for Gecko conformance. Sent an email to dbaron but haven't
seen if he replied
astearns: Is there an issue for Gecko?
florian: dbaron did reply but I haven't read. There are failing
tests for Gecko, but don't know if there's an issue
astearns: Let's get back next week call or through github issues.
Like to make sure there's an issue logged for changes in
Gecko if that's the case
fantasai: I should spend time next week digging through impl report.
5 second look we had failing tests due to broken tests so
some work will need to go into that. Don't know how much
astearns: Could I ask you to start that this week?
fantasai: I'm at AB meeting so no
astearns: By next week I'll expect to hear from florian about
Mozilla issue. Then we can decide how much we can get done
after that. I want to make steady work on this week to week
florian: Anyone hears this is 40 work hours with no one being paid
to do it.
astearns: And that needs to be solved.
<dbaron> fwiw I filed https://github.com/w3c/csswg-drafts/issues/4026
in response to Florian's email
astearns: Anything to add or change in agenda?
CSS Display
===========
Parent box of run-in or non-principal box
github: https://github.com/w3c/csswg-drafts/issues/3158
fantasai: Trying to load this. I suspect this issue is just
verifying something
astearns: This is where you asked for repub so maybe this should be
the last.
fantasai: I think we brought this in F2F when requested publication.
I think we reviewed
astearns: And there are changes from a month ago. No changes to spec
since F2F
fantasai: I think when we resolved to publish it was including these
and we forgot to remove agenda+
astearns: We did resolve to republish a month ago?
fantasai: Yeah
astearns: It's just not in this issue.
astearns: That was display.
fantasai: Yes, we don't have resolution for grid. Do for display
astearns: Should we re-resolve to publish display?
fantasai: I think resolution was in F2F but we can do it again
astearns: Objections to republish Display?
astearns: There's a DoC and a diff
<chris> sounds good to me
RESOLVED: Republish Display
CSS Grid
========
How to distribute space using flex ratios when the sum is 0?
------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/3694
fantasai: This was we forgot to handle divide by 0 case when
dividing. Minimal fix to only do that if the sum is >0. If
sum is 0 we distribute space equally
<fantasai> https://github.com/w3c/csswg-drafts/commit/5a43ab7210d08c9a012a7697eb39a382f8133079
fantasai: diff^
fantasai: Refers to how we split up space for intrinsic track sizes.
Have to distribute space even though it's flex 0. If there
are flex ratios we can use we do. If they're all 0 we
can't divide so we say do equally in that case
astearns: Any comments?
astearns: I don't see in diff anything about distributing equally
fantasai: [reads]
astearns: Alright so default case is in previous text?
fantasai: Yes.
astearns: Objections?
RESOLVED: Accept change in
https://github.com/w3c/csswg-drafts/commit/5a43ab7210d08c9a012a7697eb39a382f8133079
"Maximize Tracks" shouldn't distribute equally for flexible tracks
------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/3693
fantasai: This was another fix for errors
fantasai: There was a statement where we made a mistake saying treat
max sizing same as min sizing. Trying to select a class of
tracks and didn't use the right words.
astearns: Okay
fantasai: Just fixing an error. Happy is people want to look at it
astearns: Given issue discussion looks correct. oriol said it looks
good
fantasai: These were co-edited with oriol so he thinks they're
correct
astearns: Comments on this change? Objections?
RESOLVED: Accept change in https://github.com/w3c/csswg-drafts/issues/3693
Don't expand flexible tracks under a min-content constraint
-----------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/3683
fantasai: Case where spec forgot to consider min content correctly.
Implementations do logical and don't expand track to take
up space. Changing spec to match implementations and do
thing you expect which is size to smaller end when under
min-content constraint.
fantasai: If you can shrink something down without overflow then
min-content constraint should be that amount and not
bigger. Spec violated concept, implementations did
correct. Trying to match them up
astearns: Any comment? I note you asked for TabAtkins or Rossen to
comment
fantasai: I'd prefer to get their +1
TabAtkins: I'll review shortly
astearns: Resolve or wait on review?
TabAtkins: I trust fantasai so resolve. If I find a mistake I'll say
something
Rossen: On the same page. Proposed doesn't seem crazy, just need to
look at overall algorithm fit. I'm sure fantasai spent more
cycles so I trust her
astearns: Other comments?
astearns: Objections to this change?
RESOLVED: Accept proposal in https://github.com/w3c/csswg-drafts/issues/3683
astearns: All three of these look like they need tests or need tests
verified. Have there been any?
fantasai: None in wpt yet. I'll check with oriol and he might know
more
astearns: TabAtkins as you review can you check in tests?
TabAtkins: Sounds good
astearns: Once we have tests anything to keep us from updating CR?
fantasai: Probably tests for other things. I think most that should
be fixed is but there might be one or two not.
astearns: I suspect no DoC yet.
fantasai: Right. Bulk of work is that and changes section
astearns: Anything else on grid?
fantasai: I'm going to say no
Color Adjust
============
Combine forced-color-adjust and color-adjust properties somehow?
----------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/3880
astearns: Was on F2F, didn't get to it.
fantasai: I think this would have been better at F2F. I don't know
if there's anything for call. We need a concrete proposal
to discuss on a call that handles this issues
fantasai: If anyone is interested keep track of issue. Someone needs
to make a proposal before we can move forward
astearns: Anything else before we punt?
AmeliaBR: I have a rough proposal in the issue. More I think the
more I think it's not worth it. I would be comfortable
resolving no change but we can leave the issue open
pending a good proposal
chris: I think they're better separate. dbaron comment is on the
money there
astearns: fantasai think we should close no change?
fantasai: I'd give another couple weeks to see if we can solve
dbaron concerns and if not we close it.
astearns: Any other comments?
Disallow repetition of color-scheme keywords?
---------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/3848
TabAtkins: For future extensibility we allowed arbitrary keywords
and they're ignored. Question is what happens when you
repeat color-scheme keyword? We don't want to disallow,
but do we keep it in computed value? Collapse along the
way?
TabAtkins: No strong argument either way
TabAtkins: Originally thought there was an efficiency argument but
that's not true if trying to preserve unknown. I think
conclusion is keep the same and don't simplify.
TabAtkins: Just have computed value = specified value
astearns: Any comments?
<futhark> I’m fine with either, it’s just that dropping duplicates
means having to keep track of them during parsing
<futhark> Which requires a hash map or something
astearns: So close no change?
TabAtkins: I don't recall current state
TabAtkins: Let me look
TabAtkins: It would be changing spec
astearns: That computed is same as specified value
TabAtkins: Yes
astearns: Objections to computed value of color-scheme match its
specified value?
RESOLVED: Computed value of color-scheme will match its specified
value
What happens with multiple <meta>s?
-----------------------------------
github: https://github.com/w3c/csswg-drafts/issues/3846
TabAtkins: Meta name = color-scheme lets you set initial
color-scheme so we can get that value out quick. What
happens if you use multiple? Two obvious options are take
the first or take the last valid one. Precedent both ways
TabAtkins: I propose we take the first so we get the value as
quickly as possible so don't have to wait for rest of
page to load before we apply effects
AmeliaBR: Since whole point of meta is to get it asap it does make
sense. We have examples in HTML that are consistent
TabAtkins: theme-value also takes the first so it's consistent
that way
fantasai: I would consider multiple to be an error case. If you're
flipping colors constantly that's your fault. I think it
benefits authors if we're consistent and agree with smfr
it should be one rule for all meta tags
fantasai: Given oldest is viewport that means using last one
TabAtkins: Using last for viewport gives the bad behavior you
listed. I think viewport fell out of viewport defined as
equivalent to a stylesheet
fantasai: It's an error case. If author wants correct they should
not put multiple. I think it's fine if broken isn't
correct. Consistent story for authors is more important
that it's always last. Arbitrariness is more disruptive
then having to keep all the things
TabAtkins: But if we have to take last, we can't render until have
downloaded enough of HTML. I agree with consistency
argument. I'd like to be consistent with first and see if
we can adjust viewport.
fantasai: If you want to go that route it's fine. I think it's
important we're consistent. If you want to see first is
web compat that's good.
astearns: Sounds like we already have different. I'm concerned about
hitching consistency to viewport given comment from
futhark that viewport is last one inserted into doc.
TabAtkins: Yeah, ours is messed up. We should not rely on viewport
behavior
smfr: Before that comment I was reluctant on viewport. Changing
viewport now does have more web compat concerns. I would love
all meta tags to have same. Need to figure out dynamically
inserted nodes
smfr: UA might not process meta tags until end of head. Just because
you have multiple doesn't mean you'll see flashes, UA can wait
until end of head.
TabAtkins: Certainly can, but end of head could be different packet
and flush the queue. Definitely different behaviors
allowed.
myles: Procedurally meta tag is defined in HTML. If we decide
something here is there anyone that can make edits to resolve
this?
<AmeliaBR> We are currently defining the meta value:
https://drafts.csswg.org/css-color-adjust-1/#color-scheme-meta
TabAtkins: Should try and get agreement on consistent behavior and
get that into general meta authoring guidelines
astearns: But this needs to be specified elsewhere
TabAtkins: Yes, actual definition is in HTML. They are deferring to
us on this since we're defining it
astearns: I'm assuming that for web compat reasons we're not going
to be able to change current viewport. Given that would
anyone object to spec that the color-scheme meta will
match theme-color and take first one found?
smfr: What happens with other meta like char-set?
TabAtkins: I do not know. But those are also more super legacy and
likely to be weird
astearns: Would be nice to have answer
smfr: Agree.
fantasai: Don't want to resolve without jensimmons or rachelandrew
astearns: Fair
fantasai: I believe impact to author is bigger concern then get the
earliest possible
TabAtkins: We've got 2 css things that are inconsistent so we'll
have to change something. Maybe we have a new policy and
legacy is legacy.
fantasai: If it's completely inconsistent and we can't align I'm
fine with a going forward policy. If it's possible to
align them all we should go that way
<fantasai> Or even to align most of them
astearns: TabAtkins can I ask you to do survey of meta tags that
effect css?
TabAtkins: Looking at it. It's a consequence of algorithm and not
stated in spec so I'm chasing it down
astearns: Let's wait on this issue until we get the survey and
comments from authoring advocates. Sound good?
TabAtkins: mmhmm
<rachelandrew> I'll take a better look at issue 3846 and see if I
have any thoughts from the authoring pov.
Multicol
========
column-fill should behave more similarly in paginated and
continuous contexts
---------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/4036
rachelandrew: Is dbaron on? He'll be needed
florian: I think I can represent
rachelandrew: There was a comment from Morten. Maybe worth waiting
astearns: Thanks florian but better to move on
CSS Lists
=========
Should option/optgroup be able to set counters?
-----------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/4004
TabAtkins: Technically per CSS they are descendant of replaced so
don't generate boxes. If continuing the current
resolution that counters work on box tree there's no box
to let them set or change counter. However FF and
previous Edge allow it. Chromium does not
TabAtkins: There are use cases for this and a chromium issue to fix
and allow setting of counters.
TabAtkins: Chrome devs discussing if they should, but no conclusion
TabAtkins: This may effect related issues like if SVG elements can
set counters.
TabAtkins: We need to figure out exact terminology. fantasai's
proposal is go one level up to also things that are like
boxes, but not css boxes for layout terms and allow those
to host counters.
TabAtkins: I'm fine with that. Proposal is allow optin/optgroup and
other things that are like boxes outside the css model to
effect counters
astearns: sgtm
AmeliaBR: Makes sense. I'd like a more explicit definition to what
is and isn't like a box
TabAtkins: I prefer to define a new term other specs could hook and
we define what that is for HTML and SVG. Other markup
languages could say they are that thing even though they
don't generate css boxes
astearns: Other comments?
smfr: Sounds a little confusing for interactions with display:none.
If you have optgroup that contributes to counters and you
display:none it does it still contribute?
TabAtkins: I don't think display:none does anything to optin
smfr: If you have one of these how do you stop contributing to
counters
TabAtkins: You don't set the counter. the display:none wasn't an
intentional choice, it was legacy
smfr: Sounds like it will complicate code to determine what
contributes to counters. May be odd interaction with other
properties is what I'm saying
fantasai: I kinda disagree, I would expect display:none to have
effect on counters. You're processing css properties and
counters is one of them. I don't have strong opinion
on this
<TabAtkins> http://software.hixie.ch/utilities/js/live-dom-viewer/saved/7018
apparently 'display' does work on <option> in Chrome...
TabAtkins: If someone with FF or older Edge can check that link I
want to see if display has effect in other
smfr: [missed]
<futhark> Display:none affected in firefox
<smfr> webkit shows the ‘bar’ in the testcase
<futhark> that is, removed from select rendering
<smfr> filed webkit.org/b/199011
Rossen: We do not support counters inside of display:none. Only time
we did something more interesting is if gCS was called
inside and we'd have something to calculate in the sub tree.
I think we backed it out because it was fragile
fantasai: I think proposal is that anything that is a replaced
element has nothing to do with counters or we have
something represented in render tree and not display:none
and they can have counters
astearns: Either way implementations would need to change because
we're not interop
TabAtkins: Yeah
TabAtkins: And we're buckwild with what styles can effect inside a
select
fantasai: If we have an idea we want to do this how about TabAtkins
and I come up with specific wording that deals with the
issues brought up here. We can bring it back and think
about how it effects different impl
astearns: Objections to that path?
ACTION TabAtkins and fantasai develop spec text for
https://github.com/w3c/csswg-drafts/issues/4004
<trackbot> Created ACTION-881
Counter scopes should be based on box tree, not element tree
------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/674
TabAtkins: fantasai added the agenda. I'm curious why. There's a
person asking about implications but don't know what to
discuss
fantasai: I don't remember
astearns: We have a comment with different cases
TabAtkins: I need to look through his HTML cases to figure out what
they're trying to favor. I think we have to defer for now
astearns: My reading is here are the cases that show a difference.
Not sure they're picking a side
<fantasai> I think the issue was
https://github.com/w3c/csswg-drafts/issues/674#issuecomment-333541595
CSS Inline
==========
Make `text` of `leading-trim` interoperable?
--------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/3978
astearns: This is F2F leftover
koji: The leading-trim has text representing text-top and
text-bottom. text-top and text-bottom isn't browser interop or
even on same browser across OSs. prop is to define. One
proposal is to use specific ascender and descender. Another is
em height. This isn't defined in CSS but algorithm is from
gecko
koji: Seems to do a good job for non-tall scripts
fantasai: I don't think I agree with a platform text value for this
metric. I think people looking to trim are looking for a
particular value. Does make sense to have other two,
ascent, descent and em height. If we want to define an
existing keyword to do that or add a new I'm less sure
fantasai: Interesting question of these metrics which do we want
myles: Like to not parse tables myself. Likely look up the
functions. not sure if that defeats purpose.
fantasai: It means you can't read the sTypo metrics?
myles: Can but takes a lot of code to get the table and figure out
the values and convert
koji: If you call core text ascendant and descendant aren't interop
myles: If there was a interop field we property would just hook that
field up to core text field which defeats purpose of interop
field so that's unfortunate
koji: Clarify, the division of leading trim where authors use
webfonts so it's the same binary on all platforms and
browsers. If they use font-top they see different layout
result. For this property I think having the same result for
same font value is quite important
<fantasai> +1 to koji
astearns: Your last comment is that if for whatever reason web font
is serving two values typo text won't be interop if
metrics are different in font files. We're looking for
interop if same font files is served.
astearns: I don't know if it's the case that if you have the same
font file that the different text rendering systems will
us OS2 table data
chris: Probably not. Was the case that they all used different tables
astearns: So even if we do spec that you have to get data out of
font file we'd still end up with bad interop due to
different text rendering
koji: Could be differences of rounding. Most of difference in font
metrics comes from open type fonts having 3 different metrics
and each platform uses different of 3. If browsers use same
metrics should be interop
astearns: I'm not sure browsers are using same metrics
koji: Blink we use same metric as one platform uses. Even if same
web fonts blink uses different metrics depending on platform
koji: We rely on platform API to read metrics
<fantasai> And this drives authors crazy
myles: meta question- if we resolve on this to have interop do you
expect to apply this to other css properties. Like we'd have
to implement new type system to get interop or is this one-off
koji: At least for new things I'd like interoperable ones. Some
reasons we may need existing ones, legacy reasons or future
platform behavior. in those cases I'm fine to provide options.
<fantasai> +1
astearns: Should we continue later since we're at time?
myles: Good idea
astearns: Let's continue in GH and we'll come back
astearns: Thanks everyone and we'll talk next week
Received on Thursday, 20 June 2019 09:21:47 UTC