- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 29 Jul 2020 00:00:53 +0000
- To: public-css-archive@w3.org
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` <details><summary>The full IRC log of that discussion</summary> <dael> Topic: [css-text] letter-spacing should not apply to the end edge of a line/span?<br> <dael> github: https://github.com/w3c/csswg-drafts/issues/1518<br> <dael> koji: css 2 specs says letter spacing is added between characters<br> <dael> koji: No impl does it. Blink and webkit adds to right of character<br> <dael> koji: Gecko adds to inline end of character in resolved direction<br> <dael> koji: Commonly asked question on web when they want to center or right align or when they want to put borders on underlines<br> <dael> koji: For alignment if we use negative amrgins, lots of hacks<br> <dael> koji: Prop solve this by a switch on the property<br> <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<br> <Rossen_> q?<br> <dbaron> I think we'd like to switch to doing it right eventually; doing it just hasn't been a priority.<br> <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<br> <dael> florian: In earlier discussion fantasai suggested we define some bits and look at switch for next level. I think koji wanted entire undefined.<br> <chrishtr> q+<br> <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<br> <dael> koji: L4 it looks like not consensus. I think we should add the switch and fantasai doesn't want<br> <dael> koji: fantasai any reason you don't want switch?<br> <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<br> <tantek> +1 figure out webcompat constraints<br> <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<br> <Rossen_> ack chrishtr<br> <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.<br> <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.<br> <AmeliaBR> `letter-spacing: 0.1em trim`<br> <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<br> <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<br> <dael> fantasai: I don't think usage says 50% of websites will break.<br> <Rossen_> ack dbaron<br> <koji> q+<br> <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<br> <dael> dbaron: That makes me think there may be room to do w/o compat problems<br> <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<br> <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.<br> <Rossen_> ack koji<br> <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.<br> <dael> koji: It is a feature people want to fix and people waiting at least 18 years. Want to solve<br> <dael> koji: 18 are asking for remove the spacing at last<br> <dael> chrishtr: No spacing at end of span<br> <Rossen_> ack fantasai<br> <dael> fantasai: We're proposing fix this and not a switch. Concern from Chrome is web compat and not shippable<br> <dael> koji: Yeah<br> <dael> chrishtr: And prove no impact is a lot of work we'd rather not do b/c skeptical will succeed<br> <myles> q+<br> <dael> fantasai: Gecko is willing to ship. If they ship in nightly and decide not issue would Chrome ship?<br> <dael> chrishtr: With evidence of web compat yet<br> <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<br> <florian> q+<br> <Rossen_> ack myles<br> <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<br> <dael> Rossen_: Make sure I understand you believe this will be web compat and just make the change?<br> <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<br> <dael> koji: Timeframe?<br> <dael> myles: Apple does not comment on future products or releases<br> <Rossen_> ack florian<br> <dael> florian: Questions to WK and Mozilla. If we spec undefined for now would that slow itnerest in experimenting?<br> <chrishtr> q+<br> <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?<br> <dael> dbaron: I think it should be findable from spec if you want it impl<br> <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<br> <dael> dbaron: That's findable from spec<br> <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<br> <Rossen_> ack chrishtr<br> <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<br> <dael> chrishtr: Want to solve for webdev now not in a year. IT's a small change, that big of a deal?<br> <dael> florian: Too many problems with legacy and normal<br> <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<br> <dael> chrishtr: Don't believe it's a significant burden for developers. This is a small thing<br> <Rossen_> ack fantasai<br> <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<br> <dael> florian: Depending on nuances in that phrase, yes<br> <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<br> <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<br> <dael> koji: Not legacy. fantasai conformed we will need it for the middle. We will need a switch. Correct fantasai?<br> <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.<br> <Rossen_> q?<br> <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<br> <dael> koji: You're saying it should change to padding?<br> <myles> q+<br> <faceless2> can you have a switch to enable compat mode, but with a prefix?<br> <Rossen_> q+<br> <dael> fantasai: I think it should be with margin and maybe add a better facility for manual kerning that solves the problem better.<br> <dael> florian: Margin is better even w'o something for kerning<br> <dael> koji: What to do with existing cases?<br> <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<br> <Rossen_> ack myles<br> <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<br> <Rossen_> ack Rossen<br> <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.<br> <dael> Rossen_: Point of order, 12 minutes to the end.<br> <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?<br> <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?<br> <fantasai> s/have general/We have a genera/<br> <fantasai> s/genera/general/<br> <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?<br> <dael> chrishtr: Could but something would need to be done after to analyze if turning on switch breaks sites<br> <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<br> <dael> chrishtr: I think prop is impl the change behind and experiment flag,a ttempt to ship, and if anyone complains turn it off<br> <dael> Rossen_: Yes<br> <dael> chrishtr: Have in past with things we think will work.<br> <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<br> <dael> chrishtr: Only in cases where we have evidence it's not a problem would we be willing to do that<br> <Rossen_> q?<br> <fantasai> authors > implementers<br> <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<br> <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<br> <fantasai> S/I think imp switch/That would be a lot of analysis, whereas a property switch/<br> <dael> Rossen_: To finish the question. From 3 values in proposed swithc, auto between and right, is between the one we aspire to have?<br> <dael> chrishtr: yes<br> <dael> Rossen_: We would have said just impl between if we started today?<br> <dael> chrishtr: Yes, jsut think auto and between<br> <dael> Rossen_: So you said switch is simple so impl between is simple.<br> <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<br> <dael> chrishtr: b/c doing so forces the change and makes sites file bugs or do detial analysis of existing sites<br> <dael> myles: Third choice is wait for FF and webkit and see what they have to say<br> <dael> koji: fantasai said we don't need right only once every site has switched to use padding for kerning<br> <Rossen_> q?<br> <dael> chrishtr: Is Moz planning to ship in next release?<br> <dael> fantasai: Talked to Jonathan and plans are for soon. Next release or two.<br> <dael> Rossen_: So that's 6-12 week time frame roughly<br> <fantasai> s/two/two should be possible/<br> <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.<br> <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?<br> <dael> fantasai: I think not relevent for this discussion.<br> <dael> chrishtr: Fork to new issue as well?<br> <dael> fantasai: German uses spacing for emphasis and that's not in scope for this. THat's an HTML issue<br> <dael> astearns: Issue for us is if spacing features we give are adiquite for German<br> <fantasai> s/that/the commenter wants a tag for that, and that/<br> <fantasai> s/for this/for CSS/<br> <dael> AmeliaBR: What's the standard for German and can it be represented in CSS<br> <dael> Rossen_: We're just about done. fantasai had a proposed closing for this<br> <dael> Rossen_: Objections to that?<br> <AmeliaBR> s/the standard/the standard typographic behavior/<br> <dael> florian: I think resolve on that. It's not last work but we'll stop banning the behavior<br> <dael> Rossen_: Objections to Change Text L3 to a may for the behavior and transfer switch discussion to Text L4<br> <dael> RESOLVED: Change Text L3 to a may for the behavior and transfer switch discussion to Text L4<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/1518#issuecomment-665354152 using your GitHub account
Received on Wednesday, 29 July 2020 00:00:56 UTC