I already know the existence of this question BUT, doesn't work for me
Firefox word-break breaks short words at random points
As you can see from the screenshot I applied the mentioned CSS property but seems that the last version of FF broke words at will.
How can I prevent the break of "(09/03/2017)"? and put it on a new line like all the others browsers?
I also tried different settings of those property but nothing.
word-break: keep-all; doesn't work neither
Since is a date you could wrap that information in a
<time datetime="...">
element and apply a white-space: nowrap to it
I have seen in the comments of Is quoting the value of url() really necessary? and CSS background-image - What is the correct usage? that Mac IE 5 does not support quotation marks inside the url() function.
Also PPK's CSS page does not mention the url() function at all:
http://www.quirksmode.org/css/contents.html
So I would like to know what browser support is like for this function. What browsers recognise the value, which ones require what quotation marks, whitespace, and so on.
I realise that everything released in the past five years probably support all syntaxes. It's the older browsers I am thinking of.
Mac IE5? Serious? :) I think this browser is seriously outdated and not being used anymore :)
Anyhow, according to W3C, it's
body {background-image:url('paper.gif');}
And it works for all (older) browsers. For who are you developing if you need support for this kind of ancient browsers?
I have never ever had any issues with background-image for any browser type.
Unless of course you are putting it as a div with no content and not specifying the width and hight of the element...
example usage of background/background-image
#body {background-image:url('mylovelybg.jpg');}
or the long hand (to allow for color and repeating factors
#body {background:url ('mylovelybg.jpg') repeat-x #fff;}
today I hit F12 in FF to load FireBug to see what my site was thinking. Then saw this:
The facts showing from above:
My site likes using them "rounded", alot of them...;
My site is loaded with errors, at least as FireBug sees it.
Is FireFox right and should I assess this and if so how do I change it since I think this is crucial for IE and is the default CSS3 spec, right? Or is there something else happening thats causing all this things to show up in FireBug? I would be happy to hear what I should do to make all this disappear again, really.
Open the drop down in your console tab and un-tick stuff like "show CSS errors".
Also, it's not a bad thing. If Firefox comes across a property it doesn't know (such as border-radius at the time this question was asked) it will just ignore it and continue with the next property. This is why for instance -webkit-border-radius: 2px; -moz-border-radius: 2px; border-radius: 2px; works. Firefox will ignore the -webkit- prefixed one, it would recognize the -moz- prefixed one and ignore the non-prefixed one because the non-prefixed one had not yet been implemented in the version of Firefox you used. (It is now no longer needed to prefix border-radius unless you're supporting an ancient browser)
You might want to pop the IE-specific properties (filter and zoom) into an IE-specific stylesheet, and include that with conditional comments.
As for the rest, you’ve just got an older version of Firefox that doesn’t recognise the newer properties. That’s fine, it won’t do any harm. (Somewhat odd that moz-opacity isn’t recognised, as I thought that had been around for ages, but it’s fine.)
Check this
I think you need to use -moz-border-radius:... declarations for FireFox :)
Playing around with shjs in order to display line numbers, line breaks and spaces, i came across this: Using Pseudo-Elements for the ›hidden‹ characters it behaves just as expected (in Firefox): no line numbers, spaces or line endings get copied to clipboard.
As IE8 displays everything well, I was surprised it behaves different with copy+paste.
Copy+pasting a line from FF looks like so (which is fine):
config = ({
While the same, copied from IE8 reads:
14·config· =· ({¶
The same with Opera, btw.
Does anyone know which behaviour is the correct one, and if there is a way to teach the browser the desired behaviour?
Thanks in advance
Opera and IE are correct: There is no rule which forbids copying generated content. Mozilla’s behavior is btw one of the many reasons why you can’t use the <q> element …
Unfortunately, you can’t bring all browsers in line. Generated content is not part of the DOM and therefor not accessible per Javascript.
I'm trying to use the page-break-inside CSS directive, the class of which is to be attached to a div tag or a table tag (I think this may only work on block elements, in which case it would have to be the table).
I've tried all the tutorials that supposedly describe exactly how to do this, but nothing works. Is this an issue of browser support or has anyone actually gotten this working, the exact bit of CSS looks like this:
#media print {
.noPageBreak {
page-break-inside : avoid;
}
}
Safari 1.3 and later (don't know about 4) do not support page-break-inside (try it, or see here: http://reference.sitepoint.com/css/page-break-inside). Neither do Firefox 3 or IE7 (don't know about 8).
In a practical sense, support for this attribute is SO spotty, it doesn't make sense to use it at all at this point. You'd be lucky if even 10% of your visitors have browsers that can support this.
The solution I used was to add
page-break-after:always
to certain divs, or add a "page-breaker" div in where you want breaks. This is quite ham-handed, I know, because it doesn't do quite what you want, and causes content to not reach the bottom of the printed page, but unfortunately there isn't a better solution (prove me wrong!).
Another approach is to create a stylesheet that removes all extraneous elements (display:none) and causes the main content to flow in one main column. Basically, turn it into a single column, text-only document.
Finally, avoid floats and columns when styling for printers, it can make IE (and FF) act wacky.
Safari 1.3+, Opera 9.2+, Konquerer, and IE8 all support it, at least to some degree.
Firefox apparently still does not.
Firefox does not support this as of 2010-11-30, and thus won't in Firefox 4.
IE8 does support page-break-inside: avoid - but when I tried this on IE9, it's not very successful at avoiding page-breaks (this may be a regression, or perhaps IE8 is also only capable of avoiding page breaks in very simple cases).
AFAIK it doesn't work in any webkit browser; certainly not in chrome.
It actually works in Opera, even on real sites.
Safari 1.3 and later support page-break-inside.
So does Konqueror.
I'm trying to use the page-break-inside CSS directive, the class of which is to be attached to a div tag or a table tag (I think this may only work on block elements, in which case it would have to be the table).
Firstly, there's no need to guess. Just look at the specification, and you'll see that it does indeed only apply to block-level elements.
Secondly, <div> elements are usually block-level elements, so there's no problem applying page-break-inside to a <div> element.
Finally, you don't need to wrap it in #media. You only need #media if you want to apply media-independent rules to only one medium, for instance, if you want to use display: block only for one medium. In this case, you don't need to hide those rules from other media, because they'll only apply to paged media anyway.
From preliminary searches, it's hard to find up-to-date statistics on browser support for this, but it seems that Firefox 4beta6 supports it and Chrome 7 does not. Chrome also breaks pages halfway through a line of text, so that part of the text appears on one page and part appears on the next. Uncharacteristic lack of attention to detail, but I guess neither Google nor Apple care about printing things.
Firefox 4 also adds some nice headers and footers to your prints with url, page title, site title, number of pages, and time. Nice.
As a bit more information further to Eamon Nerbonne's answer on the IE rendering (IE8+), you need to make sure the browser is in standards mode. This article on MSDN shows what is necessary - including a meta tag in your html to force the issue:
<meta http-equiv="X-UA-Compatible" content="IE=8" />
Feels kludgy, but there you have it... seems to work more consistently.