- From: Dael Jackson <daelcss@gmail.com>
- Date: Sat, 6 Jul 2019 16:55:44 -0400
- To: www-style@w3.org
=========================================
These are the official CSSWG minutes.
Unless you're correcting the minutes,
Please respond by starting a new thread
with an appropriate subject line.
=========================================
CSS Fonts
---------
- RESOLVED: Remove min-font-size and max-font-size from Fonts 4,
replace with an example of using clamp() to handle safe
responsive typography. (Issue #3739: font-min/max-size
and computed value)
- A note will be added to Fonts spec about the font-size: 0px vs min
font-size web-compat issue
- RESOLVED: Capture that font-size keywords carry an additional bit
of information having some (unspecified) interaction
with some font families. (Issue #3906: Clarify how
computed font-size is determined for size keyword)
- RESOLVED: François does compat research on the effect of font-size
keywords and generic font-families, and report back on
interop. (Issue #3906)
- Discussion on the request to add math-script-level and math-style
properties to CSS (Issue #3746) became a wider topic about the
best way to support math on the web.
- There is a request for more examples and more of a sense of
scope of the larger issue leading to these properties to
allow the group to ensure that they're building properties
in the right way.
- Without the full understanding it's unclear if some aspects
of this, e.g. the 'script level', need to be encoded as
information in the DOM rather than in CSS (so that they can
be selected against)
- CSS and the MathML group need to establish a standard approach
to communication going forward so that specs can stay
aligned.
- Before any final decisions the meta topic of the future of MathML
needs to be addressed. There are three possible futures that
need to be evaluated in order to decide the path forward:
1. MathML is in browser engines, CSS has to be compatible with
what it is.
2. MathML is in browser engines, but we might make substantial
changes as we develop and can adjust it to fit with CSS
better.
3. MathML isn't the right path forward, and math should be
taking a new path forward.
===== FULL MINUTES BELOW ======
Agenda: https://wiki.csswg.org/planning/toronto-2019
Scribe: TabAtkins
Scribe's Scribe: fantasai
CSS Fonts
=========
font-min/max-size and computed value
------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/3739
emilio: Browsers have minimum font-size settings for a11y
emilio: And they work differently in WK-based vs Firefox
emilio: WK-based browsers, it affects the font-relative units.
emilio: In Firefox they do not.
emilio: So I was considering implementing min-font-size, and that
affects the computed value of font-size, I would assume
emilio: So first, the a11y setting in Blink can break websites
emilio: I'd also like min-font-size to work the same as the a11y
setting.
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.
AmeliaBR: How much would things break if we declared a different
computed value for inheritance vs font-relative units?
dbaron: Which is what I thought Gecko did, and maybe what it did
pre-servo
fantasai: That would be fine and would honor the constraint we want
emilio: Would it?
[Amelia re-explains their proposal]
TabAtkins: So on any given element, 1.2em would still be 120% size
of the text
emilio: That would still break websites if we used this to implement
the a11y setting
dbaron: 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
dbaron: I think this is also significantly problematic because of
people misusing rem to get a custom-sized unit
jensimmons: And they want nice math, yeah
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?
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.
dbaron: Also one of the underlying principles of CSS is that it
explains how author and user expectations work with each
other. Settings/prefs are usually explained as part of the
user stylesheet.
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.
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.
fantasai: Still if authors do understand font-relative units and use
them correctly, things should still scale correctly.
jensimmons: So to clarify, there's a min/max-font-size, and maybe
you set font-size with a calc(vw) or whatever.
jensimmons: 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 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?
<chris> yes, exactly
[yes]
jensimmons: It doesn't even make sense to me that it wouldn't
transfer over.
<florian> +1 to jensimmons
[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 ; it's fixable using correct units smartly, but
breaking the connection between ems and font-size would make it
impossible to fix]
AmeliaBR: So while CSS gives people the tools to use things
properly, we have to recognize that some people won't use
it correctly.
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
<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.
fantasai: There was a comment from Fred Wang, 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.
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
fantasai: We would be doing authors a disservice if we did not
ensure that the font-size and 1em matched.
<chris> I agree with that proposed solution
<chris> ... otherwise things end up double-applied, growing too much
<chris> ... clamping should happen as late as possible
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.
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);`
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
chris: This has been interesting. Not sure I could reproduce this
after a few days. I want some examples in the spec of what
you should use each with.
<AmeliaBR> +1 to examples!
<fremy> (side note for people interested in this and would love
examples, Jason Pamental talk at cssconf this year is a
great resource)
TabAtkins: I think we're leaning 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.
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.
myles: Ours is also complicated, probably in a different way.
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.
emilio: It sounds like Ian is talking about the text auto-sizing
actually?
myles: Ah, but I wasn't in mine.
myles: We have a lot of systems that interact to produce a text size.
myles: I've spent a long time trying to increase readability, and...
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.
florian: So what are we using these for?
myles: These predate me, there was just a note in the spec and I
started implementing
TabAtkins: These predate the math functions; they were meant to
implement the "keep vw-based font sizes from getting too
big/small"
TabAtkins: So we can just drop the properties, then
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.
<tantek> agreed with TabAtkins
<tantek> proposal: drop the properties because not implemented
anywhere
astearns: So these aren't implemented in a user-facing way anywhere,
and we're not convinced they're good for any use-case...
jensimmons: responsive typography is what the use-case is
called, you can search for it
<fantasai> https://lists.w3.org/Archives/Public/www-style/2014Jun/0187.html
<AmeliaBR> `font-size: clamp(12px, 10vmin, 24px)` vs `font-size:
10vmin; min-font-size: 12px; max-font-size: 24px;`
astearns: So looks like we have consensus to remove these
properties, until we have a use-case that
min()/max()/clamp() don't serve.
AmeliaBR: And replace the section with an example of how to use
clamp().
RESOLVED: Remove min-font-size and max-font-size from Fonts 4,
replace with an example of using clamp() to handle safe
responsive typography.
heycam: The effect of these properties on the computed value of
font-size... still worth resolving on how these browser
settings affect things?
ChrisL: Example of broken is page with <html style="font-size:
1px">. Answer is, don't do that.
TabAtkins: The way it inherits separately is a problem for designing
a font hierarchy relative to a base size, tho
AmeliaBR: Should we give advice to browsers on whether font-relative
units should be affected by browser settings?
myles: Arguments on both sides
myles: If we don't expose to author, they don't know what happened
to their page
myles: I don't think it should be specced
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.
dbaron: To respond to myles there's another tradeoff around a11y
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.
TabAtkins: For this feature, no matter how you do it it'll be
page-exposed tho
font-size: 0px is special wrt minimums
--------------------------------------
dbaron: Also, the browser minimum isn't *really* a minimum.
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.
myles: Example is layout with inline-blocks, set font-size: 0px so
that the gap below the baseline is zero.
TabAtkins: Myles, wanna capture that 0px point in the spec? If
everyone agrees something is needed for webcompat, it
should be captured
myles: In a note, sure
ACTION myles Add a note about the font-size: 0px vs min font-size
web-compat issue
<trackbot> Created ACTION-879
Clarify how computed font-size is determined for size keyword
-------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/3906
myles: I don't think we can get rid of the fact that monospace is
special, for webcompat
chris: So this is really about the fact that Courier looks too big.
chris: And browsers also noticed that CJK fonts can look too big at
16px by default
emilio: In gecko we do this based on the generic family specified.
myles: So "a, b, serif" gets a different font size than "a, b,
monospace"
dbaron: Yes, because of the assumption that those fonts are probably
monospace as well
fremy: As I recall that's not what was implemented by browsers...
myles: In WK, we only adjust if you say *only* "monospace"
myles: So using font-family to dictate font-size is fundamentally
broken, we all agree
[we all agree]
myles: So the question is if we should write down exactly how it's
broken. It sounds like everyone does it differently
dbaron: Given there's incompatibility, there's maybe room to improve
this
[emilio describes some details of how this works]
dbaron: At one point I had part of a plan to replace with with
font-size-adjust
dbaron: Probably not web-compatible, but maybe... Would require new
values.
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.
TabAtkins: We should capture in the property that extra bit of
information captured about whether size was specified as
a size
TabAtkins: because browsers seem to do something special in that case
AmeliaBR: Keywords are a bit vague anyway
TabAtkins: No flexibility in that they convert to a <length>
TabAtkins: You honor a <length> as a <length>
TabAtkins: But that's not how browsers work
TabAtkins: We might need to keep it underdefined, but at least that
there's some thing special going on
fremy: We have interop, so let's spec that
TabAtkins: OK, but let's capture there's something
emilio: Gecko code... when you have multiple families, we behave
like WebKit
emilio: Yay interop!
AmeliaBR: So weird behavior, but cross-browser consistent
chris: So how are we resolving?
dbaron: The thing this was solving is really a use-case for
font-size-adjust
dbaron: Would like engine that doesn't implement font-size-adjust
that doesn't implement it to fix it
dbaron: It's ugly because it's designed to be compatible with its
non-existence
dbaron: It's a way of saying "i want to specify font-size in terms
of x-height instead of font-size"
<chris> https://developer.mozilla.org/en-US/docs/Web/CSS/font-size-adjust#Browser_compatibility
astearns: So it sounds like proposal is to acknowledge reality in
font-size property that it makes font-sizes strange.
astearns: And at minimum capture "it's strange" in the spec.
<dbaron> oh, actually, font-size-adjust may be behind the
experimental web platform features flag in Chrome...
TabAtkins: Let's capture that keywords come with extra bit of info
TabAtkins: And also investigate if there's compat, and if so spec
that
myles: sgtm
astearns: Is there someone volunteering to do the investigation?
fremy: I volunteer.
astearns: proposal: acknowledge reality that font-size keywords have
some weirdness with particular generic font families.
RESOLVED: Capture that font-size keywords carry an additional bit of
information having some (unspecified) interaction with
some font families.
astearns: Second is to deputize François to try and capture what the
weirdness is
RESOLVED: François does compat research on the effect of font-size
keywords and generic font-families, and report back on
interop.
math-script-level and math-style
--------------------------------
github: https://github.com/w3c/csswg-drafts/issues/3746
<AmeliaBR> Explainer link:
https://MathML-refresh.github.io/MathML-css-proposals/math-script-level-and-math-style-explainer.html
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
bkardell: So we want to get that funky added to CSS.
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.
bkardell: If we have that, this is one more thing that becomes a UA
stylesheet rule.
bkardell: math-script-level is in my mind a lot like counters. It
lets you scale up or down font-size
emilio: So when you nest an element that's a subscript or
superscript, or part of a fraction, the font-size shrinks.
emilio: But in CSS it affects the computed font-size, which is
annoying.
fantasai: This effects the font-size. Why is it called script-level,
and why is separate from font-size?
bkardell: This is how I think it's similar to counters, it carries
info about nesting.
AmeliaBR: So fantasai's question is why not do this with relative
font sizes. I think reason is to give browsers some more
flexibility...
fantasai: We can have math-larger and math-smaller...
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.
bkardell: Even within that context, you can have sub/superscripts
too.
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.
AmeliaBR: Do you need to be able to absolutely set "3 sizes down
from normal", or is it always single steps?
bkardell: These map straight from MathML attributes. I know the name
isn't great, but
<AmeliaBR> `font-size-math-adjust`???
<una> what about `font-size-math-adjust: <nesting-level>`
emilio: Figuring out which nodes need to increment or decrement the
script level is pretty tricky
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
AmeliaBR: Does nesting level have effects other than font-size?
myles: fremy said yes
fantasai: So then you'd want to *select* based on that level. So
then that info must be in the DOM.
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".
fantasai: Like directionality.
<fremy> (yep, for the record I agree with fantasai)
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.
dbaron: script-size-multiplier and script-min-size
fantasai: Does this mean we're adding font-min-size back?
myles: There have been a half-dozen or so of these proposals. How do
these affect existing elements outside of MathML?
<una> `font-size-math-adjust: <max-nesting-level> / <min-font-size>`
<tantek> how well supported/used is MathML in the platform
currently? Like who else besides Firefox supports it?
<TabAtkins> tantek, igalia is implementing it for Chrome right now
bkardell: Some people do indeed think that <math> isn't great, and
math layout should be a normal part of CSS.
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.
florian: So mathjax renders math into HTML or SVG, but they're
missing some tools, so makes it subpar.
myles: So what's the criteria here: should math layout be dumped in
whole-hog?
<chris> https://www.w3.org/TR/MathML3/chapter3.html#presm.mstyle.attrs
<chris> also https://www.w3.org/TR/MathML3/chapter3.html#presm.scriptlevel
bkardell: We're trying to find the MathML core and eliminate as much
as possible.
bkardell: So far we've been doing good at that.
bkardell: Reusing CSS stuff well.
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.
TabAtkins: Is the goal that you can implement math layout with
<div>s, or are we saying that MathML is a special layout
form, like SVG, that can have its own specialized CSS
without influencing arbitrary text layout?
dbaron: There are two different groups in w3c working on different
solutions here
myles: So if this is a generic layout mechanism, you need to be able
to put flexbox inside of it
florian: I don't think we want to be able to take naive markup and
get good math out of it.
TabAtkins: Are we intending that you can make a fraction, and the
numerator is a flexbox?
TabAtkins: If so, you can nest flexbox into it. If not, then you
can't.
TabAtkins: But need to know which way we're going so we can figure
out how to interact with it
chrisl: ...
TabAtkins: We'd make a Math Layout spec
iank: So basically MathML is already in this state where you can
nest CSS layout inside of it
iank: And it uses CSS layouts to achieve some of its layouts
iank: so <mtable> uses css tables
iank: The text inside of MathML is just text layout, it can do
floats, etc.
iank: This was the feedback we gave to the group: you need to define
how this interacts with all of CSS.
myles: Are you saying that philosophically that's how this should be
designed, or that it's just a quirk of impl?
Rossen: So support rich layout that allows math, and interacts
nicely with the rest of css.
astearns: A detail is that some requirements, we may not get to.
Like western typography, some details we never get to.
myles: So the intention is that we end up with display:math at some
point?
AmeliaBR: display:fraction, perhaps, like display:ruby : some
specialized focused layouts as necessary
<dauwhe> this is a w3c strategy funnel issue
https://github.com/w3c/strategy/issues/43
<dauwhe> https://www.w3.org/community/knowledge-domain/
fremy: So math-level.
fremy: If you want a layout that's different depending on the math
level, that's fine. We could do that.
fremy: But the way I see this is that math-level is changing other
properties, in some weird interaction.
fremy: So my mental model matches fantasai, this is at the DOM level.
fremy: And if we go the "you should do math using divs", that
doesn't work.
fremy: My impression from when I worked on this, is that this is
complex to put in a CSS property.
fremy: But if our goal is to allow everything in CSS, I don't see
how it's a markup thing.
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.
* leaverou wonders if that means we should add a pseudo-class to
select it instead (re: it's at the DOM level)
<TabAtkins> leaverou, yeah, that was a question earlier
myles: So let's say we do wanna go on this path where we induct math
layout into CSS.
myles: When we write CSS specs we have to describe layout exactly.
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?
bkardell: Right now they're trying to get that defined.
bkardell: Huge criticism right now is that it's super underdefined.
<tantek> FYI: https://caniuse.com/MathML
iank: As part of our launch process we require interop-capable
specification.
iank: And the two impls currently aren't remotely interoperable,
especially layout.
iank: I spent two or three hours one day and created a list of
issues where Firefox and WebKit differ.
fantasai: If MathML is going to define a layout model closer to css,
they should definitely interact with us more than what's
happening currently.
fantasai: So we can make sure it's compatible with css layout and
all the interactions with other properties.
fantasai: Just because of where the expertise lies.
<tantek> Is there an opportunity for CSS/MathML joint meeting at
TPAC?
astearns: I would really like to see more stuff in the explainer.
Right now it looks like a reiteration of the proposal. It
has some markup examples without intended renderings, etc.
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.
fantasai: So somebody came up with a solution to a problem, but I
don't understand the problem, or why this is the best
solution to that problem.
fantasai: Would love to advise them, but can't right now.
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.
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.
myles: Agree. We already have SVG then.
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.
AmeliaBR: So wrapping up, we have some requests for 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.
AmeliaBR: Would be useful if this group gave feedback about how we'd
like to be communicated with.
AmeliaBR: And then there's further concern about where things should
live, CSS vs DOM, etc.
dbaron: fantasai was asking about the problem to be solved. There is
a political disagreement about the problem.
dbaron: In that, there is the question of whether MathML is the way
forward.
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.
dbaron: And add to CSS to improve mathjax output.
dbaron: Now we're somewhat surprisingly getting to a world where
MathML is supported across browser engines.
dbaron: So question is whether MathML is, like html, something that
needs CSS to reflect the things in it.
dbaron: Are we concerned with MathML backcompat such that CSS needs
to care about its legacy mechanisms.
dbaron: Or do we have substantial flexibility to change things as
necessary.
dbaron: So three possibilities:
dbaron: 1. MathML is in browser engines, CSS has to be compatible
with that.
dbaron: 2. MathML is in browser engines, but we might make
substantial changes in the process and can adjust it to CSS
better.
dbaron: 3. MathML isn't the right path forward, and math should be
taking this up the path.
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.
dbaron: Possible we should be discussing this more explicitly.
dbaron: I think before we decide what we're trying to solve, we
might want to have that discussion.
bkardell: Before I went to Igalia, I spent a lot of time thinking
about this.
bkardell: My own thoughts were between 2 and 3.
bkardell: HTML isn't very perfect semantically either, it's focused
on text.
bkardell: So it has no starting point. It's not like SVG, where we
all agree what SVG is.
bkardell: Thirty years the community has been working on something,
lots of back and forth.
bkardell: When we got to HTML5 and MathML was codified into the
parser, now it's in a special weird place.
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.
bkardell: So back with corporate hat on, the core-math group is
trying to find the minimal bits that hold things together.
bkardell: I don't want to personally be like "MathML is the best
thing ever", I dunno. I want to be malleable here.
<TabAtkins> myles: Minutes of the Math session during last year's
tpac:
https://lists.w3.org/Archives/Public/www-style/2018Nov/0008.html
<br dur=20min>
Received on Saturday, 6 July 2019 20:56:38 UTC