If you leave the big industry-size browsers (Chrome, Mozilla, MS Edge, maybe Opera) you find plenty of browsers who don’t have full JS support. Like Surf, Netsurf, Safari, Pale Moon, Ladybird and many more.
Sure, but if you look at the actually usage statistics, their market share is vanishingly small. You mention Safari, but surely Safari had decent JavaScript support?
So if I use a browser which isn’t used by the masses I can go to hell? Doesn’t seem a valid argument to me.
I might be not informed about recent Safari. But some years ago Safari had no JS.
No, but if I make something, I’m under no obligation to serve every market.
Correct, you don’t need or want to serve the obscure last 1 percent. But authors who use themselves software that is someway not “normal” will see it differently.
JavaScript is required for making a webpage’s content dynamic. Without JavaScript, things like Twine would not exist. The web-based interpreters for parser adventures would not exist.
It is possible to run a webserver and return dynamically rendered static webpages with every click (and with every parser command). This would alleviate the need for JavaScript. Each interaction would be a new webpage to download, essentially.
An IF engine could be developed to support this, but it would be very web traffic heavy and could not run locally on a machine offline.
Another alternative to present locally run JavaScript enabled IF is to package it into a browser executable. For example, a Chromium browser can be packaged with the webpages and web media and use JavaScript in it’s own application scope. However, there a level of risk with running executables from unknown and untrusted sources.
The web browser has security built-in to stop a webpage from accessing the user’s hard drive files. It seems to be pretty secure at present and the major browser companies are constantly updating their software.
I’m not trying to sway you in any direction. I’m just presenting the situation as I understand it.
Thanks for the infos. Yeah, I use JS myself as a web visitor/“surfer”, for example on this site. But I also like experimenting with software that is small, simple and doesn’t have many features.
I don’t know whether JS is a barrier for blind web visitors.
When blind accessiblity is not considered, the use of JavaScript can make website unrulely for blind users. I totally understand @Mewtamer’s objection to using it.
If a developer were to make a JavaScript IF engine with screen readers in mind, the experience would only be enhanced for blind players. For example, if I were to make an IF engine that was blind friendly, I would use JavaScript to replace the whole webpage with clean, unstyled text for screen readers specifically. Disable the screen reader mode and the whole webpage would be replaced with a graphical interface. The screen reader interface would look plain and uninteresting, but work very well. The graphical interface would not work well for screen readers.
JavaScript is not the problem. It’s all about the developer and their level care for accessibility with their product.
You mean .01%. I can’t imagine there are even a few thousand people using a minimalist browser.
And using it to exclusion of a full-featured modern browser.
You might not want to use them, but I do. Also what’s an "expanded " IF?
I’m not quite sure how that adjective got in there…I presume I was looking for a generic way to refer to works “expanded” beyond the capabilities of the typical framework of interpreters etc
10 posts were split to a new topic: Reimplementing ChoiceScript
W3Schools has a fantastic accessibility tutorial.
→ W3Schools - Accessiblity Tutorial
Key things that aren’t specifically stated:
- Accessibility must be planned from the start of a project.
- Remember that your project should work with a mouse, on a touch screen display, with larger fonts displayed properly, and be fully keyboard driven.
- Use JavaScript sparingly and only purposefully.
- Use concise HTML as much as possible, this means being an editor (like in writing) with your own code. Do the most with the least.
- Following accessibility guidelines does not mean your IF project will look like a webpage from the 90s. Use CSS to style things in a clean, attractive manner.
- Design your project in black and white first (with maybe one shade of gray). When things look good and distinctive, and the layout allows the text room to breathe, then apply colour and decorative elements.
My favourite tip from the tutorial is:
Always remember that you are not the user.
Yeah, although it’s not a builtin part of TADS3, just how I write things. I generally:
- Break any non-trivial new functionality into a standalone(-ish) module
- Write unit tests for all of the API methods/functions provided by the module to upstream modules/games
- Also write unit tests for upstream modules that depend on other modules but export them as a wrapped dependency. For example I have a module that provides instanceable PRNGs and a module for NPC decision-making that relies on it. The PRNG module has tests for the various pick-a-number methods it provides but I also wrote checks for the NPC module’s have-the-NPC-pick-an-option method…even though under the hood the latter is mostly just a wrapper around the former
- Independent of this kind of thing I wrote a module for implementing generic linters and I’ll write linter checks for new modules, particularly if there are a lot of gotchas. For example on the Markov chain module I put up the other day I added a linter check that looks for places where decimal probabilities are used and makes sure that all the options sum up to 1.0.
- And independent of all that, when I’ve got a case where there are a bunch of dependencies I usually use a module I wrote for doing full-on regression testing—using a reference game world and set of actions and comparing the transcript for different builds
I guess I also tend to write little one-off interactive debuggers for bigger/more complicated modules (like the transcript re-writing one). Those have sometimes ended up in the public version of the module (like in transcript re-writing module) but I frequently write an interactive debugger during development and then remove it before making the repo public (mostly so I don’t have to re-write the debugger to use less profanity).
You could run it locally, you’d just have to release the game with a simple web server—which doesn’t seem that much of a tall order given that “bundle Chromium” is already being considered.
What about unit-testing actual game logic?
Coming never to a TADS VM near you: Hidden Debugger Mode.
Yeah, I thought about that, but in the context of simply not wanting to turn on JavaScript, having a webserver installed and running as a service in the background for an IF game seems like an even bigger ask of a user.
Still, if a game was so large in scope that a performant database was required, webserver databases are probably the answer. My mind reels with what kind of game could demand a database to drive it. A monumental scale text adventure on a simulation level, maybe?
…maybe.
I’m not sure I understand the question. Can you give an example of the sort of thing you’re asking about?
@jbg
I’m not quite sure I knew what I had in mind when saying that. On reflection…
I was mostly thinking that these examples all apply to modules and not exercising, say, a state machine implemented using ActorStates/your state machine module as part of a game.
As a Firefox user, I still run into sites today that are broken unless I switch to Chrome. Less so for Edge, but double for Safari.
Since its inception the web has always been a hodge-podge of half-implemented standards and deliberate violations of same in an attempt to capture marketshare.
That said, it is the easiest/laziest way to get something ***cross-platform.
*** Really you’re just writing for the web platform that sits on top of other platforms. Browsers really are as complicated as entire operating systems today, with all the accompanying bugs, security problems, deliberate privacy invasion by design, etc. Meh.