- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 26 Jul 2017 20:49:04 -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.
=========================================
Spec Rec next steps
-------------------
- fantasai pulled a list of open Align issues to ensure they're
discussed.
- Bert reported that he's done enough work on CSS 2 so that a
discussion on how to manage it going forward can be added to
the F2F agenda.
CSS Alignment
-------------
- RESOLVED: Option #1 from the issue
(https://github.com/w3c/csswg-drafts/issues/1612)
"Reduce the size of the alignment container by the
size of the float's margin box, then center the block
in the remaining space (this is the behavior of HTML's
align attribute)"
- Issue #1611 (https://github.com/w3c/csswg-drafts/issues/1611)
"Should last-baseline's fallback alignment be safe or unsafe?"
is deferred to the F2F.
- RESOLVED: Such alignments that overflow will not participate in
last baseline alignment (Issue #1556:
https://github.com/w3c/csswg-drafts/issues/1556)
Intrinsic Size of Images with Intrinsic Aspect Ratio and No Size
----------------------------------------------------------------
- fantasai requested review on the text changes added to the spec
to address this issue (https://github.com/w3c/csswg-drafts/issues/1609)
- She also mentioned that Issue #951
(https://github.com/w3c/csswg-drafts/issues/951)
is on the F2F agenda for discussion so people can think about
it in advance.
- AmeliaBR noted that many of these cases have been addressed
in SVG so referring to that spec should be useful in this
conversation.
CSSFontFaceRule does not seem Web compatible
--------------------------------------------
- This topic will be added to the F2F agenda so all interested
parties are available.
Exclude 'none' from <counter-style-name>
----------------------------------------
- RESOLVED: Accept the edits proposed in
https://github.com/w3c/csswg-drafts/issues/1295
====== FULL MINUTES BELOW ======
Present:
Rachel Andrew
Rossen Atanassov
Amelia Bellamy-Royds
Bert Bos
Tantek Çelik
Dave Cramer
Alex Critchfield
Elika Etemad
Tony Graham
Dael Jackson
Tomoya Kimura
Thierry Michel
Anton Prowse
Jen Simmons
Regrets:
Tab Atkins
David Baron
Daniel Glazman
Chris Lilley
Peter Linss
Melanie Richards
Alan Stearns
Lea Verou
Greg Whitworth
Scribe: dael
Spec Rec next steps
===================
Rossen: Let's get going.
Rossen: As usual, I wanted to ask if there is anyone who wants to
bring extra topics besides the one tantek added
(https://github.com/w3c/csswg-drafts/issues/1002)
Rossen: tantek that one topic you added, it's agenda for F2F which
is why it didn't show. I was only querying for call.
fantasai: Gerard wanted me to ask about impl report for writing
modes and FF and Edge
Rossen: I don't being on Edge we have the numbers. Safari answered
over email and it looks like they're working on results as
well.
Rossen: In the ideal world we'll have a report for F2F next week.
Rossen: Anything else to add fantasai?
fantasai: I don't think so.
Rossen: Going through the current inventory it seems we have
publication requests for counters 3 scroll snap, font 4
was published, box alignment is now past dbaron comments.
fantasai: We published the WD for alignment last week. There's
still open items.
Rossen: What do we have outstanding for this? Are these what we
have today?
fantasai: Some yes, I think a few are marked for F2F. I can
collect a list of open items.
Rossen: Okay.
<dbaron> (from TAG meeting) we're still going back-and-forth on
some of the css-align issues
<Rossen> dbaron, thanks for the update
<fantasai> Open issues on css-align:
https://github.com/w3c/csswg-drafts/issues?utf8=%E2%9C%93&q=is%3Aissue%20label%3Acss-align-3%20label%3A%22Agenda%2B%20F2F%22
and https://github.com/w3c/csswg-drafts/issues?utf8=%E2%9C%93&q=is%3Aissue%20label%3Acss-align-3%20label%3A%22Agenda%2B%22
<fantasai> There might be a few more, those are the ones we triaged
Rossen: Did we close on UI tests for UI 4?
fantasai: I think florian fixed a bunch, I have to re-review.
Rossen: Is bert on?
Bert: I'm here.
Rossen: How are we doing with converging of CSS 2 folders, modules
etc.
Bert: I merged css-2 and css-2-testing into 1. I removed the empty
repo. There is not only 2 of them. I've been busy trying to
make all the links work and cleaning up. Some of that is
checked in. Then I started removing text that's in other
modules.
Bert: The action item is done, but I'm still working on adding
other things like the references to new modules.
Rossen: Should we be able to put this on F2F agenda for next steps?
Bert: Yes, I think we should do that. I won't have all the things
I want done, but it'll be enough to talk about.
Rossen: Thank you.
CSS Alignment
=============
Rossen: We have a number of Align topics.
Which behavior for block's "justify-self: center"?
--------------------------------------------------
Github: https://github.com/w3c/csswg-drafts/issues/1612
Rossen: Summary is you have a float and you are positioning a BFC
next to it and this block has a justify-self: center which
means without a float it'll be centered, but since the
float is taking space away the justification need to
either a) take the float into account or b) don't
Rossen: In the case that the bfc has sufficient space to
distribute around it the question is which proposal makes
more sense? Place the float and then center or center
ignoring the float and shift the float if necessary.
Rossen: As an implementor I prefer option 1. I see more people on
the issue for option 1. I'd like to hear alternatives or
opposing opinions if there are any from the WG.
[silence]
Rossen: If no one has any we can resolve on option #1: the block
would be positioned next to the float and centered in that
remaining space.
Rossen: [Reads from the github] "Reduce the size of the alignment
container by the size of the float's margin box, then
center the block in the remaining space (this is the
behavior of HTML's align attribute)"
Rossen: That's the proposal.
Rossen: If there are no objections we can resolve.
<fantasai> testcase
http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=5281
Rossen: fantasai when you discussed with TabAtkins the current
proposed is for BFC with fixed width or width which is
auto?
fantasai: Either one. As long as width is smaller than remaining
space.
Rossen: I was asking because if the width is auto and supposed to
extend out to fill available space css2.1 behavior is
already what you described here.
Rossen: The justification even though there would be centering you
wouldn't be able to tell. So I guess this is mostly
observable when BFC has fixed size smaller than available
space and has justification.
fantasai: Looks like centering with margins for auto has same
behavior as centering with center tag.
Rossen: For BFC next to floats?
fantasai: Yeah. Which I wasn't expecting. I was expecting [missed]
Rossen: This is the test case you pasted in IRC?
fantasai: Yeah.
Rossen: This is just another confirmation of existing behavior
consistent with what you're trying to define.
Rossen: I'm going to call for objections on the current proposed
behavior. Current proposed is "Reduce the size of the
alignment container by the size of the float's margin box,
then center the block in the remaining space (this is the
behavior of HTML's align attribute)"
Rossen: Is there anyone objecting this this?
RESOLVED: Option #1 from the issue "Reduce the size of the
alignment container by the size of the float's margin
box, then center the block in the remaining space (this
is the behavior of HTML's align attribute)"
Should last-baseline's fallback alignment be safe or unsafe?
------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/1611
Rossen: We discussed last week, but didn't resolve as far as I
remember.
Rossen: We wanted to gather any additional thoughts on Github.
There were no updates. Do we feel like we have enough to
resolve or do we leave to F2F?
Rossen: Last week we couldn't get to a solution going back and
forth a few times.
Rossen: We didn't resolve due to time constraints. But we also had
this back and forth about if this makes the most sense and
the most consistent with other alignments and their
default behavior in overconstraint scenarios.
fantasai: Seems we didn't have consensus because good arguments in
both directions.
fantasai: Probably what we need is actual use case scenarios to
come up with a reason for one being better.
Rossen: As I mentioned, I can be persuaded either way. I favor
consistency and in this case there was some inconsistency
with the way fallback occurs for safe and unsafe because
discrepancy between baseline-align and align end.
fantasai: There's 2 kinds of align. safe and unsafe. We could be
consistent with either one.
Rossen: Right.
fantasai: I'm okay deferring to F2F.
fantasai: I'm hoping at F2F people will h ave something concrete
for one or the other.
Rossen: I don't mind
Compatible alignments aren't always compatible
----------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/1556
Rossen: Can you summarize fantasai ?
fantasai: We opened this and resolved on some. The cases where you
have a stretch item and a last baseline aligned. If you
have content alignment you can align stretch items. As
long as the stretching takes effect. If the stretching
is constrained we resolved that since there's an
explicit need to align to top or bottom that's fine.
We're covered.
fantasai: If you have 2 end aligned things that normally are last
baseline content alignment, but if one is overflowing
and safe alignment it would end up start aligned. So
what do we do for that thing?
fantasai: Does everything shift down and do unsafe, do we bail
where if you overflow we don't do baseline? We need to
figure out and I don't have a clear proposal.
fantasai: You have 2 items, self align to the end. They have
content baseline alignment. One of them happens to be
bigger than the box, but has safe alignment so it'll
overflow the bottom. What do we do?
fremy: I don't know if we need to baseline align. It seems like an
error. I'd be fine saying we don't baseline align and just
give up.
Rossen: You favor where baseline align is ignored?
fremy: Yes.
Rossen: fantasai do you have a strong opinion?
fantasai: Options are we perform last baseline alignment and treat
all as overflow. Alternative is to say the overflow
thing can't be last baseline.
Rossen: And I think that second is what fremy was pointing out.
Rossen: From impl PoV I would also favor the second. It would be
good to hear from more people.
Rossen: If there are no other opinions we can try and resolve or
postpone to F2F with a whiteboard and more people.
Rossen: Preference?
fantasai: I'm okay resolving to bail on baseline alignment and if
this happens that item can't participate.
Rossen: Fine to me. Prop: Such alignments that overflow will not
participate in last baseline alignment. Obj?
RESOLVED: Such alignments that overflow will not participate in
last baseline alignment
Intrinsic Size of Images with Intrinsic Aspect Ratio and No Size
================================================================
github: https://github.com/w3c/csswg-drafts/issues/1609
fantasai: We won't resolve here, but I wanted attention. I checked
in some rules for this that are in the sizing spec and
we'd appreciate review. There's another case in issue
951. There's no hints in 2.1 for this case and there's
discussion there on how to handle it.
fantasai: So there's two things with these. We'd like review of
the new text and we should resolve 951, but that's on
the F2F agenda.
AmeliaBR: I haven't looked into the various issues with as much
detail as I'd like, but it looks like the specific issue
of what to do when width is
undefined...that's....basically there are a lot of
things with SVG not defined in any spec but we're
getting a de facto standard from browsers impl so you'd
want some tests to see what's already done.
AmeliaBR: I or someone else could do that before the meeting in a
couple weeks. Sorry I didn't prepare before.
Rossen: Good point. In terms of SVG and ways we compute intrinsic
size and all the variations...about a year ago we were
revving our version of SVG sizing and at that time we did
document what everyone is doing. I believe we have introp
in most of the cases. The result of the work I believe was
spec or tried to spec in the integration spec.
Rossen: If it didn't make it it should be there. Regardless it's a
valid point and we should solidify and explain how that
works. Definitely a big +1 from me.
<AmeliaBR> https://www.w3.org/TR/SVG2/coords.html#SizingSVGInCSS
AmeliaBR: The text is in SVG 2^
AmeliaBR: That's written in very SVG specific. For CSS you'd want
to generalize, but it's written with CSS terminology. It
can probably be reused. It doesn't cover min-width and
max-width which becomes and issue with flexbox and grid
layouts.
fantasai: This is defining what intrinsic dimensions the SVG has.
The SVG can return any combo of these as far as I'm
aware.
fantasai: I think the one combo they don't have is width and
height but no aspect ratio because you infer that.
Rossen: Width and height with both % aren't.
fantasai: SVG says we don't have an aspect ratio in %
Rossen: Width and height are computable.
fantasai: Spec says if width or height are auto or % CSS is told
there is no width or height. CSS algorithm takes that to
calc a box. CSS then tells the SVG here's your size.
Then SVG uses information to draw inside the rectangle.
This spec is about how to size that rectangle.
fantasai: When you're auto sized if the SVG has a width and height
that's easy. If it has one or the other...it's missing
some info...we need answers. If it has aspect ratio but
not width or height browsers tend to use size of
containing block to calc width and use aspect ratio for
height.
fantasai: That gives you a fulls sized SVG image taking up width
of containing block.
fantasai: So that's great and I think standardizing on that where
we can is great. There's one case with cyclic
dependency. You can't use containing block size if that
size depends on you.
fantasai: We need an answer for that size. I think there isn't
consistency in this respect. I think using 300px for the
width is possible but not ideal. 951 is to find a better
solution. Current proposal is same as what we do for
orthogonal flows. We have a formula to find a size.
fantasai: The rest of the cases are a little constrained. If you
don't have any intrinsic size or aspect ratio, that's
the iframe case and we use 330 x 150.
fantasai: We took the 2.1 rules and tried to write them into
Sizing. That one underdefined case is on the F2F agenda.
Rossen: That's 951?
fantasai: 951 is the open. Other we believe is consistent with
2.1, but it all requires a bunch of testing and I
haven't done that.
fantasai: We're looking for review of CSS 3 Sizing to make sure
it's correct and thoughts on 951.
Rossen: I'm going to go back to your opening statement that this
is more of an awareness call. I would side on taking this
to the F2F and solving on a white board.
Rossen: Resolving now won't get us too far.
fantasai: If AmeliaBR would review that section we'd appreciate it.
AmeliaBR: I'll try.
Rossen: Will you be at F2F?
AmeliaBR: No.
[sadness]
Rossen: Let us know if you can call in and we'll try and
accommodate.
CSSFontFaceRule does not seem Web compatible
============================================
github: https://github.com/w3c/csswg-drafts/issues/825
Rossen: This was added by ChrisL.
<myles> https://www.w3.org/TR/2011/WD-cssom-20110712/#cssfontfacerule
myles: This is about what happens in CSSOM if you pull out a rule
that represents a FontFaceRule. There's an old spec that
says this only has one rule that is a style declaration.
<myles> https://drafts.csswg.org/css-fonts-4/#cssfontfacerule0
myles: This was updated to ^ which gets rid of the one style
attribute and replaces with a bunch of strings.
myles: Before you would get your rule in JS and say
.style.getPropertyValue and in the new rule you say .family
to get the string.
myles: Every browser implements the old approach. There have been
proposals of what to do. 1) revert, 2) have both 3) make a
.style but have it be a new custom object with only some
stuff and not all the generality of the style declaration.
myles: This came up because I started making edits and I don't
know what to do.
myles: My opinion is since browsers are standardized that's what
should go in spec. I imagine there are other thoughts.
<tantek> +1
Rossen: Most people engaged in this aren't on the call today.
ChrisL, dbaron, and TabAtkins are all not on the call.
myles: We can push. I'll give the speech again next week.
Rossen: I'm sympathetic with your proposed opinion to standardize
on one behavior. But I'd also like to hear from others
that were in this conversation.
myles: That's fine.
<TabAtkins> The specced thing is definitely *better*, no question.
And it's what I designed the FontFace object after,
not knowing the spec didn't match reality. But we need
someone to actually make the change and show it's
web-compatible.
Exclude 'none' from <counter-style-name>
========================================
github: https://github.com/w3c/csswg-drafts/issues/1295
Rossen: Who is on the call from this convo? SimonSapin?
fantasai: This was filed a while ago about dealing with none
value. This was with SimonSapin & Xidorn about excluding
none from <counter-style-name> Edits are checked in,
it's on the agenda to check they're okay because it's a
change to CR spec.
fantasai: Otherwise we should resolve to accept edits and
republish counter styles.
<fantasai> well, I guess there are two more issues on counter
styles
<fantasai> to resolve before republishing
<fantasai> DoC:
https://drafts.csswg.org/css-counter-styles-3/issues-cr-20150611
<AmeliaBR> Weren't there other changes about disallowed names?
Decimal and circle, or something like that? Have they
already been approved or deferred?
<Rossen> https://github.com/servo/servo/commit/04aaef8b3d0bc12ad5d2d5c9ecf003c016928a30
Rossen: I'm trying to find the edits. Is this the edit ^?
<fantasai> Looks like the changes are here:
https://github.com/w3c/csswg-drafts/pull/1326/commits/07ca44199bda55b7d24a3d1ccc8c8a342a324c99
Rossen: For this issue, #12 in DoC....
Rossen: Excluding none from <counter-styles-name> will this reset
the CR? I missed the consequence of accepting the edit
fantasai: It's a substantive change to a CR spec so we need WG
approval for the change.
Rossen: Did anyone get to review? Does anyone have an opinion?
* tantek tries to review quickly
<tantek> interesting
<tantek> in a good way
<fremy> (I just gave this a read, I think this is reasonable
change; sounds ok)
Rossen: So we can resolve on the committed change and reset the CR
of CSS counters.
<fantasai> https://drafts.csswg.org/css-counter-styles/issues-cr-20150611#issue-7
fantasai: There's 2 more issues on counter styles before we
republish. 2 more substantive. 1 is included in the
change set which is computing undeclared to decimals.
Last one is involving i18n and a11y so we'll have to
liaise with those groups.
Rossen: tantek you seems to be reviewing. Interesting in a good
way from you. fremy seems to support.
Rossen: Should we resolve or is anyone else looking?
* tantek reviews conversation
<tantek> seems sensible, improves consistency
<tantek> per https://github.com/w3c/csswg-drafts/pull/1326
<tantek> and I've never looked at this issue before AFAIK. so
consider it an outside opinion
<Rossen> https://wiki.csswg.org/planning/paris-2017#proposed-agenda-topics
Rossen: While everyone reviews, I want to remind people to add
topics to the F2F agenda ^
Rossen: Please add agenda items.
Rossen: tantek supports it. Thanks for reviewing.
Rossen: Other opinions before I CFC?
Rossen: Objections to accepting the edits for
https://github.com/w3c/csswg-drafts/issues/1295 ?
RESOLVED: Accept the edits proposed in
https://github.com/w3c/csswg-drafts/issues/1295
Rossen: That's the top of the agenda.
Rossen: Any other quick topics? Or should we reclaim 5 min?
Rossen: I wish you all safe travels. For those of you already
there we'll see you next week.
Received on Thursday, 27 July 2017 00:49:59 UTC