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.

Extremely slow site!

Discussion in 'HTML & Website Design' started by CactusWren, May 10, 2020.

  1. #1
    Can anyone tell what's going on here?

    This is a new Wordpress installation, one-page site. I'm using Smush on the images and WP Super Cache. Images are a total of about 1300KB a think. It's hosted on GoDaddy (unfortunately).

    Pingdom's latest test said it loaded in 2.5 seconds, but it took about 10 to load from my computer. The site has a 1400 ms wait time.

    http://www.jfblawaz.com/
     
    Solved! View solution.
    CactusWren, May 10, 2020 IP
  2. mmerlinn

    mmerlinn Prominent Member

    Messages:
    3,197
    Likes Received:
    818
    Best Answers:
    7
    Trophy Points:
    320
    #2
    Well with 22 javascript files and 16 stylesheets being loaded the handshaking time is atrocious. Without looking at them I would be willing to bet that most of that is duplicated code several times over. At any rate that is definitely one of the slowdown issues.

    Took 10 seconds to load for me, too.

    Further, LIGHT GRAY text on WHITE background is IMPOSSIBLE to read, and FAR BELOW accessibility standards as espoused by WCAG. Font size is too small, too.

    For more info talk to @deathshadow.
     
    mmerlinn, May 10, 2020 IP
    sarahk likes this.
  3. deathshadow

    deathshadow Acclaimed Member

    Messages:
    9,732
    Likes Received:
    1,998
    Best Answers:
    253
    Trophy Points:
    515
    #3
    Up front, warning -- I'm going to be harsh. You've got BIG problems and most of them involve your having been suckered by the scam artist nonsense that is turdpress... and probably godaddy as well. Big tip? If a company has to use tits and ass to advertise their web hosting during 3am informercials? PROBABLY not worth using. Though you seem somewhat aware of that with your "unfortunately"

    To put it plainly and simply, whoever built that site has no business making websites. You might not want to hear that, but that's a harsh truth you NEED to hear. Others will give you the equivalent of "thoughts and prayers" or other such mental wankery saying it's fine, or you can fix it... when the entire thing needs to be pitched in the trash and started over from scratch if you care at ALL about speed.

    It's the typical train wreck of developer <broken record>igorance, incompetence, and ineptitude that is turdpress</broken> where it's painfully apparent that the people who wrote the markup, slopped scripting and style at it any old way, and created the layouts are utterly unqualified to write a single blasted line of HTML, CSS, or JavaScript. The massive wasteful goofball full screen image is too big to have ANY damned business on a website in the first place, there's a lack of indicators there's anything of value even on the site with the ENTIRE screen at 4k sucked down by that image, the menu, 4 words, and a button of illegible colour contrasts.

    Now, pingdom? It's BULLSHIT. 100% grade A bullshit because they have a blazing fast connection, and how they measure speeds is utterly broken. Yes, it's the golden child people mindlessly praise... but it's full of shit giving high rankings to some of the slowest sites out there, and pissing on the fastest sites. Much akin to how google pagespeed went from a useful tool to scam artist marketing trash.

    But let's look at some raw numbers:

    Markup: 63.7k for 2.46k of plaintext and TWO content media. Not even 8k of HTML's flipping job!

    CSS: (not counting the two google font includes) 563k in 15 separate files. There is NO legitimate reason for an entire website of this type to be using more than 48k in ONE file per media target (and being turdpress it's likely coded without them or set to "all") this is an epic /FAIL/ at styling a page.

    JavaScript (not counting analytics or the map) 698k in 21 files, on a page that to brutally frank (when am I anything but) I'm not even seeing anything worthwhile being done to warrant the PRESENCE of JavaScript!

    That we're at 1.2 megabytes of code (sent as around 260k) before we even TALK meaningful content? That's a complete failure at ACTUAL design and development.

    ... and that's before we dig into the HTML's "screw users with accessibility" methodology of endless pointless classes for nothing, endless pointless DIV for nothing, and hords of other epic failures.

    With 49 separate files loading at in excess of 2.75 megabytes, OF COURSE IT'S SLOW.

    Though helping even less, here with DNS cache flushed it took upwards of 12 seconds for the domain to resolve -- something pingDom actually doesn't count as part of their analysis... so I'd say a great deal of your problem isn't just the site itself being a giant bloated train wreck of how NOT to build a website -- aka it's made with turdpress -- it's that something's wrong with your DNS and/or you've got some sort of goofy bridging or redirection going on.

    At 49 separate files, a 1400ms ping-time could mean some people are seeing page-loads taking in excess of 80 seconds. That could be the DNS resolving issue, or it could be that the hosting is crap, or it could be that something being loaded in turdpress like some sort of extension or goofy poorly written template code is hogging the execution time.

    This is why you don't use turdpress for what appears to be a relatively simple static site... or for business... or really for anything more complex than a blog for grandma to entertain her toddler grandkids with. I mean Christmas sake it's a huffing squeeze page. That does NOT warrant the use of the fat bloated dumbass wreck of F****ardery that is turdpress.

    The images could also use some help. The massive image too big to be on a website is also saved as PNG, an inefficient format for photographs. Simply changing that to a jpeg could reduce the size of the file by a factor of four. .webp could take it even farther, though one would have to code that to fall back on jpeg for legacy browsers. (praise be the <picture> tag,).

    Between leveraging webp for modern browsers, turning that into a single static page without the asshattery that is turdpress, ditching the "JS for nothing", etc, etc, there is NO reason for that single page site to be more than -- not counting analytics, font-awesome, and the map -- around 64k in 3 files for the code and 300k in four files for the two content images and two backgrounds. That would be around 40 less separate files (so forty less handshakes), no need for the slow goofy lazy loading trickery (lazy load is often little more than throwing good code after bad), and a total transfer reduction to around 20% the original size.

    Basically, it's what happens almost any time people use Turdpress for anything other than a slap and dash blog that you don't give a flying purple fish about. ESPECIALLY if it's used for a single page "squeeze" type site.
     
    deathshadow, May 10, 2020 IP
    sarahk likes this.
  4. CactusWren

    CactusWren Greenhorn

    Messages:
    35
    Likes Received:
    9
    Best Answers:
    0
    Trophy Points:
    18
    #4
    Thanks for the honest replies. I definitely hate GoDaddy and was appalled by the UI, the quality of the hosting and the apps in Plesk, and unfortunately, I don't think the support really knew what they were doing half the time. The contrast between it and SiteGround, where I have my sites, was striking.

    As far as Wordpress, as someone who just started learning HTML/CSS/JavaScript a couple of months ago, I am now firmly looking forward to getting rid of Wordpress and either hand-coding or using other more elegant ways. However, my skills are not there yet, and for this particular website, I have to use Wordpress.

    I did make a few changes, having found a way to disable many of the CSS and JavaScript scripts, and swapped out the main png to a jpg (did I really use a png for a big file? Why?). It seems to have helped quite a bit, but still the site takes 5 seconds to load for such a small thing.

    Sounds like I'm going to have to have another go with GoDaddy support to find out what's screwy on their end. I've had problems with almost every thing I've had to deal with over there, so I'm sure it won't be fun.

    By the way, how do you guys find out how large the files are and how many requests are being made?
     
    CactusWren, May 10, 2020 IP
  5. deathshadow

    deathshadow Acclaimed Member

    Messages:
    9,732
    Likes Received:
    1,998
    Best Answers:
    253
    Trophy Points:
    515
    #5
    One of the most important tools when working with sites you can use is called the "document inspector". Most browsers have one built in now, but each has its merits and flaws. In most browsers you can start it by either hitting F12 or by right clicking on a non-link area of the page and choosing "inspect" in the drop-down.

    These typically have a "network" tab in them. If you do a CTRL-F5 refresh, you'll get what's called a "waterfall" that shows all the files being loaded, and how long they take in a graph to one side. There's a filter section as the second line of controls that usually reads "ALL HTML CSS JS" etc, etc, where you can filter by file type. In the bottom left corner it tells you how many files of the filtered type they are, their total size, and how large they were once compressed if sent by gzup.

    I usually suggest Firefox for the waterfall / filtering part as it tends to be more accurate (as chrome sometimes screws up dynamically loaded stuff), however Chrome can list certain details FF does not, such as if HTTP 2 "push" is in use or not. (A way to speed up your page even further if your hosting supports it.)

    Overall the inspector is a tool you should -- if learning to build yourself -- learn to master. It gets even more useful when working with pages written by other people in that it shows you the DOM (document object model -- the ACTUAL page) in a HTML-style collapsible tree, and when you choose elements to "inspect" shows you all the CSS properties applied, and where they're applied from. Note that whilst this tree LOOKS like HTML, it is not the actual markup of the page, as it includes anything dynamically added by JavaScript and CSS "generated content". Some people make that mistake looking at it early-on.

    You might want to look into .webp instead of jpeg. It's only supported by "modern" browsers (basically latest versions of everything except IE) but it can be coded around to fall-back to jpeg or png using the new PICTURE tag or a @supports media query.

    For HTML images:

    <picture>
      <source srcset="testImage.webp" type="image/webp">
      <img src="testImage.jpg" alt="Alt Text!">
    </picture>
    Code (markup):
    for presentational images that go in the CSS:

    .someElement {
    	background-image:url(template/images/testImage.jpg);
    }
    
    @supports (background-image:url("image.webp")) {
    	.someElement {
    		background-image:url(template/images/testImage.webp);
    	}
    }
    Code (markup):
    I took a moment to re-encode your images both as a more aggressive .jpeg and as .webp, the results are surprising.

    https://cutcodedown.com/for_others/cactusWren/images/

    The original courthouse image was over 800k all by itself as png. A re-encode as jpeg (with some smoothing to get the sky less pixelated) brought it down to 126k. As .webp it's 107k. That's more savings going from jpeg to webp than most people would get from minimizing their CSS!

    The picture of the flags sees similar results. The original jpeg was 460k, whilst a re-encode after a bit of depixelation drops it to 241k, but as .webp? Only 147k!!!

    The other images see similar drops in size, JFB2 from 70k jpeg to 29k webp, and the one with the ridiculously long name going from 10k to 6.75k.

    That's huge savings well worth the increase in code size for the legacy jpeg support.

    Just to help you along the way, if said single-page site were written "properly" it is unlikely the HTML for it would/should vary more than 5% from this:

    <!DOCTYPE html><html lang="en"><head><meta charset="uft-8">
    <meta
    	name="viewport"
    	content="width=device-width,height=device-height,initial-scale=1"
    >
    <meta
    	name="keywords"
    	content="criminal,defense,lawyer,firm,arizona,felony,misdemeanor,attorney"
    >
    <meta
    	name="description"
    	content="We can help you using our training, knowledge, and experience as we understand the stress that a criminal conviction can have on you and your family during every step of your case."
    >
    <link
    	rel="shortcut icon"
    	href="favicon.ico"
    >
    <link
    	rel="stylesheet"
    	href="template/screen.css"
    	media="screen,projection,tv"
    >
    <title>
    	JF Brown Law Firm
    </title>
    </head><body>
    
    <header>
    	<h1>JF Brown Law Firm</h1>
    	<a href="#contact">Contact</a>
    	<input type="checkbox" id="toggle_mainMenu" class="toggle" hidden>
    	<label for="toggle_mainMenu"></label>
    	<nav>
    		<ul id="mainMenu">
    			<li><a href="/">Home</a></li>
    			<li><a href="/#about">About the Firm</a></li>
    			<li><a href="/#testimonial">Testimonial</a></li>
    			<li><a href="/#contact">Contact</a></li>
    		</ul>
    	</nav>
    </header>
    
    <main id="about">
    
    	<section>
    		<h2>Attorney At Law</h2>
    		<section class="midContentImage">
    			<div>
    				<h3>About the Firm</h3>
    				<p>
    					J.F. Brown Law Firm can help by using our training, knowledge, and experience as we understand the stress that a criminal conviction can have on you and your family every step of your case from the very beginning. We strive to keep you informed.
    				</p>
    			</div>
    			<picture>
    				<source srcset="images/jfB2.webp" type="image/webp">
    				<img src="images/jfB2.jpg" alt="Jay F Brown, Lawyer"17>
    			</picture>
    			<div>
    				<p>
    					This firm has successfully handled thousands of criminal and traffic cases by aggressively fights for our clients. As a criminal defense attorney who previously worked as prosecutor and has decades of extensive trial experience and has exceptionally educated in the area of Field Sobriety Testing and breath testing equipment used by Arizona law enforcement during DUI stops.
    				</p>
    			</div>
    		<!-- .midContentImage --></section>
    
    		<section class="mediumContent">
    			<div>
    				<h3>Attorney Profile</h3>
    				<p>
    					Jay F. Brown was admitted as an attorney in the State of Arizona, after earning his Juris Doctorate (J.D.) law degree from Southern Illinois University, School of Law. He previously received his Bachelors in Science (B.S.) and then obtained a Masters in Science (M.S.), both from Southern Illinois University, College of Engineering &amp; Technology.
    				</p>
    			</div><div>
    				<p>
    					Mr. Brown now devotes himself to criminal and DUI defense and aggressively defends clients faced with serious misdemeanor and felony charges. Mr. Brown is specially trained in the areas of Toxicology, Traffic Accident Reconstruction, Drug Recognition Evaluation and field sobriety testing and attends frequent seminars to maintain his expertise in these fields.
    				</p>
    			</div>
    		<!-- .mediumContent --></div>
    
    	</section>
    
    </main>
    
    <section id="testimonial">
    	<h2>Testimonial</h2>
    	<blockquote>
    		<p>
    			I wanted to thank you for all of your help through this difficult time for me. This really meant a lot to me.
    		</p><p>
    			<cite>A.A.</cite>
    		</p>
    	</blockquote><blockquote>
    		<p>
    			Dear Jay, I highly appreciate the legal advice during this difficult time. It helped me to maintain some peace of mind. I appreciate your patience. I will be happy to make recommendations.
    		</p><p>
    			<cite>M.W.</cite>
    		</p>
    	</blockquote><blockquote>
    		<p>
    			Jay - Thank you for your representation, respect, and compassion through these most harrowing of time. You kept me informed and educated about the specifics of may case. If anyone close to me ever needed your services, I would definitely send them to your firm.
    		</p><p>
    			<cite>L.M.</cite>
    		</p>
    	</blockquote><blockquote>
    		<p>
    			Thank you for all the hard work and being kept informed throughout the process so that there were no surprises and would recommend you to any of her friends in the future.
    		</p><p>
    			<cite>J.H.</cite>
    		</p>
    	</blockquote>
    </section>
    
    <section id="contact">
    	<picture>
    		<source srcset="images/tempe_dui_lawyer.jpg.webp" type="image/webp">
    		<img src="images/tempe_dui_lawyer.jpg" alt="Jay F Brown, Lawyer">
    	</picture>
    	<form id="contact" action="/" method="post">
    		<h2>Contact</h2>
    		<fieldset class="namePair">
    			<legend>Name</legend>
    			<label>
    				<input type="text" name="firstName" required><br>
    				First<br>
    			</label><label>
    				<input type="text" name="lastName" required><br>
    				Last
    			</label>
    		</fieldset><fieldset>
    			<label>
    				E-Mail<br>
    				<input type="email" name="email" required><br>
    			</label>
    			<label>
    				Comment or Message<br>
    				<textarea name="message" required></textarea>
    			</label>
    		</feildset>
    		<div class="submitsAndHiddens">
    			<button>Submit</button>
    			<input type="hidden" name="contact_hash" value="randomHashHere">
    		</div>
    	</form>
    	<div>
    		<i class="fas fa-map-marker-alt"></i><br>
    		3116 South Mill Avenue, Suite 452<br>
    		Tempe, AZ 85282<br>
    		<br>
    		<a href="tel:6024769669"><i class="fas fa-phone"></i></a><br>
    		Phone: (602) 476-9669<br>
    		Fax: (480) 284-8945<br>
    		<br>
    		<a href="mailto:JFB@BrownLawAZ.com">
    			<i class="fas fa-envelope"></i>
    			JFB@BrownLawAZ.com
    		</a>
    	</div>
    <!-- #contact --></section>
    
    <footer>
    	<hr>
    	<div id="map">
    		<iframe
    			frameborder="0"
    			scrolling="no"
    			src="https://maps.google.com/maps?q=3116%20South%20Mill%20Avenue%2C%20Suite%20452%2C%20Tempe%2C%20AZ%2085282&amp;t=m&amp;z=13&amp;output=embed&amp;iwloc=near"
    		></iframe>
    	<!-- #map --></div>
    	<hr>
    	&copy; 2020 Jay F. Brown, All Rights Reserved.
    </footer>
    
    <script src="scripts/library.js"></script>
    
    </body></html>
    Code (markup):
    EVERYTHING else being done on that site in the markup serves little legitimate purpose, even the extra "opengraph" properties being pointless redundancies. The only OG: property worth using is og:image, the rest WILL fall back on your keywords/description META and TITLE tag or simply aren't used by any legitimate UA you should care about.

    UA == "User Agent". A browser is a type of user agent, but a user agent isn't always a browser. Search engines, screen readers (software that reads the page aloud), braille readers, and so forth are all different types of "user agent".

    The above HTML is based on what's called "proper semantics". Semantic markup being a sick euphemism for "using HTML properly" that actual experts use so as not to offend the mouth-breathers who still have their craniums wedged so far up 1997's rectum that we need to call a orthodontist to handle the extraction. It means using P for actual grammatical paragraphs, that H1 is THE heading on a page that everything is a subsection of. That H2 or HR mark the start of major subsections of the page, the first of which marking the main content. H3 marks the start of a subsection of the H2 preceeding it, and so forth down the line. you don't just willy-nilly pick them because "I want fonts in different weights and sizes" or "I want a line drawn across the screen". Those are just the default appearance for screen, not the grammatical / structural / semantic reason one would/should be choosing tags.

    A message I try to drive home with all beginners is that if you choose ANY of your HTML tags, or create classes and ID's based on what you want things to look like, you're choosing all the wrong markup for all the wrong reasons. That's NOT HTML's job and it's how you end up with bloated messes of "DIV for nothing" and "endless pointless classes for nothing" tag soup. ... and why classes like "w3-red", "col-8-s", or "text-centered" are ignorant trash, hence HTML/CSS frameworks (bootcrap, tailwind, w3.css, etc) that rely on that type of nonsense are equally broken garbage MADE by people who don't know enough HTML/CSS to be telling anyone how to build websites.

    Just look at the testimonials area, the original for the opening of the container, heading, and first testimonial:

    <section class="elementor-element elementor-element-zuorjeo elementor-section-boxed elementor-section-height-default elementor-section-height-default elementor-section elementor-top-section" data-id="zuorjeo" data-element_type="section" data-settings="{&quot;background_background&quot;:&quot;classic&quot;}">
    							<div class="elementor-background-overlay"></div>
    							<div class="elementor-container elementor-column-gap-default">
    				<div class="elementor-row">
    				<div class="elementor-element elementor-element-fkzmblx elementor-column elementor-col-100 elementor-top-column" data-id="fkzmblx" data-element_type="column">
    			<div class="elementor-column-wrap  elementor-element-populated">
    					<div class="elementor-widget-wrap">
    				<div class="elementor-element elementor-element-mjqseuu elementor-widget elementor-widget-heading" data-id="mjqseuu" data-element_type="widget" id="testimonial" data-widget_type="heading.default">
    				<div class="elementor-widget-container">
    			<h2 class="elementor-heading-title elementor-size-xl">Testimonial</h2>		</div>
    				</div>
    				<div class="elementor-element elementor-element-8cba16b elementor-widget elementor-widget-testimonial" data-id="8cba16b" data-element_type="widget" data-widget_type="testimonial.default">
    				<div class="elementor-widget-container">
    					<div class="elementor-testimonial-wrapper elementor-testimonial-text-align-center">
    							<div class="elementor-testimonial-content">I wanted to thank you for all of your help through this difficult time for me. This really meant a lot to me.</div>
    			
    						<div class="elementor-testimonial-meta">
    				<div class="elementor-testimonial-meta-inner">
    					
    										<div class="elementor-testimonial-details">
    														<div class="elementor-testimonial-name">A.A.</div>
    																						<div class="elementor-testimonial-job"> </div>
    													</div>
    									</div>
    			</div>
    					</div>
    				</div>
    				</div>
    				<div class="elementor-element elementor-element-9a596d8 elementor-widget elementor-widget-testimonial" data-id="9a596d8" data-element_type="widget" data-widget_type="testimonial.default">
    				<div class="elementor-widget-container">
    					<div class="elementor-testimonial-wrapper elementor-testimonial-text-align-center">
    							<div class="elementor-testimonial-content">Dear Jay, I highly appreciate the legal advice during this difficult time. It helped me to maintain some peace of mind. I appreciate your patience. I will be happy to make recommendations.</div>
    			
    						<div class="elementor-testimonial-meta">
    				<div class="elementor-testimonial-meta-inner">
    					
    										<div class="elementor-testimonial-details">
    														<div class="elementor-testimonial-name">M.W.</div>
    																						<div class="elementor-testimonial-job"> </div>
    													</div>
    									</div>
    			</div>
    					</div>
    				</div>
    				</div>
    Code (markup):
    Endless pointless DIV for nothing, endless pointless classes for nothing, and not even the proper semantics. Those are quotes and citations, where are the BLOCKQUOTE and CITE tags? That's flow text, where are the paragraph tags? There are multiple testimonials, why is it singular?

    Compare to how I'd have written that:

    <section id="testimonial">
    	<h2>Testimonial</h2>
    	<blockquote>
    		<p>
    			I wanted to thank you for all of your help through this difficult time for me. This really meant a lot to me.
    		</p><p>
    			<cite>A.A.</cite>
    		</p>
    	</blockquote>
    Code (markup):
    ... and you can see how ridiculous what that template is tossing out there is. Big tip, if every like tag inside an area is getting the same class at the same DOM depth, NONE of them warrant classes.

    I don't know what "elementor" is, but whatever was vomiting up all those classes needs to be put down like Old Yeller or all those poor cows in Hud that had hoof-and-mouth.

    But yeah, there do seem to be hosting issues as well as the page bloat issues, so taking GoDaddy to task -- or looking for better hosting -- should be part of the work needing to be done as well. It could be their somewhat skeezy hosting is choking on some of the things you tried to add to speed it up. WP-cache for example is notorious for making pages SLOWER despite the claims of making it faster when/if the page is excessively bloated with plugins. Those types of server-side trickery -- wp-cache, varnish, etc, etc -- are more oft than not little more than putting a band-aid on a bullet wound. Or as Bones would say, drilling a hole in a man's head instead of repairing the artery.
     
    deathshadow, May 11, 2020 IP
    Saputnik and malky66 like this.
  6. CactusWren

    CactusWren Greenhorn

    Messages:
    35
    Likes Received:
    9
    Best Answers:
    0
    Trophy Points:
    18
    #6
    Thank you so much for your analysis and the mini-tutorial you've written here. I will certainly be going through your post with a fine-toothed comb to help me "level-up". And I do have follow-up questions, but I'll ask those after I've studied this first. Thanks again!
     
    CactusWren, May 11, 2020 IP
    JEET likes this.
  7. CactusWren

    CactusWren Greenhorn

    Messages:
    35
    Likes Received:
    9
    Best Answers:
    0
    Trophy Points:
    18
    #7
    @deathshadow , Just so you know I did look at your stuff, I have been working on a learning project over here. Since I do like the aesthetics of the site and I feel most clients want stuff like that, I tried to use your html as the base and use css to make it look like it previously did while keeping as much as the semantic html and be as clean as possible. This more or less went well, except I lost steam and the end and when I uploaded it to my webserver, the formatting looks quite different (in a bad way) from what it looks like locally. For whatever reason.

    I used the document inspector to try to understand or steal as much formatting as I could from the original site. I had to modify your html and use container divs (sorry!) to get some things to work. Well, I learned a lot but there's a long way to go before I can ditch Wordpress.

    new site: http://lawsite.michaelwcho.com/jay.html (BTW I put the css on the same page to make it easier to work with and not have to switch. I only have one monitor)
     
    CactusWren, May 16, 2020 IP
    JEET likes this.
  8. kk5st

    kk5st Prominent Member

    Messages:
    3,497
    Likes Received:
    376
    Best Answers:
    29
    Trophy Points:
    335
    #8
    Can you not have multiple files open and displayed at the same time in your editor's window? I constantly use this feature in my editor. It's especially helpful when working on larger files files that I need to self reference; each view of that same buffer can scroll independently and each edit shows on its doppelganger as it happens.

    Switching focus among views is a hell of a lot faster than scrolling.

    gary
     
    kk5st, May 17, 2020 IP
  9. CactusWren

    CactusWren Greenhorn

    Messages:
    35
    Likes Received:
    9
    Best Answers:
    0
    Trophy Points:
    18
    #9
    Ah, yes I finally figured out how to do this. I'm been using Brackets, but mainly like a word processor. I need to sit down and figure out how to use more of the functions.
     
    CactusWren, May 17, 2020 IP
  10. deathshadow

    deathshadow Acclaimed Member

    Messages:
    9,732
    Likes Received:
    1,998
    Best Answers:
    253
    Trophy Points:
    515
    #10
    As Gary suggested, multiple windows is the way to go. It's actually EASIER to have them in separate files side-by-side as you can look at the markup you are styling WHILE writing the style in the window next to it, removing the constant up-down scrolling to hunt for things.

    Some of the problem you're encountering is bugs in the markup I gave. That was a drive-by post not really meant for production, just to illustrate the raw markup difference. It's got typos, unclosed tags, it was raw and untested.

    More of the problem though is you're still putting presentation in the markup. 99% of the time you see style="" the code is junk. The ONLY time the style attribute should be used is when the style helps convey content or is dependent on the content, such as font-size for a tag-cloud or width/height on a HTML bar graph.

    Likewise you've added HR where they don't belong. HR -- horizontal rule -- are NOT for "drawing a line across the screen". Under HTML 4 they were a heading depth separator when a numbered heading was unwanted or unwarranted, and under HTML 5 they are paragraph level dividers.

    Hence this:
    
    <h3>About the Firm</h3> 
    <hr class="separator">
    <p>
    Code (markup):
    Is gibberish nonsense. If HR is a heading level change in topic, you broke the relationship between the H3 and the P that follows. You don't use the tag just because you want a line there! That's the opposite of what HTML is for. Much less this:

    
    <h3 style="margin-left:20px;">Attorney Profile</h3>
    <hr class="separator" style="width:4%;margin-left:20px">
    
    Code (markup):
    Putting style in the markup where it doesn't belong, and doing so in PIXELS which is a broken/inaccessible measurement due to a lack of it scaling in many UA's.

    This stems from the entire reasoning of HTML: Saying what things ARE, or WOULD BE grammatically / structurally so that the user-agent -- a browser is a UA but a UA isn't always a browser -- can best convey that meaning to the user. Doesn't matter if it's a print, a braille reader, a screen reader (which reads the page aloud), a text-only terminal display, a high end graphical screen, a search engine, or some future device we've not even concieved of yet. HTML is supposed to be for everyone. Hence putting stuff in that says what you want things to look like utterly and totally defeats the purpose of HTML. In that same way H1..H6 do NOT mean "fonts in different weights and sizes", it means structural headings marking the start of sections and subsections.

    In fact it is to this end I tend to hide my HR in my screen media stylesheet, as I convey what it "means" by other... means.

    These basic concepts of HTML structure should in fact be familiar to lawyers. This is because the structural meaning of the tags directly correspond to the professional writing norms used in scientific and engineering papers, professional letters, and of course, legal documents. You have the document heading (h1), major subheadings (h2), headings of subsections (h3), etc, etc... if you want a change in topic without a heading you put in a horizontal rule -- be it a line, three asterisks centered, a forced page-break, or any of a dozen other appearances for the same RULE. You use the "B" tag for when things would be bold grammatically such as legal entities, and "I" for grammatical italics such as that on book or document titles. These differ from EM which stands for emphasis, and STRONG which means "with more emphasis", or CITE which is for when citing a source. Bullet lists (UL) and ordered lists (OL) are for single short paragraph bullet points. (as in a grammatical/structural "bullet point", not "hurr-durrz eye wunts teh dotsy befur eet")

    If you know legal writing at all, these concepts should seem damned familiar.

    Tell you what, I need a break from writing a proposal and draft for a paying client, lemme belt out the proper markup AND CSS, and maybe toss a smooth scroll script in there for you, which I'll then -- when I have the time -- document section by section so you can learn from it. I do these types of rewrites for people when they seem willing to put in the effort to try... which you clearly are.

    The rewrite will likely feed no styling or scripting to <b>IE9</b>/earlier so it gracefully degrades to the markup functionality. Unless someone is paying I no longer bend over backwards to support said browsers other than feeding them the vanilla markup, and <strong>MAYBE</strong> a max-width. <em>Laughably that's more than <b>Google Maps</b> does now, they dropped support for IE10/earlier!</em>

    See what I did there?

    This shouldn't take too long since we've already got a basic markup that just needs to be cleaned up.

    -- edit -- Oh, the label and input you commented out "What is this?"... that's hooks for a mobile hamburger menu. You don't really have enough menu items to worry about doing that, so yeah, I'd probably not do that in production.

    I outline the technique on my site here:
    https://cutcodedown.com/tutorial/mobileMenu

    There's a LOT of stuff people dive for scripting to do, that we don't need scripting to do anymore, or if we do HTML/CSS should do the heavy lifting with JS just filling in a few tiny blanks.
     
    deathshadow, May 17, 2020 IP
  11. deathshadow

    deathshadow Acclaimed Member

    Messages:
    9,732
    Likes Received:
    1,998
    Best Answers:
    253
    Trophy Points:
    515
    #11
    ... and here's a working rewrite. Again didn't take long as the heavy gruntwork of the markup and images was already complete, and display:flex is SO simple.

    https://cutcodedown.com/for_others/cactusWren/

    There's a .rar in there of the whole thing, a .txt of the HTML should view-source be problematic, and a sample .htaccess (and copy as htaccess.txt) that shows how one sets up HTTP2 push if supported. (which it is on my hosting).

    I took some stylistic liberties for accessibility and responsive reasons. Let's go over those.

    I did NOT use the dosis webfont on "flow content" and reserving it just for the headings. That font is HORRIFYINGLY BAD at normal text sizes compromising legibility because the slabs and bars are too thin, the aspect doesn't promote smooth reading, and it has some serif-like elements that screens often lack the resolution to render properly. If you wanted to add a different webfont I'd suggest keeping in mind that "thin glyph" fonts thanks to "font smoothing" and failing to hammer into pixel boundaries generally tell a lot of users to go screw themselves, especially those not using a Mac. Fonts like "Dosis" are fine for large headings, but for your flow? Hell no. There are even worse fonts that are generally useless for anything other than print or Mac, such as "raleway"... I'd suggest if you really don't like arial and helvetica, you try something like poppins, novo-sans, or anything that keeps the overall glyphs clear and round.

    I made the menu and contact button text bold to aid in the fact that the blue background (which I darkened and made more pure, #08F) is teetering on the edge of legibility. Likewise I added text-shadow to those buttons and any text that overlays images to further enhance legibility. It's usually a horrifically BAD idea to just slop text on top of images, but there are ways to improve things. Bold + text-shadow topping the list of "life savers".

    I generally shrunk the images and restricted the max-width more as there's really not enough content to warrant going larger, and the smaller sizes have less of a "fist in the face" as the display shrinks or enlarges. (did you see the original at 4K?)

    The contact form I dropped the idea of three columns because it just wasn't lining up to look good. Putting the image over the side-bar with the physical contact info helps things a lot. More so when we drop the e-mail address. You don't put e-mail addresses on websites, it's just begging to get flooded with spam and is why we have contact forms. Likewise I made the little font-awesome icons be centered next to the text instead of above, I just think it looks better that way. The image in question gets axed by the media query on small displays as it's not really essential, and kind-of gets in the way of the contact info when down that small.

    I also added more styling to the form elements themselves, and rounded the corners of both those and the plate images. Just taking the edge off the layout so it's less harsh.

    There were some enhancements too, like the scaling effect on hovering anchors, the addition of a back to top link, and of course the smooth scroll script that also pulls the content of the first H2 inside a section and applies it to the TITLE when you scroll to it from the menu.

    I pulled a slick trick with the back to top link MOST people throw JavaScript at. There's no point in showing a "back to top" arrow when you're already at the top, but since you have a full screen height splash area at the top, I hide the link behind it. You scroll down, it's revealed. Little z-index and painters algo lets you axe a bunch of pointless scripting.

    Alright, I've got to get back to real work, but if I have time later (or insomnia tonight, or the client leaves me waiting on them again) I'll write up the breakdown of the code explaining it. Again when someone is willing to learn or try I'll often do complete rewrites with line-by-line or at least section-by-section explanations. There's a lot to this stuff, but there's also a reason I can do under an hour in vanilla code what takes most people three days to two weeks with frameworks.

    Much less 15 minutes flat for the CSS since I already had the markup 90% ready to go.

    Oh crud, it's after 5 (EST)... I'll be free in about an hour or so since my paying client isn't likely to get back to me now. I'll try and do the HTML breakdown then. Somehow I seem to have lost two hours, and it wasn't on this.

    Hell, took me longer to write this post than it did the CSS. :D
     
    deathshadow, May 17, 2020 IP
  12. deathshadow

    deathshadow Acclaimed Member

    Messages:
    9,732
    Likes Received:
    1,998
    Best Answers:
    253
    Trophy Points:
    515
    #12
    Ok, got some spare time again, so lemme break down the reasoning behind the markup.

    Follow the bouncing ball at:

    https://cutcodedown.com/for_others/cactusWren/template.html.txt

    We start out with the doctype through character encoding. As the character encoding meta says how the content is formed, it should be BEFORE any content-bearing tag. Be it a meta content="", or the TITLE tag, or really any other tag.

    Because these first four tags always appear in this order and have NO reason to ever have anything else inserted between them, I put them on one line as a reminder. DOCTYPE MUST be first, charset META MUST be before any other tags in HEAD.

    If it's not first in HEAD, the browser when it gets to it will end up starting over from the beginning of the code throwing away any work it has already done!

    I do the same with the close of HEAD and opening of BODY, and the close of both BODY and HTML. Not to save the two or three bytes of code, but as a gentle reminder these tags MUST appear in this order, and you should NOT be putting anything else in-between them!

    It's little habits like that which can save you a slew of headaches later.

    The viewport META you are likely familiar with, it basically tells mobile we know what we're doing and to stop second guessing us. There are a lot of other values people plug in there, most of them actually hurt usability and accessibility, and many more break the user's ability to zoom on mobile.

    The height declaration in there is for some older Android devices (like my tablet and old Icoo phone) that when rotated to landscape will like about their size the same way they do width in portrait view.

    A keywords META exists to be seven or eight SINGLE WORDS or proper names that exist as CDATA (character data, just plain text) inside BODY that you want a slight uprank on. That's it, that's the be-all end-all of what it is for. Yes, it still works in most search engines, even the ones that claim it does not! (hello Google)

    The reason people think it doesn't work is they stuff it full of phrases, sentences, and words that aren't even inside the BODY tag. OF COURSE it doesn't work if you don't use it for what it's FOR!!!

    Your description META was pretty much spot on. It exists to be shown as text below your SERP listing's heading/anchor, and NOTHING ELSE. You don't just blindly stuff it with keywords, or pull other dirtbag SEO trickery with it. A simple natural language paragraph you want shown beneath the link to your page on the search engine listings. The be-all end-all of what it's for.

    Amazing how many "development experts" don't seem to understand that.

    I put the stylesheet LINK into IE conditional comment so that IE9/earlier will not load them. We're using flex and many other advanced techniques that older versions of IE fall flat on their face with, so we're just better off not sending them style at all.

    We CANNOT keep bending over backwards doubling our code or more to support browsers that are over a decade old... but the purpose of CSS is enhancement of appearance to an already semantic page, so sending them JUST the markup doesn't leave them out in the cold on using the page or gleaning useful information from it. All it does is mean they don't get the graphical bells and whistles. OH FREAKING WELL!!!

    This is 2020, if someone can't pull their cranium out of 2003's rectum just for some fancy graphics, that's their problem! Not my circus, not my monkeys.

    Note, if a cleint insists on it, the cost of the markup and CSS part of the process just doubled.

    Note I added media="screen" to those stylesheet link. There is no point in sending those to print, or aural, or anything else. If you see a LINK where it's for a stylesheet, and it's lacking a media="" or is set to media="all", what you're looking at is code written by people who don't know enough about HTML to be telling other people how to do things, or to be writing HTML professionally.

    In fact, the idea of multiple appearances for different devices or users is the entire reason CSS is separate from HTML! The same reason saying class="text-white col-4" is mentally enfeebled trash created by people who need to back the **** away from the keyboard and go take up something a bit less detail oriented like macrame.

    I used cdnjs CSS version of Font Awesome because the Javascript flavor is utter and complete shite. It doesn't work scripting off, it pisses all over the markup with SVG, those SVG take more bandwidth than using actual fonts, it's harder to style... and for what benefit? Some goofy SVG styling tricks that if you have any damned clue what you're doing you can do with CSS? /FAIL/ hard.

    It's also cndjs, it's fast and it's not going anywhere any time soon.

    The integrity check and cross-origin allowance also opens the door to it working properly if you were to up security with the "Content Security Policy" -- though for a site this simple I'd not bother, I like to put the hook in place just in case.

    The rest of the HEAD is normal stuff you likely know by now.

    In the body we start with a header. As a rule of thumb I have a rabid distaste for the new HTML 5 tags (section, header, footer, article, aside, main) but they are here, people expect them, and even if they serve NO legitimate purpose on my own sites, I better damned well get used to using them.

    The whole banner area is the header, and I gave it the ID of #top so that we can "back to top" link to it. It starts with our H1. Again, THE H1 (singular) is THE heading (singular) that everything on every page of a site is a subsection of. Hence it's the best candidate for the site title as shown on the page. (as opposed to the TITLE tag which is for the window/tab/search link). As it's THE heading -- singular -- there's no reason for it to have a class or ID.

    The anchor after we can target with the adjacent sibling combinator in CSS (a plus sign) so we don't need a class on that either. This should not be a form with a button; again just because you want it to LOOK like a button doesn't change that this is JUST an anchor linking to a spot on the current page! You want it to look a certain way, that's CSS' job.

    NAV is a pointless tag redundant to the anchors themselves, MAIN, and the first H2 on a page. I include it because people expect it to be there, and it COULD be useful as a hook for a modal menu when/if you have a ton of menu items.

    We don't need the ID on the menu UL, but "body > header ul" is a bit wordy in the CSS, and using an ID means we can 1) link to it just like we would #top if we need/want to, 2) have it override specificity. Being this is a menu -- a list of choices in no particular order -- the correct markup is an unordered list of anchors.

    Next I have hidden behind an IE conditional comment a warning to IE users to get with teh damned program. Know how I say "don't inline style unless it helps convey meaning"? Here's an exception. Small simple style for a specific target. Thankfully IE conditional comments are read by search engines AS comments, so the P inside it is ignored everywhere except IE 9/earlier.

    Also nice is that IE10/later doesn't have conditional comments, so they ignore these.

    After the header starts our main content, which also happens to be your "about" section. I gets a section inside it we can leverage for handling widths or other such issues, and being it's a main section it gets to start with a H2.

    Inside that we have two differnet types of subsections, being subsections of the main section they start with H3. Again, H3 means the start of a subsection of the H2 preceding it.

    The DIV are hooks for presentation WITHOUT saying what that presentation is, the PICTURE is there to let us use webp if supported, otherwise load the old JPEG's. Pretty simple.

    The second section being even simpler than the first.

    After the main we have the testimonials section, which starts with a H2 as it's a sibling to #about, and is filled with blockquotes.

    You don't just slop text into blockquote as by HTML rules it doesn't support inline-level tags (b, i, em, span, etc) OR CDATA as direct children. Hence you "need" paragraphs inside it for things to make sense. As these are quotes, the person being cited -- the source of the quotation -- gets the CITE tag.

    Again, semantic markup. The original WP page was this massive wreck of DIV and classes for nothing over what could simply have been plain clear as day semantics.

    With the contact form it gets a section (duh) and then the form.

    PROPERLY formed forms typically would have a heading -- in this case a H2 -- to say what the form is for. It would/should then have FIELDSET wrapping any input/textarea/select that the user can change the value of. So many people omit their fieldsets, and it makes using the pages on things like braille readers a royal pain in the arse.

    FIELDSET can have a LEGEND to describe what the set is for. In the case of this first FIELDSET it's the visitors name. The latter fieldset doesn't need a legend as it's just part of the same form.

    I put breaks in as semantically these content are not a run-on of inline data. If you wrap the input and it's text in LABEL tags you don't need to use the FOR or ID attributes on the LABEL and INPUT respectively. Not all layouts can do it this way, We kind of just got lucky here.

    The other way of doing these would look like this:

    <input type="text" name="firstName" id="contact_firstName" required><br>
    <label for="contact_firstName">First</label><br>
    Code (markup):
    If you see forms that vary from these patterns of LABEL and FIELDSET that lack either tag, you are again looking at HTML written by people unqualified to write a single blasted line of it.

    Side note, also placeholder is NOT a label. IF you see people putting what should be LABEL text as placeholder="", this too is utter incompetent trash!

    After the two fieldsets we have a div.submitsAndHiddens. In HTML 4/earlier placing inline-level tags like button or input directly under FORM was invalid markup, and whilst that restriction was lifted in HTML 5, I still like to provide a block-level container for this purpose with a clean name of what it's FOR. It also provides a convenient styling hook so we can right align the button, whilst still saying what it's FOR and not what it looks like.

    Sibling to our contact form is the other contact info. I moved the picture into it as I felt it fit better there, Then two DIV for the subsections. These DIV provide hooks for absolute positioning the font-awesome icons "centered" next to each subsection they are for.

    Again, I removed the anchor for the e-mail address as that's bad practice. I left it in the code commented out if you want to put it back in. If not restoring it, delete that commented out part.

    The map's IFRAME doesn't actually need any fancy wrappers. We can set its width and height directly so I moved the ID onto it and got rid of the "DIV for nothing".

    Even I screw that up from time to time on my initial markup.

    Finally the footer. It starts with an HR so that we're saying it's NOT part of <h2>Contact</h2>, the last heading before it. That's what HR are FOR!. Again, they are NOT for drawing a line across the screen! That is just their default appearance.

    I added a DIV just as a styling hook should other elements need be added to the footer later.

    The back to top anchor has both a FA icon, and some text. I hide the text in the span for screen media, but it will appear to give the section meaning for non-CSS, legacy IE, and search engines.

    Finally we have the scripting which I also put in a IE CC so that legacy IE won't even try to use it.

    For now said script just has my smooth scroll routine, which is a bit more modern and fancy than many off the shelf answers... but you can easily configure the scroll speed and acceleration, it swaps the document TITLE to match the linked subsection, and uses requestAnimationFrame so it runs many times smoother than the setTimeout / setInterval based equivalents.

    Alright, that's the markup. After I get some dinner in me I'll write up a description of the how/what/why of the CSS.
     
    deathshadow, May 17, 2020 IP
  13. deathshadow

    deathshadow Acclaimed Member

    Messages:
    9,732
    Likes Received:
    1,998
    Best Answers:
    253
    Trophy Points:
    515
    #13
    Oh, a brief word about the directory structure I used.

    Like many I like to keep the bits and pieces of a page separate, but I do so in a manner that's "down-tree" focused. Things that call other things always point at directorys "below" themselves so I never have to root (/) or up-tree (../) my links. I find it easier to manage and it's just generally nicer to be able to put the user-accessible pages in the root, then the sub-pieces in subdirectories.

    The structure I used here is:

    / -- where your user callable HTML goes.

    /images -- content images, aka anything that goes in a IMG tag.

    /scripts -- do I have to explain that?

    /template -- where any includes for PHP that are the template, and your various CSS belongs.

    /template/images -- images used/called by the CSS. Aka "presentational" images that have no business in the markup.

    Remember that url() links in your stylesheet are relative to the directory the CSS file is in, NOT the directory of the HTML using the CSS.

    Hence, let's say that:

    /template/screen.css

    calls

    background-image:url(images/flag2.jpg);

    It will load it from /template/images and not /images

    No more ../ nonsense, no need to start with a /, just do it.

    This can be handy if you have sites -- like forums -- where the user can choose different skins. You can alter the structure to:

    /template/skinName -- where the CSS file goes
    /template/skinName/images -- presentational images

    Changing the skin name so that it loads different images for each template... without having to alter the HTML one iota. That too is part of why CSS exists and what it's for, and why putting presentation in the HTML is more often than not an epic /FAIL/.

    Good planning of directory structure is as important a part of your development process as any other. It speaks to ones planning and organization skills, and is part of why every time I see "../" in a codebase, I assume there's likely deep rooted problems with how the site was built.
     
    deathshadow, May 17, 2020 IP
    Saputnik and JEET like this.
  14. #14
    Time free, so let's dig into the CSS. Again follow along at:

    https://cutcodedown.com/for_others/cactusWren/template/screen.css

    The first thing I have in every stylesheet -- the first 17 lines in fact -- is a reset. Resets exist because across all the different browsers not all elements share the same margins, padding, or borders. This stems from the fact that originally there was no such thing as CSS in major browsers, so each browser maker was left to their own devices as to what the defaults on things were and how they were applied.

    There are smaller resets like the so-called "universal" one of "* { margin:0; padding:0; }" but it can wreak havoc with form elements in both Firefox and IE. (in FF's case it's the Netscape 4 legacy they claim doesn't exist and isn't a thing... yeah, tell me another one Josephine.). It's a cute toy for testing, but I'd not use it in production... and in testing is it really so hard to just ^C^V?

    There are larger resets like Eric Meyer's "Reset Reloaded", but it wastes time setting/changing dozens of values that are not inconsistent cross-browser, and borders upon being a framework unto itself. ... and you likely have a pretty good idea my opinion of "frameworks"! It's so big, convoluted, and oft hard to work with that it gives resets a bad name, and makes many developers not use a reset even if they have to declare margin and padding on EVERYTHING just to get pages working cross-browser. Or worse, they don't even bother and don't care if it's broken in everything except Chrome-likes.

    The one I use (developed by Dan Schulz, RIP my friend) is a perfect middle-ground. It only resets what needs be reset, and at a quarter K of code nobody should be kvetching about how "large" it is. Pure goldilocks zone.

    Recently I added the box-sizing:border-box property to it as the "correct" standards box model is a pain in the ass to work with. Always was. Most dev's are coming around to agreeing on this in that border and padding should be PART of your width, not around it. Comically tragic given most of the "big experts" out there spent the past two decades bad-mouthing this behavior as being "broken" because it was the default in IE 5 and all later versions of IE if you omit the doctype. Microsoft actually had it right from the start, and it took near on twenty years for the rest of the world to finally go "Ok, you know what? My bad."

    After that I hide all HR. The comment says it all. HR are present for semantics and accessibility, not appearance. We convey this meaning by other means in our screen media layout.

    The little 480px media query that's in there is a bugfix for old mobile devices that don't know what a viewport META is. Basically first gen iPhones and pre Win10 IE mobile. Sadly if we sent these properties to desktop Safari it can disable the ability to zoom -- but since ALL devices that "need" this are 480px or narrower, and the odds of a desktop Safari user sizing the window that tiny are basically nil, a media query comes to the rescue.

    I always set HTML and BODY to 100% so that child elements of these tags can use min-height or height properly. One of the less talked about CSS rules is that you can't set a percentage height on an element who's parent doesn't have a height. It's ignored. Hence to set a min-height inside BODT, BODY needs a height of 100% (which is strangely treated like a min-height because it's set to overflow:auto by default). For BODY to have a height, HTML does too... in some browsers.

    Not really needed for this site as we've not needed a 100% min-height layout, but I put it in as a safegard.

    From here I'm going to explain things by selector.

    body, button, input, table, textarea, select -- the tags other than BODY listed here do not inherit from BODY properly the font settings, and I like to set the most commonly used fonts on the -page all at once.

    The font-size is declared in EM -- as are most widths, paddings, margins, and borders on the page -- so that it dynamically scales to the user preference in all browsers WITHOUT needing to dive for the zoom. This is something PX measurements cannot do and why apart from the occasional 1px border or shadow, you generally won't find pixel declarations in my codebases. PX measurements are inaccessible garbage and anyone telling you otherwise is flapping their arse-cheeks in the wind. Or completely misreading the part of the WCAG that outlines when they are allowed.

    It USED to be that Firefox didn't interpret a metricless line-height (1.5 in our case) for dynamic fonts... now it does. In THEORY setting it without a size (like EM or PX) it should inherit properly to all tags. It still doesn't do so 100% reliably, but Mozilla finally fixed the issue in FF so now it's safe to use. Some decade after people who never used a machine with non-standard default font sizes swore that it worked, running to forum moderators

    H1, H2, H3 -- apply that dosis font whilst still maintianing a fallback family, then adjust the weight and line-height.

    p -- I pad the bottom instead of using margins so I can avoid a headache know as "margin collapse". If two margins face each-other they are SUPPOSED to overlap, but some things like float, flex, and overflow screw with that. As such I only use margins when I have to when/if padding is inappropriate or already used.

    #top,
    #testimonials
    -- these two both share a number of things in common. A background-image that's centered and covered, the same flex and alignment, the same min-height, etc, etc... so declare these TOGETHER.

    The background-attachment:fixed handles all our parallax scrolling. It's amazing how many people still dive for JavaScript to handle what's one line of CSS' job... To the point it was even supported all the way back in IE4! But sure, "parralax backgrounds" are a new-fangled feature. Of course they are. :/

    #top -- the z-index is there to let it sit on top of the "back to top" fixed anchor. IE's buggy flex implementation won't center elements that don't have a explicit height. Because we have a min-height that will force it larger, we can just set 1% and boom, IE flex is fixed. The large top padding is to make room for the menu at all sizes, whilst the equal sized bottom padding is to make sure the H1 and the anchor after it remain vertically centered.

    #testimonials -- we want this UNDER the back to top link, so we set a low z-index. From there it's just padding and our background image.

    @supports (background-image:url("image.webp")) -- if webp is supported, we set both #top and #testimonials to their .webp versions. Thankfully browsers parse an entire CSS file before loading files called by url(), so this overwrite of the JPEG for legacy browsers (IE and Safari. Yup, Safari, aka "the New Internet Explorer" given how it's aging like milk) means the .jpg won't be loaded if we can use the smaller/better .webp files.

    #top:before,
    #testimonials:before
    -- I used generated content to darken the background images. Just absolute position a translucent background, job's done.

    h1,
    h1 + a,
    #testimonials *
    -- these elements need a positive z-index so they appear over that darkening background. In theory the z-index isn't needed as source-order should do the job, but I throw it in just in case.

    h1 -- again we need to bugfix IE and Edge's buggy flex implementation, in this case it won't word-wrap the H1 contents at small sizes without a width on it. Full width + text-align:center gets things right. From there it's just padding and style.

    Notice how I layer multiple text-shadows. You'll see me do this a lot to get a "darker" shadow than the blur would normally allow for.

    Also, see how when certain elements are getting the same style I group their selectors? Good way to save code and speed up changing things around. When we get to things like the blue button-like anchors, we could change/edit their style across the whole page from one place. That we can do this is why CSS pre-processors are pointless trash used by people who don't know enough CSS to... well, you've heard me say that enough times already!

    h1 span -- I set the nowrap so that the last word doesn't drop to a line all by itself. When we get really tiny we'll change the font-size, but let's put that off as long as we can.

    h1 + a,
    #contact button
    -- These all get the same general style and appearance, so hit them all at once. Nothing too fancy here apart from setting up a transition animation on transforms. This lets the enlarge on hover be animated.

    h1 + a -- margin, padding, border, yawn.

    #contact button -- since we've already applied some of its style, lets' get the rest. Normally I prefer to keep things in source order, but sometimes it just makes more sense to keep it close to where it's grouped with similar tags. Again, just padding and border style.

    #mainMenu -- normally I would say don't use absolute positioning for menus or other flow content, but we NEED the menu to be after the H1 for proper semantics/structure, and flex-order can be a real pain in the ass when it comes to keeping the sizes right. (could also mean needing more markup). Because we can control things via media queries, it's not the giant "evil of layout" it was a decade ago.

    #mainMenu li setting these to display:inline basically strips formatting off them. This avoids all sorts of render bugs in IE like the "Staircase" effect, and when possible is just the best way to handle them.

    #mainMenu a -- If we didn't set inline-block, browsers other than IE would ignore top/bottom padding. Again we have the scaling animation set up by transition, but apart from that not much to write home about.

    h1 + a:focus,
    h1 + a:hover,
    #mainMenu a:focus,
    #mainMenu a:hover,
    #contact button:focus,
    #contact button:hover
    -- when any of these elements are hovered or focused, make 'em bigger!

    #mainMenu a,
    #testimonials
    -- this complex layering of text-shadow alleviates most of the legibility concerns that arise placing text over images. I give a 1px +/- on each side to create a black text-border, then larger offsets to create a blur around them.

    #testimonials h2 -- big font, margin, yawn.

    #testimonials blockquote -- I do not recommend letting any section of text get wider than 48em, as it can make long paragraphs hard to follow. We then center them and pad them apart.

    #testimonials p larger font, space these apart too.

    #about -- as this is multi-column we can use a larger max-width... the widest subsecton being the 2 column area, so worst case they're 35em wide, well under that 48 max that's "ideal".

    I don't pad the top as I let the H2 handle the top margin.

    #about h2 -- speak of the devil. At 5em, half an EM is 2rem, smaller than our bottom padding on #about but it looks good. Sometimes equal looks great, sometimes it looks wrong. This was the latter.

    #about h3,
    #contact h2
    -- both of these want that blue border below them. Rather than using a fixed size or generated content, we can just use the border attribute. By making these inline-block they shrink to the size of their content + any padding. Because they are most always followed by block-level tags like DIV or P, we don't have to worry about them having any content ride up next to them despite being inline-level. Pad the bottom to space the border away, set the border, margin the bottom to push the content after away.

    ... and we didn't even need any extra markup. If you insist on them being that tiny fixed width, then I'd use :after to make some generated content to be that little blue stripe.

    picture > img -- all pictures are likely to share this styling. Block so it lacks the unwanted gap below them (vertical-align:bottom could also be used to fix this), full width of the PICTURE container, auto-height... and I rounded the corners and added box-shadow to make 'em a hair prettier.

    .midContentImage,
    #contact
    -- these too share the same flex and padding. I would CONSIDER merging these into the previous flex containers, but for now it's good on its own.

    .midContentImage > div both of the child DIV "should" be around a third the screen, but when flex-grow and flex-shrink are enabled this is mostly ignored. What it does do is make it so that they will both consume an equal amount of the remaining space around the images.

    .modContentImage > picture -- fix the size and disable flex grow/shrink so this stays stable, then pad around it pushing the DIV away.

    .mediumContent -- rather than try and play flex games and margin tricks with this. we can just say "make this two columns" and "put 3em between them". Quick, easy, done.

    .mediumContent p -- well, not QUITE done. The last line of our first paragraph would/could pop into the second column. Setting break-inside:avoid (and it's browser specific equivalents) makes it so that the first paragraph won't bleed into the second column and vice-versa.

    #contact -- 34em is a good maximum for the contact form, and 20em is about what the content of the address/phone column is... so with 3em of padding on each side, that gives us a max-width of 60.

    #contact > form -- let the form grow/shrink, pad the right to push the address/phone/image away, pad the bottom for extra space and for later when this goes to one column for small displays.

    #contact > div -- set this to not grow or shrink to flex's wants.

    #contact .namePair -- that first fieldset I'm implementing with floats due to the legend NEEDING to be a float to strip its junk styling. Hence the overflow:hidden so that floats are contained. The negative top right margin compensates for some issues with how the floats need to be spaced apart. Without that they would be 1em total narrower than the input/textarea in the next fieldset.

    #content .namePair legend -- Legend was one of the hardest elements to style in CSS as it tends to disobey different properties across all browsers. Some people (like me) used to absolute position a SPAN inside them to get them where you wanted, others would incorrectly use the appropriate depth heading (h3 in this case). We spent over a decade hacking around this issue.

    A few years back someone noticed that setting a float on a legend stripped all the other positioning off it in EVERY browser. So we float it. If we set the width to 100%, anything after it has to go below it as if float wasn't set. (mostly, complex topic for another time).

    #contact .namePair legend,
    #contact label
    -- simple padding. Appearance-wise these two tags end up the same on our screen layout, even if semantically they are not the same.

    #contact input,
    #contact textarae
    -- full width, padding, margin, border, and setting up an animated transition.

    #contact input:focus,
    #contact textarea:focus
    I might rag on Apple a lot for things, but they really got things right with focusing inputs making it easier to find which form element is selected than going "where's the cursor?!?". Hence I mimic that same appearance in all browsers with text-shadow.

    #contact .namePair label -- each of them 50%, boom they're side-by-side. Padding the left pushes the label text in. I didn't shrink the text as that would nab the input, and anything smaller could compromise usability.

    #contact .namePair input -- I slide these to the left 1em so they line up with the legend the same way later ones will line up with their label text.

    #contact > div > div -- the DIV inside the DIV section get relative positioning so we can move the FA icons around, left padding to make room for said icons, and of course a bottom margin to space 'em apart.

    #contact > div > img -- images inside the DIV area also need a bottom margin, and have the width fixed to a comfortable 19em. This will generally be the width of the entire column. Normally fixed widths == /FAIL/, but since the content fits, it's next to the fluid width form, and we're working in the elastic EM measurement, it's fine.

    #contact .fas -- the icons. Standard absolute positioning + negative margin trick for centering them vertically.

    #contact .submitsAndHiddens -- padding and alignment, yawn.

    #map -- fill width, elastic height, max height of the viewport for smaller mobile devices. No point in having a map that's taller than the device, and anything taller than 24em seems absurd.

    body > footer > div -- I target using > (child combinator) since other things on the page could have a footer. Both HEADER and FOOTER are completely valid structural elemeents inside not just BODY, but also ARTICLE and SECTION, so it's better to be explicit. We could throw a class at this, or maybe an id... but honestly? We only target it ONCE so why bother?

    As to what it's doing, do I have to explain padding and text-align? I thought not.

    .backToTop -- fixed on the display, z-index a hair lower than the #top we want to hide it behind, and of course turn off the underline.

    .backToTop i -- block so we can set an explicit height. I played with the line-height until the FA character was centered vertically, with text-align handling the horizontal. Bump the font size, then use colour, background, and layered box shadows to make it all fancy-like. I also made it a hair translucent when not hovered just so when/if on small screen it ends up over text, it's not a complete mess that forces a scroll. Naturally it too gets a transition animation.

    .backToTop:focus i,
    .backToTop:hover i
    -- make the icon bigger and opaque on hover.

    .backToTop span -- use absolute positioning to hide the span. I set a high top as well as high left just because flex can sometimes screw things up. I do not use display:none as that hides it from both search AND screen readers.

    ... and that is the desktop layout. Now all that's needed is the media queries to make it mobile friendly. I'll be summarizing these by query.

    max-width:58em -- when the screen got this narrow the menu on the right looked stupid, so I switched it to centered. The use of the 50% trick instead of just text-center off the 100% is so that we can at smaller sizes force a width.

    With the About and contact sections I lower the padding to make better use of the dwindling screen space, and with the image in #about I change it to shrink with the page size.

    max-width:50em -- I turn on flex-wrap and enlarge the third column of text so that it drops below the image and first column, adjusting the padding as needed. Likewise I lower the gap between the bottom two columns.

    max-width:45em -- I pull even more excess padding between elements, and switch the contact form to take up the full width, image and phone/address going below that side-by-side using float. I could have used flex, but I'd need to add more DIV for that.

    max-width:40em -- I switch the About heading to scale to the viewport width, that way we don't have to play games with wrapping. Likewise I lower the max-width of the menu to force it to two lines, and strip the column off .mediumContent.

    max-width:35em -- I turn off the contact form picture, it just gets in the way this small, and lower the width of the DIV it was in so we can better center it.

    max-width:25em -- like I did with the about H2, I set the H1 to scale with the display as well, making sure it fits two words per line instead of dropping to just one.

    Side note, rarely have I ever had break-points in testing line up to multiples of five that much.

    ... and that my friends is how you make a semi-fluid elastic responsive layout with accessible semantic markup and separation of presentation from content.

    I know this is all a LOT to take in, but take your time, read through everything I wrote, and when you're ready with questions fire away.
     
    deathshadow, May 17, 2020 IP
    JEET likes this.
  15. CactusWren

    CactusWren Greenhorn

    Messages:
    35
    Likes Received:
    9
    Best Answers:
    0
    Trophy Points:
    18
    #15
    @deathshadow, I'm blown away by all of this, thank you so much! I will be downloading and analyzing this over the next few days and will be back here shortly.
    PS. IANAL, as they say: this is my brother-in-law's website and I just made it for him. But I do get the analogy between the logical divisions in written laws and semantic html. Much appreciated!
     
    CactusWren, May 18, 2020 IP
    JEET likes this.
  16. CactusWren

    CactusWren Greenhorn

    Messages:
    35
    Likes Received:
    9
    Best Answers:
    0
    Trophy Points:
    18
    #16
    Sorry I've been MIA. Real life intruding on my dream of being able to properly create websites. In other words, I've been dealing with Wordpress again. WooCommerce. Instagram API. *shudders*

    Cool, I'll just copy this stuff for now. It's a bit over my head.

    Yeah, I'd heard that it was out of date. But makes sense to keep including them.
    So the "screen" value sends the CSS where it should go and nowhere else?
    I'm going to have to store this stuff away. Much of the CSS I just copy/pasted from the demo I was working from. In fact, I've realized that I skipped a lot of steps in my CSS education and there are many gaps in even the basics.
    So they aren't helpful with the semantic side of things, screenreaders, etc?
    Got it. And I didn't know about the adjacent sibling combinator before, thanks.
    Any chance you could explain the difference between, say, body > header ul and body > header > ul?
    So the blockquote is primarily semantic, alerting the reader that it's going to be quote, whereas the <p> is used to target it for any formatting?
    And I googled CDATA but I don't really understand it.
    Yes, once I learned how to look at that, it was pretty disgusting. I guess it's the result of the WYSIWYG page builder's way of working. I'm looking forward to getting out of that ecosystem permanently.
    So the fieldset is another semantic division for screenreaders, etc.? You wouldn't apply any styling to it?
    A little over my head at the moment, but I'll get it eventually. I need to work on forms more... Could I ask, if you were to put one on a site, what kind of script or setup would you use to process the data? I tried to set up a PERL thing but failed miserably.
    Didn't know that.
    Ah, okay. IIRC I was just trying to figure out how to copy that line so I used an HR.
    I took a look at those, but my JS is only at the beginning level... you know, for loops and just the beginning of document.getElementById("div1"), etc. I've done some online tutorials and just finished How to Learn JavaScript the Smarter Way, but not really sure where to go next. I also have a bad feeling I need to learn some PHP so I can work with WordPress and WooCommerce.
    Thanks again, this is great stuff! Some of it's over my head, but I'm sure I'll come back to study it.
     
    CactusWren, May 22, 2020 IP
  17. JEET

    JEET Notable Member

    Messages:
    3,825
    Likes Received:
    502
    Best Answers:
    19
    Trophy Points:
    265
    #17
    @CactusWren
    To get page size, and how many requests will be made by browser, open the webpage in your browser, and Choose File >> Save as.
    Save it somewhere. It will save HTML and all supporting files needed inside a folder.
    Number of files saved is the total number of requests that browser will make to server to show this webpage.
    Check the file size of the folder to see how much kb/mb of data will be sent by server, this plus the HTML page itself.

    This will not show data/requests made by AJAX (if any)

    If you only need a 1 page website, then why are you going through all this wordpress trouble in the first place?
    Make one "index.html" file, place your html in this, make a JS file for javascript (if any), and make a folder to store images, done.
     
    JEET, May 22, 2020 IP
    Saputnik likes this.
  18. CactusWren

    CactusWren Greenhorn

    Messages:
    35
    Likes Received:
    9
    Best Answers:
    0
    Trophy Points:
    18
    #18
    Thanks for the advice, I'll do that.

    Well, the WordPress thing comes from previous obligations. It's usually very easy to get started--one click and you have a website. For example, my wife wanted an e-commerce site, so I made one for her using templates/themes. What she wants is far more complex than what I can currently do using Brackets. I only started to learn HTML a couple of months ago, and have almost no clue about cpanel and all the little aspects of hosting a site.
     
    CactusWren, May 23, 2020 IP
    JEET likes this.
  19. JEET

    JEET Notable Member

    Messages:
    3,825
    Likes Received:
    502
    Best Answers:
    19
    Trophy Points:
    265
    #19
    CactusWren, I understand that quickly putting up a wordpress site seems very easy now. Unfortunately that will prove to be a mistake later.

    From what I know, wordpress updates every 3-4 weeks.
    Now, what is wrong with a PHP script, that it needs so frequent updates?
    How many bugs are there in it, how many security holes, so frequent updates...
     
    JEET, May 23, 2020 IP
  20. CactusWren

    CactusWren Greenhorn

    Messages:
    35
    Likes Received:
    9
    Best Answers:
    0
    Trophy Points:
    18
    #20
    Yeah, once I started learning to code, I began to really hate WordPress. So I will certainly be getting out ASAP. I just need to bone up on HTML/CSS and all the other things that WordPress takes care of automatically and I will be gone and not look back. It's just going to take some time, I think. Lots to learn...
     
    CactusWren, May 23, 2020 IP
    JEET likes this.