Shoot to kill; CSS selector intent

来源:互联网 发布:留学机构 知乎 编辑:程序博客网 时间:2024/05/23 21:11

One type of CSS in particular makes me cringe every time I see it; poor selector intent. Poor selector intent means carpet bombed selectors whose key selector has way too broad a reach; a selector like.header ul{} as opposed to one like .main-nav{}; .widget h2{} instead of .widget-title; article > p:first-child{} as opposed to.intro{}. Selectors whose intent isn’t specific enough.

It’s worth noting that selector intent is something I completely made up at some point today; if you think there’s a better name then please let me know!

Let’s take a closer look at the .header ul{} example. Let’s imagine thatul is indeed the main navigation for our website. It lives in the header, as you might expect, and is currently the onlyul in there; .header ul{} is fine, right? Not really. I mean sure, it might work, but it’s not very good. It’s not very future proof and certainly not explicit enough. As soon as we add anotherul to that header it will adopt the styling of our main nav and the the chances are we won’t want it to. This means we either have to refactor a lot of codeor undo a lot of styling on subsequent uls in that .header to remove the effects of the far reaching selector.

Your selector’s intent must match that of your reason for styling something; ask yourself‘am I selecting this because it’s a ul inside of .header or because it is my site’s main nav?’. The answer to this question will determine your selector.

It’s all about the key selector…

What determines the impact of a selector is its key selector. The key selector is a very important thing in the world of CSS asbrowsers read selectors right to left. This means the key selector is the last one before the opening{, for example:

.header ul      { /* ‘ul’ is the key selector */ }.ul li a        { /* ‘a’ is the key selector */ }p:last-child    { /* ‘:last-child’ is the key selector */ }

As I discuss in Writing efficient CSS selectors, the key selector plays a big part in CSS efficiency, so it’s worth bearing that in mind, but whereselector intent is concerned this is basically the place you need to be looking to see how far reaching your selector is.html > body > section.content > article span{} is a ridiculously convoluted and terrible selector that no one anywhere would ever write (right?) but despite how specific and disastrously over the top it is, its key selector (span) is still very, very broad. It doesn’t matter so much what comes before your key selector, it’s only the key that really matters.

As a general rule you should try and avoid any key selector that is a type selector (basically an element, likeul or span or whatever) or a base object (e.g. .nav or.media). Just because something is the only .media object in your content area it doesn’t mean it always will be.

Let’s keep looking at the .header ul{} example. Let’s assume our markup is thus, as we’re usingthe nav abstraction:

<div class=header>    <ul class=nav>        [links]    </ul></div>

We could select this in one of several ways:

.header ul{    [main nav styles]}

This is bad because as soon as we add any other ul to our header it will look like our main nav. This is dangerous but thankfully easily avoidable.

Secondly we could use:

.header .nav{    [main nav styles]}

This is marginally better than the .header ul example, but barely so. We can now safely add anotherul without risk, but we can’t add anything else with a .nav class; that means adding sub-navs or breadcrumbs will be a nightmare!

Finally, our best solution would be to add a second class to the ul; a class of.main-nav:

<div class=header>    <ul class="nav main-nav">        [links]    </ul></div>.main-nav{    [main nav styles]}

This is good selector intent; we are selecting this element now for exactly the right reasons, not coincidental/circumstantial ones. Now we can add as many moreuls and .navs to that .header and the scope of our main nav styles will never reach anything else. We’re no longer carpet bombing!

Keep your key selector as explicit and specific as you possibly can, preferring for it to be a class over anything else. Applying specific styling through a vague selector is dangerous. A generic selector should always carry generic styling and if you want to target something in particular you should perhaps add a class to it. Specific intent requires a specific selector.

Real-life example

A really good example of where I messed up on this myself is on a project I did at Sky; I had a selector which was simply#content table{}. (Eww, I even used an ID!!!) This is a troublesome selector for three reasons; firstlyit uses an ID which is a big no, secondly it has a lot higher specificity than it needs to and lastly—and most importantly—it has a poor selector intent. I wasn’t wanting to style these tablesbecause they were in #content, that was just how the DOM landed so that’s how I chose to target them.Entirely my bad.

For the first few weeks this was fine but then all of a sudden we needed to add some tables inside#content that didn’t want to look anything like the previous ones. Uh oh. My previous selector was far too far reaching, I was now having to undo a blanket style I’d set onevery table in the #content div. If I’d had a better selector intent then instead of:

#content table{    [foo styles]}#content .bar{    [undoing foo styles]    [bar styles]}

I should/would have had:

.foo{    [foo styles]}.bar{    [bar styles]}

And a lot less headaches. By thinking ahead and having a lot more considered selector intent then I would have had a much easier time…

Exceptions

Of course there are always exceptions. It’s perfectly reasonable to have selectors like.main-nav > li where your key selector is a type selector. It also makes perfect sense to target everya inside something like this:

html{    color:#333;    background-color:#fff;}/* Inverted colour scheme for promotional items. */.promo{    color:#fff;    background-color:#333;}    .promo a{        color:#fff;        text-decoration:underline;    }

That is a reasonably sensible far-reaching selector where it does make sense to style everya in a pretty carpet bombed manner.

Final word

In general, instead of carpet bombing your elements, shoot to kill; target them specifically and explicitly. Make sure your selector intent is accurate and targeted.

Think more carefully about why you want to target something and pick a more explicit and sensible selector; refine your selector intent. Do you mean:

.header em{}

or do you really mean:

.tagline{}

Do you want:

.footer p{}

or do you really want:

.copyright{}

Is it wise to select:

.sidebar form{}

or would a safer bet be:

.search-form{}

Consider your CSS selectors’ intent; are you being specific enough? Are your selectors matching things for the right reasons, or is it just happy circumstance? Shoot to kill. Be a CSS sniper, not a CSS carpet bomber.

Incidentally, opting to switch out a longer selector like .header ul for something like.main-nav will also help reduce specificity and increase selector efficiency; win-win-win!

It is also worth noting that Jonathan Snook wrote something similar called the depth of applicability

参考文章

0 0
原创粉丝点击
热门问题 老师的惩罚 人脸识别 我在镇武司摸鱼那些年 重生之率土为王 我在大康的咸鱼生活 盘龙之生命进化 天生仙种 凡人之先天五行 春回大明朝 姑娘不必设防,我是瞎子 电脑开机变慢了怎么办 怎么办抚顺韦德健身卡 预售健身卡合法吗怎么办 被浓硫酸泼到怎么办 婴儿误喝了生水怎么办 宝宝喝了生水拉肚子怎么办 因妈妈喝生水宝宝拉肚子怎么办 喝了几口生水怎么办 不小心吃到蟑螂怎么办 吃了有蛆的樱桃怎么办 不小心误食了蛆怎么办 吃了有蟑螂的汤怎么办 调节天平时指针向右怎么办 香薰蜡烛融化了怎么办 香薰蜡烛挂壁怎么办y 粗蜡烛只烧中间怎么办 紫薯馒头变绿怎么办 小孩手开水烫了怎么办 被油烫伤了怎么办才不留疤 烫伤水泡蹭破了怎么办 烧伤的水泡破了怎么办 烧伤后水泡破了怎么办 烫伤泡破了红肿怎么办 烧伤第二天水泡破了怎么办? 烧伤后换药特别疼怎么办 盐酸溅到皮肤上怎么办 磷性磷酸酶高440怎么办 浓硫酸沾到皮肤上怎么办 浓硫酸溅到皮肤上怎么办 浓硫酸滴到皮肤上怎么办 浓硫酸洒在皮肤上怎么办 浓硫酸溅到眼睛里怎么办 盐酸弄到眼睛了怎么办 稀硫酸进眼睛里怎么办 草酸弄到皮肤上怎么办 大理石被盐酸烧发白怎么办 香薰蜡烛化了怎么办 吸入了大量燃烧纸气体怎么办 狗链条上锈了怎么办 思维迟钝反应慢嘴笨怎么办 小孩思维慢反应迟钝怎么办