What does the following CSS do and is it valid?
h4 {
width: 83%;
#width: 75%;
}
It is not valid. #width: 75%; is a syntax error, since # isn't used in CSS property names (although it is used in CSS selectors, to select elements with specific ids). Most browsers will ignore it (hopefully) and only the first rule will be applied.
It might have been someone's attempt to write a CSS comment. This is the valid way: /*This is a comment*/
Edit
I would suggest using a CSS reset file to account for browser differences.
Apparently there's a hash hack which looks exactly like the one you have, but I have no idea what specific browsers the author is trying to target or filter since there aren't any reliable results as to what browsers apply the rule and what don't (that looooooong list of user agent strings isn't what I'd call reliable; I'd call it inconsistent).
In any case, a hash is not a valid character for property names. I'm sure anyone that isn't IE will squarely discard it on sight.
using # before a property is applying different css style for ie 7. Is a css hack like *. To make it valid you can use conditional comments for ie.
From what I've read on http://developer.expressionz.in/blogs/2007/09/08/for-your-ies-only/ the hash-hack is intended to make a rule only visible to IE browsers. Since it is - as already mentioned by others - not a valid property, other browsers will ignore it.
BTW if the second width was not preceded by #, it would take width = 75% and not 83%. The last value always overrides all the preceding ones. As others pointed out, it could be a hack, which I don't know but most likely a syntax error.
To basically answer both your questions.
The # before the property targets IE7 & IE6 (and lower)
No, it's not valid.
I asked the same question, there's more info there that may be helpful to others:
Post: " CSS - "#" sign before property "
Related
What does the following CSS do and is it valid?
h4 {
width: 83%;
#width: 75%;
}
It is not valid. #width: 75%; is a syntax error, since # isn't used in CSS property names (although it is used in CSS selectors, to select elements with specific ids). Most browsers will ignore it (hopefully) and only the first rule will be applied.
It might have been someone's attempt to write a CSS comment. This is the valid way: /*This is a comment*/
Edit
I would suggest using a CSS reset file to account for browser differences.
Apparently there's a hash hack which looks exactly like the one you have, but I have no idea what specific browsers the author is trying to target or filter since there aren't any reliable results as to what browsers apply the rule and what don't (that looooooong list of user agent strings isn't what I'd call reliable; I'd call it inconsistent).
In any case, a hash is not a valid character for property names. I'm sure anyone that isn't IE will squarely discard it on sight.
using # before a property is applying different css style for ie 7. Is a css hack like *. To make it valid you can use conditional comments for ie.
From what I've read on http://developer.expressionz.in/blogs/2007/09/08/for-your-ies-only/ the hash-hack is intended to make a rule only visible to IE browsers. Since it is - as already mentioned by others - not a valid property, other browsers will ignore it.
BTW if the second width was not preceded by #, it would take width = 75% and not 83%. The last value always overrides all the preceding ones. As others pointed out, it could be a hack, which I don't know but most likely a syntax error.
To basically answer both your questions.
The # before the property targets IE7 & IE6 (and lower)
No, it's not valid.
I asked the same question, there's more info there that may be helpful to others:
Post: " CSS - "#" sign before property "
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
CSS reset - purpose of asterik within a style
I was reading through the CSS styles for HTML5BoilerPlate, and I came across this unfamiliar line:
button, input, select, textarea {
font-size: 100%; margin: 0; vertical-align: baseline; *vertical-align: middle;
}
In particular, the second ****vertical-align***, why call twice and put an asterisk in front of it.
If anyone knows the name of the technique or why it's used, it would be a great help
Thanks!
-Adrian
It's a nasty hack that can be used to target older versions of IE (other browsers ignore the invalid asterisk-prefixed value). Definitely not a good idea, far better to use IE conditional stylesheets or similar techniques.
It's a CSS hack for Internet Explorer browsers:
*property: value
If you add a non-alphanumeric character such as an asterisk (*) immediately before a property name, the property will be applied in IE and not in other browsers. Unlike with the hyphen and underscore method, the CSS specification makes no reservations for the asterisk as a prefix, so use of this hack could result in unexpected behavior as the CSS specifications evolve.
property: value applies the property value in IE 7 and below. It may or may not work in future versions. Warning: this uses invalid CSS.
from here
This is a css hack and used to target IE7 browser.
For more reference see How to Target IE6, IE7, and IE8 Uniquely with 4 Characters
It's an IE6 hack. If you put the * in front of a CSS attribute, it will only be read by IE6. Since IE6 usage is now down to 1% of the world, we can forget about this hack (unless you live in China)
After looking through everything except the Gecko source, I'm somewhat confused by the following behavior. I wanted to see if I could style a text input based on a user-inputted value, and eventually ended up with this CSS:
input[value="password"] {
border:1px solid red;
}
The problem is, it seems the value of an input is only checked on the elements creation, as seen in this example.
Is it possible to accomplish this without the use of Javascript? Why would a browser not update styles accordingly?
It doesn’t work, because attribute selectors “match elements which have certain attributes defined in the source document” (Attribute selectors in CSS 2.1). Things are a bit more complicated really, because calling setAttribute('value','password') on the input element causes a match in many browsers (not IE). But this is irrelevant if you don’t use JavaScript.
There is, however, an indirect way, though it is mostly theoretical for the time being, due to limited browser support and to complications in implementations. You could write:
<style>
input:valid { border: 1px solid red; }
</style>
<input pattern=password id=x>
This uses the HTML5 pattern attribute, in this case specifying a regular expression that is merely a fixed string with no wildcards, and the CSS3 Basic UI :valid pseudo-class that tests whether the element’s state satisfies validity constraints. This is not suitable for normal use (e.g., no support in IE 9), but in special situations in controlled environments, things like this might be usable.
However, browsers that support such features tend to have their own reporting of validity errors, like special color around the box when the value is invalid, and I don’t think you can change that in CSS – JavaScript might help, but… So the reporting might conflict with your goals here. Moreover, it seems that browsers supporting these features treat the element’s state as valid when the box is empty. This is odd, and attempts to work around this my making the input obligatory (HTML5 attribute required) seem to open new cans of worms rather than fix. But maybe in some cases you could use just some initial value, say value="?", that the user is expected to replace by this input.
No. CSS cannot check the value of an input field past what is available in the HTML structure.
When you're typing into an input field, you're not actually changing the attribute in the HTML.
This does not work because you're not actually changing the value attribute of the element. For example, look at this fiddle:
http://jsfiddle.net/jblasco/J9xSd/
It does work, because the value attribute is actually changed. Simply typing in the field, or updating it through the Javascript method you used, does not change it. Which is normally useful, for getting the default value later, but perhaps not-so-useful in this sense.
I'm dealing with someone else's code here and have come across something like this:
.selector {
.background-position : 0px 2px;
}
Does the period on the line background-position do anything or was that their way of commenting the line out? It doesn't seem to have an effect that I know of (using chrome inspector and firefox inspector) but I want to make sure.
Thanks for any insight on this.
I usually use a z to quickly comment stuff out. But in the production CSS, I remove these lines.
It's a "comment". It makes the CSS invalid though and it looks very unprofessional, so it's a good idea to remove it altogether if you don't need it, or at least properly comment it with /* ... */.
A period there - ie in .background-position - is not valid CSS.
A period is valid in the selector, as you've shown it - ie .selector, in which case it selects elements with class='selector'.
But if I understand the question, you were asking about the dot in .background-position, which as I say is not valid. If you try to add .background-position as a style in Firebug, it won't accept it.
That isn't valid CSS; my guess is it's a comment or a mistake.
I have seen people use characters like _ and * to make sure some properties are only rendered in particular browsers (for example _background-position would be applied in only IE6), but never seen it done with a '.'
Period prefixes indicate styles exclusive to IE7
CSS Browser Hacks
Can you use the browser specific prefix in front of all standard tags?
e.g.
#div{
padding:20px;
-moz-padding-bottom:10px;
}
is the above valid CSS for ensuring Firefox has a different bottom padding to all other browsers?
No, it's not a prefix for targetting a browser, it's a prefix that is used for specific non-standard properties like -moz-opacity or -moz-padding-start. It's not available for the standard properties.
First, no, there isn't a prefix for things that are standardized, since they're the same property cross-browser (or should be, don't take this for granted in IE).
Instead of what you're after with this prefix, I'd instead look at a completely different approach...taking out the differences in rendering, instead of trying to fix them, at least as many as possible.
Take a look at a CSS reset stylesheet, to normalize the padding and such across browsers, then look at fixing any remaining quirks.
You can always do it, but the style will be ignored by browsers who don't understand it and the CSS won't pass CSS Validation.
This might be of interest.
-webkit-text-stroke
Works in Firefox browsers as well.