- From: Dael Jackson <daelcss@gmail.com>
- Date: Fri, 29 May 2015 21:23:27 -0400
- To: www-style@w3.org
text-decoration-skip
--------------------
- RESOLVED: Add leading-spaces/trailing-spaces to
text-decoration-skip in L4. Change default behavior to
skip leading/trailing spaces.
Add UA rule that <ins>/<del> don't skip anything.
Add note from L3 to L4 indicating impending changes.
Box Percent Sizing
------------------
- There was ample discussion about possible solutions to the
confusion around box percent sizing. The potential solutions
were:
1. global switch box-percent-sizing
2. switch as keyword on some properties
3. ip + bp, usable in some places
4. Nothing, settle on block
5. Nothing, settle on symmetry
- The discussion was then split into a decision between options 4
and 5 and a separate decision on if there should be a switch
at all (1, 2, and 3).
- RESOLVED: Flexbox top/bottom margins and padding resolve against
height.
- RESOLVED: No switch, for now anyway.
===== FULL MINTUES BELOW =======
Scribe: fantasai
text-decoration-skip
--------------------
Florian: A while ago we resolved to add trailing-space value to
text-decoration-skip in L4
Florian: When using in combination with pre-wrap, you might have
preserved spaces at the end of the line. Do these get
underlined or not?
Florian: In Microsoft Word they do not.
Florian: We added a new value to be able to control this.
Florian: Default currently is underlining everything.
tantek: Why add a value for the common case? Why not just make
that the default?
tantek: Barring compat problems, the default should be the desired.
Florian: One option is underline by default, switch off.
Florian: Another option is don't underline by default, switch on.
Florian: Third option is auto value by default, which can depend
on the type of pre-wrapping.
Florian: Wanted to bring up what the default should be, so that L3
has whatever we think the default should be.
Florian: So summary is initial value:
1. objects
2. objects trailing-spaces
3. auto (depends on white-space value)
Florian: Related issue is whether to skip leading spaces.
Florian: Judging by word processors, they don't switch behavior
based on text-alignment.
Florian: Microsoft Word underlines leading spaces but not trailing
spaces.
Florian: Not entirely sure if intentional to be asymmetric.
tantek: Leading spaces are visible, so kind of makes sense.
Trailing spaces are invisible.
Florian: That's true for left-alignment. Not true for
right-alignment.
tantek: It would be good to know if there's even a single web page
with right-aligned pre-wrap text.
fantasai: Probably not.
fantasai: But I would prefer to keep the behavior symmetric.
fantasai: Another consideration is that underlining indicates
links, and those spaces are clickable.
gregwhitworth: What is % use cases for links vs decoration?
Florian: pre/pre-wrap is used a lot for code.
Florian: Trailing spaces affect layout in pre-wrap.
fantasai: If we're doing it for pre-wrap, should do it for pre.
fantasai: I think if we didn't use underlining for links, then I
would say don't underline leading or trailing spaces.
Looks better.
fantasai: But since we do, I think we should default to
underlining,
fantasai: Since that indicates the clickable area.
Bo: We looked into use of underlining, and it's almost always used
for links.
Bo: We were considering, for a11y, to restrict underlining to just
links, and it didn't seem like it would be a problem.
[Florian describes case of link breaking across lines, with
leading/trailing spaces]
tantek: I don't buy the argument that we should underline the
spaces because they're clickable.
tantek: Blocks have plenty of space that are clickable, not
underlined.
...
Florian: ...
fantasai: I don't have a strong preference on underlining vs
not-underlining,
fantasai: But want leading/trailing to be symmetric.
tantek: Don't buy that argument.
Florian: People use spaces for indentation, want them underlined.
fantasai: Really? That looks terrible. Why is that wanted?
[discussion of what is ugly]
gregwhitworth: I think we should put all three options on the
board, point at the ugly one, and say, don't do
that.
plinss: For diff tracking, want to show underlining on spaces as
well, to show what exactly is added/removed.
tantek: Can't imagine you want to see underlines, unless you're
trying to show where the spaces are for some reason.
plinss: Might make sense to have the default be one way, but have
the UA default style sheet for <ins>, <del>, <u>, <s> not
skip anything.
fantasai: I don't think we can change default behavior for <u> and
images.
Florian: So, proposal is to skip leading/trailing by default.
Florian: And UA stylesheet for <ins>/<del> underlines spaces
[Unsure on <u>/<s>]
Florian: Implies we add leading-spaces.
fantasai: Or edge-spaces.
Florian: Good point. Do we need them separately-controllable?
tantek: Microsoft Word does that. Probably not an accident.
fantasai: I'm not so sure about that....
Florian: So anyway, proposal is that initial value skips objects,
leading and trailing spaces.
Florian: Suggest that UA stylesheet skips nothing for <ins> and
<del>, skips objects (as currently) for <u> and <s>.
...
dbaron: Seems weird to change default behavior and change that in
the UA sheet for a couple elements.
plinss: ...
dbaron: I suspect most of the text decoration on the web is not <u>
and <s>; treating those as especially legacy seems odd.
Florian: Proposal makes sense to me, but breaks compat.
dbaron: I think I'm fine to change the default for the property.
Can see use case for having different behavior on <ins>/
<del>. Think it's weird to treat <u> and <s> differently
from the default.
dbaron: One more quirk I'd rather not add, unless there's a good
argument for it.
Revised proposal: skip leading/trailing spaces, <ins>/<del> don't
skip anything
Proposal: add leading-spaces / trailing-spaces values to
text-decoration-skip
fantasai: I'm OK with the new defaults, a little unsure about the
two keywords.
tantek: It's worth putting in draft, then see if anyone screams.
Florian: L3 or L4?
fantasai: I think we should put into L4 draft, get some feedback,
add a note in L3 that we might switch default behavior
as in [this draft over here],
fantasai: in a future CR update.
tantek: Make it a stronger statement -- it's resolved, not might
happen.
tantek: Capture the fact that there's a consensus on the changing.
fantasai: We can change the default easily in L3, but wouldn't be
able to add UA stylesheet rules without the new values
from L4.
[Bert asserts that WDs can change]
[plinss suggests we move on]
RESOLVED: Add leading-spaces/trailing-spaces to
text-decoration-skip in L4. Change default behavior to
skip leading/trailing spaces. Add UA rule that <ins>/
<del> don't skip anything. Add note from L3 to L4
indicating impending changes.
Florian: Can't change behavior without new keywords.
fantasai: Sure we can.
fantasai: Another issue is, this is getting unwieldy. To skip one
new thing, need to re-specify the whole initial value,
which is now three long values.
plinss: Let's refine it in L4. L3 is in CR, stable for 2 years.
plinss: Moving on.
<Bert> (So that implies the initial value in L4 will change to
'objects trailing leading'? Seems fine, but just
verifying...)
<Florian> Bert, yes
Box Percent Sizing
------------------
Rossen: This was a discussion brought up a couple months ago.
Brought up by blink team, wrt implementing flex.
Rossen: They came back and said that resolving top and bottom
percentages for padding and margin out of height instead
of width kind of doesn't make sense to us and harder to
implement for us.
Rossen: Bunch of discussion of what is expected behavior, why does
it make sense to have top/bottom % to resolve against
width rather than height.
Rossen: In summary there was some exchange back and forth.
Rossen: Having symmetric layout makes a lot of sense for
app-centric layout.
Rossen: Other behavior makes more sense for auto-height document
flows.
<Rossen> http://jsbin.com/pekiyuqalu/1/edit?output
* fantasai kindof leans towards Ojan's POV on this issue
Rossen: There's a fixed-size div with items with % padding and %
width/height.
Rossen: One thing we identified early on in flex development,
Rossen: is that being able to stretch inside flex items is really
useful.
Rossen: Here when I have 100% to the inner item, in the case of
document flow that will compute to auto because its parent
has height auto.
Rossen: That means that the height will be shrink-to-fit.
Rossen: If this were a flex item, the height of the inner item
would actually resolve to 100% of the available height.
Rossen: That happens because the flex item is stretched by default.
Rossen: The one pattern that we can start noticing here is that in
traditional flow layout, usually people think of the
document in some kind of continuous media.
Rossen: Things wrap, maybe have some tables, but the only thing
you can take a hard dependency on is the available width.
Rossen: This is what we resolve most percentages out of.
Rossen: All horizontal % resolve against width, as well as padding
and margin in the vertical dimension.
Rossen: All of these values resolve from this available width.
Rossen: If you have % height, that's a hard problem, we'll just
default to auto,
Rossen: And we have this kind of asymmetric behavior.
Rossen: Flexbox, as well as Grid, started taking a different
direction.
Rossen: How about we figure out a way to fix both the width and
the height, so that when resolving percent ...
Rossen: If I have an item which has % width, resolves against
width.
Rossen: If I have an item with % height, should resolve against
height.
Rossen: This is how we spec'ed Flexbox,
Rossen: And Grid.
Rossen: In this example, we have percentage height, width, padding,
Rossen: Both horizontal and vertical ...
Rossen: If I specify margin or padding with just one number, want
the same size all around -- resolve it from just one of
these dimensions.
Rossen: That is a valid use case.
Rossen: You can use Grid or Flexbox to have layout that simulates
flow layout.
Rossen: I think the one use case that was brought up was an image
gallery, e.g. 4 columns, want to have equal margins around
photo in both dimensions.
Rossen: This is Chrome's implementation. Here's it's a block. If I
switch and make it a flex item...
Rossen: Point I'm trying to make is that the flex implementation
in Chrome will look basically like so...
<Rossen> http://jsbin.com/rivisiyifa/1/edit?output
Rossen: This is our current implementation in Edge.
Rossen: We resolve padding and margins against the available width,
Rossen: The height is still 100%.
Rossen: All heights are hard, now we're like they're kinda sort of
hard. Saying paddings and margins are hard.
Rossen: This isn't really quirky behavior.
Rossen: One proposed solution that we came up with was to have a
switch basically that allows both of these.
Rossen: If you want to have block-layout % resolution, should be
able to express that,
Rossen: And if you want it symmetric, should be able to express
that,
Rossen: And this example does exactly that.
Rossen: On :hover, I'm triggering box-percent-sizing: symmetric.
Rossen: (This is just a demo on my box, not going anywhere besides
this room.)
Rossen: To me, it still seems strange that we are going to the
extent of resolving the heights, but not resolving top and
bottom paddings.
TabAtkins: If flexbox is auto-sized, but flex item is % height, it
will resolve.
[Rossen shows through example]
Rossen: We're going to a greater effort to define available width
and available height that you can depend on.
Rossen: We measure the content, then go back to define the
available height,
Rossen: Allows % to resolve.
Rossen: So we're doing a lot of work to keep this symmetric
between available widths and heights.
TabAtkins: I agreed with you at first. That's why we specified the
way it is today.
TabAtkins: Our implementers' view is that, yes, while it is
slightly more difficult for us to implement, that's
besides the point.
TabAtkins: However, our reason for not wanting to implement this
is largely,
TabAtkins: Nobody cares. They're not used much for anything,
except one thing: hack to do aspect ratios.
TabAtkins: A lot of people using this hack to do aspect ratios.
TabAtkins: This padding hack no longer works in flexbox,
TabAtkins: And Mozilla gets bug reports about this.
TabAtkins: We're not opposed to having a switch, but want block
behavior to be the default.
<shane> an example of the bugs filed on firefox that Tab was
talking about: https://bugzilla.mozilla.org/show_bug.cgi?id=958714
<leaverou> Sorry for pointing out the obvious but if we all know
that aspect ratio is needed a lot, why aren't we
discussing how to add an aspect-ratio property instead?
<tantek> leaverou++
tantek: You're seriously using aspect ratio hack for this?
TabAtkins: Yeah.
dbaron: What is this hack?
TabAtkins: Say you want a variable-size element to always maintain
a 2:1 aspect ratio.
TabAtkins: You give the parent padding: 50%, relpos, and make the
child abspos to fill that.
<TabAtkins> <wrapper style="position: relative; padding-top:50%">
<real-stuff style="position: absolute; t/r/b/l: 0">...
</real-stuff></wrapper>
?: Why not add an aspect-ratio feature?
TabAtkins: No opposition to that. I put up a bad proposal for it.
TabAtkins: My proposal was bad. It has problems. I should feel bad.
TabAtkins: At some point, will do it properly. But in the
meantime, this hack is where we're at.
TabAtkins: Anyway, that's our argument for wanting to revert the
change.
fantasai: I disagree with having a switch. Mode switches for
interpreting existing rules are problematic, when they
combine with declarations that weren't expecting it.
gregwhitworth: Like box-sizing.
fantasai: Right.
gregwhitworth: Would have been better to be border-box from get-go.
tantek: Yes.
<tantek> except with box-sizing, we made it a switch because that
was the default behavior that web authors/designers
actually *wanted* instead of the CSS1 spec'd default
<tantek> also - units wouldn't have solved box-sizing :P
[Rossen shows example of using percentages in height dimension]
TabAtkins: In this example you could have used 3px.
gregwhitworth: On a bigger screen, e.g. 75in TV, want it to be
bigger.
gregwhitworth: Percentages are much more responsive than just
using pixels.
TabAtkins: Case like this, the difference is pretty minimal.
TabAtkins: You could continue using the same thing, and it would
work fine resolving against the width.
gregwhitworth: It makes more sense to resolve in your own
dimension.
TabAtkins: We agree it makes more sense. But nobody cares.
TabAtkins: Percentage margins/paddings are extremely rare. Main
use is just the aspect-ratio hack.
gregwhitworth: You went into this idealistically, changed your
mind when implementability came up.
TabAtkins: They presented me with convincing data that nobody
cared.
fantasai: To be fair, TabAtkins and I were pretty ambivalent about
which way to go. Issue was Grid spec and Flexbox
disagreed, and we wanted them to match. Ended up picking
Grid since it seemed reasonable at the time.
fantasai: My opinion is that, having read Ojan's argument, I agree
with keeping things consistent across our layout systems.
fantasai: However, I'm concerned wrt compat in changing Grid to
match that. [Flexbox is incompatibile atm]
fantasai: But not super strong opinion.
dbaron: Also don't have a super strong opinion...
dbaron: But block layout has a much stronger widths as input,
height as output.
dbaron: Grid/Flexbox take input in both dimensions, different
model, percentages this way makes more sense.
* fantasai unsure if that was correctly minuted
dbaron: Don't think aspect-ratio hack is a reason to keep this.
tantek: Agree with that. If they want hacks, we can give them
hacks.
gregwhitworth: Resolving percent margins/padding against width
doesn't make sense. App developers would be happier
with percentages resolved against height.
tantek: App developers don't speak up to browsers. If we don't
speak up for them, nobody does.
<tantek> which is why I'm agreeing with you Rossen
Rossen: We do speak for them. Have a lot of app developers for
Windows apps.
Rossen: People who come from Java or C based application
backgrounds is very different than conversations with ppl
who started on the web.
Rossen: Most of these papers are used to driving their layout apps
much closer than with HTML/CSS.
Rossen: Our struggle has been, for the first year or two, was "how
do we get them out of abspos?"
Rossen: Once they started learning how Grid & Flex work, how easy
it is, much more performant, it was a big Aha moment,
Rossen: And now they're converted,
Rossen: To the point that XAML team is getting requests to be more
like HTML/CSS.
TabAtkins: We're down with a switch, as long as default behavior
is the old behavior.
fantasai: And I'm not ok with a switch.
dbaron: I don't think I'm ok with a switch either, for two reasons.
dbaron: One is that I don't like switches on principle.
dbaron: Two is that I'm not sure how easy it is to do the new
behavior for blocks.
TabAtkins: It would just go down to zero in most cases.
dbaron: The current behavior is % margins on flex items.
TabAtkins: And grid items.
shane: In the case of Android, you just can't specify percentage
margins or padding.
?: Or iOS
shane: App dev platforms don't have percentages.
tantek: What? Interface Builder totally had that in the 90s....
shane: That goes back to what Tab was saying. ppl don't use this,
except in the case of this hack.
TabAtkins: It's extremely rare.
gregwhitworth: I've used that a lot...
TabAtkins: Couldn't have, wouldn't work.
gregwhitworth: I can guarantee % are not all aspect-ratio hack.
TabAtkins: Most cases where I've used them in the past, I would
just use flexbox or grid for it, and it would work
automatically.
TabAtkins: My only web-dev cases for using margins/paddings are
more-or-less gone.
Florian: Also box-sizing.
fantasai: Yeah, a lot of cases are probably "I need to use
percentages, because I have to do math that adds up to
100%"
TabAtkins: Almost always want borders to be consistent all the way
around.
Florian: Authors use percents so that horizontally things can add
up to 100% [without calc()]. Vertical is auto-sized,
sizes are consistent.
gregwhitworth: What do you think, dbaron? Right now we're in a bad
place. IE and Mozilla agree on this.
gregwhitworth: But we don't have interop.
dbaron: I wasn't convinced that anything needed to change.
dbaron: I guess Ojan is not happy about changing Chrome.
TabAtkins: Worst case, we would change. Would highly prefer not
to, not so much for implementation reasons, but because
we don't believe this is the right thing to do.
SteveZ: It seems to me that whether or not there is usage today in
percentage padding, people would have liked to use it, you
couldn't do it with unresolved height.
SteveZ: Coming up with a definition that only really works for a
hack, which we should do a better way eventually, seems
like the wrong way to design a system.
TabAtkins: From a theoretical POV I agree.
fantasai: I don't think aspect-ratio hack would be a reason to
keep this.
SteveZ: I came away with wanting to switch.
SteveZ: Want a uniform size all the way around,
SteveZ: so I want that ability,
SteveZ: but also want the ability to resolve margins/padding
against the available height.
TabAtkins: We don't see this being used.
gregwhitworth: You can't.
TabAtkins: We don't see it in the width dimension either.
dbaron: It does seem there is a use case for people who want
something evenly around the entire size.
...
Florian: There's no right way for box-sizing, so we have a switch.
Several: No, border-box is the right way.
dbaron: The other thing we could have instead of switch is
different set of units,
dbaron: percents in either inline percents and block percents.
fantasai: pi and pb
<dbaron> or i% and b%
TabAtkins: We can't parse i%
<Bert> (ip and vp would parse)
* fantasai is ok with units, proposed that last time we discussed
in fact
* fantasai doesn't want switch property
Florian: Could also have the switch be a keyword rather than the
property.
<Bert> ('padding-top: 5% independent')
Rossen: ...
Rossen: One model is you have content that dictates how it's going
to behave in a particular container.
Rossen: Other one is container dictating how things are
distributed on that level.
[Someone mentions calc(5ip + 7bp)]
plinss: Lets you get into some really circular situations.
plinss: You'd have to be really careful about where you can use
them.
dbaron: Percentages on some of these properties are function of a
size of the parent,
dbaron: and if cyclic, treated as auto,
dbaron: fall back to zero.
dbaron: Those rules would continue to hold.
TabAtkins: Define it as part of <percentage>.
fantasai: Don't think you want to do that. E.g. line-height,
font-size, not really useful.
dbaron: Only want them in certain functions that take <length> and
<percentage> and percentage is relative to size of the
parent.
Florian: This is why I think a special keyword would make more
sense...
...
TabAtkins: SVG has some things that use length of diagonal, could
finally calc() that.
plinss: So, are we getting to a resolution?
Proposals:
1. global switch box-percent-sizing
2. switch as keyword on some properties
3. ip + bp, usable in some places
4. Nothing, settle on block
5. Nothing, settle on symmetry
???: It could be useful for line-height, to fit a specific
number of lines in a container with a fixed height.
fantasai: I think 4-5 need to be combined; need a default in all
cases.
Florian: I just spec'ed box-sizing, and having done that work, #1
looks like a terrible idea.
Rossen: ...
tantek: No, I agree with Florian, this is much worse.
<astearns> would ip and bp have too many restrictions on use (bp
on height of floats, for example).
gregwhitworth: This is just margin/padding.
fantasai: How do we know? It's called box-percent-sizing. Could
also affect width/height.
Rossen: Only discussing effect on margin/padding.
fantasai: 2 & 3 are strictly more powerful.
fantasai: You could have margins/padding be different.
fantasai: Also doesn't have cascading problems.
fantasai: The cascading problem is like this:
fantasai: Somebody writes a declaration in percentages, expecting
it to work a certain way.
fantasai: Somebody else writes a box-percentage-sizing rule
together with his percentage declaration, expecting it
to work together in that way.
fantasai: The box-percentage-sizing rule ends up affecting the
first declaration, changing the way it's interpreted in
a way that's not expected.
Rossen: My choice is 1, but prefer 5.
[Florian explains difference between 1 and 2]
Florian: 2 puts keywords in margin/padding declarations, so you
can have margins and paddings have different values.
Florian: Also doesn't have the cascading problem fantasai pointed
out.
shane: 3 is better for object model.
TabAtkins: Not sure about that, think it's fine.
<leaverou> A benefit of using units is that we can in the future
extend the cases they can be used in, whereas we can't
change how a switch behaves.
<fantasai> we can't change how a global switch behaves, but can
change 2 or 3
dbaron: 2 questions
dbaron: 1. Should we have a switch? 2. If so, which one? 3. What
is the flexbox/grid default?
<tantek> 1. no, 2. ΓΈ, 3. flexbox/grid % based on height, not block
plinss: 4 vs 5
<dbaron> #4 - 5 votes (tab, bert, fantasai, shane, ian)
<dbaron> #5 - 5 votes (steve, greg, peter, rossen, tantek)
<dbaron> (others abstaining)
* astearns must be confused as to what 'block' and 'symmetry' mean
in these choices
<SimonSapin> astearns, "like display:block", and "percentages
refer to the same direction"
<bantasai> block means block-layout rules symmetry means resolve
against your own axis
* astearns was reading 'symmetry' as the margins are all
symmetrical :)
<fantasai> sorry :)
[Rossen asks for feedback from lea and tantek]
leaverou: I think #3 is my preference. We can't extend a global
switch, but we can extend where units can be used.
leaverou: #2 is awkward, especially if you use the keyword in
places where you have multi-valued / complex values.
leaverou: I think authors are already used to percentages
resolving against widths, even for vertical
margins/paddings.
leaverou: So I think there's a learn-ability benefit there.
leaverou: Even though, if we were designing from scratch, would be
better to resolve from height,
leaverou: but many years from against height.
tantek: I actually disagree with that. This is a constant source
of confusion. Would like it to stop being a source of
confusion.
tantek: This confuses *everybody* using CSS.
tantek: We have this change to get Flex and Grid right, as layout
modes.
tantek: Customers that use that kind of layout on native platforms.
tantek: Better to say "hey, use this new layout mode that does it
right".
tantek: Lower barrier to entry, reduce number of things that make
you go "huh?"
* astearns agrees with tantek
leaverou: But old models still work the old way.
tantek: What models? Goal of flex and grid is to not need to learn
that stuff.
Florian: Nice speech. Add my vote to #5
* fantasai might switch too :)
[Greg and Tab argue over compat loads of Blink flexbox vs
Microsoft grid]
SteveZ: You can get 3 on 2 by having 2 keywords, keywords being
'inline ' or 'block', and still use percentage value.
TabAtkins: We only got two responses when we asked authors for
feedback.
TabAtkins: Two non-sequitur replies.
fantasai: No, one was a valid answer.
smfr: Dave Hyatt is willing to change WebKit to #5
* Bert thinks a CSS-T without flexbox and a CSS-U with *only*
flexbox would make sense, but attempts in the past failed
and they seem stuck together forever.
plinss: In light of discussion, let's redo the vote.
#5 - 13 (smfr, Florian, dbaron, steveZ, Andrey, Jet, Chris, Lea,
Greg, rossen, plinss, tantek, asteans)
#4 - 4 votes (shane, TabAtkins, Bert, Ian)
RESOLVED: Flexbox top/bottom margins and padding resolve against
height.
plinss: All in favor of having a switch for behavior
[half a vote]
plinss: All those opposed to a switch
<dbaron> (I'm abstaining)
4 - TabAtkins, greg, fantasai, tantek
RESOLVED: No switch for now
<astearns> late vote against switch - unit would be better
<fantasai> astearns, vote was for/against any of 1,2, or 2
<fantasai> if no way to switch behaviors is 0
<fantasai> vote was 0 vs. 1+2+3
<astearns> ah, ok
Received on Saturday, 30 May 2015 01:23:56 UTC