Better to apply two styles, or a :not() pseudoclass?

[csdude55]

I have a style like this:

.foo,
#bar,
[onClick] { cursor: pointer }

Applying it to the [onClick] attribute works 99.9% of the time, but there's one instance where I have a <div onClick="blah()"> and I do NOT want it to change the cursor.

I can think of two ways to do this:

.foo,
#bar,
[onClick] { cursor: pointer }

.textCursor { cursor: text }

<div class="textCursor" onClick="blah()"></div>

Or:

.foo,
#bar,
[onClick] *:not(.textCursor) { cursor: pointer }

<div class="textCursor" onClick="blah()"></div>

Is there a reason to NOT use the :not() pseudoclass? I know that IE11 doesn't support it, but that's becoming irrelevant now. Are there any other things to consider, like speed or performance?

[tangor]

If IE11 is your consideration, ignore that. Use whatever works for your users!

[robzilla]

Simpler tends to perform better, but in this case you won't notice the difference. Personally I'd just define the textCursor class.

[csdude55]

Both seem to work the same, yeah. I keep reading that pseudoclasses have poor performance, but then I realize that I have other pseudos in my CSS file (like :hover, :before, :after, and :focus). Does having another one in the file make a difference, or is it one of those things where, if I've used one then I might as well use 50?

Using :not() is 11 bytes smaller, too, which means that the CSS file loads marginally faster. Is that enough to offset whatever the performance hit is? I don't know, and I really don't know how to bench test CSS performance.

[robzilla]

11 bytes, come on.

Does having another one in the file make a difference, or is it one of those things where, if I've used one then I might as well use 50?

One can be more expensive than 50, and vice versa, depending on what they apply to in the DOM. Either way you'd have to go pretty crazy to notice the difference. We're generally talking submillisecond here.

Performance of CSS Selectors Is Still Irrelevant [meiert.com]

[ronin]

I'm a fan of maintaining rigour when it comes to CSS specificity, so that the matter of which rule wins is not only obvious to the CSS algorithm, but obvious to humans reading the CSS file too.

For this reason, I'd go for something close (but not identical) to your first option:

.foo,
#bar,
[onClick] { cursor: pointer }

[onClick].textCursor { cursor: text }

It should be clear to any human reader of the above (and human readers includes yourself in six months time) that an element with the attribute onClick should display the cursor as a pointer, but an element with the attribute onClick AND the class textCursor should display the cursor as a text-cursor.

[Marshall]

Is there a reason to NOT use the :not() pseudoclass?

Is there a reason to not use the standard cursor action?

[csdude55]

@Marshall, the <div onClick="blah()"></div> wouldn't change the cursor even though it's intended to be clicked, so I changed it to the pointer.

But then I came across this one instance where there's an onClick surrounding a contenteditable (which I use to close ajax scripts when they focus on the textarea), but I don't want the pointer over the whole textarea so I needed that one to be excluded.

@robzilla, I know you laugh at my mere 11 bytes, but I've spent some time shaving bytes here and there and increased my load time by about 500ms! So while 11 bytes alone is mostly insignificant, it adds up.

But I'm mainly asking these questions for my own long term education; eg, whether I should rely more on pseudoclasses, and at what point the increase in file size offsets any performance loss from them.

[robzilla]

@robzilla, I know you laugh at my mere 11 bytes, but I've spent some time shaving bytes here and there and increased my load time by about 500ms!

That seems counterproductive ;-) I'm not saying you shouldn't shave, but you'd need about a hundred 11 byte shavings to get to a kilobyte, and a hell of a lot more to shave off 500ms. That's some very high hanging fruit.

But I'm mainly asking these questions for my own long term education; eg, whether I should rely more on pseudoclasses, and at what point the increase in file size offsets any performance loss from them.

We can't answer that, too many variables. You'd have to test it yourself.

[tangor]

There comes a time when chasing fractions of milliseconds could better be invested in chasing milliclicks with better campaigns.