Minimalist Semantic Markup

Welcome Guest
Please Login or Register

If you have registered but not recieved your activation e-mail in a reasonable amount of time, please use our Contact Form for assistance. Include both your username and the e-mail you tried to register with.

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - Jason Knight

Pages: [1] 2 3 ... 20
node.js / Re: Problems installing node.js
« on: 25 Mar 2020, 09:48:43 pm »
1, 2, and 3... but that doesn't mean don't learn it. If you want low latency web services it's hard to beat it since it can provide its own HTTP services.

Just... for the love of Christmas, don't try to use it to glue HTML together.

node.js / Re: Problems installing node.js
« on: 25 Mar 2020, 07:59:49 pm »
Step 1: WHAT HAVE I TOLD YOU ABOUT W3FOOLS?!? They're utterly, completely, and irrevocably full of manure because they're a bunch of sleazy dirtbag predators. Trust NOTHING they offer.

Go to the horse's mouth:

Step 2: Are you trying to install it on Windblows or Quackintosh? Don't. It's nearly impossible for anyone but total experts in it to accomplish in a meaningful manner. Windblows is a great desktop OS, Linsux is a great server OS.  Don't mix them up.

HTML / CSS / Re: CSS Grid issues
« on: 21 Mar 2020, 03:49:30 pm »
how important is having multitude of spew around favicons?
Depends on how much of an art {expletive omitted} one is. Generally if the current "correct" size cannot be found, the next size up will be scaled, however some icons scale down badly and require manual tweaking / redraw after scaling.

Generally though, if your favicon is simple, that's MOSTLY BS for pedantic idiots who don't care about wasting bandwidth on NOTHING. There ARE corner cases where one or two of the specific sizes can help, but on the whole? No... just... no.

In the majority of cases the most that is needed is:

Code: [Select]
<link rel="shortcut icon" href="/favicon.ico">
<link rel="icon" type="image/png" sizes="192x192" href="/favicon-192.png">
<link rel="apple-touch-icon" sizes="64x64" href="/favicon-64.png">
<link rel="apple-touch-icon" sizes="160x160" href="/favicon-160.png">
<link rel="manifest" href="/manifest.json">
<meta name="msapplication-config" content="/browserconfig.xml">

The first is the classic 16x16, though you can embed other sizes and they will / should be used automatically. If you state the sizes older browsers may ignore this statement.

The first png icon opens the door to high-color and larger sizes. This used to be something that was pointless, and still can be if you actually have the tools to edit a .ico file properly, but now makes sense with 4k displays and users running 200% or more scaling. (see my media center) where that 16x16 is now 32x32

The two apple versions SHOULD handle most sizes should people move the shortcut to their mobile desktop, such as for a web app. Only add the intermediate sizes if it looks like junk at said size.

I wish they all just handed it the same damned way, but every blasted maker has their own rules. I think Android handles it best using a json file.

Code: [Select]
 "name": "App",
 "icons": [
   "src": "\/android-icon-36x36.png",
   "sizes": "36x36",
   "type": "image\/png",
   "density": "0.75"
   "src": "\/android-icon-48x48.png",
   "sizes": "48x48",
   "type": "image\/png",
   "density": "1.0"
   "src": "\/android-icon-72x72.png",
   "sizes": "72x72",
   "type": "image\/png",
   "density": "1.5"
   "src": "\/android-icon-96x96.png",
   "sizes": "96x96",
   "type": "image\/png",
   "density": "2.0"
   "src": "\/android-icon-144x144.png",
   "sizes": "144x144",
   "type": "image\/png",
   "density": "3.0"
   "src": "\/android-icon-192x192.png",
   "sizes": "192x192",
   "type": "image\/png",
   "density": "4.0"

Whilst it seems like a good bit of code, it's only loaded when it's needed and doesn't slow down the main page load ready time. The Microsoft XML is similar in nature:

Code: [Select]
<?xml version="1.0" encoding="utf-8"?>
<square70x70logo src="/ms-icon-70x70.png"/>
<square150x150logo src="/ms-icon-150x150.png"/>
<square310x310logo src="/ms-icon-310x310.png"/>

In both cases -- the XML or JSON -- if you use them you don't have to put the same values in the markup. I've seen people state it both ways and there is ZERO reason to do that. In fact, stating it in the markup can cause them to load even when not in use, something the XML/JSON versions don't seem to do. (though I've heard chrome on android fixed that, I've yet to see it in the wild)

Honestly though, if you're just making a normal every-day website, EVERYTHING except the traditional .ico file is pointless BS because the majority of users aren't going to put the link to your site on their desktop, even on mobile devices. You're making a full stack web crapplet it makes perfect sense, otherwise not so much.

HTML / CSS / Re: CSS Grid issues
« on: 21 Mar 2020, 01:20:14 am »
Thanks for exlpaining the fonts, didn't realise i could give them the same font-family and assign the weight to differentiate.
Few people do... when it's right there in the spec. Specific fonts often have their own pre-drawn versions, and don't look as good when you "let the engine do it", hence the mechanism for specifying different weights and styles that way.

Almost all windows system fonts work this way, if you look at the ACTUAL contents of the fonts directory you'll see that even humble arial has multiple font files for multiple weights, style,s, and all the combinations of the two... and yet if you look in the system fonts list you'll only see Arial and Arial Black -- and that's because the over-bold that is black doesn't fit into a normal font-weight stack.

I thought it was bad practice (appears malicious) to hide an element off of the viewport and that this may have negative impact on seo etc? Is this just nonsense that i read on a stupid article?
Probably just nonsense. Display:none is far more likely to cause SEO issues, but in this case the only penalty any search engine Should apply is to ignore the element. That's fine, it's not content so what do we care.

As a rule of thumb, search engines shouldn't give a flying purple fish what your style is. What they SHOULD be caring about is your text content, and the structure / meanings provided by the semantic use of markup. That SHOULD be the be-all end-all of the topic. BUT...

Thanks to black hat SEO dirtbags constantly trying to game the system, they started looking into the style about 17-18 years ago,  Specifically a technique called "content cloaking" where text was hidden somehow. To that end they started applying SOME of the style to elements to test for this, specifically ignoring the existence of any text that was display:none, visibility:hidden, or that had a color set the same as the background-color.

Problem with this is how does one then implement dropdown menus that search engines don't ignore? Position:absolute with off-screen positioning was the obvious answer... but that too was soon targeted as the SEO dirtbags abused it. Finally search engines -- or at least Google -- compromised and said that if you position it off screen the text itself will not be indexed, but it will still spider any links present and use the associated text of those anchors.

But overall the only real penalty any of these bring to the table is that the text content of such hidden elements are ignored.

I'd also point out that since INPUT is a "void" element, its presence and content would/should NEVER be used as part of a search ranking in the first place. The LABEL on the other hand...

Worst case, apart from being ignored there are no search penalties for this; though I've heard a lot of people flap their arse-cheeks in the wind about it. If this were in fact a thing 99%+ of all dropdown menus and 100% of all mobile / hamburger menus would get you smacked by the search engines. That clearly is NOT happening as if it did, there would be a huge outcry.

If i keep the tiles the same quantity however added different length text, is this the adjustment i would need to make to keep the tiles all lined up when the collapse?
That width tweak to prevent "one on its own" is something you'd have to adjust to meet the content, though the overall wrapping behavior once you're down below that is completely automated. It's just one spot that it's nice to adjust for.

Some things just can't be trusted to automate on their own properly, so changes to things like the menu do eventually -- no matter how well planned the layout -- end up having to be tweaked.

It's part of why if you read my progressive enhancement article's page 3:

I talk about starting out at a desktop resolution, then resizing the display until it breaks. I figure out where it broke in EM width (pixels / 16 if at "normal" font size,  / 20 for "large font" users like myself,  Divided by 32 on my 4k media center), toss 5% rounded down to the nearest half EM as a bit of "wiggle room" to account for possible differences in font-family or font rendering/kerning, and use that as my media query break-point.

It's the fastest and easiest way to make sure all devices get the best layout for them. Take the desktop resolution, shrink the window until it breaks, add a query to fix what broke. shrink the window until it breaks, add a query to fix what broke. shrink the window until it breaks, add a query to fix what broke. Over and over again until you're down to 256px / 16em (if at normal system font scaling) the smallest one should really worry about in 2020 for display resolution. We [ii]used[/i] to go down to 192px, but these days there's no real point going that small.

I am still playing (mainly with the flex components) to understand the impact of changing values like flex: 1 0 auto
It's one of the things I don't like about flex, is that it uses 0 and 1 for on/off making it cryptic compared to other things in CSS where they use names. If they had simply said that "off" was saying nothing, and using "shrink" and "grow" instead of 0/1 0/1 would have been far far clearer.

Even though I KNOW it's "flex-shrink, flex-grow, flex-basis" as the order of the condensed "flex" properly, I STILL occasionally have to refresh my memory on that.

If instead of

flex:1 0 auto;

It had been:

flex:grow auto;


flex:1 1 2em;

it was

flex:grow shrink 2em;

I think it would have been a lot easier for those just learning it to understand. But that's not how they chose to do it. In that way I think that the CSS3 grid layout module is better written and crafted as I find it easier to understand and far less cryptic... but grid sucks at doing anything you want to dynamically wrap or stack compared to flex. Sometimes that inflexibility is a blessing, sometimes it's not. It's why unlike a lot of dev's out there I don't go "flex or nothing, screw grid" or "grid or nothing, screw flex".

It's a problem this industry has as a whole, insisting on using the wrong tool for the wrong job. In regular programming you've got objects for nothing because "rawrz teh functions are teh evilz", or convoluted functions because "Objects are hard" (they aren't!). In HTML we have people who insist on presentational classes or presentational markup because "but the CSS is hard" or "it's more work" (it isn't, it's usually less work, see the derpitude that are frameworks that just make things harder by doing it ALL WRONG!). In HTML/CSS these days we have people going "now that we have flex there is no reason to ever use floats" or "floats aren't as versatile". Yeah, sure, of course. Call me when I can do shape-outside:ellipse on a flex child.

Simply put most people seem to only want to learn one way of doing things, then try and planket apply that one way to everything. Whilst in some cases -- like obeying the reason HTML exists and what it's for -- this makes perfect sense... well, in other cases all you're doing is running around with a hammer in one hand and a bag of screws in the other, and calling the hammer a "flathead screwdriver". Whilst you CAN drive a screw with a hammer, that doesn't make it a good idea.

Right tool for the right job, don't throw all the specialty tools out of your box just because you got a multitool. You'll find it kind of sucks when it's time to peen a pin, or tighten a bolt to a specific torque

But no, we have people out there -- ESPECIALLY career educators and students -- who insist that one specific way -- like flex -- is the be-all end-all answer to every problem. It's shortsighted, arrogant, and ignorant... and when you call them on it? They spew all the typical propaganda based nonsense that brainwashed them into thinking that way in the first place.

Basically, a mix of the 7 classic propaganda techniques riddled with fallacies, and a bunch of Lame excuses for not being a web professional.

Identifying when that is the case on "advice" you are given is an essential skill these days, given the sheer volume of snake oil peddlers out there, much less those who simply want to believe whatever lie they are peddled simply because it's soft, soothing, and exactly what they want to hear.

The truth is often harsh, brutal, and the last thing anyone wants to hear. Advocating for the truth is therefor often controversial, confrontational, and it's why the rank and file are often suckered in by the first good bullshit story they come across.

Hence how places like Sitepoint continues to sell books despite their authors clearly knowing jack about ****, how web rot scammers like W3Schools continues to have advocates and users despite being riddled with inaccuracies, omissions, and just plain bad practices, and how many "career educators" continue to be "influential" far past their expiration date... when in point of fact more often than not they've got less legitimacy than Amway, Mary Kay, Goop, Mercola, or the dirtbag calling himself an Avocado.

There's a reason a lot of businesses who deal in high volume software turnaround treat their new hire's first few months as a crash course in how things REALLY work, having to deprogram all the BS that was packed into their heads by alleged "educators". A situation only exacerbated by the fact that so many places now blindly believe all the bald faced LIES about frameworks, in the process screwing their employees, their products, and their customers.

Sorry there, didn't mean to rant, but it's stuff you really should be aware of. Web development as an industry has serious problems, mostly relating to truth and honesty. Most of the people I've dealt with freelance consulting the past decade I wouldn't trust to hold my beer for a minute.

I just reconfigured the hosting for http2/spdy with push. Apologies if all the "Apache2 restart" and occasional 500 error interfered with anyone.

Site should be loading faster now.

General Discussion / MOVED: Coronavirus: CONVID-19 - 2020
« on: 18 Mar 2020, 01:06:03 am »
Due to the political and societal nature of the topic, this subject was moved to  The Zoo.

The Zoo / Re: Coronavirus: CONVID-19 - 2020
« on: 18 Mar 2020, 01:04:57 am »
due to the fact I think we all need to get it and recover from it
Problem is a large portion of the population CAN'T recover from it, and if it's widespread even people who normally could recover cannot -- because we lack the sheer number of professionals, equipment, and resources to keep them alive.

I often like to compare disease control to counter-terrorism. It faces many of the same problems with the general population that people forget what the worst case is like, they forget that it's a worst case that could -- and WILL -- happen if precautions are not taken.

The ideal situation is that if the people involved do their jobs, and the correct precautions are taken, NOTHING HAPPENS! -- that's a good thing, but it makes it hard for those who made sure nothing happen to be taken seriously when they talk about threats. In CT it's even worse, since letting any information that something COULD have happened and was stopped could compromise ongoing operations.

... and that's the thing, the precautions to make sure it is not millions dead will be seen as unnecessary after the fact because millions didn't die. Guys, THAT'S THE POINT.

Worst case, if you just let everyone get it, you're looking at collapsing the capacity of any healthcare system in the world to treat those who need care and treatment. We're talking millions of dead if efforts to contain it aren't maintained... and generally it's the young, the elderly, and the poor

But of course that's why so much of the current popularist rhetoric reeks of just more of waging war not on poverty, but upon the poor themselves.

As it is even with precautions the disease numbers are doubling daily, and in many places that's more than enough that the hospitals can't keep up with the people who genuinely need care to survive even the simplest of side effects like pneumonia.

Given it is more infections than the common flu, given the infection rate basically doubles every day, and given the numbers of the "horrificl" 2017 to 2018 numbers here in the colonies, a real-world worst case scenario should be around 4.6% of a countries population dead ASSUMING medical care can keep up.

That's 15 million dead in the US, and over 3 million in the UK.

And yet in spite of those realities, we already have reports of dipshits here in the US holding "Covid parties" like they do the huffing measles. Another deadly disease know-nothing luddites who do their "internet research" want to bring back.

But again, the people of most first world nations haven't faced proper epidemics since before WWII. They cannot conceive of the idea of so many dead at once you can't even keep up with getting the bodies out of homes or off the streets so they're just left where they are. They cannot conceive that just because you "feel" healthy it could still kill out. The arrogant, narcissistic "It could never happen to me".

Kind of like how detached from the idea of famine or even widespread starvation is for anyone in a first-world nation under the age of 80. They're unaware of it, never seen it, and unable to grasp the concepts. Unlike say, our friends in Ukraine who got to witness such horrors AFTER the second world war....

... and why I'm truly dismayed by the blank stare I get when I say "corporate farm conglomerates are just capitalist collectivization". Won't be long before either the mega-rich swallowing up all the wealth or the hippy dippy "organic food" whackjobs lead us into famine that's as bad as any pandemic.

Though that all adds up to the biggest problem, the utter sociopathic mindset that the hippy / boomer / me / yuppy  generation reveled in and promoted in all who came after. It's all about them. For every person that was out there protesting civil rights, you had a dozen little stoner ****'s who were dropping out, shooting up, turning on. They weren't protesting, they were looking for a reason to get high and drop out of society rather than doing anything that might fix it. Is it any wonder they became the leisure-suit wearing "did all the drugs so that there'd be nothing left but crack by the '90's" dirtbags in their 20's, and the corporate raiding suit-wearing greed greed and more greed slimeballs by the time they were thirty-somethings.

And it's that same level of sociopathic lack of empathy and narcissistic self-interest that drives much of the rhetoric and stupidity of most of today's Luddite-esque ignorance. The "I've got mine, screw everyone else" attitude that is painfully prevalent in today's society at nearly every level.

Hence why when I hear "oh we should just have everyone get it, skip the quarantine nonsense" my brain translates it into "Why should I be inconvenienced for a month or two just because it might save someone else's life".

Because that's REALLY what those with said attitude are saying.

Side note, as this is a highly political topic when you get into REAL answers and REAL discussion, I'm moving it to the zoo.

HTML / CSS / Re: CSS Grid issues
« on: 11 Mar 2020, 11:35:54 pm »
Sorry for the delay, old man ended up needing his afternoon nap. :D

Let's break down the CSS. Follow the bouncing ball at:

First up we have modern webfont declarations. See how both of them use the same font-family name, and explicity declare weight and style? That's how it's SUPPOSED to be used. It's shocking how many places -- even ones I use to handle format conversions like Font Squirrel, or good documentation like MDN -- fail to mention that little detail.

As I mentioned in the last post, we only really need woff and woff2 at this point. OTF is old outdated IE 5 nonsense, with the more modern formats being both smaller, and tend to render better on non-Microsoft platforms.

Next is that reset... just big enough to reset what NEEDS to be reset without screwing over elements that have 'issues', whilst just small enough to not piss all over the place.

I set the border-box box-model on all elements because it's just easier to work with. For all the years of asshats running their mouths about the "standards box model" and how IE's "broken box model" was bad, now we have a means of actually triggering said "border and padding are inside width" behavior, and those same asshats run around singing its praises. This is why I have a lot of disgust with fellow developers. I've been saying the "incorrect" IE way was better for 20+ years...

Now we can use it with impunity.

I hide HR on pages because they exist as a semantic element, marking a change in topci/subject basically saying "this text is not part of the headings before it". (which is why HTML 5's "footer" is a pointless redundancy). IT DOES NOT MEAN DRAW A LINE ACROSS THE SCREEN! Most people hear "horizontal rule" and think drawing a line with a ruler, and not a grammatical or structural RULE.

Kind of like vertical breaks -- or as some mouth breathers now call it a "pipe".

The first media query fixes some older iOS and Windows Mobile devices that pre-date the viewport META. If the -webkit- version is sent to desktop Safari it can break the ability to zoom (but not on mobile, way to herp that derp there Apple!) but few desktop users would make their window narrower than 480px, and every device that "needs' this fix is smaller than that.

At this point said devices are probably dead and buried in terms of userbase, but it's 105 bytes of code, so no harm in including it.

Remember, when I'm talking about minimalism I don't mean byte obsession.

I always set 100% height on html and body just because some layouts need it, sometimes backgrounds get choppped if you don't set it, and child elements cannot set % heights if the parent doesn't have a height on it.

From here out I'm going to summarize by selector. When making the primary layout before I write the big media queries, I like to start with desktop then pare it down. A lot of people will tell you to start with mobile and work your way up, but I find that approach utterly back-assward. We can target any mobile we care about with media queries... you know what we can't target with media queries? Old desktops, that's what!

body, button, input, table, textarea, select -- This nabs the elements that don't inherit from body for our primary font properties. As well as body itself. I use a 1.5em line-height on flow text as it aids legibility the longer your paragraphs get and/or wider the screen is.

body -- upping the letter spacing makes Avante Garde look more like nexa, and improves overall legibility. I've always liked this font as it's got that same style but without the rail thin glyphs... but the low default letter spacing needs some help, so help we provide.

for normal/16px/vga/100%/96dpi/"windows vista+ small" / pickAdamnedNameAlready users, 0.0625em will be 1px. For large/20px/8514/125%/120dpi/"windows vista+ medium" / pickAhuffingName already users like myself it's 1.25px... and on my 4k media center it's 2px. Aren't EM fun to work with?

#toggle_mainMenu -- you know what this is. IE doesn't obey label clicks if the input is "hidden", so we set display block to show it, then sneakily hide it off screen.

#top -- I called this <header> #top so if you want to add a "back to top" link later, it's just <a href="#top"> and you're off and running. Bottom margin pushes the content area off of it.

#top > div your "webBanner" area. Doesn't really need a class or ID since it's the only div that's a direct child of #top. The cute trick here is that I use padding to push the text off the image, then set the background-size to auto-adjust width whilst filling 100% of the DIV container.

h1 -- as there should only be one H1 if we use the 'classic' structural rules, no reason for this to have a class or ID. The padding actually sets the large height of the banner area, which we'll be able to exploit to shrink it later in the media queries. I also lower the line-height since this isn't flow text.

h1 small -- the display:block actually makes it obey its own line-height instead of its parent -- the <br> in the markup mostly being there for non-CSS users. SMALL does not mean "this text should be displayed smaller", it means "this text would be smaller for gramamtical reasons in a professionally written document, such as for de-emphasis"... a tagline under a heading fits that description as it's a subtext of the numbered heading. We explicity restate the line-height because Chakra based Edge is an idiot. Thankfully with Chromium based edge slowly replacing the old Edge, we won't have to deal with that derpitude forever!

#mainMenu -- kill the bullets, fix it on the screen. Not complicated.

#mainMenu li -- inline-block puts them all on one line (duh), and basically strips LI of formatting. Given the plethora of rendering issues that can arise when trying to style LI, it's often better to just set it to inline and target the child elements (anchors) instead.

#mainMenu a -- inline-block so they can accept padding, margin to space them apart, coloration. I added a translucent white background so when you scroll, they're still legible.

#mainMenu a,
-- both of these share these same basic styles, so group their selectors to reduce the overall code, AND to make it easy to change both of them at the same time. Also helps to set up any transitions we might want.

#mainMenu a:focus,
#mainMenu a:hover,
#mainMenu a.current,
#contactUs > div,
#contactUs button:hover
-- ditto, these all get the same colouration, so set them together. This is why "mixins" and other such CSS pre-processor crap just reeks of being for people who don't know how to use CSS

#mainMenu a:focus,
#mainMenu a:hover,
-- for hover on these elements I decided to add a scale transform to enlarge them, which is animated thanks to the transition declared on the anchors. When setting hover ALSO set your :focus so that people using keyboard navigation aren't left out in the cold.

.ctaButton -- gets some style that isn't in common with the other groupings, like larger text and some bottom margin.

-- likewise it gets a different background color on hover, since its default state looks like the menu hover state.

.tiles -- these looked like a list of anchors, so I coded them as such. Kill the bullets, set up flex, turn on wrapping for flex if things don't fit, and set an alignment just in case.

.tiles li -- the display:inline is for browsers that don't support flex and again the "issues" I mentioned with styling LI before. Remember that the condensed flex property is "grow, shrink, basis"... in this case we want auto width, it can grow to fit the available space (1), but not shrink below its content size (0)

.tiles a -- the block setting makes it fill the parent container. The min-width makes sure that they stay visible and wrap as needed. I chose 10em as that's typically the maximum text width I'd expect with those "lights" once you have more text inside them. Adjust as necessary. From there it's just padidng, margin, and alignment. The 1px bottom margin is just so that when it word-wraps there's a small border created by the box-shadow.

... and again notice how I'm doing almost everything in EM. The fractional pixel that 0.625em would create on that margin-bottom looked like ass, so that got 1px. One of those rare exceptions and why no "good practice" rule should be inviolate.

.tiles i -- again they don't need that "icon" class, they're the only italic tags inside these tiles, and it seems unlikely you'd be using book or document titles (the grammatical/semantic reason to use <i> when not <cite>ing said source) inside these "tiles".

body > section -- our main content "sections" can all easily be grabbed without throwing extra classes at things. You might be starting to see a trend in my thinking. The > says "only those that are direct children of" so you can use sections inside sections without this rule applying. The mix of 90% width with a max-width gives us a nice accessible limit, but again nothing you would be unfamiliar with. I tweaked the box-shadow so that there's 0.25em faint hairline at the top to make it clearer the start of the sections, whilst maintaining a nice bottom shadow.

Oh, and when you declare box-shadow, you can omit the "growth" number if it's going to be zero. Hence:

box-shadow:0 0.25em 0.75em 0 rgba(0,0,0,0.2);


box-shadow:0 0.25em 0.75em rgba(0,0,0,0.2);

Are functionally identical.

h2 -- I set these to inline block so they shrink to their content. Since a H2 is usually sibling to block-level elements (p, ul, ol, pre, form etc) and not inline / phrase level ones, this works well. This way we can use border-bottom instead of text-underline, since text-underline-color has spotty/unreliable support and doesn't even exist on Microsoft browsers (last I checked)

#aboutUs p -- enalrge the text to match what you were doing. I'm not wild about it that big, but it's not horrible.

#contactUs -- use flex to make the equal height columns. This way it at least has a chance at working in IE11. Again, set up wrapping just in case.

#contactUs > div -- that first level DIV we don't want to grow or shrink, so 0 0 on that. This allows the form to grow to fill the most space.

I do not set a bottom padding because flex elements compact out bottom padding and margins when possible to try and "make the most room" for mobile. The workaround for this I use:

#contactUs:after -- Just stuffs an element in there to make the gap. Normally you wouldn't say "width:100%" on a block level container, but as we're inside a flex we have to, otherwise it would ride up next to the form. Hence this too gets flex:0 0 auto;

#contactUs h2,
#contactUs h3
-- again these get the same basic values, so group their selectors.

#contactUs ul -- strip bullets, pad, yawn.

#contactUs Form -- this we want to grow to fill, but not shrink smaller than its contents allow for, hence flex:1 0 auto; I pad the top 1.5em to match the padding on the sibling DIV, making our H2 and H3 line up with each-other.

#contactUs input,
#contactUs textarea
-- again, shared style, and since we set box-sizing:border-box on everything, the padding and border are inside the width not around it... making it easy for us to make them grow to the available width. I gave them a bit of a style tweak whilst here.

#contactUs input:focus,
#contactUs textarea:focus
-- I turn off the default outline because Chromium/Blink based browsers do a SQUARE outline even if the element has rounded corners... so instead I apply a pretty box-shadow much akin to Safari's default focus behavior, just an off-magenta to match the layout instead of blue.

#contactUs button -- again, full width, padded, font-size... you know what this is. The hover state shared with the main menu becasue it's declared with a pseudo-class will override our background declaration here.

body > footer -- remember sections can have header and footer too, so a simple immediate child combinator works just like it did for <section>. Pad it, center content, color -- you know what all that does.

... and that's the base desktop layout! I did some of the groundwork for responsive layout as well, so let's summarize that by media query. Again note that since we're using dynamic fonts, our queries should also be in EM.

(max-width:85em) -- having just one tile drop and become full width looks silly, so if we set the min-width to 25% it will reduce it to a mix of 4 and 3, which looks far better. Depending on how many of these "tiles" you have in production you may end up adjusting this query width.

(max-width:70em) -- Changing the padding for the h1 and the DIV to be based on VW -- viewport width -- we're able to make it start scaling down smaller as the display shrinks, without it becoming a massive mess on displays over 1080p.

(max-width:66em) -- at this size it just helps to shrink and remove padding to better use the dwindling screen space, improving the user expierience. Likewise that massive default H2 size gets dropped a wee bit.

(max-width:42em) -- Shrink the banner image spacing even further, and lower the H1 padding to the smallest that still looks good. Likewise the fixed menu just looks better centered down this small, we kill the flex layout on #contactUs so the two sections are reduced to one column, and we shrink that oversized #aboutUs p for more comfortable reading on smaller displays.

... and that in a nutshell is how I'd have gone about what you have so far.

I know this is all a lot to take in, so study, try it, play with it, and come back with questions when you're ready.

HTML / CSS / Re: CSS Grid issues
« on: 11 Mar 2020, 11:00:27 am »
Alright, here is that rewrite up and running with some CSS and some other optimizations.

As with all my examples the directory is wide open for easy access to the gooey bits and pieces.

Your original was 8.5k for the HTML and CSS combined, my rewrite is 8.28k, you know what that means? Your original wasn't THAT bad. I mean sure, around 1k of mine is that I make it responsive, but still your original's biggest problems were a few outdated attributes and a lack of proper semantics.

I also took some stylistic liberties. with the "lights" buttons centered at a fixed size, it didn't look right to me, so I used flex to make them expand to fit. This let's us set flex-wrap so that when the page is too small they will, well, wrap.

For a font I went with Avante Garde, which is very similar to Nexa in overall shape, it just has wider bars/slabs, better kerning, and a lower letter-spacing. Said spacing is almost too low, so I set a letter-spacing to bring it up a bit more legibile. That's a handy sneaky trick with some fonts as you can often take hard to read fonts and improve them just by moving the letters apart a hair. Ends up looking like a whole new font! In some cases it can even make serif fonts -- which are usually too detailed for screen media -- look good. Shout out to my buddy Alex for showing me that little trick with plain-jane "times new roman".

Naturally I darkened the magenta, but not all the way as text-shadow fixes up the other issues.

Before I explain my CSS, I'd like to briefly review the issues with yours and a couple other changes.

First off you were using OTF with no style/weight declarations. That's actually not fully/properly functional and could have been contributing to the rendering issues. The proper formatS (yes, plural) to use nowadays are WOFF and WOFF2. Pretty much IE9 and newer supports at least WOFF as does every modern browser, and WOFF2 support is pretty complete across any browser release of the past six years. We want both formats, since WOFF2 is basically just WOFF with internal file compression.

Your background image was WAY too massive for its own good. At half a megabyte it was twice the size most conventional pages -- HTMl + all CSS + all Scripts + all images -- should be. It was in fact three times the resolution of a 4k display... It also has low colour depth which makes it a candidate for 8 bit colourspace, hence I dropped it to 1920x1260 (since even at 4k it's only half the screen width) with 256 colours, and badda-boom badda-bing, it's now 42k instead of half a meg.

I like to do my image optimization early, so I don't forget later.

The so-called "universal reset" of * { margin:0; padding:0; } is cute for testing, but it can wreak havoc with consistency of appearance of form elements cross browser. That's why I suggest using a proper "reset". Some resets are so big -- like Eric Meyer's "reset Reloaded"-- that they give resets a bad name as they waste time changing things that aren't inconsistent cross browser. Others like the universal causes problems. The one I use is a nice safe middle ground.

Code: [Select]
/* null margins and padding to give good cross-browser baseline */
table,tr,td,th,p,img {

img, fieldset {

That only nabs what you NEED to hit. At a quarter K it's well worth it for the consistency.

You set overflow-x to hidden which is usually a bad idea. If you "need" to do that, there's something wrong with your layout.

On your .active class you repeated the same padding that the "a" setting should have hit. You do that a few times, and it's something to avoid. If you have a perfectly good parent tag already defined, only declare what changes on the pseudo and classes.

Trying to make the banner area a grid is kind-of faulty. I mean it's not a horrible idea, but really that's a background image, pad your content off of it.

text-decoration-color is fairly new and poorly supported, so I'd suggest using a border instead. Border is actually nicer in some ways as you can control the amount of space between the text and the border with padding.

You declare a LOT of things in pixels, and that's really not good. Particularly if you are using dynamic fonts with pixel paddings, or dynamic fonts with pixel metric media queries.

Pixels were NEVER the correct measurement for sizing things online, and even less so now that we have support for vector formats like SVG, fonts for icons, and so forth. The "EM" measurement should be your preferred tool for everything other than "razor thin borders" since it dynamically scales to the user choice -- that way they don't have to dick around zooming all teh time -- instead of being a "fixed measurement". When possible try to declare all your fonts, padding, margins, widths, heights, and media queries in EM.

Finally you have a few manual declarations that should simply be condensed. See something simple like:

Code: [Select]
margin-top: 5em;
padding: 35px 35px 35px 35px;
margin-right: auto;
margin-left: auto;

That could be stated as:

Code: [Select]
margin:5em auto 0;

The condensed properties are your friend... and remember it's clockwise, and if a value is missing it uses the one from the opposite side.

Ok, gimme a bit to write up a CSS breakdown/explanation. I'll likely have time for that some time after lunch, so around 2 or 3 EST.

HTML / CSS / Re: CSS Grid issues
« on: 11 Mar 2020, 02:44:43 am »
OK I'm a bit confused by when to use Grid and when to use flex and assume I'll pick this up the further I head down the rabbit hole.
My rule of thumb is that if you care about IE10/earlier, you can't use either. If you care about IE11 you can use flex, and if IE doesn't matter, go for grid.

But, that "doesn't matter" is in relation to "graceful degradation" --- if it doesn't work BUT the page is still usable in those browsers -- even if it's not the layout you want -- CLOSE ENOUGH. We have to stop bending over backwards to 100% support decade+ old browsers. If columnar layout drops to one column, or they don't get rounded corners and shadows, OH WELL. Those are NOT mission critical for what's really important: delivering content to users.

I very much agree on the menu items and have not given thought as to how I should change them, it has been annoying me heavily that they vanish into the page. WIP

I'd probably given them a white or transparent white background with a white text-shadow. Would let them stand out when over things further down the page. The use of text-shadow could also alleviate the need to turn down the brightness of that magenta.

There are ways...

X-AU meta was unfortunatelty lack of experience... I am using VSCode and used the ! hotkey to generate the raw HTML tags which included this.
One of the reasons I say it's foolhardy to use Microsoft products for anything web devleopment related. I mean it's a fine editor, but on the whole any editor that "does things for you" is probably gonna do it wrong. It's a concept a LOT of folks -- WYSIWYG editor users, "site builder" users, e-macs fans -- won't even listen to.

Probably why with my choice of editor I turn it all off. Hell, I'd use notepad if the search/replace were a bit more robust, it did proper tab to space and back conversions, and didn't choke on utf-8.

I love that you brought up font awesome, I originally loaded in a CDN and found some icons didn't work..
99% of the time that happens, the CDN is feeding you an old version. Version 4 -- which the current "icon lookup" part of their site points at, is still relatively new and a LOT of places are still feeding the old files.

The one I use:

Code: [Select]

Seems to be good for now. Includes all the checks needed should you need it to work under the CSP (content security policy)

That "registering" with them gets you that horrifying mess of JavaScript? Yikes. But like anything else, over time you get "hired help" who probably shouldn't be trying to help yet.

lack of experience ASSumed not to question them.
Question EVERYTHING, even what I tell you. There are a LOT of fly-by-night frauds out there claiming to be experts. Most of them couldn't code their way out of a piss soaked paper bag with a hole in the bottom.

As for my overall markup and junky classes, just bad learning experience / practice from ASP.NET where the defaults are all bootstrap for UI.
If you're coming from, I'm actually surprised your code is that clean. Where's the 192k base64 encoded "token" meta in the markup? :D

It is all a big learning process, but honestly it's not THAT complex once certain basic concepts click. That's the problem though, for a lot of people -- even some big names in this industry -- it never clicks. End result is their using JS to do HTML and CSS' job, JS where it isn't needed, non-semantic markup, extra markup where unneccessary, etc, etc, etc.

If it feels like it's getting too complicated, you're overthinking it or you need to dial back the bling and "keep it in your pants" on the fancy stuff.

Remember, Apple revolutionized web design by ripping it all out... and then pissed their own bed in recent years by sleazing it all back in. Then they wonder why they're not meeting profit projections.

HTML / CSS / Re: CSS Grid issues
« on: 10 Mar 2020, 10:43:43 pm »
On the whole, I prefer the live link over garbage like codepen... I mean pens are ok, but I'd prefer to see a live page.

We all look at things different I guess... and yeah, as @coothead mentioned, I've seen people bitch any way you do it. Some complain if it's a pen, some complain if you cut/paste, some complain if it's a live link... It's like FFS people, at least he gave us SOMETHING that has the complete picture.

That's more than what most people provide!

Now, that said...

There are a lot of issues with what you have, but let's start with what you asked about. I'd probably just set the inner containers to inline-block and the parent to display:flex. That really should be all that's needed for CSS apart from perhaps the alignment properties.

Though while we're here, let's talk about your page.

First off, you've got illegible low-contrast colors. The un-hovered menu items are likely invisible for a large chunk of the population, and that white on magenta is... dicey with such a thin-glyph font. Generally I dislike such fonts because as "pretty" as they might be to the artsy types, they tend to piss on accessibility from on-high. NexaLight, much like Raleway, is a really, REALLY bad choice for a font for screen media.

When it comes to color choices of background to foreground contrasts, I suggest always checking against an accessibility tool like the one at webaim.

In general if you're using a system font at 1 system EM, you should treat normal AA as your minimum. If you use a normal webfont, AAA is your minimum. If you use a glyph with really, REALLY thin lines like nexalight or raleway, well... thanks to font smoothing and differences in rendering tech you should consider a 10:1 ratio as your minimum.

Sadly the WCAG standards were laid in stone before font smooting and webfonts were a thing. I should probably get off my arse and make my own tool that reflects the changes of the past decade and a half.

Now your markup... for the most part it's nice to see something clean and well formatted for a change. The problem is your general lack of semantics and/or incorrect semantics. What makes one word a grammatical <p>aragraph? What makes <label> and <input> grammatical paragraphs?

But let's work our way through top to bottom. It's what i do.

First thing that grabs my attention is the pointless X-UA <meta>. The entire point of even having that present is to make modern IE work like older ones, NOT the other way around which is why ie="edge" defeats the point of using it. The only reason to set that is if the domain has been "compatibility listed" to IE8 throught 10, (11 ignores it) and really if that compatibility mode is "needed", you've got something seriously broken in either your HTML or your CSS.

So get rid of that nonsense.

Next, you've got a stylesheet link, but what's it FOR? Where's your media="screen" since that seems to be your screen media target?

Good rule of thumb? If you see <link rel="stylesheet"> and it doesn't have a media="" on it, whoever wrote it doesn't know enough HTML. (yes folks who created, maintain, and promote "front-end frameworks", I'm talking about YOU!). I suggest setting media="screen,projection,tv" for maximum compatibility, even though HTML 5's increasingly useless validation throws a conniption fit about it. I swear, it's like the W3C and WhatWG are doing everything they can to drag us back to the worst of 1990's coding practices.

You want to say what it's for, so you're not sending screen layout to print, speech/aural, TTY, or some future type of device we've not even concieved of yet.

Likewise "site.css" is kind of vague, of course it's CSS for the site. I often prefer to use the media target as the name so you can tell what the sheets are for.

Now there's that script... to load font-awesome? Why would you do that? Font-awesome should NOT be reliant on JavaScript to function! That's just silly. Just find a commonly used CDN like the one on cloudflare, and use it.

Also, scripts inside <head> can block the render until that script loads, hence the term "blocking script". It is really recommended that well written scripts belong right before </body> and NOT inside your <head>.

In your head... in your heeheeaaahed, zombies, zombies, bees, bees

I see the telltales of prepping for a scriptless mobile menu, that's good. I'd suggest throwing HTML 5's semi-new "hidden" attribute on the input so that non-screen media UA's .. or at least any modern HTML 5 supporting ones.

NAV is a pretty pointless tag if you use headings properly... though you have content BEFORE your H1, so you're not using headings properly. Semantics first, layout second.

Likewise avoid using classes that are named the same as a psuedo-state. It's easy to get confused the difference between:

So try something else like "current".

Your "web banner" image does not appear to be content... as such it flat out doesn't belong in the markup. I also see no real reason for the extra DIV wrapping it. Background-image on .banner would make more sense.

Not sure you need div.banner-text either, but that depends a lot on how you're aligning things. Not sure why a "description text" would get "more emphasis" (what strong means) either... and again, what makes a "my cool button" anchor a "grammatical paragraph" -- what the <p> tag MEANS.

REmember, you should be choosing your semantic tags by MEANING, not what you want things to look like.

Your tile section seems equally non-semantic and burdened with "classes for nothing". I have the feeling you've fallen into the trap of slapping a class on anything and everything you want to style, and that's just bad practice that results in bloated markup. This APPEARS to be a list of items, we have tags for that. Again, not sure what makes those SINGLE WORDS be <p>aragraphs much less require "more emphasis", and really since every tag inside .tiles is getting the same class, NONE of them need classes. Even that "icon" class could probably be axed if you just leverage selectors properly.

Also I would assume those would someday be anchors? If so, that should be coded LONG before you start styling them.

... and don't let the know-nothings try to tell you that slopping a class on everything is somehow "faster" than using selectors in the CSS. 100% bullcookies. What's going to be faster for the browser? Using more markup that creates a larger pointered list of elements with classes on them, or handling CSS selectors that have been MORE than fast enough all the way back to IE 5 on a 486/66 running Windows 3.1?

There are a LOT of "experts" out there working for big places like Google and Pingdom who are utterly and completely full of manure in terms of what makes a page "faster". Ten times the markup and increasing the memory and processing overhead is NOT going to be faster guys!

When you have major sections, like your "about us", I suggest using an ID instead of a class. The unique identifier ends up handy if you want to add 'on page" navigation later on since they can also be hash targets.

Your DIV around the form is also a bit silly since <form> is a perfectly good block level container. Move the H3 inside the form, and add the PROPER semantics to your form since, well... where's your <fieldset>? Under HTML 4 STrict a block level container inside FORM was required for a reason, and whilst HTML 5 has pissed on strict from orbit, it's still proper semantics that your user inputs be in a fieldset... a semantic tag that would let you not waste a class on things.

... and whilst <footer> is allegedly semantic, with EVERY real UA treating them as a <div> and NOTHING more, I'd put a <hr> in there to properly mark that the footer content is not part of the H3 or H2 preceding it.

Now, I usually frown on HTML 5's new "structural" elements, but people seem to expect us to use them even if they're LITERALLY just DIV since no legitimate UA does anything special with them. With that in mind a more semantic version of your markup might read something like:

Code: [Select]
<!DOCTYPE html><html lang="en"><head><meta charset="utf-8">

<header id="top">

<input type="checkbox" id="toggle_mainMenu" hidden>
<label for="toggle_mainMenu"></label>


<a href="#" class="ctaButton">My Cool Button</a>



<ul id="mainMenu">
<li><a href="#" class="current">Home</a></li>
<li><a href="#">About Us</a></li>
<li><a href="#">Contact Us</a></li>

<ul class="tiles">
<a href="#">
<i class="far fa-lightbulb"></i>
<a href="#">
<i class="far fa-lightbulb"></i>
<a href="#">
<i class="far fa-lightbulb"></i>
<a href="#">
<i class="far fa-lightbulb"></i>
<a href="#">
<i class="far fa-lightbulb"></i>
<a href="#">
<i class="far fa-lightbulb"></i>
<a href="#">
<i class="far fa-lightbulb"></i>



<section id="aboutUs">
<h2>About Us</h2>
Lorem Ipsum is simply dummy text of the printing and typesetting industry. Lorem Ipsum has been the industry's standard dummy text ever since the 1500s, when an unknown printer took a galley of type and scrambled it to make a type specimen book. It has survived not only five centuries, but also the leap into electronic typesetting, remaining essentially unchanged. It was popularised in the 1960s with the release of Letraset sheets containing Lorem Ipsum passages, and more recently with desktop publishing software like Aldus PageMaker including versions of Lorem Ipsum
<!-- #aboutUs --></section>

<section id="contactUs">
<h2>Contact Us</h2>
<form action="" method="post">
<h3>Send us a message</h3>
Your name<br>
<input type="text" name="name" required><br>
Email Address<br>
<input type="email" name="email" required><br>
Write your message<br>
<textarea name="message" cols="30" rows="7"></textarea><br>
<!-- #contactUs --></section>

&copy; 2020


77% the code, more accessible, and provides more than enough hooks for all the style you were attempting to apply.

Heading to bed soon, but if I have time tomorrow I'll toss together a quick rewrite of what you have so far and a full breakdown/explanation you can learn from... since your CSS has a number of issues that would/should be cleaned up as well.

Websites / Re: LilyPond website
« on: 5 Mar 2020, 11:16:17 am »
Okay, thanks again. HTML 4 Strict sounds like the most likely way forward.
Well... no. Sadly 5 is the future and we have to get used to it, but remember, 5 is a SUPERSET of 4. As such you can write as 4 Strict and still deploy as HTML 5 for the handful of actual improvements.

There are a LOT of new things in 5 worth using. The new <input type=""> for example like "email" and "number", the pattern="" regex for <input>, tags like <time> and the reduced header size thanks to the new charset and language declaration methods. ALL well worth deploying HTML 5 for.

It's just that there are a bunch of new tags that don't serve a legitimate purpose and just result in either code bloat, or pointless redundancies.

ARTICLE, MAIN, NAV, SECTION, ASIDE, HEADER, and FOOTER are the tags you can just choose not to use, or to use sparingly in the handful of corner-cases where it might make sense.

It's why a lot of us say "code for Strict, deploy as 5".

Much less a lot of features you basically will want at some point - - CANVAS, AUDIO, VIDEO -- whilst pointlessly redundant to OBJECT, we're being forced to use thanks to browser support. It sucks that it's a wasteful extra tag in the specification, but in terms of functionality VIDEO is a must have.

There's a lot of stuff in 5 that you need that "should not have been implemented this way" but that we're pretty much forced to use because, well... what else is there? You want cross platform compatible audio and video, you're using HTML 5 because flash in the browser is dead. They shouldn't be their own tags as it defeats the entire "simplify the specification" ideal of 4 Strict, but it's what has been implemented so...

Even I've had to admit that 4 Strict is dead, but I try to uphold its ideals and ideas where possible by just not using the crappier aspects of HTML 5 that truly violate the intent.

Websites / Re: LilyPond website
« on: 5 Mar 2020, 02:17:59 am »
The CutCodeDown articles have lots of criticism for HTML 5. I supposed there's nothing inherently wrong with building on correctly-coded HTML 4?

One of the problems is that simply saying "HTML 4" is insufficient as there are TWO HTML 4's: Transitional and Strict.

Strict is the "real" HTML 4 implementing all the rules and good practices. Tranny on the other hand is just HTML 3.2 in drag, literally meaning "in transition from 1997 to 1998 practices".

... and since the first line of the site reads:

Code: [Select]
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "">It's tucking back Mr. Winky, slapping on theatrical makeup,  and putting on the CFM boots for a night on the town... since apparently it's not just transitional, it's also loose.

Though much of that stems from their still using texthtml which as I mentioned is the old outdated and deprecated way of turning tex into markup. It's built into texinfo now and should be handled there.


The program has been dead for a decade now. Kind of like texinfo itself since I don't know many places that still use said relic of the early 1990's since, well... what are the odds they're actually going to print the documentation.

Structurally there is NOT significant difference between HTML and Tex, excepting that tex is the less accessible of the two in terms of code legibility... so I'm not sure just exactly what texinfo is giving them that HTML does not any time after around 2005. Admittedly I say the same thing about how people throw base64 at things, a relic of 1970's 6 bit computing!

But really if they are so set on texinfo for Christmas only knows what, to turn it into HTML texi2any is what should be used since it's still maintained and updated:

Now, as to the file you linked to.. Perl... what is this 2003?

If this were brought to me by a paying client, I would be asking again just what it is that they think texinfo is giving them that HTML is not, particularly with the goofy and cryptic use of PERL with zero legitimate organization brings to the table. It's an outdated outmoded relic that does little if anything of value compared to HTML any time after 1998.

Because to be frank this cryptic mess without code indentation to make it clear which blocks are which:

Code: [Select]
@heading LilyPond

... music notation for everyone

@c @imageId{cmws,web-clef-g-eight-alpha.png,Catchy Musical Web Snippet}
@imageId{lilylogo,double-lily-modified3,png,LilyPond logo}
@c @im ageId{cmws,web-snippet-alpha.png,Catchy Musical Web Snippet}

LilyPond is a music engraving program, devoted to producing the
highest-quality sheet music possible.  It brings the aesthetics of
traditionally engraved music to computer printouts.  LilyPond is free
software and part of the @uref{,GNU Project}.

Read more in our @ref{Introduction}!


is in no way, shape, or form easier to edit, develop, or deal with than:

Code: [Select]
<section id="LilyPond">
alt="LilyPond logo"
<small>... music notation for everyone</small>
LilyPond is a music engraving program, devoted to producing the highest-quality sheet music possible.  It brings the aesthetics of traditionally engraved music to computer printouts.  LilyPond is free software and part of the <a href="">GNU Project</a>.
<div class="readMore">
Read more in our <a href="introduction.html">Introduction</a>!
<!-- .readMore --></div>
<!-- #LilyPond --></div>

Which is realistically all that needs to be written... and it's not like the media target attribute can't be used to target print specifically or any other media device. Hence why texinfo SHOULD have died off 10-15 years ago no matter how badly big iron dinosaurs with their derpy emacs editor want to stay relevant. Even with the full words to say what things ARE, it's STILL 50 bytes less code.

Convert it all to html, work on it in HTML, use a server-side language such as php to glue together like components of every page, and use CSS to convert it to each and every format desired like print (which also covers PDF), screen, aural, etc.

Unless they're using texinfo for something completely out of left field, which is actually highly unlikely. It's painfully cryptic, too easy to screw up in, and much like many other *nix fanboy BS was created at a time when keyboards still only had 52 to 64 keys, communications were at an unreliable 150 to 300 baud, systems only had 6 bit character spaces, and companies like DEC, WANG, and WYSE still had relevance.

In case you couldn't guess, I'm not exactly "GNU / FSF" friendly.

Really, what is it that texinfo and Perl is giving them that HTML + PHP can't, other than painfully cryptic hard to follow code?

Snippet Sharing / Re: JavaScript: Walking the DOM
« on: 5 Mar 2020, 01:42:19 am »
Can you expand upon the statement: "new code doesn't actually work."?

Sorry there, I posted a new version that didn't rely on recursion, but it didn't fly because you need an extra loop to go to the parentNode.nextSlbling || parentNode.parentNode || parentNode.nextSlbling || parentNode.parentNode ||etc, etc, etc, forevery.

The versions in the first post work as listed.

Snippet Sharing / Re: JavaScript: Walking the DOM
« on: 4 Mar 2020, 09:10:29 am »
Nevermind, new code doesn't actually work.

Pages: [1] 2 3 ... 20