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

feat: add self-contained styles for Time component #269

Merged
merged 3 commits into from
Aug 20, 2019

Conversation

markpalfreeman
Copy link
Contributor

@markpalfreeman markpalfreeman commented Aug 16, 2019

Related Issue

#136

Description

Self-contained styles for Time.

NOTE / HELP WANTED:
I removed the selector at this level that shrinks its child input padding for these small inputs.
I need guidance on where this should go instead—I don't think we want that for all .fd-form__controls, it's specific to this context 🤷‍♂
addressed

Screenshots

Before:

Screen Shot 2019-08-16 at 10 13 42 AM

After:

❗️ notice the padding issue now that it's been reverted the "default" addressed
Screen Shot 2019-08-16 at 10 13 57 AM

Screen Shot 2019-08-16 at 10 22 14 AM

@markpalfreeman markpalfreeman added Help wanted Extra attention is needed Ready for Review labels Aug 16, 2019
@markpalfreeman markpalfreeman requested a review from a team August 16, 2019 17:53
@markpalfreeman markpalfreeman self-assigned this Aug 16, 2019
@netlify
Copy link

netlify bot commented Aug 16, 2019

Deploy preview for fundamental-styles ready!

Built with commit 80fd778

https://deploy-preview-269--fundamental-styles.netlify.com

&:last-child {
margin-right: 0;
}
}

&__input {
margin: fd-space(2) 0;
input {
Copy link
Contributor Author

@markpalfreeman markpalfreeman Aug 16, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Most primary change—the removal of this padding messes things up (reverts to a larger side padding), but I'm not sure where to put it instead.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🤔 You are right that these styles are specific to this context. We have n-number of "items", each with an input and two buttons. Let's style it that way. Let's keep the fd-time__item styles. Then, let's remove (🔥) the current fd-time__input wrapper <div> and put that class directly on the <input> and make the styling:

&__input {
    margin: fd-space(2) 0;
    padding-left: fd-space(2);
    padding-right: fd-space(2);
    text-align: center;
}

I would also put the fd-time__input as a child selector to fd-time__item to make sure our specificity wins on the <input> (since that will have styles already coming from fd-form__control).

This will all be a breaking change, but hey -- we're on version 0. 😄

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This makes a lot of sense, good suggestion on just repurposing the class (maybe that's what Jenna was hinting at earlier and I didn't fully grasp it).

@@ -25,7 +25,8 @@ body {
}

.input-playground {
width: 250px;
width: 100%;
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is the default input style, which I think makes sense to have here too; without it, playground inputs with "limited" width extend way beyond their containers.

{%- for item in properties.items %}
{{ time_item(item) }}
{%- endfor %}
</div>
{%- endmacro %}

{%- macro time_item(properties={}, state={}, modifier=[], classes=[], aria=[]) -%}
{%- macro time_item(properties={}) -%}
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Cleaning up properties that aren't needed with just a single example.

&:last-child {
margin-right: 0;
}
}

&__input {
margin: fd-space(2) 0;
input {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🤔 You are right that these styles are specific to this context. We have n-number of "items", each with an input and two buttons. Let's style it that way. Let's keep the fd-time__item styles. Then, let's remove (🔥) the current fd-time__input wrapper <div> and put that class directly on the <input> and make the styling:

&__input {
    margin: fd-space(2) 0;
    padding-left: fd-space(2);
    padding-right: fd-space(2);
    text-align: center;
}

I would also put the fd-time__input as a child selector to fd-time__item to make sure our specificity wins on the <input> (since that will have styles already coming from fd-form__control).

This will all be a breaking change, but hey -- we're on version 0. 😄

@markpalfreeman
Copy link
Contributor Author

Fixes addressed, the docs page has been restored:
Screen Shot 2019-08-16 at 3 17 54 PM

@markpalfreeman markpalfreeman removed the Help wanted Extra attention is needed label Aug 16, 2019
@@ -0,0 +1,4 @@
$fd-fonts-path: "../scss/fonts/";

@import "../scss/fonts/72";
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure why I didn't see this before, but the font isn't actually needed for this component. The form input will bring the font with it.

margin: fd-space(2) 0;
padding-left: fd-space(2);
padding-right: fd-space(2);
text-align: center;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You can leverage the power of sass and write this like:

&__item {
    {{ existing styles }}

    .#{$block}__input {
        margin: fd-space(2) 0;
        padding-left: fd-space(2);
        padding-right: fd-space(2);
        text-align: center;
    }
}

I think it's safer to write fd-time__input as a descendant class to fd-time__item, but not necessarily a direct descendant (using the > notation).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah I went back and forth on both of those points :)

Changes made.

@@ -11,17 +11,17 @@ $block: #{$fd-namespace}-time;
max-width: fd-space(10);
text-align: center;
margin-right: fd-space(1);

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think I missed this before (probably because it didn't show up directly in the file diff), but what exactly is this width: 184px for? The phrase "quick fix" worries me. And what overflow issue? This seems like it might be related to the use of fd-time within fd-time-picker, but this strikes me as a problem. In fact, see the attached screenshot.

Screen Shot 2019-08-19 at 9 49 30 AM

The 4th __item is wrapping due to this arbitrary width. I know it's the playground with crazy margin values being applied, but there is still no reason why any of this should wrap to a new line.

Maybe the fd-time class should provide a flex box wrapper around the fd-time__item blocks to prevent them from ever "wrapping". Thoughts?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree that it should be changed (any fixed width seems like a hack), but I wasn't sure this was the right time to do it...

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You know what, maybe it isn't the time to do it. I've created #280 to track this work.

Copy link
Contributor

@greg-a-smith greg-a-smith left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

With the hard-coded width issue being pushed to a separate issue, this looks good. 🚢

@greg-a-smith greg-a-smith changed the title fix: add self-contained styles for Time component feat: add self-contained styles for Time component Aug 20, 2019
@markpalfreeman
Copy link
Contributor Author

@greg-a-smith thanks, I agree. I'm wrapping up some TimePicker changes I was going to bundle here, but for the sake of reviews I'll just open another small PR

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

Successfully merging this pull request may close these issues.

2 participants