News:

Want to get involved in developing SMF, then why not lend a hand on our github!

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

Just gave it a quick run on local. Seems to be fine. Files aren't called, and no errors are logged.

Arantor

Awesome, I did test it on mine but it never hurts to check :)

Antechinus

I'm currently (ie: quick test) calling the sheets 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" />';

if (!empty($context['current_action']) && $context['current_action'] == 'admin')
echo '
<link rel="stylesheet" type="text/css" href="', $settings['theme_url'], '/css/', ($context['right_to_left']) ? 'admin_rtl' : 'admin', $context['theme_variant'], '.css?fin20" />';

if (!empty($context['current_action']) && (($context['current_action'] == 'post')||($context['current_action'] == 'pm')))
echo '
<link rel="stylesheet" type="text/css" href="', $settings['theme_url'], '/css/', ($context['right_to_left']) ? 'editor_rtl' : 'editor', $context['theme_variant'], '.css?fin20" />';


Which I might change after a bit more thinking, but which works as far as the basics go.

Arantor

Yeah, that works. I could probably tweak the above to identify and return which ones, if any, that it found to remove if that would be any help?

The editor does appear in other places than just those - like the newsletter editor, plus mods.

Antechinus

#44
Quote from: Arantor on December 01, 2019, 05:59:18 PMI could probably tweak the above to identify and return which ones, if any, that it found to remove if that would be any help?

Not sure what you mean there.

QuoteThe editor does appear in other places than just those - like the newsletter editor, plus mods.

Hmm. Sounds like fun. Obviously I can sort any default actions (and could just add action=admin to the current call for editor.css). Mods could be a nuisance though. To deal with those comprehensively it might end up making more sense to go back to rewriting Load.php with a mod, if they're going to make things convoluted in the template.

ETA: Although revamping Load.php is obviously going to be problematic if people have more than one theme installed, since it could screw other themes that don't use the same structure in index.template.php. Meh. :P

Arantor

So right now it just removes editor, and admin from the list. But maybe it should tell you which ones it removed so you can put in your versions as needed.

As I said, other pages show the editor, not just the ones you've listed, and mods will break unless that is fixed.

I'll have a think about it today.

Bloc

Poor mans solution: add all css files from default theme into your own theme, and set them all to zero content. :) They are still fetched but at least you catch them all that way. Of course, mods that add their own will not be affected unless you specifially target them too.(like tp-style.css in TinyPortal).

I found it quite refreshing to have -0- styles inherited from default theme. The freedom lol :D

Antechinus

#47
Quote from: Bloc on December 02, 2019, 03:16:18 AMPoor mans solution: add all css files from default theme into your own theme, and set them all to zero content.

No. :P Do not want.


Quote from: Arantor on December 02, 2019, 02:34:38 AM
So right now it just removes editor, and admin from the list. But maybe it should tell you which ones it removed so you can put in your versions as needed.

Ah. Wouldn't worry about it. It already tells you which ones it's removing. They're listed in the array, so no problem.

$remove_bundled_stylesheet(['admin', 'editor', 'editor_ie']);

Can't see why it would need anything more than that.


QuoteAs I said, other pages show the editor, not just the ones you've listed, and mods will break unless that is fixed.

I'll have a think about it today.

I'm thinking that as long as I nail all the relevant default actions, mods can be sorted later. Mutant Responsive Beastie is not going to be 100% compatible with all available mods anyway. It'll require custom tweaks for some of them, just as the old "Responsive Curve mod" does. If the necessary calls can be added easily I think that would be fine. As far as I can tell, it'd simply be a matter of adding actions to the IF conditional, which isn't that big a deal.

ETA: While I think of it, when doing the initial test I did run it with the default admin.css and editor.css knocked out by your code, but without replacing them with my custom calls. This was actually ok for the editor pages. Not as flash for eye candy, but perfectly usable. So even if a mod does run without editor.css on some obscure pages it wouldn't necessarily be a deal breaker, and could be fixed easily anyway.

Also, I don't think the textarea in the newsletters section is relevant to editor.css. It appears to just be a standard textarea, styled from index.css and/or admin.css. This custom code doesn't have to worry about most textareas. It's only the actual editor, as shown on the reply page, that matters. Is that shown anywhere other than action=post and action=pm?

Arantor

You see, that's my point. You don't know where these things were called. If I have my code report on what it found, then you can know correctly to reinstate things.

The editor will be shown on the newsletter writing (not the news page but the actual newsletter constructor as it has the WYSIWYG editor) page and all sorts of mods, none of which you can know about currently.

Antechinus

Yes, I know it's not the news page that you're talking about.

Does anyone actually use the 2.0.x WYSIWYG? It's pretty screwed. With the WYSIWYG turned off in profile settings, the newsletter composition page appears to just show a bog-basic textarea. No BBC buttons or any other frills, so works just fine even without editor.css.

But even the non-WYSIWYG editor at action=post works without editor.css. It just doesn't look quite as slick. And the additional CSS for the WYSIWYG is trivial. I'm not sure it's even necessary. A lot of 2.0.x CSS isn't (can test to check it, just to make sure).

TBH the only reasons I'm even using editor.css are a/ it was already called by default, so I thought it might as well do something and b/ by default it did SFA, so I moved whatever I could from index.css to editor.css. But I could easily move it back to index.css, thereby making editor.css completely unnecessary. It's only a few kB. I'm pretty sure editor_ie.css isn't necessary these days either. I suspect it was only relevant for IE6 and IE7 (can test that too).




Arantor

function template_html_above()
{
global $context, $settings, $options, $scripturl, $txt, $modSettings;

$remove_bundled_stylesheet = function($sheets) use ($settings, &$context)
{
$removed = [];
foreach ($sheets as $sheet)
{
$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)
{
$header = "\n\t" . '<link rel="stylesheet" type="text/css" id="' . $sheet . '_css" href="' . $settings[$sheet_path] . '/css/' . $sheet . '.css" />';
if (strpos($context['html_headers'], $header) !== false)
{
$removed[] = $sheet;
$context['html_headers'] = str_replace($header, '', $context['html_headers']);
}
}
}
return $removed;
};
$removed = $remove_bundled_stylesheet(['admin', 'editor', 'editor_ie']);


Now you can say:

if (in_array('admin', $removed)) {
    ... blah blah blah include admin w/rtl CSS ...
}

And you don't have to check the action or anything for the editor, you can simply see exactly what was previously there and include your replacement.

Looks like I was wrong about the newsletter - but I still wouldn't presume that those are the only places it is used, because mods do various things, and I'd rather be able to know which was actually used and therefore what I need to add back, seems more reliable in my world.

Antechinus

Ok, so why don't I just move the editor CSS back to index.css and solve the whole thing that way? No need to know about any actions or arrays. Just knock out the default calls from Load and there'd be no need to worry about anything else.

Arantor

That also works, just if you cared about sparing the CSS otherwise, that'd be how you'd solve it.

I also wouldn't presume that *every* case of including admin.css is inside the admin area, because mods do strange things.

Antechinus

Meh. Ok, I suppose going belt and brace makes sense.

Arantor

Reduces the number of support questions later ;)

Antechinus

Well yeah, but traditionally it's up to mod authors to deal with integrating their mods into custom themes, so I could just torture them for fun. :D

Arantor

It will be assumed to be your problem if it works correctly on standard Curve though ;)

Antechinus

Nope. It's still a custom theme. In fact it's far more heavily customised than most themes on the Theme Site. It just looks mostly like Curve (apart from the different header, different board index, different message index, etc, etc, etc). So I could torture them just for fun and still claim to be within my rights. Don't tempt me. ;)

Arantor

You don't do much support here :P I guarantee you it will be presumed any weirdness in a mod that works fine on Curve but not a theme will be presumed to be the theme author's fault and people with trouble will be advised to go to the theme thread for support.

This is just how it's been for a while.

Antechinus

That's different. It used to be that people would be told to see the mod author about it.

Advertisement: