Theme update #553

Sapludināts
elegaanz sapludināja 21 revīzijas no theme-update uz master pirms 5 gadiem
elegaanz " komentēja pirms 5 gadiem" (Migrēts no github.com)

So far:

  • Ligther colors
  • No more border radius
  • Buttons are now always colored
  • Fix weird margin with CWed images
  • Add a border to quotes
  • Start to redesign the post page (according to the Figma mockups)
    • Full-size cover image, with a gradient and the title/subtitle/authors/date over it
    • Like/boost are now between tags and author info
    • Author info has a difference background color to make a difference between the different sections
    • Tags and license are now side-by-side

As I started it, this redesign is not perfectly following what was done on Figma (for instance lighter colors were not planned), but I'm open to discussion if you think Figma mockups should be better respected.

It is available at https://pr-553.joinplu.me/ if you want to see how it looks like. You can login with admin/admin123 to see all the pages.

So far: - Ligther colors - No more border radius - Buttons are now always colored - Fix weird margin with CWed images - Add a border to quotes - Start to redesign the post page (according to the Figma mockups) - Full-size cover image, with a gradient and the title/subtitle/authors/date over it - Like/boost are now between tags and author info - Author info has a difference background color to make a difference between the different sections - Tags and license are now side-by-side As I started it, this redesign is not perfectly following what was done on Figma (for instance lighter colors were not planned), but I'm open to discussion if you think Figma mockups should be better respected. It is available at https://pr-553.joinplu.me/ if you want to see how it looks like. You can login with admin/admin123 to see all the pages.
codecov[bot] " komentēja pirms 5 gadiem" (Migrēts no github.com)

Codecov Report

Merging #553 into master will decrease coverage by <.01%.
The diff coverage is 0%.

@@            Coverage Diff            @@
##           master    #553      +/-   ##
=========================================
- Coverage   34.51%   34.5%   -0.01%     
=========================================
  Files          67      67              
  Lines        7872    7876       +4     
  Branches     1890    1890              
=========================================
+ Hits         2717    2718       +1     
- Misses       4394    4398       +4     
+ Partials      761     760       -1
# [Codecov](https://codecov.io/gh/Plume-org/Plume/pull/553?src=pr&el=h1) Report > Merging [#553](https://codecov.io/gh/Plume-org/Plume/pull/553?src=pr&el=desc) into [master](https://codecov.io/gh/Plume-org/Plume/commit/c67f65e6844b8e000795156d89ac01e50da6aba3?src=pr&el=desc) will **decrease** coverage by `<.01%`. > The diff coverage is `0%`. ```diff @@ Coverage Diff @@ ## master #553 +/- ## ========================================= - Coverage 34.51% 34.5% -0.01% ========================================= Files 67 67 Lines 7872 7876 +4 Branches 1890 1890 ========================================= + Hits 2717 2718 +1 - Misses 4394 4398 +4 + Partials 761 760 -1 ```
trwnh " komentēja pirms 5 gadiem" (Migrēts no github.com)

Perhaps main article's max-width should be a bit wider? 40rem is quite narrow. Optimal readability would suggest making it somewhere between 45-75 characters, which can be represented by the ch unit in CSS. So I would propose perhaps making the rule max-width: 70ch instead of max-width: 40rem

Perhaps `main article`'s max-width should be a bit wider? `40rem` is quite narrow. Optimal readability would suggest making it somewhere between 45-75 characters, which can be represented by the `ch` unit in CSS. So I would propose perhaps making the rule `max-width: 70ch` instead of `max-width: 40rem`
trwnh " komentēja pirms 5 gadiem" (Migrēts no github.com)

Also the main header and main header > img are way too tall, and should each have a max-height of no more than calc(100vh - $heightOfBodyHeader) -- this allows the header to not be bigger than the browser viewport.

Also the `main header` and `main header > img` are way too tall, and should each have a max-height of no more than `calc(100vh - $heightOfBodyHeader)` -- this allows the header to not be bigger than the browser viewport.
elegaanz " komentēja pirms 5 gadiem" (Migrēts no github.com)

So… I tried to limit the height of the illustration, but it is impossible to do it without losing the ratio or a part of the image. I don't know what should be done: hide some a portion of the illustration if it is too big, or give the responsibility to author to provide images in reasonable dimensions?

Someone also proposed to have an option that could be enabled to limit the height of the header (by hiding some of the image) if you want to be sure to never have giant images. So that can be a solution too.

So… I tried to limit the height of the illustration, but it is impossible to do it without losing the ratio or a part of the image. I don't know what should be done: hide some a portion of the illustration if it is too big, or give the responsibility to author to provide images in reasonable dimensions? Someone also proposed to have an option that could be enabled to limit the height of the header (by hiding some of the image) if you want to be sure to never have giant images. So that can be a solution too.
trwnh " komentēja pirms 5 gadiem" (Migrēts no github.com)

I think fitting is better than cropping. You can either accept the ratio loss inherent to cover-fit, or you can cap the max-width of the image/header (in addition to the max-height). That style of header image can be seen in Ghost, for example: https://demo.ghost.io/welcome/

I think fitting is better than cropping. You can either accept the ratio loss inherent to cover-fit, or you can cap the max-width of the image/header (in addition to the max-height). That style of header image can be seen in Ghost, for example: https://demo.ghost.io/welcome/
marek-lach " komentēja pirms 5 gadiem" (Migrēts no github.com)

This is a great change. I only propose changing the main purple color of links from the current hex code of #7765E3 to something like #887ADE, #8D80DE, or perhaps #9784CB, because on very light backgrounds, it's very hard to see, as shown bellow:
Screenshot 2019-04-30 at 19 46 41

Screenshot 2019-04-30 at 19 53 18
This is a great change. I only propose changing the main purple color of links from the current hex code of `#7765E3` to something like `#887ADE`, `#8D80DE`, or perhaps `#9784CB`, because on very light backgrounds, it's very hard to see, as shown bellow: <img width="485" alt="Screenshot 2019-04-30 at 19 46 41" src="https://user-images.githubusercontent.com/45913977/56982556-e3e68780-6b81-11e9-9d2c-c7188b6187a5.png"> <img width="371" alt="Screenshot 2019-04-30 at 19 53 18" src="https://user-images.githubusercontent.com/45913977/56982579-ee088600-6b81-11e9-9a43-100193c5c44d.png">
elegaanz " komentēja pirms 5 gadiem" (Migrēts no github.com)

@marek-lach Even with another shade of purple the contrast was quite poor, so I made it white, but with underlining when you pass your cursor over it to make you understand it is a link.

@marek-lach Even with another shade of purple the contrast was quite poor, so I made it white, but with underlining when you pass your cursor over it to make you understand it is a link.
marek-lach (Migrēts no github.com) recenzēja pirms 5 gadiem
marek-lach (Migrēts no github.com) " komentēja pirms 5 gadiem"

Under that we could also add the line:
display: -webkit-flex; to ensure Safari likes it :-)

Under that we could also add the line: `display: -webkit-flex;` to ensure Safari likes it :-)
elegaanz (Migrēts no github.com) recenzēja pirms 5 gadiem
elegaanz (Migrēts no github.com) " komentēja pirms 5 gadiem"

According to this table Safari supports display: flex even without a specific prefix.

According to [this table](https://developer.mozilla.org/en-US/docs/Web/CSS/display#Browser_compatibility) Safari supports `display: flex` even without a specific prefix.
marek-lach " komentēja pirms 5 gadiem" (Migrēts no github.com)

Maybe under the About this instance link in the footer, there could also be a Privacy policy link. It would help to fill up the empty space there a little bit.
Screenshot 2019-05-05 at 12 13 02

As per what the `Privacy policy' page itself could contain, just basic stuff could be something like:

If you are browsing this site as a visitor, your IP address is collected by the server for moderation purposes.
As a registered user, you also have to provide your username (which does not have to be your real name), your functional email address and a password, in order to be able to log in, write articles and comment. The content you submit is stored until you delete it.

Maybe under the `About this instance` link in the footer, there could also be a `Privacy policy` link. It would help to fill up the empty space there a little bit. <img width="1280" alt="Screenshot 2019-05-05 at 12 13 02" src="https://user-images.githubusercontent.com/45913977/57192431-a5115280-6f30-11e9-9bf7-12606da65eaf.png"> As per what the `Privacy policy' page itself could contain, just basic stuff could be something like: If you are browsing this site as **a visitor**, your IP address is collected by the server for moderation purposes. As **a registered user,** you also have to provide your username (which does not have to be your real name), your functional email address and a password, in order to be able to log in, write articles and comment. The content you submit is stored until you delete it.
elegaanz " komentēja pirms 5 gadiem" (Migrēts no github.com)

I added it. I just changed a bit your text, because we don't actually collect IP addresses, and I added a part about which cookies we are using.

I added it. I just changed a bit your text, because we don't actually collect IP addresses, and I added a part about which cookies we are using.
marek-lach " komentēja pirms 5 gadiem" (Migrēts no github.com)

I added it. I just changed a bit your text, because we don't actually collect IP addresses, and I added a part about which cookies we are using.

Sure 👍

In that case the line As a registered user, you also have to provide your username, doesn't need the also in it.

> I added it. I just changed a bit your text, because we don't actually collect IP addresses, and I added a part about which cookies we are using. Sure 👍 In that case the line As a registered user, you also have to provide your username, doesn't need the `also` in it.
Īpašnieks

I think this should be a default privacy policy only, and should be editable easily by admins (probably in a future pr, this one is supposed to be about design). While we don't store much (no ip, no cookies when not logged in...), most reverse proxy configuration will log at least user ip.

I think this should be a default privacy policy only, and should be editable easily by admins (probably in a future pr, this one is supposed to be about design). While _we_ don't store much (no ip, no cookies when not logged in...), most reverse proxy configuration will log at least user ip.
trinity-1686a recenzēja pirms 5 gadiem
trinity-1686a atstāja komentāru
Īpašnieks

this would require fixing merge conflict before validation

this would require fixing merge conflict before validation
@ -45,0 +46,4 @@
println!("cargo:rerun-if-changed=static/css/_global.scss");
println!("cargo:rerun-if-changed=static/css/_header.scss");
println!("cargo:rerun-if-changed=static/css/_variables.scss");
println!("cargo:rerun-if-changed=static/css/main.scss");
Īpašnieks

Watching the whole directory (first rerun-if-changed, was there before) is pretty much useless as it is platform dependent, and on our main target (linux) apply basically on file creation/deletion inside, it could be removed

Watching the whole directory (first rerun-if-changed, was there before) is pretty much useless as it is platform dependent, and on our main target (linux) apply basically on file creation/deletion inside, it could be removed
Īpašnieks

what should it be changed to?

what should it be changed to?
Īpašnieks

this value might be a bit too close to actual white : pages that are mainly forms (creating article, editing profile, or even logging in) look odd in my opinion. I've tried with F8F8F8, and I think it looks better so to contrast with FFFFFF inside input elements

this value might be a bit too close to actual white : pages that are mainly forms (creating article, editing profile, or even logging in) look odd in my opinion. I've tried with `F8F8F8`, and I think it looks better so to contrast with `FFFFFF` inside input elements
elegaanz (Migrēts no github.com) recenzēja pirms 5 gadiem
elegaanz (Migrēts no github.com) " komentēja pirms 5 gadiem"

I think I introduced a variable for that value, but maybe I didn't?

I think I introduced a variable for that value, but maybe I didn't?
trinity-1686a recenzēja pirms 5 gadiem
trinity-1686a atstāja komentāru
Īpašnieks

👍

:+1:
trinity-1686a apstiprināja izmaiņas pirms 5 gadiem
trinity-1686a atstāja komentāru
Īpašnieks

(I just merged master into this to fix conflict)

(I just merged master into this to fix conflict)

Recenzenti

trinity-1686a apstiprināja izmaiņas pirms 5 gadiem
Izmaiņu pieprasījums tika sapludināts ar revīziju ad3a8b92d1.
Varat aplūkot arī komandrindas instrukcijas.

Solis 1:

Projekta repozitorijā izveidojiet jaunu jaunu atzaru un pārbaudiet savas izmaiņas.
git checkout -b theme-update master
git pull origin theme-update

Solis 2:

Sapludināt izmaiņas un atjaunot tās Forgejo.
git checkout master
git merge --no-ff theme-update
git push origin master
Pierakstieties, lai pievienotos šai sarunai.
Nav recenzentu
Nav atskaites punktu
Nav atbildīgo
2 dalībnieki
Paziņojumi
Izpildes termiņš
Datums līdz nav korekts. Izmantojiet formātu 'gggg-mm-dd'.

Izpildes termiņš nav uzstādīts.

Atkarības

Nav atkarību.

Atsaucas uz: Plume/Plume#553
Notiek ielāde…
Vēl nav satura.