[css-typed-om] Font Family Name doesn't uniquely identify a font face

[wilddamon]

https://drafts.css-houdini.org/css-typed-om/#fontfacevalue-objects

(Brought up by ksakamoto@ on my CL)

I'm not quire sure how |state| attribute should behave, as font family name does not uniquely identify font face.

For example, this defines two @font-face rules for 'Roboto', one for regular weight and one for bold. When only bold face is loaded, what |state| should return?

<style>
@font-face {
   font-family: 'Roboto';
   font-style: normal;
   font-weight: 400;
   src: url(https://fonts.gstatic.com/s/roboto/v16/CWB0XYA8bzo0kSThX0UTuA.woff2);
}

@font-face {
   font-family: 'Roboto';
   font-style: normal;
   font-weight: 700;
   src: url(https://fonts.gstatic.com/s/roboto/v16/d-6IYplOFocCacKzxwXSOFtXRa8TVwTICgirnJhmVJw.woff2);
}

div {
   font-family: 'Roboto';
   font-weight: 700;
}
</style>
<div>This text kicks load of the second @font-face</div>

<script>
document.fonts.ready.then(() => {
   document.fonts.forEach(face => {
      console.log(face.weight, face.status);  // 400 unloaded, 700 loaded
   });
   let f = new CSSFontFaceValue('Roboto');
   console.log(f.state);  // ???
});
</script>

[wilddamon]

@shans Could you please add the right labels and stuff? I don't have access...

[tabatkins]

In fact, there's no single way way to uniquely id a font face without specifying all of its attributes. This particular interface probably needs to be no-constructor, and instead provide a factory function that searches for a given font face when providing with search terms.

[tabatkins]

Okay, so there are two totally different ways of talking about "font faces" that we need to address here.

First is the equivalent of @font-face, representing an actual, concrete font face. This is a ResourceValue or equivalent, can be passed around to Worklets so they can use fonts, etc. I think this is just the already-existing FontFace interface, and we can just use that directly.

Second is representing the value of the 'font' property, which is a search query against the document's font faces. It's not a font face itself, it doesn't load anything, etc. This just needs to be an object with face, weight, etc fields on it, with each being CSSKeywordValues or CSSNumericValues, etc.

The latter can be pushed off for now, with us just relying on CSSStyleValue to handle it, if we dont' want to handle it at the moment.

For the former, is there anything wrong with just returning FontFace objects? More importantly, tho, when is this ever expected to be returned from a TypedOM API? No property will ever return this as a value; so it seems we can just ignore it too?

[nainar]

@shans WDYT?

[shans]

If we don't have the former, how will custom paint end up supporting text rendering?

[tabatkins]

Thru a separate mechanism? FontFace already exists, we just need to pipe those to Custom Paint. My point tho is that FontFace is not a representation of the value of the font property; it's the result of applying the font query to the UA's set of available fonts. (In other words, running FontFaceSet.load().) This is very different from <image> values, which do directly represent a distinct resource.

Chatting with @bfgeek after posting this yesterday led us to the vague idea of just providing the equivalent of FontFaceSet.load() to the appropriate worklets, and automagically hooking up the invalidation logic to the load status of the associated fonts when you depend on a <font>-typed property.

[shans]

The former is @font-face, not FontFace. Naively, the idea of being able to specify an exact, loaded font as the text rendering font seems to be the most basic primitive we could support. Hooking into font querying and fallback could be something we can do after implementing this basic feature.

[tabatkins]

@font-face is the CSS concept; FontFace is the JS concept (there's a FontFace for every @font-face).

Naively, the idea of being able to specify an exact, loaded font as the text rendering font seems to be the most basic primitive we could support.

Sure, but that's not what 'font' does, or any other property in CSS. This is my point - there's no circumstance in TypedOM spec that can return something that corresponds to an exact font face; there's no <font-face> type paralleling the <image> type. 'font' is a font query.

[css-meeting-bot]

The Working Group just discussed ont Family Name doesn't uniquely identify a font face, and agreed to the following resolutions:

• RESOLVED: Kill FontFace spec text

The full IRC log of that discussion

<nainar> Topic: ont Family Name doesn't uniquely identify a font face
<nainar> Github: (https://github.com//issues/405
<nainar> Github: https://github.com//issues/405
<dbaron> also Matt Woodrow, Mozilla (remotely) and Daniel Holbert (Mozilla)
<nainar> TabAtkins: trying to burn thrugh Typed OM issues
<nainar> TabAtkins: Current design of fontface - not designed well. Trying to 1) serve as a value to pipe to PaitWorklet, 2) be the value for fontface - to query
<nainar> TabAtkins: works for 1) not for 2) -> as fdiff type of objecct
<nainar> TabAtkins: fontface value is a query for a font object - find a matching fontface in a doc
<nainar> TabAtkins: change spec to allow fontface value object - so that it isnt directly returned, and then execute that query against a doc from worklet to get a fontface - to use in Worklet
<nainar> TabAtkins: last proposal - seems vague but... equivalent of fontfaceset.load
<tantek> trackbot, start meeting
<nainar> TabAtkins: so that you can pass in font face query. .... So that when set of fontface set changes we can get correct fontface
<nainar> astearns: given confusion - rename this fontfacevalue object?
<nainar> TabAtkins: we already have a fontface object in CSSOm spec
<nainar> dbaron: Font people call the fontface -> face?
<nainar> TabAtkins: we need to get invalidation logic right to make sure we paint with the correct fontface resouce
<nainar> iank_: if the resource loads and matches the fontface query - we should invalidate the paintworklet, we can then assign it to the canvas.
<nainar> astearns: can worklet tell when validation happens?
<nainar> TabAtkins: if we can get invalidation logic right - it only invalidates when a better font shows up
<nainar> surma: where is the query logic being used?
<mwoodrow> Rossen: Sure can, thanks!
<nainar> TabAtkins: used implicitly in css font matching algo. also use it explicity in fontfaceset
<nainar> TabAtkins: can call .load function on font property and it returns the font that matches it
<nainar> surma: you get the font closest matching?
<nainar> TabAtkins: yes
<nainar> TabAtkins: Dont have a design for it yet, updating WG - that I will rip out and replace it with a new design. So contribute here on issue
<nainar> Rossen: how does it interesect with fontface load() and other various events?
<tantek> trackbot, start meeting
<trackbot> Sorry, but no Tracker is associated with this channel.
<dholbert> Are "font-family"or "<family-name>" the same thing as this "font-face query that the font property would use" thing? ( https://drafts.csswg.org/css-fonts-4/#font-family-desc )
<nainar> TabAtkins: the ideal design - declare a custom property with this font - if you pipe it as input to Worklet then (auto/manually) we get the font face objecct as a resut of running this query agianst document
<xidorn> q+
<tantek> trackbot, associate this channel with #css
<nainar> TabAtkins:you should kick of a load and then be alerted when loaded. Get a Promise and then you get alerted when it is loaded.
<xidorn> q+
<tantek> trackbot, start meeting
<trackbot> Sorry, but no Tracker is associated with this channel.
<astearns> ack xidorn
<nainar> xidorn: Paintworklet cant use font right now?
<nainar> iank_: yes!
<nainar> xidorn: Something in typed OM can make it usable?
<nainar> TabAtkins: canvas API that selects font - implicityly executes the font matching alog. We also need a change to canvas API in general - that takes a font face objecct directly
<nainar> iank_: current paintrenderingcontext2D. doesnt take a fontface directly . We dont want to take font query string - as we dont know how to invalidate.
<nainar> TabAtkins: involved change acoss multiple APIs
<nainar> Rossen: bring back with more spec text?
<nainar> TabAtkins: Yes this is a FYI.
<nainar> TabAtkins: more involved proposal later.
<nainar> fremy: are you sure fontface object is needed? Maybe you need a query that you can depend on. Use normal canvas?
<nainar> TabAtkins: Yes but you dont need to use the same query to invalidate against.
<nainar> TabAtkins: also there is some cross worker communication. We want to limit that to once at invalidation time.
<nainar> iank_: The only way you get this is through TypedOM
<nainar> surma: People are askign meif i can use fontface with canavas same q for custom paint
<nainar> astearns: crcisla to get result of query in worklet - you use fallback if you dont get what you expect
<nainar> Rossen: do you need a resolution?
<nainar> TabAtkins: Yes please.
<astearns> s/crcisla/critical/
<nainar> RESOLVED: Kill FontFace spec text