Process stylesheet tagged passages in the Twine 1 way, even in a Twine 2 project

[hituro]

Is your feature request related to a problem? In a Twine 1 project, stylesheet tagged passages are concatenated into the story user stylesheet. In Twine 2 projects, such passages are ignored. This is in line with the Twine 2 Story Stylesheet specification.

However, the Twine 2 Story Stylesheet rapidly becomes unwieldy in a larger project, especially when CSS for 3rd party custom macros is included. It would be wonderful to be able to split that CSS across multiple passages.

Describe the solution you'd like. Passages tagged stylesheet should be processed and concatenated onto the Story Stylesheet in a Twine 2 project, just like they would be in a Twine 2 project.

Describe alternatives you've considered. A similar effect can be had by using an external compiler, but I'd much prefer to be able to manage CSS code inside the Twine app.

Additional context. The same argument could be made for JS code, of course.

[ChapelR]

This is a compiler issue, that is, you'd need to take this up on the Twine 2 side. SugarCube 2 can and does work with Twine 1 and various Twee compilers that allow for multiple stylesheets, and for tagged stylesheets.

[greyelf]

@ChapelR It is true that the Twine 2.x application injects the content of its Story Stylesheet area into a specific section of the Story Format's template. But the contents of stylesheet tagged Passages are also added to the <tw-storydata> structure like any other Passage is.

Based on the code in this section of the story.js file it is SugarCube that decides to ignore those stylesheet tagged Passages (during its start up process) if it finds the HTML file contains a <tw-storydata> element.

[ChapelR]

My point is that this should be treated as a compiler issue. It is possible for SC to handle script and stylesheet tagged passages, but I think the editing experience of the Twine 2 app should be handled by the Twine 2 app. Also implementing this on the story format side might be difficult because you're stepping on compiler's toes, since some compilers do support stylesheet tagged passages. You could just check for only Twine 2 before processing stylesheet tagged passages on the format side but I don't think that's a good idea. If the goal is to improve the Twine 2 editing experience, this should be handled on that side.

[hituro]

@ChapelR How can this be a compiler issue when other Story Formats don't have any special handling of stylesheet tagged passages at all?

[ChapelR]

The special stylesheet and script tags are a feature of Twine 1, and certain Twee compilers. SC (and other Twine 1-compatible formats) only gather these passages to ignore them, and usually only if it's detected that they're running in a Twine 1-style compiler (by looking for a specific element, #store-area, if I recall correctly). This is, afaik, the only processing of these passages done by the format itself, just keeping the passages containing CSS out of the available passages at runtime. Also, SC is compatible with both Twine 1 and 2 and the runtime is functionally the same, so some extra processing is done, but these features are not really implemented by SugarCube.

This is not a SugarCube thing, it's a Twine 1 thing and a compiler thing. Harlowe, for example, can also use stylesheet tags in Tweego, and Snowman can in Twine 1.

With Twine 2-style compilers, these tags don't do anything at all, I believe they actually function as normal tags even in SC2. The tags do work in certain compilers, but the compilers themselves generally remove the tagged passages at compile time; they're concatenated into a single html element in the data chunk--the passage elements are not usually retained by the compiler, so the format doesn't even see these passages. This isn't in the spec though, afaik, so theoretically a compiler could do this differently.

At least, that is my understanding. Nothing of any particular consequence is happening on the format side. The stylesheet element in the data chunk is processed at runtime, of course, so you could theoretically add arbitrary passages to that, and maybe TME will choose to do that, but I think the fact that Tweego, Twee2, and Extwee all already support tagged stylesheet passages and stuff means that this feature would be redundant anyway, and would also require the format to make sure it's not creating weird interactions with these compilers.

On top of all that, if the goal is to get a better editing experience, like multiple stylesheets, I would say that is an editor/compiler consideration in most cases, and definitely so in this case. The actual issue, irrespective of the solution, is one with the Twine 2 app not allowing multiple stylesheets, when every other compiler, including Twine 1, another GUI compiler, has this feature.

I do think what you're asking for is possible, but I think it would be better implemented on the Twine 2 side, and its something I'd like to see in Twine 2 as well. I believe it's been asked for in the past as well.

Of course, I'm sure we'll hear TME's opinion soon enough, and maybe I'm wrong and more of the processing than I realize happens on the format side at runtime.

[tmedwards]

I'd rather not have the Twine 2 release of SugarCube act differently from every other Twine 2 story format in this regard. Yes, Twine 2 compatible story formats have differences, but they all follow how Twine 2 outputs/uses its data chunk.

This would be better as a Twine 2 compiler issue. There's absolutely no reason Twine 2 couldn't provide for multiple JavaScript and stylesheet sections, including allowing user-defined ordering. How the Twee specification and compilers would handle the latter is a sticky wicket, but not insolvable.