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

[Under S.]

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?

[Jon Fritz]

There are only a handful of things in Firefox, Chrome or Safari that still need -moz or -webkit for.

Border-radius isn't one of them (over 94% of browsers used globally can see it without).

http://www.Caniuse.com is pretty accurate on prefixes for css.

[pziecina · Accepted solution]

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.

[Under S.]

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]

Look at it this way, if you added every vendor prefix required to the avarage user created css file you would only add about 0.5kb extra to the file size. Given that a Bootstrap css file even using a cdn version is almost 40kb, 0.5kb is nothing.

Providing you use an autoprefixer, and you remember the few cases for which autoprefixing may not work correctly, (css flexbox, original specs, and css grid layouts, old and new specs may have same name, but implement different) then adding vendor prefixes is a matter of seconds, for a lot of gain in what the end user can see.

It is just a pity that Dw when it sort of implemented a solution, for vendor prefixing, forces users to use sass/less, and that i have been asking for a stand alone solution for over 6 years, with no success.

[osgood_]

pziecina  wrote

It is just a pity that Dw when it sort of implemented a solution, for vendor prefixing, forces users to use sass/less, and that i have been asking for a stand alone solution for over 6 years, with no success.

How do you see that working Paula?

I'm becoming a bit fixated by this vendor autoprefixing thing at the moment. I can't test the autoprefixer in Brackets as that stopped working ages ago and I can't remember how that worked. When I try and install the plugin again it says there is a problem, so I gave up and I don't use Brackets much anymore anyway but I was facinated to see how these plugin autoprefixers worked so I installed the autoprefixer in Atom, its crap. I mean it autoprefixes the css but you have to select the css (supposing you know what needs to be prefixed), open the command palette and choose autoprefixer for every block of css code you want autoprefixed, what?

Surely this autoprefixing to be any good has to be executed when you save a css file, right? You need for the autoprefixer to decide what needs to be prefixed and what tprefixes, if any, can be removed.

The other programs I'm currently using require a complex web of installing noodle.js or voodle.js, pig or grunt, whatever its called, you get the picture, then diving into the terminal all just to create some extra 'unwanted' folders in the project folder with a js file which you have to run to compile the css.....hummm WTF?

This is plain crazy just to get a few vendor prefixes into your css file. Its simpler to use a sass/less file and have Prepos compile it, right. Its less complicated set up, seems to created less files, so what gives? DW has sass/less built in by default.

Either these autoprefixer plugins have to execute on saving the css file or they are useless. I dont want to be running js files or constantly selecting blocks of text and opening the command pallete to compile it.

Do you use something that runs differently?

Hummmmm.

[pziecina]

Pity you cannot get the autoprefixer to work in Brackets, as -

it only adds prefixes that have not been included

it takes the requirements directly from the caniuse site, you specify how far back you want it to go.

it adds on save

it adds to a specific selection

it adds when selected to do so, without saving.

Note: I use the autoprefixer in vs, which also includes an option to add when i use the closing }

[osgood_]

pziecina  wrote

Pity you cannot get the autoprefixer to work in Brackets, as -

it adds on save

Right I know I'm not bonkers. It has to do that othewise its pointless. The one in Atom is pointless unless you can somehow configure it to compile on save. I have not tried out the one in Sublime yet, I might have a go tomorrow and see how that works.

[pziecina]

I'm going to upset you now Os, as i know you do not have the option to install it.

The autoprefixer for PostCSS also works the way i have described

[osgood_]

pziecina  wrote

I'm going to upset you now Os, as i know you do not have the option to install it.

The autoprefixer for PostCSS also works the way i have described

Yeah, I'm angry. Cant believe they have support for postCSS and not the autoprefixer plugin, it just nuts.

What program are you using it in VS or that fancy one you have which costs a quid or two?

Edit ok I re-read your post VS

[osgood_]

pziecina  wrote

I'm going to upset you now Os, as i know you do not have the option to install it.

The autoprefixer for PostCSS also works the way i have described

Humm I get this in Sublime:

Couldn't find Node.js. Make sure it's in your $PATH by running `node -v` in your command-line. (**** OFF not doing that)

So I guess i'll just give up on getting Autoprefixer into the program that Im currently using. Its not a big deal, I'll do it manually at the end of the project as I have been doing or if I'm desperate I'll use a sass file and Prepros as it seems to be the least complicated way of going about it.

Would have been nice to have as an option but I aint jumping through hoops - hey ho life goes on.

[pziecina]

You could join the pre-release, and continue annoying the team to include one

[osgood_]

pziecina  wrote

You could join the pre-release, and continue annoying the team to include one

Well I agree with you, one should be available and If as it seems it can be done pretty easily in Brackets and VC why not in every other editor out there, not just DW.

These are the kinds of things DW should be focusing on in my opinion if it wants to attract developers like myself back at some stage. As much as I like the IDE I use now its not really acceptable to me that it forces me to jump through hoops to use something which other editors have made easy to integrate.

I guess the problem is who calls for it. I dont think many developers have called for a autoprefixer plugin inclusion in Php Storm as I think the majority of its users are top end coders who would find deploying grunt and gulp etc a breeze so can include autoprefixer at will or they probably use sass or less.

Also it obviously mostly concentrates its efforts on php so I'm also not sure how many front end developers use it. I dont understand much of it but what I do understand I like a lot. Having said that they dont have a plugin available for Web Storm either, their front end tool, so I guess its just a case of its not an important issue for the software company.

Its never perfect is it. DW isnt the only bit of software that could do with a kick up the backside sometimes.

[pziecina]

I know many people who use a pre/post-processor find it essential, but it was the use of PostCSS with the autoprefixer extension, and an extension called cssnext, that convinced me that a stand alone autoprefixer, and getting browsers to support things like css variables was the future.

I had used sass before postcss, and would still prefer postcss if I could not use a stand alone autoprefixer and the w3c offerings like css variables.

A recent not very controled survey by Brackets, put the use of sass and none sass usage about the same, but another survey, (by MS, 2 years ago) placed autoprefixing and variables in the top 3 reasons for using sass. The inclussion of sass was then removed to its own extension, and a stand alone autoprefixer was offered, this happened about the same time as the Dw team started to make sass a core feature.

[rayek.elfin]

Osgood, an alternative solution is to download PrePros Compile with Live Browser Reload

Have it watch your css production file, and have it output an autoprefixed and minified version to a distribution folder that you link to in your html/php/etc files. And the live reload works quite nicely too (there's even an option to sync the scrolling in all open test browsers).

For good compatibility, set the Autoprefixed browser support setting to "last 30 versions", or something similar.

While PrePros supports CSS preprocessors too, it will happily post-process regular CSS files as well with Cssnext and Autoprefixer  (which looks at Caniuse for its information). And no obscure task runner configuration is required. Just drop your project folder in PrePros, and set up some settings.

And it allows you to work with any editor, whether that editor supports all that pre/post processing jazz or not.

(of course, I prefer to write my task runner scripts in NPM - but PrePros does make it incredibly accessible for anyone who is interested in integrating pre- and post processing in their workflow)

[BenPleysier]

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.

[pziecina]

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.

[BenPleysier]

I was replying to rayek.elfin​ when he said

Have it watch your css production file, and have it output an autoprefixed and minified version to a distribution folder that you link to in your html/php/etc files. And the live reload works quite nicely too (there's even an option to sync the scrolling in all open test browsers).

Did you spot the similarity?

[pziecina]

Yes, i did. But i was replying to the asumption by many people and the Dw team, that one uses one file. Which for many developers is not the case

[osgood_]

rayek.elfin  wrote

Osgood, an alternative solution is to download PrePros Compile with Live Browser Reload

Have it watch your css production file, and have it output an autoprefixed and minified version to a distribution folder that you link to in your html/php/etc files. And the live reload works quite nicely too (there's even an option to sync the scrolling in all open test browsers).

For good compatibility, set the Autoprefixed browser support setting to "last 30 versions", or something similar.

While PrePros supports CSS preprocessors too, it will happily post-process regular CSS files as well with Cssnext and Autoprefixer  (which looks at Caniuse for its information). And no obscure task runner configuration is required. Just drop your project folder in PrePros, and set up some settings.

And it allows you to work with any editor, whether that editor supports all that pre/post processing jazz or not.

Ok thanks I'll investigate that avenue.

rayek.elfin  wrote

(of course, I prefer to write my task runner scripts in NPM

Yes, I understand. If I was a little braver I'd be looking at getting Autoprefixer into the program using some kind of task runner. I just dont like messing around installing something onto my system when I dont know what it is and what, if anything, adverse effects it might have.

[ALsp]

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]

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.

[osgood_]

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.

[osgood_]

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;
}

[Under S.]

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?