Huge delay when opening ui.html locally. about gumby HOT 21 CLOSED

The delay is caused because the font is loaded as with // and no protocol set.
If you are just opening the file and not serving it through http, it's going to try load the font as 'file://link-to-font'.

You can edit the link in the CSS if you want, but using // accounts for both http and https served pages

Regards,
Sean Anderson

On 29/05/2013, at 12:43 PM, "Robertino" [email protected] wrote:

I'm evaluating Gumby, and cloned the repo to my dev+design PC.
Opening ui.html in Chrome causes a huge ~23 second delay and failed download of a Google font family. This happens constantly. Hitting Ctrl+R or Shift+F5 to bypass the browser cache doesn't rid off the problem.
See screenshot : http://oi40.tinypic.com/3492lu0.jpg

I suspect that this has something similar to do as with the overzealous security measures when playing Flash video from a html page on your local hard drive. But because this is not a Flash video, I can't point my browser's Flash player to the Adobe site to whitelist the html file or the whole folder.

Any ideas, apart from not using Google fonts ?
Because this is not workable when I have to wait an extra 23 seconds after each refresh.

(I usually do as much of the prototyping, designing, and coding as possible into static pages.And only at the end chop this up in WP format and glue the pieces back together with PHP on the server in a VMware VM.)

—
Reply to this email directly or view it on GitHub.

from gumby.

OK I see it now, and I also understand why // was specified, and that changing style.css would resolve the issue. But only for the ui.html demo. Because // is also in sass/_fonts.scss. When I re-compile the delay would occur in my projects. I'm not using a server location to design. (See my workflow.)
And I'm not making changes to the core *.scss files inside my Gumby repo.

from gumby.

We would recommend you use a local server to design. Even just for simple HTML sites, this would solve your font issue as well the JavaScript's loading of jQuery mobile on touch devices. The framework is built to run on a web server not directly viewing the files.

However, if you do not want to edit Gumby's core scss files (which I do not recommend you do) you could overwrite _fonts.scss by commenting out the import in gumby.scss and including a separate scss file to handle fonts. That way re-compiling won'y overwrite your changes. This would be my recommendation, however if you are editing the css directly I don't see why you would recompile anyway.

from gumby.

What I mean is that I do not want to edit the core scss files in my local copy of Gumby because it is a git repository and would cause conflicts when pulling updates.

And changing gumby.scss like you mentioned, but also not recommended, is changing a core scss file. And would cause a conflict.

Also I'm not going to use just Gumby's scss files. I also have a lot of scss mixins, functions, styles, and animations which I re-use. That's why I need to recompile.

Besides, you encourage changing the var/_settings.scss which would need recompiling and would mean changing a core Gumby scss file.
Ref : http://gumbyframework.com/docs/sass/#!/overview
Quote:

Gumby provides a sas/var/_settings.scss file containing a load of customizable variables. Change a variable, compile and watch your changes propogate throughout Gumby.

(It contains a typo in the path too.)

We would recommend you use a local server to design
I'm using a local server in a VM, but only in the last phase when PHP is involved. Check my workflow at the bottom of the issue description.

But anyway this : We would recommend you use a local server to design makes me look elsewhere.
Asking to change my workflow is too much when there are so many others around.
So take care.

from gumby.

Ok, no problem. If you are running in a web server then you won't have any issues, I was under the impression you were viewing the file directly e.g. file://. PHP is not needed in any way whatsoever.

You are going to run into issues if you are working directly within a git repo anyway, this will always be the case. The solution to this is to use a package manager to handle keeping your dependencies up to date and create a custom version of settings.scss. We use bower to manage our dependencies within this workflow and that way can use git to version control our own projects rather than building within another projects repo.

I'm sorry you are looking else where but a web framework required to run on a web server is pretty common.

from gumby.

PHP is needed for WP (WordPress) like I mentioned.

I am currently using Zurb Foundation and have none of these issues.

I can work directly in my own git project repo as I please. How else are new repos created?
And In an existing repo, I can always do a git checkout -b my_own_masterto create a copy of the masterbranch, test things out and then throw my_own_master away, or checkout back and forth between the master and my_own_master branch, or even merge the two. And then push the merged master back upstream to origin.

I was going to post the following, but you closed this, maybe someone else can do something with it :
I plan to have only one Gumby repo for all projects.
So I copied the sass/gumby.scss, sass/var/_list.scss, sass/var/_settings.scss, sass/var/_fonts.scss files from my Gumby repo into a my-project directory (another repo).
Renamed the copied gumby.scss to my-project.gumby.scss.
Then adjusted the paths of the @import lines in my-project.gumby.scss to all point to my Gumby repo. Except the paths of the sass/var/_list.scss, sass/var/_settings.scss, and sass/var/_fonts.scss files, which point to their copies in my-project.
Then added @imports for some of my own scss at the bottom of my-project.gumby.scss file.
And it compiled at the second attempt into the stylesheets folder in my-project.

from gumby.

Yep that's how we work except we use Bower to manage our dependencies. Glad you found a solution.

from gumby.

It's again a remote solution. Requiring Node.

I need to get the complete finished html first (with all css, font, and js files) to chop it up, and eventually put it in separate WP PHP files.
If I would not make a static version of the pages first, I would have to work with HTML, CSS, etc in PHP files directly : header.php, footer.php, single.php, page.php, etc, etc.

Why would I do my design work on a local or remote server?
While I can design the static HTML pages in a git repo on my hard disk (SSD). Which is blistering fast.
Only when I have created the WP PHP files, I need to do a pull on the server in the VM.
PHP is even required to display a static page in WP.

Anyway, I guess we are never going to agree.

from gumby.

I don't really understand your issue to be honest. You can work with static files on a local server, I do this so that other tools I may use in development can also run, Sass, Node, Bower etc. Working on files directly on your hard drive is not a very common workflow for web development. Run your web server on your blistering fast SSD?

Sorry if I'm missing the point.

from gumby.

Have you tried using NFS or Samba to share the project's directory to the vm? This removes the need to pull on your local webserver and makes working on it as fast as off of the hard drive.

For clarity, we make a copy of the settings.scss file, leave gumby in its own directory (public_html/components/gumby) and then make a styles.scss file which pulls in the duplicated settings.scss followed by the core gumby scss files. The duplicate settings.scss and custom styles.scss live in their own directory (public_html/sass).

from gumby.

I do not want to develop on a local or remote server when I'm just designing.

I have Ruby installed and can use Middleman to generate/compile static HTML pages. Without a local or remote web server.
I'm pretty sure many others do this also.

from gumby.

@EpocSquadron I did something similar in my test a few comments above yours.

@chambaz I do not use tools just because they exist. Not even a web server.
If I have a static HTML file and all supporting files, on my local disk, I should be able to open the static file in the browser.
The trick with the // to prevent the browser popup of content being transferred over a not secured connection is the only thing requiring a web server. Hardly justification. To me anyway.

When I look how simple my workspace is set up compared to others, and how fast it works. I'm totally happy. Not even a single // in Gumby's _fonts.scss is going to change that.
Like I wrote, we are never going to agree on this one.

from gumby.

No one is trying to change your workflow. All people here are trying to say is that in order to not run into CORS errors working locally with anything that requires web dependent items (fonts, videos, etc), you'll need to use a web server. Plain and simple. It can be locally on a VM like you said you used earlier.

GET file://fonts.googleapis.com/css?family=Open+Sans:400,300,600,700 is going to 404 everytime.

The only solution (to not use a web server) is to comment out the Google fonts in gumby.scss (line 4) and add your own local files based on your current setup/workflow. A template for that can be found in the aforementioned file.

from gumby.

You'll also need to edit
$font-family: "Open Sans";
to your desired font-face/family.

from gumby.

Fonts and video do not need to have a web dependency in a development environment. Pulling them from other servers was only introduced in a production environment. Plain, simple, and period.

The next thing I'll here is that CSS is a server side technology.

from gumby.

I don't understand your issue then. Seems to be your displeasure with an industry accepted protocol:

http://www.paulirish.com/2010/the-protocol-relative-url/

Other than that, Gumby is a framework, a starting point, to get your development jumpstarted. Just like Bootstrap, Foundation, and others, Gumby is here for you to start with and build on. If something isn't up to your workflow or standards, change it to fit your project. If you think others will like it, fork us and submit a pull request.

from gumby.

Paul Irish is a nice chap. And I use H5BP a lot. But that article you linked to is about production environments.
Just like his jQuery local fallback trick.
Like I already mentioned, all this is not necessary in a development environment.
Unless you are prototyping/designing over a https connection locally or remotely.
The prototype/design phase doesn't require/demand anticipation of http or https. So the //is unnecessary.
Even prototyping/designing of an e-commerce site doesn't require this during the design phase.
Why make your prototyping/designing depend on being online (locally or remote) if you can prototype/design completely offline?
(I even cheat with the VM by using NAT instead of bridged networking in the guest.)

Well I'm going to ask Github staff to delete this issue (if possible at all) because I do not think Gumby deserves a discussion like this. There is nothing wrong with it, other than that it just doesn't fit my workflow out of the box because of disagreements over fundamental things. (Although I managed to make it fit my workflow in my test above.)
These disagreements are over fundamental things (not necessarily in the framework itself) and will be carried forward. I'm not willing to keep fighting them with workarounds.
The reason I was looking to replace Foundation is fighting bugs with workarounds. When all time gained by using a framework, is lost by fighting that same framework with workarounds, it's not for me.

from gumby.

I don't see the problem. Working within file:// kills a lot of stuff, especially ajax. Building a dev environment should be second nature. Also, this type of discussion (if you don't plan on forking and doing some work) is probably better on the G+ page.

from gumby.

@rsadwick What does Ajax have to do with a CSS framework? Show me where in Gumby's (s)css you specify your Ajax calls. What do styling and designing with CSS have to do with Ajax?
CSS is for styling/designing. Why bring up Ajax. And while we're at it, why add a server to a design workflow. It's about the look and layout. Do you let your graphic apps pull fonts from a server while they can be stored locally?
(These questions are all rhetorical. Just in case that you don't get it again.)
You should take your off-topic rambling to the G+ plus page.

And I didn't take the discussion in this direction. I asked a direct question regarding this CSS framework. And it turned out that a decision was made to make a client side technology dependent on server calls. That's one of the disagreements. It's others who found it necessary to make me change my workflow. But it's all about this CSS framework, which can not be said about Ajax, video, and WHY that was brought up in this thread.
Next time better think before trying to come across like your smart.

from gumby.

Hey now, no need for anyone to get nasty. Ryan doesnt work with us, but he had a valid point to add to the conversation. Also, we are a front-end development framework, not just CSS. Gumby is designed to bootstrap applications and websites. We try to cut down the work needed to take a project from prototype to production, one of those things is providing fonts hosted on a super fast CDN. I'm sorry that our visions do not align and that we our efforts to help you resulted in more frustration.bI think we can all agree that its time for this thread to die. Im glad that you've found a solution to your issue, Robert.Good luck on your project!

Sent from my iPad (via Evomail)

On May 29, 2013, at 8:55 PM, "Robertino" wrote:

@rsadwick What does Ajax have to do with a CSS framework? Show me where in Gumby's (s)css you specify your Ajax calls. What do styling and designing with CSS have to do with Ajax?You should take your off-topic rambling to the G+ plus page.
And I didn't take the discussion in this direction. I asked a direct question regarding this CSS framework. And it turned out that a decision was made to make a client side technology dependent on server calls. That's one of the disagreements. It's others who found it necessary to make me change my workflow. But it's all about this CSS framework, which can not be said about Ajax, video, and WHY that was brought up in this thread.
Next time better think before trying to be smart.

—Reply to this email directly or view it on GitHub.

from gumby.

👍 What a joy to see this repo dead. 👍 :]

from gumby.