I am trying to set up a simple blog using Metalsmith and the fullPage.js library.
At the moment I have a problem where the height of the section divs upon intial loading are roughly 2 times the correct size.
Ie. when it initially loads the height in the console reads 1563px.
The odd thing is that once I resize my browser window in any way ie. make it larger or smaller, the div(class='section') height will then resize to its correct height in the console and in the browser, and everything is laid out correctly again (with regular sized divs as opposed to the super tall ones that were there previously.
This initial height inconsistency is causing many issues with alignment in my layout, such as the prev/next arrows as well as the div content.
here is a link to my public git repo for this project.
If you want to run this locally you can pull it down, run npm install, then run nf start. You will then be able to access it at localhost/3000.
If anyone has any suggestions that would be much appreciated.
Thanks.
It is not ideal to just public your source. A link reproducing the error would be much better.
In any case, I believe yours is a case of missing the compulsory DOCTYPE declaration at the very start of the page.
Take a look at any examples of fullpage.js. They all have it.
Add this in the first line of your resulting HTML files:
<!DOCTYPE html>
Related
So this is an interesting one. I did a test of using the clown car technique for showing responsive images via svgs loaded via an object tag because I really like the approach.
Now this works all fine, except when you have a few of them on one page with the cache normally activated, you leave the site to go to anywhere else in the interwebs and then press the back button - suddenly all images are mixed up, even though the code is still correct, ie:
object 1 loads svg that shows image from object 3
object 3 loads svg that shows image from object 5
etc.
Totally random and I just can't explain how this can happen. And it only ever happens when I go back to the page via the back command of the browser (chrome).
Has anyone experienced anything like this before??
I guess I'll stick to good old normal images for now...
Just ran into the same bug. And so did Google!
I suppose we'll have to use inline SVGs as loading through <img> tags aren't a possibility for me.
If you only have a single page app, you could add target="_blank" to your <a> tags to ensure the back button will come into play far less.
I dont know what kind of success i'll have from this post but struggling at the moment to get a reply on the rockettheme forums.
I have downloaded this template (Kinetic) from Rockettheme.com (demo below;)
http://demo.rockettheme.com/?template=kinetic
I have changed it to come out looking like the link below;
http://evolve.gen.nz/
However im really struggling to differentiate the footer from the rest of the website. Im looking at changing it to a light grey however I cannot make it stretch right across the website as the footer is located in the container and stops at either edge of the container.
is there anyway to make a footer colour go right across the page?
(the same as the following website, if you go down to the bottom of the page and you will see a dark grey, charcoal colour)
http://www.colmanweb.co.nz/websites/refuge/
Any ideas on how I could get this achieved?
Thanks
You just need to edit the index.php file of the template, should be at templates/kinetic/index.php roughly. If you head to the bottom, you will find a div with rt-footer. You will want to pull this entire div statement out and paste it outside of the div with an id rt-surround. Your best bet is to find rt-debug and paste it just above.
I run a lot of sites off the base gantry template from Rocket Theme and do this type of thing often, so it should work.
Two issues you may run into. If you don't get the right closing div tag, you can get some weird output if the divs aren't closed properly. So be careful and use the indentation to help you.
Second, there may be some css styling that is specific to the old heirarchy. I doubt it in this case, but it can happen. You may have to fix some of the css styling.
i have an html file and i'm using Itext 2 with flying Saucer to convert it to a pdf file.
The problem is that if an image starts near the page end, flying saucer render a portion of it it the end of the current page and the rest in the beginning of the next page.
How to say that i want the entire image on one page only?
You can add this to your print css:
img {
page-break-inside: avoid;
}
The user guide (PDF) mentions it.
There appears to be a bug in FlyingSaucer that is causing issues with page-break-inside: avoid.
The issue manifests when css: orphans kicks in, when a paragraph is laid out towards the end of a page and the minimum number of lines cannot be rendered on the page. Then the block box layout state machine appears to go wrong.
We have pushed a fix to a fork here: https://github.com/krokiet/flyingsaucer/tree/master
At some point we will raise a pull request to get this merged back into the main code base.
I have the same problem but
img {page-break-inside: avoid;}
is not the final solution. Yes it has impact for result and in some situations it works but not always.
Here is some more details about the same or similar problem.
Similar problem
I have been trying out the Susy plugin for Compass (SASS), but I noticed that it isn't working as intended for me.
I took the index.html and screen.scss from the official Susy tutorial, compiled the SCSS and put it up on my server. As you can see it looks just like it's supposed to (on all browsers I tested it on):
What I did next was the following:
Copy the <article> in the <div role="main"> and paste it six times
In screen.scss, change the column-span (div[role="main"] > article) accordingly: from #include columns(6,9); to #include columns(1,9);
But now those new elements don't align to the grid at all, they are off by a clearly visible space. I tested this in recent versions of FF, Safari and Chrome, and only FF seems to display it correctly. Screenshot is from Chrome:
I also uploaded the source for everyone to inspect here.
Is this a general problem with Susy that the grid isn't correct or am I doing something wrong? If the first, does anybody know a workaround? I also tried with percentages and pixels, but neither worked.
Susy isn't just another grid system like all the others. It was designed to fulfill a very specific purpose: grids that are fluid on the inside. The units you use to create the grid are applied to the container, not to each column. Everything inside is built with percentages. What you are seeing is normal. It's true of all fluid grids, because of sub-pixel rounding. It's not a bug, it's a part of building responsive web sites.
If you need pixel-exact grids, Susy is the wrong tool for you. It all depends what you are trying to build.
Re-size your browser to see how it works. You'll notice the grids snapping-to and floating within a few pixels of their guides, but the grid stays intact and never triggers the horizontal scroll-bar.
Cheers!
-e
This is my first time using Susy. I really like what I'm seeing in the docs / tutorials, but I've encountered some unexpected results with some of my first layout attempts.
Version info:
>gem install compass-susy-plugin
Successfully installed sass-3.1.2
Successfully installed chunky_png-1.2.0
Successfully installed fssm-0.2.7
Successfully installed compass-0.11.1
Successfully installed compass-susy-plugin-0.9
>ruby --version
ruby 1.9.2p136 (2010-12-25 revision 30365) [x86_64-darwin10.5.0]
The image below shows the result I'm getting using the tutorial html and screen.scss verbatim:
As you can see, inspecting the h1 element shows it sitting just off the grid. Is this normal?
See my comment on another similar question:
Susy isn't just another grid system like all the others. It was
designed to fulfill a very specific purpose: grids that are fluid on
the inside. The units you use to create the grid are applied to
the container, not to each column. Everything inside is built with
percentages. What you are seeing is normal. It's true of all fluid
grids, because of sub-pixel rounding. It's not a bug, it's a part
of building responsive web sites.
If you need pixel-exact grids, Susy is the wrong tool for you. It all
depends what you are trying to build.
Re-size your browser to see how it works. You'll notice the grids
snapping-to and floating within a few pixels of their guides, but the
grid stays intact and never triggers the horizontal scroll-bar.
Cheers!
-e
If I slowly expand the browser window in Chrome vs Firefox, the grid and text jump around more in Chrome than Firefox. It appears Firefox is more precise with the layout (which may impose a rendering speed penalty).
In Firefox, everything always lines up perfectly and moves together -- the text areas and the grid -- as I resize. In Chrome, I can see the footer text moving at different times vs the article text vs the grid vs etc., as I resize.
Here's an example where the text and the grid were off by quite a few pixels in Chrome: