The problem is when focused and hover pseudo class are used together, then when the ImageView is clicked it doesn't perform focused pseudo class work rather it performs the work of no pseudo class and if I remove the hover pseudo class then it works fine but when unfocused I cannot perform the hover effect.
Where as l1 is the I'd for user ImageView in the upper Anchorpane
CSS Code:
#l1
{
-fx-image : url(logo/user.png);
}
#l1:hover
{
-fx-image : url(logo/user1.png);
}
#l1:focused
{
-fx-image : url(logo/user1.png);
}
Could it just be as simple as a misspelling? The psuedo-class I believe you are looking for is :focus not :focused. See here: https://developer.mozilla.org/en-US/docs/Web/CSS/:focus
I have never heard of :focused.
EDIT: Apparently I was wrong and it actually is spelled differently in JavaFX CSS. Disregard above.
That being said, I did not really understand what you are trying to do because your description was not written very clearly. If my above suggestion doesn't work I would be happy to help you work it out but I would need you to make your question more clear.
Beyond that, if the snippet you included contains the actual styles and ID names, I have just a couple small suggestions for you.
1. l1 is a really bad name for a selector. On top of being unsemantic and not giving you or future developers any indication of what it actually is, it also falls into the problem of the l and 1 characters looking very similar. This invites confusion with some many different fonts. Semantic selector names are a best practice. You can read more about good CSS naming conventions in this guide here: https://cssguidelin.es/#naming-conventions
2. From a UI perspective, underlines tend to indicate to people that what is being underlined is a link. Underlining an element heading like you did with "User Login" is somewhat visually unappealing and also misleading to users. See the "Do's and Don'ts" in the WPF UI Guidelines here: https://cdn.wfp.org/guides/ui/v0.14.0/basics/typography/ Or the Nielsen Norman Group's Guidelines for Visualizing Links here: https://www.nngroup.com/articles/guidelines-for-visualizing-links/
Related
When looking at the elements of a page that I am analyzing using Chrome DevTools, I am seeing the following weird display:
What is that "(1)" in the end? Since the source is user agent stylesheet, I can't drill down any further.
In the Elements panel, I see similar weirdness:
I thought parentheses were not permitted in CSS selector names. What is the "primaryNavId:(primaryLi1)" being used above?
UPDATE:
A more detailed screencap of the "inherited from" line (Styles pane):
When I click on the "inherited from" line, I get the following in the Styles pane:
UPDATE 2 - FIREFOX INSPECT:
Firefox displays the same information in the Elements pane for the item in question, but the Styles panel shows it differently, as follows:
What a mess. Now I understand why you tagged your original question (and this one) css-selectors.
To start, browser developer tools naïvely assume that classes and IDs don't contain any special CSS selector characters and can therefore be represented in CSS selector notation without any escape sequences. So what you get is something that looks like a selector, but on closer inspection is actually malformed. You can see evidence of this in pretty much every browser's developer tools. The breadcrumb navigation, for example, in every one of them will list the li element as li followed by a period (for a class selector) followed by the class name without any escape sequences. Evidently the same appears to hold true for IDs.
It would seem that Google Chrome uses this same notation for "Inherited from" labels. Firefox is smart enough to only list the element's element type (which is far more predictable), i.e. "Inherited from li", and display the actual style rule and the actual selector from the source CSS, but its breadcrumb navigation suffers from the same problem making it kind of moot.
What you're looking at in the element inspector, however, is not a selector. It's an HTML class attribute. The syntactic rules are completely different. And that's why I said that this answer of mine that you previously linked to was completely irrelevant to your original question. But I can see why you're confused, seeing as HTML and CSS are closely related and CSS has dedicated class and ID selectors. (I suspect there wouldn't be any confusion if we were forced to use quoted attribute selectors for all attributes from the beginning — but attribute selectors weren't even around until CSS2.)
As to why the class name that's reflected in the Styles pane is different from the one that's reflected in the element inspector, the reason for that is not clear. Either you're inspecting different elements altogether, or something else is at play (and judging by the cryptic-looking class names, it may well be some funky client-side scripting framework voodoo magic).
This question already has answers here:
What is the difference between id and class in CSS, and when should I use them? [duplicate]
(15 answers)
Closed 7 years ago.
So I often use a website LiveWeave.com to test HTML, CSS, and JavaScript code that I've written. It has a syntax checker, and whenever I use an ID as a selector in the CSS section, it says that it is improper to use an ID as a selector.
I have demonstrated it in this Weaver. To the right of line three in the CSS window is a yellow icon, which, when hovered over, says that it is improper to use IDs as a selector. I was under the impression that that is specifically for the purpose of being used as a selector for a single DOM element, as opposed to classes, which are designed to be applied to multiple DOM elements.
Am I wrong? IS it improper to use an ID as a selector?
The only other instance I can think of an ID being used is for JavaScript document.getElementById(), and similar functions. What is the proper use of an ID?
Note that I am NOT asking the difference between an ID and a Class, but rather whether it is proper to use an ID as a selector.
Using an ID is the most efficient way of selecting a DOM node in both CSS and Javascript. I personally like to use classes for all repeated items and ids for unique items, or unique configurations of repeated modules. There are many CSS patterns, I use a style called BEM (Block, Element, Modifier as seen here) which is a class based naming convention. Look at your favorite websites, right click or inspect. You will find that there is no one right answer to your question, only many right answers.
May I also say that both exist in the standard for a reason and serve a purpose depending on your applications needs.
Below is the order of efficiency for selectors. IDs are the most efficient and pseudo classes and pseudo elements are the least efficient.
id (#myid)
class (.myclass)
tag (div, h1, p)
adjacent sibling (h1 + p)
child (ul > li)
descendent (li a)
universal (*)
attribute (a[rel=”external”])
pseudo-class and pseudo element (a:hover, li:first)
See here...
It is not improper to use ID's as selectors, so long as the ID being used corresponds to only one element in the DOM (document object model).
If you'd like a selector that is multi-purpose, and able to be applied to multiple elements in the DOM, use a class. Although I'm sure you knew that.
The main reason ID's are frowned upon by some CSS developers, and full stack designers, is simply because they aren't as versatile and they have a higher specificity than classes, which can either help or hinder development (based on CSS knowledge).
For more information on CSS specificity, read here: https://css-tricks.com/specifics-on-css-specificity/
It's valid, it's just considered bad practice by some developers because it can make it difficult to maintain your CSS if you're not disciplined about it. I'm no expert on CSS but I'm pretty sure it's all to do with #'s having a really high specificity rating and if you have them dotted around your CSS files it makes it difficult to manage the cascade i.e. inheritance of style rules. So it's considered best by some to use IDs only for referencing elements in your JavaScript.
I've actually heard this argument before.
Some people push the idea of using solely classes for pure css stuff and keeping id for javascript and other id specific functionality.
It would seem that website follows that ideology, so they are trying to get their users to adopt it. I'm not sure if it is yet best practice to keep id out of css
You can decide for yourself whether an id is worth using, when you could just use a class instead.
If you used an ID as a selector and your using it in your Javascript too then you could make situation where if you decide to rename it then you've created a dependency that wouldn't be there if you had used a class name in your CSS.
Also, though using the ID is faster, it isn't faster if you then use #text a - since CSS reads right to left and has to check all the anchor elements first and then find the one with the ID of #text.
This also means the style isn't reusable and you can't use multiple classes either.
So I think the answer really is, based on all the pros and cons of using an ID as the selector, the best practice to keep you out of possible future problems is to not do it. Of course, this all really depends on how you code, the scope of the project and how many other people are working in the project. It's not against the rules, just not really best practice due to possible issues you might be building in that could bite you later.
On top of what has already been mentioned, even in CSS, ID's can be useful depending on what is the structural design.
For example; if every page in your website requires a header and a footer, I don't see why it would not be useful to make it an id.
What is wrong with doing:
#header {}
#footer {}
If you know for sure that your page has only one header and one footer, I don't see the point in using a class.
Mentioning the id is very specific and the page structure is undubious in this case.
Moreover, I also don't see what is wrong by doing something for example like:
.menu{}
#header .menu li{}
#footer .menu li{}
To add specific styling depending on the page segment. Seems very legit to me.
Ultimately, I even think that using ID's to indicate page sections might be more beneficial by ´knowing´ that they are unique (although they might be recurrent across different pages).
Reading an id in a CSS file should give the CSS designer the benefit of immediately knowing what page segment the following css rules are referring to.
A sheet with only classes would in that case seem less clear than using ID's imo.
On my page I have few blocks (div) that have the same style regarding background and border (menu panel, info panel, footer panel, ...).
Now I would like to write that style only once and not repeat it for every panel. Yet I don't see any comfortable way of doing that.
One approach I investigated was to introduce a dedicated class (for example panelClass) that would capture the common panel styles. Then in (X)HTML I would just add that class to every element that is supposed to be a panel.
But this doesn't feel right. After all I would be "revealing implementation" in the (X)HTML. I'm no longer able to transparently change things easily because that requires modification of the (X)HTML.
Not to mention that it introduces issues with order of the classes (and thus order in which CSS attributes will be overwritten if needed).
EDIT: (an extended explanation for kolin's answer)
By “revealing implementation” I meant that the (X)HTML (“the content”) is much more strongly connected to the CSS (“the presentation”) than I would like them to be. Maybe I’m pursuing an unreachable ideal (maybe even an unreal or a dummy one!) but I’m trying to keep “the content” separate from “the presentation”.
Thus having a class menu isn’t bad because it describes “contents” not “presentation”. While using instead (what I understood from the cited articles and few others on that site) classes like menu box bordered left_column is bad because it mixes presentation with contents. Once you start adding such classes you might very well add that CSS directly to style attribute. It sure would be much more work and an unmaintainable result but conceptually (when regarding contents-presentation separation) it wouldn’t make a difference.
Now I do realize that in real life for real pages (rich and nice) it is virtually impossible to keep contents entirely separate from presentation. But still you may (should?) at least try to.
Also just look at the “But” in the end of the article The single responsibility principle applied to CSS. In my opinion the island class he used is already presentational because it does not describe contents. It describes how to show it. And that is immediately obvious once you see how widely he used (or might have used) that class on elements having nothing in common as regarding contents.
END EDIT
Another approach was to use selectors grouping. So I would have something like:
#menu, #info, #footer {
background: /* ... */
border: /* ... */
}
This avoids the need to modify (X)HTML. But still causes order issues. And also makes it hard to group styles logically. Especially if they are distributed among many files.
I think that what I really would like to have is to be able to name a group of attributes and just import them somehow in selectors. Something like #include in C++ for example. Is there any way to achieve this? I doubt it but maybe...
If not then is there any other method?
Using classes to define styles is the correct way to do it.
One approach I investigated was to introduce a dedicated class (for example panelClass) that would capture the common panel styles. Then in (X)HTML I would just add that class to every element that is supposed to be a panel.
For me this is exactly the way I would do it.
But this doesn't feel right. After all I would be "revealing implementation" in the (X)HTML.
is there a security problem with revealing implementation?
A few selected posts from Harry Roberts :
http://csswizardry.com/2012/04/my-html-css-coding-style/
http://csswizardry.com/2012/04/the-single-responsibility-principle-applied-to-css/
http://csswizardry.com/2012/05/keep-your-css-selectors-short
I find his style of using CSS eye opening, and it may help you
update
Following on from your update, I agree with you that you should try and seperate structure from presentation, although there will be times where we can't quite manage it. Whether it is fully possible or not, i don't know.
I partially disagree about the island class, the padding property to me kind of hovers over the border of structural and presentational. structural because it alters the layout of whatever element it is applied to, presentational because the padding alters how it looks on the page.
in an ideal world you should never need a class attribute that encompasses menu box bordered left_column, because you would write a couple of classes that seperate out the structure and presentation.
thinking about your case I might create a panel class
.panel{
margin:10px 0;
padding: 10px;
display:block
}
and a panel-display class
.panel-display{
background-color:#1111e4
}
.panel-display > a{
color:#fff
}
in this way I could just play with the presentation without affecting the structure of the site.
(n.b. I'm not sure if this helps you in anyway!, it just seems logical to me)
Sometimes when I see a website I like or sites from respected people, I see the source codes and try to understand them (as we all do).
On Jeremy Keiths site he uses the following code:
[role="navigation"] a {
font-weight: bold;
text-decoration: none; }
I have never seen this before, and a few other times I saw code (which can be considered a "trick") that I had never seen before.
Other than asking what the above code means, my question is - is there any documentation, book or blogs that go through to learn about the advanced/less known CSS "tricks"?
The above targets elements that have a role attribute, such as:
<div role="navigation">
...
</div>
A class would make sense here too, but it's just another way of doing it. Attribute selectors are a standard part of CSS2, but at the time IE6 didn't support them so it hasn't been used much until recently.
There are many other such selectors that have been around for a long time but couldn't be used due to limitations imposed by IE. See Quirksmode for more examples.
That is a CSS attribute selector. It's saying "All <a> tags that are descendents of an element that has an attribute of role with a value of navigation should be styled in the following way ..."
He's using it for accessibility principally, and for styling only secondarily.
If you are looking to learn some of the newest things about CSS, I'd recommend css3.info and css3please.com. The first is a great source of examples of new tricks, and the second one lets you play with the new stuff in the browser. Other than that ... I've found that the best way to learn is to answer questions here (looking things up when you are not sure) combined with reading -- Eric Myers, Paul Irish, Quirksmode -- all of these are good resources for learning things that are new to you.
In this example, the <nav> is wrapped in a <div> and then then assigned a navigation role. The same can be achieved with just
nav a {}
A lot of sites seem to mix a "little" HTML5 with XHTML. I really don't see a reason why they don't use HTML5 "completely". The whole point of HTML5 is to be more semantic and to write less code that's more meaningful.
Some useful links.
http://html5doctor.com/
http://htmldog.com/
http://desizntech.info/2009/03/discover-the-cool-of-css-25-advanced-css-techniques/
As of now, you'll need a bit of javascript to make HTML5 elements work in IE. These links should help
http://html5doctor.com/how-to-get-html5-working-in-ie-and-firefox-2/
http://remysharp.com/2009/01/07/html5-enabling-script/
Role is a new XHTML2 attribute.
http://www.wait-till-i.com/2009/05/16/pitching-a-hack-or-a-product-dos-and-donts/
http://www.w3.org/TR/2008/WD-xhtml-role-20080407/
Cool, which browser did it work in?
http://www.w3.org/TR/2001/CR-css3-selectors-20011113/#selectors
E[foo="bar"]
an E element whose "foo" attribute value is exactly equal to "bar"
I didn't see anything on here about it with a quick search, if there is let me know.
Here is an example of a CSS selector I'd write.
div#container div#h h1 { /* styles */ }
div#container div#h ul#navi { /* styles */ }
div#container div#h ul#navi li.selected { /* styles */ }
I write all my CSS like. This allows me to stop from having styles floating around and I can technically re-use the same class name easily. For instance, I might use .selected on multiple elements across the site.
I also specify the element type (div, ul, etc) before the class/id unless the style is used for multiple elements. I also specify the element before id's even though there will only ever be one id because it allows me to know the element easily when reading my CSS. For instance I'll know right off the bat that em#example will most likely have a font-style of italic.
This isn't a question about CSS formating, it's about writing selectors.
I'd love to hear opinions on this approach, as I've used it for years and I'm reevaluating my stying.
Although it's somewhat off topic I also write my selectors like this for selector libraries (like jQuery for instance). Although I haven't looked into jQuery's internals to see if there is performance issue with specifying the element with an ID.
I think it really depends on what the selector is for.
Almost every site has one or a few style sheets that "skin" the site - fonts, text colour, link colour/hover, line spacing, and so on, and you don't want these selectors to be very specific. Similarly, if you have a component or element that's reused in many pages and always needs to look the same - like let's say the tags right here on SO - then it's going to be a pain to maintain if you use selectors based on the ID.
I would always use the ID in the selector if it refers to a specific element on a specific page. Nothing's more frustrating than trying to figure out why your rules don't seem to be working because of a conflict with some other rule, which can happen a lot if everything is classes. On the other hand, I think that nesting the IDs as you are (#container #h) is redundant, because the purpose of an ID is to be unique. If you have more than one element with the same ID on the same page then you can end up with all sorts of problems.
It does make the CSS slightly easier to understand when your selectors provide some idea of the "structure" that's being represented, but, to be honest, I think that goes against the idea of separation of concerns. The #navi might be moved outside the #h for perfectly legitimate reasons, and now somebody has to update the style sheet for #navi, even though nothing about it has changed.
A bit subjective as Darrell pointed out but that's my two cents.
While the question is a little subjective I have to say I agree with your thinking. I think defining the element before the selector is clearer when reading the code and it is less error prone.