You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cordova.apache.org by Josh Soref <js...@blackberry.com> on 2014/02/03 20:01:37 UTC
serving extra css
cordova serve is a pretty good way to test out how an application will
work on a device.
We¹d like to be able to easily transparently add in some platform specific
things (today, that¹s fonts which exist on the platform but aren¹t
necessarily on the system running the browser that¹s viewing the pages
from cordova serve).
https://github.com/jsoref/cordova-cli/commit/4ee156f1e588c329846a7ce5610a59
88a12b2eea
Is a way to do this (for IE and Firefox **). I¹m looking for some feedback
on it.
That would be accompanied with a change to a platform¹s parser, such as:
diff --git a/src/metadata/blackberry10_parser.js
b/src/metadata/blackberry10_parser.js
index 4ed280d..9244876 100644
--- a/src/metadata/blackberry10_parser.js
+++ b/src/metadata/blackberry10_parser.js
@@ -80,6 +80,15 @@ module.exports.prototype = {
www_dir:function() {
return path.join(this.path, 'www');
},
+
+ serve_extra_style:function() {
+ return 'fonts.css';
+ },
+
+ serve_extra_style_dir:function() {
+ var lib_path = path.join(util.libDirectory, 'blackberry10',
'cordova', require('../../platforms').blackberry10.version);
+ return path.join(lib_path, 'extra_www');
+ },
staging_dir: function() {
return path.join(this.path, '.staging', 'www');
And then the platform would have an extra_www/fonts.css file Š
I¹m not entirely happy with the use of the parser functionality to do this
‹ does anyone have a preference?
I could have serve automatically look for a ³well known file² within a
platform, and serve it if it exists.
Re: serving extra css
Posted by Josh Soref <js...@blackberry.com>.
Andrew wrote:
> Want to clarify the scenario here:
> - This is for users that point their BB10 web browser at cordova serve?
The scenario is for pointing other browsers at cordova serve. If you point
BB10 browser, or BB10 app host at the app, it already has the fonts
available because they¹re part of BB10.
> - This adds a <link> to include a font file that exists on the BB device
> already?
This adds a link: (which is equivalent to <link> except some browsers
don¹t support itŠ *sigh*) so that browsers that aren¹t on the device can
have the fonts available (as long as the css is able to point to woff
files which cordova serve can offer ‹ we¹d provide that).
>- This is *not* for pointing a desktop browser at it
This is for pointing a desktop browser at it.
>- This is *not* for pointing your <content> tag at it?
I believe that¹s equivalent to the first question. So, it is not for
pointing an app¹s content tag.
Re: serving extra css
Posted by Andrew Grieve <ag...@chromium.org>.
Want to clarify the scenario here:
- This is for users that point their BB10 web browser at cordova serve?
- This adds a <link> to include a font file that exists on the BB device
already?
- This is *not* for pointing a desktop browser at it
- This is *not* for pointing your <content> tag at it?
At least for iOS and Android, pointing your <content> at cordova serve
causes same-origin restrictions to kick in and kills your ability to make
network requests. That's the main reason we've been working on app-harness.
It conceptually does the same thing, but first copies your files to a
directory on the phone and points <content> to that. Not sure if that's
relevant to BB or not?
On Mon, Feb 3, 2014 at 6:58 PM, Josh Soref <js...@blackberry.com> wrote:
> Michal wrote:
> > Wouldn't this be better handled by Brian's dream of
> >browser-as-a-platform?
>
> I haven¹t worked through all the details, but I don¹t think so. If you
> want to run the blackberry specific hooks and you browse to the app from
> your blackberry browser, then you¹re going to be unhappy if it¹s a
> different platform.
>
> Browser-as-an-engine might work, maybe.
>
> > I understand that this solves your immediate problem, but I'm not sure
> > extending serve is really the right long term solution for this.
>
>
> > ..also, your idea of "automatically look for a well known file" could be
> > done within the application by feature detecting that its running in a
> > desktop browser.
>
> We¹re the SDK, not the application. I could tell authors ³if you want to
> see the fonts, put in this magic², but I¹m hoping to avoid making each
> author do that (where possible). There¹s also licensing fun w/ the fonts.
>
> I suppose that I could insert some code into cordova.js instead of having
> serve manage the css.
>
> > Would it be prehibitive to dynamically inject the style
> > on startup from the app itself?
>
> Doing it with a link: header is a lot cleaner than inserting strange logic
> into cordova.js, butŠ
>
> We can and probably will provide templates which include a style saying
> ³use font: Slate Pro². That¹s all you need for the platform engine.
>
> If we did use cordova.js instead of having serve provide the .css file,
> we¹d still need a way to get the fonts to the browser-as-engine case
> (which is handled by the .extra code).
>
> In case you¹re curious, installing fonts to a user¹s system is a no-go for
> a number of reasons (* it¹s painful to try to manage ‹ often requiring
> administrative privileges which isn¹t something we require, * Licensing is
> wrong, * it pollutes the user¹s font-space or their computer¹s font-space
> if shared, * it doesn¹t work if the user is visiting serve from a device
> other than localhost).
>
>
Re: serving extra css
Posted by Brian LeRoux <b...@brian.io>.
Do not feel this is our territory to override. The end dev should be adding
the fonts they want in their app.
On Tue, Feb 4, 2014 at 6:13 AM, Michal Mocny <mm...@chromium.org> wrote:
> On Mon, Feb 3, 2014 at 6:58 PM, Josh Soref <js...@blackberry.com> wrote:
>
> > Michal wrote:
> > > Wouldn't this be better handled by Brian's dream of
> > >browser-as-a-platform?
> >
> > I haven¹t worked through all the details, but I don¹t think so. If you
> > want to run the blackberry specific hooks and you browse to the app from
> > your blackberry browser, then you¹re going to be unhappy if it¹s a
> > different platform.
> >
>
> If you want BB-specific hooks with BB-browser, then target BB.
>
> If you want to test your app using cordova plugins on a desktop browser
> simulating a mobile phone, browser-as-a-platform is the I think the way to
> go.
>
> If you are done building your app on desktop, and now want to test more
> device specific styles (such as fonts), I would say that you should test on
> device. Is this prohibitively difficult on BB (I have not tried so not
> sure what the turnaround time is)? Perhaps the app harness + some of the
> auto-reload-on-device work that Braden is doing will help?
>
>
> >
> > Browser-as-an-engine might work, maybe.
> >
>
> I don't think so -- "engine" is the concept of replacing the use of the
> system webview, but thats still running on-device.
>
>
> >
> > > I understand that this solves your immediate problem, but I'm not sure
> > > extending serve is really the right long term solution for this.
> >
> >
> > > ..also, your idea of "automatically look for a well known file" could
> be
> > > done within the application by feature detecting that its running in a
> > > desktop browser.
> >
> > We¹re the SDK, not the application. I could tell authors ³if you want to
> > see the fonts, put in this magic², but I¹m hoping to avoid making each
> > author do that (where possible). There¹s also licensing fun w/ the fonts.
> >
> > I suppose that I could insert some code into cordova.js instead of having
> > serve manage the css.
> >
> > > Would it be prehibitive to dynamically inject the style
> > > on startup from the app itself?
> >
> > Doing it with a link: header is a lot cleaner than inserting strange
> logic
> > into cordova.js, butŠ
> >
>
> I didn't mean cordova.js -- I meant the specific app you are using for
> testing. You can ship cordova-cli hooks to add this if you want to share
> the functionality between several apps.
>
> I'm asking: do we really need to change the tools?
>
>
> >
> > We can and probably will provide templates which include a style saying
> > ³use font: Slate Pro². That¹s all you need for the platform engine.
> >
> > If we did use cordova.js instead of having serve provide the .css file,
> > we¹d still need a way to get the fonts to the browser-as-engine case
> > (which is handled by the .extra code).
> >
> > In case you¹re curious, installing fonts to a user¹s system is a no-go
> for
> > a number of reasons (* it¹s painful to try to manage ‹ often requiring
> > administrative privileges which isn¹t something we require, * Licensing
> is
> > wrong, * it pollutes the user¹s font-space or their computer¹s font-space
> > if shared, * it doesn¹t work if the user is visiting serve from a device
> > other than localhost).
> >
> >
>
Re: serving extra css
Posted by Michal Mocny <mm...@chromium.org>.
On Mon, Feb 3, 2014 at 6:58 PM, Josh Soref <js...@blackberry.com> wrote:
> Michal wrote:
> > Wouldn't this be better handled by Brian's dream of
> >browser-as-a-platform?
>
> I haven¹t worked through all the details, but I don¹t think so. If you
> want to run the blackberry specific hooks and you browse to the app from
> your blackberry browser, then you¹re going to be unhappy if it¹s a
> different platform.
>
If you want BB-specific hooks with BB-browser, then target BB.
If you want to test your app using cordova plugins on a desktop browser
simulating a mobile phone, browser-as-a-platform is the I think the way to
go.
If you are done building your app on desktop, and now want to test more
device specific styles (such as fonts), I would say that you should test on
device. Is this prohibitively difficult on BB (I have not tried so not
sure what the turnaround time is)? Perhaps the app harness + some of the
auto-reload-on-device work that Braden is doing will help?
>
> Browser-as-an-engine might work, maybe.
>
I don't think so -- "engine" is the concept of replacing the use of the
system webview, but thats still running on-device.
>
> > I understand that this solves your immediate problem, but I'm not sure
> > extending serve is really the right long term solution for this.
>
>
> > ..also, your idea of "automatically look for a well known file" could be
> > done within the application by feature detecting that its running in a
> > desktop browser.
>
> We¹re the SDK, not the application. I could tell authors ³if you want to
> see the fonts, put in this magic², but I¹m hoping to avoid making each
> author do that (where possible). There¹s also licensing fun w/ the fonts.
>
> I suppose that I could insert some code into cordova.js instead of having
> serve manage the css.
>
> > Would it be prehibitive to dynamically inject the style
> > on startup from the app itself?
>
> Doing it with a link: header is a lot cleaner than inserting strange logic
> into cordova.js, butŠ
>
I didn't mean cordova.js -- I meant the specific app you are using for
testing. You can ship cordova-cli hooks to add this if you want to share
the functionality between several apps.
I'm asking: do we really need to change the tools?
>
> We can and probably will provide templates which include a style saying
> ³use font: Slate Pro². That¹s all you need for the platform engine.
>
> If we did use cordova.js instead of having serve provide the .css file,
> we¹d still need a way to get the fonts to the browser-as-engine case
> (which is handled by the .extra code).
>
> In case you¹re curious, installing fonts to a user¹s system is a no-go for
> a number of reasons (* it¹s painful to try to manage ‹ often requiring
> administrative privileges which isn¹t something we require, * Licensing is
> wrong, * it pollutes the user¹s font-space or their computer¹s font-space
> if shared, * it doesn¹t work if the user is visiting serve from a device
> other than localhost).
>
>
Re: serving extra css
Posted by Josh Soref <js...@blackberry.com>.
Michal wrote:
> Wouldn't this be better handled by Brian's dream of
>browser-as-a-platform?
I haven¹t worked through all the details, but I don¹t think so. If you
want to run the blackberry specific hooks and you browse to the app from
your blackberry browser, then you¹re going to be unhappy if it¹s a
different platform.
Browser-as-an-engine might work, maybe.
> I understand that this solves your immediate problem, but I'm not sure
> extending serve is really the right long term solution for this.
> ..also, your idea of "automatically look for a well known file" could be
> done within the application by feature detecting that its running in a
> desktop browser.
We¹re the SDK, not the application. I could tell authors ³if you want to
see the fonts, put in this magic², but I¹m hoping to avoid making each
author do that (where possible). There¹s also licensing fun w/ the fonts.
I suppose that I could insert some code into cordova.js instead of having
serve manage the css.
> Would it be prehibitive to dynamically inject the style
> on startup from the app itself?
Doing it with a link: header is a lot cleaner than inserting strange logic
into cordova.js, butŠ
We can and probably will provide templates which include a style saying
³use font: Slate Pro². That¹s all you need for the platform engine.
If we did use cordova.js instead of having serve provide the .css file,
we¹d still need a way to get the fonts to the browser-as-engine case
(which is handled by the .extra code).
In case you¹re curious, installing fonts to a user¹s system is a no-go for
a number of reasons (* it¹s painful to try to manage ‹ often requiring
administrative privileges which isn¹t something we require, * Licensing is
wrong, * it pollutes the user¹s font-space or their computer¹s font-space
if shared, * it doesn¹t work if the user is visiting serve from a device
other than localhost).
Re: serving extra css
Posted by Michal Mocny <mm...@chromium.org>.
..also, your idea of "automatically look for a well known file" could be
done within the application by feature detecting that its running in a
desktop browser. Would it be prehibitive to dynamically inject the style
on startup from the app itself?
-Michal
On Mon, Feb 3, 2014 at 6:25 PM, Michal Mocny <mm...@chromium.org> wrote:
> Wouldn't this be better handled by Brian's dream of browser-as-a-platform?
> I understand that this solves your immediate problem, but I'm not sure
> extending serve is really the right long term solution for this.
>
> -Michal
>
>
> On Mon, Feb 3, 2014 at 2:01 PM, Josh Soref <js...@blackberry.com> wrote:
>
>> cordova serve is a pretty good way to test out how an application will
>> work on a device.
>>
>> We¹d like to be able to easily transparently add in some platform specific
>> things (today, that¹s fonts which exist on the platform but aren¹t
>> necessarily on the system running the browser that¹s viewing the pages
>> from cordova serve).
>>
>>
>> https://github.com/jsoref/cordova-cli/commit/4ee156f1e588c329846a7ce5610a59
>> 88a12b2eea<https://github.com/jsoref/cordova-cli/commit/4ee156f1e588c329846a7ce5610a5988a12b2eea>
>>
>> Is a way to do this (for IE and Firefox **). I¹m looking for some feedback
>> on it.
>>
>> That would be accompanied with a change to a platform¹s parser, such as:
>>
>> diff --git a/src/metadata/blackberry10_parser.js
>> b/src/metadata/blackberry10_parser.js
>> index 4ed280d..9244876 100644
>> --- a/src/metadata/blackberry10_parser.js
>> +++ b/src/metadata/blackberry10_parser.js
>> @@ -80,6 +80,15 @@ module.exports.prototype = {
>> www_dir:function() {
>> return path.join(this.path, 'www');
>> },
>> +
>> + serve_extra_style:function() {
>> + return 'fonts.css';
>> + },
>> +
>> + serve_extra_style_dir:function() {
>> + var lib_path = path.join(util.libDirectory, 'blackberry10',
>> 'cordova', require('../../platforms').blackberry10.version);
>> + return path.join(lib_path, 'extra_www');
>> + },
>>
>> staging_dir: function() {
>> return path.join(this.path, '.staging', 'www');
>>
>> And then the platform would have an extra_www/fonts.css file Š
>>
>>
>> I¹m not entirely happy with the use of the parser functionality to do this
>> ‹ does anyone have a preference?
>> I could have serve automatically look for a ³well known file² within a
>> platform, and serve it if it exists.
>>
>>
>
Re: serving extra css
Posted by Michal Mocny <mm...@chromium.org>.
Wouldn't this be better handled by Brian's dream of browser-as-a-platform?
I understand that this solves your immediate problem, but I'm not sure
extending serve is really the right long term solution for this.
-Michal
On Mon, Feb 3, 2014 at 2:01 PM, Josh Soref <js...@blackberry.com> wrote:
> cordova serve is a pretty good way to test out how an application will
> work on a device.
>
> We¹d like to be able to easily transparently add in some platform specific
> things (today, that¹s fonts which exist on the platform but aren¹t
> necessarily on the system running the browser that¹s viewing the pages
> from cordova serve).
>
> https://github.com/jsoref/cordova-cli/commit/4ee156f1e588c329846a7ce5610a59
> 88a12b2eea
>
> Is a way to do this (for IE and Firefox **). I¹m looking for some feedback
> on it.
>
> That would be accompanied with a change to a platform¹s parser, such as:
>
> diff --git a/src/metadata/blackberry10_parser.js
> b/src/metadata/blackberry10_parser.js
> index 4ed280d..9244876 100644
> --- a/src/metadata/blackberry10_parser.js
> +++ b/src/metadata/blackberry10_parser.js
> @@ -80,6 +80,15 @@ module.exports.prototype = {
> www_dir:function() {
> return path.join(this.path, 'www');
> },
> +
> + serve_extra_style:function() {
> + return 'fonts.css';
> + },
> +
> + serve_extra_style_dir:function() {
> + var lib_path = path.join(util.libDirectory, 'blackberry10',
> 'cordova', require('../../platforms').blackberry10.version);
> + return path.join(lib_path, 'extra_www');
> + },
>
> staging_dir: function() {
> return path.join(this.path, '.staging', 'www');
>
> And then the platform would have an extra_www/fonts.css file Š
>
>
> I¹m not entirely happy with the use of the parser functionality to do this
> ‹ does anyone have a preference?
> I could have serve automatically look for a ³well known file² within a
> platform, and serve it if it exists.
>
>