Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Mass-unprefixing in Firefox 16

paulrouget.com

Post reply on HN
Print view View original

21–30 of 45 posts

Re: Mass-unprefixing in Firefox 16

#21

Post by duskwuff »

Achshar wrote: post #15
TazeTSchnitzel wrote: post #13

Earlier quoted context omitted.

I use CoffeeScript, but I'm reluctant to use SASS or LESS, since they are ugly and I generally want to avoid having to use software to manipulate my HTML/CSS content. I'm fine with JS, but I like my compile script only having to copy my index.html and style.css file across, not having to invoke a CSS compiler.

The CSS compilers really dont make much sense to me. The language is very easy/simple as is (vendor prefixes are a mess though) and having a compiler's overhead on every request does not feel right to me. I love JS though, in fact it's my favorite go to language for all kinds of work, heavy duty or light. I thinks that is also a part of the reason I am not inclined towards languages that compile to JS, they kind of d…

If you're running the LESS compiler on every request, you're doing it wrong. Doing that might make sense in development, but for deployment you're expected to run the compiler once to generate a single static, minified CSS file. Same as JS compilers/minifiers in that respect.

As far as what these compilers do? Yes, CSS is nice enough as it is; that's why these compilers don't mess with the syntax too much. Most of what they're useful for is acting as a macro preprocessor (so you can use @color macros and automatically generate vendor prefixes, for instance), as well as for efficiently combining multiple source files.

If you're not familiar with how useful CSS compilers like LESS can be, I'd highly recommend that you take a look at Twitter Bootstrap. They use the macro-processing features pretty heavily, and to impressive effect. For instance, most of the colors in a Bootstrap site are configured in variables.less -- including light/dark color variants! -- so you can change around the whole color scheme of a Bootstrap site by adjusting just a few color definitions.

Re: Mass-unprefixing in Firefox 16

#22

Post by Achshar »

duskwuff wrote: post #21
Achshar wrote: post #15

Earlier quoted context omitted.

The CSS compilers really dont make much sense to me. The language is very easy/simple as is (vendor prefixes are a mess though) and having a compiler's overhead on every request does not feel right to me. I love JS though, in fact it's my favorite go to language for all kinds of work, heavy duty or light. I thinks that is also a part of the reason I am not inclined towards languages that compile to JS, they kind of d…

If you're running the LESS compiler on every request, you're doing it wrong. Doing that might make sense in development, but for deployment you're expected to run the compiler once to generate a single static, minified CSS file. Same as JS compilers/minifiers in that respect. As far as what these compilers do? Yes, CSS is nice enough as it is; that's why these compilers don't mess with the syntax too much. Most of wh…

> you're expected to run the compiler once to generate a single static, minified CSS file.

Yes, i stand corrected on that, i don't use them but that is not an excuse for ignorance. Plus compiling once makes more sense than compiling every time.

I also use webkit's web inspector for making live changes to a stylesheet and then saving the file in the end, very convenient compared to the changing-saving-uploading-refreshing cycle. Also it is another barrier to entry for my open source project. (someone has to know all the compiling process to contribute)

And as for uses of compilers, with CSS variables at the horizon (already functional in chrome canary IIRC) and other than this vendor prefixing problem (which everyone knows is very real and seeing the rapid release cycles of all major browsers now days, it is not far fetched to see a solution being cooked up some time soon) compilers don't have much to tackle. The cost v/s return ratio will reduce and probably even be negative in near future (if not already).

The cost is of compiling every time during development and once every time production code changes. I don't know about you, but if i am not live editing css in web inspector, i make a ton of very small changes to CSS and try them out one by one by refreshing the page. Not a great experience if i have to go to command line every time i change a byte.

> Efficiently combining multiple source files.

This problem can only arise in very big projects and if your project is in that category then there are all sorts of solutions available. (including writing your own compiler) But if that problem exists in a small or even middle sized project, them i believe, the solution is not the compiler but to re-factor the code base to use less files or merging them.

Re: Mass-unprefixing in Firefox 16

#23

Post by zobzu »

Achshar wrote: post #6
TazeTSchnitzel wrote: post #5

I personally think we should cut down on prefix use. Whilst it may be impractical to completely eliminate them, they are a PITA for developers, and have made the mobile web too heavily reliant on WebKit.

I know, i am using transitions/gradients on my project and i have to write 5(!) different rules just to set one property. This is for production code. background: -webkit-linear-gradient(#fff, #fdd 75%, #fcc); background: -moz-linear-gradient(#fff, #fdd 75%, #fcc); background: -ms-linear-gradient(#fff, #fdd 75%, #fcc); background: -o-linear-gradient(#fff, #fdd 75%, #fcc); background: linear-gradient(#fff, #fdd 75%, #…

"I am not surprised at all if developers move to supporting just webkit."

that's why Mozilla is unprefixing IMO.

But yep, so much for standards.

Re: Mass-unprefixing in Firefox 16

#24

Post by Achshar »

tomjen3 wrote: post #19
Achshar wrote: post #6

Earlier quoted context omitted.

I know, i am using transitions/gradients on my project and i have to write 5(!) different rules just to set one property. This is for production code. background: -webkit-linear-gradient(#fff, #fdd 75%, #fcc); background: -moz-linear-gradient(#fff, #fdd 75%, #fcc); background: -ms-linear-gradient(#fff, #fdd 75%, #fcc); background: -o-linear-gradient(#fff, #fdd 75%, #fcc); background: linear-gradient(#fff, #fdd 75%, #…

Why include the MS prefix? the only browser that support is not yet in production and will presumably unprefix it before it ships.

The project i am working on needs IE support, and i won't be making big changes to code once it has been deployed. It's a contract based work and not employment. So if it is not unprefixed by august, i will still have support for the browser.

Re: Mass-unprefixing in Firefox 16

#25

Post by wheels »

Achshar wrote: post #22
duskwuff wrote: post #21

Earlier quoted context omitted.

If you're running the LESS compiler on every request, you're doing it wrong. Doing that might make sense in development, but for deployment you're expected to run the compiler once to generate a single static, minified CSS file. Same as JS compilers/minifiers in that respect. As far as what these compilers do? Yes, CSS is nice enough as it is; that's why these compilers don't mess with the syntax too much. Most of wh…

> you're expected to run the compiler once to generate a single static, minified CSS file. Yes, i stand corrected on that, i don't use them but that is not an excuse for ignorance. Plus compiling once makes more sense than compiling every time. I also use webkit's web inspector for making live changes to a stylesheet and then saving the file in the end, very convenient compared to the changing-saving-uploading-refres…

> Not a great experience if i have to go to command line every time i change a byte.

That's why, as was already mentioned, you generate them on the fly during development and generate them statically for production. That way you change the file on the file in your editor and it's updated immediately in your dev environment, but there's zero overhead in production.

Re: Mass-unprefixing in Firefox 16

#26

Post by pepve »

Achshar wrote: post #12
Natsu wrote: post #9

Earlier quoted context omitted.

Why not uses SASS and let mixins do that crap?

It's probably just me but I don't use libraries and secondary "languages" that compile to another language (in web development context). So no jquery, coffeescript, SASS, LESS, pIE etc. I don't feel satisfied when my code's efficiency/speed depends on some one else's code. It somehow means i am not in full control of things. I like to keep dependencies to a minimum. Which basically means I don't want to include any f…

You must be a rich man. I don't have the time or money to exclude everything that's Not Invented Here.

Re: Mass-unprefixing in Firefox 16

#27

Post by tomjen3 »

Achshar wrote: post #24
tomjen3 wrote: post #19

Earlier quoted context omitted.

Why include the MS prefix? the only browser that support is not yet in production and will presumably unprefix it before it ships.

The project i am working on needs IE support, and i won't be making big changes to code once it has been deployed. It's a contract based work and not employment. So if it is not unprefixed by august, i will still have support for the browser.

Not really, unless you only contracted to support IE 10.

There is a proprietary filter property that works on previous versions IE.

Re: Mass-unprefixing in Firefox 16

#29

Post by gioele »

I hope I will not see many more of this kind of news.

Dear browser makers, please, enable your prefixed CSS properties only in dev/night/beta builds. Leave only unprefixed CSS properties in the release stable browsers. With this you will be able to test new features, show them to web developers and, at the same time, save them from the madness of maintaining five different slightly different versions of new CSS properties. How many developers do you think will not remove the `-moz-` prefixes from they CSS? Who do you expect to say "from now on we will only support Firefox 16, let's drop the prefixed version used by older versions"?

Prefixes are for testing, not for stable applications.

Re: Mass-unprefixing in Firefox 16

#30

Post by erikb »

Achshar wrote: post #6
TazeTSchnitzel wrote: post #5

I personally think we should cut down on prefix use. Whilst it may be impractical to completely eliminate them, they are a PITA for developers, and have made the mobile web too heavily reliant on WebKit.

I know, i am using transitions/gradients on my project and i have to write 5(!) different rules just to set one property. This is for production code. background: -webkit-linear-gradient(#fff, #fdd 75%, #fcc); background: -moz-linear-gradient(#fff, #fdd 75%, #fcc); background: -ms-linear-gradient(#fff, #fdd 75%, #fcc); background: -o-linear-gradient(#fff, #fdd 75%, #fcc); background: linear-gradient(#fff, #fdd 75%, #…

Your comment actually explains to me, what I didn't know without CSS experience: What this post is actually about.
Post reply on HN