W3C home > Mailing lists > Public > www-style@w3.org > May 2018

[CSSWG] Minutes Telecon 2018-05-09 [css-fonts] [css-values] [cssom] [css-ui-4]

From: Dael Jackson <daelcss@gmail.com>
Date: Wed, 9 May 2018 20:51:43 -0400
Message-ID: <CADhPm3v_V1+oAgv1HBSjXnDTmMhRLoqiV_cAmTixYUKAj_9hcA@mail.gmail.com>
To: www-style@w3.org
=========================================
  These are the official CSSWG minutes.
  Unless you're correcting the minutes,
 Please respond by starting a new thread
   with an appropriate subject line.
=========================================


Fonts
-----

  - RESOLVED: If you have a fragID in @font-face src, and you don't
              understand the fragID syntax, you don't download the
              font. (Issue #2566)
  - RESOLVED: If fragID is valid, but not found in the resource, skip
              as if couldn't load resource. (Issue #2566)
  - RESOLVED: Add format() signifier for font collections, similar to
              variations. (Issue #2566)
  - RESOLVED: css-font-loading, level TBD (Issue #520)

CSS Values
----------

  - RESOLVED: Add clamp(min,mid,max) with min winning over max (Issue
              #2519)
  - RESOLVED: dppx is canonical unit [in serialization of
              <resolution>] (Issue #2241)

CSS UI 4
--------

  - RESOLVED: Add often-rendered-as sentence to pointer definition.
              (Issue #1936)

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

Agenda: https://lists.w3.org/Archives/Public/www-style/2018May/0013.html

Present:
  Rossen Atanassov
  Tab Atkins
  David Baron
  Garrett Berg
  Tantek Çelik
  Alex Critchfield
  Dave Cramer
  Benjamin De Cock
  Elika Etemad
  Simon Fraser
  Tony Graham
  Brad Kemper
  Peter Linss
  Myles Maxfield
  Thierry Michel
  Anton Prowse
  Liam Quin
  Melanie Richards
  Florian Rivoal
  Dirk Schulze
  Alan Stearns
  Greg Whitworth

Regrets:
  Rachel Andrew
  Dael Jackson
  Manuel Rego
  François Remy

Scribe: fantasai

Fonts
=====

Unknown URL Fragment IDs in @font-face
--------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/2566

  myles: You can have a font collection file, has several fonts in it
  myles: Individual fonts are identified with fragID
  myles: If that name of the font doesn't exist in the file, what do
         we do?
  myles: One is we throw out the whole URL, the whole URL is invalid
  myles: The image() function does this
  myles: Alternately, throw out just the fragID, use the URL as if it
         didn't have one
  myles: Ends up pointing at first item in the collection
  myles: In that case, if you click on document navigation to a
         missing fragID, you go to the top
  myles: So we have precedent for both behaviors
  myles: Today for browsers that don't understand, they will just use
         the first item in the collection
  myles: regardless of fragID
  myles: So already some places where we have this behavior

  florian: Thing you mentioned last, in terms of what browsers do
  florian: when they don't support this
  florian: hints at consistency with that
  florian: Won't have browser showing different fonts for non-obvious
           reasons
  fantasai: But you'll have that already if fragID is valid
  myles: If fragID is valid, new browsers will show ID's font, old
         browsers will show first font
  myles: if fragID is invalid, then one of the options will make the
         new browsers have same behavior has same behavior

  dbaron: One thing to think about is how similar are the fonts in the
          collection?
  dbaron: If they're likely to be similar, then falling back to
          another font in the collection seems reasonable
  florian: Especially browsers can be consistent with older browsers

  fantasai: Concerned about the what if there's fragment id format
            that doesn't understand if it's useful as the next thing
            of the list?
  fantasai: Say a frag id in a collection that it's not in the system,
            and the browser can't load it since it doesn't understand
            it for example, an open type... can it fall down the list
            further
  florian: If the browser understands the syntax it would be good to
           fall back but if it doesn't...?
  florian: Can we do both? If the format of the fragID is invalid, it
           treats as invalid, but if the fragID is missing then it
           loads and tries to find it and falls back to first font or
           whatever it can do
  TabAtkins: What Florian said, about falling back to first font,
             that's very specific to collections
  TabAtkins: It's not a behavior we can bake into general behavior for
             fragIDs
  myles: Yeah, platform has different behaviors
  TabAtkins: There's a different consideration for fragID you
             understand but can't find, and fragID you don't
             understand.
  myles: These fragIDs are names, they're just strings
  TabAtkins: That's assuming fragID syntax for truetype collections is
             the only format that will exist
  myles: Two collection formats, both have this syntax
  astearns: I thought we'd already established that browser that don't
            understand fragment syntax will use the URL as if it
            wasn't there
  TabAtkins: We didn't establish that, it's just the current behavior
             of browsers

  astearns: Any other comments?
  florian: Can we distinguish?
  florian: For collections is *any* string accepted, regardless of
           syntax e.g. parentheses and stuff included?
  myles: Any string
  <TabAtkins> Per https://tools.ietf.org/html/rfc8081#section-4.2 the
              fragment is *not* an arbitrary string, it does a useful
              subsetting of "name-like" syntax, explicitly excluding
              things that might be functions/etc
  <TabAtkins> So `font.ttf#foo(bar)` is *not* a valid way to select a
              font from a collection. It's an unknown fragment.

  liam: Reason to use collections is to save bandwidth
  liam: Can use it in a dozen different @font-face rules
  liam: Need it to be first in your src list, can't save bandwidth if
        browser loads other things first
  liam: If bold-italic is first and regular is second
  liam: It means your whole page will be bold-italic if you didn't
        understand the fragID
  liam: and that's very unlikely to be acceptable
  liam: Seems no way to do fallback here, have the browser only
        download the object when you want it to
  liam: You should ignore the font if you don't understand the fragID
        syntax
  myles: So in today's browser, that's what would occur
  myles: In new browsers you get good behavior, old browsers you get
         the bad behavior
  <liam> [right]

  florian: Do we have any data on whether this syntax is used?
  myles: It's not supported in browsers, who would use it?
  florian: If an author is accidentally using fragID, expecting it to
           not work
  myles: Don't have any data on that
  liam: If font collections had a different font format that you could
        use in the font-face rule
  liam: and browsers that didn't understand them would skip them, that
        would solve the font fallback problem
  myles: In Berlin we specced a new format identifier syntax
  myles: we could add a new keyword for these
  myles: We can use the pre-existing resolution to extend the format
         function to support collections
  myles: Different issue, but would allow for correct fallback
         behavior that you've described
  <florian> myles, that sounds like a good idea.
  astearns: That sounds like a good idea.
  astearns: If you support collections, use this one.
  astearns: In browsers that don't support collections, whole bit
            would be thrown out
  myles: So, we extend format() function to indicate collections
  myles: and then fallback to first font if fragID is not found

  fantasai: Given we don't need to worry about consistency between
            existing supported browsers and those who don't support it,
  fantasai: it seem better if instead of picking the first font we
            fallback to the next one like the image()
  fantasai: picking the first one makes it easier for the authors to
            notice the error
  myles: But that's opposite of what liam said, he said it'd be really
         obvious
  fantasai: But if Medium loaded instead of Book, you're unlikely to
            notice
  dbaron: Seems like this might manifest as an issue of the form "bold
          and italic don't work"
  myles: You'd get synthetic bold/italic

  TabAtkins: Concern it's not just about collections
  TabAtkins: But fragIDs in general
  TabAtkins: There *are* limitations on what you can use as a name
  TabAtkins: E.g. functional notation is reserved for potential future
             use
  TabAtkins: Today we would load something using such a future syntax
             by loading the first font
  TabAtkins: That's not good
  <TabAtkins> Repeating from earlier: So `font.ttf#foo(bar)` is *not*
              a valid way to select a font from a collection. It's an
              unknown fragment.
  fantasai: I agree with TabAtkins
  florian: I would like to agree with TabAtkins, but if on the font
           format side the fragID can be any string but on our side
           it's more restricted, isn't that a problem?
  TabAtkins: The standard for this excludes fragments like #foo(bar)
  TabAtkins: Allowed syntax is things that look like names
  florian: OK, then I agree with you
  TabAtkins: RFC8081
  TabAtkins: https://tools.ietf.org/html/rfc8081#section-4.2

  astearns: Getting to half an hour
  astearns: Should at least spec the collections into format()
  astearns: And maybe come back to it?
  myles: More important to have resolution than on a particular
         resolution, so happy to do the ignore unknown/unfound URLs
  astearns: For cases where browser understands fragment and can't
            find it, browser goes to next in the list?
  astearns: Or browser doesn't understand fragID, skips downloading
  [fantasai summarizes]

  astearns: So, if you have a fragID in @font-face src, and you don't
            understand the fragID syntax, you don't download the font.
  <liam> +1

  RESOLVED: If you have a fragID in @font-face src, and you don't
            understand the fragID syntax, you don't download the font.

  astearns: If you do understand the fragID, we will download the
            font, and if ID'd thing not found, move on to next one (as
            if couldn't load)

  RESOLVED: If fragID is valid, but not found in the resource, skip as
            if couldn't load resource

  astearns: Add format() signifier for collections, similar to
            variations

  RESOLVED: Add format() signifier for font collections, similar to
            variations

Variation axes not discoverable
-------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/520

  myles: One of the requests we got from people who make websites who
         like typography
  myles: There's no way for them to know what to put in their
         font-feature-settings and font-variant-settings properties
  myles: Right now they are parsing the font with JS to pull out the
         tables
  myles: So trying to think of ways that a browser could make this
         data available to web content
  myles: Best way I could think of was to hang off of TabAtkins’s
         fontFace object
  myles: defined in font loading spec
  myles: New attribute on existing object
  myles: That gives a bunch of info about the font
  myles: Just wanted to check on general idea of extending fontFace
         like this
  <TabAtkins> My proposal for the IDL for this
https://github.com/w3c/csswg-drafts/issues/520#issuecomment-386153230

  astearns: Well I like the idea
  TabAtkins: I'm for it
  TabAtkins: I think this is the right place to put it, good approach
             for it
  myles: Tab's better at writing APIs, so we can use his suggestion if
         we think it's a good idea
  astearns: Any concerns about adding all this info?

  astearns: Instead of new UD, maybe another level?
  myles: ...
  TabAtkins: Let me see how mature the css-font-loading spec actually
             is, and then we'll decide
  fantasai: So, proposal is add it to css-font-loading, level TBD?
  astearns: Any objections?

  RESOLVED: css-font-loading, level TBD

CSS Values
==========

Add clamp()?
------------
  github: https://github.com/w3c/csswg-drafts/issues/2519
  scribe: fantasai & dbaron

  TabAtkins: Proposal for a clamp function to be added
  TabAtkins: Equivalent to using min & max in combination
  TabAtkins: but it's pretty common to do both
  TabAtkins: And nested functions for this are a bit confusing to read
  TabAtkins: Variations are might want max to win, which it doesn't
             for CSS in general

  fantasai: Now I understand why astearns put the minmax() issue from
            Grid on the agenda
  fantasai: We might want to look at that before resolving
  fantasai: There are 2 independent issues open on grid, affecting
            minmax()
  fantasai: First is an issue where the request was to have 'fr's in
            the min position
  fantasai: Somebody wanted to have 1fr but cap at 250px... space then
            goes elsewhere
  fantasai: Seemed like you might want to control the min on that fr,
            so you might want minmax() to take 3 arguments
  fantasai: the min, the goal fr, and the max
  fantasai: Other issue on minmax() was that when we were working on
            grid level 1, somebody said that min winning over max
            really bothered them, with a valid use case.
  fantasai: There are also use cases for min winning, and that's
            generally how CSS works, so we're stuck with it for level
            1, but refiled against grid level 2
  fantasai: Both of these issues are ready for working group discussion
  fantasai: Syntax for clamp() ties into these same requests
  fantasai: if we extend minmax() to have 3 arguments to handle the
            'fr' case where it makes sense to have both a min and a
            max, then that's the syntax we should use
  fantasai: Alternatively, if you want the 3 argument version then you
            have to change the name to clamp()
  fantasai: One advantage of the minmax() name which Microsoft people
            came up with is that it's really clear that the min comes
            first and the max comes last
  fantasai: A clamp() function doesn't have that property
  fantasai: What's currently in the proposal for clamp() is that the
            order is max-min, the first one still wins, maybe that's a
            reasonable proposal for one where max wins
  fantasai: for grid ... ???
  fantasai: If we're going to try to solve them we should try to be
            consistent

  TabAtkins: I think only thing that directly affects this is ordering
             argument
  TabAtkins: Ordering should match my proposal here
  TabAtkins: I don't think anything else needs to care for base
             proposal
  fantasai: But also I think we should use the same name, mimax() --
            and maxmin() for the max-wins case
  TabAtkins: minmax() doesn't resolve to a number
  TabAtkins: minmax() in grid is not a clamping function. It's not a
             mathematical function; it's an instruction to the layout
             algorithm.
  fantasai: minmax() with 2 arguments is a range, minmax() with 3
            arguments resolves to 1 of the arguments
  TabAtkins: Not until layout time
  fantasai: Percentages in here also don't resolve until layout time

  TabAtkins: 3 argument is similar to the 2 argument, still specifying
             a range
  fantasai: What?
  TabAtkins: The 3 argument version in grid will still have similar
             behavior, a command deeply integrated into the layout
             function, not something usable anywhere that can take
             various values
  TabAtkins: and the value space of its arguments is dramatically
             different from what we want to allow
  TabAtkins: Semantically similar but very different in the details
             and we shouldn't be trying to reuse the name

  Rossen: How do you propose to have clamp() work with variables?
  TabAtkins: clamp? It's just a shorthand for the min() and max()
             functions that just implements clamping in the standard
             CSS fashion.
  astearns: If we do have separate minmax() with three values and
            clamp() with three values, should have same parameter
            order at least
  astearns: If we have separate minmax() with 3 values and clamp()
            functions I think it makes sense to have the same
            parameter order at least.
  TabAtkins: Yes, I agree. Already have that in both proposals
  astearns: Are we coming to a resolution here, to add a clamp()
            function with min, mid, max?

  astearns: Are you convinced to use clamp(), fantasai?
  fantasai: I'm not sure yet, but not objecting 'cuz not sure

  RESOLVED: Add clamp(min,mid,max) with min winning over max

dppx vs x in serialization
--------------------------
  github: https://github.com/w3c/csswg-drafts/issues/2241

  TabAtkins: When Webkit introduced -webkit-image-set function
  TabAtkins: They used an 'x' unit instead of using a <resolution>
  TabAtkins: <resolution> at the time didn't include 'x'
  TabAtkins: Wanted to make 'x' a resolution, too
  TabAtkins: equivalent to dppx
  TabAtkins: For serialization, it seemed that -webkit-image-set
             function would be more often used than resolution queries
             in OM
  TabAtkins: So I wanted to make 'x' the canonical unit
  TabAtkins: Our implementers expressed some concern about this,
             thought we should use 'dppx'
  Florian: If you have people with compat concerns, then let's
           minimize the concern
  astearns: Any objections to using dppx and canonical unit

  RESOLVED: dppx is canonical unit

CSS UI 4
========

Pointer cursor over interactive elements
----------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/1936#issuecomment-341987070

  florian: Almost editorial, but maybe not
  florian: We describe cursors that can be chosen with the 'cursor'
           property
  florian: Didn't require any particular iconography
  florian: So we describe them in terms of what they are used for
  florian: e.g. “This is the thing you see when you point at links”
  florian: It's descriptive, but also normative.
  florian: People mentioned that even though that used to be a
           reasonable statement
  florian: But now lots of authors use that cursor not only on links,
           but all clickable things
  florian: If you say “The thing you only see on links”, people get
           confused
  florian: Don't you mean “The thing you see on clickable things”?
  florian: So we could change the description
  <dbaron> "The cursor that is generally used to indicate links or
           other clickable things." ?
  florian: But then that looks like it suggests a change to the UA
           style sheet
  florian: It doesn't seem like anyone is suggesting to change the
           default behavior
  florian: We can either update the description, have it not match the
           UA style sheet
  florian: Or make the description match the UA stylesheet, but not
           common practice
  <astearns> amelia's suggestion:
https://github.com/w3c/csswg-drafts/issues/1936#issuecomment-341987070

  smfr: ... authoring conventions
  smfr: On MacOS we definitely don't show the hand on clickable things
        in general
  smfr: If we knew what OSes do, that' be helpful
  florian: It seems like on native UIs, it's not the cursor used on
           clickable things
  florian: but on Web pages it is
  smfr: So I would suggest we don't make a change
  smfr: I don't think we should impose on users a difference between
        the Web view and things outside it
  smfr: I think it wanted to indicate something like navigating away...
  ...
  florian: Fair amount of agreement on the thread
  florian: The question isn't whether we should encourage pointer on
           buttons
  florian: But how to describe pointer
  florian: are we prescriptive or descriptive?
  florian: If we're prescriptive, then agreed with you
  florian: I don't have a strong opinion, fwiw. Just reporting the
           disagreement

  astearns: Not clear to me whether current spec is prescriptive or
            descriptive
  florian: Kinda both. Used to be consistent between the two, not so
           much now
  florian: We could maybe have descriptive and prescriptive bits
  ?: I would be OK with that
  florian: “Typically rendered as”
  astearns: If we were going to start over... but I don't think we
            need to change.
  <tantek> indeed
  astearns: If there's nothing testable that we're making the change
            for, no need for a change
  smfr: Ask browser vendors ... UA stylesheet ... buttons [audio
        cutting out]

  florian: Proposed resolution is don't change the sentence, add a
           clarifying rendered-as sentence
  astearns: why?
  florian: Most values have such a sentence, and since there seems to
           be some confusion, having a bit more visually descriptive
           sentence could be useful
  * fantasai agrees
  <fantasai> I initially thought 'pointer' was just the arrow.
  florian: pointer is closed hand pointing
  astearns: hearing no objections
  proposed resolution: Add sentence describing what 'pointer' looks
      like.
  tantek: are we adding screenshots?
  astearns: Doesn't seem necessary
  florian: Also the spec itself is interactive, you get the value as
           you hover over it

  RESOLVED: Add often-rendered-as sentence to pointer definition.

  <fantasai> Florian, maybe extend the 'cursor' onto the <dd>s as well?
Received on Thursday, 10 May 2018 00:52:39 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 10 May 2018 00:52:40 UTC