W3C home > Mailing lists > Public > www-style@w3.org > March 2015

[CSSWG] Minutes Sydney F2F 2015-02-09 Part III: Sizing, Text

From: Dael Jackson <daelcss@gmail.com>
Date: Wed, 11 Mar 2015 20:31:58 -0400
Message-ID: <CADhPm3uxsbwU7v5tUGLJTEvBNLvBq_RNfgKFuVeeeDCBs9EKnw@mail.gmail.com>
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 &nbsp.
  - 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>&nbsp;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>&nbsp;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 &nbsp; as a
         non-collapsible spaces.
  <koji> and used <input>&nbsp;&nbsp;<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 &nbsp; 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 &nbsp;
  koji: Treats &nbsp 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 &nbsp 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'(\&nbsp;<img\s|<img[^>]+>\&nbsp;)')
  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 &nbsp.

  plinss: We need a really-non-breaking-space
  fantasai: <img>&zwsp;&nbsp;
  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

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:39:30 UTC