[wp-meta] [Making WordPress.org] #1379: Lost text without warning when click link in Trac without JavaScript enabled
Making WordPress.org
noreply at wordpress.org
Sun Nov 15 17:32:16 UTC 2015
#1379: Lost text without warning when click link in Trac without JavaScript
enabled
-------------------------+------------------
Reporter: pdfernhout | Owner:
Type: defect | Status: new
Priority: normal | Component: Trac
Resolution: | Keywords:
-------------------------+------------------
Changes (by pdfernhout):
* priority: lowest => normal
Comment:
Having reflected on this some more, here is an easily doable JavaScript
proposal for WordPress Trac that would address the issue. If you look at a
web page at TED without JavaScript, such as this one on
[https://www.ted.com/talks/michael_sandel_the_lost_art_of_democratic_debate
the lost art of democratic debate], at the very top of the page on a
contrasting color background it says:
{{{
You have JavaScript disabled
For the best experience, please turn JavaScript on. Here's how
}}}
That text has a link that goes to [http://enable-javascript.com/ enable-
javascript.com].
So, if JavaScript is so essential to WordPress Trac, I'd suggest a similar
approach.
The approach I mentioned above that I use for a single page app that is
completely dependent on JavaScript is probably not best here. While it
could work, it would require changes to have all content either be hidden
or be added at runtime, which would be an architectural change. Likewise,
just preventing use of the entire application when it is otherwise usable
for browsing, like via an overlay div that blocks access to underlying
content, is also probably not best either.
One concern I see from more reflection is that even if only 1% of
WordPress Trac users have JavaScript turned off like via NoScript (a
guess, but we don't know for sure without quantified measurements), such
techies may be a disproportionately higher percentage of Trac reporters
than just 1%. For example, as
[http://leeandmelindavarian.com/Melinda/index.html Melinda Varian
documents], when IBM announced on the February 8, 1983 it would go "Object
Code Only (OCO)" with its mainframe VM (virtual machine) source code
instead of keeping the previous policy of having the source code
accessible to all licensed users, who could share changes with other
licensed users, forming the basis of a thriving community. The
justification was in part that only a small percentage of the sites
actually used the source code so access was not very important. I expect
some lawyer or executive somewhere thought the benefits of preventing
competitors gaining access to "secrets" would outweigh a very few unhappy
users. Of course, those small number of sites that used the source code
(Melinda Varian's Princeton University site was one of them) were the
places that were continually fixing IBM's many bugs and providing various
enhancements for free. That move has now been widely seen to have been a
disaster for IBM as well as the VM community. IBM's move to supporting
open source software in the 2000s was in part a reflection of that past
experience as some long-time IBMers were still upset about that whole OCO
decision (although obviously, industry trends with Linux played a part,
too).
So, in this case, if it turns out WordPress developers are ten times more
likely to use something like NoScript, HTTP Switchboard, uBlock Origin,
uMatrix, or whatever than the typical WordPress user, then one might find
that 10% of Trac reporters are affected by this issue, which is then not
insignificant. That's all speculation without metrics though.
So, while it can be hard to prioritize the needs of a few when there are
so many other things to be done affecting so many users, just because only
1% of some pool of users may benefit from a feature does not necessarily
mean that only 1% of the community will be affected by its removal or
change. It really depends on the specific feature and the context and the
specific users and their roles in the community. So, based on that
reasoning, and now that I also have a plausible easy-to-make change to
suggest with the TED site example, I'm bumping the priority back up to
"normal". :-) People should feel free to bump it back down of course; I
may be totally wrong.
--
Ticket URL: <https://meta.trac.wordpress.org/ticket/1379#comment:4>
Making WordPress.org <https://meta.trac.wordpress.org/>
Making WordPress.org
More information about the wp-meta
mailing list