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

[CSSWG] Minutes New York F2F 2015-05-19 Part II: text-decoration-skip, Box Percent Sizing

From: Dael Jackson <daelcss@gmail.com>
Date: Fri, 29 May 2015 21:23:27 -0400
Message-ID: <CADhPm3u5pTm7eTDQ-skjhfMA6nfHSewvnrtoYOxXVSj22HxXKw@mail.gmail.com>
To: www-style@w3.org

  - 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
          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
  - RESOLVED: No switch, for now anyway.

===== FULL MINTUES BELOW =======

  Scribe: fantasai


  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
  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
  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
  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
  Florian: ...
  fantasai: I don't have a strong preference on underlining vs
  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
  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

  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

  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
  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
  <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
  <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 %
  Rossen: One thing we identified early on in flex development,
  Rossen: is that being able to stretch inside flex items is really
  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
  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
  Rossen: If I have an item with % height, should resolve against
  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
  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">...

  ?: 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

  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
  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
  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

  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

  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
  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
  TabAtkins: Almost always want borders to be consistent all the way
  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
  <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
  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
  Florian: This is why I think a special keyword would make more
  TabAtkins: SVG has some things that use length of diagonal, could
             finally calc() that.
  plinss: So, are we getting to a resolution?

      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

  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
  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
  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
  tantek: This confuses *everybody* using CSS.
  tantek: We have this change to get Flex and Grid right, as layout
  tantek: Customers that use that kind of layout on native platforms.
  tantek: Better to say "hey, use this new layout mode that does it
  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
  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

  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

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:54 UTC