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][css-sizing] When to/not to include preserved trailing spaces #3440

Open
kojiishi opened this issue Dec 13, 2018 · 36 comments

Comments

@kojiishi
Copy link
Contributor

commented Dec 13, 2018

We found browsers are inconsistent on the topic.

Feature Blink Edge Gecko WebKit
text-align: right / center Include Include Include Not include
text-align: justify Not include Do not justify Do not justify Not include
min-content If !wrap If !wrap Include If !wrap
max-content Include Include Include Include

Can we define these? Are there more cases we should cover?

@kojiishi kojiishi added the css-text-3 label Dec 13, 2018

@upsuper

This comment has been minimized.

Copy link
Member

commented Dec 13, 2018

What do you mean by "Not include" vs. "Ignore justify" in the row of text-align: justify?

Conceptually, min-content should force trailing spaces to wrap if not !wrap, and in that case they should be counted as one space in size. Is that the behavior of "If !wrap" or "Include", or none of the browsers do this?

@kojiishi

This comment has been minimized.

Copy link
Contributor Author

commented Dec 13, 2018

Thank you for asking.

What do you mean by "Not include" vs. "Ignore justify" in the row of text-align: justify?

"Not include" mean to ignore trailing spaces and flush the end of non-space character. "Ignore justify" means justification is not applied.

For min-content, !wrap (i.e., pre) is interoperable, all impls include trailing spaces. When wrap (pre-wrap), the desired behavior is not clear to me. We wrap at spaces, and such trailing spaces are not removed, but 3 impls do not include it when computing min-content.

aarongable pushed a commit to chromium/chromium that referenced this issue Dec 14, 2018

[LayoutNG] Fix 'text-align' applied to 'white-space: pre-wrap'
This patch matches the behavior of 'text-align' applied to
'white-space: pre-wrap' and when the line wraps to the
current engine; do not include for 'justify' but do include
for other values.

Spec is not clear on this regard. An issue filed at:
w3c/csswg-drafts#3440

It turned out that our tests cover the combination of the
properties only when lines do not wrap.

Because NGLineBreaker computes |has_only_trailing_spaces| as
part of the line breaking, the last lines and single lines
don't have such item. The difference caused the bug, but the
lack of tests prevented finding the problem. This patch adds
tests for this case.

Also, computing trailing space is moved to NGLineInfo as we
discovered it is needed in other cases too, with more cases
covered and with unit tests.

Bug: 913995
Change-Id: I49428f2dcf193e2b7a745431f82724308a17d90f
Reviewed-on: https://chromium-review.googlesource.com/c/1374331
Commit-Queue: Koji Ishii <kojii@chromium.org>
Reviewed-by: Emil A Eklund <eae@chromium.org>
Cr-Commit-Position: refs/heads/master@{#616617}
@upsuper

This comment has been minimized.

Copy link
Member

commented Dec 16, 2018

If the trailing spaces are meant to be preserved, flushing the end of non-space character doesn't sound like the right thing to do? I'm not sure...

@fantasai

This comment has been minimized.

Copy link
Collaborator

commented Dec 18, 2018

The spec currently specifies that trailing spaces are hung (like hanging-punctuation) if pre-wrap is specified. This is because UAs don't want to wrap the last word down just because there are spaces following it that overflow the containing block. (Spaces are not allowed to hang for pre; they are measured just like any other characters.)

Per spec, "hanging" the spaces means they are excluded from the line box--they can overflow it, and therefore are ignored when justifying or end-aligning the text, and are not considered in intrinsic sizing.

If a different behavior is wanted, then we'd have to spec something explicitly different.

@fantasai fantasai added the Agenda+ label Dec 18, 2018

@w3c w3c deleted a comment from css-meeting-bot Jan 23, 2019

@fantasai

This comment has been minimized.

Copy link
Collaborator

commented Jan 23, 2019

@kojiishi @upsuper Did you want something different here or should I close the issue with no change?

@kojiishi

This comment has been minimized.

Copy link
Contributor Author

commented Jan 24, 2019

So IIUC it means:

  • For all cases, include if pre but do not include if pre-wrap.
  • For @upsuper question, justification should work if pre-wrap, after eliminating trailing spaces.

?

Looks logical to me, but it means it requires behavior changes to all impls, and we accept spec/impl diverge for a while until changes are done successfully. Sad for me but ok.

@upsuper

This comment has been minimized.

Copy link
Member

commented Jan 28, 2019

I don't have strong opinion either way, since I don't really have any usecase in mind for this.

The general idea explained by @fantasai makes sense to me. I have one question, though. If the trailing spaces are allowed to hang (i.e. not always hang), then I think for text-align (when available width is enough) and max-content, the spaces should be included, and the only case where it should never be included when wrap is min-content.

If that understanding is correct, then WebKit would be wrong on both text-align items, and Blink would be wrong on text-align: justify, and Gecko would be wrong on min-content, but vast majority of impls still match the spec, and the spec has at least two correct impls for each behavior (Edge counts one for all items), which sounds like an encouraging situation.

@kojiishi

This comment has been minimized.

Copy link
Contributor Author

commented Jan 28, 2019

The way I read look different from the way @upsuper read, I think it means there's a room to improve the spec?

Also, IIRC at least some of Blink behaviors (e.g., text-align) are from bugs filed by authors. We will need to review those feedback carefully before making the changes. It'd be greater if spec can solve this issue in a way that developers can follow easier.

@fantasai

This comment has been minimized.

Copy link
Collaborator

commented Jan 30, 2019

@upsuper So, let me see if I get this right.... You're suggesting that trailing spaces should be counted for max-content, but not for min-content. You're also suggesting that spaces should hang according to allow-end rules rather than force-end rules.

This makes sense to me. But did I get that right? :)

@fantasai

This comment has been minimized.

Copy link
Collaborator

commented Jan 30, 2019

Hm, actually, I think that's not right. Space should hang... when there's a force-break after, but not when there's a soft-wrap after. Is that right?

@frivoal

This comment has been minimized.

Copy link
Collaborator

commented Jan 30, 2019

Space should hang... when there's a force-break after, but not when there's a soft-wrap after. Is that right?

where did you get that from?

@upsuper

This comment has been minimized.

Copy link
Member

commented Jan 30, 2019

@upsuper So, let me see if I get this right.... You're suggesting that trailing spaces should be counted for max-content, but not for min-content. You're also suggesting that spaces should hang according to allow-end rules rather than force-end rules.

Yeah, that seems to match my understanding.

@css-meeting-bot

This comment has been minimized.

Copy link
Member

commented Feb 20, 2019

The CSS Working Group just discussed When to/not to include preserved trailing spaces, and agreed to the following:

  • RESOLVED: trailing spaces should be counted for max-content but not min-content
  • RESOLVED: when preserved trailing spaces hang they do it using allow-end rather than force-end
The full IRC log of that discussion <dael> Topic: When to/not to include preserved trailing spaces
<dael> github: https://github.com//issues/3440
<dael> fantasai: This was discussion with koji and xidorn with how trailing spaces handled for intrinisic sizing and alignment. xidorn suggested we consider then when counting for max content. For min content b/c trailing spaces don't create overflow or cause wrapping we shouldn't count them. So longest word, not longest work+space controls content
<dael> fantasai: Other suggestion was to define spaces hang according to allow-end rules. allow-end if it fits in the line it's not hanging. When you do right alignment it won't go outside. If it doesn't fit we allow it to fit on the line and in that case it's hanging
<dael> myles: Changing things about expansion opp. is something the web depends on. Do we have compat?
<dael> florian: We don'thave compat
<dael> myles: Meaning browsers do different things?
<dael> florian: Yes. safari does force-end and others do allow-end for alignment
<dael> myles: I don't think we have any philosophical desire so as long as no web compat problem we're willing to change
<dael> florian: fantasai your last comment in the issue can you clarify? I'm not sure where that's coming from
<dael> fantasai: xidorn confirmed my first comment and not second. I think I was trying to figure out...That question is about handling spaces after a forced break diff then soft break or if they're the same
<nigel> q+ to note https://github.com//issues/1997
<dael> fantasai: I think just treating the same is the plan unless someone thinks different
<dael> florian: I would think treat the same
<dael> fantasai: Obviously they're kind of different when doing [missed] content b/c there is no soft break
<fantasai> s/[missed]/max-content/
<dael> florian: For rest of the question I think in terms of taking into account for max content and not min content I initially thought we would ignore in both. If you think in terms of punctuation this proposal makes more sense. Including in max-content is right idea. For alignment I could go either way
<dael> fantasai: That's what I was thinking. spaces then text then spaces. If we say hang in general and you wrap halfway throught he text you'd see the beginning spaces but not the end. If you right align we end up hanging them
<dael> fantasai: Gonna depend on how they happen to fit. I think proposed behavior is fine
<dael> florian: Makes sense. Good argument
<dael> astearns: nigel had a point but he's having difficulty being heard
<dael> fantasai: If asking about issue #1997 that's about if inline elements interrupt whitespace trimming. whitespace is trimmed when collapsible, but this is when it's not collapsable so it's not really related
<dael> astearns: nigel can you indicate on IRC if that makes sense?
<nigel> okay, I was just referencing that other issue because it seemed relevant
<dael> florian: I am in supprot of proposal. Tests need to be updated but I will do so
<dael> astearns: trailing spaces should be counted for max-content but not min-content
<nigel> and space allocation at the ends of lines is a big deal for e.g. captions.
<dael> astearns: Objections?
<dael> RESOLVED: trailing spaces should be counted for max-content but not min-content
<dbaron> this is all just *preserved* trailing spaces, right?
<dael> astearns: What is next thing to resolve?
<florian> dbaron, yes
<dael> fantasai: when spaces hang they hand using allow-end behavior rather than force-end
<dael> astearns: dbaron has a question on previous and that is correct as far as I understand
<dael> fantasai: Yes.
<nigel> q-
<dael> astearns: Next is when preserved trailing spaces hang they do it using allow-end rather than force-end
<dael> RESOLVED: when preserved trailing spaces hang they do it using allow-end rather than force-end
<dael> fantasai: Think that's all on this issue
@kojiishi

This comment has been minimized.

Copy link
Contributor Author

commented Feb 21, 2019

@fantasai thank you for discussing this. Can I ask one clarification on what allow-end means for justification? I'm not sure if I have a good understanding of what "allow-end" behavior is.

Other suggestion was to define spaces hang according to allow-end rules. allow-end if it fits in the line it's not hanging. When you do right alignment it won't go outside. If it doesn't fit we allow it to fit on the line and in that case it's hanging

There are web pages that use pre-wrap+justify, so I wish to keep the current Blink behavior, but wondering what this means for justify.

@frivoal

This comment has been minimized.

Copy link
Collaborator

commented Feb 21, 2019

I'm not sure if I have a good understanding of what "allow-end" behavior is.

I means that the advance measure of any end-of-line preserved space that would fit the line if text-align was start need to be taken into account and continue to fit within the line with other alignments. those that don't fit the line don't count.
So

   |A_B____  |

gets right aligned as

   |  A_B____|

not

   |      A_B|____

and

   |A_B______|___

gets right aligned as

   |A_B______|___

not

   |      A_B|_________

or

A_B|_________|

For justification specifically, I believe the same logic would apply, so

So

|A_B____  |

would get justified as something like

|A_ B ____|

not

|A   _   B|____

However, currently, it seems to me that browsers just don't justify at all when white-space is pre-wrap, which I believe used to be required by CSS2.1 but no longer is.

@kojiishi

This comment has been minimized.

Copy link
Contributor Author

commented Feb 21, 2019

However, currently, it seems to me that browsers just don't justify at all...

See the table at the original comment, Blink and WebKit does justify. There were bugs filed against us when we included trailing spaces in pre-wrap+justify, because the reporter used pre-wrap+justify for the whole content (probably to make double-spacing at the end of sentence easier.)

Can we special case justify, because including trailing spaces does not look reasonable result if browsers chose to justify pre-wrap?

@frivoal

This comment has been minimized.

Copy link
Collaborator

commented Feb 21, 2019

I'm not opposed, but am a little confused at to what the use case is for using pre-wrap and using justify at the same time, so I don't really know what authors would expect.

@frivoal

This comment has been minimized.

Copy link
Collaborator

commented Feb 21, 2019

probably to make double-spacing at the end of sentence easier

Is that the only use case we know of, or are there others?

@kojiishi

This comment has been minimized.

Copy link
Contributor Author

commented Feb 21, 2019

Hm, how is pre-wrap different from normal? When authors don't need whitespace collapsing, pre-wrap looks reasonable choice for normal documents. For example, this page uses pre-wrap for the all paragraphs. The contenteditable might also want to use pre-wrap too.

BTW, forgot to say thank you for making pictures that are very easy to understand. That helped me a lot to understand what "allow-end" means in this context.

@frivoal

This comment has been minimized.

Copy link
Collaborator

commented Feb 21, 2019

Other than the effect on line-breaks and tabs in the source, pre-wrap will also preserve the (single) space between each word at the end of the line, which normal won't do. That can already be observed if you underline the text. With normal, the end of line space is gone, so it is not underlined, but with pre-wrap it is there, so it is underlined.

This sort of things makes me think that using pre-wrap for long form text is probably not ideal.

pre-wrap on editable areas does make sense, but these are rarely justified, I think?

Anyway, I am not strongly opposed, but the argument that line start and line end should be symetrical, and that we should be consistent with other types of alignments also makes sense to me. Since this is more about an exception to the general rule than disagreement about the general rule, I think we should probably open a new issue.

@frivoal frivoal added the Agenda+ F2F label Feb 25, 2019

fantasai added a commit that referenced this issue Feb 27, 2019

[css-text-3] Count trailing spaces for max-content but not min-conten…
…t, use allow-end rather than force-end hanging rules. #3440 (comment)
@css-meeting-bot

This comment has been minimized.

Copy link
Member

commented Feb 28, 2019

The CSS Working Group just discussed When to/not to include preserved trailing spaces, and agreed to the following:

  • 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
The full IRC log of that discussion <heycam> Topic: When to/not to include preserved trailing spaces
<heycam> github: https://github.com//issues/3440
<heycam> fantasai: some discussion back and forth about how to handle preserved whitespace at the end of a line
<heycam> ... most recent resolution is that it hangs if it doesn't fit in the line box
<heycam> ... koji came back to say that doesn't make sense if you have a paragraph that is white-spcae:pre-wrap
<heycam> ... since then you will end up not justifying fully with the last visible letter to the edge of the container
<heycam> ... because if that white space happened to fit, it would be within the container, otherwise you wouldn't get a flush edge
<heycam> ... the discussion is now: should we say it's force hang instead?
<heycam> ... or do something else?
<heycam> florian: koji raised this only in the case of justification?
<heycam> ... on other alignments browsers were aligned, and you're not trying to change that?
<heycam> koji: for justification including trailing spaces it's clearly wrong
<heycam> ... for right and center, I'm neutral
<heycam> ... in those cases I can see both sides of the argumnet
<heycam> florian: I'm trying to understand the use cases better
<heycam> ... 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
<heycam> ... if you have source code that is pre, and you want to switch to pre-wrap to avoid overflow, that's fine
<heycam> ... if you apply pre-wrap to body text, there are some odd things that happne
<fantasai> I think this is why actually I made the comment in https://github.com//issues/3440#issuecomment-458783789
<heycam> ... links in the text are underlined, if your linked phrase have spaces, you'll have a hanging underlined space at the end
<heycam> ... so it's a bit strange, but I'm not sure
<heycam> ... don't know if we should try to support that more, in which case what you say about justificaiton is right
<heycam> ... or decide we don't really care about this, and not optimize for it
<heycam> ... maybe people want to use double space after a period? that also feels into the category of not needing to try to support it
<heycam> ... so these are kind of at the edge
<heycam> ... of reasonable use of the properties
<heycam> fantasai: format=flowed plain text email is essentially pre-wrap text
<heycam> florian: but you don't rejustify it
<Rossen> q?
<heycam> ... 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
<heycam> fantasai: as far as trailing spaces underlined go, you can use text-decoration-skip
<heycam> ... I think it's a bit weird for something to hang for some operations but not others
<heycam> ... it might make more sense to say that if there is a soft break after a space, then that space force hangs
<heycam> ... for alignment, justification, everything
<heycam> ... but if there's a hard break, then that space does not hang
<heycam> ... for the use case of pre-wrap on an entire para, you're not going ot be ended it with a period, a space, a line break
<heycam> ... but for a line of text that happens to end with a space, then that would work
<heycam> florian: if we do force hang in that situation, what does it do for the max content size? include the size of not?
<heycam> fantasai: max size is always unwrapped, so you include the spaces
<heycam> florian: what about space at the end of the paragraph?
<heycam> fantasai: then there's a force break right after it
<heycam> florian: ok
<heycam> fantasai: let's say you have a word a space a word another space, end of the block
<heycam> ... then you wrap in the middle of that
<heycam> ... so you have word space soft-break word space end of block
<heycam> ... if you were to right align that text, the space that is at the end of the block would not hang
<heycam> ... it's at the end of the bloc
<heycam> ... the space that is wrapped does hang
<heycam> ... when you left align you won't notice
<heycam> ... when you right align or justify you will see the first line's space hang
<heycam> ... generally you want spaces to disappear the end of line -- we can distinguish between these cases by whether there's a soft wrap there or not
<heycam> koji: I think that makes sense
<heycam> ... if other browsers are willing to match, I think we can try to match
<heycam> ... is Gecko happy with it? I think xidorn wanted to include trailing spaces
<heycam> ... for right and center
<heycam> heycam: we can resolve and ping xidorn to get his opinion
<heycam> 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
<heycam> florian: currently we say that spaces hang when they go beyond the edge of the block, browsers are allowed to discard them
<heycam> ... we key that off the fact they hang
<heycam> ... are we still allowed to drop the last spaces before the forced break, or also not allowed to do that
<heycam> fantasai: let's discuss that another day

@astearns astearns removed the Agenda+ F2F label Mar 1, 2019

@upsuper

This comment has been minimized.

Copy link
Member

commented Mar 10, 2019

koji: I think that makes sense
... if other browsers are willing to match, I think we can try to match
... is Gecko happy with it? I think xidorn wanted to include trailing spaces
... for right and center
heycam: we can resolve and ping xidorn to get his opinion

As I mentioned before that I don't have strong opinion either way. I was just trying to figure out the general rule from the discussion before which seems to make sense, and matches majority of implementations. If there are usecases suggest otherwise, I'm fine with that as well.

So it seems the resolution was to have spaces force-end for alignment when it's a soft wrap, but allow-end otherwise? That sounds reasonable to me.

@frivoal

This comment has been minimized.

Copy link
Collaborator

commented Mar 12, 2019

So it seems the resolution was to have spaces force-end for alignment when it's a soft wrap,

Yes

but allow-end otherwise?

I think we were saying not to hang at all in that case.

@upsuper

This comment has been minimized.

Copy link
Member

commented Mar 12, 2019

I think we were saying not to hang at all in that case.

How would you handle cases like

|a____________|_____

then?

@kojiishi

This comment has been minimized.

Copy link
Contributor Author

commented Mar 12, 2019

How would you handle cases like...

I think it's an overflow, not hanging. Maybe a minor terminology problem though.

@frivoal

This comment has been minimized.

Copy link
Collaborator

commented Mar 12, 2019

If you try the same example with something other than spaces, we still overflow to the right even if text-align:right. So either way, it would still render as:

     |a____________|_____

and not

a____|_____________|
@upsuper

This comment has been minimized.

Copy link
Member

commented Mar 16, 2019

Being an overflow means it is supposed to have line wrap but just has no wrap opportunity? Then what about something like

|a__b______|_____

Is this overflow or hanging? If it's overflow, why is wrapping not triggered?

@kojiishi

This comment has been minimized.

Copy link
Contributor Author

commented Mar 18, 2019

Such line should wrap before "b", right? And if the 2nd line is longer than available width, it will overflow.

Maybe we have different mental model and that terminologies are confusing?

frivoal added a commit to frivoal/csswg-drafts that referenced this issue Apr 23, 2019

@frivoal

This comment has been minimized.

Copy link
Collaborator

commented Apr 23, 2019

I've made a pull request to apply this change: #3868

However, while I think force-hanging the end-of-line pre-wrap preserved spaces is a good idea, I am unsure about not doing the same for end-of-line pre-wrap preserved spaces that come before a forced break:

  • I don't understand what the use case is for that distinction
  • it would change where lines wrap compared to today, including causing some previously non wrapping elements to start wrapping. (example: https://jsbin.com/leqanut/edit?html,css,output)
  • Safari, Chrome (and Edge), but not Gecko also ignore all end-of-line pre-wrap preserved spaces (regardless of forced break vs soft wrap) for min-content sizing purposes, while Gecko includes them (also regardless of forced break vs soft wrap). (example: https://jsbin.com/wonefeq/edit?html,css,output)

Are we sure that we don't want simply force-hang for all end-of-line pre-wrap preserved spaces, regardless of being followed by a soft wrap vs forced break?

@frivoal frivoal added the Agenda+ label Apr 23, 2019

@frivoal frivoal self-assigned this Apr 23, 2019

@fantasai

This comment has been minimized.

Copy link
Collaborator

commented May 1, 2019

Well, we definitely don't want to force-hang the preserved spaces before a forced break when calculating the max-content size; otherwise max-content won't leave room for the spaces, and I think we do expect that.

@frivoal

This comment has been minimized.

Copy link
Collaborator

commented May 1, 2019

I agree with including these spaces in max-content calculations, but they shouldn't be included in min-content, or to cause additional wrapping, so I don't think that means they need not to hang. Force-hanging punctuation should also be included in max-content calculations, so the way I'd deal with that is to say that end-of-line spaces (with pre-wrap) always hang, regardless of forced break vs soft wrap, but also clarify the definition of hanging to make sure it does the right thing for max-content.

@fantasai

This comment has been minimized.

Copy link
Collaborator

commented May 1, 2019

I don't think force-hanging punctuation should be included in max-content calculations. Hanging punctuation generally means you expect the padding to provide space for it and don't want extra space to be generated for it.

@css-meeting-bot

This comment has been minimized.

Copy link
Member

commented May 2, 2019

The CSS Working Group just discussed When to/not to include preserved trailing spaces.

The full IRC log of that discussion <dael> Topic: When to/not to include preserved trailing spaces
<dael> github: https://github.com//issues/3440
<dael> florian: Before concluded whitespaces at the end of a line for whitespace pre-wrap force hang.But spaces before forced break wouldn't hang.
<dael> florian: Based on issue fantasai prop in order to make them count to max content, but definition of hanging doesn't say if they count or not.
<dael> florian: THen again spaces before a forced break also shoudln't count to min content
<dael> florian: If you look at interop browsers don't treat spaces before a forced break differently
<dael> florian: I think we shoudls ay they hang regardless of forced or soft wrap, but say they count toward max-content size.
<dael> florian: Also clarify if hanging punct. counts or not. Implied maybe, but hanging on intrinsic size isn't explicit
<dael> fantasai: [reads spec]
<fantasai> https://www.w3.org/TR/css-text-3/#hang
<dael> florian: Doesn't say for intrinsic. For min talked explicitly, but for max it's fuzzy. In punct case...it's saying a bunch of things and you can figure out what they prob mean but it doesn't say it explicitly. Esp. given tests aren't clear there's interop so clarifying is good
<dael> florian: I rpoposed we clarify toward don't count regardless of it's min or max. Space we don't count for min and do for max. I think that matches rough interop
<dael> fantasai: If we include it in max content size but then subsiquently align to the right the max content no longer fits the content. This is why we want to be consistent if it's counter for alignment max content and justification. Need same answer or otherwise weird
<dael> florian: Also quite weird with non-intrinisic size. You've got whitespace at the end of lots of lines. All except last align to the right. That's also weird.
<dael> fantasai: Yeeah. But in other cases you're wrapping. Whitespace at wrap you expect to disappear. Whitespace before a break you didn't have to put it there.
<dael> fantasai: If behavior makes more or less sense dependson if content is wrapping or not. Nice if right/left/center align is consistent and encased in max-content
<dael> fantasai: No great answer here. Having max-content and align have different answers doesn't make sense
<fantasai> s/answers/answers on a single line/
<dael> florian: If koji's test is still accurate everyone includes spaces for max and most but not all include for right align. Webkit and blink don't include for justification so they do that differently then alignment
<dael> florian: Last time around we resolved to align with WK and Blink for justificaiton and apply that to right align so never include the spaces.
<dael> florian: It's weird anyway. I have tests to match previous, I just think it's weird.
<dael> Rossen_: We're overtime
<dael> Rossen_: I don't feel we're ready to resolve.
<dael> florian: I think we forced last time and that's part of problem
<dael> Rossen_: Table discussion back to github. For those interested, continue there and we'llr esume next week
<dael> florian: Please look, what we have is well defined, but I'm not sure it's good.
@frivoal

This comment has been minimized.

Copy link
Collaborator

commented May 2, 2019

Personally, I think that justifying pre-wrap text is weird, and that we should not optimize for that case. If we give up on that, we can go back to hanging only the spaces that overflow, which means:

  • count the preserved spaces for max content
  • don't count the preserved spaces for min content
  • don't ignore the preserved spaces when center/right/justify aligning.
    That does make justification a bit odd, but again, I don't think the use case is strong, and having consistency on the rest seems more useful.

If we do want to solve it for justification as well, a more complete but also more complicated answer could be that we allow-hang (i.e. only hang the spaces that would overflow) the pre-wrap spaces in general, but force-hang (i.e. hang all of them) when justifying. Since justification already has the distinction between the last and non-last lines, text-align: justify would force-hang on all lines but the last, and allow-hang on the last line, while text-align: justify-all would force-hang on all lines.

@kojiishi

This comment has been minimized.

Copy link
Contributor Author

commented May 7, 2019

The different opinions might come from whether to see pre-wrap as 1) a variation of pre that allows wrapping, or as 2) a variation of normal that does not collapse spaces. It looks like you are the former and want to handle preserved spaces in the same way for pre and pre-wrap. I agree the former cases exist, but I think the latter is more common.

@css-meeting-bot

This comment has been minimized.

Copy link
Member

commented May 15, 2019

The CSS Working Group just discussed When to/not to include preserved trailing spaces.

The full IRC log of that discussion <dael> Topic: When to/not to include preserved trailing spaces
<dael> github: https://github.com//issues/3440
<dael> Rossen_: Is koji on?
<dael> fantasai: If koji isn't we should defer. Maybe koji florian and I do a separate call. No clear idea of what we should do.
<dael> Rossen_: No issue with that. If you move the conversation and then we can come back either before F2F or at F2F.
<dael> florian: sgtm

@frivoal frivoal added Agenda+ F2F and removed Agenda+ labels May 15, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.