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
Related
I'm about to update http://getcrow.eu and have one "issue" to solve that would make the framework everything I always wanted it to be.
Important to know:
Crow does not use tables, absolute positioning, floats or clearfix'es and it should stay that way.
We know that putting inline-blocks next to each other like so:
<div class="parent">
<div>Block 1</div>
<div>Block 2</div>
<div>Block 3</div>
</div>
with CSS:
.parent {
> div {
display: inline-block;
}
}
Creates white-spaces between the blocks. We also know there's a handful of solutions to prevent the white-spaces from creating space, which is highly required if creating a grid framework with this method.
Beneath I list the methods that I'm aware of and why I don't want to/can't use them:
(SKIP IF YOU WANT TO GET TO THE QUESTION)
Comments in the HTML inbetween children div's.
No-go because: it creates ugly HTML that the developer, using crow, must be aware of and work with.
Breaking lines at the end of children tags/ not using closing tags.
No-go because: same as above
Using minus (-) margins on .parent-wrapper.
No-go because: specified margins depends on document font size which mean the grid could break in responsive markup where html { font-size:{X}px; } changes.
Setting 0px font-size to .parent and "reset" the font size on children (this is the method I'm currently using).
No-go because: I don't want the developer using crow to force-set the children. I just want the inheritance to be natural without a grid that's setting the font size downwards for me.
Using Javascript to remove all white-spaces from .crow elements.
No-go because: I want the framework to be pure CSS and no js. This could also "flick" the DOM after pageload if user has bad connection.
Loading a font with font-family on .parent that has no white spaces.
No-go because: loading in an extra font just to get the grid framework is just wrong. Especially as you have to download extra files (font-files) and declare fallbacks for all browsers.
Using letter-spacing -{X}px on .parent.
No-go because: same as .3 (see above)
Using flex box.
No-go because: the framework focuses on vertical centering (if desired) and flex box lives it own life when it comes to that. I'm also making sure the grid is supporting IE8 which it does today.
So basically I'm searching for a - unknown/not yet discovered/way that I'm not aware of - for removing white spaces in between inline-blocks. I want it to be pure CSS. If you have a method that you know of/think would work - I can try it on different browsers.
Resolving this would surely make Crow the best grid framework. I'm already using it for various websites and I can tell that the possibilites are many when given the ability to easily position elements center vertically.
Sidenote:
Marking up the DOM like so: <div class="parent"><div>Block 1</div><div>Block 2</div></div> does the job just like I want it to. But that would require the developer using Crow to mark it up that way. And I don't want to rely on a framework creating that HTML.
InuitCSS (my choice of framework lately) uses a similar system. As wonderful as the use of display: inline-block; is in a grid system, it does appear that the whitespace issue, is an inherent one; with little chance of resolution beyond the current workarounds.
I agree that the use of comments or closing tags does introduce some issues with CMS entries, and a certain amount of mental overhead for the developers involved; but not an unmanageable amount.
If you want to have a look at Inuit's grids I would recommend it's GitHub found here:
https://github.com/inuitcss
I would also advise reading this issue, in-which Inuit's creator; Harry Roberts, weighs in on the various solutions this problem. Whilst it may not tell you anything you don't already know, it is an interesting (if outdated) discussion on the matter.
https://github.com/csswizardry/inuit.css/issues/170
I know that the above may not solve your issue, or even shed any light on the matter, but I hope it can be of use.
Using a float is your best option.
.parent div {
float: left;
}
Following your comments below you could use a negative margin.
.parent div {
margin-left: -4px;
}
But this may change browser to browser.
I'm trying to display text with line breaks in a div using the css white-space property with a value of pre-line. This works as expected for Chrome, Firefox, and IE 8, but not in IE 7.
For example,
<div style="white-space:pre-line">
CSS has a pretty useful property called white-space that I’m guessing goes unnoticed among CSS beginners.
You can probably live without this property for quite some time, but once you learn how to use it, it will come in very handy and you’ll find yourself going back to it over and over again.
</div>
will display in Chrome, Firefox, and IE 8 like this:
CSS has a pretty useful property called white-space that I’m guessing goes unnoticed among CSS beginners.
You can probably live without this property for quite some time, but once you learn how to use it, it will come in very handy and you’ll find yourself going back to it over and over again.
but in IE 7 it displays like this:
CSS has a pretty useful property called white-space that I’m guessing goes unnoticed among CSS beginners. You can probably live without this property for quite some time, but once you learn how to use it, it will come in very handy and you’ll find yourself going back to it over and over again.
You can see it here: http://jsfiddle.net/VSQnP/10/.
I've tried values of pre, but then the text doesn't wrap and long lines run off the right side of the div, and pre-wrap, but that has the same problem in IE 7.
IE7 doesn't support the white space handling property pre-line. See this page for a compatibility table.
You can use these declarations instead
white-space: pre;
word-wrap: break-word;
It's not an alternative to pre-line, as it's breaking words not lines but at least the content does not exceed the boundaries of its container.
I stumbled upon this article
http://www.thefloatingfrog.co.uk/css/my-hatred-of-br-clearall/
When would one need to use that ?
Why is it evil ?
I don't understand the substitute syntax can you explain ?
Setting clear to both with not allow other elements to float on either the left or right side of the element. The class below is an easy way to add this anywhere.
.clear {
clear:both;
}
So when you want to clear something (that is, if you were to float the next element to the left, it would be below the current element and to the left, instead of left of it) you'd simply add the .clear class.
The problem with the following code is that if later on you decide that you don't want to clear everything after the 'something' class, then you have to go through your HTML and remove the br clear="all" wherever you have that 'something' class.
<div class="something">Cool content.</div>
<br clear="all">
<div class="other">Cool content again.</div>
Instead you could do something like this:
.something {
float: left;
}
.other {
clear :both;
float: left;
}
<div class="something">Hi!</div>
<div class="other">Hi again from below!</div>
That way if later on you decide to float all blocks with the 'other' class then you can just remove the 'clear:both;' from the CSS once.
I was about to post something snarky about you not reading the article, but when I saw that it was just a page of vitriolic rage with no explanation, I figured I'd answer.
It's because there are better ways of doing what you want to do -- namely, by using CSS in the way he does in the article, he has separated the semantics of the elements he's displaying from how he's displaying them. Why is this a big deal? Well, for one, he can more easily transform how his page looks when it's shown on different platforms (mobile, desktop) and media (screen, print, a screen reader for the blind), simply by editing CSS and not having to touch the document itself. This feature of CSS is pure gold.
On the other hand, if you use a construct such as this, you put in a hard constraint about your document's presentation that sticks around no matter what media or platform you're dealing with. What makes him so mad? Because once a developer has come in before him and used <br clear="all">, he has to take it out in order to get the benefits I just mentioned. That's why it's so frustrating. One bad developer can disable a whole host of development scenarios for every other developer who comes after.
As far as CSS goes, I have to say that it's a very difficult subject to just pick up without reading all about how it works. It's hard to explain how the clear attribute works if you don't understand floats. I had quite a hard time myself until I bought a great book on the subject.
When you have floated elements, the parent element can't calculate it's dimensions effectively and sizes incorrectly. Other items that follow floated items may also sit out of position. By clearing an element at the end of your floats, you correct alter this behaviour.
EDIT
Actually correct is probably the wrong word to use as this is what is supposed to happen and using the word correct suggests it is broken.
The author is just going off on a crazy rant about how the same thing can be accomplished using CSS on the DIV elements themselves. He's saying that br class="clear" is unnecessary.
It's also not a good practice because it mixes content with presentation. If a web designer wanted to re-theme the web application, he or she would need to modify the HTML to pull out all of the br clear elements, whereas if this was done as the author suggested, then the CSS files could be swapped out independently of the HTML, making their jobs easier and giving them one less thing to rant and rave about.
The rant is of course justified, as these simple, silly lines of code can actually cause a lot of headaches.
The idea is that your markup describes the information, and the CSS formats that information.
A dummy tag to clear floats isnt semantic, as it's only purpose is for layout reasons. There are other semantic ways of clearing floats that keep this separation. As commented below but here for clarity this is a good resource for semantically clearing floats http://css-tricks.com/the-how-and-why-of-clearing-floats/
Okay that's probably not the best title, I know why we need browser resets: because browsers have different defaults set.
My question that was too long to put into a title is:
If everyone needs to use a reset stylesheet 90% of the time, why do browsers need to set default styles? We're just going to remove them anyways, right?
Because certain rules make sense by default:
Table cells have display:table-cell;
<b> makes text bold, <i> makes text italic
Paragraphs should have space in between them
Unordered lists should be displayed as bulleted lists
The problem isn't that browsers have defaults, it's that the defaults are all different.
Off the top of my head - to do something reasonable when displaying plain html, not styled sites.
Because not everyone uses a "reset stylesheet". The biggest example off the top of my head is Wikipedia, which displays content in the browser's default font.
The reset stylesheets are in my humble opinion only useful for starters who are ranting on the minor styling differences among browsers and doesn't know the default behaviours/styles from top of head so that they're forced to fill all of those styles in the CSS themselves.
If you want to see more thoughts behind this opinionated answer, check this answer.
It is because it gets you into a known state and therefore will look similar across a variety of browsers.
basically, it's a way to keep results as universal as possible by defeating any browser-based rules and omissions before your CSS is applied. http://www.css-reset.com/
See presentation on this page http://www.maxdesign.com.au/articles/css-reset/
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.