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

[CSSWG] Minutes Telecon 2015-01-28

From: Dael Jackson <daelcss@gmail.com>
Date: Wed, 28 Jan 2015 20:23:09 -0500
Message-ID: <CADhPm3uJkugzOcz-vaKXkFMGik=R2AXwxLmXaFtUj3E_HRnsyA@mail.gmail.com>
To: www-style@w3.org

  - dbaron asked that everyone review the Transitions ED since he
      hopes to bring it up for publication at the F2F.

Next Week's Telecon/Sydney F2F

  - Since both chairs, and likely many others, will be traveling
      next Wednesday, there will be no telecon.
  - Everyone was reminded to add items to the wiki for discussion in

Where is the "Complete Document"

  - RESOLVED: Turn the old road map into a 301 redirect to /TR/CSS
              and discuss updating /TR/CSS at the F2F


  - RESOLVED: Use 'content' as the new value for flex-basis
  - TabAktins explained his rational for creating 'no-wrap' as an
      alias to 'nowrap' to alleviate author confusion. However, the
      group remained unconvinced as to if it was the best way
      forward. This issue will remain open while the explores more
      possibilities and look for more information.
  - The remaining flexbox issues still need some work and/or
      understanding before they're ready for the group, though they
      should be ready by the F2F

extending break-* to lineboxes

  - Fantasai brought her proposal for extending the break-*
      properties to control inline layout. It received a warm
      reception as an idea worth exploring.

text-wrap: balance

  - The text-wrap: balance proposal was also well received with a
      lot of people showing interest in developing it further.
  - fantasai stated that she and astearns will be bringing their
      unofficial ED for CSS4 Text to the group shortly to formalize


  - RESOLVED: Change the must into a should and remove the reference
              to "may ignore" for issue 38
  - RESOLVED: Document ime-mode as obsolete as described in the
  - There was discussion on changing the language for ime-mode to
      say browsers should not support, however that wasn't resolved
      upon so the resolved upon publication will go forward with
      existing language and the "should not" language will wait for
      a formal resolution.


  Rossen Atanassov
  Tab Atkins
  David Baron
  Sanja Bonic
  Bert Bos
  Adenilson Cavalcanti
  Tantek Çelik
  Dave Cramer
  Elika Etemad
  Daniel Glazman
  Tony Graham
  Koji Ishii
  Dael Jackson
  Toru Kawakubo
  Peter Linss
  Michael Miller
  Shinyu Murakami
  Anton Prowse
  Florian Rivoal
  Simon Sapin
  Dirk Schulze
  Alan Stearns
  Lea Verou (IRC only)
  Greg Whitworth
  Steve Zilles

  Angelo Cano
  Sylvain Galineau
  Chris Lilley
  Simon Pieters
  Keshav Puttaswamy
  Mike Sherov
  Ian Vollick

Scribe: dael


  plinss: Let's get started. Morning/evening/afternoon. Anything to
          add to the agenda?
  <glazou> plinss: next week’s call
  dbaron: One thing is I'm hoping to ask for Transitions to LC/CR
          relatively soon, probably at the F2F.
  fantasai: Can we push a WD to TR first?
  fantasai: Is it up to date?
  dbaron: I don't think there's need to push another WD.
  fantasai: The things we should look at are on TR?
  dbaron: They're in the ED.
  fantasai: I think it would be good to push to TR and make a broad
  dbaron: Most of the updates are for implementors.
  tantek: I agree with dbaron. If it's ready to go, that's how you
          get people's attention. Just go.

Next Week's Telecon/Sydney F2F

  plinss: Anything else?
  plinss: I'm going to talk about the F2F. Both glazou and I will be
          on a plane during next week's call, so I propose we cancel.
  plinss: We'll need more items for the agenda, so please update the
          wiki. If there's any last minute logistics, please bring
          it up.

Where is the "Complete Document"

  plinss: TabAtkins you were talking about this on www-style?
  <TabAtkins> No one can hear me...
  * plinss no, we can’t.

  florian: Is there anything else besides turning this into a gutted
  fantasai: I think it should be a redirect
  fantasai: A gutted note isn't useful to anyone. A redirect will
            put people some place useful.
  <Bert> q+ to support fanatasi's suggestion
  <dauwhe> +1 to fantasai
  Florian: You'd have the link to the old discussion if there was
           anything useful.
  tantek: I agree with fantasai. Just point to the thing people are
          looking for. Else wise it looks like bureaucracy.

  <dbaron> /TR/CSS/ is almost 5 years old at this point
  <dbaron> er, 4
  fantasai: We can add a previous draft link if we have to. I want
            to to be a 301 permanent redirect. No aliasing.
  Bert: I'd like to suggest we don't just add a redirect, but also
        update /TR/CSS.
  fantasai: I agree.
  fantasai: Let's add that to the F2F agenda.
  Bert: I won't be there, but it sounds like a good topic
  fantasai: You can send us your advance ideas.
  <tantek> +1

  fantasai: Proposal turn it into a 301 redirect to /TR/CSS
  plinss: Anyone object?
  Bert: Both can happen, but it's easier for the webmaster if the
        update happens at the same time. Depends on how quickly.
  tantek: I guess onto the 301.

  RESOLVED: Turn the old road map into a 301 redirect to /TR/CSS and
            discuss updating /TR/CSS at the F2F

transform-style: preserve-3d creating containing blocks

  plinss: smfr are you on the call? I guess not.


  <fantasai> Summary of open flexbox issues:
  E-mail Text:
  "Need the WG to resolve on:

   1. Adding a 'no-wrap' keyword that means the same as 'nowrap'.
      (I'm somewhat disinclined, but Tab is gung-ho on this one.)

   2. Resolve naming of automagic keyword for 'flex-basis'.
      Input from implementer and usability perspectives welcome.

   Other open issues include

   3. Spec conflicts wrt handling page-break controls on flex items
      Part of the spec forces a flex-line break at that point,
      other part of spec propagates the page break to the flex line
      in the case of row flexboxes. Not sure yet which is the
      behavior to recommend, so if you have thoughts on applying
      page break controls to flex layout, please help us figure this
      one out.

   4. Abspos issues
      Tab and I haven't quite figured this one out yet. We suspect
      there's an error in the spec. We'll report back once we know.

   Issues I think we might want to defer to the next round of
   publication, but are currently open for discussion

   5. a11y, tabindexing, 'order', and other amusements as presented
      by Bo Campbell; this one seems to need more discussion time.

   6. Controls for flex line breaking; this one also needs more
      discussion time, and is likely to end up deferred to a next
      level of either css-flexbox or css-break."

flex-basis: magic

  Rossen: For the flex-basis one, we were going to implement the
          'content' keyword, or value rather. It works pretty good,
          we haven't heard any feedback about the value names.
  Rossen: At this point we'd appreciate it if we would stop changing
          our minds.
  TabAtkins: Sounds fine to me.
  Rossen: fantasai you have a concern here, are you okay?
  fantasai: I don't mind. We didn't resolve on a name, we just had a
            placeholder in the draft. It's just a matter of if it's
            okay or if there are other words.
  Rossen: We went with the 'content' value and we haven't heard
          anyone being offended by this name.
  TabAtkins: I'm find with 'content', if there's no objections let's
             resolve and we'll lock it down.
  plinss: Objections?

  RESOLVED: Use 'content' as the new value for flex-basis

  <tantek> Aside - plinss, I wasn't able to complete the edits for
           CSS3-UI by yesterday (circumstances :( ). All issue
           resolutions documented (even if just "refer to open
           issue") on issue page. Editor's draft edits will be done
           shortly today. R EQUES T: proceed with publication
           (assuming group does not object, as agreed last week),
           even if that means next publication week.

Adding a 'no-wrap' keyword that means the same as 'nowrap'

  <fantasai> https://lists.w3.org/Archives/Public/www-style/2014Oct/0188.html
  TabAtkins: The first issue was a while ago about aliasing the
            'nowrap' value to now have a dash. We had a dash
            originally and removed it to match whitespace, but it's
            hard to remember. On the other hand we can't remove
            'nowrap' at this point.
  TabAtkins: We should add an additional value of 'no-wrap' that
             means the same thing as 'nowrap'.
  Florian: I have no strong opinion as to if we should, but if we do
           that's the right way to do it.

  plinss: How will it serialize?
  TabAtkins: They're two separate values, so they'll serialize as
             you put it in.
  Florian: For property we can do magic, but for a value this is

  plinss: Objections?
  Florian: Just to clarify your proposal, this is to edit for
           whitespace too?
  TabAtkins: We can and should edit whitespace.
  fantasai: I think it's ridiculous to do only one. I'd like to hear
            from others.

  gregwhitworth: We're running some queries. I think this would add
                 to the confusion. It's kind of a toss-up as to
                 what's the most confusing.
  TabAtkins: Here's the tweet that mentioned the confusion.
  <TabAtkins> https://twitter.com/SlexAxton/status/519953582183809024
  TabAtkins: Once we get the 'no-wrap', we can deprecate 'nowrap'.
             It'll be valid, but the spec won't recommend it because
             it isn't normal naming rules.

  <sanja> q+ is there any number on how many dash-including-values
          we have?

  tantek: Does this effect DOM serialization?
  TabAtkins: No. They're two different values that do the same thing.
  dbaron: Are they separate at specified value stage and value and
  TabAtkins: No, because if we did at computed we'd have to go to
             the stupid value of 'no-wrap'.
  TabAtkins: If people believe we can get away with a rename good,
             but I'm not sure we could. I'm being conservative and
             saying the safe option.
  tantek: I think we'll confuse web authors with them both existing
          as possible serialization. If someone is looking for a
          'no-wrap' they have to look for two different values. I
          think it's complex. I'd be okay with parse time alias.
  TabAtkins: They're impossible for values.
  tantek: You say it computes to.
  TabAtkins: That's not parse time. We can do that for properties
             not values.
  tantek: Pseudo Elements is similar to this. They were
          grandfathered in like :first-letter. You don't get
          :first-letter and ::first-letter.
  TabAtkins: It's a compat call. If we can do that, let's, but if
             it's not compatible.
  fantasai: The pseudo elements is a parse time thing.
  fantasai: The specified value would still be 'no-wrap' or 'nowrap'.
  fantasai: Are you saying 'no-wrap' should parse in as 'nowrap'?
  tantek: I'd be fine with that.
  <Bert> (I don't like aliases, people will ask for 'colour' again,
         but we do have already an equality between .123 and 0.123,
         and between 10mm and 1cm...)
  tantek: If authors are putting in 'no-wrap' and expecting it to
          work, I think that would be the easiest fix.
  fantasai: I agree with you.
  TabAtkins: Theoretical stumble points aren't this, this is a real
             stumble point. It's a confusing inconsistency with the
             language. We can say there may be future confusion, but
             we know there's current confusion.
  tantek: That's why I said it's okay to alias at parse.

  plinss: Anyone writing script will have to look for the undashed
  tantek: They'll have to look for both in the future. You can make
          them look for two or one. That's the choice.
  plinss: If they're writing code against themselves they can look
          for their own style.
  tantek: Their own style sheet in this age of corporations is
          becoming increasingly rare, we can see that as an
          architectural sticking point.
  * fantasai tantek++
  fantasai: Even if you are, you can accidentally do one or the
            other over time. Or we don't make you do that.

  gregwhitworth: Do we know of anyone checking for 'nowrap'?
  TabAtkins: I don't know and don't know how we'd check. It would be
             difficult. That's why I suggested the conservative.

  Rossen: Will you implement for only unprefixed, or would you push
          that to prefixed webkit?
  TabAtkins: The conservative isn't a compat issue, so there's no
             reason to hide it behind only the unprefixed.
  Rossen: If we all change it at the same time so that we will
          effectively force people to start using the dashed version.
  fantasai: We'd have to be consistent and if we do undashed in one
            and not the other it's worse. whitespace has been around
            since CSS1.
  TabAtkins: Removing 'nowrap' wasn't on the table.
  Florian: What's confusing is merging into one.

  <tantek> I'd like to see "no-wrap" work at *parse* time as a
           minimum, and I see the use case for that.
  <tantek> you can also access it as a property right?
           element.style.nowrap currently
  <tantek> does it become element.style.noWrap ?
  <tantek> are they aliases?
  <tantek> or sorry - element.style.whiteSpace = "nowrap"
  <tantek> or element.style.whiteSpace = "no-wrap" ?

  TabAtkins: I'm finding code that checks for 'nowrap' in JS.
  TabAtkins: So it's probably a thing that happens.
  plinss: So alias at parse time, two values, no change.
  TabAtkins: There's no alias at parse. We can do computer time into
             legacy 'nowrap' keyword.
  Rossen: But then it sucks. For completeness let's have it, but
          it's not a good option.

  <fantasai> Options:
  <fantasai> A) Parse no-wrap as nowrap
  <fantasai> B) Treat as two keywords with identical definitions
  <fantasai> C) no-wrap computes to nowrap
  <fantasai> D) Do nothing

  fantasai: The options are in IRC [reads the options]
  <TabAtkins> (A) is not an option.
  fantasai: A is an option because tantek brought it up.
  TabAtkins: It's not because parse time isn't a thing we can deal
             with here.
  <dbaron> TabAtkins: ... variables
  TabAtkins: It's just not an option that accomplishes what we want.
  fantasai: It will deal with the dash for most authors.
  plinss: So it's an option, but not one you like.

  plinss: I'm not hearing consensus. Maybe an IRC straw poll?
  plinss: Type your choice, A, B, C or D.
  <TabAtkins> B
  <sanja> C
  <fantasai> D or A
  <Florian> B
  <Rossen> D
  <dbaron> D
  <tantek> A, ok with C or D.
  <glazou> abstain
  <gregwhitworth> D
  <antonp> abstain
  <astearns> B or D
  <smfr> D
  <Bert> D, then A
  <dauwhe> abstain
  <koji> B
  <Rossen> D
  <adenilson> abstain.
  <SteveZ_> D, because I am not convinced that the solution is an
  <murakami> D
  <fantasai> Just to clarify, this affects both flex-wrap and
             white-space properties

  plinss: It seems the clear winner is no change.
  plinss: Anyone that can't live with it?
  TabAtkins: I'm unhappy because I think people with no webdev
             experience aren't experiencing the pain.
  Rossen: I think this isn't a never change, we should keep working
          on it.
  TabAtkins: There's no other options!
  Rossen: So it seems we should approach this otherwise.

  tantek: I think implementors could support A and if there's
          implementation consensus on that we adopt it.
  fantasai: We generally discourage people doing tag soup parsing of
            their own. We did that in the 90s.
  fantasai: It ended poorly
  plinss: I'm seeing most people saying do nothing, but lots of
          people wanting to keep talking about this.

  Rossen: One more thing before we finish this, why are you pushing
          to change both of these? I see changing flexbox and we can
          do that regardless of whitespace.
  TabAtkins: Reason we're not doing that is consistency in the
             language is more important than theoretical consistency.
  TabAtkins: They need to be either all changed or none changed.
  Rossen: I'm not convinced with that.

  plinss: Let's move on. If someone can get better data for the F2F
          that would be welcome.
  plinss: Next issue.

Remaining Flexbox Issues

  TabAtkins: Next was the naming issue we dealt with before. After
             that is allowing specifying when wrapping should happen.
  TabAtkins: Right now in Flexbox 2 we want to let people do flex
             breaks to get wrapping the way they want.
  fantasai: I think that control of flex wrapping needs a lot more
            discussion since we don't have exact issues.
  fantasai: There's also abspos where we don't understand. There's
            the page breaking controls which also isn't worth
            discussing since we don't have a sense of pros and cons.
  fantasai: So I think we're done for flexbox.

  gregwhitworth: Can you keep us in the loop on the abspos issue.
  fantasai: We don't understand the issue yet, so if you do please
            post and tell us what to do.
  gregwhitworth: I don't know, but I'm intrigued to see what you
                 guys find.

  plinss: Are you expecting to have this for the F2F?
  fantasai: Should.
  <astearns> let's get the flex break issue on the ftf agenda

  Rossen: Is that the same issue we did when you were visiting?
  fantasai: That was a different one.

extending break-* to lineboxes

  fantasai: This was an idea, the break controls are useful for
            fragmentation controls. Do we want to extend that for
  fantasai: Let's say I don't want my links broken across lines,
            they won't break unless the line is too narrow and then
            it will break.
  fantasai: We've talked about forced break controls about breaking
            before and after. Break-inside, I've wanted for a while
            and its showed up in various drafts. We could adopt
            these two wholesale for linebreaking.
  fantasai: break-inside: avoid (for example above)

  <dbaron> seems like interactions with 'white-space' could be
           interesting, though maybe not. At the very least
           confusing to have both...

  tantek: Conceptually, I wonder if there's a possibility where you
          say you don't want it to break unless it won't fit. Maybe
          there's also a case where you don't want it to break, but
          you want it to ellipse.
  fantasai: You can do that with display-inline-block.
  tantek: You need a width and you can't set that.
  fantasai: You do max-width: 100%.
  tantek: That's a lot more complex and you have baseline alignment.
  fantasai: They work by default.
  <fantasai> element { display: inline-block; max-width: 100%;
             overflow: hidden; text-overflow: ellipsis; }
  tantek: With inline block?
  fantasai: Yep.

  plinss: So you don't want a resolution, you just want to introduce
  fantasai: Yes. We should move on.
  <tantek> thanks fantasai - that's interesting, might have to try
  <tantek> worth mentioning as an option

  Florian: Do we have a content problem where previously it did
           nothing and now does something?
  fantasai: Seems unlikely. The break properties are relatively new.
  Florian: Fair enough.

text-wrap: balance

  plinss: astearns?
  fantasai: I can do it.
  <astearns> sorry, was muted

  <fantasai> http://dev.w3.org/csswg/css-text-4/
  fantasai: There's been discussion about balancing lines or text so
            they're approximately even.
  fantasai: astearns and I drafted a proposal that could change a
            lot as we discuss. We want to do CSS4 Text at the F2F.
            We did a ED for CSS4 Text.
  fantasai: We put that in and a couple of things that were cut from
            level 3.
  fantasai: We invite feedback on all of that and at some point we'd
            like it to be official. I don't know if astearns had
            anything else?

  Bert: Are we discussing balance now?
  fantasai: Sure.
  Bert: I think balance is only useful for center aligned. Left and
        right should use indent. It's two things in different
        context and balance isn't an explicit keyword.
  astearns: It's useful with centered. You'd want it on left-align
            headlines. It's a different operation than getting the
            last line length you want. With headlines you can get
            short then average when you're trying to extend the last
            line length you tend not to want very short lines

  Bert: Another interaction is automatic font size. I'd like the
        font size to include the ability to fill the last line.
  astearns: I would call that content fitting. In addition to font,
            you may want other properties. I'm interested in that,
            but I think it's separate.
  plinss: Agree, but we do have to worry about interaction.

  plinss: Anything else on this?
  Florian: I've mentioned my thoughts on the mailing list.


Negative Values for Line Offsets

  tantek: There's a bunch. I'd like to...I put in IRC I was able to
          go through the outstanding issues enough that I could put
          it in the draft. Sometimes we mention the issue inline.
          Some things we have resolutions or Florian and I agree on
          or are close on.
  tantek: First one is one we've discussed previously.

  tantek: I think it's number 38 which is negative values on line
          offsets. Since it's got inconsistent support, it's at risk.
  Florian: One difference between our versions, how you deal with it
           if you do it we agree, but you have that browsers don't
           have to support negative values. I'm not sure I'd have
           that since everyone that supports does support negative.
  tantek: I think I put that before the at risk bit. As long as it's
          at risk if we decide no one is interoperable we can fall
          back to negative values aren't supported.
  Florian: Everyone does it, they just do it differently
  tantek: But we can't spec that. So we can go to CR if that doesn't
          get resolved.
  tantek: Other opinions? Other implementors want to chime in?

  fantasai: A link would be helpful
  <fantasai> http://dev.w3.org/csswg/css-ui/#outline-offset
  <tantek> https://www.w3.org/wiki/CSS3-UI#Issue_38
  tantek: That's the draft and the issue

  Florian: The idea is once you're negative, you're allowed to be
           negative, but you have to stop before the small box in
           the middle is smaller than twice the width.
  tantek: That's from our previous discussion. It's not new.
  Florian: That's the proposal I made on the list.
  tantek: We discussed it on the telecon with no objections. Unless
          there's new information we should go with that.
  fantasai: I'm confused as to why twice the outline width instead
            of 0.
  tantek: So there's something that can be rendered. It shouldn't
          override the outline width or style.
  fantasai: ooooh. I was imaging interior size not exterior. I think
            you should clarify that.
  Florian: So you disagree on phrasing, not behavior.
  fantasai: Yeah.
  tantek: Okay. We can accept that.
  plinss: Maybe even a diagram would be useful

  fantasai: Did we decide if negative are optional, at risk, or both?
  tantek: The intent was at risk. That's what we're proposing. The
          optional bit was before that.
  Florian: We want it this way, but we're worried about
           implementations. The other option is to replace the must
           with a should.
  fantasai: That seems reasonable to me.
  tantek: I'll turn it into a should and take out the may ignore.

  plinss: Objections?

  RESOLVED: Change the must into a should and remove the reference
            to "may ignore"

  <smfr> behavior on non-rectangular shapes needs to be specified
  <smfr> don’t assume the outline is rectangular

ime-mode property

  <fantasai> file:///home/fantasai/w3c/csswg/css-ui/Overview.html#input-method-editor
  <fantasai> http://dev.w3.org/csswg/css-ui/#input-method-editor
  tantek: The basic summary is ime-mode isn't well designed and we
          don't think it should be implemented. What I've edited is
          to obsolete ime-mode
  tantek: To say implementors should drop support ASAP. Authors must
          not use it and users may use a certain hack to fix past
          misuse. This is proposed instead of completely dropping
          since I don't think that captures that it's a bad idea.
  tantek: That's what we've written there.

  fantasai: I've read it and it makes a lot of sense.
  dbaron: I'm not convinced it's a bad idea.
  Florian: The Mozilla implementor said it was.
  Florian: It's not doable on mobile and editing type on mobile is
           though a virtual keyboard. Basically if you're thinking
           of a desktop running windows for an audience in Japan it
           works, but if you break that it doesn't.
  dbaron: We probably need something to replace it.
  Florian: There are things moving in the right direction.
  <fantasai> +1 to what Florian said
  Florian: There are things in HTML hinting at what type of thing
           you expect to be input and the UI can display the most
           reasonable input. There are missing values, but I'm quite
           convinced that ime-mode is a bad idea.

  tantek: Any other thoughts on obsoleting ime-mode?
  fantasai: I'm 100% in favor.
  Florian: The text you have now mentioned it's obsolete elsewhere?
  tantek: As a reference for incompatibility.
  Florian: Yeah. Okay.

  plinss: Do we need a resolution?
  fantasai: I think we do. Document ime-mode as obsolete as
            described in the draft?
  plinss: Objections?

  RESOLVED: Document ime-mode as obsolete as described in the draft

  SteveZ: I think your link to a non-normative should be IDed as
          non-normative so it's not a problem.
  plinss: Just change to a note.
  SteveZ: If it's not in a note, it's normative if it's in a
          normative section.
  tantek: I'll start with a note to make it more clear.

  dbaron: I'm not happy about the precedent set by saying
          implementors that don't have the property shouldn't add it
          and if implementors have it they should drop. I'd rather
          consistent across all implementations.
  tantek: Are you arguing for stronger language?
  dbaron: I think it would make more sense as a should not for
  tantek: Should not support?
  dbaron: ummhum.
  tantek: I'm fine with that. Florian?
  Florian: I'm fine with that. It means IE won't pass the test suite.
  Rossen: IE will have to chat with the editing folks and come back.
          I can't comment at the moment. But the previous would have
          been more favorable because it gives us an out. Dropping
          it since we have it is a question for us and I don't think
          we'll do it.
  Florian: I expect that IE will keep this for quite a while. People
           using IE on a desktop isn't that rare. I think it's fine
           to drop with the understanding it's unlikely to happen
           with IE.

  plinss: Anything else on this one?
  tantek: I've made the changed from dbaron so I'll regenerate.
  Rossen: So you're changing to a strong should not?
  tantek: I'm making it "should not support".
  Rossen: Yeah. Okay
  Rossen: That's a favorable spec for someone who won't support.
          We'll most likely be non-compliant.
  plinss: That's the top of the hour. I'll see most of you in Sydney
          in two weeks!

Publication (after call)

  tantek: About the publication, clilly asked me to put everything
          together and I'd like to publish.
  Rossen: If we don't have a resolution on the previous issue we
          should wait. We said obsolete, but we didn't resolve on
          the should not.
  Rossen: If you want to publish that's fine with the t-1 version.
          Otherwise we should discuss further.
  tantek: I'm okay with that if dbaron is okay with the change
          coming in later.
  tantek: I'll add the 'should not' to the ED after the publication.
  plinss: Do we need a resolution?
  tantek: We resolved to change and publish last week. I'm hoping
          the past stands.
  Rossen: I'm fine with the last, I'm not happy with the
          not-resolved additions. Publish with everything resolved
          and we'll discuss more once the draft was out.
  plinss: Let's go ahead and publish.
  tantek: I'll point to last week's resolution.
Received on Thursday, 29 January 2015 01:23:37 UTC

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