- From: Dael Jackson <daelcss@gmail.com>
- Date: Mon, 3 Aug 2020 19:43:09 -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 Pseudo Elements
-------------------
- RESOLVED: If a property applies to text and has no dependency on
box geometry it can be set on ::marker and inherits to
text of marker (Issue #4568: Which properties to reset
in ::marker)
- RESOLVED: Other properties which are not explicitly listed as
apply to ::marker must not have an affect when set by
author. UA MUST treat as not applying or treat them as
set at UA important level but either way author should
not be able to effect rendering (Issue #4568)
CSS Cascade
-----------
- chrishtr introduced the proposals for a simplified first version
of Cascading Layers which starts with a set of defined layers
(Issue #4969: What are the proper "levels" for managing Cascade
Layers?).
- There was support for looking at a simplified first approach to
Cascading Layers but also some concern that the full scope
originally envisioned hasn't been fleshed out enough to begin to
simplify.
- There are several people that either have or are working on draft
proposals for Cascading Layers. A taskforce will meet and
discuss the ideas, make sure they're detailed, and bring the
discussion back to the group.
===== FULL MINUTES BELOW ======
Agenda: https://wiki.csswg.org/planning/virtual-summer-2020#monday
Scribe: dael
CSS Pseudo Elements
===================
Which properties to reset in ::marker
-------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/4568
oriol: Related to discussion 2 weeks ago where resolved
text-transform applies to ::marker and set to none by default.
oriol: Same question for other properties
oriol: Text-indent property. Seems clear inheriting seems bad
oriol: Only applies to block container so can affect markers with
outside position
oriol: May not be obvious to authors because they're not explicitly
setting a display value to generate block. It's done by UA
oriol: Should follow rec in Tables which says if you set
display-inline:block to element you reset text-indent to 0.
Since UA gives inline block behavior to outside markers makes
sense to reset text-indent to 0
oriol: fantasai went further and proposed to do so with an important
flag so until we have clear model of outside marker layout we
prevent authors from changing.
oriol: Also works for me.
oriol: There are other properties but let's discuss this
<fantasai> https://drafts.csswg.org/css-lists-3/#marker-properties
fantasai: We have a short list of properties that apply to ::marker
and makes sense to be clear what we're talking about.
Properties that apply to box/linebox and those that apply
to text. Not clear distinguishing
fantasai: Any property that applies to text should inherit through
::marker and apply to text
fantasai: Those that apply to box or linebox- because we don't have
a layout model these properties should not apply. If they
do apply they should be forced to particular value
fantasai: When we have a proper box model we can make those that
make sense apply.
fantasai: I would change to list properties that apply to ::marker
explicitly, and then list properties that inherit to text
and say you can set on ::marker, don't apply there but
can still affect contents. If we take that as principle
these questions become more obvious
AmeliaBR: You argue color doesn't affect marker as a special thing
it affects anonymous text box
fantasai: yeah
AmeliaBR: If it affects inline text spans you can set on ::marker
and it goes through. Anything for layout box has to be on
allow list
fantasai: I think that's the principle. There's fun with fill and
stroke where rely on geometry of box
AmeliaBR: We don't have implementations of that
fantasai: Fair but still got to be careful
AmeliaBR: At some point will need to be defined
fantasai: Proposal: Properties that apply to text with no dependency
on geometry of boxes can be set on ::marker and inherit
through to text
fantasai: Properties that apply to boxes and line boxes do not apply
yet
oriol: But text-align Firefox sets to end so if you have multiple
lines in outside marker with different widths they will be
aligned to r in ltr
fantasai: text-align doesn't apply to text, it applies to line
boxes. So it would not apply to ::marker. Position of text
I believe is undefined. If an implementation supports
text-align that's fine but need to make sure it's not
changeable by author such that they can get different
results
fantasai: Either done through magic or through text-align but forced
to that value and can't be changed by author. Once there's
a layout model we loosen the restriction
faceless2: What about when have replaced content with ::marker we
have to propagate properties which allow you to resize
fantasai: Replaced content is replaced content that's a child of the
box. For list-style:image there's sizing rules that are
particular and size the image to 1em if it doesn't have a
size, something like that. Would continue to apply
fantasai: If we want to do something special for images that are
list markers we can think about that.
fantasai: Not sure
faceless2: I think was difference between setting content and
setting string of content. Bit scratchy on terms. Does
seem to vary across implementations but a lot of print
lets you use image and content. Height is propagated to
image rather than box.
faceless2: Agree in general with you
fantasai: On marker set content to URL that's an image. Then marker
is replaced element and width and height applies
faceless2: Yeah, I think that's how it works with marker-content:url
Does vary cross implementations
TabAtkins: Yeah, WebKit based engines treat the pseudo as replaced.
Spec requires anonymous element.
<dbaron> There was a spec draft of css3-content at some point
defining that behavior.
<fantasai> yeah, and I think there was some interesting questions
around web-compat... but if WebKit is able to ship that
AmeliaBR: But it is something to define to be similar to how list
style with an image would work to make ::marker case more
logical if can have it same as content with image. But
neither is well defined
emilio: I think Gecko always wraps it in an inline. But content URL
on element implementations disagree
fantasai: I think we should dig more into content url becoming
replaced, but let's file a separate issue
<faceless2> +1 to that.
<emilio> fantasai: https://github.com/w3c/csswg-drafts/issues/2889
is open for `content: url()` already, fyi
Rossen: With that issue are we ready to resolve?
Rossen: I see heads nodding
Rossen: fantasai can you give us proposal ideally with a list of
properties or a term of art?
fantasai: I think that's something we need to clean up. Two
approaches is we reference...the entire fonts spec and
subset of css-text.
fantasai: We can also audit all our properties and spec in the
"applies to" whether it applies to text or not.
fantasai: For this I think the proposals will be 2: 1) If property
applies to text and no dependency on box geometry it can
be set on ::marker and inherits to text of marker
Rossen: Similar to set of properties for ::first-letter?
fantasai: No because that can take initial-letter and other fun stuff
AmeliaBR: Might be to selection or highlight
fantasai: No, those can't change layout, and this can
fantasai: Might be similar to ::first-line though
fantasai: Rule is if property applies directly to text and no
dependency on box geometry you can set it on ::marker and
it will inherit to text
Rossen: Thoughts or objections?
<dbaron> There might be two parts to this resolution: what we want
to happen, and at what level the spec needs to define it?
heycam: Will we define in a ua stylesheet in a spec or make it clear
what computed style is?
fantasai: Compute on ::marker and inherit through
heycam: So it's about if they apply
heycam: Does that mean text-align:end is not correct?
fantasai: That's the second resolution.
Rossen: Objections to if a property applies to text and has no
dependency on box geometry it can be set on ::marker and
inherits to text of marker
RESOLVED: If a property applies to text and has no dependency on box
geometry it can be set on ::marker and inherits to text of
marker
<emilio> faceless2: I don't see the webkit / blink quirk you
mentioned in
http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=8312
fwiw. All browsers behave the same
<faceless2> @emilio If you set a height on that image, the spec says
it should be "content-replacement" and the width/height
should apply _to the image_. This is distinct from a
list of more than one item, when it becomes a
"content-list" - the distinction tab was making. That
distinction is not made by the browsers, but if you're
going to do ::marker { content: url(file.svg); height:
1em } that's the only way you can adjust the size of the
SVG.
<faceless2> @emilio https://github.com/w3c/csswg-drafts/issues/4632
<emilio> faceless2: uhhh, so the spec doesn't match any browser
implementation of pseudo-elements? fun!
<faceless2> Matches at least two print engines though :-)
fantasai: Second: If a property that's not in the first category is
not listed in the spec than it does not apply to ::marker
boxes. If an implementation is taking advantage of its
infrastructure to handle marker layout it needs to bake
that its default value in as !important so author can't set
fantasai: Example we specified that unicode-bidi does apply to
::marker. It can be set. We didn't spec that text-align
does. Gecko uses text-align to position text and that's
fine but it needs to set !important on that rule so that
author can't set it and get different results.
fantasai: When we define the box model we can release that
restriction. Until then we need to make these so author
cannot affect
oriol: All inherited properties except the ones in the resolution
should be set to initial using !important?
fantasai: I don't know that...are there properties for the box that
inherit?
oriol: text-align chromium just inherits. Should we allow this?
fantasai: If a property has an affect in an impl and we say it does
not apply the property needs to be force set so it acts
like it does not apply
dbaron: Differences are observable in computed
fantasai: Yeah. Ultimate goal is they do apply but we need to define
marker box model for that
Rossen: Hopefully not painting ourselves into a corner
fantasai: I don't think we will. Force set will be UA initial
values. Author might set it on ancestor and we need to
make sure it doesn't inherit through in unexpected ways
fantasai: Proposal: Other properties which are not explicitly listed
as apply to ::marker must not have an affect when set by
author. UA might treat as not applying or treat as set at
UA important but either way author should not be able to
effect rendering
oriol: May or must on inheritence allowing?
fantasai: Must. Must behave as no effect
Rossen: Custom properties as well?
fantasai: They don't affect layout, no
Rossen: Those that can be used by custom layout?
fantasai: I don't think it affects ::marker
Rossen: I can have it inside and propagate a bunch of properties. If
you stop from propagating to me I can't do custom layout
fantasai: Can't do it without display property and it does not apply
to ::marker or things within it
Rossen: Same with custom paint?
AmeliaBR: We can't do background image because that depends on
layout. So for now probably
Rossen: Making sure we're not in a corner
AmeliaBR: Any reason to prevent custom properties from having a
proper computed value on ::marker? No reason to not let
read in JS
fantasai: Only properties affected are those not in the previous
resolution and not listed in spec but would have affect in
impl for some reason. Custom properties don't fit into any
of those categories
Rossen: Objections to other properties which are not explicitly
listed as apply to ::marker must not have an affect when set
by author. UA might treat as not applying or treat them as
set at UA important level but either way author should not
be able to effect rendering
oriol: Clarification. The might in the proposed text should be a must
<heycam> (it also is impossible to stop custom properties from
inheriting by setting things in the UA sheet, since all
doesn't target them)
RESOLVED: Other properties which are not explicitly listed as apply
to ::marker must not have an affect when set by author. UA
MUST treat as not applying or treat them as set at UA
important level but either way author should not be able
to effect rendering
dbaron: Back to previous resolution.
dbaron: Thing that might still make people unhappy is not substance
but level of detail where spec desc.
dbaron: Best thing to do is have editor apply it and bring back to
group to see if we're okay with level of detail. There's a
wide range of ways to do that. Seem reasonable?
AmeliaBR: Qualify our resolution that spec text is subject to final
approval?
Rossen: We can always amend a resolution
Rossen: dbaron's comments will go in the issue
<break type = 15m>
CSS Cascade
===========
What are the proper "levels" for managing Cascade Layers?
---------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/4969
chrishtr: I can summarize the latest update
chrishtr: Discussed at previous F2F. I proposed we start with
simplest set of layers: 2. Base between UA and regular
stylesheets and then regular stylesheets. Allows simple
use case where you import a widget. You can define what's
important to the widget and would break without and than
use those customizable.
chrishtr: 3rd part dev marks what's important and can't be
overwritten. Then with normal cascade if they want to
override not required they put in their own rule to change.
Rossen: Allow library or component authors to provide sensible
defaults and allow consumers...
chrishtr: To customize properties that are appropriate to customize
chrishtr: We tried to make this polyfillable so that existing
websites like nextJS could with small dev effort translate
existing layers into an ordering of stylesheets on the
page and the specificities that are equivalent.
chrishtr: Then sites could use right away in build steps until
browsers finish implementing
Rossen: How does multiplicity here have anything additional against
this? More than 2 layers?
chrishtr: How would that make it harder?
Rossen: Yeah
chrishtr: Maybe there isn't a good reason other than 2 is smallest
number. Kind of a joke, kind of not. Good principle to
find smallest solution. Also use cases I've talked to devs
about seem completely solved. You have component and site
and I'm not sure you have 3 people
Rossen: Reasonable. Minimum and sufficient. We have lots of talk
about how more layers can be used, but I buy this.
TabAtkins: Me chrishtr and miriam discussed and drilled pretty heavy
to predefined layers. It's an important aspect. At the
time we thought we needed 3, but number isn't important.
Important is one of the big issues about how to make it
make sense if if you you have arbitrary names and
ordering you can define those reasonable
TabAtkins: But as soon as you add other libraries with custom layers
if you're scoping and interoperate so either normals go
with your normals then custom names become very
difficult. If you have 1 library you can change but with
2 libraries there are too many names.
TabAtkins: It gets very complex
TabAtkins: Whereas if we start with a small number of predefined and
named layers it lets us solve those issues without extra
problems. You know what default layer is for and you can
import. Everyone using default will use in roughly same
way
TabAtkins: As long as people abide by what the layers mean you'll be
able to integrate with 3rd party and they just work.
TabAtkins: I think that's important aspect that needs to be
considered and we should go with for v1 of custom
cascade. Having a small number defined handles a lot
chrishtr: Collapsing layers to 1 at run time is not trivial, miriam
brought up. If you don't have polyfill offline it's not
easy
<dbaron> I thought TabAtkins said something above about an import
mechanism that collapsed layers, but I didn't see it
minuted, and I missed some of the detail of what he said.
<TabAtkins> dbaron, being able to say "import this library's styles,
but just treat all of them as living in layer X of my
page (while respecting their own internal layer usage)"
miriam: I'm interested in finding the simplest possible starting
place. Agree a few named defined layers is good to start.
miriam: A few concerns with this proposal where it's so focused on
polyfill I'm not sure how it's helping. Offhand it supports
use cases but doesn't do a lot toward them. Are we solving
the problem or focused on polyfill. I don't know that's not
solving the problem
miriam: One feels to me like it could be a good place to start. The
examples rely heavily on !important and where so I'm not
sure I see how polyfill is simpler without extra steps.
miriam: I also think there's a trade off when we go to predefined
layers. It's that we don't get any modularization control
which was another potential feature. Ability for final
author to modularize by collapsing layers together and say I
don't trust bootstrap to get this but can subsume it. It
maybe can be handled separately but it's a trade off for
same layers
fantasai: +1 to miriam
fantasai: I understand desire to make this polyfillable but I think
we have not explored what it would look like concretely
and take what miriam proposed in January and make that
real.
fantasai: What she proposed is a really powerful system that adds
abilities to cascade and authors would find powerful.
Simplifying to 2 layers is not that compelling. To try and
design that would prevent us from trying to understand
full picture
fantasai: At this stage I'd rather explore full context miriam
proposed. Then if there is a subset we want to ship first
that's fine. But taking on this restrictive set I don't
think gives us something to build off of to get where we
want to go
fantasai: Would rather explore original proposal from miriam, get
that concrete enough to know what it looks like and have
specific issues. Shouldn't restrict to polyfillable since
the whole point is platform isn't capable of what we want.
chrishtr: Which use cases are not satisfied?
fantasai: Proposal is flatten out but when working with multiple
systems you'll have all the problems with cascade. Point
of this was encapsulate so you don't have specificity of
selectors cross interacting. You lose that. If you're
losing :where for everything you can't control specificity
of selectors. Won't have real effect of cascade layer by
flattening all selectors
miriam: Answering it differently it doesn't break any of them but it
doesn't go the full way in aiding complexity.
miriam: Something like this scaled back may be useful but I want to
see in context of how it would expand. I want to see the
whole system and then what a scaled back impl would look
like. What's the potential to grow and how are we designing
first impl so growth is in mind
chrishtr: :where is only to support polyfills
TabAtkins: Using :where as polyfill you can do arbitrary layers. The
details of that is not important
chrishtr: You can have a build tool that sticks things in :where
clause. Laying out what I thought of
emilio: Most use cases I read about are things conflicting inside
same cascade origin. Rather than inventing new ones, sorting
order in cascade is specificity and then source. Would it
make sense to add a 3rd so it's user defined, then
specificity, then source.
emilio: Multiple cascade explodes when you have shadow dom. With
this you don't have the problem and solve use cases.
chrishtr: Would that take care of non-override-able library rules?
emilio: Potentially. You can define this number is sort of like
cascade origins
miriam: I think difference is only if layers exist above or below
shadow dom in cascade which is still open
emilio: Yeah. And I think this is more efficient to impl
TabAtkins: I think for spec complexity we'd have to impl this as new
specificity.
<miriam> +1
emilio: Okay, that makes me less scared about performance
implications
dbaron: I was trying to think about something TabAtkins said about
an import mechanism that imports something with stuff from
both layers and then collapses
dbaron: 2 ways to do that and not sure which talking about. One is
pretend the layer never existed. Other is sort them in there
as though layers and then collapse to one layer
dbaron: I guess that doesn't work. Now that I said it out loud.
TabAtkins: My intention was there is a strong case to not interleave
but still let the library use layers for code
organization. Sort the rules specificity wise and then
collapse to one layer to interact with your pages
dbaron: Not sure how that works if you interleave with non-collapsed
rules
TabAtkins: I'm thinking it just lives on a layer. Then interoperate
with other rules in that layer
dbaron: So it breaks some author assumptions who put in 2 layers
about what overrides what?
TabAtkins: Shouldn't. Their layers respected in their own thing.
dbaron: That's what I was starting to think but convinced myself it
made no sense
TabAtkins: Definitely need more thought time on this topic.
Rossen: Going back to direction...2-layer approach vs continue to
explore full set of options from jensimmons and miriam.
Where are we swaying?
Rossen: One thing I didn't grasp is would the 2 layer prevent us
from expanding later down the path to get full set of layers?
TabAtkins: I don't think it does. Particularly when we do it with a
naming structure and we can distinguish between these
defaults.
Rossen: Same mental model as css properties then variables then
custom properties? So we have properties now we're adding
variables and we'll then expand
TabAtkins: yes
fantasai: I'm not convinced this requires naming. I would like to
see us try and draft something more concrete.
fantasai: If we have multiple proposals that's interesting, but I
haven't seen one that represents what we discussed in Jan
and until we have one I don't think locking down is a good
idea
TabAtkins: fantasai and I intend to put out a draft spec and will
have miriam in that
fantasai: florian has also drafted ideas so we can talk together and
see if we align or we come up with multiple proposals
<dbaron> I'm definitely interested in seeing more alternatives.
Rossen: Last time we discussed we agreed to have a smaller
taskforce. Is that forming?
many: yes
Rossen: fantasai are you willing to take this on and get it
organized?
chrishtr: miriam would you prefer to do it or have fantasai do it?
miriam: Fine if you take that
fantasai: miriam what's your time zone?
miriam: Mountain
astearns: So I think we're done with this issue
Agenda Setting
==============
astearns: Only remaining issue is one we left off because tantek
wasn't on and tantek still isn't on.
astearns: We'll push that to tomorrow
fantasai: One question. Inline and text is on Tuesday but Jonathan
is only available half the day
astearns: I did talk to him about choosing most important issues to
him to put first part of day
fantasai: Wouldn't it make sense to push to Thurs or Fri?
* dauwhe is away Wed-Fri
astearns: Thurs is full with constraints. Friday is Houdini. If
there's overflow we can do that overflow on Friday
astearns: If he has to leave before we get to everything he's
interested we can push it out
chrishtr: I think it would be nice for weekly calls to use system so
anyone who wants to can turn on video. Maybe we can have a
poll
astearns: We can start. We did try all video on webex and it was
terrible
chrishtr: I think some other tech than webex
TabAtkins: We can always use meet because it has call in
Rossen: This is something astearns and I were discussing. Being able
to take visual cues is helpful, but webex is not it.
Rossen: We'll continue to work on it.
chrishtr: Great
Rossen: We're closed on previous, forming a task force. Anything
else?
Rossen: I think we're done. Thank you for calling in. Great to see
you all.
Meeting: end
Received on Monday, 3 August 2020 23:44:06 UTC