[css-writing-modes][css-pseudo][css-inline] text-combine-upright and initial-letter

[frivoal]

It is not clear what this should do

p {
 writing-mode:vertical-rl;
  text-orientation: sideways;
  text-combine-upright: 2;
}
p::first-letter {
  initial-letter: 3;
 }

<p>13 is a really nice number. Lorem Ipsum...</p>

::first-letter should match the 1 at the beginning of the <p>, but that means it selects half of the text-combine-upright, and I have no idea of how you'd turn that into a 3-line drop cap.

I think there are three changes we could make to the specs to deal with that:

1. initial-letter has no effect when applied to some-but-not-all the characters in a run of characters grouped by text-combine-upright
2. ::first-letter needs to treat a run of characters grouped by text-combine-upright as single character and select all of it if it is the first thing in the element.
3. ::first-letter does not select anything if the element starts with run of characters grouped by text-combine-upright

---

Just for the record, I believe that text-combine-upright itself isn't an issue, and that the following ought to work just fine, highlighting that the issue is just due to selecting part of this orthogonal bit of content.

p {
 writing-mode:vertical-rl;
  text-orientation: sideways;
}
span {
  text-combine-upright: all;
  initial-letter: 3;
 }

<p><span>13</span> is a really nice number. Lorem Ipsum...</p>

[kojiishi]

Spec-wise, 9.1.2. Layout Rules has the following sentences:

For line breaking before and after the composition, it is treated as a regular inline with its actual contents. For other text layout purposes, e.g. emphasis marks, text-decoration, spacing, etc. the resulting composition is treated as a single glyph representing the Object Replacement Character U+FFFC.

I suppose initial-letter belongs to "other text layout purposes"?

[frivoal]

Selector matching and ::first-letter is not normally considered part of layout, so I don't think this sentence applies as-is, but we could tweak it if that's what we want.

If we consider the whole run as a single U+FFFC, that would mean ::first-letter does not select it, so this is the equivalent to "solution 3", right?

I think I'm ok with either solution 2 or 3, so fine.

Testing a bit further how ::first-letter and text-combine-upright interact (leaving aside initial-letter for a second), current implementations seem to do things that are neither 2 nor 3, and are all over the place:
http://output.jsbin.com/xacicok/

[kojiishi]

Ah, ok, sorry I was confused. So initial-letter is ok but not ::first-letter? My comment above was on initial-letter.

[frivoal]

One part of the problem is that as far as I can tell, initial-letter does not make sense if you apply it to part of the run of characters grouped by text-combine-upright. It can only make sense it you apply to all of it (or none of it). In turn, that problem may only be relevant if it is possible to select only a part of the run of characters grouped by text-combine-upright.

I find the rules in https://drafts.csswg.org/css-writing-modes-3/#text-combine-runs hard to understand, so I think, but I am not sure, that it would not be possible to try and apply initial-letter (or any other property for that matter) to part of a run of characters grouped by text-combine-upright using a regular element (e.g. <span>) because the presence of that element would create a box, which get in the way of creating that run. What the different browsers do on http://output.jsbin.com/xacicok/ seems to support that, but at the same time they're all doing something different, so I'm not 100% sure. Can someone who understands the spec, look at http://output.jsbin.com/xacicok/ in various browsers, and help me understand:

• for the third example on the first row, which browser is following the spec
• for the third example on the second row, whether Edge (which is the only one to support text-combine-upright: digits) follows the spec or not

If it is the case that you cannot apply a property to part of a run of characters grouped by text-combine-upright using a regular element, then it would make sense for ::first-letter not to be able to do that either. But I can think of at two ways that could be prevented:

• ::first-letter matches a single letter, creates a box, and applies a property to it. The existence of that box boundary prevents the creation of a run of characters grouped by text-combine-upright that would contain both the first-letter and the one(s) after it. (everybody except Edge with text-combine-upright:all seems to be doing a variant of this, but interestingly, different variants of it, not always aligned with what they did with a span)
• ::first-letter is defined not to match characters that would otherwise be in a run of characters grouped by text-combine-upright, so that we don't run into the problem (this appears to be what Edge is doing with text-combine-upright:all, but not with text-combine-upright: digits)

Either way, it is possible that the spec already defines this, but the text is tricky enough that I am not sure. My best bet is that Chrome is doing the right thing with text-combine-upright: all with ::first-letter but not <span>, and that Edge is doing the right thing for text-combine-upright: digits with ::first-letter but not <span>, but I am not sure.

If the specs are already defining this, rephrasing and/or more examples and/or more notes would be very welcome. If they're not, they should.

[kojiishi]

Learned initial-letter spec quickly, apologies in advance if I missed something obvious.

We should discuss initial-letter and ::first-letter separately. I understand it's often used together and thus you want to discuss together, but both technically and spec-wise, they look separate to me.

For initial-letter applying to the inline-level first child of a block container, I think the spec looks fine to me and, while Blink doesn't implement this property yet, I suppose it shouldn't be hard to make it to work.

The ::first-letter and text-combine-upright looks like an unfortunate combination. Since ::first-letter creates a pseudo element before layout runs, the tree should look like the below to the layout engine:

<p>
  <span style="text-combine-upright: all">
    <span style="initial-letter: 3">1</span>
    3
  </span>
  is a really nice number
</p>

I think how initial-letter and text-combine-upright should render this tree is clearly defined; it just does not work well for the use case.

I don't know how to solve this use case. One possible idea is to change initial-letter so that it determines the first letter in layout, not in style. Maybe people more familiar on pseudo elements and initial-letter can come up with better ideas?

[fantasai]

Agree with Koji that the way this works isn't ideal for the use cases. The ideal solution here really is #2: text-combine-upright changes the range of ::first-letter--but I'm not sure how implementable that is. Failing that, I think the specs currently imply that text-combine-upright would fail to combine (due to the element boundary), though it isn't 100% clear since in theory that boundary exists whether or not ::first-letter is styled. So at minimum we need to clarify that if ::first-letter isn't styled, it doesn't exist to interfere with text-combine-upright.

(Koji, initial-letter isn't the only property that applies to ::first-letter, so making it do some kind of selection magic the way text-combine-upright does wouldn't work.)

[fantasai]

Note that ::first-line does depend on layout, so it's not as if we don't have layout-dependent pseudo-elements. And text-combine-upright's effect can be determined even without doing layout, just requires analyzing both style and content. So it may be possible.

[kojiishi]

From the response, I think I didn't explain well enough, sorry. Let me try to rewrite my points:

• What spec defines looks clear to me, so this doesn't look like about spec missing definitions.
• We 1) compute styles, 2) build box tree, and 3) layout. ::first-letter creates a separate box in step 2, so we can't fix this use case by changing text-combine-upright.
• If we were to fix ::first-letter:
  • We have style computed at the point we build box tree, so it is technically possible for box tree building of ::first-letter to take text-combine-upright into account.
  • I don't know enough about other parts of the style engine. Changing ::first-letter that way will make it dependents on writing-mode and text-combine-upright. I need someone else more familiar with style systems to comment on its feasibility.
• If we were to fix initial-letter:
  • It looks technically possible, not sure which is easier.
  • Also not sure the change is worth if this change doesn't have other use cases. Any?
  • As fantasasi said, it doesn't fix other properties to apply to ::first-letter of text-combine-upright, if there were any use cases?
• Any other possible ways to go?

[frivoal]

If we were to fix ::first-letter:
We have style computed at the point we build box tree, so it is technically possible for box tree building of ::first-letter to take text-combine-upright into account.

This looks reasonable to me

Any other possible ways to go?

Maybe. I don't think it is a good, idea, but instead of having ::first-letter prevent text-combine-upright from working, we could have text-combine-upright prevent ::first-letter from working.
The spec currently says:

For other text layout purposes, e.g. emphasis marks, text-decoration, spacing, etc. the resulting composition is treated as a single glyph representing the Object Replacement Character U+FFFC.

Maybe we could try to extend that logic to earlier than layout, and since ::first-letter does not select U+FFFC, then in the presence of text-combine-upright affecting the beginning of an element, ::frst-letter would select nothing.

It's not obvious if this can happen at box creation time, but if we consider that the composition done by text-combine-upright is creating a box, then we can just have that box be created before we consider whether ::first-letter should.

That said, even if we can make this work, I still prefer your suggestion above.

[realskk]

I have a quick question:

p {
 writing-mode:vertical-rl;
  text-orientation: sideways;
  text-combine-upright: 2;
}
p::first-letter {
  initial-letter: 3;
 }
<p>"13" is a really nice number. Lorem Ipsum...</p>

I added double quotations around 13. In this situation, where these punctuations should be displayed?
The below two images are what I imagined.

[frivoal]

@realskk Not thinking form the spec, but from what's desirable, this is an interesting question. I am not sure why you think this is specific to initial letter though. Don't you have the exact same problem of quote orientation with regularly sized TCY?

Moreover, the initial letter probably means you cannot get either of the results you showed, since the initial letter has to be on the first inline-level child of the block container, and in your example, there is something before it: the quote. Initial letter can have quotes inside it, but not before it.

If we leave initial letter aside, and want to deal with automatic quote orientation, and presuming that you find the first example nicer, we'd have to deal with a codepoint based solution, since "" or “” or ‘’would want to be upright, but for 「」 or 『』 you would probably want the the vertical glyphs.

[kojiishi]

Looking at ::first-letter in css-pseudo-4, it looks like we already look at computed values, so I guess what we want are:

• Change ::first-letter to find the combined character when the first letter is part of text-combine-upright, either digits or all.
• Allow text-combine-upright as an allowed property to style ::first-letter.

Does this look correct?

/cc editors of css-pseudo-4: @fantasai @astearns @therealglazou

[kojiishi]

@realskk 's comment looks like a different issue, could you raise it separately?

[realskk]

@frivoal

I am not sure why you think this is specific to initial letter though. Don't you have the exact same problem of quote orientation with regularly sized TCY?

Ah, yes. My question applies to regular TCY situation also.
In addition, as you wrote, the adequate layout result might differ between "", '', ‘’, and 「」.

As @kojiishi wrote, I'll raise another issue.
My image depicts in the case of text-orientation: sideways; but, this might be applicable to regular vertical writing situation.

[fantasai]

This issue was closed, no change, by the CSSWG in Seattle. ::first-letter rules determine the extent of ::first-letter, this is clearly specified; furthermore text-combine-upright forbids combination across element boundaries, so the 13 cannot combine. If the author wants this effect, s/he needs to wrap the desired characters in markup and apply text-combine-upright: all.