I am using Bootstrap 3.
When I add <meta http-equiv="X-UA-Compatible" content="IE=edge">, the site shows error in the W3C validator.
From my answer to a similar question:
In (X)HTML5, you may only use http-equiv values that are
defined in the HTML5 spec, or
registered in the WHATWG wiki page "PragmaExtensions".
The value X-UA-Compatible is not defined in the spec, but it’s proposed in the wiki. "Proposed" means:
The following proposed extensions do not yet conform to all the registration requirements in the HTML spec and are therefore not yet allowed in valid documents.
So currently it’s not valid to use this value in (X)HTML5.
You can do:
<!--[if IE]>
<meta http-equiv="X-UA-Compatible" content="IE=edge" />
<![endif]-->
The validator is extremely pedantic. It's best to just ignore this particular validation warning, given its significant pragmatic benefit and complete lack of downsides. It's not an error of any kind in any of the major browsers.
Related
I am trying to work out why my referrer from my server always seems to be blank. I have knocked together the following to test it:
<html>
<head>
<meta http-equiv="Refresh" content="0; url='https://www.whatismyreferer.com/'" />
<meta name="referrer" content="origin" />
</head>
<body>
</body>
</html>
When I go to this page I get this:
Is this something that is being set at a server level in Apache? I have a case where I need to pass the referrer so finding out what is controlling this would be good.
The referrer header (with the famous referer spelling) is sent by the browser. If the browser decides not to send it (e.g. for privacy reasons) it just won't do. You should never rely on the header to be there. Even if you find configurations that currently work: The request is valid with or without this header. And browsers might change their opinion any time (they did: The header used to be omnipresent, not it's less present)
don't know if this is an inappropriate question, it would be great if someone could clear this up for me.
I have one free domain included in my current Internet Contract. Since my Provider does not offer free webspace, i got it somewhere else.
I set the Domain to be a Frame-Redirection to the Webspace, so that I can use the nice and short Url, but so far... this breaks the viewport.
<meta name="viewport" content="width=device-width, initial-scale=1">
Now I wonder if this is just how it works - or a matter of settings?
Thanks
I have a very simple XPage with a table and some input fields.
The application uses the bootstrapv3.0.0 theme and the OpenNtf bootstrap4Xpages plugin released on 2014-01-28.
I think I'm using correct markup according to bootstrap-3 documentation.
The page renders just fine in Chrome, but it's a mess in IE 11.
In IE the table seems to get cut at a fixed width of approx. 100px and the characteristic blue border on selected “bootstrapped” input fields does not show up as it should
Buttons styled with btn-warning display as expected, also in IE. This tells me that at least some of the styles is applied correctly in IE as well
Anyone else who have run into this problem?
Any tips on a possible solution (dropping support for IE is not an option)?
Are you running IE11 in compatibility mode? Try turning off compatibility mode and see if the site loads.
By default intranet sites load in compatibility mode, which I think really means your web site is going to look awful if it was made in the last 15 years mode.
Per Henrik Lausten has an xSnippet that can display a warning to your users if they are running like so. http://openntf.org/XSnippets.nsf/snippet.xsp?id=display-warning-message-if-internet-explorer-uses-compatibility-view-mode
Add x-ua-compatible header in your html header to disable IE so-called compatibility mode:
<!DOCTYPE html>
<html>
<head>
<meta http-equiv="X-UA-Compatible" content="IE=edge">
More info in this question:
What does <meta http-equiv="X-UA-Compatible" content="IE=edge"> do?
I was having formatting issues and got fixed by adding
<meta charset="utf-8">
<meta http-equiv="X-UA-Compatible" content="IE=edge">
<meta name="viewport" content="width=device-width, initial-scale=1">
I recommed you use these lines before </head>
<!-- HTML5 Shim and Respond.js IE8 support of HTML5 elements and media queries -->
<!-- WARNING: Respond.js doesn't work if you view the page via file:// -->
<!--[if lt IE 9]>
<script src="https://oss.maxcdn.com/libs/html5shiv/3.7.0/html5shiv.js"></script>
<script src="https://oss.maxcdn.com/libs/respond.js/1.4.2/respond.min.js"></script>
<![endif]-->
I know they are only for IE 8 IE 9 but still :)
I never encounter any problem with IE 11 can you provide any link if possible
I've placed the following Header in my vhost config:
Header set X-Robots-Tag "noindex, nofollow"
The goal here is to just disable search engines from indexing my testing environment. The site is Wordpress and there is a plugin installed to manage per-page the meta robots settings. For example:
<meta name="robots" content="index, follow" />
So my question is, which directive will take precedence over the other since both are being set on every page?
I am not sure if a definitive answer can be given to the question, as the behavior may be implementation-dependent (on the robot side).
However, I think there is reasonable evidence that X-Robots-Tag will take precedence over <meta name="robots" .... See :
One significant difference between the X-Robots-Tag and the robots meta directive is:
X-Robots-Tag is part of the HTTP protocol header.
<meta name="robots" ... is part of the HTML document header.
Therefore the the X-Robots-Tag belongs to HTTP protocol layer, while <meta name="robots" ... belongs to the HTML protocol layer.
As they belong to a different protocol layer, they will not be parsed simultaneously by the (robot) client getting the page: The HTTP layer will be parsed first, and the HTML in a later step.
(Also, it should be noted that X-Robots-Tag and <meta name="robots" ... are not suppported by all robots. Google and Yahoo/Bing suppport both, but according to this some support only <meta name="robots" ..., others support neither.)
Summary :
if supported by the robot, X-Robots-Tag will be processed first ; restrictions (noindex, nofollow) apply (and <meta name="robots" ... is ignored).
else, <meta name="robots" ... directive applies.
Just an update to Dan's experience, I also have both the
Header set X-Robots-Tag "noindex, nofollow"
and
<meta name="robots" content="index, follow" />
on my one of my Wordpress sites, and a check in Google Search Console confirmed that the noindex in X-Robots-Tag is taking precedence as the pages have been crawled and but aren't indexed. So the logic in the correct answer is indeed, correct.
In my recent experience, when Google sees mixed-messages it prefers positive action by default - ie - it favours indexing - meanwhile will flag the issue as a critical error/warning in your webmaster tools console if you have one.
see your site's status in google here: https://www.google.com/webmasters/
see you site's status in bing here: http://www.bing.com/toolbox/webmaster (note that yahoo search is now powered by bing)
Google takes this positive-by-default action because lots of site owners unwittingly have a dodgy cms semi-blocking robots and we know how google loves to accumulate as much data as it can - any excuse!
if the technical settings are erroneous they're liable to be totally disregarded, and we know how search engines index and follow by default when no settings are specified.
As I understand it you can tell the IE8 (and I assume later versions) how to best render your page.
This is useful because the page may have been designed for IE7, quirks mode or to target IE8 standards mode. As I have it, the default behaviour for IE8 when it encounters a page is to render in IE8 standards mode (not sure how it interprets the DOCTYPE though). With this default the user could change the rendering mode by clicking on the "Compatibility View" button next to the refresh button.
This is nice to give the user some control, but bad when you know your site only renders well with IE7 or whatever. In that case you don't want to enable the user to make the wrong choice and that's where the ability for a website to tell the >= IE8 browser how to render the page is very useful.
You simply have to provide the X-UA-Compatible meta tag the within the head tag. There are loads of references on the web how to do this and what values can be used. Remember to make it the first one.
<html xmlns="http://www.w3.org/1999/xhtml">
<head id="Head1" runat="server">
<meta http-equiv="X-UA-Compatible" content="IE=7" />
OK, so it's nothing new so far - however it just doesn't work for my ASP.NET project? I've tried it on a couple of other projects I have and the same problem.
Is there perhaps a scenario where because I'm using developer tools like Visual Studio, etc. that IE has been configured to always show the "Compatibility View" button for debugging purposes? Grasping at straws here I know.
I found out why this is happening.
It seems that ASP.NET's theming is interfering. When looking at the rendred output there is a dynamically inserted tag for the stylesheet (one for each) from the theme.
The ASP.NET theming engine inserts these items above the X-UA-Compatible meta tag, thus breaking IE's expectation of having it as the first tag in the head element.
So an ASP.NET site that has theming and the following in the source:
<html xmlns="http://www.w3.org/1999/xhtml">
<head id="Head1" runat="server">
<meta http-equiv="X-UA-Compatible" content="IE=7" />
will get rendered out as follows:
<html xmlns="http://www.w3.org/1999/xhtml">
<head id="ctl00_Head1">
<link href="App_Themes/White/Default.css" type="text/css" rel="stylesheet" />
<meta http-equiv="X-UA-Compatible" content="IE=7" />
This seems to be a bit of a bug. I'll create a MS Connect issue for it.
There's an interesting workaround for this here . I'll include the gist to make it easier:
The "styleSheetTheme" setting always places its CSS file in the header
at the top before anything else. To move the "X-UA-Compatible" before
it, you would have to do the following:
Make the meta tag accessible from the server code by giving it an ID and add the "runat" attribute:
...
Add the following pre-render event handler to your page (or master page):
protected void Page_PreRender(object sender, EventArgs e)
{
Control MyFirstCtrl = Page.Header.FindControl("FirstCtrlID");
Page.Header.Controls.Remove(MyFirstCtrl);
Page.Header.Controls.AddAt(0, MyFirstCtrl);
}
You can move things around in the header this way for anything that
you explicitly define in there.