This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
Custom Cursor Image CSS
Is there a way to change the default cursor images for your website when you use, for example..
body{
cursor:hand; /* Changing what 'hand' is equal to*/
}
So then I wouldn't have to use cursor:url() on everything and instead just change what the names equal to.
So for example I'd like to be able to..
hand = URL;
progress = URL;
etc etc.
You can't change the cursorset of the Operating-system. (Just imagine - What would you say as a visitor of such a website changing your system-settings). You also cannot redefine the appearance of the keywords.
You have to define custom-images if you want to do so. The best thing you could do is group elements you want to have the same cursor.
input, select, [elements,]*{
cursor: url('someInputCursor.cur');
}
body{
cursor: url('mycursor.cur');
}
however, cross browser functionality is limited.
you should test...
You can't change cursor: hand; to use a different image. You could use a CSS pre-processor (e.g. LESS or SASS) to ease the task, e.g.
$hand: url('something.cur');
body {
cursor: $hand;
}
Or perhaps use a class (or a selector that covers all necessary elements) and edit the HTML accordingly?
.customcursor {
cursor: url('something.cur');
}
No, you cannot, because the cursor property value keywords have their meanings defined in informal prose in CSS specs, with no tools for giving any instructions on how to implement them. The obvious intent is to leave the exact shapes implementation-dependent.
Using tools like LESS, you can write style sheet code that uses defined variables, but such code needs to be translated into CSS then.
Note that the hand keyword in non-conforming. The corresponding standard keyword is pointer. (People have used hand because IE 5 did not recognize pointer.)
Related
I'm considering replacing SCSS variables (i.e. $someValue) with CSS custom properties (e.g. var(--someValue)) in an attempt to both allow for a little more flexibility in the form of theming and context-specific overrides, and to make the devtools in browsers a little more usable. Eventually, I'd potentially like to dump SCSS variables entirely just to simplify the development stack.
However, I've noticed that unlike SCSS variables, CSS custom properties are entirely un-checked, and typos are a thing. I've had code break in confusing ways because a typo was made either setting a CSS custom property, or using it in an expression - after all, CSS is very lenient using un-set or invalidly set CSS properties.
Since CSS custom properties aren't exactly new at this point, I thought I'd be able to find some webpack plugin or other solution to add basic typechecking to CSS properties, but I can't seem to find any. Ideally, I'd like to require all CSS custom properties to be declared in some fashion, including something like a type for its contents (to ensure that e.g. variables are consistently used as a dimensionless vs. dimension-full value vs. color, etc), but even just a tool or technique to detect typos would catch real errors. However, I've been unable to find anything like this, either as a build tool, or SASS plugin.
How can I protect myself from simple oversights when using CSS custom properties, e.g. detect that a property set as --someValue: 13px is never used or conversely that a reference var(--someValue) appears to have no matching assignments?
Using the new #property rule you can almost have what you want since it will allow to define the type for your variables.
Example:
#property --primary-color {
syntax: '<color>';
inherits: false;
initial-value: blue;
}
.box {
--primary-color: red; /* this one is valid */
background:var(--primary-color);
height:100px;
}
.box-alt {
--primary-color:10px; /* this one is invalid and will fall to the intial-value */
background:var(--primary-color);
border:var(--primary-color) solid green; /* it won't be used here even if contain pixel */
height:100px;
}
<div class="box"></div>
<div class="box-alt"></div>
You need to run the above on Chrome or Edge (Firefox still doesn't support this). As you can see, using pixel value is not allowed here since we specified the type to be <color>.
Actually the dev tool will show you nothing but this will probably change in the future to get some warning. In the meantime, you can rely on the initial value that will get used when the custom property is either not defined or defined with an invalid value.
I want to ask, if is that possible (something like font-face). Example:
#list-style-type {
list-style-image: 'myCustomStyle';
src: url('url-to-image');
}
ul {
list-style-type: myCustomStyle;
}
Is there something like that? I know I can do that with classes on element and then set custom image, but that is not my point. I have issue from my company and something like this would be very nice.
In CSS as currently defined and implemented, you cannot. The values of the list-style-type property are a set of keywords, somewhat different in different specifications and implementations, but even the syntax does not allow for any custom values to be added.
There is work in progress to define CSS Lists and Counters Module Level 3, which would extend the syntax and semantics, to allow custom values to be defined in #counter-style rules, using constructs designed as part of CSS Counter Styles Level 3. This is planned to include the possibility of defining a named value that uses a custom image, or a construct that contains a custom image as part of it. So far, it seems that there are no implementations of this in released versions of browsers.
you can use li background image,
<li style="background:url()">list text here </li>
Or you can use like
ul {
list-style-image: url('imageName.png');
}
everybody!
Reading this topic:
Change background color of HTML <area> tag
I saw the part of a CSS code:
area{
sharedAttr: 'attribute';
}
I wonder what is this sharedAttr. What is amazing Google search:
css sharedAttr
gives only 8 (eight!) results. I can not find any documentation mentioning anything about usage of sharedAttr in css sheet. Can anybody shed some light on the topic?
Thank you in advance!
The example you referenced is alluding (albeit rather poorly) to the fact that you can define one or more CSS properties using a fairly generic selector and then use a more restrictive selector to define specific additions/overrides.
area{
/* matches all instances of the area element, so properties
that should be applied to all area elements go here */
}
#one {
/* properties which should only be applied to the element
with the ID "one" go here */
}
In context of the original question, such a technique is commonly used to reduce the number of styles that must be declared. If 100 area tags all need the same background color, it would be silly to define a selector for each one. However, additional selectors can be defined to override that color and/or define additional properties on certain elements.
I know that in a stylesheet div#name and #name do the same thing. Personally I've taken to using div#name for most styling I do, with the reasoning that it's slightly faster, and means that I can identify HTML elements more easily by looking at the CSS.
However all of the big websites I seem to look at use #name over div#name (stack overflow included)
In fact I'm finding it very difficult to find many websites at all that use div#name over #name
Is there some advantage to doing #name that I'm missing? Are there any reasons to use it over div#name that I don't yet know about?
Since the div part of div#name is not required (because ID are unique per page), it makes for smaller CSS files to remove it. Smaller CSS files means faster HTTP requests and page load times.
And as NickC pointed out, lack of div allows one to change the HTML tag of the element without breaking the style rule.
Since ID's have to be unique on the page, most ID's you'd run into would only ever appear once in your style sheet, so it makes sense not to bother including what element it would appear on. Excluding it also saves a few characters in your style sheet, which for large sites which get visited millions and millions of times a day, saves quite a bit of bandwidth.
There is an advantage to including the element name in the case where a division with ID "name" might appear differently than a span with ID "name" (where it would show a division on one type of page and a span on another type of page). This is pretty rare though, and I've never personally run across a site that has done this. Usually they just use different ID's for them.
It's true that including the element name is faster, but the speed difference between including it and excluding it on an ID selector is very, very small. Much smaller than the bandwidth that the site is saving by excluding it.
a matter of code maintainability and readability.
when declaring element#foo the code-style becomes rigid - if one desires to change the document's structure, or replace element types, one would have to change the stylesheets as well.
if declaring #foo we'll better conform to the 'separation of concerns' and 'KISS' principals.
another important issue is the CSS files get minified by a couple of characters, that may build up to many of characters on large stylesheets.
Since an id like #name should be unique to the page, there is no reason per se to put the element with it. However, div#name will have a higher precedence, which may (or may not) be desired. See this fiddle where the following #name does not override the css of div#name.
I would guess that including the element name in your id selector would actually be slower – browsers typically hash elements with id attributes for quicker element look up. Adding in the element name would add an extra step that could potentially slow it down.
One reason you might want to use element name with id is if you need to create a stronger selector. For example you have a base stylesheet with:
#titlebar {
background-color: #fafafa;
}
But, on a few pages, you include another stylesheet with some styles that are unique to those pages. If you wanted to override the style in the base stylesheet, you could beef up your selector:
div#titlebar {
background-color: #ffff00;
}
This selector is more specific (has a higher specificity), so it will overwrite the base style.
Another reason you would want to use element name with id would be if different pages use a different element for the same id. Eg, using a span instead of a link when there is no appropriate link:
a#productId {
color: #0000ff;
}
span#productId {
color: #cccccc;
}
Using #name only:
Well the first obvious advantage would be that a person editing the HTML (template or whatever) wouldn't break CSS without knowing it by changing an element.
With all of the new HTML5 elements, element names have become a lot more interchangeable for the purpose of semantics alone (for example, changing a <div> to be a more semantic <header> or <section>).
Using div#name:
You said "with the reasoning that it's slightly faster". Without some hard facts from the rendering engine developers themselves, I would hesitate to even make this assumption.
First of all, the engine is likely to store a hash table of elements by ID. That would mean that creating a more specific identifier is not likely to have any speed increase.
Second, and more importantly, such implementation details are going to vary browser to browser and could change at any time, so even if you had hard data, you probably shouldn't let it factor into your development.
I use the div#name because the code is more readable in the CSS file.
I also structure my CSS like this:
ul
{
margin: 0;
padding: 0;
}
ul.Home
{
padding: 10px 0;
}
ul#Nav
{
padding: 0 10px;
}
So I'm starting generic and then becoming more specific later on.
It just makes sense to me.
Linking div name: http://jsfiddle.net/wWUU7/1/
CSS:
<style>
div[name=DIVNAME]{
color:green;
cursor:default;
font-weight:bold;
}
div[name=DIVNAME]:hover{
color:blue;
cursor:default;
font-weight:bold;
}
</style>
HTML:
<div name="DIVNAME">Hover This!</div>
List of Css selectors:
http://www.w3schools.com/cssref/css_selectors.asp
I am finding it useful to define 'marker' css styles such as 'hidden' or 'selected' so I can easily mark something as hidden or selected - especially when using a tag based technology like ASP.NET MVC or PHP.
.hidden
{
display:none;
}
.newsItemList li.selected
{
background-color: yellow;
}
I don't especially feel like reinventing the wheel here and wanted to know what other things like this are useful or common - or if there are any pitfalls to watch out for.
Should I look at any specific css frameworks for other things like this? Plus is there a name for this type of css class that I can search by.
I agree with the other posters who say only to define what you need, rather than bloating your code with a bunch of unnecessary classes.
That being said, I find myself using the following on a constant basis:
.accessibility - visually hide elements, but keep them intact for screenreaders and print stylesheets
.clear - tied to Easy Clearing
.first-child and .last-child - easily assign styles to the first/last item in a container. This has been a lifesaver many times, and I prefer it over the poorly-supported :pseudo selectors
.replace - tied to Phark IR for transparent image replacement
Finally, I dynamically assign .js to the <html> element with
<script type="text/javascript">if(h=document.documentElement)h.className+=" js"</script>
This will allow me to define .js (rest of selector) styles to target only browsers with JavaScript enabled.
Let me give you an answer from a very novice web developer who has recently considered using CSS classes as "markers". Please don't take this as a definitive answer, as I may be completely wrong, but look at it as another point of view.
I was going to use some marker classes, too. I created one called .center to center the elements in a DIV tag. However, I was struck with the idea that I'm looking at CSS all wrong. I reasoned that CSS is supposed to define how an element is to be displayed without having to change the HTML page. By using marker classes, like .center for example, I would have to change BOTH the CSS and HTML if I wanted that DIV tag to be right-justified next month. So instead, I created a .latestHeader class (the DIV is to hold the "latest information" such as a news item), and in that class I set the text to align center. Now, when I want to change the justification of the text, I simply change the CSS for that DIV and I don't have to touch the HTML.
In regards to your question about CSS frameworks...
Personally I've always found the W3C has the most complex but also most accurate answer to any CSS question.
After many years of programming and playing around with CSS/HTML/PHP I agree with the above comment.
There is no harm in defining a marker for something to be centered or right-aligned using something along the lines of a '.center' or '.righths', but keep in mind as above that if you want to change a whole slab of text your work will be increased because you have to edit both CSS and HTML.
Defining the format for a whole section will mostly likely work out more logical, because if you want to change the section months down the trail, you just have to edit the format of one CSS declaration as opposed to editing each individual article.
CSS was however designed as the ultimate styling language which could allow an administrator to make a website look exactly what they want it to. Keep in mind though that excess CSS will increase the load on a server, will increase the time before your client sees your page and in line with the 'feng shui of web design' it is possible to go overboard with too much styling.
You should really grow this list on a need basis instead of soliciting a list of generic classes across the board--you'll only end up with bloat. If you want to avoid reinventing the wheel the look into some CSS frameworks (blueprint or 960). In some respect, generic classes like .center { text-align:center } do have some level of redundancy but often times they're needed. For example the following pattern which is all too common but should be avoided:
element.onclick(function(e){ this.style.backgroundColor = 'yellow' }
That's bad because you really ought to be using:
element.onclick(function(e){ this.className = 'highlight' }
The latter allows you to modify your styles by only touching the CSS files. But if a CSS class name has only one style element then you should probably avoid it because it doesn't make any sense to have it (.hidden in your example) and call it directly instead:
element.onclick(function(e){ this.display = 'hidden}
I often find myself keeping two classes in all of my stylesheets: "center" (which simply applies text-align: center;, and a float-clearing class that applies clear:both;.
I've considered adding a "reset" statement to all my styles, but haven't had a need for it yet. The reset statement would be something similar to this:
*
{
margin: 0;
padding: 0;
}
I reuse these often enough to include them in just about everything. They're small enough so I don't feel they bloat the code at all.