Style vs. id & class

Discussion in 'CSS' started by Xarwin, Nov 19, 2014.

  1. #1
    Hello,

    I have been working quite a lot with css and css3 over the past few years.
    I'm doing it for fun but also for designing the website of my gaming community.

    I was always wondering about this and I always got different answers about it.
    The question is: when you use for example <div style="padding:5;"></div> or you use
    <div id="test"></div> with a predefined css, does it matter and how would it matter?

    It would be some good information for me so any response and discussion is appreciated :).
     
    Xarwin, Nov 19, 2014 IP
  2. kk5st

    kk5st Prominent Member

    Messages:
    3,497
    Likes Received:
    376
    Best Answers:
    29
    Trophy Points:
    335
    #2
    For starters, this,
    <div style="padding:5;"></div>
    Code (markup):
    is a poor practice. Its appearance in the html source is indicative of the coder not understanding the meaning and use of the cascade, nor its purpose; that of separating the structure (html) from its presentation (css) using contextual style hooks.

    If you put your style inline with the html, to edit it requires that you change its every instance throughout the site; belying the very purpose of having css. In a word, it's stupid.

    The alternative is not simply id=foo. It's about choosing the appropriate selector based on the context. For that, you'll need to study the various selectors and their uses.

    cheers,

    gary
     
    kk5st, Nov 19, 2014 IP
    COBOLdinosaur likes this.
  3. COBOLdinosaur

    COBOLdinosaur Active Member

    Messages:
    515
    Likes Received:
    123
    Best Answers:
    11
    Trophy Points:
    95
    #3
    Here are three problems with putting style inline.
    • It is less efficient for both the html parser and the css parser
    • It is far more difficult to and more error prone to maintain.
    • It puts it at the most narrow level specificity and binds content to presentation.

    So professionals generally avoid doing inline styling because it makes the work less profitable and reduces the cash available for beer.
     
    COBOLdinosaur, Nov 20, 2014 IP
  4. deathshadow

    deathshadow Acclaimed Member

    Messages:
    9,732
    Likes Received:
    1,999
    Best Answers:
    253
    Trophy Points:
    515
    #4
    While some good points have been raised, one of the basic reasons to even have separation of presentation from content is being missed here... what about OTHER media targets other than "the screen you happen to be sitting in front of" -- are you SO sure you want that 5px being sent to print? Does it even make sense to waste time sending it to targets like "aural" or even non-visual user-agents like screen readers or search engines? What about when you make the site responsive with media queries? If you're just going to override it why is it even in the markup.

    It's already been mentioned that using CSS you can have the style in one spot to hit the whole site consistently -- but what about caching? If you use the same appearance on another page you've pre-cached it's appearance! If the visitor revisits the same page before their cache has flushed, they already have the appearance loaded resulting in faster page loads.

    Saying what things look like in the markup is STUPID. It's why IMHO the STYLE tag should be stricken from the specification, and that as an attribute it should be deprecated for all but the handful of corner cases where it's actually useful to convey meaning -- like width or height on a bar graph.

    Gary has it right it's not JUST about throwing ID's and classes in to replace it either; what is the element? Do you already have unique semantic tags and common wrappers so that you can use less classes and ID's and instead actually use the "cascading" part of CSS via selectors and inheritance?

    I extend the practice of not saying what things look like to my classes and ID's... class="red" or class="floatLeft" is just as mind-numbingly mouth-breathingly stupid; hence why garbage dumbass "frameworks" with their uselessly presentational classes like "col12" defeats the entire reason to even be using CSS in the first place.

    Basically, if you are saying what things look like in your markup, you're doing it all wrong; as I've said a hundred times or more, "If you are chosing your HTML tags and attributes based on their default appearance, you're choosing all the wrong tags for all the wrong reasons". What things look like has NO MALFING BUSINESS in your markup. That's not what HTML is or ever was intended to be for; no matter how far away from that original (and brilliant) intent we were dragged during the browser wars of a over a decade and a half ago.

    WHY are you putting padding on it? WHAT is it you are grouping together with that DIV? Do you even actually NEED that DIV? If the DIV is grouping elements for style can a class on it be used to target it's children efficiently?

    Sadly those are all questions a LOT of people sleazing out markup any-old-way fail to even ask; and their code is complete and utter bloated trash because of it.

    Even something simple like bold text people don't ask "why am I making this bold?" -- which should be the foremost question asked.

    Is it a heading / start of a new subsection of the page? If so that's <h1>..<h6>'s job.

    Is it the title of a book? That's <b>'s job! The semantic meaning of B being "would be bold in professional writing as in a proper title"

    Are you just trying to make some flow text stand out for emphasis? That's what <strong> is for -- since the semantic meaning of strong is "More emphasis" (while <em> means just plain "emphasis")

    If you actually use the semantic tags in logical order for what they are for, you quite often don't need to throw "classes at everything" ... and all that is why style="font-weight:bold;" in the markup is halfwit nonsense that you really shouldn't be doing.

    See every time you come across dumbass code like this:
    <div id="mainMenu">
    	<ul id="mainMenuUl">
    		<li class="mainMenuLi">
    			<a href="/" class="menuButton">Home</a>
    		</li>
    		<li class="mainMenuLi">
    			<a href="/forums" class="menuButton">Forums</a>
    		</li>
    		<li class="mainMenuLi">
    			<a href="/links" class="menuButton">Links</a>
    		</li>
    		<li class="mainMenuLi">
    			<a href="/faq" class="menuButton">FAQ</a>
    		</li>
    	</ul>
    </div>
    Code (markup):
    What's wrong with that you ask? If ever like tag (or even the majority of them) are getting the same class inside a parent container, NONE of them need classes... There isn't a blasted thing you can do to a DIV you can't do to a UL, so in the majority of usage scenarios there is NO reason to have a DIV around that UL. (unless you had sibling elements to the UL you wanted to target). This is why I also consider HTML 5's "NAV" to be a pointless redundancy

    There is no reason for the above in the majority of usage scenarios to be anything more than:

    <ul id="mainMenu">
    	<li><a href="/">Home</a></li>
    	<li><a href="/forums">Forums</a></li>
    	<li><a href="/links">Links</a></li>
    	<li><a href="/faq">FAQ</a></li>
    </ul>
    Code (markup):
    Other than developer ignorance and / or ineptitude -- Seriously:

    ORIGINAL       | REWRITE
    -------------------------------
    #mainMenu      | Removed as pointless, style the bloody UL
    #mainMenuUL    | #mainMenu
    .mainMenuLI    | #mainMenu li
    .menuButton    | #mainMenu a
    Code (markup):
    Which is why you don't need to be throwing class="" and id="" at everything -- though try convincing the drooling morons who vomit up templates for turdpress of that.
     
    Last edited: Nov 20, 2014
    deathshadow, Nov 20, 2014 IP
  5. Naina S

    Naina S Active Member

    Messages:
    203
    Likes Received:
    7
    Best Answers:
    1
    Trophy Points:
    93
    #5
    Inline styles are poor coding standards avoid them because-
    1. Bad and confusing code.
    2. Search engines do not like them.
     
    Naina S, Nov 27, 2014 IP