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

[CSSWG] Minutes Toronto F2F 2019-06-05 Part II: CSS Text, CSS Inline [css-text-4] [css-inline]

From: Dael Jackson <daelcss@gmail.com>
Date: Sat, 6 Jul 2019 18:51:10 -0400
Message-ID: <CADhPm3u9qL8D9QwZmhSZR6_umGk3_wXyj=n17=rP2RMnmWkusA@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 Text (Continued)
--------------------

  - Issue #3745 (Add new CSS text-transform values for math) will be
      deferred to TPAC when a11y experts can be a part of the
      conversation as well as spend time to see if it's possible to
      decouple the style and the markup a11y

CSS Inline
----------

  - Discussion of issue #3749 (resolved value of line-height) didn't
      lead to a resolution but several people had actions to move the
      topic forward:
      - florian will take some of the edits removed from CSS2.1 during
          the clean up of that spec and will add them to the Inline L3
          spec.
      - emilio will experiment with having Gecko return normal and see
          if it causes web compat issues.

===== FULL MINUTES BELOW =======

Agenda: https://wiki.csswg.org/planning/toronto-2019

Scribe: emilio

CSS Text
========

Add new CSS text-transform values for math
------------------------------------------
  Github: https://github.com/w3c/csswg-drafts/issues/3745

  fantasai: I really think this should be done with i18n experts
  fantasai: probably at tpac
  Rossen: Who added it to the agenda?
  bkardell: I did
  Rossen: Are we ready to discuss this?

  bkardell: There were very strong objections when I added it to the
            agenda but it seems that has been solved
  bkardell: I'd like to make some progress on that issue
  astearns: What's the points you're talking about?
  bkardell: The philosophy of text-transforms and how it interacts
            with a11y
  * fantasai agrees with Asmus in
https://github.com/w3c/csswg-drafts/issues/3745#issuecomment-478206009
  bkardell: We have a new transform that probably needs to do
            something different
  bkardell: there are at least two answers to the questions
  florian: I think that's why we need other experts on the discussions
  florian: because whether text-transform affects the semantics is
           complicated
  fantasai: I think text-transform, if we're stuck for compat with
            a11y for capitalization that's unfortunate, but we
            shouldn't introduce the same for math
  <fantasai> https://github.com/w3c/csswg-drafts/issues/3745#issuecomment-478206009

  florian: Once we have the markup communicate the semantics, we
           probably want text-transform to affect some of the
           presentation but not a11y
  bkardell: My understanding is that we'd encourage putting it in the
            markup, but there's a bunch of legacy content which is
            what would make this necessary
  AmeliaBR: I think florian's point is that you could have a
            presentation transform but the accessibility stuff should
            be in the markup
  bkardell: I'd like to get some kind of checkpoint on this

  AmeliaBR: The question is: for math-variant to be exposed and
            accessible, does it need to be exposed through
            text-transform transforming the text-content, or via an
            attribute that gets passed to the a11y tree, which _also_
            gets a UA rule to make the presentation change
  fantasai: I think that's the right way to go, and gives you the
            ability to give more accurate info to a11y than doing
            unicode transformation
  fantasai: Unicode transformation doesn't contain math semantics
  fantasai: that needs to be in the markup, if that information is in
            the content it should be given to a11y directly, rather
            than via text-transform
  fantasai: A11y doesn't say "Bold", it uses the fact that you're on
            <strong>
  AmeliaBR: Actually that's not true, ARIA WG is trying to introduce
            roles for <strong> and similar, authors don't distinguish
            <i> or <em>
  AmeliaBR: if there's an italic <span> in a header it'd be called out
            depending on the verbosity level
  Rossen: It calls out format stops

  bkardell: There's a similarity here with html's kinda-weak
            semantics, a11y tools get mostly plain text with other
            hints, for math a11y my understanding is that some tools
            use the unicode information
  Rossen: We don't support mathml in Edge
  bkardell: Well, Edge does parse mathml as XML content
  bkardell: which is why mathml is a kinda weird place
  Rossen: [describes how a11y works in Edge and how screen readers can
          poke at the DOM / render tree in non-Edge (Chromium /
          Firefox)]
  Rossen: Edge doesn't allow third-party processes in its process
  bkardell: Please fact-check me :)

  florian: I think this is a topic for TPAC, since different a11y
           experts have diverging opinions
  Rossen: Are we going to make any progress?
  bkardell: Do we have some specific questions?

  AmeliaBR: I think my point was previously said, so to wrap up: We're
            saying that the specific proposal is to take it back to
            see if we can decouple the style and the markup a11y, and
            defer for TPAC?
  bkardell: yeah

  iank: Seems like the people objecting about text-transform is just
        about a11y, is that correct?
  AmeliaBR: Yeah, it's about whether it sees the characters for a11y
            before or after transform
  florian: It's not just about a11y but more generally the semantics,
           like what would happen in reader mode and such?
  iank: Another point is that mathml has a lot of legacy content, and
        mathml does this in a very magic way. We don't want to get in
        a situation where other math libraries cannot opt-in to this
        power
  Rossen: Let's stop here for now

CSS Inline
==========
  Scribe: heycam

resolved value of line-height
-----------------------------
  github: https://github.com/w3c/csswg-drafts/issues/3749

  AmeliaBR: What's the question to be resolved?
  florian: This is about the resolved value of `line-height: normal`
  koji: Right now Blink behaves differently from Gecko / WebKit
  koji: One of our contributors is willing to try to change Blink
  koji: seems smoother for Blink to change, want to confirm that
        with WG
  emilio: Gecko and WebKit already have this behavior since CSS 2
  emilio: CSS2 defines the used value of line-height as something
          based on the primary font of the element
  emilio: I did try to switch Gecko to return normal, and it's
          probably not impossible, but it's a bunch of work
  emilio: Also mats disagreed with it
  florian: What CSS 2 has to say is fuzzy
  florian: different editions
  florian: All browsers are interoperable about what
           line-height:normal does, to an approximation
  florian: that is different from what CSS 2.1 says
  florian: 2.1 claims normal is equivalent to a number
  florian: That's not what everyone does
  florian: therefore it would make sense that for resolved value, you
           return the word "normal"
  emilio: There is
  florian: There isn't
  florian: There is only if the element is empty

  dbaron: Part of the problem is we had a long discussion at Tokyo F2F
          about line height
  dbaron: and there's nothing written down that reflects the results
          of that
  dbaron: in a readable format
  dbaron: Some edits made to CSS 2 and reverted
  dbaron: There's no usable reference for the results of that
          discussion, therefore some people involved here including
          emilio and mats, who don't know what's discussed there
  florian: I'm frustrated about these edits being reverted
  florian: I'll take those edits and put them into css-inline

  florian: Skipping over the details, the behavior of
           line-height:normal is not equivalent to a number
  emilio: You compute a number at the start of the element (and the
          element itself), but once you get that number, which is what
          Gecko and WK return from gCS, it's the same as if you use
          that px value ...
  dbaron: It's not
  dbaron: there are 2 ways it's different at least
  koji: I think dbaron and florian are talking about how
        line-height:normal is laid out
  koji: emilio is talking about how line-height is computed
  koji: and that is interop between Gecko and WK
  dbaron: What florian and I are saying is that there does not exist a
          number or a px value that is equivalent to normal
  dbaron: because depending on the text you have in the element, and
          what font fallbcak occurs, you'll get different results
  koji: That's for layout.
  florian: The computed value is normal as a keyword
  dbaron: I don't think the point you're making is relevant here, I
          think florian's argument is that we're looking at situations
          where the computed value is normal, from a style perspective
  dbaron: and we're asking what resolved value to report there
  dbaron: florian's point is that in most cases when we have a
          resolved value, putting that resolved value back in the
          computed value is basically equivalent
  dbaron: So there are cases where the computed value is a % and
          resolved value is px
  dbaron: but if you take the resolved value and put it back in
          computed value, you would get the same result (at least for
          that element, not necessarily for inheritance etc.)
  dbaron: florian's point is that in this case, there is not a single
          number that leads to that result, because what normal does
          around say font fallback, looking at metrics of possibly one
          possibly multiple fonts, is different from what any
          particular number does
  dbaron: That's the stuff that is not well documented because the CSS
          2.1 edits were reverted
  florian: The right value to return from gCS would be normal
  florian: but if there's broad interop everywhere but Chrome, to
           return what that number would be if the element is empty,
           then that's unfortunate but not unfortunate enough to
           object to that

  <tantek> reverting the 2.1 edits (there were a bunch more) was the
           right thing to do because not all of it was based in minuted
           discussions nor even test cases, and that kind of editing
           for a stable document like 2.1 is irresponsible

  emilio: I was going through the Gecko code, we have various bits of
          if line-height is normal, update the line
  dbaron: There are a bunch of things in Gecko code based on
          line-height normal, a bunch are wrong
  dbaron: Some were discussed at that previous meeting,
  dbaron: a bunch of the conditions in the gecko code are in the wrong
          place
  dbaron: There's a bunch of design decisions important for
          interactions with other features, due to the lack of
          interop, we probably still have the freedom to make
  emilio: After seeing our usage of line-height:normal in our layout
          engine, I agree that given normal is more special, the right
          thing to do would be to return normal
  emilio: I can try again to change Gecko, and if I can't I can report
          back
  <tantek> from my recollection, line-height normal was a way used (by
           implementation) to capture the legacy Netscape behavior of
           inline line layout, as opposed to what HÃ¥kon & Bert wanted
           line-height to do

  florian: Getting interop would be nice
  florian: If the only way for that is to return a number, that's OK,
           otherwise let's try normal
  myles: Philosophically returning normal would be great
  myles: might break the web
  florian: Chrome has been returning normal for a long time, so maybe
           wouldn't?
  florian: Maybe there is UA sniffing that would make it break
  emilio: Given this conversation I can try to convince Mats
  florian: I will try to take the CSS 2.1 fixes and put them in Level 3
  emilio: Notes in the spec about how that not only affects resolved
          value, but other stuff, would be great

  koji: dbaron's explanation I finally understand why we want normal,
        it makes sense
  koji: but I also want interop. Is WK willing to change?
  myles: I don't think I would change this before Gecko does
  myles: If Gecko succeeds we'd probably be willing to do it
  dbaron: My memory of the discussions we had in Tokyo, I'm not 100%
          sure we all agreed that we want to stick to a behavior that
          normal cannot be mapped to a number
  dbaron: That number might depend on something in the first available
          font, it almost certainly would, but I'm not sure we agreed
          that we do not want the behavior that you couldn't convert
          normal to an equivalent number based on available font
          metrics
  dbaron: That is using font metrics but not particular character
          availability

  florian: How about we reopen that issue as necessary, based on the
           Tokyo text, which describes ~reality
  florian: and do that based on the text
  myles: Are you suggesting you want to change the behavior to make
         normal not magic? or numbers be more magic?
  dbaron: Change normal so that its magic is a bit different
  dbaron: e.g. how font fallback interacts with line rhythm
  dbaron: One piece there is that maybe it is better if the box that
          normal gives you is only a function of the first available
          font, and not the fallback fonts
  dbaron: Then when you have multiple lines/elements, some of which
          trigger fallback, you don't get unstable line rhythm
  dbaron: I'm not sure we sorted that out fully
  myles: I have opinions on this but maybe that's a different topic
  dbaron: The reason I'm bringing it up, is it relates to the
          conclusion that there does not exist an equivalent number
  dbaron: but that's a full day long discussion
  florian: I agree there's room for discussion
  florian: I propose we first get back the text, and go from there
  dbaron: Sure
Received on Saturday, 6 July 2019 22:52:01 UTC

This archive was generated by hypermail 2.3.1 : Saturday, 6 July 2019 22:52:01 UTC