Make examples simpler, cleaner, more focused and future-facing? #6674
RE: "Add Different Padding"
Yes, it looks a bit hacky to us, too . . . but the key here is to clearly illustrate a specific concept, hopefully in a clear and unambiguous way. For the specific area that we're approaching, padding, I think it works.
Negative margins exist and are widely supported by every browser. I am not aware of any general guideline that suggests that you should not use it.
In fact: https://www.smashingmagazine.com/2009/07/the-definitive-guide-to-using-negative-margins/
Negative margins are not a hack
This is especially true. It’s because of not understanding negative margins properly that it got its hackish image. It only becomes a hack if you use it to fix an error you made elsewhere.
We are, of course, open to suggestion. If you would like to propose an alternative illustration of the concept, show us some code.
I think you misunderstand the state of users coming into this content. We're talking about people who have, in many cases, literally never even seen HTML at all. We're talking about true novices. They need to establish a basis of understanding before they can move on to more advanced topics.
I had to google "Reusable Web Components", because I'd never heard of them. Can I Use shows very poor support for several key enabling technologies. Regardless of the support, those are pretty advanced topics which require a much higher level of understanding then a novice is likely to have - in particular basic JavaScript, which occurs later in the curriculum.
It's all fine and dandy to come in and make these broad suggestions, but I really don't see any clear way for us to implement them. If you're passionate about them then, well, we're an open source project and we accept Pull Requests.
Thanks and Happy Coding!
Thanks @SaintPeter for taking your time to answer!
RE: "Add Different Padding"
Yes, it looks a bit hacky to us, too . . . but the key here is to clearly illustrate a specific concept, hopefully in a clear and unambiguous way. For the specific area that we're approaching, padding, I think it works.
Glad you agree it is hacky. But I'm not following how this margin addition illustrates padding, which is a different concept?
Negative margins exist and are widely supported by every browser. I am not aware of any general guideline that suggests that you should not use it.
In fact: https://www.smashingmagazine.com/2009/07/the-definitive-guide-to-using-negative-margins/
Negative margins are not a hack
It is a general purpose tool, so it would be hard to give such a general guideline without referring to specific context.
Though, if you really ask -- there are some ;-)
Of course, it has its use but it has to be used very carefully and can easily lead to hacks.
Sadly, I don't find this article doing good and convincing job to showcase thoses uses.
Let me try to explain. I have created a Jsbin based on the proposed code. (If I were the author, I would have linked or embedded such ready-to-use example in the article, but then again I'm not the author ;-).
As you can see in my Jsbin, I have uncommented two declarations - about line-height
and list-style
. Why? Because they are not related to the demonstrated phenomenon. Which is to create 3 column layout. And now you can see the design is broken. Also you see the boxes have some weird nested structure, which doesn't feel right. So you can easily break the design by tiny customization, which is precisely why this solution is hacky and something I would never want to have in my code.
As a side note, the code given in the article is very careless with no indentation formatting and several <li>
tags that should actually be the closing </li>
. I know it is trivial matter but can frustrate people trying to copy the code and use or understand.
The second use case doesn't even have a code. It suggests to use negative margins to overlap elements. Which is valid but again, I'm not convinced the negative margins are the best way. What it does is pulling down all of your content before. Would you really want that? It feels more likely that you only want specific elements to pull down. Then it is easy to achieve by positioning those elements whenever you want to, which would feel cleaner and more flexible, i.e. would better adapt to various design changes.
The third example to overlap the text is again easily achievable with proper positioning. Why not simply position both copies inside the same container with slightly different increment? In constrast, using negative margin feels hacky because the margin's value depends on many other particular design element, so clearly more fragile and unflexible.
The author doesn't even bother to provide any code, so can never be completely sure what actually he meant.
For the forth example,
I have also created a Jsbin. That one literally follows the given example with no modification, yet the design is already broken! Just have a look how semantically similar elements are not vertically aligned in both their texts and boxes!
Further this statement in the article is actually wrong or confusing or both ;-)
If no width is applied, adding Negative Margins to its left/right pulls the element in both directions increasing its width. It’s here that the margin acts like a padding.
Summarizing, in my view, these kinds of articles do, in my view, a disservice to community by promoting bad and hacky practices leading to fragile desing that can easily break under future modifications, leading to more and more hacky breakable code that won't serve anyone. They are also written in a sketchy way with no deep and conceptual discussion of best practices and patterns that are worth learning as long term investment.
This is especially true. It’s because of not understanding negative margins properly that it got its hackish image. It only becomes a hack if you use it to fix an error you made elsewhere.
We are, of course, open to suggestion. If you would like to propose an alternative illustration of the concept, show us some code.
I've actually said it in words -- really dead simple:
<style>
.red-box {
background-color: red;
padding-top: 40px;
padding-right: 20px;
padding-bottom: 20px;
padding-left: 40px;
}
.green-box {
background-color: green;
}
</style>
<h5 class="box red-box">padding</h5>
<h5 class="box green-box">padding</h5>
I think you misunderstand the state of users coming into this content. We're talking about people who have, in many cases, literally never even seen HTML at all. We're talking about true novices. They need to establish a basis of understanding before they can move on to more advanced topics.
The more they will feel confused by those complex layout. I have few years experience and even I have to scratch my head to understand why it is there. People with less experience will likely be even more overwhelmed by the high noise-to-signal ratio.
I had to google "Reusable Web Components", because I'd never heard of them. Can I Use shows very poor support for several key enabling technologies. Regardless of the support, those are pretty advanced topics which require a much higher level of understanding then a novice is likely to have - in particular basic JavaScript, which occurs later in the curriculum.
Your first link is entitled "Build Reusable Web Components using HTML5 Web Components". I hope it makes it clear how the two are different. The first is a general principle, the second is a particular HTML5 technology that can be used. And the second link is special for that technology, which is actually quite well supported as far as I can see. Not saying that support isn't really a problem as it gets better in the future fast, and even now there are polyfills or ponyfills :). But what I mean is the principle not the specific technology. An example is any Bootstrap component. It is flexible and reusable. And composable. Well, most of the time, at least.
It's all fine and dandy to come in and make these broad suggestions, but I really don't see any clear way for us to implement them. If you're passionate about them then, well, we're an open source project and we accept Pull Requests.
A quick way would be to simplify the code as I suggested above. From my perspective. But then, I don't have the big picture of your course (that I find great BTW), so I imagine it might get difficult with other goals you might be trying to achieve. Which I may not know. That is why I feel having a discussion to better understand it would make it more clear to me. I'll be happy to submit a PR when I better understand the other goals, but I don't want to come with my PRs completely missing the points I'm not aware of.
But for now, I have to say, I'm still unclear about the reason those additional elements complicating the picture cannot be removed. If there are some, I'd be happy to learn.
Finally, please excuse my possibly harsh critics, I actually love what you guys are doing and all my critics has the only purpose to make it better.
RE: Web Components
Sorry, if there is some other aspect of Web Components that is not related to HTML5, a cursory Google search did no reveal a clear alternative definition. My point is that if I've never heard of them I have no hope of teaching them, let alone completely revamping our curriculum around them.
We do have some Bootstrap content, of course, and we could probably expand that somewhat to explicitly include their components.
RE: Your Proposed Code
It's not clear to me how this is superior in illustrating the difference between something with and without padding. Additionally, it is not a clean lead-in to the next challenge which talks about margin. I think that in context the illustrations make sense.
I didn't mean to focus on the Web Components as buzzword.
More on clean reusable patterns that don't break as soon as you change your design :)
Which is exactly what happened with ALL examples in that "negative margin" article. Having read it, I'm even more convinced that negative margin are very likely to lead to hacks. I have yet to see a convincing example to prove that wrong. (But I'm always open to it.)
About illustrating the padding, I really don't see any reason to complicate it with margins. Padding is about the inside of the elements. Margins -- about outside. Each one can be confusing enough for a newcomer, but mixing them will double the confusion. So showing same sized elements with different paddings inside will focus the student's attention to the main point, distraction free.
Then, when margin comes up, it is perfectly logical and intuitive to bring it up. That way the student will see the clear difference. I understand that you wanted to keep the the same design, but pedagogically people are more alerted to the changes. So you get their attention right where you want it.
(Just to say I had some idea about teaching, I've been university teacher for over 20 years. ;-)
Then again, getting real user's feedback is even better.
It might be just me, I find this example too "hacky" for what it does:
http://www.freecodecamp.com/challenges/add-different-padding-to-each-side-of-an-element
This element
is put outside of the yellow box, yet it is "brutally" pushed into it by applying the negative margin. Note that the exercise is about padding, so that additional complexity feels distracting with no clear purpose.
Even worse - this element labels "margin", whereas actually none of the other boxes have any margin declared. Which is really confusing.
The current web development trend is towards reusable web components, which is being more and more promoted and enforced by frameworks. In contrast, the given example here embrace the pixel hard-coded design practices that will influence the beginners who learn from it, making it much harder for them later to un-learn it in favour of more flexible and future-facing design patterns. They will be hit hard by the massive variety of devices with varying width they will want to support.
Way too many sites out there are broken on way too many devices, which is frustrating for both users and developers. Is there any reason not to embrace the flexibility right from the start and use percentages, em's and other flexible units?
I understand this example is meant for beginners and is aimed to be as simple as possible, but ironically it actually isn't.
The simplest example really would only need two boxes: