Approaching the limit of CSS transform scale - css

For my project areallybigpage.com (*), I'm trying to see how far we can with CSS' transform: scale(...).
This works and displays the text at normal size:
#id1 { position: absolute; transform-origin: 0 0; transform: scale(10000); }
#id2 { position: absolute; transform-origin: 0 0; transform: scale(0.0001);}
<div id="id2"><div id="id1">Bonjour</div></div>
But this seems to be too much and doesn't display anything anymore (tested Firefox 32.0/Win7, laptop computer/few hardware acceleration):
#id1 { position: absolute; transform-origin: 0 0; transform: scale(100000); }
#id2 { position: absolute; transform-origin: 0 0; transform: scale(0.00001);}
<div id="id2"><div id="id1">Bonjour</div></div>
Is there a limit of scale with CSS3 transform: scale(...) ?
How can we push this limit further?
(*) : I currently don't use transform: scale(...) on this page, because of the limitation described in this question, but I would like to use it in a future version of this website.
Off-topic: if you zoom far enough with PgUp, you easily get to the 1.79e+308 float limit problem. (but this is another problem)

Actually it seems that in your test, at least for firefox* the maximum height in CSS px is an issue.
*(In chrome the maximum scale() multiplier/divider seems to be 10000)
If you add a third div with a fixed position, and you set your divs to this maximum CSSpx you can see that the higher the multiplier/divider is, the smaller the inner divs are :
s=150000;
document.getElementById('p').addEventListener('click', function(){
s*=1.1; doit();}, false);
document.getElementById('m').addEventListener('click', function(){
s/=1.1; doit();}, false);
function doit(){
document.getElementById('id2').style.transform = 'scale('+1/s+')';
document.getElementById('id1').style.transform = 'scale('+s+')';
document.getElementById('r').innerHTML = s;
}
#id1 { transform-origin: 0 0; transform: scale(1); width:17895697px; height: 17895697px; background:#AA00AA;}
#id2 {transform-origin: 0 0; transform: scale(1); width: 17895697px; height: 17895697px; background:#00AA00; }
#id3 { position: absolute; height: 100%; width: 100%;background:#AFAFAF;}
#p {position: fixed; top: 3em;}
#m {position: fixed; top: 3em; left: 3em;}
#r {position: fixed; top: 4em;}
<div id="id3"><div id="id2"><div id="id1">Bonjour</div></div></div>
<button id="p">+</button><button id="m">-</button><p id="r"></p>
Check this answer for more details : https://stackoverflow.com/a/24748165/3702797.
If we take the test case in the other way (container multiplies then contained divides), I can go to a multiplier of 10000 in chrome and 64424503296.0000038... in FF :
Chrome
#id1 { transform: scale(10000); width: 33554428px; height: 33554428px; background: #AA00AA; }
#id2 { transform: scale(0.0001); width: 33554428px; height: 33554428px; background: #00AA00; }
Firefox
#id1 { transform: scale(10000); width: 17895697px; height: 17895697px; background:#AA00AA; }
#id2 { transform: scale(0.0001); width: 17895697px; height: 17895697px; background:#00AA00; }
Chrome Fiddle Firefox fiddle
Edit
This does mean that for firefox, the maximum scale() multiplier is equal to the maximum browser CSS height/width / element height/width. If your calculated element's height/width exceeds this limit, then your element won't be scaled anymore.
r.textContent = document.getElementById('id2').getBoundingClientRect().width +" instead of 1px*20.000.000";
#id2 {
transform: scale(2e+7);
width: 1px;
height: 1px;
background: #00AA00;
}
#id3 {
height: 100%;
width: 100%;
background: #AFAFAF;
}
#r {
position: fixed;
}
<div id="id3"> <div id="id2"></div> </div>
<p id="r"></p>
Chrome doesn't seem to be limited in such a way however…

I don't believe it to be an issue with browsers, but more to do with the PC you're running it on.
Hardware acceleration/graphics acceleration would play a big part in how your page is displayed, and so you may need to factor this into your 'page'.
Many of you probably already know about this but for the rest, here's a quick tip that you might find useful.
Quick tip: If you use Chrome or Chromium browsers and hardware acceleration is disabled for your graphics card, you can try to
force it to get better video playback performance (for instance on
YouTube) as well as support for features such as the 3D Earth view in
the new Google Maps.
To check if your Chrome / Chromium browser uses hardware acceleration,
open a new tab, type: "chrome://gpu" (without the quotes) and look
under "Graphics Feature status" - all (or at least most of) the
features should say "hardware accelerated". see more...
You graphics card also plays a huge role in speed of rendering/etc, and so I wouldn't completely steer clear of use of the transform: scale(...), but would mention to any visitors that 'for best results, allow hardware acceleration and ensure your graphics drivers are up-to-date...'
But realistically, do you need this ability? Could you not use a different approach? (i.e. if you were using this idea to 'generate a background effect', for example, could you not use svg/pseudo effects/etc?).
In conclusion, I don't believe this is a bug, but I think it would be a way of seeing 'who's got the better hardware acceleration'/'graphics ability' with their browser/pc combination.
Further Reading
unleash the power of Hardware-Accelerated HTML5 Canvas
How to enable or disable software rendering in Internet Explorer
GPU Accelerated Compositing in Chrome

I don't think that there is any limit for transform:scale(...). On the latest version of Chrome, I got up to 10 000 000 with no problem. But your problem might not be transform:scale(...) if you have a very small text that you make bigger with it. There is a limit for how small font-size:..., it can't be smaller than 0.01px. If you don't have such a small text, I don't see why you would like to have such a high value for transform:scale(...), the text would be too big for anybody to be able to read it.

Related

CSS rotate is not work #media query does not change back after rotating

I have been spending a week to solve the issue on a media query but I still not able to solve this issue. The image is still not able to rotate when it shift to the 1028 pixel.
I have a image at the on the red background of my web site. I want the image to change in response to a screen with no rotate when is reach to 1028px. I understand this is the best way to using by #media query as per the source below and rotate with 0. I think I am in right way to do, but the problem is the image is not effect for what I input. I am sure that #media query suppose to applies and the image suppose could rotate. When minimize the screen to be 1028 px, the image just dropped over from the top container to the second and third container. Which I think this is super ridiculous!
I hope you guys could give me some support, and I have taken a screen capture to show this working:
/* title-image */
.title-image{
width:60%;
-ms-transform: rotate(25deg); /* IE 9 */
-moz-transform:rotate(25deg);
-webkit-transform:rotate (25deg);
transform: rotate(25deg);
position: absolute;
right: 30%;
}
#media (max-width: 1028px){
.title-image:{
position: static;
transform: rotate(0);
}
}
.tite-image {
position: static;
transform: rotate(0);
}
I'm doing the same course as you. full stack web course on udemy right?
I had the same problem the Phone just didnt want to rotate back for me so instead i kept the rotation at 0 until the screen size went above 1028px
.iphonedog
{
width: 300px;
margin-left: 100px;
position: relative;
top: 10%;
left: 50px;
}
#media (min-width: 1028px)
{
.iphonedog
{
position: static;
transform: rotate(25deg);
}
}
This fixed it for me.

Hiding scrollbar in old mozilla versions, preserving scroll

I am writing a layout that has three separate scrollable columns of pictures, just like this page. The difference is that in our design there is only one pixel between images.
I managed to hide the scrollbars in chrome and in the newest Firefox.
In Firefox 63.0.1 they are still there and I need to hide them While still preserve
- ability to scroll divs down separately
- the pictures distance 1 px apart or wider only for those older firefox versions.
Mostly I tried hiding visually via overflow hidden on outer container.
For Chrome it works.
-ms-overflow-style: -ms-autohiding-scrollbar;
::-webkit-scrollbar {
display: none;
}
Here I found This:
#parent{
height: 100%;
width: 100%;
overflow: hidden;
}
#child{
width: 100%;
height: 100%;
overflow-y: scroll;
padding-right: 17px; /* Increase/decrease this value for cross-browser compatibility */
box-sizing: content-box; /* So the width will be 100% + 17px */
}
And here I found
body.is-firefox . scroll-container {
overflow: hidden;
-webkit-transform: translateX(-18px);
-ms-transform: translateX(-18px);
transform: translateX(-18px);
}
body.is-firefox .scroll-container .inner {
height: 100%;
-webkit-transform: translateX(18px);
-ms-transform: translateX(18px);
transform: translateX(18px);
overflow-y: scroll;
overflow-x: hidden;
}
Those would be lovely, if I could have more whitespace than 1px between the images.
Or I know for sure that the device is not the newest of Firefox, then I can use those tricks perhaps.
I searched and read that identifying features is more correct and realiable that identifying browser.
Tried using modernizr to know what features does users browser support
.no-cssscrollbar .box {
color: red;
}
.cssscrollbar .box {
color: green;
}
Not sure if I was detecting the correct feature or if it can detect what I want. In the codepen example it seemed to be working Sort of. But if I tried on my webpage Chrome also had those "no-cssscrollbar" classes although I can't see any scrollbars in Chrome and there are possibility to hide them.
Anyway:
I still have scrollbars in firefox 63.0.1 and I guess older version as well.
Please help me to have code to :
- identfy if browser used can hide the scrollbar or not
- identify if browser used is older Firefox
Thank You
Use this CSS here:
#namespace url("http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul"); /*
only needed once */
:-moz-any(#content,#appcontent) browser{
margin-right:-14px!important;
overflow-y:scroll;
margin-bottom:-14px!important;
overflow-x:scroll;
}
Source: https://support.mozilla.org/en-US/questions/1216436#answer-1108340

Slow Performing Full Screen Menu On Mobile

This is a strange problem that taken a couple of days worth of Googling many 'fixes' but am yet to find a solution to this strange problem. Here goes.
I have a fixed positioned Menu Button at the top of the screen that when clicked simply allows another fixed postion full screen menu to slide down from the top of the screen. Inspired by the solution at this site:
http://gardenestudio.com.br/
here is the css styles for the overlay menu which contains a single child ul as a test.
.overlay{
width: auto;
height: auto;
position: absolute;
top: 0;
left: 0;
right: 0;
bottom: 0;
background: rgb(59, 69, 97);
transform: translateZ(0);
-webkit-transform: translateZ(0);
transform: translate(0,-100%);
-webkit-transform: translate(0,-100%);
display: inline-block;
-webkit-backface-visibility: hidden; /* Chrome, Safari, Opera */
backface-visibility: hidden;
}
With the following 'SlideIn' and 'SlideOut' keyframes applied
#-webkit-keyframes overlayAnimateIn {
0% {
transform: translate(0,-100%);
-webkit-transform: translate(0,-100%);
}
100% {
transform: translate(0,0%);
-webkit-transform: translate(0,0%);
}
}
#-webkit-keyframes overlayAnimateOut {
0% {
transform: translate(0, 0%);
-webkit-transform: translate(0,0%);
}
100% {
transform: translate(0,-100%);
-webkit-transform: translate(0,-100%);
}
}
However, the problem I am having is that on desktop the performance of the animation is fine.
But on mobile devices.. from Sony Xperia Z2 Compact (vanilla install) etc .. the performance of the animation is terrible.. for the first 10 seconds then after that time interval, the animation is smooth as silk. Note: the gardenstudio solution is smooth at all times.
I have gone through a number of optimisations and reductions of my CSS and HTML to try to find what is causing this problem.
looking at the http://gardenestudio.com.br/ example, i have reduced my stylesheet to around 800 lines (the minimum required to render the page correctly) and the HTML markup is 460 Lines (less than gardenstudio)
If I completely reduce the HTML (leaving the css) to virtually nothing, the animation is smooth.
If I reduce the css (leaving the markup) the animation is smooth..
Something tells me that there is something in my markup and/or css that is computationally expensive and causing a bottleneck.
Can anyone suggest any help finding the bottleneck or if there are any other suggested solutions, that would be great :)
Well after 2 and a half days of reducing, removing and optimising I have found the culprit for now.
We have a body content wrapper that has a Box Shadow applied to it.
Removing this Box shadow solved the problem and the animation is now smooth as anything.
I will continue to slowly re-add all the removed styles etc and report back if I find out why this is causing such a major performance hit.

IE crossing out pseudo element CSS?

I've been trying to get a few pseudo elements to work on IE, but it just doesn't let me.
It crosses out the CSS and acts like it's not there, which kinda aggrevates me.
Would anyone know what I'm doing wrong?
.newbutton {
border-radius: 50%;
width: 74px;
height: 74px;
position: relative;
background-color: black;
margin: 60px 0px 25px 17px;
overflow: visible;
}
.newbutton:before {
content: "f";
width: 80px;
height: 80px;
position: absolute;
border-radius: 50%;
z-index: -1;
top: 37px;
left: 37px;
-webkit-transform: translate(-50%, -50%);
transform: translate(-50%, -50%);
-webkit-animation-name: fadecolor;
-webkit-animation-duration: 5s;
-webkit-animation-iteration-count: infinite;
animation-name: fadecolor;
animation-duration: 5s;
animation-iteration-count: infinite;
}
.newbutton:after {
content: "";
width: 80px;
height: 80px;
position: absolute;
border-radius: 50%;
z-index: -2;
top: -3px;
left: -3px;
background: -webkit-gradient(linear, 0% 0%, 0% 100%, from(#01BAE8), to(#0183D5));
}
<div class="starttour">
<div class="newbutton headerbutton">
<span class="iconhead icon-02-arrow-icon"></span>
</div>
<p>START TOUR</p>
</div>
Screenshot of what happens:
This is a known issue, but the styles are in fact being applied. The developer tools thinks the pseudo-element styles are being overridden by the parent-elements corresponding styles. This is easily demonstrated by inspecting the Computed style of the parent-element and looking at (what the F12 tools believe to be) competing styles:
Again, however, these styles are in fact being applied to the correct elements - regardless what the developer tools believe or suggest. You can confirm this by running over the parent-element and the two pseudo-elements and logging their computed height:
(function () {
var el = document.querySelector( ".newbutton" );
[ "", "::before", "::after" ].forEach(function ( e ) {
// Output: 74px, 80px, 80px
console.log( window.getComputedStyle( el, e ).height );
});
}());
I'll check to see if we already have an internal issue tracking this bug, and add this question to it. Generally speaking, we try to give issues like this the amount of attention proportional to the amount of grief the issue is causing in the real world. So having your question as a new addition on the ticket may help us move a fix forward :)
I had this exact same issue! You must give your :before and :after pseudo elements a display property.
Add the following to the :before and :after.
display: block;
This should fix your issue. :)
To add onto the answer above. I tried display: block but my issue was that the background image was coming out warped. Instead I used below:
display: inline-block;
This fixed my issue with warped images within my :before :after
As I had the same problem with Material Font and IE11 and could not solve it with the above solutions, I looked further:
The documentation of the material design icons mentions to use
<i class="material-icons"></i>
for browsers not supporting ligatures. The codepoints for each item are listed here: https://github.com/google/material-design-icons/blob/master/iconfont/codepoints
The problem with :after elements is that HTML in the content-Tag is rendered as plain text showing the &#x.. so you have to use the \ escape as following:
content: "\e5c5";
I had this exact same issue! You must give your pseudo element's parent a overflow : visible property.
Check out this link "http://stackoverflow.com/questions/2587669/can-i-use-the-after-pseudo-element-on-an-input-field", as quoted from this link
:after and :before are not supported in Internet Explorer 7 and under, on any elements.
It's also not meant to be used on replaced elements such as form elements (inputs) and image elements.
In other words it's impossible with pure CSS.
/*
* The trick is here:
* this selector says "take the first dom element after
* the input text (+) and set its before content to the
* value (:before).
*/
input#myTextField + *:before {
content: "👍";
}

CSS3 progressive transforms for unknown amount of children

I've been playing with progressive transforms in CSS coupled with transitions. It's looking pretty good so far, but I'd like to know how I can make it generic - that is, for any amount of children.
The dabblet/gist is here - and you can see straight away that this is hardcoded for a small amount of children. I don't want to have to write div+div+div+div.... rules as below - there's probably a neat way to achieve this, but would welcome any ideas.
.fan:hover div {
-webkit-transform: rotate(10deg);
top: -10px;
left: 5px;
box-shadow: 0 2px 10px rgba(128,128,128,0.3);
}
.fan:hover div+div {
-webkit-transform: rotate(20deg);
top: -15px;
left: 10px;
}
.fan:hover div+div+div {
-webkit-transform: rotate(30deg);
top: -20px;
left: 15px;
}
edit: I realise they are just webkit rules for now too ;)
A quick glance at your code:
http://dabblet.com/gist/2574800
For the second, modified fan, only the .fan:hover div rule applies, but thanks to nesting the transform rules get applied multiple times on your divs, so the first div gets rotated 10deg, the second 10+10deg and so on...
You might hav to adjust the rules further, but the principle is clear i think.

Resources