W3C home > Mailing lists > Public > www-style@w3.org > February 2020

[CSSWG] Minutes A Coruña F2F 2020-01-24 Part III: Color Adjust, CSS Values, CSS Text [css-color-adjust] [css-values] [css-text]

From: Dael Jackson <daelcss@gmail.com>
Date: Wed, 19 Feb 2020 19:52:25 -0500
Message-ID: <CADhPm3vy7yG9zQTWupLWoGJpd=o3r2GWcwJukUgGEeC5CLW=1Q@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.
=========================================


Color Adjust
------------

  - RESOLVED: Use "canvastext" as the initial value of color (Issue
              #4608: Used color-scheme should affect the root element
              color, not initial color)

CSS Values
----------

  - RESOLVED: The mod() and rem() functions are to be added to CSS,
              mod() with math behavior, rem() with JS behavior
              (Issue #2513: mod() mode)

CSS Text
--------

  - There wasn't a clear good way to handle issue #4405 (Treat
      all-neutral lines same as empty ones for plaintext alignment);
      every possible solution had a downside. Since the feedback is
      from 2016 fantasai will reach out to see if it's still valid and
      if there's more information to help in a decision.
  - RESOLVED: Hanging spaces are ink overflow by default. UAs may make
              them scrollable overflow when they think that would be
              useful. (Issue #4297: Hanging spaces can't be scrollable
              overflow)
  - RESOLVED: Punt "removing collapsible linebreaks adjacent to word
              separators" to level 4 (Issue #3481: Remove collapsible
              line breaks adjacent to word separators)
  - fantasai will look into declaring behavior based on Unicode block
      to address Issue #337 (Segment Break Transformation Rules for
      East Asian Width property of A)
  - RESOLVED: "vertical-align: middle" always uses halfway between
              alphabetic baseline and x-height, except in modes where
              the x-height is meaningless (vertical writing modes with
              upright text orientation) (Issue #4495: Should
              vertical-align:middle behave differently when the
              dominant baseline is not alphabetic?)
  - RESOLVED: In such "meaningless" cases, "middle" means the same as
              "central". (Issue #4495)

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

Agenda: https://wiki.csswg.org/planning/galicia-2020

Scribe: fremy

Color Adjust
============

Used color-scheme should affect the root element color, not initial
    color
-------------------------------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/4608

  TabAtkins: The spec says that color-scheme on the root element
             affects the initial value of the color property
  TabAtkins: in addition to a couple of other things
  TabAtkins: The argument is that we should instead change the color
             of the root in the UA, but not the initial color value
  TabAtkins: I am not sure why this was proposed, but I see more value
             in our current spec
  TabAtkins: because I don't see a value to get black as color when
             you're in the dark theme
  TabAtkins: If we changed the initial value, a weird thing I do
             currently in Bikeshed would work better though
  TabAtkins: A detail of this, is that the actual used color in chrome
             and safari is that it's actually a color that switches
             its value at computed value time
  TabAtkins: In safari it's system-color and in blink a custom UA value
  TabAtkins: and I think that this is a useful behavior
  TabAtkins: so I tried to find an alternative behavior
  TabAtkins: We say the initial value of color is "text", and
             "initial" would work as usual
  TabAtkins: I think it's ok because all uses of "color" is in
             property that require to return the used value at
             getComputedStyle so I'm unsure this would be observable
  <tantek> except for scrollbar-color, which has keywords that are
           returned
  TabAtkins: but it would be visible in TypedOM
  TabAtkins: Can we get an agreement to match what Safari does in this
             case?

  fantasai: A question I have is that this could cause issues in SVG,
            right?
  TabAtkins: By default, it is, yeah
  TabAtkins: but I'm not sure what the expectation what would be
  heycam: It's more common to use black as the default value
  TabAtkins: And it's mostly relevant for text, for which you usually
             you would want to switch
  emilio: You use currentColor in SVG to get that effect
  emilio: not the default
  TabAtkins: The initial value is black, and also fill is black
  TabAtkins: so that change wouldn't affect anything by default in SVG
  Rossen: If it did break SVG, we would notice and backtrack

  heycam: If you don't reset the property value, and inherit
  heycam: does the value switch for the children that inherited that
          complex value?
  fantasai: Keywords inherit as a keyword, it's gonna be ok
  heycam: Really?
  fantasai: Yes, the keyword is inherited and behave per the element
  fantasai: but getComputedStyle returns a resolved value which is a
            color
  <emilio> Rossen, so if you animate between `CanvasText` and
           `Canvas`, for example... How is that supposed to work? Does
           it become a discrete animation?

  hober: If the change is compatible with what we already do, and we
         allow the UA stylesheet to use that paradigm for the color
  TabAtkins: I haven't verified that myself
  (safari team is checking)
  <hober> WebKit's UA stylesheet sets html { color: text; } if the
          color scheme feature flag is on

  emilio: I would like to question the interpolation between keyword
          values
  Rossen: You interpolate between the values
  emilio: But we can't write that value anywhere
  TabAtkins: I guess right now we cheat
  TabAtkins: We resolve the keyword, then interpolate, even though we
             inherit the keyword
  TabAtkins: just like currentColor since we switched the value
  emilio: We maintain an extra channel for currentColor to make it work
  emilio: but we don't want to add a channel for each system color
  TabAtkins: We are going to add interpolate() eventually to fix this

  hober: The UA stylesheet when the color scheme is built-in sets the
         color property to the value Text on the root element
  TabAtkins: So what I am proposing is virtually the same as what
             you're currently doing
  hober: Right
  heycam: in color-4 we say what to do with the undeprecated values
  <fantasai> https://www.w3.org/TR/css-color-4/#css-system-colors
  <fantasai> System colors that are not deprecated ^
  Rossen: Before I formally say yes, let me check
  fantasai: It's definitely there
  Rossen: ok then
  heycam: Also for background colors?
  fantasai: Yes
  Rossen: So we want to resolve on this proposal?
  astearns: No objection?

  RESOLVED: Use "canvastext" as the initial value of color

CSS Values
==========

mod() mode
----------
  github: https://github.com/w3c/csswg-drafts/issues/2513

  <TabAtkins> https://en.wikipedia.org/wiki/Modulo_operation#In_programming_languages
  TabAtkins: I was thinking about this, and looking at the wikipedia
             article...
  TabAtkins: there is a lot of divergence
  TabAtkins: but there is one constant
  TabAtkins: if a language has a pair, mod() works like Math and rem()
             works like JS
  TabAtkins: In particular, Web Assembly language does this, because
             they came to the same conclusion
  TabAtkins: so my proposal, is to add the two functions

  leaverou: Why are these functions and not operators?
  TabAtkins: More complex
  TabAtkins: and also it's not an operator in all languages anyway
  <fantasai> I support Tab's proposal fwiw
  <florian> +1 to tab's proposal

  myles: Why don't we want mod to be like js?
  TabAtkins: Javascript doesn't have a function, just a % operator that
             works like rem
  myles: But then we make CSS more powerful than JS, while JS was
         intended to be math-complete while CSS is not
  hober: I think the point of this exercise was to reduce differences
         in differences between the platform languages
  hober: I'm confused why we want to introduce inconsistencies
  hober: It might be reasonable to ask somebody from TC39 to consider
         adding the other function, and mimic their response
  TabAtkins: I don't believe it's correct to say that we want to
             minimize the difference between the two languages
  TabAtkins: Our goal is to give designers the functions they need to
             get the layouts they want
  TabAtkins: which is why we didn't add the hyperbolic functions
             because there are no known use case
  TabAtkins: and to reply to the "more powerful question", we already
             do that
  TabAtkins: For instance, we have a more complex round function, and
             that is useful because rounding is important to us
  TabAtkins: So I don't want to say we should not innovate beyond JS
  TabAtkins: but we should only do it if there's an use case
  heycam: If we really wanted to match JS, we would do an operator,
          not a mod() function in the first place

  heycam: I was on the queue to say something else
  heycam: It's confusing to have an unit called rem, and a function
          called rem
  heycam: I would like to avoid it
  myles: An author might think it gives you the size of a rem
  TabAtkins: It would not work, and authors would realize that

  fantasai: JS doesn't have a mod() function, it has a % operator, so
            either way we have to pick a name, picking rem() as that
            name is perfectly fine
  fantasai: Also, I want to point out that log() doesn't do
            console.log()
  fantasai: Also, I agree, modulus is an % operator in JS, not a mod()
            function
  fantasai: so, if we add a mod() function we don't have to match JS,
            we can do something useful
  myles: log() is a very different example, because we just cannot
         console.log like JS
  myles: but here we are doing the same thing
  TabAtkins: We have functions that can absorb css timing resolutions
             from Houdini
  TabAtkins: The paint api when it gets called gives you timing
             information

  astearns: I don't think this is gonna get narrowed down today
  TabAtkins: But, we want to check if we can ship this
  TabAtkins: so can we strawpoll or record objections?
  <debate on the options between people>
  RossenF2F: The new option is that we have both mod() and rem()
  florian: I think we should just have a decision yes or no on the
           adoption of this approval
  astearns: Yeah, let's do this
  hober: I am worried about the form of this strawpoll
  hober: because we are not agreeing on an alternative
  astearns: Yes, but if we say no, we don't do anything and defer for
            another day

  <TabAtkins> 1. Resolve to add mod() (math behavior) and rem() (JS
              behavior)
  <TabAtkins> 2. Continue thinking about the desired mod-ish behavior
              in the issue, resolve sometime later.
  <fantasai> 1
  <florian> 1
  <TabAtkins> 1
  <faceless> 1
  <leaverou> 1
  <hober> 2
  <dbaron> 1
  <RossenF2F> 1
  <fremy> 1
  <tantek> 1 because YOLO
  <stantonm> 1
  <rachelandrew> 1
  <astearns> abstain
  <jfkthame> 1
  <heycam> 1
  <fremy> 15/22 said 1
  <RossenF2F> mod(15/22)

  astearns: Proposed resolution is thus to add both mod() and rem()
  astearns: Does anybody object?
  <TabAtkins> It's 13 for option 1, 1 for option 2
  <leaverou> Chris can't vote due to lack of connectivity, but he
             votes 1

  RESOLVED: The mod() and rem() functions are to be added to CSS, one
            with math behavior, the other with JS behavior

CSS Text
========
  Scribe: TabAtkins

Treat all-neutral lines same as empty ones for plaintext alignment
------------------------------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/4405

  fantasai: Issue raised by Aharon
  fantasai: When you have a plaintext block, like a <pre> with
            unicode-bidi:plaintext
  fantasai: It resolves the paragraph base direction of each
            "paragraph" (things separated by forced line breaks)
            according to the first strong character in the paragraph.
  fantasai: This is a heuristic, not always accurate, but it's what
            the plaintext bidi algorithm does.
  fantasai: Interesting to Aharon is alignment
  fantasai: We take advantage of a para-based direction, that's not
            'direction' proper, but we use that direction per-line to
            decide what "start" text-alignment means.
  fantasai: Problem arises if you have a paragraph that's completely
            neutral chars, like punctuation.
  fantasai: Or numbers.
  fantasai: What he noticed is that you have a document that's
            entirely Arabic, but it has a line of text with no letters
            in it, it ends up being aligned to the left (wrong side
            for Arabic)
  fantasai: We already make an exception for empty line boxes; we take
            the direction from preceding line. Suggestion is to apply
            that exception to all-neutral lines too.

  florian: Currently it's undefined?
  fantasai: Currently the default is ltr if you can't find a direction.
  jfkthame: I think the terminology is a little wrong; numbers are
            weak, not neutral.
  fantasai: Sure. I don't recall the exact spec wording, it's probably
            more accurate.
  faceless: So if you have Arabic text and underlined it with a line
            of hyphens, for example
  fantasai: Yeah, that's a case here

  koji: So I guess options are previous paragraph, or 'direction'
        property. Any reason you chose previous paragraph?
  fantasai: That was the suggestion from Aharon.
  fantasai: We're specifically in a unicode-bidi:plaintext context,
            which implies the 'direction' doesn't know what it should
            be.
  koji: But then 'direction' should specify the ui or document
        direction, so it's a more natural fallback to me.
  florian: Not necessarily - if writing content like an email, the UI
           might be in English but the context is Arabic. Using
           'unicode-bidi:plaintext' on the email textarea because you
           know the lang direction is unknown.
  koji: Agree, this is heuristic, we could argue both cases.
  koji: I just think author intention is more natural fallback.
  myles: Not sure I agree with that.
  myles: If there's a quote snippet, you might want to remove some
         middle paragraphs, replacing with [...] to indicate it's been
         snipped
  myles: If you do that as currently described, it'll be on the other
         side of the screen and look wrong.
  koji: If you have English quote in Arabic text, and there's
        underline, you want it on Arabic direction
  koji: If you have hyphens *above*, it'll be Arabic-aligned; if you
        have hyphens *below*, it'll be English-aligned.
  koji: So it's a question of which is better heuristic.
  fantasai: I think you're both making good points.
  fantasai: It's not clear which is clearly better.
  fantasai: I think what is clear is that we shouldn't use ltr as the
            generic default.

  koji: Have you tested what browsers do today?
  <fantasai> testcase -
http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cpre%20dir%3Dauto%20style%3D%22direction%3A%20rtl%22%3E%0A%5E__%24%0A%D9%84%D8%B9%D8%B1%D8%A8%D9%8A%D8%A9%0A%5E__%24%0Aabcde%0A%5E__%24%0A%3C%2Fpre%3E%0A

  faceless: My understanding of "plaintext" is that you really can't
            rely on the direction property.
  TabAtkins: My intuition says that most of the time you'll be looking
             at single-language text, so the neutral paragraph should
             align with that, and the heuristic will work. When you
             have mixed text, Koji's argument that it's unclear and
             might be wrong is valid, but the "previous paragraph"
             heuristic should be right about half the time. So that's
             not bad!

  fantasai: Testcase shows that each paragraph is handled
            individually; if it's all neutral, it's treated as ltr
            even if "direction:rtl" (this is exactly what the spec
            currently specifies).
  fantasai: Interesting case - neutral text like ASCII art in a
            "plaintext" context, and there's some rtl preceding it,
            you don't want it swapped direction.
  myles: ASCII art is pretty niche. I don't think it should affect
         this decision.
  fantasai: So I think if the *entire paragraph* is neutral, we
            shouldn't look at previous paragraph; we should just use
            the "previous line".
  koji: What do you do at the beginning of the block?
  fantasai: Probably just default to what unicode says, which is ltr

  myles: I'm sure we're not the first to have this idea. Do we know
         why Unicode gives this advice?
  fantasai: Unicode doesn't define alignment.
  fantasai: They do require that the *base direction* is ltr
            (affecting bidi reordering); we don't want to touch that.
            This is just about alignment.
  koji: Unicode bidi l1 requires applying reordering to trailing
        spaces; without bidi l1 and l0 affects reordering.
  <TabAtkins> I think I got that wrong, koji, I don't understand the
              concepts you're talking about ^_^
  fantasai: We can tweak the alignment; I don't think we should be
            making tweaks to the ordering of characters.
  koji: I'd rather fix paragraph level rather than fix text-align
  fantasai: So that would be to close this issue no-change?
  fantasai: The issue is just about text-alignment; saying it's wrong
            for these cases.
  fantasai: You're saying let's not do that. That's an okay proposal!
  koji: No, just say that text-align uses base direction, and CSS can
        just say that if there's no strong characters we inherit from
        the previous line.
  fantasai: bidi reordering relies on base direction, that'll change
            the ordering of characters.
  fantasai: Like base direction determines where your period goes at
            the end of your sentence.
  jfkthame: Not sure I'm totally comfortable with changing base
            direction for reordering purposes and for alignment.
  fantasai: I'm just relaying from the issue
  fantasai: We can decide to reject the proposal.

  florian: Originally I was enthusiastic, and maybe given it's from
           Aharon my concerns are unfounded; in Unicode there of
           course is no alignment, it comes from *somewhere*.
           Currently in plaintext applications everything is
           effectively start-aligned.
  florian: So aren't those apps already effectively doing the same for
           alignment and base direction?
  koji: The feedback is from 2016, mind checking with Aharon again?
  koji: He's been responsive to me more recently.
  fantasai: Ok, I'll summarize and take it back to him
  fantasai: I'm opening some plaintext editors, and it looks like
            alignment is based on the whole file.
  fantasai: Even having differing-direction entire paragraphs doesn't
            affect it.

Hanging spaces can't be scrollable overflow
-------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/4297

  florian: We've discussed this before - should hanging spaces be
           scrollable or ink overflow?
  florian: Conclusion last time was use-cases for both. Generally
           they're invisible and unnoticeable, invisible things
           triggering overflow is bad, so generally it should be ink
           overflow.
  florian: But when text-editing, it's bad to move your caret into
           spaces and not see where you are, because there's no
           scrollbar and the caret is off the viewport.
  florian: So I think when not-editing always ink, when editing always
           scrollable.
  florian: Some people objected that when not editing, selection still
           has value for scrollable overflow so you can see the bounds
           of your selection.
  florian: So one possibility is to make that simple distinction.
           Another is to make a switch for it.
  florian: I think we had general consensus that the switch is useful,
           but some, maybe emilio, were uncomfortable with this.
  emilio: I still think it's weird, but...
  florian: I think my preference is an automatic behavior that
           switches based on edit-ability.
  florian: If we later think there are more situations, we can always
           add a property *then* that defaults to "auto". I suspect we
           won't need it, but we're not locked out.

  fantasai: I think we should define it as ink overflow, but UA *may*
            treat it as scrollable when the content is editable or UA
            thinks user would otherwise like to see it.
  fantasai: So on static pages it'll never make scrollbars.
  fantasai: But there's an allowance to improve usability on
            interactive.

  koji: Do you remember what we did for hanging punctuation?
  florian: Don't remember, but I think this should apply to both.
  stantonm: I think we defined hanging punctuation as ink overflow,
            but I could be wrong.
  jfkthame: It says "scrollable" at the top of the issue...
  <fantasai> "A hanging glyph is still enclosed inside its parent
             inline box, is still counted as part of the scrollable
             overflow region [CSS-OVERFLOW-3], and still participates
             in text justification"
  florian: Turns out the spec currently says hanging-punctuation is
           always scrollable, and there's a Chrome bug showing this is
           bad (too much scrollbars).

  astearns: We might want to say it's ink overflow all the time, and
            respond to editing as we get bugs.
  florian: For hanging punctuation, you don't have more than one
           punctuation sitting there, it doesn't overflow much anyway.
           But spaces, you can have a bunch.

  heycam: When you're editing text, and whitespace is collapsed, you
          also don't get the cursor through those.
  heycam: So why is it important to cursor through these?
  florian: You can still see your caret in that case, it's not
           offscreen and invisible.
  heycam: Why not just move the caret to the next line when it would
          overflow?
  astearns: It breaks selection, you want to be able to select those.
  heycam: You can select them, just not in the middle of them.
  florian: So, scrollable-always breaks things.

  florian: One option is "always ink"
  florian: Second is "ink by default, UAs can determine when it should
           be scrollable"
  florian: Third is "ink when not editable, scrollable when editable"
  fantasai: I like the second
  florian: Hard to test, but maybe doesn't need to be tested.
  florian: I can live with that.
  astearns: So proposal is "hanging spaces are ink overflow by
            default, UAs can choose to make them scrollable overflow
            when it's useful"

  [discussion about hanging punctuation]
  stantonm: Are there implications about underlines?
  stantonm: In our world (Kindle) we want punctuations to hang outside
            the box, overlap is fine
  fantasai: They'll still do that, yes.
  astearns: Objections?

  RESOLVED: Hanging spaces are ink overflow by default. UAs may make
            them scrollable overflow when they think that would be
            useful.

Remove collapsible line breaks adjacent to word separators
----------------------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/3481

  fantasai: Proposal is to defer to level 4
  astearns: Anyone concerned about punting?
  astearns: Reading through the issue, lots of words I don't know...
  astearns: We discussed previously and didn't get a conclusion
  fantasai: Looks like it'll need more research and digging.
  fantasai: I think we should get the spec done and defer this.

  RESOLVED: Punt "removing collapsible linebreaks adjacent to work
            separators" to level 4

Segment Break Transformation Rules for East Asian Width property of A
---------------------------------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/337

  fantasai: Close it somehow...? I don't know what to do.
  <fantasai> Section under discussion
             https://drafts.csswg.org/css-text-3/#line-break-transform
  myles: I think this is worth some discussion.
  astearns: Did you find anyone at Apple to talk to?
  myles: I started a discussion; same story happened, we tried to
         describe it to Ken and then he had no opinions, same thing
         happened with me.
  myles: So in light of that I'm willing to somewhat amend my previous
         position
  myles: The spec lists a collection of segment-break rules,
         writing-system rules, general category rules, and the word
         "hangul"...
  myles: I'd like the criteria of this to be listed somewhere that
         isn't CSS.
  myles: I'd ultimately like this to go into Unicode somehow.
  myles: Ultimately I don't think browsers should be in the business
         of making these sorts of character decisions.
  myles: If we can do that, I'm willing to accept it.

  florian: I don't have a problem with that in theory.
  florian: To the extent I've tried to discuss this with unicode, I
           didn't sense any interest on their side that this is a
           problem worth solving.
  florian: Or maybe not even a willingness to understand the problem.
  florian: If we were doing codepoint-by-codepoint I'd be concerned,
           but this is category based.
  myles: I'm an implementor here; we have different ideas about
         "complicated".
  myles: Also their lack of interest is a signal. We're not the only
         language that uses text.
  fantasai: We're one of the only that takes broken lines and unbreaks
            them.
  myles: Unicode has taken on work to describe all the linebreaking in
         CSS. So if they don't care about this, that's a signal!
  fantasai: They have no spec for line unbreaking.
  koji: We've tried to combine multiple properties, the WG rejected
        the idea, unicode started the spec for CSS. So I think I agree
        with Myles; we either convince Unicode, or stick with what we
        had before and not combine multiple properties.

  astearns: What's the current state of the spec?
  fantasai: There's a bunch of rules in the spec based around
            East-Asian Width property and General category.
  fantasai: Started with EAW, made an exception for Hangul because
            it's wide, and I think that's what's implemented in Gecko
            right now.
  fantasai: This issue was opened on "I want you to handle ambiguous
            characters better"
  fantasai: So in response we added "if the ambiguous character is in
            a context we know is wide, like Chinese, treat it as wide;
            otherwise as narrow".
  fantasai: Then Unicode redefined some characters that were
            previously narrow/ambiguous into wide, because of emoji.
  fantasai: Then we reopened the issue to treat emojis as ambiguous.
  florian: When we complained to Unicode about that change, they said
           this property is for terminal rendering, nobody should use
           it.
  koji: I agree the emoji issue is bad.
  koji: So my preference is from before, take behavior based on
        encoded block. That might be slightly less accurate than your
        current proposal, but as long as it's consistent across
        browsers authors will be happy enough.
  fantasai: So instead of using EAW/General properties (or others), we
            should evaluate unicode blocks and declare how to treat
            each?

  [discussion of how unicode blocks work]
  fantasai: That would probably work.
  astearns: That sounds great.
  myles: So somebody in this group, not me, should come up with a list
         of blocks. If it's very large, we can revisit, but if it's
         small, then ok.
  myles: My criteria here is maintainability.
  fantasai: I can take that action.
  myles: Ok, we can discuss it then.
  jfkthame: For maintainability, you'd have to recheck each version,
            approximately yearly.
  fantasai: Sure. General criteria is like "if it's more than 80% han
            characters, it's on the list", easy.
  koji: As the editor of UAX 50, I'm doing that every year. We will
        assume VerticalOrientation to U for CJK characters, you can
        check that.
  <dbaron> $ grep ';' Blocks.txt | grep -v "^#" | wc -l
  <dbaron> 291
  fantasai: The set of chars we want here are pretty much exactly
            Chinese and Japanese characters.
  jfkthame: Base it on Script, then?
  fantasai: We do that today, but we have to add punctuation, etc,
            thus the current complexity.

  astearns: So proposal is fantasai looks at the blocks, and comes
            back later.
  myles: Parting word, text started elegant, got full of exceptions
         over time. If that happens again, we should just cut it off.

vertical-align:middle when dominant baseline is not alphabetic?
---------------------------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/4495

  fantasai: Afaict from dbaron's description, issue is that
            vertical-align:middle has you find the point between the
            alphabetic baseline and the x-height, and call that "the
            middle", then use that for alignment
  fantasai: Apparently there's some impls that, in vertical modes,
            instead of doing that in a sideways fashion, take the
            central baseline.
  dbaron: I think Gecko does vertical-align:middle based on, not a
          font-derived central baseline, but a synthesized central
          baseline.
  fantasai: So I think we should clarify the spec to say you're using
            the alphabetic baseline even in vertical text.
  fantasai: *Not* the central or hanging or whatever the dominant
            baseline is.
  fantasai: So you'll always find the same point.
  fantasai: But when text-orientation is upright, the x-height doesn't
            have a meaning in the transverse axis, so maybe use
            central then.

  jfkthame: What about when text orientation is mixed?
  fantasai: Then you're rotating the text, you can still get a
            meaningful x-height and align there.
  jfkthame: I disagree, this is mostly useful for CJK text and we
            should be centering.
  fantasai: Then just use the central baseline explicitly.
  fantasai: If that's what you want to change to, though, we can do
            that.

  fantasai: So we have several distinctions we make in vertical texts.
  fantasai: First is whether you're in horizontal or vertical
            typographic mode.
  fantasai: Horizontal mode is trigger by writing-mode: sideways-rl
  fantasai: In that case we should ensure the conventions match a
            rotation from horizontal text
  fantasai: Within the vertical typographic modes (vertical-rl/lr
            modes), we have three text-orientation values.
  fantasai: upright, sideways, mixed
  fantasai: If we want this "Middle" alignment to be available for a
            paragraph in vertical typographic mode, we need to define
            it the same was as in horizontal mode, at the very least
            when t-o is sideways
  fantasai: But when t-o is upright, that definition is nonsensical.
            It'll have to be the central baseline.
  fantasai: For mixed, it's a question of do we want to match upright
            or sideways.
  fantasai: Since "middle" is this weird thing tailored to latin text,
            I say we should match it to how latin text works, which is
            the alphabetic/x-height thing.
  fantasai: If someone wants to use actually centrally-baselined
            stuff, they should say vertical-align:central;
  fantasai: Open to other opinions tho

  heycam: Kinda feel like I agree with jfkthame, where mixed is for
          primarily vertical with little bits of rotated horizontal
          text. So I think you want to align based on majority text.
  fantasai: This isn't a default keyword, you have to specifically
            request middle
  heycam: I see what you're saying, there's no other way to get that
          before.
  fantasai: So yeah, you'll get the correct (central-aligned) behavior
            by default. You have to explicitly say "middle" to get
            this behavior; I agree it's usually weird.

  dbaron: What I'm concerned about is that we don't add half the
          x-height to anything but the alphabetic baseline.
  dbaron: I think fantasai makes sense; this is something you'd use
          for a small image you want to line up with the text.
  dbaron: Since there's already a "central" value, and if there *is*
          an alphabetic baseline around to use, I think we should do
          fantasai's proposal.
  dbaron: The name is unfortunate, but we're stuck with it.
  jfkthame: 'central' keyword is new, right?
  fantasai: Yeah, we added it for CJK specifically here.
  dbaron: We don't implement it yet, I didn't realize it was there.
          But its existence influences my opinion here.
  jfkthame: So we're going to have to tell people to stop using middle
            for their CJK?
  dbaron: It doesn't really work there anyway, it's only good for
          bicameral scripts.

  astearns: So proposed resolution is to make the middle spot always
            be what middle uses, as long as the alphabetic baseline
            and x-height are in the relevant axis.

  RESOLVED: "vertical-align: middle" always uses halfway between
            alphabetic baseline and x-height, except in modes where
            the x-height is meaningless (vertical writing modes with
            upright text orientation)

  <dbaron> The followup question is whether the alphabetic |
           ideographic | central values are stable enough to implement.

  RESOLVED: In such "meaningless" cases, "middle" means the same as
            "central".

  <break>
Received on Thursday, 20 February 2020 00:53:11 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 20 February 2020 00:53:12 UTC