mrchocky: 'The point is, in a browser, the difference between style guide compliance and not is quite small. Most of the browser interface is beyond the control of the browser developers - it's actually in the web page you're viewing. And those certainly won't be style guide compliant.'
I really hope you were just clutching at straws and don't actually believe that. Even the web page you're viewing doesn't necessarily (shouldn't) dictate how you interact with that website (eg. how a browser for the blind might let you navigate a site). In a visual rendering client the only interface elements that a website controls are navigation 'buttons' (text, pictures) between and amongst pages. Compared to any normal application (music player, DTP package, graphics package) a browser is noteable for the distinct /lack/ of special interface elements it must implement that might be 'outside the scope', so to speak, of an OS style guide. From an interface perspective a browser is really just a document (html) viewer with the ability for document content to provide page turning (nothing unique to browsers). Document viewers benefit the /most/ from style guide complience - because there's no other function than page turning the user really shouldn't have to learn how to do anything. They should already know how to do it (because it behaves identically to all other applications), and be able to do it quickly and without thought.
Or to put it another way, when you can't use a document viewer because it isn't style guide complient you notice it /much/ more than if the application were more complex and perhaps understandably less intuitable.
Furthermore, because it's a document viewer, and you may want to view /many/ (millions) documents through the viewer of the course of its/your lifetime, again, the interface needs to be perfect. Maybe you could put up with a clumsy interface that was different to everything else you use for a special application you only have to make yourself use once a year, but for something you might want to use multiple times a day? It would drive you insane. And what of basic functionallity required of a document viewer? Copying content out (clipboard), printing, saving in alternate formats etc?
I find it so depressing that the person best able to port Firefox doesn't understand the importance of getting the interface right. If you do nothing else at least get the overall window to behave properly in terms of resizing (appropriate to the current contents as per NetSurf when it's working right) and interacting with other windows (stack order).
'if you wanted a fully integrated version of Firefox in RISC OS, it would take many months longer. I don't think anyone wants that.'
Hmmm? What's that now? Haven't we been waiting for many many years for a decent browser? Do you honestly imagine anyone would even /notice/ it taking months longer? How /could/ they notice? The only person the timescale ultimately effects is yourself - how much lost earnings you suffer, and how long you have to code before gaining the satisfaction of release. Of course there's nothing stopping you doing this incrementally - getting the basic working release done first and then the RISC OS 'total conversion', but from your comments I doubt that a total conversion will ever happen simply because you don't seem to realise how important it is. For that reason I won't be supporting the project.