[CSSWG] Minutes Telecon 2015-02-25

WebVTT Review

  - Everyone should review the proposal and send comments to the
      email thread.

Abspos Change Compat Risk

  - Everyone present thought the change was still the right thing
      and that more implementors need to make the change.
  - Further discussion on the topic was deferred until next week
      when more implementors are on the call.


  - Florian requested that everyone look over his proposed solution
      to issue 69 (available here:
  - RESOLVED: Add some normative text to make it explicit that the
              stacking of focus outline is left to the implementor
              to provide better user experience.
  - RESOLVED: Tighten the language of the directional focus property
              behavior and include an informative note about the
              behaviors we're considering and welcome/actively
              solicit input.

Allowing @import to be conditional on @supports queries

  - RESOLVED: Add @supports to Cascade Level 4
  - RESOLVED: Create an ED for Cascade Level 4

Logical Border Radius Properties

  - RESOLVED: Properties referencing corners drop the axis mentions
              and go into the block axis first, for example


  Rossen Atanassov
  Tab Atkins
  Sanja Bonic
  Bert Bos
  Bo Campbell
  Adenilson Cavalcanti
  Tantek Çelik
  Dave Cramer
  Alex Critchfield
  Elika Etemad
  Simon Fraser
  Daniel Glazman
  Tony Graham
  Dael Jackson
  Toru Kawakubo
  Brad Kemper
  Deirdre Lee
  Peter Linss
  Mike Miller
  Edward O'Connor
  Florian Rivoal
  Simon Sapin
  Greg Whitworth

  David Baron
  Chris Lilley
  Dirk Schulze
  Mike Sherov
  Alan Stearns
  Lea Verou
  Johannes Wilm
  Steve Zilles

  Scribe: dael

  plinss: Let's get started. Anything to add to the agenda?
  smfr: I have something remove.
  smfr: Transform-style 3d issue has been resolved by email.
  plinss: Okay.

  plinss: To start, happy birthday glazou
  * dauwhe +1

WebVTT Review

  plinss: There's been discussion on e-mail, but do we have group
          consensus feedback to send? Do folks need time to review?
  plinss: I'll take that as a no. So everyone should review and send
          comments on the e-mail. We'll gather feedback as a group

Abspos Change Compat Risk

  gregwhitworth: We made the abspos change where it goes like 0,0
                 for flex items. Google docs has an issue. I posted
                 the flipboard issue. I've got two bugs open against
  gregwhitworth: I don't know what we do because I understand why we
                 have the change. I guess I wanted to make the group
                 aware of it.

  fantasai: I thought the change was there to simplify what's going
            on. If the old behavior is what's useful we might want
            to go with that.
  fantasai: I think we ran into issues with complexity where you
            have a placeholder that has to follow layout and can't
            affect order and there's an invisible thing adding space
            so we took it out of flow.
  fantasai: If websites want this behavior we need to dig into these
  Rossen: I don't believe this is what people want, it's what people
          have. They're using what they have.
  Rossen: When we were discussing this in Sophia, we agreed the
          simplified algorithm gets us quicker to better interop.
          The abspos inline algorithm will be tricky, though
          everyone had a implementation of it.
  Rossen: I think what gregwhitworth is bringing is relevant and if
          we stick to the current algorithm which I personally
          prefer, then the question is are the other implementors
          going to follow soon. If they do, this will basically
          dictate when content will change.
  Rossen: Does that make sense?
  gregwhitworth: That's similar to what I was going to say. It's not
                 that they were asking for a specific use case, they
                 just happened to fall into it.
  gregwhitworth: It's an unfortunate thing. The sooner all other
                 browsers change the devs will see it. I think we
                 should keep it because we're moving to better
  fantasai: Okay.

  fantasai: We need to hear from other implementers.
  gregwhitworth: Is TabAtkins on the call?
  TabAtkins: Yes.
  gregwhitworth: What do you think?
  TabAtkins: I haven't had the change to check with my team.
  gregwhitworth: Why don't we circle back. dbaron isn't on.

  fantasai: While we're on flexbox, TabAtkins did you sort out the
  TabAtkins: I couldn't figure out where, so it was yesterday that I
             did it. Let me see if anyone commented.
  fantasai: That holds up publication.
  TabAtkins: No response yet. I'll let you know when I do.
  fantasai: We'll have to come back next week.
  TabAtkins: Yes.


  Florian: We just got a WD out.

  Florian: Also, I sent an email about issue 69 which was the long
           standing one about box sizing.
  Florian: I went through CSS 2.1 and figured out where everything
           should be and wrote the patch and put into CSS3 UI where
           it goes. We don't need to discuss, but I'd appreciate
  Florian: I erred on more explicit.

  Florian: Things to discuss, issue 79
  <Florian> https://lists.w3.org/Archives/Public/www-style/2015Feb/0357.html
  Florian: CSS3 UI doesn't define outline overlap. CSS2.1 does, but
           it gives 2 options. Does anybody remember why we have 2?
           All the browsers seem to do the same thing.
  tantek: That's desktop only.
  tantek: A lot of the looseness in outline has been based on
          experience on platforms where outline is essential for
          indicating user focus and that's not common on desktop.
          It's common on TV or other devices with directional nav
          like a remote.
  tantek: The rendering of the outline was left looser in CSS3 UI
          because platforms needed it for better UI. This is where
          2.1 specified too much precision. On some platforms we
          choose a better UI instead of strictly what CSS2.1 said.
  tantek: That's the experience from like early 2000 to now on
          non-desktop. It's important to keep that in and it's easy
          to forget since it's non-desktop specific.
  Florian: Okay.

  tantek: That's the history. Maybe we should have a note that
          mentions that. This isn't the first time it was mentioned.
  Florian: I'd go even further since CSS UI doesn't replace. If we
           have a note saying we don't define it's only in 2.1 If
           you want looser it should be normative
  tantek: That makes sense.

  Florian: Do you have examples of current non-desktop browser?
  tantek: Last I checked every set top box was violating it because
          it's more important to have the line visible to the user.
          It's not the easiest to set up, but I don't see why
          browsers would regress their UI.
  Florian: I was just trying to figure out why one is looser than
           the other with no clear resolution. But do these TV UIs
           do the same and we can spec that?
  tantek: They did similar as of 10 years ago, but I don't have
          modern set top devices to check today. My presumption is
          they stayed similar, but I can't guarantee. I wouldn't
          want to spec their behavior.

  tantek: The other things is there's a lot of experimentations with
          Web VR and we're going to want hooks into CSS. Outline and
          Focus behave even more differently in 3D. I don't see this
  tantek: Seeing the spectrum of implementation will broaden. We can
          add some normative text to make it explicit that the
          stacking of focus outline is left to the implementor to
          provide better user experience.
  Florian: I have no direct knowledge, but that sounds reasonable. I
           think it would be better.
  tantek: Since it's normative in 2.1 it needs to be normative here.
  tantek: Two use cases are set top boxes and web VR.

  Florian: Anyone else have something to add?
  tantek: I would welcome input from anyone working on a non-desktop
          platform, especially if you have experience with outline
          rendering. More experience gives us more data.
  plinss: Other opinions?

  RESOLVED: Add some normative text to make it explicit that the
            stacking of focus outline is left to the implementor to
            provide better user experience.

  Florian: If we have more time, I'd like to do issue 78.
  <Florian> https://lists.w3.org/Archives/Public/www-style/2015Feb/0344.html
  Florian: This is about the directional focus property.
  Florian: The way it's written, you can make something focusable
           that wasn't before. It's not implicit, but it's intended
           that the focus connector will match. I think explicit
           wouldn't hurt.
  tantek: Last time we discussed I thought we couldn't resolve on if
          you did a nav up, should it make the element focusable.
          Someone was arguing it should nav to the first focusable
  Florian: That was fantasai disputing this. I think the current
           intent is what you say.
  Florian: The spec is currently implicit but ambiguous.
  Florian: We should make the intent explicit and that a selector
           should match, but we should consider that it makes things
           un-focusable and focusable.
  tantek: I agree with your conclusion, but I wanted to bring it up
          since it wasn't consensus. I want to be upfront with the
          group that those are the ideas on the table. Even if
          Florian and I agree, the group should know about the
  tantek: I want the group to approve or tell us to do more.

  Florian: Both behaviors are useful and I'm not strongly minded
           about which to choose. Which one should be the default
           I'm not sure.
  tantek: I'd rather a smart default instead of a switch unless
          there's a use case that both are useful.
  tantek: From that prospective, consider this a call for examples
          or experience from anyone using directional focus
          property, especially if you're using them for otherwise un-
          nav-able properties.
  tantek: We haven't heard a lot so far.

  fantasai: Two other things. Existing implementations may have
            content so we might not have a choice. Second is this
            interacts with HTML and accessibility in widgets so
            those people might have feedback. Making something
            focusable without reflecting this in the HTML, is that a
            thing we want in the web platform
  <bcampbell> thanks for mentioning the accessibility implications,
              would like to investigate further and help there.
  TabAtkins: In particular some things are only focusable when other
             things are the active focus.
  tantek: fantasai's insight is correct that we might not have a
          choice if implementations have converged here. If
          implementations are different, then we can re-access and
          understand why implementations are different.
  tantek: In that case, content across implementations is unlikely.
  Florian: In terms of current implementations I think they do agree
           in terms of making un-focusable things focusable, but I
           don't know what depends on that. There's nuance. If
           you're doing through the keyboard it works, but not
           anything else.

  plinss: What does it mean to focus on something un-focusable? If
          it can't take input what's the value?
  TabAtkins: You can always do tabindex=url
  tantek: That's already in the platform.
  plinss: Seems like a bug. Should we perpetuate.
  <gregwhitworth> IE: with tabindex-1 allows both active and focus
                  to work
  <gregwhitworth> without, :active only works

  tantek: I think we'll find out through testing. I wouldn't block
          CR on this issue. Write a doc saying this is what we
          think, test, and see how it falls out. If the tests show
          implementations converge the other way we don't have a
  fantasai: I think we should clearly document the issue and narrow
            the scope. We're considering these ways, this is how
            we'll decide, here's the background data, now it's down
            to testing and implementations.
  fantasai: That's what we can to push to CR.
  Florian: Sounds fair.
  tantek: I'm happy to have an informal note that saying we think it
          should work this way and we need to test.
  tantek: Normatively we should pick one so we can test and have an
          informative note that says we think this is right and we
          think this is what's being done, but testing will reveal
          if that's true.
  tantek: I think we have an idea of what we want to do and we can
          have in the spec this is how you do this with informative.
  Florian: I do think this is the right way, but I think fantasai
           has a good point. I'm happy with the current, I'm okay
           with it, I'm not sure I prefer.
  tantek: If there's feedback before CR we'll take it and if it's
          after we'll take it.
  <Florian> clarifying my point above: I am ok with the current
            behavior, but I am not sure I prefer it over fantasai's
            suggestion, so I would definitely welcome author
            feedback (and feedback form HTML and accessibility)

  fantasai: I think you should ping HTML, accessibility and maybe
            TAG for more feedback since it's a where's the boundary
  plinss: I'd especially like to hear from accessibility.
  <bcampbell> I am unable to cut in on the phone but can volunteer
              to bring this to a greater group for accessibility.

  TabAtkins: If you're doing a game UI or something, this is very
             useful. It shouldn't limit focus to things you can type
  fantasai: The issue isn't about the nature of focusability, the
            interesting question here is can CSS be a mechanism for
            this and without it being reflected any way in the DOM.
            If it's purely CSS that effects if this can be focused.
  tantek: I think TabAtkins disagreed with the game example, such as
          getting focus and then getting event.
  fantasai: TabAtkins's example could be done with HTML.
  tantek: It might not be a bug.
  Florian: Which is why I'm inclined to say both is reasonable and
           we should have a switch for it in the future.
  tantek: I agree we shouldn't do a switch now. Tighten the language
          of the behavior and include an informative note about the
          behaviors we're considering and welcome input?

  plinss: Objections?
  fantasai: And also actively solicit input. Don't just put it in
            the spec and expect feedback.
  tantek: That's reasonable.

  RESOLVED: Tighten the language of the directional focus property
            behavior and include an informative note about the
            behaviors we're considering and welcome/actively solicit

  plinss: I accept that focusability may be something you want only
          in CSS, but I don't like these features that are side
          effects of other features. I'd like us to create specific
          property that says we're taking control of this. You can
          always have that behavior actually set. I don't like
          magical properties that are side effects.
  <fantasai> plinss++
  tantek: I think I had a property in an earlier CSS3 UI and it was
          dropped for lack of interest or objections. What we're
          dealing with is we have directional nav supported. This
          seemed the best result. In general I agree with your
          philosophy. We can try and introduce it in 4.
  Florian: The switch you suggest is what I have in mind, so I agree.
  plinss: I think this is something for 4 since 3 is heading to CR.

  Florian: I think we're okay with CSS3. There's another, but it can
           go in e-mail.
  tantek: Is that clip?
  Florian: Yes.
  tantek: It does seem editorial. So yeah, that should be it.

  <tantek> Note: resolutions for CSS3-UI issues 78 and 79 captured
           https://wiki.csswg.org/spec/css3-ui#issue-78 and
           https://wiki.csswg.org/spec/css3-ui#issue-79 as discussed
           earlier in the telcon. Thanks for everyone's input.

Allowing @import to be conditional on @supports queries

  <fantasai> https://lists.w3.org/Archives/Public/www-style/2015Jan/0292.html
  TabAtkins: We have multiple conditional rules, but the number of
             places that invoke media queries explicitly only
             involve @media, so you can't import a stylesheet that
             has new features. Right now you have to include
             everything inline,
  TabAtkins: So my proposal is extending the grammar to support the
             other conditional rules. You can do a straight media
             query or you do a supports function.
  TabAtkins: Boris pointed out that in order for this to be useful
             we'd have to be stricter in spec that says you don't
             load @imports speculatively. You only load if it
  TabAtkins: So I propose to extend the @import grammar so it can
             support any grammar.
  TabAtkins: Also tighten up the language in CSSOM as to where in
             the cascade we load conditionally imported style sheets.

  TabAtkins: Any comments? Otherwise I'd like a resolution
  <gregwhitworth> yes please!!!
  fantasai: Seems like a good idea.
  fantasai: It seems necessary and reasonable syntax. Add to Cascade
  TabAtkins: Yes, I'm fine with 4. This isn't urgent, it's useful.
  <fantasai> TabAtkins, I think either Cascade 4 or Conditional 4
             would make sense. Cascade lets you mess around with
             @import handling rules a little more directly.
  <fantasai> TabAtkins, Cascade 3 is in CR, pretty stable. Think
             it's fair to bikeshed 3, then fork off 4 to add this.
  <fantasai> (Would definitely bikeshed 3 first, so 3 is bikeshedded
             onto /TR)

  Bert: I think it's a cool idea. I was wondering you said don't
        load the stylesheets because you're risking whatever. I
        think more and more loading unconditionally because privacy
        concerns. Do you not expose anything about your browser by
        not loading?
  TabAtkins: No more than you do with scripts.
  TabAtkins: Even without script you can use the standard put the
             background image with a URL pointing to something on
             your server trick. There's no additional privacy
  plinss: It is part of the fingerprinting surface, but it's already
          exposed through other means.
  Bert: Background images aren't conditional anymore. Webkit
        recently fixed background of scrollbars because they were
        exposed. Okay. I just wanted to think about those.
  TabAtkins: If you have script, you can evaluate MQ whenever you
             want so exposing more doesn't hurt.

  fantasai: I'm thinking we should bikeshed Sascade 3 and work up
            level 4 so we can maybe add this and also introduce
  TabAtkins: We do need to add default.

  plinss: Anyone object to adding @supports?

  RESOLVED: Add @supports to Cascade Level 4

  TabAtkins: Can we get a resolution for level 4 ED?
  fantasai: If you bikeshed 3 first and then fork it.
  TabAtkins: Yeah.

  RESOLVED: Create an ED for Cascade Level 4

  fantasai: Do people want to resolve on default now?
  TabAtkins: I'd rather do that on the list.
  fantasai: Okay.
  plinss: Anything else?

Logical Border Radius Properties

  <fantasai> https://lists.w3.org/Archives/Public/www-style/2015Jan/0313.html
  <fantasai> https://lists.w3.org/Archives/Public/www-style/2015Jan/0327.html
  TabAtkins: Was that fantasai or was that from Cameron?
  plinss: Cameron brought it up.
  plinss: Anyone want to talk on it?
  Rossen: What about?

  fantasai: Naming conventions. border-block-start-order-inline-start
            -radius is really wrong.
  fantasai: There was a convention to do block first. We would just
            want to resolve on that.
  TabAtkins: Sounds good to me.
  fantasai: I posted the proposal in IRC.

  plinss: Okay. Any thoughts about adding this?
  Rossen: Sounds reasonable.
  TabAtkins: As part of the logical properties it would logicalizing
             most things. It would be let's use this pattern for
             things that are extra long.
  Rossen: fantasai and I have quite a bit of work on that spec. This
          is good input and makes sense.
  fantasai: This would be the pattern for things that reference

  plinss: Okay. Want a resolution?
  fantasai: Proposed resolution: properties referencing corners drop
            the axis mentions and go into the block axis first, for
            example border-start-end-radius
  plinss: Objections?

  RESOLVED: Properties referencing corners drop the axis mentions
            and go into the block axis first, for example:

  Rossen: Is fantasai's auto-sizing of ruby not on the agenda
  plinss: I think we did it at the F2F
  plinss: Anything else?

  fantasai: I have DoC for flexbox and a couple more issues were
            raised. Upcoming will be dealing with that, but it's
            mostly done.
  plinss: That's a future call?
  fantasai: Yeah. Probably next week.

  plinss: Alright, everyone gets 10 minutes. Thanks.

Received on Thursday, 26 February 2015 00:35:12 UTC