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))
);
}
Related
I've the following constraints which are working perfectly fine over Chrome in Desktop (simulating mobile resolution)
const constraints = {
audio: false,
video: {
width: screen.width,
height: screen.height
}
};
navigator.mediaDevices.getUserMedia(constraints).then(stream => {})
However when actually trying this on iPhone / Safari the camera doesn't respects this at all and gets super small or distorted - removing the width / height from the constraints makes it better ratio but not full screen at all, just centralized.
I've also tried with min / max constraints without lucky.
Is there any way to get this working on iPhones?
I have built a few AR Websites which are mobile first. When you request a resolution the web browser sees if the resolution exists, and if it doesn't it then decides if it should emulate the feed for you. Not all browsers do emulation (even though it is part of the spec). This is why it may work in some browsers and not others. Safari won't emulate the resolution you are asking for with the camera you have picked (I presume the front).
You can read more about this here (different problem, but provides a deeper explaination): Why the difference in native camera resolution -vs- getUserMedia on iPad / iOS?
Solution
The way I tackled this is:
Without canvas
Ask for a 720p feed, fallback to 480p feed if 720 gives an over-constrained error. This will work cross-browser.
Have a div element which is 100% width and height, fills the screen, and sets overlay to hidden.
Place the video element connected to the MediaStream inside, make it 100% height of the container. The parent div overlay hidden will in effect crop the sides. There will be no feed distortion.
With canvas
Do not show the video element, use a canvas as the video view. Make the canvas the same size as your screen or the same aspect ratio and use CSS to make it fill the screen (latter is more performant).
Calculate the top, left, width and height variables to draw the video in the canvas (make sure your calculation centers the video). Make sure you do a cover calculation vs fill. The aim is to crop the parts of the video which do not need to be shown (I.e. like the descriptions of various methods in https://css-tricks.com/almanac/properties/o/object-fit) . Example on how to draw video into a canvas here: http://html5doctor.com/video-canvas-magic/
This will give you the same effect of what you are looking for. Production examples of something similar.
https://www.maxfactor.com/vmua/
https://demo.holitionbeauty.com/
P.s. when I get time I can code an example, short on hours this week.
There are a couple of quirks on mobile gUM() you need to know about.
First, if the device is in portrait orientation things work weirdly. You need to swap the width and height. So, let's say you're on a 480x640 device (do those even exist? who cares? it's an example). To get the appropriate size video you need
const constraints = {
audio: false,
video: {
width: screen.height,
height: screen.width
}
};
I can't figure out exactly why it's like this. But it is. On iOS and Android devices.
Second, it's hard to get the cameras to deliver exactly the same resolution as the device screen size. I tweak the width and height to make them divisible by eight and I get a decent result.
Third, I figure the sizes I need by putting a <video ...> tag in my little web app with CSS that makes it fill the browser screen, then querying its size with
const rect = videoElement.getBoundingClientRect()
const width = rect.width > rect.height ? rect.width : rect.height
const height = rect.width > rect.height ? rect.height : rect.width
This makes the mobile browser do the work of figuring out what size you actually need, and adapts nicely to the browser's various toolbars.
I just got to test IE10 on a Surface Pro with 1920*1080 display resolution where "make text and other items larger or smaller" has been set to Large.
On my website I have added the CSS+JS viewport fix in addition to the viewport meta tag, all asking for width: device-width (plus I added a "min-width: 320px;" to the #-ms-viewport definition to ensure it never gets smaller than that).
I added some javascript to display the value of window.screen.width and $(window).width to see what the browser ended up using for viewport in IE10, and to my surprise the screen size of a 1920*1080 resolution display was reported as 1280x720!
Now, I can live with with that (just like small phone screens report 320px width no matter their actual resolution, since it is a good size to make stuff human readable across devices for the same font size), but when the 'Metro IE10' is snapped to the side of the screen, the problem comes: IE10 tries to make a 320px rendering of the website, but it zooms in so the right side of it is hidden.
I tried Microsofts own test page: http://ie.microsoft.com/testdrive/Graphics/MakeItSnappy/
It does the same thing - on the Surface Pro the right side is hidden, and you need to drag left/right to see it, and you cannot even zoom out to view the full width!
But when trying the same thing on my laptop with a 'normal' 1366x768 display (rendered as 100%), the snapped IE10 display has the perfect size.
Ok, I guess this is a Microsoft Windows scaling bug - but my question is: Has anybody else experimented with changing the "make text and other items larger or smaller" to 125% or 150% and making websites adapt correctly?
Check out this fix from developer Matt Stow
http://mattstow.com/responsive-design-in-ie10-on-windows-phone-8.html
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).
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.
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.