W3C home > Mailing lists > Public > www-style@w3.org > July 2019

[CSSWG] Minutes Toronto F2F 2019-06-04 Part III: CSS Fonts [css-fonts-3]

From: Dael Jackson <daelcss@gmail.com>
Date: Sat, 6 Jul 2019 16:55:44 -0400
Message-ID: <CADhPm3uXV14o-eRSxT=wchF6FVWWh4-mogF089AYkL+odtxOGg@mail.gmail.com>
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

This archive was generated by hypermail 2.3.1 : Saturday, 6 July 2019 20:56:39 UTC