HTML(5) with meteor - html

Any idea why when putting the example html files included on meteor's site in to an HTML 5 template with top level tags fails?
<!DOCTYPE html>
<html lang="en">
I see that they search for body/template tags etc and concatenate but not sure how to add the other tags then.

The '.html' file you're editing as part of your Meteor application isn't an HTML file at all, but a DSL (domain specific language) that is parsed by Meteor as HTML.
As soon as you run meteor to launch a server or deploy it, it will be parsed and interpreted, and all documents will be output as HTML5 (using the ).
You can see that on any deployed meteor app, that is the first line, even though entering it in to your '.html' file in the project will cause the compiler to crash.

I was confused by this at first as well, apparently the '.html' example files they include are intended to consist of html fragments rather than serving as html documents in and of themselves. According to the docs:
HTML files in a Meteor application are treated quite a bit differently
from a server-side framework. Meteor scans all the HTML files in your
directory for three top-level elements: <head>, <body>, and
<template>. The head and body sections are seperately concatenated
into a single head and body, which are transmitted to the client on
initial page load.
As far as I can tell, any html that is included that isn't contained within any of those three tags -- including <!doctype html> declarations, <html> tags or even <!--html comments--> -- causes the app to crash. Hopefully that's something that they'll fix eventually.

When the server is started and you access the page it automatically adds the DOCTYPE in.

Related

Include standalone HTML page in sphinx document

For most of my project's documentation I prefer a standard sphinx layout. However for the landing page I would prefer to use custom HTML/CSS/JS without any of the layout, TOC, or sidebars of the normal sphinx site. Is there a way to include a raw HTML standalone page in a sphinx-generated website in a way that completely disregards the normal layout of the rest of the site?
As a counter example I know that I can include raw HTML bits into a page using the following (see also this question)
.. raw:: html
:file: myfile-html
However this just embeds a file within the normal layout. I would like to have a completely standalone HTML page.
I just ran into this problem myself, and the way I solved it was to simply include the html file in my source/_static folder, then refer to it with a relative link.
So if source/_static/my_standalone.htm is the path where I have my non-generated HTML file, and the .rst file where I want to type my link is at source/otherfolder/index.rst, I write it like this in my rst:
Link to my non-Sphinx HTML file
===============================
To get to my standalone, non-generated HTML file,
just `click here <../_static/my_standalone.html>`_ now!

Include local html fragments within local html main container

Background
I want to stop using Latex for creating documentation and automatic reports for my applications and I would prefer to use html+css that I may later convert to pdf using wkhtml2pdf that allow for adding cover page, table of content, headers, footers, all in A4 separated pages.
wkhtml2pdf is light exe and supports for scripts/css for advanced document pre-processing / formatting. So, so far, so good, it all seems html+css is my best option to replace Latex ...
Issue
In order to ease maintenance and not to put all documentation content in a single file, I had initially thought to organize my local files like this:
doc/index.html
docs/includes/introduction.html
docs/includes/part1.html
docs/includes/part2.html
docs/resources/mystyle.css
docs/resources/jquery-3.1.1.min.js
And write main documentation index.html as follow:
<!DOCTYPE html>
<html>
<head>
<link rel="stylesheet" type="text/css" href="mystyle.css">
<script src="./resources/jquery-3.1.1.min.js"></script>
<script>
// When document is ready, feed divs with real content
$(document).ready(function()
{
$('#Introduction').load('./resources/introduction.html');
$('#Part1').load('./resources/part1.html');
$('#Part2').load('./resources/part2.html');
});
</script>
</head>
<body>
<div id="Introduction"></div>
<div id="Part1"></div>
<div id="Part2"></div>
</body>
</html>
Unfortunately doing this way, I receive a XMLHttpRequest error basically telling that it cannot load files because cross-origin is only supported for http, data, chrome, https etc... protocols (?? even though all my files are local and main.html was also launched from local file system --so all same origin-- ??).
I tried many workarounds (link rel=import, w3IncludeHTML, use iframe and try to read content) they all fall in cross-origin issue.
Question
Is there an easy/light solution to merge all local html fragments in local main.html file (i.e no external grep or extra tools, just basic html+javascript) ?
NB1: I know I can change flags in chrome browser to allow cross-origin but would like to avoid this. First, for security reason. Second, because I can't do the same when sending files to wkhtml2pdf converter. Third because is not easy to provide documentation as is and say "just click index.html to open documentation in web-browser".
NB2: Documentation fragments is very likely to be just <section>, <p>, <img>, <table> elements all merged in body of main.html managing for css-formatting and other stuff in a single place.
You can get local files in Firefox, using XMLHttpRequest.
It used to work with Chrome, but a "security" restriction has been introduced since 2010 for local files.
Maybe you can suggest to use Firefox to all your customers...
A workaround (for Chrome) could be to load ressources as <script>, and get the content in multiline strings.
In index.html:
<script src="ressource1.js"></script>
...
In ressource1.js:
var fragment1 = `
<section>
HTML content for part 1
</section>`
document.querySelector( '#target1' ).innerHTML = fragment1
Ressources are kept in separate files (in form of JavaScript) and injected in the main HTML document.
Maybe it would be worth to provide an Electron application along with your documentation files to browse it without web server.
Actually it's a node.js web server packed with a chromuim browser. It targets most platfoms and you just need your HTML/JS/CSS skills. By the way you could also integrate a PDF library inside.

My Apache reverse proxy adds code to body of fetched HTML files from head tag

I have a simple reverse proxy server using Apache 2.4.20 which gets HTML files from an internal Apache web server. The page fetching and URL rewriting is working fine, but there is a problem occurring.
After any webpage is passed through the proxy, three things are incorrect: the contents of the head tag appears in the body, the head tag is missing and a mysterious ">" character in a "p" tag is added at the top of the body tag.
This extra <p>></p> code suggests to me something wrong with the detection of a HTML tag (it could be part of <head>). Also, even without content in the head tag, the body tag still begins with that weird code.
Proxied content - viewed in developer tools, Google Chrome browser:
Proxied content - original source of fetched file:
Original HTML file - opened directly from internal server filesystem:
Proxy server configuration file - section about transfer and ProxyHTML:
I know the original server is working correctly so this isn't causing the problem.
Here's a screenshot of the HTML file viewed directly from the original server in a browser (on the proxy server device), along with source code shown in Chrome Developer Tools:
Update: As expected, mod_proxy_html is the main cause of my problem (turning it off left the original file). However, this isn't a solution for me because I need the tool to rewrite relative URL references in the proxied documents. I read the documentation page but it didn't describe any features that undoubtedly caused my problem.
List of mod_proxy_html directives from the documentation which I think aren't relevant, some tested: ProxyHTMLBufSize, ProxyHTMLCharsetOut, ProxyHTMLDocType, ProxyHTMLEnable, ProxyHTMLEvents, ProxyHTMLExtended (default off), ProxyHTMLFixups (tried from suggestion), ProxyHTMLInterp, ProxyHTMLLinks, ProxyHTMLMeta (default off), ProxyHTMLStripComments, ProxyHTMLURLMap.
I had the same issue. However, on the same machine, other sites that used the same reverse-proxy worked fine, even when they have exactly the same config, but different URL. I could not understand... except after I have noticed that the files that had problem had the BOM signature at the beginning of the file!
This caused the ProxyHTML to be confused so much that it had removed the <head> and </head> tags.
After I have removed the BOM using the dos2unix utility, files were shown properly.
Your post gave me extra motivation for fighting this. Thanks.
you are using mod_proxy_html
This mod will try to affect HTML resources proxied through depending on the directives. My advice would be to remove the ProxyHTML directives and see what comes back. If it is unaffected then you know its something to do with mod_proxy_html.
Then look at adding this directive below the ProxyHTMLEnable
ProxyHTMLFixups off
Your problem is the document type definition
<!DOCTYPE html/>
the tag should not be closed. It should look like this:
<!DOCTYPE html>
mod_proxy_html tries to fix what it sees as an extra > character by wrapping it in paragraph.

(Almost) empty index.html file

When using a almost empty file named index.html in my apache directories in order to avoid directory listings (e.g. /image folder), what is the minimum content of this file? Can it be empty, or should I include something like:
<!DOCTYPE html><title></title>
or
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<html>
<head>
<title></title>
</head>
<body>
&npsp;
</body>
</html>
or something in between?
Indeed the first line of code is the minimum valid HTML5 code. <!DOCTYPE html><title> </title>
Though you must have a title, wether that be a space or text. Otherwise use the full declaration if you do not wish to give a title in order to be valid markup.
This can be verified using the W3C validator
If you just want to avoid directory listing, it might just be better to make one single page for the error code 403, then change the following in your Apache configuration:
Options Includes Indexes FollowSymLinks MultiViews
to:
Options Includes FollowSymLinks MultiViews
removing Indexes from the list. If you don't have access to the http.conf file, placing Options -Indexes in a .htaccess file will have the same effect. This will make Apache send a 403 Access Denied error whenever a visitor is trying to access a URL which resulted in the directory list before. Now, all you need to do is to redirect these errors to your own custom error page. You can do this using
ErrorDocument 403 /path/to/custom403errorpage.html
This is not just an easier and more secure way of doing it, but also lets the users know that they shouldn't be looking around your stuff.
To avoid directory listing you need no HTML file at all. You can just add a .htaccess file in the folder with the options you want. To disable folder listing add this line to your .htaccess file
Options -Indexes
Note that on most live hosts directory listing is disabled by default
As a question about formally minimal HTML document, this depends on the version of HTML. Regarding the alternatives in the question, the first one is not valid according to current HTML5 drafts (the title element must have some content, e.g. a space), and the second one is not minimal at all (it has many optional tags) and it is not valid (URL is missing from the doctype declaration, and the entity reference &npsp; is undefined); besides, HTML 4.0 was obsoleted by HTML 4.01 in 1999.
For the purposes of avoiding directory listings (which can be avoided in other ways, too), any file will do, even an empty one.
However, an empty file, or an HTML document with blank content, will result in a blank page shown to the user when the user tries to access, say, http://foo.example.com/images/, when http://foo.example.com/images/index.html exists with no content. Therefore, you may consider using content like this:
<!doctype html>
<title>Directory listing not allowed</title>
Directory listing not allowed.

include html file within an html file

I'm trying to include an html file within another html file. the include acts as a menu and footer. i'm using the current include syntax but my html data is not displaying on the page. my include files sit at the root. i've tried:
<!--#include virtual="header.html" -->
<!--#include file="navigation.html"-->
<html>
<head>
<title>test</title>
</head>
<body>
<!--#include virtual="header.html" -->
<!--#include virtual="navigation.html"-->
<p>test<p>
<!--#include virtual="footer.html"-->
</body>
</html>
Check if your server has server-side includes (SSIs) enabled.
edit: Also, you should remove the first set of includes that come before the html tag - that's invalid.
Apache webserver? Do you have "mod_include" enabled? Do you have either in .htaccess or httpd.conf the setting "Options +Includes" set?
Includes are server side, you'll need to save the main file as an .asp file and work with it on a server (assuming your server is ASP enabled, your syntax certainly makes that look as if it's the case).
a lot of info lays here: http://www.boutell.com/newfaq/creating/include.html, if it runs in the server i would go for <?php include("filename.html"); ?> since most of the servers also have php, if not you can always use .js
P.S. i won't mentions html possible problems since other answers i think mentioned all i know...
The Netscape Navigator frames extension (cf. Wikipedia's Framing article) and its successors allow you to write HTML pages that reference other pages for inclusion. The browser then assembles the viewed page by making multiple HTTP requests. Note:
It's a horrible way to serve up webpages: there's no well-behaved document model for it. But it is fairly well supported by browsers. So this answer is for information's sake, not a recommendation; and
It creates viewed pages by juxtaposition, not inclusion, so it's not really what you were after, semantically speaking. But you can use it to solve your problem: the menu and footer bars are mini HTML pages that sit next to the page containing the main content.