Allow author styling of Lock Screen

hituro commented 1 year ago

Currently, the lock screen displays before user styles are loaded, making it difficult to restyle the lock screen. At best, there is a flash of the default lock screen before the custom styles are applied, at worst the custom styles never apply.

This can be manually fixed by moving any styles applying to the lockscreen to the <head> of the final game, but there's no in-twine way of doing that.

Of course, I understand that there may be no obvious mechanism for this. A StoryLockscreen passage would have to be loaded before the lockscreen is shown, but passages aren't processed until after lockscreen display. Similarly Twine 2 doesn't allow for multiple stylesheet passages (which might otherwise be a logical mechanism).

An event that triggers before the lock screen loads might allow JS to insert styles into the head? This is not a very intuitive approach, but perhaps modifying the lock screen is a niche enough that this is the right answer.

ChapelR commented 1 year ago

If you use Tweego, you can use modules or the head option to inject CSS into the page directly. If you're using Twine it's way more annoying, since you need to edit the compiled HTML file, but it is possible (before I switched over to using Tweego, I used to write scripts that would replace </head> with the code I wanted to inject).

Realistically, this is a compiler consideration, and it'd be nice if more compilers allowed content to be injected in the HTML file's head, not just for this but also for stuff like Google Analytics, favicons, meta tags, and general web libraries that don't need to/shouldn't go through the story format. Not that this issue shouldn't be here or anything, but maybe it's something to raise on Twine's issue tracker, too.

Also, as you've mentioned, you can style the init screen with in-story CSS if you're okay with the brief flash of the original load screen, I think that may work for some people even if it's not ideal since it may be easier than trying to hand-edit the HTML or switching to a different compiler.

david-donachie commented 1 year ago

Yeah, I'm doing the hand-edit method at the moment, because I like the Twine interface, I realise it would be easier with tweego. I could certainly understand the contention that this is too niche a problem to need a dedicated solution, though as you mention, it comes up quite often for Analytics

tmedwards commented 1 year ago

This is a project build issue, not a SugarCube issue. There's nothing I can reasonably do about this in SugarCube. Let me explain why.

Here's a simple page loading milestone diagram:

|→ Head →¦→ Body →¦→ SugarCube →|

The current loading (a.k.a. init) screen is initialized early during the loading of the head—the only resources that load before it are vendored scripts and the style normalizer. It covers page loading from its position within the head until SugarCube has finished its startup.

The only way to allow user scripts and/or styles to affect the loading screen from its initialization within the Twine 2 build process is to move the initialization of the loading screen until SugarCube execution, when passage-based user code is first available. This would leave most of the basic page load without a loading screen. That's not a model that I'm inclined to switch to.

The best way to go about this would be for compilers to allow the addition of content to the page head—and not simply for this issue. For example, there's no reason for players to be forced to wait until the story format is loaded to begin loading some resources across the network, when a few judicious HTML tags in the head could begin concurrent loading as the rest of the page loads.

Twine 2 could easily allow users to add HTML tags to the head for local or network content, blocking or non-blocking.

I'd suggest bringing head content up at Twine 2's issue tracker.

tmedwards / sugarcube-2

Allow author styling of Lock Screen #200