- From: Dael Jackson <daelcss@gmail.com>
- Date: Fri, 4 Sep 2015 17:22:23 -0400
- To: www-style@w3.org
Flexbox
-------
- RESOLVED: Don't include flex-basis in intrinsic size calculations
because that most closely matches existing behavior
- Issue #3 (Can percentages resolve given min-size: auto?) will be
resolved by getting a few implementors to talk together and
determine which solution they're converging toward.
- RESOLVED: Just blockify the children of flex and grid containers.
Don't do anonymous box fix-up. (issue #6)
Grid/Flex Percentages
---------------------
- The group tried to work through how vertical percentage margins
and paddings are defined.
- Note: Top and bottom margins in CSS have traditionally
resolved against the containing block width instead of its
height, which has some useful effects but is generally
surprising. Existing layout modes must of course continue
to do so.
- Previous group resolution had been for option 2 (below), but
Google felt they had new information regarding abspos
behavior that merited reconsideration.
- The discussion came down to three potential solutions:
- Option 1: Always resolve percents against the width.
- Option 2: Grid and flex resolve against height, and
abspos items always resolve against the width.
- Option 3: Grid and flex, including their abspos items,
resolve against the height. Abspos elsewhere
continue to resolve against the width.
- In a straw poll the group was pretty evenly divided between
options 1 and 3.
- Microsoft would object to option 1 and Google to option 3,
so the discussion reached an impasse and will be continued
privately during the F2F in hopes of reaching a conclusion.
Testing
-------
- RESOLVED: Down-level tests (e.g. CSS2.1 color tests) should be
updated to not fail on higher-level implementations
(e.g. CSS4 color implementations), but should also
leave the old pass conditions intact so that down-
level clients can still pass the tests for the older
featureset.
- It was noted that CSS reftests have a "match at least one of
these references" feature, so this can be accommodated by
linking two correct-rendering references instead of just one.
===== FULL MINUTES BELOW =======
scribe: dael
Flexbox
=======
fantasai: Let me pull up the DoC
<fantasai> https://drafts.csswg.org/css-flexbox/issues-lc-20150514
fantasai: Okay. It's a long issues list since I updated it.
fantasai: We've got a couple of open issues.
Issue #2 - Should min/max-content sizes of flex containers include
flex-basis?
---------------------------------------------------------------------
fantasai: First one is if min/max-content size of flex containers
should consider the flex-basis or just work off the max-
content.
fantasai: I think dholbert was leaning to what the spec currently
says. So if I have a flex item whose flex-basis is 50px
and the max content is 10px, when I shrink should it be
50 or 10?
TabAtkins: 50.
fantasai: It's flex-basis so it can shrink or grow.
fantasai: So if I have a flex container with one item and that
item has "hi" and I give flex-basis of 10em and I shrink-
wrap should it be 2em or 10em?
dbaron: What do existing implementations do?
dbaron: We've been shipping this for a while.
gregwhitworth: I think this one we're all over the map.
gregwhitworth: Flex is just shrink/grow?
fantasai: Yeah.
<fantasai> http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cstyle%3E%0A%20%20*%20{%20border%3A%20solid%3B%20}%0A%3C%2Fstyle%3E%0A%3Cdiv%20style%3D%22display%3A%20flex%3B%20float%3A%20left%3B%22%3E%0A%3Cp%20style%3D%22flex%3A%201%201%2050px%22%3Eem%3C%2Fp%3E%3C%2Fdiv%3E
dbaron: With flexbox it seems like the issues should have test
cases and results when they come up for discussion. A year
ago when we made an incompatible change, we had a lot of
problems and we're not going to do that again.
Rossen: You're not alone.
fantasai: This test case (link above) uses max content size.
That's fine with me.
RESOLVED: Flex containers don't consider flexible flex-basis for
min/max-content sizes.
Issue #3 - Can percentages resolve given min-size: auto?
--------------------------------------------------------
fantasai: There's an issue on percentages inside flex items with
min-size: auto which we've discussed. There were 3
options. 1 was technically impossible. 2nd was make
percentages not resolvable. 3rd is two pass layout. It
looks like implementors are converging on two pass with
optimization.
fantasai: Tab and I don't have a preference. We'd like implementors
to get together and decide.
fantasai: Does anyone else have anything? I plan to get
gregwhitworth and dholbert and Christian on a call and
have them figure it out.
dbaron: I'm a bit concerned about performance characteristics of
flexbox right now, but that's all.
fantasai: I have no opinion. It's performance vs author
expectations.
ACTION fantasai to get people on a call to make a decision about
percentages inside flex items with min-size: auto
<trackbot> Created ACTION-704
Issues #6 - Do flex item determination before anonymous box fixup
-----------------------------------------------------------------
fantasai: Last one, if you have a flex container and you put two
table cells in it, they won't become flex items
independently. They'll wrap in an anonymous table and
that will be flex.
fantasai: However, Chrome had implemented it so that each item is
independently a flex item.
dbaron: They do anonymous box after?
fantasai: Not at all.
dbaron: So it turns the table cells into blocks.
fantasai: I've seen at least one presentation at a conference
where they took advantage of this to create fallback
behavior for a flex.
dbaron: But that only works in Chrome.
fantasai: Yes.
Rossen: Sounds like a terrible hack.
fantasai: That indicates to me that there are people taking
advantage of this and could be a useful behavior. Do we
want to change the spec to use chrome's behavior?
Rossen: They are doing fixup, but they're creating 2 anonymous
tables instead of one according to your code.
zcorpan: You could get table layout by overriding with the
new 'display' value in flex implementations.
fantasai: That won't work because flex-item isn't a value for
display.
[discussion that resolves in chrome not doing fixup]
ojan: The conversion we do for position absolute, we're doing it
for flex.
dbaron: Some of this is a function of what the order of the fixup
steps are.
TabAtkins: The spec has been explicit for a long time about when
you do fixup. It's not the Chrome behavior.
ojan: We didn't violate the spec when we implemented that, the
spec changed. We're open to fixing it. I think this is
better and simpler; it's better for when we do custom layout.
fantasai: I don't think there's a strong argument one way or the
other. Web compat would swing it.
fantasai: (I had brought up the point that 'people may want to do
this backwards compat thing' when we discussed it
originally, but it was dismissed as not useful.)
<rachelandrew> slide 39 in this deck is an example of
display:table as a fallback
http://www.slideshare.net/zomigi/enhancing-responsiveness-with-flexbox-css-day
dbaron: So it sounds like we should switch to coercing the block.
fantasai: I don't know how much it's an issue, but it would be
safer to switch to they webkit behavior. I can't think
of a good use case of putting a table in a flex unless
you're trying to do this fallback. If you're not trying
to trigger fallback, I don't know why you'd put a bunch
of table cells in flex and get it wrapped in anonymous
stuff.
ojan: It sounds like no one is opposed to changing.
Rossen: So we'll want to do the same thing for grid.
fantasai: So proposal is: Don't wrap an anonymous table around
consecutive flex of a flex container.
TabAtkins: In the paragraph that specifies the other behavior.
fantasai: We'll have to dig into what about having a table row.
ojan: I'll share with you the code Chrome uses. Somewhere the
coercing behavior needs to be explained.
<dbaron> https://drafts.csswg.org/css2/visuren.html#dis-pos-flo
<ojan> Here's what chrome does:
https://code.google.com/p/chromium/codesearch
chromium/src/third_party/WebKit/Source/core/css/resolver/StyleAdjuster.cpp&q=equivalentBlockDis&sq=package:chromium&l=58
<ojan> And I believe that's what WebKit does as well.
TabAtkins: If you have two siblings and one is position: absolute
it shouldn't be a part of the table.
dbaron: I think a bunch of the coercing behavior is in that link.
fantasai: There's an equivalent section in the display spec.
<fantasai> https://drafts.csswg.org/css-display/#transformations
plinss: So everyone is okay with making the change.
RESOLVED: Just blockify the children of flex and grid containers.
Don't do anonymous box fix-up
fantasai: There's a couple things where we need to edit. Last
issue to discuss is the percentage margin stuff.
TabAtkins: It's a good idea to do now.
Grid/Flex Percentage Resolution (aka Flexbox Issue #7)
======================================================
TabAtkins: Soooo....
TabAtkins: At several previous meetings we've talked about how
vertical percentage margins and paddings are defined.
Last meeting I tried to convince people to making it
resolve against width (as it historically has) instead
of against height (as has been proposed for flex and
grid).
TabAtkins: One of the stronger arguments that's come out is the
behavior of an abspos element. Abspos currently uses
the legacy behavior. But if you have an abspos block
where the containing block is grid or flexbox, what do
you do?
TabAtkins: Currently the only thing an abspos cares about is its
containing block's size. The only thing it cares about
is that it's a rectangle and the things that make it a
containing block.
TabAtkins: Other than writing mode, abspos are ambivalent about
the containing block.
TabAtkins: If we make grid and flex resolve against the height,
then either abspos are inconsistent with in-flow boxes,
or their behavior changes based on what ancestor has
position: relative.
TabAtkins: Also, no one cares about this so we can keep it simple
with the old legacy behavior.
ojan: It's more that Mozilla has a number of bugs where web
authors ask for legacy behavior.
TabAtkins: We have no bugs asking for the new behavior.
tantek: This is really going to hurt the kind of people that
aren't filing bugs, it's going to hurt new people.
TabAtkins: The aspect ratio hack is in tutorials.
tantek: They're not beginners.
gregwhitworth: I think that people do use percentage margins, not
just for the aspect ratio hack.
ojan: I've asked for the list of sites where people use percentage
margins not with the aspect ratio hack and I don't have it.
gregwhitworth: I'll get it to you.
shane: Is it inside flexbox or outside flexbox?
gregwhitworth: I don't know.
Rossen: I wanted to go back to your opening about how abspos is
supposed to work in a way that's oblivious to the layout
type of the containing block.
Rossen: That is almost true, but it's a bit of a simplistic view.
I would disagree with your statement because, by adding
flexbox and grid and all their properties, you are taking
dependency on that layout type. I agree in the ideal case
abspos it should be simple canvas layout. It's the
simplest layout.
Rossen: If that's the only language I have to express my layout,
then there is a layout type which the only thing it cares
about is the 2D containing block. With the addition of
flex and grid, these items are speaking a different
language. Such as 'by the way when you're setting up this
rectangle, I want to take up this number of columns.'
You're starting to take some dependency on context.
Rossen: At the end of the day you're saying you're still
pretending to be only in the 2D space. You either have
abspos which was nothing to do with grid and flex, but
we're not there. We've made abspos items able to speak in
terms of grid and flex and we are extending this simple
layout to be more.
<tantek> I tend to agree with Rossen's analysis
TabAtkins: There's nothing in flex that makes abspos care. We have
static defined, but that's not different. In Grid 2,
abspos don't care unless they opt in with grid
properties. Nothing else about abspos changes when you
make a grid container the containing block. You don't
have a property that changes to a different type of
behavior.
TabAtkins: So grid isn't a great example, flexbox isn't great.
Rossen: It is because you are allowing properties of grid.
TabAtkins: We are allowing grid properties to have an additional
effect--we're not changing the behavior of any other
properties. If you explicitly want an abspos to live
in a grid, you can. But we don't make width act
differently because it's in a grid. The rest of abspos
works the same.
TabAtkins: Whatever is used as the positioning block is arbitrary.
That can change with simple page layout. You attach it
to whatever positions as you need.
* fantasai agrees mostly with Tab's analysis -- it's weirdly, and
unexpectedly, inconsistent
Rossen: How does aligning work?
TabAtkins: It just cares about what the containing block is and
aligns inside.
Rossen: I don't believe this is what we talked about for flex
items abspos whose containing isn't flex.
TabAtkins: Every display mode defines static position.
ojan: For the static position it's controlled by parent?
TabAtkins: Yes.
TabAtkins: Maintaining the property is nice because it means that
the layout doesn't change because if you change from
abspos to fixedpos nothing changes. But here it would.
<tantek> There's no need to change abspos behavior here.
Florian: If you're thinking in terms of encapsulation, you are
trying to apply the same style to them that's different
if you're in grid. That's not great. If you're in two
types they're different and that's not good.
TabAtkins: We very particularly made it so that if you're doing a
flexbox it's similar to a block. They will change
layout if you switch to abspos in a minor but random
way.
fantasai: I think the vertical-resolution behavior is more logical
if we had started that way.
TabAtkins: I don't necessarily agree. Having the ability to do
consistent padding is nice too.
fantasai: This is true.
iank: I've been running a small script. 2% is using percentage
margin/padding and they're all aspect ratios for iframes.
gregwhitworth: I had something two weeks ago. I know there are
sites out there. I'm not going to claim the
percentage margin hack isn't the most common use,
but it's not the only use. I think we've all made
our points on this. I stand by it's the more
logical case and the reason we switched is it's a
more modern layout. I agree it's confusing, but I
guess in all honestly, I hear your argument, but I
don't think it's that strong.
fantasai: I think a key point that's different is it also affects
abspos elements, whether or not it should. If percentage
resolution for grid items is against height, we can make
abspos consistent across layout modes by continuing to
resolve against width--but then an abspos contained by
a grid won't be consistent with other items in the grid.
fantasai: Or we can make abspos inconsistent to themselves and vary
their behavior by containing block.
dbaron: I would pick option 1
TabAtkins: Where abspos always uses legacy?
dbaron: Yes.
tantek: The other option seems like a strawman.
fantasai: People were seriously proposing that, though.
TabAtkins: If they're always legacy your grid items will be having
different layout if they're an abspos item than an
in-flow one.
fantasai: If an abspos item is positioned against the grid should
it have the same percentage interpretation for margins
and padding as if it was positioned against any other
box?
tantek: Rossen, why did you argue the other way?
Rossen: Consistency in grid. So if you have two items, you want
consistency.
fantasai: Abspos can position in relation to grid lines. They
don't effect the sizing, but they can position as a grid
item in certain ways.
tantek: So they're top/left bottom/right aligned.
Rossen: Yes, plus grid properties.
fantasai: So abspos positioned to a grid container can have some
abilities of a grid item which is why Rossen argued they
should have the same behavior. I think consistency is
good here, but consistency across abspos is a good thing
too.
TabAtkins: We have only one self-consistent option.
<tantek> we don't have any one self-consistent layout across all
layout methods. e.g. table layout (in particular cells)
is already very different
TabAtkins: So you all intimated before there might be legacy grid
problem with Microsoft using MS grid. Can we fix that
without infecting standardized CSS?
fantasai: One thing you could do is have boxes whose containing
block is a grid container whose display value of MS-grid
would have the percentage behavior you have, but ones
with the standard prefix would follow standard rules.
They would be separate values internally.
Rossen: We'd prefer to drop the prefix if we can.
fantasai: But the content out there that depends on this behavior
depends on the prefix as well.
TabAtkins: Insofar as people are going to update their content...
we're well aware people don't update content.
fantasai: A lot of the content they're depending on isn't web
content. Those are less likely to be doing anything
besides what's coded in a Microsoft environment.
Florian: And it makes no sense to future-proof in that environment.
fantasai: Anyone else have something to add?
ojan: I haven't been here for the previous conversations. Has the
possibility of adding a new property to control this been
considered?
fantasai: Yeah, and we hate that idea.
Rossen: I had a mock-up.
gregwhitworth: I'm against it.
tantek: So add a switch instead of a unit.
TabAtkins: Unit doesn't let us retrofit old content.
Rossen: And if you have the unit you have to deal with it
everywhere.
fantasai: Let's not go there.
Rossen: The two options on the table are, use top and bottom
percentage margin and padding as they're specified for
inline grid and flex and don't do for abspos.
Rossen: That would be because we want to leave abspos as legacy
behavior.
Rossen: 2nd is make all the layout types to be legacy behavior
including grid and flex items.
Rossen: 3rd is where we are, everything is following inside of
grid and flex, they resolve against height even for abspos.
Rossen: So it's all new, all legacy, or mixed where inline flex
and grid behave new and abspos behaves legacy.
tantek: There's a strong argument for Rossen's 3rd option. This is
the basis of the NY argument. New authors coming to CSS
are then able to use not just flex and grid from the top
down and have that consistent treatment, they can also
reuse abspos elements in a way that is also consistent.
That almost gives us an opportunity to continue repairing
that mistake form the past.
TabAtkins: You're assuming there's a population of authors that
are fed up with the behavior.
tantek: That was the minority. It was new authors. Every single
new author.
astearns: They're confused by how percentage of top and bottom
resolve gainst the width.
TabAtkins: There are a lot of parts of CSS that are confusing.
Rossen: Which is what we're trying to repair.
dbaron: One point is block layout has two directions that are
fundamentally different whereas flex in more neutral.
fantasai: So is abspos.
dbaron: Not as much.
dbaron: It does a bunch of stuff that is biased to top left or
right.
fantasai: We do lots of stuff that's biased start/start.
[whiteboarding of options]
fantasai: We have 3 options.
fantasai: 1 is keep it all consistent. 2 is make the block inline
calc as width. 3 is [missed]
<iank> http://pastebin.com/5MZyq1gc [the whiteboard of the above
options]
Florian: I was convinced by tantek last time but TabAtkins's
argument is strong. Neither sounds great to me.
tantek: I'm talking about B. The method I'm trying to take is from
the new author perspective. I like less the implementor
way. We're solving for new authors.
ojan: I think the new authors are doing the aspect ratio hack.
They search for how to do it and copy/paste.
tantek: I disagree on gregwhitworth's data and every time I teach
CSS this confuses people.
ojan: It's not 100% the aspect ratio hack, but the vast majority
is. I'm not saying 100%. There are some sites that don't.
fantasai: In regards to helping new authors, having 2 different
behaviors depending on layout mode isn't helping authors
either. It would be great if we could switch
everything...
tantek: I disagree.
tantek: New authors don't load the whole world into their head.
TabAtkins: You have to teach a confusing behavior.
TabAtkins: Are you trying to claim we can't teach block anymore?
TabAtkins: Flexbox isn't replacing block.
zcorpan: You have to learn that behavior.
TabAtkins: They're not a legacy display type.
tantek: For percentage margins they are.
TabAtkins: I don't see why that's a flexbox thing.
tantek: They're more useful.
tantek: This author focus is important. You teach them the subset
of stuff that is useful, not the crap before. We don't
teach the spacers, we teach them the subset that works and
is consistent and they can model. We want to cut stuff out
over time if it's confusing, in terms of what we teach.
ojan: I would cut percentage margin and padding from the model,
though I agree with you we should work toward the future
where we should cut the crap.
tantek: It does because you either don't teach it or teach the
piece that just works. Or you end up with the proposal to
drop.
fantasai: I think you end up teaching them how it works on grid
and flex and then they try and do it elsewhere.
tantek: And then they realize that old CSS is broken.
fantasai: It's not broken, it's used.
dbaron: I guess I feel like we're over designing here. All this
stuff ends up getting used in ways...we've gotten to the
point where the major use case for percentage margins is a
hack. Why are we adding more features that are designed in
a WG meeting? Maybe we should try and make progress on
houdini instead. I don't think grid is something we,
Mozilla, should work on because I don't think flexbox went
well.
dbaron: I'd rather put in the resources to houdini and I think
that we'll wait until grid is stable and do it then for
webcompat.
fantasai: You're off topic.
dbaron: I think this comes up because of grid, though. We have
features, but they don't use them for the things we've
intended.
esprehn: Is there more strategy beyond this...for example there's
vertical-align. There's vertical-align where people go to
that, but it doesn't do what they think. What things will
we change the behavior of so that it makes more sense?
tantek: I think for this there's just a strong reaction to "what,
this doesn't make sense" meanwhile vertical-align doesn't
make sense to anyone.
fantasai: People have expectations of what top-center should do,
but we can't fix it since its been in the language so
long.
tantek: If you ID other parts of the platform where you can alter
in some way or a new property like box-sizing to better
match...that's good. If 90% think that it should work a
different way, we've screwed up.
ojan: This is the notorious problem where you can't center on the
web.
tantek: I think vertical-align in general is confusing.
esprehn: As we release do we plan to keep doing this?
TabAtkins: My answer is no.
esprehn: Do we switch the box-model...what fix ups do we change to
meet author expectations?
tantek: For a new authors it's not a switch.
TabAtkins: People still use block layout.
SimonSapin: You talk about legacy things that are wrong like
blocks as things people don't use anymore?
<TabAtkins> We're not adding `div { display: flex; }` to our
stylesheets.
tantek: I think that's right, I'd tell authors not to use
percentage margins and padding because it's broken.
Florian: So, based on your argument that we shouldn't teach
authors the broken pieces...I don't think the situation
where grid items are and aren't abspos behave
differently, I don't think it makes anyone happy.
tantek: My initial reaction to making abspos based on context is
kind of odd. Rossen's argument is as soon as you start
nesting abspos or putting them in a grid layout you're
going to be using things that are gird specific.
TabAtkins: Not necessarily. You'll often treat it as an ordinary
item.
fantasai: You might have a "New" banner. You want to put it on any
top of the box, doesn't matter the type.
fantasai: We have two authors in the room. Rachelandrew?
rachelandrew: I think, I've done a lot of work with grid. When we
talk about new authors, they're sitting down and
learning bootstrap and working out how to do things
in CSS from that framework. People will have a
legacy understanding of CSS because those frameworks
use it.
rachelandrew: Being able to use a fragment anywhere is important.
You don't want that position to change through any
context. You don't want that to be different. It's
going to take people a very long time to change how
they have been thinking for years.
rachelandrew: People's understanding is very much based around
those frameworks.
fantasai: leaverou?
leaverou: I just got here.
fantasai: So we have percentage top and bottom margins in CSS,
which are measured against the containing block's width.
fantasai: There was a proposal to have flex and grid interpret
these differently--to resolve vertical margins against
the height.
fantasai: There was an argument for consistency across CSS or the
argument about making flex and grid easy.
fantasai: The new consideration is about abspos items. Abspos items
follow the same layout rule as blocks--always resolving
against width. The question is what if your abspos item's
containing block is a grid container. Is it like a grid
item or as an abspos everywhere else?
fantasai: Before we could say there's one consistency break:
between block/inline/table on one hand and grid/flex on
the other.
fantasai: But abspos creates a bridge between the layout modes.
fantasai: An abspos parented to a block must behave like a block.
But should it be different when the abspos is parented
to a grid?
fantasai: Is abspos internally consistent or consistent to the
containing block?
fantasai: Abspos have special properties when they are parented to
a grid container. So some of the positioning will work
the same as a grid item, but percentage margin and
padding will behave differently. Somewhere there will
have to be a break if we want flex and grid to be
consistent.
fantasai: So there could be consistency across all of CSS; or
there's a break in how abspos behave (depending on its
containing block's display type); or there's a break
in how in-flow and out-of-flow grid items behave.
fantasai: That's what's here on this chart.
1 2 3
* in-flow block/etc. width width width
* abspos to block/etc. width width width
* abspos to grid/flex width width height
* in-flow grid/flex width height height
leaverou: As long as grid acts differently it will be inconsistent
no matter what we pick. I do see why there should be an
exception there.
tantek: I think everything dbaron said and rachelandrew said was
ignored.
tantek: The point about frameworks is very important. New authors
more and more have been switching toward using frameworks.
I'm going to include Sass as a framework. I think we
should ask why is that happening. I would hypothesize that
part of why is that CSS has gotten too big and complex.
Also, too many features that are handled in bizarro ways.
tantek: Authors look at their options for the bizarre CSS rules or
the framework that just has these simple features, they
choice is obvious is that they go to the frameworks.
Everyone needs to ask is do they care about making
something authors can do directly or do you want to make
more frameworks?
tantek: I think that the second option is for houdini. I think we
should make CSS able to do it's own thing.
leaverou: I completely agree with tantek. We need to make the
language easy to use.
tantek: I am trying to fix that.
fantasai: You argue for consistency, but you're arguing against
consistency.
tantek: You keep reframing this as something different from what
I'm proposed.
zcorpan: tantek, which option would a framework use?
tantek: We don't have a framework author here. They have to build
on top of whatever randomness we build and figure out what
is the common use case.
fantasai: Let's consider that someone is a framework author and
they're building a grid layout framework. They're basing
it off flexbox, but they have a lot of fallback
behaviors. Let's say we release the grid spec and the
author says they can use grid where it's supported,
flexbox where it's not, and float layout as the last
choice.
fantasai: If the author puts a percentage margin on their items,
it will behave one way on flex and grid, but differently
on floats.
tantek: I think your example has too many assumptions.
SteveZ: A framework is to hide the complexity. I don't think from
a framework author point of view we can answer this.
They'll figure out how to calculate it for percentages.
ojan: Except they can't because the author will be specifying that
part.
tantek: The author will do it, it'll break, and they'll look in
the framework community for an answer.
fantasai: Let's do a strawpoll.
tantek: I object to how you framed the answers.
fantasai: How would you like this strawpoll framed?
tantek: They're in the minutes.
tantek: Rossen proposed how every person was advocating it.
Rossen: Option 1: Keep everything consistent in terms of
percentage resolution- that was aligned with your option A.
Rossen: Option 2: Mixed where abspos items are an exception inside
grid and flex in terms of percentage margin.
Rossen: Option 3: Everything we did in grid and flex, including
abspos is following the new model.
Rossen: From the PoV of the layout type, not abspos.
<tantek> Option 1: Keep vertical % margins/padding always
dependent on horizontal metrics
<tantek> "consistent" is an oversimplification in option 1
fantasai: tantek are you happy?
tantek: I think it's better to make clear that option 1 vertical
percentage margins/padding always dependent on horizontal
metrics
tantek: I think that's important to call out.
<astearns> option 1: keep old mistakes everywhere, option 2: keep
old mistakes in some places, option 3: fix old mistakes
everywhere we can
Rossen: One more point for implementors: as soon as you start
adding logical properties you will find yourself wishing
you had chosen the symmetry.
Rossen: Especially for vertical mode in horizontal.
fantasai: To be clear this chart is the logical width and height.
* leaverou thinks one weird rule is better than 1 weird rule + a
bunch of exceptions, so leaning towards option 1
<tantek> leaverou: it's about do we want to try to keep making CSS
more usable over time, or do we want to forever shackle
ourselves with bad decisions of the past?
<leaverou> tantek: but it's not about making CSS more usable, it's
making it more internally inconsistent
<leaverou> tantek: given that we are not going to change the past
behavior
<leaverou> exceptions are hard to teach
<TabAtkins> The idea that making the language inconsistent in tiny
ways in successive waves, is "making the language more
usable", is incorrect.
<leaverou> TabAtkins++
<TabAtkins> We should only be inconsistent with legacy when the
new behavior is actually strongly good.
<TabAtkins> Like switching to using Promises over callbacks.
<tantek> leaverou: I disagree, it's about making the set of modern
CSS more usable
<tantek> which is a subset of making the platform as a whole more
usable over time
<tantek> which requires us to drop / obsolete / or even ignore bad
things in the past - just don't teach them to authors
<Ms2ger> Except that authors need to be able to edit existing code
<leaverou> tantek: it's not universally a bad thing. Having it
depend on horizontal metrics is useful sometimes for
e.g. equal spacing between items (horizontally and
vertically)
<leaverou> tantek: it's confusing in many cases, sure, but
exceptions are even more
<tantek> leaverou: we avoid exceptions by dropping the past broken
things
<leaverou> tantek: we are never going to drop the past broken
thing here Tantek, it would break too many things.
Unless you think we're gonna drop block altogether
<tantek> leaverou: we always drop past broken things, like using
tables+gifs for layout
<tantek> by "drop" I mean what we teach authors
<tantek> modern web practices
<leaverou> tantek: in that case it's dropping a methodology, not
the tech. The tech is still there to do layout by tables
<tantek> leaverou: that's the author-centric point of view, that
we drop things effectively by dropping them from how we
teach
<tantek> that's basically what frameworks do, they drop all of the
platform
<leaverou> tantek: so we're gonna stop teaching block?
<tantek> no, we stop teaching % margins/padding on block
<leaverou> tantek: people will try them anyway. IF anything, by
changing something from grid to block and forgetting to
change the margin
<leaverou> tantek: but mostly because "they work here, why
wouldn't they work there?"
Florian: So what strawpoll do we take?
fantasai: We do 1, 2, or 3, as stated by Rossen
<shane> https://usercontent.irccloud-cdn.com/file/xkTN5ySI/IMG_20150825_122812.jpg
<shane> https://usercontent.irccloud-cdn.com/file/1kuGPaOM/IMG_20150825_122940.jpg
Bert: I prefer 1
esprehn: 1
Rossen: 3
tantek: 3
astearns: 3
fantasai: 1
jet: 1
andrey-bloomberg: abstain
SimonSapin: abstain
TabAtkins: 1
Florian: 1
leaverou: 1
ChrisL: 1
zcorpan: 1
hober: abstain
weinig: abstain
dauwhe: 1
SteveZ: 3
plinss: abstain
hyojin: 3
ojan: 1
johanneswilm: 1
gregwhitworth: 3
matt: 3
brian: abstain
iank: 1
shans: 1
rachelandrew: 1
dbaron: 2 or 3
plinss: Is there anyone voting for 3 that objects to 1?
tantek: Yes.
Rossen: Yes.
plinss: And the reverse?
TabAtkins: Yes.
tantek: We did have resolution consensus before.
TabAtkins: Then we'll object to the current situation.
fantasai: There's significant new information.
ojan: The resolution from last time was option 2.
dbaron: Did the discussion last time distinguish between 2 and 3?
tantek: No.
<tantek> The resolution from last time was effectively (2 or 3)
<tantek> what we found out today is that 3 is a clarification of
the past resolution
* leaverou thinks the abspos issue makes it even more weird to
have an exception there, so it makes sense that the
consensus has changed
<tantek> leaverou - I'd like to understand how you'd propose
making CSS *better* for authors, not just consistent with
all legacy
<leaverou> tantek: I don't think you realize how hard exceptions
make CSS to understand and teach.
<tantek> leaverou: unfortunately I do realize how painful that is
and hence want to avoid teaching authors the bad ways of
old
<leaverou> tantek: Having one consistent but suboptimal rule is
better than having that in most cases, but not in grid,
but wait, it's different if you have abspos etc etc
<tantek> leaverou: % margins and padding are *already*
inconsistent with % height
<tantek> this is trying to fix that
<leaverou> tantek: yes, but you will have this inconsistency
*anyway*!
plinss: I'm open to suggestions on how to move forward.
TabAtkins: If I understand, Microsoft's main objection is dealing
with the legacy content. I'm looking for a solution
that keeps your content working and lets this move
forward. If we knock that out, does it remove enough
objection that you're okay with it?
Rossen: No.
TabAtkins: We're at an impasse.
Rossen: The abspos information doesn't bring anything new because
we're already doing 3.
Rossen: But it's a thing we needed to clarify.
dbaron: I think one reality is that in a lack of consensus we go
with implementor market share. Does safari match chrome?
TabAtkins: Yeah.
gregwhitworth: But they said they'd switch.
Rossen: Hyatt said he would switch on the telecon.
TabAtkins: It's easier to not switch.
TabAtkins: We can make it officially undefined.
fantasai: Either way we're closing this with a formal objection.
Florian: Is leaving it undefined and let it converge work?
tantek: I'd rather have that then an arbitrary top-down decision.
shane: Is it possible to remove percentage margins from flexbox?
TabAtkins: Taking out doesn't mean it's not unspecified.
shane: It means there's no expectation on when it should be
implemented.
TabAtkins: We'll have to say percentage margins do not work in
this context.
tantek: Or ignored.
fantasai: You can't ignore because you have to parse in.
plinss: Earlier we rejected a user switch.
fantasai: I disagree with switch.
hober: I think it's a terrible idea.
Florian: Can we consider the option of leaving it undefined? Let
the market sort it out.
SteveZ: But then you don't have interop.
hober: You eventually do.
gregwhitworth: With the rest of the CSS2.1 stuff we're dealing
with I'd rather not.
<tantek> block-percentage ?
gregwhitworth: We're stuck, I'd rather we circle back and talk
again later.
gregwhitworth: I think we should move on to the next item.
plinss: I agree. We're not getting anywhere.
TabAtkins: So the spec if currently listing the behavior that
we're not happy with. We can't push to CR as it is with
and active objection from a major implementor. I will
just undefine it if we leave it as it is.
gregwhitworth: I was suggesting we go sit around a table and talk
about this.
TabAtkins: Assuming nothing comes out of a conversation we
undefine it.
plinss: So a timeline?
gregwhitworth: I was thinking tomorrow.
TabAtkins: A day or two is fine. I don't want to hold up the spec.
plinss: Let's do that.
plinss: Other flexbox issues?
fantasai: No, we've got some editing to do.
Testing
=======
Topic is old tests that are invalidated by new features
SimonSapin: We've seen that happen in two cases. One is that for
hex colors we have tests in 3 or 4 or 8 are not
supported, but in color 4 they are supported so the
old tests fail. What should we do about such tests?
SimonSapin: Should tests be updated if a later version of the spec
changes behavior?
ChrisLilley: We usually remove the test or change to point to
where ever the new spec is.
SimonSapin: If that's okay for everyone, we should change the
tests.
fantasai: For that test you have two permissible renderings. If
you're a 2.1 agent you treat it one way, if you're level
4 you render another way.
ChrisLilley: I don't think CSS2.1 UA is a concept.
fantasai: I think there's implementors that aren't caught up and
they shouldn't be flagged as failing for that reason.
fantasai: We tested for this case because there was a quirky method
of parsing hex colors in HTML and we wanted to test for
that to make sure UAs were rejecting those as invalid.
fantasai: So this is an important test to make sure people that
don't support Color Level 4 parse hex values correctly.
fantasai: For reference tests we can have two references and you
have to match either one.
SimonSapin: Okay.
fantasai: For a given UA they'll only have one reference, but for
the test suite at w3c we should have two references.
dbaron: It would be useful to have a resolution to fix old tests
that fail due to new specs, so that they pass either way
TabAtkins: Is anyone actioned to update?
plinss: We have a pull request.
gregwhitworth: How are the tests attached?
fantasai: There's metadata that tags to a specific section in the
spec. You'll have a tag to however many specs you're
testing.
SimonSapin: So each test is in a separate test suite per spec
<ChrisLilley> @ gregwhitworth
https://wiki.csswg.org/test/format#specification-links
<gregwhitworth> ChrisLilley: Thanks
RESOLVED: We want to update old tests but leaving the old pass
conditions in tact
SimonSapin: And the other case is that we decide a declaration
block could accept @rule like @page does. Even if
there is nosuch @rule defined yet because it makes a
difference inthe error recording.
SimonSapin: There's a CSS2.1 test that fails there.
dbaron: That's a case where we should fix CSS level 2.
fantasai: That should be backported.
SimonSapin: I sent an e-mail to the list asking to include an
errata.
Bert: I missed that, but there is something strange about that. It
allows @keywords inside declarations which is disallowed by
CSS2.
TabAtkins: It's fine by syntax.
Bert: We're breaking a promise that's explicit in a spec.
SimonSapin: It's a declaration that contains @rules.
Florian: It is a breaking change.
fantasai: It won't break any implementation.
SimonSapin: I made that change in Firefox a couple years ago, and
the only bug report is that this test doesn't pass
anymore.
TabAtkins: Like dbaron said we should fix 2.1 to no longer say the
opposite and then fix the test suite.
SimonSapin: I wrote an errata and there was a resolution.
<SimonSapin> Change proposed in
https://lists.w3.org/Archives/Public/www-style/2013Apr/0506.html,
resolved on in
https://lists.w3.org/Archives/Public/www-style/2013May/0783.html
plinss: So we just need that reincorporated.
Bert: I have the text. I'll put in the errata.
plinss: That takes us to lunch.
<lunch - return at 2pm>
<dbaron> <br type="lunch" duration="calc(64*60s)">
Received on Friday, 4 September 2015 21:23:25 UTC