I have just finished building a heavyweight long sales page, with a lot of elements and varying styles on the page.The CSS has ended up being over specific with its selectors, and there are numerous rounded boxes, background images etc. In short, the CSS is a bit of a mess. (only myself to blame!)
Can anyone suggest a method of going through this stylesheet methodically, in an effort to combine my duplicate properties etc? I doubt there are any tools to do this for me, but I'm wondering how others deal with this situation?
Thanks.
There are in fact some CSS Refactoring tools, which were covered on SO pretty well.
I can't vouch for them, though, since I always refactor by hand. My technique is to separate existing styles into:
Layout
Typography
Colors (Look & Feel)
Hacks
That's usually a quick copy & paste job. From there, similarities and redundancies are a lot more apparent, so combining and simplifying gets much easier.
With that done, having a TOC at the top of the page makes your sections easy to find, and generally easier to search.
Combine CSS to their shorthand properties if possible.
Take advantage of unique dom ids to apply styles to the children of that element.
You can use multiple CSS classes on the same element, for example class="somestyle some-other-style". Using this you can take duplicated CSS styles and define them in one.
Use the * selector to apply styles to all the children.
If its all in one big CSS file, split the code into sections where the styles are relevent to the pages across your site, i.e /* MEMBERS PAGE */
Run the style through an online compressor to reduce code size. Some even combine elements automatically for you, further adding less complexity.
That should get you started. It's hard to add further, it really depends on how your html code and structure is set out. If you could provide an idea we could assist further.
Related
I am using Adobe Edge Reflow and have made several designs using the software.
One thing I have found is that in the CSS exported, each element has its own ID in the stylesheet.
In many cases there are elements that should use classes but I see no way of doing this in Reflow.
For one website I made I went through manually changing this, but as you can imaging it took quite a while.
If anyone knows any way of using classes in Reflow or a better way of managing the exported style sheet I would greatly appreciate it.
Our application at work uses the ExtJS (Sencha) framework for the UI. The problem I have with the framework is the amount of HTML that is output by the framework.
I have noticed that the areas of the system that are reported as being slow by users have a ton of CSS calculation calls. I measured this in Google's Speedtracer and some pages take 8seconds to load. 80% of the time is dedicated purely to CSS calculations. Before trying to alter the way the framework works, is there anyway to delay CSS calculation of a page, or are these calculations done when the objects are rendered?
I have been searching for ways to do this, and maybe my "google-fu" is terrible, but I haven't found anything concrete on how to achieve something like this.
EDIT: After speaking a colleague, he pointed me in the direction of calling .suspendEvents() on the grid before loading any data and .resumeEvents() afterwards, this alone has saved 300ms of loading time :O This is reducing the number .getStyle calls detected by Firebug. I am yet to test this difference with Google SpeedTracer
It's hard to say what's causing your performance problem without knowing exactly what your app is doing. CSS will have some impact but not much, it's more likely that some JavaScript in your app is causing excessive reflows while the page is rendering.
Summary of stubornella's article (the second link)
Reflow is the process by which elements in a web page get laid out according to the style rules. A reflow is computationally expensive but it is usually possible to draw a static HTML page in a single reflow as long as the rendering of any later elements doesn't effect elements that have already been drawn. Things which are likely to lead to multiple reflows and some work arounds:
Dynamically adding CSS classes to elements - change classes as low in the dom tree as possible to limit the impact
Adding multiple DOM elements - create an invisible structure and add it in a single operation instead
Adding multiple inline styles to visible elements - better to create a class with all the styles, then apply the class
Applying animations to relatively positioned elements - better to animate position: fixed or position: absolute elements as they won't impact anything else
Fine grained animations - moving an element 3px at a time may be more smooth than moving it 1px at a time because you avoid two reflows
Tables are one of the few cases where the rendering of an element later in the DOM can change how an earlier element should be rendered - if you must use tables, use table-layout: fixed
We have also been struggling with the overhead of using extJS - although the framework is very comprehensive, the performance hit (especially with IE6) has been a big limitation. Here are some of the steps we took to optimize the framework:
Streamline the library to only include the packages that are used on your site. This means customizing the jsb2 file and rolling your own extJS deployment.
In our performance testing we've identified the CSS to be the biggest offender. A benefit of using a custom build of extJS is the reduction of unused CSS selectors. To further optimize the CSS, we used Google's Page Speed to identify the CSS selectors that are inefficient to refactor/remove them. Pay particular attention to:
Pseudo :hover selector
Universal * key with descendant selectors
The resulting ext "lite" should yield significant performance gains, particularly in IE6. Although the Secha team are making continuous performance improvements with every release, the overhead of loading the entire framework is too expensive to ignore.
Hope this helps...
Smartoptimizer is really awesome, have you tried any of those types of gzip code compression type tools?
https://github.com/farhadi/SmartOptimizer
Since I new with CSS, I just started to work with CSS Grid system. I would like to know if are there any technical issues in use CSS grids? I mean, which are the reasons for you to not use grid?
Thanks
Flexibility
Once you start using the grid, you are stuck with it. Any other issues you might wind up finding you will have to conform to.
In my opinion (and every other designer I've talked to) it is far easier to simply define your own columns and default sizes as classes and apply them as-needed. A custom grid if you will. Then changing the styling is as easy as changing a line or two of CSS, instead of either re-generating the grid system or redesigning the site and sacrificing in order to use the grid.
I'm a fan resets and some minor love from Blueprint (especially the Typography), but that's about it.
I've just started using object oriented CSS (OOCSS). I'm really enjoying it because it provides a very basic and minimalistic grid system. It allows you to create relative sized grids by dividing an element into halves, thirds, fourths, or fifths. The divided elements are infinitely nestable.
OOCSS is more of a philosophy than a framework. It's all about how you extend a very basic foundation.
Check out these links:
http://oocss.org/
http://developer.yahoo.net/blogs/theater/archives/2009/03/website_and_webapp_performance.html
http://www.youtube.com/watch?v=j6sAm7CLoCQ
The only real reason is that they can lead to bloated markup, sometimes you have to do some serious nesting depending on the layout and desired effects+flexibilty.
They also lead to excessive class name lists on elements. However, you can avoid this at least if you move the CSS to semantic classes/ids before deploying... but thats can be alot of extra work. Blueprint is the excpetion here because it has acommand line tool to allow you to apply the rules from its framework classes to semantic selectors.
Overall i generally use them because its alot easier to teach a designer how to use a grid template. That why im not do alot of production art tasks when i go to slice things down. It jsut makes the whole process smoother IMO.
If your site has a column layout AND repeatable design patterns throughout the site... then there aren't any reasons not to include a grid. A grid adds: organization, proportion and alignment to your page. So why not keep that consistent? There is no reason.
Just don't Overuse A Grid
Some people say a grid is inflexible? That's not totally true - you can use it where you need it. You can always remove it or adjust. Just don't overuse it.
It depends on the grid system. Most grids have a fixed amount of columns, which restrict you in how you create your layout. For example, they don't allow you to combine 30%/30%/40%, 50%/50%, 25%/75% and whatever other combinations you can think of.
Some grid systems also don't allow nesting. That means you can't use a grid element as a grid for child elements in those grid systems, which makes it a lot more difficult for many layouts to be coded to HTML.
Also, some grid systems use techniques that don't work in older browsers. Before you use a grid system, you should always make sure it supports the browsers you need to support with your project.
There are frameworks out there without such restrictions, though. Cascade Framework, in fact, has a grid system far more flexible than that of any other framework out there and works fine in both IE6-8 and modern browsers alike.
I'm working on a web app that currently has a table-based layout. Ideally I'd like to go to pure css, or failing that, a hybrid tables-and-css layout* .
I've banged my head against the wall trying to understand css layouts and positioning. The main problem I'm encountering is that, depending on the state of the app, I have different things appearing in a 'section' of the layout -- what might be contained in a div or table. For instance, I might have some text and links, and then after user interaction, there might be a form, a table, some images, different text, etc. Anytime I find a css solution, it is for a fixed-element layout, or works in a specific case, etc. They're not robust solutions, in other words.
From this In Search of the One True Layout, the author about "Vertical placement of elements across grids/columns": "Designers face the choice of relying on elements being a particular height, resorting to tables or simply not bothering." Is this true? In my app, I can't rely on elements being a particular height.
Do I fall back on tables when I have elements of various hieghts ( which is quite a bit of the site, actually). I noticed that quite a bit of sites done by well-respected people and organizations use tables for layout in certain places, and not just for tabular data! This site included.
The chances are that there are CSS techniques to achieve what you want, but they may not be obvious if using CSS for complex layouts is new to you.
In your case, to 'get it done', I would recommend a hybrid type layout, and not feel bad about using a table to layout the pieces of the application that require those particular behaviours.
If it is particularly complex and difficult than a table might be the best and simplest approach even for the CSS expert.
Dynamic heights are only a problem if you need to implement a special effect of soem sort or a background image and oftent there are ways around that. It really depends on the Visual Design and what needs to be done to make each "block" flexible to use. Sometimes things arent possible but most of the time they are - they jsut tend to add complexity to the markup. But even that added complexity is easier for me to understand than nested tables :-)
My advice if you want to get things done and spend a ridiculous amount of time on css layout, browser compatibility, CSS reset, fonts:
write simple, valid, semantic HTML
use a simple CSS framework (like blueprint). You will rely on a simple grid system for positioning and layout.
add CSS classes to your HTML
add your custom CSS for colors, backgrounds...
Please reconsider using a table layout 'to get it done'; you will be disappointed, especially if you want to add some JS magic later.
I use CSS layouts for my web apps. But, my apps don't have wildly varying information, so I can set the content area and not have to worry about the layout looking "off" because a column is way out of balance with the rest of the content.
If you're having trouble with CSS layout and positioning, I'd suggest tables first, learn more about CSS/HTML positioning, and then convert your layout LATER. I'm sure that it's made for a frustrating experience learning CSS on a "real" project.
In the meantime, get some really good sources for CSS: books by Andy Budd, Simon Collison, Eric Meyer, et. al. Also, go to their blogs and dig into the archives. A really good book for CSS layout, positioning and general use is Beginning CSS Web Development by Simon Collison from APress. All the ins and outs with great working examples.
Im working on some web software that has 2 style sheets one for style (style.css) and one for layout (layout.css). Im wondering what the poing in this is (apart from the obvious) I mean some style options will effect the layout and vice versa. So would it be better to roll all css into on page to make it easier? Maintining multiple stylesheets seems very tedious.
Anybody got an opinion on this and best practice?
Cheers
PQ
I could see this being useful in situations where you want to have multiple styles whilst keeping the same layout. For instance, if you wanted to change the colour scheme at the click of a button.
I don't think I'd use it in any other situation, as by doing so you would be duplicating classes to set different styles and increasing your workload for something that's not really beneficial.
I personally like to separate style and layout in different CSS-files as you can have the same layout with different style (and vice versa) this way. Think of having a multi-client system and each customer wants a different style while the layout stays unchanged. Have those two files merged into one will create unnecessary overhead.
i think the choice depends on personal preference and on the size of the project.
when i'm working on bigger projects with other developers, i prefer to keep the styles in a separate stylesheet primarily because you can 'give' one stylesheet to the other developer and work on another and not worry about someone overwriting your styles.
the disadvantage of this is that multiple styles might appear in different stylesheets. what we generally do is have separate stylesheets for the main layout and the various sections, so the styles for the dynamic part can be edited easily without scrolling through a 3000 line stylesheet.
I do this in a simple CMS system I wrote so that I can change the style and layout independently of one another. This means I can write a new stylesheet for layout and use it in conjunction with all existing 'styles' for (in theory) no extra effort. However, sometimes it takes a bit of work to make all combinations of style and layout work properly together.
Personally, I think its a nice thing to be able to do and would keep it as it is in your system.
I guess that the idea is that you could create a new color theme by only switching the style stylesheet. If you are careful about what you put in each style sheet, it's definitely possible to use it that way.
It might have an application in some rare cases, but generally it will just make it harder to work with the CSS. I have tried this for a site where we have multiple themes, but I ended up merging the stylesheets again after all.