Popular posts

I swear it's like an echo every single week...

Pier, there are several things that make me laugh in your post, though they are troubling too.

In case you were unaware the code I'm poking fun of came from this demo right off bootcrap's website:

getbootstrap.com/docs/4.0/examples/pricing

(which doesn't seem to even load its CSS in Firefox now?)

JS you had to write

Bwhahaha... there is NO legitimate reason for that page -- given what it does -- to even HAVE JavaScript on it.

how many hours

Hours... for that. REALLY? The base semantic markup (basically everything except div and span) shouldn't even take a competent HTML coder more than two huffing minutes given the general LACK of content. Content dictates markup, content + markup + device capabilities dictates layout. "What the content IS" should damned near write the HTML for you.

You slap in the DIV, create the desktop layout -- that's maybe three to five minutes if you design elastic and semi-fluid.

Of course their original is NOT elastic since it's derping all the media queries and widths in PIXELS despite using REM all over the place, which is why it's a borked broken jumble of crap for anyone not running that perfect 16px default -- like myself with my laptop and workstation set to 8514/20px/120dpi/125%/pickANameNotYourNose, or media center set to 24px. You know, the entire REASON the WCAG says to use EM in the first bloody place?

Then it's the lather rinse repeat of shrink the window, determine the breakpoint, add a media query to correct. That's the most time intensive but even so for a layout this simple you blow more than five minutes on that, you don't know enough HTML or CSS to be making websites.

cutcodedown.com/demos/nocrap/pricing

My rewrite of that same page, except fixing the broken mix of REM with PX by just using EM across the board... fixing the illegible colour contrasts due to low font-weights conflicting with cleartype, and adjusting the small screen responsive versions to use up a bit more screen space.

... and of course moving as much as possible out of the markup and into the CSS results in better use of caching should said site go to multiple pages or have multiple visits from the same user.

Total elapsed coding time: around 10 minutes, and that's with me having my Lucky Charms for breakfast at the same huffing time. How long it took for their original? No clue, but given the OUTRIGHT INEPTITUDE of the original markup?

Their original: 6.15k of HTML, 400 bytes custom CSS, 9.12k minified bootcrap

My rewrite: 2.66k of HTML, 5.5k of CSS, though 910 bytes of the CSS is my stock reset and initialization.

So if we omit the framework from theirs and the reset/init from mine, they 'wrote' 6.54k of code to my 7.28k, sounds like mine loses, right?

But unlike theirs I didn't have to resort to !important, mine actually works for non-standard font-metric users, mine actually has semantic markup with logical heading orders so people on braillle readers and screen readers aren't handed gibberish. Mine bothers actually meeting at least a FEW WCAG minimums instead of telling users with accessibility needs to go f themselves. It uses the media attribute so I'm not derping screen layout to non-screen devices (and the W3C can go f* themselves over the dropping of projection and tv, plenty of devices in circulation still 'need' those)*, my flavor of viewport meta doesn't screw over my phone or tablet like thier "shrink-to-fit" inclusion does, and reports properly when rotated since I added device-height. Mine doesn't resort to RGBA in places where it can slow rendering drastically like on heading backgrounds. Mine doesn't have the clipping border bug.

... and I didn't have to learn something extra ON TOP of HTML and CSS to do it, nor did I have some dumbass framework PREVENTING me from learning that either. Nor did I crap all over the HTML with annoyingly cryptic presentational classes that just scream "Go back to HTML 3.2 without CSS if you want to write HTML that way!"

See such mind-numbing idiocy as:

class="pt-4 my-md-5 pt-md-5 border-top"

My way is cleaner, simpler, no specificity hell, and I'd be shocked it to took more time to do. It's also going to be WAY easier to customize since you won't end up crapping even MORE classes into it or constantly butting heads with all the dumbass !important and bizzaroland specificity.

HOURS... pfft. REALLY?!?

Admittedly it still needs some better legacy browsers support and the dumbass 'prefixes' for Safari and IE10, but as a drive-by rewrite to fix the most obvious issues it's pretty solid... and it's not like bootcrap 4 supports 10/earlier anyways since they went prefix-less flex.

IF YOU KNOW THE FIRST DAMNED THING ABOUT HTML, you'd know that EVERY line of their original is outright gibberish from a semantics and structural standpoint be it using 4 Strict or 5 Lip-service rules! JUST like every other one of their examples that clearly illustrate the people MAKING bootcrap aren't even qualified to write a single line of HTML!

JUST like bootcrap 4 itself should make you recoil in HORROR... seriously when you see several HUNDRED sections like this:

.mr-md-4,.mx-md-4{margin-right:1.5rem!important}

Yeah... about that. Love the use of REM too given how broken they are (ignoring the browser and OS metrics) in Firefox, defeating the point of elastic design. NOT ready for prime-time use. The WCAG says to use EM, so use 'em! If you're changing the font size so much that you can't keep track of EM, you're changing the font size too damned much!

Wow you must be fun at parties.

And, you are completely missing the point.

Take care.

I don't see many targets in your example suitable for global CSS selectors. How do you recommend applying consistent styles across hundreds of pages?

David Foote leverage your semantics and child selectors!

Use the semantics and selectors FIRST. Only add classes when an element would receive DIFFERENT style from its siblings, or in the case of semantically neutral containers like DIV and SPAN only when they'd have other like tags inside themselves. If there are no like tags inside them and their siblings all get the same style, NONE of them warrant classes!

If you are using proper semantic markup, with DIV and classes/ID's to specify section types (again saying that things are, not what you want them to look like) then you should be able to have consistent styling across the entire site with all but a few exceptions needing specific styling.

Said styling being based on WHAT it is, instead of classes to say what you want it to look like.

An example I'm always using is ignorant rubbish like this:

<div id="mainMenu">
    <ul class="menuUl">
        <li class="menuLi">
            <a href="#" class="menuA">
                Some Text
            </a>
        </li>
        <li class="menuLi">
            <a href="#" class="menuA">
                Some Text
            </a>
        </li>
    </ul>
</div>

99% of the time that's a DIV for NOTHING that couldn't be applied to the UL,. and NONE of those classes are necessary. In the vast majority of cases there is NO reason for that to be more than:

<ul id="mainMenu">
    <li><a href="#">Some Text</a></li>
    <li><a href="#">Some Text</a></li>
</ul>

Since "#mainMenu" is the UL, and if you want the LI inside it you just "#mainMenu li", for the anchors it's "#mainMenu a" -- or if you are worried about nesting you can now use child selectors for "#mainMenu > li" and "#mainMenu > li a".

There is this MYTH being derped around right now (amazingly by once useful tools like ySlow and pagespeed) that slopping classes onto everything resulting in more markup and more selector rules somehow magically makes rendering "faster". To be frank when a 386/40 could handle tables for layout, that's ignorant bullshit in the face of writing more HTML than you actually need in an age of even handhelds coming in at ghz clockspeeds.

Kind of like the MYTH of putting CSS into a dumbass STYLE tag magically being "faster" or "better for caching" even when you are already going to have an external stylesheet. It isn't since if it's in the markup it's not cached across page-loads!

If your HTML is properly doing it's job of saying what things ARE, and not what you want them to look like, your stylesheetS (yes, plural) can customize that meaning to the desired appearance in a consistent manner.

CONTENT dictates markup, Content + markup + device capabilities dictates layout and design, NOT the other way around as the artists under the delusion they are designers would have you think.

That's ENTIRELY the POINT of HTML and why it was created, and why CSS was created the same time as garbage presentational tags and attributes like FONT, CENTER, ALIGN, BGCOLOR, SIZE and so forth were axed two decades ago.

... and if you're not thinking in those terms, you might as well -- as I keep saying -- going back to HTML 3.2 with tables for layout, presentational markup, and pretend the past 20 years of progress doesn't even exist.

Aka what idiocy like Bootcrap dupes nubes and rubes alike into doing; the bleeding edge of 1995 to 1997 methodology that HTML 4 Strict and CSS were created to stamp out of existence! But no, instead people crap classes all over their semantic tags (if they even have any or use them properly) to recreate the very methodology we were told to stop doing for a reason!!!

Kind of like the mental midgetry people did of using JavaScript to recreate target="_blank" behavior because it was deprecated, completely ignoring WHY it was deprecated!!! "target' being in HTML 5 just being more proof to me that the WCAG wasn't qualified to make 4 Strict's successor either...

Thanks Jason, I appreciate your mastery of the technologies we are discussing.

I ran across Jeremy Clarkes "Dry CSS" presentation: slideshare.net/jeremyclarke/dry-css-a-dontrepeaty…

If I understand your advice correctly, his approach would be a good choice for maintaining separation of content and style.

David Foote it would if it weren't for his use of presentational classes, COMPLETELY DEFEATING THE POINT of separation of presentation from content.

Since if you use half-witted dumbass classes like ".light-white-background" you have -- as I keep saying -- so completely missed the point of why CSS exists and what 4 Strict/semantics were trying to make us do, you might as well go back to not using CSS and using outdated outmoded attributes like BGCOLOR. That's OOCSS style bullshit -- and there are few things in HTML/CSS that are as outright mentally enfeebled as OOCSS. You want to talk about COMPLETELY missing the entire POINT of HTML and CSS, look no further than the pea-brained insipid vacuous train wreck of infacility that is OOCSS.

Your classes should say what things are or WHY they are receiving style, NOT what that style is... otherwise you're not separating a damned thing!

The reason for this is simple:

1) One of the entire reasons for CSS is to be able to run multiple skins off one markup. It doesn't make a lot of sense to have a class called "w3-red" if the text isn't red in all skins.

2) that style may not apply to all your different media targets. "red" or "light-white-background" is probably just going to waste ink or piss off people printing... It's certainly complete gibberish and a waste of bandwidth for non "screen media" targets.

Part of why if you don't have a MEDIA attribute on your stylesheet LINK tags, or use media="all" you've ALSO completely missed a significant part of the how/what/why of CSS. As point of fact, I use the lack of that attribute or sending to "all" as a indicator that the developer in question isn't qualified to write HTML or CSS.

3) You end up nesting together endless pointless classes on single objects -- one of by biggest complaints about front-end frameworks. This not only results in bloated markup, it ALSO means you're failing to leverage caching properly.

Same as how using the STYLE tag is stupid and it should be removed from HTML entirely. An external stylesheet can be cached across pages that share the same layout and style... or even if the same page is simply visited again. ANYONE telling you that using the STYLE tag is going to help your page load or render faster is talking out there arse. EVEN if it's Google PageSpeed saying it! That crap doesn't belong in your HTML.

HTML is for saying what things ARE; Grammatically, structurally, semantically... NOT WHAT THEY LOOK LIKE!

That attitude should extend to your classes and ID's as much as possible. That's why you shouldn't use the STYLE tag, and where possible you should avoid the style="" attribute since it too involves putting appearance instead of meaning in the markup. The only time I "allow" style="" into my HTML is when that style helps convey meaning -- a RARE corner-case such as for tag clouds or HTML+CSS bar graphs where things like width, height, or font-size is part of the content.

But yes, MUCH of the approach is sound -- before it was called DRY it was called "nesting selectors" and was just part of how we USED to use CSS before developers went full Pakled.

You never go full Pakled.

If you have multiple CSS targets that share values, you nest their selectors. That's nothing fancy warranting some fancy name, that's just common sense use of CSS.

It's also part of why garbage like SCSS "mixins" are a waste of time. We can already do that if you know how!

I had the same initial reaction, but then I realized that he was only using the presentational id and class to group the selectors against corresponding properties. His method would never include attaching the 'group-named' id or class against a target element.