13:01:27 <RRSAgent> RRSAgent has joined #css
13:01:27 <RRSAgent> logging to https://www.w3.org/2019/06/04-css-irc
13:01:29 <trackbot> RRSAgent, make logs public
13:01:29 <Zakim> Zakim has joined #css
13:01:31 <trackbot> Meeting: Cascading Style Sheets (CSS) Working Group Teleconference
13:01:31 <trackbot> Date: 04 June 2019
13:01:39 <dbaron> Zakim, remind us in 9 hours to go home
13:01:39 <Zakim> ok, dbaron
13:02:03 <dbaron> Meeting: Cascading Style Sheets (CSS) Working Group Face-to-face meeting
13:03:42 <jlin> jlin has joined #css
13:05:12 <una> una has joined #css
13:09:19 <jihye> jihye has joined #css
13:09:19 <dauwhe> present+
13:10:04 <stantonm> stantonm has joined #css
13:13:58 <rachelandrew> present+
13:18:36 <antonp> antonp has joined #css
13:23:21 <jihye> present+
13:25:04 <heycam> present+
13:25:43 <myles> myles has joined #css
13:26:06 <astearns> present+
13:26:09 <myles> present+ myles
13:26:12 <fremy> fremy has joined #css
13:27:43 <heycam> ScribeNick: heycam
13:27:43 <jensimmons> jensimmons has joined #css
13:27:57 <jensimmons> present+
13:28:00 <Rossen_> Rossen_ has joined #css
13:28:01 <flackr> present+
13:28:15 <TabAtkins> present+
13:28:19 <Rossen_> Rossen Atanassov, Microsoft
13:28:22 <astearns> Alan Stearns, Adobe
13:28:25 <flackr> Rob Flack, Google
13:28:36 <jihye> Jihye Hong, LGE
13:28:38 <oriol> Oriol Brufau, Igalia
13:28:40 <tantek> tantek has joined #css
13:28:40 <AmeliaBR> AmeliaBR has joined #css
13:28:47 <dbaron> L. David Baron, Mozilla
13:28:51 <heycam> Cameron McCormack, Mozilla
13:28:52 <TabAtkins> Tab Atkins, Google
13:28:56 <AmeliaBR> Amelia Bellamy-Royds, Invited Expert
13:29:05 <bkardell_> bkardell_ has joined #css
13:29:05 <stantonm> Stanton Marcum, Amazon
13:29:06 <koji> Koji Ishii, Googe
13:29:07 <jensimmons> Jen Simmons, Mozilla
13:29:10 <tantek> Tantek Çelik, Mozilla
13:29:11 <rachelandrew> Rachel Andrew, Fronteers
13:29:13 <tantek> present+
13:29:19 <AmeliaBR> present+
13:29:22 <bkardell_> Brian Kardell, Igalia and JS Foundation
13:29:23 <chris> chris has joined #css
13:29:26 <bkardell_> present+
13:29:30 <una> present+
13:29:56 <myles_> myles_ has joined #css
13:29:57 <dauwhe> Dave Cramer, Hachette Livre
13:29:59 <chris> present+
13:30:07 <hober> hober has joined #css
13:30:08 <florian> Florian Rivoal, Invited Expert
13:30:19 <florian> present+
13:30:39 <heycam> Topic: additional resource state pseudo-classes for media elements
13:30:44 <heycam> github: https://github.com/w3c/csswg-drafts/issues/3821
13:30:45 <bkardell_> s/JS Foundation/Open JS Foundation
13:31:08 <iank_> Ian Kilpatrick, Google
13:31:10 <heycam> hober: we currently have playing and pause pseudo classes, which media elements match when they are playing or paused
13:31:18 <fremy> present+
13:31:21 <heycam> ... the use case is, things like custom media controls, with a unified play/pause button
13:31:34 <oriol> present+
13:31:38 <heycam> ... there are a handful of other common media element states that have a similar rationale for exposing to CSS
13:31:45 <heycam> ... stuff that people are currently using script for
13:31:50 <heycam> ... this issue is the 3 easy ones
13:31:59 <heycam> ... 1 is whether or not the element is muted
13:32:10 <heycam> ... you may have a mute button, styled volume slider
13:32:13 <heycam> ... very similar to playing/paused
13:32:17 <heycam> ... hope it's uncontroversial
13:32:20 <heycam> ... other 2 are a bit weird
13:32:28 <heycam> ... the HTMl spec has a concept of media being stalled
13:32:44 <heycam> ... and you can see examples of custom UI when media is stalled on popular sites like YouTube, netflix
13:32:47 <heycam> ... the spinner looks different
13:32:55 <heycam> ... if we could provide styling for that it would be nice
13:33:03 <hober> present+
13:33:15 <dbaron> Present+
13:33:16 <tantek> q+ to ask about "buffering" vs. "streaming connection broken" (have seen different UI)
13:33:20 <heycam> ... the 3rd one is: media elements have a seeking state, which is useful for cases like when you are displaying custom controls, but seeking is happening due to other controls
13:33:37 <heycam> ... maybe seeking with a remote control, but you want you custom control to do a different thing
13:33:37 <tantek> FYI: https://html.spec.whatwg.org/multipage/media.html#htmlmediaelement
13:33:44 <heycam> ... so the HTML spec has the right hooks here
13:33:49 <heycam> ... just need something in CSS to expose them
13:33:59 <heycam> ... so 3 proposed pseudo classes: muted, stalled, seeking
13:34:03 <heycam> florian: what is seeking as a state
13:34:12 <heycam> hober: while you're seeking.  if you using the scrubber
13:34:16 <heycam> AmeliaBR: like an active state
13:34:17 <fremy> q+ to talk about additional states
13:34:27 <TabAtkins> q+
13:34:39 <Rossen_> ack dbaron
13:34:39 <Zakim> dbaron, you wanted to ask whether :muted would cover tab-level, app-level, or system-level muting (I suspect not, but want to ask)
13:34:47 <heycam> dbaron: there's ofte na lot of ways to mute something
13:35:01 <heycam> ... my guess here this ignores your tab is muted, hardware control is muted, is that right?
13:35:12 <Rossen_> q?
13:35:22 <heycam> hober: I think that's right.  but I'm not sure.  I think this shouldb e tied to the host lang's definition
13:35:26 <heycam> dbaron: ok so the HTML definition
13:35:27 <tantek> ack tantek
13:35:27 <Zakim> tantek, you wanted to ask about "buffering" vs. "streaming connection broken" (have seen different UI)
13:35:29 <Rossen_> ack tantek
13:35:43 <heycam> tantek: I like the general direction of the proposal, +1 on them.  even the less common features
13:36:00 <heycam> ... this shook loose memories of things I worked on right before Mozilla, doing HTML5 consulting, setting up video UIs
13:36:07 <heycam> ... took a bunch of notes which I forgot about that
13:36:13 <heycam> ... I needed this in 2010
13:36:40 <heycam> ... the :stalled pseudo class, I've seen different UI between buffering to show something, vs the network connection is gone
13:36:47 <heycam> ... even if you're in this "I want to play" state
13:36:52 <heycam> ... wondering if it's worth distinguishing
13:37:00 <heycam> hober: I agree there's a use case there
13:37:04 <florian> +1 to tantek
13:37:10 <heycam> ... I think network state is a little more general.  that's going to affect hte page, not just the media elements
13:37:15 <heycam> tantek: but that's a differnt can of worms
13:37:21 <heycam> hober: I'd rather tacklet that as a different thing
13:37:22 <Rossen_> q?
13:37:28 <heycam> tantek: I'm saying I'd rather not, since it is a can of worms
13:37:39 <heycam> hober: could you propose another pseudo for this?
13:37:52 <heycam> tantek: do you want one pseudo that means either of that?  two for the specific states?
13:38:01 <heycam> hober: I'd be happy to delegate this to HTML
13:38:12 <heycam> ... some HTML spec refactoring is needed anyway, for stalled
13:38:17 <heycam> ... from our perspective, we'd defer to the host language
13:38:20 <jensimmons> do these apply to <audio> as well as <video>? I’d assume so…
13:38:23 <heycam> tantek: specifially the HTML media element interface?
13:38:24 <heycam> hober: yes
13:38:46 <jensimmons> q+
13:38:50 <heycam> emilio: images have differnet set of states.  broken, loaded.  Gecko hsa internal pseudos for these
13:38:57 <Rossen_> q?
13:38:59 <heycam> ... I wonder if it is useful to try to expose a common set of pseudos
13:39:09 <heycam> fremy: I was going ot suggest the same
13:39:20 <heycam> hober: in the past when this has come up, we've agreed we should have more general subresource state exposing
13:39:26 <heycam> ... was hoping to not get bogged down on that too much
13:39:34 <heycam> ... there's specific use cases for media in custom media controls
13:39:34 <tantek> note that the HTMLMediaElement does distinguish network state a bit:  NETWORK_EMPTY, NETWORK_IDLE, NETWORK_LOADING, NETWORK_NO_SOURCE
13:39:42 <heycam> ... I agree it should be coherent with a more general thing
13:39:46 <heycam> ... so we should keep that in mind
13:39:54 <heycam> ... but the last few times it's come up over 10 years, we end up not doing it
13:39:57 <dbaron> https://github.com/w3c/csswg-drafts/issues/3134 is about image state pseudo-classes
13:40:10 <Rossen_> ack fremy
13:40:10 <Zakim> fremy, you wanted to talk about additional states
13:40:15 <heycam> fremy: we don't need to standardize pseudos for all possible cases
13:40:24 <jensimmons> anything to make doing this kind of stlying possible, without replacing everything with JS, would be ideal: https://thewebahead.net/110
13:40:28 <heycam> ... you say you're sticking to the HTML spec's state.  ther's already an error state in there
13:40:34 <heycam> hober: I'm happy for someone to propose those
13:40:46 <heycam> fremy: seems reasonable to want to style them differently if you're on the network, etc.
13:40:56 <heycam> ... in the specific cases for media controls you do want to know about the network state
13:41:16 <heycam> ... in my initial proposal it was with video in mind.  I think it's a good idea to see how we can map them
13:41:24 <heycam> ... if you end up in an error state, you want to show that in the UI
13:41:46 <tantek> q+ to ask if :seeking is *while* the user is dragging the seeker, only upon release, or both?
13:41:57 <heycam> TabAtkins: hober's list of things are video specific
13:41:57 <Rossen_> ack TabAtkins
13:42:00 <heycam> ... two specific questions
13:42:01 <jensimmons> q-
13:42:09 <heycam> ... 1st, the current definition of playing says it subsumes seeking and stalled
13:42:15 <heycam> ... keeping that?
13:42:16 <heycam> hober: yes
13:42:36 <heycam> TabAtkins: ok cool.  2nd, :muted is good, do we want a general volume state?  low-volume high-volume?
14:03:42 <RRSAgent> RRSAgent has joined #css
14:03:42 <RRSAgent> logging to https://www.w3.org/2019/06/04-css-irc
14:03:46 <heycam> ... currently, if you set the volume from script, and it doesn't work, you can tell?
14:03:46 <heycam> hober: yes
14:03:47 <fremy> @hober: `:user-locked-volume` ?
14:03:55 <Chris__> Chris__ has joined #css
14:03:55 <heycam> AmeliaBR: if I mute the whole laptop, is that included in this?
14:03:56 <Zakim> Zakim has joined #css
14:04:12 <heycam> hober: I don't know if system muted state on desktop OS affects that
14:04:18 <heycam> ... if it did, I would expect it to affect this
14:04:21 <chris> rrsagent, here
14:04:21 <RRSAgent> See https://www.w3.org/2019/06/04-css-irc#T14-04-21
14:04:32 <heycam> AmeliaBR: either way there's a clear defn in HTML?  and it's already exposed to script?
14:04:32 <heycam> hober: yes
14:04:44 <heycam> hober: AmeliaBR proposed :adjustable-volume.  so it's the opposite of that
14:04:57 <jensimmons> q+
14:04:59 <heycam> TabAtkins: :volume-locked
14:05:10 <heycam> ... expresses the semantic that you'd style on, doesn't need :not()
14:05:36 <heycam> ... but given other suggestion for a volume pseudo, you could merge this into a pseudo that takes a keyword
14:05:40 <TabAtkins> https://www.irccloud.com/pastebin/rPsIGCzk/
14:05:48 <heycam> hober: on Windows, muted and volume are independent states
14:05:56 <heycam> :volume( locked || muted || <volume-value> )
14:05:56 <heycam> <volume-value> = [ '<' | '>' ] '='? [ <number [0,1]> | <percentage [0%,100%]> ]
14:06:08 <fremy> +1 on TabAtkins's proposal
14:06:11 <astearns> ack florian
14:06:20 <heycam> florian: I don't think this varies per element.  maybe a MQ is better?
14:06:27 <heycam> hober: I think the use case is tied to media controls
14:06:35 <heycam> florian: but you can't have one media element which is locked and one is not?
14:06:39 <Rossen_> q+ fremy
14:06:43 <heycam> hober: I think it makes sense to be symmetric with the other pseudos
14:06:50 <heycam> ... but I concede the point it's a system wide thing
14:06:56 <fremy> q-
14:07:07 <Rossen_> ack jensimmons
14:07:18 <heycam> jensimmons: a few quick examples in the thread
14:07:23 <TabAtkins> :volume(locked < 50%), for example
14:07:31 <dbaron> s/a few/request a few/
14:07:32 <heycam> hober: of Tab's syntax, or when you would use this?
14:07:33 <TabAtkins> :volume(muted)
14:07:34 <heycam> jensimmons: when you'd use it
14:07:42 <florian> q+
14:07:53 <hober> div.controls:volume(locked) .volume { display: none; }
14:07:57 <heycam> TabAtkins: for :volume(locked), you'd display:none your custom volume button
14:08:20 <heycam> AmeliaBR: should the pseudo refer to the fact that the volume control works or wouldn't work
14:08:23 <heycam> hober: my case is for the latter
14:08:28 <TabAtkins> `video:volume(locked) + .controls > .volume { display: none; }`
14:08:29 <heycam> ... shouldn't display if it's going to be futile
14:08:37 <Rossen_> q?
14:08:49 <heycam> fremy: if you set vol to 0, that stil lmutes the video?
14:08:55 <heycam> hober: depends on the platform
14:09:01 <heycam> ... not on Windows.  unmuted at volumnet 0
14:09:18 <heycam> hober: on iOS you can mute audio tracks on media elements
14:09:25 <heycam> fremy: using volume 0?
14:09:27 <heycam> hober: using .muted
14:09:43 <heycam> chris: when you unmute you want to go back to the old volume
14:10:03 <heycam> florian: for this one and the prev one, wondering if this is practical as a pseudo, given the controls aren't usually a descendant
14:10:06 <heycam> hober: it's often a sibling
14:10:16 <Rossen_> ack florian
14:10:22 <heycam> hober: that's the same as the existing :play / :paused pseudos
14:10:35 <heycam> hober: I really like Tab's locked suggestion.  either as the one off or the general proposal
14:10:47 <heycam> ... since we resolved on :muted.  I'm happy to resolve on :volume-locked, and discuss merging later
14:11:03 <heycam> AmeliaBR: for the parenthesized idea, volume(max/min) might also be useful
14:11:21 <heycam> TabAtkins: are min/max different from 0% / 100%?
14:11:29 <heycam> AmeliaBR: do we want to expose %s in a selector?
14:12:02 <heycam> emilio: we don't have any other pseudos with numeric values inside them
14:12:14 <heycam> hober: I think it's a good argument for going with the one off for now
14:12:41 <heycam> RESOLVED: Add :volume-locked.
14:13:48 <heycam> Topic: :has and :within selectors
14:14:18 <heycam> bkardell_: we had 100 proposals to get around not having these. they're all happening in their own worlds,  would be good to have some of us try to wrangle those into something coherent
14:14:24 <heycam> ... to make sure we answer the use cases that exist
14:14:34 <heycam> .. would anyone be interested in working on that with me?
14:14:59 <heycam> florian: there's a long tail of something somethin within that are all kind of reasonable.  but not reasonable to have 50 different selectors
14:15:24 <heycam> ... I think there were impls constraints in Gecko that within is doable, you can do 2 or 3, but not 50
14:15:48 <heycam> florian: so should we fit which things are more worthy, but if we're going to do :has() ...
14:15:52 <heycam> emilio: doing :has() seems harder than adding more bits
14:16:01 <heycam> bkardell_: is there a limited thing that's not :has()?
14:16:06 <heycam> ... to cover enough use cases?
14:16:12 <heycam> AmeliaBR: a simple selector inside?
14:16:20 <heycam> emilio: the reason within is more reasonable is you know what you're going to match against
14:16:40 <heycam> ... do don't need to walk the whole subtree
14:16:48 <tantek> which issue are we discussion?
14:16:55 <tantek> q?
14:17:03 <heycam> AmeliaBR: it's the diff between "focus changed, let's focus-within all the ancestors, vs generic selector match start from an ancestor"
14:17:13 <heycam> fremy: for useful but less frequent, you could have a single bit
14:17:16 <heycam> emilio: :something-within
14:17:37 <heycam> fremy: but still have 50 different pseudso
14:17:49 <fantasai> fremy: maybe just have an "other" bit that catches everything, and pull out the ones that are populare into their own bits
14:17:54 <heycam> s/fremy/florian/
14:18:07 <heycam> ^ that's two lines up fremy
14:18:37 <heycam> bkardell_: as an author this was my #1 frustration
14:18:45 <heycam> ... if we know we can't do it, let's admit it
14:18:56 <heycam> TabAtkins: was my impression that generic :has we don't expect to be possible to impl reasonably
14:19:07 <heycam> AmeliaBR: I think there's agreement on the authoring use case, constraint is the impl side
14:19:21 <heycam> ... people faimilar with selector matching engines should get together to hash out what's practical
14:19:37 <tiger> tiger has joined #css
14:19:46 <heycam> fantasai: it's doable, just not easy
14:19:49 <heycam> florian: not performantly enough
14:20:07 <heycam> fantasai: if someone were to figure out how to impl it performantly ...
14:20:10 <tantek> what I'm hearing is: needs incubation
14:20:17 <heycam> TabAtkins: it will never be performant to do body:has(...)
14:20:19 <tantek> let's punt it to WICG
14:20:27 <Rossen_> q?
14:20:33 <fantasai> emilio: you can use memory instead of time...
14:20:57 <dbaron> (There's also the side question of whether :subject might be more implementable than :has()...)
14:21:02 <heycam> AmeliaBR: the other side to attract. if the way forward is with dedicated something-within selectors, we should know from author side what the demand is
14:21:11 <heycam> bkardell_: I just want to know how to move forward
14:21:20 <heycam> emilio: if someone wants to impl :has I'm happy to mentor...
14:21:27 <tantek> bkardell: "need a group of people to figure out how to move forward"
14:21:31 <heycam> fantasai: :has-child is a lot easier to impl, that would solve many use cases still
14:21:32 <tantek> sounds like a WICG effort
14:22:18 <heycam> Topic: Password reveal pseudo-element and pseudo-class
14:22:20 <heycam> https://github.com/w3c/csswg-drafts/issues/3934
14:22:22 <fantasai> github: https://github.com/w3c/csswg-drafts/issues/3934
14:22:36 <heycam> fantasai: Greg posted an issue where he wanted to ask for a pseudo-element
14:22:39 <heycam> dbaron: and pseudo clas
14:22:49 <heycam> fantasai: for when passwords have a show the password switch
14:23:13 <heycam> dbaron: [demos what the Windows UI looks like]
14:26:14 <heycam> dbaron: in many cases, users with good 30 char passwords, want to make sure they didn't make a typo
14:26:21 <heycam> ... Edge has this, and it's nice
14:26:32 <heycam> hober: sites work around this by writing terrible scripts to change input type=password
14:26:37 <heycam> emilio: that is a security issue
14:26:43 <heycam> hober: harder for password autofill to work
14:26:59 <fremy> q+
14:27:08 <heycam> jensimmons: is the proposal to create a pseudo to style the two states?
14:27:19 <heycam> AmeliaBR: the proposal is to style it if the UA provides it
14:27:29 <heycam> dbaron: two pieces.  one piece is a pseudo class that matches the control as a whole, when the pw is revealed
14:27:31 <chris> Android also has this reveal-password button
14:27:40 <heycam> ... the other is a pseudo element, that matches the toggle thing, so you can use a different image for it
14:27:40 <florian> q+
14:27:48 <heycam> fantasai: my qn is, is it important to make this stylable?
14:28:24 <heycam> Rossen_: that's what we started with.  back in IE 10, there was a demand for this, botth the x button on input type text, and the reveal on password
14:28:39 <tantek> the "x" button? is that the "clear field" button?
14:28:41 <heycam> ... and so there was a lot of web sites that started to fight with the pseudo.  until they figured out how to use it
14:28:46 <heycam> ... at the time, it was a prefixed impl
14:29:00 <heycam> Rossen_: most sites ended up with two "x"s, or two reveal buttons
14:29:08 <fremy> @tantek: yes
14:29:22 <heycam> ... having a predictable way to turn it off, at least, is why we ended up with this being stlyable
14:29:36 <heycam> fantasai: I'm figuring there's a use case for having it.  but is the use case strong for stylable?
14:29:49 <heycam> Rossen_: it's as much as making any other control stylable.  should contrls be looking native?  stylable?
14:30:01 <jensimmons> q+
14:30:01 <dbaron> (another thing that goes wrong when people use input type=text for things that are actually passwords is that mobile keyboards might try to remember the password for their autocompletion, whereas I think they're pretty good about not remembering things that go in password controls)
14:30:05 <heycam> fantasai: but it should be keying off the font?
14:30:11 <heycam> ... should use the same color and size as the text inside the box
14:30:16 <heycam> Rossen_: by default that's our Edge behavior
14:30:20 <heycam> ... not sure what every author will want
14:30:26 <myles_> myles_ has joined #css
14:30:31 <heycam> ... they might want this google style button with a large eye
14:30:41 <myles_> q+
14:30:42 <fremy> q-
14:30:52 <tantek> "large eye" so is that asking for both dimensions and image customizability?
14:30:55 <heycam> una: every time I see form elements, I can see designers wanting to match brand styling
14:31:11 <heycam> ... makes sense to adjust the element with a pseudo.  that's a common pattern, would be good to make it easier for developers
14:31:19 <Rossen_> q?
14:31:23 <AmeliaBR> q+
14:31:31 <Rossen_> ack florian
14:31:44 <heycam> florian: 2 points.  I'm confused by the pseudo class, not so much with the pseudo element apart from hiding it
14:31:56 <heycam> ... just changing the color of it sounds weird
14:32:10 <fremy> @Chris__: (to answer your long-gone question, the Edge one used a push-to-reveal as well, but for screen readers, that wasn't possible, so we switched to push-to-toggle-reveal instead so that screen readers can switch to text input)
14:32:11 <fantasai> s/weird/weird if you don't know really what it is/
14:32:15 <heycam> ... second, we have from a year back, a resolution for something that hasn't made it into a spec, which is complementary to this
14:32:23 <heycam> ... opt in for a non-password field to look like a password field
14:32:32 <una> q+
14:32:32 <heycam> ... I think we resolved on something in CSS UI to opt in to the hidden display
14:32:37 <heycam> ... these two thins probably interact
14:33:02 <heycam> dbaron: one thing I missed saying is that the intent of the pseudo element that the things that are stylable are widht, height, background-image
14:33:11 <heycam> Rossen_: and it could have state
14:33:19 <heycam> ... if it's sticky, e.g.
14:33:29 <astearns> yeti peeking at your password UI: https://codepen.io/ankitashodhan/pen/mxxjpY
14:33:48 <Rossen_> q?
14:33:55 <Rossen_> ack jensimmons
14:34:09 <heycam> jensimmons: I agree with una that the use case is strong.  replacing the eyeball with an icon that matches the styling of the site is one
14:34:20 <heycam> ... someone might want to put a red border around the input when pw is revealed
14:34:36 <heycam> ... I think CSSWG so far has been reluctant to allow styling of form controls
14:34:48 <heycam> ... but this is a newer one, and i think we're moving towards solving stylability
14:34:51 <Rossen_> ack myles_
14:34:56 <fremy> For people curious, here is when we standardized Apple's proposal:
14:34:57 <heycam> myles_: this idea of the reveal pw icon is a good one
14:34:57 <fremy> RESOLVED: input-security: auto|none in UI 4 and applies to input type=password only
14:35:01 <bkardell_> is it actually a newer control?
14:35:07 <fremy> https://github.com/w3c/csswg-drafts/issues/2495#issuecomment-380397331
14:35:14 <heycam> ... if sites start changing icons, maybe every site will have a different looking passwrod field
14:35:20 <heycam> ... which is harmful for web security
14:35:27 <heycam> ... trains users to type pw into sketchy things
14:35:36 <tantek> q?
14:35:50 <fantasai> myles: good proposal, but replacing image seems problematic
14:36:00 <tantek> But Google does it (changes the icon) so it must be ok right?
14:36:09 <heycam> myles_: on iOS it's a deliberate feature to make input type password look the same as system password entry fields
14:36:16 <fremy> q+ since I'm confused with what myles said
14:36:21 <fremy> q+
14:36:44 <heycam> chris: we don't allow style sheets to change the lock icon in the address bar
14:36:52 <fantasai> Florian^: if all password fields look the same, then users are used to typing into things that looke like that ... if they all look different, then they adapt to typing in the password into anything
14:36:54 <Rossen_> q?
14:37:05 <heycam> fremy: but you're already shipping input-security
14:37:46 <Rossen_> ack AmeliaBR
14:37:51 <fremy> q-
14:38:01 <heycam> AmeliaBR: heard a strong need for something not in the proposal, which is detecting whether the UA will be displaying a pw reveal
14:38:05 <heycam> ... or the clear field button
14:38:16 <heycam> ... argument for styling is more superfluous
14:38:17 <jensimmons> q+
14:38:34 <heycam> ... from usability perspective, having these things look different everywhere isn't necessarily good for users
14:38:50 <heycam> ... I was fighting recently with a site that was breaking the pw reveal button, because the focus kept getting lost
14:39:00 <heycam> ... could imagine all kinds of way s to make the button unusable
14:39:16 <Rossen_> q?
14:39:19 <tantek> "fussy designer could get rid of this usability feature" <-- this
14:39:34 <heycam> ... in general, CSS doesn't mandate good design, authors can shoot themselves in the foot, but when this is a very strong security / usability issue, not sure what the argument is
14:39:50 <florian> q+
14:39:55 <heycam> .. other thing was what Jen brought up; we have this much broader scope of exposing subcomponents of replaced elements, if we do this it should maybe be part of this much larger scope
14:40:04 <heycam> jensimmons: that wasn't my point
14:40:10 <heycam> una: I wanted to speak to AmeliaBR's point
14:40:13 <Rossen_> ack una
14:40:20 <heycam> ... I can see the perspective of wanting similar UX
14:40:27 <heycam> ... right now things look diff because people must reimpl them
14:40:33 <heycam> ... so I think it could help with unification
14:40:37 <heycam> ... having a standard for pw fields
14:40:42 <AmeliaBR> q+
14:40:42 <heycam> ... and could be overridden if the team wants to
14:40:56 <tantek> The pseudo-element does sound like a bit of a footgun, as it burdens webdevs with doing it in such a way that works across input fields on different desktop/mobile OSs/platforms etc. which is a lot more than they may expect they have to do
14:41:05 <heycam> ... to the second point, does this span any replaced element?  what about telephone fields?  maybe validating want to little check mark in there
14:41:12 <heycam> ... should we be thinking about form elements as a whole?
14:41:22 <heycam> fantasai: that's a good point that that exists
14:41:27 <Rossen_> q?
14:41:39 <heycam> ... placing that check mark and making sure it doesn't overlap the contents of the field.  this doesn't solve that
14:42:03 <heycam> ... I would be curious to know, if we have this pw reveal implemented across all browsers, and waited a year, would there still be such a high demand for doing custom ones?  or would it be adequate to just let the browser do it?
14:42:16 <heycam> una: I've seen very design system have different designs for these elements, so I think the demand iwll continue
14:42:37 <heycam> Rossen_: so eveyrthing else would look as designed, except hte icon?
14:42:44 <chris> q?
14:42:44 <heycam> fantasai: but these icons don't have a lot of presence
14:43:00 <heycam> una: looking at these 2 examples.  the material design one.  the second one was the Edge one
14:43:07 <heycam> ... can't really mix and match them
14:43:11 <Rossen_> q?
14:43:27 <Rossen_> ack dbaron
14:43:37 <heycam> dbaron: I had three comments.  one, AmeliaBR asked how do you detect this
14:43:41 <dbaron> @supports selector(::reveal)
14:43:46 <heycam> ... one answer is that you could use @supports for this selector
14:43:57 <heycam> ... impls would only suppor this selector if they have a pw reveal mechanism
14:44:11 <heycam> TabAtkins: I don't like that assumption.  then they'll have broken style rules
14:44:23 <heycam> AmeliaBR: that already hapepns with pseudos everywhere
14:44:42 <fantasai> ...
14:44:57 <fantasai> dbaron: Somewhat, but also today's impls don't support that pseudo
14:45:14 <florian> q?
14:45:18 <fantasai> dbaron: fremy pointed out that a year ago we agreed to add 'input-security' property that controls whether or not the password shows up
14:45:23 <fantasai> scribeNick: fantasI
14:45:34 <fantasai> dbaron: If that property has influence on whether the reveal pseudo-class matches
14:45:39 <fantasai> dbaron: then we can't do both
14:45:48 <fantasai> dbaron: You can't have a property that controls whether a selector matches
14:45:56 <fantasai> dbaron: This is not a problem for the pseudo-element, though
14:46:10 <fantasai> dbaron: We don't want to create cycles with input:reveal { input-security: ... }
14:46:17 <tantek> FYI: https://github.com/w3c/csswg-drafts/issues/2495
14:46:19 <heycam> ScribeNick: heycam
14:46:44 <heycam> florian: talking about this I said that we had introduced this prop, for arbitrary things, which is not what we resolved.  we resolved none and auto, for make it able to turn it off on pw fields
14:46:48 <heycam> ... not to hide it on non-pws
14:46:54 <heycam> fantasai: that problem still applies
14:46:57 <heycam> ... just limited in scope to input
14:47:03 <Rossen_> ack florian
14:47:12 <heycam> dbaron: the 3rd comment is that there was a bunch of discussion baout WG's history of not styling form controls
14:47:44 <heycam> ... some of this is that there was an assumption that really form controls are a big problem to tackle, and there was a bunch of ongoing work that was supposed to help us tackle this problem, which at this point has taken 14 years longer than expected
14:47:47 <heycam> ... Web Components is a thing now
14:48:19 <heycam> ... part of the idea of the origin of WCs is to help us figure out how to expose styling of form cotnrols to the web
14:48:36 <heycam> ... we should at some point think about whta we can do that is still web compatible, we have more compat constraints now
14:49:04 <heycam> bkardell_: it would be helpful to work with people how make custom control libraries
14:49:17 <tiger_> tiger_ has joined #css
14:49:17 <heycam> ... I want to be in control of these things, but not these things?  it's not simple
14:49:20 <Rossen_> q?
14:49:26 <heycam> Rossen_: there will always be native controls
14:49:27 <tantek> Also FYI: https://developer.mozilla.org/en-US/docs/Web/CSS/-webkit-text-security
14:49:28 <Rossen_> ack jensimmons
14:49:49 <heycam> jensimmons: myles_ what you brought up was interesting, keeping UX consistent as a security concern, pulls it out of the rest of the form controls debate
14:50:16 <heycam> ... if we wanted to pull those concerns up, the web should get the pw off the web page, I wonder if the genie is already out of the bottle
14:50:33 <heycam> ... I don't have any answers, but there's something interesting there
14:50:35 <florian> q?
14:50:41 <heycam> ... solving passwords on the web ... not going to happen here
14:50:41 <florian> q+
14:50:54 <tantek> Does the CVV use-case apply here? (e.g. is that a use-case for -webkit-text-security ?)
14:50:55 <heycam> fantasai: I don't think Web Components is the answer to all of this
14:50:58 <bkardell_> my above comment was intended to say that there are orgs and frameworks providing custom elements to other people now, and they seem to have similar challenges as browsers now
14:51:03 <florian> q-
14:51:10 <heycam> jensimmons: we'll get to the form controls eventually, just ship these pseudos for passwords?
14:51:11 <Rossen_> ack AmeliaBR
14:51:18 <Rossen_> Zakim, close q
14:51:18 <Zakim> I don't understand 'close q', Rossen_
14:51:20 <heycam> AmeliaBR: is there any interest in browsers that don't have this feature, adding this feature?
14:51:22 <Rossen_> Zakim, close queue
14:51:22 <Zakim> ok, Rossen_, the speaker queue is closed
14:51:40 <heycam> ... is there any work being done on the HTML side to have this as a state of the input element, that is revealed on a DOM level?  rather than just through CSS
14:51:57 <heycam> ... right now, I don't think there is any DOM level way to detect when someone toggles the reveal or not on their native input
14:52:06 <heycam> ... not sure whether it's a security concern, but it would expose info that's not already exposed
14:52:11 <heycam> ... which may be something to consider
14:52:21 <heycam> ... and the discussion maybe should happen at a DOM/HTML level
14:52:32 <heycam> ... on dbaron's concern about circularity, don't think it's an issue
14:52:51 <heycam> ... wouldn't want the revealed state to be based on a css property, but a state maintained by the input element which knows whether it's revealed or not
14:53:00 <heycam> ... and the UA sheet can say do something based on it
14:53:24 <heycam> ... but again that depends on the idea that the input element is able to maintain the state of whether it's in the reveal state, which is an HTML/DOM question
14:53:43 <heycam> myles_: when we discussed text-security a year ago, we spent a lot of time talkingabout the behavior of mobile browsers, where you press a key and it shows for 0.5s
14:54:02 <heycam> AmeliaBR: it's a state that exists only as long as you're pressing the key, vs on or off
14:54:05 <heycam> myles_: it's per character tho
14:54:11 <heycam> AmeliaBR: as you're typing?  the char you just typed?
14:54:13 <heycam> myles_: yeah
14:54:19 <heycam> una: I liked AmeliaBR what you said about HTML
14:54:25 <heycam> ... reminds me of the media control state
14:54:37 <heycam> ... it lets them decide whether to show the widget
14:55:00 <heycam> AmeliaBR: so the author could make a custom control that toggles the pw reveal state?
14:55:01 <heycam> una: yes
14:55:19 <heycam> AmeliaBR: currently most impls switch the input type from pw to text, awkward for a11y
14:55:31 <heycam> ... bad for autofill
14:55:41 <heycam> ... if authors could impl a custom pw reveal without changing the fact that it's pw...
14:55:45 <rachelandrew_> rachelandrew_ has joined #css
14:55:50 <heycam> florian: that's what we resolved 1yr ago, not that it was a DOM prop tho
14:56:03 <tantek> q?
14:56:05 <tantek> q+
14:56:07 <heycam> ... the details of whether it's showing only the last char, or the whole text, that's "auto"
14:56:14 <heycam> ... but only applies to input elements
14:56:23 <heycam> ... we didn't follow up on that, but we did resolve it
14:56:50 <heycam> AmeliaBR: that doesn't let the custom control allow you to turn the revealing on and off
14:57:25 <AmeliaBR> s/allow you to/detect whether the user agent can/
14:57:27 <heycam> florian: should we reopen that 1yr old question to see whether we should have it in HTML/DOM instead?
14:57:34 <heycam> tantek: I think we want this for cvv fields too
14:57:37 <heycam> ... so yes
14:57:50 <heycam> florian: the control we have didn't allow you to hide things.  only reveal things which are hidden by default
14:57:59 <heycam> ... didn't want them to make normal text fields look like pw fields
14:59:02 <heycam> florian: the earlier resolution, we decided we only needed auto/none
14:59:15 <heycam> ... when WebKit brought this to the group, was to stop having non-pw fields for pw-ish purposes
14:59:21 <myles> myles has joined #css
14:59:23 <heycam> tantek: that sounds like denial of the use case
14:59:38 <heycam> florian: does sound like we should reopen that issue
14:59:49 <heycam> ... should we be able to hide things revealed by default, and whether it should be a DOM thing
15:00:07 <fremy> @myles @myles_ why did you mention this to me: // text-security was implemented in 2007, 12 years ago
15:00:08 <heycam> myles_: search fields often have a manifying glass image.  if this will have an icon thing, it should use the same mechanism
15:00:37 <heycam> Rossen_: in Edge, it's the same mechanism. there's an action pseudo, for clear, search, reveal
15:01:41 <heycam> hober: can't resolve to add the pseudo class but also have input-security
15:01:45 <heycam> tantek: it's not optimal
15:01:53 <heycam> dbaron: needs to be clear what the two things do.  it's still possible
15:02:20 <heycam> emilio: could have weird states with non-revealed text but still matching the pseudo
15:02:44 <heycam> fremy: [...] if the user clicks the button it would override what's set
15:02:54 <heycam> dbaron: does input-security control whether there's a reveal button or not?
15:03:18 <AmeliaBR> q?
15:03:18 <heycam> ... someone needs to write down a defn, to check whether the input-security is reasonable, the pseudo is reasonable, and whether they interact well or not
15:03:59 <heycam> AmeliaBR: I think we've brought up a number of issues, would be worth updating the explainer/proposal to hash out these details
15:04:19 <heycam> ... and generalizing to other action buttons.  greg's not here, just throwing it back on him...
15:04:27 <heycam> jensimmons: from Greg's tweets sounds like he's diving into stylable controls
15:04:46 <heycam> tantek: 3 interrelated issues, resolving on one will make it harder to make sensible resolutions for the others
15:05:01 <heycam> florian: come back with a complete proposal
15:05:37 <heycam> tantek: hoping the "things that want a reveal button which are not pw fields" use case can be handled
15:06:04 <heycam> -- 15 min break --
15:06:18 <tantek> heycam++
15:06:50 <dbaron> github-bot, end topic
15:29:06 <antonp> antonp has joined #css
15:29:49 <jensimmons> jensimmons has joined #css
15:30:03 <TabAtkins> ScribeNick: TabAtkins
15:30:47 <myles_> myles_ has joined #css
15:30:52 <TabAtkins> Topic: Upcoming f2f
15:31:09 <TabAtkins> astearns: The jan meeting is set for Spain, as I understand?
15:31:20 <TabAtkins> dbaron: Dates?
15:31:34 <Rossen_> Rossen_ has joined #css
15:32:07 <bkardell_> here's a thing with the venue https://webengineshackfest.org/2019/#venue
15:32:08 <TabAtkins> Rossen: So Igalia hosting, location is A Coruña
15:32:52 <TabAtkins> dbaron: There's a moz all-hands the following week, if we use the Jan 20-24 dates
15:33:07 <TabAtkins> dbaron: But Moz people thus can't do the following week. Either week before or after.
15:33:52 <TabAtkins> jensimmons: Yes plz don't leave an empty week before Moz Berlin all-hands and this meeting...
15:34:00 <chris> TPAC 2020 Tentative dates 26-30 October 2020
15:34:33 <TabAtkins> TabAtkins: Probably no Houdini, we'll have talked at TPAC.
15:34:46 <TabAtkins> AmeliaBR: So W-F leading into Moz the next week seems best?
15:35:17 <TabAtkins> Rossen: So tentatively 22-24.
15:36:21 <TabAtkins> RESOLVED: Jan 22-24 for A Coruña meeting, pending final approval from Igalia.
15:37:37 <rachelandrew_> rachelandrew_ has joined #css
15:37:38 <TabAtkins> bkardell_: Igalia confirms that 22-24 works.
15:38:17 <TabAtkins> [Spring meeting will be at Apple, tess and myles will confirm room availability)
15:39:11 <leaverou> present+
15:39:13 <TabAtkins> dbaron: How many meetings this next year? 13ish months between TPACs, tentative wiki plans are for 3 meetings now.
15:39:15 <rachelandrew__> rachelandrew__ has joined #css
15:40:51 <TabAtkins> [discussion about france in August]
15:41:00 <TabAtkins> [definitely not doing Tokyo during olympics]
15:41:20 <rachelandrew__> the spring meeting - do we have rough dates? I have conference organisers to get back to
15:42:24 <TabAtkins> hober: We might be able to do two next year, haven't hosted in forever. We'll see.
15:43:03 <TabAtkins> florian: Maybe do Spring in Japan, then somewhere else in August.
15:43:56 <una> una has joined #css
15:43:58 <TabAtkins> una:
15:44:13 <TabAtkins> una: Could probably do NYC Google.
15:46:04 <TabAtkins> astearns: I could host in 2021 in Noida, India
15:46:24 <TabAtkins> astearns: In Spring, the best time to go there
15:47:20 <TabAtkins> <br type=lunch dur=1hr>
15:50:36 <jensimmons> jensimmons has joined #css
16:00:22 <myles> myles has joined #css
16:01:46 <jensimmons> jensimmons has joined #css
16:03:16 <lajava> lajava has joined #css
16:05:17 <cabanier> cabanier has joined #css
16:09:45 <rachelandrew___> rachelandrew___ has joined #css
16:15:27 <stryx`> stryx` has joined #css
16:20:17 <rachelandrew____> rachelandrew____ has joined #css
16:29:55 <myles_> myles_ has joined #css
17:01:21 <myles> myles has joined #css
17:08:45 <fremy> fremy has joined #css
17:09:01 <TabAtkins> Topic: Publish Early, Publish Often
17:09:20 <TabAtkins> fantasai: We're now on Echidna, so we can publish in about 5min normally.
17:09:22 <una> una has joined #css
17:09:27 <TabAtkins> fantasai: ONe of the goals of that was to publish more frequently
17:09:34 <Rossen_> Rossen_ has joined #css
17:09:42 <TabAtkins> fantasai: I think when we have signif changes we shoudl check with the WG to make sure everyon'es on board,
17:09:56 <TabAtkins> fantasai: But there are a lot of things where I think the editor should just be able to publish. Particularly editorial changes.
17:10:06 <TabAtkins> fantasai: So I propose we allow the editor to just push that to TR.
17:10:13 <TabAtkins> fantasai: Or other obvious bugfixes.
17:10:20 <stantonm> stantonm has joined #css
17:10:24 <TabAtkins> florian: Probably also if we've resolved toa ccept specific wording
17:10:26 <TabAtkins> fantasai: Yes
17:10:50 <TabAtkins> fantasai: But if there's a change that should be reviewed by somebody, like we resolved on a decision but not specific wording, and it's non-trivial, that should probably also still go thru the WG.
17:11:09 <TabAtkins> fantasai: But for editorial changes, trivial bugfixes, and resolutions with acceptance of specific edits, we should let people push
17:11:17 <TabAtkins> chris: Up to editor's discretion?
17:11:23 <tantek> q?
17:11:30 <TabAtkins> fantasai: Editor is fine for me. Could push thru chairs, just not waiting for the WG call.
17:11:38 <fantasai> has to be very very trivial, though!
17:12:00 <tantek> q+ to request that we have a requirement of adding to the Changes section, and preferably even an HTML diff as well, just because that *should* look minimal for editorial changes
17:12:00 <TabAtkins> AmeliaBR: Is there an intermediate state, where you ping people first?
17:12:07 <TabAtkins> astearns: I think if you're concerned, this isn't one of those cases.
17:12:28 <tantek> q+ to request that we have a requirement of adding to the Changes section, and preferably even an HTML diff as well, just because that *should* look minimal for editorial changes
17:12:40 <TabAtkins> astearns: I'd like a ping when things are published.
17:12:44 <fantasai> TabAtkins: Echidna can CC an address or ML when publication is succesful
17:12:54 <chris> zakim, thanks for condescending to open the queue :)
17:12:54 <Zakim> I'm glad that smiley is there, chris
17:13:01 <TabAtkins> TabAtkins: Echidna now has a cc feature, pass `-cc=email@example.org` to the bikeshed command to ping it when publication is successful
17:13:05 <astearns> ack tantek
17:13:05 <Zakim> tantek, you wanted to request that we have a requirement of adding to the Changes section, and preferably even an HTML diff as well, just because that *should* look minimal for
17:13:08 <Zakim> ... editorial changes
17:13:10 <TabAtkins> tantek: Strongly supportive.
17:13:22 <TabAtkins> tantek: The more we can desync publishing and make it rapid is a good thing.
17:13:45 <TabAtkins> tantek: Only request is that if you publish what you think are editorial changes, you still include changes about that, preferably with a link to a diff.
17:14:22 <TabAtkins> TabAtkins: W3C has a nice htmldiff tool useful for this, too
17:15:06 <TabAtkins> chris: This is for WD, reqs for updating other things stay the same
17:16:00 <TabAtkins> dbaron: one possible concern, sometimes we get into big arguments where the result of "we can't agree on anything" is "therefor we make no change"
17:16:37 <TabAtkins> dbaron: I don't want this to have too much implication for that, in that "therefore we make no change" should stay "therefore we stick with the previous resolution".
17:16:44 <TabAtkins> florian: Agree, but think that's a chairing issue.
17:17:06 <TabAtkins> florian: If there's disagreement, chairs can decide that we should stick with a particular wording.
17:17:35 <florian> q?
17:17:46 <TabAtkins> TabAtkins: That seems to fall under the intended rule of "don't make non-trivial changes under this process"
17:18:28 <TabAtkins> florian: Other types of changes allowed here is adding examples and inline issues.
17:18:33 <TabAtkins> fantasai: Those are editorial
17:19:07 <TabAtkins> florian: Technically not true unde rW3C process, but let's stick with the definition of "non-normative, non-controversial" as the dividing line
17:19:28 <TabAtkins> fantasai: yes
17:19:31 <leaverou> s/unde rW3C/under W3C/
17:20:10 <TabAtkins> astearns: Do you think you should still have one person review? I've made "editorial" edits that still cause problems.
17:20:36 <TabAtkins> ???: It's fine, people can review after the fact and then just push the fix.
17:20:58 <TabAtkins> AmeliaBR: Yeah, and the faster update cycle can fix issues we've had in the past with markup errors sticking around for a long while.
17:21:28 <TabAtkins> tantek: Adding non-trivial informative changes, like adding examples, could probably *use* some review, but we shoudln't require it in the process.
17:21:59 <TabAtkins> fantasai: As my goal I just wanna close the distance between ED and TR, so TR becomes more of a useful resource.
17:22:17 <TabAtkins> astearns: I want to avoid ahving this quick process meaning you hold off on normative changes bc you want to publish the editorial.
17:22:26 <TabAtkins> fantasai: I don't think that'll generally happen.
17:22:54 <TabAtkins> tantek: In the interest of not blocking on that, do we already have a custom of letting people be first in the telcon agenda if you have a pending publication?
17:22:58 <TabAtkins> astearns: Yeah, nearly always
17:23:58 <TabAtkins> astearns: So proposal is to allow editors to publish to TR at will, when the only changes are non-normative/editorial and non-controversial.
17:24:28 <TabAtkins> [discussion over difference between "uncontroversial" and "non-controversial", concluded that when there's a difference it should be considered controversial]
17:25:19 <TabAtkins> fantasai: And must include in the Changes section that the only changes are non-normative, with a link to the diff.
17:25:49 <TabAtkins> astearns: And ping www-style with the publication.
17:26:29 <TabAtkins> astearns: Anyone object?
17:26:57 <TabAtkins> fantasai: Also allowed: substantive changes when the WG has already approved the exact wording
17:27:50 <TabAtkins> RESOLVED: Allow editors to publish at-will, under the discussed caveats.
17:28:06 <TabAtkins> Topic: Republish Tables 3
17:28:20 <fantasai> RESOLVED: WDs with only editorial changes, non-normative non-controversial changes, and/or substantive changes with exact wording approved by the WG may be published by the editor straight to /TR without explicit approval, providing that a diff of changes is linked and www-style is pinged.
17:28:28 <fantasai> Topic: Republish Tables 3
17:28:30 <TabAtkins> florian: This is mostly editorial, but I still want to run thru the group.
17:28:41 <TabAtkins> s/florian/fremy/
17:28:46 <fremy> https://github.com/w3c/csswg-drafts/commit/942a46a1db056174fbb11cdf94bf2de3b14fc0e3#diff-6e3717cf0173351cda3264b270e9586a
17:28:49 <TabAtkins> fremy: Gonna explain the changes.
17:28:54 <fremy> https://github.com/w3c/csswg-drafts/commit/714ac7625b1b25ccacb183a17a77bb41144d0899#diff-6e3717cf0173351cda3264b270e9586a
17:29:01 <fremy> https://github.com/w3c/csswg-drafts/commit/8dbce74efa894eb8c7183440bd312316cb1ce449#diff-6e3717cf0173351cda3264b270e9586a
17:29:04 <tiger> tiger has joined #css
17:29:39 <rachelandrew____> rachelandrew____ has joined #css
17:29:39 <TabAtkins> fremy: First question was around % for height of table cells
17:30:05 <TabAtkins> s/First/Second, skipping ahead,/
17:30:11 <myles_> myles_ has joined #css
17:30:39 <TabAtkins> fremy: Mosty this change just moves text around.
17:30:59 <TabAtkins> fremy: Previous section was called "computing the table height", but it had details about resolving %s and other stuff
17:31:11 <TabAtkins> fremy: Hard to find that text, not in a good spot.
17:31:46 <TabAtkins> fremy: So I just lifted it to a new section so it's more clear.
17:31:58 <TabAtkins> fremy: Just wanted to bring it up if someone wants to review and make sure I didn't change anything.
17:32:11 <jensimmons> jensimmons has joined #css
17:32:38 <TabAtkins> Rossen: LIne 1896, that's a normative change...
17:32:51 <TabAtkins> fremy: Ah no, that's already implicit in the rest of the spec.
17:33:00 <TabAtkins> Rossen: But it's not just moving around.
17:33:10 <TabAtkins> fremy: Yeah, it's a clarification.
17:33:31 <TabAtkins> Rossen: My point is that here you're defining an algo that says something has no effect. That's not just an editorial change.
17:33:55 <TabAtkins> fremy: It's editorial in the sense that it's already normative in the spec elsewhere. This shouldn't be a behavior change, I'm just summarizing the effect of other stuff in the spec.
17:34:13 <TabAtkins> florian: New text, but no new requirements.
17:35:21 <tantek> editorial vs. substantial vs. normative are all different things, please don't try to collapse any two
17:35:40 <TabAtkins> astearns: It's often good in those situations to just link to the section saying that, rather than duplicating.
17:35:54 <TabAtkins> AmeliaBR: These are literally consecutive paragraphs, eh
17:36:15 <AmeliaBR> s/eh/in one subsection/
17:36:35 <TabAtkins> fremy: First link, actually adds something.
17:36:46 <TabAtkins> fremy: In spec there was a sectiond defining positioning of everytrhing inside the table
17:36:55 <TabAtkins> fremy: Described for each of them the left/top/width/height.
17:37:07 <TabAtkins> fremy: I assumed it was obvious this was the bounding box, but that wasn't obvious in the spec.
17:37:21 <fantasai> tantek, https://www.w3.org/2019/Process-20190301/#correction-classes
17:37:37 <TabAtkins> fremy: So I've officially defined that this is the dimensions of the box, returned get gBCR().
17:38:10 <TabAtkins> florian: What's the alternative interpretation of this?
17:38:40 <TabAtkins> fremy: Like, the tech was only necessarily about visual stuff. Not clear that it affected the .offsetLeft, etc.
17:38:41 <tantek> fantasai: I agree with those distinctions, glad to see that there are *four* made explicit
17:39:10 <fantasai> tantek, yeah, the resolution above was only wrt to #1/#2 -- unless exact text for #3/#4 was WG-approved already
17:39:13 <TabAtkins> fremy: Also clarified what border-spacing means with spanning cells, etc. Obvious in formula, but made it clear in prose.
17:39:14 <dbaron> q+ to ask about table wrapper versus table
17:39:41 <astearns> ack dbaron
17:39:41 <Zakim> dbaron, you wanted to ask about table wrapper versus table
17:40:20 <TabAtkins> dbaron: In the first bit, I'm a little nervous about "which means they are accessible via..." because of table vs table wrapper box, because only one of those is accessible to the OM
17:40:37 <TabAtkins> fremy: Which is used for those APIs is already specified.
17:40:48 <TabAtkins> dbaron: Yes, but then your statement of fact there is slightly wrong.
17:41:36 <TabAtkins> dbaron: You give bounding rects for both table and table wrapper, but only of those is accessible via the OM, so the statement that the definition "makes them accessible" is technically wrong.
17:41:47 <TabAtkins> dbaron: Perhaps add a parenthetical about the boxes that aren't OM-accessible.
17:43:07 <TabAtkins> fremy: Sure
17:45:28 <TabAtkins> fremy: And the third diff is Elika's editorial changes to the propdef tables, to be consistent with the rest of the CSS specs.
17:47:07 <TabAtkins> astearns: I'm hearing no objecteions to publication
17:47:31 <TabAtkins> RESOLVED: Publish  new WD of Tables 3 with the reviewed changes.
17:48:32 <TabAtkins> Topic: font-min/max-size and computed value
17:48:36 <fantasai> I've updated https://wiki.csswg.org/spec/publish with the blanket publication resolution
17:48:40 <fantasai> fwiw
17:48:41 <astearns> github: https://github.com/w3c/csswg-drafts/issues/3739
17:48:51 <TabAtkins> emilio: Browsers have minimum font-size settings for a11y
17:49:08 <TabAtkins> emilio: And they work differently in WK-based vs Firefox
17:49:17 <TabAtkins> emilio: WK-based browsers, it affects the font-relative units.
17:49:21 <TabAtkins> emilio: In Firefox they do not.
17:50:32 <fremy> fremy has joined #css
17:50:56 <TabAtkins> emilio: So I was considering implementing min-font-size, and that affects the computed value of font-size, I would assume
17:51:06 <TabAtkins> emilio: So first, the a11y setting in Blink can break websites
17:51:59 <TabAtkins> emilio: I'd also like min-font-size to work the same as the a11y setting.
17:52:28 <TabAtkins> fantasai: Reason it affects computed and not just used font size is that if you were using ems correctly (for the purpose of making something relative to text size), then everything should scale and match the size of text.
17:52:49 <rachelandrew_____> rachelandrew_____ has joined #css
17:53:29 <TabAtkins> AmeliaBR: How much would things break if we declared a different computed value for inheritance vs font-relative units?
17:53:47 <TabAtkins> dbaron: Which is what I thought Gecko did, and maybe what it did pre-servo
17:53:57 <TabAtkins> fantasai: That would be fine and would honor the constraint we want
17:54:08 <TabAtkins> emilio: Would it?
17:54:37 <TabAtkins> [Amelia re-explains their proposal]
17:55:03 <fantasai> TabAtkins: So on any given element, 1.2em would still be 120% size of the text
17:55:18 <TabAtkins> emilio: That would still break websites if we used this to ipmlement the a11y setting
17:55:57 <fantasai> dbaron: ...
17:56:47 <TabAtkins> dbaron: I think this is mostly problematic because of people misusing rem to get a custom-sized unit
17:56:49 <fantasai> s/.../people use the root font size to create a unit that's not really related to the font size, and that breaks if you apply font size minimums to it/
17:56:54 <TabAtkins> jensimmons: And they want nice math, yeah
17:57:00 <dbaron> s/mostly/also significantly/
17:57:36 <TabAtkins> myles_: So it sounds like users are getting min-font-size via the UI settings; could you just keep that separate from min-font-size property?
17:57:53 <TabAtkins> emilio: Yeah, we could. But it would still mean the minimum font size setting is magical; you couldn't override that in a user stylesheet.
17:58:25 <TabAtkins> dbaron: Also one of the underlying principles of CSS is that it explians how author and user expectations work with each other. Settings/prefs are usually explained as part of the user stylesheet.
17:58:35 <AmeliaBR> q+ to talk about author use of min/max-font-size
17:59:28 <TabAtkins> myles_: Right. There just might be a distinction between an author saying they want to scale up a font size, and the user saying they can't see text smaller than a certain value.
17:59:38 <zcorpan> zcorpan has joined #css
18:00:10 <TabAtkins> dbaron: Also, minimum font sizes don't seem to work well in practice anyway, many pages break. So maybe this isn't the most useful anyway.
18:00:26 <myles> myles has joined #css
18:00:52 <TabAtkins> fantasai: So if authors do understand the unit and use things correctly, things should still scale correctly.
18:01:17 <TabAtkins> jensimmons: So to clarify, there's a min/max-font-size, and maybe you set font-size with a calc(vw) or whatever.
18:02:06 <TabAtkins> jensimmons: So if you hit a min or a max, and we cap it when you hit the limit, should that propagate to the 'em' unit, that's the question, right?
18:02:06 <chris> yes, exactly
18:02:10 <TabAtkins> [yes]
18:02:21 <TabAtkins> jensimmons: It doesn't even make sense to me that it wouldn't transfer over.
18:02:26 <florian> +1 to jensimmons
18:02:29 <astearns> ack AmeliaBR
18:02:29 <Zakim> AmeliaBR, you wanted to talk about author use of min/max-font-size
18:02:37 <fantasai> /So/CSS provides a variety of units to allow authors to express the why of their sizes through relative measurements, against the font or the screen or the container or the pixels, etc. Authors who understand these units will use font-relative units when they want things to scale with the font, so/
18:03:46 <TabAtkins> AmeliaBR: So while CSS gives people the tools to use things properly, we have to recognize that some people won't use it correctly.
18:04:38 <fantasai> jensimmons gives an example of e.g. gmail which doesn't handle the scaling of text correctly, so zooming in creates a suboptimal layout -- but this is a case of the author not choosing to use the correct units ; breaking the connection between ems and font-size would make it impossible to fix
18:05:15 <TabAtkins> dbaron: I think I agree that making 'em' honor min/max is the only thing that makes sense. It's not clear to me which to go with inheritance, as it depends on use-case
18:06:17 <TabAtkins> fantasai: There was a comment from Fred Lang, where if min/max clamped the value before inheriting, you'd have a size in the multi-step process that gets messed up and messes up all subsequent sizes.
18:06:20 <leaverou> Agreed with dbaron. Authors use ems assuming they correspond to actual used font size. If that assumption breaks, a lot of UIs would too.
18:07:08 <dbaron> s/Lang/Wang/
18:07:36 <fantasai> fantasai: So I agree with Amelia that the computed / inherited font-size should not be affected by the min/max, but that the min/max should factor into not just the used font size but also the resolution of font-relative units
18:07:49 <fantasai> fantasai: We would be doing authors a disservice if we did not ensure that the font-size and 1em matched.
18:08:03 <astearns> ack dbaron
18:08:04 <chris> I agree with that proposed solution
18:08:26 <chris> ... otherwise things end up double-applied, growing too much
18:08:26 <TabAtkins> dbaron: I think this is a reasonable conclusion, I think it doesn't work well for Jen's use-case, but I think what does work well for that is using min()/max() inside of font-size.
18:08:39 <chris> ... clamping should happen as late as possible
18:09:30 <TabAtkins> dbaron: Because you want clamping to happen at a particular point, not to be inherited down further into the tree. So you'd use `font-size: clamp(10px, ..., 36px);`
18:10:39 <TabAtkins> AmeliaBR: Right, and that would be bad for min-font-size, as then a `<small>` child would also get clamped and not get smaller. While clamp() works properly
18:11:38 <chris> q?
18:11:41 <chris> q+
18:12:01 <heycam> q+
18:12:14 <astearns> ack chris
18:12:33 <TabAtkins> chris: THis has been interesting. Not sure I could reproduce this aftera few days. I want some examples in the spec of what you should use each with.
18:12:41 <AmeliaBR> +1 to examples!
18:13:29 <heycam> q-
18:13:30 <fremy> (side note for people interested in this and would love examples, Jason Pamental talk at cssconf this year is a great resource)
18:13:36 <iank_> q+
18:14:01 <TabAtkins> TabAtkins: I think we're leanign toward the properties being designed purely for the a11y/settings use-case, and if you want to just clamp a value in a range, you should always use the math functions.
18:14:08 <astearns> ack iank_
18:14:36 <TabAtkins> iank_: Currently the way we do this in Blink for a11y isn't via a property because the font-size clamping we do applies on a per-region basis.
18:14:57 <TabAtkins> myles: Ours is also complicated, probably in a different way.
18:15:29 <TabAtkins> myles: It seems like dbaron was saying the function of CSS was to explain browser features. It sounds like this feature shouldn't be explained in CSS, and it should remain magic.
18:15:49 <TabAtkins> emilio: It sounds like Ian is talking about the text auto-sizing actually?
18:15:58 <TabAtkins> myles: Ah, but I wasn't in mine.
18:16:06 <TabAtkins> myles: We have a lot of systems that interact to produce a text size.
18:16:30 <TabAtkins> myles: I've spent a long time trying to increase readability, and...
18:17:00 <TabAtkins> myles: The issue is "I want to use this CSS feature to do a11y, but things break", then we just shouldn't use that feature.
18:17:09 <TabAtkins> florian: So what are we using these for?
18:17:57 <fantasai> myles: These were added before my time...
18:18:00 <TabAtkins> myles: These predate me, there was just a note in the spec and I started implementing
18:18:27 <TabAtkins> TabAtkins: These predate the math functions; they were meant to implement the "keep vw-based font sizes from getting too big/small"
18:18:33 <TabAtkins> TabAtkins: So we can just drop the properties, then
18:18:52 <TabAtkins> chris: I was looking at history; this looks like something that was dropped from Fonts 3, and Myles dropped it into Fonts 4 two years ago.
18:18:57 <tantek> agreed with TabAtkins
18:19:07 <tantek> proposal: drop the properties because not implemented anywhere
18:20:02 <TabAtkins> astearns: So these aren't implemented in a user-facing way anywhere, and we're not convinced they're good for any use-case...
18:20:02 <tantek> jensimmons: responsive typography is what the use-case is called, you can search for it
18:20:13 <fantasai> https://lists.w3.org/Archives/Public/www-style/2014Jun/0187.html
18:21:24 <AmeliaBR> `font-size: clamp(12px, 10vmin, 24px)` vs `font-size: 10vmin; min-font-size: 12px; max-font-size: 24px;`
18:21:40 <TabAtkins> astearns: So looks like we have consensus to remove these properties, until we have a use-case that min()/max()/clamp() don't serve.
18:22:02 <TabAtkins> AmeliaBR: And replace the section with an example of how to use clamp()l.
18:22:23 <tantek> aside: how do we do copy-fitting
18:22:31 <TabAtkins> RESOLVED: Remove min-font-size and max-font-size from Fonts 4, replace with an example of using clamp() to handle safe responsive typography.
18:23:12 <tantek> q?
18:23:13 <chris> q?
18:23:19 <rachelandrew______> rachelandrew______ has joined #css
18:23:55 <TabAtkins> heycam: The effect of these properties on the computed value of font-size... still worth resolving on how these browser settings affect things?
18:24:47 <fantasai> ChrisL: Example of broken is page with <html style="font-size: 1px">. Answer is, don't do that.
18:25:10 <fantasai> TabAtkins: The way it inherits separately is a problem for designing a font hierarchy relative to a base size, tho
18:25:31 <fantasai> AmeliaBR: Should we give advice to browsers on whether font-relative units should be affected by browser settings?
18:25:35 <fantasai> myles: Arguments on both sides
18:25:48 <fantasai> myles: If we don't expose to authro, they don't know what happened to their page
18:25:56 <fantasai> myles: I don't think it should be specced
18:25:59 <TabAtkins> TabAtkins: Note tho that h6 defaults to smaller than standard font size. If min-font-size is set to standard-font-size (both 16px, say), and you defined your hX hierarchy by starting from h6 size and then calc()ing up the higher values, the Chrome behavior would mess things up; starting from h1 and calc()ing down would be fine. So it's not *all* pathological cases.
18:26:07 <astearns> ack dbaron
18:26:15 <TabAtkins> dbaron: To respond to myles there's another tradeoffs around a11y
18:26:35 <TabAtkins> dbaron: Some users that need a11y are concerned about privacy, and are willing to have the feature not work as well to keep secret that they're using it.
18:27:03 <TabAtkins> TabAtkins: For this feature, no matter how you do it it'll be page-exposed tho
18:27:14 <TabAtkins> dbaron: Also, the browser minimum isn't *really* a minimum.
18:28:07 <TabAtkins> dbaron: If you specify a min of 10px to font-size:1px, you get 10px font. But applied to font-size:0px, you get 0px. That's very important. So it's not a strict "minimum" anyway.
18:28:46 <fantasai> myles: Example is layout with inline-blocks, set font-size: 0px so that the gap below the baseline is zeo.
18:28:52 <TabAtkins> TabAtkins: Myles, wanna capture that 0px point in the spec? If everyone agrees something is needed for webcompat, it should be captured
18:28:55 <TabAtkins> myles: In a note, sure
18:29:16 <TabAtkins> Topic: Clarify how computed font-size is determined for size keyword
18:29:18 <astearns> github: https://github.com/w3c/csswg-drafts/issues/3906
18:29:20 <fantasai> ACTION myles Add a note about the font-size: 0px vs min font-size web-compat issue
18:29:20 <trackbot> Created ACTION-879 - Add a note about the font-size: 0px vs min font-size web-compat issue [on Myles Maxfield - due 2019-06-11].
18:30:01 <TabAtkins> myles: I don't think we can get rid of the fact that monospace is special, for webcompat
18:30:17 <myles_> myles_ has joined #css
18:30:51 <TabAtkins> chris: So this is really about the fact that Courier looks too big.
18:31:06 <TabAtkins> chris: And browsers also noticed that CJK fonts can look too big at 16px by default
18:31:37 <TabAtkins> emilio: in gecko we do this based on the generic family specified.
18:32:25 <TabAtkins> myles: So "a, b, serif" gets a different font size than "a, b, monospace"
18:32:36 <TabAtkins> dbaron: Yes, because of the assumption that those fonts are probably monospace as well
18:32:48 <TabAtkins> fremy: As I recall that's not what was implemented by browsers...
18:33:05 <TabAtkins> myles: In WK, we only adjust if you say *only* "monospace"
18:33:27 <TabAtkins> myles: So using font-family to dictate font-size is fundamnetally broken, we all agree
18:33:29 <TabAtkins> [we all agree]
18:33:45 <TabAtkins> myles: So the question is if we shoudl write down exactly how it's broken. it sounds like everyone does it differently
18:34:56 <TabAtkins> dbaron: Given there's incompatibility, there's maybe room to improve this
18:34:58 <fantasai> [emilio describes some details of how this works]
18:35:07 <TabAtkins> dbaron: AT one point I had part of a plan to replace with with font-size-adjust
18:35:18 <TabAtkins> dbaron: Probably not web-compatible, but maybe... Would require new values.
18:36:00 <TabAtkins> fremy: Last I recall Edge didn't do any adjustments, but at some point we got a bug and added new UA rules that only targeted elements that get monospace by default. We don't apply it to the *monospace value* tho.
18:36:31 <fantasai> TabAtkins: We should capture in the property that extra bit of information captured about whether size was specified as a size
18:36:40 <fantasai> TabAtkins: because browsers seem to do something special in that case
18:36:45 <fantasai> AmeliaBR: Keywords are a bit vague anyway
18:36:55 <fantasai> TabAtkins: No flexibility in that they convert to a <length>
18:37:03 <fantasai> TabAtkins: You honor a <length> as a <length>
18:37:07 <fantasai> TabAtkins: But that's not how browsers work
18:37:19 <fantasai> TabAtkins: We might need to keep it underdefined, but at least that there's some thing special going on
18:37:29 <fantasai> fremy: We have interop, so let's spec that
18:37:34 <fantasai> TabAtkins: OK, but let's capture there's something
18:37:49 <fantasai> emilio: Gecko code... when you have multiple families, we behave like WebKit
18:37:53 <fantasai> emilio: Yay interop!
18:38:06 <fantasai> AmeliaBR: so weird behavior, but cross-browser consistent
18:38:11 <fantasai> chris: So how are we resolving?
18:38:21 <TabAtkins> dbaron: The thing this was solving is really a use-case for font-size-adjust
18:38:22 <fantasai> dbaron: Like to say that the thing this was soliving is a use case for font-size-adjust
18:38:30 <TabAtkins> dbaron: I'd like to encourage the negine that doesn't ipmlement f-s-a to do that.
18:38:32 <fantasai> dbaron: Would like engine that doesn't implement font-size-adjust that doesn't implement it to fix it
18:38:50 <fantasai> dbaron: It's ugly because it's designed to be compatible with its non-existence
18:39:04 <fantasai> dbaron: It's a way of saying "i want to specify font-size in terms of x-height instead of font-size"
18:39:13 <chris> https://developer.mozilla.org/en-US/docs/Web/CSS/font-size-adjust#Browser_compatibility
18:39:43 <TabAtkins> astearns: So it sound slike proposal is to acknowledge reality in font-size property that it makes font-sizes strange.
18:39:52 <Rossen_> Rossen_ has joined #css
18:39:52 <TabAtkins> astearns: And at minimum capture "it's strange" in the spec.
18:39:56 <dbaron> oh, actually, font-size-adjust may be behind the experimental web platform features flag in Chrome...
18:40:07 <fantasai> TabAtkins: Let's capture that keywords come with extra bit of info
18:40:14 <fantasai> TabAtkins: And also investigate if there's compat, andif so spec that
18:40:19 <fantasai> myles_: sgtm
18:40:27 <TabAtkins> astearns: Is there someone volunteering to do the investigation?
18:40:32 <TabAtkins> fremy: I volunteer.
18:40:50 <TabAtkins> astearns: proposal: acknowledge reality that font-size keywords have some weirdness with particular generic font families.
18:41:18 <TabAtkins> RESOLVED: Capture that font-size keywords carry an additional bit of information having some (unspecified) interaction with some font families.
18:41:29 <plh> plh has joined #css
18:41:39 <TabAtkins> astearns: Second is to deputize françois to try and capture what the weirdness is
18:42:09 <TabAtkins> RESOLVED: François does compat research on the effect of font-size keywords and generic font-families, and report back on interop.
18:42:15 <TabAtkins> Topic: math-script-level and math-style
18:42:22 <astearns> github: https://github.com/w3c/csswg-drafts/issues/3746
18:43:04 <TabAtkins> bkardell_: In doing Chromium impl of mathml, and trying to explain the mathml magic in a way that's part of the platform, there are some funky areas
18:43:11 <TabAtkins> bkardell_: So we want to get that funky added to CSS.
18:43:55 <AmeliaBR> Explainer link: https://mathml-refresh.github.io/mathml-css-proposals/math-script-level-and-math-style-explainer.html
18:43:59 <TabAtkins> bkardell_: One is math-style. As part of layout, takes into consideration whether your math equation is happening inline in text or as a block; aligns baselines differently and tries to minimize vertical size in inline, etc.
18:44:14 <TabAtkins> bkardell_: If we have that, this is one more thing that becomes a UA stylesheet rule.
18:44:49 <TabAtkins> bkardell_: math-script-level is in my mind a lot like counters. It lets you scale up or down font-size
18:45:08 <TabAtkins> emilio: So when you nest an element that's a subscript or superscript, or part of a fraction, the font-size shrinks.
18:45:21 <TabAtkins> emilio: But in CSS it affects the computed font-size, which is annoying.
18:45:40 <TabAtkins> fantasai: This effects the font-size. Why is it called script-level, and why is separate from font-size?
18:46:06 <TabAtkins> bkardell_: This is how I think it's similar to counters, it carries info about nesting.
18:46:42 <TabAtkins> AmeliaBR: So elika's question is why not do this with relative font sizes. I think reason is to give browsers some more flexibility...
18:46:56 <TabAtkins> fantasai: We can have math-larger and math-smaller...
18:47:18 <TabAtkins> fremy: If you have a fraction, 1/2. You can nest, 1/(1/2). But third level of nesting, switch to a side-by-side fraction.
18:47:46 <TabAtkins> bkardell_: Even within that context, you can have sub/superscripts too.
18:48:06 <TabAtkins> AmeliaBR: There definitely needs to be a new property. Math fonts have a property saying how much you scale down as you go down a script level.
18:48:27 <TabAtkins> AmeliaBR: Do you need to be able to absolutely set "3 sizes down from normal", or is it always single steps?
18:49:08 <TabAtkins> bkardell_: These map stragiht from MathML attributes. I know the name isn't great, but
18:49:17 <myles_> q+
18:49:27 <TabAtkins> emilio: Figuring out which nodes need to incrmeent or decrement the script level is pretty tricky
18:49:28 <AmeliaBR> `font-size-math-adjust`???
18:49:56 <TabAtkins> emilio: It would be good to see if we can decouple the script-level from font-size, because it becomes much easier, add an "auto" value and figure it out doing layout or something
18:50:11 <TabAtkins> AmeliaBR: Does nesting level have effects other than font-size?
18:50:19 <TabAtkins> myles_: bkardell said yes
18:50:29 <una> what about `font-size-math-adjust: <nesting-level>`
18:50:37 <TabAtkins> fantasai: So then you'd want to *select* based on that level. So then that info must be in the DOM.
18:51:01 <TabAtkins> fantasai: We've had similar cases in the past of things thought to be in CSS that we pushed back and said "no, this needs to be in the DOM".
18:51:16 <TabAtkins> fantasai: Like directionality.
18:51:25 <myles_> s/bkardell said yes/fremy said yes/
18:51:29 <astearns> ack myles_
18:51:41 <astearns> q+ myles_
18:51:49 <fremy> (yep, for the record I agree with fantasai)
18:52:06 <TabAtkins> dbaron: I think one of the reasons for this is that mathml has attributes that specify both the ratio of font-size for each change in script level, and the min font-size at which you stop changing it.
18:52:22 <TabAtkins> dbaron: script-size-multiplier and script-min-size
18:52:50 <TabAtkins> fantasai: Does this mean we're adding font-min-size back?
18:53:14 <TabAtkins> myles_: There have been a half-dozen or so of these proposals. How do these affect existing elements outside of MathML?
18:53:56 <Karen> Karen has joined #css
18:53:57 <TabAtkins> bkardell_: Some people do indeed think that <math> isn't great, and math layout should be a normal part of CSS.
18:54:06 <una> `font-size-math-adjust: <max-nesting-level> / <min-font-size>`
18:54:24 <TabAtkins> florian: I think we want the building blocks of math in normal CSS. And I've heard the argument that MathML is bad for math; mathjax people will do that.
18:55:00 <TabAtkins> florian: So mathjax renders math into HTML or SVG, but they're missing some tools that make it subpar.
18:55:31 <TabAtkins> myles_: So what's the criteria here: hsould math layout be dumped in whole-hog?
18:55:44 <chris> https://www.w3.org/TR/MathML3/chapter3.html#presm.mstyle.attrs
18:55:45 <TabAtkins> bkardell_: We're trying to find the mathml core and eliminate as much as possible.
18:55:55 <TabAtkins> bkardell_: So far we've been doing good at that.
18:56:08 <TabAtkins> bkardell_: Reusing CSS stuff well.
18:56:11 <chris> also https://www.w3.org/TR/MathML3/chapter3.html#presm.scriptlevel
18:56:35 <TabAtkins> astearns: I hear this as a request from another group, like the timed text people, to get something that they can't currently do in CSS.
18:56:59 <tantek> q?
18:57:07 <fantasai> TabAtkins: Is the goal that you can implement math layout with <div>s, or are we still using mathml but ...
18:57:16 <TabAtkins> dbaron: There are two different groups in w3c working on diff solutions here
18:58:03 <TabAtkins> s/are we still using mathml but .../are we saying that mathml is a special layout form, like SVG, that can have its own specialized CSS without influencing arbitrary text layout/
19:00:06 <myles> myles has joined #css
19:00:43 <TabAtkins> myles_: So if this is a generic layout mechanism, you need to be able to put flexbox inside of it
19:01:07 <TabAtkins> florian: I don't think we want to be able to take naive markup and get good math out of it.
19:01:24 <fantasai> TabAtkins: Are we intending that you can make a fraction, and the nuerator is a flexbox?
19:01:26 <iank_> q+
19:01:31 <astearns> ack myles_
19:01:37 <fantasai> TabAtkins: If so, you can nest flexbox into it. If not, then you can't.
19:01:46 <fantasai> TabAtkins: But need to know which way we're going so we can figure out how to interact with it
19:01:52 <fantasai> chrisl: ...
19:01:57 <fantasai> TabAtkins: We'd make a Math layout spec
19:02:04 <TabAtkins> iank_: So basically mathml is already in this state where you can nest CSS layout inside of it
19:02:13 <TabAtkins> iank_: And it uses CSS layouts to ahcieve some of its layouts
19:02:18 <TabAtkins> iank_: so <mtable> uses css tables
19:02:29 <TabAtkins> iank_: The text inside of mathml is just text layout, it can do floats/etc
19:02:38 <tantek> q?
19:02:43 <TabAtkins> iank_: This was the feedback we gave to the group: you need to define how this interacts with all of CSS.
19:02:47 <astearns> ack iank_
19:02:52 <tantek> q+
19:03:21 <TabAtkins> myles_: ARe you saying that philophically that's how this shoudl be designed, or that it's just a quirk of impl.
19:03:58 <TabAtkins> Rossen: So support rich layout that allows math, and interacts nicely with the rest of css.
19:03:58 <fremy> q+
19:04:33 <astearns> ack tantek
19:04:39 <TabAtkins> astearns: A detail is that some requirements, we may not get to. LIke western typography, some details we never get to.
19:04:50 <TabAtkins> myles_: So the intention is that we end up with display:math at some point?
19:05:13 <TabAtkins> AmeliaBR: display:fraction, perhaps, like display:ruby : some specialized focused layouts as necessary
19:05:56 <dauwhe> this is a w3c strategy funnel issue https://github.com/w3c/strategy/issues/43
19:08:01 <myles> q+
19:08:11 <tantek> q-
19:08:12 <una> una has joined #css
19:08:49 <astearns> ack fremy
19:08:58 <TabAtkins> fremy: So math-level.
19:09:16 <TabAtkins> fremy: If you want a layout that's different depending on the math level, that's fine. We could do that.
19:09:29 <dauwhe> https://www.w3.org/community/knowledge-domain/
19:09:30 <TabAtkins> fremy: But the way I see this is that math-level is changing other properties, in some weird interaction.
19:09:41 <astearns> q+
19:09:42 <TabAtkins> fremy: So my mental model matches fantasai, this is at the DOM level.
19:09:58 <TabAtkins> fremy: And if we go the "you should do math using divs", that doesn't work.
19:10:32 <TabAtkins> fremy: My impression from when I worked on this, is that this is complex to put in a CSS property.
19:10:35 <florian> q+
19:10:42 <TabAtkins> fremy: But if our goal is to allow everything in CSS, I don't see how it's a markup thing.
19:11:24 <TabAtkins> fremy: So question is we need mathml markup, or is there a simplified markup that would provide the grouping/level/etc that we could provide the levels on top of.
19:11:35 <astearns> ack myles
19:11:45 <TabAtkins> myles: So let's say we do wanna go on this path where we induct math layout into CSS.
19:11:56 <TabAtkins> myles: When we write CSS specs we have to describe layout exactly.
19:12:16 <TabAtkins> myles: Do you envision that this group would make those decisions, or that MathML would do it and deliver them to us and we'd put them into our docs?
19:12:24 <TabAtkins> bkardell_: Right now they're trying to get that defined.
19:12:32 <TabAtkins> bkardell_: Huge criticism right now is that it's super underdefined.
19:12:55 <TabAtkins> iank_: As part of our launch process we require interop-capable specification.
19:13:06 <tantek> FYI: https://caniuse.com/mathml
19:13:06 <TabAtkins> iank_: And the two impls currently aren't remotely interoperable, especially layout.
19:13:21 <TabAtkins> iank_: I spent two or three hours one day and created a list of issues where Firefox and WebKit differ.
19:14:14 <florian> q?
19:14:35 <TabAtkins> fantasai: If mathml is going to define a layout model closer to css, they should def interact with us more than what's happening currently.
19:14:51 <TabAtkins> fantasai: So we can make sure it's compatible with css layout and all the interactions with othe rproeprties.
19:14:53 <tantek> Is there an opportunity for CSS/MathML joint meeting at TPAC?
19:15:00 <TabAtkins> fantasai: Just because of where the expertise lies.
19:15:08 <AmeliaBR> q+
19:15:36 <Rossen_> q?
19:15:47 <TabAtkins> astearns: I would really like to see more stuff in the explainer. Righ tnow it looks like a reiteration fo the proposal. It has some markup examples without intended renderings, etc.
19:15:58 <Rossen_> ack astearns
19:16:09 <TabAtkins> fantasai: SAme, I don't really understand what it's trying to do currently. So I can't even comment on whether they're doing it right or not.
19:16:29 <TabAtkins> fantasai: So somebody came up with a solution to a problem, but I don't udnerstand the problem, or why this is the best solution to that problem.
19:16:38 <TabAtkins> fantasai: Would love to advise them, but can't right now.
19:17:03 <astearns> ack florian
19:18:22 <TabAtkins> florian: Back to fremy's point, for those trying to solve math with css, i don't think the goal is markup that resembles mathml and uses display:fraction, display:sqrt, etc. I think it was to start from a mathml-ish markup that is processed into a pile of divs, then rendering fractions with a vertical flexbox, etc. Only a few lacking aspects would need to be added.
19:18:41 <TabAtkins> fremy: I don't disagree, that's also an option. But if that's the goal then you don't need the math-script-level property.
19:19:14 <TabAtkins> myles: Agree. We already have SVG then.
19:19:31 <astearns> ack AmeliaBR
19:19:40 <TabAtkins> TabAtkins: SVG doesn't quite solve it - we still need a few small things, like baseline control, stretchy characters. Talked about this at last TPAC. But it's pretty minimal.
19:20:09 <TabAtkins> AmeliaBR: So wrapping up, we have some requests from Brian's team at Igalia about how we want communication to happen, better explainers. larger comprehensive use-cases, rather than one proposal at a time.
19:20:27 <TabAtkins> AmeliaBR: Would be useful if this group gave feedback about how we'd like to be communicated with.
19:20:53 <TabAtkins> AmeliaBR: And then there's further concern about where things should live, CSS vs DOM, etc.
19:20:58 <astearns> ack dbaron
19:21:10 <antonp> antonp has joined #css
19:21:16 <AmeliaBR> s/requests from/requests for/
19:21:19 <TabAtkins> dbaron: elika was asking about the problem to be solved. There is a political disagreement about the problem.
19:21:32 <TabAtkins> dbaron: In that, there is the question of whether mathml is the way forward.
19:21:53 <TabAtkins> dbaron: A few years ago when it was in Firefox only and we thought we might remove it, everyone thought MathML wasn't the right way to do it; do it in CSS instead, etc.
19:22:00 <TabAtkins> dbaron: And add to CSS to improve mathjax output.
19:22:14 <TabAtkins> dbaron: Now we're somewhat surprisingly getting to a world where mathml is supported across browser engines.
19:22:34 <TabAtkins> dbaron: So question is whether mathml is, like html, something that needs CSS to reflect on things in it.
19:22:49 <TabAtkins> dbaron: ARe we concerned with MathML backcompat such that CSS needs to care about its legacy mechanisms.
19:23:03 <TabAtkins> dbaron: Or do we have substantial flexibility to change things as necessary.
19:23:13 <TabAtkins> dbaron: So three possibilities:
19:23:22 <TabAtkins> dbaron: 1. MathML is in browser engines, CSS has to be compatible with that.
19:23:41 <TabAtkins> dbaron: 2. MathML is in browser engines, but we might make substantial changes in the process and can adjust it to CSS better.
19:23:58 <TabAtkins> dbaron: 3. MathML isn't the right path forward, and math should be taking this up the path.
19:24:27 <TabAtkins> dbaron: Path to making this decision right now is very uncoordinated and not based on principles, but rather on lots of small decisions where people might not be aware of the larger path they're supporting.
19:24:33 <TabAtkins> dbaron: Possible we should be discussing this more epxlicitly.
19:24:51 <TabAtkins> dbaron: I think before we decide waht we're trying to solve, we might want to have that discussion.
19:25:15 <TabAtkins> bkardell_: Before I went to Igalia, I spent a lot of time thinking about this.
19:25:22 <TabAtkins> bkardell_: My own thought were between 2 and 3.
19:25:37 <TabAtkins> bkardell_: HTML isn't very perfect semantically either, it's focused on text.
19:26:06 <TabAtkins> bkardell_: So it has no starting point. It's not like SVG, where we all agree what SVG is.
19:26:22 <TabAtkins> bkardell_: Thirty years the community has been working on something, lots of back and forth.
19:26:41 <TabAtkins> bkardell_: When we got to HTML5 and mathml was codified into the parser, now it's in a special weird place.
19:27:01 <TabAtkins> bkardell_: If there's something I'd personally advocate, it's that we need to find a starting point or we can't have this convo.
19:27:26 <TabAtkins> bkardell_: So back with corp hat on, the core-math group is trying to find the minimal bits that hold things together.
19:27:54 <TabAtkins> bkardell_: I don't want to personally be like "mathml is the best thing ever", I dunno. I want to be malleable here.
19:28:11 <TabAtkins> <br dur=20min>
19:30:21 <myles_> myles_ has joined #css
19:39:31 <TabAtkins> myles_: Minutes of the Math session during last year's tpac: https://lists.w3.org/Archives/Public/www-style/2018Nov/0008.html
19:44:36 <dbaron> github-bot, end topic
19:44:59 <rachelandrew______> rachelandrew______ has joined #css
19:45:10 <dbaron> https://twitter.com/tpsoperations/status/1135982093631152128
20:00:06 <myles> myles has joined #css
20:00:48 <tantek> present+
20:07:49 <fremy> fremy has joined #css
20:07:55 <fremy> ScribeNick: fremy
20:07:56 <chris> present+
20:08:42 <jensimmons> jensimmons has joined #css
20:09:17 <emilio> koji: https://bugzilla.mozilla.org/show_bug.cgi?id=1418472
20:09:33 <fremy> Topic: Remove at-risk marker for percentages in column-gap
20:09:40 <astearns> github: https://github.com/w3c/csswg-drafts/issues/3988
20:09:56 <fremy> rachelandrew______: there was a resolution before I joined the group to mark percentages in column-gap at risk
20:10:03 <Rossen_> Rossen_ has joined #css
20:10:07 <una> una has joined #css
20:10:16 <fremy> rachelandrew______: but Firefox implemented it, and now the property applies on grid and flexbox as well
20:10:26 <fremy> rachelandrew______: so they asked if the at-risk could get removed
20:10:37 <fremy> astearns: do we have implementation report?
20:10:43 <fremy> rachelandrew______: yes
20:11:01 <fremy> astearns: does any other implementation want to get it removed?
20:11:11 <fremy> astearns: I assume not since we resolved to allow it?
20:11:33 <fremy> florian: yeah, I'd agree to remove because sometimes implementors are afraid to implement it
20:11:46 <fremy> AmeliaBR: yeah, at-risk should be redefined to be less scary
20:12:00 <fremy> florian: yeah, that's just the name though, the description is already encouraging implementation
20:12:21 <fremy> florian: it would be nice to change the name at the w3c level, but this hasn't happened anymore
20:12:28 <tiger> tiger has joined #css
20:12:31 <fremy> s/anymore/yet
20:12:40 <fremy> AmeliaBR: do we have tests to back this up?
20:12:56 <fremy> rachelandrew______: yes, and on top of that we have tests for grid as well, where it is implemented
20:13:08 <fremy> astearns: any objection to remove the at-risk commned?
20:13:35 <fremy> iank_: there is only one test, and that is a bit low
20:13:36 <rego> rego has joined #css
20:13:44 <fremy> iank_: we would need tests for intrinsic sizing etc
20:13:52 <fremy> iank_: but I'm ok to remove the at-risk
20:13:58 <fremy> astearns: resolved then
20:14:19 <fremy> RESOLVED: remove at-risk percentages on column-gap (and add some tests)
20:14:33 <fremy> Topic: where do we define column-gap
20:14:36 <astearns> github: https://github.com/w3c/csswg-drafts/issues/3641
20:14:48 <fremy> rachelandrew______: we define column-gap in multicol and box alignment
20:15:09 <fremy> rachelandrew______: authors were discussing how confusing that was
20:15:29 <fremy> rachelandrew______: I'd rather define column-gap in alignment, and just mention the specificities of column-gap for columns in multicol
20:16:09 <fremy> florian: we kinda did the same thing for break properties, where they usually were defined in multiple places, and now we consolidated in css-break and we added notes to the other places
20:16:20 <fremy> AmeliaBR: we should consider REC progress though, so we don't get stuck
20:16:42 <fremy> fantasai: css-align is really close to REC, so I don't think that would be an issue
20:16:49 <fantasai> s/REC/CR/
20:16:51 <fremy> fantasai: the only remaining issue is baseline alignment
20:16:59 <fremy> fantasai: and we could move that to the next level
20:17:02 <fantasai> s/issue/significant source of issues/
20:17:10 <fremy> AmeliaBR: then that seems fine
20:17:54 <fremy> astearns: suggested edit is to add an heading to explain how column-gap works in multicol, but define in box-alignment only
20:17:58 <fremy> astearns: any objection?
20:18:06 <fremy> RESOLVED: add an heading to explain how column-gap works in multicol, but define in box-alignment only
20:18:15 <fremy> (and link between them)
20:18:45 <AmeliaBR> s/astearns: suggested/rachelandrew______: suggested/
20:18:45 <fremy> Topic: why was min-content redefined to do nothing on the block axis?
20:19:39 <fremy> fantasai: since christian raised this issue, it would be good to have him on the line when we discuss this?
20:19:46 <fremy> fantasai: (this was a question)
20:20:00 <fremy> astearns: we could move to the next one to see if we can get christian on the line?
20:20:05 <fantasai> cbiesinger: ping
20:20:15 <fremy> iank_: (pinging christian on slack)
20:22:00 <fremy> (cbiesinger dialing in)
20:22:23 <fremy> <br type="technical" /> ;-)
20:25:51 <fremy> astearns: cbiesinger can you summarize the issue?
20:26:01 <fremy> cbiesinger: there was a change in css-sizing spec
20:26:09 <fremy> cbiesinger: now min-content does the same as the initial value
20:26:15 <astearns> github: https://github.com/w3c/csswg-drafts/issues/3973
20:26:16 <fremy> cbiesinger: which is great for height
20:26:29 <fremy> cbiesinger: but for min-height for instance, this is a change in behavior
20:26:49 <fremy> cbiesinger: and in flexbox with auto, you can't get a specific effect that you used to get before
20:27:03 <fremy> cbiesinger: so we should probably redefine it again so that it does a different thing by property
20:27:10 <fremy> fantasai: makes sense to me
20:27:23 <fremy> dbaron: the assumption is that it was defined before
20:27:34 <fremy> dbaron: but before it wasn't clear to me what it was actually supposed to do
20:27:42 <fremy> dbaron: you have block size that is derived from the content
20:27:53 <fremy> dbaron: but it doesn't say which inline size is used to get that layout done
20:28:13 <fremy> dbaron: so in the general case, what would be that inline size?
20:28:26 <fremy> dbaron: is that a function of something else? how does it get passed in to this?
20:28:32 <fremy> cbiesinger: yay, that's true
20:29:11 <fremy> cbiesinger: the definition of the min-content block size still exists in the spec though
20:29:25 <fremy> cbiesinger: and it has this issue, so we need to fix this no matter what
20:29:36 <fremy> dbaron: sure, but I'm not sure we should have this in the spec at all
20:29:37 <Karen> Karen has joined #css
20:29:44 <AmeliaBR> min-content block size definition: https://drafts.csswg.org/css-sizing-3/#min-content-block-size
20:30:10 <fremy> cbiesinger: in the common case in a column-flexbox, it defaults to min-height, min-content
20:30:18 <myles_> myles_ has joined #css
20:30:23 <fremy> dbaron: and how do you determine what that height is?
20:30:34 <fremy> cbiesinger: you use the inline size you derive from the sizing properties
20:30:52 <fremy> dbaron: so it's not really an intrinsic size, it's a specific size that depends on the layout you are in the middle of doing
20:31:06 <fremy> dbaron: so we don't really need this concept for that case
20:31:32 <fremy> dbaron: but for othogonal flows, you'd allegedly need the general case?
20:31:47 <fremy> fantasai: for orthogonal flows, you have to pick a size anyway
20:32:02 <fremy> dbaron: so, ok, regardless, we need to define very precisely that inline size
20:32:19 <fremy> iank_: is it true that in our implementation, the value is (...) ?
20:32:32 <fremy> cbiesinger: yes, the post-layout size is (...)?
20:33:13 <fremy> iank_: in our implementation, min-content and max-content were the same, and were the post-layout block size of this element, as if no other constraints were applied
20:33:22 <fremy> ^ clarifying the ... above
20:33:30 <fremy> iank_: and it works thanks to the clamping
20:33:53 <fremy> fantasai: I think it's very clear to me that the change was not correct anyway
20:34:01 <fremy> fantasai: so we should revert this edit anyway
20:34:12 <fremy> fantasai: but I agree we should also make sure we get things defined explicitly
20:34:28 <fremy> fantasai: and maybe think whether min-content and max-content should be the same
20:34:38 <fremy> dbaron: and even if they are the same, we need to define what they are
20:34:56 <fremy> dbaron: but if we don't have a first-layout pass, sometimes it happens?
20:35:11 <fremy> iank_: for min-height/max-height you do, because you clamp an existing height
20:35:35 <fremy> fantasai: so, yeah, using the default value is wrong because sometimes auto is not min-content
20:35:57 <fremy> fantasai: I can't think of a reason for blocks to want min-content != max-content
20:36:16 <fremy> fantasai: maybe for grid, we could trigger the different distributions algorithms for them
20:36:21 <fremy> fantasai: we should think about that
20:36:23 <fantasai> s/maybe/but/
20:36:44 <fantasai> It's less clear that they should be different in this case, because there are different space distribution rules for each
20:36:46 <fremy> astearns: so, I hear that we want to revert, and try to get a definition for this
20:36:59 <fremy> astearns: even if there is some scepticism we can get a definition that works
20:37:17 <fremy> dbaron: I would also not want to call them intrinsic if they are not intrinsic anymore
20:37:39 <fremy> dbaron: it seems to me we are defining something else entirely
20:37:56 <fremy> dbaron: doing some of these things require major changes in some algorithms, and I'm not sure what the use cases are
20:38:06 <fremy> cbiesinger: min-height:min-content seems useful
20:38:28 <fremy> dbaron: it is not impossible that this could take a year for us to implement, and I'm not sure this is worth
20:39:04 <fremy> dbaron: there are some existing implementations, but did we check that they match, and not are just superficially similar
20:39:09 <fremy> dbaron: I am not sure
20:39:15 <fremy> dbaron: so I don't want to take this lightly
20:39:24 <fremy> dbaron: so I would rather have a full proposal
20:39:50 <fremy> dbaron: so I can evaluate complexity, and evaluate the cost/benefit ratio
20:40:17 <fremy> dbaron: there are things that happen in gecko when you specify these things of course, but are we interop? probably not?
20:40:31 <fremy> emilio: I don't think we have impelemnted to block size that works in the block axis
20:40:51 <fremy> TabAtkins: (pointing another case that seems wrong in gecko, even in the inline axis)
20:41:08 <fremy> cbiesinger: agrees that some cases are difficult in the inline cases
20:41:38 <fremy> TabAtkins: we do use an approximation here, that was better than gecko that assumes a single-column
20:41:49 <fremy> TabAtkins: Edge had a good implementation
20:41:59 <fremy> TabAtkins: but regardless, we didn't
20:42:12 <fremy> TabAtkins: so I tend to agree that intrinsic isn't always as "intrinsic" as the name implies
20:42:18 <fremy> TabAtkins: it sometimes requires full layout
20:43:07 <fremy> fantasai: how about changing the spec to say that we want to match the `auto` height
20:43:19 <fremy> fantasai: but in the sense of `auto` that computes an height
20:43:35 <fremy> fantasai: not like in grid where `auto` sometimes means `stretch` etc
20:43:37 <fantasai> s/height/height based on the content size, rather than filling the container etc./
20:43:52 <fremy> astearns: can we resolve of reverting?
20:44:09 <fremy> dbaron: I'm uncomfortable going back to undefined
20:44:23 <fremy> astearns: but other engines don't want that current spec text
20:44:32 <fremy> dbaron: ok, but this is a can of worms
20:44:47 <fremy> dbaron: (snarky comments about multiple engines)
20:44:59 <fremy> cbiesinger: I'm optimistic we could get this interoperable
20:45:22 <fremy> iank_: for the cases that cbiesinger described, it would be easy to implement the correct behavior for that subset
20:45:27 <fremy> iank_: and we think it's useful
20:45:54 <fremy> astearns: as you implement subset, it would be nice to describe things in details, so we could find out if interop is possible
20:46:31 <fremy> fantasai: technically, the behavior we want should already exist in the engine, it might not just be called in that specific scenario
20:46:49 <fremy> fantasai: but the keyword would allow to tap in the computations that exist
20:47:13 <fremy> fantasai: possibly there are cases where you would need much more layout than engines are willing to do
20:47:22 <fremy> fantasai: but there are a lot of reasonable cases
20:47:32 <fremy> fantasai: and for those cases we should figure out what should happen and standardize that
20:47:38 <fantasai> s/to do/to do, e.g. for the width of a multiline column flexbox/
20:48:27 <fremy> astearns: basically dbaron hesitates due to lack of precise details
20:48:45 <fremy> cbiesinger: is there a particular case you think would be very hard?
20:48:51 <fremy> cbiesinger: so we could find out if we could solve that one?
20:49:27 <fremy> dbaron: intrinsic size depending on the inline, it could depend on layout optimizations
20:49:42 <fremy> dbaron: and there might be cases where we try to figure out block before inline
20:49:53 <fremy> dbaron: and all those cases seem intricate
20:50:16 <fremy> fantasai: yeah, grid has two passes for that reason
20:50:47 <fremy> fantasai: (explains how these metrics are computed already today, she thinks)
20:51:26 <fremy> dbaron: I'm worried it uses a value from late in the system, early in the system
20:51:53 <fremy> dbaron: gladly calc doesn't allow to make computations based on those values usually
20:52:05 <fremy> dbaron: but there might be cases where we do this accidentally in the algorithm
20:52:13 <fremy> dbaron: and it might cause instability/ec
20:52:34 <fremy> cbiesinger: I understand the concerns now
20:52:42 <fremy> cbiesinger: I'm still inching towards it's sufficiently useful
20:52:52 <fremy> dbaron: is is sufficiently useful that you would be willing to write a spec?
20:53:26 <fremy> TabAtkins: (proposed to meet next time he was in new-york to work on it, but cbiesinger is not based in NY)
20:53:39 <fremy> cbiesinger: I will write something
20:53:43 <fremy> cbiesinger: I can try writing a spec
20:54:12 <fremy> astearns: so, first resolution attempt, can we revert what's in the spec now?
20:54:43 <fantasai> https://github.com/w3c/csswg-drafts/issues/3973#issuecomment-498062046
20:54:45 <fremy> (can we get a link to the change)
20:55:37 <fremy> dbaron: do we know why we made the resolution that let to this changeset?
20:55:41 <fremy> TabAtkins: I don't recall
20:57:27 <fremy> dbaron: what I don't like is that the revert will trigger chrome to revert
20:57:38 <fremy> dbaron: and that revert will be unspecced but people will rely on their behavior
20:57:55 <fremy> florian: we could have an issue in the spec
20:58:18 <fremy> Rossen: that seems overkill, we have an issue on github seems enough
20:58:40 <fremy> Rossen: I think it would be better to first get a strawman of the chrome behavior, and we can resolve the revert at that time
20:58:43 <fremy> cbiesinger: ok, sounds fine
20:58:58 <fremy> any objection to this way forward?
20:59:27 <fremy> RESOLVED: cbiesinger will document chrome's behavior and we will revisit
21:00:08 <fremy> Topic: should outline apply to elements with display:contents
21:00:15 <astearns> github: https://github.com/w3c/csswg-drafts/issues/3323
21:00:17 <myles> myles has joined #css
21:00:36 <fremy> TabAtkins: I don't think it shouldn't
21:00:50 <fremy> TabAtkins: this property is already weird and magic
21:00:58 <innovati> innovati has joined #css
21:01:12 <fremy> florian: there is a trend however towards removing the magic
21:01:27 <fremy> TabAtkins: it's ok, we will then spec this case
21:01:36 <fremy> dbaron: we usually had outlines around descendants
21:01:36 <argyle> argyle has joined #css
21:01:42 <fremy> dbaron: and that caused issues
21:01:54 <fremy> iank_: in chrome there is a difference between focus and normal outlines
21:02:03 <fremy> bkardell_: can you clarify that?
21:02:06 <fremy> iank_: not correctly
21:02:36 <fremy> florian: when outline-style is auto, browsers can do even more magic than the other values, which already are permissive
21:03:00 <fremy> florian: focus outline in chrome is even more special than auto, I think, but it's not clear this is a requirement or historical accident
21:03:24 <fremy> TabAtkins: what if required to be the bounding box of all descendants
21:03:31 <fremy> florian: that's too much
21:03:44 <fremy> florian: we still want fragment outlines
21:04:05 <iank_> q+
21:04:06 <emilio> q+
21:04:16 <fremy> florian: I think it's ok to just say that for that special cases we will support the children
21:04:27 <fremy> florian: we will spec later
21:04:49 <fremy> una: but we would still render an outline around the element, right?
21:04:59 <fremy> TabAtkins: for display:contents there is no box for the element
21:05:50 <fremy> AmeliaBR: if we define an algorithm that creates a set of polygons based on the descendants, that would be fine, but if we want to use a box, this won't work
21:05:51 <bkardell_> q+
21:06:09 <fremy> TabAtkins: sure, but I would want to special case this in this very specific case
21:06:22 <fremy> AmeliaBR: also for other cases, or just display contents
21:06:39 <astearns> ack iank_
21:06:43 <fremy> TabAtkins: obviously people don't like it, so maybe just for display:contenents
21:06:59 <fremy> iank_: enabling outlines on display:contents is very difficult for our implementation to do
21:07:02 <fremy> iank_: so I
21:07:08 <fremy> 'd prefer not to go down that path
21:07:23 <fremy> iank_: I'm a little bit concerned about the accessibility case
21:07:35 <fremy> emilio: my comment was in the same direction
21:07:49 <fremy> emilio: drawing something keyed off that doesn't exist in the tree, is tricky
21:08:15 <fremy> emilio: focus on these elements is already something that is weird already
21:08:24 <fremy> emilio: I'm afraid it wouldn't be interoperable
21:08:30 <fremy> TabAtkins: well we could define this
21:08:50 <fremy> emilio: for the bikeshed cases, we could add a css rule
21:09:01 <fremy> like a:focus > * { outline: auto }
21:09:25 <fremy> TabAtkins: yeah, and if I had subgrid I woudln't need it either way, maybe that's fine
21:09:28 <bkardell_> q-
21:09:41 <fremy> emilio: and for the a11y tree, I think we resolved they would be in the tree
21:09:48 <fremy> fantasai: yes, they are in the tree, we resolved on this
21:10:37 <fremy> TabAtkins: so for bikeshed, I can add the rule, and use subgrid later, it's fine
21:10:47 <fremy> TabAtkins: you can already tab to them
21:10:57 <fantasai> fremy: That's not true yet
21:11:28 <fremy> dbaron: saying these elements have an outline is like poking a hole in the model
21:11:49 <fremy> dbaron: it's a bit weird, at what point are we not opening a can of worms?
21:11:52 <jensimmons> subgrid will lessen the desire to use `display: contents` to make grandchildren into grid items — but the usecase for Flexbox is the same. To make a flexbox grandchildren into flex items
21:12:11 <fremy> dbaron: like, people might want to ask other stuff like background
21:12:25 <fremy> TabAtkins: I think this is very specific though
21:12:36 <leaverou> fwiw, it looks like elements with display: contents elements don't receive focus right now in either Chrome or Gecko (not sure if that's related to the bug mentioned): https://codepen.io/leaverou/pen/oROLQm
21:12:53 <fremy> TabAtkins: like you can focus or interact with something, and outline is needed to show that, but it's very specific
21:13:06 <fremy> una: so you use display:contents and still want to interact, what is the use case?
21:13:20 <fremy> TabAtkins: explains the use case (bikeshed)
21:13:36 <fremy> una: so, you definitely want outlines here right?
21:13:45 <fremy> TabAtkins: yes!
21:13:55 <fremy> TabAtkins: and I believe this is the only hole we want to make
21:14:11 <fremy> fantasai: can we get bikeshed to stop doing this while it's not fixed everywhere though?
21:14:16 <fremy> TabAtkins: ok, fine
21:14:20 <fantasai> s/it's/a11y is/
21:14:46 <fremy> astearns: so, can we resolve on this?
21:15:04 <fremy> florian: I think it's fine to let authors have to supply the rule?
21:15:16 <fremy> emilio: I would like that
21:15:24 <fremy> TabAtkins: it woudln't work by default though
21:15:30 <fremy> emilio: yes, I think
21:16:25 <fremy> (discussion about the fact we might get a few outlines next to each other)
21:16:31 <fremy> TabAtkins: I think it's fine
21:16:49 <fremy> florian: And we want a note to make sure authors are aware if we don't do this?
21:17:24 <fremy> TabAtkins: ok, I'm fine with this, authors can use :focus-visible
21:17:38 <fremy> TabAtkins: I'll put a note and a remark about subgrid
21:17:53 <fremy> astearns: so, proposal, is to not change the spec, outlines do not apply, but we add an example to the spec
21:18:29 <emilio> fremy: I had a proposal for the outlines for the children itself
21:18:39 <emilio> fremy: that doesn't sound weird
21:19:00 <emilio> fremy: when you're focusing something you add an outline to it
21:19:07 <emilio> fremy: not sure if it's complex
21:19:11 <emilio> florian: I think it's complex
21:19:27 <emilio> fremy: but I'd set the outline property on the child box
21:19:47 <fantasai> emilio: At least in Gecko, those outlines are added via CSS
21:19:49 <fremy> emilio: at least in gecko, those outlines are added via css
21:20:00 <fantasai> emilio: It's effectively via :focus-visible { outline: 1px dotted }
21:20:01 <fremy> so we use :focus-visible { outline... }
21:20:09 <fantasai> emilio: so you cannot speical-case on the value of display
21:20:22 <fantasai> florian: Was saying it'd be based on used value
21:20:34 <fantasai> emilio: Focusing an element changes the value of descedant elements?
21:20:35 <fremy> and we cannot special case because selectors cannot depend on values
21:20:44 <fantasai> heycam: If it's up to the authors to specify outline on the children ...
21:20:47 <fremy> fremy: ok, I understand the concern
21:20:52 <fantasai> heycam: There's  no way to do that if only a text node child
21:21:09 <fantasai> TabAtkins: No real use case for 'display contents' in that case
21:21:16 <fantasai> dbaron: What about two pieces where some are text
21:21:22 <fantasai> dbaron: e.g. link with plaintext and a span
21:21:30 <fantasai> TabAtkins: We need a pseudo-element for naked text then
21:21:37 <fantasai> florian: If you do that, then yo ucan add another span
21:21:42 <fantasai> s/florian/fremy/
21:21:59 <fantasai> heycam: Check if parent is display contents?
21:22:03 <fantasai> ScribeNick: fantasai
21:22:06 <fantasai> heycam: flattened tree parent
21:22:09 <fantasai> emilio: that's awkward
21:22:24 <fantasai> jensimmons: Any use cases for 'display: contents' besides lack of subgrid or maybe flex?
21:22:33 <fantasai> TabAtkins: Probably, but subgrid's the only one I've used personally
21:22:39 <fantasai> jensimmons: Why did we invent display: contents?
21:23:02 <fantasai> AmeliaBR: To have layout modes depending on parent-child relationships not disturbed by markup
21:23:14 <fantasai> TabAtkins: Before grid, was for flexbox
21:23:21 <fantasai> hober: Basically grid or flex
21:23:21 <AmeliaBR> s/by markup/semantic wrapper markup/
21:23:30 <fantasai> rachelandrew______: Forms have a ton of markup
21:23:38 <fantasai> rachelandrew______: so would want to use it there
21:23:44 <fantasai> rachelandrew______: to get rid of things like box around fieldset, etc.
21:23:50 <hober> s/Basically grid or flex/weird flex but okay/
21:23:50 <fantasai> rachelandrew______: once a11y issues are solved
21:24:28 <fantasai> jensimmons: We've eliminated the box, but the desire wasn't to eliminate the box but to have a flattened layout model with hierarchical markup
21:24:36 <fantasai> jensimmons: Maybe 'display: contents' was the wrong solution, too general
21:24:40 <fantasai> jensimmons: what we wanted was subgrid
21:24:51 <fantasai> jensimmons: now we've eliminated the box, and dealinng with fallout
21:25:03 <fantasai> jensimmons: but there wasn't a good reason to eliminate the box, except lack of flexbox
21:25:15 <fantasai> TabAtkins: Well, in flexbox, still want to be able to reorder things
21:25:24 <fantasai> dbaron: If you want the box back, you have to figure out where the box is
21:25:32 <fantasai> dbaron: by eliminating box, don't have to define where box is
21:25:45 <fantasai> dbaron: you make the element disappear so you can deal with the children individually
21:25:57 <fantasai> dbaron: so layout hasn't assigned a position for it, so can't draw the box if you don't know where it is
21:26:25 <fantasai> TabAtkins: So if shadow-including parent is 'display: contents' but should have an outline drawn on it, draw on children instead
21:26:45 <fantasai> AmeliaBR: How does that definition work if you have 'display Contents' inside 'display contents', how do we propagate this?
21:26:49 <fantasai> emilio: Recursive
21:26:52 <fantasai> emilio: not a big deal
21:26:58 <fantasai> emilio: but if should have an outline at paint time, that's vauge
21:27:06 <fantasai> emilio: has to count for visiblity, bunch of other stuff
21:27:11 <fantasai> heycam: accounting for visibility is annoying
21:27:29 <fantasai> heycam: ...
21:27:43 <fantasai> AmeliaBR: You can have a focusable element with visibility :hidden and some children that are visible
21:27:48 <fantasai> AmeliaBR: don't see an outline
21:27:51 <fantasai> ...
21:27:58 <fantasai> myles: Why don't we apply this logic to other CSS properties?
21:28:03 <fantasai> myles: I don't think that's a road we wnat to go down
21:28:48 <fantasai> astearns: When parent has visibility: hidden?
21:28:59 <fantasai> florian: If you have 'display: contents; visibility: hidden' can you focus it?
21:29:10 <fantasai> AmeliaBR: Most browsers won't focus such a thing
21:29:27 <fantasai> fremy: we draw it in Edge...
21:29:34 <fantasai> astearns: Does sound like model-breaking behavior
21:29:45 <fantasai> astearns: Defining whether box can be fousable based on CSS properties we should ignore
21:29:54 <una> Test case to play with (nested display:contents) forked from Rachel's pen: https://codepen.io/una/pen/joRMEL
21:29:56 <fantasai> fremy: If you're visiblity: hidden, you cannot be focused anyway
21:30:08 <fantasai> fremy: So this issue isn't relevant
21:30:08 <bkardell_> display: schrodinger-cat;
21:30:10 <myles_> myles_ has joined #css
21:31:02 <fantasai> astearns: Two options I've heard
21:31:11 <fantasai> astearns: 1) Don't draw an outline. Stylesheet can try to style children or something
21:31:23 <fantasai> astearns: 2) Have UA figure out something to do with 'display: contents' things that shoudl have an outline
21:31:31 <fantasai> astearns: We have one possible definition of how that could occur
21:31:44 <fantasai> astearns: I'm unclear as to whether there's enough motivation to figure out UA magic to get this done
21:32:03 <fantasai> AmeliaBR: I prefer solution that requires authors to do less a11y-aware work, since lots of authors won't bother
21:32:14 <fantasai> fremy: Also govt' requirements, so browsers should do it by default
21:32:51 <fantasai> astearns: Cameron, do we need to evaluate conditions for outlining?
21:33:08 <fantasai> heycam: I don't know, if you had opacity: 0...
21:33:20 <fantasai> AmeliaBR: Then you wouldn't see it on the children either
21:33:29 <fantasai> TabAtkins: Aside from "don't draw this element", won't get focus outline
21:33:54 <fantasai> dbaron: But if you're display: contents, opacity has no effect
21:34:03 <fantasai> florian: Painting outlines on elements not in rendering tree
21:34:12 <fantasai> florian: Usually you don't iterate over tree to paint an element
21:34:31 <fantasai> florian: This is not the case for focus, you don't have to evaluate the entire tree to find focus
21:34:38 <fantasai> florian: We know if a focused element is focused
21:35:01 <fantasai> AmeliaBR: Much more narrow case
21:35:26 <fantasai> dbaron: There's another option along those lines, which is to say ... maybe you can't do that because selector-property dependency
21:35:51 <fantasai> dbaron: was going to say was if you're display: contents and you're focused, focus-visible aplies to descendants but cna't do that
21:36:04 <fantasai> fantasai: I think what heycam said was the simplest solution
21:36:08 <fantasai> emilio: I still think they're hacks
21:36:17 <fantasai> emilio: It's not impossible, just feels like a layering violation
21:36:54 <fantasai> florian: iank_ You were saying it's hard?
21:37:08 <fantasai> iank_: I believe our focus outlines get painted differently from normal ones
21:37:17 <fantasai> florian: What would be hard about normal ones
21:37:27 <fantasai> iank_: Don't have anything to hook up to invalidation logic
21:37:33 <fantasai> iank_: We'd need to introduce this backing to layout tree
21:37:42 <fantasai> fremy: The children draw the outline, so children invalidation
21:37:55 <fantasai> florian: but if you change the property on the parent, you need to know that the children have to be invalidated
21:38:02 <fantasai> emilio: It's a hack
21:38:15 <fantasai> heycam: We'd have to propagate a change hint to the children. Not impossble.
21:38:19 <fantasai> emilio: Nothing is impossible
21:38:24 <fantasai> heycam: Sure, but also doesn't seem too hard
21:38:39 <fantasai> astearns: It is slightly better to introduce hack into UA than to expect authors to have the same hack in their CSS
21:38:40 <leaverou> wouldn't drawing outlines on children be confusing if an element only had one child, which was focusable? Tabbing would produce no visible difference
21:39:14 <fantasai> fremy: If we have in the platform 'display: contents' then it's our responsibility to provide a11y support, putting it in the tree and providing outlines is part of that
21:39:41 <fantasai> emilio: Whether propagating outline , and someone mentioned browsers don't focus visibility hidden elements even if you have visibile children
21:39:46 <fantasai> florian: Because you can't focus them
21:40:08 <fantasai> emilio: link with 'display: contents' we say has to be focused
21:40:16 <fantasai> emilio: but link with 'visibility: hidden' we don't focus, and it's OK
21:40:21 <fantasai> TabAtkins: I consider it a bug. That I don't care about
21:40:31 <fantasai> florian: ...
21:40:42 <fantasai> TabAtkins: Nobody has brought up that as a problem in the 20+ yrs
21:40:56 <fantasai> TabAtkins: whereas within 6 months we had bugs filed against 'display: contents' for not being  focusable
21:41:19 <fantasai> leaverou: If we draw outlines on children, might be confusing if only one child that is also focusable
21:41:24 <fantasai> leaverou: there would be no visible difference
21:41:53 <heycam> fantasai: there's already no difference if you have an unstyled box wrapped around a child
21:41:58 <heycam> ... the outlines will look the same
21:42:17 <heycam> ... it's not a new problem.  whether the box is unstyled with no pbm, or it's display:contents, it makes no difference whether the outline is on the parent or child
21:42:27 <heycam> AmeliaBR: comes down to a design issue
21:42:43 <fantasai> florian: Back to earlier point, difficulty in invalidation logic
21:42:53 <fantasai> florian: you could reduce to focus case
21:42:56 <fantasai> fantasai: I think that's harder
21:43:01 <fantasai> emilio: think it's harder for us
21:43:30 <fantasai> emilio: First one you would implement display: contents with outline changed, go down the tree and invalidate other elements inside it
21:43:40 <fantasai> emilio: but in the other case would also need to evaluate focus. More special-casy
21:43:46 <fantasai> iank_: Can't speak with authority for us
21:44:05 <fantasai> iank_: The thing that scares me is potentially if outline is painted by the children, how do you make sure the outline is contiguous
21:44:07 <fantasai> florian: You don't
21:44:13 <fantasai> florian: You just make it on the children and whatever
21:44:21 <fantasai> fremy: That's the proposal
21:44:37 <fantasai> florian: If youre existing logic merges outlines, then do that. otherwise don't
21:44:41 <fantasai> emilio: That's not quite similar
21:44:48 <fantasai> emilio: You also have to check outline on parent vs child
21:45:15 <fantasai> emilio: If have different outline properties...
21:45:30 <fantasai> AmeliaBR: What if say children treated as have 'outline: inherit'
21:45:53 <fantasai> fremy: Just check if 'outline-style' is 'none', and if parent s 'display: contents' draw parent's outline
21:45:59 <fantasai> dbaron: Or draw two outlines?
21:46:05 <fantasai> dbaron: and don't worry about those conditions?
21:46:24 <fantasai> una: I think it's more confusing to have simultaneous outlines
21:46:50 <fantasai> una: if you're tabbing into the children ...
21:47:13 <heycam> fantasai: only draw the outline if it's specified
21:47:22 <heycam> ... if you happen to specify 3 outlines on the 3 different elements, you'd draw all of them
21:47:35 <heycam> ... might just be drawing because one is focused, because you've got outline specified, ...
21:47:45 <heycam> ... not dissimilar to how you handle borders for example, layer them all and paint them
21:47:54 <heycam> ... if they fall on top of each other, you won't see the ones underneath
21:48:05 <fantasai> dbaron: In the normal case for focus, if you have a box 'display: contents' with three children
21:48:24 <fantasai> dbaron: you tab to parent, you see all three outlined, and then each one outlined individually as you tab through them
21:48:44 <fantasai> florian: Don't see how to do btter than that, the children could be anywhere not necessarily adjacent
21:48:50 <fantasai> fremy: We're defining a default.
21:48:59 <fantasai> fremy: Not preventing authors from doing better
21:49:06 <fantasai> fremy: Just saying by default, we show an outline
21:49:08 <AmeliaBR> s/btter/better/
21:49:22 <fantasai> fremy: Not required to be pretty. pretty would be great, but ppl already change outlines on focus all the time
21:49:30 <fantasai> fremy: to make it prettier
21:49:40 <fantasai> fremy: But by default we want there to be an outline so it will be accessible
21:49:49 <fantasai> fremy: doesn't have to be pretty
21:49:54 <fantasai> emilio: it's still a hack
21:50:01 <fantasai> fremy: The goal is everybody at least gets an outline to show the focus
21:50:05 <fantasai> fremy: if someone doesn't like it, you can refine it
21:50:13 <fantasai> fremy: not prevent that, but at least provide something that works
21:50:41 <fantasai> florian: if outlines that are drawn for non-focused elements are not drawn, that's OK
21:50:45 <fantasai> florian: But for focus case should do it
21:50:58 <fantasai> AmeliaBR: So UA must propagate outline if it was caused by a focus change, but?
21:51:17 <fantasai> florian: Either do it always, or do it only for focus-triggered outlines, whichever is easier to implement
21:51:37 <fantasai> fremy: My guess is display: contents is much harder ot implement than what we are discussing now
21:51:44 <fantasai> fremy: we're just going the last mile to make it great
21:52:06 <fantasai> AmeliaBR: Can we make a tentative resolution that we will at least support the a11y use case and ask implementers to give feeback on which would be easier to implement: special-case for focus, or any outline?
21:52:20 <fantasai> emilio: display:contents make sense conceptually, this thing we are discussing makes no sense
21:52:23 <fantasai> emilio: it's a hack
21:52:27 <fantasai> emilio: in any browser implementing it's a hack
21:52:39 <fantasai> fremy: Users > web authors > implementers
21:52:47 <fantasai> emilio: I won't oppose but I will be very upset to implement this
21:52:52 <fantasai> TabAtkins: make Cameron do it :)
21:53:06 <fantasai> astearns: So deciding whether to draw only for focus?
21:53:07 <fantasai> Rossen: at least
21:53:08 <TabAtkins> I don't disagree that it's a hack.
21:53:13 <TabAtkins> It's just a necessary hack for a11y.
21:53:28 <fantasai> bkardell_: Are we positive you need to be able to set focus on display: contents element?
21:53:31 <fantasai> TabAtkins: Yes
21:53:37 <una> When authors use hacks, its our responsibility to make that experience more accessible
21:53:42 <rachelandrew______> CSS is making people sad again.
21:53:43 <fantasai> TabAtkins: because there are use cases to display: contents a link, an dyou need to be able to activeate the link if you're a keyboard user
21:53:58 <fantasai> TabAtkins: And when focusing you need to be able to see that it's focused
21:53:59 <AmeliaBR> Real world example: `<article class="slide"><a href="..." style="display: contents"><h2>article title</h2><img src="thumbnail"/></a><p>description</p></article>`
21:54:09 <fantasai> bkardell_: Can we just say you can't display: contents a link?
21:54:14 <AmeliaBR> (where the slide has flex or grid layout)
21:54:17 <fantasai> florian: There are use cases for it, though
21:54:54 <fantasai> AmeliaBR describes her use case
21:55:06 <fantasai> AmeliaBR: Want to lay out this article as three separate items in your layout
21:55:21 <emilio> AmeliaBR: why not making the link the flex container?
21:55:22 <fantasai> AmeliaBR: when someone tabs to that link, wnat to be able to see somehting is focuse
21:55:34 <una> Amelias example: https://codepen.io/una/pen/ZNZprm
21:55:49 <fantasai> florian gives a use case for page numbers or something
21:56:31 <fantasai> iank_: I'll have to check with implementers. I will project their sadness.
21:56:48 <Rossen_> Rossen_ has joined #css
21:56:54 <fantasai> astearns: So proposed resoution is we paint outlines on the children of a display: contents element
21:57:09 <fantasai> florian: ... special-case focus?
21:57:21 <fantasai> fantasai: I'm pretty sure it's easier to not special-case.
21:57:25 <fantasai> iank_: unsure
21:57:30 <Karen> Karen has joined #css
21:57:32 <fantasai> astearns: OK, but this is the case we want to support for a11y
21:57:40 <fantasai> TabAtkins: You can come back and say "no, it's really too hard"
21:58:01 <fantasai> TabAtkins: I don't want us to give up just because it's a little not great so we made it inaccessible
21:58:14 <fantasai> astearns: So any objection to make this change and get implementer feedback
21:59:05 <fantasai> RESOLVED: Outline of 'display: contents' is propagated to children for painting (for a11y on focus); implementers should give feedback on it
21:59:32 <dbaron> github-bot, end topic
21:59:46 <fantasai> Meeting closed.
21:59:51 <dbaron> trackbot, end meeting
21:59:51 <trackbot> Zakim, list attendees
21:59:51 <Zakim> As of this point the attendees have been leaverou, tantek, chris
21:59:59 <trackbot> RRSAgent, please draft minutes
21:59:59 <RRSAgent> I have made the request to generate https://www.w3.org/2019/06/04-css-minutes.html trackbot
22:00:00 <trackbot> RRSAgent, bye
22:00:00 <RRSAgent> I see no action items