Capitalizing first letter in string with ::first-letter. bug? - html

Question

I stumbled across this weird behaviour recently while trying to find a generic front-end way of capitalizing the first letter in a string. Normally, i would just call it quits, but i kept on trying to find a solution. However, that's when i came across this strange behaviour.
snippet:
.capitalizeWord::first-letter {
text-transform: uppercase;
}
<!-- example 1 -->
<p class="capitalizeWord">
<span>
<i></i>
test1></span>hello
</p>
<!-- example 2 -->
<p class="capitalizeWord">
<span style="float:left;"> <!--float causes it to work -->
<i></i>
test2></span>hello
</p>
According to caniuse ::first-letter chrome is supporting this.
So, my first question is: What is causing this behaviour? This has been "somewhat" answered in the comments
My initial thought was that the compiler interpreted the <i>-tags as chars. But no, the issue is still prevalent when they're removed.
Can anyone else verify that they are experiencing the same results?
Posting image for reference if your browser isn't seeing what mine is:
Anyhow, my second question: Is there a frontend way to accomplish the result of test2 but with test1's structure?
Off-topic but still relevant to answer my first question. See below
Update:
After some discussion in the comments, the problem has been narrowed down to be about the <i>-tag after all.
However, I would still classify this as a bug. Here's why:
An empty <i></i> should not trigger ::first-letter. Like, that should be self-evident by just looking at the name of the selector.
Why is ::first-letter triggered by a non letter character (an EMPTY html-tag in this case), and then stops looking within that scope when nothing has been found in the EMPTY tags, which isn't where the root-elements (p/div) scope ends... Like, whyyyyyyyyyy?
I can break the entire selector by just doing:
.box::first-letter {
text-transform: uppercase;
}
<div class="box">
some text
<!-- wooohoo, works! -->
</div>
<div class="box">
<i></i>some text
<!-- doesn't work now... I broke it, without adding ANY characters/letters to the dom -->
</div>
<span class="box">
some text
<!-- doesn't work now... I broke it again, just changed to a span-tag -->
</span>
<span class="box" style="display:block;">
some text
<!-- wooohoo, works! -->
</span>
Maybe this is me being stubborn, but, i really hate this approach they've taken with this selector. It really could have been used as "the way to go" for capitalizing strings on the web, instead of all these javascript workarounds has had to be created in its place.

Answer 1

You are asking two specific distinct questions, so I will answer them both.
my question is: what is causing this behaviour?
To answer your question: When you float the element, it is taken out of the document flow and no longer counts as part of the content of the block in regards to pseudoelement selectors. From the CSS visual formatting spec:
An element is called out of flow if it is floated, absolutely positioned, or is the root element.
Visual formatting model - W3
So in accordance with the spec, we can see the exact same result if we take the element out of the flow by using a different method, e.g. absolute positioning:
.capitalizeWord::first-letter {
text-transform: uppercase;
}
<!-- example 1 -->
<p class="capitalizeWord">
<span>
<i></i>
test1></span>hello
</p>
<!-- example 2 -->
<p class="capitalizeWord">
<span style="float:left;"> <!-- float causes it to work -->
<i></i>
test2></span>hello
</p>
<!-- example 3 -->
<p class="capitalizeWord">
<span style="position: absolute; left: 50px"> <!-- absolute positioning causes it to work -->
<i></i>
test3></span>hello
</p>
is there a frontend way to accomplish the result of test2 but with test1's structure?
As far as I know there is no way to do this in pure CSS, because you would necessarily need to take the offending element out of the flow to get the selector to find the desired pseudoelement. And by taking the element out of the flow, your elements would no longer have the same visual hierarchy.
I would still classify this as a bug
The behavior follows the spec, so it is not a bug. You might argue that it's a poor design choice.