I have found that setting a very basic style reset or style sheet initialization as I prefer to think of it has caused an unexpected result as certain browser defaults were effected. This (me being stupid) led me on a merry dance until I realised that I had turned off the default by employing the reset.
I am now carefully picking through all the pages identifying any other adverse effects.
I suppose that it very much depends on personal preference whether you use a reset or not and I may of course be over thinking this which is the curse I carry. Nevertheless I would like an opinion on whether this is good practice or a good way of over complicating everything.
If it is good practice is there a particular time when it is appropriate to apply a reset.
Eric Meyer's article reset reasoning made perfect sense to me hence employing a very basic reset. I did not employ the full Eric Meyer reset which of course may well have been my downfall. I am not intending to revisit that at this stage.
However I would like to know going fwd what considered opinion is and whether I should be attempting to apply this in future.
Regards
This absolutely depends on the way you write your webpages and the size of your project. Most pages would be 'meh, okay' without reset, but not perfect or consistent on all browsers.
It's trivial why one might use CSS reset -- the more interesting question why not use it?
If you rely on browser-defined default styles (like, for instance, the way h1, h2, h3, h4, h5, h6 get rendered or how ul bullet-lists behave by default, or default margins/paddings, etc...), then resetting your CSS will probably have you do some extra work. In other words, doing reset will bring back all HTML elements back to almost 'nothing' -- just a bunch of semantic grouping tags...
Which is good.
It's what HTML is supposed to be like, not for styling; but for logical and semantic grouping. Styling your elements from scratch will give you much more control, and will save you some browser-specific tweaks and pain.
Plus, jsFiddle does it, so it must be some good!
as certain browser defaults were effected.
Any other defaults that weren't effected would be a bug, since that's the whole point of a reset css.
The one bad point about a reset stylesheet (assuming it has no bugs in itself), is that you have to think about the style of every element used.
The good point about a reset stylesheet, is that only you have to think about every element used. Not using one is a bit like working with a colleague you don't communicate well - it'll save time when they happen to do things that go well with your work, but whether you are duplicating work or letting some case fall between the gaps and get ignored won't be obvious.
In practice, it depends upon which of the two philosophies suits a project best:
You're happy for a lot of styles to depend upon the browser default and (the plus of this approach) user settings. You only add what CSS is necessary, and let such things as default sizes and fonts depend on the browser.
You strive to have a very precise say on every element.
There are pros and cons to both these approaches, and the pros of the second approach has increased lately, as the mechanism used by browsers for re-sizing text for legibility has changed meaning that more of them resize the whole page rather than just the text (this was a big problem with taking the second approach before - you would either have some settings break your design, or have your design break settings some users depended upon to be able to read it at all).
With the first approach, using a reset sheet smashes through the very philosophy you are taking, ruining everything for you.
With the second approach, using a reset sheet is a good first step to getting going. Any time you find that the reset sheet caused a problem, what you really found was that there was something you should have been doing, that you didn't do, and it highlighted that problem for you. If you accomplish the second approach without a reset sheet, then you've effectively arrived at the same result you would have with it, at least as far as those elements used go.
Related
How slow is the * css selector on mobile browsers?
Ive heard that it should't be used for speed reasons. However im mobile optimizing a site and I cant change the source code much at this point. I need to set float:none, width:auto, height:auto, position:static for a lot of elements. If I dont use * my selector list is going to get very long.
There was a study out where this was tested. I no longer have the link but, suffice to say, it slows things down for all the reasons you probably know (every element needs to be evaluated).
As you may also already know, the different resets around choose and set only those elements that need 'resetting'. Some people, like myself, just set the elements to what we want them to be rather than a wholesale change.
Of course, like all things, testing it yourself is probably the best way.
I need to do a CSS layout. I need to know the best practices to avoid the pain of the CSS multi-browser compatibility.
What I should use to avoid issues in this regard? Should I use a CSS Framework? If yes which one?
Best Regards,
First, know your audience; this lets you know what browsers your site will be accommodating. Second, make sure you have a good grasp of CSS. Third, get familiar with the concept of "progressive enhancement." Lastly, consult this website: Do websites need to look exactly the same in every browser?
For starters, good clear code, thats styled once, and once only helps LOADS. When i say this, I mean, insure all your CSS is in an external file, and no in page or in line css calls are made.
Second, start with a good body,html statement. Get everything defaulted from the work go, your margins, your padding, font size and family, maybe simple calls, but doing it as this step, will save you countless calls of code later on. Even more so when dealing with large sites with 100's of lines of CSS code.
Lastly, keep your CSS organised, make comments, put them into catagories.
Most cross browser related issues are down to one thing, user error. Style it right, style it once, and you and your users will be happy!
I use HTML5 Boilerplate as a a starting point for css and html.
For a grid-based site, I might also use Fluid 960 GS
I write my code to be standards compliant first, and cross-browser friendly second. Don't kill yourself for the bad browsers.
You can use something like Modernizr to feature Progressive Enhancement. Here are some good reasons to do this
For bad browsers, let's just call it IE, wherever something is breaking, just give it more space, and make sure everything is readable. If you do that, it should look ok, but don't kill yourself trying to make it pixel perfect to the design. You can use that link in point 4 to explain to your client / boss why it isn't the same in every browser, and why that's a good thing, not bad.
If you can do all that, your code will be nicer to write, quicker to run and much closer to being future-proof.
If all else fails, use padding instead of margins whenever you can, and things will be more consistent when viewed in IE. And if you're supporting IE6 try and not use too many transparent png images.
There are some other good suggestions here, but I'll add one: YUI's reset CSS stylesheet. It gets rid of some of the more obvious incompatibility problems, without adding a whole lot of page weight.
QuirksMode.org is an excellent resource for browser compatibility information.
How many div tags in one HTML document would one need before it affects performance? In this case, the tags are not nested and the content within each is minimal (background color/image).
This question is a follow-up on a previous question;
Drawing lines with clickable points using JavaScript
Here I settled on doing this using HTML and CSS.
The <div> tags will have a width of at least 4 pixels, and a total width of 400-800 pixels, thereby 100-200 div tags.
On top of that, there will be five or six of these graphs/timelines stacked on top of each other. The number of div tags is then up in 500-1200.
Again, bearing that there is little content in each, how would this affect the performance?
_L
Test and find out. This will vary too much by rendering engine to answer generally.
While tag count surely has an impact when rendering html you will have to benchmark to see whether or not the time is acceptable or not.
Where I would be concerned is javascript functions that you may have that try to traverse the DOM. Looking through all those elements could be a costly operation on the client. Though once again, proper benchmarking can not be substituted.
The actual displayed size of the div has no noticeable affect on performance. Most of your performance is going to be lost in the transfer of the data to the browser and the rendering of all the elements. It should be a relatively linear decrease in performance luckily, and not something that cascades quickly.
The actual limit doesn't really exist in concrete terms, its more of an issue of the power of the person's computer and browser and connection. Needless to say, you can get pretty big without causing major problems.
The answer depends on a lot of things. Every single div tag has some tiny impact on performance. The tipping point for where performance starts to rapidly degrade will depend on the browser and computer viewing the page.
It also matters what CSS rules you have affecting those styles. Relatively speaking, some CSS selectors are fast to execute and some are slow to execute. If you have some slow CSS selectors defined, your tipping point will come much earlier that if you use no CSS or use only fast CSS selectors. Google's PageSpeed addon can give you insight as to whether you're using slow CSS selectors.
Also, if you're doing things like animating them as a particle system, your tipping point will come even faster.
If its anything like <font> tags, the answer is seemingly millions! Check out: http://www.fujinonbinos.com/ (do a View Source - seriously!)
Seriously, though, keeping things to a minimum is always good practice both for readability (code maintenance) and speed. However, this is unlikely to make a serious impact unless its ridiculous. Even the above example isn't that slow!
Having asked this question How to reach CSS zen?, I now understand that the issues I have are mostly related to positioning. I've found some articles telling that CSS is not always good enough as a layout system.
http://echochamber.me/viewtopic.php?f=11&t=40154
http://www.flownet.com/ron/css-rant.html
http://blog.workaround.org/2009/03/17/dont-abuse-css-for-page-layout/
Do you as CSS designers limit yourselves upfront to designs that CSS can handle? Should I avoid things that seems perfectly easy are in fact difficult to do with CSS?
Of course you limit yourself. As a designer, you should always think about the medium you're working with. If I were designing a magazine ad, I wouldn't be thinking about animations or video. There are certain rules you must adhere to, and it doesn't make sense to ignore that.
But of course, rules were always meant to be broken.
Why?
If you are "designing", why would you limit yourself based on a the limitation of one technology? When you design your site, you should always try to achieve the most usuable interface for the user.
If you do limit yourself, then you are just asking for the site to not be used, and then what's the point of creating it?
I don't limit myself upfront to any designs that CSS can handle (within reason of course), just figure out your design and there will be someway that you can get it looking right using CSS, but it might involve a lot of hair pulling, especially if IE6 is involved!
When implementing a web design (assuming I've got an image/drawing of what the site will look like) I always follow these steps:
I look at the design and determine what components it has. Examples are navigation areas, headers, content areas, and so on.
I implement (X)HTML that can represent the content areas without really taking the design into account (there are certain things such as content order that I use the design to determine.)
I start making the CSS and images needed for the site to look the same way it did in the original design document. Depending on the complexity of the design, I might come up short of elements to use for styling the page, and may end up adding elements that don't really make sense for the content. I try to avoid it as much as possible, though, and I try to create the elements in a way that isn't obtrusive to the content.
As you can see, I never limit the design to the capabilities of CSS. CSS comes last. Now, depending on the complexity of the design, it might not look exactly like it did in the original design document, but the goal is always to make it as identical as possible, while still maintaining clean HTML so that the design can easily be updated in the future.
Most layouts I find can be done with CSS. There are a very few exceptions (normally to do with verically centering text).
For me the main factor which limits my designs is a reluctance to use huge background images. If an effect can't be done by combining/repeating a few tiny bg images I tend to reject or tweak it. Eg a diagonal gradient on a box with curved corners which could be any height might fall into this category using CSS2.1
Almost every painter limits themselves to paint on canvas, almost every sculptor makes 3D shapes from stone or clay or metal...
But there's also the few who dream new dreams and create new things. Some flop, some shine.
Should you limit yourself based on what CSS can do with layouts? Not completely. I say dream big.
Once you've got your dream design, either figure out how to create it, find a technology other than CSS that can do it, or go start inventing!
You can do absolutely almost anything using CSS 2.1 as far as layout. Its a complete pain in the ass that has no reason to ever exist, but you can do rounded corners (using background images), gradient backgrounds (more background images) and all kinds of other bloated crap you don't need all together and still not completely destroy the semantics of your HTML.
Doing all that garbage and still attempting to be standards compliant reduces usability, because its the designers who need round corners and other frivolous crap and not the users. Usability tests have confirmed this. Sites that are bloated to accommodate presentation and usability at the cost of semantics and efficient fail in usability tests compared to their competition. I work for a website that gets several million visitors a day and I have seen the results of our usability tests.
CSS provides a very good way to create an overall design that easily can be changed by small changes in one CSS file, and instantly applies the design changes to all your pages. Of course there are things that are tricky to do with CSS, and in those cases you might want to do it in other ways, but even if your layout is mainly based on CSS, doesn't mean that you can't do some special parts using other technology! You can mix!
So you don't limit yourself when you go for CSS. You just make use of a powerful technology that can be used in perfect harmony along with others!
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.