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:
Related
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>
We have been using the uCKEditor plugin for umbraco for a few months now. We also installed a plugin for it called Image Maps.
Recently, one of our content editors noticed a sharp drop in performance while editing some pages. After testing it for a while I noticed that removing all image maps from the source completely solved the performance problem, the editor was responsive lightning fast again.
An example of an imagemap added by the plugin:
<img src="image.jpg" usemap="#imgmap20156281337" />
<map id="imgmap20156281337" name="imgmap20156281337">
<area coords="75,74,183,206" href="http://www.example.com" shape="rect"/>
<area coords="408,169,533,368" href="http://www.example.com" shape="rect" />
</map>
In reality, the plugin simply adds a few lines of HTML to the image, so I couldn't understand why it would affect performance so severely.
Therefore, I decided to check where the breakpoint would be for adding imagemaps. In a page with 5 images, I started adding imagemaps to those images via the plugin.
The first imagemap showed no performance drop. After the second image map, a slight delay started to manifest with every user action. Every imagemap afterwards made the delay progressively worse to the point where at 5 images with 5 imagemaps, the editor takes over 4-5sec to just move the cursor 1 character distance left/right. This is what my content editor colleague experienced.
I tried adding the imagemaps manually(without the plugin) and I noticed that we still get the performance issues. However, the editor seems to run fine in <>Source view, but as soon as we switch back to default the performance drops dramatically. It seems that the editor is having problems rendering the imagemaps on top of the images.
What is causing this horrible performance when working with multiple image maps in the same editor?
Is there anything we can do about it?
I discovered what was causing the problem!
While communicating with the creator of the imagemaps plugin, he referred me to his test page: http://www.martinezdelizarrondo.com/ckplugins/imagemaps.demo4/
When we are working locally in uCKEditor and we insert an image from the media picker, the image gets inserted using a relative local path like:
src="/media/1370030/4483_a.jpg"
Then I tried to paste the same html to the remote test page, and naturally, I had to include the full domain path to the image:
src="http://www.dphtrading.dk/media/1370030/4483_a.jpg"
The first thing I noticed was that locally, uCKEditor draws borders on the lines specified in the imagemaps for a specific image. I took a screenshot to illustrate:
http://imgur.com/dUJMzWn
While on the remote test server, there were no borders and no performance problems. So I inserted the full domain path for the images into our uCKEditor and this solved the performance problems (and removed the imagemap borders for some reason).
It looks like uCKEditor and probably CKEditor in general doesn't like the combination of relative file paths and imagemaps for the same image.
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 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
I keep running across this loading image
http://georgia.ubuntuforums.com/images/misc/lightbox_progress.gif
which seems to have entered into existence in the last 18 months. All of a sudden it is in every application and is on every web site. Not wanting to be left out is there somewhere I can get this logo, perhaps with a transparent background? Also where did it come from?
You can get many different AJAX loading animations in any colour you want here: ajaxload.info
I believe the animation came from the Mac OS X loading screen. Here's a similar one with a transparent background:
alt text http://homepage.mac.com/xraydoc/.Pictures/spinner.gif
I think it's just a general extension to the normal clock-face style loading icon. The Firefox throbber is the first example of that style that I remember coming across; the only real difference between that and the current trend of straight lines is that the constituent symbols have been stretched to give a crisper look, moving back to more of a many-handed clock emblem.