Quote Originally Posted by markbrown4 View Post
I'm glad you're having a good time

You're kidding right? You're arguing that we shouldn't use multiple classes because of client-side performance?
and server side performance since it's more to output, and bandwidth performance because it generally will use more bandwidth by saying classes on things that shouldn't even NEED classes if you bother with semantics and inheritance...

Quote Originally Posted by markbrown4 View Post
You have missed the point.
OOCSS is about re-using CSS
Where CSS is about re-using style on markup WITHOUT saying it over and over again -- AGAIN, "re-using CSS" in this manner is the EXACT same thing as forgettting CSS entirely and just using ALIGN, FONT, CENTER and all the other [b]deprecated[/]b nonsense... it's the CSS equivalent of the "let's use javascript to make a TARGET workalike because TARGET is deprecated" idiocy... bypassing WHY TARGET is deprecated outside FRAMESET doctypes. Again, see why I think STYLE should be obsoleted as a tag and throw a warning as an attribute... and to be frank, if you're going to do this OOCSS garbage, you might as well not bother with a stylesheet and just use the style attribute on everything -- since from a functionality standpoint it's the same thing.

Quote Originally Posted by markbrown4 View Post
that is where maintenance headaches lie in larger apps (and small apps), the HTML can always be updated in one place as each component has a server-side wrapper.
As opposed to not having to even THINK about going into the markup or the server side code and JUST edit the CSS? Sorry, that's MORE work, not less. It REEKS of the philosophy of those who still pop up HTML 3.2 and slap 4 trannies or 5 lip-services on it.

Quote Originally Posted by markbrown4 View Post
I agree object oriented is a stupid name but the objects they are referring to are the structural components - these are what the classes represent.
When the classes only implement two properties on the DOM... when the classes in the markup are specific to certain appearance or layout elements... when the classes by their very nature ONLY server the purpose of specific presentational effects -- uhm... NO. That's not what they represent.

Quote Originally Posted by markbrown4 View Post
It's not putting all of the presentation in the HTML, only what makes sense to re-use as components.
Putting ANY presentation there, with the rarest exceptions (like when the size actually represents data -- charts or tag clouds for example) defeats the point of why HTML was created, the reason STRICT was implemented and we've been supposed to be using it, and needlessly bloats and over-complicates the page.

Quote Originally Posted by markbrown4 View Post
Structure & skin are kept separate.
If you're talking layout for structure, then it shouldn't be separate -- if you're talking logical document structure, you're putting layout in it so it's not separate...

Quote Originally Posted by markbrown4 View Post
It's also not helpful to think of the page as a whole in these examples
Which makes the examples pointless, come up with better examples... if not thinking about the page as a whole, one probably shouldn't be writing for the web.

Quote Originally Posted by markbrown4 View Post
OOCSS is for small re-usable components, not major elements like navigation, aside content etc..
IF so then how does your grid example weigh into that since it's being used for the entire layout? Also, small reusable components, particularly if re-used on the same page, would benefit more from semantic markup with single wrappers to say what it is than the "lets slap classes on EVERYTHING" idiocy.

Off Topic:

<aside>Also, "aside content" ??? -- how often do you have real asides? <em>Not too often I'd guess</em>... but of course people seem to think "<i>aside</i>" means a sidebar now -- <strong>having little to do the meaning of the word</strong> or what it's supposed to be for in <b>HTML 5</b>... Always good for a laugh. Almost as laughable as the people who think B and I are deprecated or means the same thing as EM and STRONG...</aside>


Quote Originally Posted by markbrown4 View Post
We may have failed to grasp your point of HTML & CSS
How about TBL's point? How about the entire REASON STRICT undid all the crapping all over the specification 3.2 did? Of course with HTML 5 taking a massive dump on it all over again...

Quote Originally Posted by markbrown4 View Post
I want to be able to do that without rewriting stuff all over the place or duplicating effort, multiple classes work well.
Funny since the techniques you've been defending are all about rewriting stuff "all over the place" by basically turning back the clock to presentational markup -- instead of saying once in the markup what it is (either with a single wrapper and then , then using inheritance to say once for many elements what it looks like in the CSS.

But again, about 80%+ of the markup out there I look at and go "why do you need this div, this div, this span, this tag, ANY of these classes... you've got a perfectly good ID why does EVERYTHING have a class on it when you have semantic tags..." -- needlessly complex, convoluted and ultimately MORE work to deal with. Even the simplest of pages I'll see DIV wrapping IMG for no reason, multiple classes for no reason... and encouraging people to slap even MORE classes on everything is NOT the answer.

I think that's a lot of what our difference in opinion comes down to here -- you're concerned more about CSS redundancies than HTML ones.... when CSS is cached making it's redundancies less of an issue.... where in CSS you can group selectors that get the same set of base properties WITHOUT bloating out the markup...

I often do think people who complain about 'redundancies' in their CSS are unaware of how to use multiple selectors...

I mean seriously, take a simple 100% width header/footer 100% min-height, constrained width content layout...

Code:
<div id="pageWrapper">

	<div id="headerWrapper"><div id="header">
		<h1>Test</h1>
		<ul id="mainMenu">
			<li>Dummy</li>
		</ul>
	</div></div>

	<div id="content">
		<h2>Test Content</h2>
		<p>Some Content</p>
	</div>

</div>

<div id="footerWrapper"><div id="footer">
	Footer Content 
</div></div>
Code:
#pageWrapper {
	min-height:100%;
}

#headerWrapper,
#footerWrapper {
	clear:both;
	overflow:hidden; /* wrap floats */
	width:100%; /* trip haslayout, wrap floats IE */
	color:#FFF;
	background:#00F;
}

#footerWrapper {
	height:72px;
	margin-top:-72px;
}

#header,
#content,
#footer {
	min-width:752px;
	max-width:68em;
	width:95%;
	margin:0 auto;
}
Is somehow inferior or harder to work with than:

Code:
<div class="minHeight">

	<div class="wrapping darkbackground">
		<div class="constrainWidth centered">
			<h1 class="big red">Test</h1>
			<ul class="menu centered">
				<li class="menuItem">Dummy</li>
			</ul>
		</div>
	</div>

	<div class="constrainWidth centered">
		<h2 class="big red">Test Content</h2>
		<p class="padLeftMore">Some Content</p>
	</div>

</div>

<div class="wrapping darkbackground clearing rideUpFooter">
	<div class="constrainWidth centered">
		Footer Content 
	</div>
</div>
Code:
.fullMinHeight {
	min-height:100%;
}

.wrapping {
	overflow:hidden; /* wrap floats */
	width:100%; /* trip haslayout, wrap floats IE */
}

.darkBackground {
	color:#FFF;
	background:#00F;
}

.clearing {
	clear:both;
}

.constrainWidth {
	min-width:752px;
	max-width:68em;
	width:95%;
}

.centered {
	margin:0 auto;
}

.rideUpFooter {
	height:72px;
	margin-top:-72px;
}
Since that's BASICALLY the difference we're talking about in OOCSS vs. Non. In non, I suddenly want to change #contents behavior I just override it in the cascade, or I move #content out of the width declaration area -- I want to do that the OOCSS way, I'm digging into BOTH the CSS and the HTML, for no reason.

Apart from throwing multiple classes at things that probably either just need one or none, what's even the POINT?

Then take something simple -- like say you wanted rounded bottoms on #header and rounded tops on #footer -- the non--OOCSS way you go ok,

#header { border-radius: 0 0 1em 1em; }
#footer { border-radius:1em 1em 0 0; }

While your OOCSStards would make new classes for each border type, and go into the markup and add it instead of just leveraging the already present and easy to use ID... and if that's not the dumbest thing you've ever heard...