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-inline-3] initial-letters-wrap: first, whitespace collapse needs defining #5120

Closed
faceless2 opened this issue May 27, 2020 · 11 comments
Closed

Comments

@faceless2
Copy link

See https://drafts.csswg.org/css-inline-3/#example-8c68c539

<style>
p::first-letter {
    initial-letters: 3 3;
    initial-letters-wrap: first;
}
</style>
<p>A bout of illness...</p>

In the example shown above, the visual effect is that the "b" of "bout" is left aligned to the right edge of the initial-letters box. The whitespace preceding "bout" is discarded.

This appears to be by design (@dauwhe can perhaps confirm one way or another). But what is the mechanism for this whitespace collapse? Does it collapse when white-space: pre? Do we collapse just one space, or many? Is it all characters of class Zs?

I am leaning towards collapse all Zs, all the time in this case. I could imagine white-space other than normal might be used for poetry layout, for example, but even then it seems likely the word following the initial letter has to be aligned with the box. If more control is desired, authors have shape-margin.

@faceless2 faceless2 added the css-inline-3 Current Work label May 27, 2020
@fantasai
Copy link
Collaborator

Generally we only collapse collapsible white space, so I imagine that's what we'd do here as well. Is there a use case for collapsing other Zs ?

@fantasai
Copy link
Collaborator

@faceless2
Copy link
Author

To me it looks like the whitespace isn't exactly collapsing here - it's represented by the space between the initial letter and the rest of the box. At least, that's my understanding of the intention - I don't have a concrete use case.

But yes, I suppose it is probably simplest if it's treated as if it were white-space at the start of a line, and then follow the normal rules for collapsing at this point. I still think this needs stating explicitly, as according to the box model it's collapsing zero or more whitespace between two inlines to nothing, which wouldn't normally happen.

@fantasai
Copy link
Collaborator

@faceless2 Agreed it needs to be specified explicitly. (And it's collapsing because it's not there; spaces represented by a line break are also considered to be collapsed. ;)

@dauwhe
Copy link
Contributor

dauwhe commented Jun 2, 2020

This appears to be by design (@dauwhe can perhaps confirm one way or another).

Yes, by design.

Isn't this something of an issue for all initial-letters? WebKit seems to ignore any white space between the initial letter and subsequent text. Could this be a general rule? All I'm saying with initial-letter-wrap: first is that if there is whitespace between the initial letter and subsequent text, don't wrap that first line.

@faceless2
Copy link
Author

Ha. Yes, I suppose it is an issue for all initial-letters. This is the only example from the spec where the first letter is followed by a space, which is probably why it didn't occur to me.

So same conclusion I guess, but applied to a broader subject: we collapse white-space following the initial letter as if it were at the start of the line.

@fantasai
Copy link
Collaborator

So... here's a question. What about a raised initial? Don't we need to preserve white space when the sink is 1?

@dauwhe
Copy link
Contributor

dauwhe commented Jun 12, 2020

So... here's a question. What about a raised initial? Don't we need to preserve white space when the sink is 1?

Yes.

I also wonder about justified text on a line with an initial letter. Even if it's a pure raised cap, if the initial letter is a standalone, the space after it should probably be available for justification.

@fantasai
Copy link
Collaborator

@dauwhe OK, so the proposed behavior is: “if sink > 1, collapse away any white space”?

@css-meeting-bot
Copy link
Member

The CSS Working Group just discussed [css-inline-3] initial-letters-wrap: first, whitespace collapse needs defining.

The full IRC log of that discussion <dael> Topic: [css-inline-3] initial-letters-wrap: first, whitespace collapse needs defining
<fantasai> github: https://github.com//issues/5120
<dael> fantasai: Appears that current suggestion is drop-caps should have whitespace between them and first line but raised-caps should not
<dael> fantasai: Question is do we make edits to make that happen
<fantasai> s/drop-caps/raised-caps/
<fantasai> s/raised-caps should not/drop-caps shouldnot/
<dael> Rossen_: Edits to make that happen in text? Or where?
<dael> fantasai: Changes to initial-letters spec. If you have a raised initial than whatever whitepsace collapsing which would take effect should happen. word, raised-initial letter should have all spaces
<tantek> yeah with dropcaps that space after the initial letter would look like an errant text-indent
<dael> fantasai: drop-caps if you have that behavior it would be weird so we should collapse the white-space.
<dael> fantasai: dauwhe do you want to explain more?
<dbaron> This seems related to 'initial-letter-wrap: first'.
<tantek> I did find an example for this one in print lol (a whole word drop-cap)
<dbaron> There's an example at https://drafts.csswg.org/css-inline-3/#valdef-initial-letter-wrap-first
<dael> dauwhe: It's a weird case. When the initial-letter is a word. Other in English it's an A or an I that starts a sentence. We need to retain the space so reader is not confused. Some examples in spec I think. Sunk drop-cap gives you space automatically. Rasied-cap you don't so need to retain the space
<dael> dauwhe: What fantasai proposes seems reasonable
<dael> tantek: Prop the space when it's drop-cap?
<dael> fantasai: Discard space when drop-cap. Keep with raised-cap
<dael> tantek: Yeah. That's what I'm seeing in print
<dael> tantek: Print examples conform to that
<dael> dbaron: Reasonable but makes me wonder if initial-letter-wrap should default to first instead of none
<dael> fantasai: Does that b/c people didn't want to impl first
<dael> Rossen_: We're overtime and people are dropping
<fantasai> (so we couldn't make it the default)
<dael> Rossen_: Ready to resolve or table?
<dael> Rossen_: We're losing people. Let's not resolve now and take this first next week

@astearns astearns added this to the VF2F-2020-07-28 Slot B milestone Jul 27, 2020
@css-meeting-bot
Copy link
Member

The CSS Working Group just discussed white-space and initial-letter, and agreed to the following:

  • RESOLVED: preserve whitespace for sink 1, collapse otherwise
The full IRC log of that discussion <fantasai> Topic: white-space and initial-letter
<fantasai> github: https://github.com//issues/5120
<emilio> fantasai: So when you have a raised cap you need that space to appear in the first line
<emilio> fantasai: otherwise it's confusing whether the cap is part of the word
<emilio> fantasai: but for drop caps you need the space to disappear
<emilio> fantasai: so that lines are even
<emilio> fantasai: so the proposal is that if the sink is greater than one we collapse, but we don't otherwise
<emilio> faceless2: 0 is a valid sink, so we presumably collapse there?
<emilio> astearns: so we avoid collapsing only for 1 and collapse elsewhere?
<emilio> fantasai: yeah
<emilio> florian: what does a sink of 0 do?
<emilio> astearns: presumably the letter appears on its own line
<emilio> fantasai: I'd like to reopen that because I don't think it behaves like people want
<emilio> fantasai: and we have props for that stuff in L4
<emilio> florian: clarification, just regular whitespace class/
<emilio> *?
<emilio> fantasai: yeah
<fantasai> s/for that stuff/to create the necessary breaks/
<emilio> RESOLVED: preserve whitespace for sink 1, collapse otherwise
<florian> s/regular whitespace class/regular U+0020 whitespace?/
<fantasai> Topic; Drop hebrew alignment from initial-letter-align

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants