I was looking at a css file today and found the following rule set:
div.with-some-class {
display:block;
margin:0;
padding:2px 0 0 0;
*padding:1px 0 0 0;
font-size:11px;
font-weight:normal;
*line-height:13px;
color:#3D9AD0;
}
What does the star mean in *padding and *line-height?
Thanks.
This is the "star property hack" along the same lines as the "underscore hack." It includes junk before the property that IE ignores (the * works up to IE 7, the _ up to IE 6).
In CSS? Nothing; it is an error.
Due to bugs in some versions of Internet Explorer, they won't correctly ignore the invalid property name, so this is one way of providing CSS that is specific to those browsers.
Using conditional comments is clearer and safer though.
The asteriks character is a valid wildcard in CSS. Use of it alone means the following CSS properties will be used against all element nodes in the DOM. Example:
*{color:#000;}
The above property will be applied to all DOM elements, thereby defeating the natural cascading in CSS. It can only be overridden by specifically tageting DOM elements where that targeting begins a unique identifier reference. Example:
#uniqueValue div strong{color:#f00;}
The above property will override the wildcard and make the text of all strong elements that occur in a div inside an element with an id attribute value of "uniqueValue".
Using a universally applied wildcard, such as the first example, can be a quick and dirty method for writing a reset stylesheet. It is quick and dirty because granular definition of presentation after the wildcard will likely create an extremely bloated stylesheet. If you are going to use the wildcard I would suggest using it more specifically, such as:
* strong{color:#f00;}
The above example will make the text of all strong elements color red regardless of other CSS properties not specified with a unique identifier. This is considered much safer than using the "!important" declaration as that declaration is known to cause interference with natural functionality of the intended behaviors and is a maintanence nightmare.
The asteriks in your example are in the wrong place as they seem to occur inside the property declarations, the code that goes inside curly braces, and that will likely cause an error.
This is a hack for IE7.
If you write this:
.test {
z-index: 1;
*z-index: 2;
}
on all navigator which respect the W3C Standard <div class="test"></div> HTMLElement have a z-index: 1 but for IE7, this element have a z-index: 2.
This is not standard.
To achieve same thing with W3C Standard, follow this steps:
Add some Internet Explorer Conditional Comment (this is a simple HTML Comment for all other navigateur so, it's a standard way).
<!--[if IE 7]><html lang="fr" class="ie7"><![endif]-->
<!--[if gt IE 7]><!--><html lang="fr"><!--<![endif]-->
And use the previous rules like this:
.test {
z-index: 1;
}
.ie7 .test {
z-index: 2;
}
Related
I know I can use [dir='ltr'] or [dir='rtl'] to select elements that have a dir attribute with a specific value.
so I can define for example
[dir='ltr'] .float-end {float:right}
[dir='rtl'] .float-end {float:left}
to get a .float-end class that floats right or left when inside an element with ltr or rtl respectively.
The problem starts when I have an ltr sub part of a document that is rtl.
<div dir="rtl">
<div dir="ltr">
<div class="float-end"></div>
</div>
</div>
What happens is that both rules match... and I only want to match the 'ltr' case in this scenario.
The problem gets worse if I want to create classes such as start-20px and end-20px to provide left:20px and right:20px and vice versa depending on context.
Would result in both left:20px and right:20px being applied....
I am looking for suggestions on how to overcome this.
Is there a way to depend on the nearest value of an attribute of any given type of element?
This is all done within the context of LESS mixins if it helps some how...
Thanks
The problem lies in the fact that the attribute selectors currently available in CSS have no document semantics. For example, you can't use attribute selectors to express some attribute value that is inherited from some other element. This is because as far as an attribute selector is concerned, if an element's attribute doesn't have a certain value specified on the element itself in the document tree, then it will not match the selector, even if the value is derived from elsewhere.
As mentioned, you could limit selection to the closest ancestor using the > combinator, but this requires the immediate ancestor to have the specified attribute, which of course you won't be able to guarantee is the case unless you make sure of it yourself. But if you are able to modify your markup, then that really is the best way to do this, even if it means a little bit of redundancy in your markup. I don't think even LESS by itself would be able to help you, as it still depends on the structure of your markup, which it cannot anticipate.
For what it's worth, Selectors 4 introduces a :dir() pseudo-class which carries semantics of element directionality based on the rules of the document language, something that attribute selectors alone cannot accomplish. For example, both the div and the p in the following example would match :dir(ltr), but only the div is [dir='ltr'] because the p has no dir attribute specified:
<div dir="ltr">
<p>Left-to-right text</p>
</div>
In your case, you would be able to just use .float-end:dir(ltr) and .float-end:dir(rtl) respectively; you wouldn't even need to have the pseudo-class on an ancestor.
The :dir() pseudo-class compared with the [dir=] attribute selector is similar to :lang() and [lang|=], which I explain here.
Of course, being a new proposal, :dir() isn't implemented anywhere (with the curious exception of Firefox — I'm guessing Mozilla thought of the idea, implemented it, then proposed for it to be standardized). In the meantime, you'll have to work around it by going the route I des
There is now a proposed solution for this in the CSS spec: Logical Properties. Basically instead of applying different property values based on some other element's dir attribute, browsers are going to start having property values that are directionally aware.
So in a perfect world, once these have full support you could write:
.float-end {
float: inline-end;
}
These new values will exist for lots of properties, not just float. Support as of July 2019 is pretty much everybody but Microsoft (IE/Edge), go figure.
Well, I can not give a solution to your first question (about floats), but I can give you one about the second (left / right properties).
As stated by the w3c
If neither 'left' nor 'right' is 'auto', the position is
over-constrained, and one of them has to be ignored. If the
'direction' property of the containing block is 'ltr', the value of
'left' wins and 'right' becomes -'left'. If 'direction' of the
containing block is 'rtl', 'right' wins and 'left' is ignored.
O.k.
So having learned that what I expected just does not work (at least not as of now [June 2014]),
I ended up with the following LESS based solution:
// provide a mixin to use two different rule sets depending on the current direction.
.ltr(#ltrRules) {
body[dir="ltr"] & , body[dir="rtl"] [dir="ltr"] &, body[dir="rtl"] [dir="ltr"]& { #ltrRules(); }
}
.rtl (#rtlRules) {
body[dir="rtl"] & , body[dir="ltr"] [dir="rtl"] &, body[dir="ltr"] [dir="rtl"]& { #rtlRules(); }
}
.bidi(#ltrRules,#rtlRules) {
.ltr(#ltrRules);
.rtl(#rtlRules);
}
// padding
// ------------------------------------------
.padding-start(#p) {
.bidi(
{ padding-left: #p } ,
{ padding-right: #p }
)
}
so using .padding-start(10;) on some SELECTOR
.my .selector {
.padding-start(10px);
}
will eventually generate the following CSS:
body[dir="ltr"] .my .selector,
body[dir="rtl"] [dir="ltr"] .my .selector,
body[dir="rtl"] [dir="ltr"].my .selector {
padding-left: 10px;
}
body[dir="rtl"] .my .selector,
body[dir="ltr"] [dir="trl"] .my .selector,
body[dir="ltr"] [dir="trl"].my .selector {
padding-right: 10px;
}
The compromise is that I can not change the direction multiple times going into the depth of the document and that the initial seeing of the direction must be on the body tag.
That siad, if for some absurd reason I WILL get to some point in the future when I will have to change the dir more then twice I can just use the same method and add handling for body[dir="ltr"] [dir="rtl"] [dir="ltr"] & and so on...
With some luck in a few years someone will understand that it is important to add the semantics of start and end that get interpreted as left and right respectively in LTR contexts and vice versa in TRL contexts making all my macros redundant... [as has already been done in text-align for example].
I know this is a very late reply but it could help someone if I got the question right.
Does this make sense?
[dir="ltr"] *:not([dir="rtl"]) .float-end,
[dir="ltr"] > .float-end{
float: right;
}
[dir="rtl"] *:not([dir="ltr"]) .float-end,
[dir="rtl"] > .float-end{
float: left;
}
JSFiddle here
What does the CSS standard say about unsupported expressions? How should a browser deal with them? How do actual browser implementations deal with them?
I'm implementing a CSS property optimizer (for a minifier project), and we want to leave CSS fallbacks intact. Our goal is to optimize the CSS as much as possible but in such a way that it should render exactly the same as the original.
This is why it's essential for me to understand how these things work.
Simple properties
For simple properties, it's really easy.
Let's say we have this:
div {
color: #f00;
color: rgba(1,2,3,.4);
}
In this case, if the browser doesn't support rgba then the first declaration #f00 wins. There is no question here.
Shorthands
However, how does it work with shorthand properties?
Here's some code:
div {
background: #f00;
background: rgba(1,2,3,.4);
}
How does the browser render this if it doesn't understand rgba? As you know, the syntax of background is: background: <color> <image> <repeat> <attachment> <position>; and such a shorthand declaration overrides any of the 5 fine-grained declarations that came before it; so the difficulty lies in which one of the 5 fine-grained properties the browser tries to assign the unknown token to. I have several possibilities in mind:
the browser decides it doesn't understand the latter declaration at all and drops it entirely
the browser thinks that rgba(...) represents a background-image and even though it doesn't know what to do with it, clears out the previous background-color as well
the browser thinks that rgba(...) represents a background-color and since it doesn't understand it, falls back to using #f00 instead
Let's make it even more interesting, say we have this:
div {
background: #fff url(...) no-repeat;
background: rgba(1,2,3,.4) linear-gradient(...) repeat-y;
}
How does a browser interpret this CSS snippet, ...
if the browser doesn't understand rgba?
if the browser doesn't understand linear-gradient?
if the browser doesn't understand repeat-y?
if the browser doesn't understand any two of the three?
if the browser doesn't understand any of the three?
The parsing rules in section 4.2 of the CSS2.1 spec speaks in terms of declarations, which refer to entire property-value pairs, regardless of whether the properties are shorthand or not:
Illegal values. User agents must ignore a declaration with an illegal value. For example:
img { float: left } /* correct CSS 2.1 */
img { float: left here } /* "here" is not a value of 'float' */
img { background: "red" } /* keywords cannot be quoted */
img { border-width: 3 } /* a unit must be specified for length values */
A CSS 2.1 parser would honor the first rule and ignore the rest, as if the style sheet had been:
img { float: left }
img { }
img { }
img { }
A user agent conforming to a future CSS specification may accept one or more of the other rules as well.
Notice that the third example shows the use of an illegal value for the background shorthand property resulting in the entire declaration being ignored.
Although the spec speaks of illegal values, as far as an implementation is concerned an unrecognized value and an illegal value are the same thing, since either way the implementation doesn't know what to do with such a value.
So the answer to the first part of your question is
the browser decides it doesn't understand the latter declaration at all and drops it entirely
And the answers to the second part are all the same: the latter declaration is ignored entirely.
As far as I know, if a browser cannot understand even a part of an expression, then it handles the property as syntactically wrong, and ignores the whole line.
Is it possible to use attribute selectors to partially-search an inline style attribute?
Can anyone find a way to get this bit of code working?
http://jsfiddle.net/v4xPY/1/
It seems that it's not possible to do this .hidden[style*="display: block"] + .below, nor even just [style]
The attribute selector you're trying to use isn't legit CSS, though it is a jQuery attribute selector. As far as I know, CSS is limited to [attribute=value], [attribute~=value] and [attribute|=value]. (derp, see below)
But, since you're already using jQuery to toggle the hidden div, it'd be a lot simpler to just toggle a class on the below div at the same time, rather than wrestling with the attribute selector (unless there's more to it than that).
Modified jQuery:
$(function() {
$('html').click(function() {
$('.hidden').slideToggle();
$('.below').toggleClass('yellow');
});
});
and CSS:
/* Margin of Below should reduce when hidden is opened */
.yellow {
margin-top: 10px;
background: yellow;
}
Fiddle here.
Edit: Okay, I was way off on the bit about the attribute selectors, it is legit CSS3; I don't know the details on browser support, though I'd guess it'd be supported in all the usual "modern" browsers. Also, there's apparently a problem with IE7 targeting the style attribute specifically. There's a pretty good write-up at http://www.impressivewebs.com/attribute-selectors/.
Once more: Though I can't find anything that explicitly confirms this, it looks like the attribute selectors only apply to attributes that are actually hardcoded into the html; basically it's just parsing strings, not examining the dom elements' "states" as such?
In my site I need to give support for IE7. Now everybody knows that styling things in IE7 is not an easy task. People uses conditional statement in HTML to load specific stylesheet for specific version of IE. But in my case I cannot use such conditional statement, since I am in WebCenter Portal application. Here I need to use skin. It is also a CSS file.
So I want to know is there any formula exists by which I can specify a particular css attribute's value for IE7.
Say I have a class:
.filterbox{
padding:12px 0;
margin:12px 0
}
Now this margin is okay for every browser except IE7 (I didn't test it in IE<7). In IE7 if I use margin:0; then the style would be perfect, but it then breaks in other browser.
How can I specify this margin in a same css class for both in IE7 and non-IE7?
Regards.
Only use this hack if you really can't use conditional comments! They are the best solution for solving IE problems. Hacks like this will quickly mess up your CSS and also make it invalid.
So, here is a hack that targets IE7 (of course this comes after your normal definition):
html>body #filterbox {
*margin: 0;
}
from CSS hacks – Targetting IE7 on Thought-After
you can solve it if you seperate the style sheets for IE7 and other browser:
/* other browsers */
.filterbox{
padding:12px 0;
margin:12px 0
}
/* IE 7 */
*:first-child+html .filterbox
{
padding:12px 0;
margin:0;
}
Attention! You have to define the styles for Ie 7 at last, because the browser will overwrite the first definitions. The others will ignore the last ones.
This question is similar to the one I asked here. I am cleaning up some files and I came across this in this css:
.something
{
height: 33px;
-height: 34px; /* does this do anything?? /
}
and
.something
{
_width: 150px; / does this do anything?? */
}
EDIT: Okay, so the _ (underscore) is a css hack for IE, which is fine, I'll just leave it, but what about the minus sign, does it do anything at all?
Also, we are not supporting anything below IE 7 anymore, so if anything is a hack for IE6 I can take it out.
Straight from the W3C CSS 2.1 Spec -
4.1.2.1 Vendor-specific extensions
In CSS, identifiers may begin with '-' (dash) or '_' (underscore). Keywords
and property names beginning with '-' or '_' are reserved for vendor-specific extensions.
However that said, using an underscore to prefix a CSS property is a well known CSS hack to apply that rule for rendering in IE 6.
Since a CSS identifier can start with a '-' (dash) and be valid, this can be used to quickly comment out parts of CSS during development. For example in the CSS below, none of the properties will be set for h1 and only margin will be set for h2.
-h1 { color:blue; margin:2em; }
h2 { -color:pink; margin:2em; } /* property "-color" not valid */
I'm not sure about the minus sign, but the underscore is a hack to have a rule ignored in IE < 6.
http://wellstyled.com/css-underscore-hack.html
This is a CSS hack, to trick some browsers to use them (or not use them).
This one is the Underscore Hack
Versions 6 and below of Internet
Explorer recognize properties with
this prefix (after discarding the
prefix). All other browsers ignore
such properties as invalid. Therefore,
a property that is preceded by an
underscore or a hyphen is applied
exclusively in Internet Explorer 6 and
below.
#elem {
width: [W3C Model Width];
_width: [BorderBox Model];
}
This hack uses invalid CSS[3] and
there are valid CSS directives to
accomplish a similar result. Thus some
people do not recommend using it. On
the other hand this hack does not
change the specificity of a selector
making maintenance and extension of a
CSS file easier.
CSS Hacks is one (not so elegant) technique of achieving same look and feel and across browsers.
It means the CSS property will be applied in IE 6 and below. It is a CSS hack.
A cleaner method of applying styles to different IEs is using conditional comments.