Planned web site down time

You could try this: http://pastebin.com/8qhwd3td

It makes the IMG elements in the header part blocks rather than inlines. The advantage of doing this is that NetSurf applies the width and height of the image to the IMG box before it gets the image.

Currently they are inlines (display:inline;). You can’t set width / height on non-replaced inlines but you can on replaced inlines. Currently NetSurf treats the boxes as non-replaced inlines until they are actually replaced.

So my patch sets them to display:block; and means that the width and height are applied to the box before the image is available, so it doesn’t get resized later. You could also use inline-block, etc.

Out of interest, how exactly did you change it to make it render more quickly in NetSurf? Was there anything particular you avoided?

Tables and images.

The site used to be more compatible with pre-CSS browsers like Fresco and Browse, so it used a basic table layout to get things like the right hand sidebar, or right-floated ROOL cog in the header. NetSurf appears to have quite slow table handling, with lots of unnecessary refreshes during page loading, so that slowed it down.

Further, the previous design didn’t occupy the full width of the page and had a drop shadow effect. Even when images were loaded as backgrounds via CSS into DIVs for the right hand, left hand and corner parts of the shadow, it still seemed to want to refresh the entire page each time a new image loaded and didn’t seem to do much in the way of caching.

The new design didn’t set out to go faster on NetSurf, but it seemed about time that the markup was cleaned out and better use of more efficient CSS was made. In passing, I decided that the centred, drop shadow style page looked outdated, so made it full width. This means fewer images for NetSurf to redraw with. Which brings us to:

It makes the IMG elements in the header part blocks rather than inlines. The advantage of doing this is that NetSurf applies the width and height of the image to the IMG box before it gets the image.

NetSurf has always seemed to ignore the width and height specified in IMG tags. This makes it suck quite a bit on all sorts of image heavy pages as it constantly resizes things which really, it has absolutely no reason whatsoever to have sized incorrectly in the first place. IMHO, this is a fairly serious core flaw that’s been in NetSurf for as long as I can remember and really ought to be fixed in the browser.

I’m a little unwilling to start hacking around with CSS just to try and make it work better in that one browser; it might make it work worse in others. That said, limiting the example to the specific case of the two header images perhaps won’t have a big impact or cause problems elsewhere so I may patch it into the CSS and try it out for a while.

I may patch it into the CSS and try it out for a while.

Yeah, that seems to make a pretty significant improvement in NetSurf. It still seems to want to redraw the page lots, but at least things aren’t moving around while it does so. I’ve applied a similar fix to the Hub login indicator so that the whole header region becomes stable.

What’s more, there was a curious issue with Firefox 3 and 4 where it rendered a border below the Hub login indicator image, forcing the brown navigation strip to be slightly too high. It’s some kind of Quirks Mode issue I think, because I’d seem similar effects in the Wiki under Safari and Opera back when the DTD declared the pages as XHTML 1.1 strict, rather than XHTML 1.0 transitional ¹. Curiously, the block vs inline CSS change has stopped this from happening so the rendering in Firefox is now actually better rather than the same or worse.

(Now, if only I could figure out why Firefox thinks it needs a horizontal scroll bar…!).

The updated CSS file will go into SVN soon. Thanks for the patch! :-)

¹ Yes, we’re technically serving “tag soup” pages with the wrong MIME type because too many browsers break otherwise and half the Wiki would break if the browsers tried to enforce valid markup there, thanks to HTML 4-style coding in several pages. We could filter such things through an XHTML rationalisation engine such as Hpricot, but that slows it down and the results aren’t always as expected by the author.

The updated CSS file will go into SVN soon.

Done. See Revision 328.

I proceeded to get carried away with common cases! I’ve applied a similar patch to viable images in the forum (notably, not the RSS feed icon at present) and Hub. Doesn’t make a dramatic difference but it’s an improvement all the same.

The updated Beast and Hub applications haven’t yet made it into SVN. It’ll all check checked in eventually.

I still wish the NetSurf team would fix it (“How Hard Can It Be?” :-)), since that would improve its behaviour significantly for a huge number of other web sites and stop me spending any more time with essentially unnecessary CSS patches.

NetSurf has always seemed to ignore the width and height specified in IMG tags. This makes it suck quite a bit on all sorts of image heavy pages as it constantly resizes things which really, it has absolutely no reason whatsoever to have sized incorrectly in the first place. IMHO, this is a fairly serious core flaw that’s been in NetSurf for as long as I can remember and really ought to be fixed in the browser.

Yes, as I said it’s to do with boxes generated by the IMG tag getting display:inline; unless styled otherwise. The CSS spec describes how you lay out boxes with display:inline; and it’s different for non-replaced and replaced inlines.

The problem in NetSurf is we don’t treat boxes generated by IMG as replaced until we have the fetched/decoded image ready.

Unfortunatly it will require quite invasive changes to alter that behaviour. This will certainly change some time though. We need to rewrite the layout engine for JS/DOM events/dynamic CSS in the long term anyway. Or it might get done sooner in the existing layout engine, but I have other higher priority work to do.

I proceeded to get carried away with common cases! I’ve applied a similar patch to viable images in the forum (notably, not the RSS feed icon at present) and Hub. Doesn’t make a dramatic difference but it’s an improvement all the same.

TBH, just setting “img { display: inline-block; }” is probably all you need for avoiding this problem in NetSurf. (Since width & height apply non-replaced inline-blocks.) No idea what IE6 would make of it though. :) There should be no need to fiddle with margins then – it would be aligned by the text-align property as the original inline images were.

What’s more, there was a curious issue with Firefox 3 and 4 where it rendered a border below the Hub login indicator image, forcing the brown navigation strip to be slightly too high. It’s some kind of Quirks Mode issue I think, because I’d seem similar effects in the Wiki under Safari and Opera back when the DTD declared the pages as XHTML 1.1 strict, rather than XHTML 1.0 transitional 1. Curiously, the block vs inline CSS change has stopped this from happening so the rendering in Firefox is now actually better rather than the same or worse.

Not having seen the problem I can only guess, but I suspect it wasn’t a border below the image. I think the bottom of an inline image is supposed to be aligned with the baseline of its line box. So the area below the image was probably below the baseline.

…and didn’t seem to do much in the way of caching.

The cache is fixed in recent development builds and should be fine in the soon-to-be-released NetSurf 2.7. :)

Good to hear :) As a regular user of NetSurf it’s good to hear positive updates.

Can the ‘Forum’ link be restored to its rightful place on the navigation bar? My muscle memory keeps forcing me to click on ‘Software’ instead. :-(

Can the ‘Forum’ link be restored to its rightful place on the navigation bar?

I can barely remember where it was before, now… The new ordering IMHO makes much more sense left to right. I’m sure you’ll get used to it soon :-D

The cache is fixed in recent development builds

Good stuff; looking forward to 2.7.

I’ve noticed that http://www.riscosopen.org/ (as linked to from the NetSurf website homepage and NetSurf’s default welcome page), now redirects to https://www.riscosopen.org/content/ rather than http://www.riscosopen.org/content/ . Is the https deliberate?

I reckon that the wiki is crying out for some breadcrumbs at the top of the page. Is this easy to add or is the problem that pages haven’t been created in a logical structure that’d suit breadcrumbs?

Is the https deliberate?

Yes, because Hub only shows you as logged in if you’re using HTTPS ¹. I’m considering general promotion of all HTTP requests to HTTPS, since the number of people who would then be unable to view the site has now fallen to pretty much zero.

¹ Hub maintains login information across Ruby processes by using a DRb user credentials server process. This holds all information on logged in users in a hash, keyed by a random string. The cookie sent to client browsers contains this random string. Since the Hub server is only accessible by a Unix domain socket in the ROOL case, it might seem excessively paranoid to mark this cookie as only to be sent over secure connections. However, were someone in the middle to intercept the cookie over plain HTTP, they could easily construct a malicious HTTP request to the ROOL servers quoting the same cookie and masquerade as the user who’s key had been captured.

I reckon that the wiki is crying out for some breadcrumbs at the top of the page.

That’s what “Documents” is there for.

Bear in mind many users have relatively low screen resolutions with restrictions on maximum browser page width.

…that was a bit cryptic. At roughly 800px wide, considering 800×600 to be a probable lowest common denominator, we get this:

…so you can see it’s very tight for space with “Bounties” added.

…and final follow-up of myself (!) – one option might be to reverse things. Right now, the Documents page summarises the idea of there being a Wiki and lists various additional static bits of documentation.

We could instead work on some usability issues with the Wiki home page (it’s risking clutter, too many links/sections perhaps) and have the Wiki refer to the static documents. Then the “Documents” link in the navigation bar would just take you straight into the Wiki directly, which would be altogether more useful.

I think you may have misunderstood what Steve was getting at. Instead of adding a ‘wiki’ link to the main banner at the top of the page, I think he was asking for links to be added to the top/bottom of each wiki page, similar to the “Forums → Announcements”, links you get when browsing the forums, or the links you get when browsing the photo galleries, etc.

FWIW all the PRM & HAL wiki pages do have breadcrumb-style links at the top of each page. We could “easily” adopt the same format for the rest of the wiki pages, although I think it would be better if there was support for doing this within the wiki itself. I’m not sure whether a simple hierarchical structure or something more freeform like mediawiki’s categories would be best, but by having support for such a feature built in to the wiki it would make it a lot easier to add and maintain content.

And speaking of the wiki – attempting to apply an edit when using NetSurf results in the wiki complaining that I don’t have JavaScript turned on. Not terribly useful!

I’m not sure whether a simple hierarchical structure or something more freeform like mediawiki’s categories

Instiki supports categories, though I may have been forced to disable support for the Wiki syntax required to use them as part of I2 migration (it relied on colons in a way that clashed with existing page titles with colons in, IIRC, BICBW – it’s been a while since I did the migration now).

As for structure, there is none. The pages are stored flat, as indicated by the ‘All pages’ view. It may be possible to infer some kind of structure from the Wiki’s internal referencing system that shows which pages are linked to which, but it’s not immediately clear how this would be done.

For reference, we have almost 2,500 pages in the Wiki at present with over 8,500 individual page revisions.

…actually, categories work. See just underneath the “Documentation” heading of, and/or view the source for:

https://riscosopen.org/wiki/documentation/show/Web%20site%20help

You write “category:CategoryName” at the top of the page to mark it as belonging in a particular category. Case is significant insofar as the category you name is shown directly in the view, so it needs to be ‘elegantly’ human readable. As you can see from the above example, Instiki lists the category and category link at the top; the link takes you to pages in that category.

With a couple of thousand pages, though, it’d take a while to go back and set up categories on them all! There would also need to be a broad consensus on categories for it to be a useful feature IMHO.

Ah, excellent! I suppose I should have checked the Insitiki help first. And it looks like pages can belong to multiple categories, too. I’ll start a thread where we can suggest some initial category names.

Post-script edit by Administrator: Thanks for getting this started. Readers can find the thread here.

If you can’t access Firefox, Chrome, Opera, Safari or NetSurf from your current location, you’d be better of waiting until you can.

I agree!

Should Firefox 3.6.10 under (ahem) Vista be OK?

I inserted

#* p<. [[File:Riscosinstallation-tb-v1-01.png|RISC OS Supervisor prompt launching GUI:pic]]

p=. [[rool_cog.png|ROOL cog:pic]]

Internal Error

An application error occurred while processing your request.

[Edit: Inserting RANDOM GARBAGE does just that.]