<scribe> ScribeNick: 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 calandar week. Also with osme assumptions that need to be verified
... 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

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 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

florian: Anyone hears this is 40 wrk 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

end

astearns: Anything to add or change in agenda?

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 pub. 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 pub it was including these and we forgot to remove agenda+

astearns: We did resolve to repub a month ago?

fantasai: Yeah

astearns: It's jsut not in this issue.
... 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?
... There's a DoC and a diff

<chris> sounds good to me

RESOLUTION: Republish Display

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: dif^
... 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?
... 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?

RESOLUTION: 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
... 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?

RESOLUTION: 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. 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.
... 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

astearns: Any comment? I not you asked for TabAtkins or Rossen_ to comment

fantasai: I'd prefer to get their +

TabAtkins: I'll review shortly

astearns: Resolve or wait?

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 algo fit. I'm sure fantasai spent more cycles so I trust her

astearns: Other comments?
... Objections to this change?

RESOLUTION: 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 ther ebeen 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: Prob 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

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 prop to discuss on a call that handles this issues
... 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 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

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

<futhark> I was trying but Tab can present

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?
... No strong argument either way
... 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.
... Just have computed value = specified value

<futhark> I’m fine with either, it’s just that dropping duplicates means having to keep track of them during parsing

astearns: Any comments?

<futhark> Which requires a hash map or something

astearns: So close no change?

TabAtkins: I don't recall current state
... Let me look
... It would be changing spec

<fantasai> Proposal is to resolve no change [in the value] :)

astearns: That computed is same as specified value

TabAtkins: Yes

astearns: Obj to computed value of color-scheme match its specified value?

RESOLUTION: computed value of color-scheme 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 are take hte first or take the last valid one. Precedent both ways
... 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
... 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 eq to a stylesheet

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

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 shoudl 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 sam.e need to figure out dynamically inserted nodes
... 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 consitent behavior and get that into general meta authoring guidelines

astearns: But this needs to be spec 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 jen or rachel

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 consiquence of algo and not states 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

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 Morton (sp?). Maybe worth waiting

astearns: Thanks florian but better to move on

github: none

Should option/optgroup be able to set counters?

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

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

<rachelandrew> I'll take a better look at issue 3846 and see if I have any thoughts from the authoring pov.

TabAtkins: There are use cases for this and a chromium issue to fix and allow setting of counters.
... Chrome devs discussing if they should, bbut no conclusion
... This may effect related issues like if SVG elements can set counters.
... 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.
... I'm fine with that. prop 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 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

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

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 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

astearns: Either way impl would need to change b/c we're not interop

TabAtkins: Yeah
... And we're buckwild with what styles can effect inside a select

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

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 - And fantasai develop spec text for https://github.com/w3c/csswg-drafts/issues/4004 [on Tab Atkins Jr. - due 2019-06-26].

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

make `text` of `leading-trim` interoperable?

<fantasai> I think the issue was https://github.com/w3c/csswg-drafts/issues/674#issuecomment-333541595

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

astearns: This is F2F leftover

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
... 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 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
... 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 defetes purpose.

fantasai: It means you cant 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 prop would jsut hook that field up to core text field which deferts purpose of interop field so that's unfortunate

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

<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.
... 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 platofrm uses. Even if same web fonts blink uses different metrics depending on platform
... 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 itneroperable ones. Some reasons we may need existing ones, legacy reasons or future platofrm 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

end

astearns: Thanks everyone and we'll talk next week

<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

<astearns> trackbot, end meeting

This is scribe.perl Revision: 1.154  of Date: 2018/09/25 16:35:56  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00)

Succeeded: s/rely on viewport/rely on viewport behavior/
Succeeded: s/mockups/markup languages/
Succeeded: s/metrics/sTypo metrics/
Default Present: dael, plinss, astearns, Rossen_, fantasai, bdc, rachelandrew, florian, ericwilligers, koji, AmeliaBR, antonp, bradk, leaverou, myles, futhark, cbiesinger, chris
Present: dael plinss astearns Rossen_ fantasai bdc rachelandrew florian ericwilligers koji AmeliaBR antonp bradk leaverou myles futhark cbiesinger chris
Found ScribeNick: dael
Inferring Scribes: dael

WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth

Found Date: 19 Jun 2019
People with action items: 

WARNING: IRC log location not specified!  (You can ignore this 
warning if you do not want the generated minutes to contain 
a link to the original IRC log.)