- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 13 Feb 2019 19:03:42 -0500
- 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 Grid
--------
- RESOLVED: We will handle min-content track sizes as a clamp on
automatic sizes (Issue #3565)
- There wasn't time to resolve on issue #3638 (Empty grid tracks
should contribute to scrollable overflow) but the initial
response was that authors would expect the tracks to contribute
to the scrollable overflow.
CSS Remedy Project
------------------
- jensimmons introduced the CSS Remedy project to the group and
invited anyone to participate in the issues. CSS Remedy is a
starter style sheet intended to set CSS values as they'd be
designed today.
CSS Pseudo Elements
-------------------
- RESOLVED: Remove outline from list of supported styles on
::selection (Issue #3604)
- An agreement wasn't reached on issue #3603 (Should
Element.pseudo("unknown") be an error or return null?) however
there was consensus that there should be a way to distinguish
between a pseudo that doesn't exist and one that isn't valid.
- emilio will reach out to the DOM group for feedback to ensure
the solution works for them.
- This topic and issue #3607 (Identity of Element.pseudo()
return value) will be added to the F2F agenda.
- RESOLVED: Drop style from this level, restrict API to ::before and
::after, add a note to why the other things are not yet
supported (Issue #3540)
Media Queries
-------------
- RESOLVED: Close this issue (Issue #3278: Clarification on
prefers-color-scheme issues) no change, there is already
language in the spec
- RESOLVED: Do not have any normative text about this. Add a note
encouraging UAs to think about what should be done for
printing and to use light when they know printing to
paper (Issue #3522)
===== FULL MINUTES BELOW =======
Agenda: https://lists.w3.org/Archives/Public/www-style/2019Feb/0004.html
Present:
Rachel Andrew
Rossen Atanassov
Tab Atkins
David Baron
Amelia Bellamy-Royds
Oriol Brufau
Tantek Çelik
Emilio Cobos Álvarez
Dave Cramer
Benjamin De Cock
Elika Etemad
Tony Graham
Dael Jackson
Dean Jackson
Brian Kardell Brad Kemper
Chris Lilley
Peter Linss
Anton Prowse
Melanie Richards
Florian Rivoal
Jen Simmons
Alan Stearns
Lea Verou
Sean Voisen
Regrets:
Greg Whitworth
Scribe: dael
astearns: I think we should get started.
astearns: First thing, are there any changes to the agenda anyone
would like to make?
astearns: Housekeeping- we have a F2F coming up. If you haven't put
your name on the wiki as attending or regrets please do.
And look at the agenda.
CSS Grid
========
minmax(auto,min-content) under a max-content constraint
-------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/3565#issuecomment-461242081
astearns: Discussed last week. Sounds like the one thing waiting on
is the verbiage for what to do when spans >1
astearns: Is fantasai on yet?
astearns: Is there anyone else who wanted to go over last week's
discussion or have anything new?
astearns: Rossen it sounds like on this item we were waiting to
resolve on fantasai addressing a comment from Mats. She
did in the issue. Should we call for resolution?
oriol: fantasai proposed edits and they're not yet in the spec. I
had some complaints against them and they need to be tweaked
a bit. It would be better to discuss with fantasai
fantasai: I'm here
astearns: oriol did you want to discuss on the call or do it in the
issue?
oriol: I wrote them in the issue. Mostly it was that fantasai
proposed to clamp as an upper limit that's the maximum of
value. I thought it would make more sense to sum values
rather than max of them. Some other minor corrections that
maybe can be in github before making edits
fantasai: It's a max instead of sum because we want it to just fit
within the number of tracks it spans. If it spans 50px and
then one that's min-content we want it to fit in 50px plus
whatever is left. If we add to it the 50px we're giving it
more space then it needs
astearns: It sounds to me that there are 2 issues. The one on the
agenda and another that has some ramifications on this one?
florian: I think ramifications are a follow up to the thing on the
agenda
oriol: The item in the agenda was for the non-spanning case and Mats
wanted to handle spanning case as a generalization of this
and it make it more complicated
astearns: Okay, thank you
astearns: I could see two ways going forward. One is figure out the
ins and outs of spanning case on the call. Sounds like
discussion is between fantasai and oriol so might not be
most efficient. Other is resolve on accepting these edits
and if needed open a second issue for spanning case
fantasai: Can resolve on principle of handling min content track
sizes as a clamp on automatic sizes in a similar way fixed
sizes are a clamp
astearns: Make sense oriol?
oriol: Yes
astearns: We're asking for 2 resolutions? One to accept the edits
proposed in the issue and second is on principle?
fantasai: Just principle. Deal with the edits in the issue that is
open on that
astearns: Issue on agenda needs resolution. Is resolving on the
principle sufficient?
fantasai: I think so
astearns: Proposed resolution: Close the issue by resolving we will
handle min content track sizes as a clamp on automatic
sizes
astearns: Objections?
Rossen: This is on #3565?
fantasai: Yes
Rossen: sgtm
RESOLVED: We will handle min-content track sizes as a clamp on
automatic sizes
CSS Remedy Project
==================
<jensimmons> https://github.com/mozdevs/cssremedy/issues
jensimmons: I've started working on CSS Remedy project. It's a
replacement for the normalized style sheet and css
reset. devs use them to help them when getting started
with a project.
jensimmons: One of the things I found fascinating when joining group
is we can't make the default the best value because we
can't break compat. The propose of css remedy is to
collect those bits to give best practices rather then
old compat.
jensimmons: Some of you have been involved and I'd love more
interest. Mostly we're discussing on issues. It could
have a lot of traction. Already 1000 people visited on
github. We'll hopefully have it out in April or May.
astearns: Anyone want to add anything? Or we can keep this
informative
florian: People should participate. I do and if you don't want me to
be wrong you should come correct me.
<jensimmons> Thanks for letting me announce that! Thanks astearns!
CSS Pseudo Elements
===================
outline on ::selection
----------------------
github: https://github.com/w3c/csswg-drafts/issues/3604
fantasai: Currently outline applies. I tried to add a definition but
it's not that simple and I don't think anyone implements.
Does anyone want this? If not we can drop it. It's about
::selection as well as spell check.
dbaron: I wouldn't know how to define it so happy to remove
florian: Use cases I care about don't call or it so I'm okay
astearns: Anyone want to keep it?
<fremy> +1 drop it
astearns: Proposal: Remove outline from list of supported styles on
::selection
astearns: Objections?
RESOLVED: Remove outline from list of supported styles on ::selection
Should Element.pseudo("unknown") be an error or return null?
------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/3603
fantasai: Somewhat related to #3607 about identity of the pseudo
leaverou: Does it present null in any other case? If it's not
defined at all does it return null?
fantasai: That's an open question
leaverou: In general errors mean dev have to handle. But we need to
be able to distinguish doesn't exist and not defined.
Feature detection needs to be possible
fantasai: Open questions are should element.pseudo always return
same object even if you remove the style that generated
it? Other is if it doesn't exist in box tree do we get an
object back? When we request something that doesn't exist
because it's not supported what do we return?
TabAtkins: Addressed first question last week. Keeping object
identity stable is useful. Question of what do we return when ::before
doesn't have a property and can you fiddle with an object. Second
question, we do need to distinguish between a pseudo that doesn't
exist and one that isn't valid. I don't think it's useful to return
null if a pseudo element doesn't exist on an element. Perhaps a
boolean to say if it exists or not
TabAtkins: Then for the unknown thing where you put ::foo it should
throw an error. Even thought CSS style sheets can be forgiving, JS
APIs should throw in clear error cases.
fremy: I think it makes sense to return an object all the time. On
the error part I'm less sure because we'll have compat issues and
errors can cause entire thing not to work. Less sure but understand
argument
leaverou: It's impossible in JS to tell if it's that the element
doesn't exist or something else went wrong. You can sort
of guess but not be sure
TabAtkins: We can return different types of errors. We don't throw
that many errors and you can tell from type. Message will
usually let you know what's going on
leaverou: From console, but can't programmatically detect
TabAtkins: But there's one error it can cause
leaverou: What about the future?
<leaverou> Btw a historical case that may help: In old IE, setting
element.style.foo would error if the value was invalid.
This was very widely considered as annoying by
developers, until eventually IE changed and stopped
throwing.
florian: With this if you start nesting and I don't know if that's
same error as asking for a pseudo that doesn't exist
TabAtkins: Can't ask for a pseudo on a pseudo
fantasai: I think if we're deciding element returns null when it
doesn't exist it makes sense, but if we're not we should
return an error
astearns: Sounded like 3 parts to TabAtkins summary. 1) always
return...
TabAtkins: the same object for a give element/pseudo element pair
<TabAtkins> 1. Always return the same object for a given (element,
pseudo-element) pair.
astearns: Always return same object. Return an object for when a
element exists
emilio: That means you need to keep object for lifetime of element.
You could have to store a gazillion objects which you don't
need. I would have to check
florian: Garbage collected?
emilio: I guess it's not observable. Any other that does the same?
<dbaron> (discussion about the element keeping a weak reference)
fremy: [missed] if you drop the reference it's garbage collected and
you get the new one
fremy: Not possible to notice because you don't have anywhere to
compare to
TabAtkins: If you ask for a ready promise those are cached and
you're not calling because ready state has not changed.
That sort of retention of objects is not uncommon
emilio: font face it's one object and this could be many objects. If
it's a problem we can face it
TabAtkins: If you're iterating the entire tree, that's weird
emilio: I've seen people do it
florian: Pseudo with a certain style, you look at all
fantasai: One thing we could do is return null if doesn't exist on
element. If at any point it does exist browser has to
maintain the reference. Function might return null or that
object, but never another. So if pseudo element at some
point exists you keep that reference.
TabAtkins: Pseudo element does exist- if there isn't CSS setting the
before would we return null when asking for the before
pseudo
emilio: Also what happens when display on sub tree? I don't know
TabAtkins: I'm unhappy with it because it means you can't use this
API to toggle a pseudo element on. You have to go through
normal CSS which is a more complicated redirection.
Sounds good but messes up too much
<fremy> +1 to what TabAtkins just said
plinss: Isn't that a feature? Should we be able to create pseudo not
backed by CSS?
fantasai: Currently has a .style that allows you to set and have it
exist.
fantasai: Interesting thing is to plinss's point you can't serialize
that back out. We have style that will serialize out for
.style, but not for a pseudo element.
TabAtkins: If we accept nesting proposal style auto upgrades to be
able to support that. Have to define, but you can embed a
nested style in the style attribute. There's a route to
make it serialize-able
<dbaron> Another maybe-silly option is a null/undefined distinction,
if you want to think of .pseudo() as sort of like a
shorthand for a long list of DOM properties (where
undefined means "not implemented" or "the browser doesn't
know about it" and null means "known but not present")
<TabAtkins> dbaron, I don't see a good reason to return undefined vs
throwing, tho.
Rossen: Question- Is anyone working with any DOM or HTML folks on
this? Curious to their PoV. Sounds like a pretty overarching
API that we should be working with at least DOM folks. I'd
hate to see something like this worked on for so long and
then go back to square one.
<emilio> Rossen++
Rossen: Perhaps with an envoy it would be good to get their PoV
emilio: We can ask for feedback
fantasai: Would like to try and resolve and we can reopen if they
give feedback and get a publication out to request a review
astearns: Would be nice, but not sure I'm hearing consensus
astearns: I agree figuring this stuff out does make this issue about
a non-existent pseudo...how we answer all these questions
does make a difference on how we address this particular
issue
Rossen: I'm hearing a lot more questions then suggested answers.
Doesn't suggest you're ready to resolve. If we're looking to
push an updated version of spec I don't think we need to
rush a decision
<AmeliaBR> If we accept Tab's "route to serialization" by allowing
pseudo-element styles in the inline style of the main
element, doesn't that also open up a "route to
dynamically generating a pseudo-element" by declaring a
`style="::before{content:"text"}` on the parent element's
style object?
<fantasai> AmeliaBR, only if you escape those quotes properly :)
<TabAtkins> `style="&::before{content:'text'}"`, but yes
astearns: Issue on the agenda is just unknown pseudo elements. Are
there other issues for pseudos that can hop on and off of
existence?
<fantasai> https://github.com/w3c/csswg-drafts/issues/3607
fantasai: #3607
astearns: Gotcha
<fantasai> That transcript misses some of Tab's follow-up comments
* fantasai grabs the real minutes
astearns: Not happy to not resolve, but I don't think we have a
plan. What about we come up with a proposal for both
issues, discuss at F2F, come to a decision there. We use
time up to F2F to reach out to DOM people and anyone else
that would have real input on what to decide
Mark unimplemented CSSPseudoElement features at-risk
----------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/3540
fantasai: Suggestion is mark things unimplemented or drop them if no
one plans to implement. No one place to impl style method.
Other question is which pseudo elements do we want to
support. ::selection or just those that generate boxes?
Mozilla only supports ::before and ::after
astearns: I don't have an opinion as to which we have to support. I
noticed when reading spec there are lots of others in the
spec not mentioned here. It would be nice to have a note
as to why others are omitted
fantasai: I suggest we trim spec to subset mozilla supports unless
anyone intends to implement?
<leaverou> if it only supports a subset of supported
pseudo-elements, that's yet another reason to not throw
when other pseudos are used that are supported by the
browser but not by that API
astearns: Objections to trim set supports to ::before and ::after?
fantasai: And no style
astearns: Objections to either?
RESOLVED: Drop style from this level, restrict API to ::before and
::after, add a note to why the other things are not yet
supported
fremy: Begs question to what we should do for other things browser
supports. We should say what to do with other stuff.
fantasai: Yeah
astearns: Can you add a comment to the other issue mentioning we
should define that?
fremy: I can
Media Queries
=============
Clarification on prefers-color-scheme issues
--------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/3278
emilio: Basically, people are about to ship this MQ. There were
unsolved issues. Should be straightforward
emilio: One is what should MQ evaluate in boolean context.
florian: It's defined in spec. If there's disagreement to what's
defined I'm happy to hear it
emilio: People discussing on issue, but if spec says that's fine
florian: Same as no preference
dino: It makes using that form almost useless. You can't derive
meaning from it. If the query is prefers-color-scheme it will
evaluate to true if they picked on
fantasai: Not prefers-color-scheme is interesting though. Makes it
shorter to type out.
dino: You save 5 characters
TabAtkins: prefers-color-scheme and not is clearly you either do or
don't. It makes it this thing exists or doesn't and
that's what null communicates
<AmeliaBR> `@media not (prefers-color-scheme)` and `@media (
prefers-color-scheme: no-preference)` make sense as
equivalents, to me.
emilio: Other question is if it should match light on print or if
that's too smart
dino: That is another issue
astearns: I hadn't read the entire thread on #3278. Is that only
what to do in boolean context?
emilio: Yeah
astearns: Sounds like we have an answer. @media prefers-color-scheme
is the same as null
<dbaron> do existing implementations follow that answer?
astearns: It sounded like dino found it useless
dino: I don't know why you'd use it, but it does follow behavior so
it's fine
TabAtkins: Yes, we're looking for consistency in how other MQs are
handled
astearns: Proposal: Close this issue no change, it is defined in
spec.
astearns: dbaron asked in IRC if implementations match this
florian: I think we're light on tests
dino: We don't have any no-preference option
??: I think blink is one that would have to change
emilio: Blink matches
dino: We should contribute tests for this. Not sure how you can test
user choice
florian: That's always the problem with testing MQs.
TabAtkins: Generally they're all manual tests. They're very hard
dino: Internally we have JS API only exposed in test system to set
user preference for that page. Would be nice if all browsers
could standardize on an API to do things like this. Would
cover media style but nice if pointer events and touch events
and that type of thing. Not for this WG I guess
astearns: Sounds like there's consensus to close this issue and take
what's in the spec currently. Objections?
<fantasai> sgtm
RESOLVED: Close this issue no change, there is already language in
the spec
prefers-color-scheme and printing
---------------------------------
github: https://github.com/w3c/csswg-drafts/issues/3522
emilio: Somebody asked if prefers-color-scheme should always be
light web printing. Seems reasonable and I think it's what
webkit does. But author can already check that. Should we
define this?
<AmeliaBR> It sounds like something that the browser should include
in their Print UI, just like turning off background
images.
<AmeliaBR> (AKA, what Florian is saying)
florian: Feels like something up to UA. Seems reasonable UA choice
to switch to light when printing. I think a checkbox in the
print pop up is also reasonable as well. Saying UA can have
a different preference sounds good, but forcing light is
overkill
fantasai: I think suggest UA returns light when printing
<tantek> yes that seems reasonable
TabAtkins: What's returned is 100% UA determined, but most of the
time you want light when printing. Have a note that this
may vary on various factors, but printing should default
to light
dino: You might want dark if printing a PDF, but that's something
the UA can expose. I'm happy to default to light
fantasai: Suggest if you expect to print to paper you should
indicate a preference for white. Doesn't necessarily mean
PDFs should default to light
astearns: Proposed resolution: Do not have any normative text about
this. Add a note encouraging UAs to think about what
should be done for printing and to use light when they
know printing to paper
astearns: Objections?
RESOLVED: Do not have any normative text about this. Add a note
encouraging UAs to think about what should be done for
printing and to use light when they know printing to paper
Empty grid tracks should contribute to scrollable overflow
----------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/3638
astearns: Short intro to this topic
fantasai: Filed by someone using empty grid tracks. It was
showing...it's in a scrollable grid container and spacing
left by empty tracks not showing in Firefox because
different interpretations. Should scrollable overflow area
of grid container be only big enough to contain elements
or big enough for entire explicit grid. It's an
abstraction that's not a box
TabAtkins: Grid exists like flex lines. It's not a thing in the box
tree
fantasai: Argument against is impl that's the only thing that's
real. Authors expect including all grid tracks
Rossen: A grid element that itself is overflow:scroll?
fantasai: A grid container that's overflow:scroll with a bunch of
tracks and some items in it.
TabAtkins: Items in the grid fit within the visible area, but tracks
don't. Scrollbar or no?
jensimmons: Super interesting. If authors have extra tracks I think
they would expect to scroll
rachelandrew: Authors would expect a scrollbar. They expect the grid
to be real
plinss: Would you expect it to size to explicit grid lines if it's
not overflow:scroll?
fantasai: It does
plinss: Behavior should be consistent
Rossen: Are you saying the intrinsic size of the grid is the extent
for scrolling?
plinss: Yes
astearns: We're at time. That's an intro for this issue. It's an
interesting one and we should discuss in the future.
<TabAtkins> I forgot that we size it to the grid by default. I think
that's a reasonable argument for letting the grid be
part of overflow.
astearns: Thanks everyone for calling in and we'll talk next week
Received on Thursday, 14 February 2019 00:04:46 UTC