Chuck,
thanks!
> On 10 Jan 2020, at 7:23 AM, Chuck Hill <hill.ch...@gmail.com> wrote:
> I am pretty sure it is the relative URLs in font-awesome.min.css. They get
> evaluated as relative to the URL of your page not the URL of that CSS.
That idea occurred to me too, but I think in that case it would not work (would
not render the characters properly), for the fonts would not be loaded at all
from such bogus URLs, would they?
Anyway I have tried to change the URLs in the CSS file to absolute ones like
this:
===
@font-face {
font-family: 'FontAwesome';
src: url('/dms/css/font-awesome/fonts/fontawesome-webfont.eot?v=4.6.3');
src:
url('/dms/css/font-awesome/fonts/fontawesome-webfont.eot?#iefix&v=4.6.3')
format('embedded-opentype'),
url('/dms/css/font-awesome/fonts/fontawesome-webfont.woff2?v=4.6.3')
format('woff2'),
url('/dms/css/font-awesome/fonts/fontawesome-webfont.woff?v=4.6.3')
format('woff'),
url('/dms/css/font-awesome/fonts/fontawesome-webfont.ttf?v=4.6.3')
format('truetype'),
url('/dms/css/font-awesome/fonts/fontawesome-webfont.svg?v=4.6.3#fontawesomeregular')
format('svg');
font-weight: normal;
font-style:normal
}
===
and the problem persists. It persists even if I use complete URLs incl. the
server, like “http://localhost:56005/dms/css/font-awesome...”, which I tried
too.
So, triple alas, that would not be the culprit, I fear.
Thanks and all the best,
OC
>> On Jan 9, 2020, at 5:48 PM, OCsite via Webobjects-dev
>> <webobjects-dev@lists.apple.com> wrote:
>>
>> Gentlemen,
>>
>> my application does some R/R loops and creates some sessions/main components
>> which I believe it should not.
>>
>> Lately, from a webdesigner, I have got some improvements of the look of my
>> application, which essentially looks like
>>
>> <link rel="stylesheet" type="text/css"
>> href="/dms/css/font-awesome/css/font-awesome.min.css"/>
>>
>> in the html header. The CSS starts with
>>
>> ===
>> /*!
>> * Font Awesome 4.6.3 by @davegandy - http://fontawesome.io - @fontawesome
>> * License - http://fontawesome.io/license (Font: SIL OFL 1.1, CSS: MIT
>> License)
>> */@font-face {
>> font-family: 'FontAwesome';
>> src: url('../fonts/fontawesome-webfont.eot?v=4.6.3');
>> src: url('../fonts/fontawesome-webfont.eot?#iefix&v=4.6.3')
>> format('embedded-opentype'),
>> url('../fonts/fontawesome-webfont.woff2?v=4.6.3') format('woff2'),
>> url('../fonts/fontawesome-webfont.woff?v=4.6.3') format('woff'),
>> url('../fonts/fontawesome-webfont.ttf?v=4.6.3') format('truetype'),
>> url('../fonts/fontawesome-webfont.svg?v=4.6.3#fontawesomeregular')
>> format('svg');
>> font-weight: normal;
>> font-style:normal
>> }
>> ===
>>
>> Then, things like
>>
>> <i class="fa fa-plus" aria-hidden="true"></i>
>>
>> are used throughout the component templates, with the appropriate classes
>> looking like
>>
>> ===
>> .fa {
>> display: inline-block;
>> font: normal normal normal 14px/1 FontAwesome;
>> font-size: inherit;
>> text-rendering: auto;
>> -webkit-font-smoothing: antialiased;
>> -moz-osx-font-smoothing:grayscale
>> }
>> .fa-plus:before {
>> content: "\f067"
>> }
>> ===
>>
>> It seems to render the characters all right, but the reason why I am writing
>> is that as soon as the <i class...> thing is used in the page, I am getting
>> VERY suspicious R/R loops and extra sessions. Namely, what I see is that
>>
>> 1. normal R/R loop for the standard URI "...myapp/wo/SID/COMPONENT" happens,
>> uses the long-ago-created session for SID as it should, ends by
>> application.sleep(). Precisely same as if there's no <i class...>, so far so
>> good.
>>
>> But, if there _is_ an <i class...> thing in the page, I immediately and
>> automatically (without doing anything in the browser) get another four R/R
>> loops (far as I can say, served by the same thread as the first normal one);
>> each of them creates a new session and a Main page (which is never shown
>> anywhere), and if I log out its context().request() in the newly created
>> session's awake(), it seems self-evident these R/R loops are created for the
>> URIs from the CSS header, namely
>>
>> 2. ../fonts/fontawesome-webfont.woff2?v=4.6.3
>> 3. ../fonts/fontawesome-webfont.woff?v=4.6.3
>> 4. ../fonts/fontawesome-webfont.ttf?v=4.6.3
>> 5. ../fonts/fontawesome-webfont.svg?v=4.6.3
>>
>> (For some reason, for those .eot URIs this does not happen.)
>>
>> Now, I understand that the fonts need to be loaded; nevertheless, it does
>> not feel right that a full-fledged R/R loop, which creates a session and a
>> Main page, is created and run for this.
>>
>> Is that right? As always, I might be overlooking something of importance,
>> but to me this feels wrong; there should be no need to create a full-fledged
>> R/R for this, far as I understand. There are many other
>> resources/CSSs/javascripts the application uses (incl. the very
>> "font-awesome.min.css"), and none of them causes this; they all are loaded
>> without R/R loops, without sessions, etc.
>>
>> The designer knows sweet zilch of WebObjects and says if there's a problem
>> at all, it's caused by my application around his perfect and flawless CSS.
>> Well perhaps it is indeed; but I can't see the culprit.
>>
>> Does anybody here understand the problem and can say how to fix it (or, at
>> worst, that it is unfixable in principle and I have to bear with it)?
>>
>> Thanks a lot,
>> OC
>>
>> _______________________________________________
>> Do not post admin requests to the list. They will be ignored.
>> Webobjects-dev mailing list (Webobjects-dev@lists.apple.com)
>> Help/Unsubscribe/Update your Subscription:
>> https://lists.apple.com/mailman/options/webobjects-dev/hill.chuck%40gmail.com
>>
>> This email sent to hill.ch...@gmail.com
>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
