- From: Dael Jackson <daelcss@gmail.com>
- Date: Fri, 11 Sep 2015 14:32:00 -0400
- To: www-style@w3.org
Round Display
-------------
- The representatives from LG presented their work on round
display, including several demos of test cases.
- The group thought the progress was good and the use cases
compelling, though there was in expressed desire to have the
spec written to apply more widely instead of focusing only on
round displays.
- Some pieces of the spec may ultimately belong in other existing
specs, but for now they will be worked on here until they
stabilize.
- There were several issues to resolve, some editorial and some
conceptual.
- RESOLVED: Pending notation of any open issues in the draft,
publish FPWD of CSS Round Display
- RESOLVED: Add Hyojin as an editor to round display, move Soonbo
Han to former editor
Grid Layout
-----------
- RESOLVED: switch row-gap/column-gap to grid-column-gap and
grid-row-gap and maintain grid-gap as the shorthand name.
- It is possible that they will be named grid-gap-rows
grid-gap-columns instead depending on the results of
polling.
- RESOLVED: stretch stretches auto-sized tracks only
- RESOLVED: Add repeat(auto-fill) and repeat(auto-fit)
- RESOLVED: Publish grid WD after the above edits
===== FULL MINUTES BELOW ======
Present:
Rachel Andrew
Rossen Atanassov
Tab Atkins
David Baron
Brian Birtles
Bert Bos
Tantek Çelik
Dave Cramer
John Daggett(phone)
Elika Etemad
Jihye Hong
Dael Jackson
Dean Jackson
Ian Kilpatrick
Chris Lilley
Peter Linss
Edward O'Connor
Simon Pieters
Liam Quin
Matt Rakow
Florian Rivoal
Andrey Rybka
Hiroshi Sakakibara
Simon Sapin
Hyojin Song
Elliott Sprehn
Alan Stearns
Shane Stephens
Lea Verou
Sam Weinig
Greg Whitworth
Johannes Wilm
Steve Zilles
Regrets:
Daniel Glazman
Anton Prowse
agenda: https://wiki.csswg.org/planning/paris-2015#agenda
scribe: dael
Round Display
=============
plinss: Let's get started
<hyojin> CSS Round Display - Demo, Issues, FPWD Spec:
https://drafts.csswg.org/css-round-display
<hyojin> Polyfill:
https://github.com/anawhj/jRound
hyojin: I'm Hyojin Song and this is CSS Round Display.
hyojin: There are several interested parties. We use Web OS, so
all applications running on the device are web apps.
hyojin: We believe that round display will be generally useful
features.
<astearns> new properties are device-radius, shape-inside,
border-boundary, and polar
<Bert> -> https://crosswalk-project.org/ Crosswalk Project
Joone: I work with Chromium Dev.
Joone: During the last couple months we have been implementing
round display. It's based on chromium and allows developers
to work with web technology. The web API and native
intention fills the gap between web and native.
Joone: We support round display to allow developers to support
round across platforms including watch devices. Round
display would let them support watch devices with web tech.
Joone: Also, being able to surf the web with watches may become
common in the future. People spend more time browsing the
web on mobile devices.
Joone: We implemented device-radius with a boundary and there were
issues. It only provides information on if the screen is
round, there is not more detail such as the device-radius
in the spec. There was no way to know the radius, I think
there should be more information on this including the
radius.
Joone: The other issue is border boundary. When you surf you may
get a scrolling border. I think the web engine should not
code web pages so the border boundary is supported. Jihye
will show a demo.
<fantasai> The first example showed a weather app, with a blue sky
background and a white band containing information
about the weather.
<fantasai> In square displays the white band was a box, smaller
than the width of the screen, floating over the blue sky.
Additional UI elements are positioned in the top corners.
<fantasai> In the round display UI elements in the top corners
were moved to the center, and the box was turned into a
band across 2/3 of the screen.
Jihye: We made a simple web app with a device using round
properties. As you can see in round display the alignment
of elements is specified to the round display.
Jihye: It is possible because the app recognizes the shape of the
device. Without the device properties and when we implement
only considering the web and rectangular devices, some part
of the display will be concealed from round display.
Jihye: This example shows how the property works. The border is
painted around the edge of devices.
Jihye: I will show some example using Garnet.
<fantasai> The example showed a round timepicker with a digital
clock across the top third of the screen, X and check
buttons across the bottom third, and hour/minute
numbers around the clock face.
Jihye: This example shows the sample of garnet the web app
framework that is used in other digiwatch which is using
web OS platform. With this example you can choose the time
from the number elements located around the round display.
Jihye: Not only in these examples, there are so many use cases in
which elements are laid out like this one. Developers have
to consider the center points and radius of the display as
well as a radial variable.
Jihye: Described using our method, the elements can be located
easily using polar position, angle, and distance.
<fantasai> This example is showing a scroll list, with each item
having an image on the lefthand, title and description
on the right.
<fantasai> There's a title at the top, which is sticky
<fantasai> The scrollbar is wrapped from the top of the circle to
the bottom, with a curved scroll tab
Jihye: This is another example to show the scrolling event in
round display. Different from the normal scrolling amounts,
this UI is similar to scroll event.
Jihye: When I'm using this, the scrolling is more comfortable and
faster than the normal method in the round display. In the
sample, coordinates are complicated. When the rounded
method is implemented in real devices, scrolling
performance is lagging. When we use polar distance and
angle you can get improvements in showing the scrolling and
elements.
Jihye: From the example just shown, I can show the properties
related with polar, but the scrolling on the display isn't
so different from general devices.
Jihye: I found this YouTube video about scrolling events in round
display. Elements are arranged constantly in round method.
<skk> This might be the demo video:
<skk> https://www.youtube.com/watch?v=PRWHJwHqHuM
Jihye: When developers want to do layout like this they have to
use CSS shape and the text elements located are calc in
real time. We are planning to expand round display to deal
with the scrolling event.
hyojin: That's the demo, the key point is it gives us radius and
boundary as a prototype. We think those things are useful
for authors.
hyojin: Next, I will check the status of round display now. It
could be bigger. We implemented the pictures. Would you
show the spec for round display?
<astearns> https://drafts.csswg.org/css-round-display/#device-radius-media-feature
hyojin: In terms of status, we would like to take round display
to FPWD
hyojin: Round display is used to make this seem very simple. We
would like a FPWD. I think to express the device display
sheet would be of use.
hyojin: Any other opinion about device-radius?
Florian: I think the general idea is about right. We could think
of very complicated MQ to be explicit, but overshooting
wouldn't be a good way of solving this. The level of
complexity you're exposing is approximately right. I
think there is a need for more details in the spec. It
doesn't say if the corner is an elliptic or cut corner.
Florian: I think the MQ as described now could work, it just needs
more details in the spec. I think we should try to flesh
it out. I think the device radius MQ is generally the
right approach.
Florian: It will work for elliptic displays if it uses device
radius instead of pixels. For cut corner, that's not the
goal of this, but we should be able to give some
reasonable semantics if the corner cuts less than the
rounded corner. We can use min and max to get that.
Florian: If we spec these details correctly, we can do that.
hyojin: We received comments from Florian about the device radius.
We should cover the remaining issues in device radius.
Florian: Has anybody else thought of a different way of fixing
this, or does this sound right?
gregwhitworth: I tried writing a response, but we're not in the
market. My response was that this is perfect for
the round display spec, but what if I want to do
polar distance on something that's not round. I'd
like to see it generalized. All the pieces are
necessary to accomplish this task. Just in general
generalize the pieces so that they can accomplish
more, make them generic. That gives you more power
down the road.
gregwhitworth: Definitely you're providing a good use case as you
showed in the demo. Such as polar distance, you can
use any shape. You can calc the center of any shape.
Florian: The details we need to look into, but I think it can work.
If you define 100% is the edge against the edge, if
you're 100% you're following the shape. There's details,
but we can work out the general.
fantasai: Should we pull the device radius MQ into the MQ spec?
Florian: I'm fine either way. I suggested it last time, but there
was a thought to keep the pieces together. It's a
question of who is working on it.
fantasai: I think we should eventually.
gregwhitworth: I think for all of them, position polar is a great
way of fleshing this out, well done. I think we
should be able to use it in a positioning spec,
though. I'd love to see them focus on not just the
use case of watches. Something more generic.
liam: gregwhitworth I think you made a good point because I think
we're going to find other shapes in the future. I think
there's a danger of trying to solve too general a case.
border-boundary/shape-inside: display
-------------------------------------
fantasai: For the border-boundary and shape-inside: display
values, what happens when you have these in an element
that scrolls?
hyojin: Scroll is difficult. We internally tested significantly to
use shape-inside. We had some differences to describe
scroll in shape-inside.
Florian: The scrolling problem isn't limited to shape-inside:
display.
fantasai: But what happens if you just scroll the outer document
and the position of the element changes?
TabAtkins: The way my watch does it is while you are wrapping to
the shape you can't scroll. If you tap you can scroll
and it turns into a rectangle shape.
TabAtkins: The idea I guess would be it maintains its shape based
on your initial scroll position? So if you do scroll
the doc you'd get a weird circular area moving up.
Bert: I see in the spec it creates an intersection of the circular
area so the shape changes as you scroll.
Florian: The text was re-wrapping as you scroll.
astearns: The content stayed with the same line breaks and it
moved with the shape.
plinss: I'm not sure the demo is complicated enough to show that.
TabAtkins: I'm reviewing the video and it's using padding.
gregwhitworth: They had something where the contact list was
scrolling.
TabAtkins: That was something magic and random.
gregwhitworth: You can see it's not wrapping on the video.
TabAtkins: That's a custom scroller.
astearns: It's probably wrapping to the widest point in the
display and moving around. There's other scrolling
strategies for rounded shapes. If you have the content
laid out for three items and you flick to scroll you can
scroll the entire thing away and get new items.
Florian: And there's a number of similar UIs to pagination.
astearns: That was one of the strategies we considered when we did
shape-inside.
fantasai: Would it make sense instead of having a switch that makes
individual elements match to the intersection of their
area and the watch face area, to be able to say this
element should have the same shape as the display, and
also to saythat an inner element matches its containing
block? Thenyou can have multiple divs the same shape as
the displayin the same document, and within those you
can instructthe contents to fit into that boundary (or
not).
astearns: Difference is knowing if the items inside will fit in a
readable size.
fantasai: That's what regions are for.
liam: It breaks the metaphor that you're moving, though. There's
quite a user issue.
Florian: In the spec for border-boundary there is a value to match
the display and to match the parent. We'll need something
similar for the shape itself.
astearns: Border-boundary has the parent value? It probably makes
sense for shape-inside to have it too.
TabAtkins: Do we have examples of border-boundary?
Florian: In the weather app example there was a faint border and
in the rectangular one there was border around the pieces
of text.
[The example is pulled up again]
Florian: See the thin line around, that's a border boundary
matched to a display.
Florian: If you know the screen is round you can use border
radius, but if you don't know that the screen is going to
be round fitting to the display is what you're trying to
do.
esprehn: The demo text seems to be carefully selected to fit.
Does text wrap at the edges?
Florian: That's the shape-inside part.
esprehn: In the blue box, if there was more text, does it wrap to
the round edge?
Florian: Yes.
Bert: There's note in the border part saying the text may overlap
the border or the other way around.
TabAtkins: We know shape inside works with heavy overflow.
hyojin: We can find use cases. We have some trouble to describe
specifically. How can we do what it is?
Publication
-----------
Florian: I think we need to go issue by issue. Doing a review of
the entire spec in one go is something people won't have
time to. I think we need to find one issue, fix it, and
move to the next one. And we'll get there.
gregwhitworth: He did ask for a WD, though.
fantasai: If we're working on it, we should note the issues and
publish.
Florian: Is there any new issues you might want to add?
hyojin: We were planning to do scrolling, but we couldn't do that
for now. These ideas are enough to be a FPWD.
Florian: As we mentioned yesterday, it's good to have the entire
scope of the spec ready of intellectual property reasons.
If you want to add one more thing we should add it before
going to FPWD.
hyojin: It's okay to cover the whole idea.
Florian: If you're happy to go with this the content is
interesting.
Bert: There will be other opportunities to mention things. The
intellectual property will be gone over again with CR.
Florian: The time in between would be long.
hyojin: Would it be possible to do the WD?
dbaron: I think it would be good to get issues noted in the draft.
hyojin: The issues from last time, we modified the spec. We can
get all these things, but we think it's enough to
implement.
Florian: We don't have to resolve everything, just writing in the
spec there is an issue when we don't have the solution is
worthwhile.
hyojin: We can do that.
RESOLVED: Pending notation of any open issues in the draft,
publish FPWD of CSS Round Display
border-boundary/shape-inside: display (cont.)
---------------------------------------------
Bert: Are we continuing this, or are we discussing more?
Bert: I have 2 or 3 more details.
Bert: About shape-inside, I was wondering if another definition
might be useful. The shape-inside: display results in a
shape that is the overlap of the actual viewport is the
currenttext. What if I want to use that shape not on screen
and move it in?
Bert: So I want to make an element with that shape elsewhere and I
want to move it in, not overlapping with the actual position
of viewport.
Florian: That would relate to the scrolling question earlier. You
have to be careful to align when you do that.
Bert: So reusing the shape, but independent of its position.
plinss: How do you compute the intersection?
Florian: You just do the same shape, you don't intersect. Just the
same round of the screen.
plinss: But if it's not the same shape?
Florian: Same shape and size. That's tricky. If you have a square
and a circle that fits, that's fine, but if you have a
rectangle the same circle could fit, but there's a
difference.
Bert: I could set top and left to 0 and it would align.
Bert: That was my first thought when I saw the overlap.
Polar Positioning
-----------------
<dbaron> I think the polar positioning parts are quite
underspecified, and I also don't understand why
position:polar goes on the parent of the element being
positioned -- but I thought we discussed that last time
we discussed this spec.
Bert: Polar position. I think gregwhitworth mentioned it also.
This might be useful independent of fixed positioning. You
might have any object and just add some angular position to
that. That made me think the polar keyword shouldn't be on
the position property.
Bert: Should it maybe be somewhere so I can have abspos or
relatively positioned that use polar.
Florian: So you want a relative polar that's relative to whatever.
Bert: So I set a relative position and I use polar to move it.
Maybe just make the polar coordinate property active all the
time, they're just 0 by default.
<MaRakow> +1 to that
plinss: So left is 50px and polar is 30 deg.
Bert: That leads me to #3, we have a property for motion path
which solves that.
Bert: You would have the same effect with angular coordinates.
Florian: To answer plinss's previous comment, you do positioning
ignoring polar and from there you move in a polar way.
plinss: So transform.
Florian: Basically, yeah.
Bert: I think motion path and angular can move in the same way.
Florian: If the motion path is not a circle?
Bert: Rounded corners, I don't know if there's a motion path.
Florian: I think we can do this to follow the edge without even
knowing what the shape is.
Florian: If you go into a jewelry store there are varied watch
faces.
Bert: I was trying to avoid redundant properties, but alright.
Bert: Have you looked at transform and motion path for different
way to do it?
<Bert> http://www.w3.org/TR/motion-1/#propdef-motion-path
fantasai: Note that motion-path has nothing to do with moving
things...
Bert: It's a way of translating an object.
dbaron: So Bert was suggesting the polar stuff be relative to
where ever it was. That seems to introduce more work for
the author because they need to center it first and then
move. Starting in the center is more useful.
Bert: Using position fixed, that would default.
dbaron: No, you wouldn't get that.
dbaron: It would be good to have an issue before you publish.
plinss: The percentage value on polar angle doesn't make sense. So
50% is 180deg, yeah?
TabAtkins: Polar angle is wrong.
fantasai: It also puts lengths for angles. There's some copy/paste
issue.
fantasai: There's no angle value for the polar angle.
fantasai: Did that make sense?
hyojin: Yes.
gregwhitworth: Do we want to action the issue before FPWD?
Florian: The issues are in the minutes.
fantasai: It would be easier to find.
<fantasai> ACTION hyojin Fix Value line of polar-angle propdef
<trackbot> Created ACTION-706
<fantasai> ACTION hyojin Fix Percentages line of polar-angle
propdef
<trackbot> Created ACTION-707
<fantasai> ACTION hyojin Remove "For" line from polar-angle propdef
<trackbot> Created ACTION-708
<fantasai> ACTION hyojin Make polar-angle animatable as an angle
<trackbot> Created ACTION-709
<fantasai> ACTION hyojin Make polar-distance animatable as an angle
<trackbot> Created ACTION-710
<Florian> ACTION hyojin to make position polar apply to the
element rather than the parent
<trackbot> Created ACTION-711
<fantasai> ACTION hyojin Make polar-distance percentages relative
to distance from center to edge of containing block (or
mark this as an issue) so that it works for non-
circular shapes as well
<trackbot> Created ACTION-712
<fantasai> ACTION hyojin Remove "for" line from polar-distance
propdef
<trackbot> Created ACTION-713
MaRakow: For figure 6, it seems to show it describing the center
area when you're doing position polar, is that something
that happens when you're using position polar?
TabAtkins: I think it's how position polar works, seems reasonable.
MaRakow: It would be good to specify.
TabAtkins: It would mean polar distance of 0 would be in the
center.
Bert: And fantasai mentioned that 100% put it against the edge,
not over.
TabAtkins: Unless you're perfectly circular, though...
Florian: I think we can spec it property, but it's impossible in
real world geometry to get it always right. But at least
when there is a correct, let's go there.
TabAtkins: The whole concept only works when you're perfectly
circular. If it's an ellipse, you don't want to move it
all the way to the side when you have this huge major
axis.
TabAtkins: The purpose of this is buttons and you know the height
because it's an image.
plinss: I accept that's common, but I don't think that's always
true.
Florian: You had the case before where it's not.
TabAtkins: It's too magical to have something hug the edge. If
you're rectangular, what do you do?
Florian: You do it so the outer border is a tangent to the edge.
If it's round you poke the corner at the edge.
fantasai: It may not want to be default, but as an author it
should be able to do it.
plinss: There should be a way, and maybe there should be a new
keyword. If 100% does it with magic, that's scary. If you
have a rectangle you're moving in a circle, as I move it
around the center if I'm 10% off it'll be moving in this
odd flower shape. It should be achievable without
JavaScript, but it shouldn't be the default.
fantasai: That makes sense.
Florian: In general I think for when designing layout and
positioning, being robust to changes in the size and
shape of display is something we try to do. I also accept
plinss's point, so we need both.
TabAtkins: I'm okay with more complicated requiring JS to run.
TabAtkins: You're doing something that's fairly difficult. There's
no flow, it's just abspos. That's in general a fragile
method. If you want complexity you need JS.
Florian: Abspos is fragile about some things, but 0 is the edge.
It's easier for abspos, but you don't go off screen by
accident if you do 0.
fantasai: You could have a property that says where the anchor
point is. Instead of always the center, choose which
point and have an auto that picks it the point like
bgposition does.
gregwhitworth: This sounds like motion path again. You get to pick
you anchor points and the default is in the center.
fantasai: You could have a polar-anchor. It would take a <position>
and an auto keyword which would do the thing you want.
In the cases where you want to position something
exactly this distance you pick the bottom left corner.
gregwhitworth: And the bounding box is a rectangle?
TabAtkins: Border-radius is.
tantek: Does anyone else have experience designing UI with polar
coordinates?
Florian: liam had rounded pages?
liam: Never with polar coordinates.
liam: It is worth thinking about if you start dealing with polar
coordinates, if you need trig in calc.
Florian: Then you have to understand trig to use CSS.
liam: You have to in order to use polar coordinates.
liam: You work with non-rectangular if you do print work, but the
page doesn't scroll so you can fake it with a shape on the
outside.
hyojin: Soonbo Han is no longer working on this, so I would like
to become the editor.
hyojin: Would it be possible to change?
Florian: If the person who was working on this no longer is, that
makes sense.
TabAtkins: That should be fine.
fantasai: So, mark as an issue, potentially add an anchor property.
fantasai: Is that a reasonable issue?
Florian: Sounds reasonable to me.
<fantasai> ACTION hyojin Add issue about positioning items to the
edge of the containing block without overflowing it;
potentially solved by polar-anchor: <position> | auto
<trackbot> Created ACTION-714
RESOLVED: Add hyojin as an editor to round display, move Soonbo
Han to former editor
fantasai: The top item should go to MQ, shape inside goes to
shapes, polar coordinates into positioning. Border
contain into borders 4. borders 4 is shaky right now.
Positioning needs a lot of work.
Florian: MQ is getting stable. There's a few area that are not
quite there.
fantasai: AS MQ approaches CR, we should pull in device-radius.
Florian: Keep it together for now, pull out as these other specs
stabilize.
plinss: Ready to move on?
Grid Layout
===========
grid-gap-row vs column-gap
--------------------------
<astearns> https://drafts.csswg.org/css-grid/#issue-bbfb3743
fantasai: We had the argument on margins and padding yesterday.
fantasai: We have an issue on row-gap and column-gap and
potentially using grid-row-gap instead of reusing the
multicol column-gap property.
fantasai: We don't have to worry about the normal value which is
good. Also if we're using grid layout to go over a
multi-col we would have a conflict between the two
properties which I can imagine us doing if we started
working on a snap-to-grid modle. If we do that we'd
have a conflict with the properties.
Rossen: Do you recall the reason we converged on reusing the gap
property?
fantasai: Because it was there and why not reuse it?
TabAtkins: I suspect it's better to switch to grid-specific.
Rossen: I'm not opposed if there's a necessity.
fantasai: I'm not sure we'll run into it, but it's possible.
fantasai: Knowing if we'll run into this issue requires writing
the entire snap-to-grid module, and that's far in the
future.
Rossen: If you insist to add it as a preventative measure, we
could.
Florian: Is that the topic at NY where we decided to share?
fantasai: We discussed adding the properties. We had a resolution
to add them. We had row-gap for multi-col and why not
reuse that. But I thought we might use grid-template-*
with grid-to-snap. That was an issue where I thought
we might run into this as a conflict. It might be a
problem, or it might not.
fantasai: Anybody else have a comment?
plinss: It's probably good to separate them to grid-column-gap and
grid-row-gap. You don't want grid-gap to reset multi-col
gap, do you?
fantasai: It does now. I don't want it to. It doesn't make too
much of a difference.
rachelandrew: The advantage of grid spec is if it acts the same as
multi-col, they'll expect it to behave the same in
the future so if there's any change the different
name will keep people from expecting the same
behavior.
fantasai: Arguments not in favor?
fantasai: Might as well do that then.
RESOLVED: switch row-gap/column-gap to grid-column-gap and
grid-row-gap and maintain grid-gap as the shorthand name.
plinss: Would it be better for grid-gap-column/-row?
TabAtkins: We don't have a strong tendency on the current names.
They have row or column at the end, but they are all
grids and columns.
TabAtkins: I'd be fine either way.
fantasai: I think leaverou prefers matching the short hand
conventions.
<leaverou> re:shorthand conventions, that ship has sailed
<leaverou> but yeah, consistency is good
TabAtkins: Do you want to say grid-gap-rows/-columns
fantasai: Do we plural in any others?
TabAtkins: Yes.
fantasai: Then yeah, they should be plural.
fantasai: Let's be consistent as much as possible.
hober: It sounds more like the gap in the rows.
esprehn: I think grid-row-gap sounds better.
TabAtkins: Two choices grid-row-gap and grid-gap-row
TabAtkins: Why don't we just poll authors?
TabAtkins: This is easy to poll for.
<leaverou> I can poll authors pretty quickly and have results today
TabAtkins: If everybody is okay, we'll set up a poll.
fantasai: leaverou said she'll set up a poll.
<rachelandrew> i've got a lot of people on my list re layout stuff
so I can share any naming poll with that group
plinss: To throw another wrench, maybe use gutter instead of gap?
fantasai: But we have column-gap and want to be consistent.
plinss: But you call them gutterse
fantasai: I do that in the letter-spacing section, too: I use
"Tracking" as a title so people searching for either
term in the table of contents would find what they're
looking for.
plinss: It's just a suggestion.
TabAtkins: grid-gutter-rows does work.
hober: You're describing the gutter not the gap.
dbaron: The way you described it make it sound like they count as
rows.
TabAtkins: You have gutter rows and regular rows and for layout
they're both rows.
TabAtkins: You have to use row or column in there somewhere.
TabAtkins: We'll figure this out.
stretch keyword
---------------
TabAtkins: I think next set is the repeat stuff, or there another?
<astearns> https://drafts.csswg.org/css-grid/#issue-db68a1c3
fantasai: Let me grab issue 10. There's a stretch keyword for the
alignment properties. We have align-content and
justify-content, which operate on the grid tracks. You
can align to either side, or center, or distribute space
just like in flexbox.
fantasai: You can also use stretch which appears in flexbox. It
only stretches tracks that are auto sized. Alternate
pption would be to stretch all the tracks. I wanted to
know opinions.
Rossen: Stretching tracks that are fixed. If anything we can add
an anonymous column that could be stretched. I wouldn't be
in favor of stretching.
plinss: If people do tile images and they stretch, it'll break.
RESOLVED: stretch stretches auto-sized tracks only
auto-filling
------------
fantasai: Last issue is the auto-filling.
TabAtkins: Issue 5/6 in the draft.
[they head to the whiteboard]
<astearns> http://www.w3.org/TR/2015/WD-css-grid-1-20150806/#repeat-auto
<rachelandrew> something like this demo (which works in Blink with
exp. web platform features flag on)
http://codepen.io/rachelandrew/pen/ZGgZpB/
fantasai: The general issue is there's a common use case people
want to solve. You have some arbitrary set of items and
want to arrange them into a grid. Say I have 7 items and
I want to have them in a tiled layout. People are trying
to do this with flexbox and if you don't have exactly
enough to fill up the last line, they don't line up into
a grid.
fantasai: Let's say I have 450px and I have 7 items that are
100px, I would have 4 columns and 3 rows;
there's an extra 50 px and I'd say please stretch to
take up that extra bit of space.
fantasai: If you do that with flex you'll get an awkwardly sized
bottom row. That's fine for flexbox, it's not supposed
to be a grid. However, that's the goal for the grid spec.
This is a common need. The problem we have right now is
that grid-template-rows/columns require you to know how
many rows/columns you have in the main dimension.
fantasai: Sizing depends on placement, which depends on knowing
the number of tracks in at least one dimension.
fantasai: We have a repeat() function, but it takes a fixed number.
So we were thinking lets do an auto keyword so that it
repeats as necessary to fill the container.
fantasai: However, there were two cases that authors wanted.
fantasai: Let's say my viewport is x big and I only have two items.
What that will do, the repeat syntax was repeat(auto,
100px) and it will fill with the number of columns that
would fit.
fantasai: Sometimes the author might want the fallback to do
something different like center them. That wouldn't
work now because we have four columns, two of which are
empty, but still take up space.
fantasai: So one idea we had was have two different keywords:
auto-fit and auto-fill. Auto-fill would do as we
described: fill the container with as many repetitions
as necessary. Auto-fit would do that, but then after
placement would drop all the empty columns.
fantasai: There's a limitation on this syntax, this is pre-layout
so we have to put a fixed size. We can't say start
putting content in and that's how wide it should be.
That is a common use case, and you might not want to be
explicit, but we don't want to do a full pass to find
the size of the items before we start placing them.
TabAtkins: The repeat(auto) syntaxes, you'd have a second fixed
grammar that only had lengths and percentages. You also
could only have one repeat(auto) function as well.
fantasai: That's the best solution we've come up with. We think
this is an important use case.
TabAtkins: Like catalogs where they want to lay things out, they
know what size, but they don't know how many things
there will be.
fantasai: So that's the best solution we've come up with, we're
looking for comments and if you have anything better to
add. Like we could add a size of the first item keyword.
TabAtkins: Um, no, I don't like it.
fantasai: It would work for most cases.
TabAtkins: If everything is going to be the same size, that's when
you would know the size up front anyway.
fantasai: Okay.
fantasai: Thoughts from the WG?
Rossen: Good.
fantasai: Anybody else?
gregwhitworth: Seems good.
Florian: The use case makes sense, but for the solution I'm too
far out of my comfort zone.
TabAtkins: It may not be optimal, but it does the job.
fantasai: Resolve to add it?
rachelandrew: I spent a lot of time thinking it through, I can't
think of a better way to describe it. It's
complicated, but it makes sense.
TabAtkins: We think we're iterating toward fixture with the spec.
RESOLVED: Add repeat(auto-fill) and repeat(auto-fit)
fantasai: That's pretty much it for design issues. There's a ton
of issues like add an example, this needs more pictures.
We're planning to make these last edits and we're done
and we need review to suss out more issues.
TabAtkins: We're feature complete and want to move it to bug fix
and eventual CR. We need review of stuff, there is an
issue or two in the layout algorithm that we'd like
review on.
fantasai: We'd like to publish a WD after these last edits are in.
That will be the last WD unless people raise issues,
which we encourage people to do.
TabAtkins: So, are people okay to resolve to publish after we do
the edits, or review after we edit before publish?
RESOLVED: Publish grid WD after the above edits
plinss: Okay for grid?
TabAtkins: That's it for grid.
<break=20min>
Received on Friday, 11 September 2015 18:32:58 UTC