How the blazes is bootstrap "easier"?

Simply not true. I came to this forum with a bunch of questions like "Why should I code everything manually when I could use GUI tools like Wappler?" I started off questioning the effectiveness of coding everything by hand. I did not have my current perspective a month ago. I did my homework experimenting with GUI tools, studied the entire Bootstrap documentation, and read many dozens of articles on the subject to verify the counter-claims made in this forum despite their advice against using them and their reasoning. I gave a fair shot at both sides and came to my current perspective, which is different from my perspective a month ago. So, I *did* accept a different perspective. I am all for accepting a different perspective if the current one needs adjustment.

To do that, I need sound argument and reasoning. "Years of experiences in web development" means j@ck $hit if someone is to shove nonsense and untruth down my throat. "Authority" is utterly meaningless when it has no legs to stand.

In the meanwhile, I have asked you in my previous reply, point by point, WHY and HOW you rationalize your assertions. Instead of taking time explaining to them how each of your claims worked, you posted another echo chamber stating the same thing without reasoning, basically saying the same "These are true because these are facts." Compare that to @deathshadow; Every question I asked in this forum, he came back with reasons and sample code showing why his assertions were true. I see he is not interested in shoving "facts" down my throat. So I examined his claims and found them to be true. And not to mention I found a few other credible resources agreeing with his stance on things and saying how their perspectives might not sit well with those holding a popular view. I don't care for "popular views." I want something that makes sense and sit well with my work ethic. So far, your claims haven't given me any reasons to regard your perspective like that.

Seriously, do you hear yourself when you say stuff like this:

...so you can charge $2,000 for fifteen minutes of work and milk the most cash out of people who don't know j@ck $hit since "they don't care any of it?" Your wanton disregard for professionalism and work ethic is simply staggering. It is what I would call "Highway Robbery Approach to Web Development." So yeah, for that, every point you have made makes a perfect sense. I give you that. Thanks, but no thanks!

 

I shall add some comments of my own, separate and possibly disagreeing with some that Jason has or will make.

Actually, your backup "facts" were simply more assertions; essentially arguing from authority, a logical fallacy.

I will focus on menus, though the same factors rule the other components you mentioned. Just how many menu templates does Bootstrap have? How do you find the one best suited to the site? Any non-trivial site will likely have a non-trivial architecture that requires a non-trivial menu. How are the site's pages organized? Do you need a table of contents type menu or an indexed menu? Or, something else? Are there sub-menus? What vocabularies will you use, yours, the clients or the users'? Compared to the time it takes to decide these questions and test them, coding is an ongoing, iterational process, a drop in the time bucket. Bootstrap offers no benefit here.

I mentioned vocabulary. Large projects spend hours debating just which words and phrases to use, often with degreed Information Architects. If you're curious, the best degree for this seems to be in library science. I had the importance brought home to me on my own site. I wrote a short article on floats, titled "Enclosing Float Elements", a subject that is still poorly understood, maybe not at all from what I've seen. Google had it at #10. I checked my referer (yes, that's correct) logs and found that most people searched for "containing floats". I changed one word in the top heading from "enclosing" to "containing" and the article went to #1. Companies spend hours with the developers discussing test result for just the right words to use.

I find this assertion believable and silly at once.

People will generally stay with a method they know, even if it's stupid, rather than change to another even if it's obviously better. A well organized style sheet that addresses semantically named element attributes, and is developed top-down to use the cascade (you know, from Cascading Style Sheets) and specificity leads to support and debugging that takes only minutes to decode even if you've never seen it before. Not to mention reducing conflicting rules to near nothing.

When people use the term, designer, in this context, I always wonder what, exactly, do they mean. Are they referring to the crayon and color pencil brigade or the engineers who deal with user interfaces, user experiences or information organization? If the former, how do a pile of generic "designs" do any damned thing when the layout of each page has been developed by the engineers. The not-an-engineer designer's job is to create a site visual that reinforces the client's branding. Oops, some generic won't work here. If the client wants to develop a new branding, they won't look kindly on some copy/paste artist charging them for it.

Why do they need your services to repurpose existing, generic crap?

I'll let them speak for themselves.

gary

 

I personally agree with you Deathshadow. I'm not a big fan of bootstrap and prefer to write all my code from scratch and tweak everything myself. I think once you really understand HTML and CSS it's actually easier to write concise code that does what you want it to as opposed to bending your will to the bootstrap restrictions and bootstrap learning curve.

 

I know HTML and CSS and yet I use Wordpress and Bootstrap. Because I'll be damned if I worked to code a database driven website in years, when I can use Wordpress. And Boostrap does speed development a little, although in some cases it annoys me to death.

The problem is that most of my clients couldn't care less on what their website is built on. I have an OBGYN in my ex-city, who started working with me in 2013. For all this time she's been no.1 in Google for our main keywords. She has a Wordpress website I built back then, which gets routinely updates and content. She's doing SO WELL that, from running a small clinic in the middle of nowhere, she's now moved and grown the clinic smack in the historic center of the city. At ground zero so to say.

Most of this because of the 'crappy' Wordpress website she has and the work I put into her marketing.

Do you think she cares about the code not being perfect? No, she's raking in the profits.

And, after years of trying to be a 'purist', I understood clients want RESULTS and more money. They don't want to wait for months to get a simple website set up or for years to get some traffic. I have wasted years of my life tinkering my websites to 'perfection' and wasting thousands of dollars on them. 99.9% of the people won't care about this details. They want to promote, or read about something important to them, find a business partner etc.

 

Bingo. Exactly. Your customer does not care what geek library or code you use. They care about results. To a developer results means CPU, Memory, and tweaking coding to save microseconds. To a business microseconds doesn't matter. Results means MONEY. Without money you have nothing. A lot of the opinions in this thread is from a developers perspective.

If I hired @deathshadow to create a web app and web site I would have to sit here listening to a bunch of bloated non-sense of why everything needs to be recreated. Then months later I will finally have a web site that could have been finished months ago with the exact same content. Then once I fired him for being utterly ignorant, stubborn, and emotional the next nerd would rip apart his code telling me it has to be redone and how he can do it better. Developers/Designers need a strong manager. If you have 50 developers employed you will have 50 different ways of doing something. And the only thing in common is the absurd length in time and money it will take to finish. This is why you will ALWAYS see posts saying "my manager sucks.. he wants us to use XYZ library". And you know what? They will shut up and do it and the company will make money.

 

Wordpress is database driven but a database is not require to run most websites.

 

... and @NetStar ups the ante with "lame excuse #7". Attempting to make unfounded assertions about the deliverer of the message, since just like with every other point he's unable to actually support his assertions with FACTS. Anecdotes? Glittering Generalities? Oh we have these galore in order to dodge ACTUALLY providing an ACTUAL answer!

When in most cases if they're one of these inaccessible train wrecks riddled with bad practices, it's often FASTER to do it over from scratch than sit there dicking around in the document inspector, making the document WORSE by throwing more classes and style overrides at it, and in general DOING LESS WORK!

Again, the UNFOUNDED claim that this trash is somehow faster for anyone to CREATE in the first place... and the best one can typically come up with is "oh it has examples you can just cut and paste" -- the STEREOTYPE of a glittering generality right out of the textbook alongside "Vote for Orange Douche, A Real American". What is a "real American"? What makes him more of a "real American" than his competitor? Glittering generality AND transfer.

But of course, "It gets the job done" and "the real world" -- as if I've somehow less successful than he is when he doesn't know me, my story, or what I've done. The 100% cop-out of again avoiding the question entirely and doubling down on "wah wah, is not".

The very same lame duck question avoidance that made me create this thread in the first place.

AGAIN that anyone could claim these front-end frameworks "saves time" or "works better" or "makes you more productive" clearly doesn't have enough experience, interest, or possibly even intelligence to be flapping their yap on the subject, since AGAIN you keep saying it is, without saying HOW?!?

The only thing you've said that even came CLOSE was a matter of documentation, not implementation. Because again, on implementation alone it is more work, more time, more effort, more to learn, whilst pissing on the entire reason HTML and CSS even exist from so on-high you'd think the almighty just got back from Kegger-U.

Let's say we set aside idiots copying code, since there's NO reason that couldn't be done with regular HTML/CSS. Setting aside that yes, the HTML specification is a train wreck of legalese and dirtbag scam artists like W3Schools aren't helping the matter. To put the ACTUAL question as clearly and succinctly as possible... with all the shortcomings... How the blazes is this:

      <div class="navbar navbar-dark bg-dark box-shadow">
        <div class="container d-flex justify-content-between">
          <a href="#" class="navbar-brand d-flex align-items-center">
            <svg xmlns="http://www.w3.org/2000/svg" width="20" height="20" viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round" class="mr-2"><path d="M23 19a2 2 0 0 1-2 2H3a2 2 0 0 1-2-2V8a2 2 0 0 1 2-2h4l2-3h6l2 3h4a2 2 0 0 1 2 2z"></path><circle cx="12" cy="13" r="4"></circle></svg>
            <strong>Album</strong>
          </a>
          <button class="navbar-toggler" type="button" data-toggle="collapse" data-target="#navbarHeader" aria-controls="navbarHeader" aria-expanded="false" aria-label="Toggle navigation">
            <span class="navbar-toggler-icon"></span>
          </button>
        </div>
      </div>

Code (markup):

EASIER or better, or simpler, or better to work with, than this?

<div id="top">
	<h1><a href="#">Album</a></h1>
	<label for="toggle_header"></label>
<!-- #top --></div>

Code (markup):

THAT's how stupid bootstrap is. That's how stupid the people who created bootstrap clearly are.

But again, you dodge the actual question, and instead parrot the same lame excuses every other sleazy dirtbag predator online mindlessly repeats.

In terms of IMPLEMENTATION, actually using the bloody thing to create anything unique so that others can work from it, HOW is it an improvement over just using HTML/CSS straight? Aka, ACTUALLY easier. Aka living up to the claims and hype that are utterly and completely unfounded, reeking of Goebbels "Big lie"!

To the point you're either lying, or repeating the lies you've been told.

 

LOL this troll... @deathshadow you're not right about this. It's going completely over your head. It's not about bloat... It's not about DOM pollution... It's not about semantic HTML... Those are all things geeks care about and think that matter. Your customer doesn't care. Their traffic does not care. Businesses want a finished product as soon as possible to get it in front of paying customers. You just don't understand. You are stuck in to some weird nerd world that the customer views the source of the web page to see if they use bootstrap before continuing. They don't. You are so misinformed. Any company who hires you should be ashamed. You're a horrible "developer".

 

One to talk. The client DOES care when their site is slow. They do care when it costs more to host. The do care when it's broken inaccessible mess.. They do care when it hobbles your search rankings and tells potential users to sod off. They might just feel ripped off a few weeks after you've "Billy Joe and Bobby Sue"'d (Two young lovers wiiiith nothing better to do) them and find you you've cookie-cuttered the same site that's sleazed out to everyone else. Hoo hoo hoo.

More importantly, they REALLY care should they be in industries where it matters, have requirements like the WCAG, and could end up under federal prosecution or civil lawsuits over it. AGAIN, see laws like the US ADA, US EQA, and all those other things you will likely claim "don't exist" like you did before. Tell that to all the people SCRAMBLING right now to deal with the fact that as off this month (a year after it was approved), the Americans with Disabilities Act has been uprated to WCAG 2.1 status.

Meaning if you go full pakled mixing REM fonts with PX media queries, you're probably in violation. If you use JavaScript for your mobile menus without a graceful degradation plan, you ARE in violation. If you use certain combinations of font-weights (like 300), thin-glyph fonts (such as Tahoma), you're below legibility minimums and are in violation. All things bootstrap does "out of box".

But you'll just ostrich yourself again, claiming that's "not a thing".

Yet you still keep making it about everything EXCEPT the poor sods building websites. THAT'S NOT MY HUFFING QUESTION!!! The question is HOW is bootstrap EASIER TO USE for those of us building websites? HOW does it live up to ANY of these noodle-doodle claims about how great it is? So what if the client/visitor doesn't know what any of it is, why make the job of building websites harder? That's the part that's so stupid is it is clearly harder to use and work with, I can show example after example of it being so, so how is this "easier" when building a website?

You write as much if not more code, circumvent the learning required to know what to do when it goes wrong, it teaches broken practices that CAN get you in trouble in many industries, It is harder to build pages with, harder to integrate due to its complexity, makes customization of even the simplest things like colours and backgrounds a nightmare.

I've found clients generally DO know something is wrong, they just don't know how to articulate it. This is supported by your statement -- site owners and visitors don't know how it's coded, or how it works, or what is being used. What they DO know is when it's broken for them, harder to use, slower to use... all things that happen with bootcrap and can be laid square at the feet of those using it. JUST like jQuery, JUST like mootools, JUST like every other thing that CLAIMS to be easier without a single FACT to support it.

... and your answer right now is "nobody cares" -- which to me sounds like you WANT your job as a front-end developer to be as DIFFICULT as possible given the endless shit-storm of problems it creates... That's the part that's so ridiculous, it is CLEARLY and DEMONSTRABLY more work to use the framework than it is to just use vanilla HTML/CSS properly. That means that as someone building websites you're making YOUR OWN LIFE HARDER by using it. Even the alleged "professionals" that created it CLEARLY didn't know enough HTML or CSS, which is likely why they created it.

Much less how hard it makes it for back-end developers since you're handing them more to try and make sense of to slice up into things like CMS. How hard it is to reskin down the road since you have to change the markup just to change the appearance. JOE HELP YOU doing multiskinning. Or customizing for print when a client asks for that.

Client wants the columns in the other order or to have two elements reversed vertically, what's easier? Re-arranging the ENTIRE markup to change the content order, or opening up the CSS and adding two to five lines of flex-order or reversing the float directions?

Client wants you to change the colour of an element, which is easier? Looking at the markup, figuring out what a decent selector to the element is, then adding color:#F00; in the CSS (or changing the existing one), or diving into a convoluted sea of classes, finding the element, adding another class to it, then opening up the CSS to make that class, adding color:#F00 in the CSS, then BLINDLY HOPING "specificity" doesn't prevent you from doing so without "!important"?

Client wants more padding. Client wants less padding. Client wants bigger max-width. Client wants a sidebar that doesn't fit bootstrap's "grid' widths. Again, what's easier? Just setting it in the CSS off the existing semantics, or doing it the "framework" way of having to edit both the HTML and the CSS?

Client complains that the site title isn't vertically centered properly how does one adjust for that? Seriously, LOOK at most of the turdpress examples! They can't even out-of-box manage to line things up vertically properly! Oh but sure, its out of box margins and paddings "just work".

Client complains that mobile users or even people in their own locked-down secure workplace can't access the menus. Huh, you'd almost think they were using JavaScript to do CSS' job.

Client complains that on their high end 4k display with the enlarged fonts that they're getting the mobile layout. Huh, you'd almost think they were mixing and matching PX and REM any-old-way.

Etc, etc, etc. Methinks we have a very different grade of clients, or an entirely different moral, ethic, and empathetic relationship with same.

But again, setting the clients aside, how does it make OUR lives as people building websites EASIER? You keep dodging the question. It is more work, more code, more to learn, harder to customize, harder to change, harder to adjust to the site-owners wants... so how are any of the claims about it true? Why would any of us who actually BUILD websites do this stuff the hardest way possible? Aka what bootstrap and other front-end frameworks ACTUALLY do, despite the wild unfounded statements to the contrary that make up their propaganda.

Hence why you just won't give a straight / legitimate answer to the actual question.

BUT

I do have to thank you,

1) for showing me the cringe-worthy sociopathic if not blatantly psychotic mindset common to this industry that should leave anyone with even a shred of morality completely appalled.

2) For making me think about why people might "believe" the blatant lies. Of all the different reasons on how people are suckered into thinking that frameworks like bootcrap are magically "easier" one stands out head and shoulders above the rest.

"It's well documented with examples people can copy".

I said it before, in that it's not like there aren't HTML samples people can just copy, but most of those are as poorly written as Bootstrap since we've got 20+ years of "web-rot" out there. Outdated tutorials, people who never pulled their heads out of 1997's rump, sleazy predators like W3Schools filling people with broken nonsensical misinformation, disinformation, if not outright bullshit...

HOW did we get here? Well, it's right there. The inverse corollary "name calling/glittering generality" of "well documented". Implying that everything else -- like HTML and CSS are not. If one looks at the HTML specification, particularly since the WhatWG's HTML 5 was accepted by the W3C, it's a train wreck of legalese not even written for people who write websites.

When you said "Bootstrap has a specific pattern you follow with class names and structures already created" that is kind of another glittering generality -- specifically "false equivalency" -- in that HTML has the same thing in the form of semantic tags with meanings if people were to write semantic markup and leverage selectors in the CSS. It creates the document structure upon which you can hang styles. CSS provides those styles, even allowing multiple styles off the same page without editing a single line of markup. It's a false equivalency, but a telling one! It further emphasizes how by people not learning proper semantics, not learning separation of presentation from content and its associated DRY, and not learning even the most basic of HTML/CSS concepts they are driven into the open arms of liars, scam artists, and those brainwashed into repeating the same drivel.

... and who's fault is that? The W3C and WhatWG. The official documentation for building websites is nonexistent as the alleged specifications are written for those who make browsers, not those who make websites. They provide zero real-world examples, outright refuse to take an authoritative stance over how websites should be written, and are content simply to document what people are doing, instead of providing a clear, consistent, uniform standard telling people what to do and how to do it.

Also that pesky web rot hasn't helped, the people who just "didn't get the point" of 4 Strict doesn't help. That fact that most people would have failed 5th grade English in Massachusetts back in 1980 (basically the writing standard on which HTML 5 semantics was created) sure as shine-ola doesn't help.

So it's not that it's ACTUALLY easier in any way shape or form. It's that education and documentation are lacking, the W3C fails to take the authority needed to create "specific patterns" much less "structure" in people's documents, any jackass with no authority can post endless broken guides and references based on their own misunderstandings,

Even though it's all there if you can separate the wheat from the chaff. So in a way you were right, it's not easier. Not even close, not in any objective educated manner are these frameworks "easier" or "simpler" or "better" at anything. They just look that way to people who can't take the time to dig through the mire of conflicting opinions, broken gibberish legalese of the "specifications", and figure out who's talking out their arse and who isn't... so much like with religion they cling to the first lie they hear and stick with it because "it gets the job done".

When really, from an implementation standpoint, it's ALL already there in HTML/CSS if you practice semantic markup, separation of presentation from content, progressive enhancement, and hosts of other things that exist to make our lives building websites easier. Just good luck getting the W3C to give us anything that clearly illustrates that.

Bringing me back to the idea that we need a new HTML. An HTML that:

1) isn't called HTML since that would lead people back to the web rot and limp, soft, laissez faire "specification", and the wild west show of people NOT even coming close to trying to obey having a logical document structure, proper semantics, or any of the dozens of other things that give us those "specific patterns" that every HTML developer should but clearly does not know.

2) Is written as much if not MORE for people writing websites than people writing browsers.

3) Is Authoritative, telling people what to do, not simply documenting what people are doing or what can be done. You know, a SPECIFICATION!

4) Removes pointless redundancies reducing the overall number of tags and attributes. See how IMG, VIDEO, AUDIO, and EMBED are all redundant to OBJECT. Or how HTML 5's garbage "structural" tags are redundant to just using numbered headings and HR properly.

5) prevents going "out of bounds" with garbage like letting people just unrestricted make up their own nonsensical tags not one legitimate UA would ever treat as anything more than a DIV.

etc, etc, etc...

I keep coming back to this idea. I've said it for almost a decade now. that HTML itself may in fact be the problem. NOT in terms of implementation -- as there was actually little if anything truly "wrong" with 4 Strict.(I can't say that about 5) --but in terms of how the alleged "specification" is not written for people using the languages to build websites, is utterly lacking in authority or clear English that explains the semantics properly, and that outdated websites, tutorials, as well as people treating the whole mess as a wild-west-show doing things however the hell they like since the specification doesn't clearly say "NO" -- well there's your problem.

Though much of that can be traced back to an assumption TBL made when he created HTML. That it would be used by intelligent, educated, articulate professionals such as the educators, researchers, and scientists he was working with at CERN. The concept of what is ACTUALLY a paragraph didn't need to be explained that "no, two words that aren't part of the flow text are not a paragraph" or the concept of how headings have depth.

You'd ALMOST think he created it with the idea of saying what things are or would be in a professionally written document, instead of what things look like. That way the user-agent could best present those meanings within the limitations of the device or user; past, present, and future.

I think I need to shelve my other "for fun" projects and get this huffing done. A new specification, written to engineering standards, fitting the engineering code of ethics, using plain English even a fifth grader from the 1980's should be able to decipher (so that's what, second year college in America now?). No calling something "empty" but "not that kind of empty". No "deprecated", or "arrears", no derping three whole paragraphs about "parallelism" unless it's in the browser-maker side of things. (which really should be none of HTML's business. Load it however's most efficient!).

Assuming I can stay out of the hospital long enough to GED. Git 'er dun. Now excuse me, I have a neurology appointment.

 

I am glad I read this post. I am now after quite a few years going to dive back into web design and development and I keep hearing how Bootstrap is the new best thing on the web to use and makes learning like a gazillion times easier.

I think I will stay away from it....

 

(Pretty) please?!! I know you're more than capable of doing such a feat, but I'm curious as to how is that going to work out with W3C ... and uhhhmm browser makers?? Is there a way to implement a completely new version of HTML without their help/consent/permission??

 

Well it would require at least two "versions". One would be much like XHTML 1.0 or 4 transitional, where they don't have a choice as it is backwards compatible, or polyfilled to be such.

Only version 2 would implement the things that would require browser makers to be on-board. Like XHTML 2.

The trick is to find names for them that are more likely to make the more modern one less "scary" than "strict" and less vague than "1 and 2". One that also does not make the lesser version 1 sound better than version 2.

Perhaps "Legacy" and "Modern"? No, 'cause it ten years it will likely be stupid to still call it modern. "Progressive"? No, that'll scare away the right wing nuts who don't actually know what the word means. "Proper"? Hmm.. SiMPL 1.0 Legacy, and SiMPL 1.0 Proper. I like it.

Though what to call it. I wanted to go with SMPL, but that's taken, as is SiMPL. Need something not already in use as a programming language name that can be easily turned into a backronym,

HTMLS? HTML Simplified? No, looks too much like HTML 5 without the space. The naming is the hardest part. Maybe just pick a goofy name that has nothing to do with being an acronym. Works for major successful domains.

 

How about "Simpler"
SimpleR Markup
SimpleR Markup Language

"Clean"
Clean Markup
Clean Markup Language

"Elementary"
Elementary Markup
Elementary Markup Language

"Accessible"
Accessible Markup
Accessible Markup Language

... gooffy, not an acronym, and can easily be turned into a backronym? Hmmm how about:

"A-OK"
/eɪəʊˈkeɪ/
(A-OK; A-okay; AOK; Aokay)
Informal, North American

Adjective
1. in good order or condition; all right.
"everything will be A-OK"

Adverb
1. in a good manner or way; all right.
"we hit it off A-OK"

Origin
English
OK ----> A-OK (1960s)
1960s (originally an astronauts' term): from all systems OK.

A-OK 1.0 Legacy
A-OK 1.0 Proper

AOK 1.0 Legacy
AOK 1.0 Proper

<!-- say bye bye to DTD -->
<aok type="proper" version="1.0">
   <meta>
   <head>
   </head>
   <body>
      <h1>AOK</h1>
      <p><strong>HTML 5 is so 1997!</strong></p>
   </body>
</aok>

Code (markup):

LOL

 

Oppps!! Of course <meta> should go inside <head> ...

LOL

 

Thing is to maintain backwards compatibility we'd have to include both <html> and the DOCTYPE. Even Firefox has some quirks left over from the "quirks mode" trigger of the doctype.

Though much like HTML 5, DTD's are definitely on my "everything must go" list. Along with the microformats BS that led to idiocy like ARIA roles. What do I mean idiocy?

<input type="text" name="firstName" id="contact_firstName" required aria-required="true">

ARIA seems to exist JUST to let you flip the bird at using the right markup, by throwing even more code at it to imply what using the right markup should do. Take this example from MDN:

<h3 id="rg1_label">Lunch Options</h3>

<ul class="radiogroup" id="rg1" role="radiogroup" aria-labelledby="rg1_label">
  <li id="r1" tabindex="-1" role="radio" aria-checked="false">
    <img role="presentation" src="radio-unchecked.gif" /> Thai
  </li>
  <li id="r2" tabindex="-1" role="radio" aria-checked="false">
    <img role="presentation" src="radio-unchecked.gif" /> Subway
  </li>
  <li id="r3" tabindex="0" role="radio" aria-checked="true">
    <img role="presentation" src="radio-checked.gif" /> Radio Maria
  </li>
</ul>

Code (markup):

100% herpa-freaking-derp and developer incompetence, ignorance, ineptitude, and just plain asshattery.

<fieldset id="lunch">
	<legend>Lunch Options</legend>
	<input type="radio" name="lunch" id=="lunch_thai" value="Thai">
	<label for="lunch_thai">Thai</label>
	<br>
	<input type="radio" name="lunch" id="lunch_rancid" value="Rancid">
	<label for="lunch_rancid">Subway</label>
	<br>
	<input type="radio" name="lunch" id="lunch_maria" value="Radio Maria" checked>
	<label for="lunch_maria">Radio Maria</label>
	<br>
</fieldset>

Code (markup):

81% the code, works in legacy browsers, is the CORRECT semantics since inputs and labels are NOT a "list", they're a set of fields. It's not a H3, it's a LEGEND for the FIELDSET. Those images are presentation and have zero business in the HTML. Basic semantics anyone who claims to know the first damned thing about HTML would/should recognize as bullshit.

... and for what? to let some scripttard unqualified to write a single line of HTML vomit up broken gibberish that isn't even JavaScript's job?

Every Aria example I've seen has been even more mind-numbingly dumbass than bootcrap... to the point I seriously have to ask what the hell drugs are the people who created it and advocate its use on?!?

I mean get a load of this steaming load:

<div role="table" aria-label="Semantic Table Elements" aria-describedby="semantic_table_desc">
  <div id="semantic_table_desc">Semantic Elements to use instead of ARIA's table roles</div>
  <div role="rowgroup">
     <div role="row">
       <span role="columnheader">ARIA Table Role</span>
       <span role="columnheader">Semantic Element</span>
     </div>
   </div>
   <div role="rowgroup">
    <div role="row">
       <span role="cell">table</span>
       <span role="cell">table</span>
    </div>
    <div role="row">
      <span role="cell">rowgroup</span>
      <span role="cell">thead, tbody, or tfoot </span>
    </div>
  </div>
</div>

Code (markup):

Seriously, just use the correct semantic markup!

<table>
	<caption>ACTUAL Semantic Elements, screw ARIA roles</caption>
	<thead>
		<tr>
			<th scope="col">Aria Table Role</span>
			<th scope="col">Semantic Element</span>
		</tr>
	</thead><tbody>
		<tr>
			<td>table</td>
			<td>table</td>
		</tr><tr>
			<td>rowgroup</td>
			<td>thead, tbody, or tfoot</td>
		</tr>
	</tbody>
</table>

Code (markup):

Why the bloody blue blazes does that idiocy even EXIST?!?

Don't even get me STARTED about:

<section role="list">
  <div role="listitem">List item 1</div>
  <div role="listitem">List item 2</div>
  <div role="listitem">List item 3</div>
</section>

Code (markup):

It's like Foxtrot Foxtrot Seirra, JUST USE THE CORRECT MARKUP YOU IDIOTS!!!

DIV and SPAN are semantically neutral containers for the application of style without saying what that style is. That's it. If you want a semantic meaning, USE THE CORRECT SEMANTIC TAG!!! Herpafreakingderp!

 

What's the purpose of finding a new name then? ... and what happened to the guys that created HTML4 Strict? Aren't they the same people running W3C now?

 

I said it right there... same reason you release a flamethrower as a children's toy to promote a movie. Moichendiezing. We put the pictures name on everything.

Not entirely a joke. Having a name nobody else is using and that is not HTML on the marketing blurb means that if people hear about it, and go searching for it, they won't end up on legacy / outdated tutorials or references on the topic. It's not about changing that aspect of the markup apart from adding versioning back in, it's changing how people behave and think about building their HTML.

... and as much as I rail against the use of propaganda techniques, there's a reason I know and recognize them. This new version of HTML isn't about strapping on new features, or bling bling, or any of that -- though it may do so -- It's about changing how people THINK about building their HTML, which means severing the intellectual ties from HTML at the search and documentation level.

I think calling it SSHTML is sufficient to differentiate it. "Semantically Simplified HTML." Still incorporates the HTML name for familiarity, the double-S prevents confusion with SHTML, and people searching for it? If the emphasis is going to be on telling people what to do and how to do it, instead of just "well this is what's possible", we can't have people going to crazy Goog, typing in "HTML 6 tutorial" or "HTML 6 Study course" and landing on legacy trash like W3Fools, Dynamic Drive, or thinking they can/should use mindless idiotic rubbish like jQuery and bootcrap with it.

Hence why documentation -- which needs to be COMPLETE before even having an "official announcement" -- is the most important aspect of this.

In that way I really do have to thank @NetStar for lighting a fire under my ass and providing the most reasonable explanation for it, even if it was a non-answer. It might not have satisfied my question of how Bootcrap is ACTUALLY easier, or better, or simpler, but he illustrated how people might be deluded into thinking it is such.

The reason being something I've actually said for years. The official W3C documentation -- which I hesitate to even call a "specification" -- for people ACTUALLY using these languages on a day to day basis? It's effectively nonexistant. I'm going to come right out and say it: As a "standards body", they have a history of being toothless, rudderless, and utterly inadequate to the task. They do not even address the audience such specifications SHOULD be for. It's like if you were working construction and you documented a fancy new type of corner-join, but both failed to provide any instructions for the poor slobs expected to assemble it, and omitted load tolerances from the data sheet architects would need.

It's part of why HTML is a wild west show, with every know-nothing nube and willfully ignorant scam-artist predator ignoring if not outright flaunting its most basic rules. The problem isn't that HTML is "harder" than bootstrap, or that it can be more inconsistent, but that the standards body is not acting with any form of authority on enforcement, any authority in the language of the documentation, and fails to provide even the most basic examples of proper real-world usage.

As such I shouldn't be attacking bootstrap for its basic ignorance of good practices, flipping the bird at usability and accessibility, or how its creators CLEARLY don't know enough about HTML or CSS to have created such a system in the first place. No, I should be attacking WHY they wanted to create such a steaming pile in the first place, and WHY nubes and rubes alike sing its praises.

... and blame for that clearly falls on the W3C's doorstep and their ALLEGED specifications.

When he said:

That's what HTML is supposed to be, and all those rules I keep mentioning exist to provide that, but NOBODY is paying them any attention. As such they are diving for trash like bootstrap because they never learn enough HTML to find out it is supposed to provide that out of box. The rules of saying "this is a list of selections, this is a paragraph, this is tabular data, this is a heading indicating the start of a subsection of the page, this is a 'rule' indicating a change in topic / section where heading text is unwanted or unwarranted" exist to provide exactly that. The separation of presentation from content is supposed to help with that. Newer CSS features like display:flex, display:grid, and all the new pseudo-states are supposed to help with that. The cascading nature of CSS is supposed to simplify doing that directly. For twenty years we've been ABLE to do these things.

But if you ignore all these things? Because it's poorly documented, because the rule enforcement is nonexistent, because there are hundreds if not thousands of bad tutorials that haven't pulled their noggins out of 1997's rump, because you only blindly copy what others have done because the official source has put next to no effort into the process? Well, then it's easy to see why people get suckered into thinking stuff like bootstrap are actually worth using when it's just creating more work; or get suckered into thinking of W3Schools as a legitimate learning source; or think of themselves not as scam artists because all they've done is peddle other people's lies; having swallowed them hook, line, sinker, and a bit of the rod.

Side note, I ended up writing an article about ARIA. It's going to be part of my "Road to SSHTML" or whatever I call it series of posts. Should have another article up later today.

https://cutcodedown.com/blog/20190812.ARIA_Roles_-_Why_do_these_exist

-- edit --

Also, I'd call it "ZHTML X" if I could find a decent backronym for the Z, and could justify skipping past 6 through 9. Oh wait, Microsoft didn't need a reason to skip 9. They just did it. Kind of like "Wormhole eXtreme." Marketing research shows that people are more likely to be drawn in by titles with an emphasized X in them. That was a joke.

 

More crap. Bootstrap is easier because you don't need to design and style components such as navigation, headers, cards, breadcrumbs, forms, alerts, badges, pagination, popovers, hero ads, carousels, modals, tooltips, ..., etc. Thats why people use it. It's easier and quicker than actually designing it yourself.

 

Oh, you mean the huffing JOB of a designer? But let's assume we have a know-nothing who wants something simple like navigation with a single line of site title on the left, menu on the right, with a hamburger for responsive... Why is this:

    <nav class="navbar navbar-expand-sm navbar-dark bg-dark">
      <a class="navbar-brand" href="#">Expand at sm</a>
      <button class="navbar-toggler" type="button" data-toggle="collapse" data-target="#navbarsExample03" aria-controls="navbarsExample03" aria-expanded="false" aria-label="Toggle navigation">
        <span class="navbar-toggler-icon"></span>
      </button>

      <div class="collapse navbar-collapse" id="navbarsExample03">
        <ul class="navbar-nav mr-auto">
          <li class="nav-item active">
            <a class="nav-link" href="#">Home <span class="sr-only">(current)</span></a>
          </li>
          <li class="nav-item">
            <a class="nav-link" href="#">Link</a>
          </li>
          <li class="nav-item">
            <a class="nav-link disabled" href="#">Disabled</a>
          </li>
          <li class="nav-item dropdown">
            <a class="nav-link dropdown-toggle" href="http://example.com" id="dropdown03" data-toggle="dropdown" aria-haspopup="true" aria-expanded="false">Dropdown</a>
            <div class="dropdown-menu" aria-labelledby="dropdown03">
              <a class="dropdown-item" href="#">Action</a>
              <a class="dropdown-item" href="#">Another action</a>
              <a class="dropdown-item" href="#">Something else here</a>
            </div>
          </li>
        </ul>
        <form class="form-inline my-2 my-md-0">
          <input class="form-control" type="text" placeholder="Search">
        </form>
      </div>
    </nav>

Code (markup):

Any better than:

<div id="top">
	<h1><a href="#">Site Title</a></h1>
	<input type="checkbox" id="toggle_menuAndSearch" hidden>
	<label for="toggle_menuAndSearch"></label>
	<div>
		<ul>
			<li><a href="#"><em>Home</em></a></li>
			<li><a href="#">link</a></li>
			<li><span>Disabled</span></li>
			<li>
				<input type="checkbox" id="toggle_dropdown" hidden>
				<label for="toggle_dropdown">Dropdown</label>
				<ul>
					<li><a href="#">Action</a></li>
					<li><a href="#">Another Action</a></li>
					<li><a href="#">Something else here</a></li>
				</ul>
			</li>
		</ul>
		<form action="#" method="get">
			<fieldset>
				<input type="text" id="search_q" name="q">
				<label for="search_q">Search</label>
				<button>&#x1F50D;</button>
			</fieldset>
		</form>
	</div>
<!-- #top --></div>

Code (markup):

If all you're going to do is cut/paste/include pre-built CSS to go with the pre-built markup. About the only difference is another cut/paste of the custom CSS to do the same thing into your own CSS file, instead of including one file.

... and what do you get in return? Proper document structure, accessibility, easier to add/remove items and clearer for the know-nothing to edit the contents of.

More importantly, it makes it easier for those BUILDING such components, in terms of making them, customizing them, and making it easier for the end user to customize them. Take something as simple as changing the background color and font text. What's easier? Editing the existing CSS (which you don't "do" with bootstrap), or either attempting to hook onto the existing structure new overrides in a new stylesheet, and/or just slopping in more classes to then add even MORE style and MORE code?

You can see this in their own huffing examples, such as the "pricing" one. They wanted to add a border and box-shadow to the top area, something that is not provided OOB by bootstrap.

https://getbootstrap.com/docs/4.0/examples/pricing/

Do what did they do there to add that? Did they simply have a uniform identifier or class to say "this is the top area" so style could be applied in the CSS without even needing to touch the markup? Of course not, that might be easy. Instead they did this:

    <div class="d-flex flex-column flex-md-row align-items-center p-3 px-md-4 mb-3 bg-white border-bottom box-shadow">

Code (markup):

and this in the custom stylesheet:

.border-bottom { border-bottom: 1px solid #e5e5e5; }

.box-shadow { box-shadow: 0 .25rem .75rem rgba(0, 0, 0, .05); }

Code (markup):

where by the methods I advocate, the DIV (if it even existed) would be:

<div id="top">

Code (markup):

REGARDLESS of what effects I was applying, and then if I decide "I want border and shadow on that" I just do this in the CSS:

#top {
  border-bottom: 1px solid #e5e5e5;
  box-shadow: 0 .25rem .75rem rgba(0, 0, 0, .05); 
}

Code (markup):

Without ever again having the need to create classes just because I want to apply a specific presentation.

Even dumber is their throwing display:flex and a slew of flex properties at it when there's nothing TO flex in it as contents or to change based on their equally dumbass "grid measurements". But no, they have to throw those classes and style in there anyways because "reasons".

If you design with semantics, logical structure, and saying what things ARE, NOT what they look like, it's easier to target them to change what they look like and to do hundreds if not thousands of different styles off of ONE markup. You stop needing to edit the HTML altogether just because you change your mind on something stupid like "I want borders on this".

AT BEST the end result of using bootstrap is that the original creator had to use as much if not more code to create it, at worst it screws over the site developer when it comes to something other than the default lazy cookie-cutter, making changes the client asks for, and all whilst flipping the bird at accessibility as the people CREATING these "components" aren't qualified to write a single damned line of HTML.

Hence why idiocy like having the first heading on a page be a H5 tells screen readers, braille readers, search engines, and other non "screen media" users to go F*** themselves. JUST like crapping on a page's accessibility by using px for font-size and max-width

https://getbootstrap.com/docs/4.0/examples/pricing/pricing.css

Tells large swaths of users to go F*** themselves. Just as mixing a px max-width with EM/REM fonts:

https://getbootstrap.com/docs/4.0/examples/checkout/form-validation.css

Feeds users on non-standard default font sizes -- like myself -- broken layouts. A case where they -- the people CREATING their own examples -- clearly do not know enough about HTML, CSS, usability, or accessibility to be building those almighty "pre-built components" much less make the ridiculous claim about how great it is at "cross browser"... since more than half their examples either feed me the wrong max-width for the content resulting in broken layouts, or send me diving for the zoom only to encounter an even more borked page when I zoom in.

But tell me again how much it solves cross-browser issues, particularly since they dropped legacy browsers altogether and there are few if any legitimate cross-browser worries now that flex is real-world deployable that takes anything more than a quarter-k reset to resolve.

The only disadvantage I can really see is that instead of copying massive hard to decipher invalid/gibberish/broken HTML and including a single massive CSS file containing every possible CSS property wrapped in a cryptic class, you're copying simple clean proper HTML AND some CSS in two separate files. Oh noes, not that. At least if you're going to be blindly copying and pasting, is one more ^C^V really so hard given the benefits? Much less that ALL it really seems to accomplish is making those actually creating components or trying to customize them write as much if not more garbage into their HTML, along with more CSS if they want to customize it, to avoid writing the same amount of CSS as those endless classes, pointless wrappers, and other such trash.

But people don't see it that way because nobody -- even those building systems like bootstrap -- seems to know enough HTML or CSS to recognize how broken, backwards, and outright stupid the "class for everything" approach is. Hence how they dupe beginners into copying 5k of HTML that relies on 137k of minified CSS (bootstrap itself) along with 67k of minified JS library (jquery) and 47k of their own minified JS (bootstrap.min.css) to do what can/should be possible in less than 5k of HTML and CSS combined without a lick of JavaScript needed!

Take something simple, a hamburger responsive menu that the user wants the colors changed to blue. (thanks to Durangod over on CodingForums for this one). What's easier?

This broken, gibberish markup:

<nav class="navbar navbar-expand-xl navbar-dark bg-dark"> 
<a class="navbar-brand" href="/">Example</a>
  <button class="navbar-toggler" type="button" data-toggle="collapse" data-target="#navbarSupportedContent" aria-controls="navbarSupportedContent" aria-expanded="false" aria-label="Toggle navigation">
    <span class="navbar-toggler-icon"></span>
  </button>
  <div class="collapse navbar-collapse" id="navbarSupportedContent">
    <ul class="navbar-nav mr-auto">
      <li class="nav-item">
        <a class="nav-link" href="#"><i class="fas fa-home"></i> Home <span class="sr-only">(current)</span></a>
      </li> 

      <li class="nav-item">
        <a class="nav-link" href="#"><i class="fas fa-info-circle"></i> About <span class="sr-only">(current)</span></a>
      </li>
     
      <li class="nav-item">
        <a class="nav-link" href="#"><i class="fas fa-donate"></i> Contribute <span class="sr-only">(current)</span></a>
      </li> 

      <li class="nav-item">
        <a class="nav-link" href="#"><i class="fas fa-download"></i> Download <span class="sr-only">(current)</span></a>
      </li>

      <li class="nav-item">
        <a class="nav-link" href="#"><i class="fas fa-server"></i> Requirements <span class="sr-only">(current)</span></a>
      </li>
      
      <li class="nav-item dropdown">
        <a class="nav-link dropdown-toggle" href="#" id="navbarDropdown" data-toggle="dropdown" ><i class="fas fa-question-circle"></i> Support</a>
        <div class="dropdown-menu" aria-labelledby="navbarDropdown">
          <a class="dropdown-item" href="#">Paid Support</a>
		  <a class="dropdown-item" href="#">Free Support</a>
        </div>
      </li>
      
       <li class="nav-item">
        <a class="nav-link" href="#"><i class="fas fa-users"></i> Team <span class="sr-only">(current)</span></a>
      </li>
    </ul>   
  </div>
</nav>

Code (markup):

That still requires this much custom CSS to override the default styles:

.navbar .navbar-nav .nav-item a {
    color: #8796b4;
} 
 
 .navbar-dark .navbar-brand {
  color: #8796b4;
}

.navbar-dark .navbar-brand:hover, .navbar-dark .navbar-brand:focus {
  color: #ffffff;
}

.navbar-dark .navbar-nav .nav-link {
  color: #8796b4;
}

.navbar-dark .navbar-nav .nav-link:hover, .navbar-dark .navbar-nav .nav-link:focus {
  color: #ffffff;
}

.navbar-dark .navbar-nav .nav-link.disabled {
  color: #6c757d;
}

.navbar-dark .navbar-text a:hover, .navbar-dark .navbar-text a:focus {
  color: #fff;
}


.navbar-dark .navbar-nav .show > .nav-link,
.navbar-dark .navbar-nav .active > .nav-link,
.navbar-dark .navbar-nav .nav-link.show,
.navbar-dark .navbar-nav .nav-link.active {
  color: fff;
}

.navbar-dark .navbar-toggler {
  color: rgba(255, 255, 255, 0.5);
  border-color: rgba(255, 255, 255, 0.1);
}

.navbar-dark .navbar-toggler-icon {
  background-image: url("data:image/svg+xml;charset=utf8,%3Csvg viewBox='0 0 30 30' xmlns='http://www.w3.org/2000/svg'%3E%3Cpath stroke='rgba(255, 255, 255, 0.5)' stroke-width='2' stroke-linecap='round' stroke-miterlimit='10' d='M4 7h22M4 15h22M4 23h22'/%3E%3C/svg%3E");
}

.navbar-dark .navbar-text {
  color: rgba(255, 255, 255, 0.5);
}



.dropdown-item {
  display: block;
  width: 100%;
  padding: 0.25rem 1.5rem;
  clear: both;
  font-weight: 400;
  color: #212529;
  text-align: inherit;
  white-space: nowrap;
  background-color: transparent;
  border: 0;
}


.dropdown-item:hover, .dropdown-item:focus {
  color: #ffffff;
  text-decoration: none;
  background-color: #393835;
}

.dropdown-item.active, .dropdown-item:active {
  color: #ffffff;
  text-decoration: none;
  background-color: #393835;
}

.dropdown-item.disabled, .dropdown-item:disabled {
  color: #6c757d;
  background-color: transparent;
}

.dropdown-menu.show {
  display: block;
}

.dropdown-header {
  display: block;
  padding: 0.5rem 1.5rem;
  margin-bottom: 0;
  font-size: 0.875rem;
  color: #6c757d;
  white-space: nowrap;
}

.dropdown-item-text {
  display: block;
  padding: 0.25rem 1.5rem;
  color: #212529;
}

Code (markup):

That pisses on accessibility by requiring JavaScript to even WORK, or this markup:

<div id="top">
	<h1><a href="/">Example</a></h1>
	<input type="checkbox" id="toggle_mainMenu" hidden>
	<label for="toggle_mainMenu"></label>
	<div id="mainMenu">
		<ul>
			<li class="home"><a href="#"><strong>Home</strong></a></li>
			<li class="about"><a href="#">About</a></li>
			<li class="contribute"><a href="#">Contribute</a></li>
			<li class="download"><a href="#">Download</a></li>
			<li class="requirements"><a href="#">Requirements</a></li>
			<li class="support haskids">
				<input type="checkbox" id="toggle_support" class="toggle" hidden>
				<label for="toggle_support">Support<span></span></label>
				<ul>
					<li><a href="#">Paid Support</a></li>
					<li><a href="#">Free Support</a></li>
				</ul>
			</li>
			<li class="team"><a href="#">Team</a></li>
		</ul>
	<!-- #mainMenu --></div>
<!-- #top --></div>

Code (markup):

and this CSS:

.toggle {
	display:block;
	position:absolute;
	left:-999em;
}

#top {
	text-align:right;
	background:#343A40;
	color:#89B;
}

#top a {
	color:#89B;
	text-decoration:none;
}

#top a:active,
#top a:focus,
#top a:hover {
	color:#FFF;
}

h1 {
	float:left;
	font-size:1.25em;
	line-height:1.2em;
	font-weight:normal;
	padding:0.8em;
}

#mainMenu ul {
	list-style:none;
	white-space:nowrap;
}

#mainMenu > ul {
	padding-right:0.7em;
}

#mainMenu li {
	display:inline;
}

#mainMenu ul a,
#mainMenu ul label {
	display:inline-block;
	padding:1em 0.5em;
}

#mainMenu strong {
	font-weight:normal;
}

#mainMenu li > a:before,
#mainMenu li > label:before {
	font-family:"Font Awesome 5 Free";
	margin-right:0.3em;
}

#mainMenu .home > a:before {
	content:"\F015";
}

#mainMenu .about > a:before {
	content:"\F05A";
}

#mainMenu .contribute > a:before {
	content:"\F4B9";
}

#mainMenu .download > a:before {
	content:"\F019";
}

#mainMenu .requirements > a:before {
	content:"\F233";
}

#mainMenu .support > label:before {
	content:"\F059";
}

#mainMenu .team > a:before {
	content:"\F0C0";
}

#mainMenu .haskids {
	position:relative;
}

#mainMenu .haskids > label:after {
	display:inline-block;
	content:"\25BC";
	font:normal 80%/180% "segoe ui symbol",symbola,sans-serif;
	margin-left:0.4em;
	vertical-align:top;
}

#mainMenu label:hover {
	color:#FFF;
}

#mainMenu ul ul {
	position:absolute;
	left:-999em;
	top:1.75em;
	transform:translateX(-50%);
	background:#FFF;
	box-shadow:
		inset 0 0 0 1px #000,
		0 0 1px #000,
		0 0 0.5em rgba(0,0,0,0.4);
	border-radius:0.5em;
	-moz-background-clip:padding; 
	-webkit-background-clip:padding-box;
	background-clip:padding-box;
}

#top ul ul a {
	display:block;
	padding:0.5em 1em;
	color:#678;
}

#top ul ul a:active,
#top ul ul a:focus,
#top ul ul a:hover {
	color:#FFF;
	background:#343A40;
}

#top ul ul li:first-child > a {
	border-radius:0.5em 0.5em 0 0;
}

#top ul ul li:last-child > a {
	border-radius:0 0 0.5em 0.5em;
}

#mainMenu input:checked + label {
	color:#FFF;
}

#mainMenu input:checked + label span {
	position:fixed;
	top:0;
	left:0;
	width:100%;
	height:100%;
}

#mainMenu ul input:checked ~ ul {
	left:50%;
}

@media (max-width:54em) {

	#toggle_mainMenu + label {
		margin:0.5em 0.5em 0 0;
		display:inline-block;
		padding:0.5em;
		border:0.125em solid #89B;
		border-radius:0.5em;
	}
	
	#toggle_mainMenu + label:before,
	#toggle_mainMenu + label:after {
		content:"";
		display:block;
		width:1.5em;
		height:0.5em;
		border:solid #89B;
		border-width:0.125em 0;
	}
	
	#toggle_mainMenu + label:after {
		border-top:0;
	}
	
	#toggle_mainMenu + label:active,
	#toggle_mainMenu + label:focus,
	#toggle_mainMenu + label:hover {
		background:#457;
	}
	
	#mainMenu {
		overflow:hidden;
		text-align:left;
		transition:height 0.3s;
	}
	
	#mainMenu > ul {
		margin-top:-100%;
		transition:margin 0.3s;
	}
	
	#toggle_mainMenu:checked ~ #mainMenu > ul {
		margin:0;
	}
	
	#mainMenu ul a,
	#mainMenu ul label {
		display:block;
		padding:0.5em 1em;
	}

	#mainMenu ul ul {
		position:static;
		overflow:hidden;
		height:0;
		transform:none;
		padding-left:2em;
		background:transparent;
		box-shadow:none;
		border-radius:0;
	}
	
	#mainMenu ul input:checked ~ ul {
		height:auto;
	}
	
} /* max-width:54em */

Code (markup):

Where the only dependencies is loading font-awesome, and less than 384 bytes of reset. The user wants to further customize the color, DO IT IN THE STYLESHEET instead of crapping in even more classes into the markup.

The real laugh being the first two by the time you add in the excess <script>, <link>, and other such code comes to 5,112 bytes. The latter two combine -- minus the reset since that's the "framework" equivalent -- to 4,744 bytes.

Doing it properly is less code (for the lazy to copy/paste) than you make with the bloody framework! More so it's easier to customize so you don't look like every other lazy copypasta shit who's NOT doing a professional job. It's easier to understand, easier to digest, and fixes all the borked accessibility and cross-browser woes that bootstrap CREATES.

Might even be less code to be copied/created if font-awesome were used with their stock CSS and silly empty italic tags, but I don't do that in my own code since it's another massive pointless bandwidth waster.

The argument of pre-built "components" for the ignorant to blindly copy without understanding could be easily gutted by having a repository of pre-built components of vanilla HTML/CSS built with the proper semantics and structure.

 

You don't get it or you are that thick. The design and styling of your components are already done for you. Thus making it easier and quicker for you to create a web page as you do not need to design your components. Why is that so difficult for you to comprehend? There's nothing to rebuttal here. The design and styling is done for you by bootstrap (Fact. That's the purpose of Bootstrap.).