Often times I see something like this:
<body>
<div class="container">
</div>
</body>
Why not just do:
<body class="container">
</body>
You are perfectly free to do any of the following:
add a class or id attribute to the body element;
directly apply CSS to the body element, with or without class or id attributes; or
directly apply CSS to the html element, although without the class or id attributes and with some important caveats.
Any of these are perfectly legitimate uses of CSS and HTML.
Why <div id="container"/>? Through the years, many CSS techniques have employed arbitrary container elements for conceptual simplicity, to avoid certain cross-browser inconsistencies or because they were simply too complex to be achieved otherwise. A couple of more subtle reasons include that in older browsers, one could not apply CSS to the html element directly, and there were (and are) certain unusual or restricted properties for those elements—often for obvious reasons. (They were sometimes described as being "magic" for this reason.)
These all conspired to create a situation where to achieve almost any moderately complex layout, it was inevitably much easier to just start out with a squeaky-clean container element. Though the practice started as a means to an end it soon became just part of the scenery, and now many developers don't think twice about adding that sprinkling of extra markup.
No, there is nothing that says you can't add a class to the body.
Attaching a class to the body is actually quite common in various CMSes and is very handy for theming or styling specific pages.
From looking at your example, if you just want to use the body as a container, why even bother with the class? There should only be one body element, so just call that in your selector.
Walter, it may make sense if you needed to apply a slightly different subset of styling to a page with a custom body tag.
Using a wrapping div is usually for some presentational reason and make not make sense semantically; if you don't need it for your project, don't use it. Sometimes only using the body tag to contain the page is too inflexible for some layouts, and as Jordan says some old browsers cannot apply CSS to the root element.
Related
I've developing an app with Vue, and a third-party template, and dynamic plugins, and all kinds of trickery. I'm have a really hard time with the CSS.
Often I need to style particular element on the page, an <input> for example, and I can't figure out how to write a selector that actually works. The input may have been created dynamically by some Javascript and may have had CSS applied programmatically.
So I go to Firefox Web Developer, click on the element, and see a bunch of CSS classes. I create a rule:
.myCustomClass {
color: red;
}
put myCustomClass in the class="" tag in the <input>, and... nothing.
I'm thinking I need to prefix it like this:
.someOuterClass .someInnerClass .myCustomClass {
color: red;
}
but that rarely works. Sometimes I give up and add !important. Sometimes that works, and sometimes it doesn't.
So my question is, can I examine the classes that I can see in Web Developer and somehow derive a rule that is specific enough that it will always work?
I've read about specificity, but it's not helping.
Specificity is a PITA sometimes, especially when other 3rd party libraries are adding stuff to the mix.
Here are a few things you can try:
Make sure to add your styles to the END of the CSS. Theoretically, you can affect the order Webpack includes CSS (I've never tried it)
Add an ID not a class to a wrapper outside the elements you want to change. Then reference this ID in the CSS chain eg: #myAppID .className .subClassName {} Basically ID's are stronger than classes in CSS specificity. I would try to do this at a page/view level to make life easier.
If elements are already getting classes (as you see them in the inspector) try to reuse those classes with your "override" CSS. If the classes are modularized (Have a random suffix like someClass__34xft5) you shouldn't use those exact classes since they can change if the source is recompiled. In that case, use a "matching" selector [class^=”someClass__”] to match any selector with that prefix.
Not sure how deep you want to go, but here's an article about overriding Amplify-Vue prebuilt styling.
One caveat, if the CSS is being added inline via javascript somewhere, it's going to be very hard to override. You may want to use !important in conjunction with the above.
"...can I examine the classes that I can see in Web Developer and somehow derive a rule that is specific enough that it will always work?"
Probably, but why bother? You're already adding class attributes to elements. Why not add inline style attributes instead? Adding a bunch of classes or ids just to create a specificity chain to touch up styles is pretty messy...inline styles are barely if at all worse and are clearer to understand.
Inline attributes are the most specific CSS instructions you can give.
My professor asked us to develop a website using pure HTML,
JUST HTML. And it's really hard to design without CSS but I have to follow her instructions.
Anyway, my question is do you consider this code as CSS even if I removed the type="text/css"?
<style>
a {color:white; }
</style>
This maybe a dumb question but thanks for your time to answer it, I just really want to use CSS to make it easier.
Could you suggest anything that would make my coding easier? I just don't want to have repetitive code.
You are having this snippet,
a {
color:white;
}
is an element selector with the color property, whatever you write, i.e, between <style> tag, or style attribute, or stylesheet, all are CSS, if your professor is vintage fan, and is asking you to assign the color to a than you can use the font tag with color attribute with a value of white
<font color="white">Hello</font>
Demo
Note: Please read the box on the Mozilla Developer Network which says
SO DON'T USE IT
And just incase your professor understands, and his mind comes back to 2014... than would like to point out that even using
a {
color: white;
}
will target all the a elements in your document, so make sure you use a class or a specific selector to select particular a element.
Anyway, my question is do you consider this code as CSS even if I removed the type="text/css"?
CSS is CSS, not matter how it is added to the document or labeled.
it's really hard to design without CSS but I have to follow her instructions.
Could you suggest anything that would make my coding easier?
I'd start by clarifying if CSS really is forbidden and, if it is, what the purpose of forbidding it is. I can think of a number of possible reasons:
To prepare you to deal with code written by someone from 1996
To make you focus on the structure and semantics instead of the appearance
The course you are taking is almost two decades out of date
How you deal with the problem depends on which of those is the reason.
If it is the first one, then you need to look at all the obsolete, deprecated (and possibly non-standard too) presentational features of HTML (like <font> and background attributes).
If it is the second one, you just don't worry about how it looks and deal with the structure and the semantics. Let the browser's default stylesheet control the way it looks.
If it is the third one, then you probably have little option but to grit your teeth and bare it or find a better course.
<style>
a {color:white; }
</style>
Yes you write type="text/css" or not it will be considered as css.
The content of a style element is CSS, for most practical purposes (it would hardly make sense to use anything else there, since no other style sheet language is supported by browsers). The attribute type="text/css" does not change this, because the de facto default style sheet language is CSS.
On the other hand, the style element, including its content, is HTML. The content is not defined in HTML but in other specifications. Similar considerations apply to style attributes, as in <a style="color: white">...</a>: the attributes are HTML, and but they contain embedded CSS.
When you are told to use “pure HTML, JUST HTML”, then you are probably expected to refrain from using CSS or JavaScript in any way. On the other hand, you are probably allowed to use images, even though images are not HTML but are used via external references or data: URLs. There is nothing particularly logical in such a requirement.
As suggested in other answers, simply do not try to control the rendering of the page. Worry about the rendering only if it becomes intolerably messy and there is a reasonable way to prevent that in “pure HTML”. For example, don’t try to set link colors (this would in fact be an improvement over the way most web pages deal with links), backgrounds, fonts, etc. But if you use e.g. a data table, consider using , which often makes a table essentially more readable.
Yes, you can:
and too you can put style inline in your body or header
<style>
a{
color: #ffffff;
}
</style>
and so, all your css you can write it in your native .html without use of another .css file
I just wonder why should I use "class=" identificator instead of my own "tag"()?
Class example
<span class="red"> Hello there! (using class)</span>
.red {color: red;}
Tag example
<div id="reddiv">
<red>Hello, there (using own tag)</red>
</div>
#reddiv red {color: red;}
Its much more easier for me to use my own tags, since its faster to write.
Can you please tell me if doing it in first/second way has any negative/possitive sides?
While this may work in most browsers, your HTML then loses context. When an application like a search engine (or screen readers or anything else that looks at the source) parses your document, what is it to make of a tag named 'red' or 'purple' or 'job'? It won't have context, so you'll lose out. HTML uses a set of predefined tags that have meaning, you can venture out of it but you'll lose the advantage of everyone instantly understanding (all or part) of your document.
If this document is part of a data transfer framework and not on the public web, you should look at XML.
There are many advantages of using class.
First of all, with class, we use css styles which gives a lot more configuration options than simple HTML tags.
We give all the styles and formatting at one olace and just call the class everywhere we want to apply those, which in big projects like ERP, makes a big difference in code size.
The css style is more compatible with latest versions of browsers and a lot of old HTML formatting and style tags are deprecated in latest versions of HTML.
HTML tags behave differently under different browsers and different document modes. Where css will give same result everywhere.
The css classes can be applied to all the relevant tags on page at once just by defining it somewhere at the top of page.
You should also not forget that predefined tags have a lot of default properties and your custom tags none. So you would need to define everthing over again for all elements apart from span.
Also, you can have more than one class on an element, so <span class="red bold">Red</span> is possible.
You can remove, change and swap between classes to change dynamical the element style or behavior, what you can't do with tags.
Tag is element that needs class to set it behavior and style.
Custom elements are created using document.registerElement():
var reds = document.registerElement('red');
document.body.appendChild(new reds());
To what extend should I be attempting to use other CSS selectors instead of element IDs/class names or vice versa.
For instance: body > header nav ul+ul { ... } when I could just do #socialnav { ... } to achieve the same thing.
Example HTML code being (obviously there are headers with child navs elsewhere in the code):
<header>
<nav>
<ul>...</ul>
<ul....</ul>
</nav>
</header>
What is the consensus on this? I mean, I find it manageable doing it using CSS selectors, but is there a disadvantage?
Your first guiding principal should be to keep the markup semantic. Your markup above is a great example of this - you're using header, nav, and ul tags in semantically meaningful ways.
Your second guiding principal should be to maintain separation of concerns (e.g., content and presentation). If adding a class names or id's to your markup does nothing for you semantically and you're able to craft CSS selectors w/out them, then you should avoid adding extra noise to the markup.
Sometimes, however, class names and id's are very useful (not just in CSS but also in JavaScript), so they have their place. Just don't resort to them if they're unneeded and are therefore adding unnecessary clutter to your markup.
It's up to your preferences.
I find it not wise to use body > header nav ul+ul, because a small change in your document structure, and you have to rewrite the CSS selector.
Use .classselectors and #id-selectors for elements which aren't an incredible important part of the main document, and use #one-special-item > ul > li > a:hover span to select the more specific elements.
Generally I try and avoid ID selectors in CSS.
I find it a lot easier to deal with classes than using IDs.
IDs can cause issues later on down the line if the markup is used in a Server-Side application, such as ASP.NET, where the IDs are rendered as something different to how they display in the markup.
However, ID selectors do take priority over class selectors:
http://jsfiddle.net/wcLrF/
You should write your stylesheets as rule sets for your site.
If you are writing a style which is you want to to work with a single specific piece of content, then it is good practice to reference that element's ID.
If you are writing a style which is part of your general site look and feel, then it should be written to reference tagnames and/or classes as much as possible.
There will be times when the actual html code is such that it becomes hard to follow those rules, but if you try to stick to that in general then you'll be okay. You may also need to bend your rules if you need to support older browsers (cough, IE, cough) that don't support all the CSS features that you'd normally want to use.
So yes, I would say that the way you've done it in the question is the recommended approach.
Using IDs and Classes as selectors is much faster than using normal css selectors. Some also argue that you should ONLY use classes because they encourage reusability in your stylesheets.
Here's a really good article about Object Oriented CSS: http://coding.smashingmagazine.com/2011/12/12/an-introduction-to-object-oriented-css-oocss/
You're creating an HTML layout. Let's assume that you don't need the benefits of multiple stylesheets, that a small increase in HTML size is not a concern, and that you have a style which will only be used once. I'm often in favour of using an inline style here, as I view the repetition of your CSS class name or ID as the cost of an abstraction you don't currently need, and may not ever use.
Standard doctrine these days is to always create HTML layouts using semantic markup and CSS styles, so am I missing something here? Please let me know your thoughts.
Even if you only use a particular style once there are still benefits to keeping it with your other styles and not putting it inline. First, there is the separation of concerns that leads to improved maintainability. If you know you are going in to make only a style change, there is a single place to look for any changes. Another benefit is the self-documentation from having to type out the class name. By giving that style a name, even though it is used once, it makes the semantic code below more declarative -- you can read that not only is this random p a paragraph, it is also, say, the intro paragraph.
This is, of course, assuming that you are never going to use that particular style again. If you might than there is even more reason to factor it out into a named style. Inline styles aren't evil, but they are somewhat of a gateway drug.
Ideally your CSS should be "Object Oriented" (at least, as OO as CSS can be). You should "inherit" from classes that set common properties and create new classes when you define properties that could be used elsewhere.
Take a look at the OOCSS project which is trying to espouse these principles (or re-introduce them as it were).
To quote Welbog:
... It seems to me that "OOCSS" is just CSS that isn't written haphazardly. Much the same way you can write non-object-oriented designs in OO languages, you can easily mess up the fundamental ideals upon which CSS was created. OOCSS seems to be saying, "Let's not screw up anymore, guys."
One advantage of keeping the HTML and CSS separate is that you can re-skin the webpage without changing any of the HTML.
Steve
There are some situations in which I usually neglect creating a new class for a simple style change on a single element. It is usually pretty clear when you are doing it that there's a low-to-zero chance of you needing to apply that particular style to something else later down the road. The most common case for me is when I need something to have a particular padding/margin to be in the right place but it's not an element important enough to have its own ID.
This may not be a popular opinion here, but in those scenarios I don't think an inline style is evil.
Personally, I've found that I have an element or two and I would put an inline style in, go back and see that I need more than that element, so I'd change it to a class or forget about it and be not able to change it.
You could also try putting a certain div / page class, and write descendent styles for that in the stylesheet instead of inline elements.
Also, if you ever decide to add javascript, you won't already have a well-labeled class there and you'll need to change it.
Usually this isn't much problem with dynamically generated websites, but it can become a large problem when you go overboard and have tons of inline tags to switch out. It also can make it harder for people if they wish to disable styles for accessability etc-- you usually can overcome this by using a class.
Say, using <b style="color:red">bold</b> instead of body.products div b {color:red}.
I'm personally a fan of selectors, not using too many classes. They are more reusable, and you can edit the whole site in one place with the stylesheets.
But this is overkill <p style="font-weight:bold;font-size:1.2em; text-index:20px;">Indented Bold Paragraph</p> so it this <p class="indent bold larger">text</p> instead you can door ``<p><b></b></p>.
"A foolish consistency is the hobgoblin of little minds"
So, in this case is which is the foolish consistency? :) Why does DRY take precedence over the separation of markup and style?
Can you be sure that your CSS rule will only be used once? More over, how can you be sure that it won't need to be changed in the future, and how can you be sure that you would be the person needing to make the change? Are you sure you even need to add a class or id to target this unique element?
I guess I am having trouble seeing how adding
<input type="submit" style="border: 1px solid red;"/>
is some how "superior" to 12 or so more characters
<input type="submit" class="b-red">
.b-red {border: 1px solid red;}
or to a potentially equivalent character count
input {border:1px solid red;}
Of course there are situations where every rule of thumb can and should be violated. The question is, what do you gain from following DRY that outweighs the importance of following markup/style dichotomy?