I've came across this issue where the browser (Chrome) is sometimes rendering characters as completely different ones, however in inspect element they're written how they should be. You'll see in the images that on the right inspect element shows what it's supposed to be, and on the left shows what it's rendering as.
I can't find a reliable way of replicating this problem, there is no correlation of events that I can see to cause this to happen
I have noticed that the replaced words contain the correct amount of characters for the word it's supposed to be.
This can happen to any element on the site as far as I've seen. It doesn't matter if it's getting the content from the database or if it's hard coded.
Refreshing the page usually causes text to render as normal. It doesn't happen all the time.
I've just recently joined stackoverflow so I need 10 reputation to post pictures apparently.
http://imgur.com/G3yvRg2
http://imgur.com/Jqk2jwB
Does this happen only on one particular website, or some specific sites? I was thinking that maybe they used JS to like dynamically change the HTML (for whatever reason they would want).
Another cause might be some plugin that you installed in Chrome and that is working baddly / causing issues.
Also please post the encoding that the page(s) use (like UTF, ISO), that might help.
Except that, to really narrow it down to a Chrome problem, check in other browsers for the same issues.
It appears that the issue seems to be caused by 'text-rendering: optimizelegibility;'.
Mostly when used in conjunction with text-transform:uppercase;/text-transform:capitalize; , or letter-spacing.
It may also be an issue with opimizelegibility and Proxima Nova since I've never encountered this anywhere else.
After looking up the textrendering:opimizelegibilty; property more, I've released that it's an awful decision to use it more than sparingly due to performance issues (And this strange one..). From now on I'll only be using it in cases where the kerning looks particularly poor.
Related
How do you get the string that browser rendered, programmatically, using Node/JS — the same thing as if you copied everything in a browser window?
For example, for this given HTML source (notice spaces between "a" and "z"):
<html><head></head><body>a z</body>
which renders with a single space in Chrome:
how would you get this string with single space, a z?
I tried Cheerio and JSDom, but after I load the <html><head></head><body>a z</body> as string and query the body contents, I get original piece of code back, the one with many spaces.
Thank you.
Good question, however I don't think that there will be feasible way to do it.
First, what is happening is greatly explained in this article When does white space matter in HTML?.
Since white spaces are not going anywhere, but represented in such way only by browser, it will hard to troubleshoot it server side. There are reasons for that:
You don't know in which browser it will be rendered, it could be even Lynx, will it show spaces or not you don't know.
That means that, if it would be possible, you would have to test with every browser in the wild.
For instance Server-Side-Rendering (SSR) technology, partially applies / renders pages on server side, but still because there is no actually a device that will display it, it is partial. So most likely you will get same spaces.
Imaginary possible solution would be to use something like KarmaJS, install some headless browser on server side, and execute some test cases, so that KarmaJS would control browser to render the page, and may be you will be able to get access to rendered, CSS applied and hopefully spaces-trimmed DOM. Which I'm not sure, and it will be limited set of browsers.
Another imaginary possible solution would be to use WebKit or Blink engines, or perhaps Electron, to some how via API attempt to acquire that DOM.
I'm putting together a page, and am really struggling with backgrounds across browsers.
The page uses a number of alpha-blended backgrounds, box shadows and border-radii and it is composited almost entirely using inline styles (essentially there are few/no CSS classes used).
IE9 is my primary browser, and in it, the page looks great. However, on Chrome (and I'm told Firefox), most of my alpha-blended backgrounds render either not-at-all (transparent), or as solid colors! I'm using Standards Mode with an HTML5 !DOCTYPE declaration, so it's not as though I'm leveraging IE quirks or anything!
Clearly on IE versions before 9, the backgrounds (and other things are problematic). But I'm not concerned with supporting ancient software, and those users get a browsing experience that they deserve.
The common refrain for years has been that "transparency on IE sucks!", so I was comfortable in expecting that if I got it to work adequately on IE (typically the worst platform), then the others would just fall in line, but here I am struggling in the opposite direction! I'm using the standard "rgba(r,g,b,a);" directive on the "background-Color" attribute so I'm not using any radical DirectX filters or other magic, nevertheless, on (NOT Internet Explorer 9+) browsers, I'm getting some non-alpha-blended results (sometimes it works, sometimes it doesn't).
The site can be previewed at: https://net-xpert.com/ -- All of the pull-down menus are supposed to have translucent backgrounds, and so too the hovering link-bar at the bottom of the page. Also if you go to the "Ask us a Question" page, the dialog there should have tinted backgrounds on all of the input fields...
Oh, lastly, I am ENTIRELY LOATHE to implement ANY b/s, browser/platform-specific, 'experimental' style-codes! Anything in CSS2/3 is fine, but I simply REFUSE to use any kind of "-browser-some-quirky-CSSAttribute" styles! (I wish more developers would do this too! -- then browser manufacturers would be under greater pressure to adopt these STANDARDS and our lives would be SO MUCH EASIER, but I digress...)
Anyway, any insight on a standards-compliant solution would be greatly appreciated (even if it's just a communal acknowledgement that "ya, Chrome et al is currently not implementing this correctly...", at least then I'll know there's nothing to be done about it...)
Thanks!
Well, this is a very late answer, but maybe this'll still be of use to you (your site still seems to be up and running).
I have a should-work-for-you solution, assuming that you can modify one of your stylesheets. As to WHY you've encountered this problem ..? I can only speculate, because I don't know how to recreate your exact configuration.
The fix;
div[id^=mainMenuOverDiv] {
background-color: rgba(128,128,128,0.9) !important;
}
I'm not a fan of using !important unecessarily, and you may be able to remove that by using greater specificity. I've tested this in Firefox, though and it seems to work - obviously, you'll want to substitute the actual rgba(x,x,x,x) values with your own.
You seem to be using some JavaScript (I'm assuming) which randomizes the DIV ID every time you hover over the menu - but the beginning remains consistent (i.e. one time it will be #mainMenuOverDivjkhasdfsd89f9f9sdfl3l4l34lfdbvbc, then the next, it'll be #mainMenuOverDivLSDklsdkmlzxncbzmxnc90234xcvassf). Using the 'starts with' CSS selector (as provided in the example), you can still isolate the menu despite this potential spanner in the works.
It's interesting (and probably insightful) that this even works, given that inline CSS usually can't be overridden.
As for why this is happening, one possibility is that some JavaScript generated code is not correctly porting over to the non-IE browsers. Alternatively, if you're using it anywhere, code minification may also break some functionality (and vary between browsers) - many minification plugins need to be tweaked for individual setups to ensure that everything continues to work fine as one size does not necessarily fit all. For example, you might find that on one site you can minify everything except the JavaScript, while on another site, JavaScript is fine, but you can't minify inline CSS, etc. Google Analytics code sometimes falls victim to this.
So to my eye, the issue possibly isn't to do with IE/Chrome/Firefox or Safari - transparency is working fine on all of them - I think it's most likely the way your code is being manipulated or delivered to the browser.
Hope that helps in some way. Let me know if you can't use an external stylesheet and I'll try to find an alternative.
I want to make this page look the same across all browsers. Specifically, I want the wrapping point of the text to be exactly the same on all browsers so I can create a PDF version with 100% accuracy. Check this out in FF vs. Chrome, for example.
http://santaspencil.com/desktop/embedded-test/embedded-fonts-test.php
Questions:
- Can it be done?
- Are there alternatives that don't require the user to download a plugin?
You should consider embedding the font file into your CSS. But as usual stone-age IE can not do this as you will need to include an EOT font file on your server.
http://base64fonts.com will convert your font files to base64 and then produce a css code for you to copy and paste in your html. this will help with insuring your font loads across browsers (except IE).
Good luck
... I want the wrapping point of the text to be exactly the same on all browsers ...
Bang head here (sign on brick wall). Web technology doesn't even try to do this. If you figure out a way to provide your own font -such as embedded webfonts- you can SORTA make it work. But if 100% is your goal, you might as well give up sleeping.
One of the neat things about browsers is their "liquid layout" capabitity, automatically rendering a page differently on a tablet than on a desktop to fill the different screen sizes for example. One of the prices you pay for this infinite rerenderability though is inability to specify the appearance exactly. Besides, edge cases will always arise and bite. For example if the available line is 0-73 units and the text you want to put in it is 74 units long, does it "fit" or not??? (i.e. does zero count? and is using up the very last unit a "fit" or an indication of the need to "wrap"?)
The only way to have browsers render your exact appearance is to give them what appears to them to be an image. Displaying the text on your screen, taking a screenshot of it, and making that screenshot into a *.GIF is one way.
A PDF file works too, as it appears to a browser to be a "funny" image with its own rendering engine. Most rendering engines are probably the same (i.e. the ones from Adobe) even if the browsers aren't the same, so it's much more likely to work. Providing PDF documents on the web works pretty well and is pretty widely supported. If a URL looks like http://yoursys.yourdomain/yourpath/yourfile.pdf most browsers will fetch it and start their PDF rendering tool and display it directly ...usually INside the browser window so the user isn't even aware of a different application having been used.
As to the last part of your question, it's the wrong question. It should be "solutions that don't require a plugin THE USER DOESN'T ALREADY HAVE". The advantage of a PDF plugin is the vast majority of users already have it. Not all plugins are evil/inconvenient ...just the less common ones (or the Flash plugin if your target is iPhones where users aren't even allowed to download it:-).
good luck!
This is probably way too late, but I did not know this until today. There is something called a non-breaking space, represented by in HTML, you can use to prevent unwanted line breaks or other such thing. Wikipedia has a pretty good writeup on it.
http://en.wikipedia.org/wiki/Non-breaking_space
I have a big performance issue in IE6 even with javascript turned-off.
It's strange because sometimes when the page is loaded, the header is floated next to the footer, or slideshow is over the the content.
I wonder if someone had same or similiar issues in IE6 and if i minify a generated source code into a one-line, will it help somehow to gain loadspeed in that browser ?
-Want to mention that it should be compatible with ie6 so please, do not post a messages like - use modern browsers.
The problem was in MS png fixer inside css. Even if i turned off a javascript, it still works, so when i removed css lines with ms filter for png transparency, it starts working like it should.
Thanks for any submits.
I doubt that removing newlines would increase the speed in any noticeable fashion.
That is, the performance issues are likely not caused by line count but rather the size/number/type/cost of the elements/operations after the parsing.
The actual lexer that handles the newlines should see them no differently in the stream than any other character. Depending on exactly what context "source" means newlines have some effect semantically at the parser:
CSS: none (ignoring embedded newlines)
HTML: possible new text-nodes or different content
JavaScript: automatic semicolon insertion (or embedded newlines)
However, there is no reason not to try a minified version quickly to see if it makes a difference and, more importantly, to satisfy your curiosity ;-) I would definitely heed the other suggestions as well, such as checking the page (everything) for validity.
Happy coding.
You haven't specified what your page consists of, but my guess would be you're outputting the mother of all HTML tables?
The reason I guess that is because IE6 is known to be extremely slow when rendering large tables, particularly where the column widths are variable. (later IEs are also slow with this, but not as bad as IE6)
The reason is that the browser attempts to render the entire table before displaying anything, and performs a lot of calculations to work out how to render it.
The answers on this question may also help you: Are large html tables slow?
I have a problem with my matrix not rendering properly in HTML. It's a minor issue but annoying nonetheless.
The problem is that the right borders disappear on the rightmost column. It only happens on cells with data in them. Like so:
alt text http://img193.imageshack.us/img193/7718/med100width.png
Does anyone else experience this? Workarounds? Fixes? Does SSRS 2008 have the same issue?
I have had similar problems, particularly cross browser, with SSRS. The standard of the HTML generated is very poor and hence often is quirky to say the least even in internet explorer.
The client I was working for had strict standards for accessibility and browser compatibility so I looked into improving the standard of what was outputted a lot but didn't get anywhere. As reports are basically XML I was hoping someone somewhere may have written a better engine to transform this into XHTML but it appears not.
I ended up playing around with table size and column widths which in some cases seemed to resolve some of my issues.
Upon further inspection it seems that all numbers are enclosed in divs, with the attribute width=100%. Using the developer tool in IE I saw that removing width=100% restored the borders.
One solution could be to write your own renderer based on the standard html and filter out the annoying little buggers.