- From: Dael Jackson <daelcss@gmail.com>
- Date: Thu, 16 May 2019 18:56:22 -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 Overflow ------------ - heycam gave an update about the work to specify -webkit-line-clamp. There are a few differences being introduced intentionally such as skipping newer formatting contexts (such as flexbox) and having any independent formatting context child get skipped over. - iank will try fixing Blink to use the block-end edge of the line box (per spec, consistent with normal sizing rules) rather than the block-end edge of the lowest item (current -webkit- behavior). CSS Multicol ------------ - RESOLVED: Clarify the spec using the notion that this is an out of flow that leaves a forced break behind (Issue #1072: How do elements between column-span and its multicol ancestor appear around the span) - RESOLVED: Update the spec to return to the behavior as implemented in Blink/WebKit/Edge that `column-fill: auto` balances an unconstrained container, and does not balance a constrained container (Issue #3224: Improve column-fill and make it backward-compatible) - RESOLVED: Include min and max as constraints [in the above resolution] (Issue #3224: Improve column-fill and make it backward-compatible) CSS Fonts --------- - RESOLVED: Use ascii-case folding (Issue #3675: Font-family name matching requires full Unicode case comparison) CSS Lists --------- - There were three proposals to solve Issue #3686 (Initial value of counter-increment needs to be something different from none) which will be discussed in the issue: (A) fantasai's proposal: if an element has display: list-item, then the list-item counter is incremented unless the counter-increment property contains a reference to the list-item counter. (Authors can override this effect with counter-increment: list-item 0.) (B) dbaron's proposal: if an element has display: list-item, then the list-item counter is incremented. (Authors can override this effect with counter-increment: list-item -1, unless the list is reversed, in which case it would be by 1.) (C) Fremy's proposal: if an element has display: list-item, then the list-item counter is incremented unless the counter-reset, counter-set, or counter-increment property contains a reference to the list-item counter. CSS Grid -------- - RESOLVED: When calculating content based base sizes of spanning items, if extra space needs to be distributed past the growth limit, and there is a range available in another column, put it in there (Issue #3648: Distribute extra space into non-intrinsic tracks instead of going beyond growth limits) CSS Text & Sizing ----------------- - RESOLVED: Preserved spaces from pre-wrap hang when they occur before a soft wrap, but would not hang when at the end of block or forced break (Issue #3440: When to/not to include preserved trailing spaces) ===== FULL MINUTES BELOW ====== Agenda: https://wiki.csswg.org/planning/sf-2019 Scribe: iank CSS Overflow ============ Convert -webkit-line-clamp alias requirement into a spec issue -------------------------------------------------------------- github: https://github.com/w3c/csswg-drafts/issues/2847 heycam: Talked about -webkit-line-clamp, wanted to give an update, last couple weeks looking at implementing, and looking at what the actual behavior inside blink/webkit heycam: At high level, in the spec we talk about it as a fragmentation, once you reach Nth line, subsequent lines fragment, and lines disappear. heycam: In blink/WK the effect is only influencing its size. Like a max-block-size constraint, element is reflowed, where is position of last line? This affects intrinsic block-size heycam: As in blink/WK you'll end up with an element w/ this size, however the remaining lines will appear as overflow. heycam: These differences aren't insignificant, I've written patch for what blink/WK have done. Wanted to do this in a reasonable time. TabAtkins: The existing -webkit-line-clamp impls are bad and horrible. heycam: Apart from the difference with fragmenting or not, elements on subsequent lines will actually show, however this probably isn't a webcompat constraint. heycam: -webkit-line-clamp only works on -webkit-box, orientation: vertical. Some risk that if we don't respect that it may appear on elements that wasn't expected to have that treated. <fantasai> The differences are largely intentional https://medium.com/mofed/css-line-clamp-the-good-the-bad-and-the-straight-up-broken-865413f16e5 <fantasai> Main concern is really interaction with -webkit-box TabAtkins: iank did some looking. iank: I did some analysis by adding a bunch of usecounters in our -webkit-box implementation to answer questions like how many w/ single block-flow child, vs. multiple. iank: This allowed us to kill percentage -webkit-line-clamp heycam: yaya <dholbert> https://www.chromestatus.com/features/5393405823680512 seems to be the query for percentage values of webkit-line-clamp <astearns> https://www.chromestatus.com/metrics/feature/timeline/popularity/2139 heycam: One other difference between spec and impl, any independent formatting context child gets skipped over, that means a BFC, overflow: scroll, display: flex etc, I think that makes sense, is nice simple model, however it is a difference. heycam: Where this difference has more of an effect, as it only works on a "box-item" that establishes a independent formatting context. heycam: If respected that rule, we'd never be able to apply that line-clamp. Needs to be an exception around this. fantasai: A couple of options: an exception for -webkit-line-clamp stuff, e.g. inherit the line clamp behavior into the flex-item, or automatically apply. heycam: I think that's a sensible thing to do. florian: Most differences are intentional florian: We probably need to do at the syntax level, where you specifically that you need -webkit-box, etc, to apply the prefixed version. florian: We should do these tweaks, need to confess to ulterior motive, I think feature is good on its own, the way that we spec'd it is good. But it's also the first step helps us solves a bigger problem. florian: This solution is a subset which we need to get to overflow: fragments. florian: I think this is a good things. florian: Wouldn't want to clean the hacks so much that we lose the nice version. heycam: What is in the spec at the moment is good, I'll probably only implement the -webkit-line-clamp for compat reasons, but want to try and get to the standards based version. heycam: The aim for the fragmentation based solution is good. heycam: I don't think making the prefixed -webkit-line-clamp property an alias of the standards-based thing is possible. florian: I think there is an issue in the spec, about this. heycam: Can I ask people if skipping over new formatting contexts is a good thing? fantasai: I think that its not clear for many new formatting contexts (like flex) where it applies. fantasai: e.g. horizontal flexbox or table, what do you clamp? each item in the row, first item only... heycam: I agree. florian: I would to keep a vertical -webkit-box w/ single item is simpler, if isn't sufficient for web compat, and need to handle multiple items, then if we need to handle that, yup can add to spec. heycam: Can I also ask if people are against the size calculation the current implementations have. florian: Would rather not spec, until we need them. iank: We might need them. heycam: I've written a bunch of tests to determine what is happening. scribe: emilio heycam: One final difference, is the exact position, in standards version it is the block-end edge of the line-box, in implementations its actually block-end edge of the items within that linebox. fantasai: The line-box can be taller. florian: It makes the line shorter, because the line can be taller due to line-height TabAtkins: Is that what auto-sizing does? (somebody): no TabAtkins: Then that's bad heycam: I agree that line-box block-end edge makes more sense iank: I actually got a request a couple days ago about our behavior being bad, and it's a one-liner, so I may just try to change it iank: To do the same as auto-height TabAtkins: Cool iank: WebKit's behavior is also bad, and it's probably the same one-liner heycam: Another difference is that the flex item is inflexible if you have line-clamp on the flex container heycam: I suspect this is not a problem in practice since authors are not using this feature for flexbox sizing anyway heycam: I think this is all we wanted to get out of this heycam: I'll change the patch to use the line-box block-end edge as iank is going to do in Blink and land the weirdo behavior <iank> Use counters, see https://www.chromestatus.com/metrics/feature/popularity and WebkitBox* counters. <TabAtkins> I propose "boxflex item" and "boxflex container" as words to refer to the old stuff. fantasai: For the flex special-case, the simpler thing is that if you have an anonymous flex item, you inherit line-clamp from the parent heycam: Current patch makes it apply to both anon and non-anon flex containers heycam: May be more complicated emilio: No, just inherit from ::-moz-anonymous-* thing heycam: Ah, ok, maybe not florian: If we specify that -webkit-line-clamp only applies to display: -webkit-box, we need to define what that is iank: Some of it is in the compat spec florian: Should we pull that in? florian: Can we rely on the compat spec to do that? dholbert: Yeah, it's not exactly the WebKit implementation but has been good enough <xfq> https://compat.spec.whatwg.org/#css-keyword-mappings florian: ok, there's no w3c spec that depends on the compat spec, so may be an issue fantasai: Isn't it a whatwg spec? we can refer to that florian: We can pull from compat spec as well (everyone): Let's not discuss that now heycam: Is the idea to do that when we have the non-webkit version as well? heycam: Or does it makes sense to do it already? florian: I think we should spec everything we're moderately sure we won't be able to rip off dholbert: We can move -webkit-line-clamp to the compat spec too florian: The way I see it is that things that we need to define precisely how they work should get on the proper spec florian: You could see the compat spec as an incubation thing for these things TabAtkins: The ideal is that things in compat should effectively migrate out into real spec <florian> this is also why it is hard to have normative refs to the compat spec. Not because it's in whatwg (that's fine), but because it a fast and loose spec that's not terribly precise or stable CSS Multicol ============ multicol descendant ancestors of a column-span ---------------------------------------------- github: https://github.com/w3c/csswg-drafts/issues/1072#issuecomment-465362932 rachelandrew: It's a reopened issue that was resolved on but dbaron reopened requesting some clarification rachelandrew: The example is figure 21 in the spec rachelandrew: The initial thing was mentioned was essentially a clarification. The situation is when margins paddings and borders are split by the spanner, but an empty fragment ends up before the spanner <fantasai> I think this just needs to adopt the same wording as CSS2.1 block-in-inline splits dbaron: A bunch of the clarifications was just to say what happens for elements that are both descendants of the multicol and ancestors of the spanner when they're split by the spanner dbaron: A more interesting question is what happens when there's an explicit height and how's it distributed fantasai: Simplest is to treat the split as creating a fragmentation break, but computes padding borders as if the spanner didn't exist dbaron: I think everyone pretty much agreed with the outcomes even if there's disagreement on how to describe them florian: There are a couple related aspects florian: <section><div><aside column-span: all> split element florian: We thought it could be described like the spanner being out-of-flow florian: but forces a fragmentation break florian: so that it doesn't influence min-content and such florian: The div is not affected by the span itself florian: I think it's easier to define the span this way rachelandrew: I think it's one of the cleanest way to describe it rachelandrew: and easier to understand fantasai: I think out of flow stuff in CSS is taken out of the flow, the rest of the stuff is supposed to ignore it. An out-of-flow span in a paragraph doesn't cause a break on the parent emilio: Actually, it leaves behind a break opportunity florian: It's not quite true that out-of-flow don't affect the float -> floats florian: We need to define the specifics, but other than that is out of flow emilio: At least in Gecko, Webkit and Blink, out-of-flows do create break opportunities. I believe it's a bug. Edge does it right. florian: In this case it would be a forced break rather than a break opportunity Rossen: This is the model we use in Edge. We treat it as out-of-flow and force a break Rossen: This is the exact model we use for spanners in edge AmeliaBR: It is probably worth referencing it as being similar to a flow wrt. Background painting order and co? rachelandrew: Yeah I think I should write some spec text RESOLVED: Clarify the spec using the notion that this is an out of flow that leaves a forced break behind Improve column-fill and make it backward-compatible --------------------------------------------------- github: https://github.com/w3c/csswg-drafts/issues/3224 rachelandrew: Turns out that a commented out sentence in the spec which Blink / WebKit and Edge implement rachelandrew: <reads from issue> rachelandrew: Firefox does not balance, given that text was commented out in 2012 rachelandrew: I put together a couple examples rachelandrew: Proposal is to update the spec to the behavior WebKit / Blink / Edge rachelandrew: Another issue is to include min and max constrains rachelandrew: And whether we should introduce a "never-balance" mode florian: I think we almost concluded last time florian: We should generally follow the behavior of everybody but Firefox, except with the nuance that if it's not min- and max- we never go into the fill mode florian: As for adding a new fill behavior, not opposed but probably level 2 florian: If we didn't include the min- thing I'd be more reluctant to follow Chrome / Edge / webKit rachelandrew: Have looked at Prince and they match FF florian: I think web compat is the dominant thing here florian: 1 and 2 solve the problem sufficiently well that you can do what you want in more cases rachelandrew: Unless people have objections I think that'd be a good resolution emilio: Has FF had compat issues because of that? florian: No, but others have shipped that behavior for a long time florian: and if we put 2 together it's not a bad behavior rachelandrew: Without being able to do the min-size thing it does get annoying, we use server-side stuff to measure content and not get the weird columns florian: Right, without the 2 part I'd prefer FF, but not otherwise RESOLVED: Update the spec to return to the behavior as implemented in Blink/WebKit/Edge that `column-fill: auto` balances an unconstrained container, and does not balance a constrained container RESOLVED: Include min and max as constraints CSS Fonts ========= Font-family name matching requires full Unicode case comparison --------------------------------------------------------------- github: https://github.com/w3c/csswg-drafts/issues/3675 myles: Spec says that in order to match font-family names full unicode case folding needs to be performed myles: so you need to run the names to complicated ICU routines myles: We just fold ascii chars in WebKit, for performance reasons myles: We never perform unicode case folding in WebKit fantasai: When you search on a page? myles: That particular API is a different one, but we do use unicode fantasai: It should use compatibility decomposition and caseless matching myles: ascii case folding is fast myles: I haven't done any measurement but if we used the unicode case comparison it'd likely be a perf regression because font lookups are not myles: Wanted to relax this restriction heycam: Why not require the ascii-case folding? myles: That's fine too heycam: I don't think there's many situations when you have non-ascii names? myles: Fonts have many names in many languages, in addition to an ascii name, generally florian: Isn't common to have a case-mismatched cyrillic name? Is it not a compat issue? myles: It's not myles: Proposed resolution is that font-family lookups should use ascii-case-insensitive matching dbaron: What do other implementations do? myles: Probably matches chrome eae: It does fantasai: I'd like to check with jfkthame emilio: I can check what Firefox does, hang on emilio: We do whatever nsCaseInsensitiveStringComparator does dbaron: That's ascii RESOLVED: Use ascii-case folding CSS Lists ========= Scribe: heycam counter-increment initial value ------------------------------- github: https://github.com/w3c/csswg-drafts/issues/3686 fantasai: So there's a plan to use css counters for lists fantasai: Looks like Gecko is on the process of implementing it <TabAtkins> Today: <ol><li>one<li style="display:block">two<li> three</ol> results in "1. one\ntwo\n2. three" fantasai: They're blocked on an issue about the initial value of counter-increment fantasai: Basically by default we need to increment list-item emilio: The issue is not that we need it to implement this behavior, but we need it to allow the author to say counter-increment:none on a list dbaron: And does that style go on the list item or the marker pseudo? emilio: The list item florian: This is not just for markup lists, because if it was we can do it in the UA sheet, but it's also when you create list items through the display property emilio: The computed value of counter-increment needs to depend on display emilio: It's not a huge issue emilio: We have this kind of relationship for fonts and other properties emilio: The issue is that the author specified value gets lost TabAtkins: Sure dbaron: So auto would mean list item 1 if your display is list-item, and none for anything else? emilio: Yes emilio: and the computed value wouldn't include "auto" emilio: Otherwise you get into trouble with gCS, checking it against none or something fremy: What if on a list item currently you do counter-set: my-list-item 5 TabAtkins: counter-set or counter-increment? emilio: If you set counter-increment to something else you will lose the auto increment emilio: Edge does something like this AmeliaBR: You have a todo list, and you're keeping your own track of how many items in the list are completed or not, don't want to muck up the existing list counters fantasai: We discussed something similar to this ~12 years ago fantasai: From what I recall, the conclusion we ended up with was that the magic counter would be implied no matter what the value of the counter property was fantasai: if you want to override that implied behavior, you could call it out explicitly fantasai: 'none' would not turn off increments for list-item fantasai: Neither would 'foo 0' fantasai: but 'list-item 0' would <fremy> +1 emilio: ok emilio: Then we don't need this, but we should change the spec to say that the only way you can reset list-item is this way TabAtkins: Happy with that, then the spec doesn't have to disagree with implementations as much Rossen: The issue about the initial value of counter-increment Rossen: being something different from none emilio: One annoying thing is that counter-increment is the only weirdo property that depends on display emilio: you can explain counter-set for <li value=foo> using attribute mapping emilio: If you define that to be magical and non-overridable, then it becomes more complicated to implement fantasai: You run into the same issue if people are using counters already and are clobbered emilio: For li items inside an ol with the value attribute emilio: I'm fine restricting this solution to counter-increment emilio: or maybe counter-reset too? TabAtkins: We already need magic for these things because of reversed AmeliaBR: It sounds like in addition to having the list-item is always auto incremented unless explicitly told, we also need a way to say increment if displayed versus always increment emilio: That is the magic that counter-increment needs for list-item emilio: We don't need that magic for counter-set or counter-reset for lists dbaron: There's one other thing that makes me uncomfortable, but leads to an alternative dbaron: Right now if you say counter-increment: foo 1, foo 1; you increment the counter by 2 fantasai: There's no comma dbaron: Saying that if you say list-item at all anywhere then it overrides the implicit "list-item 1" feels weird to me dbaron: Another way to do it is that display:list-item implicitly have a "list-item 1" in there. But you can add "list-item -1" in there to undo that effect [general groans] emilio: So you say display: list-item has a magic list-item 1 increment emilio: and you can specify another one to cancel it dbaron: You say list-item -1 fantasai: One of authors' goals is to expose counters to do interesting things with them fantasai: I think this makes it very confusing AmeliaBR: If you hide a list item then the next one would jump down a number fantasai: I would rather it be an override dbaron: I don't understand the hiding thing dbaron: It feels inconsistent that counter:foo 1 doesn't change it, but if you put list-item into that list that the other one disappears fremy: If you do a set and don't do the increment, it's wrong? fremy: If you have <li value=4> you don't increment fremy: it sets to that value dbaron: How you implement <li value> is another question <AmeliaBR> if you have `counter-increment: list-item -1`, that wouldn't have the magical dependence on display. So now hidden elements would reduce your overall counter, wouldn't they? emilio: The way the spec defines it is mapping the attribute to counter-set property emilio: and then to counter-increment: none too dbaron: If we change it this way, we have to change the mapping of the value attribute to counter-increment: list-item 0 dbaron: to explicitly suppress the incrementing dbaron: and then if the author sets some other counter, it would break their value attribute dbaron: If the UA sheet for <li value=5> counter-set: list-item 5; counter-increment: list-item 0; then the author sets counter-increment explicitly dbaron: It would lose the 'list-item 0' counteraction * TabAtkins did not realize that "counter-increment: foo 1 foo 1;" was equivalent to "counter-increment: foo 2;"... fremy: Does anybody use the value attribute? AmeliaBR: Yes, commonly with pages of lists AmeliaBR: Has anyone thought for the issue of having the list-item counter depend on display, is that something we're ok with exposing to user counters as well? emilio: No AmeliaBR: Definitely a no? AmeliaBR: That only list-item has that? TabAtkins: We do have the case that counters only increment on things that generate boxes TabAtkins: but that's different from what list-item wants to do, which is depend on display:list-item explicitly AmeliaBR: So regular counters turn off with display:none, but the list-item counter turns off for anything other than display:list-item TabAtkins: Yes emilio: So there are 2 proposals emilio: One is that list-item is magically appended to counter-increment for list items fantasai: Unconditionally fantasai: that's dbaron's proposal fantasai: The alternative, the earlier discussed one, is that it's only added if the list-item counter is not mentioned in the explicit list fantasai: so the author doesn't have to think about what the UA is doing fremy: I was thinking about dbaron's issue -- there is a way of extending this fremy: You could stop the magical behavior if list-item appears explicitly in any of the counter properties fremy: Then you can map value="" into counter-set without worrying about counter-increment being clobbered by the author fantasai: I don't think you want to do that fantasai: Having property interactions like this makes it more difficult to implement fantasai: We want authors to be able to manipulate the list-item counter in a straightforward manner fantasai: Looking at other properties is more confusing fantasai: The author wants to set the counter to something, or change the increment, or both -- but if mentioning list-item in one changes how the other behaves, that's confusing fremy: <li value="5"> maps to counter-set: list-item 5; and the counter-increment won't use the implied list-item because it appears in counter-set fantasai: Why wouldn't you have this behavior for other counters? fantasai: If it's useful we can do it for other counters <dbaron> "Inheriting counters must be done before resetting counters, which must be done before setting counters, which must be done before incrementing counters, which must be done before using counters (for example, in the content property)." emilio: Resets are applied before increments dbaron: Reset, then sets, then increments emilio: So the increment will always be applied unless you suppress it fremy: Either you set the list-item value, and not do the automatic increment emilio: If you do what dbaron says, you could map the li value to counter-set, then counter-increment: list-item -1 fantasai: If we're cringing at this proposal in here, there will be a lot more cringing out in the world <fremy> so counter-increment has "listitem 1" implied except if you "counter-set: listitem 5" or "counter-increment: listitem 0" TabAtkins: I suggest figuring out the technical issues in the GH issue itself dbaron: I think I'm OK with Elika's proposal dbaron: Mine has the disadvantage [...] AmeliaBR: I am voting for fremy's proposal Rossen: It sounds like the leading one for a resolution would be fantasai's dbaron: I will write the 3 alternatives in the issue emilio: We could look at the code to understand the weirdness and report back CSS Grid ======== Extra space into non-intrinsic tracks instead exceeding growth limits --------------------------------------------------------------------- github: https://github.com/w3c/csswg-drafts/issues/3648 fantasai: Let's say there are two columns fantasai: one is minmax(0, 100px), the other is minmax(auto, 100px) fantasai: Normally we do a first pass to figure out the base size fantasai: min size of each column fantasai: first is fixed and gets 0 fantasai: The second is roughly the min-content contribution of any items in that column fantasai: Let's suppose that item is 150px fantasai: The max specified here is 100px fantasai: since the first column says I'm 0px, we put all 100 or 150px into the second column fantasai: and blow out the maximum fantasai: in order to fit the content fantasai: But the author did give us some space, first column has a range fantasai: Instead of blowing out the max on the second column, we could take those 50px and put them into the first column fantasai: and it wouldn't violate any of the max constraints on the columns fantasai: We ran this idea by jensimmons and rachelandrew and they both said yeah we'd expect that to happen fantasai: so I'm suggesting adjusting the grid algorithm so that when computing the min size of a spanning item, if you hit the growth limit, and have another that is still below its max, you increase that one TabAtkins: Sounds reasonable rachelandrew: I like this because it is more similar to the flex behavior, which people will expect rachelandrew: Why overflow the column when there is still space there rachelandrew: This could happen when you have a single row grid, and they're using grid for whatever reason, and they'll expect that space to be used iank: What happens if the item is 150px in width? are the columns 50px and 100px? fantasai: Yes jensimmons: Right now they're 0 and 150 but we're proposing they be 50 and 100 Rossen: Any objections? RESOLVED: When calculating content based base sizes of spanning items, if extra space needs to be distributed past the growth limit, and there is a range available in another column, put it in there iank: You'll need to specify which columns take the slack iank: 2 on the left and 2 on the right fantasai: All of them CSS Text & Sizing ================= When to/not to include preserved trailing spaces ------------------------------------------------ github: https://github.com/w3c/csswg-drafts/issues/3440 fantasai: Some discussion back and forth about how to handle preserved whitespace at the end of a line fantasai: Most recent resolution is that it hangs if it doesn't fit in the line box fantasai: koji came back to say that doesn't make sense if you have a paragraph that is white-space:pre-wrap fantasai: since then you will end up not justifying fully with the last visible letter to the edge of the container fantasai: because if that white space happened to fit, it would be within the container, otherwise you wouldn't get a flush edge fantasai: The discussion is now: should we say it's force hang instead? fantasai: Or do something else? florian: koji raised this only in the case of justification? florian: On other alignments browsers were aligned, and you're not trying to change that? koji: For justification including trailing spaces it's clearly wrong koji: For right and center, I'm neutral koji: In those cases I can see both sides of the argument <fantasai> I think this is why actually I made the comment in https://github.com/w3c/csswg-drafts/issues/3440#issuecomment-458783789 florian: I'm trying to understand the use cases better florian: because I'm a little bit confused about whether it's in general OK, or already broken, to try to use pre-wrap on body text, paragraphs florian: If you have source code that is pre, and you want to switch to pre-wrap to avoid overflow, that's fine florian: If you apply pre-wrap to body text, there are some odd things that happens florian: Links in the text are underlined, if your linked phrase have spaces, you'll have a hanging underlined space at the end florian: so it's a bit strange, but I'm not sure florian: Don't know if we should try to support that more, in which case what you say about justification is right florian: or decide we don't really care about this, and not optimize for it florian: Maybe people want to use double space after a period? that also feels into the category of not needing to try to support it florian: So these are kind of at the edge florian: of reasonable use of the properties fantasai: format=flowed plain text email is essentially pre-wrap text florian: but you don't re-justify it florian: If you try to preserve the format of the email, you don't go to justify it, since your alignments made with spaces will be broken by the justification fantasai: As far as trailing spaces underlined go, you can use text-decoration-skip fantasai: I think it's a bit weird for something to hang for some operations but not others fantasai: It might make more sense to say that if there is a soft break after a space, then that space force hangs fantasai: for alignment, justification, everything fantasai: but if there's a hard break, then that space does not hang fantasai: For the use case of pre-wrap on an entire paragraph, you're not going to be end it with a period, a space, then a line break fantasai: but for a line of text that happens to end with a space, then that would work florian: If we do force hang in that situation, what does it do for the max content size? include the size of not? fantasai: Max size is always unwrapped, so you include the spaces florian: What about space at the end of the paragraph? fantasai: Then there's a force break right after it florian: ok fantasai: Let's say you have a word, a space, a word, another space, end of the block fantasai: then you wrap in the middle of that fantasai: so you have word, space, soft-break, word, space, end of block fantasai: If you were to right align that text, the space that is at the end of the block would not hang fantasai: It's at the end of the block fantasai: The space that is wrapped does hang fantasai: When you left align you won't notice fantasai: when you right align or justify you will see the first line's space hang fantasai: Generally you want spaces to disappear when you break the line on them: we can distinguish between these cases from other trailing spaces by whether there's a soft wrap there or not koji: I think that makes sense koji: If other browsers are willing to match, I think we can try to match koji: Is Gecko happy with it? I think xidorn wanted to include trailing spaces koji: for right and center heycam: We can resolve and ping xidorn to get his opinion RESOLVED: Preserved spaces from pre-wrap hang when they occur before a soft wrap, but would not hang when at the end of block or forced break florian: Currently we say that spaces hang when they go beyond the edge of the block, browsers are allowed to discard them florian: We key that off the fact they hang florian: Are we still allowed to drop the last spaces before the forced break, or also not allowed to do that fantasai: Let's discuss that another day -- adjourned --
Received on Thursday, 16 May 2019 22:57:46 UTC