I have a character applied to a :before that sometimes doesn't display correctly in Chrome. I can't quite work out the trigger, but I've found that opening the console and refreshing (while the console is still open) seems to get the character back again. However even after closing the console and coming back later it works fine - and then at some point later I'll notice that it's reverted back to this unusual character - but as I say I haven't noticed what triggers it, if anything. A standard refresh without interacting with the console doesn't resolve it.
How it's supposed to look:
How it sometimes looks:
As you can see the character is wrong in the console style preview, as well as on the rendered page (but the CSS is unchanged, and states: content '“' (that's a copy and paste with the actual character, by the way).
(I have tested the page in other browsers, and it looks fine, but as I don't know what triggers it I'm not sure that's relevant).
The only place I've ever seen an issue like this is with editing code directly in Bitbucket, on save many characters turn into these strange little glyphs. But that isn't the issue here.
I've double checked and I'm declaring the charset on all pages: <meta charset="utf-8" />
Any ideas?
EDIT
I've now seen this issue on two sites I'm working on locally - with very different codebases. The only commonalities are the fact that it's on a :before pseudo element and running in Chrome.
Try unicode content: '\201c';.
Related
I have a very pretty calendar report that I've created on one machine, that shows my company's daily revenue as a color coded block for every day for the past several years. After finally getting a color scheme down and pretty much finalizing it, I went to test it on another machine - and hit a rather large obstacle.
This is the report that I used as a template:
http://bl.ocks.org/mbostock/4063318
It's awesome. And, inside Internet Explorer 11, it looks fantastic. I never would have expected that copying the code and testing the report would produce a blank page, but there it is. On that page, the calendar report is visible. In IE 11. Copying the code to a new html file and opening it, shows nothing. In Firefox, however, everything is visible. as is.
Now, there's a part of that page that points to "//d3js.org/d3.v3.min.js"
And I figured out that in order to make that work in firefox I had to add the http: in front, so that's not my issue.
I'm literally sitting here at my desk staring at two browser windows open and pointing to the same html file. One contains my beautiful report, one is a completely blank page.
Some cursory google searches reveal that IE 8 or lower have issues with the svg. I can't seem to find any references on someone having a similar issue though. Their situation seems to be that with IE10, you need to specify the height and width, not just one or the other, to make sure everything scales properly.
If I could have my way, I'd just run Firefox on all of the machines that are going to run the report, even if it's just for that one thing! Alas, I am but a mere peasant coder and so I have to make it work. in the dreaded IE.
Are there any svg/html/d3.js coders out there that can tell me another way to spit out the data I'm using so that I can get what I'm looking for?
copying the code and testing the report would produce a blank page
Because you're outputting invalid HTML. There is no html or head element for starters.
Output your code in to a file like example.xhtml and open it in Firefox (specifically) as it's XML parser will very quickly tell you what line and column the first XML parser error is occurring on. You are rendering in standards mode instead of quirks though that does not imply your page meets standards.
var m=(document.compatMode == 'CSS1Compat') ? 'Standards' : 'Quirks'; window.alert(m+'-mode.');
I have a QGraphicsWebView to which I construct a page by appending tags. For example:
webElement.appendInside("<img src=<img src=\"qrc:/img/ioLlogoTopLeft.png\" />");
This happens in a secondary QThread. I also use resources to set styling in the same thread:
defaultBaseFrame->setStyleProperty("background-image", "url(qrc:/img/ioLGradientTop.png)");
Both of these lines were working fine, but in the last few builds they've stopped working, and I've no idea why. Instead of an image I now get an empty frame, and the background fails to appear. The resource paths seem fine, and work fine in other (non web-view) parts of the program.
On the other hand, when I replace an image URL with a location on the internet (an http:// url), the image loads normally.
Is there some quirk to using resources in a multithreaded environment (or was that just a red-herring?) Resource images were working before, and I can't think of anything relevant in the code that I've changed recently.
Solved it. And not a particularly satisfying solution; more just a quirk of Qt. It turns out the problem started when I removed the (I assumed) redundant initialisation of the WebView to a blank page:
webView->setHtml("<html><head></head><body></body></html>");
When I re-added it, images in resource files started working again. There didn't seem to be any other difference in functionality; all the other page elements render the same, just that one little quirk was fixed.
Recall that I'm building up the page from a blank DOM tree. I had falsely assumed that the above line was redundant because QWebView always inserts those boilerplate HTML tags automatically regardless, and almost everything works as it should either way.
I've got a super strange and hard to diagnose issue. Hoping that someone on this forum has run into it before. Basically, I have a wordpress + woocommerce page loading like this:
As you can see there is a lot of extra whitespace. The problem is I can't figure out where the whitespace is coming from because every time I inspect element, the page removes the whitespace immediately and it looks (correctly) like this:
If I keep the "inspect element" window open and refresh the page, the whitespace returns, but as soon as I change the CSS in any way whatsoever (ie remove a random attribute or change anything), the page once again fixes itself.
If I locate the area where the whitespace should be (by not changing anything), there is literally nothing there that the whitespace is attached to. It's as if it's invisible.
I'm using Chrome (34.0.1847.131 m). Any ideas what could cause this strange behaviour?
This seems like an issue, somehow being caused by javascript. I've worked with WC before, and the JS they use is really buggy. I'd suggest trying to turn off javascript, and see if the issue still occurs. The next place to check would be the template itself. After that, check woocommerces filter set/action hooks. From my experience, WC's templates are super badly done (Seriously, who still uses tables). It caused me all sort of weird headaches as well.
Sometimes when I'm looking at a site with some code blocks, navigate away from that tab for a bit and come back to it, the formatting appears to be lost.
For example, earlier I was looking at some of the Django documentation:
And then when I left that tab open for a little while, looked at other stuff and then came back to it, this is how it looked:
Of course, when I refresh the page I get the formatting back so it's not a huge deal, but I'm curious as to why this happens at all.
Note: I use Chrome and haven't tested this out with browsers, so it could "just" be a Chrome issue, but I couldn't find anything when I searched the Chromium bug tracker.
I'm trying to print this page under the link graded fabric ArcCom in IE and Firefox. However, it's only printing the first page, without the complete table. How can I fix this problem? Any suggestion?
I suppose you mean link “graded fabrics,” which points to http://www.calibredesign.com/clients/spec/fps_fabric_arc.html (though if you follow the link the simple way, this page opens in a frame). Viewed separately (after right-clicking on the link and selecting “Open in new window”) it seems to get printed OK.
The reason why it does not print OK when opened in a frameset may depend on the large number of HTML syntax errors on the page. Errors like missing </table> tags may confuse browsers in printing.