SitePoint Sponsor

User Tag List

Results 1 to 25 of 26

Thread: OOP CSS?

Hybrid View

  1. #1
    SitePoint Enthusiast cluongo's Avatar
    Join Date
    Jun 2011
    Location
    Atlanta
    Posts
    71
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    OOP CSS?

    I heard some mumbo jumbo abut Object Oriented CSS, the idea sounded silly to me. Someone please give me at least 2 reasons as to why OOPCSS is a joke. If it is, because to me it seems worthless and uneeded.

    Why can't we just use CSS and be happy? It's simple enough. Whats the need with trying to over complicate everything. Seems like common best CSS practices are just fine, no need for "OOPCSS".

  2. #2
    It's all Geek to me silver trophybronze trophy
    ralph.m's Avatar
    Join Date
    Mar 2009
    Location
    Melbourne, AU
    Posts
    23,590
    Mentioned
    411 Post(s)
    Tagged
    6 Thread(s)
    Quote Originally Posted by cluongo View Post
    Why can't we just use CSS and be happy?
    You can! No one said you had to use it.

    There are some other threads on this, such as:
    http://www.sitepoint.com/forums/show...t-oriented-CSS

  3. #3
    SitePoint Mentor bronze trophy
    John_Betong's Avatar
    Join Date
    Aug 2005
    Location
    City of Angels
    Posts
    1,577
    Mentioned
    62 Post(s)
    Tagged
    3 Thread(s)
    @cluongo

    I heard some mumbo jumbo abut Object Oriented CSS, the idea sounded silly to me.
    Someone please give me at least 2 reasons as to why OOPCSS is a joke. If it is,
    because to me it seems worthless and uneeded.

    Why can't we just use CSS and be happy? It's simple enough. Whats the need with
    trying to over complicate everything. Seems like common best CSS practices are
    just fine, no need for "OOPCSS".
    Did you mean to say " at least 2 reasons as to why OOPCSS is NOT a joke"?

    I reckon that if your toolbox only consists of a hammer then only a single solution is available.

    http://www.slideshare.net/stubbornel...t-oriented-css

    There are quite a few usefult tips in the above link which I think applies to large projects.

    @noonnope - http://www.sitepoint.com/forums/show...-oriented-CSS]


    Where they go false in the statement that "OOCSS cuts code down" is when they
    don't say: "it is specifically for sites having a certain type of mark up
    repeating over and over". It will "cut" the code down for a specific type of
    sites. And it's not really cutting, it's structuring. One thing facebook didn't
    manage to do from the beginning. And they call the necessary correction
    "improvement": OOCSS. Yeah, right! facebook, we know you had crappy code to
    begin with, no reson to be ashamed now!
    What I do not like in a style sheet is duplication.

    A TLA class can reduce style-sheet size tremedously.

    PHP Code:

    .bgr {background-color:#f00}     .bgg  {background-color:#090}  .bgb  {background-color:#9ff}
    .fll {float:left}  .flr {float:right}
    .
    fs2 {font-size:2em}  .fs3   {font-size:3em}
    .
    fwb {font-weight:700
    .
    mga {margin:auto}
    .
    tdn {text-decorationnone}
    .
    w32 {width:32%} .w66 {width:66%}   .w88 {widh:88%}


    # Usage:
    <div class='w88 mga fs1'>

      <
    div class='fll w32 bgr fwb'>
         
    Red bold text
         
    <a href='#' class='tdn'a NOT underlined link</a>
      </
    div>

      <
    div class='fll w32 bgg fs2'>
          
    Green in larger text
      
    </div>

      <
    div class='fll w32 bgb'>
          
    Blue # corrected from a previous post
      
    </div>

     </
    div
    Last edited by John_Betong; Feb 8, 2012 at 23:04. Reason: not easy to spot errors when validator not available

  4. #4
    Non-Member bronze trophy
    Join Date
    Nov 2009
    Location
    Keene, NH
    Posts
    3,760
    Mentioned
    23 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by John_Betong View Post
    Did you mean to say " at least 2 reasons as to why OOPCSS is NOT a joke"?
    I don't think he did... though thank you for the STUNNING example of everything WRONG with the whole OOCSS approach pretty much proving that the folks who use it fail to grasp the point of HTML, most of the reasons to use CSS, and on the whole destroying ANY chance of having multiple page targets via the MEDIA attribute since, well... YOUR INLINING PRESENTATION IN THE MARKUP!!!

    I particularly enjoyed your use of vague/cryptic class names, and the nonsensical multi-classing which frankly at which point you might as well go back to using HTML 3.2 without CSS for all the 'improvement' in coding practices your example offers!

    Seriously:
    Code:
      <div class='fll w32 bgr fwb'>
    You might as well go back to using ALIGN, CENTER, and FONT for all the 'improvement' that gives you in your markup... and of course the uselessly vague classnames make the code SO easy to maintain.

    JUST like most of the CSS framework garbage, OOCSS relies on presentational use of classes -- basically saying what things looke like instead of what they are in the markup... It actively encourages just "slapping classes on everything" instead of leveraging inheritance and semantics -- which to borrow from Carlin, "Not every ejaculation deserves a name".

    ... and thank you for this too:
    Quote Originally Posted by John_Betong View Post
    A TLA class can reduce style-sheet size tremedously.
    As it shows the flaw in logic on which OOCSS seems to be based -- while certainly keeping the stylesheet size under control is important, MORE important is keeping the HTML size under control; something OOCSS fails to do with all the pointless PRESENTATIONAL classes in the HTML. WHY is that one of the entire reasons to use CSS?

    SIMPLE, CSS in an external sheet is cached across pages on a site; HTML is not. The more you can move out of the markup and into the CSS, the more you can pre-cache sub-page appearance, the faster sub-pages will load and the less bandwidth wasted should your site actually manage to do something more than be a 'one-hit wonder' in bouncyland.

    AND all those presentational classes do not translate AT ALL to media types, media queries... if you're only styling for desktop 'screen' it could work, but that's NOT the only thing you should be thinking of any time after 1998!!! (or before 1996 -- interesting that...)

    Which again, this is just another of those "new ideas" like the HTML 5 idiocy that seems more slated to set coding practices back a decade or more than to introduce ANY sort of better coding practice! I pity the nubes too green to realize what total trash it is -- which goes hand in hand with the "back end only" PHP coders who haven't learned enough HTML or CSS to be writing PHP in the first place, or the folks who are STILL basically writing HTML 3.2 and don't even realize it.

  5. #5
    padawan silver trophybronze trophy markbrown4's Avatar
    Join Date
    Jul 2006
    Location
    Victoria, Australia
    Posts
    4,095
    Mentioned
    28 Post(s)
    Tagged
    1 Thread(s)
    I've been thinking about this quite a lot recently.

    OOCSS
    I like OOCSS. When I first read the slides it made sense, make re-usable components with css, use multiple classes for variations.
    Another similar concept is Jonathon Snook's http://smacss.com/ which I haven't read yet.

    cluongo, flick through the slides or watch the video. If there's nothing in there you want to use, that's fine. It's not a joke though.

    CSS classes for Layout
    This is quite a different topic to OOCSS, where it overlaps is that both OOCS and layout frameworks encourage you to re-use code without having to write more CSS and to put more presentational classes into the HTML.

    I agree semantic markup is important, semantic class names are important too, you should definitely use <p class="info"> as opposed to <p class="yellow_info_bar_with_bold_text"></p>

    But, layout doesn't fit nicely into that category.
    I find layout is quite often closely tied to the content - often you change the layout to accommodate changes to the content.

    For most simple sites where there isn't a huge amount of variation between layouts you can get away without layout classes.
    As the site grows if you don't have some layout classes then your stylesheet will continue to grow with every slight variation - This is one of the major issues that OOCSS was trying to address.

    But it's not semantic!
    It makes no difference to the experience or accessibility of the final page. I've stopped caring about this.
    People have started hiding the fact that they are tying layout to content by using mixins which just copies floats / widths / gutters into the different selectors.
    There's no presentational classes in their HTML so they feel good about it, it's just that it's duplicated on mass throughout the CSS, and it's only a cover.

    Mixins will eventually be available in CSS, so duplication won't be an issue.

    Presentational classes mean that you can't change the design later on without changing the HTML
    That's true, but that's not a problem.

    With a serious re-design you're always going to be re-working the content & layout at the same time.
    I've never had the case where a full redesign didn't mean shuffling bits of HTML around.

    @John_Betong, I have a similar set of classes I stick with my reset, though I object to these three because they are strictly presentational and I can't think of good reasons for them.
    Code css:
    .bgr {background-color:#f00}     .bgg  {background-color:#090}  .bgb  {background-color:#9ff}
    .fwb {font-weight:700} 
    .tdn {text-decoration: none}
    But, to be honest there are cases where I make exceptions to the rule, for special feature buttons I do have classes like "blue-btn", "red-btn"

    Here are my utility classes
    Code css:
    .fr { float: right }
    .fl { float: left }
    .cl { clear: left }
    .cr { clear: right }
    .cb { clear: both }
    .ib { display: inline-block; vertical-align: top }
    .clearfix:after {
    	content: ".";
    	display: block;
    	height: 0;
    	clear: both;
    	visibility: hidden;
    }
    I have also used fluid grid's like this. *hold the torches and pitchforks*

    Code css:
    /* layout */
    .fluid > div { float: left }
    .fluid .quarter { width: 25% }
    .fluid .half { width: 50% }
    .fluid .third { width: 33% }
    .fluid .fourth { width: 25% }
    .fluid .fifth { width: 20% }
    .fluid .sixth { width: 16.5% }
    .fluid .two-thirds { width: 66% }
    .fluid .three-fourths { width: 75% }
    .fluid .two-fifths { width: 40% }
    .fluid .three-fifths { width: 60% }
    .fluid .four-fifths { width: 80% }
     
    .fluid .inner { padding-right: 20px }
    .fluid > div:last-child > .inner { padding-right: 0 }
     
    @media only screen and (max-width:480px) {
      /* linearize grids under 800px */
      .fluid > div { float: none !important; width: 100% !important }
      .fluid .inner { padding-right: 0 }
    }
    I'm interested in hearing others opinions on this, I think there's good reasons for layout classes.
    Especially when you use grids extensively.

  6. #6
    Non-Member bronze trophy
    Join Date
    Nov 2009
    Location
    Keene, NH
    Posts
    3,760
    Mentioned
    23 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by markbrown4 View Post
    I'm interested in hearing others opinions on this, I think there's good reasons for layout classes.
    Especially when you use grids extensively.
    In other words two things that BOTH defeat the point of using CSS in the first place. "layout classes" == presentational nonsense and a failure to grasp the POINT... you're "utility classes" basically being "how to forget about caching models and piss away all your bandwidth". "Grids" in their typical deployment relying on presentational classes forgetting that there's supposed to be more to a website than a "perfect width layout designed for just one media target".

    Your float/clear classes for example -- at which point you might as well go back to using the ALIGN and CLEAR attributes for all the 'improvement' it offers in the markup -- and don't even get me STARTED about that clearfix NONSENSE begging the question "what is this, 1998?"

    Literally, it's just another of the creations made for people who failed to grasp the entire POINT of HTML STRICT, the entire POINT of separation of presentation from content, and how "desktop screen" is NOT your only target! In other words, the folks who up until recently were vomiting up HTML 3.2 and slapping a tranny doctype on it -- today just toss a HTML 5 lip-service on top while still spewing the same outdated coding methodologies we were supposed to start moving away from almost a decade and a half ago!

  7. #7
    SitePoint Mentor bronze trophy
    John_Betong's Avatar
    Join Date
    Aug 2005
    Location
    City of Angels
    Posts
    1,577
    Mentioned
    62 Post(s)
    Tagged
    3 Thread(s)
    @deathshadow60

    Many thanks for the constructive criticism.

    Can you supply a page-link concerning good HTML and CSS practice - preferably one that you have written.

  8. #8
    Non-Member bronze trophy
    Join Date
    Nov 2009
    Location
    Keene, NH
    Posts
    3,760
    Mentioned
    23 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by John_Betong View Post
    Can you supply a page-link concerning good HTML and CSS practice - preferably one that you have written.
    I used to have a few good ones written by Dan Schulz, but with his passing they've gone off into la-la land. Most of my good stuff was forum posts (back read a few of my 'helping' others here in the CSS area -- some of them are close to full blown tutorials).

    Wait... There's this... it's a rough draft of a tutorial co-written by Dan for a website we were going to launch -- said site has languished unfinished since his passing. He was the idea guy and the one who kept projects on track; I was the technical and standards guy...

    It's a very rough draft thrown into a quicky layout, it's also three or four years out of date on content (like referencing Ian's starter book, which with 3rd edition gushing all over itself with HTML 5 like some creepy German shaiza video... not so much) and not all the links are working, but it's a starting point for insights into where I'm coming from with my approaches.

    http://www.cutcodedown.com/preview/

    The entire idea for the finished product being to show how to make the markup, THEN the layout, THEN hang the goofy graphics on it... taking this:
    http://www.cutcodedown.com/preview/l.../template.html

    plugging in content semantically:
    http://www.cutcodedown.com/preview/l.../template.html

    applying the layout with CSS:
    http://www.cutcodedown.com/preview/l.../template.html

    and then the chapter that never got written, hanging the graphics on it, throwing in some min-width, etc...
    http://www.cutcodedown.com/preview/l.../template.html

    Unfortunately with everyone just pissing out websites any old way and having ZERO interest in doing anything better, the PSD jockeys pissing all over the Internet as a whole, the Javascripttards blowing hundreds of K of javascript on little more than goofy half-assed animations, my disgust with the industry as a whole has not only made me abandon most of my Internet projects due to being sick of feeling like Don Quixote, it's made the entire Internet less useful as a tool for me than it was a decade ago.

    ... which combined with not having Dan keeping my energy up on the topic, is probably why I'm dialing back my involvement in just about everything modern and going back to my retrocomputing hobby instead... Back when there was at least SOME pride in one's code.

    If I were to finish it and update it for today, I'd probably have it use CSS3 for much of the effects handled using images, give example code for using media queries for multiple targets, add massive warnings about the complete idiotic BS that is HTML 5, probably have to add a beginner tutorial since there's currently no "on shelf" sources that are worth a flying purple fish, get rid of the LI that Dan talked me into wrapping the articles with (since IMHO the moment you have a heading it's no longer a list item), etc, etc...

  9. #9
    padawan silver trophybronze trophy markbrown4's Avatar
    Join Date
    Jul 2006
    Location
    Victoria, Australia
    Posts
    4,095
    Mentioned
    28 Post(s)
    Tagged
    1 Thread(s)
    I've tried to explain that if layout is important to you, and you like grids..
    Neither visual design or layout is important to you, so I don't expect to convince you to stop duplicating your css.

    ds, have you ever added a div, span, class or id to your HTML?
    None of those have any semantic meaning whatsover, if you've done that then you've littered your pristine HTML with meaningless garbage only intended for presentation.

    The web is primarily a visual medium,
    To 99% of your users, what the see is what they get.

    The visual representation of the site is paramount, I agree semantic markup and good class names are important too.
    You seem to be more concerned with HTML that satisfies you, as opposed to HTML that satisfies those you're creating content for.

  10. #10
    SitePoint Guru
    Join Date
    Nov 2003
    Location
    Huntsville AL
    Posts
    663
    Mentioned
    3 Post(s)
    Tagged
    0 Thread(s)
    @deathshadow60

    Many thanks for the constructive criticism.

    Can you supply a page-link concerning good HTML and CSS practice - preferably one that you have written.
    Quote Originally Posted by deathshadow60 View Post
    I used to have a few good ones written by Dan Schulz...Most of my good stuff was forum posts...a rough draft of a tutorial co-written by Dan...made me abandon most of my Internet projects...going back to my retrocomputing hobby instead...etc, etc...
    So that would be a no?

  11. #11
    SitePoint Member
    Join Date
    Feb 2012
    Posts
    1
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I don't think so that OOPCSS is necessary to use you can surely implement the CSS and do whatever you are trying to do. The results will be the same and the browser compatibility will be surely easily resolve through using simple CSS.

  12. #12
    om nom nom nom Stomme poes's Avatar
    Join Date
    Aug 2007
    Location
    Netherlands
    Posts
    10,233
    Mentioned
    47 Post(s)
    Tagged
    1 Thread(s)
    I think it sounds like a joke because "object-oriented" refers to actual programming languages (which CSS is not) who have objects (which CSS does not).

    That aside, I think Mark's and John's comments pretty much answer well why anyone is using "OOCSS" despite the above sentence. The idea of reusing code and modularity sounds sensible to many developers, probably especially those who are doing both programming on the back end *and* CSS on the front end.

  13. #13
    padawan silver trophybronze trophy markbrown4's Avatar
    Join Date
    Jul 2006
    Location
    Victoria, Australia
    Posts
    4,095
    Mentioned
    28 Post(s)
    Tagged
    1 Thread(s)
    you're "utility classes" basically being "how to forget about caching models and piss away all your bandwidth"
    I find it turns out to be the same or less HTML most of the time.
    A common layout is a container with something on the left, something on the right. *This is just an example.
    Code css:
    <div class="header">
      <span class="sign-in">
        <a href="#">Sign in</a>
        <a href="#">Create an account</a>
      </span>
      <img src="img/logo.png">
    </div>
    I might use something like this instead.
    Code css:
    <div class="header">
      <span class="fr">
        <a href="#">Sign in</a>
        <a href="#">Create an account</a>
      </span>
      <img src="img/logo.png">
    </div>
    Your float/clear classes for example -- at which point you might as well go back to using the ALIGN and CLEAR attributes for all the 'improvement' it offers in the markup -- and don't even get me STARTED about that clearfix NONSENSE begging the question "what is this, 1998?"
    There are some cases where the clearfix is preferable to overflow:hidden.
    Adding a class is much easier than coding the correct clearfix by hand each time - and less bytes, this is why it's popular.
    Literally, it's just another of the creations made for people who failed to grasp the entire POINT of HTML STRICT, the entire POINT of separation of presentation from content, and how "desktop screen" is NOT your only target!
    No, I understand separation of concerns.
    I've tried to explain that if layout is important to you, and you like grids, then you have two options - use layout classes, or a heap of custom CSS and re-invention for each page.

    Your criticisms are minor and haven't convinced me to do more unnecessary work for myself.

  14. #14
    Non-Member bronze trophy
    Join Date
    Nov 2009
    Location
    Keene, NH
    Posts
    3,760
    Mentioned
    23 Post(s)
    Tagged
    0 Thread(s)

    Arrow

    Quote Originally Posted by markbrown4 View Post
    I find it turns out to be the same or less HTML most of the time.
    A common layout is a container with something on the left, something on the right. *This is just an example.
    While I'd be wondering what it needs the span for; as I'd move the image first, float it left and text-align the anchors right... then you only need a class on the outermost container...

    NOT that semantically "sign in create an account" as one run-on makes ANY sense since inline-level tags, even anchors, do not change the meaning of the text in flow; so literally you've got a run-on sentence... NOT that a logo likely even BELONGS in the HTML... and that outer DIV is probably unnecessary too... I smell a H1, image sandbag span, and a UL there.

    Code:
    <h1>
      Site Title
      <span><!-- image sandbag --></span>
    </h1>
    <ul class="userMenu">
      <li><a href="#">Sign in</a></li>
      <li><a href="#">Create an account</a></li>
    </ul>
    Guess it comes down to how you'd go about coding things in the first place. My gut reaction to the markup of your examples is "Too many meaningless containers" and "Not enough semantic meaning"... probably also depends on how you write your markup -- thinking "screen layout" before you even have semantic markup, as opposed to making semantic markup and THEN creating the layout -- I lean towards the latter as IMHO the former is putting the cart before the horse.

    But there's a reason I can write 90-95% of my markup before I've laid down a single line of CSS...

    Hell, even with what you have for code, you've got a perfectly good outer ID and only one span inside it -- what does the span even need a class FOR either way of doing it?!? Again, like Carlin said about abortion, not every ejaculation deserves a name... so not every tag that's getting style applied should have a class thrown at it for nothing. That's the same thing as wordpress' idiotic "menu-item" class or where you see people do this nonsense all the time:

    Code:
    <div class="nav">
    	<ul class="navUl">
    		<li class="navLI"><a class="navA" title="Home">Home</a></li>
    		<li class="navLI"><a class="navA" title="Forums">Forums</a></li>
    		<li class="navLI"><a class="navA" title="Links">Links</a></li>
    		<li class="navLI"><a class="navA" title="Contact Us">Contact Us</a></li>
    	</ul>
    </div>
    Which if you don't know what's wrong with that, you probably shouldn't be writing HTML in the first place (yes wordpress developers, I'm looking at YOU!)

  15. #15
    SitePoint Member
    Join Date
    Jan 2012
    Posts
    4
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    As with any object-based coding method, the purpose of OOCSS is to encourage code reuse and, ultimately, faster and more efficient stylesheets that are easier to add to and maintain.

  16. #16
    om nom nom nom Stomme poes's Avatar
    Join Date
    Aug 2007
    Location
    Netherlands
    Posts
    10,233
    Mentioned
    47 Post(s)
    Tagged
    1 Thread(s)
    As with any object-based coding method
    CSS does not have objects though
    and it's code, but it's not programming (getting closer and closer, but still not yet)

  17. #17
    Non-Member bronze trophy
    Join Date
    Nov 2009
    Location
    Keene, NH
    Posts
    3,760
    Mentioned
    23 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by urdumania2011 View Post
    As with any object-based coding method, the purpose of OOCSS is to encourage code reuse and, ultimately, faster and more efficient stylesheets that are easier to add to and maintain.
    As SP said though, CSS doesn't have objects, it may MANIPULATE objects by declaring properties FOR the DOM (Document Object Model) -- but to even call this bloated nonsense "object oriented" is bullcookies. If anything it is the OPPOSITE of Object Oriented, since you're NOT using the DOM's inheritance and instead are inlining the properties on every element. If anything, this is PROCEDURAL CSS!

    You have a DOM element, you give it a way to hook to it or use it's inheritance, you declare properties for it with inheritance by type -- that's object oriented -- taking a HTML element and slapping classes for each property on it -- that's not object oriented AT ALL. The exact opposite in fact!!! It's almost like they threw the "object oriented" name on it to make it sound neat and trendy, instead of actually taking the time to think "what in blazes does this have to do with OOP?!?"

    It's certainly not faster since it results in more classes to be processed -- it's certainly not easier to maintain since you're basically putting all your presentation back in the markup, defeating the entire point of even using CSS (and to an extent HTML) in the first place, and does NOT allow code re-use for the HTML since you declared your presentation in it. (meaning if you suddenly want to reskin you basically have to rewrite ALL the markup).

    While I dislike their base code and most of their examples, see CSS Zen Garden for an example of what I'm talking about; you aren't gonna do that with OOCSS -- one markup for many layouts... Done by saying WHAT your content is, and then in the stylesheet saying what they look like -- Separation of presentation from content -- aka LETTING HTML AND CSS DO THE JOB THEY WERE DESIGNED FOR!

    So... "faster and more efficient"? Not so much. The exact opposite in fact. IF you're declaring presentation (and no, a div sandbag or wrapper doesn't declare presentation, even if it's used for it) in your markup, you've failed to grasp the concepts behind semantic markup, separation of presentation from content, and the entire POINT of HTML and CSS.

  18. #18
    Non-Member bronze trophy
    Join Date
    Nov 2009
    Location
    Keene, NH
    Posts
    3,760
    Mentioned
    23 Post(s)
    Tagged
    0 Thread(s)
    Wow, the more I think about this, the more I'm laughing at it... it's NOT object oriented, it's the EXACT opposite. No inheritance, no polymorphism, not actually leveraging the ACTUAL object model that's present for CSS to work on...

    That's a riot.

  19. #19
    padawan silver trophybronze trophy markbrown4's Avatar
    Join Date
    Jul 2006
    Location
    Victoria, Australia
    Posts
    4,095
    Mentioned
    28 Post(s)
    Tagged
    1 Thread(s)
    That's a riot.
    I'm glad you're having a good time
    It's certainly not faster since it results in more classes to be processed
    You're kidding right? You're arguing that we shouldn't use multiple classes because of client-side performance?
    It's certainly not easier to maintain since you're basically putting all your presentation back in the markup, defeating the entire point of even using CSS (and to an extent HTML) in the first place, and does NOT allow code re-use for the HTML since you declared your presentation in it. (meaning if you suddenly want to reskin you basically have to rewrite ALL the markup).
    You have missed the point.
    OOCSS is about re-using CSS, 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.

    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. It's not putting all of the presentation in the HTML, only what makes sense to re-use as components. Structure & skin are kept separate.
    While I dislike their base code and most of their examples, see CSS Zen Garden for an example of what I'm talking about; you aren't gonna do that with OOCSS -- one markup for many layouts... Done by saying WHAT your content is, and then in the stylesheet saying what they look like -- Separation of presentation from content -- aka LETTING HTML AND CSS DO THE JOB THEY WERE DESIGNED FOR!
    Sure you can. You can re-style each component without effecting everything else so you have a far greater level of control over the output.
    Layout frameworks are a different story but we've already been there, I think grid layout being tied to the page level & content is ok.

    It's also not helpful to think of the page as a whole in these examples, OOCSS is for small re-usable components, not major elements like navigation, aside content etc..
    So... "faster and more efficient"? Not so much. The exact opposite in fact. IF you're declaring presentation (and no, a div sandbag or wrapper doesn't declare presentation, even if it's used for it) in your markup, you've failed to grasp the concepts behind semantic markup, separation of presentation from content, and the entire POINT of HTML and CSS.
    We may have failed to grasp your point of HTML & CSS, but I use it to deliver content to users.
    I want to be able to do that without rewriting stuff all over the place or duplicating effort, multiple classes work well.

  20. #20
    Non-Member bronze trophy
    Join Date
    Nov 2009
    Location
    Keene, NH
    Posts
    3,760
    Mentioned
    23 Post(s)
    Tagged
    0 Thread(s)
    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...


Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •