- From: Dael Jackson <daelcss@gmail.com>
- Date: Thu, 17 May 2018 03:31:25 -0400
- To: 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.
=========================================
CSS Contain
-----------
- RESOLVED: Align 'contain:paint' to 'overflow:clip' behavior.
(Issue #2223)
- RESOLVED: Size layout and paint containment don't apply to
internal ruby elements. (Issue #2512)
- RESOLVED: Size containment does not apply to non-atomic inlines.
(Issue #2510)
- RESOLVED: Layout and paint containment does not apply to
non-atomic inlines. (Issue #1457)
- RESOLVED: Clarify the definition of what and how an FC is created.
(Issue #1457)
- RESOLVED: No change to spec, but add examples and improve wording
to clarify desired behavior. (Issue #2483)
- RESOLVED: Add this clarification to the spec. (Issue #2349)
- There's only one open issue left to resolve (Issue #2527: How do
layout and size containment interact with column/page
fragmentation?). After that is closed the spec can be
republished.
CSS Scoping
-----------
- RESOLVED: Accept proposal in https://github.com/w3c/csswg-drafts/issues/2158
(keep ::slotted and :host to a single argument)
- RESOLVED: Account for the specificity of the selector item and
change the spec to say pseudo elements have same
specificity of pseudo classes. (Issue #1915)
CSS Pseudo Elements
-------------------
- RESOLVED: ::selection is cleared for shipping unprefixed even
though multiple implementations do not (yet) follow
the spec. (Issue #2474)
- RESOLVED: Switch to using inheritance instead of cascade (to
describe ::selection of a child). (Issue #2474)
===== FULL MINUTES BELOW ======
Agenda: https://wiki.csswg.org/planning/berlin-2018#schedule
Present:
Rachel Andrew, Invited Expert
Rossen Atanassov, Microsoft
Tab Atkins, Google
L. David Baron, Mozilla
Christian Biesinger, Google, observer
Brian Birtles, Mozilla
Oriol Brufau, Observer
Tantek Çelik, Mozilla
Monica Dinculescu, Google
Elika Etemad, Invited Expert
Rob Flack, Google
Simon Fraser, Apple
Jihye Hong, LGE
Koji Ishii, Google
Dael Jackson, Invited Expert
Ian Kilpatrick, Google
Rune Lillesveen, Google
Chris Lilley, W3C
Peter Linss, Invited Expert
Myles C. Maxfield, Apple
Naina Raisinghani, Google
Manuel Rego, Igalia
Florian Rivoal, Invited Expert
Richard Rutter, Clearleft
Geoffrey Sneddon, Invited Expert
Alan Stearns, Adobe
Shane Stephens, Google
Surma, Google
Majid Valipour, Google
Lea Verou, Invited Expert
Eric Willigers, Google
Scribe: dael
CSS Containment
===============
contain:paint should use padding box instead of content box
-----------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/2223
florian: Currently contain:paint clips to the content box, which is
different from overflow. We should probably use padding box
as well.
florian: We should be clipping to the shaped padding box like
overflow.
fantasai: Can't you just invoke 'overflow: clip'?
florian: At some point we defined paint containment to be at
computed value time, but we do want the same effect. How
it's described doesn't matter.
fantasai: I'd say used value time.
dbaron: Shaped padding box?
florian: Padding box with border radius applied.
dbaron: Sounded related to shapes.
florian: No, it's just a piece of terminology we resolved to add.
[questions about what we resolved]
florian: We resolved to add a term, I proposed shaped-padding-box
but I'm open to other names.
<astearns> yesterday:
https://github.com/w3c/csswg-drafts/issues/2324#issuecomment-380036663
dbaron: Not crazy about that because it sounds like shapes.
florian: So the padding box with rounding corners applied and if
there's ever other types of corners those as well.
florian: Resolve to align to overflow:clip behavior?
Rossen: Objections?
RESOLVED: Align to overflow:clip behavior.
Applicability to internal ruby elements
---------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/2512
florian: Size containment, layout containment and paint containment
don't apply to internal layout parts. But we don't say
anything about internal ruby elements. We should exclude
those as well.
koji: What's internal ruby elements?
florian: Things like ruby-base container and ruby-text container.
Layout containment on these things doesn't make a whole lot
of sense.
koji: It would apply ruby element
florian: Yes.
dbaron: I'm fine with that.
Rossen: Any reasons we should be applying containment?
RESOLVED: Size layout and paint don't apply to internal ruby
elements.
Applicability of size containment to non atomic inlines
-------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/2510
florian: Having size containment apply to elements where the width
and height do not apply doesn't sound useful. So it should
not apply to non-atomic inlines.
dbaron: Do all the other forms of containment work?
fantasai: You also probably can't do layout containment.
florian: There's another issue on that.
Rossen: Objections?
florian: I think non-atomic inlines is the right word.
RESOLVED: It should not apply to non-atomic inlines.
Becoming a formatting context
-----------------------------
github: https://github.com/w3c/csswg-drafts/issues/1457
<florian> https://github.com/w3c/csswg-drafts/issues/1457#issuecomment-379156461
florian: Start reading here ^
florian: We've been discussing for a while, there's something in
contain saying things must become a formatting context
root. We've been deciding if this is the generic thing that
should go in and if yes does it apply to inlines or ruby.
florian: fantasai has been pushing back for combined reasons. 1)
does it make sense to layout and paint containment apply to
non-atomic inlines. If yes we have to FC them. If not we
shouldn't apply that. I'm reasonably convinced they
shouldn't apply to inlines. This is a radically different
thing and if you want that layout ask for it explicitly.
florian: I agree there is no need for containment to apply on these
things.
TabAtkins: Yeah.
florian: Maybe we can resolve on that?
Rossen: Proposal: Layout containment and paint containment do not
apply to non-atomic inlines.
smfr: Things with more then one box?
florian: Principle box.
dbaron: smfr means more then one fragment. I think they would apply
to something inside a multicol over many columns. So what
that means might be a problem. But if you have layout and
size containment for a thing split over multiple columns you
have to decide how to paginate and that gets interesting.
TabAtkins: It's either 0 or fixed height.
dbaron: Do you split arbitrarily or it has to be one piece? You
can't use middle line breaks because it's not containing.
florian: I think containing and fragmenting is a separate discussion
we should look at.
dbaron: File an issue?
florian: Yes.
<dbaron> I filed https://github.com/w3c/csswg-drafts/issues/2527 on
the fragmentation and contain issue
RESOLVED: Layout and paint containment does not apply to non-atomic
inlines
florian: Do we need a term for this? There's a bunch of specs that
talk about establishing a BFC. In flex it says that you
establish a FC and it means blah blah. However in overflow
spec when you set it to non-visible it must establish a
formatting context. Same with multi column spanners. It's
not a new type of FC, we just say you need to get one of
these.
florian: In this case when you need to be a FC everything is already
one except blocks and blocks become BFCs. We can just say
that.
florian: What I'd like to have is... have an anchor term that is
establish a formatting context because then it says what
type of FC it is. We've many times said BFC and that's not
what we meant.
florian: To try and stop from BFC-izing things having a term that
does that sounds nice to me.
florian: fantasai was pushing back against this.
fantasai: I think it's "establishes a formatting context" and
there's a definition for that.
florian: For what a FC is, but not when you establish one.
fantasai: Okay. We can add one to display.
florian: That definition should include that if you invoke that on
non-atomic inlines you wrote your spec wrong because you
need to blockify them first.
florian: I've got suggested text.
fantasai: There's a definition for a new formatting context but it
doesn't say type.
florian: But you made the mistake of the wrong kind so if we get it
repeatedly wrong.
fantasai: Some specs have said BFC when they meant FC. We have an
anchoring term, if you have a problem with the definition
we can adjust.
fantasai: Specs like multicol were written before flex and grid so
writers weren't thinking about things that aren't blocks.
Rossen: The definition you're referring so, can you paste a link?
Rossen: florian if the definition is not enough, then where is your
proposed text?
florian: Toward the bottom of the comment
https://github.com/w3c/csswg-drafts/issues/1457#issuecomment-379156461
florian: [reads]
[Text from issue:
Specifications may call for an element or box to <dfn export>
establish a formatting context</dfn> without further precision
as to the type of formatting context or how to do so.
This operation is not applicable to non-atomic inline-level boxes
nor to boxes with a layout-internal display-type. Specifications
that invoke this must either exclude such boxes, or to blockify
them first.
If the box is a block container that does not establish a BFC, it
is made to establish a BFC. Otherwise, the box already
establishes a formatting context, and this operation is a no-op.
Note: This has no effect on the computed value of the display
property.
Note: If a specification defines a new type of box which are
neither non atomic inline level, layout-internal, block
containers, or some other display type that establishes a FC,
then that specification must define the meaning of this
operation for that type of box.
]
fantasai: It's not true. If you try and establish on a table row.
florian: It doesn't invoke on internal display types.
TabAtkins: If you're trying to FC [missed]
TabAtkins: This'll go in the guidance, like "don't blockify and
inlinify the same element".
florian: I won't block on this, but it seems reasonable to me given
that we've made the mistake multiple times after creation
of flexbox and grid.
fantasai: I'd like to put effort into merging the wording properly.
Rossen: Let's resolve on clarifying the definition of what and how a
FC is created.
Rossen: Objections?
RESOLVED: Clarify the definition of what and how a FC is created.
Scoping of the content property unclear
---------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/2483
Loirooriol: If you have style containment and then it says that the
content property goes to the subtree.
Loirooriol: It says for the purpose of open quotes etc. It's not
clear what that means. You can use counter() function to
read counters without defining any. It's not completely
scoped. The element behaves like at the root of the tree,
but if you can read contents from elsewhere it's not
clear what happens.
dbaron: I would have thought you create new counter scopes.
Loirooriol: In another issue it was resolved that the counters are
maintained.
florian: We said it's a new counter, but not a new counter scope.
Loirooriol: Counter is created, for example, but you can't link all
the counters with a name from outside the tree.
dbaron: What does the spec say reasons for style containment are.
TabAtkins: Whenever properties change the style outside of the
containing element is unchanged and doesn't need to be
recalculated. When you increment a counter it's not going
to affect counters.
florian: So satisfied if you make a new counter scope but you don't
need to go that far. Chrome ignores what's going on in the
parent, but I don't believe that's what we resolved. We
could clarify the previous resolution a bit more.
Rossen: What would the clarification be?
florian: I proposed to replace 'etc' with details of the effects of
the content properties list with the depth of the nesting
in the tree starts at 0. Wait... we're missing something.
Counter set and counter increment must be scope to the
elements of the tree is last item. For open and close quote
we're not clear what we do.
florian: Detailing this, [reads text from the issue]
florian: That's not the point Loirooriol raised. It was also what
does the counter inside the property do. That's the other
issue we have left.
TabAtkins: When you use counter and there isn't one of that name it
creates a new counter. What happens when it does exist
outside the style scope. Style containment doesn't
prevent flowing into, but not flowing out. You should
still see the outside world's counter. You should see
that name.
TabAtkins: Counter set have special behavior because they would
alter the value outside the tree. But the read doesn't
cause alteration so it should work as normal.
florian: This bug and #2349 are both covering this topic.
florian: If we go piece by piece... for counters do we stick with
the idea that counter-set and -increment do. But what
you're saying TabAtkins isn't what chrome does.
TabAtkins: Given the example in #2483 Chrome behavior seems fine.
What behavior to you expect?
florian: 1 and 1.2 because the counter outside exists.
TabAtkins: The only counter is n on the div.
florian: But style containment is scoping to element sub tree.
TabAtkins: True, correct. Yes. Chrome is wrong.
Rossen: File a bug and leave the spec?
TabAtkins: It should be 1 and 1.2 So the :before sees a single
counter and the :after sees two counters. Yes. 1 and 1.2
is the correct rendering.
florian: If chrome is okay to align we should clarify the spec but
not change behavior.
TabAtkins: Yes.
florian: So resolve no change to spec, but add examples and improve
wording to clarify desired behavior.
Rossen: Obj?
koji: How do others browsers do it.
florian: Others don't impl.
RESOLVED: No change to spec, but add examples and improve wording to
clarify desired behavior.
Rossen: Please file browsers bug for everyone that impl this.
florian: While we clarify I'm suggesting we clarify the exact effect
on open and close quotes.
TabAtkins: Why resetting nesting depth?
florian: That seemed simpler.
TabAtkins: Nesting depth stays what you inherit from outside.
florian: Okay, so not what I wrote.
florian: Changes from must be scoped to sub tree to it starts at
what it was but changes to the depth of nesting and do not
effect outside the subtree.
Rossen: This is clarification part?
florian: I don't know if you want to resolve separately?
Rossen: We can resolve on this, but the resolution says we need to
clarify.
Rossen: Resolution covers it
Clarify style containment property scoping
------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/2349
florian: Remaining item is, definition to scoping to a sub tree is
confusing.
florian: [reads]
[Current Spec:
A scoped property has its effects scoped to a particular element
or subtree. It must act as if the scoping element was the root
of the document for the purpose of evaluating the property’s
effects: any uses of the property outside the scoping element
must have no effect on the uses of the property on or in the
scoping element, and vice versa.
]
florian: The confusing part is when you're scoping to a sub tree the
thing that would be the root is outside the sub tree you're
considering. If you have an element with 2 descendants does
it mean 2 disconnected roots? I think you mean the element
is the root for the purposes of styling.
TabAtkins: That was my intention.
florian: I think we should resolve this is our intention and we
should improve the wording.
florian: [reads proposed text from issue] [Commit with changes:
https://github.com/w3c/csswg-drafts/commit/d7c64a5d7487b5411a987fbbc0e26c480b90926e
]
TabAtkins: Yep.
Rossen: Good TabAtkins?
TabAtkins: Yes.
Rossen: Objections to adding this clarification to the spec?
RESOLVED: Add this clarification to the spec.
Publication
-----------
florian: We were almost at 0 comments, but just opened one. We're CR
so let's look at fragmentation some other day and then
publish.
fantasai: You can do CR and say that this is open and we'll fix it
in the next update.
florian: I don't think we're in a rush. We'll keep the open issue
open and when we close talk CR.
florian: That's it for contain.
Scoping
=======
Consider making ::slotted and :host take a single argument
----------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/2158
emilio: Single argument prevents discussion about specificity and
it's simpler to organize.
rune: Is this the same as matches?
emilio: Right.
rune: I don't know how much sense it makes to have this implicit
matches thing.
TabAtkins: Spec was clear. People have problems reading work like
default.
emilio: Spec was clear but impl are shipping with something else.
TabAtkins: I don't care if we do 0 spec or spec to an argument. You
can always nest a matches in there.
Rossen: I'm hearing people in favor. Objections?
RESOLVED: Accept proposal in https://github.com/w3c/csswg-drafts/issues/2158
Specificity of :host, ::slotted, and :host-context
--------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/1915
emilio: Also if we want to keep it. Per spec this has specificity of
normal pseudo class, but there's a request to affect
specificity of selector. I implemented the spec, but blink
and webkit don't touch ::slotted. ... whatever we decide I'm
fine.
TabAtkins: Should be consistent.
Rossen: Anyone have a preference?
rune: I can't see why we would do it differently.
dbaron: pseudo class vs pseudo element?
TabAtkins: No, a selector with a pseudo element adds specificity.
dbaron: No, it just matches different things.
emilio: ::slotted does that.
dbaron: Add pseudo elements to specificity.
TabAtkins: Like pseudo class when you can opt in to special
specificity.
TabAtkins: Should change selectors to ask specificity of pseudo
element defaulting to none at all.
TabAtkins: Servo asked for it explicitly with a similar example.
<TabAtkins> https://github.com/w3c/csswg-drafts/issues/2271
TabAtkins: I'm okay resolving that we make all these pseudo classes
have the specificity of their elements and clarify pseudo
elements can have the specificity.
dbaron: The reason pseudo elements don't have specificity--if you
have a ::before nothing before can match so there's no point
in changing specificity when you have exactly one. You can
change pseudo elements to have a class level specificity.
TabAtkins: Seems fine.
Rossen: Proposal?
emilio: Accounting for the specificity of the selector item and
change the spec to say pseudo elements have same specificity
of pseudo classes.
emilio: If you have ::slotted div the spec would be the class?
TabAtkins: It would be the same.
emilio: Override it.
Rossen: Objections?
RESOLVED: Account for the specificity of the selector item and
change the spec to say pseudo elements have same
specificity of pseudo classes.
CSS Pseudo Elements
===================
::selection style propagation
------------------------------
github: https://github.com/w3c/csswg-drafts/issues/2474
emilio: No one does what spec says. So I think we should change the
spec or all implementations.
rune: This has been a topic for multiple F2F. I think we covered it
in 2010.
rune: dbaron has best overview.
dbaron: Selection was specified in selectors 3, but didn't say what
it meant. A bunch of browsers implemented something, then we
tried to look at what people wanted and expected and I made
a list of requirements of what it should do. I think we
picked one but no one adjusted.
rune: I'm not sure we picked one.
dbaron: I don't know. Maybe we didn't. Way selection works in most
browsers isn't useful.
florian: I think based on the background fantasai specified a thing
that makes sense and is useful, but it's not what browsers
do today.
dbaron: Other question is is the thing spec compat with what's on
the web today.
florian: I think underlying is should we try and make it useful. If
we establish that's the goal by applying to qualifying
selectors we accept we're willing to go into that level of
complexity. If we don't accept the premise let's not
bother. Current spec had the assumption that we wanted to
bother. Is that true?
dbaron: The thing in the spec attempts to do useful things for
selections and styles. Also there were features we wanted to
build on top of ::selection so we can do things like styling
spell check region that are on top of this feature.
fantasai: We added ::grammar-error and ::spelling-error.
emilio: Annoying part of how it's spec is you need to start
resolving status to the top.
fantasai: There's different ways of getting same result. There was
an alternative way to have selection inherit from itself
in a separate tree.
emilio: You have to resolve the entire tree which is different then
what browsers do. I could say that, but I care about browser
compat.
emilio: Whoever changes the impl first needs to be aware they might
break.
florian: I don't know. It will do it wrong if you try and use it
outside unqualified '::selection'.
tantek: I'd rather see data on actual use.
TabAtkins: Argument is any current usage that would be affected is
almost certainly broken.
tantek: You'd be fine with blink changing ::selection?
TabAtkins: I would be fine with our impl to change, it would be
better for users. Only global ::selection is useful right
now and that wouldn't change.
emilio: Seems like it would make select-all sort of slow. You need
to style whole page again.
TabAtkins: Recascade
emilio: You pay the cost of selecting the whole page.
fantasai: Don't have to recascade.
TabAtkins: Track a full cascade.
fantasai: ::selection has 4 properties.
TabAtkins: True.
emilio: But then special casing that.
fantasai: Then you just... instead of using cascading you can use
inheritence through selection tree.
rune: That's what presto used to do.
emilio: Somewhat like blink and webkit do for visible
rune: Works for limited number of properties.
fantasai: Properties that apply have to be limited because they
must be non-layout affecting.
TabAtkins: Most are already inherited. Others can be shifted.
<fantasai> https://drafts.csswg.org/css-pseudo/#highlight-cascade
fantasai: And I think there's an open issue about describing it to
use inheritence.
fantasai: We can do it either as cascade or inheritance but you get
same behavior. Main difference is if you use 'inherit'.
fantasai: Most of the time authors are not setting the inherit
keyword. Behavior between cascading and inheritance is
that the inherit keyword behaves differently.
emilio: Synthetic properties that are usually reset but are not
inherited for purpose of selection... I don't know.
TabAtkins: Happy to describe like that.
emilio: Seems hard.
TabAtkins: Spec text should be fine.
tantek: ::first-line has similar issues.
TabAtkins: Not a great example.
tantek: Older and has more tests.
florian: Less constrained because compat. Can effect layout.
tantek: If you look at the ::selection and apply them to first-line
you can come up with a reasonable list.
florian: That the set of properties for ::selection is more
constrained means you can use more mechanisms.
tantek: But from user/author it's not clear it should be different
then ::first-line
fantasai: I think ::first-line is not related because it's trying to
solve different constraints.
<tantek> ::selection is only trying to solve a subset of the
constraints of ::first-line, which is why it is related and
worth looking at
TabAtkins: Pretend everything is inherited make sense?
emilio: Will people change?
TabAtkins: We should try.
florian: Is it priority or disagreement? If browsers agree but don't
prioritize there are people that have fixing browsers as a
bug. If the browsers will accept that behavior that's
different then we would not want to do this.
emilio: If there's no commitment to impl.
florian: I'm saying that there might be and a patch might be written.
dbaron: Other option is put a note in a spec saying it hasn't been
impl and we want feedback to see if it would work out and
describe the other thing.
florian: Other thing being only global is useful?
dbaron: Yeah.
fantasai: It's easy to describe current implementation. That's easy
to describe in 2 sentences and add another for why it
doesn't work well.
fantasai: I'm with TabAtkins we should try and make it more useful
and if that's in terms of inheritence that's fine. I'm
with TabAtkins that implementing correctly is unlikely to
break anybody.
fantasai: I would say if you implement in a way that makes it work
no one will be mad at Mozilla doing it right.
fantasai: You have a problem that it's prefixed in your
implementation. You've got compat on the basic case that
works so you should unprefix. Separately then make it
useful.
tantek: Reasonable approach. We heard existing unprefix
implementations are willing to change so that adds weight to
Mozilla can unprefix assuming we're willing to change.
fantasai: Prop: Mozilla should unprefix ::selection impl and the
spec should describe how ::selection of a child gets its
parent's styles via an inheritance based mechanism.
florian: Our process prevents Mozilla from unprefixing and we need
to allow.
fantasai: We generally recommend you only ship if you're reasonably
spec-compliant and impls are not and we're saying it's okay
regardless.
fantasai: ::selection is cleared for shipping unprefixed even though
multiple impl do not (yet) follow the spec.
Rossen: Obj?
RESOLVED: ::selection is cleared for shipping unprefixed even though
multiple implementations do not (yet) follow the spec.
fantasai: Currently ::selection of a child is described with
cascade. There are edge cases that will behave different
with inherit.
fantasai: Proposal is switch to describing using the inheritence
rather then the cascade.
Rossen: Current resolution is about cleared for shipping so we need
the second resolution to change the spec.
Rossen: Objections?
RESOLVED: Switch to using inheritance instead of cascade for
propagating ::selection styles to descendants.
<br type="15 min">
Received on Thursday, 17 May 2018 07:32:22 UTC