which is better between the two kinds of css reset? [duplicate] - css

This question already has answers here:
Why don't CSS resets use '*' to cover all elements?
(3 answers)
Closed 9 years ago.
*{
margin: 0;
padding: 0;
}
and
body,div,dl,dt,dd,ul,ol,li,h1,h2,h3,h4,h5,h6,pre,code,
form,fieldset,legend,input,button,textarea,blockquote,th,td,p...{
margin:0;padding:0
}
the first is simple,and I like it.But why many big web sites use the second method

The universal selector (*) selects all elements on a page. This is great, but this selector would end up unnecessarily targeting elements which shouldn't realistically have no margin or padding by default.
Targeting specific elements is more logical as you wouldn't then have to override this CSS later on. For instance, if you wanted all instances of li elements within your document to have both margin and padding, you wouldn't want to include it within your list of selectors; equally you wouldn't want this to be targeted with * as it would add (albeit a very minuscule amount) to the time it takes for your page to render.
Nowadays a lot of websites actually make use of Normalize.css (direct link to stylesheet) to reset CSS:
Normalize.css is a customisable CSS file that makes browsers render all elements more consistently and in line with modern standards.

The first one does not clutter your debug tool (like Firebug) but the second one is more customizable as you can choose the elements that are not reset. Usually CSS reset files do not reset element like input, select or button and use the second form.

You should use SECOND ONE
because this is
Best one
logically correct
sometimes we need to use default properties of HTML elements.

Related

Contextual CSS reset after YUI Normalize.css

I am building a widget. The widget will be deployed in other websites. I need to ensure that the styling of the widget is consistent across all websites. When deployed it will exist as follows
<div id="myWidget>Some content and child divs, etc.</div>
I understand that to remove all styles set by the host website the css is
#myWidget * { all: initial; }
This isn't an ideal solution as you start from barebones and need to apply styling for every element on top of that. My question is, if I want to use css frameworks e.g. https://getbootstrap.com or https://purecss.io how do I make them contextual and only apply to the elements contained within the #myWidget div - i.e. not affect elements outside of the widget?
https://yuilibrary.com/yui/docs/cssnormalize/ used to do this, but unfortunately is no longer supported (as of 2014) and I'm finding that some items need to be manually reset e.g. box-shadow.

Difference between id and class [duplicate]

This question already has answers here:
What's the difference between an id and a class?
(17 answers)
Closed 7 years ago.
<div id="stockexchange-id" class="stockexchange-class">Text</div>
In the example above I added both a class and an id into the div statement. Is there a difference between them? If I call .stockexchange-class CSS instead of #stockexchange-id CSS does it make any difference? If it doesn't then what it the point of having both of them? Also which one would be better to use?
The biggest difference is that a document can have multiple elements with the same class, but not with the same ID. An Identifier must be specific to a certain element within a document (i.e. full HTML page).
When applying CSS styling, some experts have recommended using classes over IDs to avoid specificity wars. CSS Lint (http://csslint.net/) recommends this.
The reason is that stylesheets are read from top to bottom, but IDs take precedence over class. This means that:
#stockexchange-id {
color: blue;
}
.stockexchange-class {
color: red;
}
Would color the text blue, even though red comes later. Here's a good graphic explaining specificity: https://stuffandnonsense.co.uk/archives/images/specificitywars-05v2.jpg.
If everything has the same specificity, and most styles are applied via a single class, it makes the CSS easier to reason about, since it will read from top to bottom without extra styles being mixed in different orders. It also makes it easier to override classes, which can be useful.
Finally, if you style based on classes, you can re-use the styling on the same page by applying the class to another element on the page. With IDs, since they are unique, you cannot do this. Even if you think an element is unique on a page (e.g. a Buy Button), this may not always be the case. A designer may request the same element again later in the page.
You can only use an ID name once in any XHTML or HTML document. Duplicate ID tags will cause your page to fail validation, and can have negative effects when using JavaScript with them. Simply put, an ID is like the sticker that says "you are here" on a mall directory, and there can only ever be one of those.
Classes, like ID's, can also be used to in JavaScript scripts, but unlike ID's, they can be used multiple times in the same HTML document. This separation of content from presentation is what makes sites powered by CSS more robust, but some don't know the full extent to which they can use classes.

CSS reset that sets everything to default values

I'm working on a browser extension that adds it's UI to the pages DOM. On some pages I have the problem certain styles affect my UI. To counter this I keep my UI underneath a common root which resets most of the styles to the default value.
Sometimes I missed things which causes visual glitches in my UI. (i.e. the pages CSS file sets form { width: 80%; } so I need to add form { width: auto; } to my reset styles.
Is there a collection of styles that reset every CSS attribute to the value that is declared as default by the standard for every element?
I have come across the same problem. The usual CSS normalizers listed by the other answers does not answer the question because it is made to cancel the differences across the browser's default styles.
In the context of an extension, I needed to cancel every specific style that may exist on a random website.
I have come across this solution (I am not sure if it was possible at the time of the question, 7 years ago).
.your-container-class,
.your-container-class *,
.your-container-class *::before,
.your-container-class *::after {
all: initial;
}
So far it seems to achieve the goal by removing the differences across websites. The downside is that it resets even some default styles (ol, ul, li not behaving like lists for example).
Eric Meyer’s “Reset CSS” 2.0
(the original one)
HTML5 Doctor CSS Reset
(extends the Eric Meyer's one to improve HTML5 tags reset)
Yahoo! (YUI 3) Reset CSS
(based on Normalize.css)
Universal Selector ‘*’ Reset
Normalize.css 1.0 2.1.3
("…as used by Twitter Bootstrap, HTML5 Boilerplate, YUI 3, Pure, TweetDeck, Soundcloud, Medium, NASA, GOV.UK, Guardian, Rdio, Favstar, iA, and many others.")
There are others, but this were (and still are) the 2012’s most popular CSS Reset scripts.
I recommend using a quick Google search to find something like so: http://meyerweb.com/eric/tools/css/reset/
You can implement the reset in as-is and then if any problems arise down the road, simply add to it as needed.
Be aware that some pre-made CSS resets require a shout-out to using them.
Yes, absolutely.
There are two schools of thought to this. One is the zeroing style reset sheets, which basically remove all margin, padding and other such settings from the css. A good example of this is Eric Meyer's Reset CSS
The other approach is to set everything to roughly what you'd sensibly expect it to be, setting a reasonably looking margin to paragraphs and headings, indenting lists etc. A good example of this is Normalize.css
Some browsers also support the initial value, which sets the value of a property back to what it intially was. It's not widely supported enough to use in production, IMO.
Html5 boilerplate has an normalize.css which sets al lot of css styles to a default.
http://html5boilerplate.com/
As you are applying your styles to different pages with different unique styles, its hard to say if you will get success on removing all styles from all pages with some CSS reset.
But maybe these can help:
Normalize.css (used by many CSS frameworks)
CSS Reset by Meyer

Universal Selector CSS

Is it a good habit to use in CSS universal selector to set some properies of many elements. I mean, for instance:
* {margin: 0; padding: 0;}
Maybe default values are logical and we shouldn't change them all in the one line.
This issue with the universal selector is that you are going to remove some potentially useful browser defaults on some elements, just to have to explicitly add them back at a later time.
In other words, a user is going to have to download a CSS style to put back padding or margin on an element that already had perfectly acceptable padding or margin without any download.
If you are looking to make elements render the same across all browsers, I would suggest you check out normalize.css, which tries to keep as many browser defaults in place as it can.
The universal selector is good for troubleshooting. If absolutely stumped on elements that are causing overflow issues I'll do * {border:1px solid pink}. Be sure to remove once troubleshooting is complete.
The universal selector does cause a performance issue so try to avoid it.

E#myid vs. #myid CSS Selectors

I'm curious what the difference is b/w E#myid vs. #myid (E is any element) given that there can only be one element with #myid on a page?
It must be a bug/mistake of you that #myid has no effect on the input element. It works fine for me.
As you changed your question:
Image you have two different documents that both use the same stylesheet. In one document a DIV element has the ID “foo” and in the other document a SPAN element has the same ID. You can then use the following stylesheet to style both element different:
#foo {
color: #FFF;
}
div#foo {
background-color: #F00;
}
span#foo {
background-color: #0F0;
}
Both elements would then have the same font color but a different background color.
They have different specificity.
http://www.smashingmagazine.com/2007/07/27/css-specificity-things-you-should-know/
The two selectors have different specificity. Rules given in a more specific selector will override rules given in a less specific one.
The specificity rules are really easy. Whenever there is a conflict (two or more rules setting different values on the same element), the following rules are consulted in order:
1) What 'space' does the rule live in? A rule in a higher 'space' automatically wins against rules in lower spaces:
a) Set by the user's stylesheet, with !important
b) Set by the author's stylesheet, with !important
c) Set by the browser's stylesheet, with !important
d) Set in a style="" rule
e) Set by the user's stylesheet, without !important
f) Set by the author's stylesheet, without !important
g) Set by the browser's stylesheet, without !important
2) How many #ids are in the selector? Selectors with more #ids automatically win against selectors with less (assuming they tied in rule #1).
3) How many .classes or :pseudoclasses are in the selector? Selectors with more .classes automatically win against selectors with less (assuming they tied in the previous rules).
4) How many plain elements are in the selector? Again, more is better.
5) Finally, how far down in the document is the rule? Later rules override earlier rules, if they are tied on all previous categories. This applies within a document (at the bottom of your CSS file vs at the top) and between documents (any rules in the second <link>ed css file are 'later' than the rules in your first <link>ed css file).
Understanding specificity can help you write simpler CSS. I almost always start my selectors with the closest #id that I can, because it simultaneously limits the spread of the selector to exactly the elements that I want, and automatically overrides any 'global' css rules I may have set in the document.
The difference is that in different pages you could have different elements using that ID. Why you would do that, is beyond me, but it could be needed for (just an example) a div on some pages taking the same attributes as a span on other pages.
Different browsers will give you different and strange results on non specified corner cases. Some browsers allow for multiple elements sharing the same id, others don't. It even changes with different versions of the same browser. Without knowing wich browser you are using, it's harder to replicate the bug, but I recommend you to test your css on several browsers.
Along with the other folks points about ID not necesarily being unique on a page...
It is possible to have one ID applied to either of N different elements (eg <UL Id=MyList> or <OL Id=MyList>). Then you could have different bits of javascript to handle the various elements (ie. a bit of code to handle UL, a different bit of code to handle OL).
Not saying whether or not that's would be a good design... just saying that it's possible.
Edit: what I mean is that the server side could generate a page with either an <OL> or a >UL>... not both at one time. Think dynamic web page. And again... I'm not saying one way or another if this is a good design... just that it IS POSSIBLE.

Resources