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

[CSSWG] Minutes Paris F2F 2015-08-27 Part V: Page Floats, Writing Modes, Snapshot 2015, Flexbox % Follow-Up [css-page-floats] [css-writing-modes] [css-2015] [css-flexbox]

From: Dael Jackson <daelcss@gmail.com>
Date: Mon, 14 Sep 2015 13:59:21 -0400
Message-ID: <CADhPm3u8Kc4qiW+bxQw3Eyq6Uu1=RFxSeCWCdSZCyeFOhO7Wew@mail.gmail.com>
To: www-style@w3.org
Page Floats

  - RESOLVED: Publish FPWD of Page Floats

Writing Modes

  - RESOLVED: Make the caption-side: top | bottom values logical,
              drop logical keywords.
  - RESOLVED: Propagate 'direction' and 'writing-mode' from BODY to
              FOO (HTML if not BODY). To be reopened if tests show
              this isn't the way it's being done already
  - RESOLVED: Switch to the new model, mark sideways-lr and -rl as
              at-risk. Revisit if jdaggett objects because he's not

Snapshot 2015

  - Those present were generally positive about the new text, but
      some key individuals were missing, so the final decision will
      happen on the next telecon.

Flexbox % Follow-Up

  - There was new input for the conversation that the user of
      percentage margin will reduce as grid and flexbox are used
      more, however there was still no conclusion.


  scribe: dael

Page Floats

  johanneswilm: We would like to have a FPWD on this. More
                importantly we have some doubts as to who this
                interests. We can implement what we have now, it's a
                relatively basic model, but we would like to know if
                this is interesting at all to browsers or if we
                should make it more advanced. If you want to do
                print you want more.
  johanneswilm: What we have only works in fragmented contexts. In
                any single fragment you can only have floats in the
                line or block direction. So say you want a float
                that goes to the right in a fragment that goes to
                the top, the float will move on. And you won't have
                2d floats.
  johanneswilm: And as liam pointed out on the list, you would want
                to have a way of stacking those floats. Right now
                they are displayed in document order, but you might
                want two floats in a document with a large float
                that's at the top, you might want the two small at
                top, but that's a more complex description.

  Florian: So there's conflict between what you want and what is
           implementable by browsers.
  TabAtkins: And what you can reasonably spec.
  Florian: And depending on what interest, if the browsers say we'll
           never do this, we can go for the fancy thing, but that's
           not a desirable outcome. That's the underlying tension.
  Florian: Maybe having the general model supported and a switch
           saying do it slow and fancy.
  TabAtkins: If you're doing a custom printer thing you can do what
             you want.
  Florian: The printer and web aren't disjointed.
  TabAtkins: But high quality printing is different.
  Florian: And an ebook is in between.
  TabAtkins: If you're doing a pixel perfect thing that's fine and
             you can use magic, but we don't need it on the web.
  liam: I don't think it's pixel perfect.
  TabAtkins: But with the small things you can adjust your sizing.
  Florian: Since we're working with active media, it's not inDesign.
           You're writing a style sheet for print, but that means
           it's for paperback and hard cover and kindle.

  TabAtkins: But if you want ideal design that is what you want or
             you're a smart formatter that can do the magic, go
             ahead. We're not going to do a make my page magic
  johanneswilm: We do it on top of you, that's fine. Last time
                Rossen presented something that's simple page floats
                but wouldn't work with more than one in a column,
                the basic version we have should be able to handle
                that. If browsers are interested in that, we'll make
                sure the spec is written so that you can use that.
                If you don't care we'll write advance stuff.
  dino: Is the simple thing of use to authors?
  johanneswilm: Yes. When you start to make things more complex it's

  TabAtkins: We're not against the idea, especially if they start to
             obey simple restrictions. Something to remove the
             craziness of floats. So if you're doing newspaper
             layout you make the images siblings of the paragraphs
             not children you're fine. We're fine with this though
             we may have more feedback on the exact details.
  dino: We'd be interested.
  johanneswilm: What would you guys need for us to do FPWD?
  ojan: The thing Chrome is most interested in, we haven't reviewed
        everything, but extending floats in general we'd like a
        caret approach so we can remove the crap features from
  TabAtkins: That might manifest by saying these aren't floats,
             they're a new property.
  SteveZ: Is there a list of these things you want to get rid of?
  TabAtkins: We're making it, yes.
  Florian: Do you want this addressed before FPWD?
  TabAtkins: I don't think so. I'm happy to not block now, but our
             review might involve lets put more restrictions on this.
  Florian: I think the goal is to make something which is both
           useful and implementable in browsers without major
           headaches, so we should be able to converge without
           problems, at least not philosophical ones.
  TabAtkins: We don't have philosophical problems.
  TabAtkins: I'm okay with pubishing FPWD.
  plinss: Objections?

  RESOLVED: Publish FPWD of Page Floats

  plinss: Anything more?
  plinss: Do we loop back to writing modes? jdaggett still isn't
  Florian: We deferred to the F2F to have him.
  plinss: If we don't get him, should we do it here or wait for him?
  fantasai: I think we should get through it here and jdaggett can
            add his thoughts and all resolutions are pending his

Writing Modes

  <fantasai> https://drafts.csswg.org/css-writing-modes/issues-cr-2014
  fantasai: I have a DoC linked above.
  fantasai: I'll skip to issue 2.


  fantasai: There is a caption-side property in CSS that defines
            what side of the table you put your caption. It takes
            top and bottom and in the past it took left and right.
            Mozilla implemented them all, but we dropped the sides
            because no one else did. Now we have writing modes and
            if you don't have the sides, you can only do block-start
            and block-end. So we have top and bottom keywords, we
            want left and right. And since those are physical, when
            you go into vertical, they stay physical.
  fantasai: But if you don't support all four values you have to do
            something about that. [whiteboards]
  fantasai: If you only support top and bottom and you implement
            writing modes, you can't put "top" at the top in
            vertical mode, because it's a side-caption, which you
            don't implement yet.
  fantasai: So we need to map "top" and "bottom" to over/under
            captions. We decided top and bottom should go to the
            default caption side, the block-start side.
  fantasai: We added new keywords of block-start and -end keywords
            and made the initial to be block-start.

  Rossen: This is what we're implementing. We ended up mapping top
          and bottom to be logical, just like for float where left
          and right mapped logical.
  fantasai: Float left and right maps into the line left and right
            which are logical, but not start and end. It means float
            to wherever left and right text will start.
  fantasai: If I have right to left text, right is the start but not
            the left.
  fantasai: We could put top and bottom as logical, but what happens
            to Mozilla where they can do that as side captions on the
            actual top and bottom--it becomes incompatible.
  Rossen: We implemented left and right and we dropped it.
  fantasai: Because nobody supported.
  Florian: Having left and right without vertical writing is not so
  Rossen: There are cases.
  fantasai: If you have a table and side captions on the right, it
            looks ugly and no one wants to use it. It doesn't look
            attractive unless you support vertical writing also.

  fantasai: We all agreed to add logical equivalents and we want
            authors in vertical writing modes to use those.
  fantasai: We wanted it to be clear that the caption-side physical
            values don't have an effect in vertical writing modes.
  fantasai: Do you want top and bottom to behave logically or
            fallback to the block-start?
  Florian: It's a usability question, not feasibility.
  Rossen: We have real use cases where people use vertical tables
          with captions, mostly for displaying odd tabular data. I
          don't know about them, but they were using top and bottom
          just fine.
  fantasai: It's totally logical, but as soon as you support side
            cations, top needs to be on the actual top.
  fantasai: The ones in Mozilla are in the e-mail I wrote. Side
            captions don't exist right now, but people want them.

  Florian: Can left and right be logical?
  fantasai: That's opposite of how it is everywhere else.
  Rossen: What about rows and columns?
  Rossen: You're making everything in the table logical.
  fantasai: So you're suggesting drop block-end and -start and
            decide that top goes on the other side?
  Rossen: All table properties are in a logical way without
          redefining them with logical properties. Just like we do
          for rows and columns.
  ojan: I wish we had done that for the whole platform, but it's too
  fantasai: So this will be an exception to the rule that
            top/bottom/left/right are physical keywords.
  Rossen: For tables only. It's legacy feature retrofit into writing
  fantasai: Anything else to add?
  Rossen: Otherwise you're half logical and half physical.
  fantasai: I don't buy your argument. Margin-left and margin-right
            are all physical. The only thing logical is caption-side.

  dbaron: I think of table captions as a feature that was a mistake,
          since authors can just use other markup and style to put
          the caption next to the table, rather than having browser
          features to move the caption from the inside of the table
          to the outside.
  dbaron: So I kind of don't really care. I'm tempted to just remove
          the left and right support from Gecko except that's work
          and I don't see the point of doing that.
  <tantek> +1 on removal
  Rossen: Comment out the property support.
  ojan: Sounds great to me for what it's worth.

  fantasai: dauwhe, do you have opinions?
  dauwhe: I got a request from a friend of mine in publishing that
          had been switching to figure for a11y and wanted figure
          caption display the same as caption inside table and we
          had to get those to be the same. So there's a movement
          away from caption.
  tantek: He likes how caption displays??!??
  <tantek> caption element is so broken that the more we unsupport
           it the better
  dauwhe: It's fairly easy to get it to follow the length.

  fantasai: It only works in Mozilla. The combination you want is
            writing modes plus side captions and no one has that.
  Florian: You can do it...
  fantasai: With?
  Florian: Multi elements.
  fantasai: The way side captions are defined is if you're centering
            it you're centering the table and this is off the side.
  * fantasai draws how this works, see
  dauwhe: I'd like to take this use case back to dpub.
  fantasai: That's what a side caption does, but that's besides the
            point. All that matters here is its been proposed to
            drop the block-start and -end and make caption-side a
            logical property.
  TabAtkins: If we should drop side captions, I don't see why not
             treat them logical? We call it line-top or whatever.
             Sometimes you got to retrofit.
  fantasai: How it maps goes in writing modes.
  Rossen: Sure, you can have an exception.

  <tantek> why is this only about tables?

  fantasai: We have to spec for 2.1, we're not waiting on CSS3 Tables.
  fantasai: So the caption-side property which currently takes top
            and bottom, or if you support side captions also left,
            right. We also added block-start and block-end. The
            proposal is to remove block-start and -end and to make
            top, bottom, left, and right logical
  Bert: I prefer the solution in the ED, but I see why people want
        the other. I'd rather add more keywords for logical
  fantasai: Anything else to add?
  Florian: I agree with Bert. I prefer the other but only mildly.
  fantasai: Any objections to making the caption-side property

  RESOLVED: Make the block caption-side property logical

Propagation of Direction to Body

  fantasai: Propagation of direction to body. Unlike 'background'
            propagation from the body tag to the viewport, we don't
            have a 'you didn't set this value' value. Every element
            has a value for writing-mode and direction. We got
            some feedback that there's web compat issues so we
            should propagate from the body tag to the viewport.
            The compat problem mostly comes from epub and people
            using writing modes and wanting to propagate direction
            from body.
  fantasai: So first options is don't change the spec, you only use
            the writing mode and direction of the root element and
            the direction attribute goes from body to HTML.
  fantasai: Second is the viewport and initial containing block use
            the writing mode and direction of the body.
  fantasai: Third is we ignore the direction and writing mode
            property on the body and copy that only the root element.

  dbaron: Didn't we spend an hour or two on this at a previous
  Rossen: I thought we would do what we did for background property.
  Rossen: That's what current implementations do.
  fantasai: We had a resolution to not propagate direction from
            body, but then thought there might be compat concern for
            not propagating writing-mode.
  esprehn: I don't think we can change.
  fantasai: Everyone is buggy on what aspects they propagate up.
  fantasai: You can say for each effect that gets propagated, use
            the direction but the computed value on the root isn't
            changed. The other is change the writing mode and
            computed value on the root which would keep everything
            in sync.

  Florian: Both these are done in browsers?
  fantasai: No, this is what we can put in. Browsers are incomplete
            in how they translate it. Scrolling is inconsistent.
            Stuff is buggy.
  Florian: Buggy how?
  fantasai: In that people have bugs and only propagate for some
            effects, but not others. Nothing depends on it being
            broken. Some of it depends on stuff working. We can
            define the propagation in two different ways, what is a
            better way to do it?
  Florian: You're suggesting here are a few things that would keep
           compat, which is easier to implement?
  fantasai: First we could propagate 'direction' via the HTML 'dir'
            attribute [as we discussed at the last F2F] instead of
            propagating the 'direction' property if direction is the
            only thing we care about, but it doesn't handle writing
  fantasai: The second is the way implementations sort of do it now.
  fantasai: The third would be a different approach to doing it.
  fantasai: Either way people have to fix implementations.
  fantasai: No matter what we pick we'll have to do work.

  koji: I'm not familiar with direction buggy, but if author
        specifies on HTML or body the three browsers are quite
        similar. As long as either is honored, the web compat is
        good, at least for writing mode.
  fantasai: We can't detect if the author specifies a value for
            <html> or not. There's no 'none' on writing mode.
            The computed value is one thing or the other thing.
  fantasai: Background has a transparent value and that's the initial
            value. If you set it to color or image, we can see the
            author set it to not the default.
  fantasai: So to propagate from <body> we would be completely
            ignoring writing-mode on the HTML because we can't tell
            if the author set it.
  fantasai: The question is do we change the computed value on the
            HTML element or do we leave it computing to what it had
            and take all the effects, scrolling and alignment, and
            make them depend on the body alone?
  Rossen: That's what current implementations do. How they got on
          body no one cares.
  Florian: And you don't retro-fix the HTML. Seems simple enough.
  esprehn: It does this.
  Rossen: It's already simple enough to explain so if we keep it
          this way it's better.

  fantasai: The advantage of copying is if the entire author says
            the whole document is this, you get it into the metadata
            at the top and the logical properties behave the same
            way on the root as it does elsewhere on your document.
  fantasai: You do the inheritance up and then you don't have to
            special case code for the scrolling and the like. As
            long as you did upward inheritance it will all just work.
            You don't have to handle each of these individually.
            It's clearly an implementation bug that things aren't
            there, but there's more opposite to trigger that switch.
  Florian: So it's one complicated fix or a bunch of simple ones and
           you forget half of them.
  fantasai: Does that makes sense?

  dbaron: I'm trying to find the list from the last discussion.
  dbaron: I'd be worried about time switching to something that
          doesn't match what everybody does.
  Rossen: The only thing that propagates up is overflow, writing
          mode, and background.
  ojan: You said the direction doesn't get property.
  Rossen: To the viewport.
  esprehn: fantasai is asking us to inherit everything up into the
           view. That's not what anybody does today.
  esprehn: The body inherits into the root.
  <tantek> upward propagated? or hoisted?


  Rossen: Overflow writing mode and background on gets cascaded to
          body. As soon as we have the cascade down to body, they
          upward propagate to the canvas.
  fantasai: There's two ways to get this. If you don't have a body
            you have to have code for getting from HTML to canvas.

  <astearns> https://lists.w3.org/Archives/Public/www-style/2015Mar/0188.html
  dbaron: The list I had that astearns found had 4 things:
          1) Which side you can scroll to when there's overflow from
              the viewport.
          2) If the root element is relpos and has both left and
              right set, which one wins.
          3) If the root element has overconstrained margins, which
              gets ignored.
          4) If the root or body is abspos, which position gets used
              for hypothetical box calcs.
  dbaron: 1 and 4 are the main compat risks.
  Florian: I believe fantasai's point is if you do reverse
           inheritance you can't forget to handle one of those on 4.
  dbaron: I believe we can't fix it. People already write script.
  dbaron: Also the code for the other thing we do in 4 is awful. The
          code for reverse inheritance.
  dbaron: Do we even still do reverse inheritance of the other
  fantasai: Overflow, background, cursor (maybe), direction and
            writing mode propagate up.
  ojan: For good measure, we don't do cursor, we do image-rendering
        and column gap.
  Florian: By spec cursor goes from root, not from body.
  fantasai: So image rendering is because it effect background.
  esprehn: Yes.

  fantasai: Backgrounds and overflow have 'I didn't set this' values
            and they will propagate based on if you set it on the
            root. If you didn't set it on root it propagates from
            body. Cursor direction and writing modes are all
            inheritable. You can only tell if you have a body and
            you grab it and if you don't you use the root.
  ojan: I don't think we do the thing where if the value isn't set
        we don't propagate.
  fantasai: If you set a background on the root and on the body, you
            need to assign the root element to the canvas.
  ojan: I think we don't do that for overflow.
  dbaron: Background doesn't effect computed values.
  fantasai: If you set overflow: scroll on the body and
            overflow: hidden on the HTML then you scroll the
            document and ignore the hidden?
  ojan: I think so.

  esprehn: Our code follows the spec. Where's rbyers? You wrote this.
  esprehn: We don't look to see if it's set, we look to see what the
           viewport is set by and we pick that except for BG.
  ojan: The thing on BG is more complicated, just for the record.
  <zcorpan> cursor doesn't propagate from body per spec, only from
            root. (seems blink follows the spec; gecko doesn't
            propagate cursor at all)
  koji: The other option is that, I know it's from the last F2F, but
        since mostly the combine is about writing modes, we don't
        propagate but we just use HTML and body to decide principal
        writing mode. I guess thats' what we do. I haven't checked
        IE yet.

  fantasai: [writes options on board]
            1) propagate 'dir' attr, not 'direction' or
            2) propagate 'direction' and 'writing-mode' from BODY to
                ICB/viewport/canvas (HTML if not body)
            3) Propagate 'direction' and 'writing-mode' from BODY
                to HTML (always from HTML to ICB/viewport/canvas)

  fantasai: The first I don't think we can do due to ebooks.
  fantasai: I think we can allow either 2 or 3, we can allow both in
            the spec, it gets the same result.
  Florian: I'm not hearing anyone want to do 3.

  Rossen: That was my kind of more general question. Are we trying
          to document what everyone does or spec something most
          likely no one will implement?
  fantasai: What do we want to do to get the content to work in the
  dbaron: I think you should start from a table of accurate checked
          data of what each implementation does in detail rather
          than figure it out in a working group.
  Rossen: There's 4 properties and 2 elements to test.
  astearns: And these tests should be in the test suit.
  dbaron: I think we had a previous resolution to do the same thing
          for writing mode and direction, it wasn't defined what
          that thing was.
  <dbaron> https://lists.w3.org/Archives/Public/www-style/2015May/0313.html
  <dbaron> has a previous resolution
  <dbaron> I think we should stick to the second relevant one
  <dbaron> (I'm quoting indirectly via
https://bugzilla.mozilla.org/show_bug.cgi?id=1169065#c1 )
  fantasai: The previous resolution was to handle the direction
            property by propagation the direction at the HTML level
            so you would only look at the root, but then that won't
            work for writing mode if we need to do that. So we can't
            use that and writing mode and direction should be same.

  Rossen: How about we come up with the test cases.

  fantasai: Let's resolve to propagate both and it doesn't matter
            how, we'll sort that our later.
  ojan: I'm okay with that. If we resolve to spec what browsers do
        there would be agreement from the browsers here.
  Florian: So we resolve to do #2 and if we discover it's more
           complex with test cases we'll deal with it.
  Rossen: Yes.
  dbaron: I think #2 is prob the most compatible, but we should
  Florian: If test cases expose that as not what browsers do then
           depending on what we've found we discuss again.

  * fantasai waves to r12a
  <fantasai> we're discussing writing modes
  * r12a waves back
  * r12a https://www.w3.org/2015/08/mail.php?subject=https%3A%2F%2Flists.w3.org%2FArchives%2FPublic%2Fwww-style%2F2015Jul%2F0060.html&;list=

  RESOLVED: Propagate 'direction' and 'writing-mode' from BODY to
            FOO (HTML if not BODY). To be reopened if tests show
            this isn't the way it's being done already.


  fantasai: Next is the sideways-left value
  <fantasai> https://drafts.csswg.org/css-writing-modes/issues-cr-2014#issue-41
  <fantasai> https://lists.w3.org/Archives/Public/www-style/2015May/0092.html
  <fantasai> https://lists.w3.org/Archives/Public/www-style/2015Jul/0060.html
  Florian: This one we agreed except jdaggett.
  hober: Sideways-left is when you need to know how long the run is?
  Florian: It lets you have Arabic and Japanese and they both go
           down and we're switching to a model where you cannot
           switch that inline anymore.
  fantasai: We're at the issue that's been discussed. I went over it
            on the call before.
  fantasai: Proposal is to change the way writing mode and
            text-orientation are organized to remove sideways-left
            from text-orientation and instead add to writing mode
            sideways-lr and -rl

  Florian: By removing sideways-left from text-orientation it means
           we only have sideways and sideways-right which means we
           don't need sideways-right. So that applies to some, but
           not all writing modes. So CJK works the same. In addition
           to text-orientation doing nothing on horizontal, it also
           does nothing on sideways-lr and -rl.
  Florian: So sideways-lr is the one you put on the left side
           caption in English and they do everything you would
           expect. It's one value that says do the right thing when
           flipping a language on the side.
  Florian: In the addition to the implementation difficulty of
           sideways-left, another downside is that it was biased to
           CJK. We are losing the ability to do downwards Arabic in
           Japanese or similar. According to liam they exist. I've
           tried to find examples by contacting professors and
           eventually that ended up pointing me to r12a after a few
           hops. It's rare and we can add it back later if we want
  Florian: We can fix it later, but we may never need to given how
           few people care.

  dbaron: Who is the audience for this topic? One of the people that
          cares deeply isn't here. But it's not an empty set, so
  astearns: As far as I understand the proposal I like it and don't
            need it described further.
  fantasai: The mailing list comments were jdaggett didn't think
            this made sense initially and now I'm not sure where he
            thinks it is. r12a thought about it for a while and said
            he likes it a bit better and all of the questions he's
            been getting on writing-mode are from non-CJK users
            asking if this will solve their problems. This proposal
            would make it more straight forward for those people.
  Florian: Given that everyone who cares except jdaggett agrees and
           he disagrees less than he used to...we had two threads
           one where he said if we do this can we change the name
           which isn't an objection.
  <r12a> note that i actually think the new approach *solves* some
         problems i was struggling with with the old approach (see

  liam: You mentioned my name by saying these exist. We had a
        question in XSL-FO working group about where an underline
        would go in that case, but because someone asked doesn't
        mean some one does it. We just had an implementor who was
        talking about it.
  SteveZ: I don't understand because I haven't looked carefully. It
          seemed the critical thing was instead of being engineers
          and giving a matrix, you said what do people want to do
          and give a label to those things and make those easy to do.
  Florian: [goes through and points out how most cases are covered]
  SteveZ: For the two verticals I use text-orientation to say if I
          rotate the embedded non-CJK things.
  SteveZ: Since Japanese are often trying to choose between upright
          and sideways.
  Florian: Yes. The CJK authors are more likely to be away of having
           something like this exist.
  SteveZ: Without deep thought I like it.
  fantasai: I would have made the initial value upright if we had
            thought of this originally.

  hiroshi: sideways-rl and -lr are a bit confusing because
           writing-mode is to make the characters vertical. Sideways
           to make Latin go to the side. In this situation, my
           opinion is to get rid of sideways for not and use only
           rotate. That's enough for the side captions and think
           about bidi in level 4.
  fantasai: We don't have to worry about bidi, it's a solved problem.
  fantasai: But transform doesn't solve the problems of non-CJK users.
  fantasai: If you transform from horizontal text you are not taking
            up space in the layout. If you use vertical-lr and try to
            use sideways you have a problem where scrollbars and buttons
            do not look the right way. A lot of things won't work
  hiroshi: There might be a lot of discussion concerning sideways-lr.
  * Bert 's first idea was like Hiroshi's: transform would do it...
            if only it affected layout.
  Florian: Maybe there's a middle position of at-risk.
  fantasai: Maybe. I think it's a strong use case outside of Japan.
            I think web authors would be upset if they couldn't get
            the effects that are important to have. As r12a said in
            IRC there are a lot of people that cared about those
  Florian: Marking at-risk might be good because if browsers support
           them they're okay and Japanese users won't agonize
           because they won't be waiting on those for it to progress.

  RESOLVED: Switch to the new model, mark sideways-lr and -rl as
            at-risk. Revisit if jdaggett objects because he's not

  plinss: We're over time, is the more urgent things on writing
  fantasai: That's it.

Mozilla Being Okay with Keyframes

  dbaron: I need to read the text. If I'm okay with it I can edit
          into the spec.

  ACTION dbaron review the keyframes proposal
  <trackbot> Created ACTION-720

Snapshot 2015

  <fantasai> https://drafts.csswg.org/css-2015/#experimental
  fantasai: How do people feel about the new text? I've gotten
            positive feedback, do we want to adopt the new text?
  Florian: I do.
  tantek: It's good enough to ship. Do the people who objected
          before think it's good enough?
  gregwhitworth: I'm good.

  dbaron: Is this revised since dinner?
  fantasai: Yes, I tried to handle your concerns.

  smfr: I don't find the "why" things helpful.
  TabAtkins: I try to use those when it's a long note that's not
             helpful to everyone.
  Florian: I think the why is important so it's better not to hide.
           This isn't spec level prose with unambiguous meaning and
           therefore the why is important.
  TabAtkins: Okay.

  plinss: Everyone okay? Need more time?
  smfr: You talked to hober?
  fantasai: About the part he was objecting to. There's three
            sub-sections. First was the one hober was unhappy about.
            The other two have also been revised based on other
  smfr: I think we'd like to review internally more because I think
        there are people interested who aren't in the group.
  tantek: Can we give you to the next telecon?
  fantasai: Two weeks?

  SimonSapin: Is there a meaning to the green text?
  Florian: What changed after dinner...
  fantasai: I'll remove the underlines once dbaron says okay.
  plinss: So we'll loop back next telecon.

  fantasai: I want a sense if everyone in the room agrees.
  astearns: I suspect hober will be very interested in the insert
            that says support for prefixes should be removed.
  Florian: This is the model where prefixes are shipped early when
           unstable and then once it ships the regular version
           should be used. Since we don't live in the perfect world
           it might work differently. This isn't you should remove
           the old fashioned prefixes.
  plinss: Anyone in the room have comments?
  fantasai: Positive or negative.
  fantasai: Type +1 if you like it -1 if you don't, 0 if you don't
  <tantek> +1
  <plinss> +1
  <Florian> +1
  <dauwhe> +1
  <leaverou> +1
  <ChrisLilley> +1
  <rachelandrew> +1
  <liam> +1
  <MaRakow> 0
  <SimonSapin> +1
  <gregwhitworth> +1
  <jet> +1
  <astearns> 0

  dbaron: I might have worded one of the thing differently.
  fantasai: Suggest edits.
  <dbaron> Vendors should make it possible for other implementors to
           freely implement any features that they do ship. To this
           end, they should provide spec-editing and testing
           resources to complete standardization of such features,
           and avoid other obstacles (e.g. platform dependency,
           licensing restrictions) to their competitors shipping the

  plinss: We'll loop back to this on telecon.
  Florian: Do we discuss in 2 weeks or resolve for now.
  plinss: We're expecting more feedback so we'll resolve in two

Flexbox % Follow-Up

  TabAtkins: There has not been further discussion.
  tantek: Only further thing I remember is looking at the way abspos
          handles percentage in general is internally inconsistent
          in abspos. You've got top where percentage is height and
          margin where it's percentage in width etc. So in all the
          different ways there are potential trade offs. Changing
          vertical percent on abspos elements to also be percent
          height based makes it more internally consistent. All the
          horizontals become width based and verticals become height.
          That adds more weight to option 3.
  tantek: I don't know if that changes anyone's opinion, but it may
          add more weight to solve this disagreement.

  plinss: Anyone who weighed in have you changed your minds? Or
          people willing to raise new objections?
  tantek: There was new information to keep considering this, so who
          knows if someone will find more information.
  fantasai: The other thing tantek brought up--note I totally
            disagree with block being legacy--but the usage of
            percentage will be much reduced because in the kinds of
            layout where you'll want percentage margins and padding ,
            you'll probably be in grid or flex and not block.
  <tantek> agreed with fantasai
  plinss: Alright.
  plinss: It sounds like we can't close this, so continue discussion.

  esprehn: Would you withdraw your objections to withdraw your
           objection to flexbox if we pursued the sane mode property?
  tantek: I think this would help move a mode forward. We could
          treat this like an error where the web community says
          they're fixing this or they say this is crazy stupid and
          helps us judge if the sane mode would be judged as sane. I
          see this as a good idea and a way to gain market feedback.
          Does that make sense?
  esprehn: Yes.

  Jet: Does Microsoft and Google both have interoperable shipping?
  gregwhitworth: They're not the same.
  jet: We're about the ship.
  dbaron: We shipped already.
  gregwhitworth: Microsoft Edge and Flexbox agree and Mozilla. In NY
                 the abspos situation was brought up. And as tantek
                 says we'll continue the discussion.
  tantek: It's clear we have to say something. But it's more clear
          to me this is the way to solve it.
  <tantek> the way being dimensionally consistent

  ojan: We can experiment in Chrome to see if there's mostly mobile
        content that would break, but I don't know if that's useful.
  gregwhitworth: By all means share, but it's not like we don't do
                 mobile testing. You have much larger market share.
                 I think that Apple would have the same.
  gregwhitworth: I don't know how many hundreds of millions we do,
                 but I receive a lot of bugs so we test a lot.

  ojan: On Tuesday gregwhitworth you said you could find us a list
        of sites that use percentage in margins. If you could bring
        that, it would help.
  ojan: I'm trying to understand the non-aspect ratio cases.
  tantek: Did we capture that there's user demand for aspect ratio?
  TabAtkins: It's in the minutes. Lots of times.

  plinss: We are adjourned. Thank you Mozilla!
Received on Monday, 14 September 2015 18:00:19 UTC

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