[#31520] - [4.0] Cassopeia template and blog sample data fixes and improvements
- Fixed in Code Base
- 1 Dec 2020
- Medium
- Build: 4.0-dev
- # 31520
- Diff
- richard67:4.0-dev-cassiopeia-development
User tests: Successful: Unsuccessful:
Pull Request for Issues #30812 , #30680 , #30515 , #30442 , #30426 , #29504 , #29311 , #29138 , #25239 , #24129 and possibly more which haven't been identified yet.
Summary of Changes
Introduction
This pull request (PR) is the result of the work of the Frontend Template Working Group (JEDT - FT) in the recent few months for improving Cassiopeia, the default site template of Joomla 4.0.
Beside fixing template-specific issues and bugs, our task was to make Cassiopeia be a good showcase for new features in Joomla 4.0, together with improved sample data and without introducing any additional third-party dependencies.
Development took place in the Cassiopeia repository on GitHub, so there you can find why things have been done like you can see them here.
The implementation was mainly done by following contributors (in alphabetical order):
@chmst , @drmenzelit , @hans2103 and @richard67
But of course we had some help, therefore our special thanks goes to (in alphabetical order)
@brianteeman , @ciar4n , @helvecio , @infograf768 and @N6REJ
for advice, support, testing and contribution.
Improved Template Structure - HTML and SCSS
The structure of the template has got countless small changes and a new, clear structure for SCSS files. The header has got a new structure. Module positions are the same as before.
New Error and Offline Site
The error and offline pages have been rewritten so they match the structure of the template's index.php and use the new features like colour themes or fonts schemes.
Accessibility Improvements
Not only for the template itself (colours, font sizes), but also in layouts of the Joomla core many improvements for accessibility have been made, especially in the search module and search result page.
- Colour contrast ratio is AA over the whole template.
- Font Size and Line Height are user friendly.
- For icons and images, aria labels and alt-texts are carefully used .
- All elements are included in landmarks .
- The elements and the dropdown menu (metismenu) are accessible also for keyboard users.
- Font size and family for frontend editing have been improved.
Many a11y improvements which we have found during this project were made in layouts of the Joomla core with other pull requests, but there are still some issues left in the Joomla frontend (e.g. structure of headings) where further improvement is needed.
Accessible Dropdown Menu
Currently Joomla 4 and the Cassiopeia template don't provide an accessible dropdown menu which can be used in horizontal or vertical orientation. Bootstrap classes like e.g nav-pills don't work like they did in Joomla 3.
Because the impact on the default layout of the menu module would have been to large and possibly not b/c, we have decided not to fix that.
Instead of this we have decided to provide an accessible dropdown menu with the template as alternative layout for the menu module:
There was much discussion with pros and cons if we should have made it an alternative layout provided by the module, so it can be used by other templates, too, without having to copy the files.
We have decided against it, but if it is desired to change it that way, it can be done with a future PR.
And we have decided to use metismenujs, the vanilla JS variant of metismenu, because it is already used in the Atum backend template.
Fonts Schemes
In the Protostar template in Joomla 3 it is possible to switch off Google Fonts. When switched on, the necessary CSS is added as inline CSS, when switched off, the default font-family from Bootstrap CSS is used.
In Joomla 4 inline CSS has been removed, and so the Google Fonts can't be switched off. This is not compliant to GDPR. Also for GDPR compliance, people might want to use previously downloaded web fonts from a local folder.
To make both possible, we have implemented Fonts Schemes.
A Fonts Scheme is nothing else than an (S)CSS file which imports the CSS for local fonts or web fonts and sets CSS variables (instead of creating inline CSS) for font family and weight for headings and text.
"Fonts Scheme" and not "Font Scheme" because different fonts can be used for headings and body.
To have some example for everything, we have decided to provide following Fonts Schemes:
- "None" means loading any local fonts or web fonts is switched off, and the
font-familyfrom CSS is used like it would be set by Bootstrap 4. This might look different on different browser and OS but is compliant with GDPR and doesn't have any impact on page load times or server load. This is the default setting on a new installation. - "Roboto (local)" uses the local Roboto font which is already used for the Atum backend template.
- "Fira Sans (web)" uses the "Fira Sans" font from Google Fonts, like is is now in the Cassiopeia template without this PR.
- "Roboto + Noto Sans (web)" uses the "Roboto" fonts for headings and the "Noto Sans" font for other text, both from Google Fonts. In opposite to the other fonts schemes, headings have normal font weight here for a more tiny look and to have an example for that.
Using local fonts is compliant with GDPR but may have an impact on server load and (if not HTTP/2) on page load times.
Using fonts from web might not be compliant with privacy regulations like GDPR but doesn't have such performance impacts.
Fonts Schemes can also be defined to use other web fonts than Google Fonts.
Colour Themes
In the Protostar template in Joomla 3 it is possible to switch on or off template-specific colours. If switched on, some inline CSS is added for some basic colouring, but without certain effects as you can have without template colours like e.g. gradients.
In Joomla 4 inline CSS has been removed, and so there is no way to change template colours.
Therefore we have implemented Colour Themes.
A Colour Theme is nothing else than an (S)CSS file which sets CSS variables for the template.
The template comes with 2 Colour Themes:
- Standard
This is the default theme for which we have optimized colours so everything looks well together. - Alternative
This is just an example on how to implement another colour scheme. It can be optimized with future PRs, if desired.
New Template Style Parameters in backend
For the 2 new features "Fonts Schemes" and "Colour Themes", new fields have been added to Cassiopeia's template style parameters.
Blog Sample Data (English)
Blog Sample Data has been updated by new images and a dropdown menu example and has been extended by examples for tags, custom fields and different list and blog views, and a typography page has been added.
Other Improvements
The back-to-top link which can be switched on in template style parameters has been improved so that it appears when scrolling down, then remains on a fixed position while further scrolling, and disappears after having scrolled up to the top.
Testing Instructions
Preparation
Attention: This PR can't be tested with Patchtester because the patch is too big.
If you have a development environment for Joomla 4, i.e. a git client and composer and npm, checkout the 4.0-dev-cassiopeia-development branch from my fork, run "composer install" and "npm ci" and then make a new installation.
If you don't have that, use the following package to make a new installation: https://ci.joomla.org/artifacts/joomla/joomla-cms/4.0-dev/31520/downloads/38001/Joomla_4.0.0-beta6-dev+pr.31520-Development-Full_Package.zip
Optionally, set up a multilingual site.
After setup has completed, log in to backend.
On a multilingual site, either install "Multilingual Sample Data" or do the necessary steps (enable language filter plugin, publish content languages, create home menu items) manually.
Finally install "Blog Sample Data". On a multilingual site, change backend language and install "Blog Sample Data" again a few times to have it at least installed for some of the content languages.
Basic Tests
- Check which js files and css files are loaded in the frontend.
- Explore what is available in the Main Menu Blog dropdown menu in the header area.
- Check the different types of layouts. Change layout parameters in backend and check again.
- Play with template style options in backend, not only those added by this PR, and check the result in frontend.
- Test both without being logged in to the frontend and also as logged user with edit permissions.
- Test everything also RTL, either by using an RTL language in frontend, or by editing
language/en-GB/langmetadata.xmland changing<rtl>0</rtl>to<rtl>1</rtl>. - Test everything also with small screen sizes for mobile clients.
- Check also the error and the offline page.
Tests for Dropdown Menu
Modify the "Main Menu Blog" so that it has a deeper structure, i.e. more levels of submenus.
Make several copies of the "Main Menu Blog" module. Publish these copies at different module positions, e.g. "top-a", "breadcrumbs", "main top", "sidebar-left" or "sidebar-right" and "footer".
At different module positions where horizontal menus make sense, i.e. mainly not in the sidebars, add module class "menu-horizontal" in advanced module parameters, and check the result in frontend.
Check that the horizontal menus become vertical on small screens for mobile clients.
Test all dropdown menus with different module styles like "card", "noCard" and others.
And don't forget to test RTL for any kind of menu, horizontal or vertical.
For Advanced Testers: Modify the template
In backend, go to "System -> Site templates -> Cassipeia Details and Files", and create a copy of the template.
Modify the copy e.g. by adding a user.css or using your own fonts, images, own css framework and own modules.
You can add a new fonts scheme by copying and modifying one of the existing files /templates/cassiopeia/scss/global/fonts-local_*.scss or /templates/cassiopeia/scss/global/fonts-web_*.scss, depending if fonts shall be loaded from a local folder or from web, if you can compile SCSS files. If you can't compile SCSS files, you can copy and modified the CSS files /templates/cassiopeia/css/global/fonts-local_*.css or /templates/cassiopeia/css/global/fonts-web_*.css instead. Finally add a new value to the right group (local fonts of web fonts) of the useFontScheme field in the template's templateDetails.xml file, and you are done.
Same with colour themes: Either copy and modify one of the existing files /templates/cassiopeia/scss/global/colors_*.scss if you can compile SCSS files, or do that with one of the CSS files /templates/cassiopeia/css/global/colors_*.css.
The (S)CSS files are more or less self-explaining.
Actual result BEFORE applying this Pull Request
After installing blog sample data you get following out of the box:
You can not really see much of the advantages and improvements of Joomla 4.
After moving the "Main Menu Blog" module to module position "menu" and adding a Smart Search module on position "search":
As you can see, the colour of the search button doesn't really fit to the template.
The default menu layout is not really usable when having horizontal orientation, which is only possible on module positions in the header section of the template, e.g. position "menu".
The template always loads the Fira Sans font from Google Fonts in web, there is no way to switch that off or change to locally hosted fonts.
The error page looks as follows with the "Main Menu Blog" module configured as before:
Expected result AFTER applying this Pull Request
After installing blog sample data you get following out of the box, here on the "Home" page:
Blog view:
There are no fonts loaded because the Font Scheme is set to "None". Therefore the fonts may differ between browsers, but this is safe regarding GDPR and site performance.
The same blog view with Font Scheme "Roboto + Noto Sans (web)":
Dropdown menu and available sample layouts:
In the sidebars, the dropdown menu behaves like an accordion:
Horizontal dropdown menu at main-top:
Same without title and with module layout "noCards":
The error page:
We could add a lot more screenshots, but we think the result speaks for itself.
Documentation Changes Required
The new template style parameters should be described in some documentation about the Cassiopeia template.
The dropdown menu should be described at a suitable place in documentation.
| Status | New | ⇒ | Pending |
joomla-cms-bot
- | Category | ⇒ | Administration Language & Strings JavaScript Repository NPM Change Front End Plugins Templates (site) |
Like with other current J4 PRs, the failure of system tests in Drone seems not to be related to the PR but to a problem with testing environment ("Failed to connect to 127.0.0.1 port ...: Connection refused").
| Labels |
Added:
?
NPM Resource Changed
?
|
||
After the last commit, the failure of system tests in Drone seems not to be related to the PR but to a problem with testing environment ("Failed to connect to 127.0.0.1 port ...: Connection refused", like we currently have it for other J4 PRs.
There are still open review comments by @brianteeman , which are now hidden by default on GitHub due to the long history. But I've addressed them in the team so they will not be forgotten, and people can find them when going to the tab with the changed files https://github.com/joomla/joomla-cms/pull/31520/files and searching for "brianteeman" with the text search function of the browser.
Chrome gives this warning
The resource http://localhost/joomla-cms/templates/cassiopeia/css/global/colors_standard.min.css was preloaded using link preload but not used within a few seconds from the window's load event. Please make sure it has an appropriate
asvalue and it is preloaded intentionally.
Using the standard-colors or alternate-colors the .text-warning class only has a contrast ratio of 1.97 it should be at least 4.5
.text-warning {
color: #efac4d!important;
}
Using the alternate colors the value for color: var(--cassiopeia-color-link); only has a contrast of 4.2 - it needs to be at least 4.5
The typography article has a title Colour Scheme Standard which is obviously wrong when you have the alternate colour scheme loaded. I would suggest just changing the text to Colour Scheme
Sample layout articles needs to be adjusted to probably not include the typography article
and the same problem will come up with the latest posts module - I guess that moving the typography article out of the joomla category is the easiest solution
@brianteeman
Using the standard-colors or alternate-colors the .text-warning class only has a contrast ratio of 1.97 it should be at least 4.5
It is, how the colour is generated from variables.
We have discussed about the colour warning, because it is obviously wrong as a text colour on white background and should not be used. We can write "Do not use text-warning on white background, it is not accessible" or we could not show text-warning at all.
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/31520.
Or you could change the colour. Either we are serious about accessibility or we are not.
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/31520.
Or you could change the colour. Either we are serious about accessibility or we are not.
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/31520.
The typography article has a title
Colour Scheme Standardwhich is obviously wrong when you have the alternate colour scheme loaded. I would suggest just changing the text toColour Scheme
Done with the last commit. I've also fixed capitalization of the headings.
@brianteeman Regarding the warning colour and contrast: Unfortunately, the same colour is used for the solid button with black text, so if we make the warning colour darker, we might get contract problems with that black text in the button.
I remember this was done for the alerts, too, a while ago, and I think it was a bad move to use black text here in opposite to the others. It makes other types of alerts and warnings look weird together in my opinion.
I'd be happy to get some suggestions for a better colour and opinions on black or white text in warning buttons or warning alerts.
All I care about is that if we are advertising Joomla 4 as accessible then we can not ship it with sample content that showcases that it is not
Chrome gives this warning
The resource http://localhost/joomla-cms/templates/cassiopeia/css/global/colors_standard.min.css was preloaded using link preload but not used within a few seconds from the window's load event. Please make sure it has an appropriate
asvalue and it is preloaded intentionally.
@Fedik Do you have an idea what we are doing wrong? We register and preload that asset here, from my point of view with a correct "as style":
joomla-cms/templates/cassiopeia/index.php
Lines 40 to 44 in d55195a
... then we can not ship it with sample content that showcases that it is not
@brianteeman You mean if we would remove that case from sample data would also be ok, at least for now? Or shall we mention it in the description of the PR as an open issue and later when this PR gets merged make a new issue or PR for that?
@brianteeman P.S.: And of course we are happy that you care for it and help with reviews. thanks a lot for that.
My 2c is that this has to be resolved with this PR. Its a standard class that will be used, if not by core, then by extensions.
It is a requirement of the template that it is accessible.
My 2c is that this has to be resolved with this PR. Its a standard class that will be used, if not by core, then by extensions.
It is a requirement of the template that it is accessible.
Ok, we will try to fix that.
Do you have an idea what we are doing wrong?
As message says, the preloaded file not in use.
Unused preloads in Chrome will trigger a console warning ~3 seconds after onload. This happens when the resource isn't being consumed (e.g you're not trying to use a script you've preloaded) in a timely manner.
There recommendation to use prefetch https://stackoverflow.com/a/55974964/1000711
Maybe try:
$this->getPreloadManager()->prefetch(....);| Labels |
Added:
?
|
||
Chrome gives this warning
The resource http://localhost/joomla-cms/templates/cassiopeia/css/global/colors_standard.min.css was preloaded using link preload but not used within a few seconds from the window's load event. Please make sure it has an appropriate
asvalue and it is preloaded intentionally.
Solved with the last commit, also for the fonts schemes CSS.
Remember Me / Checkbox
The input fields are all large but the checkbox is still small
On the component do you think the checkbox and the label should be on the same line?
On the module the text and the checkbox alignment looks odd
components
module
Mobile ??
The desktop view has an underline on the text and the arrow
The mobile view only has an underline on the text
The desktop view has an underline on the text and the arrow
The mobile view only has an underline on the text
@brianteeman That's by design. It is not really an underline in the header on desktop size, it is an additional pseudo element, also without our PR for the "normal" menu.
Text align would not have an effect on the arrow.
We could make it behave in the header in the same way, i.e. not underline the arrow in any case.
But we thought in the header it is an additional, useful way to distinguish the 2 different kinds of parent menu items with and without a link on the first level.
Would you prefer that we change that so it is consistent, i.e. not "underline" the arrow at all in any case?
First of all: Thanks to contributors & helpers mentioned above!
Sorry if I bother with following: I made a new installation with complete download package.
-
After all necessary fields - Response: The installation process failed.
-
After closing above message: Congratulations! Your Joomla site is ready.
Joomla Installer Joomla! 4.0.0-beta6-dev+pr.31520 -
Backend:
Warning: simplexml_load_file(): /home/.sites/…./web/myspace/administrator/manifests/files/joomla.xml:50: parser error : Opening and ending tag mismatch: copyright line 7 and extension in /home/…./web/myspace/administrator/components/com_installer/src/Helper/InstallerHelper.php on line 172 Warning: simplexml_load_file(): in /home/…../web/myspace/administrator/components/com_installer/src/Helper/InstallerHelper.php on line 172 Warning: simplexml_load_file(): ^ in /home/…./web/myspace/administrator/components/com_installer/src/Helper/InstallerHelper.php on line 172 Warning: simplexml_load_file(): /home/.../web/myspace/administrator/manifests/files/joomla.xml:51: parser error : Premature end of data in tag extension line 2 in /home/…./web/myspace/administrator/components/com_installer/src/Helper/InstallerHelper.php on line 172 Warning: simplexml_load_file(): in /home/…./web/myspace/administrator/components/com_installer/src/Helper/InstallerHelper.php on line 172 Warning: simplexml_load_file(): ^ in /home/…./web/myspace/administrator/components/com_installer/src/Helper/InstallerHelper.php on line 172 -
Check of database:
Notice: Trying to get property 'version' of non-object in /home/…../administrator/components/com_installer/src/Model/DatabaseModel.php on line 555 -
You already have the latest Joomla version, ‎4.0.0-beta6-dev+pr.31520
-
Under Options: Maybe I should insert Custom Url, which one?
Should I change to: https://update.joomla.org/core/nightlies/next_major_list.xml?
Wanted to help testing something. I'm afraid, I think it's corrupted.
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/31520.
First of all: Thanks to contributors & helpers mentioned above!
Sorry if I bother with following: I made a new installation with complete download package.
-
After all necessary fields - Response: The installation process failed.
-
After closing above message: Congratulations! Your Joomla site is ready.
Joomla Installer Joomla! 4.0.0-beta6-dev+pr.31520 -
Backend:
Warning: simplexml_load_file(): /home/.sites/…./web/myspace/administrator/manifests/files/joomla.xml:50: parser error : Opening and ending tag mismatch: copyright line 7 and extension in /home/…./web/myspace/administrator/components/com_installer/src/Helper/InstallerHelper.php on line 172 Warning: simplexml_load_file(): in /home/…../web/myspace/administrator/components/com_installer/src/Helper/InstallerHelper.php on line 172 Warning: simplexml_load_file(): ^ in /home/…./web/myspace/administrator/components/com_installer/src/Helper/InstallerHelper.php on line 172 Warning: simplexml_load_file(): /home/.../web/myspace/administrator/manifests/files/joomla.xml:51: parser error : Premature end of data in tag extension line 2 in /home/…./web/myspace/administrator/components/com_installer/src/Helper/InstallerHelper.php on line 172 Warning: simplexml_load_file(): in /home/…./web/myspace/administrator/components/com_installer/src/Helper/InstallerHelper.php on line 172 Warning: simplexml_load_file(): ^ in /home/…./web/myspace/administrator/components/com_installer/src/Helper/InstallerHelper.php on line 172 -
Check of database:
Notice: Trying to get property 'version' of non-object in /home/…../administrator/components/com_installer/src/Model/DatabaseModel.php on line 555 -
You already have the latest Joomla version, ‎4.0.0-beta6-dev+pr.31520
-
Under Options: Maybe I should insert Custom Url, which one?
Should I change to: https://update.joomla.org/core/nightlies/next_major_list.xml?
Wanted to help testing something. I'm afraid, I think it's corrupted.
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/31520.
@ChristineWk I've updated the link in the testing instructions to the latest package. The error with the XML file has been meanwhile solved with PR #31525 , and this change has been integrated into this PR here meanwhile. Could you test again? Thanks in advance.
@richard67 I've installed ca. 2h ago, because the package incl. extracting etc. tooks/take time.
But how could I test again - it seems I have to install completely new instance? Thks for info.
But how could I test again - it seems I have to install completely new instance? Thks for info.
@ChristineWk Yes.
Maybe should you wait a bit with "official" testing until review phase has finished, because we might have to make changes. E.g. not all review comments have been addressed already.
But of course you can already test to have a look on it. I hope you will like what we have done.
Remember Me / Checkbox
The input fields are all large but the checkbox is still small
On the component do you think the checkbox and the label should be on the same line?
On the module the text and the checkbox alignment looks odd
The problem is related with #31218
And checkboxes are extremely difficult to style.. I have no solution for the size at the moment. I'm open for suggestions
Remember Me / Checkbox
And checkboxes are extremely difficult to style.. I have no solution for the size at the moment. I'm open for suggestions
Try this. It worked for me on Windows 10 Firefox and Chrome inspectors
input[type="checkbox"] { transform: scale(1.5); }
Remember Me / Checkbox
And checkboxes are extremely difficult to style.. I have no solution for the size at the moment. I'm open for suggestions
Try this. It worked for me on Windows 10 Firefox and Chrome inspectors
input[type="checkbox"] { transform: scale(1.5); }
@Scrabble96 Thanks.
@drmenzelit Could you check if that helps us at the right place? Thanks in advance.
Remember Me / Checkbox
And checkboxes are extremely difficult to style.. I have no solution for the size at the moment. I'm open for suggestions
Try this. It worked for me on Windows 10 Firefox and Chrome inspectors
input[type="checkbox"] { transform: scale(1.5); }
That could work, but at first the login module has to be re-worked, to separate label from input field. At the moment the checkbox is inside the label.
Using the standard-colors or alternate-colors the
.text-warningclass only has a contrast ratio of 1.97 it should be at least 4.5
@brianteeman Fixed with the last commit. Thanks a lot to @drmenzelit .
We have checked in the team and found out that it needed to fix (override) the warning alert's icon and "x" button colours, too, in order not to get contrast problems with the black SVG icon and for consistency.
So now they look as follows:
Firefox' accessibility check only reports a contract problem for the sr-only text next to the alert's icon. That's strange and I have no idea if we can avoid that somehow. It doesn't really make sense to me.
Could you check again? That would be great, Thanks in advance, and again thanks for that many reviews and tests.
What remains to be fixed for contrast are the issues you've found for the alternative colour theme.
That could work, but at first the login module has to be re-worked, to separate label from input field. At the moment the checkbox is inside the label.
This can be done with CSS:
.com-users-login fieldset .control-label {
margin-left: 2rem;
}
.com-users-login fieldset input[type="checkbox"].inputbox {
position: relative;
transform: scale(1.5);
top: -2rem;
}
so it looks like this:
For the module, it just needs the CSS I suggested first.
Using the alternate colors the value for
color: var(--cassiopeia-color-link);only has a contrast of 4.2 - it needs to be at least 4.5
I've fixed that by using the same colour for links in the alternative colour theme as we use for the info badges of the tags, so we don't establish another kind of blueish colour.
Now the accessibility test of Firefox is fine with it for AA.
This can be done with CSS:
@Scrabble96 Would at least need something for RTL.
@drmenzelit @chmst Do we want to solve it with CSS as suggested above with #31520 (comment), or do we want to wait for the markup being fixed in the layout with another PR?
@brianteeman It seems we have solved all issues you have found up to now. Thanks again for your time and energy.
Update: Except of the "Remember me" check box, that's still being clarified.
Contrast issues look resolved now - thanks
@brianteeman How about this different "underlining" for the top-level menu items in the header on desktop screen size? I've explained above why we have done it like that. Are you ok with that?
Doesnt make sense to me but then I also wouldnt have done the split button thing either
So at least you can live with it, it seems to me. Let's see if other opinions come in.
I think I said it before but its confusing that you can complete the image and the title field but only the image will display. Title will only display if there is no image
I think I said it before but its confusing that you can complete the image and the title field but only the image will display. Title will only display if there is no image
@brianteeman Wasn't it like that all the time, also in J3 Protostar? We did not want to change everything with our little project.
Font Weights
Roboto local
The headings are font-weight: 700
The body is font-weight: 400
Roboto + Noto
The headings are font-weight: 400
The body is font-weight: 400
Fira Sans
The headings are font-weight: 700
The body is font-weight: 400
Font Weights
Roboto + Noto
The headings are font-weight: 400
The body is font-weight: 400
We did that by purpose to show what you can do with Fonts Schemes and because having bold headings with Roboto looked a but too bold to me. But if people insist on it, we can change that.
If you do it with one then I would recommend doing it with all
Hmm, another thing for which I'd like to wait for more opinions.
Back to top
If you look at the animation below you will see that the back to top link is above the login but below the password
Back to top border
To me the lack of a border on the back to top button means that you end up with this chevron just floating on the screen without any obvious reason. Compare the visual impact both with and without a border
Hmm, another thing for which I'd like to wait for more opinions.
For me the user is selecting the font only - not different styling
Sticky Header
Is it intentional that the sticky header does not work on mobile?
@richard67 the menu underline is odd as the Help and Sample Layout menu items are different to each other on desktop but the same on mobile
@richard67 the menu underline is odd as the Help and Sample Layout menu items are different to each other on desktop but the same on mobile
I know. As said, that was intentional. If others find it odd, too, we can remove that.
I just understand the logic behind the desktop v mobile decisions
I just understand the logic behind the desktop v mobile decisions
@brianteeman You understand what in detail? Or is a typo and a "don't" is missing?
the dont is missing - oops
Looking forward to testing this further this week. @richard67 can you tag the PR also with Documentation Required, as I'm keen to resolve a 2 year old forum question by comprehensively documenting Cassiopeia.
| Labels |
Added:
?
|
||
I almost forgot: The issue with styling of the back to top link which @brianteeman has found is not resolved yet. See his comments a bit above.
@drmenzelit or @hans2103 Could you have a look on it? I agree with Brian that it would be better visible if it had a permanent border, not only when hovering.
And z-index should be fixed so it is higher than the one of the password field's icon.
back-to-top issues as mentioned in both comments by @brianteeman have been solved in PR joomla/cassiopeia#259
back-to-top issues as mentioned in both comments by @brianteeman have been solved in PR joomla/cassiopeia#259
I'll apply that to this PR here later today.
- Testing requirement: installation of Joomla! 4 beta-6 with integrated PR
I tried minus and below minus in follow positions: top-a Main-top, Menu and sidebar-right.
The keyboard navigation (TAB, shift-TAB) does not cause problems.
The CSS menu-horizontal parameter does not work I always have the vertical menu.
E.g. nominal position top-a
Configuration Back-end
Do I need to make other configurations for the horizontal menu?
The menu is horizontal only in the nominal menu position
PR noce, takes time for the test... :)
The issues with the back-to-top link reported above by @brianteeman have been solved with the last commit. Thanks Brian for reporting, and thanks @hans2103 for the fix.
I have added some new top level items to the Main Menu Blog: an item type of separator that doesn't have any children and another that does. I have spotted two issues in the Menu position:
- Some of the items wrap text; others don't
- When viewed on a screen size just before it switches to the menu icon, the last menu item is half hidden.
In the 'Banner' position, there are more issues:
- The button
.metismenu.mod-menu .mm-togglerhas a class ofcolor: currentColor;which appears to be white, which in the banner position, renders it invisible. - For a separator item with no children allocated (
class="mod-menu__separator separator") there is no color at all. In fact, if there are no children, this item type - on the top level - should not be displayed at all.
In the breadcrumbs position with both left and right sidebars:
And without a sidebar-left:
@richard67 OK in local position Menu work.
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/31520.
The issues with the back-to-top link reported above by @brianteeman have been solved with the last commit. Thanks Brian for reporting, and thanks @hans2103 for the fix.
confirmed - thanks
Why does the sidebar-left position drop down to the very bottom of the screen to just above the footer in mobile view? I would expect it to sit above the top-a position or at least just above the 'main' section.
@brianteeman With the last commit we have corrected the inconsistent usage of numbers and literals for font weights, but we haven't changed yet what you had mentioned for the one font scheme where headings are not bold. I'm still collecting opinions on that. Would it be helpful in your opinion to add something about font weights to the names (language strings) of the fonts schemes shown fonts schemes select so that it's more clear?
I will stick with my view that the font weights should be the same across the font selections
I will stick with my view that the font weights should be the same across the font selections
@brianteeman You mean remove the possibility to have different font weights for different fonts schemes? Or you just mean to make the default (i.e. the schemes coming with Cassiopeia) consistent but leave the freedom to change that in a copy of the template?
I have tested this item
My notes:
Explore what is available in the Main Menu Blog dropdown menu in the header area.
OK. Tag links all lead to Home page. Too cramped on 768px wide screen. OK on Mobile.
Check the different types of layouts. Change layout parameters in backend and check again.
Where to look? Same as: Play with template style options in backend, not only those added by this PR, and check the result in frontend.
Alternative theme turns header background maroon.
Primary and Danger buttons are almost identical in colour
Layout Static / Fluid OK
Sticky Header No / Yes OK but eats too much screen because search wraps
Back to Top link No / Yes OK
Fonts local:
<link href="/j4cass/templates/cassiopeia/css/global/fonts-local_roboto.min.css?ea3c55649788d06b3eaabdda5005f2d1" rel="stylesheet" />
Fonts Fira Sans (web)
<link href="/j4cass/templates/cassiopeia/css/global/fonts-web_fira-sans.min.css?ea3c55649788d06b3eaabdda5005f2d1" rel="stylesheet" />
Roboto + Noto Sans (web)
<link href="/j4cass/templates/cassiopeia/css/global/fonts-web_roboto+noto-sans.min.css?ea3c55649788d06b3eaabdda5005f2d1" rel="stylesheet" />
Logo
Powered by Joomla OK
Title (alternative to logo) OK but Too small / too light - even when capitalised.
Tagline OK (good)
Menu Assignment - not tested
Test both without being logged in to the frontend and also as logged user with edit permissions.
Seems OK
Test everything also RTL by editing language/en-GB/langmetadata.xml and changing <rtl>0</rtl> to <rtl>1</rtl>.
Seems OK - strange to see everything right aligned.
Login Form: ',Hi Cliff' - omit comma?
Check also the error and the offline page.
Offline: OK but if logged in as admin in front end front-end remains on-line. I have always assumed that admin could only login to back end.
Not found: OK
Error: OK - Mobile OK
Main menu: Help (en-GB) is separate link from adjacent open/close marker. Sample Layouts (en-GB) is combined with adjacent open/close marker. I prefer the latter.
```<hr /><sub>This comment was created with the <a href="https://github.com/joomla/jissues">J!Tracker Application</a> at <a href="https://issues.joomla.org/tracker/joomla-cms/31520">issues.joomla.org/tracker/joomla-cms/31520</a>.</sub>
I have tested this item
My notes:
Explore what is available in the Main Menu Blog dropdown menu in the header area.
OK. Tag links all lead to Home page. Too cramped on 768px wide screen. OK on Mobile.
Check the different types of layouts. Change layout parameters in backend and check again.
Where to look? Same as: Play with template style options in backend, not only those added by this PR, and check the result in frontend.
Alternative theme turns header background maroon.
Primary and Danger buttons are almost identical in colour
Layout Static / Fluid OK
Sticky Header No / Yes OK but eats too much screen because search wraps
Back to Top link No / Yes OK
Fonts local:
<link href="/j4cass/templates/cassiopeia/css/global/fonts-local_roboto.min.css?ea3c55649788d06b3eaabdda5005f2d1" rel="stylesheet" />
Fonts Fira Sans (web)
<link href="/j4cass/templates/cassiopeia/css/global/fonts-web_fira-sans.min.css?ea3c55649788d06b3eaabdda5005f2d1" rel="stylesheet" />
Roboto + Noto Sans (web)
<link href="/j4cass/templates/cassiopeia/css/global/fonts-web_roboto+noto-sans.min.css?ea3c55649788d06b3eaabdda5005f2d1" rel="stylesheet" />
Logo
Powered by Joomla OK
Title (alternative to logo) OK but Too small / too light - even when capitalised.
Tagline OK (good)
Menu Assignment - not tested
Test both without being logged in to the frontend and also as logged user with edit permissions.
Seems OK
Test everything also RTL by editing language/en-GB/langmetadata.xml and changing <rtl>0</rtl> to <rtl>1</rtl>.
Seems OK - strange to see everything right aligned.
Login Form: ',Hi Cliff' - omit comma?
Check also the error and the offline page.
Offline: OK but if logged in as admin in front end front-end remains on-line. I have always assumed that admin could only login to back end.
Not found: OK
Error: OK - Mobile OK
Main menu: Help (en-GB) is separate link from adjacent open/close marker. Sample Layouts (en-GB) is combined with adjacent open/close marker. I prefer the latter.
```<hr /><sub>This comment was created with the <a href="https://github.com/joomla/jissues">J!Tracker Application</a> at <a href="https://issues.joomla.org/tracker/joomla-cms/31520">issues.joomla.org/tracker/joomla-cms/31520</a>.</sub>
Why does the sidebar-left position drop down to the very bottom of the screen to just above the footer in mobile view? I would expect it to sit above the top-a position or at least just above the 'main' section.
That is the way the grid of Cassiopeia was conceived (not our concept, it was like this before this PR). How should one decide if the sidebar-left is more important than the sidebar-right? And what about rtl languages?
And main content is always more important than sidebars
Why does the sidebar-left position drop down to the very bottom of the screen to just above the footer in mobile view? I would expect it to sit above the top-a position or at least just above the 'main' section.
That is the way the grid of Cassiopeia was conceived (not our concept, it was like this before this PR). How should one decide if the sidebar-left is more important than the sidebar-right? And what about rtl languages?
I would have thought it would be simple enough to adjust for rtl languages. Does this mean that in rtl setup the right sidebar drops to the bottom? I'm not sure how to test this. I thought there might be an option in Template Styles, but there isn't.
@Scrabble96 in the explanation of the PR under "Basic tests" we describe how to change to rtl
I will stick with my view that the font weights should be the same across the font selections
@brianteeman You mean remove the possibility to have different font weights for different fonts schemes? Or you just mean to make the default (i.e. the schemes coming with Cassiopeia) consistent but leave the freedom to change that in a copy of the template?
@brianteeman I think it is important to show all possibilities we have with the different font schemes. It is not only changing the font family, but also setting different styles for text and headings. It can be overwritten on a user.css file or it can be modified on a copy of the template.
Such things are always matter of taste.
The togglers in vertical menus for separator and menu heading types - which are defined in the buttons' ::after CSS - need adjusting they are not in the same alignment as menu item types that are active links with children. The latter have an <a> tag followed by a button. The separators and menu heading types are only buttons. They need some extra code along the lines of:
button.mod-menu__heading.nav-header.mm-collapsed.mm-toggler.mm-toggler-nolink::after,
button.mod-menu__separator.separator.mm-collapsed.mm-toggler.mm-toggler-nolink::after {
position: relative;
top: 2px;
}
As well as color adjustment.
See before additional code:
And after:
I think it is important to show all possibilities we have with the different font schemes.
Without reading the code or reading your mind the user will just see it and report it as a bug. Exactly as I did
I think it is important to show all possibilities we have with the different font schemes.
Without reading the code or reading your mind the user will just see it and report it as a bug. Exactly as I did
@brianteeman That's why I've asked if adding the weights to the names would be helpful. This time with a screenshot:
@Scrabble96 in the explanation of the PR under "Basic tests" we describe how to change to rtl
Sorry, I missed that. I've changed it now. BUT...
The physical position of sidebar-left is now on the right and vice versa. However, the sidebar names are unchanged.
I would find it very confusing if I allocated a module to sidebar-right and found it displayed on the left.
@Scrabble96 in the explanation of the PR under "Basic tests" we describe how to change to rtl
Sorry, I missed that. I've changed it now. BUT...
The physical position of sidebar-left is now on the right and vice versa. However, the sidebar names are unchanged.
I would find it very confusing if I allocated a module to sidebar-right and found it displayed on the left.
Feel free to open a new issue for that. It's not related to this PR here but a general core behaviour, also in J3.
The physical position of sidebar-left is now on the right and vice versa. However, the sidebar names are unchanged.
I would find it very confusing if I allocated a module to sidebar-right and found it displayed on the left.Feel free to open a new issue for that. It's not related to this PR here but a general core behaviour, also in J3.
Thank you, @richard67, I will.
The togglers in vertical menus for separator and menu heading types - which are defined in the buttons'
::afterCSS - need adjusting they are not in the same alignment as menu item types that are active links with children.
@Scrabble96 Good find. We will fix that.
@Scrabble96 Good find. We will fix that.
Thanks. I hope you also saw all the other menu layout and color issues I pointed out earlier. ;-) (no comments yet).
The togglers in vertical menus for separator and menu heading types - which are defined in the buttons'
::afterCSS - need adjusting they are not in the same alignment as menu item types that are active links with children.
Fixed with the last commit, thanks @hans2103 .
Thanks. I hope you also saw all the other menu layout and color issues I pointed out earlier. ;-) (no comments yet).
@Scrabble96 We will check and fix that, too. Be patient.
@Scrabble96 What did you mean with colours in your comment #31520 (comment)? Did you mean that links have link colour and menu items which are not links have normal text colour? That's by intention. Do you think that's wrong? Or did you mean something else?
Now we have to fix #31520 (comment) .
@Scrabble96 What did you mean with colours in your comment #31520 (comment)? Did you mean that links have link colour and menu items which are not links have normal text colour? That's by intention. Do you think that's wrong? Or did you mean something else?
@richard67 See the screenshots in my comment #31520 (comment)
I think the testing instructions should request that people add top level items that are menu headings and separators because the issues I found relate to those -
1: On slightly narrower screens with several top level menu items, some menu item text wraps i.e. menu headings and separators with children. Other items don't, i.e. active single items with or without children and separators without children.
2: On the banner position some items (menu heading and separator types) disappear because the CSS color code isn't right in this position - they are white text on a white background! Left and right padding also required.
3: Horizontal menu is not suitable for any position between sidebars as it disappears.
You can see it on my test site: https://cassiopeia.websiteprep.co.uk/ created with the full package installation from this PR this morning (which also works as an update package).
@richard67 See the screenshots in my comment #31520 (comment)
Yes, but I was referring to your other comment, where you had found the issue with arrow positions but also had mentioned colours, and there I could not see a colour problem.
The other comment which you referred to in your previous comment we will handle as far as possible, also colours for banner position.
Yes, but I was referring to your other comment, where you had found the issue with arrow positions but also had mentioned colours, and there I could not see a colour problem.
@richard67 Sorry, yes. If black (or dark grey) and blue is intended, then ignore my comment. Personally I would prefer underline/no underline, but that's my opinion.
However, on mobile view - using a mobile, not a mouse on a narrowed desktop screen - when a separator is tapped it becomes underlined. Before it is tapped it is not. Is that intended?
However, on mobile view - using a mobile, not a mouse on a narrowed desktop screen - when a separator is tapped it becomes underlined. Before it is tapped it is not. Is that intended?
Yes. Is that wrong?
However, on mobile view - using a mobile, not a mouse on a narrowed desktop screen - when a separator is tapped it becomes underlined. Before it is tapped it is not. Is that intended?
Yes. Is that wrong?
I'm not sure it serves any purpose (as it happens after the event).
After the fix for the arrow positions we have a problem now with alignment of the dropdown toggles for the different kinds of parent menu items on top level for horizontal menus:
The issue from my previous comment has been fixed with the last commit.
Dropdown toggle icons should be fine and consistent everywhere now.
The styling of the menu in the header has slightly changed, e.g. underlines are a bit closer to the text now. I will sooner or later update screenshots in the description.
@Scrabble96 wrote:
I have added some new top level items to the Main Menu Blog: an item type of separator that doesn't have any children and another that does. I have spotted two issues in the Menu position:1. Some of the items wrap text; others don't 2. When viewed on a screen size just before it switches to the menu icon, the last menu item is half hidden.
In the 'Banner' position, there are more issues:
1. The button `.metismenu.mod-menu .mm-toggler` has a class of `color: currentColor;` which appears to be white, which in the banner position, renders it invisible. 2. For a separator item with no children allocated (`class="mod-menu__separator separator"`) there is no color at all. In fact, if there are no children, this item type - on the top level - should not be displayed at all.
In the breadcrumbs position with both left and right sidebars:
And without a sidebar-left:
These still need to be solved.
@Scrabble96 wrote:
I have added some new top level items to the Main Menu Blog: an item type of separator that doesn't have any children and another that does. I have spotted two issues in the Menu position:1. Some of the items wrap text; others don't 2. When viewed on a screen size just before it switches to the menu icon, the last menu item is half hidden.
@Scrabble96
What is the expected behaviour when the menu consumes more space then provided?
In the 'Banner' position, there are more issues:
- The button
.metismenu.mod-menu .mm-togglerhas a class ofcolor: currentColor;which appears to be white, which in the banner position, renders it invisible.
This has been solved with the last commit.
- For a separator item with no children allocated (
class="mod-menu__separator separator") there is no color at all. In fact, if there are no children, this item type - on the top level - should not be displayed at all.
The colour issue has been fixed with the last commit.
Not showing the separator if there are no children doesn't make sense. You should unpublish or remove that menu item instead, if you don't want to see it as a separator. The default menu layout also shows it regardless of children or no children.
Not showing the separator if there are no children doesn't make sense. You should unpublish or remove that menu item instead, if you don't want to see it as a separator. The default menu layout also shows it regardless of children or no children.
OK. In my own menu design, I have created a new type which adds class="separator-line" in the main php file with this code:
if (($item->level > 1 &! $item->parent) && $item->type == 'separator')
{
$class .= ' separator-line';
}
which means that in lower levels it can be styled independently to not display the span but to show a line instead. Its class would be class="metismenu-item item-n level-n divider separator-line" By having its own class that means that other items with class divider parent wouldn't need CSS to counter-act the class added to 'divider' if 'separator-line' doesn't exist.
Example:
Useful if you want to break up a long menu.
@Scrabble96 Regarding the separator I understand now. I will see what we can do for it.
The collapsing to "More" thing .. do I guess right that it works with JS?
@Scrabble96 Regarding the separator I understand now. I will see what we can do for it.
The collapsing to "More" thing .. do I guess right that it works with JS?
@richard67 I do hope so! But my knowledge of minified jQuery and JavaScript files is so basic that I'm not sure I can tell the difference. If you go to https://www.bbc.co.uk and inspect the 'More' tab in the menu and click the 'event' bit, you can see a link to the code which starts like this:
(window.coreWebpackJsonp=window.coreWebpackJsonp||[]).push([[4],[function(e,t,n){"use strict";e.exports=n(249)},function(e,t,n){"use strict";var r=n(61),o=n.n(r),i=n(0),a=n(62),u=/^((children|dangerouslySetInnerHTML|key|ref|autoFocus|defaultValue|defaultChecked|innerHTML|suppressContentEditableWarning|suppressHydrationWarning|valueLink|accept|acceptCharset|accessKey|action|allow|allowUserMedia|allowPaymentRequest|allowFullScreen|allowTransparency|alt|async|autoComplete|autoPlay|capture|cellPadding|cellSpacing|challenge|charSet|checked|cite|classID|className|cols|colSpan|content|content
Hmm, thinking about the separator, not everybody wants to have a line. And what we have now is the same as described in the J3 docs: https://docs.joomla.org/Help39:Menus_Menu_Item_Text_Separator.
Regarding not showing the title, it say to use a space, and styling can be done e.g. with a user.css, so maybe it will be a "won't fix" here. But we will discuss that in the team.
Hmm, thinking about the separator, not everybody wants to have a line. And what we have now is the same as described in the J3 docs: https://docs.joomla.org/Help39:Menus_Menu_Item_Text_Separator.
Regarding not showing the title, it say to use a space, and styling can be done e.g. with a user.css, so maybe it will be a "won't fix" here. But we will discuss that in the team.
It doesn't have to be a line or not show the text, but adding a new class (perhaps 'separator-no-child' instead of 'separator-line') would allow for independent styling without affecting any other items.
We are working on a nice solution for separators being a line, horizontal or vertical depending on the menu's orientation, for separators which are not used as parent menu items, Stay tuned. And it doesn't need new CSS classes, we already have all classes we need.
@Scrabble96 We have separator lines now when a separator item is not a parent.
Now only the overflow / word wrap issues are remaining.
@drmenzelit Thanks a lot for the separator fixes in the last commit.
Link to package in testing instructions will be updated as soon as the new package is ready.
Done.
| Status | Pending | ⇒ | Fixed in Code Base |
| Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2020-12-01 21:23:19 |
| Closed_By | ⇒ | wilsonge |
@HLeithner has just told me he's tested this. I know for sure it's a step in the right direction. So merging this so that we have some incremental improvement and it starts being distributed in the nightlies
Thank you very much!
Now I need a holiday.
installing latest 4.0-dev.... got this one
Can't reproduce on a clean 4.0-dev branch.
Can it be you have old files on your branch?
Maybe a git clean -d -x -f and git checkout . and the run npm again will help?
it's already a clean install
@alikon If you are working on the 4.0-dev branch of your fork, the following command sequence on your local git client's command line will reset the 4.0-dev branch of your fork (locally and remote) to the 4.0-dev branch of the CMS:
git checkout 4.0-dev
git remote update
git clean -d -x -f
git reset --hard upstream/4.0-dev
git push origin +4.0-dev
(assuming that the remote for your fork is called "origin" and the remote for the CMS repo is called "upstream")
I have no issues either running an install
Hello everyone, I am currently testing this version in beta 6 with the new cassiopeia. I notice that the images that I resize in 16: 9 keep this proportion in the intro of the article, but that they are distorted in full article. I think it's a template issue. Can you check please?
Thank you all for this fantastic work. You guys rock! The improvements are looking very good.