

CSS transforms unprefixed in Firefox nightly - robin_reala
http://paulrouget.com/e/transformsunprefixed/

======
MatthewPhillips
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).

~~~
daleharvey
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>)

~~~
joshmoz
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.

~~~
MatthewPhillips
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.

~~~
daleharvey
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

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

~~~
daleharvey
I havent, but do plan on doing so soon

------
TazeTSchnitzel
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.

~~~
tvdw
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.

~~~
TazeTSchnitzel
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.

~~~
daeken
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.

~~~
TazeTSchnitzel
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.

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

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

------
paulrouget
Not transitions. Transforms. [fixed]

~~~
robin_reala
I’m an idiot :( Sorry! _edited_

~~~
paulrouget
Thank you!

