I didn't realize before that you were looking at the field in the table.

I can actually replicate the bahavior you listed when I try it in a table.

There does appear to be a difference in how the table is rendered in the Layout screen versus how it is rendered in the running form (Preview).

This screenshot is from the running form (Preview) - you can see that a single line field has the q-id (q1 in this screenshot) as the id attribute assigned to a div element, and that a child/decendant below that is the label element, so the CSS works here.

And in the Layout view, on the table, you can see it also has a label element, and there is a reference to the q-id (q3 in this screenhot) as a "data-col" attribute on a div element a couple levels above the label.

But when we view the label from the table in the running form (Preview), we find that it is it's structured differently.  For one thing, it isn't a label element but rather a th element.  Additionally, I don't see the q-id (q3 in this example) listed anywhere linking that label back to the specific field.  I searched for the q-id in the inspector and only found it mentioned in my CSS and in the field itself, no where on the label.

I would argue this is a bug and not an intended behavior - and hopefully someone from Laserfiche will be able to verify and report back on a bug id if applicable.

The downside is, I don't think you are going to be able to make this work for specific field labels, because the th element in the table doesn't reference back to the specific field.  If you are okay with every label in the table having the CSS applied, you can do this: 

.table-header-cell {color: red!important;}

Thank you for looking into this and finding root cause to the issue. 

I don't think I am going to be able to get this to work either because my client would prefer only this field label to be red. 

Also - Thank you for the tip for /* before and after when I don't want to use code for testing. 

I am using 11.0.2212.30987