That’s a pretty major difference. This
is why it’s always strongly
recommended that you use unitless
numbers if you’re going to set a
line-height on something like the
html or body elements, or indeed on
any element that is going to have
descendant elements.
http://meyerweb.com/eric/thoughts/2006/02/08/unitless-line-heights/
So now i will follow this suggestion. but is there any cons to follow this?
but is there any cons to follow this?
I can't see any. The behaviour he describes:
So what’s the difference? When you define a united value, like 1em, you’re setting things up to pass along the computed result to any descendants. For example, suppose the following CSS is applied to a document containing the following markup fragment:
Is usually what you want. There may be exceptions with some typographically very specialized designs with fixed line-height s to achieve some sort of effects. But that will be rare, and you'll recognize them when you see them.
Related
As styling of a website/application gets more complex, and style sheets get bigger, I find that at some point inheritance starts adding to complexity.
You keep scrolling up and down through a long document to restyle a single element. You also need to keep in mind the consequences of any edits to all other tags/selectors that will inherit from it. Things break.
What if instead of that...
Each element's styles were fully contained within its ID/Class
Repetitive/common styles were applied using mixins and variables
(with Sass for example)
That way (my assumption):
Elements would be easier and more intuitive to style. Everything that makes an element look certain way is contained in one place. Elements could be customized as much as possible without breaking anything else - nothing inherits from anything else.
Global styling would still be possible, and easier too. You define global variables and mixins and use them as you see fit. That way, any element can "inherit" exactly what it needs, and nothing else.
Arguably, the resulting CSS would be bigger, but minification and ever increasing internet speed aside - this could make resulting CSS leaner too. Since each element is completely separate from all others (no cascade), you can easily just remove it. While with inheritance we're not always sure if removing something will break something else, so we keep piling up stuff.
Am I overlooking something here? Is there any downside to doing it like this?
Well Felipe is right that you will want to have your font applied to your html body, and do something similar for any other completely global styles. Otherwise your approach makes complete sense and greatly simplifies your design, which is one of anyones main goals.
I've always believed (although I now doubt the validity of these beliefs) that:
div.name
Was faster than:
.name
However I've read recently that most CSS selector engines read from right to left, in which case wouldn't the first example actually be slower? As the selector engine would simply find every element with a class of name, and then have to identify which of those were divs?
Which way do CSS selector engines read in general? Left to right or right to left? And if they generally read right to left could someone please offer me an explanation as to why (I can't see how it makes sense to read right to left in terms of a selector engine)?
However I've read recently that most CSS selector engines read from right to left, in which case wouldn't the first example actually be slower?
Which way to CSS selector engines read in general? Left to right or right to left? And if they generally read right to left could someone please offer me an explanation as to why (I can't see how it makes sense to read right to left in terms of a selector engine)?
Frankly, it's nigh impossible to tell which selector will be slower in a given browser, much less across browsers. Performance tends to fluctuate and be unpredictable, especially at such microscopic scales and with unpredictable document structures. Even if we talk about theoretical performance, it ultimately depends on the implementation.
Having said that, as shown in Boris Zbarsky's answer to this other question and in Guffa's answer to yours, a typical browser (this is currently true of all major layout engines) takes an element and evaluates all the candidate selectors to see which ones it matches, rather than finding a set of elements that match a given selector. This is a subtle but very important difference. Boris offers a technical explanation that's not only incredibly detailed, but also authoritative (as he works on Gecko, the engine used by Firefox), so I highly suggest reading it.
But I thought I should address what seems to be another concern in your question:
As the selector engine would simply find every element with a class of name, and then have to identify which of those were divs?
As well as Patrick McElhaney's comment:
The linked question explains why selectors are read right-to-left in general, so #foo ul.round.fancy li.current is read li.current, ul.round.fancy, #foo, but is it really read right-to-left within each element (.current, li, .fancy, .round, ul, #foo)? Should it be?
I have never implemented CSS, nor have I seen how other browsers implement it. We do know from the answers linked above that browsers use right-to-left matching to walk across combinators within selectors, such as the > combinators in this example:
section > div.second > div.third
If an element isn't a div.third, then there is no point checking if its parent is a div.second whose parent is a section.
However, I don't believe that this right-to-left order drills all the way down to the simple selector level. In other words, I don't believe that browsers use right-to-left evaluation for each part of a simple selector sequence (also known as a compound selector) within the right-to-left evaluation across a series of compound selectors separated by combinators.
For example, consider this contrived and highly exaggerated selector:
div.name[data-foo="bar"]:nth-child(5):hover::after
Now, there's no guarantee a browser will necessarily check these conditions for an element in the following order:
Is the pointer over this element?
Is this element the 5th child of its parent?
Does this element have a data-foo attribute with the value bar?
Does this element have a name class?
Is this a div element?
Nor would this selector, which is functionally identical to the above except with its simple selectors jumbled around, necessarily be evaluated in the following order:
div:hover[data-foo="bar"].name:nth-child(5)::after
Is this element the 5th child of its parent?
Does this element have a name class?
Does this element have a data-foo attribute with the value bar?
Is the pointer over this element?
Is this a div element?
There is simply no reason that such an order would be enforced for performance reasons. In fact, I'd think that performance would be enhanced by picking at certain kinds of simple selectors first, no matter where they are in a sequence. (You'll also notice that the ::after is not accounted for — that's because pseudo-elements are not simple selectors and never even enter into the matching equation.)
For example, it's very well-known that ID selectors are the fastest. Well, Boris says this in the last paragraph of his answer to the linked question:
Note also that there are other optimizations browsers already do to avoid even trying to match rules that definitely won't match. For example, if the rightmost selector has an id and that id doesn't match the element's id, then there will be no attempt to match that selector against that element at all in Gecko: the set of "selectors with IDs" that are attempted comes from a hashtable lookup on the element's ID. So this is 70% of the rules which have a pretty good chance of matching that still don't match after considering just the tag/class/id of the rightmost selector.
In other words, whether you have a selector that looks like this:
div#foo.bar:first-child
Or this:
div.bar:first-child#foo
Gecko will always check the ID and the class first, regardless of where it is positioned in the sequence. If the element doesn't have an ID and a class that matches the selector then it's instantly discarded. Pretty darn quick if you ask me.
That was just Gecko as an example. This may differ between implementations as well (e.g. Gecko and WebKit may do it differently from Trident or even Presto). There are strategies and approaches that are generally agreed upon by vendors, of course (there isn't likely to be a difference in checking IDs first), but the little details may differ.
The selector engine doesn't look for element to apply a rule, it looks for rules that apply to a specific element. Therefore it makes sense to read the selectors from right to left.
A selector like this:
div span.text a.demo
would make the selector engine do these checks to see if the selector applies to an element:
Is it an a element with the class demo?
Does it have an ancestor that is a span element with the class text?
Does that element have an ancestor that is a div element?
Are there any disadvantages to using word-wrap:break-word in the following way?
body
{
word-wrap: break-word;
}
The descriptions of the values for this property are as follows:
normal: Break words only at allowed break points
break-word: Allows unbreakable words to be broken
Now, this only makes a difference in the breaking of unbreakable words (i.e. continuous strings that are longer than their containers). Otherwise, it'll make no difference for 99% of text anywhere.
So, are there any disadvantages to using this globally? It can certainly solve a lot of layout issues without (at least as far as I can see) having any adverse effects. It seems better to do this once than to have to apply it everywhere you could possibly have overflowing text that would mess up your layout.
I can't think of any disadvantages since, if you want to have some other kind of word-wrap elsewhere, you'll always be able to override this global style.
That said, if you can at all narrow down the situations in which this will be necessary, using a broad class would be preferable. There's no telling what rare but very frustrating bugs a global break-word style will cause (and in what browsers).
I can't see any advantages of making it global on a page if the page is anything other than a test page.
For me I would not want words that are unbreakable to break at all. It's easier to read when they are not broken up. However if you want to make your text fit a div without using text-align:justify; and leaving gaps in between letters or words it might be nice.
The reason why I said in other than a test page was because sometimes, when I wanted to use place holder text besides "lorum ipsum" I would type gibberish but the div would always stretch. But since I wouldn't be using that text on the live site, I probably wouldn't use it.
I think the only consideration would be support in IE8.
According to this, word-wrap: break-word; doesn't work in all scenarios.
This property applies to elements that have layout. An element has
layout when it is absolutely positioned, is a block element, or is an
inline element with a specified height or width.
Of course, this seems quite easily rectified, but it should be known in case you need to support IE8 and you intend to apply this to items that do not "have layout".
Interesting are the new CSS3 properties:
http://www.w3.org/TR/css3-text/#word-break
http://www.w3.org/TR/css3-text/#word-wrap
Is this going to cause me untold grief if I stick it at the top of my stylesheet?
* {position:relative}
Is this going to cause me untold grief if I stick it at the top of my stylesheet?
Yes. You will not be able to work with absolutely positioned elements any more, for example - the absolute positioning will always be relative to the parent element, which is almost never the desired result.
I could imagine there are even more side-effects field of z-index settings.
Not a good idea IMO.
And no, position: static is not deprecated, after all, it is the default setting :)
Wildcards can cause performance issues when not used carefully. That would probably not be the case in your example, but it's a bad habit to develop.
But more importantly, it's rare that you can conclusively say you want any behavior to apply to all elements.
With relative positioning, you will at best achieve nothing and at worst create many headaches for yourself trying to troubleshoot things that would normally "just work".
Relative positioning definitely has its uses. Apply it when you need it.
It's a bad idea imho as it changes the default behaviour of elements without clear indication and it will have unforseen consequences.
If you really want to have most elements positioned relative, you might want to think about just making div and similar relative.
Just to give the other side of the coin, I have used this setting quite a lot, and have found it useful. Main advance being the easiness of using positioning properties (top, left, right, bottom) without having to define relative positioning to parent all the time.
It's true that this setting will make it impossible to use absolute positioning in relation to anything else than the parent right above, but I find this to be a good thing. Because the first parent with 'position: relative' is visually de facto parent of any child with 'position:absolute', then it is only logical to make them direct children also in the HTML hierarchy.
In short * {position:relative} forces a convention that makes it easier to reason how positioning works.
Caveat 1: Event if the new convention simplifies things to new comers, it's different from what seasoned CSS developers are used. Prepare to face opposition if you start using this in big project with many frontend developers.
Caveat 2: Performance issue should be tested properly. I have tried turning this setting on and off on some big sites without noticing any difference, but no real tests with real numbers exist (to my knowledge).
Final note: First line in the second paragraph is not quite true. You can always overwrite wildcard definitions, setting position: static some mid level node, if you really need to.
Answering title question:
This is the current CSS 2.1 spec:
http://www.w3.org/TR/CSS2/visuren.html#propdef-position
Accepted values include static, relative, absolute, fixed and inherit.
I'm not sure about CSS 3 (it's still work in progress) but they don't seem to mention static:
http://www.w3.org/Style/CSS/current-work#positioning
Whatever, I wouldn't really care yet :)
Answering body question:
The default is static so you'd be changing the property for every single item in the page. The best you can achieve is nothing. The worse is that you'll be probably creating weird side effects you won't even notice at first sight.
Also (this is pure speculation on my side), it can't be good for performance. I'm sure rendering engines are optimized for having a majority of static elements.
I am looking for a way to condense relatively small areas of text on a page in an effort to mimic a graphic button that was done with a non-standard font. Ideally, just the letters would get squished or made thinner, leaving the space between words more or less the same. I know there are some CSS attributes that do things like this, but they are more focused on spacing between the letters and not so much on the widths of the letters themselves. These CSS methods are also not very cross-browser friendly. The majority of the user base is using IE6, so that puts a large restriction on CSS-based methods out of the blocks.
So, is there any way to control the character width/spacing that is cross-browser friendly? I know jQuery works across browsers quite well, so could this perhaps be done with jQuery by manipulating the location of the letters and possibly their widths? These are small bits of text, 5 words at a time, or so, so speed is something that can be dealt with later.
EDIT: Ok, so, the CSS letter-spacing property, as well as the word-spacing property will allow me to control the space between letters/words. However, this makes things look squished. If this truly is the only option, then I'll have to make it work, but what I am really looking for is a way to squish the letters themselves, to make the characters thinner.
maybe
letter-spacing:-1px
will help
Short answer: I don't think there is a working cross-browser example that meets your requirements.
The CSS3 specification includes a font-stretch property, but sadly enough, CSS3 is barely (if at all) supported at this time.
Some possible ways that could emulate this behaviour that I can think of:
Use a flash-based approach like sIFR
Use a javascript / canvas based approach like Typeface.js. There's a font-stretch example included on the example page
Use condensed fonts (icky-approach, since this means you are relying on the font being available for the client), like Arial Narrow.
Use a server-side script that generates an image from text parameters
In short, there is no simple and elegant solution to this problem because text and image manipulation is generally something you'd do in a graphics editor.
If this is not possible, I'd definately recommend looking into Typeface and sIFR.
I think this sort of thing should probably be done in a graphics editor and output to a lightweight image (png or similar). I think this is the only simple and reliable way to control the visual output of the text to this extent.
Make sure you repeat the text in the alt attribute on the img tag for accessibility.
This approach has issues with localization - in that you need a version for each locale - but this is still doable.
There are also going to be issues if you wanted to keep this text in-line with some other text - e.g. in the middle of a paragraph. But if that's what is being done, it sounds like "squished up text" may not really be a good UI.
So, you want to squish it without squishing it?
Try adjusting the font-size then. Or some combination of letter-spacing, word-spacing and font-size. (All of which work just fine in IE6).
.nav {font-size: 80%;
letter-spacing: -.05em;
word-spacing: .05em; }
It sounds like a nightmare.
You can fudge the whole thing by putting each word if a floated DIV and fiddling with the width each DIV.
Are you sure you're specifying your doctypes properly? Perhaps your browsers are interpreting your CSS in quirks mode, resulting in the unpredictable behavior.
I don't think jQuery will be of much help to you if letter-spacing isn't working properly. You can't alter the positions of individual letters unless every letter is inside its own element, such as a span, which just seems messy.
EDIT: If you want to shrink the horizontal width of the characters themselves, that would theoretically be done with font-stretch: narrower, for example. But it seems the major browser don't support it properly or at all. Apparently it was in CSS2, but then dropped in CSS2.1 and is now planned for CSS3.
I'd have to question the wisdom of even trying to do this in the first place. Just replace the darn graphic with something readable; or something you can duplicate with your text.
What you want to do is change the text's font. I think your best bet is looking through a bunch of different fonts that come preinstalled for your userbase and trying for the best font+size combo.
You may be able to track down the original font with WhatTheFont
Approaching ten years later, font-stretch is still virtually unsupported. But
transform:scaleX(); will do. Here.