Seems like there has been a recent update to Google Chrome that causes blurry text after doing a transform: scale(). Specifically I'm doing this:
#-webkit-keyframes bounceIn {
0% {
opacity: 0;
-webkit-transform: scale(.3);
}
50% {
opacity: 1;
-webkit-transform: scale(1.05);
}
70% {
-webkit-transform: scale(.9);
}
100% {
-webkit-transform: scale(1);
}
}
If you visit http://rourkery.com in Chrome, you should see the problem on the main text area. It didn't used to do this and it doesn't seem to effect other webkit browsers (like Safari). There were some other posts about people experiencing a similar issue with 3d transforms, but can't find anything about 2d transforms like this.
Any ideas would be appreciated, thanks!
I have had this problem a number of times and there seems to be 2 ways of fixing it (shown below). You can use either of these properties to fix the rendering, or both at the same time.
Backface visibility hidden fixes the problem as it simplifies the animation to just the front of the object, whereas the default state is the front and the back.
backface-visibility: hidden;
TranslateZ also works as it is a hack to add hardware acceleration to the animation.
transform: translateZ(0);
Both of these properties fix the problem that you are having but some people also like to add
-webkit-font-smoothing: subpixel-antialiased;
to their animated object. I find that it can change the rendering of a web font but feel free to experiment with that method too.
After trying everything else here with no luck, what finally fixed this issue for me was removing the will-change: transform; property. For some reason it caused horribly blurry looking scaling in Chrome, but not Firefox.
To improve the blurriness, esp. on Chrome, try doing this:
transform: perspective(1px) translateZ(0);
backface-visibility: hidden;
UPDATE: Perspective adds distance between the user and the z-plane, which technically scales the object, making the blurriness seem 'permanent'. The perspective(1px) above is like duck-tape because we're matching the blurriness we're trying to solve. You might have better luck with the css below:
transform: translateZ(0);
backface-visibility: hidden;
I found that adjusting the scale ratio helped slightly.
Using scale(1.048) over (1.05) seemed to generate a better approximation to a whole-pixel font size, reducing the sub-pixel blurring.
I also used translateZ(0) which seems to adjust Chrome's final rounding step in the transform animation. This is a plus for my onhover usage because it increases speed and reduces visual noise. For an onclick function however, I wouldn't use it because, the transformed font doesn't appear to be as crispy.
Instead of
transform: scale(1.5);
using
zoom : 150%;
fixes the text blurring problem in Chrome.
This must be a bug with Chrome (Version 56.0.2924.87), but the below fixes the bluriness for me when changing css properties in the console('.0'). I'll report it.
filter: blur(.0px)
Sunderls lead me to the answer. Except filter: scale does not exist, but filter: blur does.
Apply the next declarations to the elements that appear blurred (in my case they were inside a transformed element):
backface-visibility: hidden;
-webkit-filter: blur(0);
It almost worked perfectly. "Almost" because i'm using a transition and while in transition, elements don't look perfect, but once the transition is done, they do.
I found out, that the problem occures on relative transforms in any way. translateX(50%), scale(1.1) or what ever. providing absolute values always works (does not produce blurry text(ures)).
None of the solutions mentions here worked, and I think there is not solution, yet (using Chrome 62.0.3202.94 while I am writing this).
In my case transform: translateY(-50%) translateX(-50%) causes the blur (I want to center a dialog).
To reach a bit more "absolute" values, I had to set decimal values to transform: translateY(-50.09%) translateX(-50.09%).
NOTE
I am quite sure, that this values vary on different screen sizes. I just wanted to share my experiences, in case it helps someone.
In my case following code caused blurry font:
-webkit-transform: translate(-50%,-50%);
transform: translate(-50%,-50%);
and just adding zoom property fixed it for me. Play around with zoom, following worked for me:
zoom: 97%;
I have found a much better and clean solution:
.element{
transform:scale(0.5)
transform-origin: 100% 0;
}
or
.element{
transform:scale(0.5)
transform-origin: 0% 0;
}
Thanks to this post:
Preventing blurry rendering with transform: scale
I have this same problem. I fixed this using:
.element {
display: table
}
Another fix to try i just found for blurry transforms (translate3d, scaleX) on Chrome is to set the element as
"display: inline-table;".
It seems to force pixel rounding in some case (on the X axis).
I read subpixel positioning under Chrome was intended and devs won't fix it.
Try using zoom: 101%; for complex designs when you can't use a combination of zoom + scale.
2019 UpdateThe Chrome display bug is still unfixed and though no fault of the patrons, none of the suggestions offered in the entirety of this website help to resolve the issue. I can concur that I have tried every single one of them in vain: only 1 comes close and that's the css rule: filter:blur(0); which eliminates the shifting of a container by 1px but does not resolve the blurred display bug of the container itself and any content it may have.
Here's the reality: there literally is no fix to this problem so here is a work around for fluid websites
CASE
I'm currently developing a fluid website and have 3 divs, all centered with hover effects and sharing percentage values in both the width and position. The Chrome bug occurs on the center container which is set to left:50%; and transform:translateX(-50%); a common setting.
EXAMPLE: First the HTML...
<div id="box1" class="box">
Lorem Ipsum is simply dummy text of the printing and typesetting industry. Lorem Ipsum has been the industry"s standard dummy text ever since the 1500s, when an unknown printer took a galley of type and scrambled it to make a type specimen book.
</div>
<div id="box2" class="box">
Lorem Ipsum is simply dummy text of the printing and typesetting industry. Lorem Ipsum has been the industry"s standard dummy text ever since the 1500s, when an unknown printer took a galley of type and scrambled it to make a type specimen book.
</div>
<div id="box3" class="box">
Lorem Ipsum is simply dummy text of the printing and typesetting industry. Lorem Ipsum has been the industry"s standard dummy text ever since the 1500s, when an unknown printer took a galley of type and scrambled it to make a type specimen book.
</div>
Here's the CSS where the Chrome bug occurs...
*{margin:0; padding:0; border:0; outline:0; box-sizing:border-box; background:#505050;}
.box {position:absolute; border:1px solid #fff; border-radius:10px; width:26%; background:#8e1515; padding:25px; top:20px; font-size:12pt; color:#fff; overflow:hidden; text-align:center; transition:0.5s ease-in-out;}
.box:hover {background:#191616;}
.box:active {background:#191616;}
.box:focus {background:#191616;}
#box1 {left:5%;}
#box2 {left:50%; transform:translateX(-50%);} /* Bugged */
#box3 {right:5%;}
Here's the fixed css...
*{margin:0; padding:0; border:0; outline:0; box-sizing:border-box; background:#505050;}
.box {position:absolute; border:1px solid #fff; border-radius:10px; width:26%; background:#8e1515; padding:25px; top:20px; font-size:12pt; color:#fff; overflow:hidden; text-align:center; transition:0.5s ease-in-out;}
.box:hover {background:#191616;}
.box:active {background:#191616;}
.box:focus {background:#191616;}
#box1 {left:5%;}
#box2 {left:37%;} /* Fixed */
#box3 {right:5%;}
Bugged fiddle: https://jsfiddle.net/m9bgrunx/2/
Fixed fiddle: https://jsfiddle.net/uoc6e2dm/2/
As you can see a small amount of tweaking to the CSS should reduce or eliminate the requirement to use transform for positioning. This could also apply to fixed width websites as well as fluid.
It's important to add that this issue arises if the element which is being translated has a height with an odd number of pixels. So, if you have control over the height of the element, setting it to an even number will make the content appear crisp
None of above worked for me.
I had this animation for popups:
#keyframes pulse {
from {
transform: scale3d(1, 1, 1);
}
50% {
transform: scale3d(1.05, 1.05, 1.05);
}
to {
transform: scale3d(1, 1, 1);
}
}
In my case blurry effect was gone after applying this rule:
-webkit-perspective: 1000; even though it is marked as unused in Chrome inspector.
None of the above worked for me.
It worked when I added perspective
ie from
transform : translate3d(-10px,-20px,0) scale3d(0.7,0.7, 1)
i changed to
transform : perspective(1px) translate3d(-10px,-20px,0) scale3d(0.7,0.7, 1)
I used a combination of all answers and this is what worked for me in the end:
.modal .modal--transition {
display: inline-table;
transform: perspective(1px) scale(1) translateZ(0);
backface-visibility: hidden;
-webkit-font-smoothing: subpixel-antialiased;
}
My solution was:
display: initial;
Then it was crispy sharp
I was facing the blurry text issue on Chrome but not on Firefox when I used transform: translate(-50%,-50%).
Well, I really tried a lot of workarounds like:
transform: perspective(1px);
filter: blur(0);
transform: translateZ(0);
backface-visibility: hidden;
None of these worked to me.
Finally, I made the height and width of the element even. It resolved the issue for me!!!
Note: It might depend from use case to use case. But surely worth a try!
I have tried a lot of examples from these answers unfortunately nothing help for
Chrome Version 81.0.4044.138
I have added to transforming element instead
transform-origin: 50% 50%;
this one
transform-origin: 51% 51%;
it helps for me
This is what worked for me:
body { perspective: 1px; }
I fixed my case by adding:
transform: perspective(-1px)
I removed this from my code - transform-style: preserve-3d;
and added this- transform: perspective(1px) translateZ(0);
the blur went away!
FOR CHORME:
I´ve tried all suggestions here. But diden't work.
My college found a great solution, that works better:
You should NOT scale past 1.0
And include translateZ(0) in the hover but NOT in the none-hover/initial position.
Example:
a {
transition: all 500ms cubic-bezier(0.165, 0.840, 0.440, 1.000);
transform: scale(0.8, 0.8);
}
a:hover {
transform: translateZ(0)scale(1.0, 1.0);
}
In Chrome 74.0.3729.169, current as of 5-25-19, there doesn't seem to be any fix for blurring occurring at certain browser zoom levels caused by the transform. Even a simple TransformY(50px) will blur the element. This doesn't occur in current versions of Firefox, Edge or Safari, and it doesn't seem to occur at all zoom levels.
I have a div that has a small perspective shift on it to give a subtle 3D effect. The text in the div was blurring and I tried all the suggestions here to no avail.
Oddly, I found that setting 'filter: inherit;' on the text elements vastly improved the clarity. Though I can't understand why.
Here's my code in case it helps:
Html:
<div id="NavContainer">
<div id="Nav">
<label>Title</label>
<nav>
home
link1
link2
</nav>
</div>
</div>
Css:
#NavContainer {
position: absolute;
z-index: 1;
top: 0;
left: 20px;
right: 20px;
perspective: 80vw;
perspective-origin: top center;
}
#Nav {
text-align: right;
transform: rotateX(-5deg);
}
#Nav > nav > a,
#Nav > label {
display: inline-block;
filter: inherit;
}
#Nav > label {
float: left;
font-weight: bold;
}
For me the problem was that my elements were using transformStyle: preserve-3d. I realized that this wasn't actually needed for the app and removing it fixed the blurriness.
It will be difficult to solve with only css.
So I solved it with jquery.
This is my CSS.
.trY {
top: 50%;
transform: translateY(-50%);
}
.trX {
left: 50%;
transform: translateX(-50%);
}
.trXY {
top: 50%;
left: 50%;
transform: translate(-50%, -50%);
}
and this is my jquery.
function tr_init() {
$(".trY, .trX, .trXY").each(function () {
if ($(this).outerWidth() % 2 != 0) {
var fixed_width = Math.ceil($(this).outerWidth() / 2) * 2;
$(this).css("width", fixed_width);
}
if ($(this).outerHeight() % 2 != 0) {
var fixed_height = Math.ceil($(this).outerHeight() / 2) * 2;
$(this).css("height", fixed_height);
}
})}
Just to add to the fix craze, putting {border:1px solid #???} around the badly looking object fixes the issue for me.
In case you have a stable background colour, consider this too.
This is so dumb noone thought about mentioning I guess, eh eh.
Hi i am doing an image gallery where hover the thumbnails, text will appear.
It is correct in firefox and chrome but seems to have issues in IE11.
Also the fonts and its colours are different too.
.middle {
transition: .5s ease;
opacity: 0;
position: absolute;
top: 50%;
left: 50%;
transform: translate(-50%, -50%);
-ms-transform: translate(-50%, -50%);
width: 100%;
height: 100%;
-webkit-transform: translate(-50%,-50%);
}
.text {
background-color: rgba(183, 191, 183, 0.65);
color: white;
font-size: 16px;
width:100%;
height:100%;
padding-top:45%;
padding-left:2%;
}
This is the correct one in chrome and firefox
IE 11 - wrong
for those who come to this question. The OP shared his website in a previous question and there, all the above styles are inside a #media not all, (-webkit-transform-3d) . so.
as i said in a previous answer to one of your questions .
#media(-webkit-transform-3d) indicates whether 3d transforms are supported or not and this is a NON STANDARD as MDN states
This feature is non-standard and is not on a standards track. Do not use it on production sites facing the Web: it will not work for every user. There may also be large incompatibilities between implementations and the behavior may change in the future.
-webkit-transform-3d is a non-standard boolean CSS media feature whose value indicates whether vendor-prefixed CSS 3D transforms are supported or not. This media feature is only supported by WebKit and Blink. The standards-based alternative is to use a #supports feature query instead.
and, as stated in MDN, it is NOT supported in IE at all . you should use #supports . so the problem is not with the styles but with the media condition
#supports {
<group-rule-body>
}
See DOCs here > #media MDN -webkit-transform3d
Add transform as an attribute like this
var element = querySelector(".middle")
element.setAttribute("transform","translate("-50, -50")"
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.
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.
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: "👍";
}