SitePoint Sponsor

User Tag List

Page 1 of 8 12345 ... LastLast
Results 1 to 25 of 188
  1. #1
    I Use MODx kenquad's Avatar
    Join Date
    Dec 2009
    Posts
    424
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    How do you organize your CSS?

    The more complex layouts I create, and the more I move away from inline styles, the more bewilderingly long my css files become. It's a real productivity killer when you have to thumb through 1000 classes to find the one you need, or stop and fire up the "find" tool to do it for you.

    It's tempting to split the css into many smaller files, but this presents a performance issue.

    So, how do you keep your CSS organized for maximum productivity?

    Do you separate it into many files and then maybe combine them in the final version?

    Do you use comments to create sections?

    Do you make use of a code navigator or some other piece of streamlining software?

    Thanks.

  2. #2
    billycundiff{float:left;} silver trophybronze trophy RyanReese's Avatar
    Join Date
    Oct 2008
    Location
    Whiteford, Maryland, United States
    Posts
    13,622
    Mentioned
    6 Post(s)
    Tagged
    0 Thread(s)
    Your CSS file should never be so long you can't manage it, unless your making a huge website with a lot of styles for a lot of elements on page.

    I try and group my CSS based on the HTML structure.

    Aka I would have resets first, then the header CSS, CSS for each column etc, and then the footer

    If it gets long to the point where it's a hassle finding things, I'll comment.
    Always looking for web design/development work.
    http://www.CodeFundamentals.com

  3. #3
    SitePoint Addict
    Join Date
    May 2006
    Posts
    291
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Most of the time I just let Dreamweaver do it for me.

    Rgds

  4. #4
    Community Advisor silver trophybronze trophy
    dresden_phoenix's Avatar
    Join Date
    Jun 2008
    Location
    Madison, WI
    Posts
    2,802
    Mentioned
    34 Post(s)
    Tagged
    2 Thread(s)
    1000 classes??! I would hate to see the number of IDs you make. I am sure you meant 1000 rules. I like to organize my CSS the same way I organize my CDs, by current favorite; it used to drive my roommate NUTS.

    No, seriously. I take the following steps.

    1) look for duplicate declarations. If you have a rule count into the 100s, chances are that you have used individual declarations for the same rules.
    .myclass { background:green; height:100px;}
    .another { background:green; height:100px;}
    .somemore { background:green; height:100px;}
    Could be easily rewritten:
    .somemore, .another , .myclass { background:green; height:100px;}

    this saves bandwidth and helps organize the code. Additionally i there is a logical reason why all the rules are the same it become easier to modify stuff later on ( one change instead of 3).

    2) it helps to separate resets, common, function, layout ,typography and overrides . I chunk my code into these segments. Overrides I always put at the end, for obvious reasons, it may also include any IE hacks.

    3) if for some reason this is still not organized enough there is always breaking theabove sections into their own files and using links or @imports.

    hope that helps

  5. #5
    I Use MODx kenquad's Avatar
    Join Date
    Dec 2009
    Posts
    424
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by dresden_phoenix View Post
    1000 classes??!
    A hyperbolic example for clarity. I don't really run 1000 classes (or 1000 rules, for that matter) in one sheet - even though it sometimes seems that way when I'm looking for the one I want.

  6. #6
    I Use MODx kenquad's Avatar
    Join Date
    Dec 2009
    Posts
    424
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by RyanReese View Post
    I try and group my CSS based on the HTML structure.
    I use much the same approach. I started with the predefined tags such as <h1> and <p>, then the basic page structure progressing from container to topbanner to footer. That part pretty much stays organized. I run into trouble when I start creating classes that are used in just one or two specific places. They add up quickly and hide even faster.

  7. #7
    Community Advisor silver trophybronze trophy
    dresden_phoenix's Avatar
    Join Date
    Jun 2008
    Location
    Madison, WI
    Posts
    2,802
    Mentioned
    34 Post(s)
    Tagged
    2 Thread(s)
    I used to group according to structure, but really what does that mean to a HUMAN.
    I saw an advert for a company that say they were looking for a coder who "organized his CSS, alphabetically"... which just said to me that they missed the point of what organization actually DOES. Not to mention having to rearrange the whole thing every time you make or rename a class or ID.

    What I was suggesting is that you CHUNK your CSS into it's relevant potions. I have only coded for a couple of years but i found that I always had :


    resets and general classes. For example you may always use .clearfix{} or .center{margin:0 auto;}, etc.

    then the part that concerns the layout. usually mostly done with IDs., tons of size and background image work, floats... what ever it takes to get the page to lay out the way you want it.

    etc etc.

    Nother benefit to this is that you can reuse code. if you liek the way you did the type in one site or if you are working on similar layout.

  8. #8
    Resident curmudgeon bronze trophy gary.turner's Avatar
    Join Date
    Jan 2009
    Location
    Dallas
    Posts
    990
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Pretty much what Ryan says.

    First, organize your selectors contextually.
    • Global selectors
      • elements
      • classes
    • IDs and their selectors that differ from global values
      • elements
      • classes


    Once you're organized, you are likely to find many of the class selectors are not really needed. On the chance that each of those thousand classes really are necessary, go to your graphics dweeb, rant and rage and jump up and down on his desk. Then calmly suggest their is no benefit to micromanaging every third word in the site; that there should be a continuation of style/design from one page to the next**. Thus, no need for so many classes.

    cheers,

    gary

    ** Many times, the sales wonks want a different overall design from the bean counters, who want something yet again different from the main/public view. This is handled as sub-sites with their own stylesheets. See my /workshop/ pages for one approach. --gt
    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

  9. #9
    SitePoint Wizard donboe's Avatar
    Join Date
    Jun 2010
    Location
    Netherlands
    Posts
    2,105
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I follow Ryans approach. I start with a very simple reset. After that I aways declare some general classes: floats, dispays and clears, in every possible combination (this helps me to keep the style sheet organized), because before I always found my self creating a new class when I needed something floated or cleared, but this way I just add an already existing class to an already existing element. After that that indeed from header to footer.

    About the comments! I always comment, no mather how long or short the stylesheet.

  10. #10
    SitePoint Zealot
    Join Date
    Jul 2007
    Posts
    127
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I usually separate what I call my "helper classes" from my targeted IDs and classes. Indent very strictly. Try and vaguely organize my structure to mirror my HTML. Comment things.

    Then most of the time I rely too heavily on Firebug telling me which line to go to.

    By it's nature, I find CSS does not lend itself overly well to strict organization. At the same time, without extreme strictness, I find myself repeating rules unnecessarily and generally bloating my CSS quite fiercely.
    Patriotism is the virtue of the vicious.

  11. #11
    padawan silver trophybronze trophy markbrown4's Avatar
    Join Date
    Jul 2006
    Location
    Victoria, Australia
    Posts
    4,108
    Mentioned
    28 Post(s)
    Tagged
    2 Thread(s)
    I've always had one big stylesheet - with the rules grouped logically into sections and haven't had a maintenance problem.

    It's becoming more common to split the stylesheet into many smaller files and then combine and compress these server-side.
    If you're working in source control when there is only 1 stylesheet it can often get confused when you're moving lots of things around and so are others in the team. Many smaller files help to prevent the merging conflicts.

  12. #12
    I Use MODx kenquad's Avatar
    Join Date
    Dec 2009
    Posts
    424
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Thanks all for your thoughts so far.

    @markbrown4
    It's becoming more common to split the stylesheet into many smaller files and then combine and compress these server-side.
    Something I'm interested in doing - can you recommend a method/script?

    @BLZ
    without extreme strictness, I find myself repeating rules unnecessarily and generally bloating my CSS quite fiercely.
    I hear you.

    @donboe
    I start with a very simple reset. After that I aways declare some general classes: floats, dispays and clears, in every possible combination
    That is a very interesting idea, but don't you end up adding and removing classes quite a bit as the layout progresses?

    @gary.turner
    rant and rage and jump up and down on his desk
    I'm the designer as well, so I guess that would be my desk

    @dresden_phoenix
    I saw an advert for a company that say they were looking for a coder who "organized his CSS, alphabetically".
    I actually have resorted to more or less alphabetical sorting at times, not manually changing the sheet but using a code explorer. The problem there was when I had specific selectors such as div.style1 and div.style2... They would all end up under, well, "D"...

  13. #13
    padawan silver trophybronze trophy markbrown4's Avatar
    Join Date
    Jul 2006
    Location
    Victoria, Australia
    Posts
    4,108
    Mentioned
    28 Post(s)
    Tagged
    2 Thread(s)
    Quote Originally Posted by kenquad View Post
    Thanks all for your thoughts so far.
    Something I'm interested in doing - can you recommend a method/script?
    Try a search - it's been covered lots on the forums - here's an article.
    http://articles.sitepoint.com/articl...mization-steps

  14. #14
    SitePoint Zealot
    Join Date
    Jul 2007
    Posts
    127
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    That is a very interesting idea, but don't you end up adding and removing classes quite a bit as the layout progresses?
    You may be pleasantly surprised. I do the reset, begin with a standard array of classes too (when I can). I've actually found generally I use LESS CSS surprisingly. And it eliminates the weirdness caused by different browser defaults. Gives you a clean slate...

    I combine my helper/standard classes where it's appropriate as I go. Eg - I discover that I end up coloring the text of every float:left element anyway.

    I use presentational class names and actually work to minimize the specificity (or whatever that word is). I just hate overkill on the specificatiousityness. I'm far from a guru though. In the end, function tempered with my ignorance trumps whatever the best practice is that week.
    Patriotism is the virtue of the vicious.

  15. #15
    SitePoint Wizard Stomme poes's Avatar
    Join Date
    Aug 2007
    Location
    Netherlands
    Posts
    10,278
    Mentioned
    50 Post(s)
    Tagged
    2 Thread(s)
    Quote Originally Posted by BLZ
    specificatiousityness.
    awesome++

    I have one site that has a very huge CSS. In fact, due to a high number of specific pages (CSS map pages with lots of their own CSS), I was forced to split the styles all pages shared into one sheet and the rest in another (this other one @imports the first one, so most pages are really using one file who calls another file). Then, the amount of display: table and display: inline-block got to the point where I actually had to break down and make the IE sheet separate. This was horrible because updating one sheet, I had to remember to update the IE one the right way. Separate stylesheets suck.

    But, I never lose a class or an id. First, in the HTML it's under some main block. Which means it's also under that main block in the CSS. For example, if I have id="sidebar" (has to be such a generic name because different pages have different things in their sidebars), if something's in that sidebar then it'll be under #sidebar in the CSS.

    Beyond that, every text editior can /find anything. I possibly use the / key more than anything else. It means that while I did bother grouping CSS to follow the source flow, I don't really have to because / finds anything anyway. With grouping it means I can find relevant code for stuff that doesn't have a source order: tables, forms, etc. So there I just /form or /table. Tables in the sidebar? /#sidebar [enter] /table [enter] I'm there.

    Now if I were working on something like a Drupal CSS sheet where every box hass 15 classes and they all are some variant of "block" including "block-block-block" and "block-clear" and "block-block-clear" ...
    well that's why I'd never want to work on a template like that. I'd like to keep my sanity.

  16. #16
    SitePoint Zealot
    Join Date
    Jul 2007
    Posts
    127
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Off Topic:

    Oh yes, templates are why I hate the crazy specific stuff. You need to override a rule on one teensy little element...turns out it's div#useless div#unnecessary div.useless2 div.even_less_necessary div h2 span.
    There is much copy and paste from the almighty Firebug happening, I tell you.

    Whaddya do? Track down all the source, and clean the garbage out or use horrid bloated CSS and swallow a bunch of bad, unnecessary code? Sadly I confess to caring much less than I should about webspace and bandwidth - I blame "unlimited" for making me lazy.

    Anyway, yes the hallowed find function is why I don't get too excited about CSS organization. I just keep it quasi readable for my sanity.
    Patriotism is the virtue of the vicious.

  17. #17
    Non-Member bronze trophy
    Join Date
    Nov 2009
    Location
    Keene, NH
    Posts
    3,760
    Mentioned
    23 Post(s)
    Tagged
    0 Thread(s)
    It's all about having a organizational plan and sticking to it. For me, there are a few simple rules I use.

    1) There is NO excuse for using more than TWO stylesheets on a page per media type. One sheet is for elements that are common to all pages, the second sheet is for stuff unique to just the one page. This of course means that any of that "conditional comment" nonsense has no place in my markup.

    2) @import is outdated netscape garbage and has no place in a modern stylesheet. If nothing else putting every link together in the markup at least makes it clear what sheets are being loaded.

    3) Use classes and ID's that say what things are, NOT how they are going to appear. Appearance is CSS' job and as such using a presentational class in the markup is no different than just using a presentational tag; welcome to 1997. "left", "clear" or "boldFont" defeat the point of even having CSS in the first place -- one might as well go back to using CENTER, ALIGN and FONT tags at that point!

    That right there is something people miss all the damned time -- see all the rubbish CSS 'frameworks' like YUI or GRID, which by definition using presentational classes defeats one of the reasons to even be using CSS -- Separation of presentation from content and all the advantages it brings!

    4) If the CSS feels like it's getting too big, you either have redundant declarations, or the fault lies NOT in your CSS, but in the markup!

    It's something I tell people time and time again (Zathras warn, but no, no one listen to poor Zathras, no...) -- CSS can only be as good as the markup it's applied to -- See why 99.99&#37; of Turdpress templates are worth less than the typical CS degree (which are worth less on average than a sheet of bogroll), since nobody bothered to mention to Wordpress coders that not every ejaculation deserves a name... which is to say that you don't need a div on every element much less a class on every element.

    Frankly, all you have to do is look at the code output in 99% of wordpress sites to see nobody making templates for is qualified to be writing HTML/CSS in the first place!

    You'll see this "special" mistake time and time again (as in how some olympics can be... special):

    Code:
    <div id="header">
    	<div id="header-logo">
    		<img src="images/logo.png" alt="company Name" />
    	</div>
    	<ul id="header-menu">
    		<li class="header-menu-item">
    			<a href="/" class="header-menu-anchor">
    				Home
    			</a>
    		</li>
    		<li class="header-menu-item">
    			<a href="/faq" class="header-menu-anchor">
    				FAQ
    			</a>
    		</li>
    		<li class="header-menu-item">
    			<a href="/forums" class="header-menu-anchor">
    				Forums
    			</a>
    		</li>
    	</ul>
    </div>
    Which is a classic example of the "not every ejaculation" routine. Since it's a 'header' maybe it should have been a HEADING? Since that would be the first heading (and by definition every lower order heading being a subsection of the H1) it doesn't need a ID or class. Since you have a perfectly good ID on the UL, what the blue blazes does it need the same class on every LI and Anchor for? It's nonsense, but you see people doing it all the time; even people who allegedly know what they are doing -- again, see wordpress templates.

    One load of code for what I would probably have written as...

    Code:
    <h1>
    	Company Name
    	<span></span>
    </h1>
    
    <ul id="mainMenu">
    	<li>
    		<a href="/">
    			Home
    		</a>
    	</li><li>
    		<a href="/faq">
    			FAQ
    		</a>
    	</li><li>
    		<a href="/forums">
    			Forums
    		</a>
    	</li>
    </ul>
    Which provides ALL the same hooks I'd need to apply any of the exact same styling in 90%+ of cases. At worst I might have to add back in one div if the two sides of the menu are different for something like rounded corners.

    From there it's a simple matter of what order you put stuff in your CSS. For me, I always have my 'screen.css' (notice the default template is named for *SHOCK* the media type it would be for) which contains the stuff common to all pages set up in this order.

    1) Reset
    Code:
    /* null margins and padding to give good cross-browser baseline */
    html,body,address,blockquote,div,
    form,fieldset,caption,
    h1,h2,h3,h4,h5,h6,
    hr,ul,li,ol,ul,
    table,tr,td,th,p,img {
    	margin:0;
    	padding:0;
    }
    
    img,fieldset {
    	border:none;
    }
    2) BODY and other 'global' values
    For example, BODY, A -- if they are getting values that are applied across the document, I set those first. For 90% of the pages I write, that would be:

    Code:
    body {
    	text-align:center; /* center #pageWrapper IE 5.x */
    	font:normal 85%/140% arial,helvetica,sans-serif;
    }
    
    * html body {
    	behavior:url(csshover3.htc);
    }
    Sometimes I'll also have HTML there (like on 100% min-height layouts), if so it goes before BODY.

    3) Template tags, classes and ID's in source order
    Once you are past BODY I find the best way to keep your code easy to follow is to just put your tags, classes and ID's in the exact same order they are in your markup. When they appear first, that's where they go in your CSS. I do NOT advocate 'breaking up' your FaC (Fonts and Colors) from your styling, as that's just going to make it harder to maintain. If you are applying styling to elements do your damnedest to keep the values for one element in the same piece of code! You shouldn't have a width on your #mainMenu declared at the top of the code, go through some twenty elements and hundred+ lines of code to find it's floated, and then have to track down that it's background-color is declared in some other FILE... That's idiotic, and you see it all the damned time.

    If in your code you have a outer wrapper to set the fixed or semi-fluid width, followed by a h1, followed by a UL with a ID on it -- why would your order in the CSS vary from that? Makes no sense to do so, but you see it all the damned time.

    COMMENTS
    ------------------
    I feel I should cover this a bit; Comments to explain the unusual is a good thing -- dumbass redundant comments are not. I see one more dipshit greenhorn, or worse, dumbass 'professional' making comments like:

    Code:
    <!-- start Main Menu -->
    <ul id="mainMenu">
    or

    Code:
    // Main Menu CSS
    #mainMenu {
    I'm gonna spend my movie cash to start going door to door... Did you say on moviepoopshoot.com "Jay and Silent Bob..."

    Hell, I even get bothered by

    Code:
    </div><!-- end page wrapper -->
    Since the comment placement could trip a rendering bug in IE if floats are involved, and... well, a </div> is ending a section?!? No ****! Who'd have thunk it!?!

    Code:
    <!-- #pageWrapper --></div>
    Which completely avoids the possibility of the IE comment rendering bugs and is just as clear as to what's going on.

    Bad commenting is why I suggest most anyone writing code read this excellent article on IBM's Linux Developer area.
    http://www.ibm.com/developerworks/li.../l-clear-code/

    You use meaningful class names, don't waste time saying obvious **** anyone qualified to even be looking at the code in the first place should know -- and it can be just as clear or even clearer than having a comment for every line.

    Finally, I said it's ACCEPTABLE to have two (and no more than two) sheets per page -- a common template and the stuff unique to the one page -- I try in most cases to use just ONE stylesheet per media type, putting the unique content AFTER the template. This is part of why I dislike that IE conditional ******** in the markup and consider that nothing more than inept coding when used. The other reasons being the above mentioned keeping all declarations for a element TOGETHER, and I'd rather send a hack like "* HTML" in the CSS that gets cached than send more uncached markup on every page request! Besides, if you can't write code that works in IE7/newer without resorting to sending each version separate stylesheets, IMHO you have no **** business writing code in the first place!

    If nothing else it's one less handshake (so +/-200ms saved) and really if there's enough code unique to each and every page to be warranting the use of a separate file, frankly there's something fundementally WRONG with your code... but then the majority of websites have NO need for more than 32k of CSS and no need for ANY javascript; hence why the majority of new sites now have 64+K of CSS and hundreds of K of javascript usually doing CSS' job, and on the markup side a code to content ratio in excess of twenty to one! (...all in the name of making the page faster/easier to use/use less bandwidth... RIGHT!)

  18. #18
    SitePoint Zealot
    Join Date
    Jul 2007
    Posts
    127
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Ahh, I was waiting for my favorite angry elephant to go off!
    I use presentational class names strictly because I forget names that I choose sometimes and I don't like bouncing back and forth and around my source and my style docs. Unfortunately, I always seem to neglect to clean them up afterwards. No excuse there I'm afraid.

    I find the reusability of CSS pokes holes in the whole idea of reflecting how it appears in the source. I have a class that gets used 4 times on each of 100 pages. Where exactly does it belong?

    I do agree, having a plan and sticking to it is absolutely vital. Naming conventions etc. are always critical, and they are where I usually come up a bit short.
    Patriotism is the virtue of the vicious.

  19. #19
    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 BLZ View Post
    I use presentational class names strictly because I forget names that I choose sometimes and I don't like bouncing back and forth and around my source and my style docs.
    Sounds like Firebug and/or Opera Dragonfly could be your best friend. Occasionally I too forget what I named something -- or more commonly when working with someone else's code I can't find what's applied to an element... That's where tools like the two insects come in real handy.

    Though really if your code is so complex it's hard to find an element you want to change, there's probably something wrong with the formatting, or the code itself. Code should be in order of display and clear, so if the display, markup and CSS are all in the same order, it gets pretty simple to find things. It's why I didn't even understand the POINT of firebug until I used it on someone else's code once.

  20. #20
    SitePoint Zealot
    Join Date
    Jul 2007
    Posts
    127
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Yeah, I find myself wading through a lot of code that isn't mine and nasty WordPress templates lately. I thank the heavens for Firebug. I try to walk the line between making my life easier and avoiding too much of the "How do I..." questions when somebody else takes the reigns.
    I like to avoid most people feeling like they need to look under the hood. They see code, their eyes get all glassy and they begin asking questions that are the equivalent of "My nose has this fluid coming out of it, what should I do?" Umm, wipe it? Just saying.
    Patriotism is the virtue of the vicious.

  21. #21
    SitePoint Addict
    Join Date
    Dec 2008
    Location
    Brussels
    Posts
    377
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Just never make a maze of it.
    Sort your tags geographically situated in your dom tree, from North, East, South to even West if you want.
    Do everything you want but manage.

    Tip: you can make comments to general things through the website where you hold every related CSS class/ID.
    /* fonts */
    /* forms */

  22. #22
    SitePoint Mentor silver trophybronze trophy

    Join Date
    Feb 2008
    Location
    Preston, Lancashire
    Posts
    1,378
    Mentioned
    72 Post(s)
    Tagged
    1 Thread(s)
    @deathshadow60 I found your post very informative.
    Just wondering, what text editor do you prefer and do you use any shortcuts when coding to speed up the process. Much of coding is the same so something much be done to speed up the code. Have separate files and using import in CSS is clearly out of the question.

    @kenquad can you post a sample CSS file you did for a site, so we can look at it, and maybe I could say what I would do different. What I do is I group things in my CSS. For instance:

    /* main text */
    .maintext {}
    .maintext li {}
    .main text .quotes {}

    ... and so forth. So everything is pretty much grouped. I once did a CSS file for this 500 page website (yes 500 pages), which needed 1000+ lines of CSS code, some of which was not mine. I condensed most of it by using shorthand, but it was still 500 - 600 lines. I then used CSS compressor, which compressed everything. It make some difference in the file size (approximately 35&#37; reduction), but was a pain from making future edits.

  23. #23
    perfect = good enough peach's Avatar
    Join Date
    Jun 2004
    Location
    -Netherlands-
    Posts
    1,383
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    the search function can also be helpful

    http://www.sitepoint.com/forums/showthread.php?t=618724

  24. #24
    perfect = good enough peach's Avatar
    Join Date
    Jun 2004
    Location
    -Netherlands-
    Posts
    1,383
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    regarding questions about splitting CSS into multiple files and combining and compressing them together, Drupal has this function built in.

    In drupal 7 this has been improved further, it has more intelligent CSS and JS packaging based on which files are required in specific website sections, and also allows themes and modules to opt out of CSS and JavaScript compression.

    ps Drupal7 is not finished yet its still a work in progress. hopefully there will be a beta this month

  25. #25
    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 Sega View Post
    @deathshadow60 I found your post very informative.
    Just wondering, what text editor do you prefer and do you use any shortcuts when coding to speed up the process.
    I use Crimson Editor, though the ONLY reason I'm using it is it's one of the few editors that lets me turn all the crap OFF. Crap like:

    Autocomplete -- in many editors the 'prediction' is so innacurate as to be useless, while in other editors it types it in without so much as a 'by your leave' resulting in my spending more time correcting it's nonsense than I do writing code... so shtup that.

    Colour Syntax Highlighting -- Sorry, I'm not a fan of acid trips IRL, why would I want one in my code. Are people like... punctuation blind or something? I really don't get the point of colour highlighting apart from making the code harder to read. (if not impossible with many default color schemes)

    Tabs -- Tabs are fine in a browser -- in a text editor, not so much... Especially if *shock* I want to see my HTML and CSS side-by-side, or *shocking shock* want them on different displays. (I'm running four monitors, lands sake let me use them). I have this amazing thing called a "taskbar" -- does the job fine. (though I run that in portrait mode on the right side of my right display)

    Crimson is very basic, more-so if you turn off all the default crap (toolbar and the above) and turn on the useful stuff like the line-number column, allowing multiple instances, set it to two space tabs (as tabs, NOT spaces), change it to a more legible font (I'm a fan of M$ fixedSys even if it is a raster font only avail in 7 or 11), set the word-wrap indentation to zero, disable that annoying 'drag and drop text editing' nonsense, etc, etc, etc.

    As for 'tools' in the editor I use...

    "block tabbing" is a must have -- I'm amazed how many editors still fall flat on their face even TRYING to do this. Select a block, hit tab, every line in the selection is tabbed in one... hit shift-tab, every line in the selection has a tab at the beginning removed (if any)... I couldn't live without that now.

    "delete word" -- very handy.

    "convert spaces to tabs" -- great for working with shlock code from people who don't format properly.

    "remove trailing spaces" -- also great for cleaning up other people's code...

    But apart from that, I prefer to type it... since most of the other tools like macro's and so forth you end up wasting so much time setting them up and screwing around with them you never actually write anything... besides by the time I remember what ones I have set up, I can just type the damned thing out in less time.

    In a lot of ways people become over-reliant on their tools, and that's where the mistakes start to happen. From tools like auto-completion it's just a hop skip and a jump to sleazing out pages any-old-way with half-assed copypasta and fat bloated library garbage like YUI, jQuery, Mootools, etc.

    Quote Originally Posted by Sega View Post
    Much of coding is the same so something much be done to speed up the code.
    That's SSI/CGI's job if it's redundant NECESSARY markup -- though in a lot of cases it's more a matter of getting the code under control in the first place by NOT slapping DIV and class/id on EVERYTHING. As a rule of thumb if your code to content ratio breaks 3:1, the code is trash... It's why I have my loose formula for figuring out how big a page SHOULD be.

    Target Markup Size = 1.5k + (CDATA*1.5k) + 200 bytes per IMG/OBJECT tag.

    Usually once a page has actual content, there's little reason for that number to be more than +/- 10% off the mark. It's why I cringe whenever I see pages that have 3.5k of content (CDATA / plain text) with 192k of markup on only five or six content images.

    ... as that screams ineptitude of the highest order. One step away from designing with fixed metric fonts, 200+k of CSS and 370+k of Javascript for NOTHING.

    Oh, and big tip, if you have more K of markup and CSS than you images, you've REALLY screwed the pooch... if you have three times as much javascript on a static page as you have images, do the world a favor, back the **** away from the keyboard, and take up something less detail oriented like macramé weaving.

    ...and yes mods, I did the asterisks by hand -- and no I can't put that more politely as it needs to be said!


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
  •