csswizardry

6 ms·

121.
by csswizardry 14y ago
Also guys—anyone reading this who’s signed up—if you have any non-tech Twitter friends you might want to invite that’d be awesome! A quick glance over the site should tell you that the majority of users so far are web-dev types and we’d rea
122.
by csswizardry 14y ago
Thanks! That’s a great question, we need to ponder that because faavorites do take up a lot of space because of all the other data they carry. Perhaps a toggle between all open and all closed…?
123.
by csswizardry 14y ago
Thank you! > a little Marketing brushup and you'll go a long way This is where we’re struggling at the moment; we’re just a couple of devs on a hobbyist app right now. The next ‘sprint’ we’re hoping to dedicate to marketing and ideas an
124.
Show HN: We made an app for managing your Twitter favorites(faavorite.com)
24 points by csswizardry 14y ago|16 comments
125.
by csswizardry 15y ago
If you change any code it will show up in a diff, whether that be vendor prefixed or not. A vendor prefix changing is just the same as a padding value changing; if code needs to change then change it and you will fully expect to see it show
126.
by csswizardry 15y ago
I do agree, I think the wording was a little unclear. By and large these are better practices than we’re used to, but the title (and README) did say these were best practices compiled for me and Sky; not everyone will agree with them but
127.
My CSS guidelines didn’t sit too well with some… here’s a rebuttal(csswizardry.com)
11 points by csswizardry 15y ago|3 comments
128.
by csswizardry 15y ago
I wrote a rebuttal http://csswizardry.com/2012/03/hacker-news-rebuttal/
129.
by csswizardry 15y ago
I’ve honestly never heard of that being advocated; I’d drop that ASAP if I were you. If you want to ensure there is no page jump as images load then simply give the images width and height attributes :) H
130.
by csswizardry 15y ago
Points 2, 3 and 4 are irrelevant here. Do not use IDs in CSS. Use them in markup and JS and tests, sure, just not in CSS. Point 1: The speed difference between a class and an ID is so, so slight that it's almost non-existent. The specificit
131.
by csswizardry 15y ago
> Then it's possibly appropriate. It's definitely appropriate. > This again makes presumptions about what kind of site you're building. It doesn't matter whether you're building Facebook or the site for the window cleaner two doors
132.
by csswizardry 15y ago
I see your point. This started off as a personal/close-knit reference for me and my teams’ best practices. Then I thought I might as well share it, even if only one other person finds it useful then that’s better than keeping it to myself.
133.
by csswizardry 15y ago
Catch all response: This document is a personal one, and for use at my place of work. I decided to share it in the hope that it might be useful to others but if you disagree with anything please remember; this is a document for me and Sky.
134.
by csswizardry 15y ago
Because `.nav li a{}` is overly specific; that’s my whole point. EDIT Hold on, I think I get you… My example was an example of someone writing something incorrectly. An example of it being written correctly would indeed be: .nav{
135.
by csswizardry 15y ago
For me it is purely habit. I think: to each their own, just aim for consistency :)
136.
by csswizardry 15y ago
> that made my teeth itch Fair enough; any reason as to why? > not all vendor css3 definitions have the same structure, so this can't be a standard Well if it can’t be done then it can’t be done…
137.
by csswizardry 15y ago
Thanks for the comment, I’m glad you like it :) The shorthand one is a really interesting one; it takes while to kick the habit and be purposely more verbose, but you soon get tired of undoing previously accidentally-set styles. > Do yo
138.
by csswizardry 15y ago
> Not if .nav li a{} and .nav a{} are specifically meant to be differing nests. But in the example they aren’t differing nests; if you change your example then obviously it isn’t correct any more.
139.
by csswizardry 15y ago
> Please don't label things that can be discussed as 'best practices'. This is valid point, however In the README there is the line ‘This document is a personal one, and for use at my place of work […] this is a document for me and Sky.
140.
by csswizardry 15y ago
No reason other than that is what I started off with and I’d rather keep things consistent. Had I started off with underscores then I’d be asking the team to stick with that. I guess that section is more about ‘keep everything the same’ rat
141.
Show HN: I decided to document and share my high-level CSS best practices(github.com)
223 points by csswizardry 15y ago|86 comments
142.
by csswizardry 15y ago
> but I feel that classes give more meaning to an element But they don't. Classes (and IDs) have nothing at all to do with semantics or meaning. You can use whichever notation you wish (.big, .small, .alpha, .giga etc), I state as much
143.
by csswizardry 15y ago
Classes are neither semantic or insemantic, merely sensible or insensible. Realising that classes aren't subject to the same semantics as elements is a massive breakthrough for a front-end developer to make IMO. These classes aren't 'semant
144.
Pragmatic, practical font sizing in CSS(csswizardry.com)
19 points by csswizardry 15y ago|5 comments
145.
Measuring and sizing UIs, 2011-style(csswizardry.com)
1 points by csswizardry 15y ago|0 comments
146.
by csswizardry 15y ago
Ah cool, my good buddy Nick made this!
147.
Pure CSS *fluid* content slider(dl.dropbox.com)
2 points by csswizardry 15y ago|0 comments
148.
by csswizardry 15y ago
@csswizardry ;) But thanks for the link, much appreciated :D http://news.ycombinator.com/item?id=3203834
149.
by csswizardry 15y ago
Thanks :D
150.
Namespacing fragment identifiers(csswizardry.com)
1 points by csswizardry 15y ago|0 comments

More ›