SitePoint Sponsor

User Tag List

Results 1 to 10 of 10
  1. #1
    I solve practical problems. bronze trophy
    Michael Morris's Avatar
    Join Date
    Jan 2008
    Location
    Knoxville TN
    Posts
    2,053
    Mentioned
    66 Post(s)
    Tagged
    0 Thread(s)

    Conventions You Use in Your Markup

    Curious about what conventions folk use out there and figured I'd share one that I use that helps me.

    I call this the capital convention. The rule is, if javascript cares - capitalize. If not, do not. Hence classes and id's that exist solely for CSS styling start with a lowercase letter - and classes and id's that have javascript code against them are capitalized.

    I still style against the classes and id's javascript cares about - the goal here isn't to try to segregate the two but rather create a visual awareness so that the design team (and myself) knows at a glance what id's and classes can be changed without repercussions in the javascript code.

    Illustrative example:

    HTML Code:
    <div class="inputRow Toggles ECheck">
    	<div class="inputCell">
    		<label>Payment By (Name)</label>
    		{$receiptentry_form.ec_info_name.html}
    	</div>
    </div>
    <div class="inputRow Toggles Card">
    	<div class="inputCell">
    		<label>Payment By (Name)</label>
    		{$receiptentry_form.cc_info_name.html}
    	</div>
    </div>	
    <div class="inputRow">
    	<div class="inputCell">
    		<label>Processing Fee</label>
    		<input type="text">
    	</div>
    </div>	
    In the css I don't have any rules for Toggles or ECheck. Basically, depending on the mode of payment the Toggles fields may be visible or invisible. The two classes let javascript rapidly find the fields in question. A designer looking at this knows that Toggles and ECheck "belong" to the programmer and styling on them probably isn't advisable (at least in this case).

    What else in this vein is out there?

  2. #2
    billycundiff{float:left;} silver trophybronze trophy RyanReese's Avatar
    Join Date
    Oct 2008
    Location
    Whiteford, Maryland, United States
    Posts
    13,746
    Mentioned
    11 Post(s)
    Tagged
    0 Thread(s)
    If you're talking about naming schemes I try to keep mine the same. I try not to use camelCase just because it's so easy to screw up. That's just a personal opinion. If I ever need to use a two worded class or ID then I'll seperate it via a dash or something.

    I use the same naming scheme for Javascript too just to keep things normal.
    Always looking for web design/development work.
    http://www.CodeFundamentals.com

  3. #3
    SitePoint Wizard Stomme poes's Avatar
    Join Date
    Aug 2007
    Location
    Netherlands
    Posts
    10,283
    Mentioned
    51 Post(s)
    Tagged
    2 Thread(s)
    If I ever need to use a two worded class or ID then I'll seperate it via a dash or something.
    Did Opera ever fix that issue it had with - in class names?

    I avoid - both for Opera (though it may have been fixed, haven't checked the old hack relying on - in a while) and for Javascript.

  4. #4
    I solve practical problems. bronze trophy
    Michael Morris's Avatar
    Join Date
    Jan 2008
    Location
    Knoxville TN
    Posts
    2,053
    Mentioned
    66 Post(s)
    Tagged
    0 Thread(s)
    Opera fixed that a long time ago, back on version 8 or so IIRC.

    Personally I don't use - or _ but use camel case but that's a personal taste thing. It's like the open vs closed mark up.

    Before I used the capitalization rule I briefly tried using a leading _ to mark the javascript critical classes and ID's -- but IE 6 didn't like that too much.

    Here's another convention - I indent any 'sub' declarations. Example

    Code:
    #header {
    }
        #header a {
        
        }
            #header a:visited {
    
            }
    Also curious to know which is more popular among css users - open braces

    Code:
    #header
    {
       property: ;
    }
    Vs. the closed system, which I used in the first example and is the one I prefer.

    @Ryan - So yeah, naming schemes are part of it, but also formatting conventions are part of the thread subject.

  5. #5
    SitePoint Wizard Stomme poes's Avatar
    Join Date
    Aug 2007
    Location
    Netherlands
    Posts
    10,283
    Mentioned
    51 Post(s)
    Tagged
    2 Thread(s)
    Here's another convention - I indent any 'sub' declarations. Example
    I do, though only to a point. If I'm more than or 4 indents in, I don't go further. It does help me find subs of main boxes, and pseudo classes are always indented from their regular element declaration. All first children of a particular type are one indent in. If the child has an id or classname itself and has lots of children, it starts back at left and its children start indenting.
    So far as I knew, I was the only weirdo in the universe doing that : )

    Also curious to know which is more popular among css users - open braces... Vs. the closed system, which I used in the first example and is the one I prefer.
    In Javascript, it matters (in special cases) where you put the braces. Crockford has advocated the original C style (closed) to prevent the ambiguity of semi-colon insertion in special cases. I've always had my opening brace on the same line as the declaration element... also in my Perl, also in my Javascript.

    In Perl and CSS though there is absolutely no difference. I find it harder to read open braces only because I'm not used to staring at them that way 8 hours a day, but they're fine.

    Off Topic:

    Opera fixed that a long time ago, back on version 8 or so IIRC.
    I've never used Opera before 9. But I still have a page that used the hack.

    Let's see, I've dragged it out...
    if
    <body class="foo-bar">
    then
    body[class|="foo-bar"] #element {styles;}
    would only target Opera, somehow simply because there was a - in the name.

    But, on my current Opera, I can't see it taking effect, so they must have plugged that one since 9.28 (the version I used it on).

  6. #6
    Follow: @AlexDawsonUK silver trophybronze trophy AlexDawson's Avatar
    Join Date
    Feb 2009
    Location
    England, UK
    Posts
    8,111
    Mentioned
    0 Post(s)
    Tagged
    1 Thread(s)
    I prefer camelCase to using dashes and underscores too (in most cases), both in JavaScript and CSS, it's worked for me all these years, I'll keep going with it! As for the structure of code, I always use the selector followed directly by a space and then the { open curly braces, then the code goes on the next line (indented by one tab) and the close curl } is on the same level as the selector. I only have the {} on the same line if there's only one or two things to declare. As for sub declarations or styles (in the case of within media queries) I also indent within the indent. I find it increases the readability of the file (though it's extra bytes).

  7. #7
    The CSS Clinic is open silver trophybronze trophy
    Paul O'B's Avatar
    Join Date
    Jan 2003
    Location
    Hampshire UK
    Posts
    40,525
    Mentioned
    182 Post(s)
    Tagged
    6 Thread(s)
    Quote Originally Posted by Michael Morris View Post
    Here's another convention - I indent any 'sub' declarations. Example

    Code:
    #header {
    }
        #header a {
        
        }
            #header a:visited {
    
            }
    I can see how that is very useful visually to organise things but I find it very awkward to edit quickly and make quick copy and pastes without ruining the formatting. I also like to scan the page in a uniform way and have everything aligned nicely to the left.

    However, I can see the benefits of the above method but it just doesn't suit the way I work.


    Also curious to know which is more popular among css users - open braces

    Code:
    #header
    {
       property: ;
    }
    Vs. the closed system, which I used in the first example and is the one I prefer.
    I prefer:
    Code:
    #header {
       property:value ;
    }
    However if there is only one property value I will put it on one line to make it easier to read and scan through quickly (and also remove the trailing semi-colon).

    e.g.
    Code:
    #header {property:value}
    #header2 {property:value}
    #header3{property:value}

  8. #8
    SitePoint Wizard Stomme poes's Avatar
    Join Date
    Aug 2007
    Location
    Netherlands
    Posts
    10,283
    Mentioned
    51 Post(s)
    Tagged
    2 Thread(s)
    I do the one-line thing for IE6 comments. They stand out (because they look different) and are easy for me to find.

    However once IE6 gets more than one or two properties, they get newlines like everyone else.

  9. #9
    Follow: @AlexDawsonUK silver trophybronze trophy AlexDawson's Avatar
    Join Date
    Feb 2009
    Location
    England, UK
    Posts
    8,111
    Mentioned
    0 Post(s)
    Tagged
    1 Thread(s)
    That's funny, I do the exact same thing Stomme (and for the same reasons). Except in my case I span all the properties on a single line for that browser.

  10. #10
    Resident curmudgeon bronze trophy gary.turner's Avatar
    Join Date
    Jan 2009
    Location
    Dallas
    Posts
    990
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Paul O'B View Post
    I can see how that [indenting as for nested code] is very useful visually to organise things but I find it very awkward to edit quickly and make quick copy and pastes without ruining the formatting. I also like to scan the page in a uniform way and have everything aligned nicely to the left.
    I Agree. The scheme also implies a nested structure for css, which is not the case. Cascading does not equal nesting, though the html it applies against may indeed be nested.

    I prefer:
    Code:
    #header {
       property:value ;
    }
    However if there is only one property value I will put it on one line to make it easier to read and scan through quickly (and also remove the trailing semi-colon).
    Almost the same here. I will indent the closing brace, simply because it injects noise on the left side where I'm scanning for selectors, and I never omit the trailing semi-colon.

    I am often reminded the Paul is a very intelligent man, as he does so many things the way I do them.

    cheers,

    gary
    Anyone can build a usable website. It takes a graphic
    designer to make it slow, confusing, and painful to use.

    Simple minded html & css demos and tutorials


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
  •