Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
kojiishi opened this issue Jun 9, 2017 · 68 comments
Open
Labels
css-text-4 i18n-tracker Group bringing to attention of Internationalization, or tracked by i18n but not needing response. Needs Review of Test Case(s) Tracked in DoC

Comments

@kojiishi
Copy link
Contributor

kojiishi commented Jun 9, 2017

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

@kojiishi kojiishi added the css-text-3 Current Work label Jun 9, 2017
@kojiishi kojiishi changed the title [css-text] letter-spacing should not apply to the end edge of a line? [css-text] letter-spacing should not apply to the end edge of a line/span? Jun 9, 2017
@dbaron
Copy link
Member

dbaron commented Jun 9, 2017

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

@kojiishi
Copy link
Contributor Author

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
Copy link
Contributor

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
Copy link
Contributor Author

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
Copy link
Contributor Author

Blink bug is here FYI crbug.com/267056.

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

@kojiishi
Copy link
Contributor Author

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

@fantasai
Copy link
Collaborator

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
Copy link
Contributor Author

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
Copy link
Contributor Author

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

@FremyCompany
Copy link
Contributor

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:

image

@kojiishi
Copy link
Contributor Author

kojiishi commented Jun 24, 2017

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
Copy link

aaaxx commented Jun 24, 2017

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
Copy link
Contributor

@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
Copy link
Contributor

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

@kojiishi
Copy link
Contributor Author

@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
Copy link
Contributor Author

kojiishi commented Jun 26, 2017

@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
Copy link
Contributor

@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
Copy link
Member

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//issues/1518
<TabAtkins> koji: Concern that, while this is better, it may not be web compatible.
<Rossen> github topic: https://github.com//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
Copy link
Member

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

@jonjohnjohnson
Copy link

jonjohnjohnson commented Mar 8, 2018

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.

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

@kojiishi
Copy link
Contributor Author

kojiishi commented Mar 9, 2018

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

@fantasai
Copy link
Collaborator

fantasai commented Mar 24, 2018

@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
Copy link

jonjohnjohnson commented Mar 24, 2018

@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
Copy link
Collaborator

Closing as no change per #1518 (comment)

@jfkthame

This comment has been minimized.

@mruncreative

This comment has been minimized.

@mruncreative

This comment has been minimized.

@mruncreative

This comment has been minimized.

@mruncreative

This comment has been minimized.

@mruncreative

This comment has been minimized.

@jfkthame

This comment has been minimized.

@jfkthame
Copy link
Contributor

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

This comment has been minimized.

@fantasai

This comment has been minimized.

@css-meeting-bot
Copy link
Member

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

@woody-li
Copy link

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
css-text-4 i18n-tracker Group bringing to attention of Internationalization, or tracked by i18n but not needing response. Needs Review of Test Case(s) Tracked in DoC
Projects
None yet
Development

No branches or pull requests