-
Notifications
You must be signed in to change notification settings - Fork 124
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
Update login and signup forms UI, and make search label visible #3362
Conversation
} | ||
} | ||
|
||
input[type=submit] { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Avoid qualifying attribute selectors with an element.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since the markup being styled is not under our control (coming from Devise gem), there's no other way I can wrap this element with a CSS selector class cleanly. Same as the next Hound complaint for type=email
.
|
||
.field { | ||
@extend .form-group; | ||
input[type=email], |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Avoid qualifying attribute selectors with an element.
Rule declaration should be preceded by an empty line
@@ -0,0 +1,19 @@ | |||
// Login / Sign up styles needed because Devise gem controls the markup | |||
form.new_user { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Avoid qualifying class selectors with an element.
Selector new_user
should be written in lowercase with hyphens
outline: 5px auto -webkit-focus-ring-color; // Chrome, Safari | ||
outline: -2px; | ||
} | ||
|
||
.navbar-brand { | ||
padding: 12px 0 12px 15px; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Shorthands of length 4
are not allowed. Value was 12px 0 12px 15px
05399af
to
0378059
Compare
} | ||
} | ||
|
||
input[type='submit'] { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Avoid qualifying attribute selectors with an element.
.field { | ||
@extend .form-group; | ||
|
||
input[type='email'], |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Avoid qualifying attribute selectors with an element.
|
||
.navbar-brand { | ||
padding-top: 12px; | ||
padding-right: 0px; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
0px
should be written without units as 0
outline: 5px auto -webkit-focus-ring-color; // Chrome, Safari | ||
outline: -2px; | ||
} | ||
|
||
.navbar-brand { | ||
padding-top: 12px; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Properties should be ordered padding-bottom, padding-right, padding-top
0378059
to
1d5f6a7
Compare
I'm against adding a logo to the repository, as it's something that most institutions are going to want to provide for themselves and it increases the size of the repository. Can you host it elsewhere and just reference it? Similarly, I'd prefer we don't include |
@jcoyne Ok, so for the logo, where else could or should it be hosted? Just thinking if that server goes down, or people are working on the app offline, it's a broken image vs the 15KB weight. I don't even know if it looks that great, just trying to do something to break this out of generic Bootstrap app look & feel.... but maybe that's not a concern? Also, for the Sign In / Log In cleanup, I was thinking non-Devise users would not to be affected. For the life of me I can't figure out which HTML partial in Hyrax contains the Log In / Sign Up include code. Would a compromise be if someone could help me locate that file, we wrap the Devise code in a specific class selector, something like |
The devise code is in the devise gem. As for the image weight, if it’s this image, I wouldn’t worry about it being broken, if you care about controlling its availability you can move it into the hyrax app you generate. |
Would a better approach be to bring over the Devise partials? I tried this first but it didn't work...the Devise partial's path is Any idea what I'm missing? After trying this route, that's when I created the Back to the point of this ticket, I'm thinking from the perspective of say a potential adopter of Hyrax, they go to Nurax to get an impression of the UI, and the Log In / Sign Up default views, the first thing they see, looks like it's neglected or unfinished. If it's no big deal to anyone else, I can just close this ticket...that's fine too. |
@adamjarling I think the problem here is that you are trying to fix this in Hyrax, but the fix belongs in an application that uses Hyrax, such as Hyku or Nurax. Hyrax should just be a template, not a full solution, especially for something like authentication, which many institutions handle differently. This is why we don't require devise, we just use it for the default install. Adopters are encouraged to find another solution for auth, because devise is not suitable for all cases. |
IMO, if Hyrax is going to provide any kind of default login form out of the box, it should look good. So if this PR isn't worth merging, is the better course of action to remove the login form altogether? |
@mbklein Hyrax doesn't provide a login form, devise does. |
app/views/_logo.html.erb
Outdated
@@ -1,4 +1,3 @@ | |||
<a id="logo" class="navbar-brand" href="<%= hyrax.root_path %>" data-no-turbolink="true"> | |||
<span class="glyphicon glyphicon-globe" role="img" aria-label="<%= application_name %>" aria-hidden="true"></span> | |||
<span class="institution_name"><%= application_name %></span> | |||
<%= image_tag("hyrax_logo-bw.png", alt: application_name) %> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
perhaps this could be done as something configurable such as
<div class="background-container" style="background-image: url('<%= banner_image %>')"></div> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm going to pull the logo out of this PR.
1d5f6a7
to
19a0ab2
Compare
on the logo: i think it is a useful placeholder. is the primary issue here one of the size of the image? |
i'm a little confused as tot he status of this work and conversation. @adamjarling thoughts? |
@vantuyls The way I understand it, Devise is a gem which provides the markup for the Log In / Sign Up forms. This markup is not part of the Hyrax codebase. My changes are CSS additions (in the Hyrax codebase), which target Devise's Log In / Sign Up elements. My thought was if this is going to be visible on Nurax, then it should be cleaned up. The suggestion was this styling code should be added elsewhere, So maybe the path forward is:
|
Some other alternatives:
|
I don't see any value in making this change in @jcoyne said:
Since the and:
This seems like a lot of overhead to avoid putting some |
@no-reply I'm just concerned that adding these styles to the gem make them "permanent", that is, hard to remove from your local install. How about moving these styles to the generator so that one could just |
Does it make them "permanent", or just
The trade-off seems to be that any generated code needs to be manually updated to keep up with changes in the engine. The fragmentation of default styles between the engine and application seems like a risk to me. We don't seem to generate |
@no-reply We do generate https://github.com/samvera/hyrax/blob/master/lib/generators/hyrax/templates/hyrax.scss and this is intended to make it possible to keep things we don't want out of the compiled css. And, yes, i'm largely for keeping this out of the default hyrax bundle because it's so tightly coupled to |
@jcoyne what if we moved the devise-specific styles into their own sheets and imported them separately, e.g.:
That would meet your easily removable criteria without requiring a separate gem. Does this work for you? Edit: indeed, it might be enough to remove import for |
This needs to be rebased to pass CI, in any case, so I'm happy to make any changes needed if we can decide on a path forward. |
I would feel better if |
These syles impact views generated/managed by `devise` and the host application. We provide default styles to cover the most common cases. Rather than depending on these ourselves, we include the dependency in the `hyrax.scss` generated into the host application. This should help applications remove or override these styles more flexibly, while still allowing Hyrax to maintain the default styles internally.
19a0ab2
to
f388fbe
Compare
@jcoyne i pushed a new commit making that change, and rebased the rest. if it looks good, could you approve? I'll hold merge for your consideration. Thanks for sticking this one out; i think the approach we landed on is a big improvement. |
This takes advantage of the new login form styles in samvera/hyrax#3362.
This takes advantage of the new login form styles in samvera/hyrax#3362.
Fixes #3361
This updates the following:
@samvera/hyrax-code-reviewers