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.
Related
I'm using Google font 'Pt Sans' which works on both Chrome and Safari, but on Firefox character accents are displayed after their respective letter (äåö).
I have ensured that latin-ext is enabled and running, have double-checked that the correct font is being called and have run through the related css to see if I have done anything odd but can't find any abnormalities.
The accent takes the same amount of horizontal space as the letter that it belongs to, but to the right of that letter - hovering over nothingness.
Are there any known rendering issues with PT Sans? Or is this perhaps a Google fonts / Firefox compatibility issue? Any clues to what I might have missed are appreciated. Thanks.
RESOLVED
Thanks to #deceze for the answer.
As a spontaneous suggestion, have you tried/ensured that you're using U+00E4 (A WITH DIAERESIS), and not U+0061 U+0308 (A, followed by COMBINING DIAERESIS)? The result is supposed to be identical, but perhaps you're stumbling across a bug in either Firefox or the font.
Firefox was not displaying äåö correctly due to it rendering seemingly identical two-part characters incorrectly and seperately (a¨). I will have to replace them all with single symbols.
My site acro.batcave.net shows up differently on IE (Windows 7, IE 11.x) and FF (Windows 7, FF 37.x). Chrome has the same behavior as FF. The CSS is located at acro.batcave.net/css/index.css. Initially I thought I might have used non-standard CSS (the intent is to use CSS3). But I did not find any using the CSS validator at W3C. What am I doing wrong and how do I make FF (and Chrome) to display this similar to IE?
I don't know how that's happening but when your site loads in Chrome the CSS returned is all gibberish. That's why its not getting applied.
Check out the screenshot below:
http://screencast.com/t/tCYGkUnAxO
You have saved the HTML code as UTF-16 with a byte order mark, and I suspect that you have saved the CSS code the same way. Firefox and Chrome fail to decode the CSS file to text because of the encoding.
Most browsers doesn't support UTF-16 for data files unless you specify it in the link tag or the header. Instead save the files (the HTML too) as UTF-8, without a byte order mark.
When in the Element section, in the right panel, a CSS set of properties is detected twice:
Same CSS file, same line number, I have only one file named commonCSS. It happens for some elements but not for all. What is going on?
EDIT: I tried it with Firefox & Chrome so it's not browser related.
Stupid me: it was called twice in the source... Jeez, this code I'm maintaining is so awfully badly written.
I have a custom cursor that is using an image. My original code:
cursor:url(../images/drag_mini_bg.png);
I then discovered that Firefox requires you to define a default backup in case the image is not found, and changed it to:
cursor:url(../images/drag_mini_bg.png), default;
This worked for Firefox and Chrome, but not IE. I read that IE uses a different source for the path than other browsers and implemented this solution:
cursor:url(../images/drag_mini_bg.png),url(/images/drag_mini_bg.png),default;
(The second url is relative to the html file rather than the css file that this code is included in.)
This didn't seem to help, so I found out about this bug and changed the image to a .cur file:
cursor:url(../images/drag_mini_bg.cur),url(/images/drag_mini_bg.cur),default;
However, it is still not showing up in IE. Anything else I can try?
Most of what you've read is correct, but I'll make a few amendments:
Firefox does indeed require the additional parameter to be added. My understanding is that the ideal value for this is auto. But if default works for you, use it.
As you've been told, IE can only display cursors of the .cur file type. PNGs and GIFs do not work.
However, I've never heard anything about IE using a different path; the same path has always worked fine for me in all browsers (when using a CUR file, of course). You might want to provide a reference to where you heard this, but I'd suggest that dropping the second URL may solve your problems.
There's a good site called Quirksmode that has a lot of browser compatibility tables. In particular, they have a very thorough table covering CSS cursors, which shows exactly how to format it to make it work in all browsers, with examples and notes about the quirks.
Hope that helps.
If you're still trying to figure this out 8 years later...I'll add that some browsers have a maximum image size, so maybe yours was too big. I believe you want to keep it under 32x32 pixels.
I have a webpage which I have made entirely as svg (apart from the html to load the svg). So far, so good, and you can see it here (not yet complete): http://kitandmarcin.us/svgcontainer.html (it's for my own wedding, so "the client" doesn't care that not all users are getting the same experience).
This works just great in Firefox, Safari, and Chrome. It basically doesn't work in IE (including IE9), or Opera. I haven't tested anything else.
My question is, what is the best way to handle giving IE (and, I suppose Opera) users either (a) a redirection to a different page, or (b) show them something else (probably a screenshot).
I would prefer not to use javascript, because I suspect if they are already having trouble viewing the page, problems on their end with javascript are quite possible.
It works fine in Opera 11 / Windows.
You should consider just making it in good old HTML/CSS - it's not a particularly complex layout.
Alternatively, use javascript on your parent page to redirect users of IE to a static PNG version of your SVG.
IE8 simply does not support SVG without a plugin - javascript will work just fine on the page. However, SVG is supposed to work in IE9, so I'm not sure why yours doesn't. I don't yet have IE9 here, so I can't test.
ForeignObject is probably the answer why it doesn't work. Given that your svg is quite simple, I'd suggest removing the foreignObjects and using svg text and tspan elements instead. That should make it work in all browsers. And seeing how you used inkscape to create the svg it could have done all the linewrapping etc for you anyway.
From other answer about flow-elements in inkscape:
Inkscape can generate <text> and <tspan> for
you quite easily, just don't click and
drag an area but instead just click
where you want the text and start
writing, then press return where you want a
new line.
I'm not sure if IE9 supports foreignObject.
There's a way to do automatic linewrapping in svg tiny 1.2, which is supported in Opera, a workaround solution could look something like this. But to get IE9 compat too, you'll probably have to go with text+tspan.