Fluid design

Websites need to adapt to a whole range of screen sizes, and CSS does all the heavy lifting for that.

The name Cascading Style Sheets (CSS) indicates that there is a hierarchy of dependencies within how the various rules defined within a stylesheet are applied. While this allows some simplifications by condensing what might otherwise be a plethora of rules, it can also lead to frustrating complications due to the dependency inheritance. Complicated naming conventions have been created to supposedly conceptually simplify keeping track of the dependencies. Despite this, YouTube still manages to have a rule classname that is 114 characters long in its home page.

While some concessions to rendering-direction independence have been made in recent years through use of before and after, CSS is still largely using left and right. Originally, I did have a lot of clumsy complementary pairs of rules to cater for the dual directions, but in dealing with another issue, I did find a more elegant way to simplify the rules.

One of the problems with having separate CSS stylesheet files is that they are not loaded with the HTML, so that if there is too much of a delay between when the HTML has completed loading and the CSS arrives, the page can be without any styling during that time, leading to what is known as a flash of white (FoS). This can make pages look ugly, especially if the end page is dark. This is where I decided to load both the CSS and JavaScript with the page. It does substantially increase the size of the page, but compression substantially minimises transmission time.

Loading the CSS and JavaScript with the page presented an opportunity to do some real smarts. Just like PHP can be embedded in the HTML of a page to do some custom server-side processing of the page, it can also be used to do the same for CSS and JavaScript. As well, all the page information that is used to generate the HTML can also be used to modify the CSS and JavaScript. The first advantage of this is that the rules and code can be customised according to the content of the page, enabling the sort of minification that is just awkward if using separate files.

For example, tables require a fair bit of CSS and the sequence element several kB of code, but if they are not used in the page, those are not included. In addition, CSS rules can be defined down to individual instances of elements, though it requires using the same means of sequencing of ids in those files as is used to generate those for the HTML elements to which they apply. Finally, hashes can be generated for the resulting rules and code to put in the page's headers to prevent them being maliciously altered.

While CSS now allows variables, it is crude compared to having complete access to all the PHP variables and functions to embed within the CSS and JavaScript, or decide which rules and code to use. I created several PHP variables in the CSS that would choose to insert left or right according to the rendering direction or alignment of the page's language script, enabling me to replace the pairs of rules with single ones, eliminating dozens of rules. In this way, I could just think in terms of starts and ends, letting the rules be transparently adjusted by the PHP variables.

While there are some CSS properties that are catering for such internationalisation, others have not been adapted. For example, border-inline-start can replace border-left, and start or end can be used as a value for text-align, but float, clear and back-ground-position do not allow such values. These new logical properties are attempting to make CSS able to handle rendering in all directions, but until all such properties are fully defined and implemented across all browsers for at least a few years, proper internationalisation will still rely upon PHP or CSS tricks.

Furthermore, there are some subtleties associated with these newer logical properties. For example, the program uses a span tag with dir=auto to make text render according to its content's script, but maintain the spatial relationships to its siblings according to the direction of its container. However, any logical properties applying to that span will use the rendering direction of the contents, not the enclosing tag, which means any margins or padding will be the opposite way around if the scripts are different. Such properties should use the rendering direction of the enclosing tag.

I suspect that due consideration is not being taken of mixed script environments, such as can occur when editing text of one script, or even mixed scripts, within a form using another. Except for the content being edited, everything else in the form must be spatially laid out according to its direction, even if some may have contents of the same script as being edited. Having margins or padding changing those spatial relationships because of the script of the contents being edited is disruptive. User-supplied content should not mangle the form.

The navigation bars are a significant construct, being comprised of up to three menus, which are aligned to the start, centre and end. The bar itself and the centre menu are centred, the start menu is floated and aligned to the start, and vice versa for the end menu. Every tag in the bar is set to display as inline-blocks to ensure that the menus, and the content in menu items, remain together.

This does result in some significant gaps at some page widths, but it ensures that the three menus remain perceived as separate, especially since they each perform separate navigation functions, especially in the management pages. There the start menu functions as a breadcrumb drilldown hierarchy, each item being a jump to the element on the Work list page. The centre menu is for sections on the page, while the end one is for status information. Such consistency favours visual integrity over minimising blank spaces.

Floating is also used in drilldown lists and where checkboxes are used to expose other content. Here the idea is to bias part of the content to the start and the rest to the end. The logical way is to set the alignment to the start, and float the rest to the end. However, the ending float can sometimes float outside its container if last. Putting the floating end content before the start-aligned content does solve this, but the tabbing order is reversed, confusing users. The solution is to end-align the container, float the start content in a div, and the end content is in the right order.

The floating element uses the CSS calc function to size it as the full width, less what is needed for the ending aligned items. If wanting to horizontally align parts of the content in the floating div, there can be one or more fixed-width tags, and another calc-sized tag to cater for the variable width of the containing div. While grids could handle simple topologies, the regime used caters for aligning content across table cells or levels in expanding lists.

With CSS, content can be made to be on one line and end in an ellipsis if the content would overflow horizontally. Unfortunately, for some reason it does not work with table cells, so I had to limit the vertical height and hide any overflow. To cater for language scripts that use large letters, the height has to be generous, so smaller-lettered scripts will have the bottoms of the second line of text cut off. The spikes table had to use this to limit the amount of tag text shown. Sometimes there just have to be compromises!

Consistent use of CSS and embedding PHP in CSS and JavaScript facilitated fluid design and per page minification.