plugwash wrote:

i'm not sure how choosing different skins for different anonymous users (or for
the same logged in user on different devices( would affect caching but i presume
it could be made to work somehow.

do you find any of the existing mediawiki skins suitable or do you wan't a skin
specifically for portables?

doug.ransom wrote:

I always log in as anonymous user. I'd suggest the behavior to default to
single-column for PDAs or small screen devices.

I don't think you need to sniff the user-agent. I think you just need to
reference a different css with the media="handheld" attribute in a link tag to
set single column.

kjetil.lenes wrote:

(In reply to comment #2)

I always log in as anonymous user. I'd suggest the behavior to default to
single-column for PDAs or small screen devices.

I don't understand this. How do you default to single-column? Because the problem (at least on my HP with
Win 2003) is that I get almost all text on the right side of the (small screen), an on the bottom of
this, on the left side I get the log-in text. And on the very bottom, to the left, we get to the search
box. Ideally I'd like the searchbox almost on the top. A specific skin would be OK if it solved this

doug.ransom wrote:

I recently found a setting in Pocket IE user agent - you can change it to one column
rather than desktop layout (it ignores a lot of the posiitioning css). This works quite well
for reading, haven't tried the searchbox etc.

ayg wrote:

Note that the problem is broader than just stylesheets, as some handhelds don't
support CSS, but see also bug 7020.

ayg wrote:

*** Bug 8464 has been marked as a duplicate of this bug. ***

wikipedia wrote:

Hi folks,

Wow, I had a bit of time and thought I'd figure out what might've been done to support small-screen-format devices (PDAs/phones et al) and right away found this bug and note that it has sat here for 2.5 years. Well, I suppose the fraction of pages browsed on MediaWiki-based sites is still "small" for small-screen-format devices, but I bet it is rising (publishing some numbers, even just percentages, would be cool).

Anyway, I attempt to browse wikipedia reasonably often using my Palm Treo, and i figured out a way to sorta make it work, and that's to halt the page download once > ~40K of a page has been retrieved. That way the style sheets aren't invoked and the page remains pretty much as "plain" HTML-based text, and the Treo browser's (Blazer(not)) built-in word-wrap has done it's thing, and such pages are reasonably readable. However, I typically stop the page load before images are brought over, and most annoyingly, the editable "search" entry field is way down at the "bottom" of the page, instead of up near or at the top.

These days, I do quite a bit of web browsing and keep-up-with-what's-happening-in-various-fields reading using my Treo because I usually have it with me, as opposed to lugging around my lapstation.

So, in closing, I want to encourage you folks to work on addressing this issue. A number of sites out there, e.g. http://slashdot.org/palm and http://www.google.com/pda, have long ago figured out how to nail up support for small-screen-format devices in parallel to their mainline offerings, and it is long past time for MediaWiki and Wiki*.org to do the same.

thanks,

JeffH

roger.stringer wrote:

On Palm Treo and Centro devices using the Blazer web browser, you can go to Preferences for the web browser, set "Fast Mode" and set "Disable Cascading Style Sheets" to work around the problem.

With the resolution of bug 7020 (r40414), I'm inclined to resolve this as fixed, as at this point it doesn't seem to be an issue with the software.

Handhelds with either support the Handheld.css page or not, but I don't see any further work that can be done from a software standpoint at this point. Perhaps certain pages need to be redesigned or perhaps Handheld.css needs more (or better) code, but that seems outside the scope of Bugzilla. Individual projects control their own CSS pages.

Anyone else care to weigh in?

The new mobile gateway at http://m.wikipedia.org is a big step forward here. I suspect we can still improve the base styles a bit, but it's tough...

We are considering setting up an auto-forward to the mobile-optimized site for recognized user-agents, which would help people find it. (As long as they can choose to get back!)

hcatlin wrote:

I'm marking this ticket as closed, because its not very specific and
I got my job to fix this entire class of problems.

I mean, our goal is to improve this with the m.* subdomain, but its
never, ever going to be a goal that is fully attainable. So, these
kinds of tickets aren't helpful, since they are general.