@C-Lodder can you take a look at this one?

This will conflict with #11779

Brian Teeman
Co-founder Joomla! and OpenSourceMatters Inc.
http://brian.teeman.net/

I was going to say, could you firstly apply Brian's patch please?

Either way, will start looking through this now ;)

@brianteeman it won't as it uses an override for chosen.css that utilises icomoon font instead of the png for the icons.

Sorry - didnt spot the different path - but that will mean that you are not
using the correct version of the chosen.css wont it?

On 25 August 2016 at 15:08, Dimitri Grammatikogianni <
notifications@github.com> wrote:

@brianteeman https://github.com/brianteeman it won't as it uses an
override for chosen.css that utilises icomoon font instead of the png for
the icons.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#11789 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABPH8fdAoDNv8me1UdnbqG15fy23uBz6ks5qjaHAgaJpZM4JtF-G
.

Brian Teeman
Co-founder Joomla! and OpenSourceMatters Inc.
http://brian.teeman.net/

@dgt41 - Can you ping me a message on Facebook or Skype (charlie.lodder)?

@brianteeman it seems that the css works fine, but honestly I didn't do a diff to your PR to see what else might be changed. Will do that
@C-Lodder sure

I am NOT in favour of the changes to remove the button backgrounds as seen on the toolbar and the options.

@dgt41 you've gone offline

@brianteeman I will agree, let me check the css
@C-Lodder that's just an indication ?

@brianteeman changed it:

But you havent changed the buttons on the toolbar :p

This also affects buttons used in components like patchtester which also lose their backgrounds

Its like a repaint but you forgot to put any paint on the brush

Getting there.
I notice on the toolbar buttons which have a colour when you hover and the background goes grey then the icon and the text goes white which is correct

But in some places that doesnt happen eg in the menu item for a single article the select button icon stays green

Just a thought
Instead of replacing the current isis why dont we make this a new admin template called something like isis-flat

This one could be the default but it will reduce the "why did you change things" comments if the current one is still available

@brianteeman - cause it's only the buttons that are being changed. Not really much point in creating another instance of Isis just for this.

@c-lodder I will remind you of that

I know only one person against flat: @wilsonge

He has absolutely no sense of style. If it were up to him, both Isis and Protostar would be fully orange :D

Quoting colour psychology about orange:

In relation to the meaning of colors, orange is extroverted and uninhibited, often encouraging exhibitionism or, at the very least, showing-off!

If it were up to him, both Isis and Protostar would be fully orange

That could be the base of the 4.0 admin template. 1.0, 1.5, and 1.6+ have used the other logo colors as their bases or accents.

I'll be checking myself into the insane asylum now.

Good idea Michael

The asylum or the colour?

@dgt41 @brianteeman The menu item single article icon you mentioned isn't changing colour because of (template.css - line 6916)

.icon-edit::before {
    color: #378137;
}

@wilsonge @mbabker

Just because my IT degree is with a concentration in web design does not mean I am qualified by any measure to make design related decisions.

I have tested this item ✅ successfully on 9a7f543

Next tweak - looks to me like the line between is doubled? seen the same elsewhere

@brianteeman - re-apply the patch and clear your cache. This has already been fixed:

.btn-group > .btn + .btn {
    margin-left: -1px;
}

This CSS targets all buttons after the first one, inside .btn-group and pushes them back by 1px

Round or square corners??

It seems you cant decide and on this screenshot we get all variations on a single page

@C-Lodder the button groups have been fixed now - I wrote it when it wasnt but for some reason forgot to post it

@brianteeman good catch! fixed

EDIT: the modified by field is wrongly classified with input-apend, so the html part is wrong, but let's not fix it here as with the new calendar this is already fixed

Almost - you still need to fix the modified by

.input-append input,
.input-append select,
.input-append .uneditable-input {
-webkit-border-radius: 3px 0 0 3px;
-moz-border-radius: 3px 0 0 3px;
border-radius: 3px 0 0 3px;
}

This should be border-radius: 3px;

actually it probably isnt that easy - as that would effect other stuff so maybe its just that field has the wrong class?

@brianteeman read my previous comment (the edit part). removing the input-append from the class fixes the input round corners. It's not css, it's wrong html

I missed the edit ;)

So the only other thing that looks a little odd to me but dont know if its either just me or even fixable is that when you select an item in a list it goes blue and it stays blue until you do something elsewhere

That's the correct functionality, when you are in a dropdown the focus is on that element, then you select something the dropdown closes but the focus is still on that element. As you said you have to click elsewhere in the page to initiate a blur (loose focus). The only thing that makes this more obvious now is that the dropdown is well visible that is in focus (blue border) which is different from the default chosen css (grey), but IMHO this is more accessible. I can revert the colouring back to grey, but I think this is an improvement

As i said - i thought this one was just me thinking it was odd

On 25 August 2016 at 18:50, Dimitri Grammatikogianni <
notifications@github.com> wrote:

That's the correct functionality, when you are in a dropdown the focus is
on that element, then you select something the dropdown closes but the
focus is still on that element. As you said you have to click elsewhere in
the page to initiate a blur (loose focus). The only thing that makes this
more obvious now is that the dropdown is well visible that is in focus
(blue border) which is different from the default chosen css (grey), but
IMHO this is more accessible. I can revert the colouring back to grey, but
I think this is an improvement

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#11789 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABPH8S1HDggxSHsurBgEiLMI60mAo8Zgks5qjdXUgaJpZM4JtF-G
.

Brian Teeman
Co-founder Joomla! and OpenSourceMatters Inc.
http://brian.teeman.net/

@dgt41 not spotted anything else - will keep it as my default for a while and see if I spot anything else

Search Tools

See how the icon disappears when the search tools is open but does not have focus

The double border issue still exists here in the Single Article menu item options

'Close' in tags is slightly out of line. Personally I would be inclined to display such icons inline rather than with absolute positioning. The line-height will center the icon for you rather than the constant tweaking that comes with absolute positioning. Also less CSS.

.chzn-container-multi .chzn-choices .search-choice {
    background-clip: padding-box;
    background-color: #0088cc;
    border-radius: 3px;
    color: #fff;
    cursor: default;
    line-height: 22px;
    margin: 3px 0 3px 5px;
    padding: 0 7px;
}
.chzn-container-multi .chzn-choices .search-choice .search-choice-close {
    color: #f5f5f5;
    display: inline-block;
    margin-left: 5px;
}

Oops sorry I pressed close and comment instead of just comment. Sorry!!!!

@ciar4n thanks!
@brianteeman all fixed now

Cool I will keep testing tomorrow. I am still concerned though about
chosen.css

I know I'm splitting hairs here but a subtle border on colored buttons will help make the buttons more unified. Colored next to bordered buttons tend to look a pixel smaller at first glance. A slight border will rectify this?

.btn-primary {
    background-color: #2384d3;
    border: 1px solid #1c6aa9;
    border: 1px solid rgba(0, 0, 0, 0.25);
    color: #fff;
}
.btn-success {
    background-color: #46a546;
    border: 1px solid #388438;
    border: 1px solid rgba(0, 0, 0, 0.25);
    color: #fff;
}
.btn-danger {
    background-color: #bd362f;
    border: 1px solid #972b26;
    border: 1px solid rgba(0, 0, 0, 0.25);
    color: #fff;
}

.btn:hover, .btn:focus {
    background-color: #808080;
    border: 1px solid #972b26;
    border: 1px solid rgba(0, 0, 0, 0.1);
    color: #fff;
    text-decoration: none;
    text-shadow: none;
}

RGBA colors will translate to :hover. HEX for non RGBA browsers.

Just a question... is this an expected behaviour?
I'm talking about the "grey" pressed button.

@jeckodevelopment That is just an example of a hovered item. Sorry I should have stated.

@ciar4n thank you for the explanation :)

I'm not a huge fan of this for one reason:

Currently Isis is to a big degree plain Bootstrap, same as Protostar. There are some adjustments in the template.less but that is it.

You are now going to override quite a few files from Bootstrap (and Chosen), making it non-standard.
Since you override the whole file, it's hard to find out how much you changed from the original Bootstrap file. It could be one line or the whole thing.

In the end it means that issues with the original files (be it Bootstrap or Chosen) may go undetected or are hard to test and fix because our default template uses different files.

You are now going to override quite a few files from Bootstrap (and Chosen), making it non-standard.

So? By that argument every Bootstrap template should basically look like the starter template. The whole point of using a CSS framework is to give you the toolset you need to create a nice template, not retain its default styling to a damaging extent.

Yeah, that's obvious.

I just don't think the default one we ship should override a lot of it. Same as for HTML and JS overrides in our default templates (Protostar and Isis). So far they both use only a few overrides or none. But with this PR that would change.

And again, so?

We should be moving to more agnostic default layouts with the framework
stuff in template specific overrides. So I'm less concerned on that aspect.

For JavaScript libraries we should avoid hacking them but there shouldn't
be a rule against extending them for our use cases.

And for CSS, we don't need to be validating the default rules of whatever
we're using. So I'm not concerned with how much (or little) of the core
Bootstrap (or Chosen or whatever else) CSS we use as long as it's all
functional and user friendly.

On Friday, August 26, 2016, Thomas Hunziker notifications@github.com
wrote:

Yeah, that's obvious.

I just don't think the default one we ship should override a lot of it.
Same as for HTML and JS overrides in our default templates (Protostar and
Isis). So far they both use only a few overrides or none. But with this PR
that would change.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#11789 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAWfoafoac7HLqhl3Vl8U8xxxvC0RcDqks5qju_BgaJpZM4JtF-G
.

On the PR... maybe a more uniformed look across all fields. Matching border-radius (3px), border-color (#aaa) and field height (28px). Also the removal of shadows (outset and inset).

Suggested on the right...

*Blue field is :focus

I am closing this in favour of #11832