It's a simple project, and I have not played around a lot with the standard code. But I still get this weird 1px margin around my ad... in this case adduplex.
I've tried to set the with to 480, margin to 0 and for the page properties designheight is 800 and width is 480 :-/
Does anyone know what I can test/do to correct it? I dont want this margin (blue horizontal line, right of the black with white upper and lower border).
As I mentioned the black with upper and lower border is my AdDuplex Control. The blue line should be white, but because my app somehow needed this margin its blue as my background
Image:
Related
I have a TRectangle without the borders. I set sides property all to false and it gets like the picture below.
When I set XRadius and YRadius to 20 the TRectangle gets a rounded corner as I desire, however, it gets a tine black border as you can see in the picture.
I would like to know how to get rid of this tiny black border.
not set all sides to false, but instead set stroke.kind to none
I am trying to draw a 1px line and it works properly in FireFox, however, in IE11 no matter what attributes I tried it seems always produce a line with 2px thick.
It is impractical to set the origin to 0.5 unit. Depends on the width of your stroke that if it's odd number of units you need to add or subtract 0.5 but if it's an even number you don't. If you add or subtract 0.5 indiscriminately you end up for inconsistent line width based on the stroke size and origin. The shape-rendering:crispEdges seems to solve this problem. But looks like the problem was due to the shape-rendering: crispEdges property not being respected in IE.
Is there a way to define a min/max height of UI element with FluentLayout?
My situation is like this:
Black UIView must be atleast 50px high. If anyone of it's child controls (Red UIView or BigTextUILabel) exceedes that 50px - it must stretch to accomodate its content.
If I define constraints:
blackView.Above(Table),
blackView.Height().GreaterThanOrEqualTo(50),
blackView.Height().GreaterThanOrEqualTo().HeightOf(redView)
blackView will stretch over whole screen (if table is empty). On the other hand if I change constraints:
blackView.Above(Table),
blackView.Height().GreaterThanOrEqualTo(50),
blackView.Height().EqualTo().HeightOf(redView)
redView will be stretched so the height of the red wiew (in this example) is equal to the height of the black view. So the First and Second UILabels wont be in the center of black UIView.
I couldn't find any examples on Priority or FullHeightOf. So to tell you the truth I don't know how it works.
I have two divs with width of 30% and 70% and fixed height as height:100vh; Because the project needs to have the slider to be always the height of the screen you are looking at.
But I cant seem to figure out how to fix the aspect ratio of the images? As you can see in the test link that the images are narrow?
here is the link : [broken link removed]
note that this is the prototype that I am building so its still ugly as **** :)
and sorry im not too good at coding (still learning)
Your image is stretching because you've set both the width and height to 100%, so the browser is making the image width fit the div width (which is thinner than the aspect ratio of your image).
The quick fix is to amend your CSS as follows:
.cycle-slideshow img {
width: auto;
height: 100vh;
}
This tells the browser to set the height to 100% and then resize the width accordingly to keep the image the correct aspect ratio.
Although, you may want some fall back for if the browser window is much wider than it is tall, as then you'll see the edge of the image.
I have different widths for borders applied to a div, and only Firefox shows thin seams when the div is rotated to any angle using CSS3 Transition Rotate. These thin seams change slightly depending on angle.
If the borders are the same width, Firefox behaves nicely.
The div is not using an image, just a colored background, but the content seems irrelevant for the border of different widths issue I'm having.
Unfortunately the area behind the border is going to be reserved so I'm not able to use another div as a wrapper.
Here's a jsFiddle of an example to be seen in Firefox that has this issue. There are no issues in Chrome.
Status Update: Updated jsFiddle to show border-style prior to border-color per CSS rule but no change.
I wonder if this issue is because border-image property, which I am not using, allows up to eight images, one for each border slice. That said, if there were border-corner-color properties then that would solve the issue when using Rotate.
I have made a solution using :before in CSS: jsFiddle example.
I added this code:
#thinLinesInFirefox:before {
content: '';
display: block;
width: 201px;
height: 201px;
position: absolute;
top: -105px;
left: -120px;
border-top: 104px;
border-right: 110px;
border-bottom: 115px;
border-left: 119px;
/* Define border-style before border-class per CSS rule. */
border-style: solid;
/* Define boder-color */
border-color: black;
z-index: -1;
}
Basically, it overlays the same square using :before, except I have decreased the border-top and border-left by 1 pixel, and then increased the width and height by 1 pixel so that the 'real' div underneath appears to be the same size.
Because of the different borders, the seams are in slightly different positions, so what is underneath doesn't show.
Those look like antialiasing artifacts from painting the border in several separate pieces. Each piece is being rotated, so its edges get antialiased, with the result that some pixels at the join are partially transparent (because they're the result of painting two partially-transparent pixels on top of each other).
There is no problem on this testcase in Chrome because at corners it paints the borders under each other. Of course that causes non-opaque borders to be totally broken in Chrome; see http://snook.ca/archives/html_and_css/safari-transparent-borders
And if you were to make the border colors slightly different, you'd get seams in WebKit too. See http://jsfiddle.net/YVCeX/ (it shows seams in the div's background color, whereas Firefox optimizes away background painting under opaque borders, which is why you're seeing red seams, not blue ones.
There's really no good way to handle this, in general, without turning off antialiasing for border edges and having jaggy borders when rotated.