- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 17 Aug 2016 20:52:05 -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.
=========================================
September and January F2Fs
--------------------------
- Rossen asked group members to ensure that the proposed dates for
January are clear so he can finalize plans.
Wrong assumptions about baselines only occurring in the inline axis
-------------------------------------------------------------------
- RESOLVED: Remove baseline from the block-axis as a way to align
Sizing grid items
-----------------
- RESOLVED: Stretch items the same way we do for non-replaced
Scroll Snap
-----------
- There was some concern that content re-stabilizing not being
defined in the spec will prevent testing.
- RESOLVED: Accept the changes proposed here:
https://drafts.csswg.org/css-scroll-snap/diff-notes#change-resnap.
Make sure that if the UA evaluates and thinks it
shouldn't re-snap it's not required to do so,
potentially by merging the first and last sentences in
the paragraph.
- Though everyone agreed on the problem space, there were concerns
about the proposal to turn scroll-snap-padding into snap-
padding. Some of the concerns raised were:
- The proposal wasn't intuitive for authors.
- The proposal was trying to solve too many use cases to be
effective.
- The discussion will continue on the github issue to continue
resolving concerns.
- fantasai emphasized that this needed to happen quickly to
keep this from holding up the spec.
Synthetized baselines seems like a breaking change
--------------------------------------------------
- RESOLVED: Close https://github.com/w3c/csswg-drafts/issues/373
as no issue.
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2016Aug/0051.html
Present:
Rachel Andrew
Rossen Atanassov
Tab Atkins
David Baron
Bert Bos
Alex Critchfield
Dave Cramer
Elika Etemad
Simon Fraser
Dael Jackson
Brad Kemper
Ian Kilpatrick
Peter Linss
Thierry Michel
Michael Miller
Myles Maxfield
Simon Pieters
Anton Prowse
Liam Quin
Matt Rakow
Florian Rivoal
Jen Simmons
Geoffrey Sneddon
Alan Stearns
Ian Vollick
Greg Whitworth
Steve Zilles
Regrets:
Tantek Çelik
Daniel Glazman
Edward O'Connor
September and January F2Fs
==========================
Rossen: It's 9:03PT. Hello everyone. Are there any last minute
items to discuss?
<jensimmons> This is off topic, so I’ll drop it here & not say it
aloud, but I wanted to share this article that I
wrote on Feature Queries:
https://hacks.mozilla.org/2016/08/using-feature-queries-in-css/.
There’s not been much written about how to use
@supports yet… this should help teach people what it
is.
<TabAtkins> Is good article.
<jensimmons> thanks TabAtkins
<zcorpan> (I earlier today Agenda+ed
https://github.com/w3c/csswg-drafts/issues/409
- didn't know if it was on the actual agenda or not yet.
but happy to discuss it next week or discuss in the
issue)
fantasai: I wanted to do the airBnB. Reply now so Florian can sort
it out.
Rossen: Yep. Is there anything else before that?
Rossen: Then I want to add the Jan F2F as well. Go ahead Florian
and fantasai.
Florian: There's 3 people from Japan coming on top of me. So I
booked a place. I had no info from anyone else then.
There's one more, I'll check the number of beds.
fantasai: Do you have space for zcorpan?
Florian: I may. I'm not sure if I have enough without sharing beds.
fantasai: zcorpan and plinss replied on the thread.
Florian: I booked before that. I'll check. I may have 1, likely
not 2.
Rossen: Anything else on this? Or can it go back to the mailing
list?
Florian: Yep. I'll follow up there or privately.
Rossen: Thanks for organizing that.
Rossen: Reminder on the Jan F2F. I'm looking at locations. Our
current schedule has Jan 11-13.
Rossen: Please go to your calendars and verify this isn't
something that's a hard conflict with anything else before
I make final arrangements.
* fantasai will know January schedule hopefully by next week
Rossen: I'm trying to see if we can locate in Seattle itself. If
not we'll be in Redmond.
<smfr> +1 for seattle
Rossen: That's all on F2F.
Wrong assumptions about baselines only occurring in the inline axis
===================================================================
<Rossen> https://github.com/w3c/csswg-drafts/issues/197
fantasai: Mats pointed out we define block-axis baselines and
there's restrictions on how they applied so he filed
issues to remove them. In the process of trying to do
that...we checked in a bunch of changes and fremy was
concerned. Last week we talked about a bunch of this
stuff and came up with reason it won't work. So proposal
is remove them so baseline can only be in inline axis. A
grid could do alignment in a column, but the actual
container can't have block-axis.
fantasai: Reason is, for example, you have a column in a grid or
table and the first is horizontal table or grid that
have vertical text. In theory that could have a baseline
on the right or the left. On the next two rows have have
one vertical-lr and one vertical-rl and they don't align
to each other. What happens to the horizontal element?
fantasai: This is a nonsensical situation. It seems this would end
up being arbitrary and there's a bunch of complications.
fantasai: Proposal is baselines can only exist in inline axis of
the box and make sure all boxes have a baseline.
Rossen: I'm in support of this. I agree we should keep the inline
concept inline and not introduce in the block direction.
Rossen: I won't repeat everything, but we support backing out of
that feature.
Rossen: Additional comments? Questions?
* fantasai pings TabAtkins for comment
Rossen: fantasai did you want a resolution?
fantasai: Yes.
Rossen: Objections to removing baseline from the block-axis as a
way to align?
RESOLVED: remove baseline from the block-axis as a way to align
Sizing grid items
=================
<Rossen> https://github.com/w3c/csswg-drafts/issues/283
<Rossen> https://github.com/w3c/csswg-drafts/issues/394
fantasai: There was an issue filed a while back on the implied
size and how that interacts with fixed size track. We
concluded fixed size should reduct the auto-min.
fantasai: That caused me to take a closer look and we're not super
consistent on defining sizing for grid items. So what
should we do? Based on flex containers it seems they
should be doing a value that's stretched and we do the
replace for the fit and resolve the auto thing.
fantasai: If there is content bigger than the grid item it won't
stretch to fit, it'll stay in the track. And we want
that in both dimensions. The reason is the authors set
an explicit size on the track. It seems more likely the
way is to stay in the track by default. It's also to be
consistent with the lines in flex that operate in the
cross axis.
fantasai: Main axis flex does something different where we can
overflow and the items stack. One of the reason we use
auto-min is to make the content readable for the user.
fantasai: That approach's usability depends on the items moving
down and not overlapping. In fixed size you get the
overlapping. The model is more consistent with flex in
the cross axis.
fantasai: Talking with Microsoft that's what they implemented
which has some author feedback. So clarify the spec and
resolve contradictions in favor of for stretch items use
the non-replaced block formula.
Rossen: Thanks for the summary. Comments? Suggestions?
Rossen: So we have a proposal: Stretch items the same way we do
for non-replaced.
Rossen: Objections?
RESOLVED: Stretch items the same way we do for non-replaced
Rossen: fantasai you'll make the edits?
fantasai: Yep.
Scroll Snap
===========
Re-snapping requirements
------------------------
<Rossen> https://drafts.csswg.org/css-scroll-snap/diff-notes#change-resnap
fantasai: We skipped one of the San Francisco differences. You can
read it here^. I could read it out load, but best way is
to give people time to read an than type +1, -1, or 0
into IRC.
fantasai: Reasonable?
Rossen: Yep. Let's cap it at 2 minutes.
* Florian read it, sounds good. +1
smfr: I think someone will have to implement to know if it's the
right thing. We'll have to do this by feel.
fantasai: We're doing it, but this is cleaning the prose.
smfr: Does any implementor do re-snapping?
fantasai: No, but the spec requires it. I'd rather fix the prose.
If we find problems we can file issues.
Florian: Until then we need to be consistent.
fantasai: If you don't like the section that's a separate issue.
MaRakow: This is only editorial, not functional, right?
fantasai: I think there is a somewhat substantial change in bullet
2.
MaRakow: What would be the functional change resulting from that?
fantasai: I think its...it's matching a resolution from Jan 20th.
MaRakow: It sounds like all you're doing is putting the
duplication of text in one place.
fantasai: Yeah. [reads]
MaRakow: I see.
Florian: This is somewhere between editorial and normative where
the previous was too ambiguous?
fantasai: I don't remember.
Florian: I like it.
MaRakow: The "must be re-snapped" might be the most interesting. I
don't know if for proximity that's always right.
fantasai: The model is there's valid places to be and not valid
places. The proximity can change based on distance and
speed, but this is saying that the user very slowly was
holding the scroller over a scroll offset and waited for
a while before letting go. If scroll would then be
adjusted the equivalent adjustment should be made when
user isn't scrolling but content has moved so we're in
the same position.
fantasai: So the content and scroll position moves until it's
stable and we see if we snap or not. That's evaluated
the same as the user doing a precise drop. If not script
could get you into a position the user couldn't get to.
Florian: I think the spec is loose. You're not strict on heuristic.
fantasai: We are.
Florian: Within explicit scroll there may be other heuristics.
fantasai: That's fine. An explicit scroll is I want that position
exactly.
Florian: And if on top of that there's other heuristics they can
continue to apply. So be smart but do something. Am I
reading right?
fantasai: The script cannot get into a position the user can't.
MaRakow: Right now it's phrased as re-snapped. Maybe what you're
going for is must reconsider snap points in the case
where they would be if the scroll was to that position.
fantasai: I see. We're using re-snap and that implies we snap to
the previous. But there's no previous in this case. I
can say UA must reconsider snapping. I'll fix that.
fantasai: Take all these changes and "must be re-snapped" to "must
reconsider snap positions"
Florian: I think the last paragraph has a clarification of that.
fantasai: I don't know.
Florian: 2nd green highlight in the last paragraph.
fantasai: Yeah. That's fixed there.
Florian: [reads]
MaRakow: I think it's both. It's trimming the final sentence in
the 3rd bullet point. I think the last bullet is the
proposed final text.
fantasai: Let me re-evaluate.
fantasai: It looks like last and first sentence should be merged.
MaRakow: Yeah.
Florian: I'm hearing we agree about the content and some editorial
concerns. Can we resolve to do it and leave it to the
editors for phrasing?
MaRakow: I have another issue. I think you're right about merging
the sentences. Sounds probably right.
MaRakow: Other thing is the statement about content re-stabilizing.
Is that well defined?
MaRakow: I think I know what it means, but is there a definition
to link off to?
fantasai: We don't have an official definition. I'm not sure if we
want to. UA is trying to figure out batching changes.
Rossen: How to test without it?
fantasai: It's obvious that it's stable if it's not changing in a
large chunk of time. If there's changes 2 ms apart the
UA might not re-snap. We don't want to be overly precise.
We can assume 1 sec of not moving is enough.
MaRakow: That's different than I thought. I thought I was during
script execution you wouldn't re-snap.
fantasai: It's up the the UA. That's all up to them. As long as
it's not a long chunk of time where it sits there for a
while and then snaps is unacceptable. We can come up
with reasonable for testing, but pinning it down depends
on heuristics the UA might want to tweek.
MaRakow: I'm wondering if there should be a firm lower bound where
you don't re-evaluate sooner than X.
<gsnedders> I'm going to point out that manual tests are almost
never run.
fantasai: I don't think we need that. I don't think interop on the
same time is important. I think it's what the tester
feels is a reasonable limit. If a UA fails and disputes
that it fails we can re-discuss. I don't think that'll
happen.
liam: You need text that with content-editable you shouldn't
scroll while someone is typing.
Florian: That's part of the next thing on the agenda
Rossen: So back to this one to try and close.
<liam> [oops]
Rossen: What is the proposed resolution?
fantasai: To accept the changes, make sure it's clear the UA isn't
required to re-snap, it's not supposed to re-snap. Make
it clear that if the UA evaluates and thinks it
shouldn't re-snap, it's not required to do so.
Rossen: Okay.
Rossen: Sounds good to me. Do we have objections?
MaRakow: Also merge the first and last sentences.
fantasai: Yeah. And we can tack onto the resolution "by
potentially by merging the first and last sentences".
Rossen: You okay MaRakow ?
MaRakow: Yeah.
Rossen: Other comments or objections?
RESOLVED: Accept the changes proposed here:
https://drafts.csswg.org/css-scroll-snap/diff-notes#change-resnap.
Make sure that if the UA evaluates and thinks it
shouldn't re-snap it's not required to do so, potentially
by merging the first and last sentences in the paragraph.
scroll-snap-padding vs scroll-padding
-------------------------------------
<Rossen> https://github.com/w3c/csswg-drafts/issues/395
<fantasai> https://github.com/w3c/csswg-drafts/issues/395#issuecomment-239995319
fantasai: I dropped a link to the proposal. Basic issue, scroll
padding helps with when you want some breathing room
between content and viewport or you want to exclude some
area of the viewport because there's something to avoid.
So you're snapping the items in a smaller area.
fantasai: Turns out a lot of operations need the same behavior.
Like navigating to a fragment id. So you shouldn't bring
it into the viewport because the author told you to
exclude it. Even when we don't have a snapping viewport,
we would want this kind of control where the author says
exclude this area. Operations that involve the area
navigate to a fragment ID. If the user tabs through form
controls and something is off screen the UA will bring
that into the viewport.
fantasai: Page up and page down when you're excluding a header and
you want to exclude that so that content doesn't go
under. There's a lot of use cases.
fantasai: We can solve all of them with scroll-snap-padding. It
needs a rename to something like scroll padding. It
would solve all this declaratively. It would allow
authors to stop hacking scrolling on this type of page.
fantasai: The UA can create a better experience when the author
can give this info. Proposal is rename to scroll-padding
and have it solve all these cases.
fantasai: No effect on layout or scroll origins. So we're not
changing meaning, we're just allowing the UA to use it
for more than snapping.
Florian: Two things to add. It effects fantasai's cases with no
snapping. It also effects scroll snapping because if you
have...we defined explicit scrolling when you bring
something to a point. There's a few operations that
combine scroll into view and than snap which isn't
explicit scrolling.
Florian: If you tab to something you scroll to bring the focused
button into the area and than you snap. It's a combo of
the effects.
<Rossen> https://sketch.io/render/sk-046db1469a67b75d62773ad88383a1ed.jpeg
Rossen: I mentioned this to fantasai when she visited. My concern
is by default the feature kind of doesn't work. If you
look at that sketch I shared: if you have no padding by
default and let's assume it's a block. Since we don't have
regular padding the content origin is 0,0.
Rossen: Your scroll-padding, let's say it was defined as top: 2em
then the feature doesn't work because you'd have to
reposition the origin of the content.
Rossen: Also going to be odd cases with scroll padding and scroll
top butting against each other creating scrollable area 0.
Rossen: I can poke many holes into this proposal.
fantasai: I think it is important for scroll padding to be
independent and not interfere with layout. Authors may
intentionally put stuff in the scroll padding. They're
responsible to make sure the visible content is where
they want it to be. It should just be for padding not
for layout.
fantasai: I don't want to tie them together
Rossen: I totally agree. Scroll padding shouldn't effect layout.
I'm trying to say the feature itself is already becoming
seemingly broken when you don't align the layout so it
works the way it should according to scroll padding.
Florian: I don't think so.
MaRakow: To echo Rossen I think there's a lot further
considerations. The problem you want to solve is there's
a lot of scrolling mechanisms that have crappy results
and it's an interesting problem. I think the scrolling
mechanism you called out are diverse enough that I don't
think there's a single approach.
fantasai: I don't think we can solve everything, but telling the
UA the scroll padding gives the UA the information it
needs to do something smart. For example focus will
bring something into view, but it won't snap or scroll
unless the author requests. The scroll padding tells the
UA the area you consider the focus.
MaRakow: To finish my thought, I think there's an interesting idea
to declare a suboptimal region for content, but it needs
thought on interaction. For example I think you said this
is scrollers with a non-snapping scroller. But when it's
not none we need to answer how it interacts with snap
points. Also cases when snap padding can't be satisfied.
There's open questions.
MaRakow: It's a question also if it's a guarantee it'll come into
view or a hint to the UA.
MaRakow: If it's the latter I'm not sure overlapping with a
feature that controls scroll offset is right.
fantasai: When you can't get to the position we should treat it
like a snap position you can't get to. I think that's
straightforward. The UA should try and put something
into view, but it might not be able to do that because
the scroll area isn't big enough or if there is some
snapping restrictions that would restrict the UAs
ability to put the element into the snap port.
fantasai: Just as we didn't have scroll padding and we had to
bring the thing into the viewport.
fantasai: [missed] I think this can be precisely defined and the
snapping interaction is straightforward.
Florian: I'll reply to Rossen first and the diagram. If you don't
consider regular scrolling, but snapping and snap
scrolling you have the same problem. If it's positioned
somewhere you can't scroll to you have the same problem.
If the author puts things into the area that's not
reachable you won't be able to go there.
Rossen: I'm talking about default behavior. This is a default
behavior that you'll get if you don't have padding.
Putting an element that's beyond scrollable is an edge case.
fantasai: Right now there's the same problem. You get the same
problem and it's not a new issue. It's how these
properties in general work.
Rossen: Snapping and not being able to snap is one thing. Putting
a banner on top of a box and assuming that scrolling will
adjust so all text is visible is confusing. Padding
suggests that you'll have padding from your position.
fantasai: It's scroll padding. Authors are solving this now.
They're hacking scroll events because they can't solve
the scrolling piece, but they already have control over
layout.
Florian: In response to MaRakow about many things effected, I
agree there's quite a few and they're different, but
they're unified because they're all the things where the
user, whether they're moving by tab or whatever, there's
an implied request for scrolling without a coordinate. In
all these cases the UA has rules to decide where to put
the element. That's the shared characteristic. The user
asks for something the results to a scroll somewhere in
the viewable area.
Florian: This says you should only consider the area reduced by
the padding.
Florian: All the heuristics you do keep doing it. Just consider
the smaller area.
Florian: How this interacts with snapping. Instead of the user
giving an explicit coordinate, the user requests the UA
to pick some coordinate in the area. Then you use the
normal. This gives an extra step to consider the padding
when picking a coordinate. After that it's the same thing.
The UA picks, it's just an extra consideration.
Florian: All mechanisms say pick something viewable in an area.
We're restricting the area.
Florian: I'd like to argue a bit more on our point, but we can go
to the queue.
Rossen: We can take that to the issues.
MaRakow: I mostly wanted to echo that it's more productive to go
back to the issue. It's an interesting problem, we need
to talk through approach.
Rossen: I agree. I'm not trying to shoot down the problem or
solution, I want something more intuitive.
fantasai: We should wrap up this spec before TPAC. No reason to do
that except if people want to think about it that will
hold it up. Let's try and get to a point where we can
vote soonish, not in 6 months. Or we try and add it and
work out issues.
Rossen: I would prefer to take it to the issue and if there's no
traction by next week we want add it and force the issue
in the spec. How does that sound?
fantasai: Yeah. I just want this to not be let's think about this
cute idea... maybe under the cherry blossoms next May.
Rossen: Florian I see you're on the queue, I want to finish and
move on.
Florian: Short point. If we add this change it removes the need
for a proposal from TabAtkins about sticky snapping.
There is maybe extra complexity here, but drops other
proposals.
Rossen: 2 minutes left. Anything we can do in that time?
Rossen: [read them]
Synthetized baselines seems like a breaking change
==================================================
<Rossen> https://github.com/w3c/csswg-drafts/issues/373
fantasai: I think for baseline alignment the conclusion was we
keep synthesizing baselines for everything.
Rossen: So we can close this issue?
fantasai: I believe so unless TabAtkins has something?
TabAtkins: It's fine. I have nothing to say.
Rossen: You're fine closing this no issue?
TabAtkins: Yep.
Rossen: Objections?
RESOLVED: Close https://github.com/w3c/csswg-drafts/issues/373 as
no issue.
Rossen: We're top of the hour. Let's call it a day and we'll move
the remaining items to next week.
Rossen: Thank you everyone.
Received on Thursday, 18 August 2016 00:53:06 UTC