Dolphin Browser and the Default Android Browser are reading the <noscript> section in the head of my page even though javascript is turned on in those browsers. This causes the content of those pages not to be rendered.
In the head I link to a a css stylesheet that sets display to none for anything inside a div on page when javascript is turned off in the browser. It does this by residing inside a nonscript element, so the stylesheet is only read if there is no javascript.
This works for all desktop/laptop browsers I tested (not tested on mac which I don't have access to). It works on Android with Firefox and Opera. I have cyanongenmod 7 only so no Google Chrome for me.
However when it comes to Dolphin and the default Android browsers, they read the css stylesheet that resides in the noscript section and pretty much the whole page/site is not rendered in these browsers.
I have proven that this is what is happening by deleting the stylesheet link from the head section and the page renders correctly in those browsers.
Is there some way to get these browsers to respect the noscript tags in the head section?
UPDATE: This is using HTML5 - noscript in the head is allowed: http://www.w3.org/TR/html5/the-noscript-element.html#the-noscript-element
<!DOCTYPE html>
<html>
<head>
<noscript>
<link href="${facesContext.externalContext.requestContextPath}/css/no_javascript.css" rel="stylesheet" type="text/css" />
<!-- this link is being read even if javascript in enabled in dolphin -->
</noscript>
</head>
<body>
<noscript>
stuff in this noscript element works correctly
</noscript>
<div class="no_javascript_disapear">
page full of stuff not being rendered because
dolphin browser is not respecting the noscript
tags in the head.
</div>
</body>
</html>
// css in the noscript tag:
.no_javascript_disapear {display:none;}
Maybe you can use javascript to remove that stylesheet?
Read this question for how to Access Contents of <noscript> with Javascript
Otherwise, you can add a title to your no-js stylesheet:
<link title="noJsStylesheet" href="....css" rel="stylesheet" type="text/css" />
And use this function to remove it:
for(i=0; (a = document.getElementsByTagName("link")[i]); i++) {
if(a.getAttribute("title") == 'noJsStylesheet') a.disabled = true;
}
But i'm really not sure if it'll work on this specific Dolphin version.
According to HTML specifications issued as W3C recommendations, the noscript element is allowed inside body only. Browsers may allow it in the head too, but you can’t count on it. Just saying that you use HTML5 does not change this a bit; browsers do what they do, possibly implementing parts of HTML5 drafts at times.
The HTML5 draft generally recommends against using noscript at all: “The noscript element is a blunt instrument. Sometimes, scripts might be enabled, but for some reason the page's script might fail. For this reason, it's generally better to avoid using noscript, and to instead design the script to change the page from being a scriptless page to a scripted page on the fly” (followed by an example of this).
So the best approach would be progressive enhancements: Design the page first so that it works without scripting. Then, add scripting in a non-disruptive way. This could involve adding some CSS rules via scripting (which would be more natural than removing some).
But if you need a quick fix, you might consider adding, right after the link element that is now inside noscript, a script element that contains code for immediately removing that element from the document tree.
By the way, my good old Android 2.3.5 default browser seems to honor noscript inside head.
Related
Some of the AMP samples I have found seem to include the amp-custom tag before the amp-boilerplate.
<style amp-custom>
h1 {
color: red;
}
</style>
<style amp-boilerplate>.....</style>
While other examples show the amp-boilerplate before the amp-custom.
<style amp-boilerplate>
.....
</style>
<style amp-custom>
h1 {
color: red;
}
</style>
If I want my page to be compliant with AMP standards, should I place amp-custom style tag before or after my amp-boilerplate style tag.
For AMP validity, the order doesn't matter. However, the order of tags inside the header can affect page load performance. The recommended order for head tags is:
meta charset, then remaining meta tags.
AMP runtime v0.js <script> tag (this should start downloading as soon as possible as it's render blocking).
<script> tags for other render delaying extensions (amp-experiment, amp-dynamic-css-classes)
<script> tags for remaining extensions (amp-bind, ...)
<link> tag for favicon
<style amp-custom>
any other tags allowed in <head>
amp boilerplate, first style amp-boilerplate, then noscript. (putting the boilerplate lasts avoids custom styles accidentally overriding the boilerplate css rules)
Please note: this is only relevant for AMPs not served via the Google AMP Cache as the cache re-orders the head following these rules anyway.
I don't believe it matters which order you put them in. If you have concerns you can always run your code through the AMP validator tool or throw #development=1 after your URL and check the console in your browser dev tools.
Note: after adding #development=1 you may have to refresh the page twice with dev tools open to get it to show either a success or fail message in the console.
I just tried putting amp-custom before amp-boilerplate in the AMP validator tool as well as amp-boilerplate before amp-custom and both came back as AMP valid.
I know for our company website we put it after amp-custom due to what it defines for us so that it takes precedence over any other styling.
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.
TL;DR
I've read through many questions on Stack Overflow on this issue and I've tried to follow the given advice. Still, my CSS stylesheet will not work in Chrome/Safari but it can work in Internet Explorer.
The only odd thing that I can see about my scenario is my server is returning all files as of type application/octet-stream. I cannot change this aspect of the server. Is there something I can do to interpret my CSS file as a stylesheet in Chrome/Safari and IE?
I have an embedded web server project that I am working on. I have very limited control of the server software and the ability to make page-level settings. All I can do is create static HTML, CSS, and image files that are compiled into the server application.
As such, all files that are returned from the embedded server are declared as application/octet-stream in the HTTP header. This produces warnings in Chrome but no errors.
Initially, I had a problem loading this style sheet in Chrome/Safari but it would work in IE. After reading through a couple questions on Stack Overflow, I found that I needed to change my stylesheet declaration from:
<link rel="stylesheet" href="/styles/index.css">
to:
<link rel="stylesheet" type="text/css" href="/styles/index.css">
When I made this change Chrome & Safari still failed to process the CSS file but IE also started to ignore the stylesheet.
Oddly, if I do not declare a DOCTYPE on my HTML document I can get linked stylesheets to work in all of my browsers. This is, however, not a desirable solution.
My guess is this issue has something to do with the HTTP header declaration and that it doesn't match the type declared in the link element.
What can I do to get this stylesheet to work in Chrome, Safari, and IE while following good web development codes-of-practice (i.e. using doctypes on my HTML files and not embedding the style code in the HTML headers?)
For clarity sake, the relevant CSS/HTML code is shown below.
index.css
html {height:100%}
body {margin:0;min-height:100%;position:relative}
iframe {width:100%;height:100%;border:none}
.hdr {min-width:765px;overflow:auto}
.logo1 {float:left;margin:4px}
.logo2 {float:right;margin:4px}
.menu {position:absolute;top:70px;left:0px;bottom:0px;width:175px}
.content {position:absolute;top:70px;left:175px;bottom:0px;right:0px;}
index.htm
<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=windows-1252">
<link rel="stylesheet" href="/styles/index.css"> <!-- Removed the type declaration so that this would at least work in IE9 //-->
</head>
<body lang="en-us">
<div class="hdr"><img class="logo1" src="/images/logo1.png" alt="Logo #1"><img class="logo2" src="/images/logo2.png" alt="Logo #2"></div>
<div class="menu"><iframe name="menu" src="/menu.shtm"></iframe></div>
<div class="content"><iframe name="main" src="/home.htm"></iframe></div>
</body>
FYI, this is a new project that is being developed from an existing one. The original project did not declare a DOCTYPE on the HTML files. Therefore, all page data was loaded and executed in the browser in quirks mode. Furthermore, the index.htm originally consisted of multiple frames within a frameset.
I am trying to update this application, using correct, and up to date methods for developing web pages. I can make this application work, but I feel that this would be at a sacrifice of future-browser compatibility if I have to rely on browser quirks mode and framesets.
I have tried to close the link tag but that doesn't help. Technically, this shouldn't be an issue since this document is declared as an HTML5 document, rather than XHTML.
It's certainly due to the application/octet-stream content type. I can re-create the issue on my end. Soon as the content type is set to text/css your HTML/CSS load fine.
As a workaround you can use <style> tags for you CSS if you can't get the server to send the correct content type.
I hate to have to answer my own question this way but the problem was most certainly with the fact that the server was returning a content type of application/octet-stream within the HTTP header.
After discussing the issue with management we had to update the code associated with the HTTP processor. This is code that is part of a third-party RTOS and we have been extremely hesitant to making any changes to this code.
However, in this case the need has out-weighed that desire. I've integrated the necessary changes to fix the HTTP header to return a content type of "text/css" for cascading style sheets. All is now right with the world.
I think I'll just chime in here. Not to answer the question, but to confirm the issue and perhaps help people with similar problems.
I had the same problem: an external css file was loaded alright, but it was not applied in Chrome. (Safari and FF were ok about it). So, same problem, slightly different cause.
It turned out that because of a bug in the webserver code the HTTP response contained two Content Types, 'text/html' and 'text/css'.
The solution was to remove the faulty 'text/html' line. It seems Chrome is pickier than other browsers about response headers. Which I suppose is legitimate, but a warning would have been nice.
btw, you can see all the http information for a loaded resource in Chrome, when you open Developer Tools, and select Network. Then click on the file that you want to investigate. (it took me a while to find that)
We had a problems with an iframe wich it's contents was updated by an external javascript routine, the CSS were loaded but were not applied. But updating the body HTML from a routine present in the iframe head worked as suposed to.
This same behaviour was not present in gecko and explorer, but happened the same at Safari browser (webkit)
Hope this could give some light in this curious case.
I would like to add one bit of information that may save some of you some time. It appeared that chrome was not recognizing my CSS either. After reading the above post I reviewed the files in the Developer Tools->Network. Turns out that Chrome was using a locally cached version of my CSS. As soon as I refreshed as opposed to accessing the URL again, it worked!
I'm no expert, but i've made this mistake before, it's rather simple.
You've written:
<link rel="stylesheet" href="/styles/index.css">
If this is a folder in the same directory as your index.html file, then you need to remove the first /. like so:
<link rel="stylesheet" href="styles/index.css">
EDIT: I think someone else mentioned this already, but it may have been overlooked.
I was working on a print stylesheet earlier and came across a problem with IE8. I am using HTML5 and several layout tags including header, nav and footer.
For some reason in my print stylesheet the display:none; declaration on these tags is being ignored in IE8 (and I can only assume subsequent lower versions). I first thought that Developer Tools in IE9 could be causing a false representation, however I have a Windows XP installation in VirtualBox which shows the problem also.
My guess its because HTML5 tags aren't seen properly by anything below IE9. The print stylesheet hides the layout tags in Firefox and Chrome.
Is there anyway to get around this?
Edit:
Here is what I have at the moment:
<link rel="stylesheet" href="<?php echo get_template_directory_uri(); ?>/style.css" type="text/css" media="screen" />
<link rel="stylesheet" href="<?php echo get_template_directory_uri(); ?>/css/print.css" type="text/css" media="print" />
Ignore the PHP Statements, they are specific to my CMS which is WordPress.
Then I simply hide the layout tags in the print.css:
nav,footer {
display:none;
}
This works for IE9, Firefox, Chrome but not in anything lower than IE9. It seems to ignore HTML5 tags.
I suggest you try html5shiv. The main shiv does document.createElement() as you have but it's been optimized / minified like crazy. More importantly, it includes printshiv (IE Print Protector) which will let you style HTML5 elements for print.
Use Modernizr. In the Extra, make sure html5shiv /w printshiv is selected. Include this javascript library on your site and it should work like a charm.
Since all i can do is guess without actually seeing the code, my first guess would be that the html5 shiv that is being used after the css declarations, and the css simply skips the html 5 tags, without applying the css styles to them. Try setting the script at the very top, before any css link tags in the head.
You could try a workaraound using Javascript by including a pair of functions onbeforeprint and onafterprint in which you hide/show the content that should be display:none.
I highly recomend for the use of boilerplate for your trouble. Is a nice compilation for web standarts and some know and common issues in almost every browser. It use modernizr and have an awesome stylesheet that have a #media print that you can use for all your printing troubles in all browsers.
From Richard Kiessig's ultra fast asp.net book,
Head section can't contain any tags that cause the browser to draw content on the screen, users will see noting until it has downloaded all resources in the section.
-- What he is referring from this statement?
<HEAD runat ="server">
<title>WebForm1</title>
<h1> Hi </h1>
</HEAD>
Browser is rending 'hi'.
h1 inside head is invalid html. It is not allowed. But if producers of webbrowsers would reject every invalid html-document, about 90% (or even more) websites would not displayed to the user.
So one browser producer built a browser who was able to render invalid sites too, and all the user started to use this browser. So the producers of correct webbrowsers had no other chance. They also built browsers that can render invalid html. And because of this, all webbrowsers that are in use are browsers that are able to render invalid html.
BUT:
There is no standard defined on how to render invalid html. So each producer has his own ideas about how to display an invalid document, and so, when you write invalid html, you could have luck, and the document looks fine in the one browser you used for developing and testing. But the users of your website do not only use YOUR browser. They use ALL available browsers, and if your html-code is invalid, the chances are really high, that many users use a browser you dont know, and this browser don't display what you want, but some garbage.
Conclusio:
Producers of really good Web-Browsers MUST produce browsers that can render any garbage.
Producers of really good html-documents MUST procuce valid html.
The statement “Head section can't contain any tags that cause the browser to draw content on the screen, users will see noting until it has downloaded all resources in the section.” is best ignored; it just causes confusion and lacks a point. Trying to correct the mistakes in it would take long and would not really lead to anything.
Regarding the treatment of the invalid markup
<HEAD runat ="server">
<title>WebForm1</title>
<h1> Hi </h1>
</HEAD>
the simple answer is that browsers have parsers that imply a closing </head> tag and an opening <body> tag, when they encounter <h1> while parsing a head element. This is in full conformance with HTML specifications.
In the fragment, the only invalid thing, apart from the runat ="server" attribute, which is not expected to be delivered to clients at all (it’s ASP not HTML), is the spurious end tag </HEAD>. The head element was already closed, it cannot be closed again.
Yeah, sure the <head></head> can contain all tags that by default carry the display:none; property. Those are elements like <meta> and <title>. But <h1> has to render on the screen, it is display:inline;. Most elements aren't display:none; though, and should be placed in the <body></body> section.
At that point it won't validate with w3c therefore you're breaking web standards. However, it should render just fine in all modern browsers. Most people would say you want to retain organization and quality when building web pages, part of that is making sure your code is the correct syntax.
ETA: Standard HTML5 markup...
<!DOCTYPE html>
<html>
<head>
<title>My Title</title>
<!--[if lt IE 9]>
<script src="//html5shiv.googlecode.com/svn/trunk/html5.js"></script>
<![endif]-->
</head>
<body>
<header>
</header>
<section>
</section>
<footer>
</footer>
</body>
</html>
In that lt IE9 comment, it adds HTML5 support to IE 8 and below which do not support it. ;-)