15 comments

  • Hmphry xHmphry x, over 6 years ago

    Border-box is fine, as not many still have to support IE7. It's officially dead and I am not busting my ass to support the the "1% or less" who still use it. The reason people do not use calc() is because android has like 0% support for it(get on their asses, Mr. Irish).

    I never really got into conditional comments. IE was never as bad at css and html for me as it was hyped to be. Sure, the occasional star or underline hack was needed, but ehhh. Safari 6 is a much bigger headache.

    The idea of classes over IDs is because IDs are too powerful and can get really difficult to deal with if you have many state changes, or just for maintainability. I wish the author wouldn't have coped out of this one, as I'd like to hear their reasoning. IDs are fine, but classes are just as fast and do not fuck with the CSS's natural hierarchy. In my workflow, I use classes for stylings and IDs for javascript(although I do sometime have to use classes), so I get that added bonus.

    6 points
    • Mike HeitzkeMike Heitzke, over 6 years ago (edited over 6 years ago )

      Generally disagree w/ the post on border-box besides the mention of the * selector being non-performant. That point is true, but I'll continue to use border-box. As noted, support for calc is garbage.

      At the end of the day, i'm not going to change how I write markup because I don't want to throw a htmlshiv at old browsers. I don't have a problem with the conditional tags for the older IE. It's awfully helpful to have the hooks if needed...and if you don't, pare down to the one(s) you need.

      I, too, wish he would have gone more in-depth, or at least presented an argument about using ID's. Common practices != to best practices always, no shit. Using ID's mixed in with classes is the recipe for a bad time IMO.

      1 point
      • Jeff EscalanteJeff Escalante, over 6 years ago (edited over 6 years ago )

        I use IDs heavily in my css, so maybe I can give a perspective.

        Let me start with the reason people say not to use IDs, which is that it's possible that you can use them incorrectly where that's not possible with classes. This is entirely valid, and is a reasonable way to teach beginners, much like beginners learn to semicolon every single line in javascript even though it's not necessary, etc. But if you fully understand what IDs are and how they work, it's quite possible to use them safely.

        Fair enough, you might be thinking, but IDs don't offer any advantage over classes inherently, so why would you even want to bother? Well for me, there are a few advantages that I appreciate about IDs. First if the fact that you can't have more than one per page. So when I see an id in css, I know that this is not a "component" of any kind. It's not something that's re-used. I use IDs as you might use headlines in markdown. Each section of the page gets an id, somewhat like a title. Styles unique to that section of the page are scoped under that id. This makes the css easy to read through, and makes you think about repeating and non-repeating styles.

        This sort of transitions into the "don't nest css" philosophy that many people are huge fans of. The argument behind it is similar -- if you don't nest anything, and you want to re-use something, you just do it and things can't go wrong. Whereas if you nest, it's possible something could go wrong when you need to refactor a component that was previously unique and now is used in more than one place. But like I said at the end of the last paragraph, I think it's really important that you think about reusable and unique styles, hard. Just making everything reusable is a cop-out, and can easily cause problems when you re-use a class, but then need to change a couple things. Reusable components need to be handled very carefully, as these are the easiest point for possible bugs in your css, and bugs that are really hard to detect unless you make a change then check over every other place in the site that uses that component to make sure it's ok.

        So overall, the way I write css banks heavily on ids because of the exact reason most people lean away from them. I like the fact that they can only be used once per page, and ids combined with the rest of my css coding style ensure that all styles are tightly scoped, and that you really have to think hard about making or changing reusable components, which is as it should be.

        I did a short writeup of the overall style here, if you're interested: http://markup.im/#rc6E3Rdg

        0 points
        • Clark WimberlyClark Wimberly, over 6 years ago (edited over 6 years ago )

          "First if the fact that you can't have more than one per page."

          Well, you can, you're just not supposed to.

          "So when I see an id in css, I know that this is not a "component" of any kind. It's not something that's re-used."

          Like #header? Or #sidebar? Or so many things that IDs are used for that are a reusable component?

          "Just making everything reusable is a cop-out"

          Now I'm lost. Making reusable, extensible styles is way harder than hardcoding everything to an ID.

          "that you really have to think hard about making or changing reusable components, which is as it should be."

          Why would you want extra work?

          I dunno, this whole comment left me kinda confused. If anything, using IDs to scope things would lead to less-DRY code (since you can't use styles scoped under an ID for other things).

          0 points
          • Jeff EscalanteJeff Escalante, over 6 years ago

            Like #header? Or #sidebar? Or so many things that IDs are used for that are a reusable component?

            No, I don't use IDs for reusable components. Haha I thought that part of my response was pretty clear. Also you don't need ids for these things you can use html elements like header.

            Why would you want extra work?

            I explained this super clearly in my response. I don't think there's anything else I can say here, perhaps re-read?

            If anything, using IDs to scope things would lead to less-DRY code (since you can't use styles scoped under an ID for other things).

            It seems like this really did confuse you. Perhaps checking out the writeup I linked at the end would help? It turns out that for any page, there are a number of styles that are not reused (unique), alongside re-used styles. The IDs wrangle these unique styles and scope them tightly. Reused styles are outside of this realm as "globals", which should be carefully crafted and used.

            Some people have said to me they like to write every single part of the site as if it should be able to be re-used, even though it isn't at the time of them writing it. This is just a straight up waste of time. YAGNI, KISS, and premature optimization are a couple terms that apply to this sort of methodology. If that's your view on it, that's fine, difference of opinion and we can go on our ways. If you are on the YAGNI train but not convinced of my way of doing things, maybe I can help clear some things up if you ask!

            0 points
            • Clark WimberlyClark Wimberly, over 6 years ago

              From your first post:

              "Just making everything reusable is a cop-out"

              From your second post:

              "Some people have said to me they like to write every single part of the site as if it should be able to be re-used, even though it isn't at the time of them writing it. This is just a straight up waste of time. "

              Those two statements are polar opposites. Is writing extensible code a waste of time or a cop out? It can't really be both, can it?

              0 points
              • Jeff EscalanteJeff Escalante, over 6 years ago

                What I mean by both of these is that it is (in my opinion) the incorrect approach. Again, you can google YAGNI to see lengthy explanations of why I think this way. "Cop out" was the wrong term to use in the first statement, apologies, "waste of time" is more accurate.

                That being said, I have a personal rule that once an argument has come down to grammar nitpicks, personal insults, or statements devoid of all logic, I will stop participating. That is certainly the case now for this discussion, so this will be my last post.

                1 point
    • Zack BoehmZack Boehm, over 6 years ago

      Android Browser 4.4+ and Chrome for Android 36+ both support calc()

      0 points
      • Clark WimberlyClark Wimberly, over 6 years ago

        Spoiler: waaaaay too many Android phones aren't on 4.4 yet. Hell, even the new(ish) phone I use is running 4.3.

        Yeah, I'm a nerd and of course I'm running Chrome, but you def won't find that with a more "general" user.

        1 point
        • Zack BoehmZack Boehm, over 6 years ago

          I'm not entirely sure Android Browser version directly coorelates to Android version. Nevertheless, it should be better from here on out with Chrome on the Play Store and being included with new devices.

          The parent comment made it seem that it wasn't supported in any available Android browsers as of yet.

          0 points
          • Clark WimberlyClark Wimberly, over 6 years ago

            As far as I know, when you see "Android Browser 4.2" it means the browser that shipped with Android 4.2. I don't think there are any Android 4.2 phones running Browser 4.4, if that's what mean.

            Extra bummer: lots of phones that ship with Chrome also include the "Browser" or "Internet" as the main, home-screen option.

            An average user would never really know the difference.

            But heccck yeah, so glad to see Chrome shipping pre-installed on some devices.

            1 point
  • Clay MacTavishClay MacTavish, over 6 years ago

    The “classic” box model was broken and insanely frustrating.

    3 points
  • Jim SilvermanJim Silverman, over 6 years ago

    agreed. these are really just personal preferences.

    1 point
  • Andy MerskinAndy Merskin, over 6 years ago

    Well I don't know... maybe borders shouldn't break entire layouts because they added 2+ pixels to the width of an element when borders are most often used as a visual property, rather than something to affect how an element sits within the layout.

    Nothing more frustrating than setting left/right borders on elements within a grid system that relies on floats only to have them break to the next line for no reason at all.

    Of course you could set border-box on those select few elements, but meh, I haven't run into any problems using Bourbon Neat, which also sets border-box on all elements.

    0 points
  • Christopher MoodyChristopher Moody, over 6 years ago

    I agree with the basic premise, of common ≠ best, but the way this is presented is a little awkward.

    As far as I could tell there were no examples of where a "best practice" broke down in a specific situation, or where ignoring a specific rule (something like no id maybe?) aided in CSS development.

    I would have much rather seen an overview of how a developer ran up against a wall where best practices were detrimental, and worked around it to write new, specific best practices for the project.

    0 points