I did this background in firefox but I can't replicate it in webkit/chrome (I have tried several alternatives but nothing):
background: -moz-repeating-linear-gradient(0deg, gray, transparent 1px, transparent 5px) repeat scroll 0 0 white;
What would be the correct translation? It is possible to achieve the same pattern? (or at least a very close one).
Thanks!
Oh! It was there in the documentation! :
http://www.webkit.org/blog/175/introducing-css-gradients/
If you want to achieve effects like
tiling of a vertical gradient using a
narrow strip, you should specify
background-size to give the gradient
tile an explicit size.
So it was fixed adding:
background-size: 10px;
Gecko and Webkit acts differently in this matter: While Gecko will adjust the background size automatically if you specify the gradient steps in "px", webkit will (possibly) calculate the % based in the "px" measure you set.
I'm not sure if my English is correct, but that is the idea...
-webkit-repeating-greadient(...) :)
Supported by Chrome and Webkit nightlies.
Related
How does Safari determine what size to output an svg in the following scenario;
SVG code
viewBox 0 0 800 800
height 100%
width 100%
css
svg width 100%
containing div width 60%
Safari outputs a much smaller svg than the 60% of screen, ok this is a bug. But what determines the size of this smaller svg, it has no connection to anything I can think of.
Just to give some background info. Safari needs both width and height in px for it to do what you want. % don-t work. But it does output the svg, and so it must make a decision somewhere about its size.
It's not a bug you're seeing. That's the correct behavior. The browser by default scales the SVG viewbox (careful with the terminology now, we're not talking about the browser viewport) to fill the CSS-determined dimensions of the SVG element. The fill behavior is determined by the SVG preserveAspectRatio attribute. By default it's set to meet, which keeps the whole SVG viewable, and the aspect ratio preserved. The alternative is slice which scales the viewbox up to cover the element, even when that means cropping. (slice behaves similarly to background-size:cover in CSS3.)
What you need to do is:
a) Don't declare explicit height or width in the SVG file. If your graphics editor is generating them, just go in by hand and delete them. According to the spec, if no width and height are specified, a value of 100% is assumed, so your pseudocode is redundant at best.
b) Make sure you're setting an explicit height for the svg element in CSS. I recommend developer or Canary builds of Chrome for troubleshooting responsive svg sizing, as there is a bug in Chrome 18 Dev Tools that has since been fixed. Once you've got it working in Chrome, it will almost certainly also work in Safari.
c) Figure out how you want to set preserveAspectRatio and manually edit the svg to put in the declaration.
If you're still having trouble, please post a jsfiddle. It's much easier for other people to comment on.
I'm building an application using Sencha Touch that's targeting iPads. The only way to achieve a smooth animation that I know is to use -webkit-transform css property. That works for moving things around with translate3d and scaling them, however I'm looking to change elements' dimensions (width and height). Imagine an element that grows in size to accomodate for a new child - that's what I'm after
You won't have any luck with width and height, as any transitions for these properties won't be hardware accelerated. What you'll get instead in Safari is a jerky animation that isn't even scaled properly. In my tests, the browser would first transition the height, then the width would snap into place abruptly, or vice versa. If all you want to do is scale an element (change its dimensions) then you should us -webkit-transform: scale(x, y).
To be as succinct with styles as possible, I'd rather not use a media query stylesheet that is included if my page is viewed with a double-pixel-density device such as the iPhone 4.
That being said, would it be ok if I just did something like this?
.icon-1 {
background-image: url('my-image-64px.png'); // This image is 64 x 64
background-repeat: no-repeat;
background-position: center center;
background-size: 32px 32px;
}
Would this work across the board without any drawbacks? Or should I do some sort of a media query for devices with a certain pixel density?
Yes it would. The only drawback is downloading an image that is much larger than it needs to be on non-retina displays. I would recommend that you have non retina images for everything in the main stylesheet (with background size set for all images), and include a retina stylesheet as necessary that overrides all image urls with links to retina sized images.
It's a bit more work, but people on slow edge cellular connections will thank you.
Oh, and your way will also downsample your image for you, which may or not be ok. If you have 1px wide lines (for example) in the image, it may not downsize in a way that you find pleasing. But for most types of images, it will probably be acceptable.
To answer your "media query for devices with certain pixel density", the answer is yes:
media='only screen and (-webkit-min-device-pixel-ratio: 2)
In addition to dmackerman's post, to include a media query for non-webkit browser supporting higher densities, one could write:
#media only screen and (-webkit-min-device-pixel-ratio: 2), (min-resolution: 192dpi) {
}
or
#media only screen and (-webkit-min-device-pixel-ratio: 2), (min-resolution: 2dppx) {
}
which are both producing the same outcome.
Is there a way to creat a gradient with a stop n pixels from the bottom edge of the element?
For example with Moz/Firefox it would look like:
-moz-linear-gradient(center bottom , #f00 2%, #d00 31px)
It should also be noted that this gradient has a companion gradient to do the same thing to the very top of the box. So really the css looks like this for FF and i need to reproduce for webkit:
background-image:
-moz-linear-gradient(center top , rgba(255,0,0,0.75) 2%, rgba(255,0,0,0) 31px),
-moz-linear-gradient(center bottom , rgba(255,0,0,0.75) 2%, rgba(255,0,0,0) 31px);
You can't do that with the current webkit syntax. Good news though! There will be a new -webkit-linear-gradient property (just announced on the webkit blog) that basically matches the -moz syntax and will allow you to do this. This syntax should become the definitive CSS3 syntax, so you'll be able to drop the -webkit and -moz entirely at some point. (The old -webkit-gradient property will continue to work indefinitely, but is not favored going forward.)
You could use -webkit-background-size to size the gradient in pixels and background-position to place it at the bottom.
Not quite sure what you were after but I manage to stop a gradient in px by using this -
background-size:100% 31px; background-repeat:no-repeat;
Have you tried something like this?
-webkit-gradient(linear, center bottom , #f00 2%, #d00 31px)
I hope that this site helps you more.
I have a box in one of my websites that has a these property:
-moz-box-shadow:inset 0 0 50px #ecf4de;
-webkit-box-shadow:inset 0 0 50px #ecf4de;
box-shadow:inset 0 0 50px #ecf4de;
This gives the box a nice gradient towards the center. However, Safari does not support the "inset" property and IE doesn't support box-shadow at all. I can't use an image for this because the height of this box changes for each situation.
I don't want to use 3 images, (one for the top, a repeating one for the middle and one for the bottom), as this can get very messy code.
So what I'm asking is if there is any way to produce the box shadow in all browsers.
EDIT: Anybody know of some javascript snippet that could possibly do this? Just wondering...
The latest Webkit build (and probably many before) has support for inset. It will probably get to Safari for the next release.
However, you won't be able to do it on all browsers without the three images trick. Internet Explorer's not going to collaborate with you otherwise.
That being said, I don't think your goal should be to get identical results in all browsers. I think you should get decent results in all browsers, but it's normal that web pages in Safari or Firefox look better than in Internet Explorer 7. Besides, only web geeks compare web page rendering across different browsers.
Agreed; to be honest, I've no qualms about leaving my pages looking blander and blockier on Internet Explorer than superior browsers. The content is still readable, accessible, and navigable: but screw getting it pixel perfect between browsers. If anything, it'll just give Microsoft all the more incentive to improve their browser's support for CSS3.
Personally, I think the inset flag is one of the most awesome features being promised by box-shadows... aside from giving elements a depressed, "cut-out" effect, inset shadows can also be used to create glowing edges and angled shading, an effect that can't be easily achieved using straight background gradients (especially with rounded edges). Being able to inset shadows opens up a whole wealth of opportunities for web design.
Knowing that Safari didn't support it had me worrying it might be dropped from the spec at some point: God knows there's no reason to drop something so useful. >_>
inset Safari 5.0 support
http://www.css3.info/preview/box-shadow/
You may have more luck with the 'Overlay Method', the first of Jordon Dobsons's techniques here, which uses radial gradients.
But it does still require a height and width on the image (especially in Chrome).
/* Overlay Method */
figure.overlay::after{
position: absolute;
top: 0;
bottom: 0;
left: 0;
right: 0;
content: "";
z-index: 2;
pointer-events: none; /* "all" disables mouse access to image */
/* Mozilla Setting */
background-image: -moz-radial-gradient(
center, circle contain, rgba(0,0,0,0) 125px, rgba(0,0,0,.5) 250px
);
/* Webkit Setting */
background-image: -webkit-gradient(
radial, 50% 50%, 125, 50% 50%, 250, from(rgba(0,0,0,0)), to(rgba(0,0,0,.5))
);
}