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

Add latest reset/normalize stylesheet to front end? #82

Closed
iteles opened this issue Mar 16, 2015 · 13 comments
Closed

Add latest reset/normalize stylesheet to front end? #82

iteles opened this issue Mar 16, 2015 · 13 comments

Comments

@iteles
Copy link
Member

iteles commented Mar 16, 2015

Investigate alternatives to Eric Meyer's CSS reset and determine whether normalize.css is the way to go.

@iteles iteles added this to the MVP milestone Mar 16, 2015
@iteles iteles changed the title Add latest reset/normalize stylesheet to front end Add latest reset/normalize stylesheet to front end? Mar 16, 2015
@iteles
Copy link
Member Author

iteles commented Mar 16, 2015

Decided to go with normalize.css as a base and make a few modifications:

  • Added box sizing best practice from CSS Tricks
  • Removed comments for readability except where particularly interesting
  • Removed extraneous styles we're unlikely to use at this stage (can be added later, e.g mark)
  • Removed unnecessary setting of styles and/or colors that will just be overwritten later (e.g. h1 font size and margin)

Note: This does mean that if/when normalize.css is updated, we'll need to take a quick look through the updates and add only the relevant/intelligent ones. This shouldn't be burdensome, but let me know if you think otherwise - now's the time to change it!

@nelsonic
Copy link
Member

Were you seeing specific issues in the front-end that a reset stylesheet has solved...?

@iteles
Copy link
Member Author

iteles commented Mar 17, 2015

@nelsonic Not specifically on time yet as I haven't started putting anything down yet. But in past projects I've found that I end up adding a bunch of reset styles to my stylesheets anyway to help with cross-browser differences, so a reset-type stylesheet has proven to be a useful starting point.

@iteles
Copy link
Member Author

iteles commented Mar 17, 2015

Done. See: #79, can still be pulled out of the PR.

@nelsonic
Copy link
Member

What does adding the reset solve...?

@iteles
Copy link
Member Author

iteles commented Mar 17, 2015

@nelsonic It solves the problem of inconsistencies in base stylesheets across browsers and minimises the amount of CSS we have to write, keeping our code more readable.
By zeroing out things like margins and padding, it creates a more consistent baseline from which to start, ultimately meaning we need to write less CSS because we don't have to write a bunch of browser-specific CSS into every element.

@nelsonic
Copy link
Member

The perceived problem...
_Which_ browser have you tested in that you've experienced the "inconsistencies" you are describing...?

@iteles
Copy link
Member Author

iteles commented Mar 17, 2015

In fighting margins particularly in the past, I've experienced "inconsistencies", so I quickly mocked up something very simple. This top one shows pure browser defaults across (from left to right) Chrome, Safari and Firefox:
chrome-safari-ff-minimal-styling

This has 3em applied to h3 and 1em applied to p. The sizes of the text across browsers is still different as are the margins.
chrome-safari-ff-with-ems

With normalize.css, things are still not perfect in safari but this causes less headaches in the long run.
chrome-safari-ff-with-normalize

Using this code (for version 2, no normalize.css and using minimal styling on h1 and p:

<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0, user-scalable=yes">
  </head>
  <body>
    <section>
      <h1>h1 text</h1>
      <p>paragraph text</p>
    </section>

    <style>
    body {
      margin: 1em;
      border: 5px solid black;
    }
    h1{
      font-size: 3em;
    }
    p{
      font-size: 1em;
    }
    <style>

  </body>
</html>

@iteles
Copy link
Member Author

iteles commented Mar 17, 2015

I'm not married to the idea of using a reset stylesheet, but I have found in the past that putting one in solves those 'last remaining bugs' across browsers.

@nelsonic
Copy link
Member

You're still adding way more than you need to the reset.css. we probably only need 10% of it...
https://github.com/ideaq/time/blob/9421bfec9bed19c5b0bebd2b4a23738c43f35a4b/front/css/normalize.css
Some of these css rules look like "good forward-planning", but most of them look like YAGNI

  • article,
  • aside,
  • details,
  • figcaption
  • etc...

@iteles
Copy link
Member Author

iteles commented Mar 17, 2015

I've removed a few more styles we won't need in the latest commit but the leanest way to do it is start with just the obvious ones and then check back into normalize.css when we add new elements to see if any resetting is recommended and make a decision to add it in then.

@nelsonic
Copy link
Member

Right now the entire project is 120 lines of code.
time-120-lines-of-code
What kind of automated tests do we have for the look-and-feel of the app...?

@iteles
Copy link
Member Author

iteles commented Mar 17, 2015

So I'd be doubling the codebase in one fell swoop. Not a great idea!
I think I added it to the wrong branch to be honest. I was thinking we could trial this on the one to throw away - prealpha. Reverting commits 👍 so PR #79 is fully TDD.

iteles added a commit that referenced this issue Mar 17, 2015
iteles added a commit that referenced this issue Mar 17, 2015
@iteles iteles closed this as completed Mar 18, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants