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

[CSSWG] Minutes Telecon 2015-08-05

From: Dael Jackson <daelcss@gmail.com>
Date: Thu, 6 Aug 2015 07:22:35 -0400
Message-ID: <CADhPm3te=DiJkxvvZy+dwpkdiGWOOYuWarciUXF+yQHXizP9Xw@mail.gmail.com>
To: www-style@w3.org

  - bkardell informed the group that :has() has received a lot of
      support on Microsoft's uservoice.

Allowing @import to be conditional on @supports queries

  - RESOLVED: In case of one single supports query the innermost
              parentheses are optional in functional notation
  - This resolution applies to both JS and supports()

Containment and Overflow

  - RESOLVED: Leave the spec as-is for contain: paint and
              overflow: clip
  - RESOLVED: Clarify contain to make sure it specifies the order of

'system' generic font name

  - RESOLVED: accept the new 'system' value and its definition with
              a note in the spec about fingerprinting issue.

HCL colors

  - RESOLVED: Add LCH to the Colors 4 spec

writing-modes and text-orientation

  - Everyone on the call was in support of the proposal to create
      sideways-lr and sideways-rl in writing-mode, but all the
      interested parties weren't on the call, so a decision will
      occur on the mailing list.

Remove requirement for whitespace around and/not

  - RESOLVED: Revert the spec on the whitespace requirement

Specifying how keyframes interact

  - Everyone received an action to review TabAtkin's proposed
      algorithm for handling how animations interact with each other
      when one has an animation timing function and others don't

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

  Tab Atkins
  David Baron
  Sanja Bonic
  Bert Bos
  Adenilson Cavalcanti
  Dave Cramer
  Alex Critchfield
  Elika Etemad
  Simon Fraser
  Daniel Glazman
  Tony Graham
  Dael Jackson
  Brian Kardell
  Brad Kemper
  Chris Lilley
  Peter Linss
  Anton Prowse
  Florian Rivoal
  Andrey Rybka
  Simon Sapin
  Alan Stearns
  Lea Verou
  Ian Vollick
  Greg Whitworth


  scribe: dael


  glazou: Let's start
  <fantasai> glazou, can we add the conf call dial-in #s to the
             meeting announcement template?
  glazou: Yes, fantasai, I can try to do that.
  <fantasai> thanks

  glazou: First thing, any extra items? I saw one from fantasai on
          the WG list and a mention from gregwhitworth that
          backgrounds item isn't to be discussed.
  glazou: Before we start, I'm away the next 3 weeks, so I won't be
          at the F2F.
  bkardell: To add, I wanted to have a quick regression about has
            and gauging interest and feedback from Microsoft
            uservoice on that.
  glazou: How much time do you need?
  bkardell: A minute or two.
  glazou: Let's do that.

  bkardell: Two weeks ago during WG telecon when we were discussing
            as to if we should punt :has() and if developers wanted
            it and if implementors will implement. We stuck it onto
            uservoice. For those of you that don't know, uservoice
            has about 500 features that developers can go spend
            points to prioritize.
  bkardell: In the two weeks it's in the top 10% of requested
            features. I think it's clear that there's a big want. I
            think we should take that feedback to our respective
            implementors and advocate that it get implemented.
  <ChrisL> the web developers HAVE SPOKEN

  glazou: Comments from others? Implementors?
  gregwhitworth: We glanced at it here. Last time we talked about it.
                 We discussed it with 5 or 6 of us and we like what
                 it offers for developers. We've discussed with
                 engineers at other UAs and they're concerned about
                 performance. I'm starting conversations about how
                 it's utilized to see if we can scope down to remove
                 the concerns a bit.
  <ChrisL> are the performance issues verified or just worries? ie
           how much are they based on testing?
  gregwhitworth: I think it's worth keeping in the spec to say there
                 are issues raised and lets deal with them. The
                 developers are already doing it with JS.
  gregwhitworth: So that's where we stand.
  <bkardell> note it is currently in the spec only in the static

  glazou: Other opinions? Is that good for you bkardell?
  bkardell: Yep. Other than to say that in the spec it's only static
            profile so there shouldn't be performance concerns there.
  <fantasai> bkardell, the concern I have with :has() is various
             proposals to change its syntax in order to make it
             restricted enough for the dynamic profile

Allowing @import to be conditional on @supports queries

  <glazou> https://lists.w3.org/Archives/Public/www-style/2015Mar/0402.html
  Florian: I think we spoke about that a few times and there was
           something tricky about the preloader.
  fantasai: What does the preloader have to do with syntax?
  Florian: There was a bigger discussion about @supports and general
           MQ and the interaction with @viewport. If you start to do
           things like this you end up with the whole thing. While
           it sounds okay at the syntax level, you get surprising
  Florian: The advantage of @import only being at the top, the
           preloader can support that without complex syntax. So it
           can load, but not preload. Personally I don't care all
           that much, but last time we talked there were big
  fantasai: This mail is about double parentheses in the @import.
  Florian: Okay, ignore that. I'm off topic.
  * Florian apologizes for confusing this topic with another one,
            and jumping straight in without listening first, which
            would have avoided wasting everybody's time.

  glazou: So fantasai you wanted to discuss because it's the last
          one on the radar?
  <fantasai> @import "url" support(<supports-condition>)
  fantasai: Right now we have @import and a URL and @supports where
            you can put a condition. It was pointed out where if you
            just have one condition...if you have two conditions it
            makes sense
  <fantasai> @import "url" support((display: flex) and
             (align-items: start))
  fantasai: That's fine.
  <fantasai> @import "url" support((display: flex))
  fantasai: For very simple cases you end up with the double
            parentheses. Can we change the grammar to allow one set
            of parentheses?
  <fantasai> @import "url" support(display: flex)
  <SimonSapin> sounds ok
  glazou: For usability and readability I'd support that.

  glazou: I'd like to hear from others. SimonSapin said okay.
  SimonSapin: Would this only be @import?
  fantasai: Yeah, because @supports doesn't have parentheses in
  SimonSapin: Right. I think that's fine.
  fantasai: We might also consider allowing it for the JS .supports
  <fantasai> .supports("(display: flex)")
  fantasai: It's not quite the same, but it's similar problem.

  smfr: What would it look like with a not?
  fantasai: You would need parentheses. Only in the case with just
            the one thing.

  glazou: Any objections?
  Florian: I think a long time ago we resolved in the other
           direction for JS. I don't strongly care either way, but
           given that we did resolve the other direction, is there
           something we're not considering this time?
  fantasai: I think it's weirder when it's just in CSS
  glazou: It's often the case that we review something because we
          originally decided on purity of the language and then we
          find it's ugly and make the change.
  Florian: Sure.
  glazou: So no objections?

  RESOLVED: Allow to one stack of parentheses in the case of one
            single supports query

  fantasai: Do we want to extend that to JS and is dbaron on the
  SimonSapin: I think rather than default to, I think we want to
              allow both.
  glazou: Let's imagine you have an @import with two, you remove
          one, and then you end up with two stacks, we want to allow
  TabAtkins: Yeah, you can put an infinite amount of parentheses in
             a supports.

  RESOLVED: In case of one single supports query the innermost
            parentheses are optional in functional notation
            (to take place of last resolution)
  <fantasai> Resolution applies to both JS and supports(), to clarify
  <SimonSapin> In terms of grammar: `something_something :
               supports_condition | declaration`
  * fantasai thanks SimonSapin:)

Containment and Overflow

  Florian: We discussed last week, but there is follow-up.
  <Florian> https://lists.w3.org/Archives/Public/www-style/2015Jul/0461.html
  Florian: Quick summary, we had discussions as to if overflow: clip
           should stay with different semantics and we agreed we'd
           keep the old functionality. We're open to bikeshedding
           the name.
  Florian: The follow-up is, we're all clear where if you do
           contain: paint and overflow: clip you get the ideal
           situation. But if you don't specify overflow: clip and
           you do visible, should contain: paint force it to compute
           to clip? Or are we in one of those cases where the author
           didn't consider he might overflow and we don't want to
           make content disappear, shouldn't force it to auto
  TabAtkins: I believe we should stick with contain: paint auto
             clips. That's so authors don't have to do a bunch of
             properties to get containment.
  Florian: I initially agreed, my only doubt was the extra thing you
           need to flip causes content to disappear. If you didn't
           consider that, you drop content.
  TabAtkins: The contain property in general, all values can do
             bad things if you use them unwisely. We don't have to
             safeguard this one in particular.
  Florian: I can live with that. It was worth raising since we're
           careful about disappearing content.

  smfr: In general when one property influences a second property
        we've avoided influencing the computed value of the second
  TabAtkins: Yeah, if it computes is a separate thing.
  Florian: Yes, it's should it automatically overflow: clip or do
           you have to ask explicitly.
  smfr: I'm with TabAtkins. If you say contain: paint it does
        everything it's supposed to do.
  Florian: If we resolve this way, there is a follow-up.
  Florian: So proposal, leave the spec as-is.
  glazou: Objections?
  TabAtkins: smfr and I expressed we're for the resolution.

  RESOLVED: Leave the spec as-is for contain: paint and
            overflow: clip

  Florian: The follow-up, if you're not using overflow, but
           overflow-x and overflow-y and then you contain: paint. If
           you're visible in one direction and not the other the
           visible goes to auto. The contain: paint says it goes to
           clip. When I wrote this with TabAtkins the intent was the
           overflow property would apply first. So you have auto and
           then the contain doesn't apply.
  Florian: This was raised as ambiguous on the mailing list.
  TabAtkins: I'm fine with clarifying the spec.
  <bkardell> +1 to clarify the spec
  <bkardell> I think the way Florian described it makes as much
             sense as anything

  Florian: I'm not sure if it's contain or overflow that needs to
           clarify, but what do we clarify to?
  Florian: The speed argument might apply here against overflow
           applying first.
  TabAtkins: I'm okay with it. So it changes to auto and you get
             the contain effect.
  glazou: bkardell loves it too. Other opinions?

  smfr: Contain applies last?
  TabAtkins: Yes. If you were otherwise going to be
             overflow: visible you're going to change, but the
             others would clip auto.
  smfr: What if you set scrollbars?
  TabAtkins: You'd still have them, yes.
  Florian: You do the computed value rules of overflow first. Then
           if contain: paint you compute visible to clip if you
           need to, but otherwise you leave it as is.
  dbaron: That seems reasonable assuming that we want contain: paint
          to be scrollable.
  <dbaron> ...which I'm not completely convinced about
  Florian: By default they're not. But if you explicitly ask for
           scrollbars you get them.
  TabAtkins: I see no reason why it would have to have anything to
             do with scrolling. The elements can do whatever they
             want. If you don't want scrollable, contain: paint will
             do that for you.
  glazou: Do we go for the suggested clarification?
  TabAtkins: I can clarify contain to make sure it specifies the
             order of operations.

  RESOLVED: Clarify contain to make sure it specifies the order of

'system' generic font name

  <glazou> https://lists.w3.org/Archives/Public/www-style/2015Jul/0169.html
  glazou: It's been on the agenda for three weeks and has had a lot
          of traction on the mailing list, so we should do this one.
  myles: There's...at Apple we've gotten a fair number of requests
         for people to style contents so it fits with the UI. The
         proposal is to create a font family generic font name so
         that it matches the UI of the OS. It seems Android, iOS and
         Windows 10 have a relevant font family that this would use.
         What are your thoughts?
  fantasai: Makes sense to me.

  ChrisL: Do OS only have a single one? Do any have serif and
          sans-serif or something like that?
  <Bert> KDE has 8 UI fonts
  myles: Of the OS I looked at, they have one font family for the UI
         elements. So this is about font families.

  Florian: In theory they could be all over the place, but in
           practice there aren't. Generally there is one font
           family, but there could be more so we should spec
           properly for that.

  Bert: The system I'm using, KDE, has by default its UI fonts, but
        I noticed that knowing the family and size isn't enough if
        you want to mimic the normal look. You need the color and if
        they use shadows. It's rather more complex.
  myles: I think it's viable to not make this very complicated to
         support KDE.
  Bert: I have no conclusion, I was looking at the question and
        since you asked about the families, at the moment my system
        is using the same family but with different weights and
        sizes. If you want to look the same, knowing the family
        isn't enough.
  ChrisL: I don't think the claim was that this one value would be
          enough to mimic the UI, just the font.

  TabAtkins: Yes, it was to just have you mimic the UI. The font
             used can be jarring if you're trying to look native.
  TabAtkins: We should specify at least suggestions on how to choose
             a system font for things that have multiple fonts. So
             those of us that have browsers that run on Linux need
             to know what to use.
  <ChrisL> +1 to what tab said, for spec clarity
  myles: That's fine, I can write something up.
  <leaverou> Is there a use case of mimicking the default typography
             of an OS, without mimicking any other part of its UI? (
             since we have no access to anything else)
  <bradk> 'Color:system; text-shadow: system'?
  <fantasai> bradk, wouldn't work, since different elements have
             different values for it
  <leaverou> TabAtkins: Looking native takes much more than just
             mimicking the font or text-shadow though
  <gregwhitworth> I'm less inclined for the system function, but
                  like the system name itself

  glazou: Can you answer dbaron proposal from the e-mails in a
  myles: The proposal was to have system be a function so you can
         put system menu and get the menu font.
  glazou: And your answer?
  myles: The answer is that this is what I described before where,
         for the OSes I looked at, there's only one so it seemed
         needlessly complicated.

  Bert: One other issue that Nick Doty brought up. If you allow an
        app to ask what the system UI font is, you have an extra
        surface for fingerprinting. If there's a way to make the
        server not know what's being displayed.
  fantasai: We have this problem already. CSS 2.1 has system font
            keywords already. This gives you less information.
  TabAtkins: It's also almost completely subjugated...this allows
             for no additional entropy except for people that
             customize their fonts.
  Bert: But this does effect those people.
  TabAtkins: Yes, but that entropy is already out there.

  <dbaron> It's a little annoying to have two different system font
           mechanisms that work in entirely different ways...

  glazou: So in case we resolve on this, maybe a note summarizing
          Nick Doty's message would be good.
  Florian: The message is bringing up the fingerprinting, what does
           the note say?
  glazou: At least web authors are warned.
  <dbaron> It's not authors who should be warned; it's users.
  myles: There's no note for the font keywords.
  TabAtkins: Yes. If we're going to start marking fingerprinting
             vectors we can be more consistent about that and mark
             them elsewhere.
  glazou: The W3C started to do more about privacy. I think it's
          good to have a warning.
  myles: I'm fine with that.
  Florian: I'm just trying to see who should be warned.
  TabAtkins: The most useful target is people producing privacy
             enhancing tools.
  Florian: That's a good point.
  glazou: So we accept the new value and its definition with a note
          in the spec. Objections?
  <Bert> +1 to a note, even if we don't know how to solve it yet :-)

  RESOLVED: Accept the new 'system' value and its definition with a
            note in the spec about fingerprinting issue.

  fantasai: Who is going to edit this in? We need someone to do the
            editing work for this.
  TabAtkins: I have a reasonably complete fonts 3 that we can port
             over to fonts 4.
  myles: So is that volunteer?
  TabAtkins: Well...if no one else is going to do it, I'll put it on
             the list of specs I'm contributing to.
  myles: Certainly for this value I was intending on contributing
  TabAtkins: Should I take an action finishing polishing the
             bikeshed version and create an ED for fonts 4?
  fantasai: Can we deal with fonts 3 not being bikeshedded?
  ChrisL: Yeah.
  fantasai: I think that's a good idea. Can we get a resolution?
  <ChrisL> +1
  Florian: Bikeshed 3, diff spec 4, TabAtkins as an editor?

  glazou: Objections?
  dbaron: I think it's worth running by jdaggett
  ChrisL: Would he object?
  TabAtkins: He's weakly objected to other things but I can try
  fantasai: There's things he wanted fixed in bikeshed before
            porting it over so you two should probably coordinate on
  glazou: Okay, let's do that.

HCL colors

  <glazou> https://lists.w3.org/Archives/Public/www-style/2015Jul/0098.html
  ChrisL: The thing that may have confused people, it's normally
          called LCH and discussed with LAB because they're two
          identical forms. This is asking if we should add these to
          the spec.
  ChrisL: I think we should, I think I have an action to do it.
          TabAtkins and I need to discuss it.
  ChrisL: This used to be SVG and was moved it to Colors 4. I think
          I'm ready to add spec text. I think we should close with
          we should add it.
  TabAtkins: I'm fine with that.

  RESOLVED: Add LCH to the Colors 4 spec

  Action ChrisL write some language for LCH
  <trackbot> Created ACTION-702

writing-modes and text-orientation

  <glazou> https://lists.w3.org/Archives/Public/www-style/2015Jul/0060.html
  fantasai: I can summarize, but not resolve today since Koji isn't
            on the call.
  fantasai: We have a writing-mode property that says if you're LTR
            or RTL or Top to Bottom and we also have text
            orientation that says how that line of text is rotated
            in that original box. Do you rotate clockwise or anti-
            clockwise. To do something like a book spine you would
            use these things in combination.
  fantasai: The problem with the design is you can end up with the
            left side on the top or bottom or both in the same BFC.
  fantasai: You can also rotate 180 in the same line which is also
  fantasai: There was a request to simplify what can be done. There
            was discussion on how to do this and this proposal is to
            change...instead of having the text-orientation give all
            the possible orientations, we move some to writing-mode.
  <dbaron> I don't think it's actually that hard from an
           implementation perspective, although it does require some
           work; I think the main difficulty is specifying it
  fantasai: It would add sideways-lr and sideways-rl which would
            rotate the entire block. Anything that's not CJK would
            use that to turn the text sideways and that would ignore
            the text-orientation. If you're trying to do upright you
            would use vertical-lr and possibly text-orientation to
            tweak that.
  fantasai: We lose two use cases if we switch to this model. It's
            top to bottom Arabic in a CJK document which is rare. Or
            Ogram in a CJK document which is also weird and rare.

  Florian: Two comments. I spent a bit of time off list with Koji
           discussing this. We independently landed on this solution
           as well so we're both in favor.
  Florian: One downside of what we had previously is that it was
           biased to CJK. horizontal-language authors could not use
           the writing mode property for side captions without also
           using the text-orientation property. The new proposal
           fixes that. The simple use cases are just in the
           writing-mode property. Both for CJK and English users.
  Florian: The other point, for the use case we're using, if you
           have RTL inside Japanese, and want both to go
           top-top-bottom rather than end up in a bidi situation,
           we can no longer do this inline.
           I did some research to see if that case existed. I
           reached out to academics and librarians and no one could
           point out a use case. It's extremely rare if it exists.
           We're not losing anything.

  glazou: Okay. We don't have Koji so I suggest we resolve on the
          mailing list.
  Florian: Koji is fine. I'm not sure about jdaggett.
  glazou: We don't have everyone around the table. Let's gather the
          opinions before we decide.

  glazou: We have 8 minutes. We have Ruby issues, keyframes
          interaction, whitespace around and/not and max-content

Remove requirement for whitespace around and/not

  <glazou> https://lists.w3.org/Archives/Public/www-style/2015Jul/0332.html
  TabAtkins: Several F2Fs ago we talked about whitespace in regards
             to syntax. We decided that there should be whitespace
             on both sides of 'and', 'or', and 'not'. Turns out this
             breaks things. There's at least one Microsoft minifier
             that removes the space before the and. So requiring
             that space breaks all the code using that minifier. So
             I suggest we drop that requirement and recommend the
             whitespace, but not require it as long as you do
             something to have it parse into keywords.

  Bert: I'm in favor. For MQ it's quite simple since it's WD. The
        problem with be with @supports. We have a CR that requires
        spaces. We'll have to pull that back to WD. I'm in favor of
        doing it, but it is some work to do.
  TabAtkins: Yeah, that's process. We can republish as necessary.
  glazou: Who is in favor, who objects?
  ChrisL: Sounds good to me.
  Florian: As long as @supports is in sync

  RESOLVED: Revert the spec on the whitespace requirement

Specifying how keyframes interact

  <glazou> https://lists.w3.org/Archives/Public/www-style/2015Jul/0391.html
  TabAtkins: This is about how animations interact with each other
             when one has an animation timing function and others
             don't; that's not well defined. I wrote an e-mail
             algorizing the thing. This needs review and someone
             saying it matches up. Internally it's correct as far as
             we know. As long as people are okay with it, that's
             great. Review on the mailing list.

  smfr: I think the general algorithm is correct, but I don't like
        the word transition since that's a thing.
  TabAtkins: If you can come up with a better word, that's fine, lay
             it on me.
  TabAtkins: If anyone has a better name, please tell me and we'll
             change it.
  TabAtkins: Otherwise, there's nothing specific for that. Review
             and give a stamp of approval.

  ACTION everyone review the proposal so we can approve

  glazou: There's only a minute left. Thank you everyone, have a
          good F2F, I'll talk to you in September.
Received on Thursday, 6 August 2015 11:23:33 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 6 August 2015 11:23:33 UTC