- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 19 Jul 2017 21:03:42 -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
-------------------
- RESOLVED: Request updated PR for writing modes
Publishing an updated WD of css-align and css-display
-----------------------------------------------------
- RESOLVED: Publish an updated WD of css-align
- RESOLVED: Drop inline-list-item
- RESOLVED: Publish new WD of css-display
Scroll Snap
-----------
- RESOLVED: Accept this edit and close issue 1552 as resolved
- RESOLVED: Make the change to page up and down to put in intended
direction and endpoint class
- RESOLVED: Take home and end out of intended direction class
- RESOLVED: Updated CR for scroll snap
Computed value of float with absolute positioning when there is no
box?
------------------------------------------------------------------
- RESOLVED: Make the changes listed in css2.1 and position
(Issues:
https://github.com/w3c/csswg-drafts/issues/1436#issuecomment-313215820
)
object-fit: scale-down should become a flag
-------------------------------------------
- RESOLVED: Accept the change in
https://github.com/w3c/csswg-drafts/issues/1578
Should last-baseline's fallback alignment be safe or unsafe?
------------------------------------------------------------
- TabAtkins introduced the issue and indicated that they were
leaning toward safe since it allows all the content to be
reached.
- However, it was discovered on the call that the usual fallback
is unsafe so using safe would cause unexpected behavior.
- There was value in both arguments, so discussion will continue
on github in hopes of reaching a resolution next week.
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2017Jul/0010.html
Present:
Rachel Andrew
Rossen Atanassov
Tab Atkins
David Baron
Bert Bos
Tantek Çelik
Dave Cramer
Alex Critchfield
Benjamin De Cock
Elika Etemad
Tony Graham
Dael Jackson
Brad Kemper
Ian Kilpatrick
Chris Lilley
Peter Linss
Myles Maxfield
Thierry Michel
Anton Prowse
Matt Rakow
Melanie Richards
Geoffrey Sneddon
Alan Stearns
Lea Verou
Regrets:
Robert Flack
Daniel Glazman
Vlad Levantovsky
Florian Rivoal
Jen Simmons
Greg Whitworth
Scribe: dael
astearns: We have a meeting in less than 2 weeks.
<tantek> wiki page URL?
<Bert> https://wiki.csswg.org/planning/paris-2017
<tantek> thanks Bert :)
astearns: If you have not yet added your details to the wiki
please do. And add items to the agenda so we can get a
possible schedule in mind.
astearns: Next, anything people want to add to the agenda?
Spec Rec next steps
===================
astearns: Anyone have an update to share?
<ChrisL> I just sent email seconds ago
astearns: ChrisL sent an email seconds ago. There are updates for
Fonts. Thanks.
astearns: Is fantasai on yet?
fantasai: I didn't do anything other than dealing with writing
modes where I sent an update. There was a normative
change, I pushed the change, complied DoC, sent to
ChrisL.
astearns: So things are with ChrisL?
fantasai: ChrisL needs to figure out what's next to get published.
I don't know what to do.
<fantasai> https://lists.w3.org/Archives/Public/www-style/2017Jul/0012.html
ChrisL: We were waiting on if we want to go to CR or PR. Seemed
from the changes they were non-substantive, but fantasai
thought it should be CR. I asked why.
fantasai: There's a message linked in IRC. There's issue 1391.
It's a substantive change, but quite minor. But I don't
know what the state of the process is.
<astearns> https://github.com/w3c/csswg-drafts/issues/1391
<tantek> do test cases reflect the normative changes?
<tantek> is it a breaking change?
fantasai: I'd recommend a chat with Ralph to explain the changes.
I think it's silly to CR first.
ChrisL: That's listed in changes list?
fantasai: Yes, and DoC.
ChrisL: Great. I'll take that to Ralph.
ChrisL: Thank you.
astearns: Anything else on the set of specs we're trying to get
updated to CR?
fantasai: There's the list on the agenda for updating.
astearns: True.
Rossen: I believe there are tests stuck somewhere for review,
maybe Flexbox or Grid. Might be good to have eyeballs on
those.
astearns: Are there people assigned?
Rossen: I don't believe so.
Rossen: Anyone can review tests.
astearns: Let's look this week at what tests are waiting review
and you and I can assign someone to review to get things
moving.
Rossen: Sounds good.
* tantek notes that https://github.com/w3c/csswg-drafts/issues/1391
has a test case and has changes to reflect implementation
interop / consensus.
tantek: Quick note on writing modes.
tantek: I reviewed the issue and in my opinion I think we should
go directly to PR. There is a test case and it's a change
to reflect interoperable implementations so it's not
breaking.
* ChrisL wants what Tantek said minuted clearly
<Rossen> +1 to tantek
<ChrisL> thanks, t
tantek: I just wanted to add weight to the PR request.
<fantasai> thanks :)
Rossen: Should we get a resolution ChrisL? If it's going to be
worth the argument let's just call for consensus and move
on.
<ChrisL> sure
astearns: proposal: request updated PR for writing modes instead
of going back to CR b/c this change doesn't warrant
going back to CR.
<ChrisL> +1
<tantek> because this particular change reflects reality (impl
interop)
<tantek> +1
astearns: Obj?
RESOLVED: Request updated PR for writing modes.
<Rossen> yay!
Publishing an updated WD of css-align and css-display
=====================================================
CSS Align
---------
astearns: Align- it's an updated WD.
fantasai: Yep. We wanted dbaron approval on that since a lot of
the issues were filed by him. If he's okay publishing
now or wants more time to look.
dbaron: I think there's more work to do, but I wouldn't object to
a new WD. I went through the commenter response required,
well, all but 3. There were 4 I marked as not satisfied.
fantasai: Great. publish an update and keep working
astearns: Objections to updated WD of css align?
<ChrisL> that is an auto-publish, right?
<fantasai> ChrisL, yes
RESOLVED: Publish an updated WD of css-align
CSS Display
-----------
astearns: Second is also updated WD of css-display. Looked like
fewer issues.
fantasai: Fewer, but quite a few. We could do 1495 quickly before
publish. We should do an update and then keep working.
<fantasai> https://github.com/w3c/csswg-drafts/issues/1495
fantasai: Suggestion was inline-list-item is a little different
than some of the others and do we really need this one.
It might be worth dropping that unless someone has impl
and wants to keep it.
astearns: Anyone know if inline-list-item has been impl?
Rossen: I don't believe we are.
<fantasai> No hits in Mozilla's codebase
astearns: Objections to dropping inline-list-item?
RESOLVED: Drop inline-list-item
astearns: Objections to new WD of css-display?
RESOLVED: Publish new WD of css-display
Scroll Snap
===========
Clarify passing by requirement of scroll-snap-stop for different
category of scrolling
----------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/1552
fantasai: We made some changes to clarify scroll snap stop in
respect to different types of scrolling. New definition:
<fantasai> When scrolling with an intended direction, the scroll
container can “pass over” several possible snap
positions (that would be valid to snap to, if the
scrolling operation used the same direction but a
lesser distance) before reaching the natural endpoint
of the scroll operation and selecting its final scroll
position. The scroll-snap-stop property allows such a
possible snap position to “trap” the scrolling
operation, forcing the scroll contain[CUT]
<fantasai> Values are defined as follows [...]
<fantasai> This property has no effect on scrolling operations
with only an intended end position, as they do not
conceptually “pass over” any snap positions.
fantasai: What we decided was it has no effect on a scroll that
has an end point but no direction. That includes scrolls
where you jump to an element or if you are driving or
panning and let go at that point as you're dragging.
fantasai: Things with a direction like down arrow and page down
and momentum scroll are tracked by scroll-snap stop.
astearns: And I see one comment liking the wording.
fantasai: MaRakow looked it over and sent some comments. We
replied. That was offline.
MaRakow: It seems generally fine. Main thing interesting is the
previous language talked about container, it seemed,
though it was in the section about elements. I'm
generally fine with the definition unless [missed]
astearns: Anyone else have an opinion?
astearns: Objections to closing this issue as resolved?
RESOLVED: Accept this edit and close issue 1552 as resolved
Classify pageup/pagedown keys
-----------------------------
github: https://github.com/w3c/csswg-drafts/issues/1605
fantasai: We realized that page up/page down keys didn't have a
classification so we proposed adding them to the
intended item since it's basically understood to be a
screen scroll.
TabAtkins: We added home and end too.
MaRakow: I think page up and down make sense. Home and end are
more challenging since with the previous resolution end
might not get you to the end and most people expect home
or end regardless of scroll-snap-stop.
* tantek agrees
<tantek> home/end set expectation of actual top/bottom
fantasai: That's a really good point.
fantasai: One thing I would consider there is I think we put home
& end under another classification originally...let me
look that up. I could see an argument for hitting
scroll-snap-stop because we have these internet things
where you want to get to the end of an article and it
just loads another. I'm okay moving them into the
intended end.
TabAtkins: I'm okay either way.
<Rossen> +1 to keeping home/end sane
astearns: Draft has home and end in different group?
fantasai: Page up & down
TabAtkins: Direction + end point
fantasai: We can move to intended position.
astearns: Is there any objections to making the change to page up
and down to put in intended direction and endpoint class?
RESOLVED: Make the change to page up and down to put in intended
direction and endpoint class
astearns: And we'll take home and end out of intended direction
class?
astearns: Objections?
RESOLVED: Take home and end out of intended direction class
Publication
-----------
astearns: Anything else before we update CR for scroll snap
ChrisL: I sent a question about impl status. According to caniuse
it's fully implemented in safari and partially by FF and
Edge
TabAtkins: It's all an incompat subset of the old spec.
<leaverou> btw this is the caniuse URL
http://caniuse.com/#feat=css-snappoints
<leaverou> it does mention support is partial
ChrisL: Does that mean the browsers have tests is where I was
going. Transition request needs to say impl status.
TabAtkins: We're nearly finished with our impl. I'm sure we have
tests. I can poke Majid to see about grabbing them.
ChrisL: That would be great. Anyone else have tests?
Rossen: For scroll snapping I think the current version isn't
compat with the spec. We have tests but they're for the
old version so not very helpful. I would encourage anyone
with current test to contribute.
Myles: We have tests but they're old.
<ChrisL> ok I will send a transition request
astearns: This needs to get on our list of spec rec next steps to
get a test suite.
astearns: Anything more ChrisL?
ChrisL: No unless there's been additional wide review to mention.
Apart from that I'm good to go.
astearns: Has anyone outside the WG looked?
TabAtkins: Aside from some impl I don't believe so.
ChrisL: I meant since Oct last year.
astearns: I don't believe we've sent it outside the group.
ChrisL: Okay. We did it when we first went to CR. It's in case
there was anything else.
astearns: Objections to updated CR for scroll snap?
<ChrisL> +1
RESOLVED: updated CR for scroll snap
Computed value of float with absolute positioning when there is no
box?
==================================================================
Github: https://github.com/w3c/csswg-drafts/issues/1436
fantasai: The issue is about if display has value of none. 2.1
rules say position and flow don't apply and this short
circuits the rest of display computations. Normally if
you have position: absolute and float: left float
computes to none. If you have display:none the
computation doesn't happen. However, this becomes
interesting with display: contents. What do we do for
that one?
TabAtkins: This is where display: contents is the same problem as
none, it's just someone is more freshly looking.
fantasai: Anything with display: none due to its parent the float
computes to none. We propose any element with display:
none, child of display: none, or display: contents they
all behave the same in respect to these transformations.
<fantasai> https://github.com/w3c/csswg-drafts/issues/1436#issuecomment-313215820
fantasai: We proposed specific edits in the issue ^. We'd like a
resolution to make them consistent and then a second for
people to review the proposed edits.
dbaron: Idea is you make them consistent by always applying the
rule where if position is absolute float is none?
TabAtkins: It's bad that it's inconsistent.
Rossen: We already do...in all cases we would apply the rules and
it seems FF and Chrome from reading the issue have a half
and half where you do it for display: content but not
display: none so you have branching somewhere.
dbaron: I'd be hesitant to have special rules for descendants.
dbaron: But I'd be okay to make them all float: none
Rossen: There shouldn't be any special casing for descendants. I
was highlighting that in this case you're not going to
apply float computation rules, but with display: contents
you will. If we all align and make it always apply then it
will be more internally consistent and interop.
TabAtkins: It matches IE always and Chrome & FF except in cases
with display: none. Always applies is a small change.
Rossen: I'm fine making the changes to css position. fantasai you
said there might be changes to css 2?
Rossen: Or is it css display?
fantasai: Yes for css2. There are edits in the issue. It would be
good for someone to check those
Rossen: I did check, but those edits appear in css2.1 section 9.7
and in css position. I can reflect the position changes.
Question is do we need to do anything on css-display?
TabAtkins: I don't think so. Algorithm is only in 2.1 and
position. There's nothing special in display.
Rossen: Sounds good.
astearns: Sounds like we need to resolve to make edits in css
position. Would it make sense to make the edits, round
of review, and then backport to css2?
TabAtkins: We were operating off 2.1 algorithm so we know what
needs to be changed.
astearns: So we'd resolve the change for both position & 2.1
TabAtkins: Yeah.
astearns: Objections?
RESOLVED: Make the changes listed in css2.1 and position
CSS Display
===========
<ChrisL> we resolved to request CR on css display in February. Is
there some issue with the disposition of comments of the
transition request? bert was handling it
astearns: [reads ChrisL in irc]
fantasai: We resolved to publish display. Between resolution and
prep transition request Oriol filed a ton of issues and
we decided not to publish until we addressed those
issue. We now have except a few on the F2F agenda. We
can fix those and try again on CR.
ChrisL: Thanks. Good to know.
TabAtkins: I suggest we defer #8 reconsider name of frames()
timing function since we're still not at a stand still
on GH.
astearns: Can you remove agenda+ tag?
TabAtkins: Can do.
object-fit: scale-down should become a flag
===========================================
github: https://github.com/w3c/csswg-drafts/issues/1578
leaverou: Currently scale-down is defined as contain or none. If
contain would result in enlargement it's treated as same
as none. This was defined at time cover was rare. Today
we have a lot of images that are treated to cover the
entire background. I'm sure you recognize this, we see
it over the web. The scale-down behavior would be
useful, but it's defined as contain or none.
leaverou: It's unpredictable that it's defined that way based on
the name. I suggested scale-down becomes a flag used
with cover or contain. When it's on it's own it can be
defined as contain for legacy.
leaverou: I discussed with fantasai and she agreed. We wanted to
run by the group.
TabAtkins: Sounds reasonable to me.
astearns: Other opinions?
astearns: Doesn't seem like there's a backwards compat because we
can define scale-down by itself.
iank: Is there a github?
astearns: Yes. 1578
<leaverou> https://github.com/w3c/csswg-drafts/issues/1578
<rachelandrew> I think this would be useful behaviour.
astearns: I'm not hearing objections. Lots of positives.
RESOLVED: Accept the change in https://github.com/w3c/csswg-drafts/issues/1578
astearns: We made it through the agenda.
TabAtkins: fantasai has issues we could add.
[debate over what to do]
Should last-baseline's fallback alignment be safe or unsafe?
============================================================
github: https://github.com/w3c/csswg-drafts/issues/1611
TabAtkins: Fallback alignment is used in 2 cases. If you try and
use baseline alignment but the element isn't in a
context to do any baseline aligning it doesn't have a
size it can baseline align. It uses fallback. Other is
after you've done the baseline alignment you then align
the group according to your fallback alignment.
TabAtkins: Problem is with an end alignment, do we use safe end or
unsafe end? There's arguments on both. It's better to
shift down when it's too small then to lose part of the
content. I don't believe there's a strong author intent
to go into the unscrollable. I think it both cases it's
better to do the safe end alignment.
astearns: What's the difference between safe and unsafe?
TabAtkins: If container is smaller than element end alignment
aligns to two edges and you could get unscrollable.
That's unsafe. Safe is if it happens we switch to start
alignment so it scrolls down.
astearns: Got it. Seems reasonable.
Rossen: Last time we decided we fallback to end if we do last
baseline. In an overconstraint now it's start?
TabAtkins: This is unrelated. It doesn't trigger in the same cases
as discussed last week.
Rossen: Why not?
TabAtkins: Last week we were dealing with a stretching element
forced by a max width to be too small. This is things
larger than the container. It's a different set of
elements.
fantasai: Also it effects everything...you could interpret it 2
ways. 1 is we break alignment so if it overflows and the
other doesn't we don't overflow. Or they continue to
align and they both overflow and then do they align to
bottom or top.
fantasai: Other was just about one item and how it relates.
<astearns> start and end rather than bottom and top
Rossen: And this is because we fallback on end and we don't have
the problem with first because we fallback to start.
Rossen: Got it.
<dbaron> I support Tab's proposal here.
Rossen: Do we have any other cases where combination of end and
unsafe is the default?
TabAtkins: I don't think anything else falls back to end.
Rossen: Even in explicit end the default is safe?
TabAtkins: Determined by layout mode.
Rossen: Now if we have something fallback to end would safe and
unsafe be based on layout?
fantasai: I think we changed it so everything is unsafe by
default. This is a fallback to it's different.
Rossen: Now I'm starting to be less okay because we'll have cases
were I forgot one property and half my items shift in
weird ways and I don't know why.
TabAtkins: We're not proposing a control, so it's not leaving off
anything. You shouldn't make that decision because it's
a secondary alignment where the one you spec doesn't
fully apply.
Rossen: What I'm saying is I'll have two items, one last baseline
one end. In which case the one with last baseline it does
fallback to end. If we're not overconstraint they look
same. As soon as you're overconstraining one becomes
scrollable and one not scrollable directly and that's
weird and people will be confused.
Rossen: That's why I wanted to walk back from the behavior of the
explicit end or start and what kind of safe/unsafe
handling we have there.
fantasai: That's a fair point.
dbaron: You can specify safe start and safe end. It's saying
fallback for last baseline is safe end.
TabAtkins: Yeah.
Rossen: What I'm trying to say is if we made the explicit decision
that everything fallback mostly to unsafe, why make an
exception? If that's not the case maybe we revisit the
fallback to unsafe, but I don't see why to do that.
TabAtkins and fantasai: Can't change unsafe fallback,
Rossen: We have the fallback to go back to end, can we try and do
unsafe there and see if we have to change later with impl
feedback?
TabAtkins: Without any way to change safe/unsafe (and we're not
proposing a control) there's no way to get the other
and the one value we can expose should be the one that
guarantee to not hide content.
astearns: I'm confused why it's better for this case but not the
default.
TabAtkins: We already had centering and alignment based on margins
in flexbox and that was safe. We made them do the other
behavior to let you get them. When we moved to
alignment we felt it would be useful to allow a control.
astearns: It's just historical and backwards compat constraint.
TabAtkins: Maybe. I don't think it was unreasonable for flexbox to
default to unsafe because there was a control for safe.
Baseline alignment can't mimic itself with margins. We
either have to expose a toggle or make a choice and I'd
like to avoid syntax complexity of a toggle for this
edge case.
astearns: I can see both sides. I like that it will default safe
so in this edge case you won't lose content, but since
it's a tiny edge case I can see keeping it same as the
other default alignment.
Rossen: I'm going to be okay with either. I wanted to point out
consistency is always good. But I see losing content as
bad as well which will happen with explicit end already.
astearns: We're out of time. I suggest we let log bot put this in
the issue, let it sit for a week, and decide next week.
If there are additional thoughts please add to the
issues.
astearns: Thanks everyone for calling in.
Received on Thursday, 20 July 2017 01:04:37 UTC