VALID Order for CSS Elements?

That'd be the difference, I can pick up where each starts so I don't have a problem.

I find this harder, for the same reason.

Just bugs me, it's not as "tight". Personal preference

 

I was just looking at some CSS code of a company I wanted to know more about. They have a few front-end coders. I noticed I could not make heads or tails of one writer:

#great-big .long .list-of #elements [tabs] {longlineofunendingpropertiesbutgenerallylimitedtofourpropertiesorso;}
#great-big .long .list-of #elements .again [tabs] {longlineofunendingpropertiesbutgenerallylimitedtofourpropertiesorso;}
#great-big .long .list-of #elements .again>and>again [tabs] {longlineofunendingpropertiesbutgenerallylimitedtofourpropertiesorso;}

while another coder writes more like
#element {
styles;
}
and he grouped his stuff more like me— not the property orders, but the elements and when they get their declarations, and no very long chains of geneaology either.

So, if I were to work with that group, I'd spend about 4 times as much time editing the first coder's code than the second. Since all of us who can't quickly scan aphabetically would have it slow-going to edit, it's no different than anyone else's preferences as far as how easy it is for J Random Coder to make changes. Some of us can scan easier by box properties and more important things first, even if others can use alphabetically. Someone somewhere is going to get slowed down.
Do not pass Go, do not collect $200, do not cure cancer.

 

... or you spend 60 seconds using an automated css formatter to get it whatever way tickles your fancy, and another 60 seconds to convert it back when you're done.

 

Except when you have to go back in and add things, you can't just add to the end of the list.

 

There is no real official way to organize them, just whatever makes it easiest to sort through when you have to edit the stylesheet. I use comments a lot in my stylesheets and when I am defining the styles for elements, I organize them alphabetically.

Example:

/* Page Elements */
#page {
background: #fff url('image/imagetitle.jpg') no-repeat;
color: #000;
font: 1.2em 'Trebuchet MS', Arial, Verdana, Tahoma;
margin: 0;
padding: 0;

Code (markup):

If you notice, background (b), color (c), font (f), margin (m), padding (p). If you sing your alphabet like you were taught in grade school you will notice that b, c, f, m and p are all in order alphabetically.

 

Instead of clicking at the end you click in the middle somewhere wherever it should go, still just a click away.

 

Yeah, I don't arrange alphabetically and I also don't just add things on at the end. Some people do though and it's one of the reasons we're taught to always add that last ; even though the last declaration technically doesn't need it.

Unfortunately I have to sing the song for every element, excepting those right at the beginning (a, b, c) and those at the very end (x, y, z). f, m, and p in your examples would waste too much of my time trying to set them in the right order. I can't just sit here singing the alphabet song! My colleagues would know for sure what they've always suspected— that I have serious issues. : )

 

Ah, but clicking at the end requires no cognition, add up the seconds that you spend alphabetizing your code and you've wasted a bunch of time, and time is money.

 

Well, now, writing CSS should always require at least a bit of thinking. : ) And thinking, darn it, takes time.

 

And looking to see where abouts it goes (doing in in any other pattern) takes the same amount of time. We're talking maybe 2 seconds a click, around 50 clicks tops - nothing compared to the time it takes to slice, code, test. Heck, if we're starting to worry about 2 minutes, I should invoice them for the time it takes me to make an invoice.

 

In most cases, I saw there's no order for CSS. But when I wrote a page http://www.pagecolumn.com/webparts/rounded_corners.htm
I found the order of CSS had influence on the round corner display. Upto now, I don't know why. See the difference of the codes.

 

unigogo - I'm not sure where/what on your code changing the order would change for the layout... can you be more specific? I see you reversed the orders on the bottom ones but that should have zero effect on your elements rendering different.

Oh, and you might want to check out my approach to that problem:
http://battletech.hopto.org/html_tutorials/rounded_css_borders/

since it uses a heck of a lot less markup. see, you can nest your elements and therein get rid of 8 of your ten classes. (Using B instead of DIV not only saves bandwidth, it prevents the nested's from wordwrapping)

Oh, and even with the overflow:hidden it's still coming up too large in IE 7/earlier since you forgot to specify font-size:1px; - and you may wish to look up bresenham's circle. for a faster way to not only calculate a circle, but generally it returns the corrections you were hand applying. (with rare exceptions) - reason being it calculates the circle using nothing but integers.

-- edit --

Oh wait, I see it, you have a 1px gap in there... so small I didn't even notice it.... and here's your culprit:

border-left:1px solid #999;
border-right:1px solid #999;
border-width: 2px

Code (markup):

in the first example vs.

border-width: 2px;
border-left:1px solid #999;
border-right:1px solid #999;

Code (markup):

border-width is going to get overridden in the first place by the specificity of the targeteds, so no, that shouldn't work. NOT that either of those is how that should be declared since you have a wasted extra statement! Much less that your 2px declaration SHOULD be declaring 2px the whole way around the element, not just left and right, and all you WANT to declare there is left and right, so that should be either:

border-left:2px solid #999;
border-right:2px solid #999;

Code (markup):

OR

border:solid #999;
border-width:0 2px;

Code (markup):

So you aren't adding unwanted top/bottom borders to it. (I'm trying to figure out why you aren't having spacing issues because of that, I suspect it's the overflow)

Though my approach to what you have there is a bit different...

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html
	xmlns="http://www.w3.org/1999/xhtml"
	lang="en"
	xml:lang="en"
><head>

<meta
	http-equiv="Content-Type"
	content="text/html; charset=iso-8859-1"
/>

<title>
	Rounded Corners
</title>

<style type='text/css'>
* {
	margin:0;
	padding:0;
}

body {
	padding:16px;
	font:normal 85%/140% arial,helvetica,sans-serif;
}

.rounded_border {
	float:left;
	position:relative;
	height:1%; /* trip haslayout */
	overflow:hidden;
}

.rounded_border .content {
	padding:0 5px;
	border:solid #999;
	border-width:0 1px;	
}

.rounded_border .top,
.rounded_border .bottom,
.rounded_border .top b,
.rounded_border .bottom b {
	display:block;
	font:normal 1px/1px sans-serif;
	position:relative;
	/* 
		without a background color due to our layering method 
		the border of the nested elements s shows through
	*/
	background:#FFF; 
	border:0 solid #999;
}

.rounded_border .top,
.rounded_border .bottom {
	margin:0 5px;
	height:4px;
}

.rounded_border .top {
	border-width:1px 0 0;
}

.rounded_border .bottom {
	border-width:0 0 1px;
}

.rounded_border .top b,
.rounded_border .bottom b {
	margin:0 -2px;
	border-width:0 2px;
	height:3px;
}

.rounded_border .top b {
	padding-top:1px;
}

.rounded_border .bottom b {
	padding-bottom:1px;
}

.rounded_border .top b b,
.rounded_border .bottom b b {
	margin:0 -3px;
	border-width:0 1px;
	height:2px;
}

.rounded_border .top b b b,
.rounded_border .bottom b b b {
	margin:0 -2px;
	height:1px;
}



</style>

</head><body>

<div class="rounded_border">
	<b class="top"><b><b><b></b></b></b></b>
	<div class="content">
	
		5 px radius of round corner
		
	<!-- .content --></div> 
	<b class="bottom"><b><b><b></b></b></b></b>
<!-- .rounded_border --></div>

</body></html>

Code (markup):

 

I like to expand on my OCD and cascade them downward, here is an example here.

 

1) What's up with the caps.

2)

A:VISITED	{COLOR:#AAA}
A:ACTIVE	{COLOR:#AAA}
A:LINK		{COLOR:#AAA}
A:HOVER		{COLOR:#FFF}

Code (markup):

Never waste time declaring child or psuedo's that can inherit off the parent element, and both active/focus should probably be the same as hover for keyboard navigators.

a {
	color:#AAA;
}
a:hover {
	color:#FFF;
}

Code (markup):

Functionally identical, though it should probably be:

a {
	color:#AAA;
}

a:active,
a:focus,
a:hover {
	color:#FFF;
}

Code (markup):

Condensing your properties might help too, especially when it comes to making redundant declarations. What do I mean by redundant?

FONT-FAMILY:COURIER NEW;
	FONT:10PX VERDANA;

Code (markup):

The second declaration overrrides the first, so the first one shouldn't even be there. You also fail to declare a fallback font and default-family - and a bit of advice, never trust the default line-height since gecko is a retard on that, and you really shouldn't be declaring your default fonts in PX.

	font:normal 85%/140% Verdana,helvetica,sans-serif;

Code (markup):

Same goes for your background, and really fixed positioning is a bad idea... It also doesn't help that the background is repeating on the Y making the layout look broken on displays taller than your background-image (like mine). There is also no good reason to EVER declare "./", and you don't need the quotes around it either.

	background:#FFF url(background.gif) 0 0 repeat-x;

Code (markup):

Is probably what you should have there. (that #FFF should be the same color as whatever the bottom of your image ended up)

Some consistancy might be nice too, since you are expanding properties after body, but not on the elements above it?

Not that the HR declaration is all that great either since some browsers are going to ignore that styling since the default appearance of HR is inconsistant cross-browser.

border:solid #9DA5B0;
border-width:1px 0 0;


Just saying...

 

really, so thinking about what order all the border elements are alphabetically takes as long as just putting it at the end or beginning?

 

You still don't get it. We're talking about patterns and logic to arrange and organise tidy, well-thought out CSS (no matter which method is used as long as it meets those criteria); you're talking about $2 "me do html/css good" gibberish.

You've:
a) Not even read what I said and spoken completely out of context
b) Missed the point entirely

I feel for whoever has to tidy up your work, rubbish everywhere (try and palm it off as CSS if you want, we both know its nothing more than gibberish when it looks like a tornado has ripped through the page) because you're slapping things left, right and center with NO order or logic to it. This thread is about the total opposite of what you're on about.