News:

SMF 2.1.4 has been released! Take it for a spin! Read more.

Main Menu

Idle question about 2.0.x CSS calls

Started by Antechinus, September 24, 2019, 09:44:35 PM

Previous topic - Next topic

Antechinus

Was just wondering about something that occurred to me. Default index.template.php has always called CSS files like this:

// The ?fin20 part of this link is just here to make sure browsers don't cache it wrongly.
echo '
<link rel="stylesheet" type="text/css" href="', $settings['theme_url'], '/css/index', $context['theme_variant'], '.css?fin20" />';

// RTL languages require an additional stylesheet.
if ($context['right_to_left'])
echo '
<link rel="stylesheet" type="text/css" href="', $settings['theme_url'], '/css/rtl.css" />';


Which, on reflection, doesn't seem to make a whole lot of sense. It's ok if variants only change colours (and fair enough, most of them only do that) but if you have a variant that changes any positioning then you might want rtl_variant.css as well. And if ?fin20 is useful for preventing caching problems with index.css, then logically you'd want something similar for rtl.css, yes?

So really, it seems more sensible to call the files like this:

// The ?fin20 part of this link is just here to make sure browsers don't cache it wrongly.
echo '
<link rel="stylesheet" type="text/css" href="', $settings['theme_url'], '/css/', ($context['right_to_left']) ? 'rtl' : 'index', $context['theme_variant'], '.css?fin20" />';


Which not only provides more potential functionality but is less verbose code as well. Saves an http request too. Can anyone see anything wrong with this alternative?

The only catch I can think of is that it would require a complete rtl.css instead of a partial add-on file, but you have to go through the whole damned index.css when creating the partial add-on anyway, so in some ways it would make more sense to just use a copy of index.css and change positioning as you go rather than trying to pick out all the relevant bits for placement into another file.


(PS: If anyone wants to see awesome levels of mindf***ery in the GUI, try running the above code with a default rtl.css and an RTL language pack selected in admin. Makes one hell of a mess. :D )

Antechinus

Ok awesome coding dudes and dudesses: here's another question.

Given that the previous plan doesn't seem to have anything wrong with it, apart from increasing the total package size by a negligible number of kB, that led to another thought.

If I'm going to code for RTL support (one of those geek thangs, y'know) then it would be logical to also have the ability to load admin_rtl.css and editor_rtl.css when required. Bit silly if you don't, because any additional files are called after the basic CSS files and will consequently override rtl.css in the cascade, thus ensuring your admin and editor pages are configured for LTR. Not exactly an optimal result. :P

Now I can just tell that handling this effectively is going to require (cue dramatic music and gasps from the crowd) pigging around in the back end code in Sources, because forsooth that be where them monsters lurk. Unless, and here's the possibly groovy bit, there is a way of overriding the default Sources code in the theme's index.template.php.

Is this feasible? Is it sane? Answers scribbled on fag packets are fine.

ETA: The relevant Sources shiz seems to be this:

Code (Load.php Lines 1817-1842) Select
// Load a template - if the theme doesn't include it, use the default.
function loadTemplate($template_name, $style_sheets = array(), $fatal = true)
{
global $context, $settings, $txt, $scripturl, $boarddir, $db_show_debug;

// Do any style sheets first, cause we're easy with those.
if (!empty($style_sheets))
{
if (!is_array($style_sheets))
$style_sheets = array($style_sheets);

foreach ($style_sheets as $sheet)
{
// Prevent the style sheet from being included twice.
if (strpos($context['html_headers'], 'id="' . $sheet . '_css"') !== false)
continue;

$sheet_path = file_exists($settings['theme_dir']. '/css/' . $sheet . '.css') ? 'theme_url' : (file_exists($settings['default_theme_dir']. '/css/' . $sheet . '.css') ? 'default_theme_url' : '');
if ($sheet_path)
{
$context['html_headers'] .= "\n\t" . '<link rel="stylesheet" type="text/css" id="' . $sheet . '_css" href="' . $settings[$sheet_path] . '/css/' . $sheet . '.css" />';
if ($db_show_debug === true)
$context['debug']['sheets'][] = $sheet . ' (' . basename($settings[$sheet_path]) . ')';
}
}
}

Bloc

Its flawed already IMO. Calling a variant CSS by just fetching a copy of the normal index.css is counter productive. I've seldom used it this way because it 1) makes the variant css less managable - that is, keeping it up with index.css and that will be just as big as it - and 2) its just a lot easier to simply call index.css first, then the variant do its work and pin-point the changed styles. That is, if your variants are more or less color variations. Which brings me to...

..In a way variants in 2.0 functions more like "subthemes", not just css color variants as it often is intended and used as. But - if its meant for actual subthemes its less powerful than for example also being able to change templates within the subtheme. Even less powerful if you dont change any default templates - then you are stuck with templates that more or less are tailored for one look only(default) AND you got to take with you as much of default css just to make it look ok. The alternative is often just making a new theme using a better base set of templates and build color variations from that IMO. Not many do that AFAIK.

But that said...it makes sense to put the whole thing also in RTL, but again, it makes for a hard job tracking those big files and keeping them in sync.

I am actually more fond of the idea to make smaller css files that rely on each other, and rather merge them into a temp css for production, something Elkarte does(and SMF 2.1? Not sure atm) which alleviates the need to minimise the number of files. Of course, within sane limits, 20 small files is just out of the question. :D 

Antechinus

Yes, Elk and 2.1 have automatic consolidation and minification of CSS and JS files, which is nice if you can get it. Not an option for 2.0.x though, unless you go with installing a custom app of some sort to handle it.

I agree that the single call for index_thingy.css is not optimal, unless you're changing a heck of a lot in the variants. OTOH, if you're only changing colours in the variants there's something to be said for not having variants files at all, and simply using a body id or similar to call your variants, with the additional CSS for them appended to the basic index.css (ie: body id="red_thing" in the HTML, set by a ternary, and CSS like .windowbg {color: #fff;} #red_thing .windowbg {color: red;}). As long as it gets minified that's probably the best option for basic variants.

What got me thinking about how to handle RTL is that RTL support is really very easy once you are sure you have LTR sorted. You just scan through the file one declaration at a time (and FFS I know the whole thing backwards by now :D ) and swap margins, paddings and positioning as you go. It doesn't take long, and if you have to do that anyway then picking out the declarations for another file is just more work.

But I can also see the sense of splitting things down a bit, which is why I'm making the most use of files that SMF will force calls for anyway (editor.css is a good example). I just think they should be available in RTL as well as LTR, and if they aren't then I'd say that's a bug which needs fixing.

Bloc

True. But is this changed for the better in 2.1? I don't see it changing in the feature-locked 2.0.x.

Antechinus

#5
I don't expect the team to change it for 2.0.x. However, I do expect to be able to implement a custom workaround in 2.0.x. Obviously I can do it with a Sources hack, but I'd rather make it a standalone theme thing if feasible.

Oh and TBH, I'm not sure if it is changed for the better in 2.1. I haven't yet looked into how 2.1 supports (or doesn't support) RTL. But, given the team has always been very LTR-centric, I would not be surprised if this had been overlooked again.

ETA: Just took a quick look in the guts of 2.1. Relevant code appears to be this:

mkdir($context['to_install']['theme_dir'] . '/css', 0777);
$to_copy = array('/index.php', '/index.template.php', '/css/index.css', '/css/responsive.css', '/css/slider.min.css', '/css/rtl.css', '/css/calendar.css', '/css/calendar.rtl.css', '/css/admin.css', '/scripts/theme.js');
$to_copy = array('/index.php', '/index.template.php', '/css/index.css', '/css/responsive.css', '/css/slider.min.css', '/css/rtl.css', '/css/calendar.css', '/css/calendar.rtl.css', '/css/admin.css', '/scripts/theme.js');


Which, if I'm not missing anything, implies it will support the basic index.css and rtl.css, as you'd expect, and will also support an RTL file for the calendar, but will not support an RTL file for anything else. Which, again if I'm not missing anything, is frankly a bit bonkers. Particularly for things like responsive.css, which is inevitably going to include declarations for positioning of some elements.

Reminds me of my old sig: "Sources code - making front end changes impossible since 1863." :D

Arantor

I wouldn't call it "Sources code", I'd call it design that's a little naive, because subtheme support in SMF is woefully incomplete (though, conceptually existant), what would be neat is if it were finished off and then added SCSS so SCSS imports could import across themes, then you'd ditch the variant thing and make it actual sub themes and just be done with it.

Antechinus

Personally I have no interest in SCSS, and would regard that as just extra crud to work around (much like Bootstrap). Although as long as you had the option of ignoring SCSS and just coding in straight CSS then sure, no problem. That should keep everyone happy.

But I think you're rather missing the point here. The point of this topic is not subthemes as such. The point is proper (ie: full) support for RTL languages. It just doesn't seem sensible to not do it comprehensively.

What I'm after is the sanest option for overriding default Sources loads of things like admin.css and editor.css, so that I can get RTL CSS for those areas of the GUI too. At the moment they don't get it, and from a CSS perspective it would be easy to do. Now presumably (haven't given it much thought) this would be possible in the template, but offhand I'm not sure how.

I could just call all of those files myself, with a ternary to select LTR or RTL, but for that to work I'd have to put in head after the default call for "HTML headers". Which then means if I call admin.css after the HTML headers that would be a second call for the same file. Which is probably not going to matter for LTR situations (albeit it's inefficient) but seems stupid for RTL situations (because there's no point loading both files when you only want the one that conflicts with the one Sources wants to load).

So what I really want is code in index.template.php, which tells Sources to eff off and die for any default loading of CSS files related to default SMF actions. Either that or I just write a mod that hacks Load.php to make it do what I want, but I'd prefer a standalone solution in the template itself.

SychO

Quote from: Antechinus on September 27, 2019, 07:27:45 PM
.. and will also support an RTL file for the calendar, but will not support an RTL file for anything else. Which, again if I'm not missing anything, is frankly a bit bonkers.

It is not bonkers, the RTL file was changed to load last after all other css files, so that it's code can override any of the others, you don't need an RTL version of every css file, you can use just the one RTL.css

As for why there is a calendar.rtl, I'm not sure but it might've been because it includes a lot of css blocks.

Relevant Pull Request
https://github.com/SimpleMachines/SMF2.1/pull/5387
Checkout My Themes:
-

Potato  •  Ackerman  •  SunRise  •  NightBreeze

Antechinus

Ok, I understand the idea, but look at the code. You're still loading rtl.css before admin.css, so any RTL presentation is not applicable to admin areas of the GUI. Which is fine if you have no laterally asymmetric positioning, paddings or margins in admin.css, but I'm betting you do. Safe bet, too. I just opened admin.css and on Line 9 we have:


#admin_content .button {
float: right;
}


How are you implementing RTL support for that, just as an example?

ETA: By the way, calendar.rtl.css only contains 23 lines of code. If you're planning on having one RTL file do everything, the calendar file is pretty pointless. The rtl.css file is already 687 lines of code. What's another 23?

SychO

We are talking about 2.1 right ? because that's the exact opposite of what I said,
rtl.css loads last after all other CSS files (before responsive.css however) so that it can overwrite all other CSS codes.




Quote from: Antechinus on September 28, 2019, 04:42:57 AM
ETA: By the way, calendar.rtl.css only contains 23 lines of code. If you're planning on having one RTL file do everything, the calendar file is pretty pointless. The rtl.css file is already 687 lines of code. What's another 23?

Then it would make more sense to get rid of the file and move the code over to rtl.css imho
Checkout My Themes:
-

Potato  •  Ackerman  •  SunRise  •  NightBreeze

Antechinus

Ah. Ok, that's different to the stack in Themes.php. Fair enough then. Where is that code stashed? I was looking for CSS load code in Sources and the one I found was in Themes.php.

And yes, it would make sense to amalgamate the rtl code for the calendar into main rtl file. Calendar.css (LTR version) is pretty bloated at the moment. I took a look, just out of curiosity. I'm about a third of the way through it and have already knocked about 17% off the file size with no visible differences. Could have had a greater reduction by this point, but so far haven't bothered looking up hex equivalents for all the verbose rgba declarations (which are pointless when they're only showing a solid cell background anyway).

Although this still doesn't do anything to answer my original question: namely what's the best way of getting solid RTL support in a 2.0.x theme?

SychO

Quote from: Antechinus on September 28, 2019, 05:34:20 AM
Ah. Ok, that's different to the stack in Themes.php. Fair enough then. Where is that code stashed? I was looking for CSS load code in Sources and the one I found was in Themes.php.

Well, every css file is loaded from their respective source file, the main css files though are loaded from Load.php

// And of course, let's load the default CSS file.
loadCSSFile('index.css', array('minimize' => true, 'order_pos' => 1), 'smf_index');
// Here is my luvly Responsive CSS
loadCSSFile('responsive.css', array('force_current' => false, 'validate' => true, 'minimize' => true, 'order_pos' => 9000), 'smf_responsive');
if ($context['right_to_left'])
loadCSSFile('rtl.css', array('order_pos' => 4000), 'smf_rtl');

https://github.com/SimpleMachines/SMF2.1/blob/fcd7b2c0acf17d3bd6f6a5e84a1840e60e0ec6ac/Sources/Load.php#L2260-L2267

Quote from: Antechinus on September 28, 2019, 05:34:20 AM
And yes, it would make sense to amalgamate the rtl code for the calendar into main rtl file. Calendar.css (LTR version) is pretty bloated at the moment. I took a look, just out of curiosity. I'm about a third of the way through it and have already knocked about 17% off the file size with no visible differences. Could have had a greater reduction by this point, but so far haven't bothered looking up hex equivalents for all the verbose rgba declarations (which are pointless when they're only showing a solid cell background anyway).

there's a lot that can be improved in the CSS of 2.1
Checkout My Themes:
-

Potato  •  Ackerman  •  SunRise  •  NightBreeze

Antechinus

#13
Hey hang on a sec. What happens to RTL formatting when responsive.css kicks in? Isn't that going to bork things a bit?

I might whip through the 2.1 CSS a bit more seriously once I have my current Curve mutant plaything a bit more sorted. I can give you an edited calendar.css without much trouble though, any time you want it. Index.css is a bit more serious.

ETA: Actually responsive.css isn't too bad. There are 19 declarations that are laterally asymmetric. Not sure how important they are as I haven't checked yet.

ETA again: Lolz. The only declaration that is needed in calendar.rtl.css is the one to float the month-grid over at the right. The rest are superfluous. You could even get rid of that if you used flex or table-cell to do the main and month grids (with #calendar as the necessary parent).

Bloc

I have objected to the bit about the hidden loading of CSS files before and got bitten off rough - so not going there again. :P Suffice to say, in any theme I do for 2.1 I WILL take a good look at any CSS file automatically loaded that I cannot spot or see inside index.template.php. Its "bonkers" - to rip off Antech's fav expression lol - to not have those files visible. I understand the reasoning, sure, mods and all that, but still it hinders doing great stuff when you don't see whats doing that aprtuclar pace/style going nuts...and so on.

To counteract these files  in SMF 2.0 I just add them and remove everything in them. Done deal. They get loaded, not optimal, but at least they don't contain any hidden styles that will influence further out in the theme's supplied CSS.


SCSS..agree with Antech here, thats an unecessary added framework added on top of normal CSS and it will make it easier to work with CSS problems, sure. It will also make you unaware - and able - of how to make better optimsations within normal CSS limitations. Things you feel is only doable with SCSS instead of actually finding better solutions with normal CSS. IMO anyway, others may disgree.

Antechinus

#15
Hey here's a thought (which still doesn't do anything to answer my original question): it should be possible to turn off minification for testing. I'd quite understand if this was mod territory, but I can see it being useful. The css directory rapidly gets full of old minified files, and they're a PITA when running recursive searches to track down gremlins. A switch to turn it off would be very handy. :)

And re the loading of shiz: if minification could be switched off, it'd be a lot easier to see what files were being loaded and in what order. Any decent web dev add-on will give you that information if it can get hold of individual files. ;)

ETA: Ha! Already has that switch hidden in admin. Easy. :D It's on ?action=admin;area=featuresettings;sa=basic; about halfway down the page.

PS: To give her credit, I remember the thread about loading shiz and Suki explained it all very well, to my satisfaction, after copping quite a bit of flack. Yes, it is a bit more work for themers, but it's certainly not impossible to deal with, and a no-minify switch would make it pretty simple.

Quote from: Bloc on September 28, 2019, 07:11:25 AMTo counteract these files  in SMF 2.0 I just add them and remove everything in them. Done deal. They get loaded, not optimal, but at least they don't contain any hidden styles that will influence further out in the theme's supplied CSS.

Oh, just caught this. As you say it's not optimal, but within 2.0.x's limitations it may be the best option for a quick and dirty fix. I don't like it though. It's nasty. I'd prefer something cleaner.

Arantor

You know that using CSS exactly as you are today is completely compatible with SCSS, right? It just works. But the ability to do things like give users a colour picker in the admin panel to set accents and stuff like that so you don't have to... that's worth its weight in gold to me as a platform owner.

Hell, even if you just used CSS with imports (which you can totally do even in regular CSS, the syntax is the same in SCSS, but the compiler includes it inline for performance), you could do what you were trying to do with less hassle.

Also, 2.1 has the ability to turn it off, or it did when I forked off. Admin search is probably your friend.

SychO

Resource minimization CAN be turned off, and you can see the order at which files are loaded if you check the pages html head tag.

You can also stop the forum from loading any resources if you wish

// Allow css/js files to be disabled for this specific theme.
// Add the identifier as an array key. IE array('smf_script'); Some external files might not add identifiers, on those cases SMF uses its filename as reference.
if (!isset($settings['disable_files']))
$settings['disable_files'] = array();
Checkout My Themes:
-

Potato  •  Ackerman  •  SunRise  •  NightBreeze

Antechinus

I already found that. And I already knew about swtiching off loading of files in 2.1

Quote from: Antechinus on September 28, 2019, 07:27:43 AMETA: Ha! Already has that switch hidden in admin. Easy. :D It's on ?action=admin;area=featuresettings;sa=basic; about halfway down the page.

PS: To give her credit, I remember the thread about loading shiz and Suki explained it all very well, to my satisfaction, after copping quite a bit of flack.

But, and I do mention this every so often, this thread is really about questions for 2.0.x.

Quote from: Antechinus on September 28, 2019, 05:34:20 AMAlthough this still doesn't do anything to answer my original question: namely what's the best way of getting solid RTL support in a 2.0.x theme?

To which the only answers seem to be:

1/ Write a mod to hack Load.php, or...

2/ Empty all the offending files, so that although they still get loaded they don't actually do anything.

If there's a third and better option I really would like to hear about it. :)

SychO

If you don't want additional css files to override your rtl.css, then load rtl.css after this line in index.template.php


// Output any remaining HTML headers. (from mods, maybe?)
echo $context['html_headers'];
Checkout My Themes:
-

Potato  •  Ackerman  •  SunRise  •  NightBreeze

Advertisement: