I have a HTML fragment file which was created by extracting the Windows CF_HTML clipboard data after having copied a web page (http://www.w3schools.com/) in MSIE to the clipboard. The HTML fragment source is located here:
http://pastebin.com/suJDw9tW
Now when I open this file in Chrome, it displays the web page perfectly with all images.
However, when I try to open it in MSIE, it first seems to crash MSIE or make it hang for about 5-10 seconds, then the page is displayed very badly and WITHOUT IMAGES although there is a BASE tag inside the HTML.
How do I need to change this HTML to make it display correctly in MSIE WITH IMAGES?
Document type declaration should be on the first line without any preceeding characters.
This probably provides more backwards compatibility with older versions of IE. Those are just quite widely used even today, unlike older versions of the other browsers.
Related
I have a HTML file that renders correctly in Chrome 66 when the file extension is ".html", so I know that the code if fine.
However, the process that generates the code defaults to an extension of ".DAT" and there isn't a way to change it. Also, I tried associating ".DAT" with Chrome, but the page still shows code instead of rendering.
When I was using an older version of Chrome (50 something) it was rendering the pages properly. How can I get ".DAT" files to render correctly in my newer version?
I have the same behaviour today with one of our users.
Some DAT files with html coding are displayed as loose html code instead of being rendered.
If I open it in IE it works fine.
I'm currently using a solution which converts a pdf file to a data URI. The data URI is then set as an iframe's source and displays the pdf on almost every major browser, I have learned that IE 11 does not like this though. After reading up on it, i realize that iframes don't support data URI's as the source (nor do any elements other than an image URI) and that I can't set a source for an element so I'm unsure how I could achieve the same with Internet Explorer.
I've tried using an embed (learned that it doesn't like data URIs either), an iFrame, initiating a download in a new tab of the file itself (to mimick viewing a it in the browser - no avail) and I'm running out of ideas but unfortunately a lot of people still use Internet Explorer so I'd like to make it compatible. Is there any way to recreate this behavior in Internet Explorer like other browsers do?
Thanks in advance :)
I ended up giving up on this for lack of time to research/test. The final solution was just as well I suppose. I ended up writing the PDF to subdirectory in the website and then setting the source ofthe iframe to the download method of the file. Tad slower than my original implementation but it works for legacy purposes. When will IE die!
When I try to load a PDF Data URI into an iframe (eg, src="data:application/pdf;base64,...") in FireFox (18.0.2 [current release], OSX) it instead opens a download window.
For an example, check out the website JSPDF.com
The same site works fine in Aurora (20.0a2)
Is this a known issue with Firefox? Is it not conforming to the spec...?
Aurora has a built-in PDF renderer that can render PDFs inline.
Current release as of yesterday does not have that; it first appears in Firefox 19, which is about to be released.
A browser without a PDF plug-in or built-in PDF renderer will simply offer to download or open in a helper app a PDF that's loaded in a window as you're doing, which is exactly what you see.
As far as the spec goes, both behaviors are compliant. Nothing says a browser needs to support inline rendering of PDF.
You need to modify the options :
To :
I had a very similar problem with Firefox, iframes and data URIs. I resolved it by checking that there was no spaces in the data type definition. Mine was text/html, so instead of writing this:
src="data: text/html, ..."
it had to go like this:
src="data:text/html,..."
I conclude that firefox didn't understand the content type with spaces, thus considering it was a downloadable file.
This might be caused when there is no adobe reader installed. I'm not sure though. As I can't test it here as I don't have a Mac with Firefox running.
There is a standard from Adobe that in theory specifies opening PDF documents from a link clicked in a browser in a way to open specific sections (AKA "anchor", "named reference") of PDF document. This functionality should be of great help if one would like to refer to a specific portion of large PDF (such as some standard or specification).
However, from what I see now, support for this standard is close to non-existent.
For example, these links should open Scala Reference PDF at section 3.2.6, "Annotated Types":
http://www.scala-lang.org/docu/files/ScalaReference.pdf#subsection.3.2.6
http://www.scala-lang.org/docu/files/ScalaReference.pdf#nameddest=subsection.3.2.6
http://www.scala-lang.org/docu/files/ScalaReference.pdf#page=23
(Techincally, variant #3 should open page #23, which is essentially the same destination)
Is there a working way (may be with a couple of shims, proprietary wrappers or whatever else) to make this work on majority of systems? What is the usage share of Adobe Reader plugin, should I care about other systems?
If it's not possible, at least I'd like to find a working solution for every platform (i.e. Windows, Linux, Mac) that I could recommend to my site's users if they want to be able to use named destination links.
From what I've tested:
Windows, MSIE/Firefox/Chrome, Adobe Acrobat Reader plugin - all variants work with version 9+, but:
MSIE has a weird caching issue (i.e. anchor does not work until document was cached)
Older versions do not work
It has issues with link format: generally, it should be regular absolute link to a real web server, starting with "http://". Relative links, samba-style links (\\HOST\dir\file.pdf#something), anything else besides "http" (or probably, "https") scheme won't work
Windows, any browsers set up to run Adobe Acrobat Reader as a separate process - does not work
Windows, any browsers, FoxIt Reader - does not work
Windows, any browsers, CutePDF - does not work
Linux/Konqueror/Okular - only variant #1 works
Linux, any other browsers set up to run Okular or any other PDF viewer as external process - does not work (as browser does not pass any "#arguments" in a command line)
Any OS, Firefox 15+ PDF.js internal PDF viewer - does not work
I'd appreciate if you'd try it to test in various different combinations.
What seems to work in general is variant #4 but using the number of the page as in actual division into pages in the PDF document, in this case
http://www.scala-lang.org/docu/files/ScalaReference.pdf#page=31
The PDF document has page numbers that start from the content proper, after the table of content, but that numbering differs from the one to be used in #page=...
I have a webpage like e.g. www.example.com/NYSE/rates. If the user decides to save the html she sees on her local disk, I want to preset the filename she gets, when she clicks "Save as", with NYSE_rates_09_12_2011.html. (Which obviously will be different tomorrow or for a different stock exchange.) Now I always get rates.html as default.
How can I do that?
It appears that in at least the latest version of the most popular web browsers on Windows (Internet Explorer, Firefox, Chrome, Safari and Opera) the default filename filled in when saving a webpage is taken from the page's <title> tag, so simply making sure the date appears in there should put you right.
As I found out, this is a known problem with Firefox, that stems from the days of Netscape Navigator. And there is an add-on "File Title" that fixes it.