W3C home > Mailing lists > Public > www-style@w3.org > December 2014

[CSSWG] Minutes Telecon 2014-12-17

From: Dael Jackson <daelcss@gmail.com>
Date: Wed, 17 Dec 2014 20:03:30 -0500
Message-ID: <CADhPm3vpEN9Bc-7A4qQ_CKLojGiYKLjBgh3foH=U9mO=F-=RNA@mail.gmail.com>
To: www-style@w3.org
Styling Task Force
------------------

  - It's confirmed that the new task force will meet on 7 and 8
      February in Sydney, just before the CSS F2F

Sydney F2F
----------

  - The wiki will be updated with nearby hotels

Box Alignment
-------------

  - The group was evenly divided as to if 'true'/'self' should be
      allowed in combination with 'stretch'.
  - Several people expressed a desire to have more time to read up
      on the issue before forming an opinion, therefore it was
      decided to resolve on publication without 'stretch' in
      <item-position> and move it back later once the group comes to
      a decision.
  - RESOLVED: Publish a new WD that doesn't have the changes, but
      instead have an issue

Inline Layout
-------------

  - RESOLVED: Publish Inline Layout WD

Counter Styles to CR
---------------------

  - RESOLVED: Take Counter Styles to CR

findRule/deleteRule
-------------------

  - RESOLVED: findRule and deleteRule will apply to the last
      keyframe with a specified value (no change to spec)
  - RESOLVED: For multiple values we expect the number and order of
      values to match, but whitespace will be trimmed by browser. As
      long as number and order is good, you'll get the last rule
      that matches.

CSS3 UI pending edits
---------------------

  - tantek will work on the pending edits this week

Flexbox and Tabbing
-------------------

  - The group had a lot of concerns about the proposal to have the
      tab order follow the visual order and gave a lot of feedback
      of potential breakages with this change.
  - bcampell will create a list of example websites and/or
      screenshots to help further understanding and the group will
      come back to this topic in the new year.

===== FULL MINUTES BELOW ======

Present:
  Rossen Atanassov
  Tab Atkins
  David Baron
  Bert Bos
  Bo Campbell
  Adenilson Cavalcanti
  Tantek Çelik
  Dave Cramer
  Elika Etemad
  Simon Fraser
  Sylvain Galineau
  Dael Jackson
  Brad Kemper
  Chris Lilley
  Peter Linss
  Shinyu Murakami
  Anton Prowse
  Matt Rakow
  Florian Rivoal
  Simon Sapin
  Alan Stearns
  Greg Whitworth
  Steve Zilles

Regrets:
  Angelo Cano
  Alex Critchfield
  Daniel Glazman
  Michael Miller
  Lea Verou

Scribe: dael

Styling Task Force
------------------

  plinss: Let's get started.
  plinss: I got the additional items from fantasai and sgalineau.

  Rossen: I have another about the inaugural meeting about the
          whatever-it's-called task force
  Rossen: Just a quick update, I have a number of replies. The two
          days before the CSS F2F works for everyone. We will hold
          the meeting in Sydney on February 7th and 8th which is a
          Saturday and Sunday.
  Rossen: shans will follow-up with exact location, but it will
          probably be the same place. In the meantime we've resolved
          on a name, so we'll create a ML and wiki soon. It'll be
          similar to CSS meetings.
  plinss: I'll ask about the domain for Houdini. You can start on
          the extf name and we'll carry over.

  <bkardell> I tried to jump in there but couldn't ... trying to
             find out if we will be opening up WebRTC or a conf line
             for that inaugural meeting

  <tantek> Florian - re: CSS3-UI pending edits - planning to do a
           block this week as other tasks have quieted down.
           http://lists.w3.org/Archives/Public/www-style/2014Dec/0201.html
  <tantek> Florian - please don't worry about writing patches for
           the simple edits, it's easier for me to just do edits
           directly than deal with all the machinations of applying
           patches.
  * Florian tantek: thanks.
  * Florian Tantek: Can you join the call, since this has been put
            on the agenda...
  * Florian tantek: i misread your earlier message, and now see that
            you will be on the call from 9:15. Ignore my previous
            request to join, since you are joining already

Sydney F2F
----------

  plinss: Do we know where CSS is meeting in Sydney yet?
  TabAtkins: It's in the Sydney office.
  Rossen: I thought it was on the wiki.
  plinss: I looked, but maybe I missed it.
  TabAtkins: It's all on one line that says place.
  <dbaron> https://wiki.csswg.org/planning/sydney-2015 , under
           "Place"

  Rossen: Has anyone been to the office?
  TabAtkins: Yeah. I can recommend any of the hotels in Chinatown.
             Central business is maybe 15 min walk, but has nice
             hotels.
  Rossen: Central is to the east?
  TabAtkins: Yes. Chinatown is to the south.
  Rossen: Either is close enough to walk?
  TabAtkins: Yeah.
  plinss: If you can get actual names that would help.

Box Alignment
-------------

  fantasai: Can you paste the link?
  <plinss> http://lists.w3.org/Archives/Public/www-style/2014Dec/0267.html
  <astearns> I'm assuming "'true'/'self'" should be "'true'/'safe'"
             in the message?

  fantasai: The issue is in the previous draft we didn't let
            'stretch' combine with overflow. The issue is that this
            doesn't make sense because 'stretch' doesn't respond to
            the keywords.
  fantasai: 'Stretch' is more similar to content-distribution
             keywords. On content-alignment they can't combine with
             overflow position keywords. You can have a fallback
             alignment which can combine, but if you just just
             specify 'stretch' there is no meaning.
  fantasai: TabAtkins checked in with some changes to change how
            things are organized and folded 'stretch' in and it now
            means you can combine 'true' and 'safe' with stretch in
            align-self.
  fantasai: Do we revert that aspect, or do we want to allow this,
            but only for align-self?

  TabAtkins: And what 'safe'/'true' do, for a couple of the
             alignment properties, if you do align-self it does, but
             if it's bigger it goes outside and that might make it
             go outside the scrollable area. We made these so that
             you can say don't do whatever alignment you were going
             to do, just allow the start alignment.
  TabAtkins: 'Stretch' got in there, it's always going to be safe
             anyway, but there are a few other values like start
             that can't be un-safe. It doesn't do anything to have
             'safe', but it allows it because calling out those
             things would make the grammar more complex.
  TabAtkins: This happened to make 'safe' and 'true' apply and it
             doesn't do anything. That's what fantasai is objecting
             to.
  fantasai: I don't think the grammar is more complex, it parallels
            the content property more.
  <BradK> I would rather have complicated grammar than meaningless
          values.

  fantasai: TabAtkins and I don't agree, so you all need an opinion.
  plinss: That you can't scroll in opposite direction is a bug and
          we should fix that.
  TabAtkins: Yes, but for now that's not the question.

  dbaron: I think there's decent arguments on both sides. I can see
          authors having a way of generating values for these
          properties where you'd rather not deal with not producing
          'safe' or 'true'. It also seems odd to have values that
          don't do anything.
  fantasai: Another issue is in the future we might want a fallback
            for the 'stretch' keyword in which case the grammar
            doesn't work the way it's supposed to. It doesn't work
            in the way it does with content-alignment.
  TabAtkins: We'd be in the same boat as align-content properties.
  <astearns> I have a slight preference for not allowing a
             meaningless combination of keywords.

  TabAtkins: fantasai, one thing I realized is the baseline
             properties that don't allow 'safe'/'true' will need it.
             The last-baseline defaults to 'end' so you need to know
             if it's 'safe' or 'true'. We need to apply those to
             baseline so that would leave stretch as the only one
             without.
  fantasai: But in the baseline we have four values that don't
            including 'stretch'. We need to be consistent.
  TabAtkins: Or we can loosen on the other side. It won't do
             anything because it will default to reasonable things.

  fantasai: We need to have someone else speak up so we're going to
            be quiet for 30 seconds.
  * fantasai thinks people who have an opinion should speak up and
             not just talk into the minutes
  * astearns thinks that recording an opinion in IRC should be
             sufficient :)
  * dbaron hasn't really had the chance to digest the issue
  <gregwhitworth> I'm with dbaron
  <gregwhitworth> I would like more time
  <Bert> (Sorry, still trying to understand the issue. :-( )

  plinss: We have 4 people with opinions and we're evenly split.
  bkardell: I'd echo dbaron. There's good arguments on both sides,
            it's difficult to pull the trigger on one.
  Rossen: Should we wait until next week. I'm in the same group as
          dbaron. I haven't had a chance to review and absorb so I
          can have an opinion. It's important enough that we
          shouldn't just resolve for progress. I suggest doing this
          over mail. We can have a deadline for mail.
  fantasai: We want to publish tomorrow because that's the last
            publishing date before the end of year. I propose we
            revert the syntax to the old text, publish the spec
            tomorrow, and keep this on the telecon agenda.
  fantasai: I'd like it to be published and I'm okay to publish and
            add this later.
  Rossen: That sounds good if TabAtkins doesn't object.
  <bkardell> this sounds p reasonable
  <bkardell> +1
  TabAtkins: I'll go with it.

  plinss: I recommend that you revert and add an issue?
  TabAtkins: We'll need to since we have to apply the baseline.
             We'll pop something in there.
  plinss: Everyone okay with publishing the WD?

  RESOLVED: Publish a new WD that doesn't have the changes, but
            instead have an issue

Inline Layout
-------------

  fantasai: There was an issue about floats, I don't know if we need
            to deal with that. Are we deferring?
  dauwhe: I think so. ChrisL has already started the process.
  fantasai: Okay. We'd like to publish a WD.

  Florian: Now that I've reviewed, I've sent some comments about it,
           some of which have been addressed already, but it's a WD
           and it's going in the right direction so go ahead.
  plinss: Objections?

  RESOLVED: Publish Inline Layout WD

Counter Styles to CR
---------------------

  * fantasai was pretty sure we had a standing resolution to take
             counter styles to CR
  TabAtkins: I haven't written the new DoC. There was one comment
             during LC period. It was a comment asking us to add the
             additional counter styles implemented by at least two
             browsers. Made sense so I did so.
  TabAtkins: They were present in the old draft, we had removed
             them, I added them back and that was it. I've had no
             other comments so I believe it's stable.
  Florian: I'd echo fantasai's comment, but yeah.
  plinss: Objections?

  RESOLVED: Take Counter Styles to CR

  plinss: Do we have tests for the new ones?
  TabAtkins: I'm not sure if the existing tests do, but it's trivial
             to adjust so that can be done.
  plinss: That would be good. Standard CR period?
  TabAtkins: Yeah.

  * fantasai wonders where ChrisL is

findRule/deleteRule
-------------------

  sgalineau: Last time we talked we agreed to specify what browsers
             do as much as possible with the warning about a new API.
             For these two methods, the key job is to define the key
             argument, which is a keyframe selector
  sgalineau: That can be single value, percent value or from/to
             keyword.
  sgalineau: That works fine across browsers. One thing we need to
             agree on is if multiple rules match your selector,
             which do you return? Webkit, Blink and IE return the
             first, Gecko does the last.
  TabAtkins: Other way around, I think. In the bug Timothy said we
             switched to last.
  sgalineau: Let me check.

  Rossen: Can you paste the test?
  sgalineau: Yeah.
  <sgalineau> http://jsbin.com/jelili/5/edit?html,css,js,console

  <TabAtkins> https://code.google.com/p/chromium/issues/detail?id=438387
  TabAtkins: Here's the bug that said we switched.
  sgalineau: The build I had returns first. So that means we have
             two browsers doing each.
  TabAtkins: We had two before, we're now three to one.
  sgalineau: I don't think so.
  TabAtkins: That implies we previously were three to one
  sgalineau: I have three to one on doing it first.

  sgalineau: Point is...is there a good reason to pick one or the
             other? We need to pick. I think the last made the most
             sense.
  sgalineau: Now that we cascade the benefit isn't as obvious to
             using last.
  TabAtkins: I'm in favor of sticking to last since we switched.
  dbaron: The code comment says, well, no it doesn't say why. It
          just says last instead of first and references www-style
          posts.
  sgalineau: It used to be the last one had the effect so it was
             reasonable at some point.
  dbaron: I think the intent was the last one was the winning one.
  <dbaron> http://lists.w3.org/Archives/Public/www-style/2011Apr/0037.html
  sgalineau: If we do the last, does anyone from Apple or Microsoft
             object to changing?
  TabAtkins: In your earlier e-mail you said IE was returning the
             last.
  sgalineau: That was wrong. I tried remote IE and it did first.

  sgalineau: The fact they can swing, I think we can change without
             destroying anything. I'm happy with doing last.
  Rossen: I wouldn't say I'm excited, but if we have to switch we
          still have a chance. What about webkit?
  smfr: We're fine switching

  RESOLVED: findRule and deleteRule will apply to the last keyframe
            with a specified value (no change to spec)

  sgalineau: When you specify value, what browsers agree on is the
             number and order must match the selector you agree on.
  sgalineau: So are we okay with requiring the same order and the
             interop issue today is that some browsers aren't happy
             if you have spaces in there. You have to put your value
             without spaces. I think we should get rid of that.
  <bkardell> +1, that's lame
  <dbaron> Gecko converts the selector to an array of floats and
           then tests deep equality on the arrays.

  sgalineau: You need to know the values and query in the same order.
             So if the style sheet says 50%,75% you need to go in
             that order. Is that are problem, or is it okay? That's
             the interop today.
  sgalineau: The main issue is the whitespace. everyone agrees that
             the order must match. The whitespace is the only
             weirdness. I haven't tried escaping and whatnot.

  dbaron: Is there interop on from and to matching 0% and 100%?
  sgalineau: Yes.
  dbaron: And 100% matching 100.0%?
  sgalineau: Good question.
  dbaron: Gecko converts to an array of floats and does testing on
          the arrays. That's how we handle both conversions.

  * tantek Florian are we good re: Agenda item 3? Per
           http://krijnhoetmer.nl/irc-logs/css/20141217#l-221 and
           http://krijnhoetmer.nl/irc-logs/css/20141217#l-234 ?

  smfr: I'd prefer we ignore whitespace which would be a change for
        webkit, but I think it's fine.
  sgalineau: So the user does the trimming?
  smfr: Basically whitespace is ignored or normalized. I think that
        would match expectations?
  plinss: And normallizing float numbers?
  sgalineau: It works in Chrome, I can check.
  smfr: Webkit does it via string, so I suspect we would fail. I'd
        be okay changing that.
  sgalineau: Webkit and Blink are happy with 100.0. I haven't tried
             firefox. It's reasonable.
  <BradK> And 100% = 99.999999999999%?

  sgalineau: So we're saying for multi-value...for single value it's
             matching of number values. For multiple values we
             expect the number and order of values to match, but
             whitespace will be trimmed by browser.
  sgalineau: As long as number and order is good, you'll get the
             last rule that matches.
  <dbaron> sounds good to me

  RESOLVED: For multiple values we expect the number and order of
            values to match, but whitespace will be trimmed by
            browser. As long as number and order is good, you'll get
            the last rule that matches.

CSS3 UI pending edits
---------------------

  Florian: tantek said on IRC that he'd resolve them. Also, he made
           a comment as to if I should write patches. I work better
           if I work on an issue until it's over.
  tantek: That's what the issues list is for. I keep notes on the
          wiki.
  Florian: So I'm not sure if you want me to do less...?
  tantek: I won't use patches for simple things because it's faster
          to make edits directly.

  plinss: Let's not get into the weeds of editing techniques. It
          sounds like you have how to do the edits done worked out.
  tantek: I can get a big block done within the week.
  Florian: Since there's a patch for everything it shouldn't take
           long.
  tantek: Well, the patches do take long.
  plinss: You can sort that out offline

  Florian: I just want to make sure we keep making progress.
  Florian: We've been making a lot of progress on the telecons. I
           don't want to bring this up again since its holding me up.
  tantek: I think we went over it, so I don't know what else to
          discuss.
  plinss: I think Florian wants a commitment to keep up on edits.
  Florian: I think that five things are done and another 23ish are
           pending. I'm hoping it's not tied up too much in the
           future. To be honest, I don't know why you don't like me
           doing them. In the past you said you'd do them and it
           wouldn't hold me up.
  tantek: I typically edit in bursts. I'll get to a block this week.
  plinss: I think when we discussed offline at TPAC, we just wanted
          to set a reasonable time frame of something like 2 weeks.
          I think that's the expectation.
  tantek: Alright.

Flexbox and Tabbing
-------------------

  bcampbell: Thanks to everyone that's been helping me. The problem
             we've been having is when visual order changes the tab
             order is following and there's a bug in Mozilla dealing
             with residual order.
  bcampbell: In a discussion, especially for screen reader, it
             surprised me screen readers would like to follow the
             visual order instead of the traditional path from the
             DOM. So the tab order, I was proposing that it followed
             the visual order.
  bcampbell: The suggested wording is basically saying that rather
             than saying the order doesn't effect the default, we
             say that it does effect the order.

  fantasai: The reason the spec is how it is currently is because
            there's cases you want the order different and it's
            better different and this makes it possible. If you
            always follow visual, you can't have a different order
            unless you futz with your layout. So if you have mobile
            and desktop layout and you have desktop layout side by
            side, but the logical order matches mobile, you want tab
            to follow mobile.
  fantasai: You don't want to just go left to right because that
            visually looked better. You don't want to follow in that
            case. There's another case where someone is using visual
            to make changes that should have been at the source
            level. If you tie them together you can't split. I can
            see that maybe it's better because all the pages are
            terrible, but are we giving something up?
  fantasai: Should we never follow the source order or is it people
            write bad pages?
  fantasai: Are you saying that we should always follow the visual
            order on principle and it's bad to do otherwise, or are
            you saying that we should follow the visual order
            because there are too many bad pages and we should
            accommodate those at the expense of good pages?
  bcampbell: That's a good question and a long one.
  bcampbell: I think the suggestion is that, and I'd like to see an
             example of what you talked about, we're talking about
             the majority of the cases that are keyboard only. I
             think that may be the weakness regarding how are the
             majority using flexbox and just not knowing.
  bcampbell: Having information that using flexbox for mobile and
             we're causing an issue, I'd like to bring that evidence
             back to the group. The way I'm seeing it right now,
             they're asking for the same experience generally for
             web pages. This allows nav-index to fall away, but to
             change after that point we have to use tab index and
             you're forcing someone to use tab-index through the
             page.

  fantasai: So an example would be something like the WG homepage
            where there's a title, an introductory paragraph, and
            then quick links to things you'd want to hit fast and
            then we have short articles. We present linearly. When
            you increase page width, we put the quick links side-by-
            side on the left because that looked better.
  fantasai: In this case you're saying tab order would do links and
            then the introductory paragraph even though the logical
            order is the opposite. We use order because you want
            this on the left even though the source order is
            different.
  fantasai: I don't think you'll see this in column flexbox often,
            but left or right for a visual person, there isn't quite
            as strong of a this comes first. Sometimes these are
            equally emphasized. Or here's the stuff on the side that
            comes first, but I'll color it differently to make it
            less emphasized.
  <fantasai> bcampbell: Here's the layout I was talking about:
             http://csswg.inkedblade.net/staging/redesign/divya/
  <fantasai> bcampbell: (That page responds to media queries. Try
             resizing it very large/very small.)
  <fantasai> bcampbell, The example here in Flexbox shows the use of
             reordering a column flexbox in an illogical way (
             pulling an image up above its header):
             http://dev.w3.org/csswg/css-flexbox/#overview

  Rossen: I have a few things.
  Rossen: What fantasai is explaining based on our experience with
          windows store that use grid and flex to control
          application layout. What we've seen and the feedback we've
          received, controlling tabbing for magazine and news
          related apps, the visual order isn't necessarily what's
          desired.
  Rossen: So if you have sections and sub-sections, you want to
          navigate between the sections. So you have business,
          sports, etc. before you tab inside a section. If you only
          have visual order you have to go through all the business
          before you get to sport.
  Rossen: I would strongly suggest that you take that feedback/this
          kind of feedback back.
  <ChrisL> having to tab through all items of a list is even more
           annoying.
  bcampbell: Isn't that a huge problem for a keyboard user? If
             you're jumping from section header to section header
             and not going into the sections to interact. The
             keyboard only user...
  Rossen: You can always...this is somewhat in the hands of the app.
          If the only thing you use for nav is the tab key, which is
          hardly ever the case, this makes sense. But there's also
          the direction keys where this hub selection makes sense.
  bcampbell: I've seen a lot like this and this is a major challenge
             right now. You have powerful shortcuts and you have an
             advantage over a keyboard user. So you're saying each
             section has a header, you have to do some code to get
             the person into a section. It's another facet of
             keyboard use. I understand what you're saying and I'd
             like to research more

  bcampbell: I'd really want to understand the impact of the
             responsiveness of flexbox and when we're trapping
             people into a particular flow if we flip this as
             suggested.
  bcampbell: I'd like to keep the conversation going and maybe bring
             it up in the next meeting.
  Rossen: I can point you to come windows apps that use complex
          layout that use flex and grid and fragmented content with
          regions where you'll have even more challenges. There has
          been a lot of work done on our end and I believe the
          proposal that you have will be quite limiting.
  bcampbell: OK. I understand what you're saying. I want to get my
             head around what you're saying and understand it really
             well.
  bcampbell: I see it in a different way. It'll take a long time to
             explain, but maybe I can lay it out in a better way.
  <bkardell> maybe it is worth collecting a bunch of use cases and
             say how all are impacted by any choice
  plinss: We'll come back to it in the new year.

  tantek: One of the challenges I find in the discussion is there
          aren't screenshots or URLs pointing to the examples. I've
          seen many layouts that need something more complex than
          sequential tabbing. I've seen it where you have to tab
          through 100 links to get to the next section. If there's a
          passion to fix this, rather than shoehorn an auto
          behavior, I'd like to see documented cases.
  <bkardell> +1 to what tantek is saying
  tantek: A link to a real website where we can see, or at least a
          screenshot that anyone can see. Anyone researching, please
          document incrementally. That allows the best analysis and
          participation from the group

  Rossen: And to add to that, while the examples you brought was a
          tab navigation through a visual map of something, that is
          for me a pretty canonical example where tab reordering
          would be the perfect tool to give an idea, like go through
          in order of population size. The point is you have the
          same set of data, but you want to change the order based
          on the semantic you want to use. Visual only is limiting
          there.
  <ChrisL> tab navigation in maps is really poor
  <ChrisL> yes, its active exploration not "go through everything"
  <tantek> I wonder if there are any good examples of sequential
           navigation for these examples.
  <tantek> perhaps on a /sequential-navigation page on the wiki?
  bcampbell: I agree in that situation, that makes sense. I'm trying
             to speak for keyboard only users.
  Rossen: We understand.

  bcampbell: Let me try and get my research and I'll keep a running
             place for the information and have a good way to have a
             conversation. I see links people have been giving me.
  <tantek> please keep the running documentation on the wiki
  <tantek> not some offline file
  <bcampbell> will do
  <tantek> thank you bcampbell! appreciated!
  <bcampbell> thank you

  plinss: That's the end of the hour. No meeting for the next two
          weeks. Happy Christmas, New Years etc. Travel safe. I'll
          miss the first meeting of the new year.
  plinss: Thanks everyone.
Received on Thursday, 18 December 2014 01:03:58 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:51:52 UTC