- From: Dael Jackson <daelcss@gmail.com>
- Date: Sat, 6 Jul 2019 18:51:10 -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 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