- From: Dael Jackson <daelcss@gmail.com>
- Date: Fri, 7 Aug 2020 10:15:32 -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 Inline 3 (Continued)
------------------------
- RESOLVED: No change [leave as text-top and text-bottom] (Issue
#860: Naming of text-top and text-bottom baselines)
- There was interest from the group in extending the vertical
align property to the n-th child so a proposal should be created.
The proposal should deal with cases for different elements
setting first and last baseline and cases where first baseline
isn't necessarily the first baseline selected. (Issue #1339:
Vertically align to nth-child)
- RESOLVED: Canonical order of vertical-align is source,
baseline, shift (Issue #5235: vertical-align syntax /
canonical ordering)
- RESOLVED: We want to allow reordering of values for vertical-align
(Issue #5235)
- RESOLVED: In order to keep vertical-align and align similar we
want to allow reordering of values for align property
(Issue #5235)
- RESOLVED: auto value of baseline-source not allowed in
vertical-align shorthand (Issue #5235)
- RESOLVED: top and bottom take precedence over middle (Issue #5234:
'vertical-align: middle' on table cells)
- RESOLVED: Leave vertical-align superscript and subscript as a may
[for using font metrics] (Issue #5225: vertical-align:
super and font metrics)
- RESOLVED: Font face descriptor for metrics should include
superscript and subscript size and position and allow
opting in to use font metrics (Issue #5225)
- RESOLVED: 0.2em [amount to shift down for vertical-align: sub] and
1/3 em [amount to shift up for vertical-align: super]
are the ratios [when not using font metrics] for
superscript and subscript (Issue #5225)
- Being able to vertically align to the middle of the cap height
(Issue #4707) will be deferred to the next level so that the
group can see if the central property, once implemented, solved
this problem, as well to include problems like these in the
more universal solution for all languages.
CSS Text
--------
- There was a proposal to introduce a switch for letter-spacing
behaviors in order to allow authors to opt into the preferred
behavior and, if that behavior is later found to be web compat,
make it the default.
- However, there was push back about creating a switch which may
later be unnecessary, especially if it's found that it can
become the default value.
- Both Firefox and WebKit are working on changing the behavior in
their implementations so there should be real data to determine
if this is a breaking change shortly.
- RESOLVED: Change Text L3 to a may for the [letter-spacing]
behavior and transfer switch discussion to Text L4
(Issue #1518: letter-spacing should not apply to the end
edge of a line/span?)
===== FULL MINUTES BELOW ======
Agenda: https://wiki.csswg.org/planning/virtual-summer-2020#tuesday
Scribe: dael
CSS Inline 3
============
Rossen: It's :15 after the hour
Rossen: We'll do vertical alignment and break at top of hour
Naming of text-top and text-bottom baselines
--------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/860
fantasai: We have text-top and text-bottom of vertical align
fantasai: Not really top and bottom in vertical text. Should we
rename?
fantasai: My position is in spec use over and under terms, but
keywords in vertical-align no point in renaming since
existed since CSS1. Any new properties with the new
keywords should be consistent with vertical-align.
Don't rename the syntax, use over and under in spec.
AmeliaBR: We have keywords for this, text-before-edge and
-after-edge which are legacy keywords for SVG. If there's
a desire for logical names we could undeprecate
fantasai: Yeah but don't match anything else in css. Also in
vertical-lr before and over edge don't coincide.
I'm not sure which SVG thinks is what.
fantasai: Difference between flow- and line-relative keywords
Rossen: myles brought up good point on issue about aligning with
naming from font terms
fantasai: Yeah. Fonts uses top and bottom, but it's so deep it's
only exposed to author of font file in abbreviated form
fantasai: I think so far removed from terms web authors use it's
effectively not relevant
koji: They are very different. Font is physical so top is not always
over. CSS always takes text-top and -bottom as logical but in
fonts text-top is physical
<fantasai> https://drafts.csswg.org/css-inline-3/#baseline-types
fantasai: I don't think we should rename or alias keywords. Stick
with text-top and -bottom. In spec prose use text over and
under. That's what I drafted ^
AmeliaBR: Given we're stuck with property being vertical-align
having keywords as describing from vertical alignment is
probably okay.
fantasai: Yeah, that's where I landed. Close no change
Rossen: Are you saying current text-over?
fantasai: Current spec does not add new keywords. Uses text-top and
-bottom. Doesn't switch over anything. Spec prose when
discussing uses text-over or ideographic-over in
descriptions
Rossen: I see
Rossen: And leaving no change is closer to font terms as well
besides weirdness koji mentioned
Rossen: Proposal is no change, leave as text-top and text-bottom
Rossen: Thoughts or objections?
koji: Confirm- I think we're adding keywords for ideographic-top and
-bottom?
fantasai: I think we don't have -top, we just have ideographic which
is the bottom edge. Inherited from SVG. Not adding any
keywords for top
chris: Because they were originally baseline
Rossen: Objections?
RESOLVED: No change
Vertically align to nth-child
-----------------------------
github: https://github.com/w3c/csswg-drafts/issues/1339
fantasai: Some discussion of being able to align not just to first
or last line but of a particular child of element
fantasai: Some people working on mathML polyfills wanted this. Also
cases where might want vertical alignment in respect to
heading but stuff above you ignore
fantasai: Feature to say hey this element is what you should pay
attention to for baseline.
<fantasai> https://github.com/w3c/csswg-drafts/issues/1339#issuecomment-494988680
<fantasai> e.g. baseline-priority: high | normal
fantasai: Question is does WG want to add such a feature like
baseline-priority:high and if it's high that gets priority?
<dbaron> what if you want a child to override the first baseline but
not the last baseline?
AmeliaBR: Useful for various layout cases where default baseline
alignment isn't what you want.
AmeliaBR: Agree with TabAtkins that way to do it that the child
declares it rather than figure out how to have parent
refer to which child
Rossen: Multiplicity?
AmeliaBR: First child that says baseline priority if first and last
child with last
Rossen: Intent of feature is select a specific
AmeliaBR: You select by setting property on child element
fantasai: Yes, makes sense
TabAtkins: You don't declare on everything, you put it on the one
thing you want the baseline to come from and that's what
you get
dbaron: What if author wants something high priority for first but
not last?
fantasai: Interesting. Should let them do it. Maybe set separately
for first and last baseline
AmeliaBR: Or what if you want to align with last line of heading? I
don't know.
AmeliaBR: Probably need to think through full proposal
<faceless2> See also https://github.com/w3c/csswg-drafts/issues/4116,
which is the same sort of issues except images exporting
baselines.
fantasai: What I'm hearing is interest in doing this. Proposal
should deal with cases for different elements setting
first and last baseline and cases where first baseline
isn't necessarily the first baseline selected
Rossen: At least to start with. More cases will come as we work. I
agree there's interest from group.
Rossen: Who will work? fantasai?
fantasai: I guess. I would appreciate people with comments and ideas
Rossen: General support in going forward with such feature. Sounds
like a natural extension to baselines and using more
granular capabilities. Please help fantasai with use cases
and ideas
Rossen: Sound good?
fantasai: Yep
dauwhe: Is Brian on?
Rossen: I don't see on meeting
dauwhe: Might be interested because MathML work
Rossen: Definitely. Anyone interested should help fantasai
vertical-align syntax / canonical ordering
------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/5235
fantasai: Minor questions. We split vertical-align to 2 longhands
because SVG had the two longhands and CSS had shorthand,
so made them relate like this.
fantasai: Questions. Added baseline-source longhand where it's
first or last. What's best canonical ordering of values?
fantasai: I put baseline-source then baseline-alignment then
baseline-shift. E.g. "first alphabetic 0.4em"
fantasai: If that seems fine we can close on that
<fantasai> vertical-align: first alphabetic 0.4em
Rossen: Thoughts?
Rossen: Sounds like your proposal makes sense
heycam: Reads nicely in that order. Don't remember specific needs
for these properties.
fantasai: Second question was normally we allow reordering of
keywords and values as long as can parse without
ambiguity. CSS align restricts position of first and last
with baseline keyword.
fantasai: Do we want to be consistent with css align or do we want
to allow reorder because in this context can parse either
way?
fantasai: I guess 3rd option is make it reorderable in align also
<fantasai> https://drafts.csswg.org/css-align-3/#baseline-values
heycam: In other properties is that also 2 separate properties or is
it within the one?
fantasai: Current alignment property is just one with no longhand.
Current is [ first | last] ? baseline
<fantasai> css-align - <baseline-position> = [ first | last ]?
baseline
fantasai: Do we match, allow arbitrary order in these, or loosen
alignment to allow reordering
Rossen: Can we do that?
fantasai: I think so. Would make invalid things valid. I don't think
lots of people use first | last especially since it
doesn't work in Chrome
Rossen: Not sure I would jump to that conclusion so quickly. Doesn't
sound benign
AmeliaBR: Change is to allow keyword to be in either order. Not
breaking anything but something that didn't work might work
fantasai: Yes
AmeliaBR: Fairly new property so I don't think big web compat risk
Rossen: Is that based on data or feelings?
AmeliaBR: Feelings. And we warn people about zombie css and do not
guarantee that something with no affect before is always
no affect
fantasai: And first | last don't work in chrome so no reason to try
and use it there
Rossen: We have canonical ordering. Do we allow value reordering and
do we expand to align. That's the progression. Let's decide
vertical-align first.
fantasai: Preference is lean toward consistent, otherwise no opinion.
Rossen: If align wasn't there is there a reason to disallow
reordering
fantasai: No
Rossen: So for vertical-align want to allow reordering
Rossen: We can resolve on this and then figure out if we can extend
to align. Sounds like we feel fine without data but this is
new and ideally doesn't break
Rossen: With that we have 2 resolutions
Rossen: Anyone think we should go the other way? Keep them strict
without re-ordering?
Rossen: 2 resolutions.
Rossen: The canonical order, vertical-align: first alphabetic
0.4em...record that?
Rossen: Okay. Canonical is first, alphabetic, shift
florian: As spec currently?
fantasai: Yeah
Rossen: Objections?
RESOLVED: Canonical is source, baseline, shift
Rossen: We want to allow reordering of values for vertical-align
Rossen: Objections?
RESOLVED: We want to allow reordering of values for vertical-align
Rossen: Third: In order to keep vertical-align and align similar we
want to allow reordering of values for align property
Rossen: Objections?
RESOLVED: In order to keep vertical-align and align similar we want
to allow reordering of values for align property
fantasai: One more on this. Normally when have longhand/shorthand we
allow all values of longhand to be part of shorthand
fantasai: Initial value of baseline-source is auto. Do we want that
initial value to be allows in vertical-align shorthand? It
is initial value so no need to be specifiable. If it is
explicitly and we add auto to alignment-baseline that's
not parse-able easily
fantasai: Might be a reason to disallow. Don't lose capability and
opens possibility to auto value
florian: So when you mean auto you omit the value
fantasai: Yes
[This is also how it will be serialized anyway due to shortest
serialization]
fantasai: I don't think it's a big deal. I have a slight preference
to omit in case it's useful in future since auto is
general keyword
florian: Easier to add than remove so let's do what you suggest and
we can add it back if we change our mind
Rossen: Fair. Other reasons to keep it by anyone?
<dbaron> that sounds good to me
Rossen: Objections?
RESOLVED: auto value of baseline-source not allowed in
vertical-align shorthand
'vertical-align: middle' on table cells
---------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/5234
fantasai: Has top keyword and bottom keyword which are special
because don't work off baseline. They shift based on total
linebox size.
fantasai: Also has middle which is x-middle baseline and aligns to
x-middle of parent. Same as alphabetic
fantasai: We also have vertical-align top, middle, bottom all behave
completely unrelated to inline layout and they are
basically start, center and end. By splitting to longhand
it means we have to map to magic. Middle is part of
alignment-baseline and top and bottom are line relative
fantasai: Can spec vertical-align: top middle on a table cell. What
does that mean?
fantasai: I prefer top and bottom take precedence
<dbaron> sounds fine to me
AmeliaBR: Did debate recently about which longhand top and bottom go
to. One solution is move them into other longhand to solve
this one issue
AmeliaBR: It would mean that alignment-baseline controls table
alignment because that makes no less sense than anything
else
florian: Think we had reasons to put in longhand we picked
fantasai: Because not possible to combine top or bottom with shift.
Can in theory with everything else
fantasai: I don't have a strong feeling about this. Don't know if
anyone else does
florian: To extent we keep in this longhand your proposal seems
reasonable. Should they be moved is separate
fantasai: Right, anyone who wants can re-open that issue and tag for
discussion
fantasai: This top and bottom take precedence over middle
Rossen: Other comments or objections?
RESOLVED: top and bottom take precedence over middle
vertical-align: super and font metrics
--------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/5225
fantasai: Maybe should have Jonathan.
fantasai: 3 questions on this.
fantasai: Background is current implementation of super and sub
script are not dependent on font metrics, use UA ratio
fantasai: Second point is there are font metrics for super and
subscript. Third point is they are not particularly
reliable
fantasai: Should spec allow, disallow, or require using font
metrics? Require I don't think we can do reasonably
dbaron: Gecko seems to use font metrics.
dbaron: Cross platform code calls into font metrics code to get
super and subscript metrics. I haven't looked into specifics
of what they return
fantasai: Spec allows but doesn't require it. If that's fine leave
spec as-is
Rossen: That'll satisfy the halfway solution dbaron described or the
full solution
dbaron: Dug in further. We hard code these to 0.2 x em height for
sub and 0.34 for super.
<dbaron> https://searchfox.org/mozilla-central/search?q=_OFFSET_RATIO&path=&case=false®exp=false
<dbaron> or more precisely,
https://searchfox.org/mozilla-central/search?q=NS_FONT_%5BA-Z%5D*_OFFSET_RATIO&path=&case=false®exp=true
dauwhe: There are places css is used which are not browsers which
would be pleased to use font information
florian: Source of concern. That it should be accessible, yes. If
you can get that with a keyword that does something
different in browsers is not great
fantasai: So question is do we want to allow browsers or impl to use
font metrics? If we're not requiring do we want to require
a ratio and get interop? If we're disallowing should we
spec a ratio?
fantasai: If not using font metrics should we add an ability to do
so?
heycam: Saw proposal about overriding metrics in @fontface rule
faceless2: That was myles. If solving solve for all.
AmeliaBR: Have a feature in font-variant that allows proper
typographic sub and superscript from font. So is a way to
access if you have a well defined font. Haven't played
with it.
fantasai: That one will pull out glyphs and synthesize them if font
doesn't have. Doesn't shift baseline so if you have nested
super or an image as a super that's not a pure glyph you
cannot do that
AmeliaBR: As an author it would be useful to be able to have
vertical-align:super do something nice and typographic but
I'd be very worried about backwards compat if we widely
change the standard html 1 subscript style
<florian> [more info on using font-variant for that sort of things
at https://wiki.csswg.org/faq#styling-sup-and-sub-using-font-variant-position
]
fantasai: Ratios aren't consistent but close
fantasai: One option is we could allow font metrics, don't require,
try and get alignment on the ratios.
fantasai: Then explore having the metrics spec via @fontface
faceless2: Solving without solving for superscript size is doing
half the job
fantasai: That's against Fonts 5
fantasai: You want to file it?
faceless2: I think it's best solved in fontface rule
fantasai: But you have to be able to access the size. vertical-align
is only about baseline position. If you want to be able to
size it you have to add to fonts 5 as separate issue.
faceless2: Yeah. I'll put a note
fantasai: Proposal: leave spec with a may, look into asking impl to
align on fallback ratio, allow investigation of
descriptors via font face
florian: Question, what we expect impl to do with the may is by
default link to a fixed ratio and have an allow list of
fonts with useful metric and use that if someone
particularly cares about typography
fantasai: Seems like
florian: If we don't give guidance I wonder if people won't start to
use metrics from fonts or cause more problems where I put
something which looks wrong in Chrome and I corrected
fantasai: Author can always use explicit length or percentage. If
they wanted something precise they can do that
Rossen: Any time we define anything as may we define may have
problem for authors
florian: Seems safe if we assume default is ratio and you opt in to
better, if it's it that it's fine. If it applies in bad
fonts for some browsers it will be weird.
fantasai: Maybe suspend until myles gets back
florian: I'm hinting at it's fine but adding a note what the may is
for and that people should be careful when impl
fantasai: If you want to propose text that's fine
florian: I'll do that and run by myles
Rossen: We can record resolution, myles can read and reopen when he
comes back.
Rossen: Progression of fantasai's suggestions makes sense. Can't
disallow so we need at least a may
Rossen: Aligning on ratios that are as interop as possible is great.
Rossen: Already a number of posts in issue from impl that desc how
they get ratios. Encourage more of that so we can come down
to something same.
Rossen: First resolution should be leave vertical-align super and
sub as a may
Rossen: Objections?
RESOLVED: Leave vertical-align super and sub as may use font metrics
Rossen: I don't know that we can have a resolution about ratios
without actual ratios
fantasai: Yeah
Rossen: Leave that open
fantasai: Okay
Rossen: Last one is with @fontface
fantasai: I think font face descriptor for metrics should include
super and subscript size and position and allow opting in
to use font metrics
Rossen: Sounds good. Objections or comments?
RESOLVED: Font face descriptor for metrics should include
superscript and subscript size and position and allow
opting in to use font metrics
<break type=short>
<dbaron> If we want that descriptor to be able to override the
"fixed" values in browsers, we might want the spec to say
that sooner rather than later (i.e., before the descriptors
get implemented).
<fantasai> we just resolved on that, I thought
Rossen: Time to restart
Rossen: Time check, 40 minutes remain
fantasai: Back to previous issue we have data from impl (thanks
everyone)
fantasai: [lists ratios used by each browser]
fantasai: All slightly off but fairly close
fantasai: I propose 0.2em and 1/3em and put that in spec
florian: +1px seems very specific
koji: I checked commit log and added hyatt. So it's old code
florian: In that case sure
fantasai: Proposal 0.2em and 1/3em. Slightly different but very
close for everyone
Rossen: Thoughts or objections?
koji: Do we have myles?
Rossen: 12 more minutes [before he can join]
fantasai: Safari is using 0.2005 and 1/3em
faceless2: That was me measuring on screen so not gospel
Rossen: As any other decision we can change our minds
Rossen: Would be reasonable
Rossen: Objections to 0.2em and 1/3 em are the ratios for super and
sub script?
RESOLVED: 0.2em and 1/3 em are the ratios for super and sub script
vertically align to middle of cap height
----------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/4707
fantasai: Proposal is defer to next level
fantasai: Lovely diagram for the problem. They don't have quite
right font metrics because x-middle is not middle of cap
height.
fantasai: 2 things going on here that make me want to defer. Adding
cap-middle is easy. Couple of concerns. Cap metrics not
particularly reliable
fantasai: Also we have a central baseline that tends to coincide
with cap middle already. Possible central baseline will
solve when implemented for many purposes
fantasai: Last reason to defer is we have same problem, not just
western but other writing systems. We have an issue that
most writing systems besides western and cjk don't have
the metrics to do the sizing in inline layout and we don't
have a solution to that
fantasai: My inclination is try and defer until we can solve
worldwide problem to get top / bottom / middle for every
writing system. I don't know what it will look like
fantasai: Given that current implementation of central will get you
close and we want to solve for all writing systems I
propose we defer cap middle until more context on 5244
florian: That's with understanding it's possibility central baseline
will solve it?
fantasai: Yeah
Rossen: Agree with use case and problem. Will revisit once central
baseline is solidified and see what else is needed
fantasai: Yeah. Central baseline is solid but needs implementations
Rossen: Okay. Anything else on this?
fantasai: That's all
CSS Text
========
letter-spacing should not apply to the end edge of a line/span?
---------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/1518
koji: css 2 spec says letter-spacing is added between characters
koji: No implementation does it. Blink and webkit adds to right of
character
koji: Gecko adds to inline-end of character in resolved direction
koji: Commonly asked question on web when they want to center or
right align or when they want to put borders on underlines
koji: For alignment if we use negative margins, lots of hacks
koji: Proposing solve this by a switch on the property
fantasai: I would like to investigate more web compat of doing
things right. Hasn't happened yet. Agree undefined for L3.
I think don't add a switch at this point in time
<dbaron> I think we'd like to switch to doing it right eventually;
doing it just hasn't been a priority.
florian: If you want to use letter-spacing for purpose of
letter-spacing, what is specified is good. It has been used
for other cases, though. Because of that we're to some
degree locked into behavior
florian: In earlier discussion fantasai suggested we define some
bits and look at switch for next level. I think koji wanted
entire undefined.
koji: I thought fantasai wanted to define it but she said she's fine
to undefine. I think for L3 we are in consensus to undefine
koji: L4 it looks like not consensus. I think we should add the
switch and fantasai doesn't want
koji: fantasai any reason you don't want switch?
fantasai: I want to figure out what web compat constraints are to
see how much we can fix and how much has to be a switch. I
want to actually discuss with more information and thought
as to what that ought to look like
<tantek> +1 figure out webcompat constraints
florian: All agree some aspects can't work nice way. Not clear all
aspects must stay as implemented. Maybe some could switch to
better without breaking pages.
chrishtr: This property has high use on web according to use
counters. Half of all web page loads. Will change layout
and break or move content around.
chrishtr: This issue has been pending for 2 or 3 years now. In
theory it's possible there could be a way to make a change
to all browsers behavior without breaking web no one has
put in work to prove that in 3 years.
chrishtr: More practical way forward is new aspect to property to
allow sites to opt in to internal characters getting
spacing. That's actionable thing we can do
<AmeliaBR> `letter-spacing: 0.1em trim`
fantasai: While so many sites use letter-spacing, most are not in a
way where compensating for this bug. Most of them use it
normally and not notice rendering is slightly off. Fixing
in general makes these sites work as author intends.
Possible some sites where switching can cause break. But
we would fix others.
fantasai: I don't think usage says 50% of websites will break.
dbaron: 2 things. Gecko behavior is substantially different from
Chrome. We occasionally get an issue from a dev but I don't
remember us facing breakage for this
dbaron: That makes me think there may be room to do without compat
problems
dbaron: Other is since letter-spacing is old it may be in reset
stylesheets. Interesting is how many are something other than
letter-spacing normal or 0
florian: If we define as undefined in L3 and worry about it in L4
that lets us do either. If we define as Chrome it locks us
in. If we undefine for now maybe we can do better later.
koji: To dbaron's statement we have got this request in bug reports
18 years ago and 18 comments. 18 is not low and 3 are from
this year.
* fantasai didn't catch what the bugs were
koji: It is a feature people want to fix and people waiting at least
18 years. Want to solve
koji: 18 are asking for remove the spacing at last
chrishtr: No spacing at end of span
fantasai: We're proposing fix this and not a switch. Concern from
Chrome is web compat and not shippable
koji: Yeah
chrishtr: And prove no impact is a lot of work we'd rather not do
because skeptical will succeed
fantasai: Gecko is willing to ship. If they ship in nightly and
decide compat is not issue would Chrome ship?
chrishtr: With evidence of web compat yes
koji: Concerned Gecko has different policy. They resolve regression
bug as fixed when change and we have strict policy to avoid
regression. If we search for letter-spacing and center it's
most common and people use it a lot to make sure that
letter-spacing title is centered correctly. Change will break
all those pages
myles: In our new layout engine we have implemented this. Just
haven't turned on new engine by default. In middle of
progress here
Rossen: Make sure I understand you believe this will be web compat
and just make the change?
myles: Our impression is that we are going to try and make the
change and if not web compat we'll back out. We're going to
err on side of changing
koji: Timeframe?
myles: Apple does not comment on future products or releases
florian: Questions to WebKit and Mozilla. If we spec undefined for
now would that slow interest in experimenting?
florian: I'm very interested in if some degree is doable, but not
convinced we can wrap up in time to take Text 3 to CR. Does
disappearance of text cause you to give up on experiment?
dbaron: I think it should be findable from spec if you want it impl
fantasai: What if left current definition as a may and say you may
do something else? It's not undefined but it's a may.
dbaron: That's findable from spec.
chrishtr: I don't see down side of having another option. Make it
undefined with the default settings and you could opt into
only the internal edge mode and still have a possible
future change to all browsers if it's compat to make the
default that
florian: That's kind of what we're saying. We're making it
effectively undefined now. May have a switch later. When we
refine what undefined means we can add the switch
chrishtr: Want to solve for webdev now not in a year. It's a small
change, is it that big of a deal?
florian: Too many problems with legacy and normal
fantasai: If we add things now that we only need temporarily it has
to be maintained forever and webdev have to carry
knowledge. Makes sense to wait 6 months to get it right
chrishtr: Don't believe it's a significant burden for developers.
This is a small thing
chrishtr: To makes sure I understand the core concern. I think that
you would like the default to switch if possible to make
website behave in great way by default
florian: Depending on nuances in that phrase, yes
chrishtr: I agree that is a good thing to aim for. But it hasn't
been achieved in this case. Lots of usage and evidence
it's risky. Without a lot more work and research don't
think can ship in Chromium
florian: I think future you suggest is letter-spacing growing a
keyword, something like a length and either auto or
nice-typography and there's a chance in a year or 3 where
we say both is same
koji: Not legacy. fantasai conformed we will need it for the middle.
We will need a switch. Correct fantasai?
fantasai: I'm not convinced we need a switch. I think it's possible
and reasonably likely. Main reason I think so is some of
the examples I've seen. But I'm not really... only reason
we need a switch is compat. No reason if not for compat.
If you want spacing on both sides you can add padding.
fantasai: Only reason to have a switch is for compat. Lots of
switches between previous and current isn't good for css
and add complexity
koji: You're saying it should change to padding?
fantasai: I think it should be with margin and maybe add a better
facility for manual kerning that solves the problem better.
florian: Margin is better even without something for kerning
<faceless2> can you have a switch to enable compat mode, but with a
prefix?
koji: What to do with existing cases?
fantasai: We might be stuck with this being one sided. But then
switch would not affect end edge, only end of element.
I just think that interest in forward momentum from 2
implementors to fix it. I think we should see if
that works
myles: That's what I was going to say. 2 implementors in process of
implementing. If I understand from chrishtr you don't have
evidence it's not web compat. Given that it seems a natural
way forward. A compromise of adding both as a may is okay
with us
florian: For compat there is evidence some sites break. Not a clear
analysis of if they can be isolated to limit breakage or if
it's widespread.
Rossen: Point of order, 12 minutes to the end.
Rossen: Something chrishtr mentioned that this is small. At the end
of day this is an API adding to the platform. It is adding
complexity which may be unnecessary. We have a general
principle against that. Question for chrishtr and koji where
you have proposal of switch - isn't doing so going to give
you the behavior we believe should be there by default?
Rossen: So are we talking about a run time switch or experimental
switch and not a css property so you can flight and test
overall impact?
Rossen: In other words when you implement this switch aren't you
going to arrive at desired implementation anyway, and
couldn't that be behind a field trial switch?
chrishtr: Could but something would need to be done after to analyze
if turning on switch breaks sites
Rossen: But when you impl you add desired behavior. At which point
you have great data, which is you impl it by default. If
flighted this a bunch broke, then in order to address pain
of dev can release with a switch
chrishtr: I think proposal is impl the change behind and experiment
flag, attempt to ship, and if anyone complains turn it off
Rossen: Yes
chrishtr: Have in past with things we think will work.
chrishtr: When we don't have evidence it is likely to be not a
problem we don't want to do that. It's a PITA for sites to
have to deal with it
chrishtr: Only in cases where we have evidence it's not a problem
would we be willing to do that
<fantasai> authors > implementers
chrishtr: Or if the situation at hand is very severe. Sometimes with
security we might do something like that because security
is bad enough we'd break sites. This case is not anything
like that. There's a whole bunch of people that use
Chromium based browsers we have to worry about. That would
be a lot of analysis, whereas a property switch is trivial
chrishtr: Switch seems more practical and if data comes in later
that it doesn't matter we can change the default. I wish
web was different on centering it's not
Rossen: To finish the question. From 3 values in proposed switch,
auto between and right, is between the one we aspire to have?
chrishtr: Yes
Rossen: We would have said just impl between if we started today?
chrishtr: Yes, just think auto and between
Rossen: So you said switch is simple so implementing between is
simple.
Rossen: Great. So back to my question if implementing between is
simple why can't we flight and test compat just like Firefox
and new WebKit is willing to do. If you say nope breaking
too much and we want to add the switch that's easy convo
chrishtr: Because doing so forces the change and makes sites file
bugs or do detailed analysis of existing sites
myles: Third choice is wait for FF and webkit and see what they have
to say
koji: fantasai said we don't need right only once every site has
switched to use padding for kerning
chrishtr: Is Mozilla planning to ship in next release?
fantasai: Talked to Jonathan and plans are for soon. Next release or
two should be possible.
Rossen: So that's 6-12 week time frame roughly.
fantasai: I would like to wrap this up and say we resolve to allow
both for text L3. You may do the thing specified so far
and you may do something else so we can close for L3. Open
separate issue on L4 for if there should be a switch.
chrishtr: Seems clear won't resolve on switch in this meeting so
agree we should wrap up. What about comments for German
letter spacing?
fantasai: I think not relevant for this discussion.
chrishtr: Fork to new issue as well?
fantasai: German uses spacing for emphasis and the commenter wants a
tag for that, and that's not in scope for CSS. That's an
HTML issue.
astearns: Issue for us is if spacing features we give are inadequate
for German
AmeliaBR: What's the standard typographic behavior for German and
can it be represented in CSS
[no because of this bug]
Rossen: We're just about done. fantasai had a proposed closing for
this
Rossen: Objections to that?
florian: I think resolve on that. It's not last work but we'll stop
banning the current behavior
Rossen: Objections to Change Text L3 to a may for the behavior and
transfer switch discussion to Text L4
RESOLVED: Change Text L3 to a may for the behavior and transfer
switch discussion to Text L4
Rossen: Thank you for calling in. Not all discussions are easy but
they are fun.
Rossen: No call tomorrow
Rossen: We are going to reconnect on Thursday at 7amPT
Rossen: Thanks for calling in!
Received on Friday, 7 August 2020 14:16:20 UTC