Converting to SugarCube's new CSS model

Erik Temple

My first issue doesn't seem to be related to CSS definitions per se. Fonts are failing to load via @import. Longer version:

My design relies on two imported Google fonts, e.g.:

:: Imported Fonts [stylesheet]
@import url(https://fonts.googleapis.com/css?family=Arvo:400,700);
@import url(https://fonts.googleapis.com/css?family=Open+Sans:400italic,700italic,400,700);

:: Basic CSS [stylesheet]
/* Main display and drawers setup */
html, body {
margin: 0;
padding: 0;
width: 100%;
height: 100%;
overflow:hidden;
}

body {
color: #000;
font-family: 'Open Sans',serif;
/* Disable webkit tap-highlighting on non-links */
-webkit-tap-highlight-color: rgba(0,0,0,0);
tap-highlight-color: rgba(0,0,0,0);
}


With SugarCube 1.0.4 installed, the imported fonts simply don't load. The font rules are not being overridden by any SugarCube styles, but e.g. the rule in font-family: 'Open Sans',serif; results in display of the default serif font.

It seems that something about v1.0.4 is preventing the @import rules from having any effect: The Sources pane in Chrome's developer tools shows no attempt to contact fonts.googleapis.com (and the same thing is true in Firefox). There are no visible errors or warnings in the console log.

So the page isn't even trying to load the fonts. What could be causing this?

TheMadExile

SugarCube 1.x changed the way user stylesheets are added to the page.  That change is very likely biting you here.  If you inspect the element <style id="style-story"> you will probably find that your @import rules are not at the top.

I could address that in the next release (partially restoring the pre-1.x behavior), however, I'm not certain I should.  Currently, there is no way to specify the ordering of multiple stylesheet passages, which is problematic since styles cascade (this has been an issue in all story formats since day one).  For that reason, I do not recommend using more than one stylesheet passage.  And, if you're not using more than one stylesheet passage, the new behavior won't affect your @import rules.

My suggestion would be to consolidate your various stylesheet passages, putting the @import rules at the very top (they must precede most other rules).

Additionally, I'd suggest getting the habit of quoting the contents of url() notation, since non-US-ASCII characters are not allowed in unquoted versions.  You don't have that problem here, but getting into the habit ensures that you never run afoul of that particular gotcha.

TL;DR: Using multiple stylesheet passages is, and always has been, broken.  Don't do that, since, even with the old behavior, you never know when it's going to bite you in the arse.  Use one stylesheet passage per story/game.

greyelf

Getting into the habit of using a single stylesheet passage is also a good idea if you are thinking of using Twine 2 any time in the future.

Erik Temple

Great, thanks. That's an easy fix. By the way, I am currently importing all of my stylesheet code from the same Twee file, which I believe means that it is pretty much guaranteed to be tiddled in source code order (due to an enhancement TME made in an earlier version of SugarCube). Since it is a lot of code, I like to be able to page through it using the :: subdivisions. But I can insert comments instead that have a searchable string.

Thanks for the tip, greyelf. I don't have much interest in Twine 2, honestly, at least not until it's a downloadable app, supports external files (I hate the graphical Twine interface for anything but occasional visualization), and either has all of the great features of SugarCube or there is a SugarCube 2 to go along with it!

TheMadExile

Erik wrote:

By the way, I am currently importing all of my stylesheet code from the same Twee file, which I believe means that it is pretty much guaranteed to be tiddled in source code order (due to an enhancement TME made in an earlier version of SugarCube).

No story format makes guarantees about the order of the tiddlers within the passage store (that's a compiler issue), nor does any story format, currently (AFAIK), make guarantees about preserving the ordering existent within the passage store when decoding it into the passage cache (and the cache is what is processed during script and stylesheet setup).

Some compilers (TweeGo and Twee 1.4+) are setup to maintain the same ordering existent in the source files when compiling the passage store, however, that only addresses the first issue (and only if the author knows about it and ensures the proper order in their source files).  Twine 1 is trickier because, well, story map.

Frankly, user styles and scripts should have been handled via singular special passages (e.g. StoryStyles & StoryScripts or something like those), rather than via tags, in Twee/Twine 1 and their story formats.

Erik wrote:

Since it is a lot of code, I like to be able to page through it using the :: subdivisions. But I can insert comments instead that have a searchable string.

Do both (sort of)?

/*:: Yakkity Smackity */

That should not be taken as the start of a Twee tiddler, while still allowing you to search for `:: blah`.

Erik Temple

Cool, thanks for the info. I think I was misremembering something we discussed a while back related to source code order.

Erik Temple

Chrome for Windows and Android show SugarCube's loading progress bar off-center:

[IMG width=500]http://i.imgur.com/2gSC7Tw.png[/img]

Chrome for OSX, Firefox, and other browsers don't seem to have this issue. I can't see anything in the CSS that would cause it. Is anyone else seeing this?

TheMadExile

Hmm.  Actually, it's not off-center, the real bar is the correct size and in the correct position (you can see that if you highlight the element or watch the sweep).  What's happening is that it is rendering some extra cruft to the left of the actual bar, which gives the off-center look.  And no, there's absolutely nothing in the CSS that should cause that behavior (I don't style the bar at all, actually).  It looks like a bug in either WebCore or Chrome itself, though apparently not on all platforms.

Let me see what I can find out.

Okay, that didn't take too long.  After some poking in Chrome for Windows, it appears that the problem is the element's height.  If it exceeds 27px or so, it goes wonky and starts displaying the rendering error past the left side, making it look off-center.  It looks like I can stop its histrionics simply by setting its height to something less than the failure point.

Could you please try this style out and confirm that it patches the issue?  If it does, then I'll add it to SugarCube's core CSS.


#init-loading progress {
height: 20px;
}


Erik Temple

Yes, that fixes it on my side as well. Thanks!

Erik Temple

Actually, I've been pretty bothered by the newish default style for the <progress> element on Windows and mobile Chrome, so I'm thinking that I'll just restyle the progress element. Am I right that SugarCube uses only the indeterminate progress bar (i.e., no percentage values)?

TheMadExile

Yes, that is correct.

Erik Temple

Is there a way to ensure that custom styling for the progress bar is loaded before the bar is displayed? Right now, the default styling appears for a couple of seconds before my custom CSS is loaded.

TheMadExile

Only by editing the format itself (within <style id="style-init-screen"> would be the logical place).  The loading screen must be available before the document is ready, which means before the format's entry function is called, thus before any passages are processed (incl. stylesheet passages).

Erik Temple

That's what I figured. I'm close enough to release for that not to be a hassle, so that's probably what I'll do. I have some <meta> stuff I want to do too.

What's interesting is that there was no FUOC when all I was doing was limiting the height to 20px, but I suppose that my new CSS is a lot more complicated and just takes more time to render.

Erik Temple

If anybody else wants to customize the SugarCube as described by TheMadExile, you're welcome to use/start with the code in this fiddle:

http://jsfiddle.net/u6td8swk/4/

It's a simple but fairly modern-looking indeterminate progress bar based on the one in this tutorial.