CSS transforms unprefixed in Firefox nightly | Hacker News Reader

CSS transforms unprefixed in Firefox nightly

paulrouget.com

69 pointsrobin_reala31 comments

IndexedDB is far bigger news here. Does this mean saving Blobs in IndexedDB is finished?

I hope this doesn't mean Firefox is going to stop working on it because their implementation is much slower than in Chrome and IE (albeit Chrome is using the old spec).

Yes Blobs are working, no I very much doubt work will stop (there is a bug open to switch to a levedb backend - https://bugzilla.mozilla.org/show_bug.cgi?id=679267)

At this point we are unlikely to switch to leveldb, work on that has stopped. During integration and testing for leveldb we made a lot of progress on sqlite optimzation and the leveldb advantage diminished significantly, if not disappeared.

(Notice that the bug you referenced hasn't had any real progress since it was filed in August 2011, and work has stopped on the parent bug for integrating leveldb.)

I don't know much about the particular performance problem you're referencing, but I doubt it is as simple as sqlite not being fast enough.

I write an indexedDB library and have 25 unit tests that have multiple operations per test, let's say an average of only 2 per test. So about 50 operations, mostly just get or put. Chrome takes about 1 (when warm) to 1.5 (cold start) seconds to run all of the tests, Firefox takes 3.5 (warm) to 5 (cold). IE10 is phenomenally fast, less than a half a second even when cold.

This is some combination of slowness from pulling js from the cache, raw js speed, and indexedDB speed. I assumed it was mostly the latter but I could be wrong.

I was about to agree with you, for PouchDB I have a test suite of 460 tests which take around 20 - 30 seconds and are mostly indexedDB operations, I remember having to increase some timeouts to have tests pass in Firefox

But I just ran the test suite again and after a few runs, there was little difference in timing, firefox even came faster a few times.

And this is in latest stable, I cant test nightly yet due to some api changes, and I know there was a lot of work done on idb performance improvements last week.

Pleasantly surprised

Just out of curiosity, have you tested IE10 and if so what were your results?

I havent, but do plan on doing so soon

Can you post your test suite in a bug on bugzilla.mozilla.org? We'd like to profile this.

Ugh. We should get rid of prefixes already. They are a hassle for web developers, and reality is the web moves so fast that what's supposed to be "experimental" may be very quickly put into production use. Removing them would not prevent changing the syntax of a CSS property. Prefixes are bad anyway because they ensure only 4 engines can be ahead of the curve, unless web developers decide another matters enough to add the prefix for it.

Edit: Actually, if we don't get rid of prefixes entirely, we should get rid specifically of vendor prefixes. Using -experimental- or -x- is fine with me. Just don't segment by vendors so only some browsers are explicitly supported.

I don't think you understand why the prefixes are there. CSS was designed in a way that things should either work or not. There shouldn't be different ways to interpret a property. With browsers battling over several syntaxes for CSS3 implementation, the last thing we want is to have webdevs build a separate stylesheet for every browser out there, because (for example) "transform:" works different on Firefox 3 than on Firefox 4, and Chrome's implementation is also different. The prefixes help a lot here: you can group all these different stylesheets into one by using the prefixes, and once the standards are finalized they'll just use one syntax that can't be interpreted any other way.

CSS parsing rules mean it doesn't matter. You can simply specify a property with several syntaxes, and browsers ignore the ones they don't recognise.

Let's say that you have a property that takes in two color parameters, crazy-coloring. Webkit implements crazy-coloring: bgcolor fgcolor; Gecko implements crazy-coloring: fgcolor bgcolor;.

How do you propose we differentiate these and know what the designer meant? That's why we have prefixes, until it's standardized.

Usually we don't end up with cases that are that drastically different. And in that case, now only Webkit, Gecko, and maybe Trident and Presto are considered. Other, less popular rendering engines are rarely included in the set of prefixed properties, excluding them from the ability to use new features.

indexedDB specifically had very different behaviour in webkit and firefox, it still does afaik

There's also different behaviour across versions. Prefixes don't help.

How could one differentiate between different implementations in browsers?

Prefixes help. My favorite example is CSS gradients with transparency.

Mozilla: background-image: -moz-linear-gradient( rgba(255, 255, 255, 0.7) 0%, rgba(255, 255, 255, 0) 95% );

IE 9: filter: progid:DXImageTransform.Microsoft.gradient( startColorstr=#550000FF, endColorstr=#550000FF );

IE 8: -ms-filter: progid:DXImageTransform.Microsoft.gradient( startColorstr=#550000FF, endColorstr=#550000FF );

Webkit: background-image: -webkit-gradient( linear, left top, left bottom, from(rgba(50,50,50,0.8)), to(rgba(80,80,80,0.2)), color-stop(.5,#333333) );

How would one properly differentiate between browsers implementing functionality differently in this case without prefixes? The only option would be to wait years for standards to be finalized and then implemented.

Well, each of those values will only work correctly in one browser, other browsers would skip the ones they don't understand, yes?

Now the client wonders why the website looks so different in different browsers.

Eh? Did you even read what I posted? Browsers ignore CSS they don't understand, hence you can put several versions of a rule, and a browser will use the one it understands.

How is the browser supposed to magically discern developer intent?

What do you mean? Competing syntaxes usually don't get confused by browsers as being valid.

Because of the prefixes, yes the browser knows which properties to skip. But you were advocating removing prefixes, so I'm wondering how browser are supposed to differentiate between properties?

Eh? Have you ever done, say...

  color: rgb(255, 255, 255);

  color: rgba(255, 255, 255, 0.5);

Browser which do not support rgba simply ignore it and use the rgb() value.

Wait so you want them all to use the same prefix? So you'd have five properties called "filter:" or "background-image:"?

If my gradient looked bad in Mozilla, how on earth would the I know which property to change? They'd seem identical unless I memorized every single browser specific implementation of every CSS property.

Comments exist, you know.

It's not like we don't have this issue already with different versions of the same engine changing syntax.

Code should be self-documeting. You're proposing we remove something that serves to differentiate between properties in favor of simply adding the exact same information in the form of a comment.

Only where necessary. Where browsers do not disagree, it saves developers time and effort.

Not transitions. Transforms. [fixed]

considering that I'm working right now on bug 762303 - unprefixing transition and friends - I almost did a spit take when I read the HN headline. :-)

I’m an idiot :( Sorry! edited

Thank you!

Reply on news.ycombinator.com