- From: Dael Jackson <daelcss@gmail.com>
- Date: Mon, 4 Dec 2017 19:29:12 -0500
- 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. ========================================= Values and Units ---------------- - astearns requested review of his calc() clamping tests from implementors: https://github.com/w3c/csswg-drafts/issues/434#issuecomment-341267463 Contains -------- - RESOLVED: Use principal box as the box to which we do paint containment clip. (Issue #1809: https://github.com/w3c/csswg-drafts/issues/1809 ) - Discussed whether style containment should be affecting pagination controls within the element. Tab will clarify what style containment is supposed to accomplish in principle so that this issue can be resolved accordingly. - RESOLVED: Create new counter scopes at style scoping root for style containment. - The suggested way to address issue #1457 (https://github.com/w3c/csswg-drafts/issues/1457 ) would be that 'contain' would apply to neither inline nor ruby. Line Grid --------- - The group reviewed dbaron's proposal to comprehensively address line spacing: https://github.com/dbaron/css-line-spacing/blob/master/explainer.md - The group wanted to make sure that it covered all necessary use cases, but a preliminary pass suggested it would. - No one was ready to completely replace existing spec test with this proposal, but it will be used when attempting to fix the current spec. Line Heights (CSS Inline & CSS2.1) ---------------------------------- - RESOLVED: Take florian's proposed change to definitive line heights: https://github.com/w3c/csswg-drafts/issues/1801#issuecomment-328707794 - RESOLVED: Take florian's proposed change for line-height normal: https://github.com/w3c/csswg-drafts/issues/1802#issuecomment-328704733 - RESOLVED: To define first available font more strictly in the fonts model and leave it undefined in 2.1 (https://github.com/w3c/csswg-drafts/issues/1798 ) - RESOLVED: Change the wording such that 2.1 is saying you should define the content area based on the first available font and only that font. (https://github.com/w3c/csswg-drafts/issues/1804 ) ===== FULL MINUTES BELOW ====== Agenda: https://wiki.csswg.org/planning/tpac-2017#proposed-agenda Scribe: TabAtkins Values and Units ================ Negative calc() clamping ------------------------ github: https://github.com/w3c/csswg-drafts/issues/434 astearns: I wrote some tests, and modified them before I checked them in, and now they're bad tests. astearns: As far as I can tell, we have no interop at all. EVery browser clamps at a different time, depending on whether the animation goes up or down... astearns: So I want impls to check on it. Contains ======== Scribe: fantasai To which box does paint containment clip? ----------------------------------------- github: https://github.com/w3c/csswg-drafts/issues/1809 TabAtkins: Whenever element generates more than one box? TabAtkins: Which box do we clip to? TabAtkins: Suggestion is principal box, that sounds great to me. fantasai: The principal box is the box that contains the content, seems like the right call. florian: List markers? TabAtkins: They get clipped if they're outside markers. fantasai: Just like for 'overflow: hidden'. dbaron: Table captions? fantasai: Table wrapper box is principal RESOLVED: Use principal box. Clarify style containment ------------------------- Github: https://github.com/w3c/csswg-drafts/issues/1872 TabAtkins: Question is, why does style containment restrict break properties? TabAtkins: Reason why I have these things set is I want to ignore a style tree for style computation purposes. TabAtkins: Should be able to completely ignore that subtree. TabAtkins: Break property if allowed to work would violate that. TabAtkins: Break properties propagate up. fantasai: They don't affect computation tho. TabAtkins: But they affect layout further up the tree. fantasai: break-inside doesn't propagate up, only forced breaks do. fantasai: Also sounds pretty bad in terms of fragmentation if you can't honor 'break-before: avoid'. TabAtkins: Avoiding breaks should work, yeah... fantasai: ... florian: Since contain property is ahead of css-content, should put the bookmark-* / string-set prose into the css-content spec. dbaron: I'm trying to understand model of possible optimizations here. dbaron: I don't see anything for which this is relevant dbaron: Still doesn't feel like style containment to me. fantasai: Also if disallowing break-*, then why not margin-*? dbaron: It seems like you're trying to introduce something but not really worked out what. dbaron: Maybe write out what that optimization is to make that clear dbaron: and discuss others. fantasai: Also pretty sure if break-* needs to be disallowed the margin-* collapsing should also... but that sounds more like layout containment. Scoped Counters --------------- github: https://github.com/w3c/csswg-drafts/issues/1887 TabAtkins: If you have a style scoped element, which says counters are scoped to the subtree TabAtkins: does counter-increment create a new counter? TabAtkins: Or does it increment the existing counter from the outside? <fremy> +1 on this one TabAtkins: I think it should implicitly create a new counter scope at the style scoping root. fantasai: And so counters() would reveal a new level of counter? TabAtkins: Yes. TabAtkins: Don't want to fuss with the subtree when calculating counters further down in the document. fantasai: So you're disagreeing with Oriol's comment? TabAtkins: Yes. astearns: Write a test? astearns: So proposed to implicitly create new counter scopes at style scoping root for style containment. RESOLVED: Create new counter scopes at style scoping root for style containment. Becoming a formatting context root ---------------------------------- github: https://github.com/w3c/csswg-drafts/issues/1457 TabAtkins: We addressed this a bit in the past, text we had was bad. TabAtkins: Layout containment needs a formatting context root TabAtkins: wanted to say that the element ends up being an FC root somehow TabAtkins: only a few places where that's difficult. TabAtkins: Some are easy: TabAtkins: flow root, table, flex, grid, all satisfy condition. TabAtkins: For display: flow, becomes flow-root TabAtkins: Next issue is with ruby. TabAtkins: Ruby is effectively inline element. TabAtkins: Wanted to create a ruby inline block flow-root thing. florian: We don't have that yet. If it's not useful, do we really want to add it? TabAtkins: Better to fill the boxes, so this is consistent and defined. fantasai: How about saying layout containment doesn't apply to inlines, ruby or otherwise? If you want it to apply, turn it into an inline block. Xidorn: Create a wrapper box? TabAtkins: Wrapper boxes are scary and bad. fantasai: We have block ruby, it just creates a wrapper. TabAtkins: Make something block-like, either inline-block or block or something. fantasai: For most of these layout modes, the FCR-ification doesn't have much effect. Layout is fundamentally the same fantasai: but for inlines and ruby, it's a very significant change to layout fantasai: I'd rather say that layout containment just doesn't apply here, so the author is making an explicit decision about the layout change they're getting, rather than getting such a significant side-effect from a “performance tweak”. TabAtkins: My two constraints for this problem is that contain should work on ruby because it works on inline, and that whatever effect it has should be possible to get without using 'contain' for its side-effect. florian: Suggestion is to apply contain to neither inline nor ruby. fantasai: That is my suggestion, yes. astearns: We don't have contain and inline ruby. astearns: Is there a use case for contain on inlines? fantasai: You can't get that. It turns into inline-block. astearns: So if we choose not to apply contain to inlines, what do we lose? TabAtkins: Just that authors have to take an extra step of declaring inline-block. fantasai: I'm arguing that's a feature, not a bug. fantasai: If the author wants to have an inline-block, should be explicit about it. If they didn't, then they're not going to be happy anyway. TabAtkins: Internal table elements? florian: We already resolved they don't apply. Line Grids ========== Scribe: eae Topic: https://lists.w3.org/Archives/Public/www-style/2017Oct/0013.html <dbaron> https://github.com/dbaron/css-line-spacing/blob/master/explainer.md dbaron: Based on the discussions we had in Paris. We were talking about rhythmic sizing and the connections to line box contain. We've also had the line grid module which was designed to address many of the same issues and rhythmic sizing. dbaron: What I've been trying to do is look at the two and come up with a minimal viable product for line spacing in css and address existing concerns about line spacing. dbaron: I've tried to separate out the important pieces, as described in doc linked above. dbaron: Some people have raised concerns that I have addressed in the doc, others have raised concerns that I did not address. dbaron: Not interested in talking about naming. More interested in important use cases and what developers and designers really need form line spacing. dbaron: That requires distinguishing what existing tools actually do versus what developers actually want. dbaron: Figuring out what we need for line-spacing in css requires more knowledge about what these requirements are than I know. I think we have people in this room that know more about this than I do. dbaron: People are welcome to read and comment on the doc. There is also a github page. dbaron: More importantly, I want to determine what the requirements are. florian: I'm not the ultimate expert but have thought about it a fair bit. All use cases I want to address are equally addressed by your proposal. florian: If it is a simplification I'm all for switching to it. There are tweaks that might make it better but lets leave that to the side for now. florian: Fundamental problem shared with line grid. florian: From my point of view, if it helps implementation I'm in favor of this proposal over line grid. dbaron: I don't now what the key differences are. I don't think implementability was a key factor. florian: I didn't notice anything I missed during the removal process. iank: Is a line grid shared between formating contexts? dbaron: I think it is shared. florian: Issue I want to tackle later. dbaron: I think a lot of the key use cases are driven by things that are pretty separate. fantasai: One thing that was dropped which we might be able to re-add later was to have every other or every third line snap to the line grid. fantasai: Not super important right now but is issue that comes up. fantasai: For instance if you have different font sizes, i.e. line with smaller text size that takes up 1/3 the space. dbaron: I think of that as establishing a new grid. florian: Don't think it is especially critical. myles: You're totally right, making an inner line grid that has a size of 1/2 is common and something we should eventually support. dbaron: Some ways to approximate it. You could establish a new line grid. dbaron: In order to snap baselines you need to be careful in how it relates to the other grid. myles: Voicing weak support for your proposal. We haven't seen broad adoption of existing line grid spec. If this can get better support I like it florian: Reverse question. Does switching to this increase the chance of getting it? What are we gaining? dbaron: One thing we're gaining is the changing of the line hight model itself. florian: I'd argue we should add that as a separate thing as people might want it without the grid. dbaron: Agree but syntax will be tricky. fantasai: From what I understand from previous discussion: there are a variety of different levels of strictness re aligning to grid behavior. fantasai: 1) I want a sane inline model, no grid. fantasai: 2) Concept of really strict line grid, like physical pages where you can see things from the other side or facing pages. Multi-col in general. Where you want text to align across columns. Being stricter about grid in those cases is more important. fantasai: 3) If you gave a large single column of text and an intrusion then a consistent set of margins is more important than covering an integral number of grid items. Readers might not see whether it aligns to a grid in this case, so consistency in width of margins might be more noticeable. In those cases having a strict grid isn't desirable. fantasai: We might need both approaches. fremy: Whether we'll be more likely to implement. Questions around BFC. Flexible columns snap to grid, how would that work? Needs to be cleared before we proceed. florian: On agenda for later. iank: Echo your concerns. As it stands I can't say whether we're happy with this proposal. Seems okay but we'd want to limit it with regards to bfc, flexbox etc. When line hight changes etc. Lots of remaining issues. koji: I agree with fantasai that it should be available without grid. I also agree that we need a strict grid model. koji: I think dbaron's proposal is a little different. We need a less strict model as well. I think the flow model works better. astearns: Any other concerns or comments on David's proposal? nmccully: I also agree that it seems like a good proposal. I have concerns about baselines defined in other specs and how they relate. You mentioned dominant baselines being used to align, other specs talk about other baselines and flow. I have use cases that need support for setting different baselines. Being able to specify the baseline to snap to the grid. astearns: Those use cases are next on the agenda. fantasai: I think that David's proposal can handle this. Allows use of first or last baseline, you also have the option to use hanging baseline, etc using alignment-baseline property. You cannot have it align the alphanumeric baseline with the cap height though, for instance. koji: Question to David. The item 4 in your proposal looks like a possible solution to double spacing? dbaron: I think the changes to the line height calculation reduces the double spacing problem depending on ... hard to say if it fully solves it but in many cases when used well it'll solve it. dbaron: E.x if you're going to set a large line height it'll solve it more than a small line height. You're now applying the height on the line as a whole rather than the little pieces thus less likely to exceed height. If small line height more risk. florian: If you're setting the size of the grid independently from the size of the font then it increases the risk. The problem isn't there in your proposal, koji: That item 4 can then be applied to line-grid or rhythmic sizing? It's a general approach? fantasai: Yes. fantasai: No syntax for it in the proposal but the feature could be made generic by adding such syntax. <fantasai> This is listed as the first Open issue koji: Thanks. astearns: I think it would be interesting to try to apply that to the rhythm model and see what comes from it. * fantasai agrees with koji & astearns on this point astearns: More comments or should we go on to use cases? *silence* astearns: Both the line grid and the rhythm proposals should take David's explainer into account. fantasai: I think we should try to fix the inline layout problem, helps everyone regardless of grid. This is the #1 priority in relation to fixing inconsistent line heights in a paragraph. fantasai: We should continue to work on line-grid and rhythm, as both solve different use cases that people want. fantasai: block step size is probably easier, would work on that first, before line grid. fantasai: We should go through use cases and get a clear idea. florian: Question. Do we want to try to resolve on replacing existing line grid with David's proposal? Or should we postpone that decision until after. fantasai: Should put note in spec to point to the alternative. myles: We shouldn't resolve to replace existing spec without first going through fixing to existing spec. fantasai: We need to fix the inline model, need a loose grid and need a strict grid. fantasai: We have a step sizing proposal and a line grid proposal. Would work on step sizing next as it is better understood. Then to line-grid later. koji: ok nmccully: Have a couple of use cases for grid snapping. I looked at the baseline spec, and there are a couple of overloaded terms. There is central but it is not obvious whether which opentype baseline it maps to. nmccully: Depending on the font and the font design are going to be quite different. nmccully: Projecting, for CJK layout the relevant metrics are the em box. Differ from bounding top/bottom. nmccully: Mapping between latin and CJK font metrics are overloaded and the interaction between western and CJK content is not up to designer. Would like to see more baselines or explicit ones for Japanese fonts to allow pairing between CJK and Latin with layout as expected. Would like these baselines to be available for all fonts. nmccully: These baselines are critical for aligning. The metrics top center and bottom are then snapped to a grid. nmccully: There are different snapping behavior beginning to be supported in css. The possibilities where you snap lines, whether body grid with 14pt and letting with 21pt and a title between two paragraphs where it is larger. You want to center that on two grid lines. The options of how you position glyphs within that tall line, whether you consider the taller one to be the line-hight or the large one. nmccully: You're aligning glyphs within a line and the taking the line and aligning it to the grid. Each visible in different types of design. All possible variations might not be possible with the proposal. nmccully: Snapping the first line of a paragraph, two use cases. 1) Body text paragraph followed by smaller size one, first line is snapped to grid smaller ttype one is not. Following one is re-snapped to grid. Subtleties around what you do with the smaller line. Whether it is centered or nmccully: ...two examples. First one is snapping to the top. Second one snapping to center. nmccully: Is not an even leading amount in first case. nmccully: Both cases have adjacent flow that is top aligned in main column. nmccully: This type of snapping, two flows snapping to grid, is one of the goals of this proposal florian: Would this be solved using a line grid on the larger block and disabling it for the smaller one? fantasai: If you know the relative sizes of the fonts you can make that work. fantasai: In the first case you'd have a zero margin or line gap as needed, the second case you'd have that plus half the difference. florian: You align the stepped block on the dominant baseline. fantasai: If you're able to align baselines that is easy to do. If you are in a context without relationship and UA can't do baselines alignment you'd have to compute the margin. myles: Are everything you've shown here is common and valuable and are things the css spec need to support? nmccully: Yes, I don't think any are edge cases. koji: I agree that em top/bottom are important. Can't comment on line grid at the moment. em top and em bottom are not well defined today. koji: I wish we defined it better and how it relates to dominant baselines. koji: When we tried to do underlines for CJK there was no font metrics we could use for it. We computed em top and em bottom. Are not defined. koji: This might be a good opportunity to finally define them clearly. nmccully: I agree. One of the things we did in OpenType was to add metrics like this. ICF box top/bottom and em top/bottom to allow type designers to specifying them for layout engines. nmccully: Agree that having the metrics available is essential for layout engines. koji: It's great to have the metrics, is ill defined. myles: If you don't have them, you synthesize? nmccully: Yes, have synthesized in engines I've worked on. <koji> The OpenType algorithm to synthesize em box is here https://www.microsoft.com/typography/otspec/baselinetags.htm#ideoembox <nigel> sorry to throw this in from another room, but if you can define em top and bottom, how about defining the content rectangle height? https://github.com/w3c/csswg-drafts/issues/814 * fantasai notes https://drafts.csswg.org/css-inline/#baseline-synthesis probably needs some review from competent people myles: It seems that none of the three proposals have anywhere near enough details to explain the difference between the grids. nmccully: Would greatly improve matters if line-heights and glyph placement were more controllable. nmccully: The existing baselines aren't sufficient, glyphs can shift today, being more explicit is important even if that requires adding more baselines. nmccully: Defining how layout engines should use these baselines to position glyphs needs better definition. Smaller group should discuss this. Meta Bug for Line Height (CSS Inline & CSS2.1) ============================================== github: https://github.com/w3c/csswg-drafts/issues/1796 florian: This is a meta issues, many issues linked from it. Want to work on that css 2.1 doesn't define how line height is calculated. It tries to but contradicts with itself. florian: I've written a bunch of tests to see what browsers actually do. Much more interop between browsers than expected. florian: I'm not talking about which font metrics are used. Separate discussion. florian: I'm also not talking about when we have multiple inline elements within a line. Several fonts with different glyphs within a line, how are they aligned? That is what I'm talking about. Position of the baseline inline-level boxes with non-normal line-height ----------------------------------------------------------------------- florian: There are two general cases where line height is normal or has a value, resolves to specific size. Then there is normal. florian: In case where it is a size, you get exactly that size. Not clear from spec. Some spec text suggest it should be union of that per font, no browser does that. florian: The baselines from the first font is used and everything else is aligned from there. Not what the spec says but it is what all UAs do. That is good. astearns: Is it worth resolving to change spec to match that? florian: Yes. florian: Have proposed wording. If enough people have looked at my tests to verify them I'd be happy to resolve. florian: We have to be very specific when patching css 2.1 florian: Happy to craft detailed diff if we agree on the high level issue. eae: Matches our behavior. myles: We should just make the change and revisit if it causes problems. florian: The specific proposal is listed in issue 1801 at the bottom. [ When the value of the line-height property is something other than normal, determine the leading L to add, where L = 'line-height' - AD of the first available font. Half the leading is added above A of first available font and the other half below D of first available font, giving the glyph and its leading a total height above the baseline of A' = A + L/2 and a total depth of D' = D + L/2. Glyphs from fonts other that the first available font do not impact the height of the inline box. ] <florian> https://drafts.csswg.org/css2/visudet.html#leading dbaron: I was still looking at the previous issue. florian: One is about size, the other about alignment. dbaron: I think that seems reasonable. You might even want to say height or baseline of the inline box. dbaron: There might be some cases where that is not what we do but think that is for normal line height. Seems reasonable to me. astearns: Next step would be? florian: Resolve if we agree. astearns: And then we can review that pull request? RESOLVED: Take florian's proposed change to definitive line heights. Height of an inline-level box with line-height:normal using primary and fallback fonts ------------------------------------------------------------------- github issue: https://github.com/w3c/csswg-drafts/issues/1802 florian: CSS 2.1, in some cases, claims that line height normal behaves the same way as defined with a specific value. Probably between 1 and 1.5. Not what browsers do. What UAs do is take all fonts that are used, plus the first font, even if not used. That is what everybody does. Not what CSS 2.1 claims. dbaron: I have a vague memory of gecko doing something odd in some cases. If there is a simpler impl I'd be happy to change. florian: Only case I could find that skipped first font if unicode range is used for the first font. Chrome and Gecko have different behaviors. Other then that and the case where the first font' doesn't have the space glyph there is full interop. astearns: Has anyone reviewed these tests? florian: fremy said he did. astearns: Is Edge fine with taking this change? And Chrome? eae: Yes. myles: Let's do it! dbaron: Go ahead, trying to figure it out will take awhile. astearns: Any objections? dbaron: I'm pretty sure the gecko behavior is too weird. Might be worth having test coverage. florian: There is 2.5 browsers doing one thing, 1.5 the other. RESOLVED: Take florians proposed change for line-height normal. dbaron: Want to go back to line height normal. In some cases we use different font metrics. dbaron: The text in the proposal was very specific about the metric. florian: Will update it to be more clear about the specifics and that the font metrics in question isn't defined. dbaron: What metrics are used should be looked at separately. Will add comment. <dbaron> FYI, I did figure out the crazy Gecko behavior I was trying to remember: https://github.com/w3c/csswg-drafts/issues/1802#issuecomment-342349505 Behavior differences when the primary font does not contain U+0020 ------------------------------------------------------------------ github issue: https://github.com/w3c/csswg-drafts/issues/1798 florian: We discussed whether the first font in the fallback list should count as the first available font even if it doesn't have a space glyph. We did not specify whether it should also apply to line height. florian: Safari, Edge, and FF half the time considers it even if it doesn't have a space glyph. florian: Safari and Chrome do not. fantasai: The “first available font” should have a strict consistent definition across specs. florian: Is not consistent across implementations. florian: Happy to change if implementations are willing to change. florian: I don't really care strongly, arguments on both sides. florian: Are edge and safari ok with that? fremy: I didn't run all of the tests but I think we do the same thing? florian: So there are three compat implementations? florian: The first available font wording is used in 2.1 just not defined. astearns: Might be acceptable to not test the presence of space in 2.1 florian: Define it in fonts3 and then have that definition apply to all cases where we mention first available font Proposed Resolution: To define first available font more strictly in the fonts module and leave it undefined in 2.1 RESOLVED: To define first available font more strictly in the fonts module and leave it undefined in 2.1 Height of the content area of inline level boxes ------------------------------------------------ github issue: https://github.com/w3c/csswg-drafts/issues/1804 florian: All browsers agree that the size of the content area depends on the size of the primary font, even if no characters from the primary font are used. florian: The specification doesn't define the behavior, say "may do A or B". florian: Should remove "may do A" as no browser does that. florian: Suggest we remove suggestion saying that one may do something that nobody does. dbaron: Would argue it should be a SHOULD rather than MUST instead of a MAY. myles: Content area also depends on the line-gap property florian: Just depends on font metrics. florian: Spec says "do whatever you want, here are two suggestions". Doesn't mandate a specific metric. myles: Shouldn't say ascent or decent, have specific meaning. dbaron: I don't think this ones includes line gap, only asc+dsc. florian: There is a paragraph saying that if more fonts are used the height of the area isn't defined but we suggest... I propose we remove that. Rossen: What about overflow? florian: People don't do that for background I think. Rossen: I'll follow up with a test case. astearns: Let's continue making tests given the number of questions raised. fantasai: This is about where the background is painted for inline elements, very specifically about backgrounds. Rossen: I might be miss-reading the issue. fantasai: The question is how tall is the background painted behind the text. Can't set overflow on inlines. Has to be set on containing block. florian: I'm not an editor for any of these specs, there will be pull requests not in spec. florian: Would like to move forward. Proposed resolution: Change the wording such that 2.1 is saying you should define the content area based on the first available font and only that font. RESOLVED: Change the wording such that 2.1 is saying you should define the content area based on the first available font and only that font. [end of day]
Received on Tuesday, 5 December 2017 00:30:11 UTC