- From: Dael Jackson <daelcss@gmail.com>
- Date: Tue, 24 May 2016 19:35:29 -0400
- To: www-style@w3.org
=========================================
These are the official CSSWG minutes.
Unless you're correcting the minutes,
Please respond by starting a new thread
with an appropriate subject line.
=========================================
Media Queries
-------------
- Discussion around syntax for overflow (scrolling vs paged) MQ,
and possibly having a multi-value MQ.
- Discussed difference between returning false and unknown
- Discussed the need for a way to truly negate a MQ to create
two complementary code blocks, since (given unknown being
different from false) the current syntax doesn't give that
ability.
Sizing
------
- RESOLVED: Intrinsic sizes that don't require layout to
recalculate are treated as definite.
Flexbox
-------
- The decision on how to handle percentages will wait on use cases.
- The group discussed how to handle layout when there's a column
multi-line flexbox that's floating and has a column wrap.
- There's a fast and performant and clearly broken and useless
approach done by Chrome or doing actual layout as done by
Edge.
- People were uncertain which approach was best and concerned
that whatever is decided would still work years down the
line.
- TabAtkins wanted more time to think about a solution, so the
discussion was tabled.
CSS Containment
---------------
- RESOLVED: Publish FPWD of css-contain-1 after edits on overflow
dependency
===== FULL MINUTES BELOW ======
Agenda: https://wiki.csswg.org/planning/san-francisco-2016#proposed-agenda-topics
Scribe: dauwhe
Media Queries
=============
astearns: Let's get started.
astearns: Overflow stuff isn't prepared yet, is there anything
else?
astearns: The other topic is flexbox, but we're waiting until 2:30.
Florian: We can try to do MQs.
Florian: One MQ thing is also about colors.
Florian: Light-level media query?
fantasai: We resolved to defer.
Florian: Simon said that he might not like it at all.
Florian: Since it's been in spec for a while, I'd like to hear the
objection.
myles: First objection: fingerprinting
myles: A website will know if I'm outside or inside.
myles: Second is that it's an OS thing.
myles: Third, OS has night mode that might interfere.
Florian: For the 3rd thing, I don't think it would fight.
Florian: Given the adjustments already made, are we in a mode that
needs boosting?
Florian: You have to take into account the display and the
environment.
Florian: LCD would be different than e-ink
Florian: so you can take into account OS stuff then.
<fantasai> https://lists.w3.org/Archives/Public/www-style/2016Mar/0356.html
<fantasai> resolution on deferring light-level ^
fantasai: Here's the resolution... move light-level to next level
of MQ.
Overflow
--------
TabAtkins: Overflow
fantasai: I had action item for proposal.
fantasai: I'll try on the fly.
fantasai: The questions were:
fantasai: there's a block and inline axis
fantasai: can be scrolled or clipped
fantasai: block can be scrolled, paged, scrolled and paged.
fantasai: We had overflow inline and overflow block
fantasai: but you don't care about everything
fantasai: so you'd have overflow and can just ask about block
fantasai: or do separate query for inline
fantasai: so syntax would be superset of keywords.
overflow: scroll | page | scroll-page | none |
scroll-inline | scroll-block | clip-inline | clip-block
dbaron: Don't know what you mean by overflow-inline.
dbaron: Does it have two different values but matches either?
Florian: It doesn't have a value, it answers yes or no.
dbaron: All the features have a value.
dbaron: Just because a spec is written a certain way doesn't mean
the concept isn't there.
Florian: If you include undefined, then yes
Florian: some MQs always return false.
dbaron: Either they have a particular value or no value.
dbaron: I'm not totally against, but it's a little weird.
fantasai: Can you specify them together?
fantasai: Is the syntax going to be (writes on whiteboard)
fantasai: <block> | <inline>
Florian: Less risk by having one value then combining.
fantasai: That works for me.
Florian: Scroll pages is the ??? one?
Florian: We can spend forever on bikeshedding, but this makes sense.
Rossen: If you want to constrain to match only block
Rossen: then having it match scroll and not scroll.
fantasai: You can say (overflow: scroll) and (overflow:
clip-inline).
Florian: Between multivalue MQ and separate overflow-inline MQ.
Florian: Either way you type the same words,
Florian: which one is easier for impl, for extensibility.
fantasai: They're both easily extensible.
Florian: Having two properties is less work.
Florian: MQ so far don't have multivalue.
Florian: You may need to change your code.
Rossen: Sure.
fantasai: (writes) overflow: scroll | page | scroll-page | none
fantasai: scroll-inline | clip-inline
fantasai: scroll-block | clip-block
fantasai: I just want this first set to work because those are the
common cases.
Rossen: What is scroll-page.
fantasai: You can scroll but get new pages on forced breaks.
Florian: Or can break on infinite scroll.
TabAtkins: The presentation case is good.
astearns: Do we do the top box on this level, do the rest later?
fantasai: That's ok.
esprehn: Who has scroll-page?
fantasai: Presto.
esprehn: Scroll and page seem obvious, but the others...
TabAtkins: We had at least one implementation that had behavior of
scroll-page.
hober: That impl won't be updated for MQ.
TabAtkins: But we know it's been useful to someone.
esprehn: We're trying to spec someone's experience. What about
flipboard?
fantasai: They page.
TabAtkins: The user agent is the one answering these questions.
flipboard can do whatever it wants as a web app.
Florian: The inline direction is relevant to our user agent
(vivliostyle)
Florian: both scroll-inline and clip-inline are used.
esprehn: It seems bad to define all these things here.
fantasai: This is about whether fragmented or not.
esprehn: What if there's an expando triangle at the bottom.
TabAtkins: Give us an existence proof.
fantasai: If you can do that on any page, it's effectively scroll,
fantasai: you're not fragmenting.
esprehn: I want clip.
dbaron: That's a scrolling UI.
fantasai: There's a continuous scrollable area and you can view it.
dbaron: You can look at the other part of the layout, but you're
not changing the layout.
fantasai: If you have paging, it changes layout, because you have
to space content away from the breakpoint. That's
fragmentation.
Florian: For inline, scrolling and clipping we understand
Florian: but we don't have inline fragmentation because we don't
understand what it is.
Florian: The rest are things sensible UA's want to do
Florian: why exclude them?
Florian: If your UA doesn't do them, just say no.
<dbaron> I think some UAs may have had table printing code that
did inline-direction fragmentation
esprehn: I think there's a lot of dead stuff in css
esprehn: like a monochrome display with only green.
esprehn: There's a matrix one.
TabAtkins: Some versions of lynx need that.
Rossen: What is your main objection?
esprehn: Every new print person will want more.
esprehn: It's an enumeration of possible user experiences.
dbaron: It's an enumeration of the way the content can be laid out
in css.
Florian: The things that are not defined in css are not in this
list.
hober: Can we add scroll-page but make it at risk?
fantasai: Just say no,
hober: As a reader of the spec, I'd like to know that no UA does
this.
fantasai: But there's a decent chance there are some UAs
fantasai: I don't think at risk makes sense.
Florian: By not implementing it you are implementing it.
hober: Just spec as returns false :)
esprehn: What UA can only display the initial viewport?
Florian: Digital signage.
TabAtkins: Digital signage is currently bad about this.
Florian: If you know your UA doesn't show overflow, then you need
to know this.
shane: How many pages do you expect will show digital signage?
TabAtkins: There's a news site that's designed for both--web and
elevator,
TabAtkins: content is the same,
TabAtkins: their content is amenable to MQ.
hober: My understanding of esprehn's point is hinging on that.
plinss: If you don't parse it you're ok.
dbaron: MQs are intended to be more speculative than other stuff
in the platform.
dbaron: "are you doing this familiar thing, or might you be new"
esprehn: I wish my toaster supported css.
astearns: This is not sounding productive.
Florian: Are we ok with having this in spec and not implementing?
esprehn: I object to the fact that the platform has stuff you
shouldn't use as an author.
esprehn: I have to wade through a lot of useless stuff.
Florian: We've removed some useless ones already.
TabAtkins: We should do better with examples and education.
TabAtkins: We can do more than the maximally useful.
astearns: Do block overflow now and inline later.
Florian: We know what we want to write, and someone wants to
implement, why wait?
astearns: Do we split into levels? or do we put the whole proposal
in?
astearns: I don't care. Straw poll?
fantasai: I want to keep scroll-page.
dbaron: Should none be called clip?
fantasai: None triggers falsiness.
TabAtkins: That's how MQs work.
astearns: A straw poll. A: overflow: scroll | page | scroll-page |
none
jensimmons: So we're doing things that no one wants to do now?
astearns: This allows implementation later.
myles: If it never gets hit, how do you know it works?
myles: That's a recipe for untested code.
dbaron: You write a query that says "do you have the feature"
dbaron: Everyone returns false.
dbaron: Later you can use it.
TabAtkins: We wouldn't write code today
TabAtkins: but if anyone does do it, the ability to discriminate
is useful
TabAtkins: and we know it's been done in the past or niche.
TabAtkins: So it's reasonable.
Florian: You can return unknown instead of false
Florian: but then there's problems with boolean logic.
Florian: If you know you're not doing it then say false.
plinss: It doesn't help now.
gsnedders: What happens if you give an unknown keyword?
TabAtkins: It stays as unknown.
TabAtkins: If it gets to top level it becomes false.
Florian: Overflow (not scroll-page) is the issue.
gsnedders: ah.
jensimmons: You're interested in the inline things?
Florian: Yes.
Florian: We haven't implemented yet but it's in the plan.
Florian: We're also thinking about scroll-page.
Florian: As dbaron says, these are not theoretical UI modes, they
are css layout modes
Florian: and we know how they work.
Florian: This is stuff we do in css today.
Florian: We know what these things do.
Florian: Not all of them are implemented in mainstream things.
bradk: If we have A, what is purpose of third line?
Florian: I don't understand it either.
fantasai: Third line if you want to explicitly query block axis.
fantasai: If you're scrolling does this query return both axis.
fantasai: there are few question:
fantasai: is it block scroll, or both, or either?
Florian: Didn't used to be a problem.
fantasai: For scroll-page, if you query the media type about
scroll, it should probably say yes.
TabAtkins: Can always return true for scroll.
fantasai: We do not page.
TabAtkins: Requiring negative query for common cases is not good.
fantasai: Scroll page ua would want to fall under scroll.
TabAtkins: Let's not over-think. Match one thing or another.
Rossen: Back to straw poll?
astearns: Do everything at once, or split into levels?
fantasai: Option C: keep spec as-is, with overflow-block and
overflow-inline as separate.
Florian: overflow-block is too verbose.
bradk: I like the way it is, it's explicit about which direction.
Florian: People stopped doing @media print, when they were talking
about pagination.
* gsnedders suspects most web developers will just keep using
@media print…
fantasai: We're breaking out paginated part of print, like for an
e-reader.
TabAtkins: Webkit and chrome don't want to implement values they
won't use in the future.
esprehn: Because false and undefined are different, we'd still
have to implement.
fantasai: You'd still return false on tactile.
esprehn: So your binary has to contain things you don't support.
Florian: You will always have to do that with MQ.
esprehn: That's why I'm objecting to shipping speculative stuff.
Florian: They're both on my road map.
plinss: If any UI shipped, would you implement the MQ?
dbaron: The fact that the new boolean thing isn't right is a
problem.
dbaron: It doesn't do what we want to do.
dbaron: We want to make it possible to "if this matches, do stuff,
if not do other stuff"
dbaron: If it's unknown neither block run
dbaron: People want "or else"
dbaron: and the old MQs give you that, well it fails at a higher
level.
plinss: Let's put an else rule in MQ
plinss: @else.
hober: In a world where some browsers return unknown
hober: you have to write rule so unknown ends up false.
hober: Will be in practice indistinguishable.
dbaron: Unknown and false behave the same
dbaron: not unknown and false behave the same.
dbaron: If you're using the not to be else.
dbaron: Maybe MQ need a syntax for is this thing supported in MQ.
gsnedders: Often you can make an assumption... more likely scroll
than page
gsnedders: it's probably going to be right.
Florian: You write your non-conditional code for what is most
probable and then test.
dbaron: Having to write non-conditional code and then override is
a huge pain.
<fantasai> +1 to dbaron
Florian: The problem with else.
Florian: we need syntax that makes the else apply in things that
don't support it.
TabAtkins: This is something that doesn't transition well.
jensimmons: Do we need to allow MQ in @support?
jensimmons: If you support foo, then I'll ask some questions about
whether foo is supported.
gsnedders: It makes sense to treat MQ separately from @support
dbaron: It's useful to have is a MQ supported so you can used and
and or
dbaron: is it supported AND is it true
dbaron: you keep the unknown.
jensimmons: What if they don't support the test and the feature?
dbaron: Then it doesn't work.
dbaron: Just like @supports.
TabAtkins: We can explore that.
gsnedders: Supports is better than @else.
fantasai: We should make it easy to see if this is supported and
true, or unsupported or false.
Florian: Supported and true is good.
fantasai: You need the opposite of supported and true.
dbaron: you could have a function that captures the unknowns
gsnedders: can we call it supports
<jensimmons> Can you put a media query inside a feature query?
<jensimmons> (currently)
ACTION: TabAtkins to look into supports on MQ
<trackbot> Created ACTION-770
<dbaron> The function is, I think, known-and-true()
Percentage sizing issues
========================
astearns: We're talking about percentages.
<fantasai> https://lists.w3.org/Archives/Public/www-style/2016May/0050.html
fantasai: Bigger one is filed against grid and abspos.
fantasai: The thing Christian and Igalia folks wanted answered
fantasai: this is what we want to tackle first.
fantasai: Everything else depends on this.
TabAtkins: I can summarize;
TabAtkins: resolving % on children when container size is
shrink-wrapped
TabAtkins: for float that shrink-wrap, if we have child 50%.
TabAtkins: We will do normal shrink, then child will be 50%
against that.
dbaron: Intrinsic width is separate from layout.
dbaron: Intrinsic width doesn't know %.
dbaron: In layout you have input width, it takes that.
dbaron: It's interoperable across lots of things.
fantasai: It's undefined in 2.1.
dbaron: shrink-wrap is undefined in 2.1.
TabAtkins: Now it says % is never resolved, we want to change.
fantasai: If you do same in height, then % are treated as auto.
fantasai: If you have the same situation in height axis, that
percentage is not resolved, is treated as auto.
fantasai: So we have an inconsistency, how will we resolve?
fantasai: Which parts of flex and grid do we make consistent with
2.1 width.
TabAtkins: These calculations happen separate from layout.
TabAtkins: You need to run real layout to figure out height.
cbiesinger: I like the principle.
cbiesinger: Width calcs should require layout
cbiesinger: for intrinsic size calcs.
fantasai: In css 2.1 we didn't run into this.
fantasai: Orthogonal flow breaks the assumption of width input
height output
fantasai: then you have to perform layout to find intrinsic size.
fantasai: Grid and flex and multicol and writing modes allow
switching of the axes.
fantasai: That's the complication.
fantasai: And we've tried to make flex and grid consistent.
fantasai: Right now the axes are not consistent in block layout.
ojan: To be fair, there are other ways in which flexbox treats
height and width differently.
Rossen: Not really.
Rossen: If you assume all you have is flexbox.
Rossen: Can we make it symmetric?
Rossen: When you hit it, you are bound to do this measuring.
Rossen: For flexbox and grid, their measuring should be symmetric.
Rossen: How do you deal with block layout when there are flex or
grid heights.
Rossen: Is there a reason we need to change anything?
Rossen: I don't think there's a need.
dholbert: This is about percent on something that happens to be in
a flex container.
dbaron: Some of the issue is that sizing is attempting to define
for block.
TabAtkins: We can special-case as appropriate, but right now
they're not correct.
TabAtkins: If we do adopt this, right now we don't allow
intrinsics to be definite.
TabAtkins: If we correct for float and make a general principle.
TabAtkins: Then min-sizing are definite.
dbaron: Things for floats are true for abspos,
dbaron: You need a mechanism for when things that were indefinite
are definite.
dbaron: Percentages inside table cells for example.
TabAtkins: It's not hard to have in spec, in this case this length
is indefinite.
TabAtkins: Just trying to figure out what default should be.
TabAtkins: If we define that intrinsic sizes are considered
definite by default, then that fixes our issue.
TabAtkins: We can then simply text in flexbox.
Rossen: What would be a simple example?
TabAtkins: Treat intrinsic sizes as definite when they don't rely
on layout, by default.
TabAtkins: Shrink wrapping would be definite for resolving
intrinsic sizes on children.
TabAtkins: If you say height: min-content that requires layout, so
would be indefinite.
astearns: Any objections?
RESOLVED: Intrinsic sizes that don't require layout to recalculate
are treated as definite.
Flexbox
=======
Percent Sizing
--------------
<Rossen> https://drafts.csswg.org/css-flexbox-1/issues-cr-20160301#issue-1
<fantasai> http://drafts.csswg.org/css-flexbox-1/issues-cr-20160301
TabAtkins: This will be covered by general sizing behavior.
astearns: Are we going to republish?
dholbert: Should we reopen percent padding discussion?
dholbert: Would be useful before we republish.
dholbert: We have several more bugs this week.
dholbert: Currently spec says browser decides.
TabAtkins: If we want to start on this I have numbers.
TabAtkins: People using percentage in margin or padding: .035%.
TabAtkins: This is any usage, including usual hacks.
dholbert: Most people using margin/padding are expecting
traditional block behavior.
TabAtkins: Nobody cares and we should do what is consistent.
tantek: There's different opinions on what is simplest.
dholbert: I want to change.
dholbert: I want to see if Microsoft is still concerned.
<Rossen> https://developer.microsoft.com/en-us/microsoft-edge/platform/usage/css/padding-left/
jensimmons: If this group that thinks it's a rare use case that
people use percentage in margins, you're wrong.
jensimmons: Every person using responsive web design uses this.
jensimmons: Using best practices
jensimmons: every single person is using percents in margins and
gutters.
TabAtkins: Our calculations were looking for percentage margin on
a flex item.
dbaron: A percentage of what.
jensimmons: The relevant is what percentage of people using flex.
ojan: It's 11%.
ojan: The most useful thing would be examples.
ojan: The question is does it resolve against width or height.
tantek: If you were to use flex in responsive design, would you
use percentage margin/padding?
tantek: If the answer is yes, then I'd ask what your expectations
would be.
TabAtkins: Beyond bug reports asking for block behavior.
tantek: There are lots more new authors, and simplifying model for
them is more important than maintaining past behavior,
shane: Support for responsive design is separate from backwards
compat,
jensimmons: Are people going to need to use percent in flex?
tantek: It's an orthogonal question.
ojan: Maybe jen can come back with examples, and we can discuss.
ojan: And it doesn't sound like MS has changed their behavior.
astearns: Anything else for flex?
TabAtkins: That's all we needed.
Running layout to compute intrinsic sizes in the width axis
-----------------------------------------------------------
TabAtkins: There's one more.
TabAtkins: Running layout to compute intrinsic sizes in the width
axis.
TabAtkins: Two chrome implementations have run into this;
TabAtkins: have a column multi-line flexbox
TabAtkins: that you're floating,
TabAtkins: it has column wrap.
TabAtkins: To find width of column wrap flexbox you need to do
real layout
TabAtkins: and that's problematic.
TabAtkins: Edge does this correctly.
TabAtkins: Chrome does not.
TabAtkins: So things are clearly broken from authoring perspective
TabAtkins: but it's performant and consistent.
gregwhitworth: We brought this up two years ago.
gregwhitworth: In some cases you do want to do actual layout.
gregwhitworth: I think it's worth taking the effort to do it in
performant manner.
TabAtkins: So performant easy stupid one? or the harder one that's
correct?
esprehn: Doesn't servo do this in parallel?
esprehn: So they would object.
fantasai: This problem exists for a lot a things in css
dbaron: Only things from the past few years.
fantasai: Orthogonal flows have existed for awhile
TabAtkins: The similar examples that work are multicol
TabAtkins: but flex can have different widths in column wrap.
fantasai: But you need to know how many columns in multicol,
so it's the same problem.
iank: This is if auto-width.
<fantasai> First draft of CSS Writing Modes was published in 2012.
It said that logical heights are sized to fit the
content.
Rossen: Where are you going with this?
Rossen: Are you proposing we allow layout-based measuring?
TabAtkins: Yes, otherwise you can't float a multi-col flexbox
TabAtkins: If other browsers are not willing to do it...
<SimonSapin> Yes this is all a big problem for Servo and I don’t
know what to do about it :(
plinss: It doesn't matter if you're performant if you're always
delivering the wrong answer.
ojan: I feel torn. There's the obviously correct one... in chrome
we won't be able to do this anytime soon.
cbiesinger: We are considering a rewrite of our layout engine.
ojan: But this is two years away.
dbaron: A few years ago, intrinsic width was a rather clean concept.
fantasai: That no one understood.
dbaron: There was some architectural sense to it.
dbaron: I'm concerned about what's been happening to it
dbaron: and how it's tying web tech to current implementations.
dbaron: Like how Servo has something that works with stuff two
years ago, but not current stuff.
dbaron: Especially as it aligns with how processors are evolving.
Florian: The number of cores is stagnating.
esprehn: This isn't the right forum to discuss if Servo is the
right thing.
Florian: But doing this doesn't invalidate Servo.
Florian: We shouldn't make everything parallelize-able even at the
expense of author expectations.
dbaron: Servo parallelizes that breaks up the tree.
dbaron: Start at top, pass info to leaves, return other info up.
dbaron: There's a cost to passes.
dbaron: Pass one moves information
dbaron: pass two is the layout
dbaron: more passes are costly.
SimonSapin: What dbaron just said.
SimonSapin: In some cases we already need to sequentialize layout,
like floats and counters.
SimonSapin: Doing intrinsic width requiring layout is probably not
impossible without throwing it all away.
SimonSapin: I don't know yet how complex this will be.
TabAtkins: We might allow the JS plugin for sizing to rely on
layout.
iank: This is a houdini topic.
plinss: There are a lot of other layout problems that css hasn't
done yet
plinss: and they mostly fall into this category
plinss: and if we cut this off now, it's very short-sighted.
TabAtkins: IE is ok, we're torn, Servo doesn't like it but can
slow-path it.
TabAtkins: Authors 100% have a preferred behavior.
dauwhe: And w3c has principles to answer this question.
astearns: Is there a gecko consideration?
dholbert: It will take some work
<TabAtkins> Test case:
http://software.hixie.ch/utilities/js/live-dom-viewer/saved/4176
<TabAtkins> ^^^ if the dark green expands to fill under both lime
boxes, you do layout to calculate intrinsic sizes
plinss: Authors will always be able to blow things up.
dbaron: We also want web performance to be predictable.
plinss: I remember when it took 30 seconds to resize 4 levels
of nested tables.
plinss: If we're not giving authors what they need, what are we
doing?
plinss: The authors expectation is to do the right thing.
shane: Yes.
plinss: They're giving a bullshit answer for performance.
gregwhitworth: 99% don't know the predictability that you know
because you work on the engines.
dbaron: And floats were defined for something other than what
people are using them for.
gregwhitworth: Had we addressed this two years ago... IE11 laid
out floats to get size.
gregwhitworth: I do want to back what plinss said.
gregwhitworth: In case of conflict, consider users over authors
over implementors over specifiers over theoretical
purity.
dbaron: There was no consensus for layout, and there was consensus
for doing what we knew how to do.
gregwhitworth: Can we start, though? I know there's a burden of
work. But for the authors and the platform, we need
to do this in performant ways.
fantasai: This is even more clear than the float case.
dbaron: I think this is a rewrite the layout engine thing.
dbaron: We don't have the resources to do this.
dbaron: There might be other ways to fix the broken behavior.
<TabAtkins> http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=4177
(looking at test case link above)
<shane> http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=4179
<-- content occlusion
TabAtkins: The spec mandates edge's behavior
TabAtkins: so do we leave it alone, or do the stupid fast thing?
dbaron: The way I'd look at describing an intrinsic width
mechanism to do this
dbaron: a column wrapped flexbox is an orthogonal flow.
dbaron: So if you have one of those things floating, you compute
intrinsic heights, then do width as output.
cbiesinger: Blink doesn't deal with that, doesn't need height
until layout.
dbaron: I think that's looking at it backwards.
dholbert: In the test, there's a set width and height on the flex
items.
dholbert: If it was text you'd have to do layout.
dbaron: That depends on what heights or widths are specified.
dbaron: If there are few enough, you're not going to get a
sensible layout anyway.
gregwhitworth: What do you mean?
dbaron: You're not going to like the results.
gregwhitworth: You're assuming everything is auto.
dbaron: Right.
dbaron: Part of the problem that led us into this is not treating
the orthogonal flexbox as orthogonal.
TabAtkins: Possibly.
dbaron: I think some of that weird behavior is from the same
problem.
TabAtkins: The weirdest behavior is to avoid t-shaped documents;
TabAtkins: like auto height of 100vh for mixed direction things.
TabAtkins: A column flex box should not have those fix-up things
that apply
TabAtkins: to text.
TabAtkins: There might be some stuff from orthogonal flows we
could import
TabAtkins: but the general case won't give us good results.
dbaron: 'cause that's the way they flow
dbaron: Flexbox today has so many patches to get good results.
<dholbert> FWIW, here's a testcase with no specified heights on
the items, and with multiple lines of text in each:
http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=4180
<dholbert> Edge gets that "correct" (per authors' expectations) --
no overflow ^
fantasai: I don't understand what you mean by “act like orthogonal
flows”.
TabAtkins: They do height first, then width.
cbiesinger: This is different because it's doubly orthogonal.
dbaron: It's two layers of orthogonal nesting.
dbaron: Getting orthogonal stuff only makes sense with widths.
fantasai: It won't wrap unless there's a constraint on the
container.
fantasai: In the case of writing modes, we impose the 100vh rather
than calculating as max content
fantasai: but column wrap flex uses max content.
dbaron: The problem is not that you want width on layout, but you
want the auto size calc for column wrapping flexbox in
that dimension
dbaron: rather than in the other way.
gregwhitworth: However you want to solve it is fine.
dbaron: I would really like intrinsic widths to be not dependent
on layout
dbaron: and I think there are good ways to do that;
dbaron: except for floats
dbaron: except for block formatting contexts that contain floats
and texts.
TabAtkins: I'd be happy to defer
TabAtkins: until we can prepare some ideas.
TabAtkins: I don't want to put dbaron on the spot right now.
TabAtkins: I want more time to think.
dbaron: OK.
astearns: The original question is do we want to do anything
before we publish flex
astearns: and the answer is no, we publish.
astearns: So let's take a break
astearns: we do need some topics from tue and wed.
<break duration="NaN">
Scribe: fantasai
CSS Containment
---------------
Florian: Why don't we have a public working draft?
TabAtkins: We were waiting on layout and ?, but I'm cool with that.
dbaron: I have an open bug.
dbaron: On the title of the spec.
dbaron: Should be level 1 rather than level 3.
TabAtkins: There's also an open issue about overflow: clip
TabAtkins: Can I publish a WD of css-contain-1?
RESOLVED: Publish FPWD of css-contain-1 after edits on overflow
dependency
<dbaron> BTW, the reason I noticed the level being 3 rather than 1
was that we submitted *tests* for the spec, and Shepherd
complained that they weren't associated with the spec!
<dbaron> (And that one bug report was based on having it on for
nightly & aurora but off for beta & release.)
Control Characters
------------------
<dbaron> gregwhitworth, fwiw, we have one bug report on visible
control characters,
https://bugzilla.mozilla.org/show_bug.cgi?id=1220462
TabAtkins: So, on control chars.... we lost the data
TabAtkins: It was on Emil's server, but then he shut it down and
it's gone.......
gregwhitworth: {///}
gregwhitworth: We're not surprised people are running into problems.
gregwhitworth: That's why we wanted to announce and do a
coordinated PR push.
gregwhitworth: And why we want everyone to have it behind a flag,
so that we can coordinate a release.
Received on Tuesday, 24 May 2016 23:36:29 UTC