- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 19 Feb 2020 19:52:25 -0500
- 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