This looks a nicely put together guide on creating HTML and CSS , with lots of explanatory notes, and all on a single, well laid out page. I can see plenty of places in what I’m working on at the moment that would benefit for the practices suggested.
Does anyone have any thought on what it offers?
Overall it’s trying to give off opinions as rules, but I went through the whole document and it’s pretty solid. I disagree with some readability comments he makes, along with how to format values (e.g. leave off 0 in 0.5).
There is one point I disagree on
Avoid using several attribute selectors (e.g., [class^=“…”]) on commonly occuring components. Browser performance is known to be impacted by these.
I sincerely doubt you are building an application large enough for this browser performance to matter at all. I’d ignore this unless you are going for a monster application where you NEED to focus on this.
Other than these minor things, I read it all and I agree with everything he says. A few things are opinion based and aren’t technically OFFICIALLY labeled as best practice but I do follow the practices he suggests, and if you were to want to standardize your CSS and everything, I’d go with that document. Great find!
I doubt I’ll use everything in there, as all I’m doing right now is re-skinning my blog. Given how the CSS I started with looks though, there’s plenty to take away from this for me, and I may as well get into reasonable shape whilst it doesn’t matter so much. Aside from anything else, it should make things so much more readable when I come back to it next time.
This is the sort of thing I’d like to find in the Versioning newsletter @Ophelie @Jasmine ???
I still don’t buy into this “use spaces instead of tabs”. Space-formatted code is a PITA.
Code doesn’t have to render the same way in every environment – indentation is a semantic construct, not a visual one – and formatting code in such a way that its rendering matters, is introducing visual information into a semantic layer.
IMHO the only time strict adherence to any particular coding convention is needed is if the code is not solely for your own use.
i.e. when contributing to a project or working with a team, then it can be important.
Yup, can’t argue with that.
The problems arise when you need to mix indentation with alignment. A couple examples of alignment from this topic’s guide:
.selector {
-webkit-box-shadow: 0 1px 2px rgba(0,0,0,.15);
box-shadow: 0 1px 2px rgba(0,0,0,.15);
}
.icon { background-position: 0 0; }
.icon-home { background-position: 0 -20px; }
.icon-account { background-position: 0 -40px; }
If you’re using tabs, then you need to be extremely diligent about how you mix tabs and spaces. Even the best programmers will screw this up from time to time. Plus, our editors will sometimes fight us and automatically convert groups of 4 spaces into a tab character, not knowing those were alignment spaces.
Tabs sound good in theory, but in practice they go wrong too easily and end up doing more harm than good.
I used to do tabs - did it religiously. However the extra space caused by tabbing would alwyas cause display issues. Ultimately it doesn’t matter if you keep the same environment, etc, but overall I just had more issues with tabs.
For example, one issue I had is that if I edit files online live, whether on test or development, the online editor doesn’t accept tabs as a character. It’ll tab onto different links/buttons and the only way I can get tabs in is if I copy/paste the character.
Dunno - just a hassle.
Did you have to search far to find that bad example? 
To be fair, that’s quite old code, from before I’d really considered any of this. It fails because I’d assumed a fixed tab size (of 4 characters), whereas your rendering of it is 8 characters. Now perhaps I could argue that, enforcing indentation with a fixed number of spaces is no different than enforcing indentation with a fixed tab-size. But that’s by the by 
These days, I tend to go for tabs for indentation and spaces for alignment, but sure, it is almost impossible to do that consistently without making mistakes (I suppose you could set your code editor to make all whitespace visible, but I find that just too distracting).
So I can totally see the arguments for using spaces.
I just can’t get over the inconvenience – it takes more keypresses; editor shortcuts for things like indenting a selected block work with tabs; auto-indentation after newline works with tabs. Tabs are just way more convenient and easy to work with.
If only there were some middle-ground, some best of both worlds.
Yeah, that can be annoying.
(Though my response is just not to use online editors – they’re never as good as proper code editors anyway. If I have to use one, I’ll write the code in my own editor and then paste the whole thing into the online editor.)
Unfortunately my environment is kinda sh**. I have a chromebook which means I can’t use any good editors on here. I don’t really use any good editors anyway. I used Notepad up until 8ish months ago (only switched to convince a job I was “normal”.) So a plain online editor is fine by me.
It’s not even the online editing that soley led me to my decision. I also would indent tab i nmy HTML and when you get really nested structures it would get to the point where 3/4 the way across my monitor would be an opening tab. Just horrible to look at. 2 spaces just made it easy.
As far as it being an extra key, it never bothered me with that. I generally need a half second to think about what comes next in my structure so I sorta am programmed to enter → space → space and then usually the thought will come to me. I don’t really think I could use that extra space as an argument in my personal judgement as to which to go for…
I’m not sure which editor you’re working with, but every widely used editor I can think of can use spaces just as conveniently. Press tab once and you get 4 spaces (or however many you decide you want). Press shift tab, and it removes 4 spaces (in some editors, a single backspace works too). Select several lines and press tab, and they all indent 4 spaces. Shift tab removes. Auto-indentation works too.
You didn’t think we were always pressing space-space-space-space, did you?
Yeah I suppose I did. I’d never seriously considered it before, because I’d never had reason to change the way I code. I’ve just become increasingly aware of the number of style guides that recommend using spaces, hence the conversation
I kinda like more breathing room personally 
Even if I did switch to using spaces, I’d still want it to be groups of 4 – 2 never seems like enough space, makes everything look crowded.
Which is part of the reason why I also prefer this:
selector
{
... rules ...
}
Even thought style guides always say this:
selector {
... rules ...
}
@Adam runs Versioning (confusing I know) but we’re streamlining the process you can alert him to news.
Same. He advocates the other since it’s the norm but I just have OCD - I need brackets to line up.
Yeah exactly – every brace is at the same level of indentation as its pair, so it’s easy to see where the pairs are (and it looks neater 
)
Yeah this is great, thanks Chris, I’ll add it to the next newsletter fo’ sho’.
And yep, I do the Versioning stuff, so if you see similarly great stuff, feel free to ping me here, email me (adam at sitepoint dot com) or find me on some other social media platform. As Jasmine says, soon it’ll be easier to send stuff through for the newsletter, but those options will obviously still apply too.
Thanks!
This topic was automatically closed 91 days after the last reply. New replies are no longer allowed.