Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Reworking site template to utilize Sass #2687
Alright @parkr, there it is. Got a bit bigger than I thought it would.
So folks, apologies for any mistakes I might have made. This is my first bigger pull request touching more than 2 lines of code at a time.
I'm open for questions/suggestions and won't be mad if this doesn't get merged. :)
Some argue that you can/should use an
Anyway that's just my opinions/rationale for the existing markup. If you guys disagree and want to change it that's
Did you update all the padding to reflect this change as well? Otherwise it's going to bork styles everywhere.
I'm also generally
I actually haven't heard of this yet, but I'm open for suggestions. What do others think about this? I can see your point here and give this some thoughts.
Edit: I looked around a bit and this answer on webmasters.stackexchange.com was what I was looking for. Good explanation and I agree with you, @jglovier. Removed the
I consider your second sentence about that bogus as well. Switching the headlines in such a case doesn't seem consistent to me.
Yes. I had
Up to this point I never found a situation where instead of
When no fill attribute and no fill property are present in the document, it defaults to black. For when the stylesheet doesn’t load, this seems fine for me, because the other colors aren’t present either in this case.
I’d like to here @parkr's opinion here. Thank you for your feedback. It is definitely helping me. :)
Thanks for your detailed comment, @jglovier! Always great to know you'll reply to a call for help with detail, clarity, and honor.
Disclaimer: I have always been more of a server guy myself, and don't have much knowledge of the latest trends in CSS. My personal site is an example of the simple things I ask for from CSS.
I don't really understand this. Does that mean I'll be up until dawn messing around with my new Jekyll site? I'm worried that new features adds overhead, even for someone like me that has been making websites since I was 12.
I have no idea how
I think the fill should stay in the HTML as well. It makes it more interchangeable and deletable if I decide I don't want it. I think that is highly possible. Thus it becomes fully isolated in the HTML.
Now the default behavior for calculating the width of elements with the default box model is as follows:
Content width + border widths + paddings (roughly, there are edge cases for when content width is zero)
Problem? Yes, because we can’t set the total width of the element. We need to calculate. For when we set
Box Sizing | CSS-Tricks – see the image at the top of the article. Visually clear.
I moved it to the CSS, because of seperation of markup and style. Having
I suggest having
Thanks for that great explanation of
I think it should only be in one place – having it in two places will bring just confusion to users trying to change this.
It feels like it's an integral part of the graphic itself, so I'd prefer to see it left in the
Yeah, exactly why I opted not to use it in the first place. There would be cognitive overhead for users who aren't accustomed to the box-model because it affects how padding works.
As for browser support, CSS
Again, since it's a preference thing and not a clear best practice thing, I'd say let the default theme stick with the most familiar paradigms.
Here's caniuse.com browser support stats for CSS
Here's caniuse.com browser support stats for
Note that primary green is full support, and off color green is partial support.
@troyswanson When using
I’m going to revert this now. It’s not a big deal, because it affected the behavior of the footer columns only. However I want to point out that in my opinion