Search posts, tags, users, and pages
The changes to CSS that make it even more viable to separate presentation from the content. In particular the CSS "grid layout module" (horrible inaccurate name, great tech) with its ability to re-arrange an entire layout REGARDLESS of source order means you can maintain proper semantics and logical document order for non-visual users, without being in conflict with your screen media layout.
On top of how for proper elastic semi-fluid layout we're no longer limited by floats and negative margin tricks, or even goofier tricks such as those pulled by frameworks.
grid-template-areas is probably the most powerful technique to come along, and frankly it's the type of thing that probably should have been a part of CSS from the start.
It has also been extremely encouraging how quickly browser adoption was. It's interesting to see a technology created by Microsoft actually get adopted without significant heel dragging -- even if the final version deployed in all major current browsers is relatively incompatible with the draft specification found in Internet Explorer. Even Edge who you'd expect to be late to the party were up and running mere months after RoW. More telling is how Safari had it the same time as Blink -- fascinating given how on so many other fronts Safari has been aging like milk ever since Google forked off Blink from Webkit, and absconded with all the real talent at the same time.
I would say it's shocking how quickly once it was decided to be done how all four major browser engines (EdgeHTML, Gecko, Blink, and Webkit) all got support in place inside of a year -- to be frank we've NEVER seen that before. You compare to flex, where we STILL have major significant rendering differences across browser engines -- or how many major browsers still struggle to even reach HTML 4 compliance -- and it indicates that moving forward we may FINALLY be getting a mechanism in place for genuine improvements in the various specifications to be real-world deployable in a year or two, instead of a decade or two!
Particularly encouraging is it also shows a lack of partisanship on the part of browser makers and the W3C... unlike the constant belittling of features introduced by M$ that they spent a decade and a half dragging their feet on -- webfonts, word-wrap:break-word, and all the other fancy CSS3 stuff that were introduced in IE5 a decade before anyone was even talking about there BEING a third release of CSS -- a feature they introduced as proprietary, was suggested as a draft, and hit a final release that all browsers adopted spanned a relatively short five years. That from the 'final' version of the spec dropping to full-on browser support in three of the four engines was under six months? MIND-BLOWING given the history of browsers fully and properly implementing new features.
So it's not just the new tech I find exciting, but the change in attitude and speed-up of adoption cycles.
Particularly as these types of changes make it easier to build proper semantics and to then style / augment it in a manner that makes so many older techniques and much of the alleged "improvements" of frameworks look outright decrepit by comparison.
I mean, if we're going to try to find / create better ways of doing things, MAYBE we could do it by improving the specifications, having it native to the browser, and without pissing on the intent of HTML and 'requirements' like accessibility from orbit?
That said techniques are also easier to allow to gracefully degrade for older browser users (oh noes, someone still using IE doesn't get my columns and full-height layout, notz thatsies!) is the icing on the cake, and was one of the reasons CSS was even created in the first place.
Though much like the enhancing of caching models, focus on semantics in the markup, and separation of presentation from content, the graceful degradation aspect does tend to go unused or ignored by the people who can see no further than the screens they are seated in front of -- aka the apologists for all the fat, bloated, slow, ineptly coded disasters like HTML/CSS frameworks.
We're getting more and more tools to speed up doing it RIGHT, which combined with the accessibility and existing speed of development when practicing semantic markup with separation of presentation from content, a lot of these "shortcuts that really aren't shortcuts" are going to be harder and harder for the ignorant and incompetent to defend.
Shame we don't have a "modern" HTML specification to match, what with a good chunk of HTML 5 setting us back twenty years.
Also as a side note, it's painfully apparent we're from two different worlds of development, isn't it? The things you listed are the type of sleazy predatory scams I'd like to see stamped out... Kind of funny how radically different our definitions of "efficient" and "hassle free" are since given the RESULT of the things you listed -- like WP and DIVI -- are the polar opposite of hassle-free if any form of accountability is involved.
Again cute for a blog for grandma, but has no real business in business.
NOT trying to start another fight over it, I just cannot relate to what you said at ALL and find it... well, either delusional or intentionally predatory.
Jason Knight , sure, we can discuss stuff as long as you keep it civil.
Maybe you and I deal with a different league of clients. Yours sound to me like a bunch of bureaucrats shelling out our tax money for the things that are mostly about legal implications. Mine are real-world, grass-roots clients who are also extremely tight with cash and want something up and running quickly. I could use all the same arguments you have been making for my clients, and they will still go with someone else who can give them what they want.
...Heck, as I wrote the above, I got a call from an existing client telling me that he decided to do it himself with Yola builder for $4/month. He is a cheap b?????d and wanted something for less than $300 for a five-page brochure site. I quoted $295 and planned to slap together something with a free Bootstrap template in 15 minutes flat, but I guess I won't even have to do that now.
See, my question to you is, how are you going to compete against that reality? The reality that people are cheap, they want what they want, and they don't give a rat's tail what goes on behind the surface? To them, there is absolutely no difference between a page manually coded by hand and a page put together with Divi. They won't look at HTML code or how many kilobytes each page is using. They only care that their site looks good and that they can update the site by themselves. And, they want all those features while paying less. Therefore, I need to figure out how I could remain competitive by spending as little effort as possible while charging the same or even less. Seriously, what's wrong with that?? To me, it's either this or those clients will flip a bird on my face. I play smart, and there will be a stash of cash to grab. It's not about the utopian tech ideology. It's about surviving and getting paid in a hardboiled wild west of web development.
And that's why I think it's been great to see all kinds of visual builder tools showing up for developers, such as Divi. Divi revolutionized the way I handle WordPress projects. I did learn how to put together a custom theme from scratch using codes like "get_footer();" "wp_footer();" etc. etc. but why do that when I could just slap Divi theme at the problem and brute-force it? Responsive layouts and CSS animation are friggin' hard and tedious if you try to hand-code all that stuff in a code editor. I recently looked into CSS Grid, but it was so friggin' hard to wrap my head around it. I was immediately on my mission to hunt down a visual tool to deal with CSS Grid and viola! There are at least several:
cssgrid.cc/css-grid-builder.html
zurb.com/playground/css-grid-builder
This, my friend, is what excites me the most about today's landscape; More visual tools for coding problems! If you don't think those CSS Grid tools are incredibly useful, I don't know what is. I can leverage these tools to do everything with less time and effort while maximizing the value for my clients.
Responsive layouts and CSS animation are friggin' hard and tedious if you try to hand-code all that stuff in a code editor.
And that right there is the part I don't understand, and it guts most of the points you make. I don't find them any harder, tedious, or so forth compared to the alterantives -- if anything those alternatives are what's harder to work with, slower to develop, and end up being more work all-around.
BEFORE you even talk about all the shortcomings those systems have on things that do actually matter -- like usability, sustainability, maintainability, and economy.
... and it's why when you say this:
I quoted $295 and planned to slap together something with a free Bootstrap template in 15 minutes flat, but I guess I won't even have to do that now.
I'm staring at that dollar amount bug-eyed since IMHO 30 bucks would be overcharging given the RESULT something like bootcrap tends to vomit up.
That's why I do -- and I admit this -- belittle the knowledge and skills of those who use bootstrap by choice, and would consider charging that much for something built with it to be highway robbery. The only reasonable explanation I can find for how one could consider what those systems do having any sort of merit is a complete lack of understanding of what HTML is, what it is for, and how to use it.
Which is why when you say this:
I recently looked into CSS Grid, but it was so friggin' hard to wrap my head around it
I'm genuinely flabbergasted -- BUT, I suspect that might be that you've had your head so polluted by the sleazy shortcuts you can't see it, or just how broken the methodologies you've been using are.
I'm not putting the blame for that on you, I'm putting the blame on broken tutorials, and the card-stacked propaganda these sleazy shortcuts dupe people with.
You asked a very good question:
how are you going to compete against that reality? The reality that people are cheap, they want what they want, and they don't give a rat's tail what goes on behind the surface?
I don't, well... I kind of do. I let the fools take their sleazy shortcuts, fall flat on their face, and wait for them to come hat-in -hand asking for their broken train wreck to be fixed.
Or watch them plow themselves into ground in under a year, like most startups, and end up happy I didn't sully my name by association. Even better having not wasted my time on a client who doesn't care about their own business; has unrealistic financial expectations; and therein likely has unrealistic wants that flat out isn't worth the headache!
But that's a semi-recent change for me. About eight years ago I reached the point and realization that there are clients that no amount of money makes it worth the pain or time required to deal with. I've actually made more money since I started saying NO.
... and quite often they do come back -- I don't want to say groveling on their knees, but... -- asking for help when they realize just how badly they've screwed themselves.
Hence when I'm called into these 'public' sites that are required to meet laws -- like the US ADA, UK EQA, etc, etc... -- they are universally screwed over by the techniques you are advocating and the various issues that are not readily apparent to a normal sighted user sitting at a desktop/laptop.
Like when mobile goes bits-up face-down; like when the sites rank poorly in search from a lack of semantics or logical document structure; when that same lack of proper HTML basically tells non-sighted users to golf foxtrot yankee.
... aka all the things you seem to be dismissive of.
IMHO, that is a good chunk of what separates fly by night get rich quick schemes with all the legitimacy of Amway, Mary Kay, Vector Knives, "make money fast in real estate", and late night informercials, and actually doing a professional job.
When someone hire's a professional it's because they don't know, and expect the pro to know enough NOT to screw them over. Using these sleazy broken bloated shortcuts tends to screw everyone over for readily apparent reasons if you know the first thing about websites BEYOND -- again -- "but it looks ok on my screen".
That's not... how did you put it?
bureaucrats shelling out our tax money for the things that are mostly about legal implications
It's about reaching as many users as possible, something the systems you are advocating fall so short of, they end up asking Peter Dinklage "How's the weather up there?"
It's about lowering hosting costs when talking millions of visits a day. It's about making servers have to work less hard by leveraging caching models.
... and most importanty, it's just about delivering content to users.
A subject in which the entire notion of shoe-horning content into an off the shelf layout it wasn't designed for is an utterly back-assward appraoch to development.
When I'm working with a new client who has nothing, the first thing we go over isn't colours, or laoyut, or showing off shiny flashy templates in an attempt to sucker them with bling. We talk about their CONTENT. What are they doing? What's the product? What's the message? What should it say?
I then work from that point using the progressive enhancement approach. Queue the broken record.
1) Start out with the content or a reasonable facsimile of future content in a flat text editor, organizing it to meet professional writing norms as if HTML doesn't even exist.
which unless you're at the same time writing the content from scratch shouldn't take more than five minutes.
2) Mark up that content SEMANTICALLY -- saying what things ARE and not what you want them to look like. I do so using the 4 strict / professional writing norms and not the bloated crap HTML 5 pissed on things with.
This means H1 is THE heading that everything on every page of the website is a subsection of. IF the client "requires" using the HTML 5 section tag, you restart at H1 each time you open a new section.. An H2 is the start of a major subsection of the page, with the first H2 being the start of the main content (which is why MAIN and NAV are pointless redundancies). H3 is the start of a subsection of the H2 before it. H4 is the start of a subsection of the H3 before it, and so forth. Even HR means a change in section/topic where heading text is unwanted and unwarranted. P is for grammatical paragraphs not "I want line breaks after this". Even B and I have the semantic meaning of "WOULD be bold or italic for grammatical reasons, such as a entity in a legal document for bold, or a book title not being CITEd or recieving EMphasis.". It means tables for tabular data, UL and OL for short bullet point lists or selections. As in a grammatical bullet point, not hurr-durrs its haz teh dot befur it.
Said semantics is important for screen readers, braille readers, search engines, and all sorts of other non-visual UA's. The heading orders provide alternative navigation -- the same type HTML 5's pointless ARTICLE, NAV, SECTION, HEADER, FOOTER, and MAIN were SUPPOSED to add to the specification that not one single legitimate user-agent does a thing with. That alternative navigation helping search (which is why headings get an uprank) and users on things like mouth-sticks and puffer-sticks. Don't know how many paraplegics you know... you may never have even seen or heard of said devices.
It also provides a layer of future-proofing since that semantics can be leveraged for media targets and user-agents we've never even conceived of yet!
That's the accessibility layer of device neutrality that is the ENTIRE reason HTML was created by TBL in the first place!
... and since we're talking about the semantic stage, semantically neutral tags such as DIV and SPAN have ZERO business being added at this point, nor should any classes be declared. Also beware that whilst Anchor introduces the behavior of being a hyperlink, it too is semantically neutral appying ZERO meaning to what it wraps. This is why people who just slap anchors into NAV are know-nothing fools who need to read the bloody spec!
Some ID's may be applied such as when desired for internal linking via hashes, or as required by semantics for association such as with the FOR and HEADERS attributes.
3) Then you create the first of your layoutS (yes, PLURAL). I usually start with my desktop media layout becuase we can't target legacy desktop with media queries. There are those who say to do "mobile first" but that's utterly backwards since any mobile we care about CAN use media queries. It's more sensible -- dare I use the word easier? -- to develop for what you can't target first, then use targeting to change it than to try and... well... not target what's targeted?
This is where you can add DIV, SPAN and classes, but only do so AS NEEDED... and as Carlin joked about "not every ejaculation needs a name" not every blasted element needs a DIV around it or a class on it! Selectors, LEVERAGE THEM.
Said layout done properly should be elastic -- designed in EM's so it dynamically scales to user preferences -- and
This is where most of the time should be invested -- 15 minutes on the shy end, much more if you want to do anything particularly unique. This time investment should be no more than you'd have using frameworks, WYSIWYGS, or any other such nonsense.
4) Then create your media queries to make it mobile friendly. Since it's elastic you shrink the window, figure out where it breaks, conver it to EM and there's your max-width. Lather, rinse, repeat -- usually ends up one or two k of code, 4k at max.
Another five minutes in most situations.
5) Then if desired enhance the ALREADY WORKING PAGE with JavaScript, keeping in mind that JS only functionality is a violation so avoid going there unless there's no other way. ENHANCE, don't supplant.
6) then you go back to the style phase (step 3) to repeat for other media targets such as print or speech as desired. As you should have practiced separation of presentation from content you can have different style and layout for all the different device types. It also means you can write multiple skins and layouts the user can choose between off of ONE static unified markup without ever having to edit a single line of HTML moving forward.
Hence why I use terms like "shortsighted", "mentally enfeebled", and so forth when I see classes like "text-center", "box-shadow", "w3-red", or "xm-s-12". You might as well go back to writing the disastrous HTML 3.2 at that point!
To this point if you've spent any more time than you would have with the allegedly "easier" shortcuts, you haven't learned enough HTML, CSS, or JavaScript to be working as or calling oneself a professional.
It's called progressive enhancement, and it is how you create layouts that "gracefully degrade" -- aka should fancier technologies like CSS, images, media,
Which is why CSS is separate from HTML, why LINK has a MEDIA="" attribute, and why putting anything in the HTML that says what you want it to look like is incompetent NONSENSE. Why screwing around in photoshop drawing pretty pictures IS NOT DESIGN.
All things you're not going to get with some visual editor or frameworks that inherently rely on classes that have presentational names.
... and again 15 to 30 minutes being the ideal for most layouts.
The problem is that what you make with those shortcuts might LOOK on the surface the same -- but it's like slapping aluminum siding on a MiG-21 and calling it a modern stealth plane. If it even gets off the ground it's going to auger-in the moment it tries to turn and burn.
That ILLUSION of being good only runs skin deep, hiding an ugly that runs right to the bone... and the first person to come along and run their finger across the top to look for dust or scratch at it with their fingernail is not going to be impressed.
Much less that the results DO tell a lot of potential users to go f..k off. Me, I never considered telling the target audience of websites to f..k off to be a very sound business strategy... and if that means I have to tell potential site owners with unrealistic time, financial, or other expectations to sod off... well, that's the price of business. That again has saved me time, effort, and headaches that aren't worth the pennies on the dime said fools expect.
If nothing else it helps me separate the wheat from the chaff. You can't waste your time trying to help people willingly and intentionally shooting themselves in the foot for being a cheapskate. MORE so when being willfully obtuse in their ignorance.
... and catering to that crowd encouraging their ignorance is just flat out sleazy, predatory, and dishonest -- and a significant part of what's been going wrong in web development the past ten years, dragging things back to the worst of the pre-dotcom bubble burst skulduggery.
It's the same two-faced lies that created that bubble -- makes sense since the development practices reek of that same pre-4 Strict mentality that gave us the disaster that was HTML 3.2 and the equally idiotic 4 Tranny
Which is why right now we're perched atop yet another financial house of cards far, FAR overdue for another collapse. I think the only reason we haven't see a proper burst yet is people woke up to "advertising can pay for everything" and "multi-level marketing" being 100% scam artist BULLSHIT (well, unless you own a advertising service or are at the top of the pyramid -- certainly profitable FOR the scammers) before they got enough traction to do any lasting damage.
Now if we could just do something about this cryptocurrency trash.
Bottom line, to me what you describe is the equivalent of opening a business on main street with no wheelchair access, no fire alarms, sprinklers, or extinguishers, no braille on any vending machines or on the restroom signs, doors that open inwards only, 1930's cloth covered wiring with nothing but two-prong electrical sockets, and no fuses or circuit breaker.... but it looks nice and was easy to build.
The only difference being no building inspector, fire marshal, or ambulance chasing ADA lawyers yelling "hey stupid" and shuttering your doors.
Though you wait, do a website for the wrong industry and that last one will rear its ugly mug. You ever deal with clients facing $30K a day fines because their site was built with pixel fonts, illegible colour contrasts, and is unnavigable on a braille reader?
It's not just about "meeting legal requirements" -- those requirements exist for a REASON. That reason being if your running a business you don't tell the handicapped to perform anatomically impossible acts upon themselves.
Aka stuff that things like the HTML and CSS specifications and guidelines like the WCAG exist to ensure you don't do and never have to worry about... as opposed to shrugging and going "What?!? Me Worry?"
I'm staring at that dollar amount bug-eyed since IMHO 30 bucks would be overcharging given the RESULT something like bootcrap tends to vomit up.
$295 is supposed to cover the potential extra hours I need to spend dealing with fussy and picky customers who would request for gazillions of changes after I finish coding. $30!? That won't even cover my regular hourly wage.
That's why I do -- and I admit this -- belittle the knowledge and skills of those who use bootstrap by choice, and would consider charging that much for something built with it to be highway robbery.
And how is that not tech elitism and bullying? You think you are better than me because I use Bootstrap and you don't. That's elitism right there.
I'm genuinely flabbergasted -- BUT, I suspect that might be that you've had your head so polluted by the sleazy shortcuts you can't see it, or just how broken the methodologies you've been using are.
No, CSS Grid is just weird without some framework that already solved the problem for us. Just as an example, I tried to recreate the "holy grail layout" a while ago because I kept hearing how great CSS Grid was. I started by copying and pasting some codes and spent hours trying to figure this out, to no avail. Here is a copy of the code I dealt with:
1) HTML
<div class="container">
<div class="row">
<div class="maincontentarea">
<div class="maincontentarea__header">
(header)
</div>
<div class="maincontentarea__jumbotron">
(jumbotron)
</div>
<div class="maincontentarea__sidebar">
(sidebar)
</div>
<div class="maincontentarea__main">
(contents)
</div>
<div class="maincontentarea__footer">
(footer)
</div>
</div>
</div>
</div>
2) CSS
.container {
display: grid;
grid-template-column: 125px 125px 355px 355px;
grid-template-row: 80px 200px 400px 80px;
grid-gap: 15px 15px;
max-width: 960px;
margin: auto;
}
.row {
padding: 15px;
}
.maincontentarea {
margin: -30px;
}
.maincontentarea__header {
background-color: #ff8282;
grid-area: 0 / 0 / 1 / 2;
}
.maincontentarea__jumbotron {
background-color: #fcca41;
grid-area: 1 / 0 / 2 / 2;
}
.maincontentarea__sidebar {
background-color: #c4fc2a;
grid-area: 2 / 0 / 3 / 1;
}
.maincontentarea__main {
background-color: #3dfa8c;
grid-area: 2 / 1 / 2 / 1;
}
.maincontentarea__footer {
background-color: #69c6fc;
grid-area: 2 / 0 / 4 / 1;
}
It's probably messed up either way since I tried just about any possible combinations of things I could imagine. The whole grid-area thing defined by numbers is confusing, and I don't know why people keep wanting to figure that out when I should be able to identify where everything is visually! Compare this to Bootstrap. All I need to know is that class="container" defines the max width, and it will be a matter of throwing in class="col-sm-4" etc. to create columns. The syntax is far easier to grasp. Fast and easy, and no need to think twice about it. And, not to mention I could use one of those Bootstrap-compatible visual editors out there.
1) Start out with the content
Hold on right there. It's an interesting process, but I can tell you it's not going to fly with my clients because, when they say, "We want a website," they are talking about, well, something that looks like a website. My process is this:
1) Start with picking the pre-made template that looks the closest to client's requests.
2) Rewrite all existing demo contents and images with the real one.
3) Override the template CSS (bootstrap and template-specific ones) with "custom.css" and customize it to the core.
4) Launch!
I find it far easier than writing from scratch because I only need to be able to read CSS and know what it is. Just modify a few parameters and ba-baam! It's done.
I have to say that your process is an intersting approach, though. So, you start with contents and then figure out how the site should look like? Let me ask you this; What do you tell your clients when they ask for the visual first? They've got to worry about branding and marketing color theme. And you can finish all that stuff in just half an hour by using only a code editor? I'm sorry, but I am suspicious. My process is pretty darn simple, yet it usually takes 10 ~ 15 hours of fiddling with the template to get everything right (usually a top page and a few sub-page variations), and even then, additional requests come in, and that could add a few more hours of fiddling time. There is no way your fascinating and detailed process takes only half an hour to complete!
Dan W. I'm going out of order here as my answers make more sense this way.
What do you tell your clients when they ask for the visual first?
I start out by explaining that websites are about MORE than what it looks like, explaining that content is king and that when talking content on the web TEXT is the first class citizen. That their product/message is the most important part and that any visuals should be dictated by those. I explain that a fancy flashy appearance can often work against them by making it harder to get to that content, alienating potential users.
Again there's MORE to a website than what it looks like for perfectly sighted users sitting in front of screens, and part of your job as a professional is to explain that and address those things -- something you are NOT going to be doing by using a framework.
CONTENT should dictate markup, CONTENT + markup + device/user capabilities should dictate layout.
Starting out with some pretty picture and then shoe-horning the site owner's content into it is utterly and completely back-assward. It's why WYSIWYG's are a scam, it's why frameworks are a sham, and it's why all those sleazy "shortcuts" many claim are "easier" simply do not get the actual job done in a professional manner!
Which is why when you call that... well...
And how is that not tech elitism and bullying? You think you are better than me because I use Bootstrap and you don't. That's elitism right there.
It's not elitism, it's inclusionary for what really matters, VISITORS TO THE WEBSITE. As I keep saying the methods you advocate tell a lot of users to go f..k themselves. It doesn't matter how pretty the result is or how much you convince yourself that it's somehow "easier" if you're telling users on restricted/limited connections, users with accessibility needs, users in locked down workplaces, the poor, people in rural areas who are unlikely to see infrastructure changes for a decade or more, users on specific user agents, and every other "easily dismissed" group where to stick it!
... and you are NOT doing a professional job if you're not even bothering to actually meet the specifications and guidelines on which our entire industry is based!
That's not being elitist, that's giving a damn about the client and their users instead of trying for a sleazy dishonest fly-by-night cash grab.
That won't even cover my regular hourly wage.
Which is why clients unwilling to open the purse for a job done right aren't worth having as clients -- and I don't care how long YOU put into it, the RESULT isn't worth spit given the methodologies you are advocating. I'm sure you work long and hard on these, but your RESULT given the choice of technologies is -- IMHO -- a waste of your time and their money!
Your example of your attempt to use grid illustrates just how BADLY the framework approach has clouded your mind. You're using presentational classes in a manner that means you might as well go back to using HTML 3.2 with tables for layout and pretending CSS doesn't even exist. You're slopping out presentational classes before you even know what the content is, the same mentality that led to nonsense like the FONT and CENTER tags, attributes like ALIGN, BGCOLOR, BORDER, etc, etc that we spent a decade trying to get people to stop using! When I build a site I do NOT have pre-determined classes, and I use clasees and ID's when needed to say what things ARE -- semantically and grammatically when possible -- NOT what I want them to look like.
Even the classes like "row" are bad since once you go responsive it might no longer even BE a row; or on different media targets should you start customizing for print or aural/speech. "sidebar" is equally presentational when it might not even BE a sidebar in all supported layouts. Then you have "container" which is uselessly vague since it doesn't even say WHAT is being contained or WHY!
It's bad enough making classes to replicate the broken outmoded behavior and methodologies of HTML 3.2 and 4 tranny '90's style without further confusing things with.
... and as someone who uses the CSS grid module, I actually have ZERO clue what the devil you're trying to do with that code either way, I suspect you are throwing grid at elements I would NOT be even using grids on, possibly a better job for flex, inline-block, or float. I also avoid grid-area preferring to use grid-template-areas since I can then put names of what things ARE in there to create my layout.
Likewise your fixed width pixel declarations are such a middle finger to usability and accessibility with zero fluidity or elasticity that I would NEVER allow a client of mine to deploy a layout like that. The WCAG says to use EM, so use 'em!
I also have the nasty feeling that you've got two outer DIV for NOTHING there, but that depends on what you're trying to accomplish. No clue why you are using the negative margin, why you think you need that main container, and in fact those extra DIV are likely getting in the way of and/or BREAKING your attempt at building a grid layout. Yeah, once you have both .row and .maincontent in there -- NEITHER of which seems to be serving any legitimate purpose -- they break the ability of the grid on the outermost container to do a blasted thing! You want the children to obey the grid you have to set display:grid on their PARENT, not their great-grand parent!
If I were coding the same general concept it would likely end up more like this:
<div id="top">
<h1>Site Title / Logo</h1>
... and other header stuff here.
<!-- #top --></div>
<div id="callToAction">
<h2>Call To Action</h2>
What you call a "jumbotron" which is also a presentational concept, aka improper use of classes.
<!-- #callToAction --></div>
<div id="content">
<h2>Main Content area</h2>
Blah, blah, blah
<!-- #content --></div>
<div id="extras">
<h2>Extras</h2>
Stuff that would go into a sidebar on large screens, but don't call it a sidebar since that's presentational and would NOT be a 'sidebar' on many smaller screens or different devices.
<!-- #extras --></div>
<div id="footer">
<hr><!-- semantically say this is NOT part of the "extras" section! -->
Disclaimer and other footer stuff here
<!-- #footer --></div>
With the grid and padding set on BODY. Those extra DIV serviing no legitimate purpose I can fathom or decipher.
Hence the style being:
// assumes a reset is in use
html, body {
height:100%; /* enable min-height layout */
}
body {
display:grid;
box-sizing:border-box; /* so we can pad whilst still doing min-height */
min-height:100%;
max-width:60em;
margin:0 auto;
padding:1em;
grid-template-columns:auto 16em;
grid-template-rows:auto auto 1fr auto;
grid-template-areas:
'top top'
'cta cta'
'content extras'
'footer footer';
}
#top {
grid-area:top;
background:#F88;
}
#callToAction {
grid-area:cta;
background:#FC4;
}
#content {
grid-area:content;
background:#3F8;
}
#extras {
grid-area:extras;
background:#CF2;
}
#footer {
grid-area:footer;
background:#6CF;
}
Though I'm guessing WILDLY as to what you were trying to do. You seemed to have a slew of things declared for nothing, including some height declarations that shouldn't exist since the CONTENT should be dictating any heights, not fixed pixel amounts. You had four pixel values on the 'column' axis for Christmas only knows what, resulting in a FIXED WIDTH layout, a giant middle finger to usability and accessibility. "FR" exists for a reason, use it. Which of those declarations were you expecting to shrink/grow with the max-width of your outermost wrapper?
I call the first part #top so that if I want to later implement a "back to top" link I can just <a href="#top>Back to Top</a> -- the use of ID's on other major sections is done for similar reasons should the client or any end users require an accesskeys menu or any other internal linkage.
See what I mean by "DIV for nothing"? Classes for nothing? Presentational nonsense in the markup?
To make it responsive you then just narrow the window 'till it breaks, figure out how many EM that is (divide by your default system font size) and then gut out. Let's say you're CONTENT (what should be dictating your breakpoints) falls apart when #content is 24em or less, so with the sidebar being 16em and the 1em of padding that's 42em as our breakpoint, so the responsive query would be:
@media (max-width:42em) {
body {
padding:0;
grid-template-columns:auto;
grid-template-rows:auto auto auto 1fr auto;
grid-template-areas:
'top'
'cta'
'content'
'extras'
'footer';
}
}
Killing the outer padding to use more of the dwindling screen space, and switching it to a one column 100% min-height layout with #extras being the one that expands to fill the space.
Live demo here:
cutcodedown.com/for_others/danW
Though you want real fun and the true power of CSS grids I was talking about? Try this out:
grid-template-areas:
'cta cta'
'top top'
'extras content'
'footer footer';
Displaying things however you want REGARDLESS of your source order. That way you can preserve your semantics and logical document structure for non-visual UA's whilst customizing the layout however you want. INCLUDING the "content first" approach to layout since non-visual users and search work better when your content area is BEFORE any extra crap like the sidebar stuff. ANOTHER essential part of accessibility and SEO.
Things those frameworks DON'T GIVE YOU! You're missing the intent, reason, and logic on which HTML was even CREATED, meaning that you simply are not doing a professional job anyone should be paying real money for.
and you can finish all that stuff in just half an hour by using only a code editor? I'm sorry, but I am suspicious.
With good reason, you've been duped into using techniques that produce two to ten times the code needed, don't give you sufficient direct control over changes, force you to think in terms of overriding existing code instead of just doing it right from the start, and in general just leaves you spinning your wheels in the mud.
When I say half an hour, that's from the time I get content or a reasonable facsimile of future content to the time I give the client the first layout draft. Typically it's 15 to 45 minutes, an HOUR at MOST if the client's needs go above/beyond the norm or they insist on goofy animooted BS their marketers insist on even as I tell them not to go there. For a base template from scratch using the progressive enhancement approach that's an entirely reasonable amount of time.
Naturally as the client jerks us around on changes that timeframe goes up, but from content to base layout? I've not spent more than an hour on that in the decade and a half since I abandoned the presentational 1990's style methodology for semantic markup, separation of presentation from content, logical document structure, and progressive enhancement.
... and yes, sometimes I have to pull that "reasonable facsimile" out of my backside just because the client falls short on having any idea what they want on the site to begin with; but in those cases you are often better off walking away since any client that doesn't even know WHAT they want the website to have for content, probably doesn't need a website and will just create more headaches for you in the long run.
Especially if contractual obligations get involved. I don't do JACK for starting to code without a signed contract in hand, notarized if it's domestic, witnessed by a independent third party if abroad. Suddenly you have accountability, rights and responsibilities, and a slew of other things meaning that if you get caught omitting those things the "screwing around with frameworks and what it looks like FIRST" approach do not provide, you're looking at being called out as an amateur PRETENDING to be a professional.
That's called "doing business with someone". As opposed to "doing the business TO someone".
Because a LOT of the things you are dismissing that those frameworks do not provide, and a LOT of the problems those frameworks introduce can and will whip around and bite clients in the backside... and when they get bit, they tend to whip around and bite you.
MORE SOif they end up wondering why their site is failing with low traffic numbers, and go looking for help from someone other than you, and gets "well it was slopped together with bootcrap any-old-way and is riddled with accessibility woes and failings that tell search engines to sod off." as the response.
Or if their content is just that damned good that the failings don't impede their growth, they can end up similarly hobbled as more people see the accessibility woes, and the heavy traffic makes them have to spend two to three times as much on hosting -- or getting SUCKERED into going to the cloud when they don't need to or wasting time on stuff like Varnish or other caching trickery that doesn't fix the REAL problem. Very quickly what should be a financial success ends up a money-pit.
Succeed or fail it still ends up being a problem. Problems that can be avoided by more robust and efficient development techniques, bothering to learn and follow specifications and guidelines, and to simply stop trying to slink by on as little effort as possible.
As I often say there's a reason it's called work, and not happy-happy fun-time.
Well, maybe you are right about this one after all. I can't deny that your example is shockingly small and yet it does exactly what I was trying to do in my CSS Grid experiment. I hate to admit it, but sure, I can see you could write all of that stuff from scratch in less than 10 minutes.
I did the negative margin thinking that it might have something to do with the test code not working. I didn't know that I could use names for template areas instead of cryptic combinations of numbers. I put the row and the container div because I was doing it inside a Bootstrap template. And I habitually use BEM for class names no matter what. I haven't fiddled with CSS Grid enough yet. I learn by fiddling with pre-made templates.
However, what if you want the Jumbotron, the top nav and the footer to be 100% width while the contents remain contained? I don't see how you could accomplish that without a container div inside a 100% width parent div.
You said I've been duped. I don't even know if I want to think that way. At least you've got to admit that CSS Grid is still in its infancy and it's not like you can use it today. You will surely be writing far more code than this if you tried to replicate the same holy grail layout without CSS Grid, won't you??
I didn't know that I could use names for template areas instead of cryptic combinations of numbers.
I hate cryptic code so... yeah. Also there are a LOT of bad tutorials right now because people seem to expect -- even WANT -- it to be as complex as flex-box... it isn't.
I put the row and the container div because I was doing it inside a Bootstrap template.
Aka something utterly incompatible with clean coding practices.
However, what if you want the Jumbotron, the top nav and the footer to be 100% width while the contents remain contained?
Then you would need to remove the width from BODY, and add one div inside each of those outer section DIV, so yes, that would grow quite a bit. Outer DIV for the min-height behaviors, inner DIV for the min-width. The content/extras (sidebar) area would need it's own grid inside the parent grid or to be built with the negative margin column trick, depending on how you want to go about it.
You said I've been duped. I don't even know if I want to think that way.
It's a VERY bitter pill to swallow -- one I myself had trouble with back 15 to 13 years ago as I moved away from thinking in terms of presentational markup to separation of presentation from content. Basically a LOT of what you say is stuff I was saying back then. I had been making websites for around five years, had heard about the advantages of 4 strict but had been mostly dismissive.
MOST people never manage to swallow that pill as if you are sighted, we're ALL visually oriented. We think in those terms FIRST and it's something of a chore to come to the realization there's more to it than that. I mean when I started making websites I had worked in marketing and advertising, print, am a physical medium artist... so I had my head filled with ideas that were utterly incompatible with accessible design. In many ways I think we all start there.
I have to admit that at that time I had been suckered by the same type of thing, basically still creating HTML 3.2 style methodology under the 4 tranny doctype, not embracing any of the improvements 4 Strict with proper use of semantics and CSS offered. It wasn't until a friend/apprentice of mine (Dan Schulz, RIP) showed me the light that I transformed from THINKING I was doing professional grade work into actually DOING it. The apprentice very quickly became the master.
A lot of the things I say are basically channeling his spirit. He was one of the most brilliant front-end dev's I ever knew, with incredible insights and an ability to see nuances that escaped most people. Much like with my friend Aaron it was crushing seeing them take their own lives at half my age.
You will surely be writing far more code than this if you tried to replicate the same holy grail layout without CSS Grid, won't you?
Not significantly. The big hangup would be the 100% min-height, which I'd be tempted to implement with either display:table or flex-box... but these days with IE's numbers FINALLY dwindling into nothing I probably wouldn't bother. I used to defend IE's share against the pool size, but now? No. Even I'm kicking support for it to the curb.
NOTE when I say I'm dropping 'support' that's not the entire picture, as I DO still support graceful degradation in it; but if the end user doesn't get 100% min-height or columns, OH FREAKING WELL. We're using a new technology that doesn't work in older browsers -- between media queries and a few other techniques it's not rocket science to make a site that drops to one column in older browsers.
Does it look perfect? No. Is it USABLE? Yes. For most clients that's where / how I draw the line, and if they "insist" on supporting IE 'identical' to the rest -- which does often happen in medical where they still have WinCE thin clients -- I up front tell them the extra effort is going to cost them more.
At least you've got to admit that CSS Grid is still in its infancy and it's not like you can use it today.
Last year (2017) over a seven month period -- from march to october -- it matured overnight. The specification is no longer in draft, no longer seeing significant changes, and ALL modern browser engines -- EdgeHTML, Webkit, Blink, and Gecko -- now support it.
IE remains the only sticking point, and again that's what graceful degradation is for. So long as the page is still usable I'm not bending over backwards to feed people on decade out of date browsers a 100% identical experience -- UNLESS the client is willing to pay for it.
But... well, you asked the question, let's try doing it. Old-school and aiming for... how about IE8 as the cut-off? We can then use display:table trickery for the 100% min-height layout, and let's implement those inner width restraints whilst at it. The markup ends up rather ugly:
<div id="top">
<div id="header"><div class="restrain">
<h1>Site Title</h1><!-- THE heading that everything on EVERY page is a subsection of -->
Menu, search, etc would be here.
<!-- .restrain, #header --></div></div>
<div id="callToAction"><div class="restrain">
<h2>Call to Action</h2>
<p>
This is the area you'd call a jumbotrong
</p>
<!-- .restrain, #callToAction --></div></div>
<div class="contentWrapper">
<div id="content">
<h2>Content Area</h2>
<p>
The main content area
</p>
<!-- #content --></div>
<div id="extras">
<h2>Extras</h2>
<p>
Stuff that would go into a sidebar on large screens, but don't call it a sidebar since that's presentational and would NOT be a 'sidebar' on many smaller screens or different devices.
</p>
<!-- #extras --></div>
<!-- .contentWrapper --></div>
<!-- #top --></div>
<div id="bottom">
<div id="footer"><div class="restrain">
<hr><!-- semantically say this is NOT part of the "extras" section! -->
Disclaimer and other footer stuff here
</div>
<!-- .restrain, #footer --></div></div>
<!-- #bottom --></div>
<div class="fauxColumns"><div></div></div>
But still entirely manageable. When I complain about "DIV for nothing" and "classes for nothing" it's typically when they're there for NOTHING. Here we're using them for something.
The CSS is certainly bigger, but nothing out of the ordinary for the time and certainly nothing that should take very long to play with given all the techniques and methods are well known.
/* assumes a reset is in use */
html, body {
height:100%; /* enable min-height layout */
}
html {
background:#DEF; /* see how we can target this too? */
}
body {
display:table;
width:100%;
min-height:100%;
margin:0 auto;
}
body, div {
box-sizing:border-box;
}
/* we shouldn't have to say #header or #callToAction here, but IE is 100% derp */
#top,
#header,
#callToAction,
#bottom {
position:relative; /* depth sort over fauxColumns */
z-index:2;
}
#top {
display:table-row;
}
#bottom {
display:table-cell;
vertical-align:bottom;
}
.restrain,
#content,
#extras {
padding:0.5em;
}
.fauxColumns div,
.restrain,
.contentWrapper {
max-width:60em;
width:100%;
margin:0 auto;
}
.fauxColumns {
position:fixed;
top:0;
left:0;
width:100%;
height:100%;
z-index:1;
}
.fauxColumns div {
position:relative;
height:100%;
}
.fauxColumns div:before,
.fauxColumns div:after {
content:"";
position:absolute;
top:0;
z-index:1;
height:999em;
}
.fauxColumns div:before {
left:0;
width:100%;
background:#3F8;
}
.fauxColumns div:after {
right:0;
width:16em;
background:#CF2;
}
#header {
background:#F88;
}
#callToAction {
background:#FC4;
}
.contentWrapper {
position:relative;
overflow:hidden;
}
#content,
#extras {
float:left;
position:relative;
z-index:2;
}
#content {
width:100%;
padding-right:16.5em;
}
#extras {
width:16em;
margin-left:-16em;
}
#footer {
background:#6CF;
}
@media (max-width:42em) {
#content, #extras {
float:none;
padding:0.5em;
width:auto;
margin:0;
}
#content {
background:#3F8;
}
#extras {
background:#CF2;
}
.fauxColumns {
display:none;
}
}
Live demo here:
cutcodedown.com/for_others/danW/legacy.html
Most of the 'bloat' is the faux-column trickery. It would need some playing with so as to degrade gracefully to IE7 (which right now goes bits-up face-down due to it not knowing box-sizing or display:table) but that's to be expected.
The modern way is a lot leaner, and you can target older browsers to have some 'tweaks' for graceful degradation. In that directory:
cutcodedown.com/for_others/danW
I placed a 'modern' version using grid and the inner wrappers, that includes fallbacks to make legacy IE show the content area and sidebar as one column over the other, with no min-height. In MOST cases right now -- again unless the client is willing to pay more -- I call that "close enough" as we just can't keep being expected to bend over backwards to support browsers a full decade behind the times -- which pretty much describes EVERY version of IE.
... and laughably, I'm providing MORE support for legacy browsers than most. Even bootstrap 4 -- as much as I rag on it -- has gone flex, telling IE10/earlier to sod off. Good for a laugh when one of the whole alleged reasons to use a framework is legacy browser support.
You CAN also do a 'trick' using generated content to keep the markup even simpler. I'm writing this during "early morning insomnia" but when I'm clear headed I'll add an example of that as well.
You stick to simple proven techniques, it really doesn't take any more time than a framework, often it's LESS time -- particularly as you become more proficient with the "vanilla" methodologies.
Oh, and yes, "restrain" or "widthWrapper" might SEEM like presentational names, but we're not saying WHAT they look like, that's just saying what they're for. There's a difference between that and putting "col-s-4" or whatever into your markup.
I guess I owe you an apology for calling you an elitist, arrogant, etc. You, sir, utterly shattered my "efficient workflow" world to pieces, left me in despair in the process. I am in shock as I see just how ridiculously small and short these files really are while still accomplishing the kind of layout common for Bootstrap templates. I can NOT deny that I could manually retype these files line by line from scratch and still takes only a fraction of time I usually spend overriding and tweaking a pre-made Bootstrap template. I'm about to lose my mind as I think of how many hours I might have wasted doing that all these years as I believed I was skipping all the manual hard work by doing it that way. For the first time in my career, I am starting to think that writing something from scratch might be FAR faster and easier when you know what you are doing. And, not only that, I really might have been duped!
The whole thing made me very painfully realize one thing; I don't know jack s^^t about HTML/CSS after all. Well, I learned Bootstrap first and foremost, picked up some bare minimum basics like margin, padding, color, etc. just random pieces and thought that was enough to get the job done. And not to mention all these people keep telling me about frameworks being mainstream, backend devs loving Bootstrap, BEM removes hassles, and so on. "display: table" "display: table-cell" Whaaattt?? I didn't even know such parameters existed.
What shocks me, even more, is that I can actually make sense out of your HTML files a lot easier than mine. I can see how you don't need a visual tool because it's so concise and clearly labeled that I could look through them, glance at the browser and know exactly where everything is. Heck, you only use one or two divs with a label telling me what it is in the browser view. And you say the legacy file is more "bloated," but what bloat?? My "custom.css" to override Bootstrap styles gets FAR longer than that by the time I manage to change everything to client's requirements.
I'm depressed thinking how many hours I might have wasted doing the way I've always done and, quite frankly, I'm super-embarrassed. I'm going back to the blank slate and learn the basics for real now. Hats off to Jason.
Sorry for the delay, got sat down in the corner wearing the dunce hat for a week.
What shocks me, even more, is that I can actually make sense out of your HTML files a lot easier than mine.
That is precisely the reaction I had when Dan Schulz -- a guy I taught to program, RIP buddy -- showed me similar code and techniques fifteen years ago when I was still basically writing HTML 3.2 with tables for layout, FONT and CENTER tags, and all those attributes and inlined STYLE attributes like everyone else was at the time. Aka techniques I found out we were supposed to stop using in 1998 but to this day people still use.
Even when they don't use the tags and attributes deprecated in HTML 4 Strict, the mindset and methodology remains of people insisting on saying in their markup what things look like, instead of what they are. The opposite of the entire point of HTML!
And you say the legacy file is more "bloated," but what bloat??
To me since I've been using flex and grid, putting all those extra DIV and classes in there feels bloated to me. It's one of the things that makes me so excited for these technologies -- far more than anything HTML 5 tried to do inside BODY -- is that it lets me gut the markup down even leaner.
I mean, check this out for crazy:
cutcodedown.com/for_others/danW/sneaky.html
View source that. It abuses italic tags inside the BODY and uses grid layout to plug them in for the coloured sides, meaning the semantic markup and semantically neutral grouping DIV remain relatively untouched.
I somewhat dislike the approach as keeping track of those empty tags is a bit vague and hard to follow, but it's a really cool/slick option. I like having options.
Well, I learned Bootstrap first and foremost,
.. and that's a good chunk of the problem of what's going on right now with these frameworks, and "site builders". People learn them first without actually learning enough of the underlying languages. As such it's very easy to think that it's easier, when you didn't take the time to verify. It handed you results, results you thought you wanted. As time passes and issues arise, you'll start to realize how fragile, incomplete, and difficult to work with those seemingly "simple" results were.
Trust me, we've all been there. When I started out 20 years ago I was slopping pages together with Nyetscape Composer because I didn't take HTML seriously as a language. It's a full language with structural rules, the tags have meanings and purposes, and it requires a great deal more respect and attention than most people give it.
Particularly if you care at all about accessibility.
And not to mention all these people keep telling me about frameworks being mainstream
The propaganda technique known as bandwagon, likely with a healthy smattering of glittering generalities, plain folks, and testimonial thrown in. One of the easiest ways to sell a lie, and we all fall for it when starting out; regardless of the topic.
backend devs loving Bootstrap
The only ones who love it are the ones who don't know enough HTML to be trying to slice it up into back-end code, or who have never once had a front-end developer hand them decent code. Not to blanket cover an entire group, but in my experience that's what it is.
How is handing them more markup, more complex markup, two to ten times the markup needed to do the job, making their job any easier? It's more code for them to try to dissect, understand, and slice up into their logic.
Compared to using presentational markup? Sure, bootstrap looks all nice and shiny; but that's basically comparing to coding techniques and methodologies that should have gone the way of the dodo back in 1997. That's the card stacking aspect of the lies they are selling. They cherry pick bad outdated code for comparison to make themselves look good. jQuery does the same thing.
I look at these things I generally don't have to cherry pick -- I can open up any example or site built with these frameworks, grab a few dozen lines at random, and point out as many broken techniques as there are line of code. This is because the frameworks themselves are based on the same outdated, outmoded -- and to be frank incompetent -- site-building techniques as the 1990's style "vanilla" code they compare themselves to.
My "custom.css" to override Bootstrap styles gets FAR longer than that by the time I manage to change everything to client's requirements.
... and that's the biggest problem with it. They're harder to customize because the framework itself you don't edit, instead you try to target things with your own specificity hacks or worse, adding your own classes to it. You end up writing as much if not more of your own CSS than you would have had without the framework, while writing that much more HTML to boot!
More so, you hit the biggest point on the head -- "custom". By the time you customize it, you've put in so much work to override what the framework does out of the box it would have been easier, simpler, and faster to just DIY from scratch!
... and what about changes on the fly?
Customer: "Can you make the sidebar headings centered?"
Framework developer: Goest through the markup adding class="text-center" to every blasted heading manually.
Vanilla developer: Adds "text-align:center;" to "#extras h2" once in the stylesheet.
Oh yeah, so much harder to use the vanilla approach.
One of the things framework fans love to say is DRY. "Don't repeat yourself" -- when they repeat themselves endlessly in the markup for no good reason! BEM done "properly" has the same flaw, throwing endless pointless classes on things that just don't need classes.
... and then people call it easier? No... it isn't. It's why I've spent the past six or seven years thinking I have a different definition of the word "easy" from RoW.
"display: table" "display: table-cell" Whaaattt?? I didn't even know such parameters existed.
There's a lot of CSS and HTML that people don't know exists, and that's much of the problem. If half the time spent learning frameworks were spent learning the languages instead, we'd have a much easier time of doing just about everything.
But the people making the frameworks clearly never learned this stuff, resulting in those using them never learning it either.
For example, take something as simple as building a table. Not one of these framework developers seems to have even the slightest clue of how to do it properly!
Take this snippet (I cut down the data rows) from a site I rewrote for a friend as a favor a few months ago. Classic example of the ignorance of the simplest parts of HTML.
<table>
<tr>
<td colspan="3" style="tableHeading">Cards</td>
</tr><tr>
<td class="columnHeading"><b>Card</b></td>
<td class="columnHeading"><b>Set</b></td>
<td class="columnHeading"><b>Price</b></td>
</tr><tr>
<td><b>Eureka</b></td>
<td>Legends</td>
<td>340.00</td>
</tr><tr>
<td><b>Savannah</b></td>
<td>Unlimited</td>
<td>150.00</td>
</tr><tr>
<td colspan="3"><hr></td>
</tr><tr>
<td colspan="2" class="sumTitle" align="right">Total</td>
<td><b>490.00</b></td>
</tr>
</table>
I groan and facepalm... Where's their THEAD, TFOOT, and TBODY? Why are they using a COLSPAN to do CAPTION's job? Why are they using TD+B to do TH's job? Since there should be TH shouldn't there be SCOPE attributes?
<table>
<caption>Cards</caption>
<thead>
<tr>
<th scope="col">Card</th>
<th scope="col">Set</th>
<th scope="col">Price</th>
</tr>
</thead><tfoot>
<tr>
<th colspan="2" scope="row">Total</th>
<td>490.00</td>
</tr>
</tfoot><tbody>
<tr>
<th scope="row">Eureka</th>
<td>Legends</td>
<td>340.00</td>
</tr><tr>
<th scope="row">Savannah</th>
<td>Unlimited</td>
<td>150.00</td>
</tr>
</tbody>
</table>
Being the properly formed semantic markup for that type of information... and yes the TFOOT tag goes before TBODY.
But even when people were using tables for layout nobody seemed to have bothered to learn that there are more tags that go into tables than TR and TD.
This general ignorance of the most basic of HTML structures is why we have endless broken incomplete forms, inaccessible broken layouts on 80%+ of the web, and sites in certain industries (those I cater to) landing in court for these problems.
Sucks, huh?
.. and most of it comes from the reaction "But it looks ok". There's more to HTML than what it looks like in the browser on screen media.
I worked through all your examples as well as articles and tutorials on your website while you were away. I have also been looking through W3C and MDN articles on HTML/CSS basics in my desperate attempt to pick up all the missing pieces. The last ten days have been a life-changing storm, and, quite frankly, I am a little angry that I've been duped. Or, I might say, I duped myself all these years by not taking time and effort to dig deeper than what all these articles told me to believe. Why are these "experts" telling so many lies?? WTF!?!?
Working through all the examples that you posted for me and reading the articles in your site for the past few days taught me more real web development than anything I've read in the past few years (mostly random tutorials focusing on tools). The "separation of concerns" and why we call CSS "CASCADING Style Sheet" make sense to me now. I've got to start with the CONTENTS with a proper STRUCTURE, not begin with containers and a truckload of lorem ipsums. The way you wrote those templates is so short and concise that I could manually type every line from scratch in the FRACTION of the time I often spent customizing a Bootstrap template, AND it works correctly in any devices, even a screen reader could interpret the contents. AND, they are future-proof for the most part.
Why aren't more people talking about this?? Maybe most of us are so lazy that very few even bother to dig deeper??
Why are these "experts" telling so many lies?
Ignorance -- again, not meant as an insult -- is the only explanation that implies no malice on their part. They just don't know because they too never learned it or were never exposed to anything that defined it, taught it, or promoted it. Any other explanation becomes willful deceit on their part, and why it's so frustrating to watch those who actively prey upon said lack of knowledge.
... and there are predators out there, as there is with any other industry. Those who have an emotional or even financial investment in promoting these broken systems. That's where understanding the 7 propaganda techniques and recognizing their use often puts to lie their claims.
Said techniques -- bandwagon, transfer, glittering generalities, card stacking, plain folks, testimonial, and name calling -- exploit flaws in how the mind works.
The human psyche has some pretty severe flaws, and one of the biggest is that when you don't know something, the FIRST answer that gets you through the day is often treated as a inviolate truth -- because "but it worked"... Sure it worked, for you, today, within the limited scope of your understanding at the time. That doesn't make it the best answer, the only answer, or even the right answer! But as part of the brain basically trying to save a few watts, it takes the shortcut of that first answer being the immediate go-to and being resistant to accepting any other answers.
That's what confirmation bias is, and how it leads to an outright cognitive dissonance. When information that contradicts that bias is presented, it is either rejected or worse, twisted into fitting the preconceived narrative. Again why I compare it to cultism, since that's the same mechanism that lets doomsday cults thrive even when the date of the apocalypse set by their prophet goes by with nothing happening.
Hence another of the dangers of learning frameworks first. On top of not knowing enough about what's underneath to actually know if any of the claims about them are true, it establishes that initial bias... and it's why when you DARE to call any of it into question, you get an endless slew of anecdotes, testimonials over how much it helped THEM, dismissive attitudes towards rational arguments, and nit-picking over how it's being said instead of admitting that it's the message that's upsetting them, not the language.
... with not one single fact or example to back up their claims, a dismissive attitude over facts and examples you show, reducing their entire counterpoint to nothing more than "wah wah, is not". Hence why it often feels like talking to creationists, who use one moldy old book written by goat herders who knew nothing of science as their 'proof' whilst ignoring thousands of years of learning, discovery, and rational thought.
Which is part of what's been so frustrating the past decade plus of this nonsense, and why I do often go "off the rails" with the language about it. ... and guys, you were right, that wasn't helping my cause. Just gives the detractors ammunition.
The bandwagon aspect is the biggest part, and not just the "millions of people use it successfully" shtick. Echo-chamber is part of bandwagon that leverages repetition and stamping out of dissent to create the illusion of there being no objections.
It is to that end those of us who advocate the vanilla techniques simply aren't found in the communities discussing this stuff. ANY act of dissension regardless of how politely worded it attacked, derided, and leads to near instantaneous flame wars and bans -- most always one-sided in who gets banned regardless of how polite or impolite the language used.
... hence why those who've spent a decade dealing with this generally dive straight for the insulting language; it's a bit like Picard being pissed off at Q's judgemental treatment of humanity. If we're doing to be damned, let's be damned for who we really are. -- so if we're going to be treated like we're using four letter words for simply voicing concerns, issues, or pointing out flaws, we might as well just go ahead and use the four letter words.
It's a vicious self-feeding cycle.
In that way, places like W3Schools, SitePoint, and so forth end up killing off competent coders so long as they can keep selling their hokey certifications or twenty year out of date books. They foster communities filled with little more than suck-ups and sycophants, all because for them it's more about maintaining their status quo than it is getting people to build websites in a better way... or even properly for that matter.
Which is why such websites are filled to the brim with web rot, bad advice, outright disinformation, and hosts of other failings; and those running them show zero interest in changing that. They want people who will blindly agree because "status quo for the win".
Just look at how many people come pouring out of the woodwork in defense of W3Schools if you dare to say anything negative about it. The site is filled to the brim with disinformation, inaccuracies, and glosses over essential details... and that's now that they fixed many of their older issues. Just a few years ago it was so bad that an many in the industry banded together to create a site called "w3Fools" mocking it.
Because a bad education is as worthless as none.
... and I can prove that the people who create their content are unqualified to tell others how to build websites; just look at their framework: w3.css. For all my complaints about how broken, sloppy, and nonsensical bootstrap and the claims about it are, by comparison w3.css makes BS look like it was created by a genius with deity level understanding of DTML and CSS.
As I often say if you don't know what's wrong with classes like "w3-red", "w3-border", "w3-large" then you haven't learned enough about HTML or CSS to be using either. Don't even get me started about how they reset all font sizes into pixels, an instant WCAG violation.
A situation only exacerbated by their basically having spent the first decade and a half of their site pretending they had something to do with the W3C... they didn't. They never actually claimed it per-se, but the choice of name and their utter unwillingness to correct anyone on the misconception was disingenuous, dishonest, and more than a little sleazy. It took a decade and a half of complaints just to get them to add a disclaimer about that to their site.
To this day, most 'experts' out there will point you at them as the go-to to learn, when what they teach is -- to be brutally frank -- incomplete, inaccurate, or just plain wrong.
... and sadly as the place many people start, many people copy from, and many people mimic,
But more than any of the above, there's just the status quo mentality in action. All of these broken, bloated techniques I'm always ragging on are rooted in two things.
1) the simple fact that people are visually oriented, and expect to be able to say in their HTML what things look like. Again, not HTML's job.. They want to start with the appearance, they only think in terms of appearance, and disregard any other factor.
2) Presentational markup was the norm during the browser wars, and many people have never left that mid to late 1990's mentality. It's all just people blindly copying what others have done without questioning any of it -- even when the governing body of the specifications told us to cut that out twenty years ago.
Both lead to the illusion that you have built a working website, but that runs only skin deep, whilst the ugly goes straight to the bone.
You take an illusionary result, the illusion of ease by preying on ignorance, wrap it in Goebbel's "big lie" by endlessly repeating the glittering generality of "how easy it is", card stacking bad examples as alleged proof?
The masses yum up like it was chocolate soft serve with jimmies every single time, even when what's handed to them is a waffle cone filled with diarrhea and mouse droppings sprinkled atop. Two developers, one cup.
Masters of these methods can convince people to believe in almost anything, and once it becomes belief, it's near impossible to change their minds as that confirmation bias eliminates the capability for critical thought. That's why these methods are the core promotional techniques of every faith, political group, marketer, and are the lions share of the "con man bible".
... and once you start to recognize the techniques, see through it, and the outright lies being peddled? It's like suddenly seeing the world through Hoffman lenses for the first time.

Also why I say "show me something that changes my mind. A fact, an example, anything?!?" -- and in not one single case has anyone even tried. Instead they say I'm being elitist, naive, idealistic, unrealistic, or simply -- again -- cry "wah wah, is not"."
I'm willing to change my mind when presented with facts, true believers rarely are. The trick being to catch people before that cognitive dissonance sinks in, and to convince the handful who retained their ability to think for themselves.
So to answer your question? They lie because they can get away with it, people want to believe it, and it lets them control the narrative. The same reasons preachers, politicians, and con-men like through their teeth.
It is depressing to think about all of that, but then again, it makes a perfect sense. Well, at least I'm glad that I didn't go any further in my ignorance. And, honestly, I think I was in a bit of denial as well. I didn't want to admit that I probably shouldn't be so proud of the way I slapped everything together even for the sake of making money. I have been taking a sober look at myself in light of all these discussions and thinking about how I need to have more respect for the industry. After all, I would be p^^sed if someone sold me something that he "slapped together" and cut all the corners. Why should I be if I were doing the same thing?
Like that whole BEM stuff. I looked at some of the "BEMified" Bootstrap templates I was using before all of these discussions. The minified Bootstrap core CSS files and the jQuery core minified files alone turned out to be 767KB in size. The empty template (landing page style) with only some lorem ipsum placeholder contents is 9KB, and the custom.css is 17KB. Background images and decorative images are around 800KB total. It comes out to be around 1500KB for the top page alone. Let's say I could have a properly coded website with the same contents in less than 50KB doing all the right things, cut out unnecessary elements and quit using Jumbotron-like, media-heavy nonsense. And let's say it was for a small business website getting only about 300 visitors a day. That's still about 435MB of the data transfer everyday that doesn't need to be there. That's like, what, 13GB of wasted bandwidth every month for a website that is supposed "just a 'simple' small business site, no big deal." How did I even miss THAT insanity!?!? And I called myself a professional!? Yikes. Embarrassing...
How did I even miss THAT insanity!?!?
It's not discussed, and when it is the result is outright attacks, ridicule, scoffing, and a general hostility rooted in the fact that the propaganda, and illusion of a quality result is the first thing anyone sees.
Sadly, that's what often makes me so hostile on the topic; since it often ends up the same old "Do as we say not as we do" when it comes to ... civility. It's entirely acceptable to ridicule, dismiss, and attack separation of concerns, semantics, and every other good practice... but you DARE to go after these broken bloated "media darling" frameworks, preprocessors, and outdated methodology using the same basic level of disgust and disbelief, and magically now that exact same behavior is unacceptable. All because you dared to question the status quo.
You'd almost think the top "names" in the industry were running a giant scam centralized around these things.
That's still about 435MB of the data transfer everyday that doesn't need to be there.
It actually runs deeper than that, and consider when a product or product line warrants something like its own forums. This stuff scales up scary when you're talking about something like a million+ post forum with a thousand or more users visiting dozens of pages apiece. (I actually administered a forum like that for a decade, before being forced out by new owners of the related franchise)
Consider again the moving of presentational images, static style, and even static scripting out of the markup. What if this was for a forums like I described, where using the framework techniques you end up with an average HTML per page visited of 150k. If you have a thousand different users visit resulting in 30K page views a day. These numbers are within the norm of the forum I mentioned having administered at the time I left.
That's 4.5 gigs of markup per day. Now, let's say that all that's being delivered on the average page is 24k of plaintext and a half dozen content images. There's no need in most cases for that to be more than around 50k of HTML if semantics is leveraged You just reduced it from 4.5 gigs a day to one and a half. That's shaving off 90 gigs a month, often the difference between a $200/mo hosting plan and a $30/mo one. Which is why when you master these techniques and can deliver such reductions, site owners who "know better" won't bat an eyelash at being asked two grand, they know they'll make it back over time. Good business, good investment, and sound practices play the long-term game, not the petulant "wah wah, I want it now" games.
... and remember on sub-pages most of your presentational images, CSS, and so forth are cached so they aren't reloaded constantly. Only the markup with it's unique/different content is sent on each and every page-load. Because of this, it is possible for bloated HTML built with bad practices to actually total MORE bandwidth than everything else on the page! All it takes is traffic where visitors go to more than one page on the site!
That's something few people seem to realize, that if you have a site where people are visiting dozens of pages every time they come in the door -- aka a HEALTHY website with content of value -- your HTML throughput can actually exceed that of images, JavaScript, and external stylesheets COMBINED!
You don't hear a lot of framework fans talking about that, do you? It's a concept that on the face of it few would even think of, but if you understand networking traffic and how website caching works, it's actually pretty obvious.
... and that's before we even talk the processing overhead. Anything you do in the markup for any complex website is going to be put together by server-side code. That means the more markup you have, the harder that server has to work, the bigger the memory footprint, and the longer it has to sit there with the connection open.
That's where the "oh everybody has broadband" lame excuse falls apart so miserably, it still all has to be sent through the same pipe from the server, and that server's connection (or multiple connections, or multiple connects across multiple servers) only stretches so far before you end up throwing hardware and money at a problem that may not even have needed to exist in the first place.
... and it's why bloated code, especially HTML can -- for high traffic sites -- end up the difference between dumping thousands a month into managed dedicated servers, VPN's, staff sitting there nurse-maiding everything, etc, etc... and comfortably hosting on a $20/mo VPS where the most difficult maintenance task is running apt-get or yum once a month for updates.
But again few people take HTML seriously enough for that, much less thinks in these terms. It's sleazy, ignorant, dishonest, and infuriating the way most people treat and talk about HTML.
Poor performance and long-term cost overruns most always being the result of an industry filled with the attitude that the core language on which websites are based, doesn't actually matter and shouldn't be taken seriously when it comes to building websites.
You can see said attitude at every turn, the majority is open about it constantly saying things like "well that really doesn't matter". Really, the rules of the specification and intent it was built upon doesn't matter? Wow. That should tell you ALL you need to know about the people who promote frameworks and poo-poo vanilla coding.
Background images and decorative images are around 800KB total.
I would recoil in horror at that many presentational images. Bet you dimes to dollars those images have zero relevance to the content since they're part of the template too, right? Wonder how many of those images could be vectorized to a single smaller font file, or have poor encoding, or are being wasted doing things that we haven't needed images for since CSS3 became real-world viable for deployment.
Aka all the things that have the Photoshop jockeys quaking in their boots as their relevance in the industry dwindles even further.
Is it why there are services like WPEngine which specializes in hosting WordPress sites at a premium cost? They are freakin' expensive, but so many people recommend it for running a large-scale WordPress site. I used to think it was a good thing, but now, I am beginning to wonder why I shouldn't call such service a borderline scam selling on all the wrong reasons to lake in some cash instead of educating people that they might not even need a mega-power hosting if they build a website differently with cleaner code.
I'm also beginning to wonder whether making everything "easy" for the general public (Ex. Wix, WordPress, visual page builders, etc.) might not always be positive in a bigger picture. Here, we are getting into the territory of industry/social cost. I can't help thinking we are paying a high price for accepting bloated code base as something of a necessity/norm. What if the vast majority of websites utilized a much leaner code base? I imagine the traffic saving would be huge, and we might even have a better performance in general... Am I off-balance here, though?
They are freakin' expensive, but so many people recommend it for running a large-scale WordPress site.
I often think that's part of why there's no tearing rush to fix any of WP's real problem! There's no incentive to make it leaner when you can make a buck off the people suckered into using it. Who cares how many people are screwed over by it and how many businesses destroy their web presence, there will always be another sucker in the pipe if you just use Goebbels's "big Lie" to promote it.
The same way companies like Amway, Mary Kay, and other MLM's continue to exist despite clearly being nothing more than legalized pyramid schemes; aka business models that are unsustainable unless you routinely have everyone below the fifth or six tier give up and walk away after having their wallets drained.
... and thanks to the propaganda and outright bunko, even those burned, even those who lose their shirts, are slow if not outright incapable of embracing the idea that it was the scheme itself -- and not them -- which led to their failure.
Same as I keep comparing to with Apple, where the company can do no wrong and if something does go pear shaped those who've bought their products are so emotionally invested in it, everything that goes wrong has to be their fault, not Apple's.
I'm also beginning to wonder whether making everything "easy" for the general public (Ex. Wix, WordPress, visual page builders, etc.) might not always be positive in a bigger picture.
Thing is they're rarely actually easier in the short term or the long run, given how hobbled the results. They have the illusion of ease created by -- again -- the "big lie" of repetition. You claim it's easy, you get people who are just starting out and convince them it is easy, you create a system by which they never learn any other way of doing things whilst simultaneously making them think they know the underlying technology. You give them what looks like a good result that sweeps all the problems under the carpet.
... and when it fails, you feign ignorance as to the problems, leverage a community of sycophants to stand up for it, and blame the end user. If they don't blame themselves and start to question the system itself, you ban, ridicule, and isolate them so the faithful aren't disturbed -- or even better you use them as an example of "this might happen to you if you don't stay true to the faith". There's a reason many stricter more extremist religions use the threat of excommunication to keep the flock in line. It's a proven mind control technique that politicians, preachers, and con-men use and falls squarely in the province of the propaganda technique known as bandwagon. Not only should you want to be part of the group, you don't want to be shut out. Oh, but it works for everyone else, the problem must be you. Etc, etc, etc. Again it's plain as day once you recognize the techniques.
Each of these systems -- wordpress, react, jquery, bootstrap -- have their own little echo-chambers. Worse, they interact with each-other as since they are all peddling the same lies, it is in their interest to work together to keep these lies afloat.
The apparent "ease" is an illusion, one dispelled the moment you start poking around under the hood and researching the underlying languages.
What if the vast majority of websites utilized a much leaner code base?
We probably wouldn't be careening towards a bandwidth crunch; whist sure then end users are getting more and more station to wall improvements in speed, nobody is building the new backbones to support it! The core infrastructure that gets you around the globe is pretty much the same as it was a decade and a half ago. The seven "tier 1" providers are doing jack-all in terms of legitimate improvement to match the demands of larger sites and faster provider-to-customer lines. They aren't going to either because if they did, it might cut into their over-the-top profits, even if that means said skimming off the top will eventually cause their businesses to fail.
It's a sad fact that many alleged "investors" have figured out that you can actually make a ton of money short-term by destroying a company's future, rather than risking the chance of long term investment. We don't have investors anymore, we have shareholders; there's a difference.
... and until the owners of the tier 1 providers are willing to reinvest in their businesses, we're going to see all the high speed connections of 45mb+ start to be unable to deliver their advertised speeds from anywhere but the local region. We're going to see latency spike resulting in the increase in the handshaking penalties during page-loads. This is looming on the horizon yet nobody is taking the steps on the hardware side to prep for it, nor are there many taking the time to at least try and slow down this "march towards death" by leaning out things on their websites.