Minutes Berlin F2F 2018-04-12 Thu Part IV: Table Boxes, Aliasing, Text, Overflow [css-text-3][css-overflow-3][css-tables][css2][css-cascade]

   These are the official CSSWG minutes.
   Unless you're correcting the minutes,
  Please respond by starting a new thread
    with an appropriate subject line.

CSS Tables

   - RESOLVED: rename “table box” to “table grid box” (Issue #2501)

Text L3

   - RESOLVED: Spaces don't hang when break-spaces is specified (Issue

CSS Cascade

   - RESOLVED: Define property/value aliasing in CSS Cascade as an
               operation on par with case-mapping the identifier.
               This affects parsing CSS files, OM arguments, and
               .style.propertyName, etc. (Issue #866)
   - RESOLVED: We create a new legacy shorthand concept in Cascade L4
               for properties which need both aliasing and value mapping;
               these are like regular shorthands except are never serialized.
               (Issue #866)
   - RESOLVED: Everything that's currently defined as an alias needs to
               use new alias definition or become a legacy shorthand.
               (Issue #866)

Overflow 3

   - When discussing Issue #129 (padding-bottom in overflow content)
       the group originally thought they could solve the bigger author
       pain point (block-end padding) in isolation. However, as
       conversation continued it became clear that an entire model that
       covered inline padding and the relationship to absolutely
       positioned elements was required to address this issue.


Agenda: https://wiki.csswg.org/planning/berlin-2018#schedule

Scribe: dael

CSS Tables

table box naming
   github: https://github.com/w3c/csswg-drafts/issues/2501

   fantasai: Proposal. fremy was complaining about confusion between the
             two. At some point the suggesting of table grid box came
             up. So request is rename table box to table grid box.
   astearns: Obj?

   RESOLVED: rename table box to table grid box

Text L3

Audit details of break-spaces value against use cases
   github: https://github.com/w3c/csswg-drafts/issues/2465

   astearns: These are things we're rounding back to.
   astearns: This issue needs to be address to unblock something
   flackr: Igalia is about to impl and needs this closed.

   fantasai: There's several slight details. This is about
             break-spaces. Goal is on some property is there's a mode
             for editing when you're typing a space it behaves
             more predictably for the user.
   fantasai: We want caret to move forward, spaces to not overflow (as
             long as containing block is more than 1ch wide),
             so spaces don't hang.
   fantasai: There's currently a break-spaces value on overflow-wrap,
             but right now spaces are defined as can hang at end of
   fantasai: There's side effects of this. When you have a word at the
             end of the line and it fits but the space doesn't, even
             though you're breaking spaces it doesn't move to next line
             but it does overflow. If you want things to wrap it's a
             problem this space overflows.
   fantasai: Related issue is that when you're trying to define
             intrinsic size of this box if the space is hanging it's
             not measured but if you want it visible you want to count
   fantasai: Seems to me if we want the space to behave like a normal
             visible character, it should also affect size and not be
   fantasai: This means if the word fits and you type a space if the
             word fits it will wrap, and we measure the space when
             measuring intrinsic size

   fremy: We fixed an issue in Edge when people expect contenteditable
          not to wrap at same places because they use it for
          underlines. They use it as a rendering of the text.
   florian: So rendering should be same either way even if the reason
            is because when it's editable you wouldn't want anything
   florian: We're not proposing a difference based on editability,
            we're proposing both modes are same. But when you're in
            editing the new behavior is sane, not almost sane.
   fremy: We did the reverse.
   fremy: We made it so that when layout not taking space
   fantasai: fremy's fix where you made them match that's good and if
             they want spaces to show and say break-spaces the spaces
             take up space.
   florian: But why align editable and not to not take space.
   fremy: Most content web is spaces not so we changed to that case.
   florian: It's hanging but it's there.
   fantasai: Edge behavior is in the spec now as most recommended as I
             recall, for the default behavior.
   fantasai: Change is that spaces don't hang when 'break-spaces' is
   florian: Rest is consequences of that.
   fremy: Sounds good.
   astearns: Obj to Spaces don't hang when break-spaces is specified?

   RESOLVED: Spaces don't hang when break-spaces is specified

CSS Cascade

Aliasing mechanism
   github: https://github.com/w3c/csswg-drafts/issues/866

   fantasai: Couple places in text with an alias like overflow-wrap and
             word-wrap and the way they're aliased in the spec is not
             how they're implemented.
   fantasai: Previously resolved that when we do alias we treat as
             shorthand of other properties. Mozilla has different
             mechanism. If we're changing I need a resolution on what
             to change to.
   florian: I think it's not just Mozilla. In general aliasing in a
            browser doesn't work as a shorthand.

   emilio: How to observe?
   florian: By browser engineers complaining. What is the different
   emilio: [missed]
   dbaron: One difference might be when serializing declaration you try
           and serialize to a shorthand first and you don't want to do
           that here.
   dbaron: You want that for real shorthands
   <fantasai> dbaron's comment on observable difference -
   emilio: But not aliases.
   dbaron: Example if you have a declaration that says border:medium on
           each direction we'll use border:medium. Same rule is that if
           someone declared overflow-wrap:inherit we'd serialize to
   TabAtkins: CSSOM wording has preferred order where shorthands are
              above longhands, but prefixed are below all of them.

   fantasai: Trickier is page-break aliases. Those ones the page-break
             which is old cannot express all the values of the longhand
             which is where we're moving to
   <fantasai> https://www.w3.org/TR/css-break-3/#page-break-properties
   dbaron: There are also things that aren't supposed to work for
           shorthands. We might have changed some of those things to
   emilio: Spec says generally that getPropertyValue works for
           shorthand but in getComputedStyle only properties are actual
           long hands but if there's properties for shorthands also
           expose them there. getPropertyValue.font is supposed to work.
   emilio: Both work in webkit and block, but getComputedStyle.font
           isn't supposed to work per spec.
   emilio: Edge and FF don't impl any shorthand in getComputedStyle
   dbaron: We do some.
   emilio: blink and webkit support both.

   dbaron: Other question is what is the actual mechanism we use.
   dbaron: In old style system at the point we converted a string to an
           internal css property ID--where we also did lowercasing and
           such--we also did the alias mapping. So every time you had an
           input that's a string that was asking something about a
           property we would convert it.
   emilio: Now I think we preserve a bit longer to control aliases via
           prefs. But not much longer. Once they're in the declaration
   fremy: We only have "realId"s that are HTML. If we have
          -webkit-something and if the same as a prefix it's the same

   astearns: I'm a bit confused. dbaron you started saying it's not
             like a shorthand because when you serialize the property
             turns into alias.
   dbaron: The thing that's not the alias is turned longhand.
   emilio: Supposed to serialize the short hand. If you have foo per
           spec it should be -webkit-foo.
   dbaron: If it's word-wrap and overflow-wrap it's supposed to switch.
   TabAtkins: It's alphabetical.
   emilio: One is long hand.
   TabAtkins: Yes, if they're both shorthands.
   florian: If word-wrap is defined to be a shorthand you'll serialize
            to the thing that's supposed to be the shorthand
   fremy: When you spec the alias it's the same thing.
   astearns: Instead of defining alias as a shorthand we define alias
             as a separate thing and define what browsers are doing.
   myles: If you say .font does what you spoke about work? Would the
          alias and the original exist there?
   emilio: Yeah.
   myles: It's not just turning strings into an ID. You also do this
          other thing.

   florian: What about properties that take values?
   emilio: Same. Whenever you parse a property ID if you receive like
           the alias you once you process it it's the same as if you
           got the longhand
   florian: If you serialize the transition-property property ...
   florian: If you serialize the transition-property property which
            takes property names you do not preserve the name.
   dbaron: In old gecko we did not preserve it.
   florian: And a shorthand you do preserve?
   dbaron: Yes.
   florian: That's one reason I pushed for shorthand originally.
   dbaron: We could still spec the other way for alias

   florian: Initial reason for shorthands was double. One we looked for
            in page-break has a different set of values.
   emilio: Parsing rules. That's what we used to have for
           box-transform. We impl it as a shorthand and special cased
   florian: In general I think we can do the simple thing.
   fremy: For the transition-property property we keep the ID as it is.
          If you can't match to a property in the end it doesn't work
          for us.
   emilio: We preserve the ID... I agree it's not relevant.
   fremy: We're not preserving it as a shorthand.
   myles: So mechanism for alias is not shorthands.

   florian: I'd like to resolve in general and separately for
            page-break and friends.
   emilio: Can't change parsing rules?
   florian: No.
   astearns: Seems to me like we could define what aliases are in
             Cascade in general and when we have an alias that needs
             mapping we define that in it's own spec.
   fremy: Example some -webkit-flex properties are different.
   florian: We define separately then? If values are the same we don't
            do anything.
   emilio: In FF we don't have any special case. I don't have context
           for page-break but how is it supposed to work with
           page-break:foo and then break:foo
   florian: Let me pull spec up.

   florian: page-break-before:always maps to break-before:page
   [and break-before has additional values]
   fremy: They're not aliases.
   florian: If we define aliasing mechanism it won't work here.
   emilio: Page break properties, how should they work with aliases?
   florian: They're supposed to be shorthands.
   emilio: Why are we covering?
   myles: There are shorthands and aliases and they're different
   dbaron: Page-break still needs to be a shorthand.
   astearns: But that's not relevant
   florian: They're defined as these are aliases and you do them as
            shorthands. We have to change that
   <fantasai> Another aliasing case is

   astearns: We have to change where we say alias in all our specs
   myles: Where values aren't the same.
   florian: We had resolved on they're the same.
   myles: was a bad resolution.
   emilio: What's expected to happen when you serialize
           page-break-always? It's defined to map to break-before:page
           What's expected serialization of page-break:always in
   emilio: Is it break-before:page? break-before:always?
   fremy: It's not an alias. Alias is a webkit thing so it's an alias.

   florian: Let's delete alias from that paragraph and leave the rest
            as is. Let's define alias somewhere.
   emilio: If we define this is a shorthand then break-before:left will
           be page-break. It's weird because page-break is legacy
   myles: Define in other direction?
   fantasai: Can't because break-before has values that
             page-break-before can't express.
   emilio: Page maps to page
   florian: Thing on the left are everything you have things on the
            right are more values.
   emilio: We can special case that.

   fremy: Can have concept of legacy property that's serialized at the
   emilio: Then you have shorthands where you have to create special
   fantasai: You'd have a list of properties where you're looking for a
             shorthand and you never look at those.
   fantasai: Right now when you try to serialize you have a list of
             declarations and if it corresponds to a shorthand you
             serialize as the shorthand. And we're saying when you
             check, eliminate the legacy shorthands from the list.

   astearns: Several things to resolve. First is we should define what
             an alias is in CSS Cascade
   astearns: Objections?

   RESOLVED: We should define what an alias is in CSS Cascade.

   astearns: In pure alias cases where we don't want shorthand behavior
             we need to change to the definition written in the
             previous resolution.
   florian: Yes.
   astearns: We will use this definition where it's appropriate.

   RESOLVED: We will make the required edits for the definition
             resolved previously.

   astearns: Proposal: We create a new legacy shorthand concept in
             Cascade L4 for those things that we have legacy shorthands
             that should never be serialized
   astearns: Or is this a type of shorthand.
   emilio: There's a tricky thing because only place for this kind of
           shorthand is when the new thing supersedes the old. Is there
           a case where they don't map?
   fantasai: glyph-orientation which takes a keyword and a degree and
             those map to keywords in text-orientation.
   emilio: Okay. That's fine as long as you can map.
   astearns: That can be it's own section or subsection.
   astearns: Objections?

   RESOLVED: We create a new legacy shorthand concept in Cascade L4 for
             those things that we have legacy shorthands that should
             never be serialized

   emilio: Then someone needs to edit.
   fantasai: TabAtkins and I can.
   florian: Do we need to resolve on a list?
   emilio: If they have same syntax you're fine otherwise use legacy.
   astearns: Let's do what we resolved and look at the fallout from
             that. Better to have them take time and find places it
             doesn't work.
   florian: Principle stated is if they take same values it's alias
            otherwise it's legacy.
   emilio: They're different things.
   astearns: florian is asking that we resolve to put thing in one
             bucket or the other and if we find problems we bring that
             to the group.
   astearns: Proposal: everything that's currently defined as an alias
             needs to use new legacy definition or is a legacy shorthand

   RESOLVED: Everything that's currently defined as an alias needs to
             use new legacy definition or is a legacy shorthand.

   fantasai: If you're using aliasing mechanism what does that
             mean...you'll always serialize as the new thing and we
             don't have objects in OM rep that?
   emilio: We do.
   fantasai: We should spec that
   myles: If you set the old object you should be able to read that
          from the new object.
   fantasai: So this also applies to .style.
   emilio: Yes.
   fantasai: Anywhere name is exposed. Okay.
   fantasai: I think that's it.
   fantasai: If you type in word-wrap:break-word and re-serialize that
             you get overflow-wrap:break-word That's okay?
   many: Yes.

Overflow 3

padding-bottom in overflow content
   github: https://github.com/w3c/csswg-drafts/issues/129

   fantasai: Issue was filed by frustrated devs where if they have an
             element with overflow:scroll and it has padding and if the
             content overflows, the padding is useless.
   TabAtkins: I'm one of these web authors.
   fantasai: Chrome includes that padding at the bottom. Request is
             everyone matches Chrome.
   emilio: On the spec issue there's a reference to an old Mozilla bug.
   fantasai: I'm not sure spec is clear on what happens.
   TabAtkins: Probably not wrong that Mozilla thinks it's spec
              compliant, I just think it's wrong. Everyone does it a
              little different.
   TabAtkins: There's a difference between block overflow and inline

   fantasai: I don't think we can solve this all. And I think it'll be
             undefined for a while. But biggest pain point is the
             padding-bottom on the overflow container. Idea is to fix
             that one in a way to make web authors happy.
   <fantasai> http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=5907
   fantasai: Since Chrome has shipped for a while we can be sure it's
             fairly compat. There's a test case ^ You can see Chrome
             has padding at the bottom and FF has none.
   TabAtkins: Use case: I am a blog post editor and I want the text
              editor behavior where I can scroll the bottom text to a
              reasonable region to read it.
   fremy: Reasonable.
   dbaron: Would be nice to spec something simple. Given there's
           incompat there's a simple thing that can be close to what
           current browsers do.

   fantasai: My current proposal is to leave padding and margin undefined
             ngeneral but say for padding you have to leave space at the
   astearns: You're asking for a targeted fix and dbaron wants a
             general fix.
   TabAtkins: Would it be bad to resolve this and then try and resolve
              inline. It's a more complicated space.
   dbaron: I'd like to resolve we intend to change inline even though
           we don't know how to do it.
   fantasai: It's possible for web compat we can't fix inline and even
             if that's the case I think it's reasonable to try and fix
             this. General usability of CSS we should make this work.
   TabAtkins: When we nail down inline padding at least 2 browsers will
              have to change.
   dbaron: People care more about block because they scroll in that
           direction more.
   fantasai: And throwing in block axis overflow with scrolling is less
   fantasai: I would like to include as much of margins and padding in
             the overflow areas but we have the case of “will this
             trigger scrollbars where it's not expected”.
   fantasai: Since we don't have a web compat constraint with bottom
             padding I think we should do that.

   astearns: Prop: Require that you leave space in scroll containers
             for block-end padding?
   TabAtkins: Cool.
   astearns: Add a note saying like to enforce for inline padding, but
             not sure if we can for web compat.
   fantasai: We'll file another issue on that.
   astearns: Okay dbaron ?
   <fantasai> testcase for inline-end padding
   <fantasai> Looks like Chrome includes padding-inline-end
   dbaron: I guess so.
   dbaron: I think we used to do that and changed to compat with spec.
           Spec is quite clear that's what you do. Nothing to imply you
           should move padding.
   myles: I talked to hyatt and he said he did it because it was
          symmetrical and looked better.
   myles: In webkit.
   myles: I think webkit.
   astearns: Objections?
   fantasai: I'd be happy to resolve for inline too; just don't want to
             hold up block-end.
   myles: I think we should do both.
   fantasai: Okay.
   astearns: Resolve and then talk inline or block?
   myles: no preference
   astearns: Resolve for just block. Obj?

   RESOLVED: Require that you leave space in scroll containers for
             block-end padding in the scrollable area.

   astearns: Do we also require space for inline padding because
             consistency is nice.
   fantasai: There's a test case above in IRC: 
   emilio: Is that compat?
   TabAtkins: Chrome puts padding on all the sides.
   astearns: Same argument applies. If Chrome has been doing it for so
             long. Can you see if there are bugs on extra unexpected
   myles: When would the scrollbars not appear?
   rune_: Bug report ^
   TabAtkins: It's a spec bug.
   rune_: Yeah, it's not compat.
   myles: Same argument applies.
   astearns: And fremy agreed.
   astearns: dbaron wanted consistency.
   astearns: Objections to use same space saving for inline-padding?
   koji: It's a block inline.
   fantasai: Padding on scroll container itself. Everything else is undefined.
   TabAtkins: From test case in bug, we do apply padding if it's inline content
              that overflows, but not if it's a block causing the overflow.
              If the block is inline overflowing no padding, but the text you do.
   myles: Same as my comment.
   TabAtkins: I didn't realize we did that as well.
   astearns: Maintain that?
   TabAtkins: No.
   astearns: Worried if you don't?
   fantasai: I have concerns about web compat but I won't block.
   dbaron: Apply to content nested arbitrarily deep? You're propagating 2
           versions to know if it's block or inline overflow?
   myles: I think the answer is no, just children.
   TabAtkins: No, it looks as far down as you want to know.
   <fantasai> o_O

   astearns: Proposal: Preserve space allocated by inline-end padding on the
             scroll container.
   fantasai: Dunno abspos.
   myles: No browser does that. Scary.
   TabAtkins: It's close to blink and chrome.
   dbaron: Inlines you add the padding and blocks you don't?
   myles: yes
   TabAtkins: Presumably difficulty of reading text flush with edge was the reason.
   dbaron: But then why not blocks?
   TabAtkins: Blocks aren't text.
   TabAtkins: Clarification. Inline content has to be a direct child.
   myles: Toggle looks at just the children.
   dbaron: Inline inside a block child you don't apply
   dbaron: I think applying all the time is good, but I'd rather leave
           as is then keeping the inline vs block.
   astearns: You don't want the chrome/webkit current.
   dbaron: Right.

   fantasai: Clarification to previous resolution - doesn't apply to
             abspos. Because that's what impl and it makes more sense.
             abspos is positioned with respect to padding edge, so it
             doesn't expect to have that extra space anyway.
   myles: So it's abspos and you say padding:0 it's now underdefined.
   fantasai: Previous resolution the padding is added to inflow
   dbaron: Can you make inside of a scrollable area be abspos or only
   fantasai: If I do absolute something and the scroll container is
             relpos I can scroll.
   dbaron: Per spec it should be relative to height without scroll but
           I'm not sure that's what people implement.
   dbaron: Adjusted by size of scrollbars if you have to adjust for
   fantasai: Bottom edge of the abspos position container does not
             include the overflowing content. If the thing does
             overflow then things are weird are drawn below that
   TabAtkins: In chrome assuming scroll container is abspos and is
              right:0 bottom:0 the abspos is in the bottom right.
   dbaron: Before you scroll.
   dbaron: If it's causing the overflow do you scroll?
   fantasai: You only add the padding to the inflow content.
   <rego> check chromium behavior in:

   dbaron: But if a child of the scroll container is relpos but it has
           children that are abspos do you scroll?
   ??: Do abspos children of relpos contribute to the overflow
       characteristics of it's parent?
   dbaron: That's how we impl.
   TabAtkins: We do not add padding if the abspos is the overflowing.
   dbaron: Now for abspos you need to track this deep.
   fantasai: When you calc height of box and you scroll to the last
             thing that's inflow and you add padding below that thing,
             that's your direct child. There may be a deep nested thing,
             but we're not looking at that.
   dbaron: Gecko used to do that but that's different then what I think
           we're saying. The other difference is if you have a scroll
           container and has an explicit height container and that
           overflows, do you add padding there.
   fantasai: Don't think so.
   fremy: Made a test case and it's worse then that.
   <rego> this is the output of my example before:
          https://i.imgur.com/PQZ775X.png (edge behaves like firefox
          and webkit like chromium)

   fantasai: As an author I don't expect an abspos to respect the
             padding but I do expect things in-flow remain inside the
             mat that's around it.
   dbaron: You're changing the model. I thought model was you have
           overflow, add padding around that, and then you overflow.
   fantasai: Then we added abspos.
   dbaron: But I think my model is simple. You figure out what the
           scrollable overflow area of all descendants is and then you
           add the padding and that's the area you add the scroll to.
   dbaron: Abspos children are relative to the padding as if inside the
           viewport and then those are placed in the scrollable area
           which is probably on top of where it was before in the
   dbaron: This is what gecko impl and dev don't like.
   myles: In this model some things are inside the viewport.
   florian: I'm not disputing this may be nice, but doesn't that cause
            overflow where you don't expect it? Spec I believe that
            creating scrollbars too often is why chrome only does it in
            some cases because it would make scrollbars everywhere
            which people hate.
   fantasai: dbaron problem with your model is I have a position
             relative scroll container I put an abspos in the bottom
             right in your model it triggers padding. If the padding is
             2em then we add 2em padding and create all this scrolling.
   dbaron: I buy that for abspos positioned relative to the scroll
           container. I don't for things relative inside the scroll
   fantasai: Okay.
   dbaron: Did we test that?

   florian: Are you not worried that it would create lots of scrollbars?
   dbaron: It's worrying. An actual proposal with details would be good
           before resolve.

   <fantasai> http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=5910
   fantasai: test case dbaron proposed ^
   dbaron: You can't scroll to the thing at all
   astearns: I'm worried you said this is what we used to do and dev
   dbaron: It's because it's not what spec said to do and partly
           because dev said it didn't yield expected but it does work
           as expected in the other case where we were wrong.

   astearns: We need to come up with a proposal for how to deal with
             scroll container padding and then evaluate the full
             proposal with spec text.
   astearns: Amend previous resolution to say we will try to define a
             way to make scroll padding work in block and inline for
             all cases in a way that breaks the web.
   fantasai: If previous is in-flow content I think we're scoped okay.
   myles: Not if we're doing investigation. You're doing 1/4 of the
   fantasai: But people want this 1/4 to work and it has web compat.
   fremy: If we don't have a model that's clear we'll impl and then
   myles: Agree it's wasted work.
   astearns: I suggest that we draft the whole model and the portion
             that's easy and see if it makes sense to do the easy part
   astearns: I think we need spec text first.
   florian: Mostly sounds good to me. I thought in previous discussions
            someone from blink stated that they're only extending
            padding in some cases is because it's not web compat.
   TabAtkins: It's not written anywhere to...and I don't remember it,
              so I dunno.
   <fremy> http://software.hixie.ch/utilities/js/live-dom-viewer/saved/5911
   <fremy> ^ testcase with abspos in inline relative
   fantasai: Some of these cases will be exploratory to figure out
             what's web compat.
   astearns: Proposal: Undo the previous resolution and continue to
             figure out a whole model.

   RESOLVED: Undo the previous resolution and continue to figure out a
             whole model.

   <br type="15min">

Received on Tuesday, 29 May 2018 20:03:43 UTC