- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 9 May 2018 20:51:43 -0400
- 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