- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 10 May 2017 23:31:55 +0300
- 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.
=========================================
Spec Rec next steps
-------------------
- Most specs were addressed over email in advance of the call.
- astearns submitted a pull request for the final changes needed
for Writing Modes.
DOMMatrix stringifier behavior doesn't seem to match implementations
--------------------------------------------------------------------
- RESOLVED: In the case of NaN we would throw an exception during
serialization.
Stretching image grid items in both dimensions
----------------------------------------------
- RESOLVED: Stick with Seattle resolution: making the default
intrinsic.
Rename `auto` to `legacy` for `justify-items`
---------------------------------------------
- RESOLVED: Rename auto to legacy.
Alignment publication
---------------------
- RESOLVED: Move CSS Alignment to CR with the added legacy value
defined as at-risk. The action of starting the CR
process will start in 2 weeks (May 27) unless we hear
elsewise.
Question re white space processing rules for U+000D
---------------------------------------------------
- RESOLVED: Accept the change in
https://github.com/w3c/csswg-drafts/issues/855
How does 'inherit' keyword behave in a child of ::first-line?
-------------------------------------------------------------
- fremy will write a summary of the proposal on the GitHub issue
so the group can resolve next week.
Allow percentages for `column-gap`
----------------------------------
- RESOLVED: Add percentages for `column-gap` to L1 and mark as
at-risk.
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2017May/0022.html
Present:
Rachel Andrew
Rossen Atanassov
Tab Atkins
David Baron
Bert Bos
Tantek Çelik
Dave Cramer
Alex Critchfield
Elika Etemad
Robert Flack
Simon Fraser
Tony Graham
Dael Jackson
Brad Kemper
Peter Linss
Myles Maxfield
Michael Miller
Simon Pieters
Anton Prowse
Florian Rivoal
Jen Simmons
Geoffrey Sneddon
Alan Stearns
Greg Whitworth
Regrets:
Vlad Levantovsky
Lea Verou
Scribe: dael
Spec Rec next steps
-------------------
Rossen: Let's get started. Hello everyone.
Rossen: Are there any extra items people want to add?
Rossen: Thanks to everyone who replied to emails. Almost
everything is replied.
Rossen: One thing I couldn't gage is writing modes. Did we make
the editorial change?
astearns: I submitted a PR. It needs fantasai review and merged.
Rossen: Awesome. Thanks astearns.
Rossen: The other thing...there were a few specs that were still
waiting for dbaron or someone from Mozilla for tests and
discovering if there were some that could be contributed.
Is any of that materializing now that we're past F2F?
[silence]
Rossen: I'll take that as a no.
Stretching image grid items in both dimensions
----------------------------------------------
Github Topic:
https://github.com/w3c/csswg-drafts/issues/523#issuecomment-295075752
Rossen: I don't see fantasai yet.
Rossen: Anyone from Mozilla want to handle this? Or do we move on?
Current tag is customer not satisfied.
TabAtkins: We should wait on fantasai because she might have more
to the topic to explore.
DOMMatrix stringifier behavior doesn't seem to match implementations
--------------------------------------------------------------------
Github topic: https://github.com/w3c/fxtf-drafts/issues/120
zcorpan: DOM Matrix has [missed] for parsing a string. The string
is CSS syntax. Values are unrestricted doubles so you can
have non and infinity and it's unclear what the
serialized is to do. If it returns NaN and infinity with
JS.
zcorpan: I think the most reasonable things is to just use
ECMAScript to string.
TabAtkins: I asked in the related thread what's the benefit of
allowing infinity and NaN in CSS and I'm not sure how
the thread on DOMMRect you pointed to answer the
question.
TabAtkins: At the bottom of fxtf draft you reference the issue
1343 in CSS.
TabAtkins: You proposed CSS syntax should allow infinity and NaN
so DOMMatric can round trip. I asked what was the
benefit and you pointed to another thread.
<smfr> TabAtkins is referring to
https://github.com/w3c/csswg-drafts/issues/1343
zcorpan: It does cover DOMMatrix in that thread. It's part of the
thread.
zcorpan: It's with one level of quotation for the reason of using
unrestricted double in geometry APIs.
TabAtkins: What transforms can produce a NaN or infinity in here?
zcorpan: I'm not sure if it's possible.
TabAtkins: We don't allow the values. It can't be possible because
then we'd have transforms without matrix.
ChrisL: You can generate one and re-serialize it.
zcorpan: Exactly. If you do 1/0 it's an error now but it could be
infinity instead.
TabAtkins: It could in theory but it doesn't yet and we don't have
a proposal to do it yet. afaict the only things that
can produce NaN or infinity are operations we don't
allow. I'm still not clear on the benefit of allowing
CSS to recognize them because it doesn't mean anything
in CSS. If you gave this to transform what would it do?
zcorpan: I don't know. How matrix work is above my head, but you
can end up with NaN and infinity so I wanted to get a
resolution on how this would parse. I don't have a use
case for it.
TabAtkins: Alternative is in other cases where you can get into a
state with a value that cannot be represented we just
give up and do the empty string when you serialize. Can
we do that? If you as for the CSS Serialization of a
string with NaN or infinity you get an empty string.
zcorpan: Reasonable. I can live with that.
smfr: I know we're getting an empty string...
zcorpan: If you parse it again you get an identity matrix.
Rossen: zcorpan you're okay with TabAtkins resolution I think. Is
there anything else to explore on this?
zcorpan: Consensus on TabAtkins proposal sounds good.
smfr: I don’t think think that returning an empty string is
developer-friendly
<smfr> authors won’t know why they got an empty string
TabAtkins: smfr is disagreeing. Thanks for clarifying.
TabAtkins: I don't know what else you can do, though. The to
string of DOM produces CSS matrix. If you have a matrix
that can't be a valid CSS transform, what are you
supposed to do?
smfr: Throw exception.
zcorpan: What happens in Chrome & Gecko you serialize NaN. When
you parse you get an error.
Rossen: I still don't get what happens when you try and roundtrip.
What's the expected behavior when you parse back.
TabAtkins: Yeah, it fails to parse.
<zcorpan> SyntaxError
Rossen: So if this was an error on input, why not an error on
output?
TabAtkins: I'm okay with throwing as well. Just something that
indicates the to string failed.
Rossen: That's what I'd lean towards as well.
Rossen: Let's try to resolve. Prop: In the case of NaN we would
throw an exception during serialization.
Rossen: Objections?
RESOLVED: In the case of NaN we would throw an exception during
serialization.
<zcorpan> InvalidStateError?
<TabAtkins> Yeah, I think that's probably the best error, zcorpan
Stretching image grid items in both dimensions
----------------------------------------------
Github topic: https://github.com/w3c/csswg-drafts/issues/523
fantasai: In Seattle we had three options. One we wouldn't take
because violates design guidelines. Other two we would
have contain & intrinsic size behavior. You could opt
into either. We picked intrinsic for the default.
There's details in
https://github.com/w3c/csswg-drafts/issues/523#issuecomment-295075752
fantasai: We closed that, but Mats disagrees with the resolution.
All other issues on Grid are closed as of when we
stopped accepting issues.
fantasai: This issue has a commenter disagreement so comes back to
WG. Do we stick or do we change to contain sizing by
default and opt-in for intrinsic via keyword-max-content
or something like that.
Rossen: Opinions?
jensimmons: My opinion is I agree #3 should not be considered. I'd
be okay with leave as-is, but I agree with Mats that
as an author having the default be contain would be
more handy and make more sense. We need both as an
option and the tool to switch definitely. The default
I'd lean contain.
TabAtkins: Reason why we didn't go for contain is it puts sizing
control in this property...
fantasai: TabAtkins we changed.
jensimmons: That was 3 which we agreed not to do.
fantasai: Option was default is contain on all keywords, not just
normal.
jensimmons: Ideally we would have tool to switch between, but the
way the world works if we set default to contain we
would get the switching tools quicker. Not certainly,
but might.
<rachelandrew> I'm still keen on the resolution
Rossen: But forcing a less then optimal default as a forcing tool
isn't doing much good.
jensimmons: Agreed. I still like contain as a default. That's a
secondary non-heavy.
TabAtkins: I'm concerned that when we have contain
sizing....having different defaults based on layout of
parent it makes the design confusing. It's better if we
have consistency.
jensimmons: [missed]
<Rossen> +1 to what Tab said
fantasai: Flexbox resizes to fit the container. It does only do
that with a single line. If you have wrapping it takes
intrinsic.
TabAtkins: It obeys constraint of flexbox and a bit of aspect
ratio magic. The sizing is normal flexbox, not just
images.
jensimmons: You can make the same arguments here.
TabAtkins: I disagree. Part of flex is doing this one thing. We're
not adding a different way of sizing.
jensimmons: I think from author prospective there would be
something similar to having default of flexbox where
they are both text and image contained. If there's an
image just left with intrinsic size it starts to
overflow and that's not typically what authors want.
Authors expect content to stay in grid cells.
fantasai: Things that are smaller then grid size, contain will
cause them to size up.
rachelandrew: I don't like the upscaling. I like the original
resolution because it's the most consistent and
easier to explain. The upscaling will cause problems.
<gregwhitworth> +1 to TabAtkins rachelandrew
fantasai: Another thing to consider is grid is being deployed and
we don't have a definition of contains that WG approved.
Changing will cause implementation stress.
TabAtkins: Adding that, even if we had a contain definition, it's
still transition stress because it's shipped without
this. They're getting things to look well and then this
change will break pages.
fantasai: I would say if it was significantly better thing to do
it might be worth doing, but since we're debating and
there's good for both sides, given the status we're at
it makes sense to go with intrinsic and add the contain
keyword. That would be my position.
TabAtkins: I agree.
<rachelandrew> +1 to fantasai
fantasai: I'm sympathetic, but it's not so clearly better that
it's definitely the right answer.
TabAtkins: I would also treat it differently if it was obvious fix
instead of possibly better.
Rossen: I'm seeing people favor option 1. Let's try for resolution.
Rossen: Unless jensimmons you feel there's something else you want
to add.
jensimmons: I don't want to block it, but I think we need to
define contain.
fantasai: We have a definition, we need comments. There is a
definition in sizing 4. Mostly waiting for dbaron and
Mats there.
jensimmons: We should keep going forward on getting that done
because it's desperately needed.
dbaron: Does option 1 match what impl ship today?
Rossen: I believe so.
TabAtkins: It does.
jensimmons: I'm curious about that. I'm not sure what Mats impl
and he did Gecko.
TabAtkins: I'd hope he's not impl something different. Even if he
is, the other browsers aren't.
dbaron: I would disagree with TabAtkins' hope. But I don't know
what he did.
Rossen: Let's go back to this. Since Mats isn't here I'd like to
call for consensus on #1. We'll continue working on
contain.
<astearns> is this the definition?
https://drafts.csswg.org/css-sizing/#contain-fit-sizing
Rossen: Objections to sticking with Seattle resolution: making the
default intrinsic?
RESOLVED: Stick with Seattle resolution: making the default
intrinsic.
<jensimmons> we don’t have interop on https://jsfiddle.net/1fd948nz/1/
at the moment, fyi
<fantasai> https://software.hixie.ch/utilities/js/live-dom-viewer/saved/5143
fantasai: We've got different behavior on different browsers
Rename `auto` to `legacy` for `justify-items`
---------------------------------------------
Github topic: https://github.com/w3c/csswg-drafts/issues/1318
fantasai: Alignment spec has a bunch of keyword magic with
justify-items. It sets default value of justify self for
any children. We tried to figure out how to incorporate
center tag and did it with a special set of keywords
called legacy with an initial value of auto. All auto
does is this magic, but we could just use legacy keyword
by itself.
fantasai: Proposal is rename auto to legacy so all it does is if
you have legacy keyword on parent it pulls the parent
alignment, else does normal thing.
fantasai: Alternate is drop this thing.
fantasai: We haven't gotten any significant comments. Apparently
style stuff is implemented chrome. Not sure how people
are impl center and align attributes in HTML.
fantasai: If impl don't want to implement center and align
attributes through this we should drop. If we want to
keep it we recommend the rename.
fantasai: Did that make sense or do we need more explanation?
Rossen: Your explanation was great. In our impl we handle center a
little magic. Rename would be okay. Trying to kill it
would be better.
Rossen: I'm in favor of mostly everything you proposed.
fantasai: Reason to keep it would be if we want to standardize.
Alternative would be add yet another property to control
magic.
fantasai: We can't unimplement center tag.
TabAtkins: Benefit of another alignment property is we can make it
actually inherit. It might be better structurally.
fantasai: But then you have a weird thing where you have to figure
out, I inherited this, alignment is this, what wins?
fantasai: We can't resolve with cascade.
fantasai: Incorporating it has the benefit that the cascade is
understandable.
<dbaron> For what it's worth, I'd probably have an opinion on this
if I had ten minutes to think about it...
TabAtkins: There's definitely problems either way, I agree.
fantasai: I'm happy to defer
Rossen: Let's resolve on rename
Rossen: Any objections on renaming auto to legacy?
RESOLVED: Rename auto to legacy.
Alignment publication
---------------------
Rossen: Was that the only thing keeping us from CR on alignment?
fantasai: Yes...I think we should add legacy to at-risk list. All
the issues are closed. I would like to initiate
transition.
Rossen: That would be great.
fantasai: While we process that we can look at dropping. If it's
at-risk we can drop later.
dbaron: I'll try and start asking this for all CRs: Is there
someone other then the editor that has read the draft and
thinks it's ready?
fantasai: We've had a lot of comments from Igalia & Matt. There
have been detailed reviews of the draft. I think it has
been impl...this was the reference spec of grid. I think
it's gotten decent amount of review.
dbaron: There's bunches not related to grid and I worry those
aren't ready.
fantasai: I think they're straight forward. We kept asking for
review and no one has so TabAtkins and I have done two
line by line reviews of the spec.
fantasai: If someone wants to review the spec I'm happy to delay 2
weeks, but if it'll be more no response and no review
it's not useful.
fantasai: I've been asking for review for years.
dbaron: I submitted comments a year or two ago.
dbaron: I would like the bar for CR to involve someone other then
the editors say they think it's ready.
fantasai: I totally agree with that.
<astearns> we're meant to show wide review before CR
<rachelandrew> Does this review need to be from an Implementor?
I've spent a lot of time reading it, I'd be happy
to do a more formal review.
<astearns> rachelandrew: does not have to be from an implementor -
your formal review would be great
dbaron: I can probably look, but not this week.
Rossen: I agree, dbaron. We can action the WG to review Alignment
spec in the following two weeks. I also sympathize with
fantasai saying she has asked for review. Let's use the
resolution forcing function. Would you agree two weeks is
enough before we call for resolution? Or three?
dbaron: 2 is fine.
Rossen: Proposal: Move CSS Alignment to CR with the added legacy
value defined as at-risk. The action of starting the CR
process will start in 2 weeks unless we heard elsewise.
Florian: Have we asked for horizontal review? We could bundle the
two.
Rossen: Good idea. Let's see. Who do we need for horizontal
review? a11y folks.
ChrisL: i18n, privacy, security
fantasai: I think for privacy & security we should send them a
note saying we don't think there's anything that would
effect you, but feel free to read the spec.
Rossen: That's good.
Florian: Is 2 weeks short for horizontal?
ChrisL: It is. i18n wants 4 weeks.
ChrisL: I think for specs we're prepping for CR we should in the
future schedule earlier.
fantasai: I don't think we'll get feedback on horizontal review.
Maybe general this could be better written.
fantasai: i18n wanted flow relative directions which is what we
did. We have self-start vs start so there's all kinds
of writing mode control. a11y issues are ones that
effect everyone, e.g. if stuff overflows it could be bad.
Rossen: I think we should stick to 2 weeks. If someone starts
screaming we can be flexible.
RESOLVED: Move CSS Alignment to CR with the added legacy value
defined as at-risk. The action of starting the CR
process will start in 2 weeks (May 27) unless we hear
elsewise.
fantasai: Rossen can we have WD resolution?
Rossen: Oh, yes.
<fantasai> TabAtkins, would you mind adding the at-risk thing and
pushing to /TR?
Question re white space processing rules for U+000D
---------------------------------------------------
Github topic: https://github.com/w3c/csswg-drafts/issues/855
Rossen: Is anyone prepared to talk on this?
TabAtkins: I can do it based on thread.
TabAtkins: According to the text spec a lone U+000D is the same as
a proper line break.
TabAtkins: Impl don't do that, they drop it from white space
processing.
TabAtkins: There's a test case in the issue. It appears it's
consistent. We should probably change spec to match
implementation.
Florian: To clarify, is that the one macs used to be used before
OS10?
TabAtkins: Someone used it at some point.
fantasai: Yes.
Florian: So it's not likely something on the rise, it's the other
way around.
myles: Matching implementation is good idea.
dbaron: This is about carriage returns getting to the CSS level.
Classic mac could have processed before.
TabAtkins: I don't think HTML parser does magic.
gsnedders: It replaces them with line feed (000A).
<zcorpan> or textContent = "foo\rbar"
<zcorpan> html parser normalizes
TabAtkins: Nevermind. He's just using entities in test example.
Florian: Then go for it.
Florian: Make the suggested change to match impl.
Rossen: Okay. Any objections to accepting the change?
RESOLVED: Accept the change in https://github.com/w3c/csswg-drafts/issues/855
Reconsider name of frames() timing function
-------------------------------------------
Github topic: https://github.com/w3c/csswg-drafts/issues/1301
Rossen: Long issue, added by dbaron. Has some ML discussion.
TabAtkins: I feel like github is having fruitful discussion
How does 'inherit' keyword behave in a child of ::first-line?
-------------------------------------------------------------
Github issue: https://github.com/w3c/csswg-drafts/issues/1097
fremy: There's a proposal that makes sense. On the properties that
apply on ::first-line and inherit should inherit and not
custom properties.
fremy: I can explain the issue if someone needs.
Rossen: Yes, please.
fremy: The issue is a span is inside a div with ::first-line. If
you set on the span color: inherit will do so from
::first-line. In webkit if you do this wrong it also
appends. It seems like it's causing some problems.
fremy: It furthers what happens with custom properties where if
you do the inherit from the ::first-line it could become a
block and then it's not part of first line. The prop is if
custom properties & background do not inherit by the
children of the ::first-line.
fremy: If you spec a background inherits on the ::first-line it'll
inherit from the div.
<dbaron> Is the proposal written somewhere?
Florian: At first it sounds reasonable, but I expect horrible,
subtle things hiding somewhere.
fremy: I think proposal makes sense.
Florian: I think so too.
fantasai: I agree with Florian. I don't have time to look right
now. I would prefer a week to look.
Rossen: We can push the resolution out a week. Let's look at this
one.
Rossen: Florian are you okay?
Florian: Yeah.
Rossen: fremy?
fremy: Sure.
dbaron: If we have a week, can there be a written version of the
proposal? The issue is very long and I don't know what
proposal we're looking at.
Rossen: fremy let's have you summarize the proposal on the github
issue.
Allow percentages for `column-gap`
----------------------------------
Github topic: https://github.com/w3c/csswg-drafts/issues/1321
Florian: We resolved 4 years ago to allow column-gap to take
percentages. Given that it's now, is that L1 or L2?
Rossen: Didn't we take the opposite for grid-gap?
Florian: I don't remember.
jensimmons: We resolved grid-gap to take percentages.
Rossen: If we're in alignment there's no controversy. They should
be aligned.
Florian: Behavior is not unexpected. Question is where do we spec
it.
Florian: We'll have to redo L1 CR, but we could do it there. Not
sure there's impl.
Rossen: I would say add as at-risk and then pass it to L2. I'm
fine with that. Just more process & editorial work. Other
way is push to L2 now and if impl pick it up we can bring
it back.
fantasai: It's trivial to edit and to impl compared to making so
other stuff in columns work. I think L1 and at-risk is
fine.
Rossen: That's fine. Leave this in multi-col L1 and mark it as
at-risk.
Florian: Put it in L1.
RESOLVED: Add percentages for `column-gap` to L1 and mark as
at-risk.
Rossen: That's the hour. Thanks everyone.
Received on Wednesday, 10 May 2017 20:33:01 UTC