[css-inline] initial-letter should be clearer about how it makes its block taller #719
Assignees
Labels
Comments
|
The CSS Working Group just discussed
The full IRC log of that discussion<fantasai> Topic: spacing above initial letters<eae> fantasai: Spacing above initial letters <fantasai> github: https://github.com//issues/719 <eae> dauwhe: We've been trying to sort our issues around spacing around initial letters. <eae> ...this gets somewhat complicated especially as it can have ascenders and marks extending outside. runs the risk of overlap. Something had to be done. The idea is to define boxes that helps us explain initial letter. <eae> dauwhe: One is visual box which is the bounding box without padidng and borders. <eae> ...you see at the bottom here and initial letter and the acsent mark extends outside. <eae> dauwhe: Initial letters have alignment requirementss <eae> jensimmons: are these diagrams explanations of what we have in the spec or what you are proposing? <eae> fantasai: What's the relationship between the top of intial letter and the top of where it's placed. <eae> fantasai: If you have a paragraph and the second paragraph with an intial letter, has to ensure enough space between the two. We don't want content to overlap. We don't want to add too much space or it'll look bad. <eae> fantasai: Intiial letter spec has a lot around how letter is aligned with other content in the paragraph and talks about how the bottom edge is aligned. Sometimes there is a decender, if there is a second line we don't want the decender to blend into the second line. Open questions around the top. <eae> fantasai: Such as a border or the previous paragraph. Trying to answere the question about how to create space around the top, <eae> dauwhe: We have the spacing box, no padidng and border, same as the visual box. It there is padding and border we have the union, taking the larger of the physical box and the border box, hopefully becauses clearer with some examples. <eae> dauwhe: We have four cases depeneing on padding border on the intial letter itself or the containing box. <eae> florian: This is initial letters 3 <eae> dbaron: Can we not have margin collapsing? <eae> iank_: That bit is pretty magical <eae> florian: Isn't most of the dread around marging collapsing around margin collapsing through, which we're not doing here? Should be fine? <eae> iank_: This introduces what looks like marging collapsing for inlines, which we do not do today <eae> jensimmons: margin collapsing where you remove the ability for authors to remove margins? <eae> dbaron: The container is a block which cna have margin collapsing with many things already <jensimmons> s/remove/use <eae> dauwhe: Case 4a, no border or padding on initial letter or contianing block. <eae> iank_: This is avoiding something earlier in the tree without a border? <eae> iank_: Say the previous box, nested five times in, has a border. Is it shifting down to avoid that border? <eae> florian: This is collapsing the acsender with the margin <eae> iank_: This is participating in margin collapsing? <eae> fantasai: Yes, we're not going to get sensible results if we don't do that. <eae> fantasai: We sent margins on our paragraphs to get enough space between our paragraphs. If there is acsent authors don't want to create more space if it fits within the declared margin. <eae> fantasai: That is not what you typographically want. <eae> florian: In the example currently on the screen you wouldn't be able to tell them apart. <eae> fantasai: If you have sections which don't start on their own page, which happens often, and you're expecting three lines worth of spacing between secitons you want that to always be three lines worth, regardless of ascents on the intial cap. Also want to make sure it doesn't overlap with the previous section if it is taller, so needs to be able to extend the margin. <eae> dbaron: My worry about this is that ir probably more than doubles the engineering complexity of initial letter. Adding margin collapsing, my gut feeling, is at least 2x the engineering cost. <eae> dbaron: it's more stuff, nothing in initial letter was all that complicated, was a relatively simple feature up until now. Margin collapsing is very complicated and performance sensitive. <eae> astearns: Is it possible to have a solution without margin collapsing solving the non-overlap case. <eae> fantasai: Would require you as an author to know the distance between cap-height of glyph and glyph bounding box. Would work but be font specific. <eae> dauwhe: ...and authors would have to do it for each letter <eae> ???: The acsent is sticking out of the box, why is this different from any other case where text is outside it's layout box? <astearns> s/???/myles__ / <eae> fantasai: In this case we potentially have a lot of extra content outisde of the box. Could say that we don't care if we overlap the ink with the previous line. <eae> florian: Latin scrips don't stack up a lot, other writing modes have cases where there is a lot of stacking and potentially more ink overlap <eae> florian: lineheight often reserves space for this, in this case we align with the top of the bounding box so anything that reaches out reaches out far <eae> myles__: My response to fantasis point, by default in css, we overflow and don't clip. <eae> fantasai: By default we try not to have it be unreadable <eae> TabAtkins: Can and should do it as a generic case where you never have acsents running into previous content. Would make initial letter simpler if it wasn't a part of initial letter <eae> fantasai: If we were to do it for text in general we'd take a different approach. <eae> florian: You don't want to do it in a small feature <eae> fantasai: You're more likely to run into problems here, it's a bigger chunk of ink that would overlap than a normal line of text <eae> fantasai: People don't tend to run into this for normal text and writing systems with more stacking tends to have a taller line height. <eae> TabAtkins: Can we settle on a simpler model that pushes it down to avoid ink overlap? <eae> fantasai: In that is likely to be less of a problem, have it overlap, and have authors fix it, rather than introduce extra spacing. <eae> TabAtkins: I like it <eae> astearns: Do we want to raise an issue around dealing with this problem in a generic case? <eae> fantasai: Case of line boxes is a little different. With lines of actual text rhythm is important and the text is smaller. Not convinced that you'd want to have the same solution. <eae> astearns: Is there anything with meaning in this proposal for initial letter? <eae> fantasai: I think it's really a question of how, if the working group objects, it puts a strict constraint in what we can do. <eae> iank_: I think people are going to need implementation experience to see how much work this would be. IF David is saying this will be complex that scares me. <eae> florian: Should we put a note in the spec about that? <eae> florian: Do we specify the behavior as described, overlap with preceding content, and also put in a note explaining the thing dauwhe presented and say "this is what we really want, if you want to implement go ahead" <eae> iank_: The only thing that scares me there is that for some implementation this would be easy, for others hard. <eae> astearns: Clarify in spec what would happen with insufficient margin. <eae> fantasai: We would have to be clear that proposals add but don't change behavior <eae> dbaron: I'd be curious if other implementors have same reaction as I as with regards to margin collapsing complexity. Another example, what if you have a float that is anchored within the block with the initial letter but before the initial letter, how does the collapse of the margin influence the tentative collapse of the float? <fantasai> s/proposals add but don't change behavior/the proposal being considered changes behavior, not just adding a new feature (switch)/ <eae> iank_: In our current layout implementation there is no way we could implement this sanely. In our new one, maybe. I agree, very complex <eae> futhark: If you have an imaginary margin for the initial letter collapsing as if it was a block, if you change the font, you'd reflow and layout the text before we know the margin. <eae> dbaron: In the presence of floats you don't know if the initial letter is at the top of the box as the float might push it lower. A lot of complexity <eae> iank_: Super scary! <eae> astearns: Sounds like we're not willing to make any changes to the current spec <eae> fantasai: We need to agree on some desired behavior. what behavior we're going for. <eae> myles__: My proposal would be to use the layout box of the glyph for the layout behavior and not consider the bounding box <eae> astearns: What I remember you saying, don't move the content down. <eae> fantasai: Would lead to more correct behavior in most cases, much more tangible than the alternative. If we went with the other approach, where acsenders take up space, authors will have to compensate with negative margin per glyph. We'll never be able to go back and fix it. <eae> fremy: If you draw a border around it then everything needs to fit inside of it. <eae> fantasai: inline blocks are layed out differently from inlines. <eae> koji: if the glyph overflows the inline block that doesn't work <eae> fantasai: cap-height is used for sizing and positing of the initial letter. <eae> fantasai: only if cap-height is the alignment used <eae> fantasai: Doesn't dictate the size of the initial letter box, includes ascent <eae> fantasai: Initial letter box by default size to the bounding box. Glyph bounding box would have a lot of extra space around it. <eae> koji: Davids proposal is very simlar to this <eae> fantasai: Does not change how inline boxes background are is painted. Here the background area of that box coinsides with the gklyph bounding box <eae> ???: What is meant to happen when you don't have as many lines of text as the height of the intial letter? <eae> fantasai: Defined in spec, clearing. The intial letter is part of the first line, everything below that is an exclusion area, everything will wrap around it, even if it is the next block. Like how floats work. <myles__> s/???/heycam/ <eae> heycam: The exclusion area also includes the decenders? <eae> fantasai: There isn't anything special about it. It's all below the first line, all exclusion area. <eae> iank_: If you have two paragraphs and they're nested. what happens them? <eae> fantasai: If one of them is a BFC then BFC might get narrower, not sure. <eae> fantasai: The proposal on the table, if border or padding is used then the initial letter must be contained within the paragraph. <eae> astearns: If the initial letters container has no border or padding then the glyph content above the alignment point for initial letter is not considered for layout? <eae> astearns: Objections? <eae> dauwhe: In general, content area includes everything up to acsent, why did you phrase it as you did? <eae> florian: Acsent might be too height for some fonts. <florian> s/florian/fantasai/ <fantasai> s/height/high/ <eae> astearns: Second option, that fantasai was against. If we assume that the author would add enough space to avoid overlap that would require negative margin and by font specific. <eae> fantasai: You could have more slack there, with the negative margin approach it's more strict, different amount of space per character, per font. The negative margin is specific to the font and the glyph, really bad. <eae> astearns: dauwhe are you okay with default to overlap? <eae> dauwhe: I'm totally fine with that, majority of use-cases would not be affected. Would only apply to a minority of content. <eae> astearns: Any other objecitons? <eae> RESOLVED: If the initial letters container has no border or padding then the glyph content above the alignment point for initial letter is not considered for layout. <myles__> ("alignment point" usually means "cap height") <eae> RESOLVED: Note to be added that the default behavior may change in the future. <fantasai> the margin box of the initial letter must be inside the content box of its container <eae> RESOLVED: The margin box of the initial letter must be inside the content box of its container. <eae> astearns: Any other initial letter topics? <eae> fantasai: Going back to dbarons initial question. Be clear about whether it is created space between the top of the first line and the container. Whether the line box itself is increased or if a different kind of height is added? <fantasai> dbaron points out it is detectable by how vertical-align: top behavies: if the item is aligned to the top of the first line or to the top of the raised cap <astearns> RESOLVED: Add an example that shows default overlap <fantasai> I think in Sydney we decided the top of the first line minus the raised cap, so suggest we resolve on that <fantasai> proposed resolution: initial letter does not increase the height of the line box <eae> astearns: what mechanism pushes everything down then? <eae> fantasai: The initial letter itself is able to take up space. The initial letter box itself takes up space. <eae> astearns: Does that satisfy your question David? <eae> dbaron: Could you say what you proposed yourself again? <eae> RESOLVED: initial letter does not increase the height of the line box <eae> fantasai: I think that's it for initial letter. We have other inline layout stuff. |
fantasai
added a commit
that referenced
this issue
Jun 13, 2020
1 task
|
Normative edits completed; opened a separate issue to track the request for examples/illustrations. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The section on Raised and Sunken Caps specifies that the initial letter's margin box contributes to the size of the containing block. However, it's not clear on the mechanism that's used for this.
In particular, it should be clear about whether this works by:
It should also presumably be clear that it increases the size of the block only if the margin-box of the initial letter would (based on its alignment) protrude above the top of the first line box.
The difference is detectable, at a minimum, by testing
vertical-align: topelements in the first line.The text was updated successfully, but these errors were encountered: