Hi OC, 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.
Chuck > 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
