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-fonts] Clarification on behaviour when modifying @font-face rules #3542
Comments
You should not be able to do this at all via any interface. Parsing will fail at the very least.
Ideally, they should work as if they are initially setup that way.
Could you paste code here for how you change them? That would probably be easier for others to figure out what is happening. |
Thanks for the reply. You should be able to perform the actions above in any of the listed browsers using devtools. Regarding the first point, you can do this by directly modifying the text content of a |
The behavior on https://css-tricks.com is indeed very interesting that I cannot explain from a brief test. I also tried in https://areweasyncyet.rs/ which is a website I was recently working on, and everything seems to work as expected via editing the style for that site, so I would guess that either there is a common bug among browsers, or there is some interesting behavior hidden in some corners of the spec that I don't know yet... |
Yeah, you’re right that we should investigate this and describe it in the spec. |
If it helps, I found an overview of the font loading method: https://css-tricks.com/design-v17/#article-header-id-8 Digging into the implementation a little deeper, for any given document it looks like fonts are being loaded with:
|
OK, I think we should close this issue. The special behavior on css-tricks.com is purely because it's using multiple approaches to load the same set of fonts. Specifically, you can find the following code in their script: if ('fonts' in document) {
var e = new FontFace('Rubik', 'url(/wp-content/themes/CSS-Tricks-17/fonts/Rubik-Regular-hint-all.woff2) format(\'woff2\'), url(/wp-content/themes/CSS-Tricks-17/fonts/Rubik-Regular-hint-all.woff) format(\'woff\')'),
t = new FontFace('Rubik', 'url(/wp-content/themes/CSS-Tricks-17/fonts/Rubik-Bold-hint-all.woff2) format(\'woff2\'), url(/wp-content/themes/CSS-Tricks-17/fonts/Rubik-Bold-hint-all.woff) format(\'woff\')', {
weight: '700'
});
Promise.all([
t.load(),
e.load()
]).then(function (e) {
e.forEach(function (e) {
document.fonts.add(e)
})
})
} If you clear these manually added fonts via |
Agreeing that the reported issue is caused by the same fonts being loaded by multiple routes - so if the CSS is changed or invalidated, but the others are not, they still have an effect. |
I'd like some clarification on how fonts should be handled if the
@font-face
block that describes them is modified after the document has loaded.Using any of the methods below, my expectation (which could be wrong) is that the browser should stop rendering text using a custom font:
@font-face
rule by renaming it to something like@-disabled-font-face
font-family
value in a@font-face
rule but not updating thefont-family
elsewheresrc
value in a@font-face
rule@font-face
rule@font-face
ruleHowever, Safari, Chrome and Firefox all continue to render text using the font. Is this the expected behaviour? If so, could somebody point me to the part of the spec that defines it?
The text was updated successfully, but these errors were encountered: