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