FireBrick Custom CSS: Difference between revisions

FireBrick Custom CSS (view source)

Revision as of 21:47, 4 October 2019

11 bytes added , 4 October 2019

m

→‎Internal inline CSS - using data URIs

CecilWard

252

edits

Revision as of 03:48, 6 September 2017 (view source) CecilWard (talk \| contribs) (→‎Performance degradation with external websites: Minor rewording in places; additional guidance regarding availability and caching lifetimes.) Tags: Mobile edit Mobile web edit ← Older edit		Revision as of 21:47, 4 October 2019 (view source) CecilWard (talk \| contribs) m (→‎Internal inline CSS - using data URIs) Newer edit →
(2 intermediate revisions by 2 users not shown)
=== Using CSS @import === Completely separate 'print'- and 'screen' stylesheets can be maintained in separate .css files and these files can be conditionally included by reference in a master .css file using the CSS <code>@import</code> directive at the top of the file with a media-type qualifier within the directive ege.g. <code>@import 'my_fb_print.css' print;</code>. This qualified import form is concise compared with using a <code>{ }</code> statement block qualifier and in theory might minimise the size of an initial CSS download, depending on the browser. A general disadvantage of <code>@import</code> is the latency introduced by additional http requests, some of which can not be parallelised, so this delay increases page rendering time, unless of course the CSS is already cached. === Pulling in multiple .css files === * Alternatively, depending on your chosen configuration options, you may be able to log in to the Firebrick’s command line even if you find the web UI unusable. == Performance degradation with external websites == If your custom CSS is located on an external web server, try to ensure that the web server of your choice is well-configured and has excellent availability in order to avoid the possibility of introducing unpleasant delays in the responsiveness of the Firebrick's web UI. (Perhaps consider testing what effect unavailability has on the behaviour of your Firebrick's UI - your Firebrick firmware release could exhibit a delay in response before a timeout if the link to the web server is broken, and as regards visual appearance if the custom CSS can not be fetched, then it could use previously cached CSS or defaults.) To avoid having to use an external website to store your custom CSS, you can employ a <code>data:</code> URI - see [https://tools.ietf.org/html/rfc2397 RFC 2397]. Be aware that there may be a limit on the length of URIs however, and in any event see RFC 2397 section 2. IIt ~~recommend~~is recommended that you should not attempt to include newlines in the inline CSS of your data URI, as this may be forbidden by the URI scheme standard. Be aware of the risk of your inline CSS containing characters that are either prohibited in data URIs, illegal in quoted strings or in XML attributes. See both the RFC for the data URI scheme and also the XML standards. Just some examples of illegal characters are ", %, &, >, newlines and ~~there are probably~~ various others, The simple technique of including literal CSS straight, as below, is only usable if the particular fragment of CSS does not contain any problematic characters, otherwise see the next section for a general method. Example,: straight, inline CSS. ~~(exercise~~Exercise caution regarding prohibited characters if adapting). In the following example, any line-breaks ~~may~~which be included for readability~~. These~~ must be removed and the whole string must be entered as a single line. <syntaxhighlight lang=xml><http css-url="data:text/css,@media screen{div.main,div.sidemenu div.menu a,div.topmenu,textarea{font-size:x-small}div.footer{padding:2px 10px 1px}div.footer *{vertical-align:top}}" /> </syntaxhighlight> Note the presence of the comma after <code>text/css</code>. This is essential in a <code>data</data> URI. === Base64-encoded data === You may use base64-encoded <code>data</code> URIs for safety and complete flexibility as shown in the example below. Using base64-encoding removes any risks and problems with illegal characters completely. Note again the presence of the comma, now after the keyword '~~base64~~<code>data</code>'. This is essential in a data URI, whether base64 is used or not. If you are using any non-ASCII characters in your CSS text, unless you have already CSS backslash-hex-encoded them, which avoids the issue, your CSS should be Unicode text and you must first UTF-8-encode your CSS into a byte stream, before then base64-encoding those bytes. You ''must'' then also declare that your original CSS text was UTF-8 as in the example below.