This is really weird... When I open the following simple HTML document in Internet Explorer 7.0.5730.11 (on Windows Server 2003 Web Edition SP2)
<html>
<body>
<p>+</p>
</body>
</html>
it shows me a totally blank page. FWIW, this is just a trivial "repro" sample. In real HTML documents, I observed other, even more bizzarre effects caused by presense of the "plus" character that follows a tag.
NB: The problem appears to be extremely ittermittent. Most of the time it does work properly (i.e. displays the "plus" character), and I still can't find any way to reproduce this problem at will.
Some additional details based on recent comments:
There was no server involved. I was opening a file on disk (i.e. used file:// protocol).
The file did not contain anything except five lines shown above. No document type declarations, no character encodings, no nothings.
Looks like a bug in IE. Did anybody encounter the same or similar problem?
NB: I appreciate all the responses received so far, but neither of respondednts encountered this problem. Something tells me that 99.(9)% of StackOverflow audience will not be able to reproduce it. :-)
Does it work if you use the numeric character reference notation?
<html>
<body>
<p>+</p>
</body>
</html>
Does it work if you use a Doctype? IE does get a bit picky if you don't use a doctype (insert no-right-to-be-picky pun here).
By intermittent do you mean using the same code it appears and doesn't? That sounds really strange.
CLOSED - NOT REPRO... er I mean I only get the +, no matter how many times I refresh. I suggest using the HTML entity reference - but this might be a problem with your system/browser if others can't reproduce either.
For whatever it's worth, I just tested this on IE 7 (7.0.5730.13C0) and it consistently displays the "+" even with several refreshes (at least 10 or 12). You didn't mention an OS but in my case it's Windows XP SP2 (Help About displays Version 5.1 (Build 2600.xpsp_sp2_qfe.070227-2300: Service Pack 2). The OS may make a difference in this case.
It's possible that this is due to the server, particularly if it's trying to parse the page as a script. To check:
What HTTP headers do you see when the effect occurs?
When you "View Source" at that point, what do you see?
Does the effect ever occur when you load the page directly as a file?
Does the effect ever occur in other browsers?
Related
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.
I just got to know that I can use tag like:
<a/href="http://www.google.com">Google</a>
I have not read this thing ever in my career, might be, I have limited knowledge however it is creating some problem for me, because I am matching "<a href" in content and processing accordingly like making it open in new tab etc.
I tested it on browsers Chrome, Firefox and both allow it to be a link.
Is this standardized?
It isn't standard. It is an error. Browsers are very good at error recovery.
Looks like a syntactic markup error. Modern browsers will correct this, but older ones may show an error / cause the element to misbehave. If you run the page through a HTML validator it will fail.
just add protocol http:// before the link
and
add target="_blanck" for new tab
Follow
</br></br>
Follow
</br></br>
call us
Here's a snapshot of my HTML code as viewed after clicking View Source in IE9. I opens up in Notepad++
Here is the code as parsed by the IE9's Developer Tool:
Why is there a disconnect between the two?
As #Shadow Wizard suggested in a comment, the probable cause is some data character before the <!DOCTYPE ...> declaration. For example, the problem is reproducible by taking a valid XHTML document and inserting the no-break space character (NBSP, U+00A0) at the very start of the document. But the presence of a BOM at the start does not cause the problem (at least not on IE 9, hardly on any browser in use). There is a large number of invisible or barely visible characters that might cause the problem.
The Developer Tool does NOT show you the source of your code, it shows the DOM (Document Object Model) that's why there are differences. You can read more about DOM here: https://developer.mozilla.org/en/DOM/
The content showed in Developer Tool represents your parsed Source with some modifications to be more readable and without incorrect tags, in two words it does not show the exact source.
The web application im working on has a few custom attributes on HTML elements to store data that is output.
Only happens here and there and so far I haven't noticed anything wrong in how the page is rendered on IE7, IE8, FF 3.5 and Chrome 3.
I'd like to assume everything will be ok but just wanted to check if anyone else has had problems with custom attributes in other browsers.
I understand its not part of standards to add custom attributes but all that matters to me is how the page is output to customers.
html5 supports custom attributes with names starting with "data-". Using those yields the smallest chance that anything breaks in the future.
Browsers silently ignore tags or tag attributes they do not understand, so you're good. That said, your HTML won't validate (I know you said you don't care, but still) plus there are other possible ramifications.
See this question for more details.
Just be sure to use the same case when referencing the attribute in code. I've had issues in the past with Internet Explorer returning null with getAttribute because my case didn't match what was defined in markup or previously in code.
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.