- From: Dael Jackson <daelcss@gmail.com>
- Date: Fri, 1 Sep 2017 08:50:01 -0400
- To: www-style@w3.org
========================================= These are the official CSSWG minutes. Unless you're correcting the minutes, Please respond by starting a new thread with an appropriate subject line. ========================================= CSS Text 3 ---------- - The group agreed that what is in the spec for letter-spacing is right, but that there hasn't been any move to implement, partially based on a concern over breakage. There were three options to get over this barrier: 1) Someone implements & ships 2) Someone does a web crawl to get actual statistics of usage 3) Everyone ships at once - Myles is going to investigate implementing this part of the spec to see if it works without breakage and fantasai will write test cases. - RESOLVED: No change (on applying line-spacing on a bidi-mixed string), Blink/Gecko require bugfixes. https://github.com/w3c/csswg-drafts/issues/1517 - RESOLVED: bidi reordering that would split an inline given infinite space will always create separate fragments even if the two fragments end up adjacent due to line breaking Note: Behavior for letter-spacing (and other things affected, like box-decoration-break), falls out of this definition: in this case, if the two letters end up adjacent but are part of different fragments, the spacing between them will be given by the parent (according to the letter-spacing rules that control letter-spacing at element boundaries). This avoids the measuring problem. - RESOLVED: Rename line-break:break-all to line-break:anywhere. - RESOLVED: After edits from this meeting, publish new WD of Text 3. text-spacing fullwidth punctuation collapsing --------------------------------------------- - RESOLVED: Accept change matching JLReq's punctuation spacing, put a note into the spec about maybe needing more complex stuff, follow up with JLReq about the topic. (Issue #1668) Orthogonal Flow Constraint: viewport vs scroller ------------------------------------------------ - RESOLVED: Add "size of nearest fixed scrollport" to the list of things you clamp orthogonal flow inline sizes to, editing the CR. (Issue #1391) ===== FULL MINUTES BELOW ====== Agenda: https://wiki.csswg.org/planning/paris-2017#topics Scribe: TabAtkins CSS Text ======== letter-spacing -------------- github: https://github.com/w3c/csswg-drafts/issues/1518 koji: Text 3 letter-spacing specifies that the letter-spacing after the last character of an element should be eliminated. koji: Concern that, while this is better, it may not be web compatible. koji: Our team prefers it be opt-in, so existing pages still work but authors can choose the better model. koji: It looks like Sebastian and François agrees. fantasai: I know it's different, I wanna know if it actually causes a problem. fantasai: Adding extra switches is extra cognitive load on the author; it would be better to just do the right thing. koji: We have a bug requesting this feature for years. koji: He wants to stop using negative margin to cancel the space. koji: If we change things, his pages' compensation will instead ram the characters together. fantasai: Right, question is how many people will have that problem, vs how many will be *fixed* by the change. fantasai: If you have a large amount of letter-spacing to cancel, so large negative margin, and there's text after, that's a problem. fantasai: But if it's a small letter-spacing, it'll have less than ideal spacing but still *okay*--and lots of other pages will have improved letter spacing. koji: I think it's a little self-contradicting - people that want this feature care about it, and people who care can apply negative margin today. myles: I don't think that's necessarily true TabAtkins: I've never realized I needed to deal with this case myles: There's a difference between caring about letter-spacing, caring and noticing there's a problem, and caring, noticing, and trying to fix it with this hack. 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. fantasai: I'm not hesitant, I think we should try it. fremy: letter-spacing is used everywhere on the web, so even if a tiny fraction care enough to use the hack, it'll still be a lot of web pages. 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. myles: glyph-spacing is bad name. fremy: Sure, anything works. myles: I think making two solutions, one broken and one working, isn't great. We should investigate fixing the one. fantasai: Someone has to ship it then. myles: Or crawl for it. myles: Look for letter-spacing and negative-margin on the same element. Florian: Hard to tell automatically if it's bad. fantasai: Have to investigate the *inherited* letter-spacing value, and if negative margin on the element. fantasai: That's the pages that are trying to work around it. fantasai: But there's also millions of pages that aren't trying to fix it, and will look better when we change it. fantasai: So it's a balance of how much bad it is. fantasai: Slightly worse appearance, or readability is affected. fantasai: So you have to actually look at the page. <fantasai> If it's mostly just slightly worse appearance, we're winning: there are many many more pages that aren't trying to compensate. bdc: Huge letterspacing is bad design by default, while negative letterspacing is often used for proper kerning. 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. fantasai: If you apply letter-spacing to whole paragraph, no impact, since you won't run into this edge case. dbaron: This isn't the first time it's brought up - maybe web compat, don't know, a little afraid of it. dbaron: If it is web-compatible we should stick to the current design. dbaron: If we wanna conclude it's not, we need more evidence than brought so far that it's not. dbaron: Until we have evidence that it's not, we should stop trying to discuss it every six months. <astearns> +1 to dbaron <myles> I think dbaron made the point I was trying to make, but much more elegantly than I did 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", ... fremy: I'm concerned it'll be a lot of webpages, but I'm not sure how to figure it out. 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) <tantek> (illustrative real world examples, not artificial data URls etc.) koji: I'm not clear on the next actions. koji: I think someone has to do a collection and figure out whether it's problematic or not? myles: Someone somewhere has to prove that an impl that follows the spec is not web-compatible. TabAtkins: WG likes the current spec, and puts burden of proof on implementations to prove that it's not Web-compatible TabAtkins: Need to evaluate pages where they have negative right margin that matches to the letter-spacing TabAtkins: And then see if they are actually broken. koji: So who will do this? myles: Whoever wants to change the spec. koji: Spec has been there for five years so far... fantasai: Yeah, nobody has stepped forward to implement this. fantasai: We want a spec and impls that match. fantasai: So first option is somebody impls and ships and sees what trouble they have. fantasai: Second is somebody does a crawl and checks the stats. fantasai: Broken vs slightly suboptimal; we don't care about latter, because we'll fix a bunch more pages. fantasai: Third is we do what we did with control characters, where we all ship at same time. Florian: Option 1 where things just ship, there are release channels for early info... bdc: I don't see how the crawl is possible really - the margin might be a little different than the spacing, they might have negative spacing and positive margin... fantasai: positive margin is fine; it doesn't cause overlapping that hurts readability, just puts in a larger gap. bdc: So I'm in favor of just keeping the spec as it is. fantasai: So in favor of moving forward, do impls have a pref on which strategy to use? koji: To me this is a nice feature, but not worth spending a week doing a crawl. koji: So I'd much rather have another property that does opt-in and see the usage. fantasai: That won't give us useful information. fantasai: Majority of people aren't paying attention to this, or aren't caring enough to do anything about it. myles: I think, going along with fantasai, you can track the # of times you encounter a website that uses it, but that's only useful as a fraction, and you don't know the denominator. 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. fantasai: [repeats three options] fantasai: And I think the WG is generally agreeing that changing the spec isn't a valid fourth option. Bert: Gradual change; reduce it by half this year, then quarter next year, eventually it's nothing. :) Rossen: So I don't think we did very good with the third option. Rossen: Anyone want to do option #1? [crickets] Rossen: Anyone wants to crawl? [crickets] Rossen: So we're at same position as before. fantasai: Question on #1 - we had zero interest in impl and shipping it. fantasai: But if someone was to give you a patch, you just had to ship it, then what? myles: I'm happy to investigate it, I want to make this work. I'll impl and see if it doesn't work. Rossen: Sounds good. <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. ACTION Myles to investigate changing letter-spacing impl to match spec regarding spacing at start/end of element. <trackbot> Created ACTION-857 ACTION: fantasai to write test cases <trackbot> Created ACTION-858 <br dur=15min> letter-spacing and word-spacing applied to which side ----------------------------------------------------- github topic: https://github.com/w3c/csswg-drafts/issues/1517 koji: Problem from user perspective is that when letter-spacing is applied to a bidi-mixed string, Blink and Gecko has sometimes do l-s, sometimes double l-s, it's hard to predict. koji: WK and Edge add even letter-spacing. koji: It's not specced in CSS2, CSS3 defines quite different algorithm that solves this problem. koji: But it requires some complex impl. fantasai: CSS3 just says letter-spacing is applied after bidi reordering. myles: If we end up shipping what we resolved in the last topic, I think that'll mean that the Blink behavior of switching which direction you add l-s to, you won't need anymore myles: because then letter-spacing isn't on "left" or "right", it's on "inside". fantasai: 2.1 defines it as "between characters" - double or nothing is just wrong. <fantasai> https://www.w3.org/TR/CSS21/text.html#spacing-props <fantasai> CSS2.1 defines letter-spacing as "between" characters fantasai: CSS3 is more precise "between adjacent typographic characters, after bidi reordering". No ambiguity. <fantasai> https://drafts.csswg.org/css-text-3/#letter-spacing-property myles: So what's the proposal, making it legal to have double/ nothing? koji: Proposal is to match WK/Edge. myles: Oh, okay, great. myles: So that's what the spec already says, right? koji: If spec says between chars, this might be an impl issue. koji: Most impls apply it to the left or right of characters. koji: Edge and WK apply it to the line-right direction, so always "to the right" regardless of direction. fantasai: And if we apply the previous topic's resolution, the user can't tell whether it's line-left/right. koji: Blink/Gecko apply it to end edge of resolved bidi direction. Florian: Can't you detect it with backgrounds? fantasai: No, l-s doesn't occur at a boundary; the l-s at a boundary is determined by the element containing both of them. dbaron: I think the current spec is solid, just a decent bit of work to implement. astearns: So reading of issue is just that Blink/Gecko need to change behavior to match spec? koji: Yes. RESOLVED: No change, Blink/Gecko require bugfixes. Applying letter-spacing after line breaking ------------------------------------------- github topic: https://github.com/w3c/csswg-drafts/issues/1509 koji: As fantasai just mentioned, difference between CSS2 and CSS3 is that 3 says apply l-s after bidi-reorder. <fantasai> CSS2.1 implied after bidi-reorder. L3 specifies explicitly to avoid confusion. koji: But bidi-reorder applies after line-breaking, koji: Which can change the number of "between" spaces there is to add letter-spacing. koji: So after we add letter-spacing, the line width can change, shorter or longer. koji: So I think this is a worse issue than what it's trying to solve. fantasai: You have to include the letter-spacing when figuring out spacing and line-breaking. fantasai: This is same as kerning. koji: We don't redo kerning after bidi. koji: Because changing line widths after break is really bad. fantasai: Yeah, def don't want to change line-width afterwards, that's bad. fantasai: So that means you have to consider letter-spacing before breaking the line. fantasai: But since bidi-reordering happens after breaking the line, you won't know where the letter-spacing goes until after doing the reordering. myles: Do you have an example of this breaking? koji: [looks it up] koji: Last bit of example 16 in Text. koji: There's a 2em spacing between the characters in the span, but reordering separates the letters. myles: I understand now. fantasai: If you have that example, bidi-reordering puts two letters next to each other that weren't next to each other logically, do you perform shaping and kerning between them? myles: Ours won't cross bidi boundaries. koji: We're trying to do better at shaping across element boundaries, but only in logical sequences, before bidi reordering. koji: I believe we're trying to match Gecko's behavior. fantasai: Yeah, difficult; we're splitting up letters in an element, so where does the letter-spacing go? fantasai: Per spec, you don't put the letter spacing between letters of the element and letters outside the element. fantasai: So I see you point that it's hard to measure correctly. koji: If we follow Edge/WK impl and resolve the previous l-s topic, there should be 2em space on the right of C. TabAtkins: line-right edge - in logical order, it separates the letter from the next logical letter. fantasai: Example: you have a para with 1em letter spacing. Inside you have a span with 0 l-s. Between the last letter of the span and first letter outside the span, there's 1em letter spacing, where does that attach? Example: <p>f_o_o_<span>bar</span>_f_o_o</p> fantasai: Another span with borders and padding. You do linebreaking calcs. fantasai: Then you cut the line and do bidi reordering, but it has b-d-b: clone. Now you have two pieces with padding around them, where before you had only one. Now what? koji: I was reading b-d-b for the first time this morning, and thought of that exact problem. dbaron: Okay, at bidi *resolution* time, the element would split into two separate fragments, and thus both get borders. koji: But you don't know how linebreaking will happen yet. TabAtkins: If there's only enough room for 4 letters, so the "c" and the aleph are next to each other, is that still two independent spans? dbaron: We don't unclone them - they stay separate fragments. <dbaron> http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cstyle%3E%0Aspan%20%7B%20border%3A%20medium%20solid%20blue%3B%20background%3A%20aqua%3B%20%7D%0A%3C%2Fstyle%3E%0A%3Cp%3Eab%3Cspan%3Ec%D7%90%3C%2Fspan%3E%D7%91%D7%92%3C%2Fp%3E%0A%3Cp%3Eab%3Cspan%20style%3D%22box-decoration-break%3Aclone%22%3Ec%D7%90%3C%2Fspan%3E%D7%91%D7%92%3C%2Fp%3E%0A%3Cp%3Eab%3Cspan%20style%3D%22box-decoration-break%3Aclone%22%3Ec%D7%90%3C%2Fspan%3E%3Cbr%3E%D7%91%D7%92%3C%2Fp%3E <dbaron> http://software.hixie.ch/utilities/js/live-dom-viewer/saved/5292 dbaron: That might not be an intentional decision; they might have thought about it as normal linebreaking and this behavior just falls out. fantasai: I think it's okay to allow impls to do that. TabAtkins: So the c and aleph would still be considered separate fragments, even though they are adjacent TabAtkins: and the letter-spacing between them would be controlled by the parent. fantasai: I like this solution. TabAtkins: Wouldn't be too complicated, and would give sensible results in most cases and sensible-enough results in the rest. TabAtkins: During bidi resolution, you split them into separate fragments, and behavior falls out from that. koji: So we'll lose the letter spacing between bidi runs. TabAtkins: If the bidi runs are in the same element, yes - they'll use the parent's letter-spacing. <fantasai> Proposed that bidi resolution would result in splitting an inline in infinite space will always create two fragments, even if they end up adjacent due to line breaking. RESOLVED: bidi reordering that would split an inline given infinite space will always create separate fragments even if the two fragments end up adjacent due to line breaking line-break: break-all --------------------- github topic: https://github.com/w3c/csswg-drafts/issues/1561 Florian: line-break:break-all isn't a great name. Should we find a better name? Florian: I think all names are bad, but I can't come up with a good one. Florian: This value allows line-breaks everywhere. Florian: word-break:break-all allows for breaks between letters, but not between punctuations, spaces, etc. Florian: line-break is terminal wrapping, word-break is just hyphens-wherever-you-want Florian: Trying to do better ignoring web constraints is hard, trying to do better *with* web compat is near impossible. Florian: line-break:break-all is the newest one, with best chance of renaming. Florian: Unfortunately it's got the best name, I think. koji: I don't mean it's badly named, just that same keyword on similar property doing differently is confusing. koji: Particularly if we have a shorthand for both of these. fantasai: shorthands can do custom syntax; we'll definitely redesign the whole thing if we do a shorthand fantasai: Shorthand would be *great*, we can make it all make sense koji: I understand it's possible, but if we're naming now, why choose "break-all"? fantasai: We didn't have a better one. koji: Line-break:terminal? Florian: how about line-break: anywhere? Rossen: anywhere? Rossen: any? Rossen: all? TabAtkins: That would force a break between every character [a few people like anywhere] Rossen: anyone care? [several other ppl care] TabAtkins: I think re-using the keyword is bad Rossen: So from the people paying attention, any objections to renaming break-all to anywhere? dbaron: How widely implemented? fantasai: Nowhere, it's new, we added it this year. RESOLVED: Rename line-break:break-all to line-break:anywhere. Florian: I have a PR for this change; other than me changing this keyword, can the editors approve it or tell me what's wrong? fantasai: Yeah, at lunch. RESOLVED: After edits from this meeting, publish new WD of Text 3. text-spacing fullwidth punctuation collapsing --------------------------------------------- github topic: https://github.com/w3c/csswg-drafts/issues/1668 Florian: In CJK, full-width punctuation takes a full-width box, but they visually fill half to fit Florian: Japanese expects that when they're next to each other ( like two close-parens), there will not be a big space, they'll be collapsed visually. Florian: The font contains space, but it needs to be canceled out in some cases. Florian: We have a rule in Text 4 that says when to do this. Florian: One rule is overcomplicated. We did it wrong because JLReq wasn't specific enough. Florian: Case is where you have a closing punct followed by an opening one: `)(`. Florian: If you did nothing it's 2em long, we want 1.5em long. Florian: Closing, half-space, opening. fantasai: Collapse away the adjacent half space. Florian: We specced that each is .75em long. Florian: Proper is to keep all space on closing one, remove all space from opening. Florian: Difference is barely observable, we should match. fantasai: Did the people working on those things consider the case of different-sized fonts? fantasai: Second paren is half the size of the first one, then what should happen? Florian: That's where it becomes observable. fantasai: I think probably 75% on each side isn't the right answer, so we should change it, but also not convinced we should always use the first. Florian: Unsure. Murakami says to do it the other way, and InDesign does it the other way, so we should match. fantasai: One thing we often do is look at print examples, and find where they're not handling cases. fantasai: I think we should choose one or the other; we could use innermost or outermost... Florian: They're same level. fantasai: Always use bigger one? myles: That'll cause space to change when font-size animates? TabAtkins: It'll do that no matter what. Florian: I think we should match publishers, with a note about if someone has cases not considered, let us know. fantasai: Korean mixes font sizes a lot; rather than ruby they just reduce font-size for such annotations Florian: But they use Latin punctuation, not full-width, so this doesn't apply. myles: I think it makes the most sense to do what everyone else does as a first pass. fantasai: Happy with that if we follow up with JLReq to make sure they think about this case. Rossen: Are you current JLReq liaison? Florian: Not yet, I have something later about that. koji: I think previous spec is ambiguous, just says "put a half space between them". Rossen: So can we resolve to accept change, put a note in, and follow up with JLReq? RESOLVED: Accept change matching JLReq's punctuation spacing, put a note into the spec about maybe needing more complex stuff, follow up with JLReq about the topic. Renaming the dynamic and static profiles of selectors ===================================================== <Rossen> https://lists.w3.org/Archives/Public/www-style/2017Jul/0039.html <fantasai> https://www.w3.org/TR/selectors4/#profiles Rossen: Mail sent last Saturday. TabAtkins: So I've seen enough feedback by now that I agree that "static/dynamic" is confusing. Dynamic makes people think of JS. Let's talk about it over lunch and come back? Orthogonal Flow Constraint: viewport vs scroller ================================================ github topic: https://github.com/w3c/csswg-drafts/issues/1391 fantasai: We resolved to use the nearest scrollport height for orthogonal flow fallback height. fantasai: But that can be auto. ICB is always fixed; we want this to be fixed as well. <dbaron> Should it be the nearest scrollport that's non-auto height? <astearns> nearest scrollable definite-height ancestor? <astearns> dang, dbaron beat me to it Rossen: When I was working on this, the logic I added was to keep looking for the nearest ancestor that imposes a fixed height or scroller, and if scroller is height:auto I think I keep going up. Rossen: You can go figure out the viewport size, but that doesn't buy you much. fantasai: I think you want it to be a size you can calc without doing layout. Rossen: Which is doable if you find a fixed ancestor. fantasai: If you look for fixed size and subtract intervening mbp, you run into problems we saw before with stretch, where you get so much accumulated mbp you're zero size. fantasai: Also, our goal if you're doing autosize is to not make it larger than what you can see in one screenful; goal is to fit a line of text they can comfortably read. Nearest fixed container might be larger than the viewport. Rossen: But then you'd have that problem with other things. TabAtkins: The other things are intended to scroll vertically. fantasai: It's very important that a line length is less than the size of the viewport, so you don't scroll back and forth. fantasai: So nearest fixed container might violate that. fantasai: This is why we used viewport instead of some random number. TabAtkins: If it's as big or smaller than the viewport, then even if it's not perfectly nice, the user can scroll it into place and be able to read comfortably fremy: You're preventing people from using transforms. They might want large initial size, then scale it down. You'd prevent that. TabAtkins: For transforms all bets are off. TabAtkins: We could clamp to smaller of the scrollport and the viewport. Rossen: Using smaller of fixed-height ancestor or viewport sounds okay. fantasai: If your parent is fixed size, we already clamp by that. fantasai: But when we don't have a fixed size, we don't want to look up thru multiple layers of auto and find a size bigger than auto. Proposal: orthogonal flow fallback height is min(100vh, nearest fixed-size scrollport ancestor's height), no caring about mbp or anything. * dbaron notes that this proposed resolution needs to be logicalized + logical swap for other ordering. + available size of immediate container, which normally controls size <fantasai> min(100vh, nearest fixed-size scrollport, available size) fantasai: Looking at spec, you choose smaller of "containing block size" and "ICB size", and the issue/discussion was about replacing ICB size. <fantasai> current CR is min(100vh, available size), previous resolution was min(available size, nearest scrollport) TabAtkins: So just adding one more bullet to that list, for nearest fixed scrollport. RESOLVED: Add "size of nearest fixed scrollport" to the list of things you clamp orthogonal flow inline sizes to, editing the CR. <br type=lunch dur=1hr>
Received on Friday, 1 September 2017 12:50:56 UTC