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?
Related
I am looking for a site for somebody, and fixing errors as I find them.
There is no Favicon.. that is ok, I can fix that.
My question is, do browsers (or certain browsers, Chrome in this case) request favicon.ico as soon as they load a site.. or maybe on check that there is no alternative icon path mentioned in the source.. irrespective of whether "favicon.ico" is actually mentioned in the page source?
That was the original behaviour, yes. /favicon.ico was an implicitly present file which (some) browsers would check for. Only later did that actually morph into a proper standard with <meta> tags, arbitrary file names and image formats other than .ico.
The download attribute on an anchor element should set the name of the downloaded resource to the value of the download attribute. In the current version of chrome, the download attribute doesn't, however, change the name. Is this not anymore supported? Anything changed?
Here is a post explaining the functioning of the download attrib: http://updates.html5rocks.com/2011/08/Downloading-resources-in-HTML5-a-download
If it worked as expected, the name of the downloaded resource would be MyGoogleLogo. It is, however, the last element (file) of the href.
It seems that the download attribute works only when the resource is retrieved via HTTP from the same server as the linking document. So if you have
<a href=foo.txt download=something.txt>xxx</a>
on a web page, it works, but if it is in a local file, it does not; neither does it work if a web page refers to a resource on another server. By “works” I mean setting the filename; even when it does not “work” in this sense on Chrome (or Firefox), it causes a pure download instead of navigation to the resource, i.e. the resource is downloaded as a file but not opened in the browser.
According to MDN info, “In Firefox 20 this attribute is only honored for links to resources with the same-origin.” This seems to apply to current Firefox, too, in the stronger sense that the download attribute is completely ignored for cross-origin requests.
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.
Is anyone aware of whether it is problematic to use protocol relative URLs for an image source to prevent mixed content security warnings.
For example linking an image like:
<img src="//domain.com/img.jpg" />
instead of:
<img src="http://domain.com/img.jpg" />
or
<img src="https//domain.com/img.jpg" />
In my testing i've not seen anything to suggest this is wrong but i'm not sure if it has edge cases where it will create problems.
EDIT i've seen it throw errors when using PHP's getimagesize function.
Found an interesting gotcha for the use of protocol relative URLs:
You have to be careful to only use
this syntax in pages destined for
browsers. If you put it in an email,
there will be no base page URL to use
in resolving the relative URL. In
Outlook at least, this URL will be
interpreted as a Windows network file,
not what you intended.
from here
Essentially though there are no valid reasons why this shouldn't work as long as the request is made by a browser and not an external email client.
more info from here:
A relative URL without a scheme (http:
or https:) is valid, per RTF 3986:
Section 4.2. If a client chokes on it,
then it's the client's fault because
they're not complying with the URI
syntax specified in the RFC.
Your example is valid and should work.
I've used that relative URL method
myself on heavily trafficked sites and
have had zero complaints. Also, we
test our sites in Firefox, Safari,
IE6, IE7 and Opera. These browsers all
understand that URL format
IE 7 and IE 8 will download stylesheets twice if you're using a protocol-relative URL. That won't affect you if you only use it "for an image source", but just in case.
The following should be considered when using Protocol-Relative URLs:
1) All modern browsers support this feature.
2) We have to be sure that the requested resource is accessible over both HTTP and HTTPS. If HTTP redirects to HTTPS it is fine, but here the load time will take a little longer than if the request was made directly to the HTTPS.
3) Internet Explorer 6 does not support this feature.
4) Internet Explorer 7 and 8 support the feature, but they will download a stylesheet twice if protocol-relative URLs are used for the css files.
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?