I wonder about something, why should i name classes and style them, when i can just target then with css3 pseudo-classes? Will not be lesser "html code"?
<header>
<nav>
Link 1
Link 2
</nav>
</header>
In my CSS instead of i style the menu like this
.menu {
background-color: red;
width 50px;
}
I can just write like this?
header nav a:link {
background-color: red;
width 50px;
}
This is just an demostration/example i wrote fast, because if this is "smarter" or "better" coding then alot of webpages can get rid of alot unncesseriy classes and divs then they just target them as an Child-element?
Is this better or not?
Short answer: because it makes things easier.
It may be:
very difficult to write specific rules to target very specific elements
impossible to target elements directly if the HTML is very dynamic
cumbersome to add a lot of specific selectors if you want to style several elements the same in different parts of the document
difficult to move elements around in the document, because you need to touch the CSS rules as well every time
Classes identify groups of elements which you all want to treat equally, completely independently of their position within the document. This enables you to decouple your CSS and your document structure and reuse CSS efficiently for different documents.
The content of a web is often (very often) dinamic. that means it is developed in a team when (in my case) I do all the styles and they do all the programing stuff. You may have a container (div) and you may know what is going to be inside (links) but you will never know if you may have one or 200 links inside. You can control the html container and give it a class but even if my mates could make that any link inside has a class as it is generated, why bother them if I can target perfectly the links through header nav a:link
Related
Hello StackOverflow Community,
I just started using Squarespace to create a site for a client & friend offering some safety and equipment training courses, I love the templates, it's quite easy to use with the drag and drop of it all. However, I'm running into a problem with the course catalog page. I'm adding custom HTML to allow for a nicely laid out list with descriptions but the class and id selectors just don't target the elements. Targeting the <li> and <ul> elements targets them all, site wide. Anyone with any experience using Squarespace, could you possibly share your knowledge on how I might target specific elements? Thanks so much in advance.
I did post in the Squarespace forum but haven't gotten any replies, so here I am.
For Squarespace-related questions (both on the Answers forum and here on SO), it's usually easiest to provide a solution if you provide the URL of the page in question and the view-only password if applicable (necessary for sites that are in trial mode and not yet paid for).
In any case, assuming that you are using a code block in order to insert your HTML, you can add a classes to your elements in your HTML and then target them by adding CSS via the CSS Editor, or within a style tag with the code block itself.
For example, if putting it all inside the code block itself, something like:
<ul class="myclass1 myclass2">
<li>List item one.</li>
<li>List item two.</li>
</ul>
<style>
.myclass1 li {
color: red;
}
</style>
Now, if you were to add the CSS via the CSS Editor, you would exclude the <style>...</style> bit from the code block above, and instead insert the following via the CSS Editor.
.myclass1 {
color: red;
}
Note that, when using the CSS Editor, the <style> tag is excluded.
If neither of the above work, it is likely because you are dealing with Squarespace's own rules having a greater level of specificity. That simply means that Squarespace's default CSS rules are overriding your own. To compensate for this, you can either rewrite the rule above as color: red !important; or use your browser's developer tools web inspector to select the element in question, inspect the CSS rules that are applying to it (which will reveal Squarespace's default rules), then rewrite your rules with the same or greater specificity.
Finally, if my original assumption that you are using a code block is incorrect, then you are in fact using a text block. It is still possible to target specific elements within specific blocks in Squarespace. To do so, you must use the block ID.
To obtain the block ID, you must be comfortable using your browser's web inspector (mentioned earlier). Using it, locate the block in question.
Note that you do not want to use block IDs starting with yui.... Those IDs are dynamically generated and change with each page load. IDs starting with anything else are fine to use, such as block-yui....
Once you have the block ID, you can use it as part of your CSS, like so:
#block-yui_3_17_2_3_1425032049582_4670 ul li {
color: red;
}
Here again, specificity may be an issue and you may therefore have to add !important or write the rule with greater specificity as mentioned above.
Generally, it's difficult to actually get answers on Answers; StackOverflow is probably more effective.
Okay, this is a gross oversimplification, but I have a javascript application to help people develop webpages. It has its interface superimposed over the page that is being developed, and it all works fine, apart from one thing.
If the div class used in the interface is used by the webpage that is being developed, the interface' embedded stylesheet overrides the properties of the webpage!
This happens on jsfiddle, the embedded css is takes precedence over the external css.
JSfIDDLE
external css:
.color {
color: green;
}
Index.html:
<style>
.color {
color: blue;
}
</style>
<div class="color"> Text to be coloured </div>
When run, the text is blue. If someone could make the text turn green, I think it would demonstrate how to overcome the problem.
Obviously, one way to fix this would be to change the interface classes and rules to something like this:
<style>
.color_interface {
color: blue;
}
</style>
<div class="color_interface"> Text to be coloured </div>
And make them unique, but the project has hundreds of css rules, and I'm just wondering if there's a better way, and a safer way (there's still a small chance someone has a rule "color_interface") to do nullify css rules, so they won't contaminate the page.
I'm thinking the only way to do it is probably a 'reset' stylesheet concerning my rules, setting them all back to their defaults. Is there a way to do this dynamically with jquery, maybe?
What you're witnessing is CSS by design. Specifically, specificity.
If your goal is to release some kind of library that can be used publicly and you want to avoid naming conflicts, I think a fair practice is to simply namespace your selectors, e.g., .starkers-color { color: blue; }. That won't necessarily avoid specificity issues, but it should prevent against having your selectors overridden by implementors.
If you inspect the JSFiddle page you'll see that the reason for it not working is that your inline style definition is placed in the body where it has no effect.
The CSS rules you specify is instead placed as an inline style in the head element.
To your problem:
Again, referring to JSFiddle, would it be possible to load the page in development inside an iframe? This would mean you get the separation you require.
This is because the order of the CSS when rendering. Your include is at the top of the page but your style tags are below that, meaning your style tags will alway take precedence over you include at the top. You could try adding an important to you css includes but this is majorly hacky and could create a whole load of new issues.
I have been told, as well as read that using the style attribute in html is considered bad/sloppy/poor form. Further, that all rendering specific bits should be divorced into css and other parts as appropriate. I am trying to understand why exactly this is.
I can see why you might want to keep the HTML a pure semantic DOM, that speaks about the structure of the document, but for practical pages, the importance is that the page looks right and functions appropriately.
Is there some more compelling reasons for this separation?
Separation of concerns This makes it easy to replace the styles without changing the markup, or vice versa. Plus you can have one person working on CSS and another working on content
Don't Repeat Yourself You can apply a style to many elements without having to repeat it over and over. Smaller pages means quicker load times using less bandwidth. Plus it's easier to modify later, because you can change it in one place in one file, instead of many places in many files.
Cachability If the same style sheet is used on every page of your site, browsers can download it once and then cache it, instead of downloading the styles with the content of every single page. And they won't have to re-download it whenever the content of those pages changes.
Multiple Versions It is easy to create multiple versions of the visual layout and appearance of your site since you just need to swap out the stylesheet file to change the appearance of every page. For instance, you can create a white-label version of a web application which your partners can re-skin to match their brand. See CSS Zen Garden for some great examples of how flexible this approach can be.
Start with this code:
<ul>
<li style="color: blue;">One</li>
<li style="color: blue;">Two</li>
<li style="color: blue;">Three</li>
<li style="color: blue;">Four</li>
</ul>
Let's say that today, you decide to change the link color to red. Since these styles are inline, you tediously have to walk through each element and change the style attribute. Imagine doing this for 10, maybe 20 HTML pages and you'll see why this becomes a problem.
Using a stylesheet separates the content:
<ul>
<li>One</li>
<li>Two</li>
<li>Three</li>
<li>Four</li>
</ul>
From the style:
ul li {
color: blue;
}
Had you used a stylesheet from the beginning, changing the color is as simple as changing blue to red in your stylesheet.
Aside from making the document easier to style, there's also selector specificity. Imagine that you inherited the first code chunk from a previous developer and would like to change the color again, but you (being a nice developer) prefer stylesheets:
ul li {
color: red;
}
You'll soon become frustrated and resort to using !important, as your selectors can't override the inline styles.
CSS should be another file included in HTML because, if you want to change one style of an element that is included in more than one pages you will just change one style from CSS and the changes will be applied to all of the files. If you have the style in HTML, you would need to go on the pages one by one and change the styling. Its a good template building practice.
By separating markup and css. You can use css to change the look of everything, without affecting the markup.
Benefits include:
Creating different designs for the same html.
Dividing work within a team. One front-end developer can focus entirely on the css.
Back-end developers, do not have to hassle with the css.
Easier to change the look in the future.
Easier to migrate the html-markup to a new platform or content management system in the future.
Hi I have about six months experience in web development.
I have the following observation,
I use <div> tags a lot, it gives me the ability to position the elements, to archive the elements,
and it seems I can use <div> tags to do everything, simply playing with its display property.
I've never had to use <ul> or <li> elements in combination, except for horizontal menu navigation, and I am not sure why you can't do it with <div> elements, but it seems to be the 'convention' for achieving a horizontal menu.
Did I miss something? Are there some properties that <li> elements have that are better or more useful than <div> elements?
Please don't restrict this question to only horizontal menu list; I want to know any scenario where you would use a <li> over something else.
Yes, you can do anything (more or less) strictly with div tags (with exceptions, like forms and inputs, and images, and what not). But that's not the point.
First, specific tags have default css applied to them. li's have bullets, for example. You can change these, but in many situations, it's just easier to use the tag that has the style you're looking for.
But the most important reason is what's called "semantic markup", which is the concept that which element you use corresponds to a semantic meaning. li means it's a list of items, so even if you have no CSS applied (such as when a screen reader reads a page aloud for blind person) then it still has meaning.
The only reason to use one tag over another is semantics. The purpose of HTML syntax is to provide meaning to the content that is being rendered.
A <ul> element is an unordered list. It means the content is a collection of items where order is unimportant.
A <div> element is simply a structural element with no semantics associated with it. You could certainly use <div> elements to create the styles typically associated with <ul> elements, but it would mean losing the inherent semantics of the original element.
If you wanted to maintain the original semantics with <div> elements, you could use the list role:
<div role="list">
<div role="listitem">...content...</div>
<div role="listitem">...content...</div>
<div role="listitem">...content...</div>
</div>
However, the WAI-ARIA roles model isn't very well supported, so you'd be better off using the basic markup of:
<ul>
<li>...content...</li>
<li>...content...</li>
<li>...content...</li>
</ul>
HTML tags should help to explain the intent of the layout. When you use div for everything, it says nothing about the content. ul/li makes it clear that you have a list of related items.
This was the motivation for the addition of many new tags in HTML5: to make the layout have more semantics, that make it more understandable to humans maintaining the code, and to screen readers. So yes, you can make a page look the way you want with only div's, but it will be harder to understand.
Now depends your needs you can use any tag for example if you want to create a custom select is not ok to use div because is more useful to use ul li, check this example: http://jsfiddle.net/RwtHn/1152/
Now if you want to determine a section in which you want to add different paragaphs, pics or other static elements is more that ok to use divs. Check this for ul li : http://www.w3.org/TR/html401/struct/lists.html andthis for divs: http://www.w3.org/wiki/HTML/Elements/div . Is not a rule when to use what to use but it an help you in web development if you are codding well.
Cheers.
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/