change size from 99.99% to 99.9% to avoid rounding errors in Edge and IE #296

Closed
wants to merge 1 commit into
from

Conversation

Projects
None yet
4 participants
@dotnetCarpenter
Contributor

dotnetCarpenter commented May 26, 2016

What kind of change is this? (Bug Fix, Feature...)
This fixes #295

What is the current behavior (You can also link to an issue)
#295

What is the new behavior this introduces (if any)
lost_edge_fix
Edge with this patch applied

Does this introduce any breaking changes?
None

Does the PR fulfill these requirements?

  • Tests for the changes have been changed to reflect this change (99.9%)
  • Docs have been added or updated

Can I get a time estimate for merge? I'm nearing a deadline and need to resolve this fast.

@peterramsing

This comment has been minimized.

Show comment
Hide comment
@peterramsing

peterramsing May 26, 2016

Owner

@dotnetCarpenter Thanks for the PR!

I will do some testing in different browsers with this change. I want to make sure it does not cause any issues in other browsers.

@corysimmons Could I get your thoughts on this since you were behind the 99.x percentage? ( #174 )

Pending testing and if Cory has any other thoughts I could see merging by the end of the week. Would you mind giving us a bit more source code to see if there might be an issue up the DOM that might be causing this as I haven't experienced this (yet). 😄

Thanks!

Owner

peterramsing commented May 26, 2016

@dotnetCarpenter Thanks for the PR!

I will do some testing in different browsers with this change. I want to make sure it does not cause any issues in other browsers.

@corysimmons Could I get your thoughts on this since you were behind the 99.x percentage? ( #174 )

Pending testing and if Cory has any other thoughts I could see merging by the end of the week. Would you mind giving us a bit more source code to see if there might be an issue up the DOM that might be causing this as I haven't experienced this (yet). 😄

Thanks!

@dotnetCarpenter

This comment has been minimized.

Show comment
Hide comment
@dotnetCarpenter

dotnetCarpenter May 27, 2016

Contributor

@peterramsing thanks for the quick reply. Here http://firefund.github.io/styleguide/kalei/#/style/blocks/f-footer.css (icons are below the rest of the content) and http://firefund.github.io/styleguide/kalei/#/style/blocks/f-payment-form.css (the radio buttons are below the "Pledge" button) is where we see the bug in Edge and IE11.

f-footer.css

If you open devtools and find f-row__cell-4 inside f-footer and change the width: calc(99.99% * 4/12 - 2.26667rem) to width: calc(99.9% * 4/12 - 2.26667rem) in f-footer.css the icons should be on the most right.

.f-row_12 .f-row__cell-4 {
    -webkit-box-flex: 0;
    -webkit-flex: 0 0 auto;
    -ms-flex: 0 0 auto;
    flex: 0 0 auto;
    width: calc(99.9% * 4/12 - 2.26667rem);
}

f-payment-form.css

If you open devtools and find f-row__cell-7 f-row_not-mobile inside f-payment and change the width: calc(99.99% * 7/12 - 1.41667rem) to width: calc(99.9% * 7/12 - 1.41667rem) in f-payment-form.css the radio buttons should be on the right side of the big arrow.

.f-row_12 .f-row__cell-7 {
    -webkit-box-flex: 0;
    -webkit-flex: 0 0 auto;
    -ms-flex: 0 0 auto;
    flex: 0 0 auto;
    width: calc(99.9% * 7/12 - 1.41667rem);
}
Contributor

dotnetCarpenter commented May 27, 2016

@peterramsing thanks for the quick reply. Here http://firefund.github.io/styleguide/kalei/#/style/blocks/f-footer.css (icons are below the rest of the content) and http://firefund.github.io/styleguide/kalei/#/style/blocks/f-payment-form.css (the radio buttons are below the "Pledge" button) is where we see the bug in Edge and IE11.

f-footer.css

If you open devtools and find f-row__cell-4 inside f-footer and change the width: calc(99.99% * 4/12 - 2.26667rem) to width: calc(99.9% * 4/12 - 2.26667rem) in f-footer.css the icons should be on the most right.

.f-row_12 .f-row__cell-4 {
    -webkit-box-flex: 0;
    -webkit-flex: 0 0 auto;
    -ms-flex: 0 0 auto;
    flex: 0 0 auto;
    width: calc(99.9% * 4/12 - 2.26667rem);
}

f-payment-form.css

If you open devtools and find f-row__cell-7 f-row_not-mobile inside f-payment and change the width: calc(99.99% * 7/12 - 1.41667rem) to width: calc(99.9% * 7/12 - 1.41667rem) in f-payment-form.css the radio buttons should be on the right side of the big arrow.

.f-row_12 .f-row__cell-7 {
    -webkit-box-flex: 0;
    -webkit-flex: 0 0 auto;
    -ms-flex: 0 0 auto;
    flex: 0 0 auto;
    width: calc(99.9% * 7/12 - 1.41667rem);
}
@dotnetCarpenter

This comment has been minimized.

Show comment
Hide comment
@dotnetCarpenter

dotnetCarpenter May 27, 2016

Contributor

The styleguide is WIP but I will freeze it the next few days so you can examine the examples.

Contributor

dotnetCarpenter commented May 27, 2016

The styleguide is WIP but I will freeze it the next few days so you can examine the examples.

@peterramsing

This comment has been minimized.

Show comment
Hide comment
@peterramsing

peterramsing May 28, 2016

Owner

@dotnetCarpenter I do not disagree that this is causing an issue. I just need to ensure that it does not cause any regressions. I'm doing some more testing at the moment in older browsers.

What I can be pretty confident in is creating a global override for this. That way it would be backwards compatible. Thoughts on that?


I'm on holiday right now until Tuesday getting to this in the evenings and can't make any promises on a merge timeline. I'm going to test some more and then experiment with a global setting.

Owner

peterramsing commented May 28, 2016

@dotnetCarpenter I do not disagree that this is causing an issue. I just need to ensure that it does not cause any regressions. I'm doing some more testing at the moment in older browsers.

What I can be pretty confident in is creating a global override for this. That way it would be backwards compatible. Thoughts on that?


I'm on holiday right now until Tuesday getting to this in the evenings and can't make any promises on a merge timeline. I'm going to test some more and then experiment with a global setting.

@peterramsing

This comment has been minimized.

Show comment
Hide comment
@peterramsing

peterramsing May 28, 2016

Owner

@dotnetCarpenter What is odd is that in my typical test cases I am not experiencing this issue in Edge. So thank you for finding an edge case. Oh frontend development! 😄

Owner

peterramsing commented May 28, 2016

@dotnetCarpenter What is odd is that in my typical test cases I am not experiencing this issue in Edge. So thank you for finding an edge case. Oh frontend development! 😄

@dotnetCarpenter

This comment has been minimized.

Show comment
Hide comment
@dotnetCarpenter

dotnetCarpenter May 28, 2016

Contributor

I understand your reason for precaution but I personally really don't think we need a global override. Having set the value to 99.99% gives the browser 0.01% room for rounding numbers - eventually this will be a calculated px value.

This is fine if you don't work with scaled design. In this instance, we're using rem as unit and changing the html font-size to create a design that looks identical on tablets and desktops.
In the case of Edge and IE, 0.01% is too little.

Let's say we have a 12 column grid. Each column is 99.99% wide. There is potentially 12 places where the browser needs to calculate a px value for each width. We set the width to 99.99% so that there is a 0.01% stronger possibility for getting a total value at exactly 100% or below
.
We then have a gutter, lets say 20px. It still doesn't change our rounding total because the gutter doesn't change the calculation.
But we're using a variable gutter, lets say 2rem. There is now up to 12 + 11 calculations that together, within a window of 0.01%, most be exactly 100% or below.

By changing the value to 99.9%, the browser has a 0.1% window to get a px value that is actually below or equal to 100%.

So you won't see the issue in simple cases. You need to have many units calculated by the browser, in a tight design, before you see an error.

Since we're changing all of lost widths to 99.9%, everything will be harmonized to
the same px values. We're talking about a difference of ~1px.

Lets play with real numbers to illustrate. A 1200px viewport, with a 12 column grid.
We insert 3 different blocks, lost-column: 2/12, lost-column: 4/12 and lost-offset: -2/12, named
c2, c4 and o2. We set the gutter to @lost gutter 3.4rem;, which is 54.4px
(1rem== 16px).

<div class="c2"></div>
<div class="c4"></div>
<div class="c2"></div>
<div class="c2 o2"></div>

In Edge the numbers are:

.c2 {
  width: 154.7px;
  margin-right: 54.4px;
}
.c4 {
  width: 363.8px;
  margin-right: 54.4px;
}
.o2 {
  width: 154.7px;
  margin-left: 209.14px; 
  margin-right: 0;
}

In total: 1200.24px
0.24px too wide! Layout breaks in Edge

In Chrome the numbers are:

.c2 {
  width: 154.641px;
  margin-right: 54.4px;
}
.c4 {
  width: 363.688px;
  margin-right: 54.4px;
}
.o2 {
  width: 154.641px;
  margin-left: 209.047px;
  margin-right: 0;
}

In total: 1199.858px
0.142px below 100%

If we then change lost to use 99.9%, then Edge is fine.

In Edge the numbers are:

.c2 {
  width: 154.52px;
  margin-right: 54.4px;
}
.c4 {
  width: 363.44px;
  margin-right: 54.4px;
}
.o2 {
  width: 154.52px;
  margin-left: 208.96px; 
  margin-right: 0;
}

In total: 1199.16px
0.84px below 100%. Yes!

In Chrome the numbers are:

.c2 {
  width: 154.453px;
  margin-right: 54.4px;
}
.c4 {
  width: 363.328px;
  margin-right: 54.4px;
}
.o2 {
  width: 154.453px;
  margin-left: 208.859px;
  margin-right: 0;
}

In total: 1198.746px
1.254px below 100%

So lets add scaling to the mix and revert to 99.99%. We set html { font-size: 62.5%; } which
change 1rem to mean 10px in a standard browser. We have set the font-size to be 62.5%
of 16px and our gutter to be 3.4rem of 62.5% * 16 == 3.4 * 10 == 34px.
The numbers from before is now a bit smaller.

In Edge the numbers are:

.c2 {
  width: 171.68px;
  margin-right: 34px;
}
.c4 {
  width: 377.36px;
  margin-right: 34px;
}
.o2 {
  width: 171.68px;
  margin-left: 205.72px; 
  margin-right: 0;
}

In total: 1203.12px
3.12px above 100%! Layout breaks in Edge

In Chrome the numbers are:

.c2 {
  width: 171.641px;
  margin-right: 34px;
}
.c4 {
  width: 377.281px;
  margin-right: 34px;
}
.o2 {
  width: 171.641px;
  margin-left: 205.641px;
  margin-right: 0;
}

In total: 1202.845px
2.845px above 100% wait - WAT! Turns out that chrome round to 13 decimal places.
Even though this should be way off - Chrome magically does the sensible thing and fit
child elements it their container. Not sure that the 13 decimal rounding is the reason why this is not a problem, but I've tested both the float and flexbox version of lost and it doesn't break. An alternative explanation is that Chrome DevTools are lying about the numbers.

Ref: http://cruft.io/posts/percentage-calculations-in-ie/

Let's scale everything by changing the viewport to 700px with 99.99% as base width in
our calculations in lost. Now both gutter and widths will be re-calculated by the
browser when the viewport change size, because we set the font-size
on the html to 1vw in a media query with (max-width: 1000px) so that
viewports bigger than 1000px get 1rem == 10px, like before but viewports below will
get a scaled value where 1% of the viewport in 1000px == 10px. In viewport width 700px
== 7px etc.

Ref: https://www.w3.org/TR/css3-values/#viewport-relative-lengths

In Edge the numbers are:

.c2 {
  width: 96.1px;
  margin-right: 24.7px;
}
.c4 {
  width: 216.89px;
  margin-right: 24.7px;
}
.o2 {
  width: 96.1x;
  margin-left: 120.82px; 
  margin-right: 0;
}

In total: 700.11px
0.11px above 100%. Layout breaks in Edge

In Chrome the numbers are:

.c2 {
  width: 95.875px;
  margin-right: 24.922px;
}
.c4 {
  width: 216.688px;
  margin-right: 24.922px;
}
.o2 {
  width: 95.875px;
  margin-left: 120.797px;
  margin-right: 0;
}

In total: 699.876px
0.124px below 100%

If we apply this patch we'll get the following numbers:

Edge:           699.46px       0.54px below 100%    <- Layout is fine in Edge
Chrome:         699.876px      0.124px below 100% <- notice, no change at all with 99.9%

I think I have shown that:

  1. The difference between 99.99% and 99.9% is less than 1px in most cases.
  2. You will notice the biggest change when dealing with huge sizes. Not small compact designs.
  3. Chrome somehow gracefully handle sizes that breaks layout in Edge.
  4. Since all grids made in lost will be harmonized
    (e.i. all grids will proportional be the exact same as before this patch) there is little
    to no risk of users noticing this. Sub-pixel rendering can affect thin lines but this patch
    does not introduce such issue, as it is always the risk with a percentage design.

Ref: http://firefund.github.io/styleguide/kalei/grid.html

Contributor

dotnetCarpenter commented May 28, 2016

I understand your reason for precaution but I personally really don't think we need a global override. Having set the value to 99.99% gives the browser 0.01% room for rounding numbers - eventually this will be a calculated px value.

This is fine if you don't work with scaled design. In this instance, we're using rem as unit and changing the html font-size to create a design that looks identical on tablets and desktops.
In the case of Edge and IE, 0.01% is too little.

Let's say we have a 12 column grid. Each column is 99.99% wide. There is potentially 12 places where the browser needs to calculate a px value for each width. We set the width to 99.99% so that there is a 0.01% stronger possibility for getting a total value at exactly 100% or below
.
We then have a gutter, lets say 20px. It still doesn't change our rounding total because the gutter doesn't change the calculation.
But we're using a variable gutter, lets say 2rem. There is now up to 12 + 11 calculations that together, within a window of 0.01%, most be exactly 100% or below.

By changing the value to 99.9%, the browser has a 0.1% window to get a px value that is actually below or equal to 100%.

So you won't see the issue in simple cases. You need to have many units calculated by the browser, in a tight design, before you see an error.

Since we're changing all of lost widths to 99.9%, everything will be harmonized to
the same px values. We're talking about a difference of ~1px.

Lets play with real numbers to illustrate. A 1200px viewport, with a 12 column grid.
We insert 3 different blocks, lost-column: 2/12, lost-column: 4/12 and lost-offset: -2/12, named
c2, c4 and o2. We set the gutter to @lost gutter 3.4rem;, which is 54.4px
(1rem== 16px).

<div class="c2"></div>
<div class="c4"></div>
<div class="c2"></div>
<div class="c2 o2"></div>

In Edge the numbers are:

.c2 {
  width: 154.7px;
  margin-right: 54.4px;
}
.c4 {
  width: 363.8px;
  margin-right: 54.4px;
}
.o2 {
  width: 154.7px;
  margin-left: 209.14px; 
  margin-right: 0;
}

In total: 1200.24px
0.24px too wide! Layout breaks in Edge

In Chrome the numbers are:

.c2 {
  width: 154.641px;
  margin-right: 54.4px;
}
.c4 {
  width: 363.688px;
  margin-right: 54.4px;
}
.o2 {
  width: 154.641px;
  margin-left: 209.047px;
  margin-right: 0;
}

In total: 1199.858px
0.142px below 100%

If we then change lost to use 99.9%, then Edge is fine.

In Edge the numbers are:

.c2 {
  width: 154.52px;
  margin-right: 54.4px;
}
.c4 {
  width: 363.44px;
  margin-right: 54.4px;
}
.o2 {
  width: 154.52px;
  margin-left: 208.96px; 
  margin-right: 0;
}

In total: 1199.16px
0.84px below 100%. Yes!

In Chrome the numbers are:

.c2 {
  width: 154.453px;
  margin-right: 54.4px;
}
.c4 {
  width: 363.328px;
  margin-right: 54.4px;
}
.o2 {
  width: 154.453px;
  margin-left: 208.859px;
  margin-right: 0;
}

In total: 1198.746px
1.254px below 100%

So lets add scaling to the mix and revert to 99.99%. We set html { font-size: 62.5%; } which
change 1rem to mean 10px in a standard browser. We have set the font-size to be 62.5%
of 16px and our gutter to be 3.4rem of 62.5% * 16 == 3.4 * 10 == 34px.
The numbers from before is now a bit smaller.

In Edge the numbers are:

.c2 {
  width: 171.68px;
  margin-right: 34px;
}
.c4 {
  width: 377.36px;
  margin-right: 34px;
}
.o2 {
  width: 171.68px;
  margin-left: 205.72px; 
  margin-right: 0;
}

In total: 1203.12px
3.12px above 100%! Layout breaks in Edge

In Chrome the numbers are:

.c2 {
  width: 171.641px;
  margin-right: 34px;
}
.c4 {
  width: 377.281px;
  margin-right: 34px;
}
.o2 {
  width: 171.641px;
  margin-left: 205.641px;
  margin-right: 0;
}

In total: 1202.845px
2.845px above 100% wait - WAT! Turns out that chrome round to 13 decimal places.
Even though this should be way off - Chrome magically does the sensible thing and fit
child elements it their container. Not sure that the 13 decimal rounding is the reason why this is not a problem, but I've tested both the float and flexbox version of lost and it doesn't break. An alternative explanation is that Chrome DevTools are lying about the numbers.

Ref: http://cruft.io/posts/percentage-calculations-in-ie/

Let's scale everything by changing the viewport to 700px with 99.99% as base width in
our calculations in lost. Now both gutter and widths will be re-calculated by the
browser when the viewport change size, because we set the font-size
on the html to 1vw in a media query with (max-width: 1000px) so that
viewports bigger than 1000px get 1rem == 10px, like before but viewports below will
get a scaled value where 1% of the viewport in 1000px == 10px. In viewport width 700px
== 7px etc.

Ref: https://www.w3.org/TR/css3-values/#viewport-relative-lengths

In Edge the numbers are:

.c2 {
  width: 96.1px;
  margin-right: 24.7px;
}
.c4 {
  width: 216.89px;
  margin-right: 24.7px;
}
.o2 {
  width: 96.1x;
  margin-left: 120.82px; 
  margin-right: 0;
}

In total: 700.11px
0.11px above 100%. Layout breaks in Edge

In Chrome the numbers are:

.c2 {
  width: 95.875px;
  margin-right: 24.922px;
}
.c4 {
  width: 216.688px;
  margin-right: 24.922px;
}
.o2 {
  width: 95.875px;
  margin-left: 120.797px;
  margin-right: 0;
}

In total: 699.876px
0.124px below 100%

If we apply this patch we'll get the following numbers:

Edge:           699.46px       0.54px below 100%    <- Layout is fine in Edge
Chrome:         699.876px      0.124px below 100% <- notice, no change at all with 99.9%

I think I have shown that:

  1. The difference between 99.99% and 99.9% is less than 1px in most cases.
  2. You will notice the biggest change when dealing with huge sizes. Not small compact designs.
  3. Chrome somehow gracefully handle sizes that breaks layout in Edge.
  4. Since all grids made in lost will be harmonized
    (e.i. all grids will proportional be the exact same as before this patch) there is little
    to no risk of users noticing this. Sub-pixel rendering can affect thin lines but this patch
    does not introduce such issue, as it is always the risk with a percentage design.

Ref: http://firefund.github.io/styleguide/kalei/grid.html

@corysimmons

This comment has been minimized.

Show comment
Hide comment
@corysimmons

corysimmons May 30, 2016

Contributor

@peterramsing Sorry, I was on vacation and kinda digital detox.

Lgtm. 👍

Seems like he did the math whereas I just eyeballed all the browsers (well, not IE11 and Edge apparently) until things looked right. :D

Contributor

corysimmons commented May 30, 2016

@peterramsing Sorry, I was on vacation and kinda digital detox.

Lgtm. 👍

Seems like he did the math whereas I just eyeballed all the browsers (well, not IE11 and Edge apparently) until things looked right. :D

@peterramsing

This comment has been minimized.

Show comment
Hide comment
@peterramsing

peterramsing May 30, 2016

Owner

@corysimmons Thanks for the input. @dotnetCarpenter I don't disagree with anything you said. I also agree that this causes no issues with current browsers and I want to ensure that is the it doesn't break older browsers. I know I know...that's what semver is for but I want to go slow especially when I'm on holiday and glancing at this here and there.

What I'm thinking, especially since I agree with this PR and @corysimmons's notes that the original rounding was eyeballed, I propose we get an 8.0.0 7.0.0 here shortly.

Owner

peterramsing commented May 30, 2016

@corysimmons Thanks for the input. @dotnetCarpenter I don't disagree with anything you said. I also agree that this causes no issues with current browsers and I want to ensure that is the it doesn't break older browsers. I know I know...that's what semver is for but I want to go slow especially when I'm on holiday and glancing at this here and there.

What I'm thinking, especially since I agree with this PR and @corysimmons's notes that the original rounding was eyeballed, I propose we get an 8.0.0 7.0.0 here shortly.

@dotnetCarpenter

This comment has been minimized.

Show comment
Hide comment
@dotnetCarpenter

dotnetCarpenter May 31, 2016

Contributor

@peterramsing Since you're talking about a new major release. I have one situation where I need to reverse lost-column. Perhaps we could squeeze in a reverse option in lost, when used with the flexbox implementation (perhaps also with the float implementation but that is not my primary goal)?

Right now I got this hacky solution:

/* f-row_reverse is implemented extremely hacky to override *lost* margins */
.f-row_reverse {
    flex-direction: row-reverse;
}
.f-row_reverse [class^="f-row__cell"],
.f-row_reverse [class*="f-row__cell"] {
    margin-left: var(--gutter-width, 3.4rem)!important;
    margin-right: 0!important;
}
.f-row_reverse [class^="f-row__cell"]:last-child,
.f-row_reverse [class*="f-row__cell"]:last-child {
    margin-left: 0!important;
}
.f-row_reverse [class^="f-row__cell"]:first-child,
.f-row_reverse [class*="f-row__cell"]:first-child {
    margin-right: 0!important;
}
Contributor

dotnetCarpenter commented May 31, 2016

@peterramsing Since you're talking about a new major release. I have one situation where I need to reverse lost-column. Perhaps we could squeeze in a reverse option in lost, when used with the flexbox implementation (perhaps also with the float implementation but that is not my primary goal)?

Right now I got this hacky solution:

/* f-row_reverse is implemented extremely hacky to override *lost* margins */
.f-row_reverse {
    flex-direction: row-reverse;
}
.f-row_reverse [class^="f-row__cell"],
.f-row_reverse [class*="f-row__cell"] {
    margin-left: var(--gutter-width, 3.4rem)!important;
    margin-right: 0!important;
}
.f-row_reverse [class^="f-row__cell"]:last-child,
.f-row_reverse [class*="f-row__cell"]:last-child {
    margin-left: 0!important;
}
.f-row_reverse [class^="f-row__cell"]:first-child,
.f-row_reverse [class*="f-row__cell"]:first-child {
    margin-right: 0!important;
}
@peterramsing

This comment has been minimized.

Show comment
Hide comment
@peterramsing

peterramsing May 31, 2016

Owner

@dotnetCarpenter I think it's best to do a major release as it could be a breaking change. There is also another breaking change in the queue so this might be the best time to do it.

As for this new feature of reverse: that seems like something worthwhile and let's get a new issue going and ensure we have a good understanding of the value-add. For every line/feature we add the more we have to maintain. 😄 This doesn't need to be in a major release as it wouldn't cause any breaking changes.

Thanks for the work!

One final thing for this PR. I unchecked the updated docs as the Getting Started needs a minor update.

I'll begin laying out a beta release for 8.0.0 7.0.0 and process it some more.

Owner

peterramsing commented May 31, 2016

@dotnetCarpenter I think it's best to do a major release as it could be a breaking change. There is also another breaking change in the queue so this might be the best time to do it.

As for this new feature of reverse: that seems like something worthwhile and let's get a new issue going and ensure we have a good understanding of the value-add. For every line/feature we add the more we have to maintain. 😄 This doesn't need to be in a major release as it wouldn't cause any breaking changes.

Thanks for the work!

One final thing for this PR. I unchecked the updated docs as the Getting Started needs a minor update.

I'll begin laying out a beta release for 8.0.0 7.0.0 and process it some more.

@peterramsing

This comment has been minimized.

Show comment
Hide comment
@peterramsing

peterramsing May 31, 2016

Owner

...and by 8.0.0 I meant 7.0.0. ...not fully back from holiday! 😉

Owner

peterramsing commented May 31, 2016

...and by 8.0.0 I meant 7.0.0. ...not fully back from holiday! 😉

@peterramsing

This comment has been minimized.

Show comment
Hide comment
@peterramsing

peterramsing May 31, 2016

Owner

For funsies...this was the idea for backwards compatibility that I was playing with before the others on our weekend adventures woke up yesterday morning.

a47ebba

Owner

peterramsing commented May 31, 2016

For funsies...this was the idea for backwards compatibility that I was playing with before the others on our weekend adventures woke up yesterday morning.

a47ebba

@custa1200

This comment has been minimized.

Show comment
Hide comment
@custa1200

custa1200 May 31, 2016

Could it be exposed as a setting of to decimal places?

Sent from my iPhone

On 31 May 2016, at 10:42 AM, Peter Ramsing notifications@github.com wrote:

...and by 8.0.0 I meant 7.0.0. ...not fully back from holiday! 😉


You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

Could it be exposed as a setting of to decimal places?

Sent from my iPhone

On 31 May 2016, at 10:42 AM, Peter Ramsing notifications@github.com wrote:

...and by 8.0.0 I meant 7.0.0. ...not fully back from holiday! 😉


You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

@peterramsing

This comment has been minimized.

Show comment
Hide comment
@peterramsing

peterramsing May 31, 2016

Owner

@custa1200 are you seeing this change possibly causing larger issues that would warrant this needing a parameter?

Pending browser testing and if it breaks in older versions of IE this still might be an option. My hope after hearing what Cory had to say is that this fix is not a breaking change. If this needs to be a parameter then so-be-it but adding complexity should be only done out of necessity.

Owner

peterramsing commented May 31, 2016

@custa1200 are you seeing this change possibly causing larger issues that would warrant this needing a parameter?

Pending browser testing and if it breaks in older versions of IE this still might be an option. My hope after hearing what Cory had to say is that this fix is not a breaking change. If this needs to be a parameter then so-be-it but adding complexity should be only done out of necessity.

@peterramsing

This comment has been minimized.

Show comment
Hide comment
@peterramsing

peterramsing May 31, 2016

Owner

@dotnetCarpenter Could you create a new PR and reference this PR? Point the new PR to the beta branch and I'll merge this in.

Thanks!

Owner

peterramsing commented May 31, 2016

@dotnetCarpenter Could you create a new PR and reference this PR? Point the new PR to the beta branch and I'll merge this in.

Thanks!

@@ -70,7 +70,7 @@ And the processed CSS looks like this:
```css
div {
- width: calc(99.99% * 1/3 - (30px - 30px * 1/3));
+ width: calc(99.9% * 1/3 - (30px - 30px * 1/3));

This comment has been minimized.

@dotnetCarpenter

dotnetCarpenter May 31, 2016

Contributor

Getting Started is changed in the README

@dotnetCarpenter

dotnetCarpenter May 31, 2016

Contributor

Getting Started is changed in the README

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment