- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 4 May 2016 19:39:48 -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.
=========================================
MQs should respond to page size
-------------------------------
- There was agreement on the mailing list that media queries
should respond to page sizes set in @page, but Florian wanted
more guidance with what direction the proposed text should take.
- Florian suggested that he could write the text to allow the
property function similar to @viewport.
- There was some uncertainty as to if this was the right
approach, though several people were also in favor of it.
- Florian will write proposed text including use cases and bring
it back to the group.
propdef tables for shorthands
-----------------------------
- RESOLVED: Adopt the proposed convention for propdef tables for
shorthands (proposal here:
https://lists.w3.org/Archives/Public/www-style/2016May/0007.html)
Snap Points
-----------
- 'proximity' and 'mandatory' still need to be renamed, but the
group didn't like 'strict' and 'loose'.
- Though originally the topic was around the snap alignment
container, there were really three items that need to be named:
A. a box that has a scrollbar
B. the viewport of the scroll container
C. the snapping area of the viewport of the scroll container
(i.e. viewport minus scroll-snap-padding)
- RESOLVED: A div with overflow that's not visible is a 'scroll
container'
- RESOLVED: B (the viewport of the scroll container) is a
scrollport. C (the snapping area of the viewport of
the scroll container) is a snapport.
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2016May/0022.html
Present:
Rossen Atanassov
David Baron
Bert Bos
Dave Cramer
Alex Critchfield
Elika Etemad
Simon Fraser
Daniel Glazman
Tony Graham
Dael Jackson
Brad Kemper
Ian Kilpatrick
Chris Lilley
Peter Linss
Myles Maxfield
Edward O'Connor
Anton Prowse
Matt Rakow
François Remy
Jen Simmons
Alan Stearns
Lea Verou
Greg Whitworth
Regrets:
Tab Atkins
Tantek Çelik
Michael Miller
Scribe: dael
MQs should respond to page size
===============================
astearns: Let's get started.
astearns: Just to make sure, ChrisL are you on for the first
topic? [silence]
astearns: Okay.
<astearns> https://lists.w3.org/Archives/Public/www-style/2016Apr/0352.html
Florian: There is a statement in the paged media spec, css page
spec, together with an issue saying it may be wrong that
MQ don't respond to the size of the page. That's very
unfortunate.
Florian: On the ML we agreed it would be good to have it work, but
we need to define what "it work" means. I can write a
proposal, but I want a sense of what we're trying to
achieve.
Florian: There's two levels of what to achieve. The first, which
is important, is if you have an unqualified @page rule
and inside you size the page, if you have a MQ query
against width or height it should take that into account.
Florian: Second level, less critical. Inside that MQ that has
adjusted based on the @page size, can you adjust the page
again? How many levels do we go after. An interesting
thing we can try and do is you query for @media maxwidth
= 5inches and inside you do @page size=5 inches have a
boundary on how small the page can get.
Florian: Do we want to do that as well? Some level of nesting for
@page and @media? Or is that not important?
Rossen: Is there a use case?
Florian: In general, or level 2?
Rossen: The circular reference?
Florian: It's because we have to write a definition. In general
it's the same situation with @viewport. If you have a
responsive design that can shrink to a point and after a
point it would be too squished. Dealing with that case
seems as reasonable with printing
Rossen: Why should this be an exemption? This problem is nothing
new. At some point you have to resolve if the container or
content has preference on setting size. If you have a
container, a regular div, that changes in size and inside
of it you have a flexbox that wants to be as big as
possible, we have a mechanism to resolve by saying at the
end of the day the container will have the size it wants
and the content inside may take it into consideration or
not.
Rossen: In no case do we have the content dictating what the final
container size is.
Florian: Not quite. With @viewport you can have a MQ that says if
the screen gets smaller than a size then don't do it. We
have it on @viewport but it would be worth it on @page.
Rossen: Is there currently a use case to solve, or just going for
theoretical completeness? And if there is a use case
should it be different than other layout constraints.
Florian: I think we're just repeating...I'm not sure how to
rephrase. Let's do the queue.
glazou: To address the beginning question, I support the original
and the extra. It's implemented in the wild and people are
using it for @viewport so people will use it for print and
pages. So I'm in favor of both things.
<dbaron> I still don't understand how @page interacts with actual
sizes of paper...
MaRakow: I was going to say I understand what Florian is talking
about for @viewport, but even for that it's a confusing
set of logic. It would probably be easier to look at this
in a concrete form, a draft or examples. I'm familiar
with viewport, but I'm not sure about items unique to
@page.
Florian: I was kind of asking before I wrote so that I spent time
writing what the group wants. If I need to write so we
can develop consensus I can do that.
MaRakow: I think it's more obvious with viewport where there's one
viewport instead of multiple page sizes and the like.
Florian: What we've been saying is this only is non-qualified
@page which applies to all pages. If some pages have
different sizes, that doesn't count. MQ respond to the
unqualified page. If you change that size it should
respond. If you only change page 37 the MQ can't answer
to just that in any way I can think of.
Florian: Trying to answer Rossen. I'm not trying to be different.
I'm proposing same as @viewport.
Florian: The @viewport mechanism works both ways. Either you're a
typical mobile UI which by default sets constraints or
you can use it to add constraints to a viewport where you
can go up and down but don't go too small because my
layout can't handle that. I'm suggesting we carry that
over. It's not required, but nice to have. It vaguely
matches what Chrome has now.
<dbaron> FWIW, I'm a bit hesitant about the second half
<dbaron> though I don't feel like I really understand the issue
astearns: It sounds tome there's general agreement to have
something like @viewport for @page. So I think you
should write more details so we can argue over them.
Florian: Is it okay if I make a pull request and post about that
on the list?
<BradK> Page3 editors draft already allows @page inside @media
plinss: I'm not convinced it's the right way to go. It seems the
MQ should query the size it's being.
Florian: Most of the time you print to PDF and the size of the
page is the one you ask for. All MQ designed for screen
fail as soon as you print.
plinss: I'm not sure I get the second point. There's aspects of
how @viewport works that seem broken to me that I'd like
to fix. It's more than I can load into my head right now,
but we can talk offline. Solving the PDF would be better
from a new mechanism to say your desired page size.
Florian: But @page with size says the size of the page you want.
fantasai: It is the syntax designed. It's unfortunate. We didn't
sort out how to handle if your parent has three sizes
how to you express a preference.
Florian: I can make a proposal based off of what we have discussed
and we can re-discuss after that.
astearns: Please add the PDF case and any other use case you're
solving to what you propose.
Florian: Sure.
ACTION Florian write a proposal for @page with use cases
<trackbot> Created ACTION-767
astearns: Next topic is "Bug in nested counter scopes" and
TabAtkins is not here.
astearns: Anyone else have an opinion?
astearns: Or do we table for now?
ChrisL: I'm here now.
astearns: We decided to do color next week because smfr dropped
and Ric is coming next week. So maybe Wednesday next week.
ChrisL: And that's more MQ color than CSS4 Color?
astearns: Yes. MQ and spec higher gamut colors.
propdef tables for shorthands
=============================
<astearns> https://lists.w3.org/Archives/Public/www-style/2016May/0007.html
fantasai: Basically I was going through some specs where we're
using shorthand and we have a convention of seeing the
property to get the shorthand. In a lot of cases they
have a lot of the same information. I thought it would
be nice to put that info in the propdef table. That
would be useful as we encourage people to use the
shorthands more. scroll-snap-padding and the like where
we add more longhands to deal with physical and logical
differences.
fantasai: For one spec we deferred longhands to an appendix and
put the shorthands at the top.
astearns: So the proposal is only when things can be a single
value?
fantasai: Yes.
dbaron: I think this is mostly okay as long as whatever defines
the concepts in the propdef tables says if a shorthand
defines one of these and disagrees with a longhand that's
an error in the spec. If we have something explicit where
if a spec does that there's a mistake.
fantasai: I'm down with that. I'm not sure where we have something
that defines the propdef tables, but I'm fine with it.
Florian: I'm not sure on which side of the error we should do. If
it contradicts itself there's an error. I'm not sure if
we should say it's on the shorthand or longhand.
fantasai: I agree. It's not clear which is correct, there's an
error that needs to be fixed.
<leaverou> I wonder if these could be marked up as shorthands and
bikeshed would automatically generate the right propdef
tables
astearns: Anyone opposed to this convention?
Florian: One question: is this going forward or do we rework
existing?
fantasai: Going forward and as people update specs we should
update. We don't have to go back and fix everything
actively.
Florian: That makes sense to me. And encouraging people to use
things right is a good point for me.
Florian: Getting people's attention where it should be sounds like
a good idea.
<jensimmons> +1 — anything that makes the specs more usable for
general authors is :)
RESOLVED: adopt the proposed convention for propdef tables for
shorthands
Scroll-Snap
===========
Rename keywords 'proximity' and 'mandatory'
-------------------------------------------
<astearns> https://lists.w3.org/Archives/Public/www-style/2016May/0006.html
fantasai: Someone, I think astearns raised this issue being that
they're grammatically inconsistent. No one had a good
proposal, but we do have something that takes 'strict'
and 'loose'
MaRakow: My main concern is that they're less indicative of what
they do. near and always gave more indication of what
they're trying to do. I feel lukewarm on everything
proposed, but those are easier to spell.
leaverou: 'Strict' and 'loose' are not self-evident to me. I agree
we need to resolve the grammar.
* glazou agrees with Lea
??: I agree
Florian: They're long words, but they work. I'm okay with 'strict'
and 'loose', but I'm not sure they're better.
astearns: Sounds like we need to keep searching for terms. I agree
none of the proposals are right.
Snap alignment container (concept name)
---------------------------------------
<astearns> https://lists.w3.org/Archives/Public/www-style/2016May/0000.html
fantasai: There have been a handful of options. 'scroll snap port'
and 'snap window' came on the list. This is the area of
the viewport that we're snapping boxes into. It's the
viewport scroll snap padding.
MaRakow: I like 'snap box' a lot.
astearns: I'm not that happy with 'snap box' because it's a
category error. When I think of snapping boxes I'm
thinking of the page layout, not the window in which
viewing the content.
Rossen: What do you mean by window? a div with a scrollbar?
fantasai: There's the area representing the box and the area
representing region of the viewport. They're snapping
together. 'snap box' is too generic. It doesn't indicate
if it's the content or viewport part?
Rossen: So I have a bit with a scrollbar and something scrolling
inside? What's the viewport.
fantasai: Snap window is the scroller's viewport.
Rossen: So every view defines a viewport.
fantasai: Yes. I don't know what you want to call it, but the
scrollers viewport has the window.
Rossen: It's a box with a scrollbar on it and a bunch of boxes
moving beneath it.
fantasai: That needs a name. You can call it whatever, but for now
let's call it the scrollport. The part of the scrollport
being snapped to needs a name.
MaRakow: To clarify, on 'snap box' the way it's controlled and
adjusted is similar to margin box etc. I see you need to
distinguish scroller box vs contained elements. Maybe
there's something with meaning. I like usage of box
because it's similar to how you're controlling the box. I
like that idea.
Florian: If we call everything a box, box doesn't mean anything.
fantasai: A box is similar concept to an element, but we also use
margin box etc. It's overloaded and I don't want to
overload it more. It's a rectangle. You can't fragment
the box. So I think it would be better not to use box.
MaRakow: The language we've been using seems to have been aligning
boxes to boxes. It feels natural.
Florian: Everything in CSS is boxes, but we want a word not a
phrase.
leaverou: Window is overloaded from JS, so it's a minor objection,
as I'm not sure any authors will be confused due to JS.
Rossen: I had the same. Window has a meaning in many places.
Florian: Though I don't think we had consensus it's a great name,
every time we say 'scroll port' people know what it means.
I think it's stable so we can derive from it. 'scroll
snap point'. I'm not sure it's lovely, but it wouldn't be
confused so I'm for it.
astearns: It sounds like there are two options, one with port and
one with box. Or can we go with port.
leaverou: What's wrong with 'snap container'?
fantasai: Container tends to be a box in a more structured thing.
I would consider it to be the scrolling element itself.
In our version we used 'scroll snap container' to refer
to the scroll container capturing snap point.
fantasai: It's a rectangle within that. It has a thing and needs
padding.
leaverou: I think I misunderstood. Isn't the scroll container also
the thing trying to define?
fantasai: We need a bunch of names.
<MaRakow> https://drafts.csswg.org/css-snappoints/#definitions
<fantasai> a) Need a name for a box that has a scrollbar
leaverou: THat's a scroll container.
<MaRakow> scroll container +1
fantasai: That or 'scrollable box'. I'm happy with either, but
lets start with that. A div with overflow that's not
visible, what's that thing.
leaverou: scroll container.
RESOLVED: A div with overflow that's not visible is a 'scroll
container'
fantasai: Yep. We need to get overflow in sync with this.
fantasai: Next concept. The viewport of the scroll container.
<fantasai> e.g. @viewport doesn't apply to the scroll container
(unless it's the root element)
leaverou: right...
Florian: scroll-port
MaRakow: I think it's viewport
Florian: Earlier Rossen said this is a thing with nothing special.
Viewport has special characteristics. I'm not happy with
overloading it. It may be we at some point make them able
to do the same things, but not now. So, 'scroll port'.
<jensimmons> IMO, I would not call it a viewport. That’s already a
complex concept that people struggle to understand.
MaRakow: It sounds bad, though. viewport is familiar.
fantasai: @viewport and meta rule don't apply to this. It does
make sense that they're distinct.
fantasai: So I think it makes sense to have a separate term.
Rossen: I think it's clear what leaverou and jensimmons think. I
see jensimmons opposes viewport name. It would be great to
hear from the devs.
leaverou: I can see reasons...
<jensimmons> scrollport or snaport would hint to people — “hey
it’s kinda similar, but not. Check this out… it’s a *-
port…”
fantasai: We have the viewport units that reference the root
viewport. There are several things in CSS named after
the viewport that don't have any relation to these
scroll containers.
leaverou: I can see why we could do 'adjective viewport', but I
also agree it could be confusing. I'm not quite sure.
jensimmons: I don't have a lot to say because I'm trying to
understand snap-points, but viewport is a huge
important concept and I has a name. fooport indicates
similar without the same.
<BradK> +1 Jensimmons
leaverou: I'm not sure about inventing names. 'scroll port' hides
the view port so it doesn't sound similar.
ChrisL: The port thing in viewport means a type of port that has a
subregion. 'snap port' doesn't inherit from viewport. It's
in the snap area.
<jensimmons> +1 on that
Florian: We don't have many ports in CSS. If you get the port you
don't get confused.
leaverou: If we invent words in CSS it gets confusing like
fragmentainer.
<ChrisL> fragmentainer is an *awesome* neologism
<dauwhe> fragmentainer has been useful, I think
Florian: Fragmentainer isn't common, but it's clear.
<fantasai> "port - n. an opening in the side or other exterior
part of a ship for admitting air and light or for
taking on cargo. "
<BradK> The snapping area of a scroll port should be the snap port
astearns: So this is a word we're inventing for the spec. We're
inventing instead of a longer phrase through the spec.
leaverou: The words leak into tutorials.
ChrisL: That's better than overloading a word.
Florian: We invent words all the time. Like flexbox.
leaverou: Flexbox is a contraction of "flexible box" though.
ChrisL: In the same way style-space-sheet is a lot of things, but
stylesheet is a specific subclass of thing.
MaRakow: The viewport terminology, people are confused because we
have too ambiguated a definition. We have talked about
splitting layout and visual viewport and when we get to
that it's clear this is the visual viewport.
MaRakow: I think if we get that cleared up visual is the same as
what we're talking about where an element scrolling is
top-level scrolling.
leaverou: sub viewport?
Florian: I think this is a scroll port.
fantasai: We're on b.
<fantasai> b) the viewport of the scroll container
<fantasai> b.1 - scrollport
<fantasai> b.2 - visual viewport of the scroll container
fantasai: Proposals on the table ^
fantasai: And we will get to c.
<fantasai> c) the snapping area of the viewport of the scroll
container (i.e. viewport minus scroll-snap-padding)
<BradK> Isn't scrollport already in common use?
<MaRakow> @BradK no
* BradK Googled "CSS scrollport". 2,620 results.
<MaRakow> @BradK that's exactly how many times it's been said in
this conversation alone ;-)
leaverou: visual viewport of the scroll container is too long. It
could be scroll container viewport
fantasai: visual viewport
leaverou: Is there a not visual viewport?
Florian: Yes.
<Florian> SCROLL container visual viewPORT = SCROLLPORT
MaRakow: You don't have to say the whole name every time. You say
the visual viewport after the first time.
dbaron: In the original email in the agenda it is drawing a
distinction between the snapping thing and the scrolling
thing.
fantasai: Yes.
Florian: That's the c thing. We're on b.
Florian: We're trying to name the thing with an offset. The offset
is FROM something we also don't have a name for.
astearns: Is b or c more likely to leak out?
fantasai: I think they'll both be common. b isn't specific to
scroll snap spec. It'll be in overflow and other specs;
probably transforms.
fantasai: There's a number of things that are distinct between top
level viewport effected by @viewport rules. They don't
apply to these scroll ports. We'll want to use these
terms to define differences. So it'll definitely be in
scroll snap and overflow.
fantasai: C is only for scroll snap.
<jensimmons> I suggest figuring them out together. They’ll work
together in people’s understanding.
<jensimmons> A: scroll container. B: scrollport. C: snapport.
astearns: I propose we go with what jensimmons put in IRC. If c is
specific to snapping it's a snap point.
Florian: I'm with jensimmons
<Florian> b : SCROLL container visual viewPORT = SCROLLPORT
<Florian> c : SNAP area of the scroll container visual viewPORT =
SNAPPORT
???: Me too
<dauwhe> +1 to jensimmons
fantasai: I'm with jensimmons
<BradK> +1 Jensimmons
<dbaron> What's the difference between A and B?
astearns: Anyone object?
<ChrisL> +1
<leaverou> +1, they do work well together
BradK: Do we use hyphens?
fantasai: I would go with no.
fantasai: A is the css box that has overflow other than visible.
fantasai: B is the viewport of the scroll container.
dbaron: Okay.
astearns: So dbaron are you okay with this term?
dbaron: Is A a box?
fantasai: Yes.
Florian: Is it an element?
fantasai: It's a box in the same way a flex container is a box and
a fragment container is a box.
fantasai: It's good to maintain the invariant that a container is
a box.
<leaverou> Although I'm convinced about scrollport/snappport now,
note that even fantasai described it as "the viewport
area of the scroll container" right now to get whoever
asked to understand.
Florian: How is it not an element?
Rossen: Elements make boxes.
fantasai: I'll sent a link.
<fantasai> https://www.w3.org/TR/css-display-3/#intro
Florian: I'm just not sure why it's one or the other.
Rossen: Elements aren't visual, boxes are.
dbaron: A is a box and B and C are rectangles.
fantasai: Yes.
dbaron: Okay.
astearns: Objections to A: scroll container. B: scrollport. C:
snapport.
RESOLVED: B: scrollport. C: snapport.
<fantasai> Yay!
astearns: There was one item that Rego wanted to talk about, but I
don't think we have time.
fantasai: We need to do that one at the F2F.
astearns: I was going to suggest it for the F2F agenda.
astearns: Anything else anyone wants to bring up?
TPAC
====
Rossen: Quick one on TPAC. I know dbaron and Florian are on call.
Please look at proposed time and date for Houdini and make
sure it's okay with you before we settle the arrangements.
Florian: What's the link?
Rossen: I'll dig it up, it's in the Houdini ML. It' a reply to
your e-mail.
Bert: Isn't it too late to decide dates? I think the schedule and
room is published.
Rossen: I just received an e-mail that I was hoping we weren't too
late.
ChrisL: The date was the 15th. That was if we're meeting or not.
There's no room allocations.
Florian: Most likely I won't be able to avoid some conflicts.
Schedule it and I'll attend what I can.
astearns: Please do keep adding things to the agenda. I think
that's it for the call. Thanks everyone!
Received on Wednesday, 4 May 2016 23:47:25 UTC