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

[CSSWG] Minutes Telecon 2015-01-21

From: Dael Jackson <daelcss@gmail.com>
Date: Wed, 21 Jan 2015 21:00:34 -0500
Message-ID: <CADhPm3tNWoUEuP8zB1XSQYMpJ_UFdSWZ8JVKt7f2XkzsLBZs8Q@mail.gmail.com>
To: www-style@w3.org
Flexbox Accessibility

  - BCampbell brought his revised proposal for addressing the
      accessibility concerns created when Flexbox changes the visual
      order of the boxes and the tab order.
        - The new proposal is to create a method for authors to
            designate if the order is important so that only those
            items with the important signifier will have their tab
            order changed in line with the visual order.
  - There were several questions about the implications of the
      proposal and clarifications about if a change is even needed.
  - Another suggestion what the the directional nav-* properties
      from CSS3 UI might help address some of the issues.
  - Several people brought up that this issue seems larger than just
      Flexbox and has been around since early CSS.
  - It was agreed that this topic would be best solved at a F2F
      meeting. bcampbell said he'd try and make it to Sydney, but
      likely it would have to wait until NYC in May.

Grid Layout Issues

  - RESOLVED: align-content and justify-content on grid containers
              operate on the grid tracks (allows distributing extra
              space between grid tracks)


  - tantek will make note of the outstanding issues and objections
      in the WD so that they're a part of the publication

Color & Background Serialization

  - RESOLVED: Accept the proposed change for the serialization order
      for <final-bg-color> (available here:

Floats & Initial Letters

  - fantasai brought her and dauwhe's potential solutions for when a
      float is interacting with an initial letter.
  - SteveZ raised an alternate proposal that he thought might handle
      the problem a bit better
  - Several people were unsure as to which proposal is best without
      visual examples, so this topic was also declared a good fit
      for the F2F in February.


  Rossen Atanassov
  Tab Atkins
  David Baron
  Bert Bos
  Bo Campbell
  Tantek Çelik
  Dave Cramer
  Alex Critchfield
  Elika Etemad
  Simon Fraser
  Daniel Glazman
  Koji Ishii
  Dael Jackson
  Toru Kawakubo
  Brad Kemper
  Chris Lilley
  Peter Linss
  Michael Miller
  Edward O'Connor
  Florian Rivoal
  Andrey Rybka
  Simon Sapin
  Alan Stearns
  Lea Verou
  Steve Zilles

  Sylvain Galineau
  Simon Pieters
  Keshav Puttaswamy
  Ian Vollick
  Greg Whitworth

  Scribe: dael

  glazou: Let's start
  glazou: Anything to add to the agenda or discuss before we start
          to official agenda?
  glazou: There's one item from koji, but I'm not sure we'll have
  <tantek> glazou: I'd like to prepare a CSS3-UI draft for
           publication before the f2f
  <glazou> tantek: ok, will put that between items 2 and 3
  <tantek> thank you glazou

Flexbox Accessibility

  bcampbell: Let me paste the wiki.
  <bcampbell> https://wiki.csswg.org/spec/css3-flexbox/accessibility
  bcampbell: After posting some arguments and replies, it was my
             example that I put in with a trivial flexbox that was a
             diagram, I agree it was trivial and we need to address
             the holy grail of layout.
  bcampbell: I did some research on that and realized it says the
             sequence of the containers in this layout has no
             meaning and therefore rearranging visually has no
             consequence. We have an argument against that from Matt
             King in IBM who is somewhat of a spokesperson for the
             blind and he's said that he wants it to work for the
  bcampbell: After seeing that there's real need and a meaningful
             sequence, I talked to Richard and a developer on a high
             profile IBM app to understand why we have this issues
             and what exactly they want. Flexbox has the opportunity
             to be powerful for designers that need to move things
             visually and not get developers to change the code.
  bcampbell: There's several examples that I can site where data
             comes into the client and you're able to arrange the
             data using Flexbox. Those developers are crying out
             about losing the Mozilla "bug" because they're not
             going to update or use tabindex to go through.
  bcampbell: So we have a complex, rich application, like an e-mail
             app, so that's the other side of the power. To go back,
             the argument to force browsers to update tabbing order
             is what I'm hearing from the disabled community.
  bcampbell: From Richard and I's discussion, what we need is a
             parameter to tell if the sequence is meaningful or not.
             If it's not meaningful, we can stay with the old way.
             When it is meaningful, we need to be able to tell the
             browser that it is and switch the tab order.
  bcampbell: The proposal has changed more to allow Flexbox to have
             the power of doing it either way.
  bcampbell: I have two questions to ask. The first one is if we
             have anyone that knows today how the backlog is for
             complaints about the way Mozilla reorders for Flexbox.
             The bug has been around for a long time and I'd love to
             know if it's a huge point of contention.
  bcampbell: I'd also like to understand better, and everyone has
             been good at explaining and helping, but I'm wondering
             in this holy grail layout, starting tab order in the
             middle of the content and page, what situation does a
             user need to do that?
  bcampbell: I'm from a standpoint of just people using a webpage,
             not people with a disability. In general I'm going to
             assume this isn't a huge deal.
  bcampbell: I'll open it there.

  <dbaron> Is this discussion supposed to be primarily about tab-
           order, or also (which I thought was more important) about
           reading order?
  glazou: tantek?
  glazou: dbaron go ahead.
  tantek: Sorry I was muted. I'm hoping this is one of the areas
          where directional nav can help such as when there's a
          scenario when the author...
  tantek: uses Flexbox to move things and the tab order is non-
          obvious and not fixable by the browsers, but the author
          can say I know where things belong.
  bcampbell: I'm unfamiliar with the spec language that you mean.
  tantek: Directional nav-* property in CSS3 UI. Let me get a link.
  <tantek> http://dev.w3.org/csswg/css-ui-3/#nav-dir
  <astearns> http://dev.w3.org/csswg/css-ui/#nav-dir
  tantek: Take a look at that and see if it could help from
          authoring side.
  bcampbell: Interesting.
  <astearns> directional navigation is separate from tabbing, yes?
  <fantasai> astearns, yes

  <fantasai> I think creating an 'order' property was a mistake, it
             should have been 'visual-order' if only affects the
             visual order.

  dbaron: One thing about this discussion was that there was...a lot
          of the discussion seemed to be about tabbing order, but
          we've been talking about what is the logical order in
          which to read the content or do anything other than how
          you put it on the screen along the x and y axis
  bcampbell: I think what you're referring to is the visual order
             may be different than logical. The answer I got on that
             was mainly from Matt King. He was adamant that all
             screens should follow the pattern, left to right, top
             to bottom. That is not necessarily the visual flow on a
             screen, but it's the flow screen reader users
             understand. That's where it starts to get subjective.
  bcampbell: You can manipulate that via visual hierarchy, but I
             think that argument when you get to those who want it,
             they want it the way its always been.
  dbaron: At some point what you said is you want a switch that says
          if you want things in the order as reordered by order or
          in the original order? I think 'order' is that switch.
  dbaron: The idea of order is the DOM should be in the logical
          order. If you want the visual different you use order to
          manipulate that.
  bcampbell: But if you use order to manipulate the visual order,
             this is the basis of what we're talking about, then you
             have a tabbing order that jumps everywhere. If the
             visual is meaningful to the viewer, you need the
             sequence of the tabs to flow in a meaningful direction.
  dbaron: If it's meaningful, they shouldn't be using order, they
          should do the DOM in that order.
  bcampbell: In principle I agree, but that isn't how it's being
             used and it's sort of unreasonable in a larger, agile
             team environment.
  bcampbell: The other part is developers are finding that the speed
             of CSS to move things is faster. Inside of IBM on high
             profile apps it's that they're using Flexbox in any way
             they can. That has tons of implications and breaks
             things for those with a disability. Without a switch to
             say we want to change the order and say that we want
             this to flow in a meaningful way, they need that to get
             the benefits.
  bcampbell: If the idea is to not have those benefits for Flexbox,
             how do you get people not to mess things up for those
             with disabilities?
  bcampbell: Can I understand the arguments against adding a switch
             other than dev should be doing good coding? I think
             we're stretching CSS and if it's moving in this way
             with Flexbox and Pseudo Elements I think we'll have to
             change the stance of updating the DOM backwards.

  <leaverou> Not having tabbing order follow that order that reduces
             its usefulness. For example, if you pin posts in a
             forum with order: -1; wouldn't you expect tabbing to
             respect that? I can't think of any case where you would
             want tabbing to follow the source order
  * leaverou (but I can only get part of the discussion, so feel
             free to ignore of the above doesn't make sense)
  <fantasai> leaverou, the argument we're making is that you
             shouldn't be using 'order' for semantic reordering
  <fantasai> leaverou, which is very clearly stated in the spec, but
             hasn't been reflected in e.g. your favorite tutorial
  <ChrisL> you shouldn't be using 'order' for semantic reordering
  <leaverou> fantasai: no matter what we evangelize, authors *will*
             use it that way, just like they're using :before and
             :after for semantic content too. proper accessibility >
             semantical purity IMO. Also, what *is* non-semantic
             reordering? Is there any example of that? (sorry if it
             has been mentioned, I keep dropping)
  <fantasai> leaverou, consider main vs navigation sidebars. Putting
             sidebar on left or right is a visual decision that
             shouldn't affect navigation/speech order

  <tantek> bcampbell: can you provide a URL to one of these high
           profile app examples that we can look at ?

  * bradk doesn't think CSS should be an excuse for bad HTML
  <tantek> bradk I agree and you should say that on the record
  * fantasai agrees with tantek's point about speaking up :)

  ChrisL: fantasai made the point in IRC, you shouldn't use 'order'
          to modify the semantic order, it's designed for visual.
          There are things used for alternate reading orders. It's
          all very well to say the content and DOM should be in
          natural reading order.
  ChrisL: Say you have a map and the reading order depends on what
          part of the map you want to look at. If you want heights
          you can tab through that, or shops and tab through that.
          There isn't only one right order. Reordering the DOM all
          the time also isn't a good answer.
  bcampbell: I think what I pinpoint is when you say stuff like
             should, I get that. I agree that you should do it the
             right way. I'd like to look at the directional-nav
  bcampbell: What I'm seeing from all sides is that this flexbox
             tool could be a great possibility for what designers
             can do. To go back to all these teams and say no, I
             guess that is an option, but I'm hearing loud voices
             that say flexbox is awesome for these things, but a11y
             says flexbox is killing us.

  * glazou thinks we should speed up a bit, already 18 mins on this
  * fantasai it's a complex topic, I don't think there's much speed
             to be had
  * glazou fantasai if it needs more, it’s a good ftf item
  * fantasai it's def a good f2f item, I think
  * tantek agrees with fantasai, and notes that this is perhaps one
           of the very important aspects of flexbox. also +1 to f2f
           discussion to see the problematic layouts in person.
  * Rossen agree to spend longer time on this during f2f
  * dauwhe is NYC in May too late?

  bcampbell: The simple solution for everyone is to allow people to
             use flexbox. I'm sort of beating a dead horse. The
             argument to add a parameter, if that's on the table,
             the argument is that you shouldn't be adding things in
             that order.
  astearns: I have an argument about adding a switch.
  astearns: Having a flexbox specific switch is a little too narrow.
            We considered a switch that changes the way pointer
            properties go in display order rather than DOM. We
            should consider a switch that allows us to change tab
            for all the ways we can manipulate display.
  TabAtkins: Caring about order is a narrow view that doesn't
             address the problem. There's lots in flexbox that
             causes problems. We need to address visual order rather
             than DOM order directly. Maybe that's a CSS property or
             maybe it's something for a11y.
  bcampbell: That was part of the problem. If you're changing the
             visual order it needs to be accessed by the a11y tree.
             That sounds like a huge undertaking that can take a
             long time.
  TabAtkins: Not necessarily. That's the answer, there's no way
             around it. In order, you can force direction in upwards
             or rightwards direction, that reverses your normal flow.
             The assumption that DOM table order will match visual
             order isn't really valid with advanced layout.
  fantasai: It's worth noting with MQ, the visual order can change
            depending on the device or as I change the width of the
            browser window. If you want to insist that you want it
            to go strictly left to right top to bottom in this size
            for this device, but if I change device or screen width
            I want to change the reading order to match that
            different order, then that should be a screen reader
            feature that reads the page in strictly visual left to
            right top to bottom order, and handles all the different
            ways of repositioning items (including flexbox, grid
            positioning, floats, abspos, etc.. Any way you can get
            things out of order, if you want that visual order you
            should have a feature that does that.

  glazou: bcampbell will you be in Sydney?
  bcampbell: Not unless I can make a good argument for it.
  glazou: It seems to me this is an excellent topic for a F2F
  bcampbell: I agree. I can work on it, but I doubt it. That's a
             good question. NYC if we don't have a resolution before.

  tantek: We've been able to rearrange content in CSS for a long
          time. This isn't Flexbox in particular, it sounds like
          you're finding new examples. Links would help us see if
          it's a new problem or the same old one. Presentation vs
          DOM problem has been around since CSS1
  <ChrisL> yes, floats have provided reordering since forever
  bcampbell: The question is if Flexbox doesn't give you more
             flexibility, why have it?
  tantek: It gives you more flexibility. The problem case we've had
          floats doing this since forever, positioning, tons of ways
          before flexbox. If we want this semantic order we
          shouldn't monkey-patch, we should solve.
  bcampbell: I completely agree.
  tantek: I think that's why people are asking for it at a F2F
  <astearns> all the other ways we've been able to reorder display
             have been hacks - using features not meant for layout.
             Flexbox is the first feature meant for layout, so
             keeping tab order consistent with the intended layout
             is a bit more important than before

  glazou: I'm sorry we don't have a conclusion, but I suggest we
          move on.
  bcampbell: This move more forward another step. I'll see about the
             F2F. Thank you.
  glazou: If you can't make Sydney, let's do it in NYC.

  <bradk> Is there any reason why nav-index can't solve this?
  <bradk> Nav-index: visual-order
  <tantek> bradk nav-index was a poor design, and only addresses the
           tabbing problem
  <tantek> or only *tries* to
  <tantek> er, *tried*. sigh.
  <astearns> bradk: using nav-index along with order is a
             maintenance nightmare
  <bradk> Expand nav-index to affect screen readers too then
  <tantek> bradk, astearns: if anything I'd prefer to brainstorm a
           'nav-next' property similar syntax as 'nav-up' etc.
  <tantek> bradk - now that's crazy nav-index spooky side-effect
           from a distance stuff! :/

CSS Grid Layout Issues

  glazou: Rossen you requested a week on this.
  Rossen: I'm okay with it.
  <Rossen> we did re-review it one more time internally and are OK
           with the proposed change
  glazou: So, who raised the issue? Was it you fantasai?
  fantasai: Let me try and remember it.
  fantasai: The issue was we wanted to update the spec so
            space-around and space-between creates space between the
            grid tracks. That gives us some useful functionality and
            is consistent with how items are thought about.

  glazou: So Rossen says he agrees.
  glazou: Objections?
  <andreyr> no obj

  RESOLVED: align-content and justify-content on grid containers
            operate on the grid tracks (allows distributing extra
            space between grid tracks)

  glazou: Okay for everyone?


  <Florian> I am joining now
  <Florian> give me 1 minute
  tantek: Thanks to Florian help we've made good progress with
          resolutions. I would like to publish a draft before the
  <fantasai> Publish early, publish often
  tantek: I'd like to both continue to resolve the issues and
          anything we can't resolve in time I'll incorporate inline
          to the spec. I wanted to see if that plan is amenable to
          the group and, if so, I'll follow that plan and have
          something for next Wednesday.
  ChrisL: Sounds good. Can I have it by Tuesday for the publication
  tantek: I can do that, but I wanted to let the group review. If
          people are okay with what's there and the continued
          progress, that's fine with me too.
  ChrisL: If you have it for Tuesday, I can put it in the queue and
          if we don't resolve on Wednesday I can pull it out.
  tantek: Okay.

  glazou: Anyone object to the publication?
  fantasai: I'm in favor.

  TabAtkins: I think it's reasonable for Florian to be a co-editor
             with everything he's put into the draft
  tantek: I'll make sure Florian is acknowledged.
  tantek: Florian has put a lot in, but there's been a lot before.
          I'll give Florian proper acknowledgment.
  * dauwhe agree wtih TabAtkins
  glazou: To add to what TabAtkins said, I think he should be a co-
          editor, but we won't spend the rest of the call on it.
          He's doing major work. Lets go back to the main subject.
  * fantasai agrees with TabAtkins and glazou
  <ChrisL> I agree it makes sense for Florian to become co-editor.
           And +1 to publish
  * tantek TabAtkins glazou fantasai ChrisL I will definitely your
           suggestion under strong advisement. I'll discuss with
           Florian also.
  * ChrisL @t thanks


Color & Background Serialization

  <glazou> http://lists.w3.org/Archives/Public/www-style/2014Dec/0194.html
  glazou: That was from Sebastian Zartner.
  <leaverou> I think it makes much more sense at the end, because
             it’s *underneath* the background image, so it follows
             the order of the rest of the bg layers
  TabAtkins: I can do this. Apparently, currently the grammar for BG
             puts the bg-color at the end of the last layer. The
             serialization matches the grammar. Apparently Firebug
             users prefer it at the front. Are we okay with
             switching the serialization around? Is that a compat
  <leaverou> is there any reason to put it in the beginning besides
             people asking for it? Did they provide any rationale?
  dbaron: You're putting the color at the beginning of the last
          ident instead of the end of the last.
  TabAtkins: Yeah. That's what he's asking for.

  TabAtkins: I'm reading dbaron's comment on it. It sounds like it's
             to make the code simpler.
  TabAtkins: I don't care either way. It's a tiny change. fantasai
             should be the one worrying about accept or reject.
  smfr: Any feelings on the compat risk of this?
  TabAtkins: No feelings.
  dbaron: Are browsers interop now?
  TabAtkins: I'm testing Chrome.

  TabAtkins: It's only asking to rearrange the serialization of the
             last layer. It's not a meaningful change.
  glazou: The main question isn't how the browsers are serializing.
          Are there frameworks that parse it and expect the color at
          the end?
  TabAtkins: No idea. Chrome puts the color at the beginning.
  smfr: Same with webkit.
  dbaron: Which implies it's fine the change.
  <Rossen> can you share the tc?

  fantasai: The reason for end is that it's painted at the bottom of
            the bg layers and the bottom layer is the last with
            multiple layers. That's the original rational.

  TabAtkins: I'm either insane or Chrome has a completely broken
             serialization of the bg shorthand. It looks like we're
             100% broken.
  TabAtkins: This is what I get...I don't know how we completely
             broke that, but it's crazy times.
  dbaron: We didn't get the "this".
  <Rossen> TabAtkins: can you share your test case pls?

  * TabAtkins rgb(255, 0, 0)
              repeat, repeat scroll, scroll 0% 0%, 0% 0% / auto,
              auto padding-box, padding-box border-box, border-box
  * TabAtkins background: url(foo), red url(bar);

  TabAtkins: So ours is an error.
  TabAtkins: It does look like color is first.
  ??: So there's not that strong of dependences on how this is

  glazou: So are there objections to the change?

  RESOLVED: Accept the proposed change for the serialization order

Floats & Initial Letters

  <glazou> http://lists.w3.org/Archives/Public/www-style/2014Dec/0166.html
  <ChrisL> initial letter I18n examples from richard ishida
  fantasai: When dauwhe and I worked on initial letters, we
            discussed a lot of things already, but not how to deal
            with if there's a float on the first or second line of a
            paragraph with a two line drop cap.
  fantasai: We went with the float clears the initial letter as if
            the initial letter was a float.
  fantasai: Other options were float is between the initial letter
            and the rest of the text. Or it fits between initial
            letter and the rest of the text.
  fantasai: I think there's a reasonable argument for at least two
            options. If the float is on the first line and not the
            second, it's awkward no matter what.
  fantasai: If you want an image at the beginning you can put it
            before the paragraph with the initial letter.
  fantasai: Generally an image is an item on it's own.
  fantasai: I wanted to see if there's other feedback

  <tantek> aren't such floats usually FOR the initial letter

  SteveZ: I sent you another interpretation on the ML which is to
          say we should treat the initial letter as defining what
          the first line or current line is which means the float in
          the second line would move to the front and up because
          it's part of the initial letter sequence.
  SteveZ: The argument is the initial letter has moved the line it's
          shortening so it's part of the same sequence. It would
          give you a fairly reasonable handling of most cases, even
          with shorter lines.
  Florian: I was with you until the last thing.
  SteveZ: That would be okay because it would float beneath the
          initial letter.
  Florian: I thought it would get to float below.
  SteveZ: It's not perfect, but I think better.
  fantasai: I think it's an interesting interpretation. You can get
            yourself into interesting floats because the float might
            be on the second line, it fits on the second line, so it
            should shift left and it fits, but then when you move it
            up it doesn't fit anymore because the first line is now
            also shortened.
  SteveZ: You might need logic like that in Regions, so you make
          your decisions and if the layout changes, you ignore that.

  fantasai: I'd like dbaron opinion.
  Rossen: Sounds like a lot for doubtful benefits. The layout logic
          is quite complicated for something that's complex enough.
  <Florian> floats are hard enough already
  SteveZ: It's no worse than two floats on one line.
  Rossen: If the initial letter is a float, yeah.
  fantasai: no
  SteveZ: The alignment is different, but it's basically a float
  <dbaron> we should be moving away from treating the initial letter
           like a float
  <tantek> dbaron meaning ::first-letter ?
  <dbaron> tantek, yes

  fantasai: Floats depend...you never move a float up. You can
            decide if it fits, as you layout the text you see if it
            fits on the line and if it does, great, and you shift
            the position. If it doesn't fit you push to the end of
            the line and continue layout.
  fantasai: If you move it up, you can't do that. Here's my line #2,
            it fits, great, but we have an initial letter so you
            have to push it up, shorten the first line, and then you
            have to re-layout and the float may no longer fit. So if
            you're not moving up you can layout, but in this case
            you have a cyclic dependency.
  SteveZ: It's no worse than you have to take the length of the
          lines being shortened by the drop cap.

  tantek: I think we should capture this as an outstanding issue. I
          think it would also benefit from F2F visual discussion.
  Florian: Use cases would be good

  <fantasai> I want to note that if you want to put a float in the
             top left corner, you can already do that
  <fantasai> Just put the float before the paragraph

  dauwhe: I haven't seen an example where there's this possible
          interaction so I want to do a search for that.
  Florian: I think Steve's proposal is sane, but it's harder, and to
           see if it is worth solving, I'd like to see use cases.
           Otherwise, fantasai's solution is simpler, and also sane.
  dauwhe: I also think initial letter is different than a float.
  tantek: I also see Rossen's concerns about adding complexity
          without real world examples.
  dbaron: What we need to solve is let's not have cases where the
          spec says there should be a result that's unachievable,
          but else wise I agree.
  tantek: I think with an addition that we find that out from impl
  dbaron: We already know that it is.
  <dbaron> I think the simple solution is saying that a float that's
           not in the first line and intersects (i.e., on the same
           side as) a drop cap clears below the drop cap
  <fantasai> dbaron, that's exactly the proposal dauwhe and I have

  <SteveZ> My proposal is documented in:

  fantasai: To summarize. I think your idea is interesting, but it
            introduces a complexity in floats that doesn't already
            exist. It also can create a loop. I think this is a bit
            of an edge case. Lastly I agree with Rossen that this
            doesn't seem like a really important thing to solve.
            That complexity doesn't seem to be worth dealing with
            for such an edge case that is rare in practice.
  fantasai: That's why I think you have an interesting idea, but not
            a good idea for us to go with.

  tantek: I don't know which is better because there's a lack of
  SteveZ: I thought we were waiting to the F2F to solve
  dauwhe: I can make diagrams. Cool.
  <ChrisL> diagrams++
  fantasai: Anyone want to pursue SteveZ case?
  <astearns> let's wait until the ftf to decide, including steve's
  Florian: Without examples, no, but if he has examples maybe.
  tantek: I can't answer without examples.
  SteveZ: I also have to understand putting the float before the
          drop cap a bit better.
  <Bert> (Also seems asymmetric to me: you might to move up when
         floating left, but probably not when flowtimnmg right...)

  <fantasai> <img> <p>Drop cap paragraph/p>
  <fantasai> img { float: left;
  <fantasai> Done. Puts it in top left corner of paragraph


  glazou: We're at the top of the hour
  Florian: Quick question on CSS3 UI. There was one resolution that
           we made that was objected to. If we pub without changes
           that's fine, but I don't want to make edits and change
  tantek: Issue 40?
  Florian: No. If we publish, publish as is and don't roll in the
  <Florian> I cannot hear you
  tantek: I can capture the objection. I'd rather have the edits in
          and capture the consensus and the objection.
  <tantek> this is about Issue 47 resize (I think)
  <Florian> it is about issue 47
  <tantek> need URL to the objection
  <Florian> it's in the wiki
  <tantek> great. thanks.
  <Florian> Objection was from Tab and smfr.

  glazou: I'm lost. What are you waiting for tantek?
  tantek: Nothing.
  glazou: Okay.
  glazou: That's it for today. Talk to you next week and thank you
          very much.
Received on Thursday, 22 January 2015 02:01:05 UTC

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