Open ghost opened 8 years ago
I'd hazard a guess that it's something to do with codepen's environment. Does the title on https://simplaio.github.io/rucksack work for you?
I copied the exact css from Rucksack and applied to my project and its still buggy
The code can be found here: https://github.com/umbriel/stupid-starter
I confirm the weird behaviour in Safari, Safari 10.0.3 on macOS Sierra 10.12.3.
With the default parameters this is the output:
font-size: calc(12px + 9 * ((100vw - 420px) / 860))
After a bit of research I found out that this issue has nothing to do with the plugin itself, just a Safari bug.
You can read more about it here: Viewport Unit Based Typography
TL;DR Safari needs percentages to work. Check this pen: Cross-browser fluid type
Argh. Safari is like the new IE.
Okay, I don't know how we'd fix this in a robust manner - percentage font-sizes are relative to their parent, like em
. So you couldn't just sub out px
and rem
with percentage font-sizes in this plugin and expect it to work. Restraining the supported inputs of this plugin to percentages would be similarly limiting.
What I'd recommend, and I might add this to the README if no better solution presents itself, is to use % inputs with postcss-responsive-type
to set a responsive base on the html
element, and then use rem
units throughout your codebase.
Hopefully this is filed as a bug against webkit somewhere, and isn't just a known difference in their implementation.
I checked also in Safari Technology Preview latest: Release 26 (Safari 10.2, WebKit 12604.1.12). Same issue.
My solution at the end was building this formula. Maybe can help you in restructuring the plugin and make it work also in webkit.
But that would break as soon as you have a font-size defined anywhere up the tree? Ie: regardless what percentage that formula resolved to, it's still relative to its parent:
<div class="foo-one">
<div class="bar">
<div class="foo-two"></div>
</div>
.foo-one, .foo-two {
font-size: 100%
}
.bar {
font-size: 20px
}
foo-one
font-size = 16px
foo-two
font-size = 20px
Anyway, there's also https://github.com/rodneyrehm/viewport-units-buggyfill, though haven't looked into it.
Also, I still can't get a consistent repro - we use postcss-responsive-type
on simpla.io, and that works as expected for me in Safari 10.0.3 on Sierra.
You are correct about breaking as soon as you have a font-size defined anywhere up the tree. Need to update my pen.
Also I can definitely see it working on simpla.io. Let me investigate more.
Well, I built Simpla.io, and we're not doing anything special. Using postcss-responsive-type on the html el (with px values) and rems throughout the rest of the site.
Safari doesn't yet explicitly support viewport units in calc statements (according to caniuse) so my best guess is that they have a half baked implementation that breaks in random use-cases/contexts. But who knows. Maybe it only works at the root of the doc, not when there's anything up the tree? Might make sense considering % works.
In any case, I'd say best 'solution' to this (using the term lightly...) would be to just document that Safari 9+ can be buggy, and suggest the '% on root' trick if you run into problems.
I think that's a good solution for now. Hopefully this will be fixed soon in Safari.
Guys,
I have faced to the the same problem and I've solved with a simple 'line-height: 0vh'.
Try: h1 { font-size: calc(28px + 20 * ((100vw - 320px) / 880)); line-height: 0vh }
Tested only in Safari 10.
Regards.
@julianIFS if that works then it's the world's biggest hack, because I have no idea why setting a line-height would have an effect on a calc statement in font-size, unless it has something to do with how Safari combines declarations into a font
property. Assume this patches with any line-height set, not just '0vh'?
But with Safari anything goes, so if it's a consistent patch (for an inconsistent issue, I still haven't been able to repro in any of my projects using postcss-responsive-type) then I'll document it in the README
¯_(ツ)_/¯
I have been working up fluid font this last few days, and encountered the safari anomaly re non auto scaling. xhtml 1.1
have observed similar anomaly in Safari scaling 'correction' as described by ghost;
Safari scales only on manual refresh, unless line-height;0vw is added ( to html or body in my case)
OSX 12.6 Safari 11.03 Chrome 64 OSX 13.2 Safari 11.02
h1, p, code and table all scale progressively with the calc.
the html { font-size: calc(16px + (24 - 16)*(100vw - 400px)/(800-400)); } works fine in Chrome 64, but requires manual refresh in Safari to reset the scaling, on each viewport change. Works as expected on first load including iPhone 5/ipad mini 2
adding line-height;0 to html makes no diff, Safari scaling is reset only on manual refresh
adding line-height;0vw to html (or body ) and progressive scaling works with dragging the viewport in Safari, just like Chrome
either: html { font-size: calc(14px + (26 - 14) * ((100vw - 300px) / (1600 - 300))); line-height:0vw ; }
or: body { font-size: calc(14px + (26 - 14) * ((100vw - 300px) / (1600 - 300))); line-height:0vw ; }
Not sure if newer version of Safari is supported but when I try the following it doesn't work as intended:
http://codepen.io/umbriel/pen/WwLBxQ
Works fine in Firefox, Chrome and probably other modern browsers. But safari Version 9.0.3 fails entirely as evidenced in the Codepen I linked.
Does anyone have any ideas why this is?
edit: I may have found the culprit, it seems vw in conjunction with calc is the issue from what I tried. Is there a way of making it work?