- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 27 Jan 2016 18:56:28 -0500
- 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.
=========================================
Missing named line search
-------------------------
- RESOLVED: Accept the new language as suggested in option B of
this e-mail:
https://lists.w3.org/Archives/Public/www-style/2016Jan/0063.html
Snap Points
-----------
- There were still concerns about avoiding behavior that feels bad
to a user when using 2D scrolling, especially when combined
with mandatory.
- RESOLVED: Bring 2D snapping into the spec and mark as at-risk.
- There were varied opinions on if there needs to be more
terminology around the viewport to distinguish between
different types.
- MaRakow reported he wasn't blocked on this, so a decision
wasn't needed right away.
- It was agreed that the viewport terminology should be
defined in device adapt, overflow, or the viewport specs.
- fantasai explained that she believed having scroll-snap-padding
and scroll-snap-margin physical and scroll-snap-align logical
makes sense because scroll-snap-align interacts with the
scrollers which operate in logical direction.
- MaRakow felt that her example case didn't deal with the case
when the user sets two properties on a 1D scroll. He'll
make another example case to further the conversation.
- The bikeshedding of the properties currently called 'mandatory'
and 'proximity' will happen at the F2F, but it was agreed that
the names should be improved.
- The short conversation on splitting scroll-snap-type seemed to
indicate approval of the split, but naming will wait until the
F2F.
Group Reminders
---------------
- Please remember to reply to the e-mail about spec publications
(available here:
https://lists.w3.org/Archives/Member/w3c-css-wg/2016JanMar/0014.html)
- Also, please continue to continue reviewing tests to keep the
testing backlog small.
===== FULL MINUTES BELOW ======
Agenda: http://lists.w3.org/Archives/Public/www-style/2016Jan/0250.html
Present:
Rossen Atanassov
David Baron
Dave Cramer
Alex Critchfield
Elika Etemad
Simon Fraser
Tony Graham
Dael Jackson
Brad Kemper
Simon Pieters
Anton Prowse
Matt Rakow
Francois Remy
Florian Rivoal
Lea Verou
Regrets:
Tab Atkins
Daniel Glazman
Peter Linss
Myles Maxfield
Edward O'Connor
Alan Stearns
Ian Vollick
Greg Whitworth
Scribe: dael
Missing named line search
=========================
Rossen: Let's get going.
Rossen: Do we have any additional agenda items?
<Rossen> https://drafts.csswg.org/css-grid/issues-wd-20150917#issue-26
fantasai: The named line search as described in the email was
doing some non-consistent things. We changed the rules
and wanted whoever was interested to review. This was
the last week to review so if you didn't want to you
didn't. I won't go over them.
Rossen: We went over it on our end.
<Rossen> https://lists.w3.org/Archives/Public/www-style/2016Jan/0123.html
Rossen: The edits and the conclusion captured in this thread
(above) makes sense.
Rossen: We're good with that resolution.
fantasai: Did we resolve?
Rossen: We can sure. Do we have enough other implementors? Anyone
from webkit who can look or Mozilla?
fantasai: It was raised by the Mozilla implementor so they should
be okay. TabAtkins and I made the change so I'm assuming
webkit is okay. The webkit implementor said on the
thread they liked it.
Rossen: Okay. Do we have any objections?
RESOLVED: Accept the new language as suggested in option B of this
e-mail:
https://lists.w3.org/Archives/Public/www-style/2016Jan/0063.html
Snap Points
===========
2D Point Snapping
-----------------
Rossen: Keep, drop, or at-risk?
Rossen: Who wants to take that?
MaRakow: I can speak where it is. We talked to...Apple spoke to
their concerns about the complexity at the Japan F2F. I
was going to omit it, but Google wanted it on the table.
I don't have a super strong opinion, but I'd like to
decide to keep or drop now.
Rossen: We don't have to resolve to keep if it's there. If you
want drop or at-risk we should resolve.
MaRakow: It's not in the spec, but in the TabAtkins and fantasai
proposal.
Rossen: It's not part of an official spec. So if we want to add it
let's resolve.
Florian: I'm not sure I agree because we've agreed to align to the
proposal. I'd rather a resolution either way so that we
don't have to debate which spec is official.
Rossen: We have an official one and it's part of our charter.
There's changes being brought from the proposed spec. We
did resolve to have the slow combining of the spec. As the
wording from last week's resolution is masterfully crafted
by fantasai, we're not rubber stamping, we're moving many
of the terminology pieces.
Rossen: The topic was brought to the group to see if this part of
the spec is to move forward or put at-risk.
* fantasai thinks the point of Florian's comment was to avoid this
topic.
Rossen: So, what is the proposed resolution at this point?
MaRakow: I'd not resolve at this point, but leave it out, but I
wanted to make sure everyone had a chance to speak.
fantasai: We'd prefer leave it in and marked at-risk. I think a
big part of Apple's concerns was from unclarity and
we've clarified. TabAtkins and I believe there are
reasons to keep it so we'd prefer in the spec and at
risk instead of drop it.
<Florian> +1 to fantasai
Rossen: So the proposal is to move it into the WD and mark as
at-risk.
MaRakow: fantasai, do you have what would remove it from at-risk
in either direction.
fantasai: at-risk is in the draft and gets dropped if there isn't
sufficient interest to implement. The WG likes it and
thinks it's a good idea but it needs implementor
interest.
MaRakow: So keep or cut depends on if there's other
implementations when we want to go to PR.
Florian: Yes, if it's not implemented we can drop it quietly. If
there's implementations we keep.
smfr: My concern isn't implementation complexity, but experience.
We do axis locking on scrolling. My concern with 2D is you
have a situation where you're scrolling on one axis and 2D
will move you on the other axis. I want implementation that
doesn't feel bad to user. A polyfill to implement this
behavior may help us see what it feels like and work out
details in JS form.
Florian: I don't think spec requires you go off axis, especially
if you're in proximity. What proximity means is up to you.
smfr: But mandatory + 2D would feel weird.
fantasai: The intended use case is for something like a 2D map
where you want to pan. A map or a planet or a game where
you're going between worlds in 2D. If you're doing
scrolling with a scrollbar it will be awkward. It's
intended for other cases.
smfr: So what about when a user without a trackpad encounters
content like that?
Florian: I think a map like that with proximity is logical, but
mandatory can be odd.
fantasai: You have that problem without snapping. If you're
navigating something like the Super Mario Bros map with
a scroll wheel it won't work.
smfr: So I prefer to mark it at-risk. Once we have an
implementation we may not like it.
fantasai: Seems good to me.
Rossen: So, resolution is to bring it into the spec and mark as
at-risk.
Rossen: Objections?
RESOLVED: Bring 2D snapping into the spec and mark as at-risk.
Viewport Snapping
-----------------
<Rossen> https://drafts.csswg.org/css-scroll-snap/issues-2015-12#issue-6
MaRakow: This is talking about the terminology in the spec for the
scrollable region in question. Is it a visual viewport or
a new term? fantasai has proposed scrollport, I think.
There was debate on that.
MaRakow: The visual viewport implies some of the shared technology
the browsers have for UI and what's viewed by the user.
The content you see on screen is the visual viewport.
That's the term in the spec.
fantasai: It wasn't clear to me that viewport was being used for
the scroller rather than the main root. And we have
places in our syntax where we use viewport to refer to
the root viewport.
fantasai: The issue is that we need a new term for the portion of
the viewport that is the boundary of snapping so we
wanted the active region used for snapping for this
viewport. We were discussing terminology for that. I'd
heard scrollport in a couple of places. So that could be
the viewport of any scrollable box. The root is the only
place that has the distinction. So do we introduce it as
the visual viewport and the viewport of all scrollable
divs.
Florian: I think I'm in favor of fantasai's proposal because it's
complex enough to need to understand and hard to learn.
If we can keep the terms clear I think it will make CSS
more learn-able.
MaRakow: The visual viewport only pertaining to the root may not
stay true. One item we added back in IE10 was to declare
a region with overflow as zoomable. I think that's
functionality we'd like to introduce and that has zooming
at the root and sub elements.
MaRakow: I wouldn't expect that the split in the long-term be
unique. I think if we want to distinguish between root
and element viewport, we might want to specify the root
for vw and vh
Florian: It's also meta-viewport, @viewport
MaRakow: Right. All those things we'd want to distinguish.
<smfr> iframes have viewports too
Florian: We would need to disambiguate all of CSS at that point.
Florian: I think a hierarchy of terms for visual and root and
another term that's for scrollable...these are clearly
related...but keeping layout as the root is more clear.
MaRakow: But then there's still the case for sub-elements. You'll
have visual and layout and scrollport and then there's
too many terms for the number of concepts.
Florian: Do you need to have zoom for this to matter? You have an
element that's overflowing and scrollable
MaRakow: Only case where they're different dimensions is when you
have a zoom, currently. You can imagine other features,
but that's the big one.
Rossen: It also makes the difference...most obvious is any
container that can position fixed position. The root
viewport, but also iframes. We also have a device:fixed
positioning which is similar to fixed but doesn't get
effected by zoom so any UI you want to attach on the side
of a viewport (using the term loosely) the optical zoom
may or may not effect those.
Rossen: For naming sake, the scrollport only talks about scrolling
but doesn't have panning or other manipulation you can use
to target that.
Rossen: Is this something we need to discuss for scrollsnaps or
should this be in the viewport spec that Florian plinss
and I are working on.
Florian: This kind of term definition belongs in that root spec or
the device adaptation spec.
Rossen: I'm just curious if this is worth being captured in any
way in scrollsnap.
Florian: It's good to know which term, even if defined elsewhere.
fantasai: It should be defined in overflow.
MaRakow: Either way, I think I can make an unambiguous spec
without another term.
fantasai: I think it's fine.
Rossen: For this issue, do you not need a resolution.
fantasai, MaRakow: no
Rossen: Okay.
Rossen: So we decided to take this into device adapt, overflow, or
the viewport. Between these specs one can define this.
Physical/Logical Coordinates Mismatch
-------------------------------------
<Rossen> https://drafts.csswg.org/css-scroll-snap/issues-2015-12#issue-7
fantasai: TabAtkins and I replied to this. I don't think I added
it to the list.
fantasai: Let me find it.
fantasai: This may need to be at the F2F
<fantasai> https://lists.w3.org/Archives/Public/www-style/2016Jan/0138.html
fantasai: MaRakow pointed out that the coordinate system for
scroll-snap-padding and scroll-snap-margin is physical
and scroll-snap-align is logical. He was listing the
background in that we added logical to margin and
padding so both coordinate systems will work in both.
fantasai: scroll-snap-align is logical for a few reasons. The
direction that you're scrolling is almost never going to
want to be physical because the direction of the
scrollers are logical. So we designed scroll-snap-align
to match that scrolling are mostly logical. Also when
you set the axis you can choose physical or logical and
you pay attention to that.
fantasai: So we don't think it's harmed by being just logical. We
could add physical and have them both expressible, but I
think you'll always want to be logical even when
referring to physical. If we find we want it in the
future we have the space to do so, but we can limit it
now. That encourages authors to do the right think and
limits testing.
MaRakow: I don't think it helps for mismatch between horizontal
and vertical.
fantasai: You can use the scroll-snap-type and say x or y. That's
provided. In the alignment if you give one keyword it
applies to both axes.
MaRakow: I looked at your example and when you give two keywords
which is the first?
fantasai: We wanted to be consistent with how alignment and
box-alignment works.
MaRakow: The example in your mail is only a single keyword for
align, but the issue arises with two keywords. So I don't
think your example covers the situation.
fantasai: The situation is...
MaRakow: If someone wants a thing only scrollable in one direction
so the specify x and then they specify center and none,
we want it to work.
Florian: Why would they specify both? Why put both keywords on
scroll-snap-align.
MaRakow: It's not an argument as to if it's a good idea, but if
you have two, which is the first and which is the second?
MaRakow: The spec needs to say what happens for two.
Florian: The author would make his life harder. The simple way to
author is one keyword in one direction. In the vast
majority of cases the contradiction doesn't happen. If
you use it the normal way there is no contradiction. You
can get yourself there but you don't have to.
MaRakow: I'm not saying this is the way you should build it, but
if someone uses two keywords which is first and which is
second? I'd like the spec to say something to keep it
consistent. I'm not saying you should use two, but if you
do what do you do?
Florian: I was trying to go after that we should try to have the
syntax that makes sense in most use cases. If the
scroller is 1D, if you have two we have to decide, but
it's not common. I think fantasai made more sense in her
argument for what we do when there's 2D. That's the
scenario that it makes sense to look at.
MaRakow: So it would help to have an example that more clearly
shows when the problem arises?
Florian: So I think because setting one keyword for 1D the logical
option is to set one keyword, so that's neutral. So we
should look at the 2D scenario and see what's more
relevant to express for that scenario.
MaRakow: I don't think it's unique between. The only thing that
changes isn't if you can scroll, but if snapping is
interesting in the other axis. I can do an example with
overflow in both directions and you want snapping
physical.
Florian: Yeah, probably that would help. It's a good thing to
compare.
fantasai: The default of scroll-snap is to work in block. We
default to doing only one axis because we imagine that
that's the most common. If we were to default to both
directions the author could assume it's great on their
big screen, but it could give horrible behavior on a
smaller screen. To prevent that which could be common we
made the default to accept both.
fantasai: The default is logical. So it makes sense that
snap-align should be logical. If there's compelling
cases for when logical isn't appropriate we can add
physical keywords. I'm just not seeing a case for that.
Florian: So what we need to address this is 2D snapping and 2D
scrolling example.
MaRakow: I'll see if I can come up with a better example.
Florian: Thanks.
scroll-snap-type Bikeshedding - Mandatory/Proximity
---------------------------------------------------
<Rossen> https://drafts.csswg.org/css-scroll-snap/issues-2015-12#issue-1
<Rossen> https://lists.w3.org/Archives/Public/www-style/2015Dec/0177.html
MaRakow: The proposal is 'near' and 'always'. I would agree that's
there's better names than 'mandatory' and 'proximity'.
fantasai: I'm the same on this issue. We could do better, though
I'm not super excited about those names. I'm open to
other ideas.
MaRakow: If it helps, I can add an issue to the spec saying we're
searching for better names.
fantasai: We'll have more people at F2F so that may be better for
bikeshedding.
MaRakow: I won't be there, but if something comes up...
Rossen: We can try and find a time you can call in if you'll be in
the office.
MaRakow: I won't be in the office, so I won't be able to call.
Rossen: Bikeshedding can be re-bikeshedded. So fantasai proposes
we take these to the F2F, look for better ideas, and bring
them back as proposed changes.
Rossen: Would that apply to the next issue?
Florian: Probably.
Splitting scroll-snap-type
--------------------------
<Rossen> https://drafts.csswg.org/css-scroll-snap/issues-2015-12#issue-3
fantasai: We can talk about if we agree on splitting. But names
should wait.
Florian: I can see why we can, what's the use case?
MaRakow: It's a goal to make it more clear as to which type of
snapping applies to which axis. I have a hard time
telling which would work better, but it's a lot of info
into a single property. If we can be clear which snap
types are for which axis it's a good goal.
Florian: Splitting into 2 properties makes sense if we expect them
to cascade separately. Do we expect that?
Rossen: Good point. I don't see why they couldn't.
Florian: You can, but is it useful?
Florian: Is it a writing mode story where if you're mandatory or
proximity it's fixed but if you flip...eh, maybe.
Rossen: I don't know how much the inheritance model helps anyway.
MaRakow: Seems like we maybe need a good example that shows an
advantage.
Florian: I think the split is possible...just...wondering how
often you'll want.
Florian: You can rely on default and be fine but you can rely on
the shorthand. Sure. If we can get good names, why not?
Rossen: Sounds like we came back to needing more people and more
bikeshedding at the F2F.
Group Reminders
---------------
Rossen: Spec updates. This is a nudging. We don't need to discuss.
Florian: Related to the updates, how are we on testing and
clearing the queue?
Rossen: What in particular?
Florian: We still have quite a few things in the test queue.
Rossen: Right. It did move, but not significantly reduction. There
was a lot of move right after the discussion we had. I
would have to go back and see. I'm not sure if that was a
momentary surge.
Florian: I think it was.
Rossen: I don't think we'd be able to decide a lot more on the
call.
Florian: Yep. Just a nudge.
Rossen: Fair enough. If you can help reviewing tests, please do so.
Rossen: Let's call it a day. We'll see most of you in Sydney. Safe
travels!
Received on Wednesday, 27 January 2016 23:57:27 UTC