Post a Comment
Yup, I have blogged about web browser memory problems on embedded devices here:
http://eugenia.blogsome.com/?s=verizon (search for the word "verizon" if the right article doesn't come up automatically by clicking the link)
Depending on the browser, you need at least 15-20 MBs of *available* RAM to get a good experience out of web browsing these days. And this number is going to go up as more sites move to CSS-only (rendering complex CSS layouts requires more CPU and RAM rather than when rendering plain HTML).
On the other side, if layout is only (ie correctly) done in CSS, you can have a very good view of every website without considering much of the CSS.
So it should be more easy to write a lightweight browser giving a good view than with older, heavy html, designs.
Lynx is a very good test if a website was done right or wrong...
I am not sure I understand you. Creating a css-only browser is not easy, it's in fact more difficult than having HTML 4 support. And a CSS-only web page takes A LOT of CPU. And it won't be compatible with the BULK of mobile/embedded/text browsers. This is why osnews will remain cHTML.
And Lynx is terrible, although very popular. If you want a good text-mode browser try ELinks.
Well, if a page is done "right", the structure is in the html, whereas the design is in the css. Now it is easy to ignore the CSS and still have a good structured page. Next thing would be to accept colors from the CSS, perhaps some framings, and graphics. This is not heavy yet. You can get rid of exact measurements and sizes.
Sure there are more decent text browsers than lynx. I just wanted to point out that a good designed website can be very good readable _even_ on lynx. Now put some graphics support and what I wrote above into lynx and you have a primitive browser, which still gives relatively good looking and for sure good readable output.
Problem is, this really works well with _only_ good written html pages (where _every_ design thing is in CSS!).
For example, this website gives high CPU load (because of the transparency thing):
http://pong2.berlios.de
Still you can have fun with it with "every" primitive browser, too.
<blockquote>The browser doesn't support a lot of Internet standards: no Flash, no movie files, no images other than .GIF and .JPG (and possibly .PNG), no Java</blockquote>
Sounds like heaven to me...
you'd think he might consider testing its PNG capabilities before writing the review, it would be interesting to know for sure.
but given the fixed layout of the sites html, SPECIFICALLY:
<table width="765" border="0" cellpadding="0" cellspacing="0">
<COL width="155">
<COL width="610">
Opera rendered in 'normal' EXACTLY as it should... It should ONLY display properly on <800 pixel displays in opera with 'Fit to width' / 'Small Screen Rendering' on.
Which I still say fixed width is just bad site design. Remove the width= on the table and the second column, and make the site actually USE the clients browser window instead of crippling it on small screens, and making it a crappy little stripe down the middle of the screen on larger ones.
I am sorry, but you didn't get it right. The mobile browsers are AUTODETECTED on osnews and they are served a DIFFERENT source code. Didn't you see in the screenshots that it looked different than the version you quoted?
The mobile version of osnews has width 100%, not 765px.
Edited 2006-08-19 05:00
>> I am sorry, but you didn't get it right. The mobile browsers are AUTODETECTED on osnews and they are served a DIFFERENT source code
My bad, although that seems like an awful lot of effort when you could probably just write once and be done with it. (well, except for WAP which should get it's own since that's not HTML)
Hey, at least I didn't do the XHMTL fanboy ranting and raving about how you used tables for layout.
Given how it rendered though, I would wonder if there isn't some element on the page pushing it to that limit - the odd spacing of the navigation table for example makes me think something's not kosher there.
Do you have any cgi flags in place that can 'force' OSNews into feeding specific versions? I'd be interested in seeing what the desktop copy of Opera does at various settings (such as the small screen previewer)
> I would wonder if there isn't some element on the page pushing it to that limit
Nope, it's all 100%. It makes sense for normal desktop websites for the browser to have such a 800px limit. Pocket IE has this limit too. Webkit on Symbian too. However, when a site does fit on the native res of the device, they don't stretch to 800. That's where the bug is. The idea for 800px is correct, it's just that Opera DS' implementation needs polishing. My main problem is that other versions of Opera Mobile don't have this problem.
Well, I just got my hands on one for a couple hours - and I think I found the 'issue'
It is NOT Opera mobile, but a modified version of full blown opera able to handle full blown XHTML... The browser in normal (non small screen) operation is SUPPOSED to emulate a 800x600 display 'shrunk' to fit on the top lcd, and a zoomed in box on the bottom one. Really slick as you are able to send it to most any site 'desktop' opera can view and have no problems (apart from scrolling around a whole lot, though the controls for that are fairly intuitive)
As such this site should be sending the DS the full 'normal' version of the site, not the reduced.
>Hey, at least I didn't do the XHMTL fanboy ranting and raving about how you used tables for layout.
XHTML does not work as well as cHTML does for all the browsers we support. We don't have this special support only for mobiles, but for embedded and text mode browsers. And these browsers only barely manage to do HTML.
huh, intresting. When you start doing real web work, you'll know there are just times you have to use tables for containers. The tables on osnews DO encapsulate data, and its a valid use for tables.
google news is an excellent example. also, php.net is all payed out via tables. The simple fact is, you can't do everything you can do with tables compared to css. Visa versa as well. Its best for any real programmer not to be religious about these type of ordeals.
Nintendo has come a long way since the NES. I find the DS pretty cool. Hope to get one soon. I use the opera web browser on the desktop and on PDAs.
I think I'll personally get a DS for work purposes. I've a wireless network setup at work, I'd find it very nice to be able to control my administrator applications from a hand help device. I've thought about the Axim and others, but just don't want to fork out the money on large devices.
>Which I still say fixed width is just bad site design. >Remove the width= on the table and the second column, >and make the site actually USE the clients browser >window instead of crippling it on small screens, and >making it a crappy little stripe down the middle of the >screen on larger ones.
Fixed width is bad, but the main problem of not having fixed width is, that lots of webdesigns are done by graphics people and they usually are used to doing print layouts, so things like that happen, often you
want to have one column fixed the other resizable, you need a fixed width attribute, the proper way of doing this would be css not tables, but as long as several resizing css attributes are broken you have to do it the old way and have to face it that browsers with small screens run into problems. (have you ever tried to do a decent table free css only layout without any hacks which should also be able to resize and adjust? Good luck especially if the whole thing has to run on the IE.
Anyway back to topic, the loading time looks severely like everything is routed through a big firewall of nintendo, as the article notices, opera for mobile devices is not that slow, there must be something else fishy going on. Now given the fact that Nintendo tries to be "family friendly" they probably really route everything through a proxy so that they can block content upon request, it would make sense (for them).
it may just be that the DS is trying to handle the full version of the website whereas opera mini is fed through opera's converter to sanitise it for use on small screens, the DS has a lot more work to do, first rendering and then scaling full web pages, and not much memory with which to do it
I have two Nintendo DS Lites (the previous model was too bulky for my liking) and Opera is currently my favourite desktop webbrowser.
My cellphone operator T-Mobile now has more than 600 free Nintendo hotspots in the Netherlands, hopefully this will further increase as browsing at home with a Nintendo DS instead of using my PC doesn't make much sense to me, but online gaming is nice though. But if I can freely browse the web for checking the latest news and my emails while travelling by train (airports are already supported) it would become an excellently useful feature to me. My cellphone's screen is just a bit too tiny and a laptop is not appealing for me for taking with me while i.e. going on vacation.
I have Opera Mini on my mobile phone and that is far from slow, it is faster than every other included browser I have seen so far.
So it is hard for me to believe that the Opera team messed this one up.
Let's see what other reviewers will say, especially if they have a version in their native language.
Opera Mini doesn't get the data from the website, it get's it from an Opera server that preprocesses the data (e.g. sizing down the images). It has less data to download and less code to render (and Opera sees all the websites you are surfing but that's another topic).
Opera DS however deals directly with the original data from the website like a browser on a PC does. But it's hardware is much more limited.
That's why it's so slow compared to Opera Mini.
It appears to not be 800 pixels fixed, but detecting the content, assuming 100% as 800 pixels if no other numbers are declared...
Case in point, the screencaps from the IGN site are of the normal HTML content, not a mobile browser version... Their normal site is designed for 1024 across.









