i understand what there is a difference between id's and class's - ids and ment to be given to a unique item, and class's and like tags, they can be given to multiple items..
but why do you need to have both, in the past i used to write everything using #id (this was when i was new to writing html and didnt know any different) and the code still worked.. would not have been 100% valid but still worked.
i know now using html5 you can define areas differently, but for this im not talking about using html5
Imagine if you had a load of buttons that looked the same on the page. Would you want to repeat yourself numerous times in your CSS? Or use a class and write it once.
This is applicable in any case of the same styling on different elements.
Adding to Sam's answer. Ids are helpful both for styling and javascript. If you want only a particular style applied or want to increase the specificity of your css id come handy.
#id is used to describe the document structure or important containers/elements and they must be unique entries.
.class is used to describe elements which are can be many elements in this documents.
If you try to validate the document and have many id's this will be error and if you want your document to be valid you must rename the id's of use classes.
Classes are useful because they can be many classes with one name on your document and you will not be force to copy/paste style from one element to another and change only the tag to describe the new element.
concise answer:
id - Shows on your page once.
class -Shows on your page more than once.
Related
I would like to know if this is good practice, or if this is a wrong thing to do.
Thank you
You surely can. It actually helps when you want same kind of behavior for your DOM elements on different pages.
You can have common CSS and JS files for these HTML documents containing the code for elements with same ID's or classes. Reduces duplication of code.
If they only are different because they are in a different document, I would even go as far as to say they are not different. Of course you can give them the same ID. We do it with headers and footers all the time, why not with p-elements? Just don't add the same ID more then once in one document.
Regarding the question if this is good practice or not, that entirely depends on the use case and context.
id=identifier. One document can have only one unique id. So two documents can have the same id once in each document.
Think of #header. Multiple html documents will have #header. But only once in each document.
Although when duplicate id's are present in a document, browsers parse the code fine without complaining. But still invalid.
According to many recent HTML specs, when we are using custom attributes (meaning any attributes not defined in the spec), we should prefix them with data-. However, I see no reason to have to do this (unless you require perfectly valid HTML, obviously). Pretty much all current browsers correctly ignore custom attributes, meaning no conflicts except with identically-named attributes from others' code, and we can ignore even this with custom prefixes or something similar (as suggested on the AngularJS directive page). What, if any, other benefits are there? This question has been asked before, at least twice, but both are pretty old.
I forget where I read it, but some guide said custom HTML tags need dashes, and single-word tags aren't valid. First of all, why? Second, should we do this, and why (besides being valid)? Would there be any problem with underscores or camelCase, etc.? Also, conflicts with existing elements shouldn't be a problem, if, like with data attributes, you prefix or suffix them, etc. See the Angular directive page again.
I'm sure all these questions have been asked before, but I'm combining them into one. Is that a good idea (quick, someone ask on Meta)?
The data-* attributes have two advantages:
It is a convention meaning other programmers will understand quickly that it is a custom attribute.
You get a DOM Javascript API for free: HTMLElement.dataset. If you use jQuery, it leverages this to populates the keys and values you find with .data().
The reason for the - in custom element names is for two basic reasons:
It is a quick way for the HTML parser to know it is a custom element instead of a standard element.
You don't run into the issue of a new standard element being added with the same name which would cause conflict if you register a custom Javascript prototype for the DOM element.
Should you use your own custom element name? Right now it is so new that don't expect it to be fully supported. Let's say it does work. You have to balance the issue of the extra complexity with the benefit. If you can get away with a classname, then use a classname. But if you need a whole new element with a custom Javascript DOM prototype for the element, then you may have a valid usage of it.
I am working on some large web projects at work, and a lot of HTML ID's and Classnames are being used.
When I create something new in one of those huge projects, naming new ID's and classes can be frustrating, because I always end up with something like #subprojectname_title , .subprojectname_editor to make sure that I don't overwrite any classes and ID's that have previously been written for the "parent" project, and to make sure I dont inherit the previously written styles.
I always have to write subprojectname whenever I create a new class or id for that subproject, and thats quite annoying.
I'm looking for suggestions on how I can make my selectors shorter, without having to reset the style to make sure I dont inherit from the previous selector, and without messing with the previously written styles (overwriting them, changing their names).
I have a simple solution for this in my projects.
I use "unique" names for globally effective styles and "common" names for local scope.
i.e. My site.css uses names such as "defaultList" or "defaultWhiteButton", where as my pageX.css uses "list" and "button".
I never make use of IDs for my selectors, since IDs are used (in my purposes) for all programmatic behavior and not cosmetic.
I make use of classes only in my CSS.
I hope this helps.
Instead of .subproject_thingie1 and .subproject_thingie2 everywhere I usually go for adding a root class or id to differentiate between projects/pages.
That way you can have global styling maintained on all pages on the same class names while being able to add specific rules for specific pages.
But as always, the best solution depends on how well the existing project is written.
I am developing a library of HTML components. The underlying technology is not relevant; the code for each component just generates HTML that is ultimately sent to the browser.
The problem I'm having is that a lot of the generated HTML needs to be styled by the application. And I don't know ahead of time exactly what that styling might be. Also, the generated HTML tends to have several divs and spans for, each of which might be styled differently. Think of something like a calendar component and all the different ways that might be styled.
At first I thought I'd just assign a class to every non-trivial element. I prefixed all my class names with "foo" (the name of my library), so the div for the calendar component has class foo-calendar. But inside the components I started to wonder about this approach because I kept having to make up weird names for all the various divs that make up each one. And what about when there's only one tag of a certain type in the component? Do I still give it a class even though it doesn't add any additional meaning?
The I started thinking that I'll only add enough classes to uniquely identify each tag. So if there's only one input field in the component, I won't give it a class at all, because the CSS selector ".foo-calendar input" will find it. But this approach seems a little too subjective.
Another question I have is, do I prefix all my class names with the name of my library, or only the "top-level" classes? Or do I nest the class names? In other words if the calendar has class foo-calendar, then does the month display have the class "month" or "foo-month" or "foo-calendar-month?"
What strategies do you follow for assigning CSS classes to library HTML?
I'd say more classes is better (to make css selection easier), and namespace them all (to avoid collision), but I'm imagining a WordPress plugin or something modular that I might want to plug into my existing website.
I really like the way Gravity Forms structured their html classes, because it makes it easy for me to tweak and customize without having to touch the markup, so if that's what you're looking for, maybe take a look at their CSS Guide: http://www.gravityhelp.com/gravity-forms-css-visual-guide/
I suggest looking into OOCSS (Object Oriented CSS).
Code - https://github.com/stubbornella/oocss
Introduction - http://www.stubbornella.org/content/2009/03/23/object-oriented-css-video-on-ydn/
I personally like this method because it feels easier to style elements on the page.
The basic idea to evaluate the styles you have on your page then create some general purpose classes that can be applied throughout your site. Sometimes I get very granular and I create a class like .bold {font-weight:bold} but most of the time this should not be done. Also another key idea is to separate CSS structure (your grids, positioning, etc.) and your styles (colors, font-weight, backgrounds, etc.). This is done to improve maintainability.
If you find a common theme in how your widgets are styled then break that out into a class and apply as needed. For example, all over the web there are elements that have an image to the left and text on the right. See your SO signature at the bottom of your question here. This could be made into a generic class that could be applied any instance of a widget with an image to the left and text on the right.
If you add a reset declaration you don't need to prefix all your classnames. You'll find a proper reset-css in several css frameworks.
I would use as less as possible classes for your elements (and would use no IDs), as you have described in the 4th paragraph.
Of course if you do this, your css selectors are becoming very long - but maybe you could use SASS/SCSS to prevent totally chaos ;-)
Why is it bad practice to have more than one HTML element with the same id attribute on the same page? I am looking for a way to explain this to someone who is not very familiar with HTML.
I know that the HTML spec requires ids to be unique but that doesn't sound like a convincing reason. Why should I care what someone wrote in some document?
The main reason I can think of is that multiple elements with the same id can cause strange and undefined behavior with Javascript functions such as document.getElementById. I also know that it can cause unexpected behavior with fragment identifiers in URLs. Can anyone think of any other reasons that would make sense to HTML newbies?
Based on your question you already know what w3c has to say about this:
The id attribute specifies a unique id for an HTML element (the id
attribute value must be unique within the HTML document).
The id attribute can be used to point to a style in a style sheet.
The id attribute can also be used by a JavaScript (via the HTML DOM)
to make changes to the HTML element with the specific id.
The point with an id is that it must be unique. It is used to identify an element (or an anything: if two students had the same student id schools would come apart at the seems). It's not like a human name, which needn't be unique. If two elements in an array had the same index, or if two different real numbers were equal... the universe would just fall apart. It's part of the definition of identity.
You should probably use class for what you are trying to do, I think (ps: what are you trying to do?).
Hope this helps!
Why should I care what someone wrote in some document?
You should care because if you are writing HTML, it will be rendered in a browser which was written by someone who did care. W3C created the spec and Google, Mozilla, Microsoft etc... are following it so it is in your interest to follow it as well.
Besides the obvious reason (they are supposed to be unique), you should care because having multiple elements with the same id can break your application.
Let's say you have this markup:
<p id="my_id">One</p>
<p id="my_id">Two</p>
CSS is forgiving, this will color both elements red:
#my_id { color:red; }
..but with JavaScript, this will only style the first one:
document.getElementById('my_id').style.color = 'red';
This is just a simple example. When you're doing anything with JavaScript that relies on ids being unique, your whole application can fall apart. There are questions posted here every day where this is actually happening - something crucial is broken because the developer used duplicate id attributes.
Because if you have multiple HTML elements with the same ID, it is no longer an IDentifier, is it?
Why can't two people have the same social security number?
You basicaly responded to the question. I think that as long as an elemenet can no longer be uniquely identified by the id, than any function that resides on this functionality will break. You can still choose to search elements in an xpath style using the id like you would use a class, but it's cumbersome, error prone and will give you headaches later.
The main reason I can think of is that multiple elements with the same id can cause strange and undefined behavior with Javascript functions such as document.getElementById.
... and XPath expressions, crawlers, scrapers, etc. that rely on ids, but yes, that's exactly it. If they're not convinced, then too bad for them; it will bite them in the end, whether they know it or not (when their website gets visited poorly).
Why should a social security number be unique, or a license plate number? For the same reason any other identifier should be unique. So that it identifies exactly one thing, and you can find that one thing if you have the id.
The main reason I can think of is that multiple elements with the same
id can cause strange and undefined behavior with Javascript functions
such as document.getElementById.
This is exactly the problem. "Undefined behavior" means that one user's browser will behave one way (perhaps get only the first element), another will behave another way (perhaps get only the last element), and another will behave yet another way (perhaps get an array of all elements). The whole idea of programming is to give the computer (that is, the user's browser) exact instructions concerning what you want it to do. When you use ambiguous instructions like non-unique ID attributes, then you get unpredictable results, which is not what a programmer wants.
Why should I care what someone wrote in some document?
W3C specs are not merely "some document"; they are the rules that, if you follow in your coding, you can reasonably expect any browser to obey. Of course, W3C standards are rarely followed exactly by all browsers, but they are the best set of commonly accepted ground rules that exist.
The short answer is that in HTML/JavaScript DOM API you have the getElementById function which returns one element, not a collection. So if you have more than one element with the same id, it would not know which one to pick.
But the question isn't that dumb actually, because there are reasons to want one id that might refer to more than one element in the HTML. For example, a user might make a selection of text and wants to annotate it. You want to show this with a
<span class="Annotation" id="A01">Bla bla bla</span>
If the user selected text that spans multiple paragraphs, then the needs to be broken up into fragments, but all fragments of that selection should be addressable by the same "id".
Note that in the past you could put
<a name="..."/>
elements in your HTML and you could find them with getElementsByName. So this is similar. But unfortunately the HTML specifications have started to deprecate this, which is a bad idea because it leaves an important use case without a simple solution.
Of course with XPath you can do anything use any attribute or even text node as an id. Apparently the XPointer spec allows you to make reference to elements by any XPath expression and use that in URL fragment references as in
http://my.host.com/document.html#xpointer(id('A01'))
or its short version
http://my.host.com/document.html#A01
or, other equivalent XPath expressions:
http://my.host.com/document.html#xpointer(/*/descendant-or-self::*[#id = 'A01'])
and so, one could refer to name attributes
http://my.host.com/document.html#xpointer(/*/descendant-or-self::*[#name = 'A01'])
or whatever you name your attributes
http://my.host.com/document.html#xpointer(/*/descendant-or-self::*[#annotation-id = 'A01'])
Hope this helps.