- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Sat, 23 Dec 2017 10:02:11 -0500
- To: "www-style@w3.org" <www-style@w3.org>
=========================================
These are the official CSSWG minutes.
Unless you're correcting the minutes,
Please respond by starting a new thread
with an appropriate subject line.
=========================================
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
#1075)
- RESOLVED: Behavior already defined in CSS Fragmentation; reference
that and file any further issues there. (Issue #1894)
===== FULL MINUTES BELOW ======
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
possibility.
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
consistent.
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
spec.
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
wrong.
Note: Previous WG discussion on ::selection was
https://lists.w3.org/Archives/Public/www-style/2014Dec/0299.html
<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
-----------------------------------------------------
https://github.com/w3c/csswg-drafts/issues/1738
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
omitted.
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
defined.
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
issue.
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
view.
fantasai: It is what I'd expect to happen, and it is what
implementations seem to do. Makes sense to specify that
behavior.
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
context.
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
split.
[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
border?
[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
already.
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
pagination...
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
out]
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
spanner?
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