1. Advertising
    y u no do it?

    Advertising (learn more)

    Advertise virtually anything here, with CPM banner ads, CPM email ads and CPC contextual links. You can target relevant areas of the site and show ads based on geographical location of the user if you wish.

    Starts at just $1 per CPM or $0.10 per CPC.

Why still code HTML/CSS by hand in a text editor in 2019?

Discussion in 'HTML & Website Design' started by Gary-SC, Jun 3, 2019.

  1. #1
    Could someone help me understand why web developers are *still* coding HTML and CSS by hand using a text editor in 2019 when our computing environment is so modernized that we literally drag and drop out of our way for everything else we do on our devices? Why haven't GUI front-end development environments such as Wappler, Webflow, and Pinegrow caught on? Why UNIX command line tools for web development in 2019!?

    I know, I'm a dumb ignorant noob asking all these questions. Still, it is driving me absolutely crazy as I see so many things are just manual and old style. It feels so arse backward to have to type HTML and CSS by hand to build something visual when MS Word can do all of that with the menus and buttons. Why the heck do people think it's natural to design by writing a bunch of text? Why can't I just draw with a digital pen and draw boxes? Why so much hatred toward GUI tools among developers??

    Please, someone enlighten me. I'm so utterly confused that I don't know what to say anymore!
     
    Gary-SC, Jun 3, 2019 IP
  2. deathshadow

    deathshadow Acclaimed Member

    Messages:
    9,732
    Likes Received:
    1,998
    Best Answers:
    253
    Trophy Points:
    515
    #2
    Simple. HTML is about MORE than what it looks like. In fact, if you choose your HTML tags based on their default appearance, you're choosing all the wrong tags fro all the wrong reasons!

    HTML is for saying what things ARE -- grammatically, semantically, structurally -- so that the user-agent (software that turns it into something the user understands. A browser is always a UA but a UA isn't always a browser) can best translate that into something meaningful REGARDLESS of device or user capabilities. This means screen readers (horrible name for software that reads the page aloud), braille readers, puffers (blows morse on your arm), TTY, print... and of course search engines.

    Search engines don't have eyeballs, they don't give a flying f*** about your colors, or font sizes, or layouts, or any of the rest of that bullshit. They care about your logical document structure and semantic layout!

    Using something like Word for web development is a stunning example of how utterly f***ed up your markup can be, what with it vomiting up presentational classes, all the wrong tags, no navigable structure for alternative access... I've never seen anything output by word for HTML/CSS that was worth a flying purple fish.

    You also have the issue of the simple fact not all users have the same screen space, screen size, pixels per inch, resolution, font rendering technologies, space sucked down by browser chrome (the stuff in the browser window around your page, not the Chrome browser, there's a difference) and dozens of other things that gave us both the <link> and <style> tag's "media" attrribute for saying "this is for screen, this is for print, this is for speech", and with CSS3 we now have responsive layouts.

    A good layout should be three things:

    1) Elastic. All fonts, widths, paddings, and margins declared in EM, not PX. EM has no fixed relationship to anything on the computer, and adjusts to the user's font-size preference be it via the browser settings or inherited from the OS. Yes, the normal default on BODY is 16px, but I run 20px. My media center does 24px... and using EM means that it will detect and use that without sending me diving for the zoom, and making sure things all scale evenly / correctly.

    2) Semi-fluid. The normal behavior of HTML block level elements is to expand/contract to fit the available space, it's "fluid" -- Like water. You pour it in a bowl, it becomes the bowl. You pour it in a teacup, it becomes the cup.. You want that so that word-wrap can improve your accessibility. It's also why fixed width layouts -- aka every time someone derps out the question "what width should I design for" -- are an epic /FAIL/ at web design. Hence why drawing a fixed width layout in a WYSIWYG, GUI, or paint program like Photoshop is the fastest way to tell visitors to your page to kiss off. And telling users to kiss off is not a great plan for a successful website!

    So we have fluid, what's the "semi" part? You put a max-width on it so that really long lines of text don't become unwieldy and hard to follow.

    Be water my friend...

    3) Responsive. The new kid on the block. Adding/removing columns, adjusting paddings, re-arranging the entire content so as to best fit smaller displays without having to scroll side-to-side. We USED to use JavaScript for this (it was called mcSwitchy)) but it was a train wreck. Past decade we've now got media queries where we can override our style in the stylesheet depending on screen width. Ideally your break-points should be in EM as well. You use a metric, for the most part try and stick with it.

    Bottom line, a website shouldn't have just ONE appearance. If you are thinking one appearance, one layout, and people using screens only, you've got a LOT to learn.

    Let's take one of my older sites as an example. Needs a refresh, aging poorly, was built when "skeuomorphism" was still all the rage... But it was the very first page I made responsive with CSS3.

    https://ewiusb.com

    Simple little fan page I made to help others with a product that... has some severe issues, and to document various fixes and things they didn't explain the manuals that came with it. Thing is, off of ONE HTML I have multiple appearances.

    Screen readers, braille readers, puffers, TTY, and search engines all really only care about this:
    https://cutcodedown.com/images/ewiUSB/ewiUsbComNoCSS.jpg

    ... and this:
    https://cutcodedown.com/images/ewiUSB/headingOrders.png

    The content, its semantic structure, and the heading orders for alternative navigation. (aka keyboard/mouth-sticks/pressure sticks,three-button interfaces, basically anything that isn't a mouse!) A properly structured document should look something like that with a single H1 as the parent of all content on the SITE, with sibling level H2 for the major subsections. If those sections started by the H2 had subsections, they'd be started with H3. THEY DO NOT MEAN fonts in different weights and sizes.

    Now, if you visit the site odds are good you're seeing something like this:
    https://cutcodedown.com/images/ewiUSB/ewiUsbComNormal96.jpg

    But on the machine I'm on right now, where I'm set for "IBM 8514 / Large Fonts / 20px / 120dpi / 125% / Windows 7 medium / Pick a huffing name already" I am getting this, where the fonts are 25% larger, but nothing else -- like images -- are enlarged.

    https://cutcodedown.com/images/ewiUSB/ewiUsbComNormal120.jpg

    Then we have the responsive aspect of it. All of these different layouts are off of ONE single HTML.
    https://cutcodedown.com/images/ewiUSB/ewiUsbComNormal96.jpg
    https://cutcodedown.com/images/ewiUSB/ewiUsbCom800Wide.jpg
    https://cutcodedown.com/images/ewiUSB/ewiUsbCom640wide.jpg
    https://cutcodedown.com/images/ewiUSB/ewiUsbTinyMobile.jpg

    At some sizes the logo didn't fit and looked like crap resized, so we get rid of it. When the screen is too narrow for columns, start stripping off columns. This way the page is accessibile to EVERYONE regardless of screen size, resolution, font-size preference, or limitations of the device.

    The page even gracefully degrades images off, since it maintains separation of presentation from content.
    https://cutcodedown.com/images/ewiUSB/ewiUsbCom800WideNoImages.jpg

    Is it pretty? no. But it's usable enough that people who disable images to save bandwidth would have zero problem with that.

    HTML is for everyone, it's inclusive. CSS is for saying what things look like for specific cases, which is why we have the media="" attribute on <link>. If you see <link rel="stylesheet"> and there's no media="" or they set media="all", you're likely looking at ignorance, ineptitude, or even just plain apathy.

    You're not going to get all that from a WYSIWYG. If all you are thinking about is what it looks like in your WYSIWYG, you're not thinking at all and have failed to divine the purpose of websites. Worse, you get into certain industries, failing to do any of this could land you in court with massive fines. Trust me on this, I've been the guy called in to fix when people have these problems and have a prosecutor yelling at them for about a decade now. It's a good niche that pays well, assuming the clients haven't been so utterly packed full of manure they refuse to listen.
     
    deathshadow, Jun 4, 2019 IP
  3. Gary-SC

    Gary-SC Member

    Messages:
    101
    Likes Received:
    26
    Best Answers:
    0
    Trophy Points:
    33
    #3
    @deathshadow, I find your argument is compelling, indeed. I will have to spend some time going over these materials and also the articles in CutCodeDown site. I'm even thinking of experimenting with Webflow to recreate your layout and see how the source code will be different from yours to see if it validates what you've been saying.
     
    Gary-SC, Jun 4, 2019 IP
  4. deathshadow

    deathshadow Acclaimed Member

    Messages:
    9,732
    Likes Received:
    1,998
    Best Answers:
    253
    Trophy Points:
    515
    #4
    Good place to start understanding it, the code of webflow's home page. Aka a typical BROKEN inaccessible website that tells visitors like me to f*** off with it's artsy fartsy BS. Hence why cache-empty it takes around 40 seconds to get a usable (though not useful) page here.

    Go to their page, and hit "view source". Now look at EVERYTHING before " <body class="h_body">". First off there's no reason to say class on a body in the markup. You need it for JS from time to time sure, but not in the markup. Much less the body tag is a body? Wow, they really needed to tell us that on a element that's only one nesting deep on the DOM?

    But everything before that is far, far worse. Static style in the markup, blocking scripts in the <head>, endless pointless redundant META not one legitimate UA cares about. META redundant og: meta that WILL fall back to the normal ones if omitted. Overstuffed nonsensical use of the keywords META. data- attributes likely meaning they're doing something stupid with JavaScript that has no reason to be done with... well, JavaScript.

    They have 10k of code before they even get to the flipping content!!! All of it doing less than 1k's flipping job!

    
    <!DOCTYPE html><html lang="en"><head><meta charset="utf-8">
    <meta
    	name="viewport"
    	content="width=device-width,height=device-height,initial-scale=1"
    >
    <meta
    	name="description"
    	content="Build responsive websites in your browser, then host with us or export your code to host wherever. Discover the professional website builder made for designers."
    >
    <meta
    	name="google-site-verification"
    	content="iy6FyGpYh9LOjk-xMM3E0Wk2Ay6cGRGEY6IRbny6xB8"
    >
    <meta
    	property="fb:pages"
    	content="149158061793615"
    >
    <meta
    	name="theme-color"
    	content="#4353ff"
    >
    <link
    	rel="stylesheet"
    	href="template/screen.css"
    	media="screen,projection,tv"
    >
    <title>
    	Webflow
    </title>
    </head><body>
    Code (markup):
    Is about how I'd write that same <head>. Wow, not even 700 bytes. NONE of that garbage belongs there unless they're "throwing more code" at trying to fix a slow page; which is like trying to stop herpes by giving the patient syphilis. If they actually need ANY of the rest of what they have there, they've likely got deep rooted issues that weren't fixed elsewhere.

    Issues like this:

    
        <div class="meganav">
          <div class="html-embed w-embed">
            <style>
              body {
                -webkit-font-smoothing: antialiased;
              }
    
              .nav_dropdown {
                -webkit-overflow-scrolling: touch;
              }
    
              .nav_mobile-back-wrap {
                position: -webkit-sticky !important;
                position: sticky !important;
              }
            </style>
          </div>
          <div class="nav_position">
            <div data-w-id="29f8530e-d318-262b-afa3-32726a79cc9c" class="nav_inner">
              <div class="nav_mobile"><a href="#" class="nav_logo-wrap cc-mobile w-inline-block"><img src="https://assets-global.website-files.com/5b16310a8abd739dc4fad4af/5b1732cfb35dca6d74e4b235_webflow.svg" alt="" class="nav_logo"/></a>
                <div data-w-id="29f8530e-d318-262b-afa3-32726a79cca0" class="nav_lll"></div>
              </div>
              <div data-w-id="29f8530e-d318-262b-afa3-32726a79cca1" class="nav_main"><a href="https://webflow.com/" class="nav_logo-wrap w-inline-block"><img src="https://assets-global.website-files.com/5b16310a8abd739dc4fad4af/5b1732cfb35dca6d74e4b235_webflow.svg" alt="Webflow logo" class="nav_logo"/></a>
                <div class="nav_list">
                  <ul id="nav_items-menu" data-w-id="29f8530e-d318-262b-afa3-32726a79cca5" class="nav_items w-list-unstyled">
                    <li id="nav_features" data-w-id="29f8530e-d318-262b-afa3-32726a79cca6" class="nav_item">
                      <div data-w-id="29f8530e-d318-262b-afa3-32726a79cca7" class="nav-text">Features</div>
                      <div data-w-id="29f8530e-d318-262b-afa3-32726a79cca9" class="nav_dropdown">
                        <div class="nav_mobile-back-wrap">
                          <div data-w-id="29f8530e-d318-262b-afa3-32726a79ccab" class="nav_mobile-back"><img src="https://assets-global.website-files.com/5b16310a8abd739dc4fad4af/5b1767e9269b9c05e6d834fd_L.svg" alt="" class="nav_l" />
                            <div>Features</div>
                          </div>
                        </div>
    
    Code (markup):
    STYLE is invalid inside BODY and causes the browser to have to "start over again" on applying rules and wait for the full body DOM to be created before external style can be loaded. endless pointless classes for nothing. endless pointless DIV for nothing, data- attributes indicating that they are using scripting to do CSS' job, presentational images in the markup where they have ZERO damned business, did we mention the ENDLESS POINTLESS DIV FOR NOTHING?!?

    That's 2k of markup doing 322 bytes job! No joke, if I were writing the same page it would read:

    
    <div id="#top">
    
    	<h1><a href="/">webflow</a></h1>
    	
    	<input type="checkbox" id="toggle_mainMenu" class="toggle" hidden>
    	<label for="toggle_mainMenu"></label>
    	<ul id="mainMenu">
    	
    		<li>
    			<input type="checkbox" id="toggle_features" class="toggle" hidden>
    			<label for="toggle_features">Features</label>
    
    Code (markup):
    With EVERYTHING else they're doing there being something I'd do in the external -- singular -- stylesheet. They are not doing a single blasted thing that in 2019 warrants more markup than that. Basically that one section -- the page title and the beginning of the menu -- is six and a half times the code needed! Worse, that's before we talk about how it is broken for scripting off/disabled/blocked users and is using around 5k of JavaScript to do 1k of CSS' job!

    ... and I bet they thought their version -- which SOMEBODY at SOME point had to write the HTML, CSS, and scripting for -- was somehow the magically "easier', or "faster", or "simpler" approach. Hell their use of numbered headings ALONE is utter gibberish.

    An H1 (unless you use HTML 5's redundant SECTION tag, which they did not) is THE headING (singular) that everything on every page of a site is a subsection of. Just like how in a newspaper or book the title of the document appears in the top left corner of every page or fold-pair. H2 indicates the start of a major subsection of the page, with the first H2 being what should be the start of your main content. (Unless you use HTML 5's redundant MAIN tag, which they did not.). An H3 is to mark the start of a subsection of the H2 preceding it. An H4 marks the start of a subsection of the H3 before it. Care to guess what H5 and H6 mean structurally, grammatically, and semantically. They do not mean fonts in different weights and sizes. It also means jumping straight in with an H4 is going to confuse the f*** out of visitors on alternative navigation.

    Hence it's a REALLY bad idea to do what they did, use DIV+IMG for what should be the H1, and have the first heading on the page be a H2 and then skip straight to H4. This proof positive they do not know enough about HTML to be writing it... and this is their business page trying to convince people to use it?!?

    I mean seriously, this wreck of ineptitude:

    
                    <li id="nav_features" data-w-id="29f8530e-d318-262b-afa3-32726a79cca6" class="nav_item">
                      <div data-w-id="29f8530e-d318-262b-afa3-32726a79cca7" class="nav-text">Features</div>
                      <div data-w-id="29f8530e-d318-262b-afa3-32726a79cca9" class="nav_dropdown">
                        <div class="nav_mobile-back-wrap">
                          <div data-w-id="29f8530e-d318-262b-afa3-32726a79ccab" class="nav_mobile-back"><img src="https://assets-global.website-files.com/5b16310a8abd739dc4fad4af/5b1767e9269b9c05e6d834fd_L.svg" alt="" class="nav_l" />
                            <div>Features</div>
                          </div>
                        </div>
                        <div class="nav_1">
                          <div class="nav_title-wrap-wrap">
                            <div class="nav_title-wrap cc-third">
                              <h2 class="nav_title cc-features">Design</h2>
                            </div>
                            <div class="nav_title-wrap cc-third">
                              <h2 class="nav_title cc-features">Build</h2>
                            </div>
                            <div class="nav_title-wrap cc-third">
                              <h2 class="nav_title cc-features">Launch</h2>
                            </div>
                          </div>
                          <ul class="products_ul w-list-unstyled">
                            <li class="products_li">
                              <a href="https://webflow.com/designer" class="products_link-block cc-designer w-inline-block">
                                <div class="nav_link-inner">
                                  <div class="nav_icon cc-designer"><img src="https://assets-global.website-files.com/583347ca8f6c7ee058111b3b/5b3fef9a95a9f03beadf7e63_designer-white.svg" alt="" class="nav_icon-img" /></div>
                                  <div class="nav_link-bottom">
                                    <h4 class="nav_link-title">Designer</h4>
                                    <p class="nav_paragraph cc-products">The power of CSS, HTML, and JavaScript in a visual canvas.</p>
                                  </div>
                                </div>
                              </a>
                            </li>
    
    Code (markup):
    Another roughly 2k block with another major flaw... headings before the content (bad SEO and gibberish alternative navigation), and if the content is big enough to warrant the use of numbered headings and paragraphs, they STOP being "short grammatical bullet points" -- the meaning of a LI. (list item).

    It's almost like they chose H2, H4, and P based on what they wanted things to look like as if it's still the peak of the 1990's browser wars, instead of actually using HTML properly.

    Whilst there is little reason for that section to be more than:

    
    		<li>
    			<input type="checkbox" id="toggle_features" class="toggle" hidden>
    			<label for="toggle_features"></label>
    			Features
    			<ul class="holds_3">
    				<li>
    					Design
    					<ul class="holds_2">
    						<li class="designer">
    							<span>Designer</span><br>
    							The power of CSS, HTML, and JavaScript in a visual canvas.
    						</li>
    
    Code (markup):
    Since these are just list items. Believe it or not this provides MORE than enough hooks to create that exact same style with better behavior from the CSS, and the result would be more accessible as well. Again, they're using six times the markup needed for such a section. Markup is generally not cached between the same pages on a site, meaning it chews more bandwidth and slows load times. If you move all the "hard work" into a single external stylesheet, subpages can re-use the same style from the cached CSS. This is why people telling you to move style into the <style> tag and to use presentational classes to "speed" things up or make them "simpler" generally are flapping their arse-cheeks in the wind. Maybe if they didn't waste time with six times the markup, ten times the CSS, and four times the number of DOM elements they wouldn't be encountering load and render time issues.

    I don't have the time to recreate their whole page, but what I just showed for rewrites is roughly the markup I'd use if I were to do so... though to be frank I would never design a page that way since that type of "mega menu" is a giant middle finger to usability and accessibility, and worse shoves the content too far down the markup.

    Just as Carlin joked "not every ejaculation deserves a name", not every element in HTML needs four div with five classes around them!

    ... and again, that's their own site, where you'd THINK they'd put the effort in to help show off what they're capable of. Yes, it's very flashy, but from an accessibility, usability, responsive, and general coding perspective, the entire thing is a monument to developer incompetence and ineptitude. They are fortunate the rank-and-file are so easily swayed by "ooh pretty" regardless of the facts. It helps them dupe people into screwing themselves.
     
    Last edited: Jun 4, 2019
    deathshadow, Jun 4, 2019 IP
  5. dojodesign

    dojodesign Well-Known Member

    Messages:
    206
    Likes Received:
    26
    Best Answers:
    0
    Trophy Points:
    140
    #5
    deathshadow nailed it again. One more thing, it's more time consuming to play with all this drag and drop junk, coding, when you have the experience, is way faster.
     
    dojodesign, Jun 5, 2019 IP
    qwikad.com likes this.
  6. Gary-SC

    Gary-SC Member

    Messages:
    101
    Likes Received:
    26
    Best Answers:
    0
    Trophy Points:
    33
    #6
    @dojodesign

    Are you actually saying that as a graphic designer? (Your signature implies that you do logo design.)

    @deathshadow

    I am experimenting with Webflow and also trying the way you described in one of your posts. (ex. start with text page as if nothing else is there, etc. all in text editor) I have to say that Webflow has a steep learning curve...
     
    Gary-SC, Jun 5, 2019 IP
    deathshadow likes this.
  7. deathshadow

    deathshadow Acclaimed Member

    Messages:
    9,732
    Likes Received:
    1,998
    Best Answers:
    253
    Trophy Points:
    515
    #7
    A learning curve that consumes time. Time that could probably be better put towards just learning HTML and CSS. You are learning one way of doing things, that results in a page that's just plain WRONG under the hood.

    Tools of that do a great job of LOOKING like they did a decent job, but it's a facade. The beauty is only skin deep, whilst the ugly runs right to the bone. Often so damned ugly, they're even ugly on the phone... Shabba.

    Again, they often claim to be "easier", but that's just name calling. That might sound odd, but claiming to be somehow "easier" is one of the best propaganda techniques, ranking alongside methods like "25% more than competitors". True propaganda name-calling is not the in your face crass you might find in posts like mine. It's subtle. One of the best is making claims about what you're trying to promote, that implies the opposite of everything else. HTML/CSS bears the brunt of this bit of nonsense ALL THE TIME.

    Words like "easier", "simpler", or phrases like "more productive" aren't just name calling, they're also glittering generalities if they don't actually explain HOW it's easier.

    ... or if they do try and explain, you can bet more often than not they use card stacking in their examples, cherry picking specific issues or even flat out manufacturing bad coding techniques to make their product look better.

    Then of course they try to use the classic "Everyone is using it" . Frameworks love that one. It's the propaganda technique called Bandwagon and it begs the question: Didn't your mother ever ask you what you'd do if all the other lemmings ran off a cliff? Sadly bandwagon in the form of peer pressure is one of the easiest ways to convince the masses of outright lies. It plays to how people will do the most dishonest, immoral, disgusting things in a group they'd never consider doing on their own... and it's why certain forums, certain groups, and certain promotions all do everything they can to maintain an echo-chamber of the faithful. Same reason radical extremist religions use "excommunication" as a threat to keep the mob quiet.

    Comparing the product to others people already use, or including it in their 'features' is known as transfer. Bootcrap despite being easily recognized as a steaming pile of ignorance and ineptitude by anyone actually qualified to write HTML/CSS/JS, is very popular and has lots of fans. By mentioning "our WYSIWYG uses bootstrap on the back end" they hope to transfer those good feelings over; riding its coat-tails as it were.

    Of course the mob is always happy to proclaim how happy they are, so it's easy enough to leverage testimonial to make it look good; but testimonial is always suspect and on its own amounts to nothing more than hearsay. It is a very powerful technique for manipulating opinion, but in reality should rarely be taken at face value.

    You will also find that more often than not such systems will promote themselves using the language of the trade, mated with marketspeak double-talk. This is an aspect of what's known as plain folks. You use the language of the audience, of the trade, to make yourselves sound legitimate and that you are relatable. You're "talking their language", making it sound like you're one of them. Rarely is this true, and it's intentionally crafted by marketers to sound that way.

    Name calling, glittering generalities, card stacking, bandwagon, transfer, testimonial, plain folks... The seven core propaganda techniques you should learn to recognize, determine the intent, and push past to get to the actual facts. The more of them you see, the more likely it is that someone is trying to control the narrative, twisting the truth and manufacturing lies for their own ends.

    Making the most important question, "what are the ends?" -- are they trying to sell you something, do they have a financial interest in having you blindly believe what they're saying? There's a reason the biggest liars are always trying to sell you something.
     
    Last edited: Jun 5, 2019
    deathshadow, Jun 5, 2019 IP
  8. dojodesign

    dojodesign Well-Known Member

    Messages:
    206
    Likes Received:
    26
    Best Answers:
    0
    Trophy Points:
    140
    #8
    I have 17 years of graphic /website design work under my belt. I do have a portfolio for logo design, but I also do website design. Actually the logo design is more of a recent love of mine, I did do some of this during this time for clients who wanted more than just a website, but I got more interested in it at the beginning of 2019. It's really fun to sketch and then trace the designs, and it appeals to my creative side more than the website design work.
     
    dojodesign, Jun 6, 2019 IP
  9. Gary-SC

    Gary-SC Member

    Messages:
    101
    Likes Received:
    26
    Best Answers:
    0
    Trophy Points:
    33
    #9
    In addition to some insights I gained from a few people in this forum, the following advice I received from a friend of mine over the weekend pretty much nails it for me:

    "Learn HTML and CSS by "learning by doing," but you should also go straight to the W3C and read HTML specifications. Learn information design basics by reading the books by Edward R. Tufte, and learn usability basics by reading Jacob Nielsen's book and his organization website; Learn about accessibility by reading W3C specs and reading "Building Accessible Websites" by Joe Clark. My point is that learning the core tech and fundamentals avoid wasting time fiddling with tooling."

    It was my third week of learning HTML/CSS. It was something out of necessity at first, but this stuff is beginning to intrigue me!
     
    Gary-SC, Jun 9, 2019 IP
    mmerlinn likes this.
  10. deathshadow

    deathshadow Acclaimed Member

    Messages:
    9,732
    Likes Received:
    1,998
    Best Answers:
    253
    Trophy Points:
    515
    #10
    Whilst this is -- or at least should be -- good advice, be prepared for the fact it is written in a painfully obtuse legalese. It is one of HTML's biggest problems is that to be brutally frank (Jason? Brutally frank? Say not so!) it reads as if it were written in Finnish, translated by a Russian to Japanese, and then Google translated to an "Engrish moist goodry", that whilst reading it you can almost hear a young Vietnamese streetwalker saying "Me love you long time!"

    You can see this in the simplest of things, like their use of the word "empty." <div></div> is NOT what the HTML specification means by an "empty tag". Empty means it CANNOT hold CDATA requiring a closing tag -- such as IMG, INPUT, BASE, etc -- and not that it doesn't have content. When a word as simple as "empty" can have such a convoluted definition (leading to XML fanboys who still think <div /> is valid XHTML -- it isn't!) is it any wonder that beginners run away from it screaming in terror, and that even many experts misinterpret the simplest of things?

    Another example is the word "deprecated". We're not talking down to those old tags like they were a petulant five year old who won't stop yelling at a fancy restaurant. "to be of lesser value" is the closest dictionary definition to the sense in which they use it. The word makes little to no sense for English language speakers for what likely should actually be "depreciated". As in legacy, outdated, and of no value having no place in modern implementations. Apparently "depreciated" is "too strong a word" -- only further proving how toothless and dottering the W3C can be at times. This is one of the worst aspects of HTML 5, as on top of their "living document" BS and getting rid of having real "versions" tracked on the document side, they have also made the "specification" documentative instead of authoritarian. It documents what CAN be done in modern browsers, instead of being written from the point of view of what those of us writing websites should be doing and/or how to use it properly. Legacy tags and attributes that the people who made HTML 4 Strict would NEVER have allowed into the specification -- EMBED and target="" for example -- being allowed in... with other pointless redundancies like VIDEO and AUDIO also being introduced. They WhatWG -- the group that actually created HTML 5 -- willy nilly introduced redundancies based on what people were doing any-old-way, instead of taking the time to think, reduce the number of unnecessary/redundant tags, and then simply document how all the tags SHOULD be used.

    But no.... Apparently making a specification that actually specifies things is some sort of blaspheme.

    This is only further exacerbated by the fact that the official HTML specification -- and this has gotten worse and worse the past two decades -- simply is not written for use by people who create websites. It's written for the people who make BROWSERS. That's right, THE specification for THE language used to create websites, was not written nor even seems to be for people who will use THE language to create websites.

    Hence why people dive for third party references and tutorials, opening the door to scam artists to try and sell you something because the official standards body dropped the ball so hard it broke their own foot.

    Finding GOOD third party references is tough, but I think the current best is MDN -- The Mozilla Developer Network. Mozilla are the folks behind the Gecko rendering engine that is the core of the Firefox browser. It makes a degree of sense that if the specification was written for browser makers, one of the browser makers might be the best choice to turn it into something digestible for site developers.

    Hence it's currently hard to go wrong with their reference:
    https://developer.mozilla.org/en-US/docs/Web/HTML/Reference

    On the other hand, there are other reference/tutorial sites that reek of web rot, and are created and run by people as unqualified to be telling others how to use HTML or CSS as the halfwits, morons, and fools who create all these simpler "tools" that are in fact the opposite of simple and easy. The poster child for this is a site called W3Schools. It took nearly a decade and a half to get them to even put a disclaimer -- which is buried on their disclaimer page -- that they are NOT affiliated with the W3C in any way, shape, or form... yet after 20 years of their bullshit people STILL think that's the case. Of course they have no real interest in clarifying that since they use their incomplete tutorials, incorrect reference, and shit-ton of bad practices to dupe beginners into shelling out for their equally bullshit "certifications". They are without a doubt one of the worst sources on the web to learn from...

    ... and yet still 90%+ of all "experts" out there blindly point beginners at it. This is because most of these ALLEGED "experts" never bothered learning HTML; despite their wild protestations to the contrary.

    You want proof of how utterly ignorant and incompetent W3Fools is? Take everything you've learned about HTML and CSS so far -- as it sounds like it has now "clicked" for you -- and look at their framework "W3.CSS". If there has ever been a train wreck laundry list of how not to build a website, there it is. But because people point nubes at their site all the damned time, people get suckered into using it. And again, W3.CSS sounds so much like W3C some people even get suckered into thinking it's some sort of "official" part of HTML/CSS. It isn't.

    Once you've learned the basics of HTML/CSS, if you don't know what's wrong with:

    
    div class="w3-card-4">
    
    <header class="w3-container w3-blue">
      <h1>Header</h1>
    </header>
    
    <div class="w3-container">
      <p>Lorem ipsum...</p>
    </div>
    
    <footer class="w3-container w3-blue">
      <h5>Footer</h5>
    </footer>
    
    </div>
    Code (markup):
    Just f***ing stop making websites. Two DIV for nothing, invalid heading depths, H5 that is not starting a subsection and has no H4, H3, or H2 to indicate the start of a subsection of, pointless redundant classes on every malfing DIV, and of course the presentational "w3-blue" class. Leaves me with just one message for W3Fools -- "LEARN HTML!"

    These are all telltales of an outdated site-building methodology we were supposed to stop using 21 years ago. That so many people have just flat out refused to extract their craniums from 1997's rectum is why we end up with so much of these garbage practices still being promoted today. The people making these frameworks and tools do NOT understand enough about HTML or CSS for their techniques, methodologies, or opinions to belong anywhere but either a museum or a funeral pyre.

    NNGroup is still one of the most important sites you can go to in order to learn about REAL design from an accessibility / engineering standpoint. Social engineering is an important aspect of good design, and NN's actual user studies should be taken as the Gospel.

    Which of course is why you mention Jacob Nielsen to most of the twaddles out there calling themselves "professional designers" or "front end coders" their response is either "Who?" or they utterly and totally lose their shit with more insults than I've ever used online, like you walked into their home uninvited, emptied the liquor cabinet, forced yourself on their daughter, and then took a dump in their cornflakes for good measure. I'm not joking either, I've had actual "designers" (aka PSD jockeys) who instantly go on the attack if you even MENTION nnGroup in their presence because it takes everything they do for a living, and renders it meaningless. Many of the articles on nnGroup flat out prove that the people making frameworks, using Photoshop as a "design tool", or playing around in WYSIWYGS are nothing more than... well, do I REALLY have to use those two words again?

    That friend mirroring pretty much what we've been telling you all along. Again as I keep saying, until you have a firm grasp of how things are done in the underlying languages, how are YOU qualified to know what's easier and what isn't? Until you know the basics, you shouldn't be trying to make that type of judgement. The problem is that there are several mental hurdles along the way -- a few of which I can tell you're now jumping over -- that can make the "idea" of something "simpler" automatically become appealing. It is in that moment of vulnerability that these scams -- WYSIWYG's, frameworks, pre-processors, site builders -- thrive. They work their way in, and because you can end up with A result -- ANY result -- it creates that all essential confirmation bias to keep you using them. The problem being that having taken that apparent shortcut you never learn to do it right, don't know that these systems made things harder and take longer, etc, etc.

    Give the average Joe a couple of years of such delusion, and it's hardly a surprise you have people who THINK their sites are great when they've got absolute trash. They end up defending garbage like bootstrap or jQuery tooth-and-nail, to the point that even when it bites them in the ass, they're more willing to blame themselves or put in weeks of work fixing stupid little shit, than admit they were wrong and that the tool itself might actually be at fault! We see it on forums like this all the time, and in many places if you even SUGGEST the framework, or WYSIWYG, or any other tool they are using is causing the problem, YOU suddenly become the problem... because you're rocking the boat and upsetting the allmighty all-precious inviolate status quo. People who say "don't rock the boat" are usually either lazy, stupid, selling something, or a mix of all three.

    As a great character once said: "Life is pain".

    There's a reason I compare it to how religious and political extremists are able to manipulate the masses. It involves all the same tricks, but more importantly results from well documented failures in how the mind works. Specifically confirmation bias and cognitive dissonance. With the brain trying to so so much on a limited amount of wattage, it likes to take shortcuts to accept an answer that gets it on to the next problem. EVEN if that answer is wrong.

    It sounds like you're having the "epiphany" that turns mediocre site owners and incompetent developers into actual experts. Again those "mental hurdles". Sometimes instead of trying to run ahead full bore or trying to go around hoping nobody notices, it helps to just slow down enough to clear it properly.

    It's not a race. Doing things right, properly, and well takes time and work. There's a reason it's called work, and not "Happy Happy fun time". I know we're in the age of instant gratification, but anything worth doing is worth putting in the effort of actually trying. If you don't try, well... that is why you fail.

    Also, remember, Most of us badmouthing these things have either tried them, or been FORCED to work with them either for clients who were suckered, or bosses who are suckers. It's why we're so readily and easily able to provide examples of just how stupid they are. It's not like ANY of us here haven't already been there. Land sake, my first website was built with a WYSIWYG called "Netscape Composer". It was trash. We ALL get suckered by things that LOOK easier at the start. The only question is how long before you realize you've been suckered.

    Sadly for society -- though much to the delight of Amway, Mary Kay, Goop, Trump, anti-vaxxers, anti-gmo, homeopathy, naturopathy, the dirtbag calling himself an avocado, and the Ice Capades -- many people never figure it out.
     
    deathshadow, Jun 10, 2019 IP
  11. MilesWeb

    MilesWeb Well-Known Member

    Messages:
    869
    Likes Received:
    35
    Best Answers:
    7
    Trophy Points:
    173
    #11
    Here are few reasons why developers still code HTML/CSS by hand in a text editor in 2019:
    • This is because many times the WYSIWYG tools and page builders don't generate good quality of code.
    • These tools come integrated with inherent design limitations and only provide the flexibility provided by the backend drag-and-drop features.
    • If you learn and code using WYSIWYG tools you won't learn web development but just learn to drag-and-drop things.
    • You don't get much control over the finished project while using a page builder and also a developer lacks the uniqueness of getting empowered from manual design and development.
     
    MilesWeb, Jun 10, 2019 IP
  12. Gary-SC

    Gary-SC Member

    Messages:
    101
    Likes Received:
    26
    Best Answers:
    0
    Trophy Points:
    33
    #12
    Why are they jumping from h1 to h5? Why didn't they just style the core elements? Ex. I can style <h1> itself to look like that. No need to wrap with another tag and two classes to do what they are doing here as far as I could tell. All the other examples on that page remind me of what I saw in the MASSIVE CSS file Webflow vomited to render a simple layout. I figured they were probably throwing in every CSS definitions they can imagine covering all the basis regardless of whether I am actually using any of them. I guess that's what frameworks do. What a convoluted way to style a page!!

    And yes, it "clicked" for me once I saw HTML differently. HTML is not about visual layout and eye-candies. It's about contents and how it's structured. I learned that separating two aspects of a web page (content and appearance) allows me to reuse a single HTML document in multiple ways (screen vs. print, various screen sizes, screen vs. screen reader, etc.). And not to mention Webflow drag & drop was a massive FAIL to do any of that properly. I think it was good, though, for me to try it myself for real and experience how wrong their approach really is.

    Good point. I even see an interesting parallel between writing HTML/CSS and writing in general. There is no "easy way" out of knowing how to write. There is no way I could write well by dragging and dropping prefabricated paragraphs.
     
    Gary-SC, Jun 10, 2019 IP
  13. Gary-SC

    Gary-SC Member

    Messages:
    101
    Likes Received:
    26
    Best Answers:
    0
    Trophy Points:
    33
    #13
    I found all these points to be true in my Webflow experiment last weekend. I concluded that coding HTML/CSS by hand correctly was the only way to do it right at the end, and I also found that "visual coding" as a concept was far off the mark, to begin with.
     
    Gary-SC, Jun 10, 2019 IP
  14. deathshadow

    deathshadow Acclaimed Member

    Messages:
    9,732
    Likes Received:
    1,998
    Best Answers:
    253
    Trophy Points:
    515
    #14
    Because they are choosing their tags based on their default appearance, NOT their structural / semantic meaning.

    I think a history lesson to explain how we got into this mess might help.

    There was a period about 20 years ago -- it was called the "browser wars" -- where Microsoft and Netscape went to war over who's browser would control the web. CSS hadn't even been invented yet though the early rumblings were there, and websites looked... well, rather plain. People started wanting their sites to look fancy so both browser makers started adding presentational stuff to the specification. There were a bunch of tags that were "browser specific" like MARUQEE, and others that were adopted into HTML 3 such as FONT and CENTER. To make columns people started abusing the TABLE tag.

    I mean, go back to the HTML 2. specification's reference:
    https://www.w3.org/MarkUp/html-spec/L2Pindex.html

    A lot of tags missing, aren't there? Didn't even exist yet. Also notice there's no way to align text left/right/justify, no attributes for setting colours. It was expected that HTML would be used JUST to create your grammatical / structural meaning of pain jane hypertext following professional writing norms.

    So the browser makers -- without the W3C's blessing -- started adding their own crap such as FONT, CENTER, ALIGN, BGCOLOR, LINK, VLINK, and hosts of other presentational nonsense that resulted in fat bloated markup, but worse, meant anyone not on a desktop resolution screen was told to go f*** themselves. Eventually the W3C relented and released the abortive MESS that became HTML 3.2, and by extension HTML 4 transitional. Transitional in this case literally meaning "transitioning from 1997 to 1998 coding practices".

    It got so ridiculous that what we saw was HTML like this:

    
    <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
    <HTML>
    	<HEAD>
    	<META
    		HTTP-EQUIV="Content-Type"
    		CONTENT="text/html;charset=windows-1252"
    	>
    	<TITLE>HTML 3.2 style coding demo</TITLE>
    	</HEAD>
    	<BODY BGCOLOR="#112233" LINK="#4488CC" VLINK="#778899" ALINK="#8888FF" TEXT="#000000" BACKGROUND="images/bodyBackground.bmp">
    		<CENTER>
    			<TABLE WIDTH="768" BORDER="0" CELLSPACING="0" CELLPADDING="16">
    				<TR>
    					<TD>
    						<TABLE WIDTH="736" BORDER="0" CELLSPACING="0" CELLPADDING="8">
    							<TR>
    								<TD COLSPAN="5" ALIGN="CENTER" BGCOLOR="#224488">
    									<A HREF="/index.php">
    										<FONT FACE="arial" SIZE="+3" COLOR="white">
    											JEDIT
    										</FONT>
    								</TD>
    							</TR><TR>
    								<TD WIDTH="20%" ALIGN="center" BGCOLOR="#336699">
    									<A HREF="/index.php">
    										<FONT FACE="arial" COLOR="white">
    											Home
    										</FONT>
    									</a>
    								</TD>
    								<TD WIDTH="20%" ALIGN="center" BGCOLOR="#336699">
    									<A HREF="/index.php">
    										<FONT FACE="arial" COLOR="white">
    											News
    										</FONT>
    									</a>
    								</TD>
    								<TD WIDTH="20%" ALIGN="center" BGCOLOR="#336699">
    									<A HREF="/index.php">
    										<FONT FACE="arial" COLOR="white">
    											About
    										</FONT>
    									</a>
    								</TD>
    								<TD WIDTH="20%" ALIGN="center" BGCOLOR="#336699">
    									<A HREF="/index.php">
    										<FONT FACE="arial" COLOR="white">
    											Forums
    										</FONT>
    									</a>
    								</TD>
    								<TD WIDTH="20%" ALIGN="center" BGCOLOR="#336699">
    									<A HREF="/index.php">
    										<FONT FACE="arial" COLOR="white">
    											Links
    										</FONT>
    									</a>
    								</TD>
    							</TR><TR>
    								<TD ALIGN="left" COLSPAN="3" bgCOLOR="#DDEEFF">
    									<h2>
    										<FONT FACE="arial">
    											Content Section Title
    										</FONT>
    									</h2>
    									<FONT FACE="arial" COLOR="#224466">
    										Your page content would be here.
    									</FONT>
    									<br><br>
    								</TD>
    								<TD ALIGN="center" COLSPAN="2" bgCOLOR="#AACCEE">
    									<h2>
    										<FONT FACE="arial">
    											Sidebar Section Title
    										</FONT>
    									</h2>
    									<FONT FACE="arial" COLOR="#224466">
    										Sidebar content
    									</FONT>
    									<br><br>
    								</TD>
    							</TR><TR>
    								<TD COLSPAN="5" ALIGN="center" BGCOLOR="#224488">
    									<FONT FACE="arial" SIZE="-1" COLOR="#DDEEFF">
    										Disclaimer text here, &copy; whoever.
    									</FONT>
    								</TD>
    							</TR>
    						</TABLE>
    					</TD>
    				</TR>
    			</TABLE>
    		</CENTER>
    	</BODY>
    </HTML>
    
    Code (markup):
    That's not a joke. That is how everyone was writing HTML 22 years ago... and if you think that's bad, you should have seen the tricks people pulled (and still pull with HTML e-mails where CSS ranges from incomplete to nonexistant) to use image files to create styled borders. Even when we got CSS, it was years before we had border-radius or box-shadow so separate image files had to be used and added to the markup (typically with more TD and IMG tags, or using background-image on endless DIV) To achieve such styles.

    Now, that train wreck might be hard to follow, but there were certain rules -- like inline level tags such as FONT not being allowed to wrap block or special tags like DIV, TABLE, TR, TD, etc, etc -- That are why if you wanted the whole document in Arial and you wanted "correct" code that worked in all browsers, you were saying <font> every time you started to write phrase-level content and </font> before you closed the block level parent.

    Needless to say, CSS was a god-send, and with HTML 4 Strict -- aka the "real" HTML 4. All the presentational tags and most of the attributes were "deprecated", aka removed from the specification on the grounds of being redundant, bloat, and harder to work with. Because there were new features and a ton of old websites, HTML 4 "transitional" was created so that the new stuff could be used on old pages, but all new websites would/could/should have been written with HTML 4 Strict and using CSS for style.

    So what happened from around 1998 to 2008? The vast majority of people refusing to embrace 4 Strict and CSS properly just kept on vomiting up HTML 3.2 as 4 Tranny, but using CSS to "correct" the handful of things HTML 3 couldn't do on its own.

    The thing is though, does this methodology look familiar? Saying every blasted time on every blasted element what things look like? You found the answer!

    Bingo. More than that, they use classes to replicate all the bloat and bad practices of HTML 3.2 / 4 Tranny. They assume they need all these extra DIV tags because they see everyone else do so, and you needed all those extra tags to apply styling prior to 1998. When I say that HTML/CSS "frameworks" replicate the worst parts of browser wars era HTML 3 I'm not kidding.

    I've said it many times, the people who vomited up HTML 3.2 style methodology with the 4 Tranny doctype on top, now just slap the HTML 5 lip-service around it and pat themselves on the back over how "modern" they are. Even as they basically continue to use practices over two decades out of date on every damned line of code.

    To that end, there is ZERO difference in methodology, mindset, or application between:

    
    <center>
    	<table border="0" cellspacing="0" cellpadding="8">
    		<tr>
    			<td width="33.33%" align="center">
    				<font color="green">Small column</font>
    			</td>
    			<td width="66.67%" align="center">
    				<font color="red">Large Column</font>
    			</td>
    		</tr>
    	</table>
    </center>
    
    Code (markup):
    and...

    
    <div class="w3-row w3-display-middle">
      <div class="w3-col m4 l3  w3-green w3-center">
        <p>Small Column</p>
      </div>
      <div class="w3-col m8 l9 w3-red w3-center">
        <p>Large Column</p>
      </div>
    </div>
    
    Code (markup):
    Other than the broken attempt at the latter being "responsive". They are using presentational classes and DIV to do what people used to use tables for. In the process, they completely miss the intent/improvements of HTML 4, the purpose of CSS, and basically have shoved their craniums so far up 1997's rectum that we need to call an orthodontist to handle the extraction!

    Yup, the industry term for it is "separation of presentation from content". The laugh is some people -- back end coders -- hear the term and think it has something to do with server-side separations of concern, such as the totally proactive "model view controller" 'paradigm'. It doesn't. It's often comical when they find out that client side can be less code they have to hack up into turning a HTML template into a PHP/ASP/node.js one in their code, and how 90%+ of the crap most "designers" hand them is just making their life harder too.

    You've likely not encountered this yet, but it explains how a lot of this "a class on every damned thing" isn't as hard once you get server side code involved. If we were making a menu where we went full Pakled on classes and then make a PHP template function, the "worst case" scenario you'd see ends up coded like this with all the classes and ID for nothing, opening and closing PHP willy nilly, using multiple echo to do one echo's job, etc, etc:

    
    <?php
    
    $menuItemIndex = 0;
    
    function template_menuItem($link, $text) {
    global $menuItemIndex;
    $menuItemIndex++;
    ?>
    		<li class="menuItem menuItem_<?php echo $menuItemIndex; ?>" id="menuItem_<?php echo $menuItemIndex; ?>">
    			<a href="<?php echo $link; ?>" class="menuLink"><?php echo $text; ?></a>
    		</li>
    <?php} ?>
    
    Code (markup):
    Not only are they throwing classes and ID's in there for f*** knows what, their entire PHP methodology is a train wreck for what -- if we clean up both the HTML and the PHP -- could simply have been:

    
    <?php
    function template_menuItem($link, $text) {
    	echo '
    		<li><a href="', $link, '">', $text, '</a></li>';
    }
    
    Code (markup):
    Which one is easier for the guys writing server-side code is "easier" for them to work with? More so, which one do you think is going to chew up more of the server's time? Servers on successful sites have to spend massive amounts of time processing that code for each and every user. Using more code, requiring more computation, etc, etc all adds up over time to increased hosting costs.

    The laugh being the idiots who defend said practices keep saying that "the database is the real bottleneck so it doesn't matter". If that were true, then how did PHP 7 magically make Wordpress and Joomla so much faster overnight? Yes, database is a good chunk of the load, but it's not the only place heavy load comes from. Hence why such garbage front-end practices dump a giant load on everyone involved!

    It all cascades from that initial markup. That's why it needs to be considered the foundation on which everything else is built... and why all the people out there saying it's "not that important" , or saying "it's not a real programming language", or trying to make it "simpler" with visual tools all clearly have no clue what HTML is, what it is for, or how to use it!

    As you seem to have discovered. Eye-opening, isn't it?
     
    Last edited: Jun 10, 2019
    deathshadow, Jun 10, 2019 IP
  15. 137th Gebirg

    137th Gebirg Active Member

    Messages:
    70
    Likes Received:
    0
    Best Answers:
    0
    Trophy Points:
    91
    #15
    To the OP, I still hand-code everything. HTML, CSS, JavaScript, back-end languages, everything. Why? Because coders who rely solely on IDE's and "frameworks" to write their code for them don't actually know how to code. When they run into something that their framework can't do out of the box, they're stuck and get wrapped around the axle. A fully operational knowledge of language syntax is requisite to solving pretty much any problem. If you don't have that foundation and frame-of-reference, you will hit an insurmountable brick wall sooner or later. I only ever use libraries like MooTools and JQuery when I absolutely need to - AJAX and custom interface widget behaviors come to mind there. Aside from that, it's all me.
     
    137th Gebirg, Jun 11, 2019 IP
  16. Gary-SC

    Gary-SC Member

    Messages:
    101
    Likes Received:
    26
    Best Answers:
    0
    Trophy Points:
    33
    #16
    HOLY CR@P. Are you saying these snake-oil-selling BOZOs are spending all their time building tools that are nothing better than junk that merely replaces some 20-year-old <TABLE> tags with <div> and the old farty inline styling tags with a truckload of presentational classes!?!? WTF!?!? This is not just insane, this is UNETHICAL. Why the hell are they trying to stall the progress!?!? Heck, I might be a noob, but I know by now at least the cleverness of being able to write something like "#nav a {color: #999;}" could transform the ENTIRE SET of <a>s to use that color without having to slap the same damn class on every friggin' one of them under #nav. That's one of the damn things Webflow didn't even let me do without stupid workarounds that should be unnecessary, to begin with. The history lesson makes a perfect sense. It explains where the current common practices come from. It seems to me like it's a classic case of people utterly unable to get out of habit and being lazy.

    I don't know anything about programming yet, but I can easily tell that the second example is a lot more concise and likely much less effort to write. :)

    I have wondered about the performance implication of all these things. It's one thing to compare merely by file size, but is it possible that maybe the effect of having so many presentation classes overlapping each other have an exponential negative effect on how fast a site loads because of the processing a browser has to do? See, I've come across a site that stalls on me despite a fast internet connection. Maybe all of these things the bozos are doing to us are causing them?

    Hell it IS!! Hits just keep on coming. I'm glad I'm learning all these things.
     
    Last edited: Jun 11, 2019
    Gary-SC, Jun 11, 2019 IP
  17. Gary-SC

    Gary-SC Member

    Messages:
    101
    Likes Received:
    26
    Best Answers:
    0
    Trophy Points:
    33
    #17
    That's interesting, because I have indeed heard of people who can put together a responsive layout with Bootstrap but they couldn't do so without it. I guess they just know which Bootstrap components do what, but they don't know how that worked in code?
     
    Gary-SC, Jun 11, 2019 IP
  18. mmerlinn

    mmerlinn Prominent Member

    Messages:
    3,197
    Likes Received:
    818
    Best Answers:
    7
    Trophy Points:
    320
    #18
    And a hell of a lot easier to debug.

    The more manure you need to shovel, the longer it takes to shovel it. That is true in ALL aspects of life. Just ask any farmer who needs to shovel manure.
     
    Last edited: Jun 11, 2019
    mmerlinn, Jun 11, 2019 IP
  19. deathshadow

    deathshadow Acclaimed Member

    Messages:
    9,732
    Likes Received:
    1,998
    Best Answers:
    253
    Trophy Points:
    515
    #19
    Exactly that. They are using classes to recreate techniques we've been told for over two decades to stop using... and yes, it does border on if not outright feel unethical which is why there's such outrage from those fighting against such practices.

    It's also where -- despite many improvements -- HTML 5 has created an equal measure of distaste as in certain places it ignores or flat-out undoes the progress HTML 4 Strict offered us; by either re-introducing redundancies that we were trying to get rid of to make it simpler, or by actively encouraging practices (like those new "structural tags") that amount to little more than the type of outdated and outmoded document structure we're talking about.

    Dan Schulz -- a dearly departed (passed in 2009) close friend, student of mine turned mentor, and something of a legend 'round these parts used to say that "The people who just wrapped endless pointless tables around everything, now just wrap endless pointless div using classes to do the same thing". It's where I got that "endless pointless" phrase I use far, FAR too often from. Today those endless pointless DIV have been replaced by HEADER, FOOTER, MAIN, SECTION, ARTICLE, NAV, and ASIDE whilst STILL offering no real improvement in accessibility, usability, or simplicity. It's as if the WhatWG (the group that actually made HTML 5) not only failed to grasp the point of HTML 4 Strict, they carefully and methodically tried to find a way to justify using all those extra elements regardless of if they were useful or not.

    Much like this "Aria role" nonsense that adds NOTHING of value to pages for 99.9999999% of actual legitimate users, and again typically doubles the amount of code you have to write wrapping your content. It's so mind-numbingly stupid that you'll actually see people write garbage like:

    <section aria-labelledby="KittensHeader">
      <h2 id="KittensHeader">All Abbout Kittens</h2>
      <p>Lorem ipsum dolor sit amet, consectetuer adipiscing elit.</p>
    </section>
    Code (markup):
    It's like... wow, no shit. the content after the H2 is described by the H2? ISN'T THAT WHAT FLIPPING HEADINGS MEAN!?! Worse than that, you start to get into outright derpitude like:

    <form role="form">
    Code (markup):
    Or WORSE:

    <div role="form">
    Code (markup):
    That's how unbelievably and mind-numbingly STUPID this whole "Aria" BS is.

    Though Aria really was created for a group I call "microformat junkies". These fools who think that HTML isn't complicated enough, that content cannot be self explanatory, and that every blasted wrapper or even word REQUIRES extra tags and descriptions around it above and beyond those of professional writing norms. They came up with their own little bullshit format for doing so that in pretty much every usage case is only actually meaningful to "data scrapers". "Data scrapers" being a polite name we use for CONTENT THIEVES.

    There are SO many things in 'newer' specifications that flat out show beyond a shadow of a doubt that the people making these "specifications" don't know enough about HTML to be making diddly squat! Why? Because they've not updated their skills since -- and/or not learned anything newer -- than 1997.

    Sooner or later you have to let the content itself stand up on its own. I swear these clowns won't be happy until every blasted word in a sentence has a tag around it. I'm waiting for them to suggest stupid nonsense like <verb>, <noun>, and <adjective> tags. That's how crazy that particular rabbit hole is getting, those in favor of such nonsense they just keep digging further down. Talk about some fools in desperate need of an unbirthday; and when that day comes I shall futterwacken... vigorously. Of course their methods makes us angry, we're all mad here!

    Though I often think the language used is as much to blame. "HTML 4 Strict" -- the word "strict" is intimidating to beginners, when it is in fact easier, simpler, smaller, and more concise than 4 Transitional or even 5. There is a reason a LOT of developers will tell you "write for 4 Strict, deploy as HTML 5". That way you can use all the useful stuff from 5 such as the smaller and simpler <head> contents or improved input types, and tags forced upon us such as VIDEO and AUDIO (even though they are essentially redundant to OBJECT) whilst still maintaining the good practices and narrowed focus that we were handed 20 years ago.

    It is REALLY disturbing how so much of what people are calling "modern" and "good practices" are nothing more than the worst of what was the norm from 1995 to about 2003.

    Precisely that. The more code there is, the more code the server has to processs, the more code the browser or other UA has to process, so the bigger the impact. Even classes by their mere presence introduce excess overhead, which is why the LIES currently being mindlessly parroted about moving your presentation into the <style> tag and throwing a class on each and every damned thing you want to style are so frustrating. Anyone tells you that using twice or more the markup is going to make pages faster is talking out their arse; and I don't care who's huffing saying it.. even if it's Google.

    Google has this tool called "pagespeed insights" that USED to be a useful assessment of problems with a page. But that usefulness has been utterly compromised by their pulling a bait-and-switch turning a one useful tool for site owners and developers into nothing more than a marketing scam to sell you their "pagespeed insights service" or a CDN. Rather than talking about file sizes, file counts, actual loading time penalties, DOM complexity, code complexity, excess rules, etc, etc... they now run their mouths about dicking with caching models, moving static files to CDN's, the sizes of images they themselves provide from their own damned advertising service, moving style from your external CSS to <style> tags on each and every damned page, and hosts of other bullshit that has dick-all to do with ACTUALLY making websites load faster.

    ... and as always, because it's a big name in the industry saying it, it's basically forbidden to even question just how stupid it all is. Again, almost like religious extremism and how they isolate, control, and manipulate their faithful. It's all about control when their reputation and money is on the line.

    They are certainly a contributor. Internally the browser turns HTML into something called the "DOM" -- document object model. It's basically a memory structure that contains not only information about the element from where it is in the document to it's style, but also has "pointers" which help build a tree-like structure of parents, siblings, and children. This "tree" can be accessed from JavaScript and directly manipulated and is part of how browsers render the page.

    Large numbers of tags mean large numbers of DOM elements. Large numbers of classes mean bigger lists of elements used to index and speed up the application of style. They all add up to a larger and heavier memory footprint... and it is for these reasons the LIES about loading up on classes and slopping STYLE into the markup hold water like a sieve. The ONLY way such nonsense actually seems to end up "faster" is if you're already using two to ten times the code you should be using in the first damned place.

    ... and when I say that, I generally mean for the exact same if not better appearance with the same or better functionality and/or accessibility!

    More importantly, the claims about "render time" -- aka from the time the HTML is loaded and turned into a DOM to when the page is drawn in the browser and is ready for the user to use -- are utter and complete nonsense. Why? Because if a 40mhz 386 with 8 megs of RAM running Windows 3.1 and IE 5.01 can handle basic CSS and table based layouts in a more than acceptable amount of time, they can take their claims and stick 'em when even the cheapest crappy Chinese phones come with 32 times as much RAM and run at 25 times the clock speeds!

    Though the biggest contributor to a slow page load is one rarely discussed or planned for. File counts and ping time.

    Every time you have another file on a page, the browser and server have to perform a "handshake", a back-and-forth process of saying "Do you have this file?", "Yes I have that file, it's xxx old.". Browser checks its cache to see if the cached copy is older than the new one, if it is "ok, send me that new file". Each of those methods basically take your ping time to the server and ping time from the server to you to occur. Browsers and servers can perform multiple requests simultaneously back-and-forth, but in a lot of cases that number of simultaneous connections are limited -- either from the server being overburdened with requests, or other users on the same network as you banging up against your ISP or OS connection limits.

    Dicking with the cache control times CAN somewhat alleviate this, but caching only gets you so far over time since even if you say "don't delete this" the browser still may if the last access date is old enough.

    The "rule of thumb" is that under ideal circumstances you treat the first 8 files as "free", and then take the remaining files and assume they take 200ms (a fifth of a second) apiece. So a page made from 38 separate files when the cache is empty (a first time visit) adds six seconds of overhead to the first time visitor. (38 - 8) / 5 == 6. A page made from 128 separate files is looking at 24 seconds.

    But beware that's the real-world AVERAGE. A lot of people will get that down to 50ms a pop if they're on fiber and the same backbone, whilst a lot of users on crappy connections (like US cable connections from the likes of Spectrum or Time Warner) could be looking at a second or MORE per file... suddenly that page made from 128 separate files takes two minutes to finish!

    These time penalties having dick-all to do with your connection speed. You might have a dream 10 gigabit width connection that once file transfer has started can pull down a 2 hour 4k movie in 3 minutes flat, but STILL end up having websites built from hundreds of files that take minutes to finish loading!

    This is why the "but it's fast for me" excuse should typically be met with "well lah-dee-huffing-dah for YOU! It's taking two minutes here because you've got too many damned files!"

    I think that's part of where the LIE of not using or reducing external CSS files comes from, but if you use just ONE CSS file instead of twenty, that's more than enough to eliminate the problems. Same with the number of separate scripts. Thing is, if the CSS / presentation is in an external file, and you use one CSS file for the entire SITE, that CSS can be cached meaning even if it negatively impacts the first cache-empty visit, it is already present when the user visits another page. This means the ONLY thing that needs to be transferred when the user navigates to other pages on your site is the new markup and/or any content media (images/movies/audio/etc). THAT is leveraging caching properly and has far more impact than dicking around with the cache-control headers on the server.

    There are even techniques -- such as sliding doors, the incorrectly named "CSS Sprites", and webfonts for vector image storage -- that let you reduce the number of separate images by combining them into single files. Again reducing the file count.

    Again, if people used 20k or less HTML for 10k of plaintext and a dozen content media, with 48k or less CSS in one file, and 64k or less (after minification) of JavaScript, MAYBE they wouldn't be so gullible when it comes to such claims.

    I even have a forumula for HTML size that generally explains what the code SHOULD be based on the use of proper semantics and the leveraging of CSS selectors:

     Expected HTML size in bytes = 2048 +
                         plaintext * 1.5 +
            content media elements * 256 +
                     form elements * 128 +
                           anchors * 128
    Code (markup):
    If a page exceeds that by a few percent, it's probably ok. If it's more than double those numbers, it is entirely possible the code is utter and complete crap. There are only a handful of cases where going beyond that is acceptable. For example, let's use my own web dev site's main page as an example:

    2048 + (4170 bytes plaintext * 1.5) + (4 content images * 256) + (0 form elements) + (35 anchors * 128)

    That page's HTML should be 13,807 bytes. The total HTML used on the main page at this moment? 11,405 bytes. So we're golden.

    Now let's look at the main page for Webflow -- their own website.

    2048 + (4409 bytes plaintext * 1.5) + (4 content images * 256) + (2 form elements * 128) + (99 anchors * 128)

    So we should expect 22,614 bytes. Their code size? 157,436 bytes.

    If that's not developer ignorance, incompetence, and ineptitude, I don't know what is. That's seven times the code needed to do the job! Don't even get me STARTED about their megabyte of CSS on a site that has no reason to use more than 48k, or their 2 megabytes of JavaScript spanning 23 separate files... and for what? Some goofy animated BS as marketing flash to cover up for a lack of "content of value"? /FAIL/ hard.

    ... and that's the site they're trying to use to convince people to use it? I mean FFS they can't even get the use of numbered headings proper.

    https://cutcodedown.com/images/webflow_invalidStructure.png

    Again, the people MAKING these tools don't know enough HTML or CSS to be building websites, much less instructing others on how to do so or creating tools to "simplify" the process.

    ... and they use classes to recreate techniques we've been told for two decades to stop using.

    
          <div class="hp_track cc-hero">
            <div class="dbl_visuals-wrap w-hidden-medium w-hidden-small w-hidden-tiny">
              <div class="dbl_view cc-sticky">
                <div class="hp_wrapper-site">
                  <div class="dbl_visual-wrap">
                    <div class="dbl_shadow"></div>
                    <div data-w-id="d198a8a7-8a16-80f9-e12f-4a1c1178cf17" style="display:block" class="dbl_design-wrap">
                      <div class="dbl_canvas">
                        <div data-w-id="d198a8a7-8a16-80f9-e12f-4a1c1178cf19" class="dbl_ui-overlays">
    
    Code (markup):
    Might as well put a bullet in the temple at that point.

    ... and yes, I would say there's only FOUR content images present. Everything else there is presentation and has no business in the HTML.
     
    Last edited: Jun 11, 2019
    deathshadow, Jun 11, 2019 IP
  20. Gary-SC

    Gary-SC Member

    Messages:
    101
    Likes Received:
    26
    Best Answers:
    0
    Trophy Points:
    33
    #20
    @deathshadow

    I am beginning to wonder how many users out there even pay attention to their graphics and animation. I know I don't stop to look at animation and go, "WOW, that is SO KEWL!!! Let's see that AGAIN!!!" I look at Webflow's official site now, and I can't help thinking that it doesn't say much about what they do. Just a bunch of fancy graphics, animations, and flashes.

    I guess my view on this web site design stuff has changed completely.
     
    Gary-SC, Jun 15, 2019 IP
    deathshadow and kk5st like this.