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
Comments
What happens if the @font-face rule is removed and re-inserted with the new font-display value? |
@KenjiBaheux That seems reasonable, yes. @litherum Great question that I have no idea what the right answer is. |
On how we decide what is reasonable:
Strawman:
This would allow authors to "unblock" fonts. cc/ @irori to confirm that this is what our implementation does and if the above idea is concerning from an implementation viewpoint. |
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.
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? |
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? |
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.
The text was updated successfully, but these errors were encountered: