- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 12 Dec 2018 17:58:11 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `font-display says it's valid in @font-feature-values but it isn't an at-rule`. <details><summary>The full IRC log of that discussion</summary> <dael> Topic: font-display says it's valid in @font-feature-values but it isn't an at-rule<br> <dael> github: https://github.com/w3c/csswg-drafts/issues/2973#issuecomment-442167124<br> <dael> TabAtkins: A while back got a requirt to override font descriptor for fonts they don't control. Specifically google fonts. Google fonts control that and due to caching don't want arbitrary things in there. Idea is add font-display to font feature values which kinda adds additional information and we can expose that<br> <chris> q+ to note this is very interesting but seems more CSS Syntax than CSS Fonts 4. Would also like to see the proposal more fleshed out.<br> <dael> TabAtkins: Right now font-feature-values doesn't take descriptors. Needs minor spec edits for that.<br> <dael> TabAtkins: myles objected because seems ad hoc. We want to define additional fontface, but they cascade atomically. Rather then trying to come up with special fix for this one problem we thought why not try and fix the general problem and have a way to explicitly extend these @rules<br> <myles> i didn't "object"<br> <myles> just said it would be a shame if we did it<br> <dael> TabAtkins: IN thread had proposal for @partial rule that looks like an @rule where partial is the first ident. Whatever is in there is matched with the appropriate @rule and override what's in it with the partial. @partialFontFace and then put the descriptor. Font family or a weight or what have you. CHanges the font display value of font faces loaded from another source<br> <dael> TabAtkins: Only a handful of atomic cascade now, but this lets you handle that override case<br> <dael> TabAtkins: Proposal in thread if we want it. Probably a new WD, doesn't fit in Fonts spec. I'm happy to edit and persue if people are interested, but want interest before more time<br> <dael> leaverou: How to determine which @rule it overrides?<br> <dbaron> q+<br> <dael> myles: The way this would have to work is each @rule has to opt in. By default none get a change and we opt in @rules. When it's opted in it would have to spec how the partial rules match with the base @rule. For Fonts there are 3 descriptors that would match, different for other @ rules<br> <dael> TabAtkins: Font family has to match and the partial has to be = or less restrictive match on style, stretch, and weight descriptors.<br> <chris> q?<br> <dael> TabAtkins: If you only want the bolds you can specifiy that, or you can allow for everything<br> <dael> TabAtkins: Defined by each @rule when it claims I'm allowed to be extended. Rules are ad hoc for what the @rule does<br> <astearns> ack chris<br> <Zakim> chris, you wanted to note this is very interesting but seems more CSS Syntax than CSS Fonts 4. Would also like to see the proposal more fleshed out.<br> <myles> q+<br> <dael> chris: I agree with this belonging in sep spec. Also have questions on how matching works. I understand how it works for each @rule differently, but I'd like a definition that says see each @rule for matching and there's a common term the @rules can refer to.<br> <fantasai> The contents of @supports already cascades<br> <dael> chris: Seems generally useful, but I'd like more examples and where it won't work, like I assume not on @supports<br> <astearns> ack dbaron<br> <dael> chris: I think it's great, it's really interesting<br> <dael> dbaron: This feels like it's a confusing mech to me. Applies to some but not other @rules. Applies to those that don't cascade and turns them into cascading @rules<br> <chris> kind of like inherit applies to non-inheritable propertes, which is also a bit weird :)<br> <dael> dbaron: I think it's confusing enough that some do that and some don't. What TabAtkins said about @font-face where it interacts differently also sounds weird and confusing<br> <fantasai> +1 to dbaron<br> <leaverou> +1 to dbaron as well<br> <dael> dbaron: I feel it might be better handled as extensions to each @rule that needs this mech. Feels like avariant, not a new @partial rule<br> <dael> TabAtkins: THat's what it is, I'm just unifying it under one name to be recognizable. THe stuff after the @partial is what that @rule wants to do its extension grammar with<br> <dael> chris: I think as unified as poss on extension mech is better than duplicating half the @rules<br> <astearns> ack myles<br> <dael> myles: That's the direction I was going to mention<br> <dael> myles: 2 pieces, one to open a closed blocka nd add stuff. Then there's the specific idea of the fonts problem where different people want to change different parts.<br> <dael> myles: Such a general solution would solve this use case. I don't think this use case is suffiecnt for this complicated thing. If there are other use cases the combination of them could motivate.<br> <dael> astearns: AS long as solutions are generalizable. I'd like to see other rules we'd want to open and see if enough similar. I'm a little scared with each rule can define how overwritten with partial rule<br> <dael> TabAtkins: All reasonable.<br> <dael> TabAtkins: The particular use case for fonts is strong. I'd like to address that. If we're not going for general until we find more things, I'd push to solvet his use case<br> <dael> myles: Rather then giving up I think somebody should do research to see if there are use cases. We're asking the question, not answering it<br> <dael> astearns: I think general solution merits a bit more work. WIll need non-font use cases so we can evaluate general solution outside this thing that needs to be solved. Agreed we need to solve this and we should take time to see if general solution is the way to do. More specific @rules is a rats nest we've added to for decades and normalizing would be good<br> <dael> fantasai: I don't think a generic rule is normalizing anything. Agree with dbaron that if we're going to do it...we might decide on a specific syntax, but the @rule should be named after its @rule and not be generic<br> <myles> @partial font-face @partial-font-face @font-face-partial<br> <myles> @font-partial-face ????<br> <dael> TabAtkins: I don't care about @parial fontface or @fontface.partial I jsut want to see partials as a thing<br> <myles> @key-partial-frames<br> <dael> TabAtkins: Let's look at use cases, see if we can find decent ones for other cases of extension. Maybe there's a good reason to extend something like keyframes.<br> <dael> astearns: Alright. Sound good to everyone?<br> <dael> astearns: Alright, thanks.<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/2973#issuecomment-446682455 using your GitHub account
Received on Wednesday, 12 December 2018 17:58:13 UTC