Menu icon Foundation

Coder | Milton Keynes, United Kingdom

My Posts

  • 12
    Replies
  • Breakpoint pixel gap

    By Peter Gibb

    breakpoint

    I was testing an element where there's no global style and styling only applies within specific breakpoints that there's a 1px gap between breakpoints. From _settings.scss $medium-range: (40.063em, 64em); /* 641px, 1024px */ $large-range: (64.063e... (continued)

    Last Reply by Steven Leimberg over 3 years ago




My Comments

Peter Gibb commented on Jason kalawe's post almost 4 years

Thanks @Rafi Benkual. Do you have an idea of timescale for when this will be available?

Peter Gibb commented on Peter Gibb's post over 4 years

The rounding issue doesn't seem to be a problem in Chrome 41 but sounds like it may be back in Chrome 42.

We've implemented the range definitions to 4 decimal places and that seems to be working with no ill effects on Chrome or any other browsers.

Thanks for your help.

Peter Gibb commented on Peter Gibb's post over 4 years

Thanks Rafi. My original question was simply if there's a reason why we can't / shouldn't define the range in ems to 4 decimal places as this gives the exact value and takes rounding issues out of the equation. This seems to work but I didn't know if there was some greater reason why it should be avoided.

Thanks

Peter Gibb commented on Peter Gibb's post over 4 years

Hi Rafi,

By way of an update, I can confirm that cross-browser testing has shown this to be an issue specific to Google Chrome 40. Other browsers seem to be fine, and indeed Chrome 39, but Chrome 40 in both OS X and Windows exhibits this problem.

Thanks,

Peter

Peter Gibb commented on Peter Gibb's post almost 5 years

I've stripped the rest of the page out to isolate the issue.

The issue can be seen at 961px (1px above the upper-bound for the medium breakpoint on our site).

This file is built using the native lower-bound breakpoints of .063em
http://demo.icaew.com/peter-gibb/breakpoint-pixel/60-063em.html

With this file at 961px, neither the medium or large breakpoint media queries apply.

Changing the lower-bound breakpoint settings to 0.625em (60.0625em x 16px = 961px) results in this file:
http://demo.icaew.com/peter-gibb/breakpoint-pixel/60-0625em.html

With lower-bound breakpoint settings changed to 0.62em also seems to work though the maths aren't quite so clean (60.062em x 16px = 960.992px
http://demo.icaew.com/peter-gibb/breakpoint-pixel/60-062em.html

This is the only scenario I've seen the issue in, but it does make me wonder if there are going to be other problems in these 1px crossover areas.

Peter Gibb commented on B C's post almost 5 years

Any progress with this? I'm trying to do something that combines B C's original query about a second dropdown (one for nav and one for account links) and a search dropdown like Joe Windeknecht's.

Peter Gibb commented on Nick Caldwell's post almost 6 years

Really surprised and disappointed to see how the accordion component is marked up. It fails W3C HTML validation which really makes it unusable - if we're willing to deploy markup like this we might as well go back to using FrontPage.

Can Zurb not offer some valid markup which still binds into functionality of the component?

Peter Gibb commented on Neil Mastroianni's post almost 6 years

I was having a similar issue trying to use data-interchange to swap between a top-bar based small/medium mobile menu and a large-up desktop mega menu.

The sub-menus on the mobile version didn't work (height was limited to initial size and no back link). In console it was reporting:

Uncaught TypeError: Cannot read property 'scrolltop' of undefined foundation.topbar.js:93
Foundation.libs.topbar.toggle foundation.topbar.js:93
(anonymous function) foundation.topbar.js:137
x.event.dispatch jquery.js:4676
y.handle jquery.js:4360

Using Alan Smithee's link however solved my problem by adding

$("#mega-menu").on("replace", function() {
$(document).foundation();
});
 

where id="mega-menu" is the element with the data-interchange.

Thanks.

Peter Gibb commented on Peter Gibb's post almost 6 years

I've managed to resolve this to install and compile Foundation 5 on Windows from behind a corporate firewall. The issue was a combination of Git and Ruby install options and a closed Git port 8419.

For anyone else with no prior Ruby or Git experience, here's what worked for me:

Zurb Foundation 5 - SASS Windows installation

INSTALLING GIT

Check if you have GIT installed by opening CMD.EXE and entering:

git —version

If GIT is not installed, go to http://git-scm.com/downloads, download and install it.

Ensure when installing GIT that you select the checkbox to run GIT from the Windows command prompt.

Select Checkout as-is, commit as-is option for line endings.

INSTALLING RUBY

Make sure you have Ruby 1.9+ installed (v2.0 has been installed in working tests)

In CMD.EXE, type:

ruby —version

If this returns less than ruby 1.9 or isn’t found, go to http://rubyinstaller.org/downloads and download the appropriate version of RubyInstaller

When installing Ruby, make sure you select the option to Add Ruby executables to your PATH

INSTALLING NODEJS

Make sure you have NodeJS installed
In CMD.EXE type:

node —version

If this isn’t found, go to http://nodejs.org/download and download the appropriate installer.

CONFIGURING FOUNDATION INSTALLATION

In CMD.EXE, to work around the closed Proxy GIT port (8419) enter:

git config --global url."https://".insteadOf git://

In CMD.EXE enter:
npm install -g bower grunt-cli

In CMD.EXE enter:
gem install foundation

In CMD.EXE go to the working area where you want to create your project.
Create the project by typing:

foundation new PROJECT-NAME

Peter Gibb commented on Peter Gibb's post almost 6 years

After investigation, I think the problem may be related to the installation of GIT on Windows.

In the scss folder, if alongside the app.scss and _settings.scss files, I create an empty _foundation.scss file, the project compiles (It's empty, but it at least compiles). This would seem to point to the configuration being the issue in that the _foundatuon.scss file in bower_components isn't being picked up.

What's not clear is that if GIT, Ruby or NodeJS need to be installed with anything other than the default settings, what the settings need to be.

Posts Followed


Following

    No Content

Followers

My Posts

My Comments

You commented on Jason kalawe's post almost 4 years

Thanks @Rafi Benkual. Do you have an idea of timescale for when this will be available?

You commented on Peter Gibb's post over 4 years

The rounding issue doesn't seem to be a problem in Chrome 41 but sounds like it may be back in Chrome 42.

We've implemented the range definitions to 4 decimal places and that seems to be working with no ill effects on Chrome or any other browsers.

Thanks for your help.

You commented on Peter Gibb's post over 4 years

Thanks Rafi. My original question was simply if there's a reason why we can't / shouldn't define the range in ems to 4 decimal places as this gives the exact value and takes rounding issues out of the equation. This seems to work but I didn't know if there was some greater reason why it should be avoided.

Thanks

You commented on Peter Gibb's post over 4 years

Hi Rafi,

By way of an update, I can confirm that cross-browser testing has shown this to be an issue specific to Google Chrome 40. Other browsers seem to be fine, and indeed Chrome 39, but Chrome 40 in both OS X and Windows exhibits this problem.

Thanks,

Peter

You commented on Peter Gibb's post almost 5 years

I've stripped the rest of the page out to isolate the issue.

The issue can be seen at 961px (1px above the upper-bound for the medium breakpoint on our site).

This file is built using the native lower-bound breakpoints of .063em
http://demo.icaew.com/peter-gibb/breakpoint-pixel/60-063em.html

With this file at 961px, neither the medium or large breakpoint media queries apply.

Changing the lower-bound breakpoint settings to 0.625em (60.0625em x 16px = 961px) results in this file:
http://demo.icaew.com/peter-gibb/breakpoint-pixel/60-0625em.html

With lower-bound breakpoint settings changed to 0.62em also seems to work though the maths aren't quite so clean (60.062em x 16px = 960.992px
http://demo.icaew.com/peter-gibb/breakpoint-pixel/60-062em.html

This is the only scenario I've seen the issue in, but it does make me wonder if there are going to be other problems in these 1px crossover areas.

You commented on B C's post almost 5 years

Any progress with this? I'm trying to do something that combines B C's original query about a second dropdown (one for nav and one for account links) and a search dropdown like Joe Windeknecht's.

You commented on Nick Caldwell's post almost 6 years

Really surprised and disappointed to see how the accordion component is marked up. It fails W3C HTML validation which really makes it unusable - if we're willing to deploy markup like this we might as well go back to using FrontPage.

Can Zurb not offer some valid markup which still binds into functionality of the component?

You commented on Neil Mastroianni's post almost 6 years

I was having a similar issue trying to use data-interchange to swap between a top-bar based small/medium mobile menu and a large-up desktop mega menu.

The sub-menus on the mobile version didn't work (height was limited to initial size and no back link). In console it was reporting:

Uncaught TypeError: Cannot read property 'scrolltop' of undefined foundation.topbar.js:93
Foundation.libs.topbar.toggle foundation.topbar.js:93
(anonymous function) foundation.topbar.js:137
x.event.dispatch jquery.js:4676
y.handle jquery.js:4360

Using Alan Smithee's link however solved my problem by adding

$("#mega-menu").on("replace", function() {
$(document).foundation();
});
 

where id="mega-menu" is the element with the data-interchange.

Thanks.

You commented on Peter Gibb's post almost 6 years

I've managed to resolve this to install and compile Foundation 5 on Windows from behind a corporate firewall. The issue was a combination of Git and Ruby install options and a closed Git port 8419.

For anyone else with no prior Ruby or Git experience, here's what worked for me:

Zurb Foundation 5 - SASS Windows installation

INSTALLING GIT

Check if you have GIT installed by opening CMD.EXE and entering:

git —version

If GIT is not installed, go to http://git-scm.com/downloads, download and install it.

Ensure when installing GIT that you select the checkbox to run GIT from the Windows command prompt.

Select Checkout as-is, commit as-is option for line endings.

INSTALLING RUBY

Make sure you have Ruby 1.9+ installed (v2.0 has been installed in working tests)

In CMD.EXE, type:

ruby —version

If this returns less than ruby 1.9 or isn’t found, go to http://rubyinstaller.org/downloads and download the appropriate version of RubyInstaller

When installing Ruby, make sure you select the option to Add Ruby executables to your PATH

INSTALLING NODEJS

Make sure you have NodeJS installed
In CMD.EXE type:

node —version

If this isn’t found, go to http://nodejs.org/download and download the appropriate installer.

CONFIGURING FOUNDATION INSTALLATION

In CMD.EXE, to work around the closed Proxy GIT port (8419) enter:

git config --global url."https://".insteadOf git://

In CMD.EXE enter:
npm install -g bower grunt-cli

In CMD.EXE enter:
gem install foundation

In CMD.EXE go to the working area where you want to create your project.
Create the project by typing:

foundation new PROJECT-NAME

You commented on Peter Gibb's post almost 6 years

After investigation, I think the problem may be related to the installation of GIT on Windows.

In the scss folder, if alongside the app.scss and _settings.scss files, I create an empty _foundation.scss file, the project compiles (It's empty, but it at least compiles). This would seem to point to the configuration being the issue in that the _foundatuon.scss file in bower_components isn't being picked up.

What's not clear is that if GIT, Ruby or NodeJS need to be installed with anything other than the default settings, what the settings need to be.

Posts Followed


Following

  • No Content

Followers

  • No Content