I have finally perfected my web page and it works perfectly in every browser.
However, when I abstracted out the header and footer contents into server side includes, the layout changes marginally in Firefox/Opera/Safari, but in IE, the layout changes makes the page look broken.
Are there any known issues that could cause the layout to change when using SSIs? Quite frankly, I'm surprised that using a SSI would have an effect like this. I am using HTML5 tags, the modernizr js library, and the page validates if any of that matters.
EDIT: I fixed my problem by changing what code was abstracted (I simply abstracted one parent tag further than before). HOWEVER, I am still eager to know exactly why this bug happened in the first place. Is there someone out there who could shed light on what in particular could cause this?
Chances are that its not SSI that's causing any issues.
It's entirely possible that there are newlines in the HTML code causing IE to insert extraneous spaces, causing the layout to break.
Also, be sure you separated the code correctly when you moved pieces to the includes. It is probably easiest to check this by running your HTML through a validator.
I was having a similar problem and fixed as follows.
i had something like this:
<div>
<include>
</div>
and fixed it by changing it to this:
<div><include></div>
The issue ending up being a bug with how the server parsed the HTML and with HTML5 tags. For whatever reason, when I added one extra tag set to the SSI, it worked.
My original include looked like this:
<header>
<!--#Include File="/includes/header.shtm"-->
</header>
with the included file being:
<nav>
<ul>
<li>Home</li>
<li>Products</li>
<li>About</li>
<li>Contact</li>
</ul>
</nav>
But when I took all of the HTML5 tags out of the include, as shown below, everything worked as normal. I'm not sure if this is an issue with an old version of apache or what, but doing this fixed everything.
<header>
<nav>
<!--#Include File="/includes/header.shtm"-->
</nav>
</header>
It may be a file encoding problem with UTF-8, inserting BOM characters at the beginning of the included file. My solution was to save the include file as UTF-8 without the BOM signature.
I noticed having the include statement just after the body tag showed the extra space, but adding (any?) html tag around the include statement hides it. I'm guessing the browser ignores the characters once they're "inside" the body instead of the beginning.
My particular situation involved Visual Studio, but it shows up with a mix of editors. See also
How can I avoid the blank space when using PHP include?
Force Visual Studio (2010) to save all files in UTF-8
UTF-8 without BOM
Related
I have an unusual situation. I am in a transitional state for a website that will eventually be a wiki-like site that uses markdown files to generate documentation. However, for our phase 0 demonstration to upper management, I need to use HTML instead of markdown for advanced layouts. This leads to large portions of the Markdown files being HTML. Generally speaking, this is working fine, but sometimes the "4 spaces means code block" "feature" of markdown means that instead of rendering the page, I just get the HTML pasted to the screen in a <pre>.
So, my question is, how can I turn off the "4 spaces means code block" thing? IMO, this is an idiotic design in the first place, but it's really screwing with my current project!
For example:
I have a banner
<div class="banner detail">
<div class="banner-inner">
...
</div>
</div>
On some pages, this renders exactly as expected. On others, it spits out the "banner-inner" div and everything inside it to the page. Hell, even convincing this editor to display that code snippet instead of processing it took 5 minutes of trial and error poking...
Please, some one help me turn off or get around (without simply not using indenting...) this "feature"!!
Sadly, whether this "feature" can be turned off is relegated to a customization question for the specific software package in use.
On the bright side, I was able to eventually determine that the specific problem I was having was caused by the engine interpreting invalid HTML code (ie, missing a closing tag) as code to be displayed rather than processed. So in the end, seeing this happen actually tended to mean that I had a bug to fix.
Hello,
I have the website DaltonEmpire (http://daltonempire.nl, check out for yourself), and when I got home today, it showed error 500. I had made really tiny HTML changes at school via my new CodeAnywhere app, but this was not supposed to happen. After some cleaning up of my PHP, just removing whitespaces, the page loaded.
But now, the background is completely gone and there all all kinds of weird &nspb; tags between my HTML according to Chrome Developer Tools [1], which weren't there before. In my actual code, of course there's whitespace to order my HTML, but that's just spaces, no &nspb;'s, and that never happened before.
Also, the body background is not loaded [2], and the Developer Tools indicate that CSS responsible for the background is not included at all [3] (rather than overwritten or not loaded), even though it is clearly in a <style> block with the body selector [4]. Manually adding that [5][6] bit through the Developer Tools seem to fix this.
Has anyone any idea how this could happen/how this could be solved?
The strangest thing is, I did not change anything specific at all that I can recall. What has caused this?
I need my website to be fixed as fast as possible, as my visitors are students to get their educative documents and in two days is their test week.
Thanks in regard,
Isaiah van Hunen
Attachments:
Weird &nspb;'s
Background not loaded
Background CSS not included?
Background CSS is included
Adding manual Background CSS
Background loads
I can help with 1).
is a formatting entity:
it is the entity used to represent a non-breaking space. It is essentially a standard space, the primary difference being that a browser should not break
(or wrap) a line of text at the point that this occupies.
http://www.sightspecific.com/~mosh/www_faq/nbsp.html
Microsoft Word puts it into HTML files, and so do other WYSIWYG editors.
Unfortunately, CodeAnywhere seems to have the same issue.
Do you have an earlier version of the code that you can open in Notepad/Notepad++/Atom in order to add the whitespace manually there (with ` tags or the like)? That might help.
I have a handlebars template file that I'd like to minify. I found a couple questions that were related to my issue on StackOverflow, but nothing exactly like it that had an answer. My issue is that spaces that are within the templated values are getting removed when I run the code through a minifier.
Example:
I have this line of code in my template file:
<div>{{{displayName}}} - {{cost}}</div>
When I use the un-minified file to render the page, I get entries like:
ProductName - $5.50
which is what I want. After running the template through an html minifier, my template line now looks like this:
<div>{{{displayName}}}-{{cost}}</div>
and the entries on the rendered page look like:
ProductName-$5.50
Not optimal. Now, I understand that I could just run through the template and put in non-breaking spaces into all the places where I'd like spaces to be. Nice. Simple. Easy... relatively.
But.
A secondary, and larger, issue comes into play (and what's the point of going through and putting in all those non-breaking spaces into my template file to avoid this situation with the html minifier if there are more issues) when I'm selectively adding attributes or classes to a given html element.
Example:
I also have lines in my template files that look like:
<div class="paymentMethod{{#if paymentSelected}} active{{/if}}">
On the condition where my template (handlebars) variable "paymentSelected" is true the html shows as:
After minification, however the minified template file contains:
<div class="paymentMethod{{#if amazonAndPaypal}}active{{/if}}">
which makes the html on the page show as:
which, consequently, messes up all of my css and javascript because there is now one unrecognized class on the element instead of two correct classes.
Again, there is a way of getting around this. I could just place all of the class definitions into the template variables. So, my new template would be:
<div class="{{#if amazonAndPaypal}}paymentMethod active{{else}}paymentMethod{{/if}}">
This kind of goes against the idea of removing redundancy though. So I don't like it. And this is a fairly simple case, with only two possible classes.
I'm sure there are more possibilities for hassle with html minification of template files, but I think I've shown my point.
Now, all of that explanation comes to my question:
Is there a tool out there that will minify html but ignore spaces that are between opening and closing template tags? For me, those spaces are similar to the spaces between words. I don't want all the spaces between the words of a sentence removed any more than I want the spaces within my template tags to be removed.
I also went searching for a generic sed solution, but didn't find anything in that direction either.
Could you just use &nbsp;?
<div class="paymentMethod{{#if paymentSelected}} active{{/if}}">
Okay, so I figured out a better option, and this may be incredibly obvious to some but I'm pretty new to the whole Handlebars gig.
A better solution to minifying the html templates would be to precompile the templates and to then minify the resulting javascript. This way, I also get the savings of no compilation time on the browser side and (because I'm using Handlebars as my templating language) loading the smaller runtime script.
Granted, this solution doesn't explicitly answer the question I posed, it does solve the ultimate problem I'm trying to solve, which is to minimize the page-load time on a browser by doing everything I can to the necessary assets prior to a browser downloading them.
Does commented html elements and White spaces will causes page loading time.I know commented markup will not run by browser.compressing markup is the good idea while deploying in server
<!--Html Elements -->
It will still increase your page size, but shouldn't be a problem. Having 10000 lines of commented-out HTML is going to be a problem though, but keeping your comments small, should not increase the page size by too much.
It won't be run by the browser, but it will be in every case streamed by the server, and downloaded by the client. It shouldn't make any difference, as long as you don't have enourmous amounts of characters in there.
If you're using dynamic pages generated server side, you might be interested in server-side comments, that don't get streamed in the response, so the client never downloads/sees them.For instance, in JSP, <%-- this is a server-side comment --%>.
Also, remember that javascript code is not affected by these comments, actually, <!-- --> is used to to avoid javascript code showing up on old old browsers that didn't support javascript. See this link: Hiding JS code from old browsers.
Your page size will be increased but the execution time will stay the same as the comments are not parsed.
If you are using a server-side language, you can use their comments instead, like so:
<ul>
<li>Something</li>
<?php /* <li>Else</li> */ ?>
</ul>
This will hide the HTML from anyone poking around in your source code and will reduce the page size as the commented out HTML will not be sent to the user.
You could also use PHP's output control functions to automatically strip out any HTML comments. More info here: http://www.php.net/manual/en/ref.outcontrol.php
You can also use those functions to compress your pages, remove whitespace, etc, which will also speed up page load by decreasing page size.
I use Hakyll to generate some documentation and I noticed that it has a weird way of closing the HTML tags in the code it generates.
There was a page where they said that you must generate the markup as they do, or the layout of your page will be broken under some conditions, but I can't find it now.
I created a small test page (code below) which has one red layer with the "normal" HTML markup, and a yellow layer with markup similar to what hakyll generates.
I can't see any diference in Firefox between the two divs.
Can anybody explain if what they say is true?
<html>
<body>
<!-- NORMAL STYLE -->
<div style="background: red">
<p>Make available the code from the library you added to your application. Again, the way to do this varies between languages (from adding import statements in python to adding a jar to the classpath for java)</p>
<p>Create an instance of the client and, in your code, make calls to it through this instance's methods.</p>
</div>
<!-- HAKYLL STYLE -->
<div style="background: yellow"
><p
>Make available the code from the library you added to your application. Again, the way to do this varies between languages (from adding import statements in python to adding a jar to the classpath for java)</p
><p
>Create an instance of the client and, in your code, make calls to it through this instance's methods.</p
></div
>
</body>
<html>
It's actually pandoc that's generating the HTML code. There's a good explanation in the Pandoc issue tracker:
http://code.google.com/p/pandoc/issues/detail?id=134
The reason is
because any whitespace (including newline and tabs) between HTML tags will cause the
browser to insert a space character between those elements. It is far easier on the
machine logic to leave these spaces out, because then you don't need to think about
the possible ways that the HTML text formatting could be messing with the browser adding
extra spaces.
There are times when stripping the white space between two tags will make a difference, particularly when dealing with inline elements.
I ran tidy over it and it fixed the unusual linebreaks.