- From: Dael Jackson <daelcss@gmail.com>
- Date: Tue, 25 Oct 2022 19:00:04 -0400
- To: www-style@w3.org
- Cc: www-international@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-Internationalization Joint Meeting
======================================
Backslash & Yen sign behavior [css-fonts-4 issue #1282]
-------------------------------------------------------
- It was not clear if there was enough interest in specifying an
interoperable heuristic. Representatives from Chrome and Firefox
will investigate further internally
Flow-relative syntax for `margin`-like shorthands [css-logical-1
issue #1282]
-----------------------------------------------------------------
- Goal is to not just *enable* logical stylesheets, but make them
*not harder* than physical.
- Discussed possibilities for per-declaration, per-block, and
file-level switches, with the latter two potentially in the
future.
- It's unclear whether logical is the best default for all properties
even in a flow-relative stylesheet; e.g. text-shadow often needs
consistency across the page.
- Even in a flow-relative stylesheet, individual declarations may need
to be physical: both systems need to be available per declaration.
- Proposed syntax options were `margin-logical: values` or `margin:
values !logical`. Syntax that interferes with the property value
space is not workable. There were both strong feelings for and
against the ! syntax with neither getting a majority support.
- The propdef tables may need to be annotated with additional
information, such as whether a value assignment is physical,
logical, or N/A.
- Discussion will continue on github to determine if this can apply
to all the margin-like shorthands and then work on the syntax.
===== FULL MINUTES BELOW ======
Agenda: https://github.com/w3c/csswg-drafts/projects/32
Scribe: TabAtkins
CSS-Internationalization Joint Meeting
======================================
Backslash & Yen sign behavior
-----------------------------
github: https://github.com/w3c/csswg-drafts/issues/6848
fantasai: WebKit has a bunch of code to handle this problem - the
backslash is often rendered as a Yen sign, especially on
Windows systems, for historical reasons
<addison> (or a won sign or a yuan sign; special handling is on
non-Windows OS)
fantasai: The special handling in WK is they check if they have one
of the "known problematic fonts" or if the encoding is one
of the "known problematic encodings", they'll render the
backslash as Yen, kinda like a text-transform.
fantasai: So for the WG, do we want to adopt a heuristic like WK's,
or do we want to ask them to remove it?
fantasai: Currently text rendered on Windows doesn't look like other
OSes, because the Yen characters appear on Windows and not
elsewhere.
addison: One issue is that it's an expectation of some speakers that
the path separator is actually a Yen
addison: So actually showing backslash might not be expected by the
user.
florian: Because this is a strong expectation in Japan/Korea, at
least, that the backslash doesn't look like the backslash,
authors will continue author this way, and if it works
inconsistently based on the system that's not good. I think
we should try for interop.
florian: Reason it works on Windows is the fonts; if you don't have
the right font it won't happen
florian: So the font heuristics should probably be standardized
florian: On top of that, I think authors should be able to control
this more directly.
florian: An @font-face descriptor that lets them say what this font
is doing with regard to backslash or yen
florian: Otherwise pages authored on windows will look different on
Mac or Android, etc.
florian: So we should aim for interop on at least the heuristics.
florian: And likely go beyond to let authors specify.
emilio: The compat issue on Mac comes from authors not specifying a
font-name, or specifying a font that doesn't exist?
addison: The last one.
emilio: In that case, can that font be shipped on Mac?
<addison> I believe locales for JP, KR, TW, and CN regions do this
florian: And Android, and Linux...
emilio: These kinds of heuristics don't seem terribly appealing to
implement... I'd rather not have them, especially if it works
on windows due to fonts
<addison> This is rooted in DOS code page behavior
myles: There's no way we can ship this font on iOS or Mac, that
options is off the table
emilio: Can you explain why?
hober: Fonts are expensive; this would have to be a business
arrangement, and the spec probably shouldn't rely on that
existing for all OSes
drott: Can we discuss what the heuristic would look like? Is it like
"this window font as the primary in the font stack"?
<fantasai> WebKit heuristic is described here:
https://github.com/w3c/csswg-drafts/issues/6848#issue-1067848361
drott: And second to emilio, I don't think I'd like to carry this
legacy issue further by putting it into @font-face
<emilio> +1
drott: So probably fit with a heuristic but not further
fantasai: Heuristic is "problematic font? problematic encoding? yes
to either, render backslash as yen"
iank: What does "render" mean?
fantasai: Do a text-transform, basically.
myles: And this is a whole-element thing, looking at primary font,
not a glyph-by-glyph sub.
drott: So primary font of the element, ok.
fantasai: So just checking, you're looking at computed 'font-family'
and looking at the first font in the list?
myles: Probably, yes, I'll need to check.
myles: Also this code is older than the Blink fork. But this behavior
doesn't happen in Mac Chrome, so presumably it was deleted?
iank: I'd have to dig into the history, yeah
myles: grep for "yen sign" in the webkit codebase to find it in ours
<emilio> https://searchfox.org/wubkat/rev/0c40ba62b482511fe03646f1d4982efd727475dd/Source/WebCore/rendering/RenderText.cpp#1345-1346
<emilio> iank: ^
<emilio> https://searchfox.org/wubkat/rev/0c40ba62b482511fe03646f1d4982efd727475dd/Source/WebCore/platform/graphics/FontCache.cpp#457
is the font-family check
hober: Sometimes we need heuristics for compat reasons, but that
makes me nervous
hober: So one, heuristic should be as simple as possible.
hober: And two, spec is as a floor; this is the minimum for compat,
but you might do better, and hopefully bring it to the group
to specify.
florian: I'd like to push back against this as legacy. It's a compat
problem, but it's not rooted in the past; it's the current
expectation for Korea and Japan users
florian: I don't think a German user wants their path filled with Yen
signs, so it's not spreading.
florian: The primary offender is Windows system fonts, but Japanese
fonts are often *written* this way.
florian: So if your primary font is one of these manually-authored
fonts, but it didn't download, you'll have this problem
again.
florian: So that's why my suggestion for @font-face exists, so
authors can tell us what their font expects and we can do
the right thing just like if it was a windows system font.
myles: Right now there are zero browsers that do this on a
font-by-font basis; putting it in @font-face would mean we
have to invent a new mechanism
florian: I don't see why that would be required - the descriptor
would just tell you whether the font is one that needs the
transform
<TabAtkins> (I assume this would just cause the font to trip the
"problematic font?" part of the heuristic.)
andreubotella: What happens on Windows if you copy text with this
behavior?
addison: They'll copy a backspace, that's the actual character
andreubotella: Is that what authors expect?
addison: Windows users will see it as a Yen when they paste, as well.
The only difference will be if they put it in a message and
send it elsewhere.
JakeA: Note that text-transform doesn't usually do that; it typically
changes what you copy
fantasai: For some values; for other values (like fullsize-kana) you
do *not* copy the transformed version of the text.
<iank> Our bug relating to this:
https://bugs.chromium.org/p/chromium/issues/detail?id=305827
<fantasai> And I would argue that text-transform should never copy
out the transformed text
dholbert: Does the text-transform handle the scenario where the font
has a backslash but not a yen character?
<addison> Not just yen sign... sometimes the won sign (in Korea)
myles: We don't handle that; rather, I don't know what happens, but
we don't seem to do anything special.
dholbert: So possibly rendering tofu rather than slash
myles: Probably just doing a fallback, like text-transform:uppercase
on a font with only lowercase will trigger fallback
<David-Clarke> All the fonts and encodings shown in the example are
Japanese, but this affects Korean?
<emilio> Gecko also implemented this hack and removed it:
https://bugzilla.mozilla.org/show_bug.cgi?id=926580
drott: I found the Chrome bug to remove the hack
drott: There was some question of whether content was being created
expecting this, and if we could phase it out
astearns: Seems the answer is yes, and no.
florian: When Windows reaches 0 market share...
myles: I asked another group earlier this week - in Japanese
keyboards, is there separate backslash and Yen keys? If not,
what keycode comes out?
florian: Think the answer is "depends on the keyboard"
<karlcow> Option + Y = ¥ on my MacBook Japanese keyboard. AND \ for \
on the keyboard. (Just to answer the question but that
indeed depends on the keyboard)
<karlcow> oops on my US keyboard
<karlcow> on my Japanese keyboard. There's a yen key on the top right
with the pipe.
astearns: Probably enough discussion - is there appetite from gecko
and blink to specify a simple heuristic and implement it?
iank: I think the problem is... I'm looking at the patch that removed
this, and it's a lot bigger than a text-transform.
iank: Appears to be special code...
astearns: Re: tess's point, the rule should be simple and you should
implement it as you want.
chris: The backing store is a backslash
fantasai: I'd said before it depends on the transform
myles: From a user perspective it looks like a Yen, so they'd expect
a Yen
<addison> (if you paste into a cmd shell, you want the path separator
to be a path separator)
florian: Unsure that's true, to the user it's a path separator, and
that's a specific codepoint
emilio: I'd want to check with jfkthame and the Japanese folks
emilio: But given we removed this a while ago, I don't think so. We
could reconsider, I guess.
drott: The previous patch didn't seem to be text-transform based
ACTION drott to investigate for Chrome
ACTION emilio to investigate for Firefox
[css-logical] Flow-relative syntax for `margin`-like shorthands
---------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/1282
<fantasai> https://github.com/w3c/csswg-drafts/issues/1282#issuecomment-952428897
<fantasai> https://github.com/w3c/csswg-drafts/issues/1282#issuecomment-1105613943
miriam: fantasai and I looked at this last year, with Jen
miriam: CSS was built around physical property - trbl, width/height
miriam: For various reasons logical props are more resilient,
especially with multiple langs
miriam: Whether that's building it in purposely, or automated
translation
miriam: It would be great if we could move toward a world where
flow-relative logical props are the default
miriam: The easier solution is that we just add `-logical` to various
props
miriam: But long-term that feels like a second-class citizen, not the
default
miriam: We'd like to get to a simple, clean way to default to relative
miriam: Our plan is multi-step, starting with a property-by-property
flag of some sort
miriam: Whether that's a new prop name, a !flag, or something
miriam: That says "I want this property to be read as logical"
miriam: And once we've defined that for each property...
fantasai: And we'd add physical equivalents so you could explicitly
either way, if you wanted
fantasai: Wouldn't change the default, just let you be more specific
miriam: Once defined for all props, we could look at a block-level or
even file-level change of the default
miriam: So like an at-rule that switches default to logical for
everything in it
miriam: Or even a file-level switch.
miriam: Would have to be lexically scoped to the file; separate files
shouldn't interact.
<dbaron> Do some of the "property-by-property" mean
"declaration-by-declaration"?
[yes]
miriam: The second comment fantasai linked is someone just saying
"let's add an 's' to the property 'margins' and 'paddings'"
miriam: There's some other syntax approaches that I didn't look at
closely
r12a: You already talked about cascading - I've been using these
logical props for a long time as much as possible
r12a: I've been using them for arabic and hebrew pages, and I've
found there are occasionally situations where you really need
to leave margin-left in the code, otherwise things break
r12a: There's not many, but some cases
r12a: so we should be careful and warn people that if we provide a
big switch and say "this'll fix everything" it can break
things, too. Careful applying it en masse
miriam: Right. The logical shorthands would likely be in a different
order than the physical anyway, so updates would require more
than just the flag.
miriam: So the situation is more like you use this when writing a new
file, not adapting an old file.
addison: I think Richard was saying sometimes you need both so you
need both options.
fantasai: Right, that's part of our proposal
addison: And it's not so much as when people are mixing langs in a
page, but rather they want the same stylesheet for both
their LTR and RTL translations without much fiddling.
emilio: The "switch per file" doesn't work for the OM
emilio: The simplest solution is having different properties, but
that's not ideal
fantasai: The browser could parse it in and use the declarations...
Our proposal provides two shorthand syntaxes, both
explicit, in addition to the current "ambiguous" one.
fantasai: So the ambiguous would get decided as one or the other.
emilio: How would you decide that when writing it out with JS?
emilio: Right but then el1.style.margin = el2.style.margin loses the
detail
fantasai: The OM is currently locked into physical, so we're probably
stuck with that. Any ideas?
dbaron: I think if you want a file-level switch, you need it to store
the information in each declaration.
dbaron: So I think when you said property-by-property, at least some
of the time you meant declaration-by-declaration
miriam: yeah
dbaron: So a file-level switch will have to alter the declarations at
parse time to store the information, and possibly
indistinguishable in the OM.
fremy: It's common to bundle CSS, so per-file is an issue
[discussion about ease of "s" suffix or "l-" prefix]
fantasai: That still makes logical CSS a second-level, more awkward
option
astearns: My question on file-level switch - is there a specific set
of shorthands this would apply to? Or is it just certain
ambiguous properties?
astearns: If we add new shorthands, will they use this switch?
fantasai: Note it's not just shorthands, it's every property that
assigns in a physical orientation.
astearns: So it's not an allowlist, it's a set of props with this
characteristic
fantasai: Right, so we'd like look at overflow, which is x/y, and
we'd define that it can also be block/inline
miriam: But like 'left' won't change, it just gets a different
property
fantasai: But like text-shadow should be able to assign
block/inline, etc
<dbaron> text-shadow may be the exception to wanting the default to
be logical!
rachelandrew: Issues 'margins' (suffix), that's easily typo'd. Very
confusing especially since the order changes
rachelandrew: Not sure if we need a file switch at all, kinda like
the staged approach.
rachelandrew: Wonder if, once we have the prop-by-prop, that'll be
enough, especially since we know most authors use
postprocessors which can handle the "file-level" itself
rachelandrew: So we can find out if we even need the second step once
we've done all the properties individually.
r12a: The switch sound like it could be useful because it makes
things easier in some circumstances, but it's more complex
r12a: We've been stuck for over a year on just margin and padding, tho
r12a: The margin-inline/etc already exist and are great, but don't
have the 4-value sorted out
r12a: So it seems like just a nomenclature, wish we could sort that
out.
emilio: So the devil is in the details of 'margin'. If a logical
version of the shorthands is something we need eventually
anyway
emilio: I think it would be great to make progress here so we can
just do logical margins
TabAtkins: That exact thing is step 1 of this proposal
emilio: So yeah can we resolve on that?
emilio: And come up with a consistent model for how to switch margin
to the logical thing second
<iank> +1 to emilio
florian: The point of discussing this switch now is not to have it
now, but to be consistent with the switch eventually
florian: because if properties all work in different ways, we can
never introduce the switch, at least not simply
florian: So we don't need to decide on the switch, just need a model
where we can intro it eventually
<addison> consistency and completeness
florian: Goal is to not just *enable* logical stylesheets, but make
them *not harder* than physical
dbaron: Responding to emilio, I think it wasn't clear if we want
`margin-logical: values` or `margin: values !logical`
dbaron: I think we need to be careful about assuming the end-state is
everything-logical
dbaron: text-shadow was mentioned, and shadows in particular you
usually want consistency of light sources.
dbaron: So want the light in upper-left, even if you have Japanese
with a mix of vertical and horizontal or RTL Hebrew mixed
with your English
dbaron: So might need some more thought about the end state
addison: I think the switch is an end state, and primary challenge is
agreement on interim bits. Does seem to be important.
addison: And to get complete
addison: So let's focus on that.
astearns: Right, but agreeing that we *will* have a switch is a good
impetus
r12a: Don't agree it's a good impetus since it's been years we've
been talking about it without delivering
r12a: Let's just make a decision
r12a: All the explicit logical properties already work, just the
shorthand is missing
<jensimmons> :dir
r12a: Meanwhile while we wait, need a way to change properties,
currently browsers use :dir to do so
florian: Here's a concrete proposal, tying to David's earlier point
about storing state
florian: I propose we don't go with extended names. Instead we use
!syntax, and add a propdef line for specifying what the
property defaults to if you don't specify the !.
florian: So for like text-decoration you'd say "Default Directions:
n/a", but margin would say "Default Directions: physical",
etc
florian: And later we can worry about a global switch, maybe with
smarts about shadows, etc.
florian: But first is the state in the propdef table.
TabAtkins: Agree with what Florian said.
emilio: Not a fan of the bang, would prefer a ? mark
emilio: Would prefer a separate shorthand, even with `-physical` and
`-logical`
emilio: Less to figure out there
emilio: Lots of thing to sort out to make !logical work
?? What things?
emilio: And I just don't like the aesthetics
florian: It helps with the mental model, adding a ! in the
declaration ties well with the idea that this is a state to
be remembered per definition
emilio: Complexity - we don't have conditional shorthands that expand
one way or another based on some condition
emilio: So how do we define that, how do they serialize
emilio: Easier to say that margin-logical expands to the 4 logicals,
margin-physical expands to the 4 physicals
emilio: But for the ! thing margin could expand to 8 properties,
choosing any 4 depending conditionally
fantasai: I think you can say it expands to all of them
unconditionally, but the order is conditional
emilio: So if you have 8 declarations...
fantasai: You set the wrong ones to initial, and the right ones to
the values
fantasai: Just the order needs changing
fantasai: And we simplify in serialization
emilio: Say you have all 8 defined, and you serialize the margin
shorthand
emilio: What form do you use?
dbaron: I think some of these aren't much harder than today
dbaron: Dunno if we do them ideally today, but today if you declare
margin and then margin-inline-start, should you serialize the
margin shorthand?
dbaron: I think you shouldn't and that extends to this case
emilio: We do serialize it
dbaron: Think that's a mistake
emilio: That's how they all work, they're separate properties with
separate values
dbaron: Back when we were doing logical props as huge array of
expanded props, we would not have serialized it
dbaron: When we did it to depend on the order, we should have
depended on some of the properties of the older solution that
we dropped.
<addison> that sounds like you (emilio) are arguing for the ! syntax?
<emilio> ?
<emilio> quite the opposite
miriam: I get it that -logical is easier to impl and more consistent,
but if there's not a plan for how it becomes a first-class
citizen, I don't like it
miriam: That's why I like the ! solution, it's easy to toggle which
is the default.
miriam: Concerned we just do the simple-to-implement and leave it
that way, second class
emeyer: I'm not a particular fan of the ! either
emeyer: We have already "not important" jokes, and this'll look like
"not logical"
emeyer: Wonder if we can just add a keyword to the value
fantasai: Can't do it, that interferes with some property syntaxes,
and we need something that's completely consistent. Has to
be outside the property space.
iank: Are there that many props...
iank: As David said there are some we want to make physical.
iank: What's the list?
<addison> has someone written the list?
fantasai: It's pretty long, but some that you might *usually* want
physical you want logical sometimes
iank: This does make me skeptical of the switch
fremy: What about a logical() function for the top-level property
syntax?
astearns: We're out of time. I think the approach of figuring out
what we *can* do property-by-property, with the switch as
an eventual goal, is the way to go.
astearns: Kicking things up a level, I'm frustrated we couldn't do
all the issues. Want to find a way out of this, can't
always wait for tpac
[unminuted scheduling talk]
<chris> sad in particular we didn't get to
https://github.com/w3c/csswg-drafts/issues/4497#issuecomment-763459971
<break>
Received on Tuesday, 25 October 2022 23:00:47 UTC