Inspiring

Answered

Vendor Prefixes (-moz, -webkit) finally obsolete, or..?

Forum|Forum|8 years ago
April 6, 2017
7 replies
8380 views

I was looking over my code today, and every instance of rounded corners kinda looks ike this :

.classname {

width: 300px; height: 300px;

-moz-border-radius: 20px/20px;

-webkit-border-radius: 20px 20px;

border-radius: 20px/20px;

}

I didn't mind it at first, but as the website nears completion, streamlining is more on my mind than it was during building. So I Googled the subject of vendor prefixes (and their relevance in 2017) and found this. It's a year old, but about as recent an article as I've found on the subject.

So now I ask, what percentage of my audience am I potentially losing by doing away with -moz & -webkit backup code on a website scheduled to go up this summer?

This topic has been closed for replies.

Correct answer pziecina

Vendor prefixing is still used for new features that could still be changed, and even though desktop browsers may have many hidden behind a flagged browser setting, mobile device browsers have no such option. This means that even though in many cases vendor prefixing could be dropped, in reality if you intend to use the property on mobile devices you must use them, as mobile browsers have become the new IE6 when it comes to being updated.

So if you drop the -webkit- prefix, the propert may not be applied. Having said that, the device user will never know as the browser will simply ignore anything it does not recognize.

most editors have at least an autoprefixer extension, but Dw does not, (Brackets does). If you wish to use an autoprefixer in Dw you have to use sass/less, (no comment on what i think of that).

Use the property then running it through a vendor prefixing solution, costs very little extra work, for in general a lot of gain.

U

Under S.Author

Inspiring

Just wanted to return to this thread specifically to thank pziecina and osgood_ for turning me on to calc(). Although I'm pretty sure it's more or less equivalent to the original "left:50%; margin-left:-200px" calculations I improvised when it comes to potential issues with physical placement down the road, I can see it coming handy in a bevvy of other situations.

O

osgood_

Legend

https://forums.adobe.com/people/Under+S. wrote
Just wanted to return to this thread specifically to thank pziecina and osgood_ for turning me on to calc(). Although I'm pretty sure it's more or less equivalent to the original "left:50%; margin-left:-200px" calculations I improvised when it comes to potential issues with physical placement down the road, I can see it coming handy in a bevvy of other situations.

Use whatever solution you feel comfortable in deploying. If you've tested it and it works, no reason not to use it.

kiemthecao

Participant

Good Idea

U

Under S.Author

Inspiring

Leaning towards leaving the prefixes in until someone tells me they're safe to remove on mobile as well in 2017, and that doesn't seem to be the case quite yet.

While I've got you pros here, I thought I'd throw this minor question in, since it doesn't really warrant its own thread. If I want a DIV to begin 200px left of the center of the screen, extending to the right edge of the browser -- while responding to browser re-sizing fluidly -- would the following code be considered "good," or at the very least, "acceptable"?

div.name {

position: absolute;

left: 50%;

margin-left: -200px;

}

I'm asking because I tried "left: 50%" as a total guess, hoping it would do pretty much what it did (begin the div at the center X point on-screen)... I then expected to have to throw in a "right: 0" but it seems the div's natural properties took care of that.

I've only tried it in a couple of browsers and it seems to hold up. Am I understanding how CSS works well enough to start trusting myself more? Or are lines like "margin-left: -200px" considered cheap hacks to be avoided?

pziecina

Legend

Don't use that if you want it to be center of the screen, as the center will depend on the users browser size and/or the devices screen size.

First you will have to decide just how big the div will be, then use the css calc function to let the browser position the div.

calc(50vw - half the size of the div) , so say your div would be 200px then you would use -

-webkit-calc(50vw - 100px);

calc(50vw - 100px);

O

osgood_

Legend

https://forums.adobe.com/people/Under+S. wrote
I was looking over my code today, and every instance of rounded corners kinda looks ike this :
.classname {
    width: 300px; height: 300px;
    -moz-border-radius: 20px/20px;
    -webkit-border-radius: 20px 20px;
    border-radius: 20px/20px;
}
I didn't mind it at first, but as the website nears completion, streamlining is more on my mind than it was during building. So I Googled the subject of vendor prefixes (and their relevance in 2017) and found this. It's a year old, but about as recent an article as I've found on the subject.
So now I ask, what percentage of my audience am I potentially losing by doing away with -moz & -webkit backup code on a website scheduled to go up this summer?

You would definitely need to use some vendor prefixes but border-radius is not one of them, infact I havent used it in ages. I don't think you can just completely ignore all of them.

O

osgood_

Legend

You can use Autoprefixer CSS online – make your vendor prefixes is actual

if you type in

.radius {

border-radius: 10px;

}

Thats what it will translate as not:

.radius {

-moz-border-radius: 10px;

-webkit-border-radius: 10px;

border-radius: 10px;

}

whilst if you type in:

.radius {

display: flex;

}

it will shoot out the necessary prefixes:

.radius { display: -webkit-flex; display: -ms-flexbox; display: flex; }

ALsp

Legend

Both John and Paula make excellent points, so I'll simply add this...

If you don't know when a vendor prefix is needed, then you are going to wind up with a problem eventually. Things like border-radius are simple. So are linear gradients. Caniuse.com should be your guide on that. But where Paula is right in her assessment of mobile browsers, so is the idea that attempting to support people who are using old devices is asking for a big headache. We support the last two versions of a device. In other words, we support iPhone 7 and iPhone 6, while ignoring iPhone 5 and earlier.

The other side of this coin is that in order for certain things, such as Flexbox to be deployed successfully, there are vendor-prefixed properties that do not equate to the standard properties, which sometimes must be used. For example, if you do want to support iOS6, then you need:

display: -webkit-box;

display: flex;

So, it's not just a prefix, but a whole different name.

Not so simple, right?

pziecina

Legend

I'm not certain how reliable Caniuse is anymore?

My reasoning for doubting the accuracy started with css grid layouts, as just looking at the list of browsers says that in theory css grids will be supported by over 80% of browsers by the end of this year, (went from about 4% to 37% in one month).

Then if you look at css shapes, it says about 70% support.

The problem for me, is that both those specs are being distorted by each browser/device having the same % weight applied to calculate support, which is clearly not true for user support. In the case of css shapes the user base for Chrome desktop and both iOS and Android account for over 80% of internet usage, not 70%.

In the case of css grids, once iOS 11 is released, and Android 57, then only Opera mini and the 2 previous versions of Android, will count as not being supported, possibly giving over 95% support.

pziecinaCorrect answer

Legend

Vendor prefixing is still used for new features that could still be changed, and even though desktop browsers may have many hidden behind a flagged browser setting, mobile device browsers have no such option. This means that even though in many cases vendor prefixing could be dropped, in reality if you intend to use the property on mobile devices you must use them, as mobile browsers have become the new IE6 when it comes to being updated.

So if you drop the -webkit- prefix, the propert may not be applied. Having said that, the device user will never know as the browser will simply ignore anything it does not recognize.

most editors have at least an autoprefixer extension, but Dw does not, (Brackets does). If you wish to use an autoprefixer in Dw you have to use sass/less, (no comment on what i think of that).

Use the property then running it through a vendor prefixing solution, costs very little extra work, for in general a lot of gain.

U

Under S.Author

Inspiring

pziecina wrote
Vendor prefixing is still used for new features that could still be changed, and even though desktop browsers may have many hidden behind a flagged browser setting, mobile device browsers have no such option. This means that even though in many cases vendor prefixing could be dropped, in reality if you intend to use the property on mobile devices you must use them, as mobile browsers have become the new IE6 when it comes to being updated.
So if you drop the -webkit- prefix, the propert may not be applied. Having said that, the device user will never know as the browser will simply ignore anything it does not recognize.

So something as simple as border-radius may not translate to Mobile Firefox, for instance, despite everyone else clearing it as safe to use? Sounds like mobile just made vendor prefixes relevant all over again.

I'm not sure I feel safe removing -moz and -webkit anymore. :/

pziecina

Legend

Whilst in total agreement with your reply, when using the latest version of Dreamweaver, there is no need for all that jazz, this is all part of the included package.

Having mentioned this as a solution in previous replies, it was met with scorn.

Hi Ben, here we go again

I will repeat why I think a stand-alone autoprefixer is necessary.

Currently to use an autoprefixer solution in Dw you have to set a source and output file, which is o/k if you only have your css in one file. What happens though if you have a number of different css files, and a number of different file paths for those files?

For anyone not building mainly small sites, the use of multiple css files is a common practice, as is having all the required css files combined into one when a particular module is requested by the end user. To use Dw's set-up, you would have to go into the settings every time you wished to edit a different css file to the one specified in the settings, plus you would have to have two files for every css file you have, one sass/less and one the output file.

With a stand alone autoprefixer, there is nothing to do beyond setting up once for the browser support options, and having it add the vendor prefixes on save, no matter which file you work on, or which site/module you have selected, or the location of that file.

As i have said though, i no longer think Dw is aimed at users like me, and i think anyone working on medium to enterprise sites, will agree that Dw trying to force the only workflow they offer now, on users, is not a strategy to encourage anyone to use Dw, beyond those requireing only the basics.