- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 17 Oct 2018 19:49:02 -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 Paged Media L3
------------------
- RESOLVED: Publish updated WD of Paged Media L3
CSS UI
------
- RESOLVED: Change cursor in vertical writing mode to a must (Issue
#3196)
CSS Grid
--------
- RESOLVED: Accept this edit:
https://github.com/w3c/csswg-drafts/commit/63a1d65afa5997a56b210c1cbddccdb2603ecec9
[A computed track list is a list alternating between
line name sets and track sections, with the first and
last items being line name sets.] (Issue #3154)
CSS Align & Grid
----------------
- RESOLVED: Content alignment and self alignment share a baseline
(Issue #3200)
Selectors 4
-----------
- There is a request for review of Issue #3071: :valid-within /
:invalid-within pseudo-classes
Multicol
--------
- During the discussion of Issue #3064 (Shouldn't column-fill: auto
take min-height into account?) there was interest in creating a
general approach to handling heights so this topic will be added
to the F2F agenda where it can be discussed with a whiteboard.
CSS Shadow Parts
----------------
- The right people weren't on the call to cover Issue #2386 (confirm
browser support) so it will be added to the F2F agenda
CSS Inline
----------
- RESOLVED: Add drop and raise as keywords to initial-letters
property (Issue #2955)
- RESOLVED: Order does not matter for the keyword in initial-letter
property (Issue #2955)
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2018Oct/0009.html
Present:
Rachel Andrew
Rossen Atanassov
David Baron
Tantek Çelik
Emilio Cobos Álvarez
Dave Cramer
Alex Critchfield
Benjamin De Cock
Elika Etemad
Javier Fernandez
Tony Graham
Dael Jackson
Cameron McCormack
Manuel Rego Casasnovas
Melanie Richards
Florian Rivoal
Jen Simmons
Alan Stearns
Greg Whitworth
Fuqiao Xue
Regrets:
Chris Harrelson
Peter Linss
Scribe: dael
CSS Paged Media L3
==================
astearns: Are there any changes to the agenda people would like?
xfq: I have one. Update CSS paged media L3
astearns: Republish?
xfq: Yes a working draft
<xfq> https://lists.w3.org/Archives/Public/www-style/2018Sep/0020.html
astearns: What has changed?
xfq: The current version on /tr is from 2013. It doesn't contain
some normative changes like the bleed property
xfq: I would like to request a new WD mostly because w3c css
validator needs a stable reference
xfq: Is there any objection?
florian: I haven't reviewed delta but I remember reading the ED
before and not finding a glaring problem. I'm in general in
favor
dbaron: I'd like to hear from editors if they support
fantasai: I think there should be update WD, don't think there's
controversy, but I haven't made a changes
xfq: I've seen commit and all substantive changes are in changes
list now
fantasai: Okay, then seems reasonable
astearns: Thanks for reviewing change list
astearns: Any objections to update WD of Paged Media L3?
RESOLVED: Update WD of Paged Media L3
astearns: Other agenda?
Housekeeping
============
astearns: Housekeeping: continue adding things to TPAC agenda. We've
got a good set but I'm happy to take more.
dbaron: I added a column for time conflicts. Might be useful if
people who will have to miss part of the meeting fill that
out.
astearns: Thank you. That would be very useful.
astearns: Also if you want to call in for particular topics it would
be good to know times and topics
<rego> https://wiki.csswg.org/planning/tpac-2018
CSS UI
======
Add value `horizontal-text` to property `cursor`
------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/3196#issuecomment-427739133
florian: Conversation has evolved. The property has 2 values about
text: text and vertical-text. 'text' is when it's a
vertical the I beam that usually shows like it's
horizontal, but the browser may show vertical at vertical
and may do angles. That we have one must on vertical-text
but a may on text it's a problem.
florian: Suggestion is change the may to a must. If it's over
vertical text you must match. Diagonal I think stays as a
should.
florian: If we get that for text we can deprecate vertical-text
dbaron: State of implementations switching to vertical?
florian: I don't remember. At least one impl does it, but I don't
remember if more than one
astearns: I'd be more happy to resolve if we have an impl report
astearns: If this is something we'd have to wait on bugs or if this
is uncontroversial
florian: It is not something everyone impl.
florian: I think I have the list, but I'd have to find it.
myles: Webkit does rotate
<heycam> Gecko also does
<heycam> just tested it
dbaron: I can tell you Gecko has code that does it, though I haven't
made sure it works
florian: Test harness is too slow to pull results
dbaron: It's possible we only work for auto
fantasai: Works for text
myles: Chrome, FF and Webkit all rotate
florian: So shouldn't have too many problems with must
<dbaron> I'd note the test should test behavior both with 'cursor:
auto' and with 'cursor: text'
<dbaron> and the Gecko code only looks at writing mode
florian: I will note current phrasing does not care if the text is
vertical due to a specific reason. Not sure we've tested
all those variants
astearns: Suggestion is change the wording that it's must when
writing mode gives you vertical?
florian: At least writing modes. If we can do any reason it's nice.
Angled cursor except 0 or 90 deg should be a should
florian: For 90deg transforms what do people think?
<fantasai> Gecko doesn't look at transforms
<fantasai> Neither does Chrome
gregwhitworth: With transforms we don't change ours. I would
struggle to feel that is a high priority for webdevs.
For vertical it makes sense. I think that's where I
would start and then try and find a common pattern
florian: So must on writing mode, should on transforms
fantasai: Yeah
myles: If no impl I'm not sure it should be a should
florian: Keep as a may?
gregwhitworth: May sounds right. Majority of webdevs aren't using
text you'd want copy/paste at odd angles. I'd put
may. If someone wants that step sure.
florian: So that's unchanged, make it a must for vertical writing
modes
astearns: Proposal: Change cursor in vertical writing mode to a must
astearns: Objections?
RESOLVED: Change cursor in vertical writing mode to a must
CSS Grid
========
Define computed value of grid-template-rows/columns
---------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/3154#issuecomment-428002686
fantasai: As part of fix computed values I noticed this. Wanted to
cross check with the group this seemed reasonable
fantasai: Current ED says [reads]
<astearns> https://github.com/w3c/csswg-drafts/commit/63a1d65afa5997a56b210c1cbddccdb2603ecec9
fantasai: What this means is no distinction in computed value of
50px and minmax(50px,50px). Functionally same so shouldn't
be a distinction
astearns: Any idea about what's implemented?
fantasai: Didn't check
fantasai: It's hard to check because getComputedStyle is the used
value for these prop so can't retrieve computed value
fantasai: Main check would be animating between. Not sure animation
is well supported
fantasai: This would clarify.
rego: I think animations aren't working on any mpl yet so hard to
check.
astearns: I like the clarification and seems reasonable to me.
Haven't thought through implications for animations
fantasai: What this does is makes it as likely as possible to
animate between 2 values so that functionally same values
compute to each other. Everything matches so values that
mean the same are represented same.
fantasai: Additional magic we might want for animating, but that's
issue #3201. Computed value that's best we can do to make
animation as easy as can be
astearns: Other comments?
astearns: Concerns?
emilio: Can test be written? All this is tricky and to get interop
tests would be best
fantasai: Tests would be for animation and this is not being
animated as far as I know. But we can write tests
astearns: When someone impl animations for these properties tests
will need to be written
<emilio> yeah, fair enough
astearns: Concerns or objections on taking this edit:
https://github.com/w3c/csswg-drafts/commit/63a1d65afa5997a56b210c1cbddccdb2603ecec9
?
RESOLVED: Accept this edit:
https://github.com/w3c/csswg-drafts/commit/63a1d65afa5997a56b210c1cbddccdb2603ecec9
<fantasai> https://github.com/w3c/csswg-drafts/issues/3201
fantasai: Issue #3201 is looking for impl feedback and is related
CSS Align & Grid
================
Can baseline content-aligned items and baseline self-aligned items
align together?
------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/3200
fantasai: We noticed spec was inconsistent on if there is 1 or 2
first and last baselines. Depends on if elements use
content or self baseline alignment
fantasai: We think intent was 1 baseline and that simplifies amount
of info impl keeps. Want to make sure there aren't
problems we didn't think of
fantasai: dholbert and javier think it's right way to go
<fantasai> Proposal: Align the note and clarify css-align to match
10.6 in Grid: there is only one baseline that is shared
across items in an alignment context, and both types of
baseline alignment use it.
astearns: Thanks for dholbert and javier for putting their approval
in issue
astearns: Other opinions?
fantasai: Content alignment and self alignment share a baseline
astearns: Objections to Content alignment and self alignment share a
baseline?
RESOLVED: Content alignment and self alignment share a baseline
Selectors 4
===========
:valid-within / :invalid-within pseudo-classes
----------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/3072
fantasai: Proposal to add :valid-within and :invalid-within pseudo
classes. Seemed reasonable. Want to know if WG thought we
should add
astearns: Anyone with a ready opinion?
fantasai: Not urgent
astearns: Let's take this as a call for review and add comments in
github
heycam: I can add comment to issue. Alternative is you have a pseudo
class on the form and not just any arbitrary ancestor
fantasai: I think that's what we do, but I'll check. If it's not we
can make it work on form
fantasai: I think that would solve the use case. If it works on
forms and fieldsets maybe.
* heycam didn't think about fieldsets; nor did he look at the test
in the issue
fantasai: Looks like they're using at a smaller level for a segment
of a form. Don't know if that solves the use case.
fantasai: We can continue that conversation in issue
astearns: Thanks for bringing it to attention. Please comment on the
issue and we can see if we should take or modify this
Multicol
========
Shouldn't column-fill: auto take min-height into account?
---------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/3064
fantasai: If you have column-fill:auto it doesn't take effect if you
have auto height multicol container. Goal of auto is fill
first column then move rather then balance. Fixed height
or page we can fill.
fantasai: Commenter said if height works, why not fill up to
min-height?
fantasai: Reasonable to me. rachelandrew agrees
florian: Max is reasonable, but why min?
florian: Why would you stop at a min.
fantasai: Because at the min you balance.
dbaron: If you have more than that? You've filled all columns at min
and you have more, do you go back and do it again?
rachelandrew: Yes, I think so.
dbaron: Seems like a very special case. I don't feel it's work
adding the complexity of redoing it a second way because
someone suggested it's nice
myles: Second that
florian: I'm a big fan of multicol being smarter, but I'm not
convinced on this
fantasai: What's happening now is if you have a min-height and you
say auto it will balance and not fill the column. You have
all this extra space because you have a min-height. Was
max-height you don't necessarily have extra space.
florian: What do you mean you balance?
astearns: Useful for case where there is not enough content when
columns balanced to meet min-height. In that case all
columns don't fill min-height. Change is some columns
would fill min-height. Too much content, though, is a
second pass
rachelandrew: Request makes sense. If it's worth impl is different
issue. Expectation makes sense.
florian: I need to re-read. astearns explanation sounded different
astearns: I might be wrong, that's my take
dbaron: I get the model, but having trouble imaging the design where
someone wants this
fantasai: Can go back to commenter and ask for more info
rachelandrew: Using min-height we haven't seen much because only
float was available. Now that we have grid people
thinking about layout different. Using min-height is
common and powerful. If there's more content I want to
use min-height because I don't want it to be smaller
then viewport.
rachelandrew: At first glance this looks like a powerful use case
that would be helpful. But I've been looking for 2.5
minutes
dbaron: Broader then min-height? whenever the height comes from
something else?
florian: Original comment was more shouldn't make auto take computed
height?
fantasai: Question is shouldn't column-fill:auto...okay, yea.
dbaron: Another example is if you have a multicol whose height is
stretched should column-fill: auto work? I think not right
now
rachelandrew: As an author I want it to work the same everywhere
rachelandrew: If the height is created by a grid track or a
min-height...all the many ways to create height. They
should all look the same
dbaron: More sympathetic for a general approach then just min-height
florian: Same here
rachelandrew: Makes sense
astearns: rachelandrew do you think there's enough for you to work
on this?
rachelandrew: I'll think about it. Maybe discuss at F2F?
astearns: A whiteboard would be good for this
rachelandrew: I'll have a think on this
astearns: Let's add F2F Agenda tag to this
CSS Shadow Parts
================
confirm browser support
-----------------------
github: https://github.com/w3c/csswg-drafts/issues/2368#issuecomment-429342082
astearns: Is TabAtkins on?
fergal: I'm here, but I was hoping TabAtkins would be.
astearns: Will you be at F2F?
fergal: No. I was hoping to have agreement before
astearns: Summarize agreement?
fergal: There is a draft spec. Agreement I believe we have is there
will be no idl for this in initial version. Agreement on
minimal version that's acceptable. We have naming right for
everything. There will be a part= and exportparts= and
syntax is colon separate inner and outer name
fergal: We postponed multiple parts with an *. Everything with theme
is postponed.
fergal: But I don't know if anyone else on the call understands that
dbaron: Is that written somewhere?
fergal: It's in the issue. That list is there.
dbaron: I see 50 or so comments. Is there one to look at?
fergal: Toward the bottom
<astearns> 20 days ago
fergal: From 15 days ago
<fantasai> fergal,is it this comment?
https://github.com/w3c/csswg-drafts/issues/2368#issuecomment-426472596
Rossen: What's the urgency to agree before TPAC? Especially since
you said you wanted names agreed to proceed?
fergal: No particular urgency, just that this has gone for a long
time. I won't be at TPAC
Rossen: Is this something TabAtkins can handle in F2F?
fergal: I think so. I don't know for sure that Ryosuke Niwa is going
to tpac
myles: He is
fergal: If there's no one on the call who was in the discussion it
has to wait.
astearns: Summary is still useful
astearns: We'll let you know fergal what time at TPAC in case you
can call in
fergal: Great
CSS Inline
==========
raise/drop keywords for initial-letters
---------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/2955
fantasai: Someone asked for keywords representing drop-caps vs
raised-caps rather then use numbers
fantasai: Thought it would be easy to say drop computed to integral
floor and raise computes to 1. It's a question of if WG
things work adding
<fantasai> https://github.com/w3c/csswg-drafts/issues/2955#issuecomment-430277200
<fantasai> Amelia's follow-up comment on reordering:
https://github.com/w3c/csswg-drafts/issues/2955#issuecomment-430323643
fantasai: Summary of proposal^
astearns: Reasonable to me.
astearns: I like keywords rather than opaque numbers
dauwhe: Reasonable to me too
astearns: Objections to adding drop and raise as keywords to
initial-letters property?
<tantek> +1 to keywords
RESOLVED: Add drop and raise as keywords to initial-letters property
fantasai: Follow up is if we can swap order of keyword letter and
number
<fantasai> https://github.com/w3c/csswg-drafts/issues/2955#issuecomment-430323643
astearns: Seems CSS-like
<tantek> it depends. background does that. border does not.
<fantasai> “Would it be possible to tweak that syntax so that drop 3
and raise 2 are valid values? (While still being
unambiguous for parsing when there are two integers.)”
fantasai: Comment^
astearns: tantek responded in IRC [reads]
astearns: I assume because border it would not be unambiguous
fantasai: Right. I think the principle is if it's unambiguous you
can reorder
<dbaron> We've had properties where swapping ended up being
confusing like x/y in background-position
astearns: Any future thoughts on adding to the syntax? Where
re-ordering might not be unambiguous?
<tantek> I lean towards usability (forgiveness) up front, thus
allowing re-ordering.
<tantek> makes it easier to author off the top of your head
fantasai: I don't think there's other relevant numbers. Can't think
of anything. We've had people asking for lots of features
and none is more numbers
dauwhe: I can't think of anything either. Lots of wants, but they're
additional properties.
astearns: dbaron mentions properties where swapping was confusing
astearns: Not sure it's a problem here, at least in my mind it's not
confusing to put keyword where you want
astearns: Objections to allowing the keywords to be put in either
position along with the number?
dbaron: I think some depends on how much we might extend. Initially
with background-position-x/y we thought it was fine to let
people put in either order. Then we extended and it was
confusing.
fantasai: I think the part that's confusing there is when you have
one keyword and one non-keyword and there's strict order,
but not in other cases
fantasai: This one we're doing opposite. No strict order when
there's a keyword and it's unambiguous
<AmeliaBR> Jumping in as the person who suggested it: There's no
harm with starting out with the more strict syntax & then
seeing if there's any author confusion/frustration.
astearns: Leaning a bit more toward dbaron. I'm a little concerned
we might want to extend values syntax here.
astearns: If there isn't anything anyone can think of that would
extend syntax, and I know dauwhe has put a lot of thought
into this, I'm okay with allowing the swap
astearns: AmeliaBR said she's okay with a particular order now and
figure out swap later.
astearns: dbaron what do you think?
dbaron: I'm okay with it if we don't see future possibilities to
expand. But if this becomes 3 value at some point letting
these two swap might be problematic
astearns: One way to look is we're committing to extra properties if
we want to extend. And that's not a bad thing. More
properties with a name makes it clear what you're doing
rather then adding a value in a list
fantasai: I can't think of a reason to add another number to this
feature
dauwhe: Yeah
tantek: Tend to agree if a property requires ordering of numbers
it's confusing. Classic example is how many people get
latitude and longitude wrong. That's a classically studied
problem.
tantek: We barely get away with TRoBLe
[argument if that even works]
tantek: Larger point is list of numbers has been shown to be a
usability problem
astearns: Hearing slight concerns but no objects. I'm inclined to
propose: Order does not matter for the keyword
RESOLVED: Order does not matter for the keyword in initial-letter
property
Housekeeping
============
astearns: Anything in 4 minutes?
Rossen: Question- status of the proposal for static variables?
Rossen: I remember dino brought this a few F2F ago and we've been
getting requests for this. Curious where we stand, is it in
a spec, can we bring to TPAC perhaps?
Rossen: Is this happening?
astearns: I see a draft in a repo
<astearns> https://drafts.csswg.org/css-env-1/
Rossen: Awesome. I'll put this on F2F agenda
myles: We're shipping it
Rossen: Cool. I'll try to play with it. Thanks.
astearns: Safe travels everyone. For those not going to TPAC please
let me know if you want to call in to any of the meeting.
astearns: Thanks for calling in!
<rego> Chromium is shipping env() too:
https://www.chromestatus.com/feature/5710044637167616
<myles> Rossen: https://webkit.org/blog/7929/designing-websites-for-iphone-x/
<myles> Rossen: these are the ones we support:
https://trac.webkit.org/browser/webkit/trunk/Source/WebCore/dom/ConstantPropertyMap.cpp#L53
Received on Wednesday, 17 October 2018 23:49:56 UTC