422473 - Pages that support multiple OS via SHOWFOR plugin won't look right without Javascript

Status: VERIFIED WONTFIX

(support.mozilla.org :: Knowledge Base Software, task)

Description

[Nelson Ko [:nkoth]]

The SHOWFOR plugin which is used to render platform sensitive information depends on Javascript to manipulate css.

This requirement could be a problem for in-product help, because it is likely that many people will be using Firefox without Javascript. The pages will still show but OS/platform detection fails and content for all platforms show all together (which could be difficult to read).

Need to know if this is a blocker, and what actions can we take to address this?

Comment 1

[Mike Shaver (:shaver -- probably not reading bugmail closely)]

The traditional mechanism to solve this is to

- emit all the spans or images with a default-hidden CSS
- emit a default that's in <noscript>
- JS-write a rule at the beginning of the page that sets display according to OS (and weep about the block/inline issue)

Comment 2

[Laura Thomson :laura]

Limited to making the SHOWFOR show Windows / Firefox 3 as the default if JS is disabled.

Comment 3

[E. Cooper [:ecooper]]

With some general tweaks to wikiplugin_showfor.php and wikiplugin_div.php, the content is easily taken care of. All of the content divs/spans are run through them. The problem is with the toc. 

That is, while the actual content will display properly for Windows/ff3 if Javascript is disabled, the toc will still list all the headings for the page. Anyone have any ideas? maketoc is handled by lib/tikilib.php

Comment 4

[David Tenser [:djst]]

Why can't we just make the default css (for people without javascript) be that of Firefox 3 + Windows? That should work for both the TOC and the content, shouldn't it?

Comment 5

[Chris Ilias [:cilias]]

In February, out of 12,007,164 visitors, only 287 had JS disabled. That's around 0.002%. Given what little impact this bug has and the limited resources for 1.1, I think we should move it off the 1.1 list.

Comment 6

[David Tenser [:djst]]

Thanks Chris; very good rationale for pushing it out.

Comment 7

[Mike Connor [:mconnor]]

Why even bother fixing it then?  Something that impacts 0.002% of site visitors is rarely, if ever, going to be a priority in finite time...

Comment 8

[David Tenser [:djst]]

Because the content looks broken for those users.

Comment 9

[Mike Connor [:mconnor]]

Sure, but anyone with JS disabled is used to that.  My point is that 287 users out of 12M is not significant, and doesn't seem like an effective use of resources.

The big issue is that once you make the decision to support no-JS, you need to build all of your UI to support no-JS.  That starts becoming a significant portion of your finite developer resources, or constrains you to 1996-era UI if you don't want to build and QA with/without JS enabled.

For example, we've talked about inline display of relevant articles if you say "No" to "Did this article solve your problem?"  Now you need to build a separate UI for no-JS cases, because you can't keep that content hidden by default.  Or you have to always show the related articles, and remove the dynamic UI.

This just doesn't seem like a justifiable use of resources, based on the numbers.  If you've got spare webdev cycles that you wouldn't use otherwise, I'm sure I can find something more leveraged to do with that time than support 0.002% of SUMO users...

Comment 10

[Laura Thomson :laura]

I'm inclined to WONTFIX.  It really doesn't seem like that big a deal.

Comment 11

[David Tenser [:djst]]

Main point for keeping it was that it should be a fairly simple fix (just change the default CSS rules; probably less time than it took for mconnor to write comment 9 ;) but I agree that it's not a big deal.

Comment 12

[Majken Connor [:Kensie]]

those 287 are still our users though and we're using js in a way that they might not understand.

In most cases where not having js on breaks things things just don't work, you click, nothing happens etc. For us we have weird things like text running together, but it's not obvious this is because js is off because most of the page makes sense. For instance instructions to right click show up as "right-clickhold down the Ctrl key while you click"

We don't have to support non-js but I agree whole-heartedly with david that we should give them a usable view. Then when they try clicking to change the view and it doesn't work they'll realize it's cuz js is off.

Comment 13

[Mike Connor [:mconnor]]

There's actually a much better reason to have a script-free default to the majority case, which is that the pages (i.e. keyboard shortcuts) look like crap until you hit the onload handler.  Even on a new laptop and a fast (45 Mbps) connection, I get everything and then stuff gets hidden.  Hopefully there's already a bug on this?

(I'm going to talk to Nelson about SHOWFOR, the current implementation seems... strange.  More details, and probably a bug, after I talk to him.)

Comment 14

[Majken Connor [:Kensie]]

leaving as wontfix as we're not going to fix this for the sake of fixing it, but marking depends on mconnor's showfor bug as this will be fixed if that gets taken.