New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Wrap versions' list to look more consistent #3445

Merged
merged 3 commits into from Jun 6, 2018

Conversation

Projects
None yet
6 participants
@stsewd
Member

stsewd commented Dec 23, 2017

I just noted that the Versions section looks different to the others.

Here is how it looks right now

active-before

no-active-before

And how it will look like after merging

no-active

only-active

@humitos

This comment has been minimized.

Member

humitos commented Dec 23, 2017

Good catch!

I think when there is no active/inactive version we don't want to display it as a table (or unordered list).

So, I'd say that this should be something like:

captura de pantalla_2017-12-22_23-55-42

Similar as it is now but without the borders (probably this means more than CSS --I mean, touching the html layout maybe). What do you think?

@stsewd

This comment has been minimized.

Member

stsewd commented Dec 23, 2017

@humitos I think the same, but that it is how the rest of the sections looks like, should we change the other sections too?

dowloads-empty

@humitos

This comment has been minimized.

Member

humitos commented Dec 23, 2017

Oh, I haven't notice that. I'd say that it's "cleaner" to remove the dark gray when there is nothing to show. Looks nicer without that background IMHO.

@humitos

This comment has been minimized.

Member

humitos commented Feb 15, 2018

@stsewd can you make the changes I mentioned you?

I think that's the only thing missing to wrap this PR in a mergeable state.

@stsewd

This comment has been minimized.

Member

stsewd commented Feb 15, 2018

@humitos should I change the empty state for all the lists then? I think we are moving to other style and layout as mention on #3572 (comment)

Also see #3554

@humitos

This comment has been minimized.

Member

humitos commented Feb 16, 2018

should I change the empty state for all the lists then?

Yes, I'd say so.

I think we are moving to other style and layout as mention on #3572 (comment)

This, and the other issue you linked are going to be bigger changes. I'd prefer to wrap this PR, merge it and achieve those other changes in different PR. I'm sure those will require some discussion to finally agree.

@stsewd

This comment has been minimized.

Member

stsewd commented Feb 16, 2018

@humitos this is how it looks now. I search some other lists, I didn't touch the subproject list, since that is done on #3572

screenshot-2018-2-16 versions read the docs

screenshot-2018-2-16 kong2 read the docs

screenshot-2018-2-16 kong2 read the docs 1

screenshot-2018-2-16 integrations read the docs 1

screenshot-2018-2-16 integrations read the docs

@humitos

I'm approving the PR since it's looks great.

The only thing to consider is my comment about not using list stylish when the list is empty and we are showing a simple message.

Maybe this is a matter of tastes, so another opinion could help here.

</p>
<li class="module-item">
<p class="quiet">
{% trans "No active versions." %}

This comment has been minimized.

@humitos

humitos Feb 19, 2018

Member

Why are we considering this as a list of 1 element if it's empty?

I mean, we are using a li and displaying it as a row when it's not a list. In another comment I suggested to use just the simple text:

"No active versions."

as a p without too much style.

This comment has been minimized.

@stsewd

stsewd Feb 19, 2018

Member

This is a common pattern across other lists (some times with a p and other just with a li)

<li class="module-item quiet">{% trans "No projects found" %}</li>

<li class="module-item quiet">{% trans "No objects found" %}</li>

This comment has been minimized.

@humitos

humitos Feb 19, 2018

Member

Nice reply! Hehe!

Makes sense to leave as you did, then :)

@agjohnson

This comment has been minimized.

Contributor

agjohnson commented Feb 27, 2018

👍 on using a single item list to display "No items". This is the pattern we're using on all other listings as they are reworked.

@agjohnson

This comment has been minimized.

Contributor

agjohnson commented Feb 27, 2018

The changes here are great! For some reason the "Edit" buttons are misaligned now though. The text should align to the middle of the button, it's more towards the top currently. I'd take a look at some of the places we do use this same table layout and have a button inline in the rows for a clue.

@agjohnson

Noting required change on edit button alignment.

@stsewd

This comment has been minimized.

Member

stsewd commented Mar 1, 2018

@agjohnson I see the same on master :/. Probably something about the font that rtd uses on production?

Local

screenshot-2018-3-1 metap read the docs

Org site

screenshot-2018-3-1 bookpy read the docs

Master on local

screenshot-2018-3-1 versions read the docs

This branch on local

screenshot-2018-3-1 versions read the docs 1

On the org site

screenshot-2018-3-1 versions read the docs 2

@humitos

This comment has been minimized.

Member

humitos commented Mar 23, 2018

I have the same problem than @stsewd with the fonts. They look different from .org than from local host.

Although, I think the problem is because the padding is not properly set. It's 4px in the bottom and 6px in the top even in production .org site:

captura de pantalla_2018-03-23_12-27-45

I think it should be 5px in both :)

@stsewd

This comment has been minimized.

Member

stsewd commented Apr 11, 2018

I just rebased this PR, for recap the only thing missing here is the problem with the font: on local development looks different from the production site, so it looks like is not centered. And as @humitos mention #3445 (comment) is not really centered on the production site either.

.module-item .module-item-menu li a { display: block; padding: 6px 10px 4px; margin: 7px 7px 0 0; font-weight: bold; font-size: 14px; height: 20px; line-height: 17px; text-decoration: none; color: #fff; background: #8CA1AF url(../images/gradient-light.png) bottom left repeat-x; border-radius: 3px; -moz-border-radius: 3px; -webkit-border-radius: 3px; text-shadow: 0 1px 1px rgba(0, 0, 0, 0.5); box-shadow: 0 1px 1px #465158; -moz-box-shadow: 0 1px 1px #465158; -webkit-box-shadow: 0 1px 1px #465158; }

The only difference I see from prod/local is that Typekit is loaded on dev, so, I think that takes precedence over fontawesome.

prod

local

@davidfischer

This comment has been minimized.

Contributor

davidfischer commented Apr 11, 2018

I created an issue with respect to fonts in development vs production #3939. Essentially, we are using proprietary fonts (loaded through TypeKit) which are loaded in production only.

@ericholscher

This comment has been minimized.

Member

ericholscher commented May 22, 2018

This looks ready to merge. Should we hold off on this @agjohnson until we do more design tweaks, or should we get this in to make things a bit nicer for now?

@ericholscher

This comment has been minimized.

Member

ericholscher commented Jun 6, 2018

Tested locally & it looks good.

@ericholscher ericholscher merged commit 7f01c6c into rtfd:master Jun 6, 2018

1 check passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details

@stsewd stsewd deleted the stsewd:consistent-sections branch Jun 6, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment