GenHelm makes it very easy to reuse and override script and css styles. These can be defined in four separate locations:
After describing the common fields we will discuss the fields that are specific to styles followed by those that are specific to scripts.
The definitions may appear intimidating but be aware that most of the columns are options. In many cases you will just fill in two or three columns.
Similar rules apply to overriding styles and script at the layout level.
In most cases, style and script files will be taken from the styles and support folders of the site itself. In such a case, it is not necessary to enter anything into the File Location column. Alternatively, you can enter the keyword SITE in upper case to make it clear that a file belongs to the current site.
In many cases, script and sometimes styles will be stored in the inherited pseudo site (which defaults to system). To draw on these system files, enter the uppercase keyword FRAMEWORK.
If your site inherits from an industry pseudo site (as indicated in site_settings) use INHERIT to specify that the script or css file is to be drawn from this site.
You also have the option of specifying DYNAMIC as the file location. In this case, the component will be loaded from the current site if it exists there. If it is not found within the current site it will be loaded from the inherited site if such a site is specified within site_settings and if the inherited site defines the component to be loaded. Finally, the component will be loaded from the system pseudo site if it is found there.
Another possibility is that you may want to pull files from a remote server such as a CDN (Content Delivery Network). For example, Google serves the jQuery framework from the url https://ajax.googleapis.com/ajax/libs/jquery/3.3.1/jquery.min.js, Therefore, the path portion if this file (specifically https://ajax.googleapis.com/ajax/libs/jquery/3.6.0/jquery.min.js could be entered into the File Location field to pull jQuery from this location. The advantage of using popular CDN files is that there is a good chance that your web users have visited other sites that refer to these same files so the files may be cached in your user's browser even if they have never visited your site before.
This field allows you to specify where within the html the styles or script file is to be included. For script, this can be in one of three locations:
In the case of styles, you have the option of placing these in the head section or at the bottom of body section. Usually styles go into the head section however for large stylesheets this can result in delays since the loader must wait for the styles to be loaded before continuing to load the rest of the html. Google recommends sculpting CSS to render essential CSS in the head section but postpone non-essential CSS until after the "above the fold" content is loaded. To follow this recommendation you should generally do the following:
Additionally, you can select nowhere if you want to prevent a (non-final) script and styles defined at a higher level from being included.
Sometimes it is important for one stylesheet to be included before another stylesheet (since styles indicated in the later sheet will override like named style definitions in earlier sheets). Similarly, sometimes script in one file may need to be physically positioned ahead of script in another file. The priority column allows you to control this sequencing by placing a lower number in the priority column for files that need to come before other files (that are assigned a higher priority value).
In many cases the priority is not important and you can leave this column blank. If you do need to use it you may want to leave some gaps in the priorities in case you later need to define files that must be included between existing files. The default priority is 5000 so if you set a file to have priority, say 4000, it will be loaded before those that do not have a priority set.
Each script file or stylesheet requires the browser to make a request to the server. There is a fair amount of overhead in each file request so people often combine all of their styles or scripts into one file. The problem with this strategy is that you end up with file "bloat". That is, a certain page may only need a hand full of styles but nevertheless you include a stylesheet that contains hundreds of styles.
A cleaner strategy is to group styles into smaller subsets that are commonly used together. For example, you may have a set of styles for handing responsive grids and another set of styles to support carousels, etc. This way you need only include the styles that pertain to the items on your specific page. This strategy introduces a new problem in that the browser may need to make several round trips, one to load each separate file.
The group column seeks to solve this quandary. It allows you to logically divide content into different files while at the same time combine these files into one common file to be served at runtime. For example, say your page needs five separate css stylesheets. If these stylesheets are all given the same group name the five sheets will be combined and served under a common name. This way, the browser only needs to fetch one file. The runtime framework handles the process of combining these files automatically.
Note then when grouping files, be sure to use the version column to make sure that newer versions of a file are re-cached.
The device column makes it easy to include files that are device specific. For example, suppose you use a set of styles for phone devices and these same style names are defined differently for desktop devices. In this case, you can control which stylesheet gets loaded into each type of device.
When serving files from a Content Delivery Network it is important to ensure that you have been delivered the expected files without manipulation.
The Integrity property allows the browser to check the file source to ensure that the content is never loaded if the source has been manipulated.
The Crossorigin Property should be used when a request is loaded using "CORS" which is now a requirement of SRI checking when not loaded from the "same-origin" host.
Basically, if you are loading files from a CDN and if the provider supplies suggested values for the Integrity and Crossorigin fields, enter these in the same row as the CDN file you are referencing.
Recall that it is normally possible to override a file defined in site_settings at a lower level (either at the layout or page level). Similarly, layout files can be overridden at the page level. Sometimes you may not want to permit certain files from being overridden. For example, if a site wide script is used to support a security requirement, you would not want a certain page to disable this. In such cases you can designate a file as being final by checking the final column.
It is a good idea to use the Comment column to describe the purpose of a script file or stylesheet.
The Media column reflects the media attribute of a stylesheet link definition. It is used to indicate that a stylesheet applies to the print media, speech, etc. or you can even code a complex media query in this column.
One way to make the rendering of a page faster is to include the styles inline rather than forcing the browser to load an external stylesheet. The disadvantage of this approach is that the browser does not cache inline styles (only those loaded from a separate stylesheet). For this reason, it is only recommended to inline stylesheets that are relatively small, say up to 20 or 30 lines.
By default, the loading if scripts interrupts the loading of other html content since the browser normally waits for the script to completely load before proceeding. Depending on how your script has been coded, it may be possible to set this option to async to tell the browser that it is okay to load the script in parallel with the html content.
The defer option should be specified if it is important to tell the browser not to execute the script until the entire page has been loaded.
Use the inline option in cases where you want to render the script inline rather than forcing the browser to make a round-trip to the server to load the script. The inline option should only be used for small scripts since the browser will not cache inline scripts.
One of the powerful features of the GenHelm framework is that scripts and styles can be added on demand. This helps to prevent resource "bloat" which is common in other frameworks that don't support the granular loading of scripts and styles conditionally. To learn how this is done please refer to the help associated with the custom model.
|GenHelm Architecture||GenHelm Architecure.|
|Why GenHelm?||Summary of the GenHelm methodology.|
|Getting Started||Learn how to start a new website.|
|Naming Conventions||Naming web pages and other items.|
|Common Web Page Fields||Descriptions of fields that are common to all page models.|
|Layouts||Defining codeframes and layouts.|
|Styles and Scripts||Descriptions of fields that are common to all page models.|
|Meta Tags||How to configure meta tags for your site and specific pages.|
|Dollar Functions||General information about dollar functions.|
|Navigation Tips||Navigation Tips and Techniques|
|Favourite Icons||How to configure favorite icons for your site.|
|Blog Maintenance||Blog and post administration.|
|Direct Command Help||Help for the direct command field.|
|Programming with GenHelm||Writing programs that interact with the GenHelm framework.|