Troubleshooting
In Inform, just as in life, things do not always turn out the way we plan. Sometimes, our problems are obvious and easily mended, but we occasionally have a genuine whodunnit on our hands. How can we solve such mysteries?
A good first step is to wade into the the developer tools for our page. Click on the part of the page that is behaving unexpectedly, and select inspect. What we see may be overwhelming at first, but this reference has prepared us in a general way for interpreting it.
The window will be split into two frames. At left will be our page, and at right we see a structured view of HTML elements and relevant CSS. In this pane, I have clicked on the orange-backed hyperlink:
We can resize these panes at will. At center will be the specific web content that we clicked on, and to its right will be all relevant CSS. Each CSS entry will also state where it is coming from. These entries are also listed in order of precedence. Entries at the top will generally be the ones applied unless we add an !important designation to something further down the ladder.
Do we see our entry there?
If not, we likely have a formatting problem or typo with our initial class, element, or property. CSS (and therefore our code) can be (though not always) sensitive to spacing. We may have an entry that is not compatible with Bisquixe’s format. In nearly every case, the failure of an entry to appear in the rightmost pane indicates a problem with the first two-thirds of our css-set-fast string.
Is our entry there, but struck through with a line?
This is, as already stated, likely to be a problem of precedence. CSS is parsed according to a system of priorites known as the CSS Cascade. Like Inform, CSS has an affinity for the specific. .BufferLine, for instance, usually inherits CSS properties from .BufferWindow. If we intervene, styling .BufferLine directly, that is a more specific tactic that will take priority over inheritence.
If we have a case where being specific isn’t enough, we should have a look at our inspector to see what entries are above it. One of them is taking precedence. Can we see why? Should we specify one of them instead?
Is our entry there, but struck through with an orange-and-yellow triangle at left?
We can hover our mouse cursor over the triangle to read an error message. Most commonly, these errors pertain to improperly formatted or inapplicable values. If we have specified a color for a width property, that will surely turn up here. Most of the time, though, our problems are more subtle. Perhaps a rather complex clip path value is missing a comma somewhere. The format for a CSS entry is typically rigid. Consider this entry. What is wrong with it?
css-set-fast ".BufferWindow; background; linear-gradient (blue, red)";
CSS will not tolerate a space between
linear-gradient and (. These distinctions can be difficult to identify! Sometimes, we could use a second set of eyes. Showing our code to people or creating a thread at intfiction.org is always a good option, as this a friendly and helpful community.
Other difficulties
Because formatting for css-set-fast is specific, it may not always be clear how to engage with a specific property or grant it precedence. As recently discussed, for instance, it is not enough to style a link via a custom class. Rather, we must specify both class and a: link all at once.
css-set-fast ".Style_jmp a:link; color; black";
How are we to know such things? An internet search will turn up some answers, but this is again an opportunity to create a thread. Making a new thread benefits the community because others experiencing our problem can find answers in a search.
Another option is to attempt to recreate the desired effect in the game’s glkote.css file. If we can get our changes working there, we must have a difficulty translating native CSS to Bisquixe’s specific format.
In my own anecdotal case, the most common problems arise from formatting and typos. As consolation, the more difficult, whodunnit-style mysteries are the most gratifying to solve.