Skip to content
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

@stsewd
Copy link
Member

@stsewd 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
Copy link
Member

@humitos 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
Copy link
Member Author

@stsewd 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
Copy link
Member

@humitos 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
Copy link
Member

@humitos 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
Copy link
Member Author

@stsewd 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 https://github.com/rtfd/readthedocs.org/issues/3554

@humitos
Copy link
Member

@humitos 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 stsewd force-pushed the consistent-sections branch from 75e074c to 0ca31d8 Feb 16, 2018
@stsewd
Copy link
Member Author

@stsewd 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

Copy link
Member

@humitos humitos left a comment

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." %}
Copy link
Member

@humitos humitos Feb 19, 2018

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.

Copy link
Member

@humitos humitos Feb 19, 2018

Nice reply! Hehe!

Makes sense to leave as you did, then :)

@agjohnson
Copy link
Contributor

@agjohnson 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
Copy link
Contributor

@agjohnson 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.

Copy link
Contributor

@agjohnson agjohnson left a comment

Noting required change on edit button alignment.

@stsewd
Copy link
Member Author

@stsewd 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
Copy link
Member

@humitos 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 stsewd force-pushed the consistent-sections branch from 2104e30 to 7b7ecb3 Apr 11, 2018
@stsewd
Copy link
Member Author

@stsewd 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.

https://github.com/rtfd/readthedocs.org/blob/7b7ecb3bfc6fa37f56dc7eace19f8ce09f8233f4/media/css/core.css#L392

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
Copy link
Contributor

@davidfischer 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
Copy link
Member

@ericholscher 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
Copy link
Member

@ericholscher ericholscher commented Jun 6, 2018

Tested locally & it looks good.

@ericholscher ericholscher merged commit 7f01c6c into readthedocs:master Jun 6, 2018
1 check passed
@stsewd stsewd deleted the consistent-sections branch Jun 6, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet

6 participants