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

[CSSWG] Minutes Telecon 2015-04-08

From: Dael Jackson <daelcss@gmail.com>
Date: Thu, 9 Apr 2015 05:14:17 -0400
Message-ID: <CADhPm3urfwvGe0-h0pbE6GtB5isYGsMNnrC36zh-j8xUrL=hmQ@mail.gmail.com>
To: www-style@w3.org
Loading Fonts and Changes in Status

  - There was disagreement as to if the specific order of state
      changes is needed to prevent bugs or if it's an unnecessary
      step that slows performance.
  - TabAtkins will gather more cases and the e-mails that lead him
      to make the language more strict in order to further the

Media Queries

  - RESOLVED: Change the appropriate sentence in MQ to "User agents
              must re-evaluate <a>media queries</a> in response to
              changes in the user environment that they're aware

Font Loading Control

  - RESOLVED: Remove the timeout portions from the proposed font
              loading control spec.
  - RESOLVED: Move Font Loading Control to the Font Loading spec.

Cursor Image Formats

  - RESOLVED: We are recommending informatively .cur support.
              Normatively must support PNG and SVG and saying should
              support animated formats too.

text-combine-upright (TCY) on ::marker

  - RESOLVED: Accept fantasai's proposal to add text-combine-upright
              to ::marker.


  Rossen Atanassov
  Tab Atkins
  David Baron
  Sanja Bonic
  Bert Bos
  Adenilson Cavalcanti
  Tantek Çelik
  Dave Cramer
  Alex Critchfield
  John Daggett
  Elika Etemad
  Daniel Glazman
  Tony Graham
  Koji Ishii
  Dael Jackson
  Toru Kawakubo
  Brad Kemper
  Chris Lilley
  Peter Linss
  Edward O'Connor
  Florian Rivoal
  Simon Sapin
  Alan Stearns
  Greg Whitworth
  Johannes Wilm
  Steve Zilles

  Simon Fraser
  Michael Miller
  Simon Pieters
  Anton Prowse
  Mike Sherov
  Lea Verou

  Scribe: dael

  glazou: Let's start.
  glazou: Any extra items?
  jdaggett: The font rendering proposal is something I'd like to
  glazou: We'll put that after item #1 since you're far away and
          time zones.
  jdaggett: We can hold off until TabAtkins is on the call.
  glazou: No problem. Anything else?

Loading Fonts and Changes in Status

  <glazou> https://lists.w3.org/Archives/Public/www-style/2015Mar/0536.html
  jdaggett: We should wait for TabAtkins.
  TabAtkins: Let's do this.
  jdaggett: The first item is, basically, the way the CSS Font
            Loading spec is written it sort of requires certain
            state changes to occur in a certain order.
  TabAtkins: Yes.
  jdaggett: It seems that's unnecessary.
  TabAtkins: We want to ensure state changes happen in a specific
             order. Otherwise people get bugs.
  jdaggett: The ordering is fine. If there's a guarantee at a
            certain point we should be careful. In this case a font
            could end up being loaded trivially.
  TabAtkins: Yeah. Let me link the e-mail. In these examples in the
             e-mail I think they're Chrome bugs. We shouldn't have
             behavior depending on implementation concerns. People
             depend on sync behavior in one browser and it doesn't
             work in another.
  <tantek> TabAtkins++ depending on implementation details of
           async/sync is a huge recipe for bugs
  jdaggett: You're forcing slow.
  TabAtkins: Forcing consistent.
  jdaggett: Consistent but slower.

  TabAtkins: Yes. I am requiring that because it's required for
             several cases. It's not obvious to me which should be
             sync. I don't think we should have an API that
             sometimes makes sync changes and sometimes makes async.
  jdaggett: I think when we implemented this in Gecko you have to
            introduce artificial states where you can load this and
            it's in a cache, whatever the reason is you end up
            having to put it into an extra state and spin the event
            loop and then set up something where it comes out at the
            next spin so you're doing the right thing.
  jdaggett: It seems like a lot of additional that's not that
  TabAtkins: I think having an API that can do sync or async
             depending, I think that's bad for browsers. They have
             to do odd things for some cases anyway. It requires you
             to say even though we're capable of doing it fast,
             we're going to wait for the next event loop.
  jdaggett: Maybe we need to hear back from the Chrome implementors
            because for us it creates artificial states.

  TabAtkins: That's, yes, if you do a URL and sometimes it's sync
             and sometimes async because sometimes it got loaded
             somewhere else, that will be a source of bugs for
             authors. This kind of unpredictably is always a problem.
  TabAtkins: It might happen because they've loaded in their test
             environment, but once you're public it won't be loaded
  jdaggett: I think it's an artificial simplification of something
            that's already complex. I don't think you're introducing
            bugs when you say if it's simple if can change.
            Introducing artificial boundaries...this thing happens,
            then this etc. in all cases, you end up with sync cycles
            that aren't great for authors.
  TabAtkins: But doing anything else creates unpredictability. I'm
             going to object that to something that allows sync or

  jdaggett: Talking this over with Cameron, this doesn't make sense,
            but we need to talk to others. There's two
            implementations that feel like the right way, but the
            spec says something else.
  TabAtkins: I think that might be because I set status to loading
             and that's really bad. It might be we're taking
             advantage of that at the time of implementation, but
             we're being stricter because of feedback that I should
             be strict in async.
  jdaggett: It would help if you can post the downsides of changing
            this? I think examples of bad would be helpful.
  TabAtkins: And I can link back to the e-mails that caused me to
             change the text.
  dbaron: Also, when there's a callback there's a risk of authors
          expecting async and having that be a problem when it syncs.
  TabAtkins: Anything that keys off will be promise based. I'm
             worrying that authors will expect it to change sync-ly
             and it not changing sync-ly in other cases.

  glazou: So TabAtkins you'll accept an action to provide more
  jdaggett: And it might be useful to hear from other members of the
            Chrome team.

  ACTION TabAtkins to provide more info to jdaggett
  <trackbot> Created ACTION-679

Media Queries

  glazou: So back to Microsoft. I think, gregwhitworth, you posted?
  gregwhitworth: I expressed our desire for it to be 'should' for
                 the pointer. I read Florian's feedback and I still
                 think it should be a 'should'. Especially for the
                 future because we don't know about MQ down the road.
  gregwhitworth: I've laid it out in the e-mails so I don't know if
                 you want to talk about this on the call.
  Florian: I'm not sure if it's on the call, but I don't understand
           your point. When it comes to future-proofing I think
           that's erroneous. If we find something that should be
           'should', we can change that. I don't think we should
           take future needs as a reason to not have it strict.

  Florian: As to pointers, If you disagree with my example I'd like
           to understand what I'm missing.
  gregwhitworth: Your scenario where we have a continuum model. The
                 surface where 90% of the time they're using in a
                 touch format. Then they take it to work and dock it
                 they have a mouse. So what you're saying the
                 primary is touch, but now it's mouse. So that's why
                 I think it should be a 'should'.
  TabAtkins: That seems irrelevant.
  Florian: So you're saying you don't think the primary pointer has
           changed. So you don't change it. But if it has changed,
           let the author know.
  TabAtkins: I don't see why if you think the pointer has changed
             you shouldn't change it.
  gregwhitworth: So I don't see why the OS...
  TabAtkins: Then you don't know it's changed. This is saying if you
             know the value has changed, let the browser know and
             that you must do that.
  Florian: So whatever happens in the environment causes it to
           change, then the browser should match. And I think it's
           straight forward for Windows because you have that in the
  gregwhitworth: For example we have plug and play on the OS so we
                 know when something changes. But with a device that
                 doesn't have plug and play that's not possible.
  gregwhitworth: If we have a device that doesn't have the
                 capability, I'm questioning if we're talking about
                 a must or the end author. They're going to think I
                 said pointer is fine and they must reevaluate,
                 they're not going to take that browsers will change.
  Florian: But if you have a device that's not plug and play it
           wouldn't be primary.

  TabAtkins: Would it help if we add "that they're aware of"
  <ChrisL> +1
  gregwhitworth: That feels like a 'should'.
  Florian: What we want to avoid is UA knowing and not changing.
  dbaron: If you want exceptions for certain MQ characteristics, we
          should make those exceptions for just those. Don't weaken
          the spec for things like width.
  <fantasai> dbaron++
  <Florian> +1 to dbaron
  gregwhitworth: That's what I said in my e-mail. If we take MQ at a
                 granular level and things where there's
                 interoperability make it a 'must'. But I think for
                 pointer...TabAtkins, I think it's a good idea to
                 add that. But I'd rather get more granular. So
                 these 5 are 'must' and this one is 'should'.
  <ChrisL> let's go for the more granular and the "that they are
           aware of"

  Florian: So when a browser knows about the luminosity MQ, but the
           device doesn't actually have a light sensor... no author
           will expect it to change if the UA can not know about the
           change in the environment. I think we can add the
           phrasing, but I don't think it's significant. The other
           changes go under deciding what is the primary device.
  Florian: I'm okay with granular, but I'd want 'must' on everything
           we have.
  gregwhitworth: What's the point of granular then?
  Florian: Well, exactly.

  gregwhitworth: So we're at an impasse. I understand your point,
                 but if I'm Photoshop and I have a UI for touch and
                 one for website and have it where if you have a
                 pointer fine, they plug in the mouse and expect the
                 UA to adjust they should expect that. Then I see
                 that pop up and expect the mouse, but the UA thinks
                 the most used is touch.
  TabAtkins: You're still talking about the definition of the
             pointer MQ, not if you know it's changed. Let's not
             talk about if it should change. I haven't heard
             arguments for if the browser knows the MQ has changed
             it should change. I haven't heard any reason not to
             change to a 'must'.
  TabAtkins: I'm okay with the one change to make it clearer that it
             only expects to change things when it knows about it.
             I'm fine with that.
  gregwhitworth: Ultimately I'm fine with it being a must as long as
                 it's stated for authors to be aware of. I did get
                 hung up on the definition of a pointer, but that's
                 the one we worried about.
  TabAtkins: Okay, I'm making the change now.
  <TabAtkins> proposed resolution: Change the appropriate sentence
              in MQ to "User agents must re-evaluate <a>media queries
              </a> in response to changes in the user environment
              that they're aware of,"
  * fantasai suggests putting "that they're aware of" in parens
  * Florian fantasai: not sure it matters, why would you want

  glazou: gregwhitworth are you okay with that?
  gregwhitworth: Yes.
  glazou: Objections?

  RESOLVED: Change the appropriate sentence in MQ to "User agents
            must re-evaluate <a>media queries</a> in response to
            changes in the user environment that they're aware of,"

Font Loading Control

  <jdaggett> http://tabatkins.github.io/specs/css-font-rendering/
  jdaggett: Back in March TabAtkins put together a better version of
            the old proposals for what's being called the font
            rendering property but it's more like a font load
            control property. It's giving the author control over
            the intermediate presentation when downloadable fonts
            are used. Different browsers have different behaviors
            around what's displayed when the pages loads and the
            font is available.
  jdaggett: Some display nothing, some do a fallback, for Chrome and
            FF they do a bit of both. Nothing at first, fallback if
            it takes too long. IE always does fallback, Safari will
            always show a blank page until the font loads.
  jdaggett: The proposal is for a property that lets you set the
            timeout. I don't think this is a great idea. I'm not
            sure what the right way to put a handle on this, but I
            think the idea of a low-level timeout is a bad thing to
            give to an author.
  jdaggett: It's going to be variable, what you give them. The way
            fonts are downloaded is via the content of the page and
            when exactly that mode starts will vary from
            implementation to implementation and how long it takes
            will depend on what else is loading at the same time. So
            a 2 sec timeout you set may have no relation to the same
            timeout on another browser.
  jdaggett: I also don't feel like authors should be able to say I
            never want to show content until this font loads. I
            think that's poor design. A lot of people complain about
            where you're looking at a page and the content has
            loaded, but you won't see anything.

  glazou: I received a lot of complaints asking if it's a CSS
  jdaggett: I can see that it's reasonable to say let's have a hint
            like this font is important and load it first, but
            explicit timeouts isn't interoperable.

  Florian: I'm not entirely sure the current design is right, but
           having the property is a good idea. Both users and
           authors have preferences, but there are disagreements as
           to if you should have fallback or just wait, so this is
           something where people like the control.
  Florian: If this should be expressed in terms of timeout, I have
           less of an opinion, but having a way for authors and
           users to switch between behaviors is something I'm in
           favor of.
  jdaggett: User and author wants can be conflicting.
  jdaggett: It's primarily a mobile problem, so there's no user
  dbaron: I don't htink it's a problem of lousy UAs, I think we want
          to find a solution for all users, not the small number of
          users that can edit their stylesheet.
  <dbaron> ... or go in to the preferences ui
  <glazou> dbaron++

  TabAtkins: The big issue is most browsers do the block for a
             couple seconds and then show the fallback. The fact
             that it's uncontrollable is what I'm trying to address.
             The point is to let authors control if you swap in at
             some point. So discussion on allowing people to block
             seems backwards because today everyone blocks. So
             unless we're saying UAs can't ever block, saying we
             don't want to let authors control blocking isn't
  jdaggett: But people are fiddling around to finagle around that.
  TabAtkins: I don't want hacks around to be a fix for a thing. This
             property might not be ideal, but I'm trying to make the
             crazy hacks not be necessary.
  <Florian> Totally agree with Tab
  glazou: Most people that complained about Safari don't know what
          local storage is. This kind of work around, they just
          don't know.
  jdaggett: I'm fine with wording saying don't do what Safari is
            doing, but I do think the way the property is structured
            with explicit timeouts, you allow authors to say never
            display until it's pure. That's a problem for someone
            that makes a UA. I want to be able to give the users
            something they want so I don't think respecting a
            forever timeout is good.
  glazou: You're trying to move the responsibility for showing
          things to the UA. This will be self-controlled; users will
          go away if it's mis-used.
  TabAtkins: I do think it's bad if people are doing heavy blocking
             and I'd be okay with allowing UA to have a max timeout.
             That could be user controlled or set as a default.

  jdaggett: This may seem orthogonal but I think it's important to
            put in hints to initiate to load ASAP because that's the
            underlying reason.
  TabAtkins: It is orthogonal. If you're using the font right away
             you still have to deal with the download times. That
             still needs to be controlled.
  jdaggett: The reason you get that is the font load is initiated
            late. If you have something initiate the font load
            you're less likely to get the behavior.
  TabAtkins: I can get the font information in the first network
             packet and still have to wait the few seconds due to UA
             behavior. This is to let that be fixed and have better

  Florian: There's 3 useful values. Auto is the browser does
           whatever it wants to do. Another is show it immediately
           even if you don't have the font and refresh when you get
           it. The third is show the content immediately and don't
           refresh when you get the font, but still initiate the
           download, so you can use it next time you reload. If
           it's useful to be able to set explicit times I'm not
           convinced of, but being able to say show immediately
           is important.
  <fantasai> Florian++
  jdaggett: I'd have less problem with that.
  TabAtkins: Those are the three planned values. If we want to allow
             the explicit timeouts on the keywords, we can do that
  jdaggett: The keywords are different. The property is much finer
  TabAtkins: No.
  TabAtkins: They are they same three keywords.

  <tantek> do we have any examples of *good* behavior with non-
           blocking webfont loading?

  Florian: I think those three are sufficient. What jdaggett objects
           to is the timeout.
  glazou: This is only a draft. We can keep stuff people disagree
          with and it will be eventually removed if we don't get the
          2 implementations.
  dbaron: I don't think that's a reason to put things in we don't
  glazou: So we have two options. Keep stuff and remove later or if
          we have a compromise, get rid of it.
  fantasai: I think if we don't agree on something and we don't have
            a clear path of working on it towards consensus it
            should be dropped and keep what we have consensus on.
  Florian: I think the property is important and I would suggest
           removing the parts jdaggett objects to and putting them
           back later.
  TabAtkins: I'm okay with moving them from the main spec and
             discussing it later.
  glazou: So the parts of having a duration?
  jdaggett: It's the timeout aspect of it.
  glazou: So are there objections to removing the timeout portions
          from the font loading?
  <ChrisL> yes
  <fantasai> fantasai: I agree with John, I'm in favor of dropping
             timeout and keeping the rest

  RESOLVED: Remove the timeout portions from the proposed font
            loading control spec.

  TabAtkins: So can I put it as an ED?
  <astearns> +1 to publish as a font loading spec
  jdaggett: We can, but we need to have an issue that it needs
            another name.
  <ChrisL> yeah the name is poor
  glazou: Okay, so we need to change the name and we need a short
  fantasai: Font Loading
  TabAtkins: We have it. The Font Loading API
  <ChrisL> font-loading-declarative
  glazou: font loading control
  <astearns> font loading level 2?
  <BradK> Font-not-loading
  jdaggett: font loading control isn't bad.
  <ChrisL> font-ld
  glazou: Okay. Font Loading Control. Done.

  <fantasai> Can we just add it to the font loading module???
  * fantasai thinks font-loading property should either be in
             css-font-loading or css-fonts
  * fantasai thought we had an outstanding action to create Fonts
             Level 4??
  * fantasai jdaggett ^
  <jdaggett> fantasai: yes, back in the oct f2f i asked permission
             to start one
  <fantasai> jdaggett, Could we put font-loading in that?
  <fantasai> I feel like having a pile of one-property specs isn't
             really helpful to people trying to find things and
             understand how they fit together
  <jdaggett> fantasai: i think font loading spec would be better
  <fantasai> :)
  <fantasai> jdaggett: http://www.w3.org/TR/css-font-loading/ ?
  <jdaggett> yes
  <fantasai> That works for me, too
  <jdaggett> fantasai: font loading is more about the font loading
             algorithm, since script is involved
  * fantasai nods
  <jdaggett> so having a property in there isn't bad
  <fantasai> I'm okay with either

Cursor Image Formats

  Florian: So there were two different issues on this.
  Rossen: The first issue, like gregwhitworth pointed out, we're
          still waiting. On the technical side as to if we can
          support other image formats, we should be able to. If
          we'll do it is a different question. Technically there are
          no limitations.
  Rossen: Obviously if other browsers support the different cursor
          formats, there's nothing holding us back.
  Rossen: It has to be differentiated in impl follow-up. But we
          should be able to support it.
  ChrisL: If it helps I made some tests. It was one test for each
          format that was proposed. That's sitting there.
  Rossen: Sorry, you were breaking up, were you asking if we should
          review all the different formats?
  ChrisL: No, I'm saying I've got some tests that lets us see what
          browsers support it. I've also got tests for PNG.
  Rossen: So the low-level cursor API supports a bitmap and an alpha
          channel map. Anything can become a bitmap and then used as
          a cursor. Besides performance I don't think there will be
          technical reasons. This is about the can we, we can, there
          are no implementations promises.

  <tantek> I'd like to move forward with: Informative note that
           browsers support .cur, and Normative must requirement of
           PNG / SVG
  <ChrisL> plus one to what tantek just typed
  Florian: tantek I agree with your point. [reads from IRC]
  glazou: That was the original proposal.
  Florian: It went a bit further. It was you must support anything
           you do through the image value type.
  glazou: Anyway, the proposal is an informative note about support
          for .cur and normative for PNG/SVG
  tantek: More than that.
  Florian: There was a should where if you support something
           animated you should support it in the cursor as well.
  <ChrisL> yes, should is appropriate for animated at this time

  glazou: So opinions and objections please?
  tantek: This is one of the two outstanding issues on CSS3 UI so
          I'd really like it resolved.
  <ChrisL> (no objections)
  glazou: There seems to be consensus.
  Rossen: I wouldn't object to this. I'm not sure about the animated
  Florian: That's why it is 'should'. And IE supports animated. It
           does it though .ani
  Rossen: Yes. The usefulness if questionable.
  fantasai: Recommend or require?
  Florian: Recommend.
  fantasai: I'm okay with that,

  tantek: So Microsoft, any objections?
  Rossen: No.

  RESOLVED: We are recommending informatively .cur support.
            Normatively must support PNG and SVG and saying should
            support animated formats too.
  Florian: And the <image> will normatively require SVG and PNG
  glazou: Okay.

  <tantek> RESOLVED: Informative note about browsers .cur support.
           Normatively MUST support PNG, SVG, and any other static
           <image> formats your UA supports elsewhere. SHOULD
           support any other animated <image> formats your UA
           supports elsewhere.
  <tantek> ^^^ all, please double-check that resolution.
  <tantek> the details are important
  <ChrisL> tantek yes that is what we agreed
  <tantek> Thanks ChrisL, I wanted to get the exact thing in the
  <Florian> tantek: Almost. change second sentence to: Normatively
            require any supported static <image> formats, and
            normatively required that <image> supports at least PNG
            and static secure SVG.
  <tantek> what is static secure SVG?
  <Florian> (this makes no difference to cursor, but it makes PNG
            and SVG mandatory for <images> in general as well)
  <Florian> tantek: https://svgwg.org/specs/integration/#secure-static-mode
  <tantek> svgwg.org?!?
  <tantek> ok I'll find a normative w3.org ref

Font Loading Control

  fantasai: jdaggett and I were discussing the font loading and
            we're suggesting it moves to the font loading spec
            instead of being on it's own. Is that okay?
  fantasai: It would be nice to have it with the font loading API.
  glazou: Objections?

  RESOLVED: Move Font Loading Control to the Font Loading spec.

text-combine-upright (TCY) on ::marker

  <glazou> https://lists.w3.org/Archives/Public/www-style/2015Apr/0043.html
  fantasai: It's a text level property and I was suggesting we
            include it in ::marker because that's common and not a
            layout thing.
  fantasai: So it should be okay to add and we can mark as at risk,
            but it's an important use case.
  Rossen: Is this level 3?
  <jdaggett> really?!? hmmm
  fantasai: pseudo-elements level 3 for ::marker

  glazou: What do you think?
  Rossen: I don't have an objection. You mentioned it's common?
  fantasai: It's for when you have upright and vertical text. I
            don't have an example off the top of my head. Let me see
            if I have any scans I can find quickly.
  <jdaggett> i'm skeptical that TCY is used in ::marker

  <dbaron> koji asked if writing-mode is ignored in ::marker
  fantasai: Right now ::marker doesn't accept writing mode or any
            other layout.
  koji: Having the numbers in writing mode is often used. So I
        question if it's common.
  Rossen: It's fine as long as there's a good use case for it.
  Rossen: Would also that apply to content?
  fantasai: It already does.
  Rossen: Okay, then I believe ::marker should be the same.

  glazou: Is there any objections against fantasai proposal?
  jdaggett: I'm skeptical, but if there's an example to demonstrate
            it's useful, okay.
  fantasai: Any case where the entire number is a single unit.
  fantasai: There's a lot of cases where twelve is written 1 2 with
            both upright.
  Rossen: I'm fine with adding this as at risk and then moving on.
  glazou: Objections?

  RESOLVED: Accept fantasai proposal to add text-combine-upright to

  glazou: It's the top of the hour. Thank you very much and talk to
          you next week.
Received on Thursday, 9 April 2015 09:14:51 UTC

This archive was generated by hypermail 2.4.0 : Monday, 23 January 2023 02:14:50 UTC