- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 11 Mar 2015 20:31:58 -0400
- To: www-style@w3.org
Sizing
------
- RESOLVED: Add gregwhitworth as editor to Sizing
- RESOLVED: Auto margins assumed to be zero for intrinsic size
computation
- The spec authors will work out a way to address the various ways
percentages work.
Text
----
- RESOLVED: Treat replaced elements as ideographic chars for
line-breaking. Based on data, possible add an
exception for  .
- It was agreed that the Text spec says that control characters
should show, but everyone should coordinate when the change
is made so that no one browser gets inundated with bug
reports.
- RESOLVED: Everyone will go coordinate on September being when
control characters (Unicode class Cc) become visible.
Implementations should aim to have it in their
codebases by June, ready to go out in the next release
after the coordination date.
====== FULL MINUTES BELOW =======
Sizing
======
Scribe: tantek
Editor
------
RESOLVED: Add gregwhitworth as editor to Sizing
ACTION: fantasai figure out what it was wrt percentage sizing
<trackbot> Created ACTION-670
Max-Content Sizing
------------------
fantasai: We were discussing the two different concepts of
"max-content" sizing: the size that the thing wants to
be (e.g. for multicol, col-width * col-count) vs. the
width at which it will be the shortest and not waste
space horizontally (which for multicols is col-count*max-
content of the content).
fantasai: Conclusion was that 'max-content' keyword would refer to
the first concept, since that's what authors really need
for stuff.
fantasai: In the cases where we need the second concept, we'll
call it the super-max-content for now, probably won't be
exposed to authors.
<SimonSapin> fantasai, What's the intrinsic size of div in
<div style="width: auto"><p style="width: 100px;
margin: 10%"></div> ?
dbaron: This is the thing where the only difference between them
is multicol.
fantasai: I think so. Although gregwhitworth's float case is one
that might be relevant, too.
dbaron: I don't think there's a case for having this extra spec
concept.
dbaron: There are lots of concepts that exist that we don't write
code for.
dbaron: Putting it in a spec creates a risk that somebody ends up
implementing the concept that isn't used.
TabAtkins: So we define max-content, put a note in the spec saying
that we might need this extra concept.
TabAtkins makes an example:
multicol element w/ columns: 2 200px
TabAtkins: It will lay itself out at 400px.
TabAtkins: Suppose you have an unbreakable word?
fantasai: Could be breakable
fantasai: Actually, that's an issue, if it's unbreakable, you'll
have min-content > max-content.
dbaron: That is severely broken.
dbaron: It's a spec bug if max-content < min-content.
TabAtkins: You'll get 2 columns of 300px each.
fantasai: We're mixing up a bunch of different concepts
fantasai: (goes to whiteboard)
fantasai: If container is 600px
fantasai: multicol element will lay out 300px wide columns
fantasai: but at 400px, 200px each column, the first line would
wrap.
fantasai: In the 300px case it doesn't wrap because it fits
fantasai: and the height of my thing is going to be 1em.
fantasai: This got shorter, I'm wasting 58px of space
fantasai: (...) so 500 px is a point in the layout that stuff
changes.
fantasai: You have unwrapped all of the lines
fantasai: beyond 500px you start getting extra space
fantasai: so this is kind of like a breakpoint in the layout.
fantasai: If you make the thing any narrower than 400px
fantasai: then you're going to drop down to 1 column
fantasai: then you have another concept.
fantasai: What is the minimum size that you don't get overflow?
fantasai: Take the length of the longest word
fantasai: multiply it by the number of columns
fantasai: the longest word basically
fantasai: whatever that is is the min content size.
SteveZ: I think I get min content and unwrapped lines.
SteveZ: But it's this funny thing in between that I don't get.
fantasai: This size, which is I want to be that size, that one
could be in the middle or smaller than the min content
size, or larger than the intrinsic max size.
Rossen: Let's go one column.
Rossen: You have 1 col with 200px.
Rossen: You have min content 100.
Rossen: (draws on white board)
Rossen: Your content inside is 100.
Rossen: Your max is 150.
Rossen: Let's say there are 2 words.
Rossen: In this case you're happy.
Rossen: You're going to have 200px content width.
Rossen: I think there are three cases:
Rossen: 1) both min & max > 200
Rossen: 2) or only max > 200
Rossen: 3) happens when you start multiplying the columns
Rossen: What doesn't currently work, what are you proposing to
change
Rossen: for case #1: both min & max are strictly > col size
Rossen: case #2: only max > col size
Rossen: case #3: ...um
Rossen: is you have more than one column
Rossen: for completeness.
Rossen: Same as above but with the opposite sign.
fantasai: So the question we have is
fantasai: when you have a multicol element that is shrink to fit
fantasai: what size does it end up being?
Rossen: Let's answer the 1 column question first.
Rossen: before multicol.
dbaron: Isn't 1 column equivalent to non-multicol?
Rossen: Exactly.
fantasai: A non-multicol doesn't have a column-width.
dbaron: I am not at all convinced that we should consider the
column width at all for any intrinsic size computation.
Rossen: You're saying 1 column is equivalent of having a block.
dbaron: Yes.
Rossen: When I have a block with 200px, what it reports to a float
trying to wrap around it, it will report 200px min & max.
Rossen: For single column width 200px, it shouldn't honor the
200px.
dbaron: Column width is a minimum, or more like maximum.
Rossen: Same as a table cell.
fantasai: No. it is different.
fantasai: If you have a block...
fantasai: If col width is 200px.
fantasai: If my block is 50px.
fantasai: My column will be 50 px.
fantasai: The column width is a suggestion.
dbaron: Column width is merely a hint for determining the column
count.
fantasai: Yes.
dbaron: Although I don't quite remember...
dbaron: The formula for when both column count and column width
are specified,
dbaron: it takes the smaller of the two numbers.
fantasai: Yeah.
fantasai: If your container is 150px wide, the column will be
150px wide.
fantasai: If your container is 250px...column will be 250px.
fantasai: If your container is 400px, your column will be 2 cols
of 200px each.
fantasai: We had (...) but we ran into the shrink to fit sizing in
the multicol spec says if you have a float, and you have
enough space, then the multicol will be columns * colwidth
fantasai: and that's implemented.
fantasai: If as an author I specify hey, I want you to shrink to
fit around this thing
fantasai: that's what they expect.
fantasai: If they have a long line of content, they don't expect
the columns to get wide.
fantasai: We have a problem here.
fantasai: It's really important that the shrink to fit max is,
is...
fantasai: It's important that the shrink to fit max include the
maximum of the min content size, and then column count *
column width
fantasai: that way you're maintaining that invariant.
fantasai: You're also getting the thing the author asked for.
fantasai: We have this other concept of unwrapped.
fantasai: Authors will not want that.
fantasai: You will have layout land at that answer for certain
cases.
fantasai: That's a break point in the layout where it won't get
shorter.
fantasai: It might become a useful concept if for example.
fantasai: If you have tables and you're doing orthogonal flows
fantasai: you might want things to be as few lines as possible.
fantasai: Without orthogonal flows it's not that interesting as a
concept.
fantasai: We also have a similar issue:
fantasai: the shrink to fit sizing takes the width of the widest
float
fantasai: but if the box is wider its content could be wider by
placing the floats side-by-side
fantasai: like gregwhitworth brought up.
fantasai: The shrink to fit expectation is narrower than (...)
fantasai: That's a concept that we don't have a clear idea where
it would be used
fantasai: but I have a feeling it will show up.
Rossen: go back to .(...) what are we calling it?
fantasai: Max content
fantasai: We have 3 concepts:
fantasai: One small concept,
fantasai: two big concepts.
fantasai: The author gets exposed to these through shrink to fit
sizing and the max content keyword,
fantasai: when the author is doing grid layout for example,
fantasai: then they're going to expect to be this size and not
wrap the text.
Rossen: In this case, 600px, 2 columns.
Rossen: 300px columns each.
fantasai: Where is 600px coming from?
Rossen: min content
fantasai: If you have a really long unbreakable line or an image,
then it will be wide enough to fit that image without
overflow.
Rossen: In this case it will overflow.
fantasai: It won't.
Rossen: You will have two columns.
fantasai: When you layout a multicol element at 600px with 2
columns, each will be 300 px wide.
Rossen: Your column count has to be driven by the max of (...)
TabAtkins: This is not the size of the largest word.
dbaron: Maybe we should take some of this offline
dbaron: I'm not sure what we're trying to solve right now.
TabAtkins: (...)
dbaron: The thing you just said, you implicitly assumed two
concepts.
dbaron: I don't think you have to assume that.
fantasai: For the purposes of this discussion there are 2 concepts.
dbaron: There are potentially many more concepts.
TabAtkins: We need to be ok with multicolumn having a different
answer for that.
SteveZ: You're just defining what max content means in a multicol
situation.
fantasai: The other case is you have a bunch of floats
fantasai: and you shrinkwrap a bunch of floats.
fantasai: You could have this (...) but you actually get this
(...).
fantasai: The floats (3) could fit next to each other
fantasai: but since you asked it to shrinkwrap, current
implementations shrink them to one on a line each.
gregwhitworth: It is weird and we'll try to spec it.
fantasai: More fun times.
TabAtkins: Resolutions.
TabAtkins: Can we get a resolution that we should define max
content of multicol this way?
dbaron: I think I object to a big part of that.
fantasai: Which part?
dbaron: Most of it.
dbaron: And I want to propose an alternative.
SteveZ: The piece that confuses me with a 600px image
SteveZ: I would expect multicol to go away in that case.
Rossen: You specified the number column count 2.
TabAtkins: multicol assumes if you specify count that you meant it.
fantasai: So we need to make this correction.
TabAtkins: So we fix this in sizing now.
TabAtkins: dbaron can suggest whatever he wants
TabAtkins: and we can resolve the differences later.
gregwhitworth: We need to discuss per the mail thread what does
"min content" really mean.
gregwhitworth: We can take it offline.
TabAtkins: (...) ?
fantasai: The intrinsic size.
Rossen: So if it's the only thing you're going to get the
specified size.
fantasai: No, there is a min content size and a min content
contribution.
fantasai: There are two separate concepts.
dbaron: One of the reasons for that is that we want the width
property to accept values.
dbaron: That says use the min or max content.
dbaron: The min content size does not include consideration of
the specified size constraints
dbaron: You have to factor that into the min content contribution
for sizing of its parent, though.
gregwhitworth: You guys (Mozilla) if you have a really long
line ...
gregwhitworth: but Blink's will shrink to the size of the longest
word.
dbaron: I think this is very different than what Rossen and I were
talking about.
fantasai: It is fully defined and Mozilla's implementation matches
what it is defined as.
<gregwhitworth> Here is the min-content issue we need to discuss:
http://dabblet.com/gist/599a04c05a22f48a292d
<gregwhitworth> Discussion is here:
https://lists.w3.org/Archives/Public/www-style/2015Jan/0022.html
SimonSapin: I missed this earlier.
SimonSapin: Can we got back to percentages?
Scribe: fantasai
SimonSapin: Intrinsic size computation for blocks:
SimonSapin: You account for margin/padding/border of children
SimonSapin: But it's unclear what happens if these contain
percentages or auto values.
SimonSapin: If you compare with width of children, we have
specific text that says it's indefinite, do something
else.
TabAtkins: But for margin/border/padding we don't say.
Rossen: No interop here.
dbaron: Auto isn't interesting. Just treat as zero.
TabAtkins: Yeah.
SimonSapin: Put that in the spec.
dbaron: In gecko we do the reverse computation.
<dbaron> SimonSapin, fwiw, http://dbaron.org/css/intrinsic/#outer-intrinsic
did define it :-P
fantasai: I think this discussion was super-useful, I understand
what's going on here much better thanks to the
discussion
fantasai: Let's get together and update the spec before we lose
all the context again.
RESOLVED: Auto margins assumed to be zero for intrinsic size
computation
Inverting of Percentages
-------------------------
dbaron: Did we come to a conclusion on percentages?
Rossen: We discussed computing to zero.
dbaron: I think trying to do something useful with percentages is
good.
dbaron: We were unable to do it for width.
fantasai: I agree we should do something useful and not stupid
here.
fantasai: Shouldn't create overflow artificially.
[Rossen talks about stacking percentages]
dbaron: Tables already do this.
dbaron: Tables do inverting of percentages.
dbaron: At some point your preferred width becomes infinite, but
you never use it directly, you always min it with
something.
fantasai: With width percentages, you treat as auto for both
intrinsic size computation and for final layout.
fantasai: With percentage padding, you treat as zero for intrinsic
size computation, but then honor it for layout, which
results in overflow and bad layout.
fantasai: I think this is worth fixing.
[Rossen says something about making things better for flex, but
wasn't sure what he said]
ACTION: fantasai, Tab, SimonSapin, Rossen, gregwhitworth, dbaron
to figure this all out and spec it.
Rossen: Tonight.
plinss: Or else.
Text
====
Scribe: TabAtkins
Emoji Linebreaking Issues
-------------------------
<fantasai> https://lists.w3.org/Archives/Member/w3c-css-wg/2015JanMar/0080.html
(Member Only Link)
fantasai: First issue is about line-breaking around emoji/etc.
fantasai: There was some back-and-forth in the thread.
fantasai: The best option is to treat images as ideographic chars
for linebreaking.
fantasai: It solves linebreaking problems when images are used as
emoji.
fantasai: And gives better behavior than the current spec in
general.
fantasai: So this doesn't cause breaks right before an end
parenthesis, etc.
fantasai: Main concern is, is this web compatible?
fantasai: Right now everyone breaks around images.
fantasai: But Presto treats images as ideographic characters.
fantasai: The critical piece is that the images will break between
each other if they're siblings, which is handled by this
suggested rule.
fantasai: Only behavior change is a few restrictions we add for
ideographic chars, mainly around punctuation.
fantasai: Which you probably meant to work in the first place.
fantasai: We're taking Presto as an example of webcompat.
fantasai: We're hoping this is worth giving a shot at fixing to be
sane.
fantasai: We need to hear back from impls to see if they're
willing to implement.
<zcorpan> line breaking around images is a bit different in quirks
mode:
https://quirks.spec.whatwg.org/#the-table-cell-width-calculation-quirk
szilles: What unicode categories are these?
fantasai: Proposal is to treat as the ID class (ideographic).
fantasai: Current behavior is not actually expressible in the
unicode spec.
fantasai: Unicode puts "glue" (nbsp, etc) as a higher priority as
nearly anything else.
fantasai: But images apparently decided they have a higher
priority than forced non-breaking.
fantasai: So this change'll bring us *more* in line with the
unicode spec.
fantasai: Any comments, or should we make the fix?
zcorpan: I don't understand the consequences?
fantasai: Example: "<img> foo", you can't break after the img
any more.
fantasai: Or "(<img>)", you can't break in the parentheses
anymore, they'll stay with the image.
zcorpan: I'll search if Presto has any open compat bugs for it.
zcorpan: I also posted a link to Quirks Mode. Line-breaking there
is a bit different, at least for table cells.
zcorpan: If we change how linebreaking works around images, it
might need to be adjusted in Quirks.
zcorpan: When you calculate the minimum width of the table cell,
you act like there's no breaking opportunity around
images.
zcorpan: But when you actually lay out there might be linebreaks
there.
<koji> Are you proposing to fix just for images and leave other
replaced elements?
fantasai: For all replaced elements.
fantasai: And for U+FFFC
<koji> I'm negative, at least for <input>, that'll break too much.
<koji> I'm not sure how much we'd break for <img> though.
<Florian> koji: yes, but it depends how much content this breaks.
Hopefully not much.
fantasai: What would it break for <input>?
zcorpan: Looks like Presto has at least one bug about
"<img> foo" breaking a website due to non-breaking.
<zcorpan> "There are cases where the total width of the images
exceeds that of the containing <div> block and instead
of creating a line break, Opera displays the image
outside of the block." - url was
http://www.clasohlson.se/product/category.aspx?category=kroppsv%c3%a5rd:tandv%c3%a5rd&id=88753177&_path=251882;85177601;88752827;88753177
but probably the site has changed
<koji> Presto being bugged from users indicates that there are
legacy such content.
<fantasai> http://software.hixie.ch/utilities/js/live-dom-viewer/?%3Cstyle%3E%0Ahtml%20%7B%20font-size%3A%203em%3B%20%7D%0A%3C%2Fstyle%3E%0A(%3Cinput%3E)%3Cbr%3E%0A%3Cinput%3E.%3Cbr%3E%0A%3Cinput%3Eabc%3Cbr%3E%0A%3Cinput%3E%26nbsp%3Bfoo
<koji> In HTML4, I believe, authors used to use as a
non-collapsible spaces.
<koji> and used <input> <input>.
<koji> I'm not sure how much such content survive today though.
koji: The bug was reported to Presto by a user; that indicates at
least some users believe there should be forced break
opportunities between and <input>.
Florian: It's definitely a breaking change; the question is if
it's breaking too much.
Florian: Not surprising that Presto gets a bug if everyone else
does something different.
Florian: Unsure that one single bug is enough evidence to rule it
out. Presto survived for a while without fixing this.
fantasai: So it sounds like Greg will look into actual websites
and see what may or might not break.
fantasai: Anything else to do?
koji: I have seen editors that, when I type two spaces at the end
of a sentence, converts it into multiple
koji: Treats   as non-collapsible space.
murakami: I think the emoji and gaiji should be treated same as
ideographic chars, and do linebreaking correctly.
murakami: I don't understand why people wouldn't expect   to
not break.
murakami: That makes no sense and is a bug that we should fix.
<zcorpan> 16,311 pages in httparchive match REGEXP_MATCH(body,
r'(\ <img\s|<img[^>]+>\ )')
zcorpan: I checked httparchive for nbsp before/after an image, and
there were 16k matches.
zcorpan: About 130k pages in the set, so about 12% of all the
pages match the query.
zcorpan: Haven't analyzed whether they're broken in Presto or not,
but there's a lot of pages.
plinss: So we'll come back to this with data?
johanneswilm: This applies to <canvas> and <svg> and similar too?
fantasai: Yes.
fantasai: Another thing to consider is if nbsp is a big issue, but
nothing else is -- nbsp isn't a big deal for emoji,
they're mostly concerned about punctuation being correct.
fantasai: We could just say that it behaves as an ideographic char
*except* it still has a break opportunity between it and
an nbsp.
fantasai: It would be stupid, but it would fix all the other cases.
TabAtkins: Suggest we resolve to do ideographic change, and based
on data may or may not do nbsp tweak to it.
fantasai: zcorpan, can you run a query with parentheses, or a
period after the image?
zcorpan: Sure.
<zcorpan> r'(\(<img\s|<img[^>]+>[\)\.])' 999 matches
<Rossen> 999 out of 1000?
<zcorpan> out of ~130k
RESOLVED: Treat replaced elements as ideographic chars for
line-breaking. Based on data, possible add an exception
for  .
plinss: We need a really-non-breaking-space
fantasai: <img>&zwsp;
dbaron: nbsp changed meaning between original (just a char that
didn't add a breaking opportunity) and unicode later
meaning (inhibits breaking around it).
Visibility of Control Characters
--------------------------------
<gregwhitworth> http://i.imgur.com/N8ouTs8.png
<gregwhitworth>
https://lists.w3.org/Archives/Public/www-style/2014Nov/0282.html
gregwhitworth: We had a bug a while ago (^^^ pic above) showing
hex boxes.
gregwhitworth: I brought it up on the list, asking Text to specify
that control chars get shown.
gregwhitworth: Firefox actually did this, but everyone assumed
they were broken.
gregwhitworth: So we all need to coordinate our release, to avoid
getting inundated with bugs.
gregwhitworth: And coordinate with, say, a 6-month period to give
devs warning.
gregwhitworth: So let's agree to make the change in, say,
September?
dbaron: Did we back it out?
gregwhitworth: Yeah, the bug is in the discussion.
gregwhitworth: roc is the one that suggested the coordination day.
[gregwhitworth goes to fetch roc]
gregwhitworth: roc, we're trying to coordinate the visible-control-
chars release.
roc: We already have it implemented, we just need to flip a UA
property.
<jet> Mozilla bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1099557
RESOLVED: Everyone will go coordinate on September being when
control characters become visible.
fantasai: Okay, so MSFT, Blink, and WebKit need to implement
behind a flag, preferably by June, and report back if
sooner so we can coordinate.
dino: I can't control when an iPhone releases, so...
gregwhitworth: As long as we have enough.
dino: If we committed to doing it...
fantasai: Just impl behind a flag, and flip it at the same time as
everyone else. Everyone else might get it out sooner,
but we all know it's coming out in Safari too.
dino: Okay.
gregwhitworth: Chrome and FF are the main ones that can just ship
it whenever. MS and Apple will have to just commit
to it.
johanneswilm: I hope I'm not using those characters that'll become
visible after.
gregwhitworth: We'll put out PR to help people figure this out.
Received on Thursday, 12 March 2015 00:32:28 UTC