Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[css-font-display] Font loading behavior when the descriptor is modified via CSSOM #69

Open
KenjiBaheux opened this issue Dec 22, 2016 · 5 comments

Comments

@KenjiBaheux
Copy link
Contributor

Fielded question: "How does font loading behave when this descriptor is modified via the CSSOM?"

Note: Blink currently works as if the @font-face rule was removed and re-inserted with new font-display value. But it's unclear if this is the desired behavior.

@KenjiBaheux KenjiBaheux changed the title [css-font-display] [css-font-display] Font loading behavior when the descriptor is modified via CSSOM Dec 22, 2016
@litherum
Copy link

litherum commented Jan 3, 2017

What happens if the @font-face rule is removed and re-inserted with the new font-display value?

@tabatkins
Copy link
Owner

@KenjiBaheux That seems reasonable, yes.

@litherum Great question that I have no idea what the right answer is.

@KenjiBaheux
Copy link
Contributor Author

On how we decide what is reasonable:

  • What would the least surprising option? Are there similar concepts in other CSS features?
  • Which behavior would empower developers?

Strawman:

  1. initial @font-face rule with font-display: optional
  2. web font is not readily available
  3. the UA downloads the web font for a future use
  4. the web font is downloaded but not used due to font-display: optional
  5. font-display is touched (either via CSSOM or by removing and re-inserting a font-face rule)
  6. the UA re-runs the logic (even if font-display wasn't actually modified)

This would allow authors to "unblock" fonts.
Are there any downsides?

cc/ @irori to confirm that this is what our implementation does and if the above idea is concerning from an implementation viewpoint.

@tabatkins
Copy link
Owner

Freshly re-evaluating the timeout behavior does indeed sound like the best way to handle it. It's simple and matches the behavior you'd get if you inserted a fresh @font-face with a new name, but pointing to the same file.

the UA re-runs the logic (even if font-display wasn't actually modified)

This seems clear if the @font-face was removed and re-added. Are you saying, tho, that just setting a font's display to itself should trigger re-evaluating the timeout behavior? Or should it be a no-op?

@KenjiBaheux
Copy link
Contributor Author

KenjiBaheux commented Jan 18, 2017

Yes, I felt that setting font-display to itself should re-run the logic.

Are there any similar patterns in CSS? What would be the least surprising option?
If I set font-family to itself, does the UA recheck for items in the font list until it finds one that's available and then update the document if the selected font is different than before?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants