[CSSWG] Minutes Paris F2F 2017-08-04 Part I: CSS Shadow Parts, Review of TTML, CSS Break: Consider adding clone-most-nested [css-break]

=========================================
  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 Shadow Parts
----------------

  - TabAtkins presented his proposal for a spec called Shadow Parts
      (available here: https://tabatkins.github.io/specs/css-shadow-parts/ )
  - RESOLVED: Move CSS Shadow Parts to WG ED space.

Review of TTML
--------------

  - Nigel joined the group to talk over the request for review on
      TTML2 and to talk over the areas where TTML and CSS overlap:
      https://www.w3.org/wiki/TTML/CSSRequirements
  - The CSSWG will meet with TTML during TPAC.

CSS Break: Consider adding clone-most-nested
---------------------------------------------

  - After discussing the use case more, the group agreed it was a
      good thing to solve, but the exact details of the use case
      requirements were unclear, and TTML needs to clarify.
      Proposal: https://github.com/w3c/csswg-drafts/issues/1633

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

Agenda: https://wiki.csswg.org/planning/paris-2017#topics

Present:
  Rachel Andrew, Invited Expert
  Rossen Atanassov, Microsoft
  Tab Atkins, Google
  Brian Birtles, Mozilla
  Bert Bos, W3C
  Tantek Çelik, Mozilla
  Dave Cramer, Hachette Livre
  Emil A Eklund, Google
  Elika Etemad, Invited Expert
  Rob Flack, Google
  Daniel Glazman, Disruptive Innovations
  Koji Ishii, Google
  Dean Jackson, Apple
  Ian Kilpatrick, Google
  Peter Linss, Invited Expert
  Myles C. Maxfield, Apple
  Jack Moffitt, Mozilla
  Naina Raisinghani, Google
  Francois REMY, Microsoft
  Melanie Richards, Microsoft
  Florian Rivoal, Vivliostyle
  Simon Sapin, Mozilla
  Till Schneidereit, Mozilla
  Geoffrey Sneddon, Invited Expert
  Alan Stearns, Adobe
  Surma, Google
  Jet Villegas, Mozilla
  Greg Whitworth, Microsoft

Regrets:
  Jihye Hong, LG Electronics
  Dael Jackson, Invited Expert
  Chris Lilley, W3C
  Simon Pieters, Opera
  Hiroshi Sakakibara, Beyond Perspective Solutions
  Lea Verou, Invited Expert

Scribe: tantek

CSS Shadow Parts
----------------

  TabAtkins: (summarizes previous work)
  TabAtkins: (shows https://tabatkins.github.io/specs/css-shadow-parts/ )

  TabAtkins: Deep combinator was too powerful.
  TabAtkins: Works for transferring single values-
  TabAtkins: terrible for outside of that.
  TabAtkins: In particular one element, e.g. heading part of your
             warning message
  TabAtkins: you have to expose a lot of custom properties
  TabAtkins: theoretically all 300+ CSS props
  TabAtkins: then xfer each one by one.
  TabAtkins: Worse if you try to style pseudos
  TabAtkins: huge combinatorial problem
  TabAtkins: variables fall down quickly if you want to allow ...

  TabAtkins: This proposal (https://tabatkins.github.io/specs/css-shadow-parts/)
             that Shane and I wrote up
  TabAtkins: for letting authors expose an entire element from their
             shadow dom to other parts of the page.
  TabAtkins: This would go into the dom spec
  TabAtkins: we'd add some pieces.
  TabAtkins: (shows feature in spec)
  TabAtkins: Important part in CSS, two new pseudo-elements that
             appear on any shadow host
  TabAtkins: ::part() and ::theme()
  TabAtkins: (summarizes proposal from link)
  TabAtkins: Do allow some pseudo-classes on them
  TabAtkins: but can't depend on anything to do with the DOM tree,
             e.g. no ::part():first-child.
  TabAtkins: One aspect of vars that is available to preserve is
             that they do allow you to target things further down in
             the tree
  TabAtkins: useful in practice for authors right now.
  TabAtkins: ::part() is one level, ::theme() is what this component
             chooses to expose plus what all its subcomponents
             choose to expose.
  TabAtkins: In general ::part is better to do, helps with
             encapsulation. But ::theme helps you do what variables
             do.
  TabAtkins: (shows example of a custom button)
  TabAtkins: There are some suggestions for more features, e.g.
             elements may want to censor
  TabAtkins: e.g. give theme ability to exclude certain elements
             from being exposed.

  TabAtkins: This is ready for FPWD.
  fantasai: ED?
  TabAtkins: Comments?
  TabAtkins: I'd like to pursue this in the public repo, right now
             it is just in my personal github
  TabAtkins: at the very least as an ED.
  TabAtkins: Also ready for FPWD if group is ready for it.

  glazou: Part is always exposed?
  glazou: But you need to expose it outside the shadow DOM?
  TabAtkins: Yes that is exactly the point.
  glazou: I understand the point, I'm puzzled that we need to add an
          attribute for that.
  glazou: Part serves same purpose as class.
  TabAtkins: But we don't want to expose arbitrary class(es)
  astearns: We don't want to expose arbitrary class(es), why don't
            we say component say these classes that are allowed to
            style
  astearns: and then the selectors styling in the component could
            look like the selectors outside.
  glazou: I have another suggestion, give a list of attribute
          selectors, name and value
  <glazou> [class|="foo"], [part]
  plinss: but then you're ...
  glazou: unless ...

  plinss: what's in the ... is not just the ... not just in the
          shadow tree, but something that is deliberately exposed
  plinss: and then propagate these things up to the root
  plinss: this is basically what I wanted but just wanted pseudos...
  plinss: Can we do structure?
  TabAtkins: No.
  plinss: It flattens the entire shadow tree?
  TabAtkins: Yes, because exposing the entire structure exposes too
             many details
  plinss: ... so I'm fine with that.

  fantasai: I don't understand the use case for theme.
  TabAtkins: vars right now can be used to target an arbitrary depth
             down the shadow tree
  TabAtkins: same thing that theme does.
  TabAtkins: Part gives you only one level.
  TabAtkins: Not currently a way to block theme like vars.
  fantasai: Why?
  TabAtkins: e.g. to theme custom buttons regardless of where they
             are
  TabAtkins: just by setting vars.

  fantasai: Second question is ...
  fantasai: just wondering if ryosuke has read your draft.
  TabAtkins: He has but doesn't like theme.

  fremy: Why can we just not create a namespace of classes that we
         expose?
  fremy: Instead of a new attribute
  fremy: classes that start with ...
  TabAtkins: Possible, but class has traditionally be treated as a
             user (author) space thing, and we don't introspect on
             the internals of class name.
  fremy: It seems like a bad idea to have to use part and class.
  TabAtkins: Class for internal styling, use part for how external
             world can see you.

  dbaron: I'd be in favor of this moving to ED space.
  dbaron: The structure thing that plinss brought up could use some
          more examination.
  dbaron: I can imagine different things that all expose the same
          piece instead
  dbaron: and you'd want to expose that instead of having to mirror
          the names.
  TabAtkins: Yes that is possible, trying to hit the minimal case
             right now.
  TabAtkins: Can carefully expose more structure.
  plinss: Stack of custom elements?
  TabAtkins: Each pseudo can expose its parts
  dbaron: no particular reason author needs to know your buttons are
          x-button vs button.

  dbaron: One other point, I find the part and theme names confusing
  TabAtkins: Which part? (lol)
  dbaron: The fact that they are very similar, but have very
          different names that don't tie them together.
  TabAtkins: like because "theme" doesn't indicate it is like "part"?
  <gregwhitworth> maybe ::parts()

  dauwhe: I certainly support ED on this.
  dauwhe: We have this problem in the ebook world
  dauwhe: publishers creating styles
  dauwhe: need users to override parts of it but not all.
  dauwhe: We run into lots of problems with the cascade
  dauwhe: trying to allow user to control P but not H.
  TabAtkins: ... inside shadow vs outside shadow
  (explains how to solve it)

  Rossen: So I heard a few in favor of moving to ED to begin with
  <fantasai> +1 to ED

  Bert: I have a question.
  Bert: Not sure I understand how you expose part.
  Bert: Do you need pseudo at all?
  TabAtkins: The button already has children, the may or may not be
             exposed.
  TabAtkins: You can take the actual dom children and pull them into
             the shadow dom
  TabAtkins: and two, letting you use the descendant combinator
             implies you can use child combinator.
  Bert: Not at same level.
  TabAtkins: I would find that a little bit ...
  TabAtkins: big one is that child and descendant combinators
             already match the actual children.
  Bert: namespace issue ok
  TabAtkins: Pseudo gives you a clear context about what you're
             matching.
  <TabAtkins> Because of how the cascade works for rules originating
              inside the shadow vs outside the shadow, you can
              prevent the outer page from manipulating particular
              properties on an element by just setting them from
              inside the shadow dom.

  plinss: One thing I like about pseudo approach, in the ExtWeb
          approach, you can use ... to explain pseudo ...
  plinss: I can explain that that was a ... element all along.
  TabAtkins: Our inputs are implemented with shadow dom.

  TabAtkins: Any objection to ED space?
  Rossen: Does anyone?
  Rossen: Doesn't seem like it. go ahead and move it.

  RESOLVED: Move CSS Shadow Parts to WG ED space.

  Rossen: ... ?
  TabAtkins: The part attr will go into the DOM spec; the
             pseudo-elements will go into the Scoping spec.

Review of TTML
--------------
  Scribe: fantasai

  Rossen: We have Nigel joining us on the call.
  Rossen: Asked a few weeks ago to review TTML current WD.
  <Rossen> https://lists.w3.org/Archives/Public/www-style/2017Jul/0007.html
  Rossen: Some back and forth over email.
  Rossen: Provided feedback, first time by dbaron, 2nd time by
          Florian.
  <tantek> See also dbaron's review
           https://lists.w3.org/Archives/Public/www-style/2016Nov/0106.html

  Florian: Feedback I wrote wasn't sent to TTML, sent to us to
           decide if it was my position our position.
  Florian: We haven't resolved on that officially.
  Rossen: Would you want to summarize?
  Florian: Roughly very similar to what dbaron said half a year
           earlier.
  Florian: Didn't review anything other than style and layout, but
           for this part.
  Florian: You have a system that is very similar to CSS, but isn't
           CSS
  Florian: Some attributes take the same syntax, but have different
           semantics
  Florian: Some take a superset, some take a subset, some overlap in
           both ways
  Florian: We could do a mapping, but different semantics is a
           problem
  Florian: E.g. 'line-height' defines the height of the line box in
           CSS, in your case it defines the spacing between
           baselines which is similar but not quite the same
  Florian: Other times you and we solved the same problem in
           parallel and came up with a different solution
  Florian: e.g. your alignment properties are different from ours.
  Florian: You can't really map to CSS, you can try but because of
           these differences, will come out wrong
  Florian: Implementing TTML will be completely different from
           implementing CSS
  Florian: Browsers have a CSS engine
  Florian: If not compatible with CSS, unlikely to work out
  Florian: There's a rough mapping in an informative part, but it's
           not really going to work.
  Florian: I understand the history of starting from XSL:FO, but
           that's dead for client-side on the Web.
  Florian: Out of context, it might be a good technology, but in the
           context of the Web it's hard to fit.

  nigel: Fair summary
  nigel: Interested in specifics of line height issue
  nigel: One thing, you mentioned an informal document that brings
         out correspondences to CSS
  nigel: Here's a link
  <nigel> -> https://www.w3.org/wiki/TTML/CSSRequirements
  nigel: We did quite a bit of this analysis.
  nigel: We used dbaron's and your feedback (which we found).
  nigel: Absolutely right that the syntax is different.
  nigel: For us, compatibility with previous versions is important;
         breaking would be a problem for us
  nigel: a lot of the target devices are not browsers
  nigel: but there is a growing recognition that being able to
         render with CSS would be a good idea.
  nigel: So there has to be a syntactic mapping, but wrt semantic
         mapping...
  nigel: We discussed with TAG recently, and they had useful view
         that we should describe the mapping into CSS for this to be
         useful implemented.
  nigel: Question of whether this mapping should be normative,
         unsure how much real world difference it makes.
  nigel: Other recommendation from TAG was that if there were
         styling requirements
  nigel: then it would be really helpful if there were CSS
         equivalents.
  nigel: If things that we need in subtitle / caption word aren't in
         CSS, we ask CSSWG to add them
  nigel: this makes it easier to implement with a CSS backing.
  nigel: If we can get to any detail, even offline, want to know
         e.g. differences in line height semantics.

  myles: I guess, we've looked into this a bit and our findings
         align with Florian's findings.
  myles: Our conclusions are in line with Florian's conclusions.
  myles: We would be hesitant to implement if not aligned with CSS.
  (Myles represents Apple, works on WebKit)

  Florian: Wasn't on TAG, don't know what they said
  Florian: But rather than have you define things and us define
           things in parallel
  Florian: better to define in terms of CSS, and if something's
           missing, then we add it.
  Florian: Wrt subtle differences, determining how subtle secondary,
           if they are normatively defined independently
  Florian: then there will be differences, and even small
           differences are problems in deployment.
  Florian: Differences between different and broken are subjective.
  Florian: If the syntax layer needs to be different, this is a
           minor annoyance but fine
  Florian: But in terms of semantics, don't redefine separately
           what's already defined in CSS
  Florian: file bugs against us to add things.
  Florian: Could go through long list of details on every property
  Florian: I took line-height as an example
  Florian: but given you have normative prose, there are bound to be
           differences.
  nigel: I understand where you're coming from.
  nigel: From TTML WG PoV, it's not always so obvious how to add
         things to CSS
  nigel: but also there is pressure to get a new version of TTML
         out, and if we had to wait for CSS, wouldn't be able to
         satisfy our community.
  nigel: TTML2 could be seen as a req document, and align with CSS
         later.

  nigel: I've not heard any dissent from view that these reqs need
         to be met.
  nigel: So assuming there is a requirement, we do need to support
         them in subtitles and captions world.
  nigel: As soon as we have access to CSS definitions we can add
         them back in.
  nigel: There is time, actually
  nigel: We're in WD at the moment, the review ends in September
  nigel: we wouldn't be in CR until after TPAC.
  nigel: If there is an opportunity to get some features specified
         in CSS, could contribute to that in some way
  nigel: then there is time to fill some of these gaps.
  nigel: Most important ones that would be useful:
  nigel: filling line gap
  nigel: text-representation for ideographic scripts
  nigel: ruby
  nigel: fontShear
  nigel: these would be useful
  <Rossen> https://www.w3.org/wiki/TTML/CSSRequirements#disparity
  <Rossen> https://www.w3.org/wiki/TTML/CSSRequirements

  astearns: Not time to define new things in CSS, but time to review
            list of places where you're unsure if there's
            concordance.
  astearns: I saw some things, e.g. where we do have the feature.
  astearns: Would be nice to have semantics map, and syntax if
            possible.
  astearns: Would be good to have someone from group review list to
            check for actual gap.

  Florian: We have a bit of precedence with this, with EPUB
  Florian: Where they couldn't quite wait for us.
  Florian: This is overall not a story that ends very well.
  Florian: Similarly to your situation, not all EPUB readers are
           browsers, but kinda.
  Florian: When you ask to support things that are not CSS but kinda
           it's problematic.
  Florian: Originally they asked us for stuff, and if we didn't
           deliver fast enough they tried to define their own thing
  Florian: But realized that doesn't work, so now are planning to
           just bug us to prioritize and fix things

  Florian: Wrt differences we were discussing
  Florian: I wonder if it's worth doing, if we don't go all the way
           in.
  Florian: If we can bring it to the point that browsers can
           implement
  Florian: Then it's worth it.
  Florian: But if it's not possible to implement in browsers, then
           making it less different is maybe not so useful.
  nigel: wrt displaying in browsers, they do.
  nigel: TTML has a profile IMSC
  nigel: one of the implementations is a JS implementation with CSS.
  nigel: Clearly there's a desire to present subtitles in browsers.
  nigel: I imagine same would be true for TTML2.
  nigel: Experience of editor of IMSC had with creating imsc.js was
         that he had to work around limitations of CSS quite a bit
  nigel: e.g. putting each character in its own span to tweak its
         position.
  nigel: Some easier things to fix, like box-decoration-break
  nigel: possibly just understanding layout options in CSS better
         would help.
  nigel: As you guessed, ppl will want to map to browsers better
  nigel: browsers natively doing is maybe ???
  nigel: Making decision based on whether browsers want to natively
         present TTML is maybe a step too far
  nigel: just about whether to present TTML at all, e.g. using JS
         libraries.

  jet: It seems like we're a bit torn in that browser vendors see it
       as obvious to render TTML using our existing layout engines
  jet: but the consumers of TTML might want custom layout in the
       future
  jet: e.g. never render markup in front of a face, where browsers
       wouldn't even know where to start.
  jet: Need to innovate in ways beyond just render text in a fixed
       location.
  jet: Want to align on things like text rendering
  jet: but polyfill things that we wouldn't know where to start
       dealing with.
  nigel: Avoiding faces is done by author positioning
  nigel: but sounds really cool

  nigel: Have a question to you,
  nigel: TAG said it would really be good if CSS would support
         requirements.
  nigel: Is that something you concur with?
  Rossen: So long as the feature requirements that are specific to
          CSS come to us fit to overall model of what we're doing
  Rossen: as long as they are coming as requests we will definitely
          review and consider
  Rossen: for those that don't, not much we can do.
  Florian: For those already in the spec, you have a solution
  Florian: But for us what would be most useful is not to tell us to
           support the solution of the TTML group, but to take a
           step back and tell us the use case.
  Florian: Maybe the way you solved it is a perfect fit for CSS,
           maybe it's not but another approach would work.
  Florian: Question is does the thing you care about fit into CSS?
  Florian: If so then maybe it will influence what we do in CSS,
           either importing wholesale or adjusting the capabilities
           otherwise
  Florian: Having only the solution without understanding the use
           case would not help very much.

  nigel: One more thing to add... sounds like there are some actions
  nigel: Whatever those actions are, we've set aside time at TPAC
  nigel: best day for us would be Friday
  nigel: set aside time to invite to join us
  nigel: to hopefully come to some resolutions.
  nigel: Will send a formal invitation.
  nigel: Could also do Thursday if preferred.
  Rossen: We have some requests pending for TPAC, I believe Thursday
          is mostly gonna be for CSS Houdini meetings, so that's
          likely to fill the day.
  Rossen: Haven't settled on Thursday or Friday, so depends on that.
  Rossen: Already have some a11y and few more groups that want to
          meet with us.
  Rossen: But definitely send an email.

CSS Break: Consider adding clone-most-nested
---------------------------------------------
  Scribe: TabAtkins
  github: https://github.com/w3c/csswg-drafts/issues/1633

  fantasai: We had a request from Nigel to add a value for the
            box-decoration-break property. Can you explain?
  nigel: Imagine you're displaying subtitles, and for a11y you want
         to put a high-contrast background behind the text. Not on
         the whole <p>, just behind the lines.
  nigel: You don't want the background to be tightly wrapped to the
         text edges - you want it to extend slightly out for
         readability.
  nigel: But you cant predict the linebreaks.
  nigel: That's okay right now with box-decoration-break: clone
  nigel: But then what if you have a span in the middle of the text
         with a different color background.
  nigel: And the break falls in the middle of that other span.
  nigel: You want the span's background to be what extends; you want
         to use padding to display that.
  nigel: So the most relevant background color to "extend" is from
         the innermost element at the break, not the element that
         sets box-decoration-break.

  nigel: fantasai asked a good question.
  nigel: Should it be "most nested" or "most nested thing that
         *counts", paraphrasing.
  fantasai: I think we have this problem generally with
            fragmentation.
  fantasai: At the break, you want to have a little bit of extra
            padding with the background beneath it.
  fantasai: It's possible that maybe we can solve this by just
            saying "add this amount of padding at the break".
  fantasai: Whether that solves this is, do you need borders too? Or
            just backgrounds.
  fantasai: Like a border around the inline that only closes if it's
            the innermost nested border?
  fantasai: Seems weird, I guess not.

  nigel: I think for border-radius you want [...]?
  fantasai: If both have border-radius; normally we'd just slice and
            get the green and black backgrounds overlapping each
            other on a clean break.
  fantasai: If only the green gets a border-radius, you'll see the
            black background peeking out from under the green.
  fantasai: That's a problem.

  <dbaron> a general 'break-padding' property sounds like it could
           be useful...
  <fantasai> dbaron, yeah, that's what I was thinking. But it
             doesn't solve the border-radius case he was describing

  <astearns> I think it would be helpful to have a diagram in
             https://www.w3.org/TR/ttml2/#style-attribute-inlineAreaBreak
             that showed a rendering using each value for cases
             where there's a difference

  Rossen: I think this is in conjunction with the line-padding
          property in TTML, right?
  nigel: Yeah.
  Rossen: Box decoration and fragmentation, you're talking about
          linebreaking, not general box breaking
  TabAtkins: It can be about boxes too.
  Rossen: Sure, but that's not his requirement.
  Rossen: Also something we don't have in CSS is line-padding that
          extends in every break.
  nigel: Line padding was introduced to IMSC when border-radius
         wasn't available in TTML; at that point the only styling
         you could do was background-color and get a square box.
  nigel: Now with border-radius it's gotten more complicated, and
         probably need to extend it a little further than just the
         line-padding semantic, to include the other background
         effects (or things that otherwise affect the background).
  nigel: Your point about targeting line areas specifically is well
         made.
  nigel: If there was a way to say "for each line in this <p>, apply
         this styling" that would be really helpful, but that
         doesn't seem to exist yet.
  <Rossen> Here's nigel's example
https://github.com/w3c/imsc-tests/blob/master/imsc1/png/linePadding2/0.000000.png
  fantasai: I think it would be relatively easy to describe a ::line
            pseudo if the only things that work are background and
            things on the line box like background.
  fantasai: Once inheritance applies it's hard.
  fantasai: We have this problem with ::first-line; it's a mess,
            lots of bugs, spec isn't precise enough despite our
            efforts.
  fantasai: But if it's just about "background here, put a
            border-radius on it", it's not too hard.
  fantasai: Not high priority to do in browsers, but wouldn't be too
            hard.
  iank: We don't have an architecture that can support that (styling
        lines individually). It's several years away.
  Rossen: The existing model of line boxes in most impls, certainly
          in Edge, is not easily expendable to support this. Not
          impossible, but it would be quite hard.
  Rossen: Though this is a valid use-case and feature.

  fantasai: What's line-padding?
  Rossen: Imagine you have a span - I posted one of Nigel's examples
          (https://github.com/w3c/imsc-tests/blob/master/imsc1/png/linePadding2/0.000000.png
)
          - that adds background to the current inline. And the span
          breaks. You can put padding on the span - you'll get
          padding at the start and end of the span. If it fits on
          one line, great; the background will extend a little past
          the text.
  Rossen: But if the text breaks in the middle, you have some
          padding on start of first fragment and end of last
          fragment, but all other broken edges have no padding.
  Rossen: line-padding feature adds padding to every break-edge.
  Rossen: Basically to the linebox itself.
  Rossen: If the linebox has background, it extends.
  fantasai: The linebox is wider than that actually, but I get what
            you're saying.
  fantasai: That makes sense, and I see how adding border-radius
            would be tricky.
  nigel: Doing just the inline-padding isn't the only place we want
         to do something with line areas.
  nigel: Another feature, fill-line-gap, says "draw background areas
         between lines".
  nigel: Hard now, because character heights are UA-dependent.
  nigel: So can't specify a padding-top/bottom that correctly fills
         in the space between lines.

  fantasai: Question I have - you have a line of text with some
            line-spacing, say 1.5. You're seeing there's a
            background under the text, and a .5em gap between the
            lines.
  fantasai: When asking to fill the linegap, you're filling that
            .5em space, what happens at the top and the bottom? Do
            you add .25em at each? So each line gets .25em of
            background above and below? Or just between the lines?
  nigel: At the moment we don't say.
  fantasai: Ok, that's a really important question to answer if we
            need to add this to CSS.

  fantasai: Second question, if two lines have different lengths,
            what happens?
  nigel: Probably we take whatever answer is most convenient.
  nigel: But as far as I know you can't set a padding value, because
         you can't calculate it...
  <nigel> https://github.com/w3c/csswg-drafts/issues/814
  fantasai: We should specify how the content box is calculated.
  TabAtkins: Why's it hard? Just the difference between font-size
             and line-height, right?
  fantasai: Not quite - the background area isn't the size of the
            line height box of the inline that's used for layout.
            The area around an inline - in 2.1 there were two ways
            to calculate the area, based on font metrics, and impls
            might do different things.
  Rossen: This is going a bit off topic, can we bring it back to
          box-decoration-break?

  TabAtkins: So it sounds like box-decoration-break: inner-clone
             badly solves border-radius issues, and limiting it to
             just background is better solved with a break-padding
             property?
  <fantasai> break-padding also causes problems with border-radius
  fantasai: So I think those are the main two request from Nigel,
            this and figuring out the fill-the-gaps issue.
  fantasai: Which I think is best done by making impls
            interoperable, then just using padding on the element.
  fantasai: If we have a consistent box height, then having a
            line-height of 1.5 and a padding on inline of .25em
            above and below *should* fix the gap; if it doesn't, we
            should fix that.
  fantasai: And for the other issue of cloning spaces - it seems the
            solution you're proposing doesn't actually solve the
            problem.
  fantasai: It's not just "clone most nested"; if there is
            border-radius involved, you want to copy that innermost
            border-radius all the way up, so the lower backgrounds
            don't show up underneath the top-most's border-radius.
  Rossen: So yeah, the feature request is something we'll work on,
          probably as part of Break. We'll go from there!

Received on Friday, 1 September 2017 12:50:50 UTC