How to make a DIV wrap for content with no whitespace? - html

I am trying to get a DIV element to wrap its content despite the content not having any whitespace. The content is a nucleic acid sequence, so inserting whitespace every x-characters is possible, but I'd rather do it more elegantly if possible.
e.g.
<div>TCTTGCTGCGCCTCCGCCTCCTCCTCTGCTCCGCCACCGGCTTCCTCCTCCTGAGCAGTCAGCCCGCGCGCCGGCCGGCTCCGTTATGGCGACCCGCAGCCCTGGCGTCGTGGTGAGCAGCTCGGCCTGCCGGCCCTGGCCGGTTCAGGCCCACGCGGCAGGTGGCGGCCGGGCCCTGAGGCGCGGGATCCGCAGTGCGGGCTCGGGCGGCCGGGCCCAGGGAACCCCGCAGGCGGGGGCGGCCAGTTTCCCGGGTTCGGCTTTACGTCACGCGAGGGCGGCAGGGAGGACGGAATGGCGGGGTTTGGGGTGGGTCCCTCCTCGGGGGAGCCCTGGGAAAAGAGGACTGCGTGTGGGAAGAGAAGGTGGAAATGGCGTTTTGGTTGACATGTGCCGCCTGCGAGCGTGCTGCGGGGAGGGGCCGAGGGCAGATTCGGGAATGATGGCGCGGGGTGGGGGCGTGGGGGCTTTCTCGGGAGAGGCCCTTCCCTGGAAGTTTGGGGTGCGATGGTGAGGTTCTCGGGGCACCTCTGGAGGGGCCTCGGCACGGAAAGCGACCACCTGGGAGGGCGTGTGGGGACCAGGTTTTGCCTTTAGTTTTGCACACACTGTAGTTCATCTTTATGGAGATGCTCATGGCCTCATTGAAGCCCCACTACAGCTCTGGTAGCGGTAACCATGCGTATTTGACACACGAAGGAACTAGGGAAAAGGCATTAGGTCATTTCAAGCCGAAATTCACATGTGCTAGAATCCAGATTCCATGCTGACCGATGCCCCAGGATATAGAAAATGAGAATCTGGTCCTTACCTTCAAGAACATTCTTAACCGTAATCAGCCTCTGGTATCTTAGCTCCACCCTCACTGGTTTTTTCTTGTTTGTTGAACCGGCCAAGCTGCTGGCCTCCCTCCTCAACCGTTCTGATCATGCTTGCTAAAATAGTCAAAACCCCGGCCAGTTAAATATGCTTTAGCCTGCTTTATTATGATTATTTTTGTTGTTTTGGCAATGACCTGGTTACCTGTTGTTTCTCCCACTAAAACTTTTTAAGGGCAGGAATCACCGCCGTAACTCTAGCACTTAGCACAGTA</div>
I need not support every browser. I'm mainly interested in Chrome, Safari and Firefox and other standards-compliant browsers.

CSS style like this will help:
word-wrap:break-word
Other CSS settings that control wrapping are described here.

You can use a "breaking zero-width space" (​), which will break the word but will be ignored when copying into, say, notepad.

Related

Add soft hyphens in a CMS: getting it to work in Chrome

­ is awesome, especially because it works in all popular browsers. You put it in the middle of a word, which tells the browser that the word may be broken in that place. If it does get broken there, a hyphen appears. If it doesn't, the character remains invisible.
But it's not very easy to use for content authors: you have to go into the HTML to add it. Even if you can add it in a CMS, you can't see where it is as soon as you inserted it.
So I went ahead and declared an inline style in my CMS for my authors to use. They can select part of a word, for example <span class="shy">communi</span>cation, and then a css rule will magically add the ­ using an :after pseudo-element! And with some CMS-specific CSS I can give that tag a dotted underline to show that it's got one of those soft hyphens. Works in Firefox and IE8+. Neat.
But the hyphen doesn't appear in Google Chrome! It breaks the word, but there's no dash. I knew it didn't support the hyphens css property, but it does normally support ­.
But all right, so I removed the css style and wrote some javascript to add ­ upon load. Using jQuery, I tried both .append and .after. I even tried innerHTML += '­'. None of them work! How disappointing...
How to work around this?
I figured out a solution while writing this question.
­ seems to work in Chrome only if there is another character right after it (and before it). The issue above is that the ­ character is always the last one within the tag. So I added a space and then closed that space with css. Unfortunately this does not work with a css pseudo element, so I still needed javascript.
I did need to use browser detection because adding the space made it stop working in Internet Explorer and Firefox. (using makes it work in Firefox, but not IE)
$(".shy").each(function(){
this.innerHTML += '­ '; // add the soft hyphen (for all browsers)
// Only Chrome has an issue
if(/chrom(e|ium)/.test(navigator.userAgent.toLowerCase())) {
this.innerHTML += ' '; // add a space
$(this).css('margin-right', '-.26em'); // close the gap from the space
}
});
To be used like this:
<span class="shy">communi</span>cation

Which elements can be safely made contenteditable?

I've been working with contenteditable recently within a HTML5 page and encountering bugs when using it with certain elements, and I'd like to know where and how I can actually safely use it.
I've discovered that making a span element contenteditable results in some buggy behaviour in both Firefox1 and Chrome2. However, making a div or section contenteditable appears completely safe3.
A guideline a couple of people have mentioned is that only block-level elements should be made contenteditable. However, the Mozilla Developer Network lists the heading elements h1 through to h6 as block-level elements, and making a heading element contenteditable is buggy in Firefox4 and can crash the page in Chrome5.
I'd like to be able to use more than just divs and sections, but I'm not clear on what elements I can actually safely make contenteditable. By safely, I mean that using the element under normal conditions, I should be able to perform normal editing tasks without it doing unexpected or buggy things. I should be able to write in it, delete content, cut, copy, paste, and move my text cursor about and highlight text without unexpected or strange behaviour.
So, which elements can I really make contenteditable safely? Is there a specific category? Are there certain criteria the safely-contenteditable element must match?
Bug notes:
Firefox 21 w/ span: Element loses focus if the text cursor is brought to the beginning or end of the element, but not if it got there by deleting content. Highlighting part of the element, cutting and then pasting will split the element in two at that point then insert a blank element between the two parts - without actually putting the text you were trying to paste anywhere.
Chrome 27 w/ span: If the span covers multiple lines e.g. by being wordwrapped, cutting and pasting content will often insert a linebreak after the pasted content.
Unless you make the div display:inline, in which case it can still lose focus as in 1, but apparently only if you bring the text cursor to the end. I don't consider this "normal" usage of the element though.
Firefox 21 w/ heading: Selecting part of the content then cutting and pasting will, similarly to 1, split the heading element in half at that point, and insert a third heading element between the two halves. It will, at least, have your pasted content inside it, but now you have three heading elements where there was originally one.
Chrome 27 w/ heading: Select some content and cut and paste. The page crashes. You get an "Aw snap!" message. That's it.
Demo code
Here's a demo for reproducing the above. It's pretty simple, though at the moment the only thing it isn't reproducing is the lose-focus bug.
[contenteditable=true] {
border: 1px dotted #999;
}
<article style="width: 100px">
<h1 contenteditable="true">Heading</h1>
<p>
<strong>Some adjacent content</strong>
<span contenteditable="true">Span! This is long enough it will spread over multiple lines.</span>
</p>
<div style="display: inline" contenteditable="true">An inline div also with multiple lines.</div>
</article>
In my opinion, I'd say div is the safest bet across the board. Any element you wish to truly edit (be it a span, header, etc), you can place inside the div and edit as if it were just that element. Also, to account for the display:inline issue you mentioned, you could always use float:left or float:right on your editable div to give it an "inline feel" without having it actually be inline.
Hope that helps!
Since this is an evolving feature with, apparent, low priority from the browser vendors support has been sketchy and regressions not uncommon. The current state of affairs is evolving, so check the Googles, CanIUse etc and make sure support is there for your sites visitors, everything else is moot ...
Support in Firefox seems to be solid, at least for some elements, now https://developer.mozilla.org/en-US/docs/Web/Guide/HTML/Editable_content
It works well in Chrome as well as far as my testing goes.
And CanIUse looks good: http://caniuse.com/#feat=contenteditable
There are a number of different bugs related to the feature in the different browsers though, but for simple use cases it should be ok now, as of August 2016.

<br> not causing new line on Chrome

Example page
I have some <span> elements which are inline-block and after the last <span> I have a <br> to break a new line (could be more than just one <br>).
The new line works on Firefox but doesn't work on Chrome (v. 24). Don't know why.
I write this so people who are searching the internet would have something to read regarding this matter, because I did not find anything on google/stackoverflow regarding this.
as soon as u add content, it works. chrome just doesn't like giving you empty space.
try adding on the empty new line.
Edit: changing since there was so much discussion on the topic.
Firefox has a bug, it should not display the newline. According to W3C standards the element "must be used only for line breaks that are actually part of the content". Without content following the <br>, it will not create this newline.
Might not be the best solution, but if you add a white space after the <br /> it works in Chrome.
<br />
Solved: http://jsbin.com/ezatoy/32/edit
By adding a ZERO WIDTH SPACE to the container element like so:
div:after{ content:'\0200B'; }
This insures that there will be some content after the last <br> occurrence, effectively breaking into a new line. no need to add/change any DOM.

How to hide a soft hyphen (­) in HTML / CSS

I am trying to word-wrap an email address within a div, where otherwise it would overflow because it's too long for the div's width.
I know this issue has been covered here before (e.g. this question), but read-on, because I cover all the possible solutions mentioned there and elsewhere.
None of the below solutions do exactly what I want:
CSS
"word-wrap: break-word".
Depending on the div's width, this breaks the email address at awkward places. e.g.
info#longemailaddress.co.u
k
Use a Soft Hyphen within the HTML:
­
This is really well supported, but renders a visible hyphen on the page, leading user to believe the email address has a hyphen in there:
info#long-
emailaddress.co.uk
Use a thinspace or zero-width space within the email address:
  (thinspace)
​ (zero-width space)
Both of these insert extra characters (bummer if user copy-pastes)
Linebreaks...
<br />
... are out because, most of the time, the div is large enough to contain the email address on one line.
I guess I'm hoping for some ingenious way of doing this in HTML/CSS, perhaps making use of pseudo elements (e.g. :before / :after), or by using a soft hyphen but somehow hiding it with CSS in some clever way.
My site uses jquery, so I'll resort to that if I must, although I'd rather not include a whole hyphenation library just for this one little problem!
Answers on a postcard please. (Or, ideally here...)
You can clip the text and use a tooltip
width: 100px;
overflow: hidden;
text-overflow: ellipsis;
What I do is on hover show the full text as tooltip or use the title attribute for tooltip.
<p class="email" title="long-email-address#mail.com">...</p>
Maybe you can try <wbr> instead of <br>
Unfortunately, this won't work in IE.
word-wrap:break-word is based on the width of the container you want to break the word in. It's not going to break it where you decide to. You are unfortunately out of luck unless you want to reduce the width of the div so that it breaks where you want.
The other solutions, as you've discovered, are inadequate for your needs. Additionally, using a "jQuery hyphenation library" probably won't fix your issue either because it'll just be injecting the characters, line breaks, or so on just as you tried. You end up with the same problem.
I don't mean any offense by this, but maybe it would be good to rethink the design, rather than work around the design? Robin's answer is a decent alternative, though you won't be able to select the email address without javascript.

Two BR tags between inline images (within wrapper) causing spacing differences in Firefox vs every other browser. Example done in JSfiddle

JS Fiddle Link http://jsfiddle.net/Xfvpu/1/
Okay so I have a document with xhtml doctype and I use the proper br / tag
but for some reason the gap between two images renders differently in Firefox than it does every other browser.
The page is can be found at http://www.safaviehhome.com/Rugs/Area-Rugs.html
the CSS is all mixed up unfortunately so I can't explicitly post it, but the two images are within a DIV wrapper, and the images themselves are not in seperate divs. They both have image maps, and the size between the two images width only differ by around 20px.
In between the two images are two br /
tags, I tried fiddling around in Firebug but could not figure it out .. And I won't be happy until I figure this out .. it's pissing me off! :)
The difference between other browsers and Firefox is around a 10px difference .. Firefox adds extra spacing .. I'm not asking for any help specifically, just wanted to see if there is some rendering issues I'm not aware of so I can put this issue to rest.
Look in other browsers vs Firefox to see what I mean .. I would really appreciate some help I need to figure this out for my own knowledge.
You cannot rely on using <br/> for vertical spacing. You need to use styles, such as
<div style="margin-top:5px">image goes here</div>
Or even:
<img style="margin-top:5px" src="yourimg.jpg" />
In my experience browsers are sufficiently consistent if you use this approach.
Edited to add:
But (and I can't stress this strongly enough): browsers will never be entirely consistent. Designs which assume that 100% consistency is possible will fail. (If this seems harsh, try getting through one day using only your smartphone's browser. Yuck.)
While I do not know the exact reason why Firefox acts like it does, I can offer an advice. From my experience using br tags for layout are, er, not the wisest idea, since you easily lose control of the exact spacing it creates. Like in this case, where it seems that Firefox intreprets two br tags as two lines, whereas at least Opera take the first one as a line break after the map and the second one creates this empty space.
You didn't ask for a workaround, but I can't resist: take a look at br-less alternative.