I am simply wondering if there exists a global CSS reset for CSS3. Something along the lines of the commonly-used versions created by Eric Meyer or YUI, but for CSS3 specifically. I've queried channels such as Google, Github and here on SO, but haven't come across a comprehensive solution.
Edit:
The term "reset" is probably misleading since it deals mainly with resetting browser default settings. "Recalibration" may be better suited.
I should clarify and put forth a use case.
This would work in tandem with the normal CSS reset yet also handle any styling caused by rotation, box shadow, animation, border radius, etc. For example, as mentioned before on this post:
-webkit-transform:none; /* Safari and Chrome */
-moz-transform:none; /* Firefox */
-ms-transform:none; /* IE 9 */
-o-transform:none; /* Opera */
transform:none;
The above snippet, and others like it, would be associated with any HTML tags that might get affected by them, as it is with current CSS resets.
The implementation need for this would probably not be too common if you are in control of your properties. However if you are, for example, creating an app or plug-in that will be used across different domains, where the styling of the pages the plug-in script is invoked on can influence that of the plug-in itself, then something like this would be very useful.
I realize there are other ways to tame CSS inheritance and handle cross-domain issues, but this question is put forth regarding the CSS3 reset directly.
Much thanks.
The real way to solve your problem is either to use the scoped attribute, or to create your widget using the Shadow DOM.
This way, you can insulate yourself from external CSS. Unfortunately, neither are really ready for use, so yes, you'll have to manually protect yourself.
The alternative is to set everything (transform, font-size, padding, etc) in your code with !important, rather than resetting it to 0/none, then setting it anew.
Related
I'm not sure this is possible, but id like to set all user styles back to chrome defaults for div and descendants.
I'm building a Chrome plugin that creates a popup on any web page, however due to the fact every page has a plethora of custom styles, trying to track down every inconsistency and overwrite it with my divs (and descendants) custom style, it is becoming a nightmare.
Every time I think I've covered all bases another site implements something else that needs to be overridden.
What would be the easiest approach to standardize my popup in this situation?
One approach I can think of is to (bite the bullet) and get a hold of the the default Chrome CSS styles and implement them into a series of catch all descendant selectors, however surely there is a better way.
If you want to be absolutely sure that the styling of your elements is not affected by the web-page's CSS, there are 2 possible solutions:
Use an iframe to implement your popup. (This solution is "safe" and simple enough, but based on the kind of interaction between the popup and the web-page it might become cumbersome.)
Utilize the Shadow DOM. (This is probably the "proper" solution, but the implementation might be a little more complicated.)
Some resources regarding the 2nd solution:
An introductory tutorial.
An actual example of incorporating the "Shadow DOM" concept into a Chrome extension:
RobW's Display Anchors extension
There is a third option worth discussing and rejecting, which is to reset all the style properties of the div and its descendents to its default value. Pseudo-code:
#my-div, #my-div * {
#for-every-css-property {
%propertyName: initial !important;
}
}
This answer shows an attempt at such a solution. It uses specific values instead of initial which will work in older browsers without the initial keyword, but will not correctly reset elements which have a different default from the base (e.g. user566245 mentions that textarea elements should have a border).
Issues:
Unfortunately initial is not actually the browser's default value.
If we don't use !important above then there is a risk that the page might have provided a rule with a more specific elector which overrides our own. For example if the page specified properties for table > tr > td then this would be applied over our rule because that selector is more specific than #my-div *.
Since we do use !important, any custom styling we want to do after the reset must also use !important on every property.
If the page happens to inject any additional CSS styles after ours that uses !important then these can override our reset.
It is rather inefficient. We are asking the browser to apply a huge bunch of CSS rules to every element under our div.
Vendor-specific properties should also be reset. (E.g. -webkit-animation-name.)
If new CSS properties come into existence in future, you will need to update your list.
Whilst this solution can be applied to current browsers, it is rather horrible, so roll on Shadow DOM! I would recommend the <iframe> solution in the meantime.
I don't know if anyone has tried this, but a more efficient solution might be to use Javascript to detect what site-defined CSS properties could be problematic, and reset only those.
I have a website which I support as far as IE8, no further.
When I first launched the site, I decided to use CSS vendor prefixes for CSSs elements such as border-radius, box-shadow etc. I did this from a complete noob standpoint.
However, is a better approach not to use them and simply let browsers catch up rather than patch up for the sake of uniformity?
No, you shouldn't remove all of them, however you may as well remove the ones which are no longer required.
How can I find out which prefixes are no longer required?
Can I use... is a great resource for checking browser support for various CSS, HTML and JavaScript features. If you perform a search for box-sizing, for instance, it will tell you that all modern browsers have partial support for this and that Firefox requires the -moz- prefix. You can also view all of the CSS support tables on just one page here.
How can I clarify that the prefixes are no longer required?
There are a couple of online resources which display information about browser usage. An example of this is StatCounter. StatCounter offers browser version statistics which can be filtered on time. If we look at the last 3 months, we can guestimate that we should still aim to support Firefox 20+, Chrome 25+, IE 8+ and Safari 5.1+.
Personally, I would just keep your vendor prefixes for now - this still remains professional practice - those browsers who don't need them, will simply ignore them anyway.
Our approach is to drop those which aren't needed.
border-radius
box-shadow
box-sizing (soon? firefox still uses it. Noted by #James Donnelly)
opacity (not a prefix, but no need for the ms-filter thingie)
inline-block (same here, no need for inline+zoom fix)
If you really want to get rid of prefixes, one of the solutions you can try is -prefix-free. It's a javascript plugin which loops through your stylesheets and, according to current browser removes the unused ones.
Although I didn't test it, I think it will definetely lower the performance.
You can also remove prefixes for properties which doesn't have a signifact meaning for functionality and/or user experience, like border-radius, box-shadow etc. You would have to test each element how it behaves without these properties. E.g. you have a button with border-radius: 4px. In a browser which doesn't support border-radius it will simply have rough corners. You must only consider if its worth sacrificing.
I'm almost done with a project and now I'm facing a problem I don't know how to solve.
I did the whole css styling with the box-sizing: border-box (with ie6/7 polyfill) applied and it worked like a charme on every device I tested, until I picked up a blackberry. It doesn't support box-sizing (actually it does, but only from the very last version) and now all my layout is broken. Since the project is almost finished I don't want to go back and update every single stylesheet to not use that css rule. What do you think would be the best way to tackle this?
speaking about this:
http://caniuse.com/#search=box-sizing
Thank you
The first suggestion is that you could perform a server-side detection of the BlackBerry browser and if the version detetcted doesn't support the box-sizing property just send to the client an overriding stylesheet on the cascade, containing all the necessary rules (with an higher specificity, of course) to correct the wrong style.
Otherwise, if this method still need too much work to fix, you could try to serve a non-strict doctype for that specific browser only and see what box-model is used by that browser. For sure it's a bit hacky method, but maybe this change could have some good impact and "straighten" your layout.
I'm not too sure if it is refered to as "Master Reset" but you'll know what I mean.
Ive been using
*{
padding: 0;
margin: 0;
}
With no real problems that I have noticed but ive heard people say that its bad practice to use something like that. So ive looked into reset stylesheets and found this which seems good. But im not sure if its worth using that if there are no problems with using *{foo:bar;}
I hear some people say that in some browsers it messes up with the styling of form inputs. I used to use this, until I stumbled across the meyer reset, which just seemed like a safer, proven approach.
There are arguments for and against CSS resets. The general idea is that by "zeroing-out" all properties you're given a consistently blank canvas across all browsers to which you can apply your custom styles.
The problem with using a reset is that everything will be reset - so, you need to specify custom styles for everything, or at least everything you're going to be utilising within your site.
Read Snook's view: http://snook.ca/archives/html_and_css/no_css_reset/
I often see sites with odd styles applied in commenting systems. For example, I might leave a comment with a <code> tag and because the site uses a css-reset the code tag has no special styling, making it visually pointless. This is only a problem with those full-on resets, like Meyers or Yahoos. Developers forget to apply styles to reset elements... Your flat-reset, while simple, has other ramifications.
In my opinion it's better to have no reset and just style each element on top of default styles offered by the browser.
I think this is just personal preference, the more complex your styles get the more it matters and a more specific reset style sheet may matter. All that matters is that your sites look like they should across all reasonable browsers (and by reasonable at this point I'm not including anything IE6 or prior).
I've switched to only a handful of resets to handle negative margins in extreme cases, otherwise most current browsers seem to be pretty consistent, a very different ecosystem than a few years ago.
Should the following be shunned, or praised for its simplicity?
For the record, I use it in every site I build, but I've noticed it's not present in many main-stream CSS-reset frameworks — is there a reason they don't use it too?
* { margin: 0; padding: 0; }
Its best NOT to use it as it causes issues with form elements, especially input buttons and select boxes.
See christianmontoya.com
The universal selector can slow things down quite a bit, especially on some WAP browsers. Just think about it for a second: it matches every single element in the document tree.
Besides, for most elements, you'll go on and specify a margin/padding that is different from 0 anyway. As in, there's no point in resetting them for all elements to begin with.
Something you definitely don't want to do is use relative sizes with the universal selector. Things get weird really quick if you do. ;-)
For a good baseline to work from, I'd recommend a tried and tested reset stylesheet.
I once did some performance testing between the * {margin:0;padding:0}, Eric Meyer's reset, the YUI reset and no CSS at all. The performance difference was negligible.
That said, I now use Eric Meyer's reset so I don't lose the formatting on input buttons which actually makes buttons easier to style cross-browser.
If your intent is to set the padding and margin of every single element, then there should be no problem with that selector.
There's nothing particularly wrong with it. * is referred to as the "universal selector", and browser support for it is generally considered to be good, though IE does have some obscure bugs, as usual:http://reference.sitepoint.com/css/universalselector#compatibilitysection
I consider it an important first step in building my CSS layouts. It removes a lot of the troublesome default styling of different browsers and allows me to get more browser-independent results.
Of course I couple it with IE's conditional comments to write IE-version-specific divs around my whole page, and use those to work with IE's bugs (as FF et. al. tend to be more accurate to CSS spec).
EDIT - and I've never noticed any performance problems with it.