Csswg-drafts: [css-text] letter-spacing should not apply to the end edge of a line/span?

[kojiishi]

The spec defines so, but some tests http://output.jsbin.com/mobaxex/ indicates no impls do this today.

While what the spec says looks reasonable in many cases, this does not look web-compatible, and conformant behavior may look worse if authors have put workaround, or in some use cases where it's not desired. Should we make the new behavior opt-in?

Edge platform data usage indicates 44% and Chrome usage indicates 30%.

[dbaron]

What leads to the conclusion that it doesn't look web-compatible? I think in many cases the appearance that results is undesirable.

[kojiishi]

Can't agree more it's undesirable in most cases, I'm just saying this is not compatible with any existing browsers.

What if author has already put a workaround? Such as:

span {
  letter-spacing: 1em;
  padding-left: 2em;
  padding-right: 1em;
  background-color: lime;
}

This renders good with all existing browsers but will be undesirable with conformant browser, correct?

[SebastianZ]

There is a long-standing related Mozilla bug.

For what it's worth, in order to different use cases I suggested earlier to extend the syntax of letter-spacing to allow to control whether the spacing should extend the text. The proposed syntax was:

letter-spacing: [ normal | <length> ] [ inside || [ outside | inline-start | inline-end ] ]?

For web compatibility, the default value would then be normal inside inline-end. The value currently defined by the spec. would be normal inside.

Sebastian

[kojiishi]

Thank @SebastianZ for the info, this is a great help.

According to the Mozilla bug 125390, IE6 behaved like what the spec says, but Edge does the same as Gecko/Blink/WebKit. @atanassov do you happen to know the background?

I agree with you that if we want to change the behavior, I think we need to extend the syntax. I don't have clear idea which values we should define yet. I need better understanding on what the spec is requiring (#1509), and need to understand what is the good letter-spacing for bidi (#1517).

[kojiishi]

Blink bug is here FYI crbug.com/267056.

Its comment 13 indicates that authors may put a workaround by applying negative right margin.

[kojiishi]

@SebastianZ, I support the idea to add a feature to switch the behavior. Two questions:

1. Would adding a keyword safe for serialization? If not, are you happy to have another property to control the behavior?
2. #1517 indicates a) existing behavior is not interoperable and b) no browsers do inline-end. Would you be ok with like auto for compat, or do we want to align the behavior first in #1517?

Not sure if @dbaron is happy to make this opt-in, or he still wants to change the default behavior.

@FremyCompany @litherum thoughts?

[fantasai]

I would prefer to not complicate letter-spacing, if that's at all possible, by adding unnecessary switches. Usage of letter-spacing is high, but that does not mean that a behavior change would regress websites: it's entirely possible that it would improve the situation. If we are concerned about web-compat, we should have some data indicating that the costs outweigh the benefits, and so far I don't see that here.

[kojiishi]

In crbug.com/267056, the commenter said he's using negative margins to solve the problem, and that this change will break his site. This is one proof, but from what you wrote, it looks to me that you're saying, you acknowledge the compat problem exists. Just saying it's small enough not to care, correct?

Can you show why you think this breaking change is ignorable?

[kojiishi]

and I'm also interested in hearing what other impls think. @litherum @FremyCompany ?

[FremyCompany]

I have mixed feelings about this. It is unfortunate that browser engines have settled on a sub-par design for the feature but I don't doubt that fixing letter-spacing (to leave the last letter of the line unaffected) wouldn't be trivial and would cause compat issues.

That being said, I share @fantasai's point of view that adding a flag to letter-spacing is adding complexity to the platform that might not be worth the gain. The work-around (negative margin) for this particular issue doesn't seem very difficult to use when needed, so I would posit it is probably fine to keep things as-is in this case.

Except if your language uses ideographic-like or monospace characters, letter-spacing is a not a functioning concept to start with:

[kojiishi]

Thank you @FremyCompany, that's a great idea I completely missed it exists. I'm good if we can agree with your proposal.

So, in high-level view, we have 3 options:

1. Change to a new, better behavior without switches.
2. Add a new, better behavior as opt-in.
3. Go with existing behavior. Authors have workaround, not pretty but workable.

I'm good with 2 or 3.

If consensus is on 1 (I guess there is/was, correct?) I'd like to learn what we discussed from web compat perspective.

[aaaxx]

The problem with the negative-margin hack is that it doesn't help when the span also has a coloured background, so the third option is just not good enough.

By the way, the ligature handling is wrong in @FremyCompany's picture: they should get automatically disabled as soon as any amount of letter-spacing is applied.

[FremyCompany]

@aaaxx well, the handling of ligatures isn't wrong because font-feature-settings beats other properties per the spec but, you are right, if I didn't do anything, ligatures would have been disabled.

You are also right the workaround isn't perfect but the question is whether it is good enough for the desired use cases. Having a background on the inlines isn't working well in that scenario. Underlines is another example of something that doesn't work well.

It would be interesting to study why people use letter-spacing on actual websites. I'm wondering, because even on Google.com, it is used as a hack for various things none of them striking me as the intended purpose of letter-spacing. Given how fragile hacks usually are and how widespread their use seems to be, changing the behavior of letter-spacing now seems unrealistic to me.

Another option to consider, if we decide the statu quo isn't good enough, would be to add a new property altogether. I would prefer to adding a flag for letter-spacing. We could repurpose letter-spacing to be exactly the behavior websites depend on today, then add glyph-spacing to behave as we wish letter-spacing should have worked.

[SebastianZ]

1. Would adding a keyword safe for serialization? If not, are you happy to have another property to control the behavior?

My earlier statement about normal inside inline-end being the default value was wrong. normal would stay the default, of course.

And serialization wouldn't be a problem, because both normal and <length> values (without the new keywords) would still be serialized the same way like now.

1. #1517 indicates a) existing behavior is not interoperable and b) no browsers do inline-end. Would you be ok with like auto for compat, or do we want to align the behavior first in #1517?

I just realized that my proposed syntax is web-incompatible. It should have been:

letter-spacing: normal | <length> [ inside || [ outside | inline-start | inline-end ] ]?

Where <length> values without keywords are interpreted as <length> inside inline-end, for compatibility.

Regarding your question, I'd say the behavior should be aligned first, so it's easier to add the new values.

Also, I assume there may be no use case for having inside as separate value. I just added it for completeness. And outside could also be expressed by allowing both inline-start and inline-end to be specified at the same time. So, the syntax could be simplified to:

letter-spacing: normal | <length> [ inline-start || inline-end ]?

Btw. my use case (having number input where each digit is displayed in its own "block" [copying the layout of a printed form]) would already be covered if browsers implemented the spec. as it's currently specified, i.e. if the spacing weren't applied at the end edge.
Though because that's not the case, I came up with this new syntax.

Sebastian

[kojiishi]

@SebastianZ:

Regarding your question, I'd say the behavior should be aligned first, so it's easier to add the new values.

Great! Can we try this in #1517?

[kojiishi]

@aaaxx:

The problem with the negative-margin hack is that it doesn't help when the span also has a coloured background, so the third option is just not good enough.

Agreed. We have two workarounds:
a. Use negative margin to eliminate the end-spacing.
b. Use positive padding to add the same spacing to the start-side.

The workaround b works good if you need spacing on the begin side too, even when it has borders or background color.

Do you happen to know any real pages that has 1) letter-spacing, 2) has background-color or borders, and 3) don't want start-side spacing? My imagination can't tell me how often this combination occurs, I hope you can help us on this.

[SebastianZ]

@SebastianZ:

Regarding your question, I'd say the behavior should be aligned first, so it's easier to add the new values.

Great! Can we try this in #1517?

Yes, that's what I wanted to say with that sentence. 😄 Sorry for not mentioning #1517 again!

Do you happen to know any real pages that has 1) letter-spacing, 2) has background-color or borders, and 3) don't want start-side spacing?

My use case came up from a website, unfortunately not a public one. It is one allowing users to enter something restricted to a specific number of digits or characters. The form was basically copying a printed form used for tax declarations.

Sebastian

[css-meeting-bot]

The CSS Working Group just discussed tter-spacing should not apply to the end edge of a line/span?.

The full IRC log of that discussion

<Rossen> Topic: tter-spacing should not apply to the end edge of a line/span?

<TabAtkins> kochi: Text 3 letter-spacing specifies that the letter-spacing after the last character of an element should be eliminated.

<Rossen> github-topic: https://github.com/w3c/csswg-drafts/issues/1518

<TabAtkins> koji: Concern that, while this is better, it may not be web compatible.

<Rossen> github topic: https://github.com/w3c/csswg-drafts/issues/1518

<TabAtkins> koji: Our team prefers it be opt-in, so existing pages still work but authors can choose the better model.

<TabAtkins> s/kochi/koji/

<kochi> all right :)

<TabAtkins> koji: It looks like Sebastian and François agrees

<TabAtkins> fantasai: I know it's different, I wanna know if it actually causes a problem.

<TabAtkins> fantasai: Adding extra stuff is extra cognitive laod on the author; it would be better ot just do the right thing.

<TabAtkins> koji: We have a bug requesting this feature for years.

<TabAtkins> koji: He wants to stop using negative margin to cancel the space.

<TabAtkins> koji: If we change things, his pages' compensation will instead ram the characters together.

<TabAtkins> fantasai: Right, question is how many people will have that problem, and how many will be fixed by the change.

<fremy> q+

<TabAtkins> fantasai: If you have a large amoutn of letter-spacing to cancel, so large negative margin, and there's text after, that's a problem.

<TabAtkins> fantasai: But if it's a small letter-spacing, it'll have less than ideal spacing but still okay, but lots of other pages will have improved letter spacing.

<TabAtkins> koji: I think it's a little self-contradicting - people want this feature to care about it, and people who care can apply negative margin today.

<fantasai> myles_: I don't think that's necessarily true

<fantasai> TabAtkins: I've never realized I needed to deal with this case

<TabAtkins> myles_: There's a diff between caring about letter-spacing, caring and noticing there's a problem, and caring, noticing, and trying to fix it with this hack.

<TabAtkins> myles_: What's stated in the spec is generally the correct result. I'd like to implement it, but I share fantasai's hesitation that we don't know how much will break.

<fremy> ack fremy

<TabAtkins> fantasai: I'm not hesitant, I think we should try it.

<Rossen> q?

<TabAtkins> fremy: letter-spacing is used eveyrwhere on the web, so even if a tiny fraction care enough to use the hack, it'll still be a lot of web pages.

<TabAtkins> fremy: And browsers are mostly interoperable today. I don't think it's a huge problem to keep current spec, add new glyph-spacing property that works properly, and tell authors to use latter.

<TabAtkins> myles_: glyph-spacing is bad name

<TabAtkins> fremy: Sure, anything works.

<TabAtkins> myles_: I think making two solutions, one broken and one working, isn't great. We should investigate fixing the one.

<TabAtkins> fantasai: Someone has to ship it then.

<TabAtkins> myles_: Or crawl for it.

<TabAtkins> myles_: Look for letter-sapcing and negative-margin on the same element.

<TabAtkins> Florian: Hard to tell automatically if it's bad.

<TabAtkins> fantasai: Have to investigate the inherited letter-spacing value, and if negative margin on the element.

<TabAtkins> fantasai: That's the pages that are trying to work around it.

<TabAtkins> fantasai: But there's also millions of pages that aren't trying to fix it, and will look better when we change it.

<dbaron> q+

<TabAtkins> fantasai: So it's a balance of how much bad it is.

<fremy> q+

<TabAtkins> fantasai: Slijghty worse appearance, or readability is affected.

<TabAtkins> fantasai: So you have to actually look at the page.

<Rossen> q?

<TabAtkins> bdc: Huge letterspacing is bad design by default, while negative letterspacing i soften used for proper kerning.

<fantasai> If it's mostly just slightly worse appearance, we're winning: there are many many more pages that aren't trying to compensate.

<TabAtkins> bdc: So there, we'd have the opposite issue - if we remove the space after last letter, we'd have bigger space between words than we currently have.

<TabAtkins> fantasai: If you apply letter-spacing to whole paragraph, no impact.

<TabAtkins> ack

<tantek> q?

<Rossen> ack dbaron

<TabAtkins> dbaron: This isn't th efirst time it's brought up - maybe web compat, don't know, a little afraid of it.

<TabAtkins> dbaron: If it is web-compatible we should stick to the current design.

<TabAtkins> dbaron: If we wanna conclude it's not, we need more evidence than brought so far that it's not.

<TabAtkins> dbaron: Until we have evidence that it's not, we should stop trying to discuss it every six months.

<tantek> agreed with dbaron

<Rossen> q?

<Rossen> ack fremy

<astearns> +1 to dbaron

<TabAtkins> fremy: I've seen a lot of websites using letter-spacing for not letter-spacing itself; icon fonts and aligning, letter-spacing of 1px because "it looks better on my PC", ...

<TabAtkins> fremy: I'm concerned it'll be a lot of webpages, but I"m not sure how to figure it out.

<myles_> I think dbaron made the point I was trying to make, but much more elegantly than I did

<TabAtkins> TabAtkins: Do a good collection of affected pages via a crawl, then we can just sample them to whatever accuracy you want. Basic stats.

<tantek> or at least provide URLs to illustrative examples (didn't see any in the issue)

<TabAtkins> koji: I'm not clear on the next actions.

<tantek> (illustrative real world examples, not artificial data URls etc.)

<TabAtkins> koji: I think someone has to do a collection and figure out whether it's problematic or not.

<fantasai> s/not./not?/

<TabAtkins> myles_: Someone somewhere has to prove that an impl that follows the spec is not web-compatible.

<fantasai> TabAtkins: WG likes the current spec, and puts burden of proof on implementations to prove that it's not Web-compatible

<fantasai> TabAtkins: Need to evaluate pages where they have negative right margin that matches to the letter-spacing

<fantasai> TabAtkins: And then see if they are actually broken

<TabAtkins> koji: So who will do this?

<TabAtkins> myles_: Whoever wants to change the spec.

<TabAtkins> koji: Spec has been there for five years so far...

<TabAtkins> fantasai: Yeah, nobody has stepped forward to implement this.

<TabAtkins> fantasai: We want a spec and impls to match.

<TabAtkins> fantasai: So first option is somebody impls and ships and sees what trouble they have.

<TabAtkins> fantasai: Second is somebody does a crawl and checks the stats.

<TabAtkins> fantasai: Broken vs sligthy suboptimal; we dont' carea bout latter, because w'ell fix a bunch more pages.

<TabAtkins> fantasai: Third is we do what we did with control characters, where we all ship at same time.

<TabAtkins> Florian: Option 1 where things just ship, there are release channels for early info...

<TabAtkins> bdc: I don't see how the crawl is possible really - the margin might be a little different than th espacing, they might have negative spacing and positive margin...

<TabAtkins> fantasai: position margin is fine; it doesn't cause overlapping that hurts readability, just puts in a larger gap.

<TabAtkins> bdc: So I'm in favor of just keepign the spec as it is.

<TabAtkins> fantasai: So in favor of moving forward, do impls have a pref on which strategy to use?

<TabAtkins> koji: To me this is a nice feature, but not worth spending a week doing a crawl.

<TabAtkins> koji: So I'd much rather have another property that does opt-in.

<TabAtkins> fantasai: That won't give us useful information.

<TabAtkins> fantasai: Majority of people aren't paying attention to this, or aren't caring enough to do anything about it.

<TabAtkins> myles_: I think, going along with Elika, you can track the # of times you encouter a website that uses it, but that's only useful as a fraction, and you don't know the denominator.

<TabAtkins> myles_: I can say 1k websites use the property, but we don't know how many sites considered it and didn't use it because it was bad for them.

<TabAtkins> fantasai: [repeats three options]

<TabAtkins> fantasai: And I think the WG is generally agreeing that changing the spec isn't a valid fourth option.

<TabAtkins> Bert: Gradual change; reduce it by half this year, then quarter next year, eventually it's nothing.

<TabAtkins> Rossen: So I don't think we did very good with the third option.

<TabAtkins> Rossen: Anyone want to do option #1?

<TabAtkins> [crickets]

<TabAtkins> Rossen: Anyone wants to crawl?

<TabAtkins> [crickets]

<TabAtkins> Rossen: So we're at same position as before.

<TabAtkins> fantasai: Question on #1 - we had zero interest in impl and shipping it.

<TabAtkins> fantasai: But if someone was to give you a patch, you just had to ship it, then what?

<TabAtkins> myles_: I'm happy to investigate it. I'll impl and see if it doesn't work.

<TabAtkins> Rossen: Sounds good.

<fantasai> s/investigate it/investigate it, I want to make this work/

<dbaron> I think Gecko would be happy to try taking a patch.

<dbaron> Probably don't have the resources to do it in the near future.

<TabAtkins> ACTION Myles to investigate changing letter-spacing impl to match spec regarding spacing at start/end of element.

<trackbot> Created ACTION-857 - Investigate changing letter-spacing impl to match spec regarding spacing at start/end of element. [on Myles Maxfield - due 2017-08-11].

<TabAtkins> <br dur=15min>

[tabatkins]

Post topic-closing resolution: No change to spec until we get data from Safari/Firefox trying it out.

[jonjohnjohnson]

After reading the current draft and going through this discussion and [css-text] letter-spacing and word-spacing applied to which side? #1517 (as well as https://github.com/w3c/csswg-drafts/issues/1509 & https://github.com/w3c/csswg-drafts/issues/2165), I still can't decipher if browsers are suppose to implement A or B layout of this image. Combining a large letter-spacing value with different values of text-align regardless of direction or unicode-bidi.

Notice the blue box outlining the extra space created by letter-spacing.

[kojiishi]

Thank you for asking. The spec says A, the 4 implementations do B.

[fantasai]

@jonjohnjohnson The spec very clearly states “Specifies additional spacing _between_ typographic character units” and “Letter-spacing must _not_ be applied at the beginning or at the end of a line”. Could you explain where your confusion comes from so that we can fix that aspect of the spec?

[jonjohnjohnson]

@fantasai If I just take the language in the current draft of the spec, I have confidence in "A" being the recommendation. I was just thrown off by the discussion here and elsewhere, primarily on the topic of web compatibility (i've used margin/padding to offset myself). So just hoping impls will be glad to give us this/a solution to well balanced typographic "tracking".

..and if vendors do come back with data making this change to letter-spacing incompatible, you could always start fresh with an actual tracking property, that doesn't "complicate letter-spacing" but overrides it, if not set to auto/none? Though, I'm not sure how tracking translates to CJK, Thai, etc.

[fantasai]

Closing as no change per https://github.com/w3c/csswg-drafts/issues/1518#issuecomment-320197568

[kojiishi]

Re-opening, as no one has succeeded to ship this yet after ~3 years. @fantasai and I are discussing how to move this forward offline.

[faceless2]

We've implemented letter spacing as specified, although are not yet shipping. Spacing between typographic character units seems to be the only sensible option when bidi is involved - with a more naive definition, simply adding letter-spacing after a letter, it all goes wrong very quickly.

Florian merged a PR from us a couple of months back for some tests demonstrating this:

http://wpt.live/css/css-text/letter-spacing/letter-spacing-bidi-003.xht
http://wpt.live/css/css-text/letter-spacing/letter-spacing-bidi-004.xht
http://wpt.live/css/css-text/letter-spacing/letter-spacing-bidi-005.xht

edit:

here's a much simpler example which might serve as a better illustration: https://jsbin.com/gegawon/edit?html,output

[kojiishi]

@faceless2 great you're going to ship it, look forward to the feedback. Each impl should have their own criteria how much they can accept the breakage.

Updates on impl statuses:

• For Blink, the same as before; the breakage is beyond what we can accept.
• @litherum wanted to give it a try in 2017, but told me that it won't happen in near future.
• @dbaron looks like supportive (from Gecko 125390)
• @fantasai thought the breakage is acceptable for Gecko, but when we went through a few real site examples last week, IIUC she seemed to acknowledge the breakage is more than she thought. No conclusions yet.

A few URLs @fantasai and I read and/or examined together:

• http://artequalswork.com/posts/manual-kerning/
• https://designshack.net/articles/typography/kerning-live-web-type-with-jquery-and-lettering-js/
• http://kaoriha.org/dtp/tsume/ (this site sometimes uses margin but sometimes letter-spacing, see tsume-a4 class)
• https://torounit.com/blog/2012/10/23/1372/ (in Japanese, please use your favorite translation service to read "it is widely known technique to use letter-spacing to remove spaces between inline-blocks)
• https://davidwalsh.name/remove-whitespace-inline-block#comment-61052 explains Yui3.Grid uses the technique mentioned above.
• lettering-js -- the title of the site is an example, wrap each character in a span and apply letter-spacing.
• optical-kerning jQuery plugin uses the same technique, demo here.

[kojiishi]

I think the miscommunication in the previous discussion was that, I think I somehow mislead people to believe that center/right-aligned case was the only case, when I actually wanted to say it was one of many cases the spec behavior will break.

[karip]

Note that changing this may affect SVG2 letter-spacing and word-spacing, because SVG2 refers to CSS Text Level 3 for letter-spacing and word-spacing definitions.

Currently, Chrome and Webkit render SVG text correctly without extra space at the end of the line. Firefox differs.

I haven't tested how browsers implement bidi text and other special cases for SVG.

Here's an example of right aligned text in SVG and browser results:

Edit: I had a look at the SVG text layout algorithm and the extra space at the end of the line after CSS positioning doesn't seem to affect SVG text anchoring. However, CSS positioning may affect text decorations such as underline and overline.

[kojiishi]

@karip Thank you for the info, this is very much helpful. If WG agrees to add a property or value to switch the behavior, we could say its initial value should do this for CSS and do that for SVG. That text can go to CSS Text or SVG. I look forward to hearing what SVG experts think we should do.

[fantasai]

It seems to me that the cases @kojiishi posted are largely requiring letter-spacing at the end of a span, in the middle of a line. They're not needing the letter-spacing at the end of the line. Letter-spacing at the end of the line is also the most problematic for the SVG case (and for CSS cases, too).

So my suggestion here is that:
* We define for CSS Text Level 3 that letter-spacing is not applied at the end of the line. This solves the SVG case, improves rendering in many CSS cases, and will not break at least the letter-spacing-as-kerning examples that Koji posted.
* We mark as undefined how letter-spacing applies at element/fragment boundaries in the middle of the line for Level 3, possibly describing the behaviors under consideration as options for Level 4.
* We explore further in level 4 the problem of letter-spacing applying at element at element/fragment boundaries in the middle of the line, possibly introducing a switch if necessary.

Does this seem like a workable plan?

[mruncreative]

Let me join the discussion saying how it should work:
*before the first character half of the additional space is inserted
*after every character the additional space is inserted
*after the last character half of the additional space is inserted instead of the entire additional space
How it currently works:
*after every character the additional space is inserted

This is important because letter-spacing has traditionally been used in Germany to highlight words in text like italic text in English speaking countries.
That's why the space to the sides of a word in a text should be equal. See the picture below for how not to do it:

[faceless2]

I disagree that what you're describing is optimal - a half-space surrounding the text isn't desired in many situations, and if you consider nested inlines with different letter-spacing values, it would massively complicate your proposal. The existing specification doesn't do this. But, if it were implemented the behaviour you describe could still be achieved (with letter-spacing:2em; padding-inline: 1em)

The problem is not specifying the correct behaviour, it's that the existing spec is not implemented because a large body of websites have added workarounds to the behaviour as it's currently implemented, and these sites would break if the specified behaviour were implemented.

If I can paraphrase what I believe is suggested above, the short term plan is to fix the most obviously broken case where letter spacing is messing with the spacing at the end of the line. The mid-term plan is to find a way to for authors to opt-in to the "new" letter-spacing behaviour, to enable it for those that want it, but not breaking existing websites that don't.

[mruncreative]

Well, then give me the chance to correct myself. It should work like this:
*after every character the additional space is inserted
*after the last character no additional space is inserted

Do you agree on this? Can we get this over with quickly?
There is one thing I'm sure everyone agrees: the spacing on both sides of a spaced word should be equal!

[mruncreative]

The mid-term plan is to find a way to for authors to opt-in to the "new" letter-spacing behaviour, to enable it for those that want it, but not breaking existing websites that don't.

No, that would be way more complicated than removing the workarounds from the few pages that used workarounds in my opinion.

[faceless2]

If you check the current spec you'll see it specifies that spacing is applied _between_ letters, not after. "spacing on both sides of a spaced word" is zero, and therefore equal. So I think we're agreeing on that point at least.

[astearns]

No, that would be way more complicated than removing the workarounds from the few pages that used workarounds in my opinion.

I agree it’s more complicated, but it’s what we have to deal with in making improvements to CSS. Almost all the pages that use the workarounds will never be updated, so we cannot break things behind us.

[mruncreative]

I agree it’s more complicated, but it’s what we have to deal with in making improvements to CSS. Almost all the pages that use the workarounds will never be updated, so we cannot break things behind us.

Okay, then do it. You guys are talking about it for three years already.
You all seem to know how it should work and already have a consensus about making a new CSS attribute in order to not break compatibility. You just have to do it.
What will you call it? "real-letter-spacing" instead of "letter-spacing"? Edit: "tracking" has been suggested in the discussion above
Edit2: Don't let your dreams be dreams. Yesterday you said tomorrow. So just do it. Make your dreams come true. Just do it. Some people dream of success. While you're gonna wake up and work hard at it. Nothing is impossible.

[faceless2]

Lots of things are impossible, and I have had plenty of dreams I don't want to come true under any circumstances.

Personally, I quite like something like letter-spacing: 1em gap for the "new version" and letter-spacing: 1em for the old version, but as far as I'm aware the discussion on details hasn't started yet. But I'm confident it will happen, so keep an eye on this issue as it will be cross referenced when it does.

[kojiishi]

@mruncreative:

You all seem to know how it should work and already have a consensus about making a new CSS attribute in order to not break compatibility.

We don't have a consensus yet unfortunately. Chromium's original proposal is to add a CSS property to not to break existing pages. @fantasai and a few others are against adding a property, instead want to change existing behavior, but it breaks existing pages at the level we're not allowed to implement. We're stuck there for 3 years unfortunately. Your opinion is very much appreciated to make progress on this issue.

p.s. If you haven't read this already, can you please have a look at Code of Conduct? Sorry if you have read this already.

[kojiishi]

@mruncreative
BTW, you might find elsewhere already but you can get what you want by:

em {
  font-style: initial;
  letter-spacing: 2em;
  margin-left: 1em;
  margin-right: -1em;
}

https://jsbin.com/menabat/edit?html,output

[mruncreative]

what you want by:

I don't want it anymore. I rethought what I want as soon as I was told about what the spec says.

Well, then give me the chance to correct myself. It should work like this:

I want you people to find a solution to implement what the spec says. I don't care whether it is the existing letter-spacing, a new property or an extra value letter-spacing: 1em gap.
Just solve it. It's three years. The longer you take the more complicated the websites and ebooks get and if "@fantasai and a few others" get their way the impact of the change will be larger if you take another three years.

However I'm completely neutral towards the solution you guys choose. I just want you to choose on one ;)

[frivoal]

I just want you to choose on one

A way forward has been proposed in https://github.com/w3c/csswg-drafts/issues/1518#issuecomment-652750185. I suggest we resume the discussion about that, as I think it might break the deadlock and could allow us to make progress.

Specifically, I'd be very interested in hearing what @kojiishi, as well as @litherum and @jfkthame, think about it.

[kojiishi]

I don't think the new proposal is shippable for us due to the number of pages it breaks. Talked about it to @fantasai, but since she believes the block usage is incorrect, she said she wants to break those pages and let authors fix them. Unfortunately we can't do that in Chromium.

IIUC, @dbaron thinks Mozilla can try shipping even the previous one, so my hope at this moment is Mozilla to ship and get reverted. From our experience on break-word, I hope that can convince WG?

[kojiishi]

I found @dbaron is happy to accept contributions if any but doesn't have plans to implement.

If that's still the case, how about:

• Make it undefined in level 3.
• Add a switch to level 4 (Did I understand correctly that @fantasai is ok to add a switch to level 4?)

Is this agreeable?

[kojiishi]

Started thinking about the "switch" in level 4, but then I found this is more complicated than I originally thought, because we don't know which character comes to the edge until we run the bidi algorithm, but that is after line break.

One possible idea is to compute line breaking by adding to the right of every character/atomic inline. Then after lines are broken and applied the bidi algorithm, but before computing alignment/justification, remove the spacing from the right end of each letter-spacing run. This can make the line overflow the available width if large negative letter-spacing is used, but probably acceptable because glyphs look overflowing anyway in such case.

Maybe there could be other ideas, I'll think about it a little more.

[kojiishi]

More tests on SVG behavior with underline, filter, getBoundingClientRect, textLength, and bidi.

[kojiishi]

EDIT 26 Jul: Add handling trailing spaces.

From the discussions above, here's a proposal for the level 4 "switch":

letter-spacing-behavior: auto | between | right

auto

The behavior is determined by the following conditions: * If the resolved direction of the character or atomic inline is `rtl`, the behavior is undefined. * For CSS, if the _`letter-spacing` run_ (see `between` below) includes the rightmost in-flow fragment of a wrapped line after the bidi reorder, the behavior is undefined. * For SVG, if the _`letter-spacing` run_ is at the right edge of a SVG text after the bidi reorder, the used value is `between`. * Otherwise the used value is `right`.

between

When computing line wrapping, this value is the same as `right`. Compute _`letter-spacing` runs_ after lines are wrapped and the bidi reorder was applied, but before computing alignment and justifications. A _`letter-spacing` run_ is a sequence of inline fragments that have the same used value of the `letter-spacing` property. Then for each _`letter-spacing` run_, run the _remove the rightmost spacing algorithm_ below.

right

Add the spacing to the right of every character and atomic inline.

Remove the rightmost spacing algorithm is an algorithm to remove the spacing from the rightmost character or in-flow atomic inline, except trailing spaces, floating, and out of flow positioned boxes.

1. Iterate fragments in the range from line-right to line-left.
2. If it is an in-flow atomic inline, remove the spacing from it, and this algorithm is done.
3. If it is a text fragment, find the rightmost character that is not a trailing space. If there was one, remove the spacing from the character, and this algorithm is done.
4. If it is non-replaced inline box, iterate its children from line-right to line-left recursively.
5. Otherwise loop until all fragments are consumed.

Note, this between behavior may make lines to underflow if positive letter-spacing, or overflow if negative letter-spacing. I think this is acceptable because when letter-spacing is negative, glyphs may look overflowing anyway. The between behavior only changes how much they overflow.

[chrishtr]

I agree with @kojiishi that we need to have an opt-in for this feature due to risk of compatibility. I don't think the implementation complexity is all that high.

[fantasai]

Did I understand correctly that @fantasai is ok to add a switch to level 4?

Only if we are sure it's absolutely necessary. I'm not yet so sure. :) But I think we can explore that option for L4, yes. I would prefer to do that in a separate issue, though. This discussion is long already.

[chrishtr]

Only if we are sure it's absolutely necessary.

Given the very high usage and difficulty of estimating how many and how sites will break, we need this new switch to to opt into the desired behavior.

[jfkthame]

Personally, I've never been convinced that the current design/spec of letter-spacing as inserting space between typographic units is the right one, mostly because of the complications this introduces at boundaries. I think a much simpler model would be that letter-spacing increases (or decreases) the advance width of all typographic units equally on both sides, so that the glyph remains centered (typically) within its advance. Or in other words, half of the letter-spacing is applied to each of the left and right sidebearings of the glyph.

In particular, this works well for use-cases such as German-style e m p h a s i s where it's desirable for the letter-spacing to not only add some space between each letter of <em>emphasis</em> but also to adjust the inter-word spaces before and after it. With letter-space as currently spec'd, this could be done by adding margin-inline-start and -end (or with current implementations only adding it to the start), but with the alternative model we'd automatically get half the specified letter-spacing as an addition to the word spaces. This (IMO) would be much more convenient for authors.

For cases where (half) spacing at the inline-start and/or -end edge is not desired, it'd still be possible to suppress this by using a negative margin.

This also automatically works well at element boundaries within the line. And the symmetry means it's blind to bidi issues, unlike current behavior.

I think this would make for a simpler and more understandable model for both authors and implementers. But if -- as is quite likely -- changing the behavior of letter-spacing carries too much webcompat risk, perhaps we could introduce it as a separate property tracking, specified in terms of a simple, consistent effect on glyph sidebearings.

[kojiishi]

@jfkthame's idea works for me, it solves many issues including center-aligned case.

A few issues we'd like to keep in mind. It doesn't solve right-aligned case, but authors can still work around by using negative margins, and it is less common than center-aligned. It also doesn't solve excess underlines, which is a little harder to work around. Technically speaking, border/background too, but I think it is common to add some spacing in these cases, so they might be ok.

I'm fine to have a switch or a new separate property, just need it to be opt-in.

[mruncreative]

@jfkthame

I think a much simpler model would be that letter-spacing increases (or decreases) the advance width of all typographic units equally on both sides, so that the glyph remains centered (typically) within its advance. Or in other words, half of the letter-spacing is applied to each of the left and right sidebearings of the glyph.

This is exactly what I proposed further up in the discussion. However it is not necessary because you can simply include the spaces in the tag: word<letter-spacing> word </letter-spacing>word
We don't need special treatment in that regard.
As a German I care more about getting an extra spacing html tag with correct letter spacing see https://github.com/whatwg/html/issues/5709

[mruncreative]

Upon further research that also seems to be what typesetters did originally.

[mruncreative]

Letter spacing in German usage is basic formatting like underlining. So it's really important to be part of the content and transferable from one document to another and independent of CSS. As well as easily supportable by e-readers or the like.

[jfkthame]

I don't believe German usage requires a new tag; the appropriate HTML tag is <em>, which you can style with letter-spacing instead of italics when desired.

[mruncreative]

I can also style <i> or <b> but that's not the point. I want an exclusive tag for letter spacing.

[mruncreative]

Just like Americans have their exclusive tag for italic text no one here even used before the end of the war.

[mruncreative]

CSS styled tags are simply not a viable solution for archiving.

[mruncreative]

Or keeping the styling when the section is taken out of the original document.

[mruncreative]

Scrapers will probably also ignore it.

[jfkthame]

This is not the right place to argue about new HTML tags, I'm not going to engage further in that.

[jfkthame]

Regarding the actual issue here of how letter-spacing behaves: An alternative to a new tracking property would be to extend letter-spacing to take two values, which would be the extra space to be added on the left- and right-hand sides (or inline-start and inline-end sides; I'm not sure whether physical or logical is better here) of each typographic unit; so while current implementations of (single-valued) letter-spacing add all the space on one side, the two-valued syntax could be used to add half the desired space on each side, so that centering etc works nicely.

[mruncreative]

@jfkthame
The first two were completely on topic. Can you please not just mark my words as "not to your liking" and thus hidden for everyone who does not have an account?
These are my first three comments for everyone to read:

mruncreative 1 hour ago

I think a much simpler model would be that letter-spacing increases (or decreases) the advance width of all typographic units equally on both sides, so that the glyph remains centered (typically) within its advance. Or in other words, half of the letter-spacing is applied to each of the left and right sidebearings of the glyph.

This is exactly what I proposed further up in the discussion. However it is not necessary because you can simply include the spaces in the tag: word<letter-spacing> word </letter-spacing>word
We don't need special treatment in that regard.
As a German I care more about getting an extra spacing html tag with correct letter spacing see whatwg/html#5709

mruncreative 1 hour ago

Upon further research that also seems to be what typesetters did originally.

mruncreative 1 hour ago

Letter spacing in German usage is basic formatting like underlining. So it's really important to be part of the content and transferable from one document to another and independent of CSS. As well as easily supportable by e-readers or the like.

[fantasai]

@mruncreative Your comments are off-topic because we are not discussing HTML tags here. I have hidden them, so that they do not distract from the on-topic discussion here. If you continue with your off-topic comments I will delete them.

[css-meeting-bot]

The CSS Working Group just discussed [css-text] letter-spacing should not apply to the end edge of a line/span?, and agreed to the following:

• RESOLVED: Change Text L3 to a may for the behavior and transfer switch discussion to Text L4

The full IRC log of that discussion

<dael> Topic: [css-text] letter-spacing should not apply to the end edge of a line/span?

<dael> github: https://github.com/w3c/csswg-drafts/issues/1518

<dael> koji: css 2 specs says letter spacing is added between characters

<dael> koji: No impl does it. Blink and webkit adds to right of character

<dael> koji: Gecko adds to inline end of character in resolved direction

<dael> koji: Commonly asked question on web when they want to center or right align or when they want to put borders on underlines

<dael> koji: For alignment if we use negative amrgins, lots of hacks

<dael> koji: Prop solve this by a switch on the property

<dael> 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

<Rossen_> q?

<dbaron> I think we'd like to switch to doing it right eventually; doing it just hasn't been a priority.

<dael> florian: If you want to use letter-spacing for purpose of letter-spacing what is spec is good. It has been used for other cases, though. b/c of that we're to some degree locked into behavior

<dael> florian: In earlier discussion fantasai suggested we define some bits and look at switch for next level. I think koji wanted entire undefined.

<chrishtr> q+

<dael> 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

<dael> koji: L4 it looks like not consensus. I think we should add the switch and fantasai doesn't want

<dael> koji: fantasai any reason you don't want switch?

<dael> 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

<dael> florian: All agree some aspects can't work nice way. Not clear all aspects must stay as impl. Maybe some could switch to better w/o breaking

<Rossen_> ack chrishtr

<dael> 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.

<dael> 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.

<AmeliaBR> letter-spacing: 0.1em trim

<dael> chrishtr: More practicle 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

<dael> 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

<dael> fantasai: I don't think usage says 50% of websites will break.

<Rossen_> ack dbaron

<koji> q+

<dael> dbaron: 2 things. Gecko behavior is substantially different from Chrome. We occasionally get an issue from a dev but I don't remember use facing breakage for this

<dael> dbaron: That makes me think there may be room to do w/o compat problems

<dael> dbaron: Other is since letter-spacing is old it may be n reset stylesheets. Interesting how many are something other thanl letter-spacing normal or 0

<dael> 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.

<Rossen_> ack koji

<dael> koji: to dbaron 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.

<dael> koji: It is a feature people want to fix and people waiting at least 18 years. Want to solve

<dael> koji: 18 are asking for remove the spacing at last

<dael> chrishtr: No spacing at end of span

<Rossen_> ack fantasai

<dael> fantasai: We're proposing fix this and not a switch. Concern from Chrome is web compat and not shippable

<dael> koji: Yeah

<dael> chrishtr: And prove no impact is a lot of work we'd rather not do b/c skeptical will succeed

<myles> q+

<dael> fantasai: Gecko is willing to ship. If they ship in nightly and decide not issue would Chrome ship?

<dael> chrishtr: With evidence of web compat yet

<dael> koji: Concern 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

<florian> q+

<Rossen_> ack myles

<dael> myles: In our new layout engine we have impl this. Just haven't turned on new engine by default. In middle of progress here

<dael> Rossen_: Make sure I understand you believe this will be web compat and just make the change?

<dael> 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

<dael> koji: Timeframe?

<dael> myles: Apple does not comment on future products or releases

<Rossen_> ack florian

<dael> florian: Questions to WK and Mozilla. If we spec undefined for now would that slow itnerest in experimenting?

<chrishtr> q+

<dael> florian: I'm very interested in 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?

<dael> dbaron: I think it should be findable from spec if you want it impl

<dael> fantasai: What if left current defintion as a may and say you may do something else? It's not undefined but it's a may

<dael> dbaron: That's findable from spec

<dael> chrishtr: I don't see down side of having another option. Make it undefined witht he 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

<Rossen_> ack chrishtr

<dael> 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

<dael> chrishtr: Want to solve for webdev now not in a year. IT's a small change, that big of a deal?

<dael> florian: Too many problems with legacy and normal

<dael> fantasai: If we add things now that we only need temp it has to be maintained forever and webdev have to carry knowledge. Makse sense to wait 6 months to get it right

<dael> chrishtr: Don't believe it's a significant burden for developers. This is a small thing

<Rossen_> ack fantasai

<dael> chrishtr: To makes ure 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

<dael> florian: Depending on nuances in that phrase, yes

<dael> 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

<dael> 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

<dael> koji: Not legacy. fantasai conformed we will need it for the middle. We will need a switch. Correct fantasai?

<dael> 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 for non-compat. If you want spacing on both sides you can add padding.

<Rossen_> q?

<dael> 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

<dael> koji: You're saying it should change to padding?

<myles> q+

<faceless2> can you have a switch to enable compat mode, but with a prefix?

<Rossen_> q+

<dael> fantasai: I think it should be with margin and maybe add a better facility for manual kerning that solves the problem better.

<dael> florian: Margin is better even w'o something for kerning

<dael> koji: What to do with existing cases?

<dael> fantasai: We might be stuck with this being one sided. But then switch would not effect end edge but at least end of element. I just think that interest in forward momentum from 2 impl to fix it. I think we should see if that works

<Rossen_> ack myles

<dael> myles: That's what I was going to say. 2 impl in process of impl. If I understand from chrishtr you don't have evidence it's not web compat. Given that it seems a natural way forward. A comprimise of adding both as a may is okay with us

<Rossen_> ack Rossen

<dael> 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.

<dael> Rossen_: Point of order, 12 minutes to the end.

<dael> 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. have general principle against. 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?

<dael> Rossen_: So are we talking abotu a run time switch or experimental switch and not a css property so you can flight and test overall impact?

<fantasai> s/have general/We have a genera/

<fantasai> s/genera/general/

<dael> Rossen_: In order words when you impl this switch aren't you going to arrive at desired impl anyway and couldn't that be behind a field trial switch?

<dael> chrishtr: Could but something would need to be done after to analyze if turning on switch breaks sites

<dael> Rossen_: But when you impl you add desired behavior at which point you have great data which is you impl it by default and whenw e flighted this a bunch broke and in order to address pain of dev we will release with a switch

<dael> chrishtr: I think prop is impl the change behind and experiment flag,a ttempt to ship, and if anyone complains turn it off

<dael> Rossen_: Yes

<dael> chrishtr: Have in past with things we think will work.

<dael> chrishtr: When we dont' have evidence it is likely to be not a problem we don't want to do that. It's a PTIA for sites to have to deal with it

<dael> chrishtr: Only in cases where we have evidence it's not a problem would we be willing to do that

<Rossen_> q?

<fantasai> authors > implementers

<dael> chrishtr: Or if the situation at hand is very severe. Sometimes with security we might do something like that bc 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. I think imp switch is trivial

<dael> 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 differnt on centering it's not

<fantasai> S/I think imp switch/That would be a lot of analysis, whereas a property switch/

<dael> Rossen_: To finish the question. From 3 values in proposed swithc, auto between and right, is between the one we aspire to have?

<dael> chrishtr: yes

<dael> Rossen_: We would have said just impl between if we started today?

<dael> chrishtr: Yes, jsut think auto and between

<dael> Rossen_: So you said switch is simple so impl between is simple.

<dael> Rossen_: Great. So back to my question if impl between is simple why can't we flight and test compat jsut like FF 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

<dael> chrishtr: b/c doing so forces the change and makes sites file bugs or do detial analysis of existing sites

<dael> myles: Third choice is wait for FF and webkit and see what they have to say

<dael> koji: fantasai said we don't need right only once every site has switched to use padding for kerning

<Rossen_> q?

<dael> chrishtr: Is Moz planning to ship in next release?

<dael> fantasai: Talked to Jonathan and plans are for soon. Next release or two.

<dael> Rossen_: So that's 6-12 week time frame roughly

<fantasai> s/two/two should be possible/

<dael> fantasai: I would like to wrap this up and say we resolve to allow both for text L3. You may do the thing spec 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.

<dael> chrishtr: Seems clear won't resolve on switch in this meeting so agree we should wrap up. What about comments for German letter spacing?

<dael> fantasai: I think not relevent for this discussion.

<dael> chrishtr: Fork to new issue as well?

<dael> fantasai: German uses spacing for emphasis and that's not in scope for this. THat's an HTML issue

<dael> astearns: Issue for us is if spacing features we give are adiquite for German

<fantasai> s/that/the commenter wants a tag for that, and that/

<fantasai> s/for this/for CSS/

<dael> AmeliaBR: What's the standard for German and can it be represented in CSS

<dael> Rossen_: We're just about done. fantasai had a proposed closing for this

<dael> Rossen_: Objections to that?

<AmeliaBR> s/the standard/the standard typographic behavior/

<dael> florian: I think resolve on that. It's not last work but we'll stop banning the behavior

<dael> Rossen_: Objections to Change Text L3 to a may for the behavior and transfer switch discussion to Text L4

<dael> RESOLVED: Change Text L3 to a may for the behavior and transfer switch discussion to Text L4