I just got into LESS this morning. It's a lot nicer to write than pure css, BUT it would really solve a big headache for me if it was possible to refer to attribute from classes within classes...
Say I have
#El1
{
width: 100%;
}
I'd like to do something like
#El2
{
position: absolute;
width: 100%;
top: #El1.height;
bottom: 0;
}
So #El1 can size itself whichever way it wants and #El2 can be positioned beneath it and fill the entire remained for the viewport.
Not matter how hard I google I can't find anything to seem to indicate that this is possible. From how I understand the processing of the stylesheet takes place on load, my hunch is that this can't be done, because the height of El1 isn't known by the time the css rules are processed. But just on the off chance that there is a way to do this, I thought I'd ask... so is there any way that this can be done?
Related
I've got an element it's position: absolute, and left:0;
As soon as I put in top:0; it disappears. I know it's there somewhere but I can't work out where. I tried increasing top by 10px at a time and decreasing by -10px at a time but it doesn't show up.
Is there any way I can see where it is positioned on the page easily so I can work out what I am doing wrong and bring it into view?
I don't know why left: 0; worked and top: 0; caused a problem but I added position: relative; to the parent which allowed me to see my element and position it.
Slimbox is working perfectly for me with one exception... my slideshows often open way to low. The positioning is effected by any scrolling already done on the page. Every time the page is scrolled a bit, the slideshow opens lower than it had previously for the same page. Scroll down the page much and the show can be completely out of sight.
lbCenter and lbBottomContainer in the CSS control the positioning, but I can't find how to adjust them accurately. The default is:
#lbCenter,
#lbBottomContainer {
position: absolute;
z-index: 9999;
overflow: hidden;
background-color: #fff;
}
In an old thread here, I found suggestion for adding:
top: 30px !important;
As long as !important is included, this does work but with a significant caveat; the caption is moved from below to above the image and covers some of it. ( And !Important doesn't seem like an ideal solution )
How can I adjust the positioning of both while keeping the caption below the image?
This one was on me. My links included href="#" as some others required. The # caused the page to scroll to the top even as the slide show opened where the link was located.
<a href="#" onclick="show('homes')">
Eliminating the hash tag resolved it.
See this pen:
https://codepen.io/armandsdz/pen/xqGaoe
I have a simple Foundation grid and I set display:flex to "row" element in order to get all columns be the same height.
It all works fine in Chrome, Firefox.
But on Safari, Edge, Yandex browsers (any version) those columns are a pixel or so too wide and it results in them not fitting within one row. Therefore, it wraps to two rows.
See image
Setting flex-wrap: nowrap would be an option in case of only one line but it's often not the case.
And most importantly it doesn't solve the issue at its core.
What am I missing in this flexbox world or is it a bug?
Thanks!
Addition: It happens not only when column width is, for example, 33.33333% but also when it's 25%. So where does that extra pixel come from?
The :before and :after pseudo-elements are part of a clearfix hack to contain floats and prevent margin collapse. (See this SO question about that.) Flexbox essentially disregards floats, but older browsers that don't support flexbox would fall back to using the floats so they would need the clearfix. Based on #DannieVinther and #Armands' comments, there are two possible solutions:
If you want to maintain the clearfix functionality for older browsers that don't support flexbox, you can add a rule to set width: 100%; on the :before and :after pseudo-elements. This will give the pseudo-elements a width of 100% and a height of 0, so they won't mess with the width of the rows of actual content.
.row:before, .row:after {
width: 100%;
}
If you don't need/care to support older browsers, you can simply override the clearfix hack by adding a rule to set content: none; on the :before and :after pseudo-elements.
.row:before, .row:after {
content: none;
}
I am using Pelican for generation of web pages. However I cannot avoid overlapping of code blacks with the menu list this way.
This the concerned code piece
General
Start by reading
The Zen of Python <https://www.python.org/dev/peps/pep-0020/>_
.. sourcecode:: python
import this
For python we have pocket-lint that checks for PEP8 and some other things.
Try the following:
#general .highlight {
display: flex;
}
#general .highlight pre {
width: 100%;
}
The display mode flex allows the contents to rearrange in size and position. By setting this, the bounding box of the surrounding div is pushed to the right, such that background color and border are not overlapping anymore. However, due to the flexible nature of this display mode, the width of the content is reduced to the minimum required. This can be compensated by simply maximizing the width of the element.
I have a composited div (it has translate3d) with an opacity transition:
#bad {
background-color: red;
-webkit-transition: opacity .5s linear;
-webkit-transform: translate3d(0, 0, 0);
}
If I change its opacity while transition is undergoing, it will flicker in Safari.
The flicker happens about once in three seconds and is akin to a white flash.
There is no such problem in Chrome.
Scroll up and down in this fiddle to see what I mean.
The problem does not seem to be limited to opacity—changing -webkit-transform while its transition is undergoing has a similar effect: once in a while the element is rendered in one of the transition's final states.
The problem goes away if I remove -webkit-transform but unfortunately that's not an option right now.
Can I fix this in Safari by some other means?
The problem is changing property values and adding animations need to happen at the same time.
A race condition not present in OSX 10.5 was introduced when Core Animation was rewritten in C++. I learned this when my experiments with additive animation developed the same flicker. I found the workaround to be Core Animation's kCAFillModeBackwards. I also found the same workaround was effective for CSS Transitions by hacking up my own fork of WebKit, with emphasis on the hacking part. But conjecture doesn't help WebKit devs and I didn't want to annoy them any further. I do think the problem is with Core Animation, not WebKit. I'm guessing that they should use the same CFTimeInterval derived from a single call to CACurrentMediaTime throughout any given CATransaction.
Unlike transitions, CSS animations do allow for fill modes. It might be difficult to reproduce transition behavior, but that is one option. In particular, the challenge would be replacing interrupted animations with new ones that begin where the previous left off. In other words, it's easy to animate from opacity of 0 to 1 or 1 to 0, but what happens if the user wants to start when current animated progress is at 0.577564? This might require manually modifying the #keyframes style rule, not an easy task.
Then there is the question of the appropriate animation-fill-mode. Normally you wouldn't want to perform layout using forward filling animations, you'd use the CSS properties themselves. But in this case it might be simple enough to not set the underlying value, instead use only a forward filling CSS animation that gets replaced but never removed when finished. The alternative is setting the underlying value via element.style and at the same time adding a backwards filling CSS animation.
Of course, the flicker also does not happen if WebKit doesn't use Core Animation. By far the easiest way to prevent the flicker in your case is to not enable hardware acceleration.
Instead of:
-webkit-transform: translate3d(100px, 100px, 0);
try:
-webkit-transform: translate(100px, 100px);
http://jsfiddle.net/z6ejt/9/
In my case I found 3 actions that solved the same problem:
I needed to fade in an image on the ready event, tried with the jQuery animation but the image was flickering on OSX Safari.
Solved with these actions:
1) Analyze the CSS and delete all transition rules applied on the image, they seem to conflict with the animation command.
I had this rule
img {
/*DON'T COPY !!!*/
-webkit-transition:all 0.2s ease-in-out;
-moz-transition:all 0.2s ease-in-out;
-ms-transition:all 0.2s ease-in-out;
-o-transition:all 0.2s ease-in-out;
transition:all 0.2s ease-in-out;
/*DON'T COPY !!!*/
}
I deleted it.
2) Add this CSS rules to the element you need to fade in:
display: none;/*initial state modified by the fadeIn function*/
-webkit-backface-visibility: hidden;
-webkit-perspective: 1000;
-webkit-font-smoothing: antialiased;
-webkit-transform-style: preserve-3d;
-webkit-transform: translateZ(0);
3) Use the jQuery function "fadeIn" and don't use the command ".animate({opacity: 1} ecc..".
These actions resolved the flickering problem on OSX Safari .
This seems like a bug in CoreAnimation.
Kevin Doughty blogged about it and provided a simple fiddle to reproduce it.
I am not certain, but I believe it is caused by a Core Animation bug rdar://problem/12081774 a.k.a. the flash of un-animated content.
[...]
I believe the Safari transition flicker is directly related to the bug I filed. The workaround is to use a Core Animation fillMode of kCAFillModeBackwards or kCAFillModeBoth. It seems like there is something wrong with animation timing, where a property value change and an animation started on that property within the same transaction don’t actually begin at the same time. A backwards fill solves this by extending the effect of the late starting animation to be applied before its actual start time.
Kevin also reported this as #115278 in WebKit and tried to tackle it but from my understanding he didn't proceed with this and the patch wasn't accepted.
Of course it's not a real answer (doesn't solve the problem) but at least it explains the problem.
The following CSS fix the transition flicker on safari
* {
-webkit-backface-visibility: hidden;
}