Minutes Telecon 2017-09-27 [css-backgrounds] [cssom] [css-writing-modes] [css-rhythm] [css-syntax-3] [css21] [css-inline] [css-multicol]

# Dael Jackson (a day ago)

========================================= These are the official CSSWG minutes. Unless you're correcting the minutes, Please respond by starting a new thread

with an appropriate subject line.

'border: 1px inset' is not interoperable

  • It was agreed that if more specificity is needed for inset that work should occur in L4 of Backgrounds and Borders. However, there is currently no use case for this level of specificity so a use case is needed before this is revisited.

Define serialization for background shorthand

  • RESOLVED: Postpone this until there's further evidence of use cases and move this to L4 if there is evidence.

Publication of Backgrounds L3

  • RESOLVED: Publish a new CR of backgrounds and borders.

Orthogonal Flow Constraint: viewport vs scroller

  • RESOLVED: Add max-height as well as height to the conditions that define the height for resolution of orthogonal flow sizing.
  • Florian will write tests for this resolution.
  • It was suggested by Rossen to also add an informational note that this does not guarantee the height will be correct.

<hash-token> seems to get type ID for sequence "#-\" followed by EOF

  • RESOLVED: Fix the check for a valid escape as described in #1821.

Meta bug for line height

  • The working group was reminded to review the tests (available here: w3c/csswg-drafts#1796) before the F2F.

Publication for Multicol

  • RESOLVED: Publish a new WD of multicol

Avoiding accidental double spacing

  • Koji wrote some test cases (w3c/csswg-drafts#938 ) and wanted to understand if his test cases gave intentional or accidental double spacing.
    • In general, it was felt that the tests produced expected behavior.
  • Florian continues to be concerned that unintentional double spacing can occur between browsers on the same code due to differences in font calculations.
    • Koji plans to write more tests to investigate these concerns more.

===== FULL MINUTES BELOW ======

Agenda: lists.w3.org/Archives/Public/www-style/2017Sep/0053.html

Present: Rachel Andrew Rossen Atanassov Tab Atkins Tantek Çelik Dave Cramer Alex Critchfield Benjamin De Cock Elika Etemad Javier Fernandez Robert Flack Tony Graham Dael Jackson Brad Kemper Myles Maxfield Thierry Michel Theresa O'Connor Anton Prowse Manuel Rego Casasnovas Melanie Richards Florian Rivoal Alan Stearns

Regrets: David Baron Bert Bos Emil Eklund Daniel Glazman Peter Linss François Remy Greg Whitworth

Scribe: dael

Agenda Setting

Rossen: Let's get started. Rossen: Good morning! Rossen: As usual, first item is call for any additional items or anything to change on the agenda. rachelandrew: I posted to the list about putting multicol back to WD if we could add that. <fantasai> +1 to Rachel rachelandrew: To republish as a WD since we've had so many changes. I posted a run down of those changes. astearns: We decided to take this back to WD because there were so many changes. This is just a resolution to publish. Rossen: I see and I see your email. Rossen: Any other additional topics?

Spec Rec Next Steps

Rossen: There was some good discussion on private list. I wanted to draw attention to the first one. Rossen: It's the topic of testability and that we want test cases to support CR+ specs. Rossen: astearns, are we closed on this topic? Is the final plan what's in the private list thread? Or do we need discussion? astearns: All I suggested was we keep issues open on CR specs until we have test cases. Rossen: And is there agreement on this? astearns: fantasai and I talked last night and I think...I think she's okay. Correct? fantasai: Yep. Rossen: Perfect. And thanks to everyone submitting test cases.

Rossen: We have a couple of topics on backgrounds & writing modes which are tracked specs. I didn't see much about other specs. Rossen: If there are issues you're facing with the tracked specs please let us know.

Backgrounds & Borders

'border: 1px inset' is not interoperable

github: w3c/csswg-drafts#1489

Rossen: Is zcorpan on? [silence] fantasai: I can probably take this. fantasai: Basically the inset and outset borders we don't define what color they should be. This is resulting in non-interop, especially on 1px. Do we want to work on aligning and, if yes, do we try and do this in L3 or L4? <tantek> L4 please fantasai: I don't think we can resolve on the result, but figuring out where to put this work would help me agenda set. Rossen: Fair. <tantek> unless someone has citations of real world sites where people are complaining <tantek> and in which case, seriously, 1px inset/outside/ridge etc. border?!? why?!?

Rossen: For the impl would this be something high on your list of things to fix if we were to agree? Or will this be low priority? Rossen: I'm going to take silence as it being low priority. Rossen: As an impl I would say this is low priority for us. We have no had any reports of issues because of this. I don't see us rushing this.

Rossen: One more call. Rossen: If no one raises urgency I propose L4. Rossen: So this is the call. If you're an impl and want to rush an interop fix, now is the time. <tantek> if Edge is still using the Trident border style rendering code which was ported from Tasman, then I'd say that's a good default if you want to specify something in L4 :) <bradk> Wait for L4 Rossen: Okay, let's take this to L4.

Rossen: fantasai is this specific to 1px or inset in general? fantasai: I'm not sure. florian: From bug it looks like there's a general problem and it's worse at 1px. We need to dig into details. Rossen: Okay. Again, I don't think we can push inset to L4.

<tantek> I want to know what is the use-case for these odd 1px border-styles <tantek> seriously why are people doing them? what effect do they expect? fantasai: The spec has a not-specific statement as to what the color should be, but no formula. All impl are spec complaint. <tantek> yes that's deliberately vague to capture what implementations did in the late 1990s / early 2000s Rossen: Okay. Let's close saying if there are any more restrictive spec changes that have to be made in terms of inset and color computation, they would go in L4. Objections? tantek: I'd want a use case. Why are you doing this? for what effect. fantasai: The default rendering of hr to be consistent? tantek: Why? fantasai: Don't know. <bradk> Inset borders are not in vogue anyway tantek: That's why I want it documented. I'd prefer an explicit statement saying we don't know why to do this. Most things we do with a use case for what's trying to be achieved. You're just making work without a use case. <astearns> the effect we're looking to achieve is interoperability in an existing feature Rossen: Fair point.

Rossen: Your point will be in github. If we ever come back to this we'll have to call for use cases and then revisit. Fair to you? tantek: Yeah. Rossen: Anything else? fantasai: That's it.

<tantek> suspects that anyone wanting border color precision like that for 1px will explicitly compute and define each TRBL side's color explicitly <florian> tantek: I agree, and even more so once we add the multiple borders we've resolved on, you even do explicit inset/ outset at subpixel level on retina screens. <tantek> florian yes, retina-specific enhancements / experiments is another good reason to leave those border-styles underspecified.

Define serialization for background shorthand

github: w3c/csswg-drafts#418

fantasai: Defining serialization when splitting BG into multi long hands. Question is do we tackle in L3 or is L4 okay? fantasai: Is it really important to converge now or are people happy to defer? Rossen: I'll piggyback on tantek's point for use cases as well as ask if there are any impl that are currently seeing interop issues because of this and in any urgency to change their serialization. Rossen: I'm hearing silence which I am taking as no interest or use cases. Rossen: Obj to postponing this until there's further evidence of use cases and move this to L4 if there is evidence? <tantek> +1 to at least postpone to L4, and note explicitly no use-cases

RESOLVED: Postpone this until there's further evidence of use cases and move this to L4 if there is evidence.

Publication of Backgrounds L3

<fantasai> drafts.csswg.org/css-backgrounds-3/issues-cr-2014 Rossen: Backgrounds and Borders was...that was bikeshedified last week, correct? fantasai: Yep. I updated DoC. We just closed issue 14. Issue 12 is adding caniuse panels which we don't need to block on. All other issues are clarifications or resolved. <tantek> ship it! Rossen: Awesome. Any objections to publishing new WD of backgrounds and borders?

RESOLVED: Publish a new CR of backgrounds and borders.

<tantek> do we have a changes section? <tantek> since prev CR? <astearns> do we have tests for all of the backgrounds and borders changes since the last publication? <tantek> astearns also a good question - "tests for all ... changes"

       - I was just looking for a "Changes from 2014 CR" section
       myself to understand what those changes were. tests would
       be great in addition!

<tantek> anyway I'm ok with resolving to publish an updated CR ( because that takes a while post-resolution) but I'd strongly prefer if it the updated CR included a "Changes from previous CR" informative section (e.g. in the/an appendi x)

Orthogonal Flow Constraint: viewport vs scroller

github: w3c/csswg-drafts#1391

florian: We resolved recently that if you had orthogonal flows with indefinite size you would go with icb or closest scrollport with fixed dimensions. We did not discuss, but I found out, chrome & safari will also pick one up with auto height and fixed max height and they'll pick up the max for the auto. florian: Since we have almost two impl and that looks useful, I suggest we add scrollport with fixed max height to what we look through. Rossen: The one thing I want to add is that when we talk about these use cases and combinatorial nesting of scrollports the one thing I don't see being addressed is with the addition of flexbox and grid there are many different other cases which will result in a scrollport having a defined width or height. Rossen: And max height is not the only one. If your scrollport is a grid item with height stretch that will also be defined. Computing dimensions in which we resolve orthogonal flows based on these two properties won't be enough in all cases. Rossen: Having said this I also know there will be too many other permutations we can come up with so I'm a little concerned we will have something that kinda makes sense for blocks only but when we come to more powerful layout features we'll be back to having quite a bit of interop issues. Rossen: My hopes is we either keep it more vague for now or we try and nail down all the permutations. florian: For other permutations don't you need to do some kind of layout to figure them out? Rossen: You have to. florian: Max height you don't. Rossen: You have to do the layout to figure out final size. If we are striving for some height quality of guarantee which are of the order if you have orthogonal flow we guarantee it will always be visible. If we want that type of guarantee we need to do a lot more work and take into account other sizing and layout effects. Rossen: If we don't want that guarantee I'd prefer less rigorous and leave text as-is.

florian: I'm not sure question of level is right. Once one behavior is established it is. I'd want to make it as convenient as we can without depending on layout. Adding max-height seems simple and useful. But if you don't want to I wouldn't object, I just noticed this was the case in 2 browsers already. <fantasai> +1 to Florian Rossen: Here you have 2 impl that have this behavior. And you said they are not interop when border and padding is in play. I'm a little wary of trying to define a little bit to nudge and require others to follow if we're not going all way. florian: Multiple browsers will have to change anyway because we're not interop. But your argument of all or not at all...okay. I felt it was easy fruit so I'd rather grab, but I don't care strongly. I just felt it was new information. fantasai: I agree with florian that including max height isn't any harder then doing height. I don't see a reason not to. Rossen: I've stated my reason. fantasai: We're not suggesting look for the thing with max height and use actual height. We're just saying use max height as the limit. That's straight forward. <fantasai> <div style="overflow: auto; height: 100px"> <fantasai> <div style="overflow: auto; max-height: 100px"> Rossen: florian I thought you said that would also work with height auto. florian: What I meant is what fantasai said. That height is auto we can't use that height, but if max height is there we use that. I meant what fantasai said. Rossen: It's a pretty crude approximation. That you have max-height doesn't mean you'll grow to that. You could have a fixed height parent which drives overall height and you get overflowing vertical text. I don't see how max height guarantees. florian: I don't think it guarantees, I think it's never worse and sometimes better. fantasai: You use smaller of closest scroller. If we look at closest scroller and it has no height we'll use initial containing block. Accounting for max height means we can limit. If we don't consider max height we'll be bigger for sure. florian: I think it's easy, sometimes useful, never worse. Rossen: I would agree with that. It shouldn't make it worse.

Rossen: Are there other opinions on this topic? Rossen: What is effect on the current tests for writing modes and what would it do for progress? fantasai: Simple edit to text. In terms of tests the impl have yet to converge. I have an action item to write some tests for this. Impl sometimes match speccing behavior sometimes don't and that's because they're based on different logic. This is prob simpler. Regardless of this change we'll need specs to change. florian: If we write extensive tests we won't get 2 impl any way. We could write naive tests that pass. Rossen: Current snapshot of the test suite was sometime last year, correct? florian: We resolved recently to change that so we need a new test anyway. It's just what resolution do we write it to. Rossen: I'm just trying to understand where we are. koji: As I understand last thing had 2 impl. And you said safari is slightly not interop. florian: If you just test this thing you get impl. If you try and interact to check for robust it breaks. If you just test this it passes in chrome and safari.

Rossen: Other opinions? Rossen: Obj to add max-height as well as height to the conditions that define the height for resolution of orthogonal flow sizing?

RESOLVED: Add max-height as well as height to the conditions that define the height for resolution of orthogonal flow sizing.

Rossen: I also think adding a note that suggests there are many cases that will break this...the current resolution is brittle if we claim we guarantee the height. florian: We don't offer that guarantee. If you want a note that this helps but isn't enough, I'm fine with that. Rossen: A note that it's not guarantee is good for authors.

ACTION florian to write tests for the resolution " add max-height as well as height to the conditions that define the height for resolution of orthogonal flow sizing"

<hash-token> seems to get type ID for sequence "#-\" followed by EOF

github: w3c/csswg-drafts#1821

TabAtkins: Definitely a bug, needs change. I won't do details, but if you have a malformed hash token at end of stylesheet it can sometimes report it's valid even though it can try and escape an EOF. TabAtkins: If you have a hash token with like a # symbol [missed] TabAtkins: hash -/end of stylesheet it's [missed] This is a small bug to test if something is a valid escape. I don't check to see if second character is EOF. If I add that it won't have any additional consequences. TabAtkins: All bugs were extremely minute. It's just that this is not what was intended in the spec. florian: Go for it. Rossen: Any other opinions or concerns on this topic? Rossen: If not we can resolve. Rossen: Objections?

RESOLVED: Fix the check for a valid escape as described in #1821.

Meta bug for line height

github: w3c/csswg-drafts#1796

florian: As I've said before I made a bunch of tests and made conclusions. Please review my tests so we can change the spec. I think we're almost fully interop. Look into it. Thank you. florian: There will be TPAC drawings. But that will be more useful if people read before. Rossen: I see it's on the F2F agenda. This is a nudge to everyone to look before the F2F.

Publication for Multicol

<tantek> changes section? <astearns> tantek - yes, many changes: drafts.csswg.org/css-multicol/#changes <tantek> thanks astearns, noting here FTR: drafts.csswg.org/css-multicol/#changes Rossen: Objections to publishing multicol WD?

RESOLVED: Publish a new WD of multicol

Avoiding accidental double spacing

github: w3c/csswg-drafts#938

<koji> w3c/csswg-drafts#938 koji: The biggest problem for me is I'm failing to understand definition. I made this example ^ koji: astearns gave me feedback that...the left most in the example is normal. Second I applied line-grid. I applied line-box contain to third. koji: Second block has some double spacing but astearns says they're all intentional. Is that common understanding within this group? myles: I think you're asking me? florian: Everyone. koji: Yeah. We need to distinguish intentional and accidental double spacing and there isn't a clear definition. koji: The second box is [missed] it happens accidental when font metric is only slightly larger. Is that correct?

astearns: One thing I missed when I commented is that in your example you are not changing line height. It's all the same, but there are some fallback fonts making some lines taller. koji: Correct. It started with line-height:normal and it does double step. astearns: Right. With that new understanding I believe you are correct that this is an example of the problem stated by the issue. 2nd is accidental line spacing because the author had line-height:normal and the grid set to something without double spacing. astearns: In my mind this is an intentional result of the feature. You use rhythm to get consistent spacing, but the content is such that you don't get it, so the spacing is forced by the grid so the result is what authors should expect. koji: Okay. koji: Are you saying this is intentional or accidental? astearns: Accidental in that if the author didn't know what content would go into their grid, they didn't have control over the fonts used, the person setting up line grid might not have expected it. But they chose a rhythm, chose a grid, so we're fitting author intent of using a grid. astearns: I think this is an example of the issue as stated. I personally don't think the issue is terrifically important because author said they wanted to use a grid or rhythm. koji: Thank you, that is exactly my understanding. florian do you have different opinion?

florian: I'm struggling with how to say my opinion in 10 minutes when in last F2F we tried to discuss and didn't conclude in 2 hours. florian: I think when you have a case of line-height: normal and then step to a value and large fallback the feature works as intended. Similar case, technically, is line-height: normal, line-height-step to a specific value, and the main font on the engine happens to be a little too big and everything is double spaced. That's not what authors want and I don't know how to fix that. florian: First problem happens with line-grid but the second one you don't have the same problem because line-grid falls out of main font size. koji: But if you go to single grid in that case lines overlap. Grid is fixed height, line-height is normal, and main font is lager. florian: Line-grid you don't set it. That's the point. koji: What you're saying is line unit is fixed size and line-height: normal and the primary font is taller then specified unit. Is that the case? florian: I think yes, I didn't hear you clearly. koji: If you compress the font to a single unit they overlap. You said the font is taller then the unit, right? florian: What unit? <Rossen> how is this problem different than having display: grid with fixed row repeats and auto placed grid items? ... some will fit in one row others will cause two rows to be created

koji: Let me confirm. You said unit is fixed size. florian: I said line-step-height is fixed, line-height is normal. That font on that system gives a line-height taller then step you set for primary font. koji: If the font is taller and you try and fit in a single step you overlap, right? florian: Line-height is normal. They're larger then your step so you double space everything. koji: You said that's a problem? florian: Yes. florian: Double space everything is a problem if the rhythm works in general and some fallback is taller that's working as intended. If everything is double spaced that's not working as intended.

florian: Primary font...I can't do this in 5 minutes. florian: I tried for hours and failed. koji: [missed] We mostly discussed which features people break and that's not related. Rossen: For the sake of furthering this, I think in summary I've heard that florian's main objection is in case of fallback font being slightly larger then primary you will have double spacing when fallback font is used. florian: That is how it works and in general not a problem. Rossen: And because of this you expect everything will have double spacing? florian: No, what I'm saying is when the author sets a value for line-step-height they don't know what the result of line height calculation will be so they cannot set it in a reliable way. So there is a possibility that things will look right on one browser and not in the other because different font metrics. That's not what the author wants and a limitation. The double space everywhere on every browser is what's wanted. koji: I think I understand your point much better. I'll prepare another test to see if my understanding is correct.

Rossen: Sounds great. How about we try and wrap here. Seems like there's more clarity for koji in test cases you need to look at. Why don't you create the test cases and bring them back? Rossen: We'll take time during F2F on this, but if we can resolve before even better. Rossen: Okay for both of you? koji: Okay for me. florian: I have no objections to koji trying things out. I don't think it'll change what I think of this feature.

Rossen: That's the top of the hour. Have a great day/night and we'll talk next week.

Contact us to advertise here

Want more features?

Request early access to our private beta of readable email premium.