You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[css-conditional-5] Remove definitions of <font-format> and <font-tech> #8110
Worse: is only a subset of what is defined in CSS Fonts.
Are you referring to the <string> production? This is the legacy part of format() which is intentionally not included in the conditionals definition.
Regarding the PR: What does the spec look like after bikeshed processing - do the font-tech and font-format become clickable references to fonts-4? font-format would then no longer be correctly defined.
Yes. Should it be invalid in @supports but valid in src for @font-face?
If so, I will close my PR but I think it should be defined in prose (more simple) or in the syntax. I think rewriting the syntax would require to not define font-tech() as a type (<font-tech()> = ...) but as a context-sensitive function (font-tech() = ...).
I did not check the result in Bikeshed, which reports an error for duplicate type refs of <font-tech> in CSS Conditional 5 and CSS Fonts 5, and generates a link to CSS Fonts 5 for <font-format>. I do not know well how it works in details and I do not really understand why it generates a link to CSS Fonts 5 for <font-format> but not <font-tech>.
I updated the PR to import <font-format> and <font-tech> from CSS Fonts by defining that "a CSS processor is considered to support a font format when it is capable of utilising the specified font format in layout and rendering, and this format is not specified as a <string>", which is similar to the prose excluding an unknown -webkit pseudo-element for a supported selector.
Activity
drott commentedon Nov 29, 2022
Are you referring to the
<string>production? This is the legacy part offormat()which is intentionally not included in the conditionals definition.Regarding the PR: What does the spec look like after bikeshed processing - do the font-tech and font-format become clickable references to fonts-4?
font-formatwould then no longer be correctly defined.cdoublev commentedon Nov 29, 2022
Yes. Should it be invalid in
@supportsbut valid insrcfor@font-face?If so, I will close my PR but I think it should be defined in prose (more simple) or in the syntax. I think rewriting the syntax would require to not define
font-tech()as a type (<font-tech()> = ...) but as a context-sensitive function (font-tech() = ...).I did not check the result in Bikeshed, which reports an error for duplicate type refs of
<font-tech>in CSS Conditional 5 and CSS Fonts 5, and generates a link to CSS Fonts 5 for<font-format>. I do not know well how it works in details and I do not really understand why it generates a link to CSS Fonts 5 for<font-format>but not<font-tech>.cdoublev commentedon Apr 26, 2023
I updated the PR to import
<font-format>and<font-tech>from CSS Fonts by defining that "a CSS processor is considered to support a font format when it is capable of utilising the specified font format in layout and rendering, and this format is not specified as a<string>", which is similar to the prose excluding an unknown-webkitpseudo-element for a supported selector.vitorroriz commentedon May 8, 2023
At https://www.w3.org/TR/css-conditional-5/#at-supports-ext, It is confusing for me to read:
Given that at @font-face src we accept
<string>for legacy reasons.