W3C home > Mailing lists > Public > www-style@w3.org > December 2017

[CSSWG] Minutes TPAC F2F 2017-11-07 Part IV: Constructible Style Sheets, ::selection cascade, Multicol [css-pseudo][css-multicol]

From: fantasai <fantasai.lists@inkedblade.net>
Date: Sat, 23 Dec 2017 10:02:11 -0500
To: "www-style@w3.org" <www-style@w3.org>
Message-ID: <109e0d41-85ad-056b-018a-80078446bb62@inkedblade.net>

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

Constructible Style Sheets

   - RESOLVED: Start working on constructible style sheets in WICG

CSS Pseudo Elements

   - The ::selection cascade issue (https://github.com/w3c/csswg-drafts/issues/374 )
       skipped, since issue was filed with incorrect conclusions.

CSS Multicol

   - RESOLVED: Apply proposed edit from Oct 2013 to spec.
        - Text from Issue #1739: Column rules are painted just above
            the border of the multicol element. For scrollable multicol
            elements, note that while the border and background of the
            multicol element obviously aren't scrolled, the rules need
            to scroll along with the columns.
   - RESOLVED: Remove sentence 2 and 3 and adding clarification about
               the principal box. (Issue #1738)
   - RESOLVED: Remove example XVII: "If a tall image is moved to a
               column on the next page to find room for it, its natural
               column may be left empty. If so, the column is is still
               considered to have content for the purpose of deciding
               if the column rule should be drawn."
   - RESOLVED: column-span applies to elements lower than the first
               level of descendants as long as it's part of the same
               formatting context. (Issue #1072)
   - RESOLVED: If the fragment before the spanner is empty, nothing
               special happens; the top mbp is above the header, and
               it's just an empty fragment.
   - RESOLVED: autofill rebalancing applies to the immediately
               preceding column row of a spanning element only. (Issue
   - RESOLVED: Behavior already defined in CSS Fragmentation; reference
               that and file any further issues there. (Issue #1894)


Agenda: https://wiki.csswg.org/planning/tpac-2017#proposed-agenda

Scribe: eae

Constructible style sheets
   document: https://tabatkins.github.io/specs/construct-stylesheets/

   ericwillinger: Common use case is with shadow dom. People will
                  construct a stylesheet inside a shadow root. Creates
                  a thousands of stylehseets.
   ericwillinger: Could have browser logic that shares them. A better
                  way might be to have a js api to explicitly share it.
   TabAtkins: We'd like style sheet parsing to be async. Will decide
              later between an async constructor or factory functions.
   astearns: dglazmen had some comments he wanted me to forward: He's
             really happy and wants to use it right away.
   astearns: If you have a doc with a style node, he'd like to be able
             to add a style to the document through that.
   TabAtkins: Want to be able to replace a stylesheet with a
              constructed one?
   astearns: Yes, and further also for link elements. The link element
             question could remain open but he'd really like it for the
             style element.
   TabAtkins: One of the issues with applying styles to shadow roots is
              wanting to apply them to all shadow roots. You want to
              apply UA styles that are easy, trivial, to override. One
              possibility for that is defining another origin that
              lives just before author style. Might be done with
              constructor for constructible style sheets.
   TabAtkins: Some discussion in shadow dom around this. This is one

   Rossen: Do you need a resolution?
   TabAtkins: More than one implementor is usually needed. Any takers?
   TabAtkins: We have a consumer, which is useful, but no other
              implementor as of yet.
   dbaron: Don't know yet.
   smfr: Seems interesting, not high priority at the moment.
   Rossen: On edge side, not opposed to it but it's interesting and
           needed. Not a priority at the moment.
   Rossen: So two interested parities but no commitments.

   RESOLVED: Start working on constructible style sheets in WICG

CSS Pseudo Elements

::selection cascade
   github: https://github.com/w3c/csswg-drafts/issues/374

   TabAtkins: The original part of the issue: I assumed my testing had
              proven that there was a simple subset we could agree on.
              A few weeks ago Greg posted that not to be the case.
              David recently commented and linked to data dating back
              many many years.
   TabAtkins: The probable issue is that it's still more complicated
              than I though it was. We need to figure it out and be
   fantasai: We looked at this many times in the past. Once was when
             dbaron posted all options, another time was during pseudo
             discussion, when we realized we couldn't do certain
             options due to interop/web compat.
   Rossen: You're saying spec text is not accidental?
   fantasai: Yes.

   TabAtkins: My memory are hazy but I said something like "all
              browsers agree on behavior but all disagree with spec".
              We need to either update spec or change behavior.
   dbaron: When is spec text from?
   TabAtkins: In pseudo
   florian: 2-3 years old?
   TabAtkins: More than one year old.
   florian: Less than five.
   dbaron: 3.3 in pseudo spec links to substantially more info that
           lead to the text.
   TabAtkins: The point is: As far as I can tell no implementing
              matches the spec. We're trying to do more of these and
              would be good to have at least the first one match the
   TabAtkins: Someone need to write good tests for it.

   dbaron: Hard part is how the selection styles interact with each
           other across elements.
   dbaron: This is the reason gecko hasn't unprefixed it.
   TabAtkins: The only actionable point is "make this all better", my
              original premise was ruined by you all pointing out I was

   Note: Previous WG discussion on ::selection was

<br type="15min">

CSS Multicol

z-order of column-rule and column scrolling
   github issue: https://github.com/w3c/csswg-drafts/issues/1739

   rachelandrew: These first three issues are ones I dug out from the
                 mailing list archive. They're all quite old.
   rachelandrew: Things we've discussed, not sure what to do so
                 bringing them up here.
   rachelandrew: First one. z-order for column scrolling.
   rachelandrew: Suggested change to wording.
   rachelandrew: Is this something we want to add into the spec or do
                 we need to discuss it?

   florian: Do we have interop on the proposed wording?
   rachelandrew: There is an issue with overflow which as resolved a
                 while ago, interop on the issue across browsers as far
                 as I can tell.
   rachelandrew: Firefox does not support spanning.
   Rossen: Firefox is different due to that.
   rachelandrew: Right, relating to the fact that they haven't
                 implemented it.
   florian: The things that is linked to is not a minimized test case.
            Is an example.
   rachelandrew: Correct.

   Proposed resolution: Apply proposed edit from Oct 2013 to spec.
   florian: A minimal test case would be good, but I'm fine with it.
   Rossen: There is one in the github issue.
   rachelandrew: I'll add a test as part of spec change.
   florian: I volunteer to review it.

   RESOLVED: Apply proposed edit from Oct 2013 to spec.

Text describing column boxes as block container boxes

   rachelandrew: This is another text change for column boxes.
                 Basically there is a section in the spec, example 9,
                 about container boxes.
   rachelandrew: There was a proposal to have the second sentence to be
   rachelandrew: There was no objections yet no edit took place. Looks
                 like it was dropped.
   rachelandrew: Idea of containing block not defined in spec.
   TabAtkins: I agree, go ahead and kill second sentence
   <TabAtkins> Kill "That is, column boxes behave like block-level,
               table cell, and inline-block boxes as per CSS 2.1,
               section 10.1, item 2 [CSS21]."

   rachelandrew: Should we remove either or both of these sentences?
   florian: Remove 2nd and 3rd?
   fantasai: I don't think we should remove the 3rd.
   TabAtkins: Default case applies.
   florian: This might be read as shutting down other properties that
            could apply unless specified.
   fantasai: Behavior when you apply position relative needs to be
   TabAtkins: Doesn't turn column boxes into abs containing blocks is
              fine, makes sense, should be explicitly informative. As
              written it is bad and should be removed.
   rachelandrew: A clarification would be useful.
   fantasai: It might help to clarify that the multicol container is
             the principal box (not mentioned in spec) and that the
             column boxes are anonymous.
   fantasai: For example position: relative doesn't apply to column box.
   rachelandrew: Makes sense to me.
   Rossen: Super good clarification. We all know this yet it isn't
           mentioned anywhere.
   Rossen: Common source of confusion.

   rachelandrew: What are we suggesting to remove here? Turn third
                 sentence into a note?
   TabAtkins: Yes, and also make it clear that it clarifies that
              nothing you do on the column box...
   fantasai: The part about being a principal box should go in sentence
             two. We should fix that.
   fantasai: We don't have a good term for that box now, we refer to it
             as the multicol "element", separate issue.
   gregwhitworth: One thing that would be beneficial is having an
                  example in there. Saying principal box isn't
                  necessarily going to help web developers clarify.
   Rossen: Similar to the table example in 2.1, speaks volumes when
           people see it
   Proposed resolution: Remove sentence 2 and 3 and adding
       clarification about the principal box.

   RESOLVED: Remove sentence 2 and 3 and adding clarification about the
             principal box.

Proposal to drop example XVII
   github issue: https://github.com/w3c/csswg-drafts/issues/1740

   rachelandrew: Again, raised in 2013.
   rachelandrew: This example was dropped for reasons mentioned in
   rachelandrew: No resolution.
   rachelandrew: Perhaps needs a clearer example.
   Rossen: OK. Any opinions?

   RESOLVED: Remove example XVII: "If a tall image is moved to a column
             on the next page to find room for it, its natural column
             may be left empty. If so, the column is is still
             considered to have content for the purpose of deciding if
             the column rule should be drawn."

Column Spanning Issues
   github issue: https://github.com/w3c/csswg-drafts/issues/1072

   rachelandrew: Three issues all referring back to each other. Main
                 issue is 1072. Propose we resolve it first and then
                 refer back to it.
   rachelandrew: Quite a long issue. dbaron raised it and florian
                 commented quite a lot.
   rachelandrew: Quick summary: When you got an element with column
                 spanning and they're not a direct child of the
                 multicol box container and they're still spanning. The
                 definition says what happens to the ancestor. A good
                 example would be a section with headings and one of
                 them has span all.
   rachelandrew: Was discussed on a call in May, June, and then went
                 back to discuss on github and then stopped.
   rachelandrew: Perhaps we shouldn't allow these nested things to span.

   fantasai: There was some comments on allowing nesting of block but
             not things within another formatting context. Seems like a
             reasonable compromise.
   fantasai: I don't think it is particularly useful for it to pop out
             of a formatting context root, as long as spanners nested
             within regular block elements work. The restriction
             makes sense from a behavior and implementation point of
   fantasai: It is what I'd expect to happen, and it is what
             implementations seem to do. Makes sense to specify that
   rachelandrew: I'd be happy to draft that up, makes sense to me.
   fantasai: Happy to review spec text.

   [discussion about florian's comment in issue 1072]
   <iank> https://github.com/w3c/csswg-drafts/issues/1072#issuecomment-299097552
   <iank> ?
   fantasai: Arbitrary depths but you cannot cross a formatting context.
   fantasai: Header inside a <section> is a good example.
   Proposed resolution: Column span applies to elements lower than the
       first level of decendence as long as it doesn't cross a
       formatting context

   RESOLVED: column-span applies to elements lower than the first level
             of descendants as long as it's part of the same formatting

Background and borders for spanners
   github: https://github.com/w3c/csswg-drafts/issues/1072#issuecomment-299076034
   <nainar> Board images: https://photos.app.goo.gl/sm5cc7q8pywbSF0P2

   fantasai: What if the spanner is the very first element in an
             element that has borders and margins and paddings?
   fantasai: Is the top margin pushed to after the spanner?
   fantasai: For an inline what florian suggests in the issue that would
             be broken, what would we do in that case?
   rachelandrew: I'd like to see what implementations do at this point.
                 Haven't looked at that.

   <fantasai> http://software.hixie.ch/utilities/js/live-dom-viewer/?<!DOCTYPE html>%0A<span style%3D"border%3A solid%3B">%0A 
<span style%3D"display%3A block">splitblock<%2Fspan>%0Arest of text<%2Fspan>
   fantasai: Here is an example with a block splitting an inline. You
             can see that the border and then the split inline.
   fantasai: There is a lot of fragmentation bugs as well. Entirely
             separate pile of "fun". Right now we're only dealing with
             the multicol aspects. What are the implications for this
   [fantasai gives an example with spanners and multicol and borders]

   iank: What appears if the spanner is the first child? What do you
         want to appear before the spanner? Marking border padding?
   fantasai: Yes
   iank: Makes sense
   fantasai: I don't know if I want that, but it is what would fall out
             from it being analogous.

   <dbaron> The in-progress Gecko implementation treats it as analogous
            to block-in-inline splitting.
   <dbaron> although it's a little harder in a few ways, and a little
            different in others.

   Rossen: The example is having a section inside an element with
   [fantasi draws an example]
   fantasai: We have a multicol with some stuff and a section element,
             then we have an h2 and the h2 is a spanner.
   fantasai: The section has a border.
   fantasai: We definitively have a border around the section. The
             question is where the border goes.
   fantasai: Remember the header is inside the section.
   fantasai: First piece of border is before the split. Then you have
             the header and then the border continues.
   fantasai: If that is bad behavior we could say that this first
             empty fragment doesn't exist and then the border would
             start after the header
   Rossen: For the purpose of margin collapsing, when we take the
           spanner out of the element, the right element, assuming it
           was the only content, then margin collapsing with the red
           border would change.
   Rossen: If the element is effectively taken out of the flow of the
           containing blocks flow and then I don't see a reason why
           this element would be breaking the position of the top
           border of its parent.
   Rossen: Now that the spanner is outside of the containing block and
           margin collapsing would change, the red box in the digram
           could be pushed further down due to margin collapsing.
   fantasai: So you're saying it would normally be positioned here but
             there being no margin between them there would be no space
             between them and the margin would not be in between. I
             think that is a pretty good point, arguing for leaving it
             up here.
   rachelandrew: It is a little weird, if that was one line of text up
                 there it is still odd.
   iank: Effectively the spanner is treated as out of flow positioned?
   Rossen: Yes, pulling it out of flow is getting tricky. We're there
   iank: That would mean that margins would collapse though it.

   [something from jensimmons that was missed]

Scribe: TabAtkins

   fantasai: I think rossen's argument about the margin collapsing
             behavior is critical. Normally, the <section>'s margin top
             is never going to be between the section's header and its
             first paragraph. If we go with the behavior where the top
             fragment doesn't exist then the margin is between the header
             and first paragraph. It should be above the header.
   fantasai: That for me is the compelling argument to not do anything.
   jensimmons: I can see a use-case where <section><h2/>content is the
               proper markup for content, and for small viewport sizes
               it's styled one way, and for large it's done in this
               diagram style.
   jensimmons: I think it's fine if we let it break the section box.
   rachelandrew: I think so too. Just need a resolution for that so
                 it's tied to the spec.
   fantasai: I think this is a common situation, just question of where
             to draw top mbp; it goes above the column-span header.
   rachelandrew: Happy with that.

   RESOLVED: If the fragment before the spanner is empty, nothing
             special happens; the top mbp is above the header, and it's
             just an empty fragment.

Interaction between column-span and column-fill
   github: https://github.com/w3c/csswg-drafts/issues/1075

   rachelandrew: The multicol spec doesn't define the interaction
                 between column-fill and elements with column-span
   rachelandrew: Says content is auto-balanced across columns.
   iank: So this is - if you've got a bunch of text before the spanner,
         does it just fill the first column, or does it balance?
   TabAtkins: Examples show it balancing.
   dholbert: Not sure that's what's being asked, it's something about
   fantasai: So column-fill takes auto, balance, and balance-all
   fantasai: Balance means the last page is balanced, all the rest you
             fill the first column, then the second, etc. When you run
             out of content that'll fit (a forced break, or a big
             chunk that won't fit on the page) you just stop, don't balance.
   fantasai: balance-all means you *do* balance on all pages.
   fantasai: Auto means you don't do any balance at all.
   fantasai: column-span says if you have content before the span, the
             span is a break (like a page-break), but you always
             balance the content before the spanner.

   fantasai: So question in issue is, if you have a span in the middle
             of a page, the content after the span is balanced
             depending on the column-fill property.
   fantasai: But if there's another spanner two pages down...
   fantasai: The rule "balance the content before the spanner", does
             that apply to the previous pages ?
   fantasai: I don't think that makes sense - a page break should limit
             how far you balance.
   TabAtkins: Agree.
   fantasai: The row of boxes that get terminated by the spanner is the
             row that is forced to balance. Previous column rows don't
             balance by default (that depends on column-fill)

   Rossen: ...
   TabAtkins: The concept you're talking about is the column row
   Rossen: But not previous page
   TabAtkins: By definition those are previous column rows.
   fantasai: You can have multiple column rows per fragmentainer.
   fantasai: Generated by spanners and page breaks.
   Rossen: So autofill rebalancing applies to the immediately preceding
           column row of a spanning element.
   <dbaron> ^^ I agree

   RESOLVED: autofill rebalancing applies to the immediately preceding
             column row of a spanning element only.

   dholbert: [gives a questionable example, we're trying to figure it

How does abspos work in a containing block split by a spanner
   github: https://github.com/w3c/csswg-drafts/issues/1894
   <Rossen> https://codepen.io/rachelandrew/pen/rYeagj?editors=1100

   rachelandrew: It's not clear how abspos works when the containing
                 block is split by a spanner.
   rachelandrew: I built an example, we don't have interop, it's all
                 very strange.
   rachelandrew: How should we resolve this?
   TabAtkins: My first instinct is that the containing block is
              generated by the fragments.
   dbaron: That's the easiest to implement for us, and what we were
           planning to do unless someone disagreed.
   Rossen: It's not what we do.
   iank: We were looking at multicol and abspos; dunno if
         webcompatible, but would be nice to have the fragment that
         contains the abspos do it.
   dbaron: What's hard about that is the only case where you don't know
           the abspos cb at the time you construct it.

   TabAtkins: Situation iank was talking about earlier, a large
              containing block at the end of a column, part of it is at
              the top of the next column.
   TabAtkins: What happens there?
   dbaron: That happens during fragmentation, and this happens during
           frame construction
   dbaron: fragmentation happens during layout
   TabAtkins: CSS doesn't treat those two separately...
   TabAtkins: per spec
   dbaron: In ours you have to duplicate the logic then, in each place.
   iank: Ah, we do some layout.

   dbaron: The other two options are (1) always use first fragment, (2)
           union the fragments
   TabAtkins: Don't union, that's bad
   dbaron: I think the "per fragment" is the sanest thing. Did the
           tests show something else?
   rachelandrew: I think authors would prefer what grid does, unsure
                 what tests show
   rachelandrew: In grid, if you have an abspos grid item, the grid
                 area generates the containing block.
   rachelandrew: Unsure about usage in multicol right now.
   TabAtkins: (because multicol sucks on the web)
   iank: Is there use-cases for wanting an abspos to span across a

   dbaron: There's another set of issues we haven't resolved yet; if
           you have an abspos whose cb is part of a pagination
           sequence, and it has a large negative or positive top that
           pushes it up or down into a different fragment, I don't
           think we've defined that yet.
   iank: It would be nice if a box has fragmented, and the abspos is in
         that fragment, we consider that fragment as the cb
   fantasai: What you want is that if you have a web page in screen media
             and it's laid out all as abspos, you want it to paginate in
             a sane way--in a way that approximates the screen layout--
             and you can't get that with such a proposal.
   fantasai: We want a page that is laid out with abspos to print out
             well for the user.
   dbaron: The other model that gets you something in that direction is
           you consider the cb to be the entire fragment chain.
   TabAtkins: What's meant by that?
   dbaron: Pretend all the fragments are together; top is relative to
           first frag, bottom is relative to last, etc...
   fantasai: Yes. This is all defined in css-break-3

   florian: Can I ask what we're trying to solve here? If we want to
            solve printing pages as they exist, I think Fragmenting
            gets it right; something else, what?
   dbaron: Less about that, more figure out what engines should do for
           a feature that's already been specced for a decade.
   fantasai: I'm okay with that behavior (spanner causing the break)
             being different form the general fragmentation behavior. I
             think that's a weird case.
   fantasai: Important to make regular fragmentation make sense, though.
   dbaron: I think it makes sense to make this agree; I just didn't
           think about that when I filed the issue, because impl-wise
           it's separate in our code.

   [dbaron draws an example]
   [There are three columns, split by a spanner]
   [there's an element which starts in the second column above the
       spanner, then continues into the third column above the spanner,
       then finishes partway through the first column after the spanner]
   dbaron: If an abspos is in the element, and you say "top:0;
           bottom:0", it'll start in the second column, span across the
           third, and across the first after the spanner.
   rachelandrew: Are we happy to resolve on that behavior?
   [general agreement]
   florian: I think most of these use-cases are best solved by page
            floats, not abspos, but if you have a use-case not solved,
            please bring it up.

   RESOLVED: Behavior already defined in CSS Fragmentation; reference
             that and file any further issues there.
Received on Saturday, 23 December 2017 15:02:54 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:53:04 UTC