Going Chameleon about semantic-mediawiki.org

[kghbln]

I just made the disaster transparent at https://github.com/SemanticMediaWiki/Stragula

[kghbln]

Done. This took longer and was a bit more painful for me than expected. Still learned something and I guess it looks cool now.

[kghbln]

So I worked on the skin today. I focused on the footer which took quite some effort but this one is cool now. This is the Main Page The top navigation bar including dropdowns has to be fluffed as well as the Main Page. However right after that was done I would like to switch to Chameleon and remove Vector. Fine tuning can be done thereafter in case there is some general area which needs to be worked on first. I am thinking of removing the logo until a new version is in place. All the stuff on "Chameleon.css" will eventually go into the "smwo.less" file.

• smwofixedhead.xml
• smwo.less
• LocalSettings.php
• Sidebar

@s7eph4n @mwjames @JeroenDeDauw FYI and ggf. comments.

[s7eph4n]

That's a problem with the gallery format. It uses z-index to manage which slide is visible, but it does not create a proper stacking context.

(Although Chameleon should probably additionally create a stacking context on the main content area of the page as a fallback for misbehaving content.)

See https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Positioning/Understanding_z_index/The_stacking_context

[s7eph4n]

There is a respective issue upstream: Leaflet/Leaflet#3690, but it has been open since > 2 years now, with the last comment more than a year old.
Anyway, Chameleon@dev-master contains the fallback now, so should fix this.

[JeroenDeDauw]

Such fancies

[kghbln]

Now after fiddling with the look and feel of this dropdown menu for many hours I realize that we have a z-index issue like here. Have not figured out which class must be changed to get it dominate. My thought was that is should be the "dropdown-content" class but adding some z-index to it does not change a thing.

This is a show stopper: This three column drop-down menu does not play at all for narrow clients, like smart phones. I am afraid that we will have to revert back to the side menu we had before unless somebody comes up with a striking idea.

[kghbln]

Have not figured out which class must be changed to get it dominate. My thought was that is should be the "dropdown-content" class but adding some z-index to it does not change a thing.

Now I tried it the other way around, trying to reduce the z-index of the footer and all the stuff down there. It helps to some extend, however "ul.nav.navbar-nav.small" and variants are gone for good this way. Running out of ideas right now.

This is a show stopper: This three column drop-down menu does not play at all for narrow clients, like smart phones. I am afraid that we will have to revert back to the side menu we had before unless somebody comes up with a striking idea.

Setting column-width does not work here since the columns are no embedded in something wider. I tried to set a min-width for the manual but this does not help either. Running out of ideas right now.

[JeroenDeDauw]

karsten-hoffmeyer.info? Not loading

What is with the suggestions bit? If we use the skin, do we need to modify it somehow?

[kghbln]

karsten-hoffmeyer.info? Not loading

That's something else being obfuscated. Glad to see that it works. The website is karsten.hoffmeyer.info

What is with the suggestions bit? If we use the skin, do we need to modify it somehow?

Indeed Chameleon is like an unpainted house out of the box - nothing one would like to see. The link gives a first glimpse of the direction.

[kghbln]

So I trained working with Chameleon this week. Next up is smw.o

Kingsdocs is really cool but only Bootstrap 4. So I looked at Bootswatch for an alternative template. My preferences in order of appearance.

1. https://bootswatch.com/3/cosmo/ - probably also closes to class "smworgtable-v2" - start
2. https://bootswatch.com/3/flatly/
3. https://bootswatch.com/3/sandstone/

[kghbln]

A nice website I found on the way: https://www.bootply.com/

[mwjames]

If you want show the languages as dropdown on top, you add:

<component type="NavMenu" flatten="navigation" showTools="no" showLanguages="yes"></component>

and disable it add the bottom with:

<component type="ToolbarHorizontal" hideTools="no" hideLanguages="yes"></component>

[kghbln]

I had the languages in before at the top but decided we should probably not have this a an addition the the embedded language buttons we e.g. use on the manual pages. I like these embedded ones better.

[kghbln]

Issue: Slideshow dominator. Probably something to fiddle with z-index.

[mwjames]

(Although Chameleon should probably additionally create a stacking context on the main content area of the page as a fallback for misbehaving content.)

Maps [0] failing as well. [0] https://www.semantic-mediawiki.org/w/index.php?title=Demo:Berlin&useskin=chameleon

…

On 12/11/17, Stephan Gambke ***@***.***> wrote: That's a problem with the gallery format. It uses `z-index` to manage which slide is visible, but it does not create a proper stacking context. (Although Chameleon should probably additionally create a stacking context on the main content area of the page as a fallback for misbehaving content.) See https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Positioning/Understanding_z_index/The_stacking_context -- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: #37 (comment)

[kghbln]

So I was right about "z-index" giving pain. Thanks a lot for the code tweaks. Works perfect on swm.o!

[kghbln]

Given that nobody had substantial comments on the general look and feel I will continue on the path I am currently taking to fluff the skin.

Forgot to note that I increased both the base font size as well as the base line hight to improve readability of the content.

[mwjames]

Some quick comments: - The [0] embedded table looks odd (or better wide). - The search field looks enormously large. - For the breadcrumbs (`egSBLBreadcrumbTrailStyleClass`) you might choose `sbl-breadcrumb-bootstrap` instead. As for the sidebar (or then navbar): - Introduction - Manuals - User manual - Administrator manual - Developer manual - Community - Portal - Report a bug -- sep -- - Sandbox - Links ... @s7eph4n Can those generated sidebar dropdowns contain separators (like the standard boostrap dropdown)? [0] https://www.semantic-mediawiki.org/w/index.php?title=Help:In-text_annotation&useskin=chameleon

…

On 12/12/17, Karsten Hoffmeyer ***@***.***> wrote: Given that nobody had substantial comments on the general look and feel I will continue on the path I am currently taking to fluff the skin. Forgot to not that I increased both the base font size as well as the base line hight to improve readability of the content. -- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: #37 (comment)

[mwjames]

Might try the following CSS to reduce the white space between h1 and content. ``` .contentHeader { margin: 0 0 0.5em; border-bottom: 0; padding-bottom: 0; ```

…

On 12/12/17, James HK ***@***.***> wrote: Some quick comments: - The [0] embedded table looks odd (or better wide). - The search field looks enormously large. - For the breadcrumbs (`egSBLBreadcrumbTrailStyleClass`) you might choose `sbl-breadcrumb-bootstrap` instead. As for the sidebar (or then navbar): - Introduction - Manuals - User manual - Administrator manual - Developer manual - Community - Portal - Report a bug -- sep -- - Sandbox - Links ... @s7eph4n Can those generated sidebar dropdowns contain separators (like the standard boostrap dropdown)? [0] https://www.semantic-mediawiki.org/w/index.php?title=Help:In-text_annotation&useskin=chameleon On 12/12/17, Karsten Hoffmeyer ***@***.***> wrote: > Given that nobody had substantial comments on the general look and feel I > will continue on the path I am currently taking to fluff the skin. > > Forgot to not that I increased both the base font size as well as the > base > line hight to improve readability of the content. > > -- > You are receiving this because you were mentioned. > Reply to this email directly or view it on GitHub: > #37 (comment)

[s7eph4n]

Can those generated sidebar dropdowns contain separators (like the standard boostrap dropdown)?

This will probably need a patch. I'll investigate.

[kghbln]

• The [0] embedded table looks odd (or better wide).

This looks to me as if pre has a fixed width. Will look into this.

The search field looks enormously large.

Do you think? Well otherwise you would not have noted. I think this is for tablets and smartphones. It may be that this was streched since I enlarged the font and the line hight. Will have a look however I do not think this is a big issue.

For the breadcrumbs (egSBLBreadcrumbTrailStyleClass) you might choose sbl-breadcrumb-bootstrap instead

Will try.

As for the sidebar (or then navbar):

That's similar to what we already have. I propose this one which dupes items but is more and specifically catered for the diffrent user groups we have:

• Sidebar

Might try the following CSS to reduce the white space between h1 and content.

Yeah, this was however not fluffed yet. The right and left margins of the content area are much to wide too.

[kghbln]

The [0] embedded table looks odd (or better wide).

This looks to me as if pre has a fixed width. Will look into this.

I have no idea what is going on. As soon as we put a pre into a table it takes the full width of the container class and does not automatically overflow. pre does not have a defined fixed width so this is pretty weird. So I switch to smwpre class to overcome the issue. This one does not overflow automatically either however it does not go into the full lenght. Perhaps I have overlooked something. In the end this is not a show stopper for me but something that I have to look into again.

[kghbln]

@s7eph4n One question: What I have not figured out yet is how to get to the page if I am looking at a version diff. Probably we also need a link in the actions menu for this. This issue may also be specific to fixedhead.

[s7eph4n]

Good question. Off the cuff I'd have said same as from Edit pages, but it does not work like that. It would probably make sense to add a dedicated button to the page tools (also for Edit pages). E.g. like this:

[kghbln]

Off the cuff I'd have said same as from Edit pages, but it does not work like that.

True, however then editing a page we also get a link in the action menu which brings you back to the page. This appears to be the equivalent to the read tab in Vector.

It would probably make sense to add a dedicated button to the page tools (also for Edit pages)

Sounds like a reasonable idea to me. Indeed, as soon as action edit is triggered the button should change to this dedicated return button.

[mwjames]

I could imagine that the dropdown design needs a nudge.

background-color: #3e85b5;

background-color: #2780e3;

[mwjames]

The content alignment seems a bit odd.

[mwjames]

Some ul/li misalignment.

[kghbln]

Might try the following CSS to reduce the white space between h1 and content.

Done. Looks indeed much better now.

[kghbln]

The content alignment seems a bit odd.

I have reduced the number of outer cells from 2 to 1. Since I worked on the skin on a wide screen I guess that the wide scree will look a bit different now, i.e. the content will be more narrow than the footer. In the end narrow screens should get precedence since this is what we are trying to do here anyways.

[kghbln]

I could imagine that the dropdown design needs a nudge.

Trying to do this with the less variables seems impossible. So far I have not figured out the naming scheme used. Thus I end up defining CSS for something which perhaps has a variable.

The dropdown menu is now changed for the regular navbar. This should now be ok:

.dropdown-menu > li > a:hover,
.dropdown-menu > li > a:focus {
	background-color: #fff;
        color: #5e9dc8;
        text-decoration: underline;
}

Of course the dropdown for the user menu follows different rules. Moreover the integration of Echo is going to be a disaster.

[kghbln]

Some ul/li misalignment.

Wow, changing

.dropdown-content a {
        padding: 3px 6px;
}

to

.dropdown-content a {
        padding: 3px 3px;
}

causes the ul bullets to vanish. This is quite unexpected. At least to me. Moreover changes to this class are being ignored in the third and lower level. Wtf.

[kghbln]

I further increased the size of the font, however decreased it for h1 to 3:

$egChameleonExternalLessVariables [
        'font-size-base' => '18px',
        'font-size-large' => '20px',
        'font-size-small' => '16px',
        'font-size-h1' => '30px',
        'font-size-h2' => '26px',
        'font-size-h3' => '22px',
        'line-height-base' => '1.6667', /* 30 : 18 = */
        ...
        ];

[kghbln]

The dropdown for the personal tools is a complete desaster. I have spent over an hour on this with only marginal progress. I am not going to waste more time on this right now. ULS and Echo are horrific.

[kghbln]

I have changed the search bar to only display the search button, i.e. removed the go button.

[kghbln]

I have redone the default navbar styling as well as the one for the navbar dropdowns. Basically it now follows the dropdown style we use for the language selection on translated pages. Doing color inversion in the background in contrast to underlining on hover has the advantage that echo and uls integration should be easier. Moreover a changed background on hover is even more visible than underlining.

Note: The navbar for mobile devices is still borked and will follow.

Somehow I also had to streamline the shades of blue we are using:

• blue light #dcf0f7
• blue (default) #5e9dc8 - smworgtable-v2
• blue medium (hover and border) #458ec0
• blue dark (focus) #3e85b5
• blue very dark #0c2c52 - smworgtable-v2 (unused right now - probably to be abandoned)

There are many other blueish colors all over the wiki which will have to be adapted.

[kghbln]

I have now completed the work on the the top navbar for narrow and wide screens including the navbar dropdowns with the exception of echo. So far I cannot find glitches. Hopefully you do not either.

Echo and dropdowns within the text area are to follow.

[mwjames]

I know I'm super nitpicky here! The action dropdown has a tiny misalignment.

Maybe should we should lose the round corners as in:

I imagine 16px should be fine as font size to help the reading flow (the current 18px seems a bit large and requires the eyes to strain focus).

I might be wrong but it looks like a ul/li inconsistency appears here.

[kghbln]

I know I'm super nitpicky here! The action dropdown has a tiny misalignment.

Good nitpick. Did not see this but indeed needed to be corrected. --> Done.

I imagine 16px should be fine as font size to help the reading flow (the current 18px seems a bit large and requires the eyes to strain focus).

I personally liked 18px better but doing 16px will not break my heart. --> Done.

Maybe should we should lose the round corners as in:

Good point. --> Should be done.

I might be wrong but it looks like a ul/li inconsistency appears here.

I only worked partially on this. Indeed needs more love.

[kghbln]

Good nitpick. Did not see this but indeed needed to be corrected. --> Done.

Oops. Disaster struck with the "fix". I had to revert it since the same class is applied to the personal tools. So doing a top 40px instead of 39 px is a complete disaster for this instead of keeping this issue.

.skin-chameleon .navbar-tools > li:last-child > ul.dropdown-menu,
.skin-chameleon .navbar-tools li.open:last-child > ul.dropdown-menu {
        top: 40px;
}

@s7eph4n Will it be possible to get two different classes for page tools and personal tools. Unless you have a better idea.

This issue only appears when the page tools share the spot with the edit button.

• ok
• not ok

We will have to differentiate in case page tools shares the spot with the edit button.

[kghbln]

Maybe should we should lose the round corners as in:

Done.

I might be wrong but it looks like a ul/li inconsistency appears here.

I made the hovering on the items consistent here with all other dropdowns, i.e. not text-decoration underline but a different background color. The only shortcoming of this solution is that I cannot enforce a margin on the right of the last column. This does not seem to be possible with CSS. Ideally I would have liked to span the whole width of each hovered item without having any margin but this is not possible either.

[kghbln]

I will change the dropdowns from using a background color to underlining the text. Probably the better idea until CSS is ready for some of the issues.

[kghbln]

I will change the dropdowns from using a background color to underlining the text.

This is done now and indeed creates much less CSS issues.

Now after fiddling with the look and feel of this dropdown menu for many hours I realize that we have a z-index issue like here. Have not figured out which class must be changed to get it dominate. My thought was that is should be the "dropdown-content" class but adding some z-index to it does not change a thing.

I have now made the container have a min-height of 65% so this issue is now avoided.

More notes:

• We should revisit the size of the font. On a wide desktop screen the font appears to be more of a thin line than actually something readable.
• The three column drop down menu within the content area is still a show-stopper.

[kghbln]

Another blocker related to the post before. I have to somehow sanely spread "body-content" to the bottom of the page. Currently that's really bad as the example shows.

[kghbln]

May someone test this on a mobile device, i.e. just access smw.o:

@media only screen and (min-device-width: 768px) {
	.smwofootergrid.container {
		position: fixed;
		bottom: 0;
	}
}

.smwofootergrid.container {
	width: 100%;
}

It appears that @media is also being applied to mobile devices for whatever reason. However I am testing from a desktop screen ...

[kghbln]

No, this does not work either. I have to figure out another way to make the footer sticky at the bottom of the screen.

[mwjames]

Still learned something and I guess it looks cool now.

That's the spirit.

…

On 4/14/18, Karsten Hoffmeyer ***@***.***> wrote: Done. This took longer and was a bit more painful for me than expected. Still learned something and I guess it looks cool now. -- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: #37 (comment)