[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