01:40:32 <liam_> liam_ has joined #css
01:51:26 <projector> projector has joined #css
01:51:57 <leaverou> leaverou has joined #css
01:52:27 <Rossen> Rossen has joined #css
01:52:58 <shans> shans has joined #css
01:53:28 <sylvaing> sylvaing has joined #css
03:06:18 <Guest60> Guest60 has joined #css
04:26:43 <dauwhe> dauwhe has joined #css
05:04:25 <dauwhe> dauwhe has joined #css
06:33:32 <ankh___> ankh___ has joined #css
07:05:17 <dauwhe> dauwhe has joined #css
07:16:04 <dauwhe> dauwhe has joined #css
08:00:51 <antonp> antonp has joined #css
09:16:58 <dauwhe> dauwhe has joined #css
09:27:45 <dauwhe> dauwhe has joined #css
10:16:36 <Karen_> Karen_ has joined #css
11:18:10 <raks437> raks437 has joined #css
11:20:09 <raks437> raks437 has joined #css
11:28:18 <dauwhe> dauwhe has joined #css
12:00:26 <raks437> raks437 has joined #css
12:02:24 <plh> plh has joined #css
12:08:24 <castastrophe> castastrophe has joined #css
12:15:21 <raks> raks has joined #css
16:01:01 <RRSAgent> RRSAgent has joined #css
16:01:01 <RRSAgent> logging to https://www.w3.org/2020/09/10-css-irc
16:01:03 <Zakim> RRSAgent, make logs Public
16:01:05 <Zakim> Meeting: Cascading Style Sheets (CSS) Working Group Teleconference
16:02:10 <NeilS> NeilS has joined #css
16:02:18 <dholbert> dholbert has joined #css
16:02:41 <dholbert_> dholbert_ has joined #css
16:05:05 <fantasai> Topic: MathML - CSS Integration
16:05:51 <fantasai> astearns: First item was meta-issue by bkardell_
16:06:13 <dholbert> present+
16:06:16 <fantasai> bkardell_: number of issues brought to F2F last year
16:06:21 <fantasai> bkardell_: but concern about not having enough context
16:06:24 <fantasai> present+
16:06:37 <fantasai> bkardell_: spec wasn't clear enough
16:06:49 <fantasai> bkardell_: so filed an issue to explain the context of the MathML proposal
16:07:03 <fantasai> bkardell_: and how these CSS proposals fit into that context
16:07:26 <fantasai> astearns: Does anyone have questions about the overall projecthere?
16:07:41 <fantasai> iank_: Might be helpful if we get an update for impl in Chromium
16:08:07 <faceless2> present+
16:08:12 <fredw> fredw has joined #css
16:08:18 <bkardell_> present+
16:08:22 <fredw> hi
16:08:28 <emilio> present+
16:08:28 <NeilS> present+
16:08:42 <fantasai> fredw: Been working on MathML Core Level 1 specification
16:08:53 <fantasai> fredw: try to extract core concepts of MathML to implement in Chromium
16:08:57 <fantasai> fredw: Several things related to styling
16:09:05 <fantasai> fredw: It was difficult to implement without writing CSS
16:09:10 <fantasai> fredw: e.g. want to modify font, interact with font size
16:09:19 <fantasai> fredw: also I think one argument that ian was making
16:09:27 <fantasai> fredw: How implemented in WebKit / Gecko is internal
16:09:30 <fantasai> fredw: not really exposed to users
16:09:43 <fantasai> fredw: nicer to implement in a way that integrates with CSS, so can use CSS to modify
16:09:57 <fantasai> fredw: work in Chromium for MathML, more or less done with the work plan for this year
16:10:04 <fantasai> fredw: Already implemented most of the CSS proposals in Chromium
16:10:14 <fantasai> fredw: Only thing missing is text-transform, due to some controversy
16:10:21 <fantasai> fredw: and the script-level issue
16:10:30 <fantasai> fredw: need to update in response to feedback
16:10:49 <fantasai> bkardell_: worth saying context of meta-issue is that MathML didn't have very good interop
16:11:00 <fantasai> bkardell_: lot of things that were underdefined, not explained how they fit into the platform
16:11:05 <fantasai> bkardell_: answers duplicated with CSS solutions
16:11:23 <fantasai> bkardell_: so as part of work in Chromium, chrome team has been very good at making sure we have necessary answers
16:11:31 <fantasai> iank_: I've been pretty impressed with how things have been going
16:11:49 <fantasai> iank_: principle of using CSS, ability to drop in a grid into a MathML structure, really great to see
16:12:09 <fantasai> astearns: Remaining issues that are linked from this meta-issue are things that are working in Chromium, just looking to standardize?
16:12:13 <fantasai> astearns: or still bits to work out
16:12:29 <fantasai> fredw: More or less implemented in Chromium, but still have some flexibility to change. But it works
16:12:39 <fantasai> fredw: Some of these things are implemented in Gecko as internal CSS properties
16:12:43 <fantasai> fredw: would just need to actually expose them
16:12:47 <fantasai> fredw: WebKit want to do the same
16:13:02 <fantasai> Topic: cramped script style
16:13:17 <fantasai> Topic: math-oriented display values
16:13:33 <fantasai> github: https://github.com/w3c/csswg-drafts/issues/5385
16:14:05 <fantasai> bkardell_: 2 ways of integrating math into text
16:14:09 <fantasai> bkardell_: inline style or block style
16:14:14 <fantasai> bkardell_: proposal is to add display style
16:14:27 <fantasai> bkardell_: there was a comment in the issue that it should be "inline math" instad of "inline-math"
16:14:41 <fantasai> astearns: It would be a display-inside value
16:15:05 <fantasai> iank_: I think web devs are quite used to 'inline-foo' pattern
16:15:22 <fantasai> iank_: math is an inside display type, but maybe add as an alias
16:15:26 <fantasai> TabAtkins: I agree
16:15:35 <fantasai> TabAtkins: if we were adding a bunch more at once, could maybe make a clean break
16:15:52 <fantasai> TabAtkins: but just one would feel inconsistent
16:16:46 <fantasai> TabAtkins: so would say add inline-math into the table, easy
16:17:31 <fantasai> dholbert: Other places where 'display: contents' is like none?
16:17:36 <fantasai> faceless2: SVG
16:17:51 <fantasai> TabAtkins: various form elements, replaced elements
16:18:12 <fantasai> astearns: So we want ...?
16:18:29 <fantasai> TabAtkins: Add math to <display-inside>, add inline-math to <display-legacy>
16:18:48 <fantasai> iank_: It's basically zero overhead to add inline-math and convenient to authors
16:18:58 <fantasai> astearns: What happens to 'inline-math' on non-MathML elements?
16:19:08 <fantasai> fredw: Would behave like none
16:19:19 <fantasai> faceless2: I thought behaved like mrow
16:19:50 <fantasai> NeilS: Unrecognized elements in MathML context only
16:19:56 <bkardell_> fantasai:  generally speaking we try to avoid having things disappear if you do something slightly wrong
16:20:38 <bkardell_> fantasai: I don't think it should behave as display none on unrecognized elements.  The fact that display contents does that is really only because we couldnt' think of another way, but that isn't a good pattern
16:21:01 <fantasai> astearns: My expectation was behave like 'flow' on non-MathML element
16:21:08 <fantasai> astearns: either inline or block
16:21:22 <fantasai> iank_: If you have div { display: math; }, will effectively create a block flow internally
16:21:47 <fantasai> fredw: create a block node
16:21:52 <fantasai> iank_: would change box tree slightly
16:21:59 <fantasai> fredw: that's also what we do if don't set display: math on math element
16:22:07 <dholbert> for comparison / reference, data:text/html,<input type="radio" style="display:flex"> still renders as a radio button (we don't force it to display:none)
16:22:18 <fantasai> bkardell_: Unknown element will by default do what you're asking for, but what happens if you set 'display: math' explicitly on it, do something it can't do
16:22:39 <fantasai> fantasai: Ignoring isn't an option, can make it behave as a different value though
16:23:40 <fantasai> RESOLVED: Add 'math' as a <display-inside> value.
16:23:51 <fantasai> RESOLVED: Add 'inline-math' as a <display-legacy> value.
16:24:00 <fantasai> RESOLVED: 'math' outside of MathML context behaves as 'flow'
16:24:21 <fantasai> emilio: Does it behave as or compute to flow?
16:24:25 <fantasai> TabAtkins: whichever is easiest
16:24:34 <fantasai> emilio: compute to is more likely to be easier
16:24:43 <fantasai> emilio: it's what we do for 'display: contents'
16:24:55 <fantasai> RESOLVED: 'math' outside of MathML context computes to 'flow'
16:25:29 <fantasai> emilio: What if you have a non-MathML element inside a MathML element?
16:25:43 <fantasai> fredw: An element not in MathML namespace?
16:25:51 <fantasai> emilio: document.createElement('div') and append to math element
16:25:59 <fantasai> iank_: should work
16:26:05 <fantasai> emilio: should work how?
16:26:07 <fantasai> fredw: not defined
16:26:10 <fantasai> emilio: should be defined
16:26:17 <fantasai> emilio: SVG just doesn't create boxes for those elements
16:26:25 <fantasai> emilio: if you have a random div in SVG, doesn't do much. Not a fan of this.
16:26:34 <fantasai> NeilS: I thought MathML spec said it would be treated as an mrow?
16:26:45 <fantasai> fredw: non-MathML element, so not in the MathML namespace
16:27:03 <fantasai> NeilS: I thought we'd treat as unknown element, whether in mathml namespace or not
16:27:08 <fantasai> iank_: I don't think you specifically want that
16:27:23 <fantasai> iank_: the way that MathML core is currently specified, we can accept arbitrary elements inside MathML subtree
16:27:34 <fantasai> iank_: all the integration points, because more closely tied to CSS, should just work
16:27:45 <fantasai> iank_: if you have a div inside a mathML mrow or something like that, that should lay out as block
16:28:01 <fantasai> fantasai: Should lay out as block inside, whatever MathML wants to do inside
16:28:14 <fantasai> astearns: Seems need to do something around this, but let's get to other issues in the agenda
16:29:00 <faceless2> In SVG, unknown elements collapse to a <g> normally, or a <tspan> if they're inside a <text>
16:29:22 <fantasai> fantasai: Might make sense if you set div { display: math; } then behave same as unknown mathml namespace element with that, treat as mrow
16:29:24 <TabAtkins> Yup, and <mrow> is the mathml equivalent to a <g> basically
16:29:52 <fantasai> emilio: A bit skeptical that that works
16:29:59 <fantasai> emilio: if you put a float inside mathml?
16:30:06 <fantasai> iank_: Like flex/grid, it blockifies.
16:30:09 <fantasai> iank_: doesn't float
16:30:19 <fantasai> emilio: but you need to define these cases.
16:30:28 <fantasai> emilio: how does abspos behave, what's the containing block
16:30:30 <fantasai> emilio: etc.
16:30:43 <fantasai> fredw: tried to write this up in the spec
16:31:00 <fantasai> astearns: Let's raise issue on spec and come back to it some other day
16:31:20 <fantasai> emilio: I don't think these are obscure cases.
16:32:02 <fantasai> Topic: text-transform values for MathML
16:32:07 <fantasai> github: https://github.com/w3c/csswg-drafts/issues/5386
16:32:36 <fantasai> bkardell_: MathML created and exists with lots of tools/systems that don't have full access to Unicode
16:32:49 <fantasai> bkardell_: So legacy documents and even things written before that available
16:33:17 <fantasai> bkardell_: so number of case where the markup itself contains the information that you need in order to understand that this character that we want to render isn't the literal text value of the element
16:33:25 <fantasai> bkardell_: text-transforms were the solutions that we used
16:33:30 <fantasai> bkardell_: because that's what needs to happen
16:33:38 <fantasai> bkardell_: didn't see any reason to make that specifically hidden or unavailable to users
16:33:48 <fantasai> bkardell_: I know fantasai and Florian had raised some concerns last time
16:33:53 <fantasai> bkardell_: we've talked a bunch since then
16:34:03 <fantasai> bkardell_: fantasai has updated the meta-advice in css-text-3 to provide some nuance
16:34:07 <fantasai> bkardell_: the meaning *is* in the document
16:34:13 <fantasai> bkardell_: I don't know if ppl still object to these or what
16:34:31 <fantasai> fredw: 2 separate cases
16:34:38 <fantasai> fredw: case of math-auto, which is automatic italic
16:34:41 <fantasai> fredw: and this is the most important one
16:34:51 <fantasai> fredw: Not adding any semantics
16:34:57 <fantasai> fredw: default var rendered as italic
16:35:06 <fantasai> fredw: the other was strings for tools/documents not using Unicode
16:35:17 <fantasai> fredw: we are using text-transform to do the transformation even if MathML says to preserve the semantic
16:35:22 <fantasai> fredw: maybe a bit controversial
16:35:33 <fantasai> fredw: Florian was saying it's OK as long as we have the mathvariant attribute in the markup
16:35:43 <fantasai> fredw: if ppl really don't like, can only add math-auto one
16:35:53 <fantasai> fredw: might break some back compat, might need a polyfill, but...
16:36:00 <fantasai> NeilS: could be done internally and not break anything
16:36:13 <fantasai> NeilS: My concern is a11y, will changed character be in the a11y tree
16:36:34 <fantasai> bkardell_: had several ppl who implement screenreaders saying that the transform value is exposed on existing ones, and that was a sticking point because we don't always want that
16:36:52 <fantasai> bkardell_: certainly we can go either way here
16:37:00 <fantasai> bkardell_: either it will be, or it won't be, exposed to screenreaders
16:37:22 <fantasai> NeilS: As long as exposed to screenreaders, then no a11y issue
16:37:28 <faceless2> +1 to Neils comment
16:37:30 <fantasai> bkardell_: There's a specific example in the issue itself
16:37:38 <fantasai> bkardell_: to non-Math ppl like myself, not intuitive
16:38:03 <fantasai> emilio: Proposal of math-auto
16:38:14 <fantasai> emilio: is it like user-select, like auto behaves as inherit or something?
16:38:18 <fantasai> emilio: it's not clear to me
16:38:29 <fantasai> emilio: seems like pseudo-code that Rob posted would be computed value time which is a bit odd
16:38:54 <fantasai> fredw: basically transformation, whether italic or not  [...]
16:38:58 <fantasai> fredw: it doesn't copute to italic
16:39:02 <fantasai> s/copute/compute/
16:39:15 <fantasai> iank_: would it be fair to say that you'd apply to ...
16:39:17 <fantasai> fredw: only to mi element
16:39:24 <fantasai> fredw: mi { text-transform: math-auto }
16:39:31 <fantasai> fredw: Takes effect when only one letter
16:39:37 <fantasai> fredw: don't think it can be computed
16:39:48 <fantasai> iank_: the specific variant is based on the attribute on the mi element?
16:40:06 <fantasai> bkardell_: in the example or in general?
16:40:30 <fantasai> bkardell_: mi is special, because it has this idea of a single-letter identifier
16:40:37 <fantasai> bkardell_: those are treated stylistically a certain way
16:40:43 <fantasai> bkardell_: but that's only stylistic, no meaning
16:40:54 <fantasai> bkardell_: but math-variant is where you provide additional semantics missing from your lack of character support
16:41:17 <fantasai> iank_: so if you have mathvariant specified, it turns off that auto text-transform behavior?
16:41:26 <fantasai> faceless2: mathvariant is acting as a preshint
16:41:36 <fantasai> faceless2: but math-auto, if no other math-transform is set
16:41:47 <fantasai> faceless2: it would be italicized if it was one letter
16:41:55 <fantasai> iank_: so also have all the other math transform values
16:42:00 <fantasai> fredw: can override the default behavior
16:42:16 <fantasai> iank_: so it's for this leaf to do this slight magical behavior
16:42:24 <fantasai> NeilS: I think math-auto is really presentation
16:42:37 <fantasai> NeilS: Others are there for legacy issue, and not presentation, should actually map to a different character
16:42:44 <fantasai> NeilS: that's why may not be appropriate for CSS
16:43:16 <bkardell_> fantasai:  I guess I have 1 question and 1 concern...
16:43:45 <bkardell_> fantasai: does the auto italic thing be a text transform really, or does it really just want font styling?
16:44:03 <bkardell_> fredw: the way math fonts are designed, you do
16:44:31 <bkardell_> fantasai: the other ones you do want to be a semantic effect. I am a little uncomfortable with this.
16:44:57 <bkardell_> fantasai:  whatever screen readers do it's intention was clear and I don't love changing that
16:45:33 <fantasai> astearns: if this is only way to get semantics for legacy stuff, do we really want to expose it to CSS so that it can be used on new things?
16:45:53 <fantasai> bkardell_: MathML Core 1 is a pretty minimal subset, there are lots of things that use more elements than we're including
16:46:07 <fantasai> bkardell_: and the intent is for mathml to have a healthy future with additional levels
16:46:12 <fantasai> bkardell_: so will be unknown elements
16:46:25 <fantasai> bkardell_: so weird to say you don't have access to the magic to make other elements work like L1
16:46:36 <fantasai> iank_: broadly agree with that
16:46:44 <fantasai> iank_: also from what we've heard from screenreader developers
16:46:50 <fantasai> iank_: this sort of text-transform is only presentation
16:46:54 <fantasai> iank_: that ship sailed a long time ago
16:47:07 <fantasai> bkardell_: it's not that they couldn't be that
16:47:09 <fantasai> bkardell_: the new one has to be
16:47:28 <fantasai> iank_: text-transform: uppercase is definitely exposed to screenreaders
16:47:36 <fantasai> NeilS: Another case we haven't resolved yet
16:47:40 <fantasai> NeilS: is hyphen-minus
16:47:42 <fantasai> NeilS: vs minus
16:47:47 <fantasai> NeilS: They're defined to be equivalents
16:47:58 <fantasai> NeilS: it should map hyphen-minus to U+2122 MINUS
16:48:09 <fantasai> NeilS: Could imagine that text-transform would be the way to do this as well
16:48:32 <bkardell_> fantasai: you could go either way with that one
16:48:40 <fantasai> faceless2: You'd also struggle to do that with text-transform
16:49:02 <fantasai> faceless2: apply to whole document, then declaration for e.g. fraktur would override and disable
16:49:12 <fantasai> bkardell_: I suggest we either resolve or move on
16:49:20 <fantasai> fredw: maybe just resolve on math-auto, and unsure for rest
16:49:30 <fantasai> astearns: I think I heard you say that math-auto is the only one you have implemented so far?
16:49:34 <fantasai> bkardell_: upstream chromium
16:49:43 <fantasai> fredw: we have the others implemented in a separate branch
16:49:47 <fantasai> astearns: so let's resolve on math-auto
16:49:56 <fantasai> astearns: any objections to adding math-auto to text-transform?
16:50:07 <fantasai> emilio: Not quite objection, but want to clarify how it behaves exactly
16:50:27 <fantasai> astearns: resolve to add, then work on details
16:50:32 <fantasai> RESOLVED: Add math-auto to text-transform
16:50:43 <fantasai> astearns: still seems like there's concerns around the rest of math-values
16:51:00 <fantasai> faceless2: The only concerns are wrt exposing to screenreaders?
16:51:08 <fantasai> astearns: there seem to be a lot of them, also, that's my concern
16:51:45 <fantasai> fantasai: I don't like adding things that are supposed to alter semantics to CSS.
16:51:51 <fantasai> astearns: let's hold off on these for now
16:52:57 <fantasai> fantasai: ...
16:53:23 <fantasai> iank_: would it be possible to add a new HTML-level attribute with mathvariant and then, if you set `text-transform` to auto that'll read the attribute and apply it?
16:53:34 <fantasai> iank_: Semantics would still be in the document, just whether you apply it would be in CSS
16:53:42 <fantasai> NeilS: I don't think it makes sense to add something new
16:53:49 <fantasai> NeilS: this is all for legacy support
16:54:14 <fantasai> bkardell_: maybe talk about that, maybe at HTML layer we can do something
16:54:21 <fantasai> NeilS: I have to drop off for another MathML meeting
16:54:40 <fantasai> Topic: math style
16:54:48 <fantasai> github: https://github.com/w3c/csswg-drafts/issues/5387
16:55:30 <fantasai> NeilS: 2 ways of displaying math, one tries to minimize height to fit in lines better
16:55:34 <fantasai> NeilS: one is taller one
16:55:46 <fantasai> NeilS: shifts positions / sizing rules, etc.
16:56:04 <fantasai> NeilS: Designed so you don't have as much gap in lines if you have math in it
16:56:14 <fantasai> NeilS: rules defined in TeXBook
16:56:32 <fantasai> astearns: the switch is true or false for displaystyle?
16:56:37 <fantasai> astearns: I like normal and compact much better
16:56:58 <fantasai> iank_: Makes sense, but seems to also be able to affect the font size?
16:57:05 <fantasai> iank_: that will need to be carefully defined
16:57:19 <fantasai> NeilS: That effect is through the scriptlevel feature
16:57:44 <fantasai> fantasai: Affects the font size, indirectly through another property
16:57:56 <fantasai> iank_: Happy to add, pending scriptlevel discussion
16:58:02 <fantasai> astearns: ok, any concerns to add?
16:58:18 <fantasai> astearns: would it go into display module?
16:58:23 <fantasai> iank_: Goes into MathML Core
16:58:40 <fantasai> RESOLVED: Add math-style: normal | compact
17:06:11 <astearns> zakim, end meeting
17:06:11 <Zakim> As of this point the attendees have been dholbert, fantasai, faceless, bkardell_, emilio, NeilS
17:06:13 <Zakim> RRSAgent, please draft minutes
17:06:13 <RRSAgent> I have made the request to generate https://www.w3.org/2020/09/10-css-minutes.html Zakim
17:06:16 <Zakim> I am happy to have been of service, astearns; please remember to excuse RRSAgent.  Goodbye
17:06:20 <Zakim> Zakim has left #css
17:07:08 <bkardell_> hmm, I guess a few people didn't present+ in those minutes @fantasai @astearns - I see neither iank_  nor fredw
17:07:09 <CSSWG_LogBot> CSSWG_LogBot has joined #css
17:07:30 <fredw> present+
17:07:35 <iank_> present+
17:07:40 <iank_> :)
17:11:59 <gsnedders> plinss: https://drafts.csswg.org is claiming there are no specs in the repo!
17:18:45 <astearns> TabAtkins: maybe a bikeshed issue? I'm not seeing the generated spec in https://drafts.csswg.org/css-shapes-1/
17:19:07 <TabAtkins> it's a temporary server issue
17:19:16 <TabAtkins> lemme see...
17:22:02 <TabAtkins> hm, looks like server needs kicking
17:22:21 <TabAtkins> there's a single process running, but it's orange which I think means something bad, and it's not making progress
17:23:51 <TabAtkins> i just did a push to the repo, should hopefully kick off the regen process again? we'll see
17:25:21 <TabAtkins> yeah, things look fine now
17:25:43 <astearns> thanks!
17:50:57 <AmeliaBR> AmeliaBR has joined #css
18:10:46 <plinss> @tabatkins yeah, an orange process means it crashed (usually due to a db server issue), when that happens it blocks other processes (to make sure someone looks at it)
18:11:52 <plinss> most can be safely deleted, and the server will recover, but an 'UpdateDrafts.py' that has a '--pushId' arg should be manually re-run, so don't delete those, ping me.
18:13:20 <plinss> the 'no specs' error generally happens because a repo import crashed and left the db in a weird state, the next import will generally fix it
18:14:28 <plinss> (the db code is using transactions so that shouldn't happen, but still does sometimes, not sure why, maybe when the db hiccups it doesn't roll back transactions properly)
18:54:53 <Guest60> Guest60 has joined #css
20:10:42 <Guest60> Guest60 has joined #css
21:55:25 <heycam|away> heycam|away has joined #css
22:03:16 <una> una has joined #css
23:13:55 <Karen> Karen has joined #css
23:40:00 <castastrophe> castastrophe has joined #css