Commit graph

8 commits

Author SHA1 Message Date
gorhill
7a5d09b4a2 this fixes #665 2015-02-04 18:06:31 -05:00
gorhill
084f092c33 re #550: use non-minified external libs 2015-01-30 08:04:52 -05:00
gorhill
0c152b2859 fixed flawed 1st-/3rd-party test 2015-01-08 10:37:19 -05:00
gorhill
1fe7045b92 too many changes for #433: branching so that I can commit and keep working on it 2014-12-28 10:07:43 -05:00
Raymond Hill
2e4c0a2bfe remove depending on vapi-appinfo.js 2014-12-01 14:25:33 -02:00
Deathamns
6d49ef0dac Avoid using Chrome's @@bidi_* type i18n messages
... for the sake of portability.

When including vapi-common.js in an HTML file, then the body element there
will have a "dir" attribute filled with the current locale's direction
(ltr or rtl).

The following languages are considered right-to-left: ar, he, fa, ps, ur.
Everything else is left-to-right.

After the "dir" attribute is set, we can decide in CSS which elements
should have different styling for rtl languages (e.g., body[dir=rtl] #id).
2014-11-09 17:40:40 +01:00
Deathamns
749b6f186d Use a dedicated file for storing extension info
Chrome has getManifest(), Safari doesn't have anything, Firefox has an
asynchronous API...
So, instead of using extension APIs, store the common informations
(extension name, version, homepage url) in a file (vapi-appinfo.js), which
can be included when it's needed (its data will be available at vAPI.app.____).
The file's content is updated each time the extension is being built, so
it shouldn't be modified manually.
2014-11-09 17:39:38 +01:00
Deathamns
5b79bf3536 Work on vendor API abstraction, and near complete Safari support 2014-11-09 17:39:12 +01:00
Renamed from background.html (Browse further)