I've been showing a website to a customer who insists on using IE and found out, to my surprise, that IE7 does not autodiscover the Atom newsfeed.
The feed is linked to within the HEAD element of a valid HTML 4.01 Strict page with <link rel="alternate" type="application/atom+xml" href="atom.xml" title="Atom 1.0">, the link is pointing to the correct URL, the linked feed is a valid Atom 1.0 XML file served as application/atom+xml and contains the correct <link rel="self">.
Firefox, Opera, Safari and IE8 beta 2 all do correctly find out the feed and lighten up the relevant address bar button - it's just IE7 that stays greyed out. Same IE7 had no trouble in discovering newsfeeds elsewhere and to pass the HTML part of DiveIntoMark's autodiscovery test suite with flying colors.
Changing the HREF to a fully qualified URL made no difference, nor did changing the TYPE to a RSS 2.0 MIME or removing the TITLE attribute.
The website address is http://www.monteanalogo.net/.
Any hint about what's wrong here?
I copied your source to my local machine, and IE7's auto-discovery kicked in fine once I changed the href to a full url, rather than a relative one:
<link rel="alternate" type="application/atom+xml"
href="http://www.monteanalogo.net/atom.xml" title="Atom 1.0">
Needing a full URL seems to be an IE glitch, as the RFC on atom auto-discovery states that:
The value MAY be a relative URI, and if so, clients MUST resolve it to a full URI ... using the document's base URI
Microsoft's own publisher's guide also lists the full url in the href tag, but makes no mention of it being compulsory:
Here is an example of Atom Autodiscovery:
<head>
<link rel="alternate" type="application/atom+xml"
title="your feed title here"
href= "http://www.company.com/feedurl.xml">
</head>
Related
In my web application I have some files with extension ".css.map".
Looking on the internet I see that, as content type, I should put "application/json" so my include directive looks like this:
<link rel="stylesheet" type="application/json" href="resources/css/angular-chart.css.map"/>
Nevertheless, this does not prevent my browser to display the warning:
Resource interpreted as Stylesheet but transferred with MIME type text/html
This warning seems to be the cause of a blank page displayed on internet explorer browser (chrome and firefox seem to be fine). After reloading the page IE does display it right, but I'd like to solve this problem at its root, by getting rid of that warning.
I think the problem is in the
rel="stylesheet"
so, what should I put there?
You shouldn't link to map files at all. Tools that use them will use a X-SourceMap header or infer the URL by adding .map to the URL of the actual stylesheet or JavaScript program.
Try explicitly specifying the type as json in your link tag, like so:
<link rel="stylesheet" type="application/json" href="blah">
I have a tiny HTML file with a favicon and a redirect redirect to differentiate a number of URLs which have no custom favicons, on different computers, which I would like to bookmark on Chrome. Since the absolute initial path differs on all computers, I was hoping to use %UserProfile%\Desktop\ as the path to my file, which would work on all computers, but I don't know whether and how I can enter this kind of path in a URL in Chrome?
Running either Windows 7 or Windows 8 on those computers.
As far as I'm aware, you cannot bookmark dynamic URLs. What you can do is compressing your HTML page into a data URL which can be used as a bookmark:
data:text/html;utf-8,<!DOCTYPE html><head><title>Title</title><link rel="shortcut icon" href="http://example.com/favicon.ico"></head><body><script>setTimeout(function(){ window.location.replace('http://example.com/') },1);</script></body>
This is just the following HTML without new lines and data:text/html;utf-8, at the beginning:
<!DOCTYPE html>
<head>
<!-- Page title, can be omitted -->
<title>Title</title>
<!-- Link to the favicon in href -->
<link rel="shortcut icon" href="http://example.com/favicon.ico">
</head>
<body>
<script>
setTimeout(function(){
// URL to redirect to in quotes
window.location.replace('http://example.com/')
},1);
</script>
</body>
I just tested this and it seems to display the correct favicon if you provide the path to it. To add it to your bookmarks, right-click the bookmark bar and select Add page... then enter the data URL for the location.
If you need to use local favicons, then you can convert your .ico to a data URL as well. Here's one tool of many that I found through Google: http://dopiaza.org/tools/datauri/
A simple search for ico to data url should give you relevant results.
You'll get a nice long URL that you can use in place of http://example.com/favicon.ico and it'll still be contained within the bookmark.
I am a bit confused about the behavior of <link rel="alternate" ...> in browsers and i am looking for some clarification. Let's use the following code for illustration:
<!DOCTYPE html>
<html lang="en">
<head>
<link rel="stylesheet" href="a.css" type="text/css"
title="Main Stylesheet">
<link rel="alternate stylesheet" href="b.css" type="text/css"
title="Alternative Stylesheet">
<link rel="alternate" href="fr.pdf" hreflang="fr" type="application/pdf"
title="Alternative document in French">
</head>
<body>
</body>
</html>
When this code runs in a modern browser (e.g. Firefox v27.01), the browser parses the above HTML document and then downloads the stylesheets, a.css and b.css. The former is used to apply the style to the document. However, b.css is available through the 'View > Page Style' menu of the said browser. So, clearly the parser in Firefox is able to recognize the "alternative" stylesheet and in this case decided to download it.
One can read at W3C > HTML5 > 4.8.4.1 that the outcome of parsing those <link>s are basically hyperlinks referencing the respective document. In the case of stylesheet, the browser is smart enough to download it as well. But, for the other alternate document (fr.pdf) in our example, it looks like Firefox does not download it and if it links it, it is not visible anywhere. I tested in Chrome (v.33.0.1750.117), Opera (v.19.0.1326.63), IE (v.10.0.9200.16798) and could observe same thing (i.e. no visible artifact that the fr.pdf has been linked). So, as all those modern browsers behave like this, it looks like I have misunderstood the meaning of "alternate" relationships:) Would someone have an explanation for me of how they are intended to be used? My belief is that in a RESTful manner, user-agents should be able to (hyper)link all the <link>s in order to navigate that web.
Thanks in advance.
The <link> element does indeed identify external documents that are related to the current document. And the rel attribute specifies the nature of that relationship. In the specific case of rel="alternate stylesheet" (some) browsers can do something specific with the link. In particular, Firefox and Opera give the user a chance to select this "alternate" stylesheet from the application's menu. See, e.g., the screen shot
from this article.
In order to apply that style sheet, the browser needs to download it.
In the more general case of rel="alternate" (not a stylesheet), then the browser won't know anything useful to do with the related link. Therefore, as far as the browser is concerned, there's no need to download it.
Here is my problem, I have 2 link rel tags in my html index header. One tag is for my stylesheet the other is a shortcut icon link rel to use a icon in my browser tab (fyi using FF19).
<link rel="shortcut icon" href="tophat2.ico"/>
<link rel="stylesheet" type="text/css" href="style.css"/>
Each rel link works fine on its own. when I have them one after another though the one on the bottom (being parsed second) is the only one that is displayed however. They appear to be overriding eachother so I conclude I cannot have both a icon shortcut and a stylesheet each as a separate rel link but that is the only method I can find via Google so I am stuck.
See http://mathiasbynens.be/notes/rel-shortcut-icon. It says:
Most sites use the following HTML to specify a favicon:
<link rel="shortcut icon" href="/favicon.ico">
Looks okay, right? Guess what — it isn’t!
Today, I learned that shortcut is not a valid link relation. Indeed,
it doesn’t show up in section 4.12.5 of the HTML5 specification on
‘link types’. It is, in fact, proprietary to Internet Explorer.
Without IE, rel="icon" would suffice to specify a favicon.
Since you are using Firefox, that would explain why it isn't working. Try just this:
<link rel="icon" href="tophat2.ico"/>
But be aware that this may not work in IE 8 or below. Later on in that same post it says:
If the shortcut value is omitted from the rel attribute, Internet
Explorer ignores the declaration entirely, searches for a file called
favicon.ico in the site root, and uses that instead. In fact, almost
every browser does that when there’s no link rel="icon" specified.
Using rel="icon shortcut" won’t work in IE either, since it doesn’t
treat the rel attribute as a space-separated list.
Just make sure to always put the favicon in the root directory of your
site, and name it favicon.ico
OK I FIXED IT!!! I have no idea why the ** this worked but it did. I copied my rel link=icon
tag and pasted it as a duplicate above the 2 waring rel links. The duplicate being parsed first appears broken which doesn't matter but now the 2 below work so I have a working stylesheet and icon. Thanks for trying to help everybody. This one shall probably remain a mystery.
Is there some directive I could use in my HTML to tell the browser not to ask for the favicon?
Add this line.
<link rel="icon" href="data:,">
This assigns an empty data URL to the favicon’s element which specifies the location of the external resource. This trick stops the user’s browser from sending an automatic HTTP request for the favicon.
This has some more details
No, I don't think there is. From Wikipedia:
Most web browsers do not require any HTML to retrieve a favicon that conforms to the de facto file name and type (favicon.ico) located in the web site's root. If no favicon link is detected upon HTML page load completion and no previous site visits are recorded in the browser's history, a favicon.ico is requested automatically.[8]
The only thing you could do is explicitly point the browser to a different location (that for example could return a 204 no content)
<link rel="shortcut icon" href="http://www.example.com/my_empty_resource" />
You could try pointing the <link> at a data URL. As commented below, IE will not like this, though.
Example (from 11011.net):
<link rel="icon" type="image/gif" href="data:image/gif;base64,R0lGODlhEAAQAIAAAAAAAAAAACH5BAkAAAEALAAAAAAQABAAAAIgjI+py+0PEQiT1lkNpppnz4HfdoEH2W1nCJRfBMfyfBQAOw==" />
Edited to reflect Pekka's concern regarding IE.
If you are not using HTML and its auto generated by Flask or some frameworks you can always add a dummy route in the app to just return dummy text to fix this issue.
Eg for Python Flask Application.
#app.route('/favicon.ico')
def favicon():
return 'dummy', 200