[css-inline-3] Add keywords for raised / dropped initials

[fantasai]

In #2950 (comment) @AmeliaBR wrote:

@Crissov, I'm not sure if the specific numbers you suggest are common enough to make default. But, I do like the idea of keywords dropped and raised for the two most common use-cases for the second property. (I personally find it confusing that you need to specify a "drop" of 1 for not-dropped-at-all.)

[property-name]: 3 dropped;
[property-name]: 2 raised;

dropped would still be the default, and any other levels of sunken-ness could still be set with integer values.

This is maybe a separate issue, though.

//CC @Dan503

It would be pretty easy to add keywords that compute through to an integer, with dropped copying the first value and raised computing to 1.

[AmeliaBR]

Thanks for moving this discussion to its own issue, @fantasai.

For completeness, @Crissov's original comment was:

Iʼd like to approach this with non-existing keywords for the most common cases in mind. These sound reasonable to me:

{
text-initial: dropped; /* = 3 3 */
text-initial: sunken; /* = 3 2 */
text-initial: raised; /* = 3 1 */
...
} 

[Different property names suggestions for the other issue omitted here to focus on this issue.]

[Crissov]

Would sunken also make sense if it computed to the first integer less one, floored at 1?

[Dan503]

I like the idea of being able to say drop or rise using key words. I'd prefer to align it with syntax similar to how the span keyword works in CSS Grid. As in keyword value rather than value keyword.

We also should be able to set both at the same time.

[property-name]: drop 3 rise 2;

Or it could be done as functions instead?

[property-name]: drop(3) rise(2);

[fantasai]

@AmeliaBR Not going to add keywords that compute to arbitrarily chosen constants like 3.

@Dan503 If we need sub-properties, we add sup-properties. Adding a complex syntax isn't really great, it was just unavoidable in Grid. :(

Proposal is to change the syntax of initial-letters from

initial-letters: <number> <integer>?

to

initial-letters: <number> [ drop | raise | <integer>]?

Where an omitted second argument is equal to drop which computes to the positive integer floor of <number>; and where raise computes to 1.

This is basically syntactic just sugar for what we have already.

[AmeliaBR]

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.)

[Dan503]

If you wanted it to both raise by 2 lines and drop by 2 lines at the same time, how would you do that with the proposed syntax?

If you say "not possible", then you see the limitation in the proposed syntax.

Maybe this is a feature for the next level.

[AmeliaBR]

@Dan503 You'd need to use the two-number version that is currently in the spec. The first number is the size expansion factor, the second number (which must be an integer) is the line number at which it is aligned. I'm not sure exactly what you're picturing, but probably either 4 2 or 5 3 would do what you want.

See examples in the spec. E.g., this is 3 2 (Letters 3 lines high, baseline aligned with the second line of the paragraph):

[Dan503]

Thanks @AmeliaBR that cleared things up :)

[css-meeting-bot]

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

The full IRC log of that discussion

<fantasai> Topic: raise/drop keywords for initial-letters
<fantasai> github: https://github.com//issues/2955
<dael> fantasai: Someone asked for keywords representing drop-caps vs raised-caps rather then use numbers
<fantasai>
<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
<fantasai> https://github.com//issues/2955#issuecomment-430277200
<dael> fantasai: Summary of proposal^
<dael> astearns: Reasonable to me
<fantasai> Amelia's follow-up comment on reordering: https://github.com//issues/2955#issuecomment-430323643
<dael> astearns: I like keywords rather than opaque numbers
<dael> dauwhe: Reasonable to me too
<dael> astearns: Objections to adding drop and raise as keywords to initial-letters property?
<tantek> +1 to keywords
<dael> RESOLVED: add drop and raise as keywords to initial-letters property
<dael> fantasai: Follow up is if we can swap order of keyword letter and number
<fantasai> https://github.com//issues/2955#issuecomment-430323643
<dael> astearns: Seems CSS-like
<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.)”
<dael> fantasai: Comment^
<tantek> it depends. background does that. border does not.
<dael> astearns: tantek responded in IRC [reads]
<dael> astearns: I assume because border it would not be unambig
<dael> fantasai: Right. I think the principle is if it's unambig you can reorder
<dbaron> dbaron: We've had properties where swapping ended up being confusing like x/y in background-position
<dael> astearns: Any future thoughts on adding to the syntax? Where re-ordering might not be unambig?
<tantek> I lean towards usability (forgiveness) up front, thus allowing re-ordering.
<tantek> makes it easier to author off the top of your head
<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
<dael> dauwhe: I can't think of anything either. Lots of wants, but they're additional properties.
<dael> astearns: dbaron mentions properties where swapping was confusing
<dael> astearns: Not sure it's a problem here, at least in my mind it's not confusing to put keyword where you want
<dbaron> am I audible?
<fantasai> no
<dael> astearns: Objections to allowing the keywords to be put in either position along with the number?
<dael> astearns: dbaron you are not audible
<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.
<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
<dael> fantasai: This one we're doing opposite. No strict order when there's a keyword and it's unambig
<dael> astearns: Leaning a bit more toward dbaron. I'm a little concerned we might want to extend values syntax here.
<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.
<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
<dael> astearns: AmeliaBR said she's okay with a particular order now and figure out swap later.
<dael> astearns: dbaron what do you think?
<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
<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
<dael> fantasai: I can't think of a reason to add another number to this feature
<dael> dauwhe: Yeah
<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.
<dael> tantek: We barely get away with TRoBLe
<dael> [argument if that even works]
<dael> tantek: Larger point is list of numbers has been shown to be a usability problem
<dael> astearns: Hearing slight concerns but no objects. I'm inclined to prop: Ordr does not matter for the keyword
<dael> RESOLVED: Order does not matter for the keyword in initial-letter property

[AmeliaBR]

A thought on @tantek's comment:

Larger point is list of numbers has been shown to be a usability problem

What about making it <number> at <integer>? E.g., that sunken capital would be initial-letters: 3 at 2, still meaning 3 lines high, aligned at line 2. Then it could be swapped unambiguously (although slightly less read-ably) as initial-letters: at 2 3.

Full syntax, with the short keywords, would be <number> || [at <integer> | drop | raise ]?

Downside is that the -webkit- value syntax would no longer be fully compatible.

[fantasai]

@AmeliaBR I don't think that extending the syntax like that is an overall win, personally. :) We try not to introduce syntactic markers in property value syntaxes unless there's a syntactic ambiguity problem.

And one of the nice things about the simple two-value syntax is that it's easy to remember what happens to a missing second argument: it duplicates the first, just like most other places in CSS. The 'at' keyword doesn't create the same connection to the generic missing values rule.

[fantasai]

Anyway, file a new issue if you feel strongly about it; closing this one out.