- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 14 Feb 2018 19:19:55 -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.
=========================================
Selectors
---------
- RESOLVED: Remove drop pseudo class. (Issue #2257)
CSS Values & Units 3 and CSS 2
------------------------------
- RESOLVED: Revert the change [to Values & Units about how to handle
an empty URL] and open an issue noting that we had this
change and we're not sure about it at this point. (Issue
#2211)
- astearns will complete the tests he was preparing so that
republication of Values & Units 3 can happen next week.
CSSOM
-----
- RESOLVED: Add serialization principles to CSSOM (Issue #1564)
- TabAtkins will make these edits as the spec doesn't currently
have a full editor.
Process
-------
- astearns will make new github label to distinguish edits where the
community is invited to make the edits as well as edits that are
good for a newcomer.
CSS Typed OM
------------
- RESOLVED: Keep last week's resolution for Houdini issue #610, say
ignore instead of throw, and for matrix use the previous
behavior with an issue noting we'd like to enforce in
the same way but we don't know how.
Media Queries
-------------
- RESOLVED: Have calc serialize in MQ same as properties, have that
called out in the spec, and then test to see if we can
follow that. (Issue #1968)
CSS Contain
-----------
- RESOLVED: Have the break properties not affected by style
containment. (Issue #1872)
- Florian will create a PR to move flow-from and flow-into into
Regions spec.
CSS Sizing
----------
- RESOLVED: Accept the change in
https://github.com/w3c/csswg-drafts/issues/2248#issuecomment-362114572
(auto computes to auto always, but the resolved and used
value of auto is 0 on non-flex or grid items)
- RESOLVED: Have min and max content keywords behave for textarea's
height the same as for blocks in the height property.
(Issue #2141)
- RESOLVED: Have min and max content keywords for width property of
inputs and textarea to size based on contained content.
(Issue #2141)
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2018Feb/0010.html
Present:
Tab Atkins
David Baron
Tantek Çelik
Elika Etemad
Simon Fraser
Tony Graham
Dael Jackson
Chris Lilley
Peter Linss
Michael Miller
Anton Prowse
Melanie Richards
Florian Rivoal
Dirk Schulze
Geoffrey Sneddon
Alan Stearns
Lea Verou
Regrets:
Dave Cramer
Benjamin De Cock
Daniel Glazman
Brad Kemper
Vlad Levantovsky
Manuel Rego Casasnovas
Jen Simmons
Scribe: dael
astearns: Let's get started.
astearns: Does anyone have anything extra to add to the agenda?
astearns: Is TabAtkins on yet?
[silence]
astearns: We'll skip item #1 and #2.
Selectors
=========
drag and drop
-------------
github: https://github.com/w3c/csswg-drafts/issues/2257
astearns: Suggestion was drop the drop pseudo class since they have
nothing to hook into.
florian: What happened to what they hooked into?
gsnedders: There was no implementation interest in it.
astearns: There was a drop zone global attribute that wasn't gaining
traction so they removed it.
astearns: Objections to removing drop pseudo class for now?
RESOLVED: Remove drop pseudo class.
CSS Values & CSS 2
==================
empty url() behaviour needs errata to match Level 3
---------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/2211
fantasai: Basically gsnedders found css2 and values3 disagree what
to do with an empty URL.
fantasai: Looks like we decided for L3 to make it invalid instead of
refer to location of stylesheet. I couldn't find the
minutes of that resolution so if anyone remembers that
discussion it would be useful. We should make specs agree
and impl to agree with specs.
astearns: Do we have data on current impl?
fantasai: gsnedders do you know? I tested using computed values
where I got URL of the page, it was invalid.
gsnedders: I think Chrome & FF resolve to page itself. I'm not sure.
astearns: Proposal is change L3 to match impl and revert the invalid
resource bit?
fantasai: Would need to look what that looks like in the changeset.
I have no real opinion on which way to go.
astearns: I spent time trying to find the resolution that lead to
this and I failed as well.
astearns: What should we do fantasai? Resolve to revert or do more
research and see what's impl, have tests, and then decide
on how to change L3?
fantasai: I think we have a fairly good idea. Test we ran so far
it's not treated as invalid. It's supposed to be parsed as
incorrect. Since this is a spec in CR and we have 2.1 and
previous version say valid points at page we should
revert. If someone thinks revisit we can re-open it.
That's my opinion because we want to update V&U.
fantasai: If we're not sure what to do don't make the change, file
an issue, leave it open for later.
astearns: Given that we're still trying to figure out why we made
the change it makes sense to open an issue.
fantasai: Then let's revert the change tot he draft and publish.
astearns: What about revert change to draft, leave change and note
as a comment in the draft so there's something in the
source?
fantasai: I can mark it as an issue in the draft, this is CR spec.
That text I can leave it commented in and that text is
linked from the issue.
astearns: Sounds fair.
astearns: Proposal is revert the change and open an issue noting
that we had this change and we're not sure about it at
this point.
astearns: Objections?
RESOLVED: Revert the change and open an issue noting that we had
this change and we're not sure about it at this point.
Publication
-----------
fantasai: That's the last issue and there's a DoC. I'd like to
resolve to republish CR.
astearns: I started writing tests for second to last issue and I
haven't updated tests to match the negative calc
resolution. I'd like to update the tests in the next week
and then we can resolve to publish.
astearns: Sound good?
fantasai: That's fine.
CSSOM
=====
Spec no longer defines the general "shortest serialization" principle
---------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/1564
fantasai: Main issue is we need someone to make edits. There's no
active editor. This keeps coming up as some editor is
confused as to why Firefox serializes different and it's
because this isn't in the spec.
fantasai: Can we assign somebody to do the edits?
astearns: There's the edits to re-introduce the shortest
serialization and the other principles dbaron mentioned.
fantasai: Yes, they should all be in the spec but no one is owning
them.
astearns: I would love to have an editor for CSSOM. I've been trying
to recruit one. Anyone on the call willing to volunteer?
TabAtkins: I can do particular issues, but not the new general
editor.
astearns: Can we tasks you to add the principles in the issue? Just
this edit.
TabAtkins: Absolutely.
tantek: Not volunteering. Do we have a label for something like PR
desired where there isn't someone assigned but we'd welcome
someone to do a PR for this item?
astearns: We don't but it would be good. A first issue tag for easy
things would also be good for someone new.
<Chris> "Good first issue"
florian: We have edits needed, but it doesn't distinguish.
tantek: This is a callout to a volunteer stepping forward instead of
saying this is the a to do list.
tantek: This is a good example where it's non-normative text where
it's a easy first edit.
fantasai: This isn't non-normative
tantek: Reading dbaron's text it sounded like it's non-normative.
TabAtkins: This is in the guideline of things where we really want
to say it normative but there's too many variations. This
needs an experienced editor.
florian: The principle of tantek's ask is sound.
fantasai: Spec is normative and will say there are exceptions. For
properties should should be able to apply these and get
correct serialization.
tantek: I think enough text is in there that a new person could do a
decent PR. This is the kind of edit I'd welcome someone
taking a shot at. Anyway. Didn't mean to sidetrack.
astearns: It would be good to have a tag saying outside submissions
welcome and a tag that says this is unassigned and we
don't have an editor.
TabAtkins: Agree to both.
<dbaron> I think this is the sort of edit where I'm likely to have
substantive disagreements with draft text by Tab, and Tab
would be likely to have substantive disagreements with
draft text by me.
astearns: objections to putting these principles into cssom?
RESOLVED: Add serialization principles to CSSOM.
ACTION TabAtkins to make the edits in
https://github.com/w3c/csswg-drafts/issues/1564
<trackbot> Created ACTION-867
ACTION astearns to come up with new tags for new edits
<trackbot> Created ACTION-868
CSS Typed OM
============
Does the is2D design allow for inconsistent interpretation of
CSSTransformComponents?
-------------------------------------------------------------
github: https://github.com/w3c/css-houdini-drafts/issues/610
TabAtkins: This needs a revisit because I remembered the reason I
made a choice.
TabAtkins: Short recap, dbaron suggested that is2D causes behavior
changes so if it's set to true we throw on changes that
would touch 3D parts of an object. Problem is matrix
component. It doesn't reinvent 2 or 3d objects on its
own. I didn't want a low power of the DOMMatrix.
TabAtkins: So the matrix object just contains a DOMMatrix. Problem
is DOMMatrix doesn't have this logic. is2D flag is read
only and just reflects if it's 2d or 3d. There's no way
for the is 2d flag on the transform to effect how the
DOMMatrix responds to operations. There's nothing in the
spec for it now and it would be a tear away problem.
Things are linked in lifecycles which is awkward for
implementations.
TabAtkins: There's no way to do this thing on the matrix component
as designed. We can't even split into 2 or 3d because the
2d will still want a matrix.
TabAtkins: That's why I went that is2D is a declaration from the
author and we ignore the 3d-ish parts rather then the
more controlling way. So I think we need to revert unless
someone has a more clever way
krit: For DOM we made the flag read only on purpose because
different transversions where something looks 2d but is 3d.
TabAtkins: Right. Same policy is elsewhere. A translate with 0 on
the z axis is still 3d. It's a product of your intent not
the contents. I agree the DOMMatrix isn't a bad design,
it's trying to do a different thing then transform are
trying to do.
dbaron: I'm not especially happy. It think it's worth leaving an
issue to see if somebody can come up with something better.
TabAtkins: Yeah. If we're going to go with that I would prefer to
change my recommendation from last week to ignore instead
of throw since that'll be consistent with us coming up
with a good way to do it that works.
TabAtkins: If we stick with the solution from before where is2D just
changes serialization, if we can solve the matrix
component then sets to 3D will do something and I'd
prefer we do something in case it's stuck for an extended
period of time.
TabAtkins: So ignore sets rather then throw.
astearns: Work for you dbaron?
dbaron: I'm okay with that.
astearns: As far as I understand suggestion is we keep previous
resolution but change so we don't throw on sets.
TabAtkins: Ultimate issue is I have no way to enforce the previous
resolution on matrix. So keep last week, say ignore
instead of throw, and for matrix use the previous with an
issue noting we'd like to enforce in the same way but we
don't know how.
astearns: Objections to this path?
RESOLVED: Keep last week's resolution, say ignore instead of throw,
and for matrix use the previous behavior with an issue
noting we'd like to enforce in the same way but we don't
know how.
Media Queries
=============
How do media queries with calc() where it can be resolved early
serialize?
---------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/1968
florian: A few weeks back we decided that calc is supposed to
simplify down as soon as it can, but not simplify away.
florian: Raised against MQ. Implementations were new, but 2 new impl
we not doing that. Chrome was about to agree to not do that
which means remove the calc when serializing. In same
discussion it was raised if combining length units early
was what we wanted.
florian: I don't have a stand, but since impl sort of disagree on
the resolution we need to revisit. I think TabAtkins
thought what we resolved was good.
TabAtkins: I'm not strong either side. Whatever works.
florian: Do we have anyone who wanted to impl the other thing?
[silence]
astearns: Not enough strong opinions on the call.
astearns: Reading dbaron's comment it sounds like you'd be against
dropping calc?
dbaron: I'm catching up on the issue
dbaron: I was pointing out one issue with dropping calc it sometimes
makes a thing valid that wouldn't be valid without the calc.
We don't check range restrictions in calc.
florian: In FF and webkit that's what they do. If you have aspect
ratio of -1/-1 with a calc it serialized through as all
which is what you'd expect.
dbaron: Maybe...I don't know how well calc validity rules are
specified. Changing validity rule would need to be specified
carefully.
florian: In same discussion MQ in em serializes to em but em+px
serializes to px in a calc and why.
florian: Do we need to revisit how calc serializes in MQ? Happy with
existing rules? Revisit based on impl?
[silence]
florian: Asking differently: When we resolved on rules for calc in
general context were people in favor of what we resolved
remembering MQ or did we forget and need to investigate?
astearns: I do not recall MQ being part of that conversation.
fremy: I don't see a point of making them different. We don't
support calc but if we did it would be same as properties. If
no one is arguing different we should stick with what we have.
florian: Yep. It was pointed out all impl don't do that but it could
be a bug. There isn't a problem of web compat because this
is new. But if we resolve one thing in spec and everyone
impl something else it's not helping.
florian: In other words, I'm happy to close won't fix and I'm happy
to take tests from fremy and then file bugs one people.
Deal?
fremy: Why not ^-^
astearns: Proposal is close, have clamping in MQ calc be exactly the
same as for property values. We'll then have tests to see
what's been impl and see if it matches reality?
florian: Informal tests say they don't, but formal lets us file bugs.
astearns: I like not having something special for MQ. But I think
it's useful to have something explicitly discuss this in
MQ spec so we can hang a test off it.
florian: Sure...
florian: I'll phrase it to explicitly refer to the canonical text.
Sounds good.
astearns: Proposal is have calc serialize in MQ same as properties,
have that called out in the spec, and then test to see if
we can follow that.
astearns: Obj?
RESOLVED: Have calc serialize in MQ same as properties, have that
called out in the spec, and then test to see if we can
follow that.
CSS Contain
===========
Clarify style containment effect 1
----------------------------------
github: https://github.com/w3c/csswg-drafts/issues/1872
florian: There's a thing called style containment with 2 groups of
effect. #2 isn't under discussion, that's fine. What's
under discussion is how style containment should/shouldn't
affect break-before and break-after.
florian: A number of people said affecting made no sense. TabAtkins
wasn't sure. TabAtkins are you now sure?
TabAtkins: I think we can remove it.
astearns: Proposal is to have the break properties not affected by
style containment?
florian: Or drop the part that claims they are.
astearns: Objections?
RESOLVED: Have the break properties not affected by style
containment.
florian: Part 2 talks about flow-from and flow-into. I think that
should be moved to regions spec given relative maturity.
astearns: I think that's fine. Can you open an issue on regions to
add that?
florian: I can open a PR that changes both specs?
astearns: Even better.
CSS Sizing
==========
Decide how to handle `min-width/min-height: auto` for non-grid/flex
items
-------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/2248
<fantasai> https://github.com/w3c/csswg-drafts/issues/2248#issuecomment-362114572
fantasai: The issue is about what do we do with computed values on
non-grid and non-flex items. Behave as 0. dholbert
proposed auto keyword computes to itself on all display
types, but the resolved value should be 0.
fantasai: This has a couple of advantages. One is that it makes the
computed value easier to compute, the keyword isn't based
on display type information. Second advantage is there was
some behavior we were trying to resolve for another issue
which required us to distinguish between auto and 0 min
sizes on elements that are no flex and grid so being able
to refer to that is good.
fantasai: Disadvantage if you're animating from initial value of
assumed 0 on the min-height and min-width, that breaks.
fantasai: Not sure how many people are animating that and, if they
are, assuming initial value of 0.
fantasai: I think we should take proposal, but want to hear from
group. Toward the end of the issue there's discussion
about a separate item that needs to file separately.
astearns: Other opinions?
astearns: Proposal is have the computed value be auto but the used
value be 0?
fantasai: Used value is 0. Resolved value would be 0.
Change...currently computed value is 0, computed value
remains as the keyword auto. If you use getComputedStyle
we'll return 0 for backwards compat.
fantasai: Kinda like we do for width where auto computes to self but
getComputedStyle returns 0.
astearns: Objections to this change?
RESOLVED: Accept the change in
https://github.com/w3c/csswg-drafts/issues/2248#issuecomment-362114572
Please add vertical auto-resize textarea field
----------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/2141
fantasai: Had a number of requests for form control textarea able to
take size from height on contents. Currently auto means
take from rows and cols.
fantasai: Proposal is new min and max content behave on textareas
more like blocks.
fantasai: 2 questions 1) should we do this for textarea for block
dimension. 2) do we want to consider this in the inline
direction?
fantasai: Take them one at a time.
fantasai: We previously discussed this on iframe, but that's
separate due to more security concerns.
fantasai: Should min and max content on the height of a textarea
tell the textarea to take height from the amount of
contents it has.
dbaron: This is a new feature where as you type in the textarea the
size changes?
fantasai: Yes.
astearns: Can change.
tantek: I've seen that effect via JS.
TabAtkins: Easy to do in JS.
tantek: Shouldn't need JS though.
fremy: As I mentioned in issue I'm fairly confident this is a good
feature. I've had people use JS and get it wrong. Still
concerned about min-content being bigger then auto. Maybe
only say max or have something special for min.
dbaron: For textareas they have a different min and max content
because the way they wrap. Generally they allow any
character for wrap though that might vary.
florian: I don't think any character is the case.
dbaron: At least in emergency cases. Something long and unbreakable
it'll wrap rather then force scroll.
florian: If so that's probably consequence of styles. I don't think
there's anything that calls for different text wrapping in
these. I don't recall seeing any that didn't look like
bugs. But you can achieve the effect by applying CSS and
that may be in the UA stylesheet.
<dbaron> Gecko's wrapping styles for textarea { white-space:
pre-wrap; word-wrap: break-word; }
astearns: With regard to fremy concern about min-content being
bigger then auto, is that the case for blocks?
fantasai: I'm confused about this concern. I don't see why it's
different. It's definitely true on grid items where auto
can be smaller then min-content. Auto says use this other
formula which is some cases but not all based on content.
fantasai: I don't understand the concern about auto having to have a
relationship with min and max content. I'd prefer if they
behave just like they do for blocks. Only think that needs
to be different is auto itself.
astearns: Sound reasonable fremy ?
fremy: I'm still not sure...it's possible that auto is smaller than
min-content. I'm surprised. In my mental modal auto is always
bigger.
fantasai: But that's not true.
fremy: Possible. If that's not true then fine.
fantasai: [gives example when it's not]
astearns: The current discussion is using min and max content
keywords and have them behave for textarea's height the
same as for blocks in the height property.
astearns: More concerns or discussion?
astearns: Objections?
<TabAtkins> yay!
<TabAtkins> (I had Francois' concern as well, but Elika convinced
me.)
RESOLVED: Have min and max content keywords behave for textarea's
height the same as for blocks in the height property.
astearns: Inline direction
fantasai: Since we're working on this for form controls we have
option to make it apply in inline direction. Not sure it's
useful for textareas. On inputs I could see people might
want to use it to size an input. Question is do we make
these keywords work on those.
TabAtkins: In inline axis we care more about min and max interacting
with auto. That's how floats work. If we were to let
min-content refer to actual content it would change
behavior. If you had a long word wider then textarea it
would change size.
fantasai: Auto means use the size spec in the html attribute or
default to the size.
<rachelandrew> +1 for the inline direction, makes sense that we can
do the same in both axes.
fantasai: The min-content contribution has nothing to do with
min-content size of element. Nothing to pinch unless you
spec min or max content keyword nothing would change.
TabAtkins: You're right. Nevermind.
astearns: rachelandrew put +1 on IRC
astearns: Proposal is to have min and max content apply to both
inputs and textareas? With the previous for the height is
it only textarea or also inputs?
fantasai: Let's start with just textareas? Inputs are one liners.
astearns: But for inline this would be both?
fantasai: That seems reasonable. I'm also okay to only do it for
input if people are uncomfortable with textarea.
astearns: Concerns about inputs and textareas?
astearns: Proposal: have min and max content keywords for width
property of inputs and textarea to size based on contained
content.
astearns: Objections?
RESOLVED: Have min and max content keywords for width property of
inputs and textarea to size based on contained content.
astearns: Is anyone chomping at the bit to impl and give feasibility
feedback?
[silence]
astearns: We'll have to see how long this lasts in this level of the
spec
astearns: Thanks everyone for calling in. We'll continue sizing
issues next week.
astearns: Thanks all!
Received on Thursday, 15 February 2018 00:21:19 UTC