- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Tue, 29 May 2018 16:00:17 -0400
- 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.
=========================================
FX specs location
-----------------
- When there are FXTF issues that need WG review, editors will flag
as Needs Review. Chairs will make sure Needs Review issues are
added to telecon agenda (in an appendix as things that need review
or input, but won't be discussed on the call).
- FXTF editors may send email summarizing spec or issue statuses
to the CSSWG mailing list to bring attention to them as needed.
Publications and Editors
------------------------
- RESOLVED: New WD for Filter Effects.
- krit will create a DoC for Masking so that it can be republished.
- RESOLVED: Add ChrisL and smfr as editors to Compositing and
Blending
- RESOLVED: Editors for Geometry are krit and TabAtkins
CSS Grid 2
----------
- RESOLVED: Remove the dual-axis proposal in favor of per-axis. (Issue #2280)
- RESOLVED: Publish a new WD of Grid L2 with the removed dual-axis
proposal.
CSS Display
-----------
- RESOLVED: ::marker exists on all elements, on ::before and on
::after but no box unless it's display: list-item.
(Issue #1793)
- RESOLVED: In a block-in-inline split, the block is inside the
inline in the box tree, and is a sibling of the two
fragments of the inline in the fragment tree. (Issue
#1477)
- RESOLVED: A multicolumn spanner that splits and inline is inside
of the inline box tree and a sibling to the fragment in
the fragment tree. (Issue #1477)
===== FULL MINUTES BELOW ======
Agenda: https://wiki.csswg.org/planning/berlin-2018#schedule
Scribe: dael
FX specs location
=================
krit: There's a lack of response from CSS WG right now since these
specs are in the FXTF repo. Especially when they're mentioned.
krit: Is there anything we can do to make this more visible to CSSWG
members?
krit: Many of our issues don't need WG or a proposal can be made
before WG review. If there's anything editors can do to let
CSSWG members know their attention is needed. Elsewise please
keep and eye on that repo.
Rossen: astearns and I scrub issues with Agenda+ on telecons
astearns: But krit said some might not need telecon if it gets
attention in github
fremy: Should we add a tag that's agenda+ for review so it's sent
with the agenda but for review?
Rossen: Agenda+ items get attention because astearns and I are
getting those regularly. Request is for 'hey FXTF is between
CSS & SVG can we get more people to actively work on issues
so they can make it to agenda+'
florian: There's 2 levels. One is everyone remembering. Then there's
a review+ tag that you scrub with the agenda+ but you just
list those in the call agenda.
Rossen: We have a tag for Needs Review.
astearns: We only look for agenda+ and needs csswg review. If you
use the Needs Review for non agenda+ items individuals
could look at the repo and then Rossen and I can look and
mention in telecon.
florian: Just list them in the agenda of things we won't talk about
but please look. And do that across all repos.
<fantasai> https://lists.w3.org/Archives/Public/www-style/2018Feb/0009.html
<fantasai> https://lists.w3.org/Archives/Public/www-style/2018Mar/0039.html
fantasai: I'll often post a summary status like ^ and I'll say here's the
status, here's what needs feedback. I don't know how useful,
but I try and do that to bring attention to issues that need it.
Maybe this is a useful thing to try.
krit: FXTF has its own ML, is it okay if I send it to CSSWG as well?
fantasai: Yeah.
krit: I don't want to annoy anyone.
fantasai: Right now it's low traffic because we use github.
krit: Yes, those suggestions are good.
Publications and Editors
========================
New WD for Filter Effects and CSS Masking
-----------------------------------------
astearns: What's changed?
krit: A lot.
krit: Last publication was 2014 for both.
astearns: Yes, let's republish.
ChrisL: Is there an up to date changes section?
krit: Yes for both.
ChrisL: Okay.
<ChrisL> https://drafts.fxtf.org/filter-effects/#changes
RESOLVED: New WD for Filter Effects
Rossen: What's the status for Masking?
krit: Both specs have 12-14 issues, about half can be solved by SVG.
ChrisL: So Filters isn't a transition. Masking needs a DoC since
it's in CR as well as a changes section.
ChrisL: So let's not resolve to publish if we're not there.
krit: What is needed before I can ask for publication?
ChrisL: A DoC ready
fantasai: And we get to review it as well.
Rossen: So we need to do this before we call for resolution?
fantasai: Yes.
krit: There are open issue for masking.
ChrisL: That's fine. And we don't have to go back to WD.
astearns: The opens are called out in DoC.
ACTION krit compile DoC for Masking and bring it back for CR
publication resolution
<trackbot> Created ACTION-873
Assigning Editors
-----------------
Rossen: Compositing and Blending
ChrisL: I volunteer as tribute.
eae: I haven't quite managed to convinced people to do it yet.
Rossen: You can lead by example. :)
Rossen: We have smfr and ChrisL to edit.
RESOLVED: Add ChrisL and smfr as editors to Compositing and Blending
krit: Geometry - it would be nice to have someone familiar with JS in
general.
Rossen: Who possesses those powers?
astearns: It's in CR. Impl status?
krit: Most UA shipping already. So impl status is pretty good. Have
to check in detail.
astearns: People with impl experience would be best editors for spec.
Rossen: I agree.
Rossen: For people who are impl this...?
krit: I said to astearns I'd volunteer but if I do it alone it would
take longer. It would be preferable if someone with more
experience.
TabAtkins: I have the skills but not the time.
Rossen: Can you teach someone?
TabAtkins: I can help.
astearns: Anyone at Google you can delegate?
TabAtkins: Possibly?
Rossen: Mozilla? Anyone good with webIDL?
Rossen: So we have krit.
emilio: Cameron has the right experience.
Rossen: TabAtkins should we put you there for now and you transfer?
Rossen: Editors for Geometry are krit and TabAtkins
krit: In general editors are always welcome. ameliaBR would be
willing but needs funding.
RESOLVED: Editors for Geometry are krit and TabAtkins
CSS Grid 2
==========
Dual-axis vs. Per-axis Subgrids
-------------------------------
github: https://github.com/w3c/csswg-drafts/issues/2280
<tantek> Note also that Mozilla (mats) now has a public intent to
implement on subgrid (on dev-platform)
Rossen: We took time to review and there's impl feedback from Mats
that per-axis makes sense and is implementable. So we either
can discuss more or resolve.
Rossen: Anything remaining to discuss in this issue before we move
to adopt this?
Rossen: Objections to publishing Grid L2 with the per-axis subgrid
model?
ChrisL: Is that fpwd?
Rossen: It is.
Rossen: Is it?
Rossen: Did we not publish the original fork?
fantasai: We did.
<dbaron> https://www.w3.org/TR/css-grid-2/
Rossen: So it's an updated WD.
Rossen: Are there objections to adopt the per-axis model and publish
a WD?
rego: There are clear use cases and mats has a working sample. He is
asking to remove a section and add that the dual axis is
included.
Rossen: I'd like to publish as is and then open individual issues
against it.
Rossen: Other comments?
tantek: You don't want to make Mats' changes before publishing?
Rossen: We open them as separate issues.
fantasai: Mats is asking to loosen restrictions a bit; and for some
of it I don't actually understand what he's asking yet.
fantasai: We need a resolution to remove the dual-axis proposal.
Rossen: Objections to removing the dual-axis proposal?
RESOLVED: Remove the dual-axis proposal
Rossen: The second issues, removing g,h, and i from subgrid should
that be a separate issue?
fantasai: I'm happy to remove i. Removing g and h I don't understand.
Rossen: That's why I suggested a separate issue.
fantasai: I don't have a problem discussing and republishing in 2
weeks.
Rossen: Objections to publishing a new WD of Grid L2 with the
removed dual-axis proposal?
RESOLVED: Publish a new WD of Grid L2 with the removed dual-axis
proposal
Rossen: Please someone open the g and h as a new issue.
CSS Display
===========
Is ::marker created by display:list-item or does it always exist?
-----------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/1793
TabAtkins: We all agree on overall behavior. More a question what
model we want. ::marker pseudo element. Original question
is decided. It was what things in theory can have
::marker pseudo elements. It's only created by thing with
display:list-item. Theoretical model of the element tree,
which things have 'display: list-item'.
TabAtkins: We wanted approval that ::marker elements always existing
the box tree on elements before or after and they're auto
suppressed.
TabAtkins: Other options are if they exist in the tree depends on
style or say they always exist but not on elements but
not on pseudo elements ::before or ::after which breaks
the current behavior for FF and Chrome.
TabAtkins: Final option is ::marker elements always exist and can be
on any tree abiding elements. This could mean that
::marker pseudos contain ::marker pseudos. Because you
can't set display on them, though, you'll never see them.
TabAtkins: Depends on the theoretical model you want.
emilio: Is that required? Except for ::slotted I think most browsers
reject multiple pseudo elements at parsing time.
TabAtkins: Does not require that.
TabAtkins: That would be good if you actual style nested ::marker.
emilio: It would mean you can set content before.
TabAtkins: Ideally you should be able to, but right now you have an
unstylable marker.
dbaron: Auto-suppressed?
TabAtkins: Like how ::before doesn't create a box unless it's
non-none. ::marker wouldn't have a box unless it's
contents had display.
dbaron: Is there a distinction between exists and suppressed and not
existing?
TabAtkins: One is a layer violation. It requires us to not
completely build on the tree until we resolve the styles.
Right now we can build the element tree fully. This is
theoretical design and has no practical considerations.
TabAtkins: We suggest they always exist on elements, ::before and
::after
fremy: Is that all browsers do?
TabAtkins: Those are all that browsers have always there. If we add
more we can categorize properly.
TabAtkins: Objections to my preferred option that ::marker exists on
all elements, on ::before and on ::after but no box
unless it's display: list-item.
florian: If you display: list-item...the initial value of content is
normal then you get it but if you don't display list item
is it like a ::before?
TabAtkins: It does not show up.
Rossen: Objections?
<dbaron> sounds good to me
RESOLVED: ::marker exists on all elements, on ::before and on
::after, but no box unless it's display: list-item
<fantasai> Possible practical implication might be getComputedStyle
on ::marker?
How does block inside inline affect the box tree, exactly?
----------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/1477
TabAtkins: I recommend looking at the first comment because
Loirooriol has a great markup example.
TabAtkins: Basic idea, in the box tree there's a span and a div list
inside it is it an inline box with a block box inside and
during fragmentation we split that or does the splitting
happen at box tree time?
florian: Observable?
TabAtkins: Affects how other properties are defined so yes in
theory. I don't think any property could be used as a
probe of it. No one uses exact box tree for spec.
Loirooriol: Saying splitting happens in the box tree is more
consistent because operations happen in the order. If
splitting is in box tree we need some kind of exception.
CSS 2.1 doesn't distinguish between when it happens so
it's like it happens between boxes.
TabAtkins: Impl information in FF eq they split and special case
text-decoration so it propagates down.
koji: We split spans, wrap it in anonymous box, and for the box we
split. That last part is same as Gecko.
<fantasai> https://www.w3.org/TR/css-break-3/#break-decoration might
need an update
TabAtkins: Our layout structure doesn't distinguish boxes and
fragments either. Hard to argue we have one behavior or
the other.
fremy: Not sure why we need to know.
TabAtkins: Affects how we write specs.
iank: Anything we do with block behavior should stay.
TabAtkins: Impl details don't matter, it's the theoretical model.
Being closer to impl matters. We can live with either
model. We just need to decide.
florian: Which makes spec writing easier?
TabAtkins: Split not until fragment time is easier I believe. Makes
text-decoration easy. Other cases that treat them as a
single thing work fine in that model.
dbaron: I worry a bit about making something trivial to define if
it's actually more complex then implemented. I think it's
better if the things easy in implementation are easy in spec
and hard in implementation are hard in spec.
TabAtkins: Agree.
florian: That's say split boxes not fragments.
fantasai: Shows up for box-decoration-break.
Loirooriol: If splitting happens in box tree, inline assumes if you
general boxes in that case it uses the box. If one of
the two inline boxes are chosen it's strange.
TabAtkins: And both are the principal box because both get all
properties.
fantasai: I'd prefer at fragment tree time, and if we want to change
the parentage maybe that's sensible. I don't think spliting
in the box tree makes as much sense. I think of this as
fragmentation so it makes sense to say that that's what's
happening.
fantasai: Also, box-decoration-break should be controlling behavior at
these breaks. We're slicing by default but may want to
switch to clone. This is how we define how the sides of a
box that has been split are drawn and if we define them as
separate boxes we have to define that they behave as
fragments for this case. If it is a fragment it's not a
special case.
florian: Split at fragment level makes a lot more sense. Seems to be
a difference with impl that don't distinguish, but dbaron
point earlier that this makes it easier to define hard to
impl...
fantasai: Does it? There's a reason why we try to discuss and get
review and it's to point out where model doesn't make
sense. I see some reasons for define as fragments and only
theoretical worries for the other.
Rossen: The model in fragmentation spec makes a lot of sense to me.
Early stages of writing draft there was back and forth for
what is a fragment and what's a principal box. As an impl it
was a time somewhat odd to map and refer to things not in
our impl. There's not a principal box in the impl nor do we
call anything a fragment, but the model matched well.
Rossen: If the model in the fragmentation spec doesn't make sense
what do you propose to change?
fantasai: Didn't say it doesn't make sense? Issue is about block in
inline splits. Is inline fragmented or of many boxes? A
lot of impl has a structure that's not one or the other.
We need the theoretical set up here.
iank: Eventually we want to move to a model where we use fragment so
I'm fine that way.
iank: We don't want to do inline splitting at the box tree level
eventually.
florian: I think so long as we have a conceptual model where boxes
and fragments are different this should be at the box
level. If we only want to talk about boxes because matches
impl that's a different conversation.
dbaron: I think there's another view to it then not having both
concepts which is that you can keep boxes and fragments as
terms but view the fragments as what you get when you split
boxes rather then a later process stage.
florian: It's a processed box?
fantasai: Isn't that what fragments are?
dbaron: That's what I thought until a few weeks ago. However people
have said things that have made me think differently,
including this issue.
florian: I don't think fragments are boxes that have been processed
in a particular way.
TabAtkins: As per spec you are right. Fragment tree is the result of
layout on boxes. You get a different tree out of that.
florian: Fragments is not a short term to mean a box piece. It's not
a whole bunch of boxes some of which are fragments.
fantasai: A box is composed of one or more fragments.
florian: But later in the process we don't have boxes and fragments.
dbaron: You have a box tree and you go to a fragment tree by
splitting things up.
dbaron: A box corresponds to one or more fragments. If the box has
children those are in one or more of the children.
fantasai: This is the case where it's not clear that's happening.
TabAtkins: In multicol even children might fragment. Putting some
children in one fragment and one in the next is fair.
dbaron: If box A is parent of box B then any fragment of box B will
have a parent of fragment A.
fantasai: How we lay this out, they don't act like their the child of
the parent. Layout wise it behaves like a sibling and lays
out that way. Same is true of block. It lays out as if
it's a sibling of the anonymous block before and after.
florian: It changes the variant but it doesn't change that you can
consider the fragment tree as a processed version of the
box tree. There's a little re-parenting but not a lot.
Rossen: I'm trying to get to a model that makes sense. What's the
model we define in the fragmentation spec in your mind?
dbaron: I didn't see the fragmentation spec as contradicting my
model.
fantasai: It doesn't because it doesn't talk about block-in-inline
splits and column spanners.
TabAtkins: It's fragmenting easy cases.
Rossen: Is it easy? If you have a whole bunch of open inline
elements, open spans, and text inside that generates some
line effects and then a block element that breaks this line
flow. At that moment what do you have?
dbaron: In my mental model? One of the things about the blocks
inside is that some ways they act like not a child like
backgrounds but for relpos they act like they are.
Rossen: If an inline element was an anchor open before and close
after the block.
dbaron: I think it's not related to DOM event propagation.
Rossen: But it's type of hit test.
florian: When you say some aspects siblings and some not, it's that
the same as in box tree descendants and in fragments its
siblings?
dbaron: If you have it as though there's a thing there is some ways
and not others it's easier to have the object there and
disable features then not have it there and re-conjure it
when you need it.
fremy: If you have regions it's in 2 elements and your model can't
have regions. They're in different places of the tree and
they'll have fragments that aren't related.
dbaron: It was a model describing how fragmentations worked and I
didn't mean you have to follow it always. Still feels weird
to me and I didn't know the spec was different until recently
florian: For Gecko these are siblings or one child? The block that
interrupts inlines.
dbaron: Child of the inline but it is a child of the block fragment
of the inline and those are kind of special.
florian: But that's not a conflict. You have a single data structure
that represents both box and fragment tree. In that single
data structure there's a thing that keeps the parenting
relationship. In box tree they're parented in fragment
node. The object is present in one of the two trees. You're
just overlapping the two so it's difficult to talk about
one concept without the other.
Rossen: Is there a model we can agree on?
dbaron: I'm fine resolving on it. I just want to recognize it's
pretty substantive decision.
Rossen: With that warning. What do people think? Ready to resolve?
TabAtkins: If people agree, yeah?
Rossen: Objections?
TabAtkins: Prop: A block inside an inline is a descendant in the box
tree and a sibling in the fragment tree.
fantasai: And the inline is a single box that has been fragmented.
Rossen: You're agreeing
fantasai: They're two things, both need to be considered.
astearns: It's not just the box that the block is a sibling.
florian: You're agreeing, there's wordsmithing.
fantasai: I want it clear that there's a single inline that has been
fragmented. It's saying the block is a sibling that's a
fragment which is a fragment and there's a following
fragment doesn't say it's the same box.
Rossen: Prop: Blocks inside of...
Rossen: Objections to what fremy is typing?
<TabAtkins> <inline>foo<block>bar</block>baz</inline> <== 'block' is
a child of 'inline' in the box tree; 'block' is a
sibling of two fragments of 'inline' in the fragment
tree.
<fantasai> proposed resolution: In a block-in-inline split, the
block is inside the inline in the box tree, and is a
sibling of the two fragments of the inline in the
fragment tree
<fremy> Proposal: There is one inline box containing one block box
(in the box tree). In the fragment tree, there are two
inline fragments, sibling on each side of the block fragment.
Rossen: What fantasai said is the same. Objections to: "In a
block-in-inline split, the block is inside the inline in the
box tree, and is a sibling of the two fragments of the
inline in the fragment tree"
RESOLVED: In a block-in-inline split, the block is inside the inline
in the box tree, and is a sibling of the two fragments of
the inline in the fragment tree.
fantasai: One more. Same applies to column spanners splitting a box.
Same logic applies.
florian: Same problem but column spanner may break multi levels of
parents.
Rossen: They can already have multiple, for inlines.
Rossen: Agreed?
Rossen: Proposal: A multicolumn spanner that splits and inline is
inside of the inline box tree and a sibling to the fragment
in the fragment tree
RESOLVED: A multicolumn spanner that splits and inline is inside of
the inline box tree and a sibling to the fragment in the
fragment tree.
fantasai: We forgot anonymous boxes.
<br type="lunch">
<fantasai> The block in a block-in-inline split is actually a
sibling of the anonymous block boxes on either side, not
of the inline box fragments.
<fantasai> And in the column case, the spanner is siblings with the
column boxes
Received on Tuesday, 29 May 2018 20:00:45 UTC