IRC log of css on 2019-06-19

Timestamps are in UTC.

15:56:59 [RRSAgent]
RRSAgent has joined #css
15:56:59 [RRSAgent]
logging to https://www.w3.org/2019/06/19-css-irc
15:57:01 [trackbot]
RRSAgent, make logs public
15:57:01 [Zakim]
Zakim has joined #css
15:57:03 [trackbot]
Meeting: Cascading Style Sheets (CSS) Working Group Teleconference
15:57:03 [trackbot]
Date: 19 June 2019
15:59:42 [dael]
Present+
15:59:49 [dael]
ScribeNick: dael
15:59:57 [plinss]
present+
15:59:57 [astearns]
present+
16:00:29 [Rossen_]
present+
16:01:08 [bdc]
present+
16:01:19 [rachelandrew]
present+
16:01:36 [florian]
present+
16:01:41 [ericwilligers]
present+
16:02:04 [koji]
present+
16:02:15 [AmeliaBR]
present+
16:02:30 [dael]
Topic: Writing Modes
16:02:32 [dael]
astearns: We've got all writing modes folks. At F2F I was told it was a week to get writing modes to rec
16:02:43 [bradk]
bradk has joined #css
16:02:49 [smfr]
smfr has joined #css
16:02:55 [dael]
florian: It was a full time week of work, not a calandar week. Also with osme assumptions that need to be verified
16:03:02 [antonp]
Present+ antonp
16:03:23 [bradk]
present+
16:03:24 [dael]
florian: Assumptions there's one thing that needs to be checked for Gecko conformance. Sent an email to dbaron but haven't seen if he replied
16:03:32 [dael]
astearns: Is there an issue for Gecko?
16:03:34 [leaverou]
present+
16:03:49 [dael]
florian: dbaron did reply but I haven't read. There are failing tests for Gecko, but don't know if there's an issue
16:04:10 [dael]
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
16:04:18 [stantonm]
stantonm has joined #css
16:04:36 [dael]
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
16:04:44 [dael]
astearns: Could I ask you to start that this week?
16:04:51 [dael]
fantasai: I'm at AB meeting so no
16:05:18 [dael]
astearns: By next week I'll expect to hear from florian about Moz issue. Then we can decide how much we can get done after that. I want to make steady work on this week to week
16:05:37 [dael]
florian: Anyone hears this is 40 wrk hours with no one being paid to do it.
16:05:42 [dael]
astearns: And that needs to be solved.
16:05:54 [dbaron]
fwiw I filed https://github.com/w3c/csswg-drafts/issues/4026 in response to Florian's email
16:05:58 [dael]
Topic: end
16:06:09 [dael]
astearns: Anything to add or change in agenda?
16:06:11 [myles]
myles has joined #css
16:06:11 [dael]
Topic: Parent box of run-in or non-principal box
16:06:20 [dael]
github: https://github.com/w3c/csswg-drafts/issues/3158
16:06:20 [futhark]
futhark has joined #css
16:06:27 [myles]
present+ myles
16:06:37 [dael]
fantasai: Trying to load this. I suspect this issue is just verifying something
16:06:44 [chris]
chris has joined #css
16:06:48 [dael]
astearns: This is where you asked for repub so maybe this should be the last.
16:06:48 [futhark]
present+ futhark
16:06:58 [cbiesinger]
present+
16:07:09 [dael]
fantasai: I think we brought this in F2F when requested pub. I think we reviewed
16:07:31 [dael]
astearns: And there are changes from a month ago. No changes to spec since F2F
16:07:46 [dael]
fantasai: I think when we resolved to pub it was including these and we forgot to remove agenda+
16:07:53 [dael]
astearns: We did resolve to repub a month ago?
16:07:56 [dael]
fantasai: Yeah
16:08:01 [dael]
astearns: It's jsut not in this issue.
16:08:03 [chris]
present+
16:08:26 [dael]
astearns: That was display.
16:08:35 [dael]
fantasai: Yes, we don't have resolution for grid. Do for display
16:08:45 [dael]
astearns: Should we re-resolve to publish display?
16:08:54 [dael]
fantasai: I think resolution was in F2F but we can do it again
16:09:01 [dael]
astearns: Objections to republish Display?
16:09:08 [dael]
astearns: There's a DoC and a diff
16:09:12 [chris]
sounds good to me
16:09:16 [dael]
RESOLVED: Republish Display
16:09:25 [chris]
rrsagent, here
16:09:25 [RRSAgent]
See https://www.w3.org/2019/06/19-css-irc#T16-09-25
16:09:28 [dael]
Topic: How to distribute space using flex ratios when the sum is 0?
16:09:32 [dael]
github: https://github.com/w3c/csswg-drafts/issues/3694
16:10:16 [dael]
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
16:10:17 [fantasai]
https://github.com/w3c/csswg-drafts/commit/5a43ab7210d08c9a012a7697eb39a382f8133079
16:10:20 [dael]
fantasai: dif^
16:10:59 [dael]
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
16:11:09 [dael]
astearns: Any comments?
16:11:27 [dael]
astearns: I don't see in diff anything about distributing equally
16:11:37 [dael]
fantasai: [reads]
16:11:51 [dael]
astearns: Alright so default case is in previous text?
16:11:54 [dael]
fantasai: Yes.
16:12:02 [dael]
astearns: Objections?
16:12:14 [dael]
RESOLVED: Accept change in https://github.com/w3c/csswg-drafts/commit/5a43ab7210d08c9a012a7697eb39a382f8133079
16:12:24 [dael]
Topic: "Maximize Tracks" shouldn't distribute equally for flexible tracks
16:12:34 [dael]
github: https://github.com/w3c/csswg-drafts/issues/3693
16:12:50 [dael]
fantasai: this was another fix for errors
16:13:32 [dael]
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.
16:13:48 [dael]
astearns: Okay
16:13:59 [dael]
fantasai: Just fixing an error. Happy is people want to look at it
16:14:17 [dael]
astearns: Given issue discussion looks correct. oriol said it looks good
16:14:34 [dael]
fantasai: These were co-edited with oriol so he thinks they're correct
16:14:45 [dael]
astearns: Comments on this change? Objections?
16:14:55 [dael]
RESOLVED: Accept change in https://github.com/w3c/csswg-drafts/issues/3693
16:15:06 [dael]
Topic: Don't expand flexible tracks under a min-content constraint
16:15:15 [dael]
github: https://github.com/w3c/csswg-drafts/issues/3683
16:15:52 [dael]
fantasai: Case where spec forgot to consider min content correctly. Impl do logical and don't expand track to take up space. hcanging spec to match impl and do thing you expect which is size to smaller end when under min-content constraint.
16:16:24 [dael]
fantasai: If you can shrink something down without overflow then min-content constraint should be that amount and not bigger. spec violated concept, impl did correct. Trying to match them up
16:16:35 [dael]
astearns: Any comment? I not you asked for TabAtkins or Rossen_ to comment
16:16:44 [dael]
fantasai: I'd prefer to get their +
16:16:49 [dael]
TabAtkins: I'll review shortly
16:17:00 [dael]
astearns: Resolve or wait?
16:17:11 [dael]
TabAtkins: I trust fantasai so resolve. If I find a mistake I'll say something
16:17:36 [dael]
Rossen_: On the same page. Proposed doesn't seem crazy, just need to look at overall algo fit. I'm sure fantasai spent more cycles so I trust her
16:17:40 [dael]
astearns: Other comments?
16:17:49 [dael]
astearns: Objections to this change?
16:17:56 [dael]
RESOLVED: Accept proposal in https://github.com/w3c/csswg-drafts/issues/3683
16:18:22 [dael]
astearns: All three of these look like they need tests or need tests verified. Have ther ebeen any?
16:18:33 [dael]
fantasai: None in wpt yet. I'll check with oriol and he might know more
16:18:48 [dael]
astearns: TabAtkins as you review can you check in tests?
16:18:50 [dael]
TabAtkins: Sounds good
16:19:01 [dael]
astearns: Once we have tests anything to keep us from updating CR?
16:19:16 [dael]
fantasai: Prob tests for other things. I think most that should be fixed is but there might be one or two not.
16:19:21 [dael]
astearns: I suspect no DoC yet.
16:19:29 [dael]
fantasai: Right. Bulk of work is that and changes section
16:19:34 [dael]
astearns: Anything else on grid?
16:19:44 [dael]
fantasai: I'm going to say no
16:19:53 [dael]
Topic: Combine forced-color-adjust and color-adjust properties somehow?
16:20:04 [dael]
github: https://github.com/w3c/csswg-drafts/issues/3880
16:20:10 [dael]
astearns: Was on F2F, didn't get to it.
16:20:45 [dael]
fantasai: I think this would have been better at f2F. I don't know if there's anything for call. We need a concrete prop to discuss on a call that handles this issues
16:21:10 [dael]
fantasai: If anyone is interested keep track of issue. Someone needs to make a proposal before we can move forward
16:21:16 [dael]
astearns: Anything else before we punt?
16:21:44 [dael]
AmeliaBR: I have a rough prop 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
16:21:54 [dael]
chris: I think they're better separate. dbaron comment is on the money there
16:22:05 [dael]
astearns: fantasai think we should close no change?
16:22:19 [dael]
fantasai: I'd give another couple weeks to see if we can solve dbaron concerns and if not we close it.
16:22:32 [dael]
astearns: Any other comments?
16:22:41 [dael]
Topic: Disallow repetition of color-scheme keywords?
16:22:53 [dael]
github: https://github.com/w3c/csswg-drafts/issues/3848
16:23:53 [futhark]
I was trying but Tab can present
16:24:50 [dael]
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?
16:25:04 [dael]
TabAtkins: No strong argument either way
16:25:40 [dael]
TabAtkins: originally thoguth 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.
16:25:48 [dael]
TabAtkins: Just have computed value = specified value
16:25:50 [futhark]
I’m fine with either, it’s just that dropping duplicates means having to keep track of them during parsing
16:25:53 [dael]
astearns: Any comments?
16:26:05 [futhark]
Which requires a hash map or something
16:26:07 [dael]
astearns: So close no change?
16:26:13 [dael]
TabAtkins: I don't recall current state
16:26:22 [dael]
TabAtkins: Let me look
16:26:28 [dael]
TabAtkins: It would be changing spec
16:26:30 [fantasai]
Proposal is to resolve no change [in the value] :)
16:26:36 [dael]
astearns: That computed is same as specified value
16:26:38 [dael]
TabAtkins: Yes
16:27:07 [dael]
astearns: Obj to computed value of color-scheme match its specified value?
16:27:14 [dael]
RESOLVED: computed value of color-scheme match its specified value
16:27:24 [dael]
Topic: What happens with multiple <meta>s?
16:27:33 [dael]
github: https://github.com/w3c/csswg-drafts/issues/3846
16:28:14 [dael]
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 are take hte first or take the last valid one. Precedent both ways
16:28:35 [dael]
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
16:28:59 [dael]
AmeliaBR: Since whole point of meta is to get it asap it does make sense. We have examples in HTML that are consistent
16:29:05 [bradk]
bradk has joined #css
16:29:12 [dael]
TabAtkins: theme value also takes the first so it's consistent that way
16:29:45 [dael]
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
16:29:56 [dael]
fantasai: Given oldest is viewport that means using last one
16:30:26 [dael]
TabAtkins: Using last for viewport gives the bad behavior you listed. I think viewport fell out of viewport defined as eq to a stylesheet
16:31:13 [dael]
fantasai: It's an error case. If author wants correct they should not ut multiple. I think it's fine if broken isn't correct. Consistant story for authors is more important that it's always last. Arbiraryness is more disruptive then having to keep all the things
16:31:45 [dael]
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.
16:32:03 [smfr]
q+
16:32:06 [dael]
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.
16:32:38 [dael]
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.
16:32:49 [dael]
TabAtkins: Yeah, ours is messed up. We shoudl not rely on viewport
16:32:52 [astearns]
ack smfr
16:33:19 [dael]
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 sam.e need to figure out dynamically inserted nodes
16:33:42 [dael]
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.
16:33:42 [myles]
q+
16:34:02 [dael]
TabAtkins: Certainly can, but end of head could be different packet and flush the queue. Definitely different behaviors allowed.
16:34:03 [astearns]
ack myles
16:34:11 [fantasai]
s/rely on viewport/rely on viewport behavior/
16:34:27 [dael]
myles: Procedurally meta tag is defined in HTML. If we decide something here is there anyone that can make edits to resolve this?
16:34:44 [AmeliaBR]
We are currently defining the meta value: https://drafts.csswg.org/css-color-adjust-1/#color-scheme-meta
16:34:47 [dael]
TabAtkins: Should try and get agreement on consitent behavior and get that into general meta authoring guidelines
16:34:53 [dael]
astearns: But this needs to be spec elsewhere
16:35:08 [dael]
TabAtkins: Yes, actual definition is in HTML. They are deferring to us on this since we're defining it
16:36:01 [dael]
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?
16:36:19 [dael]
smfr: What happens with other meta like char-set?
16:36:33 [dael]
TabAtkins: I do not know. But those are also more super legacy and likely to be weird
16:36:38 [dael]
astearns: Would be nice to have answer
16:36:41 [dael]
smfr: Agree.
16:36:49 [dael]
fantasai: Don't want to resolve without jen or rachel
16:36:52 [dael]
astearns: Fair
16:37:06 [dael]
fantasai: I believe impact to author is bigger concern then get the earliest possible
16:37:32 [dael]
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.
16:37:57 [dael]
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
16:38:06 [fantasai]
Or even to align most of them
16:38:12 [dael]
astearns: TabAtkins can I ask you to do survey of meta tags that effect css?
16:38:27 [dael]
TabAtkins: Looking at it. It's a consiquence of algo and not states so I'm chasing it down
16:38:43 [dael]
astearns: let's wait on this issue until we get the survey and comments from authoring advocates. Sound good?
16:38:46 [dael]
TabAtkins: mmhmm
16:38:57 [dael]
Topic: column-fill should behave more similarly in paginated and continuous contexts
16:39:05 [dael]
github: https://github.com/w3c/csswg-drafts/issues/4036
16:39:18 [dael]
rachelandrew: Is dbaron on? He'll be needed
16:39:34 [dael]
florian: I think I can represent
16:39:55 [dael]
rachelandrew: There was a comment from Morton (sp?). Maybe worth waiting
16:40:02 [dael]
astearns: Thanks florian but better to move on
16:40:05 [dael]
github: none
16:40:13 [dael]
Topic: Should option/optgroup be able to set counters?
16:40:25 [dael]
github: https://github.com/w3c/csswg-drafts/issues/4004
16:41:10 [dael]
TabAtkins: Technically per CSS they are decendent 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. Howveer FF and previous Edge allow it. Chromium does not
16:41:17 [rachelandrew]
I'll take a better look at issue 3846 and see if I have any thoughts from the authoring pov.
16:41:25 [dael]
TabAtkins: There are use cases for this and a chromium issue to fix and allow setting of counters.
16:41:46 [dael]
TabAtkins: Chrome devs discussing if they should, bbut no conclusion
16:41:58 [dael]
TabAtkins: This may effect related issues like if SVG elements can set counters.
16:42:34 [dael]
TabAtkins: We need to figure out exact terminology. fantasai prop 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.
16:42:56 [dael]
TabAtkins: I'm fine with that. prop is allow optin/optgroup and other things that are like boxes outside the css model to effect counters
16:43:03 [dael]
astearns: sgtm
16:43:16 [dael]
AmeliaBR: Makes sense. I'd like a more explicit definition to what is and isn't like a box
16:43:47 [dael]
TabAtkins: I prefer to define a new term other specs could hook and we define what that is for HTML and SVG. Other mockups could say they are that thing even though they don't generate css boxes
16:43:51 [dael]
astearns: Other comments?
16:43:59 [TabAtkins]
s/mockups/markup languages/
16:44:18 [dael]
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?
16:44:27 [dael]
TabAtkins: I don't think display:none does anything to optin
16:44:42 [dael]
smfr: If you have one of these how do you stop contributing to counters
16:44:52 [Karen]
Karen has joined #css
16:44:56 [dael]
TabAtkins: You don't set the counter. the display:none wasn't an intentional choice, it was legacy
16:45:05 [gtalbot]
gtalbot has joined #css
16:45:27 [dael]
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
16:45:58 [dael]
fantasai: I kinda disagree, I would expect diplay: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
16:46:15 [dael]
TabAtkins: If someone with FF or older Edge can check that link I want to see if display has effect in other
16:46:21 [dael]
smfr: [missed]
16:46:24 [futhark]
Display:none affected in firefox
16:46:31 [smfr]
webkit shows the ‘bar’ in the testcase
16:46:36 [futhark]
that is, removed from select rendering
16:47:14 [dael]
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
16:47:47 [dael]
fantasai: I htink prop 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
16:47:59 [dael]
astearns: Either way impl would need to change b/c we're not interop
16:48:03 [dael]
TabAtkins: Yeah
16:48:17 [dael]
TabAtkins: And we're buckwild with what styles can effect inside a select
16:48:49 [dael]
fantasai: If we have an idea we want to do this how aout TabAtkins and I come up with specific wording that deals with the issues brought up here. We can bring it back and htink about how it effects different impl
16:48:55 [dael]
astearns: Objections to that path?
16:49:10 [dael]
ACTION TabAtkins and fantasai develop spec text for https://github.com/w3c/csswg-drafts/issues/4004
16:49:11 [trackbot]
Created ACTION-881 - And fantasai develop spec text for https://github.com/w3c/csswg-drafts/issues/4004 [on Tab Atkins Jr. - due 2019-06-26].
16:49:24 [dael]
Topic: counter scopes should be based on box tree, not element tree
16:49:27 [dael]
github:
16:49:36 [dael]
github: https://github.com/w3c/csswg-drafts/issues/674
16:50:02 [dael]
TabAtkins: fantasai added the agenda. I'm curious why. There's a person asking about implications but don't know what to discuss
16:50:11 [dael]
fantasai: I don't remember
16:50:32 [dael]
astearns: We have a comment with different cases
16:50:57 [dael]
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
16:51:10 [dael]
astearns: My reading is here are the cases that show a difference. not sure they're picking a side
16:51:25 [dael]
Topic: make `text` of `leading-trim` interoperable?
16:51:27 [fantasai]
I think the issue was https://github.com/w3c/csswg-drafts/issues/674#issuecomment-333541595
16:51:31 [dael]
github: https://github.com/w3c/csswg-drafts/issues/3978
16:51:40 [dael]
astearns: This is F2F leftover
16:53:03 [dael]
koji: The leading-trim has text repesenting text-topa nd text-bottom. text-top and -bottom isn't browser interop or even on same browser across OSs. prop is to define. One prop is to use specific asender and descender. Another is em height. This isn't defined in CSS but algo is from geck
16:53:12 [dael]
koji: Seems to do a good job for non-tall scripts
16:54:02 [dael]
fantasai: I don't think I agree with a platform text value for this metric. I think people looking to trima re 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
16:54:15 [dael]
fantasai: Interesting question of these metrics which do we want
16:54:31 [dael]
myles: Like to not parse tables myself. Likely look up the functions. not sure if that defetes purpose.
16:54:38 [dael]
fantasai: It means you cant read the metrics?
16:54:51 [dael]
myles: Can but takes a lot of code to get the table and figure out the values and convert
16:55:02 [dael]
koji: If you call core text ascendant and descendant aren't interop
16:55:03 [fantasai]
s/metrics/sTypo metrics/
16:55:32 [dael]
myles: If there was a interop field we prop would jsut hook that field up to core text field which deferts purpose of interop field so that's unfortunate
16:56:21 [dael]
koji: Clarify, the division of leading trim where authors use webfonts so it's the same bianary on all platforms and borwsers. 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
16:56:25 [fantasai]
+1 to koji
16:57:04 [dael]
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.
16:57:25 [dael]
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
16:57:36 [dael]
chris: Probably not. Was the case that they all used different tables
16:57:57 [dael]
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
16:58:38 [dael]
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
16:58:45 [dael]
astearns: I'm not sure browsers are using same metrics
16:59:14 [dael]
koji: Blink we use same metric as one platofrm uses. Even if same web fonts blink uses different metrics depending on platform
16:59:22 [dael]
koji: We rely on platform API to read metrics
16:59:28 [fantasai]
And this drives authors crazy
16:59:52 [dael]
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
17:00:28 [dael]
koji: At least for new things I'd like itneroperable ones. Some reasons we may need existing ones, legacy reasons or future platofrm behavior. in those cases I'm fine to provide options.
17:00:32 [fantasai]
+1
17:00:49 [dael]
astearns: Should we continue later since we're at time?
17:00:54 [dael]
myles: Good idea
17:01:01 [dael]
astearns: Let's continue in GH and we'll come back
17:01:06 [dael]
topic: end
17:01:12 [dael]
astearns: Thanks everyone and we'll talk next week
17:01:40 [futhark]
futhark has joined #css
17:02:49 [chris]
Ah how naive I was to think everyone would use the typographic ascender/descender eventually. From CSS2: https://www.w3.org/TR/2008/REC-CSS2-20080411/fonts.html#cap
17:22:25 [astearns]
trackbot, end meeting
17:22:25 [trackbot]
Zakim, list attendees
17:22:25 [Zakim]
As of this point the attendees have been dael, plinss, astearns, Rossen_, fantasai, bdc, rachelandrew, florian, ericwilligers, koji, AmeliaBR, antonp, bradk, leaverou, myles,
17:22:28 [Zakim]
... futhark, cbiesinger, chris
17:22:33 [trackbot]
RRSAgent, please draft minutes
17:22:33 [RRSAgent]
I have made the request to generate https://www.w3.org/2019/06/19-css-minutes.html trackbot
17:22:34 [trackbot]
RRSAgent, bye
17:22:34 [RRSAgent]
I see no action items