- From: Dael Jackson <daelcss@gmail.com>
- Date: Fri, 13 Jun 2014 10:22:55 -0400
- To: www-style@w3.org
grid/subgrid
------------
- RESOLVED: Move subgrid to at risk for level 1 and add a
requirement for display-box: contents to be used with
grid and include examples.
position: sticky
----------------
- dbaron brought to the group some behavior inconsistencies
between implementations when using position: sticky and the
margin box and padding box are the same size.
- The group looked through dbaron's examples (available here:
https://bug915302.bugzilla.mozilla.org/attachment.cgi?id=8386943)
and agreed it was broken.
- Rossen will address the inconsistency in his continuing work on
the spec.
Acknowledgements
----------------
- Everyone thanks the TTA for being wonderful hosts!
==== FULL MINUTES BELOW ======
Full Agenda: http://wiki.csswg.org/planning/seoul-2014#agenda
ScribeNick: dael
grid/subgrid
------------
Rossen: A quick review
Rossen: Grid is awesome.
<astearns> [whiteboard drawing]
<fantasai> http://fantasai.inkedblade.net/style/discuss/subgrid-markup/
<fantasai> My position: If you can convince me that 80% of Web use
cases for grid layout can be handled without
compromising accessibility, I will retract my objection
to removing subgrid. Otherwise not.
Rossen: The thing we can do with grid is you have a division of
space and you have lines where you can size and have
adaptive layout.
Rossen: The one thing it doesn't give you is grouping.
Rossen: If you have items on the grid you want to group and
attach behavior, you can't.
Rossen: For example, a simple form with a button and an input
field for text. If you want to treat it as a group where
text spans two cells and the button is one, but I want
hover where the whole group is hovered, in order to deal
with that we go into subgrid territory.
Rossen: It behaves like a semi-transparent item in the level of
grid and the purpose is grouping.
Rossen: All the items in a subgrid are in the top-level grid,
but have this invisible element that lets us attach
behavior.
Rossen: For the past 1 or 2 years, one exercise we went though
was to take the initial grid spec with-in an app based
grid with cells and try and merge that with typography
based grid
Rossen: We did that. Everyone in the grid task force contributed
a lot.
Rossen: The spec is in fairly good shape to get to LC.
fantasai: I think it needs another round or two for the algorithm.
fantasai: But design-wise, it's good.
Rossen: As concepts, it's good.
Rossen: The one wrinkle is that implementing subgrid will be
fairly complex.
Rossen: The reason why is (and subgrids nest) so the entire
layout of subgrids boils down to the dependency of
subgrids, which can bring any element anywhere in a
subtree with a different amount of spanning on some
level as well as overflow.
Rossen: The current sampling makes me think Blink and Firefox
are close to implementing grid.
fantasai: Mozilla is nowhere near.
jet: It's been going around for a bit. Mats is working on it.
Rossen: But we want to push grid out as soon as we can. We want
to revise our un-prefixed version of grid for everything
except subgrid.
Rossen: I think subgrid as a functionality is needed. I propose
we move subgirid to level 2, allow level 1 to ship so
all implementors that are close to done can roll out at
the same time.
Rossen: And then work on subgrid as soon as we can.
Rossen: In the meantime, if we find out implementation of
subgrid is quicker, we might pull it back into level 1
before REC, but my initial prototyping suggests it will
have a significant implementation delay.
fantasai: My position is if we can cover 80% of common use cases
with existing spec without using subgrid or compromising
accessibility, I'm okay with this. But I'm not convinced.
I think we can cover 30%. There's common cases that will
be worse with using just grid.
fantasai: Those are cases for which grid is designed and I haven't
heard markup for an example that uses grid and isn't bad
markup.
Rossen: I can tell you almost, nearly all, HTML based windows
store apps use grid.
Rossen: They're accessible and are requesting subgrid as a
future, but almost all that content that will be on the
web will be fine without subgrid.
fantasai: App layouts seem to be simpler.
Rossen: I don't agree.
fantasai: I want a concrete example of something common with
proper markup and I haven't seen that.
dbaron: fantasai's concern is about people having to remove things
from markup.
TabAtkins: So anything doing a vaguely grid layout,
accessibility-wise it's fine. Right now they're deeply
nested, but for accessibility they're fine. There's a
decent number of use cases for in-page components that
are better solved by subgrid, but I want to solve page
layout right now.
* liam wants to see page layout solved too :-)
fantasai: So write an example an post to the mailing list.
TabAtkins: Look at any website.
fantasai: I did and said you'd have to remove these things
(section markup and ids) and add empty elements.
fantasai: I went to a grid layout framework's homepage and analyzed
their examples. I posted the link about that.
fantasai: I took that, figured out how to do the markup with grid
and subgrid and figured out that it's very different.
TabAtkins: This first example is fine if you don't remove sections.
fantasai: If you want the pictures to line up, you need to remove
the markup that collects around "here" [pointing] unless
you guarantee that the headers are the same number of
lines.
fantasai: So something where you have something that looks like a
grid, but doesn't rely on things being the same size. If
it's same size, why not use flex?
TabAtkins: You don't need subgrid until you're trying to style
with padding and border. You're taking each top level
piece and display-box works.
fantasai: Then we can put display-box: contents in the grid spec.
TabAtkins: That's silly.
fantasai: I agree.
fantasai: But I don't want to give a feature that authors
will be excited to use, but to use it they have to strip
out markup to use it. They'll continue to do that years
after we ship subgrid, because of habit and because of
backwards-compat with old versions of IE.
fantasai: Even if subgrid ships in 2 years, it'll suck for 10 years
because people will keep stripping it out.
TabAtkins: Given the pattern, worst case you need a div around
the pattern so that you can say auto-flow.
hober: I think the point stands is you have to take out the markup
for a complicated model.
fantasai: auto-flow only works in one direction.
fantasai: I'm not convinced this isn't harmful. I'm pretty sure
it's harmful. Unless you have examples that show me I'm
wrong, but you have not done that.
* dauwhe see footer at http://alistapart.com
TabAtkins: Most sites have a simple grid that's hard to do now and
can be addressed just fine with grid.
fantasai: And how many of the use cases is that?
TabAtkins: The plan is people will use grid forever.
fantasai: I don't want them in the habit to do harmful things to
use grid and keep using those habits.
TabAtkins: This is a short period of time.
fantasai: So we wait until subgrid is implemented, if it's only a
short period of time.
fantasai: It's not just about old tutorials sticking around, it's
about habits and compat. If you do it the old way it'll
work in old versions of IE.
hober: Probably you shouldn't add very attractive, desirable
features to use practically in the real world but that
require reduced markup quality.
TabAtkins: I say not in many or most cases and the markup quality
today is so terrible we're improving it anyway.
TabAtkins: We'd rather a flatter structure.
plinss: Does display-box: content solve most of the problems?
TabAtkins: Some.
plinss: Enough to alleviate your concerns?
fantasai: Yes, my concerns are about markup being actively ruined.
plinss: So is display-box being ready before subgrid a way to make
this work?
TabAtkins: So I can't promise, but it's likely going to be ready
before subgrid.
TabAtkins: We have something else calling for this feature.
plinss: Does this handle your concerns?
TabAtkins: I'm otherwise going to object to objections here.
fantasai: If that's implemented and shipped before or with grid
and we update the spec to have a nice tutorial to use
these together, than I think that will be acceptable.
plinss: Okay.
TabAtkins: Sounds fine to me.
Rossen: Jet, you're okay with that?
fantasai: I'm waiting for display-box: content; before I remove my
objection.
TabAtkins: The agreement was it shipping.
fantasai: Until that's happening, I'm not removing my objection.
dbaron: Would you be okay with something in the spec that says
implementors implementing grid are also expected to
implement display-box?
hober: That's a message to say that things should be in the order.
All the examples should have to use it in order to have the
affect you want.
TabAtkins: The examples today don't need it.
plinss: So phrase it in a way to say display-box: content is an
implementation requirement of grid.
dbaron: They're correct that the examples should have it as well.
clilley: Rossen does the app store has an accessibility review?
Any problems with grid?
rossen: Grid is a default that's used for authoring apps. In
order to submit it has to meet accessibility. I'm not
sure how it's assessed.
rossen: With the current grid, which we have without subgrid,
all these applications exist just fine.
clilley: Some data would be useful.
rossen: They're all new content. None are using the same
pattern as a website, though I wouldn't expect much
difference.
fantasai: If you're using it for labels and forms elements,
the markup required by grid is a jumble.
dbaron: The other point is that on the web we want the platform
made so people write accessible content as the default.
If you have a review state that means you have a different
situation.
dbaron: I think we almost had a compromise.
plinss: Proposed resolution is to move subgrid to level two and
add a requirement for display-box to be used with grid.
fantasai: I'd prefer a label for at risk.
astearns: How far along is the display-box implementation?
plinss: People said it's easier.
astearns: Is it implemented yet?
jet: I think it's almost landed.
plinss: So it's coming real soon.
fantasai: We should finish the Display draft, then. :)
RESOLVED: Move subgrid to at risk for level 1 and add a
requirement for display-box to be used with grid and
include examples.
fantasai: I'll make the edits
Rossen: I'll review them.
TabAtkins: And I'll go over them.
position: sticky
----------------
dbaron: This is a follow-up to an issue that hasn't been edited
into spec.
fantasai: (Can we turn the spec into a list of links into the
www-style archives?)
dbaron: There was a thread started that says it doesn't explain
the two boxes you need to use sticky
dbaron: My understanding of sticky is that you have something like
a header and you want to to scroll up with the content and
then stop for a period of time with the content where it's
the header and then scroll off when it's done being used.
dbaron: So it's fundamentally like position: relative except the
offset is changing dynamically.
dbaron: You can use any of the top/right/bottom/left properties.
dbaron: You have the boxes you care about. The scrollable box, the
element's containing block, and than you have the sticky
element itself.
* liam wonders if this is e.g. for a table header that remains
visible when you scroll a long table
<fantasai> yes
dbaron: For the sticky element we only care about the margin box
and for the scrollable area we care about the padding box.
dbaron: What happens if you set none of the offsets, nothing
interesting happens.
dbaron: If you set the offset to top: 20px, it's relative to the
outside box so it means you care about the edge that's
20px from the top of the scrollable area. So you prevent
this margin box from going above...
dbaron: So top: 20px says the top px of the sticky box won't go
above the container as long as the scrolling box doesn't
go above.
hober: So it implicitly controls two edges?
dbaron: It's two constraints. And the 2nd overrides the first.
dbaron: The point of the second is to have it scroll off. Even
though this isn't in the spec, we agree that this is how
it works.
dbaron: Where implementations don't agree is if the boxes are the
same size.
Rossen: Or some of the internal boxes are bigger.
dbaron: I want to discuss what if they're the same. The issue is
that the second constraint constrains relative to
something that's scrolling within the scrollable area.
hober: If they're the same you never hit the bottom.
dbaron: The problem is the scrollable box is sorta like two boxes:
The actual box and the scrollable area.
dbaron: There are three options for the second constraint where
the sticky element's containing block is its scrollable
container.
dbaron: I prefer 1) Throw out the second constraint.
dbaron: 2) make the scrollable constraint the area inside the
scrollable container.
dbaron: And that means most of the time the second constraint
doesn't happen either unless you're in an overflow case.
dbaron: Gecko does #1
dbaron: 3rd is Webkit's approach which is use the box that isn't
being scrolled. You have to write weird test cases to
trigger this.
dbaron: Webkit will force the sticky element into the box, even if
it's below it.
dbaron: If the sticky element is scrolled up above, it'll force it
down into the box. Which seems crazy.
dbaron: I think in this case where the two boxes are the same, the
purpose of the containing block constraint has disappeared.
[whiteboard]
dbaron: I've got a testcase link in which Gecko and Webkit disagree
<dbaron> https://bug915302.bugzilla.mozilla.org/attachment.cgi?id=8386943
dbaron: So the case...
dbaron: In Webkit, I was right the first time. If the box is way
below, Webkit will constrain it to the bottom and than
will scroll it up to the 20px margins until, I'm not
sure when.
Rossen: Can I add one more view?
Rossen: This is what I was going to add into the spec and it's
almost ready.
Rossen: Last I talked about this with Cory is the following:
Rossen: We have an element to which you'll be using position: sticky.
Rossen: You default to 0px, no matter what.
dbaron: They default to auto, not 0.
hober: For what it's worth, the Webkit test case is paying
attention to how I thought.
dbaron: [corrects hober's use of the example]
hober: Oh. That's evil.
dbaron: The other thing to notice is they have a bottom of 180px
that pushes them outside the containing block.
Rossen: So the terminology we used is the sticky position, which
is the position at which the box will get stuck. Also the
release position, which is the condition at which the box
gets put away.
hober: That you're using enormous values is what makes it apparent.
Rossen: So sticky position is by the scroller, release position
is triggered by containing block and an open question is
if the containing block is the same as the scroller, in
which case we need to define reasonable behavior.
dbaron: I was suggesting if they're the same, you throw away
and release.
Rossen: So it's stuck forever. That could be reasonable. If you
have a bunch of these they'd stick on each other. It
would be sucky if they're the same size, but a reasonable
compromise.
Rossen: The other problem is when sticky is above the trigger so
we have to either define so it's brought back or it
doesn't trigger.
dbaron: The other fun case is if you have both top and bottom or
left and right and figuring out who wins
Rossen: We can use the scroll direction as a preference so if
you're scrolling down we take preference of the top.
hober: Having the behavior depend on initial scroll direction is
weird. As an author trying to debug, not realizing it's
that you originally scrolled in a certain direction...
dbaron: I think he meant by which way you can scroll to overflow.
hober: I'm presuming you've scrolled a bit.
Rossen: Initially. When the scroller is at origin than you have a
direction.
hober: That does seem reasonable.
adenilson: I have all three browsers open and they're all doing
something weird.
dbaron: It's a weird testcase.
dbaron: We should try and fix this.
TabAtkins: We're no longer shipping sticky.
TabAtkins: It's in stable, but not in less stable versions.
dbaron: I think Chrome has sticky in its experimental web
platform, but Apple is shipping and we are.
TabAtkins: The more I think about it Webkit's behavior makes sense.
dbaron: It makes sense to pull to the opposite edge.
TabAtkins: It doesn't want to exit it's containing block.
hober: Which is undesirable in the weird case where they're
the same.
Rossen: Having section don't necessary mean...they can be
separated by headers.
hober: But they do stack.
TabAtkins: This is how I'd expect if the containing block is
the viewport.
Rossen: Or if the release is defined by interacting with another
sticky item.
hober: No, no.
dbaron: You can compute this locally and this is all data you want
to send to your compositor. What I don't like about
Webkit's approach is it's totally different information in
that one case.
dbaron: In every other case it's in the scrolling except in that
case where the release is a scrolling position.
fantasai: Sticky is relative to the nearest ancestor.
fantasai: It's sticky in both dimensions?
hober: Yes. In the axis you set and offset.
dbaron: top/bottom/left/right auto means not sticky.
hober: It's relatively positioned, but you haven't offset it from
it's original static position.
fantasai: Okay.
dbaron: In Firefox the green one is honoring the bottom 180 and
the orange one is honoring the top 180
dbaron: Green starts like that because that's bottom 180.
dbaron: There's no release constraint, just sticky.
TabAtkins: Whereas in ours this means sticky so it stays.
hober: So there's a release side where you're willing to release
but if you haven't hit that you should stick.
TabAtkins: Now that I can see it live, I can see it's a bug,
TabAtkins: I'm not sure...
TabAtkins: If I like it or not.
TabAtkins: If you say the green is bottom 180, top 0 it wouldn't
ever fall off.
dbaron: It's kinda an edge case and I just want the make the
implementation simpler and don't have to worry about a
release that's outside the box.
TabAtkins: I'm assuming this is because it's easier, but I'm
not sure.
hober: I think Simon thought through a lot of edge cases.
TabAtkins: I'm not opposed to changing.
dbaron: I think we're done this topic.
TabAtkins: How is editing position?
Rossen: It's going.
TabAtkins: You have a plan?
Rossen: Yeah.
Rossen: I have most of this edits done, I have to clean it up.
TabAtkins: Can we define static position in your draft?
Rossen: Fine with me. We need it for flex and grid.
plinss: We haven't published a WD in 2 years.
Rossen: As soon as I have the edit I'll ask for a new WD.
Acknowledgements
----------------
glazou: A few minutes ago I e-mailed TTA to thank them for hosting.
I think the walking distance hotel was very convenient and
they were incredibly helpful.
<liam> [I would like to thank Daniel for the audio webinar
facility]
glazou: I'd also like to thank dwim for all the help he gave us
<glazou> Thanks dael!
[Meeting adjourned]
Received on Friday, 13 June 2014 14:23:23 UTC