- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 17 Oct 2018 16:56:14 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `raise/drop keywords for initial-letters`, and agreed to the following: * `RESOLVED: add drop and raise as keywords to initial-letters property` * `RESOLVED: Order does not matter for the keyword in initial-letter property` <details><summary>The full IRC log of that discussion</summary> <fantasai> Topic: raise/drop keywords for initial-letters<br> <fantasai> github: https://github.com/w3c/csswg-drafts/issues/2955<br> <dael> fantasai: Someone asked for keywords representing drop-caps vs raised-caps rather then use numbers<br> <fantasai> <br> <dael> fantasai: Thought it would be easy to say drop computed to integral floor and raise computes to 1. It's a question of if WG things work adding<br> <fantasai> https://github.com/w3c/csswg-drafts/issues/2955#issuecomment-430277200<br> <dael> fantasai: Summary of proposal^<br> <dael> astearns: Reasonable to me<br> <fantasai> Amelia's follow-up comment on reordering: https://github.com/w3c/csswg-drafts/issues/2955#issuecomment-430323643<br> <dael> astearns: I like keywords rather than opaque numbers<br> <dael> dauwhe: Reasonable to me too<br> <dael> astearns: Objections to adding drop and raise as keywords to initial-letters property?<br> <tantek> +1 to keywords<br> <dael> RESOLVED: add drop and raise as keywords to initial-letters property<br> <dael> fantasai: Follow up is if we can swap order of keyword letter and number<br> <fantasai> https://github.com/w3c/csswg-drafts/issues/2955#issuecomment-430323643<br> <dael> astearns: Seems CSS-like<br> <fantasai> “Would it be possible to tweak that syntax so that drop 3 and raise 2 are valid values? (While still being unambiguous for parsing when there are two integers.)”<br> <dael> fantasai: Comment^<br> <tantek> it depends. background does that. border does not.<br> <dael> astearns: tantek responded in IRC [reads]<br> <dael> astearns: I assume because border it would not be unambig<br> <dael> fantasai: Right. I think the principle is if it's unambig you can reorder<br> <dbaron> dbaron: We've had properties where swapping ended up being confusing like x/y in background-position<br> <dael> astearns: Any future thoughts on adding to the syntax? Where re-ordering might not be unambig?<br> <tantek> I lean towards usability (forgiveness) up front, thus allowing re-ordering.<br> <tantek> makes it easier to author off the top of your head<br> <dael> fantasai: I don't think there's other relevent numbers. Can't think of anything. We've had people asking for lots of features and none is more numbers<br> <dael> dauwhe: I can't think of anything either. Lots of wants, but they're additional properties.<br> <dael> astearns: dbaron mentions properties where swapping was confusing<br> <dael> astearns: Not sure it's a problem here, at least in my mind it's not confusing to put keyword where you want<br> <dbaron> am I audible?<br> <fantasai> no<br> <dael> astearns: Objections to allowing the keywords to be put in either position along with the number?<br> <dael> astearns: dbaron you are not audible<br> <dael> dbaron: I think some depends on how much we might extend. Initially with background-position-x/y we thought it was fine to let people put in either order. THen we extended and it was confusing.<br> <dael> fantasai: I think part that's confusing there is when you have one keyword and one non-keyword and there's strict order, but not in other cases<br> <dael> fantasai: This one we're doing opposite. No strict order when there's a keyword and it's unambig<br> <dael> astearns: Leaning a bit more toward dbaron. I'm a little concerned we might want to extend values syntax here.<br> <AmeliaBR> Jumping in as the person who suggested it: There's no harm with starting out with the more strict syntax & then seeing if there's any author confusion/frustration.<br> <dael> astearns: If there isn't anything anyone can think of that would extend syntax, and I know dauwhe has put a lot of thought into this, I'm okay with allowing the swap<br> <dael> astearns: AmeliaBR said she's okay with a particular order now and figure out swap later.<br> <dael> astearns: dbaron what do you think?<br> <dael> dbaron: I'm okay with it if we don't see future possibilities to expand. But if this becomes 3 value at some point letting these two swap might be problematic<br> <dael> astearns: One way to look is we're commiting to extra properties if we want to extend. And that's not a bad thing. More properties with a name makes it clear what you're doing rather then adding a value in a list<br> <dael> fantasai: I can't think of a reason to add another number to this feature<br> <dael> dauwhe: Yeah<br> <dael> tantek: Tend to agree if a property requires ordering of numbers it's confusing. Classic example is how many people get lat and long wrong. That's a classicaly studied problem.<br> <dael> tantek: We barely get away with TRoBLe<br> <dael> [argument if that even works]<br> <dael> tantek: Larger point is list of numbers has been shown to be a usability problem<br> <dael> astearns: Hearing slight concerns but no objects. I'm inclined to prop: Ordr does not matter for the keyword<br> <dael> RESOLVED: Order does not matter for the keyword in initial-letter property<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/2955#issuecomment-430706617 using your GitHub account
Received on Wednesday, 17 October 2018 16:56:16 UTC