Is there a way for nesting an image in an HTML page *inline* in IE7?
I can't use external resource, all because of a particular server configuration (it's a web dispatcher in maintenance mode that redirects all requests to a single .html page).
So I can't afford using the classical embedding by using the following:
<html>
<img src="mypic.jpg" />
</html>
When looking for a solution, I found these:
Using inline SVG within an XHTML file # => I can't use XHTML extension in my case the page has the .html extension (and I can't change it)
Using base64 encoding # => It works pretty well with Firefox & Chrome, but not in IE7
None of which seem to be working in my configuration.
The more I seek the less I hope. Any ideas?
The only option, as far as I know, for embedded image in an HTML document for current versions of Internet Explorer is VML (which isn't supported by anything other than Internet Explorer).
You could use something like Raphaël to abstract the VML or SVG into a single JS script (but that would add a dependency on JavaScript).
That easiest option would probably be to reference a normal image on an external URI … on a different server.
For the svg solution, your page doesn't need to end in .xhtml. In fact, it can end in whatever extension is handled by your web server.
The page being in xhtml is defined by its doctype definition. Put the doctype definition of xhtml 1.0 (strict or transitional) or even better xhtml1.1 and embed svg in the page.
As an alternate solution, you could try to output the image directly with an .html extension, keeping its original mime (image/jpeg for instance) but I'm not sure it would work.
Instead of redirecting to a single .html page, you could redirect to a single image and put your text on the image. This has obvious drawbacks, but how important is the image?
What you meant by base 64 encoded?
Related
We have a universal React application sitting behind a CDN.
We want to serve up HTML with srcset images from the server, but need to handle the fact that IE will not support this HTML feature, ideally using feature detection.
As the site is served from a CDN, IE will get the same initial HTML as other browsers. When the page loads in the browser, we want to swap out these srcset image tags for some different HTML, but this means React will complain about a mismatch between the client side HTML and the already rendered server side HTML.
What's the best way to handle this?
e.g.
ignore the warning, or specify it's ok somewhere?
use a client side polyfill that happens after the page has loaded e.g. using componentDidMount? In this case, how do we handle subsequent renders of an unchanged component not rewrite this HTML on the client?
use a cache key on the CDN for the user agent - but this would mean sniffing browser rather than using feature detection
The best and most compliant way is to leave both attributes. My guess is that browser will use "src" as a fallback but use "srcset" if available.
No polyfills or strange manipulations needed here :)
I have object tag that look like this :
<div id="embeddedPdfContainer"><object data="<c:url value="/download-pdf/${id }"/>" id="embeddedPdf" width="820" height="1135" type="application/pdf"></object></div>
In chrome this tag works the way I want it to. In firefox it doesn't work at all and it's messed up in IE. Here's album with screenshots in each browser. What are my options here ?
Also on firefox I figured out that this pdf doesn't work with default firefoxe's pdf viewer. When I choose to use adobe acrobat extenstion for pdf documents it works perfectly.
You can just write the link to the pdf directly into the data attribute like this:
<div id="embeddedPdfContainer"><object data="/download-pdf/some.pdf" id="embeddedPdf" width="820" height="1135" type="application/pdf"></object></div>
I tested it with Chrome and Internet Explorer (different versions) and it works
If you want to stay with the c:url option you should change the second " to '
so changing this:
"<c:url value="/download-pdf/${id }"/>"
into this:
"<c:url value='/download-pdf/${id }'/>"
in order to not "escape" the string
When you deliver dubious HTML:
<div id="embeddedPdfContainer"><object data="<c:url value="/download-pdf/${id }"/>" id="embeddedPdf" width="820" height="1135" type="application/pdf"></object></div>
^ ^
| |
Start End?
... browsers try to figure out what you had in mind, with a varying degree of success that depends on the algorithms they implement and how imaginative the webmaster is. Different browsers can't always agree on how to handle valid code (where there're clear rules and specs) so it's to expect that the level of disagreement increases with invalid code.
IMHO, the simplest path to obtain cross-browser compatibility is to generate valid code. As help, you can use the on-line W3C HTML validator or whatever equivalent tool your IDE provides.
Your jsp code seems to be syntactically correct, but we can't know if the generated code is meaningful. Instead of writing the jsp code, you should write the generated html code, and its related css code.
Anyway, regarding the Firefox's issue, I think it is due to this Firefox bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=937663
Lastest version avaible (Firefox 28) seems to be still affected, maybe next one will fix it.
Regarding Explorer issue, it could be due to a difference in page's rendering. Writing an IE-specific ccs code will fix the issue.
I wonder that this works in any browser!
c:url is part of the JSP Standard Tag Library (JSTL). And to use JSTL core tags you should include in the JSP page at least:
<%# taglib uri="http://java.sun.com/jsp/jstl/core" prefix="c" %>
Next thing is that the PDF format is also no HTML (format)!
The handling of PDF files depends heavily on the users system settings and configuration.
Any browser would need an (integrated) plugin to display PDF files!
See e.g. this question here at SO: Embed Pdf in html5
As you can see therefore normally an embed element is used with a type attribute of type="application/pdf".
But this is also far from ideal and won't work in every browser!
What are my options here?
As written in the accepted answer of the above linked question, you should "convert the PDF to HTML5 and embed the HTML5 version."
First of all the c:url tag has nothing to do with the browser-side behavior. The tag should be rewritten by server and the browser should receive an absolute path. (Maybe you can post source from your browser?)
So the problem is only the browser compatibility of PDF embed in <object>. Most modern browsers should work with this tag including Firefox, so you should check whether you have pdf plugin properly installed on your Firefox.
For the IE problem you didn't mention which version you are using, so it may be solved by using <embed> other than <object> to solve this problem. According to this answer, you may try this style for better compatibility:
<object data="abc.pdf" type="application/pdf">
<embed src="abc.pdf" type="application/pdf" />
</object>
Does the use of an external viewer, morelike https://docs.google.com/viewer , within an <iframe> or an <object> would help ? This a compromise as far as you cannot change configuration of visitor browser to add/load an extra plugin.
For the styling part, you can set display:block to <iframe> or <object> , set size and margin.
<edit> this is not the problem </>
are you sure of the use of your quotes and this part ? "<c:url value="/download-pdf/${id }"/>"
You are wrapping value and data together
I have an iframe on a page that I need to initially have a blank src for, as I eventually set the src with javascript.
I had been using a however have encountered an issue in Safari and Chrome where this loads a duplicate copy of my page within the iframe.
I read about "about:blank" in another question, however I've read that IE9 sends a null request to the server when you use this as the src. I've also yet to find anything listing this src as standards compliant.
Does anyone have an alternative to "about:blank" that they use to create an empty iframe?
about:blank is the way to do it. Alternately, you could just insert the whole <iframe> element with JavaScript later, and don't worry about a valid "empty" src.
One of the linkers in Google Web Toolkit contains a dynamically created iframe. They use javascript:'' as a temporary placeholder for the src attribute. The reason, according to the source comments, is "Prevents mixed mode security in IE6/7.".
Source.
As part of the about URI scheme standard, about:blank is probably the best option as it has very good browser support.
about:blank Returns a blank HTML document with the media type
text/html and character encoding UTF-8. This is widely used to load
blank pages into browsing contexts, such as iframes within HTML, which
may then be modified by scripts.
You can see further here
Oh, what frustration. The supposedly XHTML-complient CKEditor can't actually be served as application/xhtml+xml, so I have to switch to text/html. Suddenly my pages start breaking all over the place.
I serve a well-formed HTML5 document that uses namespaces---in particular, the "example" namespace. Some elements have the "example:fooBar" attribute, but I see now that Chrome when reading a document as text/html converts all attributes to lowercase---grrr!!!
So I change the attribute to "example:foobar" and try element.getAttributeNS("http://example.com/ns", "foobar"). No luck. So I investigate the DOM, and Chrome 17 shows a "localName" of example:foobar. Ack! How hard can namespaces be? Shouldn't Chrome be using a local name of foobar? That is, after all, the local name; example is the namespace prefix!
Is this is Chrome bug? Do all browsers do screwy things like this?
We're using the customer's default browser to display locally generated HTML files in a preview mode. The files are between 0.5M and 2.5M in size. These files do not progressively render in any of the top 5 Windows browsers (Chrome, FireFox, IE, Opera, and Safari). In other words, when we try to load these files, the browser window displays a blank white page until the page is fully loaded.
The HTML files we generate have no tables or script and have all CSS references in the head section of the HTML file. Our pages include about 10 unique 16x16 png images (with image height and width explicitly included on each img tag) that are referenced several hundred times. Our output validates 100% compliant with XHTML 1.0 Strict using the W3C validation service.
Any tips on how we can enable progressive rendering of LOCALLY loaded HTML files or is progressive rendering a feature that is disabled for locally loaded files?
As an alternative, I'm looking for any tips that would allow us to display a GIF busy indicator graphic while the rest of the file loads and is rendered. We tried doing this by placing a GIF image at the top of our HTML file (immediately following the open body tag) followed by a div with display:none styling that included the full content of the HTML we want rendered. Unfortunately, the GIF file does not display until the full HTML file is loaded.
Thank you,
Malcolm
I can suggest that you confirm that the content is being interpreted properly by the browser. Despite the W3C checks, things could still be handled in 'quirks mode' .. In my experience, 'xhtml-transitional' has proved to be the most likely to provide cross-browser zen. Also, confirm that major tags like 'div' and 'p' are being closed quickly. It's hard for the browser to know what to do if the whole page is always in one layer of 'div' ..
Good luck!
Tim