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

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?

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

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

Blink bug is here FYI crbug.com/267056.

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

@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. [css-text] letter-spacing and word-spacing applied to which side? #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 [css-text] letter-spacing and word-spacing applied to which side? #1517?

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

@FremyCompany @litherum thoughts?

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.

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?

and I'm also interested in hearing what other impls think. @litherum @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:

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.

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.

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

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.

2. [css-text] letter-spacing and word-spacing applied to which side? #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 [css-text] letter-spacing and word-spacing applied to which side? #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

@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?

@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:

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

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

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

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 #1509 & #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.

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

@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?

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

Closing as no change per #1518 (comment)

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.

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

Another 3-years past, It there any progress for it whether on level 3 or 4?