Announcement

**coothead** · Apr 29, 2022, 04:58 PM

Originally posted by semicodin

What on earth is wrong with it? :

This...

Code:

</LEAD> <!-- CLOSING LEAD -->

...should be...

Code:

</div> <!-- CLOSING LEAD -->

**semicodin** · Apr 29, 2022, 06:16 PM

Oh my God what an idiot! roflmao 😆

As always, I thank you Coot. Somebody has been working waaay too much. Maybe I’ll roll myself into the game room and play bingo with the old ladies in their purple hair (maybe I’ll die my hair purple lol). Sending you a pint down the bar Coot . . .

**deathshadow** · Apr 30, 2022, 07:09 PM

Originally posted by semicodin View Post

Oh my God what an idiot! roflmao 😆\

Don't kill yourself over this one. Typo's like that are commonplace amongst the most advanced of developers. It's also why we have tools to help with that. Also apologies for any typo's in this, I'm typing blind and relying on the braille reader because my sugars are through the roof blurring my vision. Hopefully the shot of Trulicity and some fast acting insulin will clear my vision in an hour or two.

Whilst these days I ignore a LOT of the warnings because I vehemently disagree with certain changes made to HTML 5 (such as yesterdays valid HTML 5 is invalid today and todays will likely be invalid) the official validation tool:

https://validator.w3.org

Can tell you all sorts of useful stuff about your page, including missing tags:

Which if you scroll down will even highlight the elements having trouble because of the mistakes.

Again, I don't trust everything it tells me due to recent changes in HTML 5 that violate even their own rules, but for finding problems like missing or misspelt tags, it's the go-to.

It's one of the reasons I have the "web developer toolbar" installed:

https://chrispederick.com/work/web-developer/

An amazing browser extension that includes sending the current page's HTML or CSS to the validation services, viewing your document outline to make sure you have headings and are using them properly, disabling visual style so that you can see what braille readers, search readers, and so forth get from your page, etc. etc.

Looking at your page -- and please keep in mind I'm TRYING to help you -- you've got a LOT of code issues that seem to be due to mixing 1997 and modern techniques. Again, I question where you're learning HTML from, and if you learned it prior to 1998 you really need to unlearn that stuff. Like the willy-nilly mix and match of upper and lower case with no real plan or style guide. That ALONE can cause problems in some UA's. (my braille reader hates it)

Even just some of the simple stuff. For example if you <link> in google fonts, you do not need to repeat them with @import in the stylesheet. It's either-or, NOT BOTH! I recommend axing the @import versions as they won't start loading until after the stylesheet is present. If you keep the HTML ones they will start downloading as soon as it has all the HTML. Load orders are weird.

As I mentioned before -- and PLEASE don't get upset by my saying this, you're learning, SO LEARN -- your use of lorem-ipsum placeholder text for everything makes it painfully difficult to determine what the correct HTML would even be. What I can say is that you've got double-breaks for what are clearly grammatical paragraphs. A <br>eak is supposed to be a structural change/pause, not "I want space or a newline". P is for grammatical paragraphs, not "this is some text I want a space after".

Your table is similarly flawed as again, it's hard to tell from your placeholder text if this is even tabular data... though I will say it's refreshing to see someone using THEAD and TBODY for once... though your THEAD and spanned TH (the latter lacking SCOPE) doesn't look like it would be a table header on the column axis. That looks like it would/should be a CAPTION. The question is, is it actually a column heading spanning both columns (unlikely) or is it text describing the content of the table?

Again, HTML tags exist to say what things ARE, NOT what you want them to look like!. That's a huge mental hurdle a lot of people have difficulty with, but once you embrace it you'll find yourself spinning your wheels in the mud a lot less. I used HTML for about four years before I "got it" in that regard. I'm just lucky that when I finally "got it" it was 2002-2003.. That's why even your span for DBLUE (dodgerblue?) isn't quite right. You should be saying WHY the text is blue, not that it is blue. What makes it so special? Is it getting <em>phasis? Is it a title / legal entity (<b>), a book title that's not being <cite>d (<i>), is it getting "more emphasis" (<strong). When possible say why it's getting a style, NOT what that style is.

This is why "frameworks" like bootcrap and failwind are utter mental-huffing-midgetry!

To that end your classes are also troubling. Saying things like "left" and "right" is a bad idea since they might not even be left or right on small low resolution displays. Those are presentational concepts that should be avoided in your markup if possible.

You've also got some little flubs that again, just reek of outdated code. Such as:

Code:

<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">

That's the HTML 4 version. Under HTML 5 just say:

Code:

<meta charset="utf-8">

Similarly with your <style> (that really should be a separate file included via LINK, yes, even in testing) you don't set the media target. Your screen layout likely doesn't print very well, and users on non-visual UA's could give a flying purple fish about your screen layout. Thus if you're going to use <style> do it thus:

Code:

<style media="screen">

If it's your screen layout, though again what you really should have is more along the lines of:

Code:

<link rel="stylesheet" href="template.screen.css" media="screen">

A big thing you might want to watch out for is your comments as their placement could trigger bugs. YES, comments are supposed to be ignored by the browser, but Apple, Mozilla, and Microsoft can be a bit... derpy about that. You start having "double render" or "dissapearing content" bugs you'll be ripping out your hair and most developers won't even know why it's happening. Thankfully in most modern browsers it's fixed, but you never know when a regression is going to bite you in the backside. The "trigger' for this behavior is when a comment ends up between sibling-level elements. The solution? Move any comments for your closings BEFORE the closing tag. Then they can never end up between elements.

So where for example you have:

Code:

</DIV> <!-- CLOSING TWOCOLUMNS -->

I would suggest:

Code:

<!-- #twoColumns --></div>

The # as per CSS letting you know it's an ID you're closing, and you don't need to say "closing" as that's what the "</div>" means.

There are also a lot of "meaningful" new tags you should be using instead of DIV. Endless pointless nested DIV is never a good thing, and DIV really should be restricted to grouping SECTION or ARTICLE, and the occasional table where you want to do things table can't handle on its own like rounded corners.

Which you overthought, but that's ok. Again, we all start somewhere.

For example, if I were writing that same thing -- adding headings so there are accessible landings and logical document structure -- it would go something like this:

https://cutcodedown.com/for_others/s...plate.html.txt

Notice that I condense HTML through HEAD as well as </head><body> and </body></html>. I don't do this to save a few bytes, I do it as a reminder that these tags MUST appear in that order and one should never paste anything in-between them. Both for myself and others.

Those are the type of "habits" you'll pick up on the journey that can help you not make certain mistakes. Much like you can see I keep each attribute on an element on their own line if there's more than one of them. It's just cleaner / easier to scan.

Eh, what the heck, I'll belt out some matching CSS as you've got problems there too.

https://cutcodedown.com/for_others/s...ate.screen.css

Which you can preview here:

https://cutcodedown.com/for_others/s.../template.html

Everything before the "BODY" declaration is called a "reset". The intent of HTML is not to say what things look like, so the defaults used by user-agents is entirely up to the vendor. This led to problems when CSS was introduced and we still fight the cross-browser inconsistencies today.

All a reset does is give you a even baseline so that across different browsers you won't have any headaches. There are larger resets like Eirc Meyer's "Reset Reloaded" but that's a fat piece of bloatware that sets a slew of values that don't need resetting. It gives resets a bad name and is why many dev's will tell you not to use a reset. There's the smaller "universla reset" of "* { margin:0; padding:0; }" but it can wreak havoc with form elements.

The one I use is 611 bytes. Anyone complaining about that being "bloat' is delusional. The laugh being the people who object to that are usually the ones who see nothing wrong with using 100k of HTML to do 16k's job!

You can see the overall stylesheet is a lot simpler. I didn't match your 60/40 as that can have scaling issues galore. You can also see I didn't need the class to set the borders on the table as I set them "top". As CAPTION renders separate from the rest of the TABLE, I was able to leverage that with a bottom border to give the half EM spacing.

In particular pay attention to selectors like nth-child, child selector (>) and so forth. You can kick a lot of pointless presentational junk to the curb by using them. To that end in your original CSS see how you repeated yourself a LOT? If you have multiple selectors that share the same properties, comma delimit those selectors together. See this:

Code:

.sayWhatsSoSpecial h2, .sayWhatsSoSpecial p { margin:0 0.5rem 1rem; }

Some advice, the "pixel" fraction conversions you were using often render funny for the audience of EM/REM. There is NO fixed relationship, aka 1rem does NOT always equal 16px. That's the point of it. Normal users are often unaware of that, but on my laptop I have 1rem set to 24px by the os/browser default. My workstation it's 24px. On my media center's 65" 4k display since I sit ten feet away, 1REM starts life at 32px. Thus when you said 1.06EM for a font-size, what was delivered to me on my workstation is 25.44, which renders as 25px in FF and 26px in chrome-likes.

That's the whole point of using EM/REM, so that the entire page scales to the user preference without them having to screw around with zoom.

To that end I also suggest you not try to do sizes that are not even multiples or divisors of two... but if you do need to do it, we have a newer CSS property called "calc" that will give you what you want with ... less of the fragility of rounded off floats. For example where you wanted 17px on normal (1rem==16px) displays...

font-size:calc(1rem * 17 / 16);

Gives you that size, AND is easier to change if you "need" that type of granularity.

Also don't set a 1em line-height, you're making descenders overlap. 1.2 should be considered your minimum for most fonts, and higher line-heights like 1.5 greatly improve legibility. Same goes for running your text right up to the edges of borders. A LOT of users get turned off and/or have difficulty reading that. Which can suck if you're trying to save space...

You can see I scaled down the padding around the table's containing DIV to 0.5rem. This is a cute trick as with the broder-radius of 2em and an outer border of 0.5rem, we end up with a 1rem inner border-radius being a perfect match. The way you had it you had an inner and outer border radius mismatch. Again, something people new to this often don't think of the math behind it. Honestly, I find it a bit confusing that they chose border-radius to be based on the outside of the border and not the inside. Just makes calculating stuff like this take a bit more thought.

I also didn't implement all those font changes since it's clear you're playing with your choices. Some advice though, once you settle on a face stick with it. TRY to keep the number of "flow fonts" (fonts for headings and "paragraphs") to just TWO, and one is preferable. Ever-changing font-faces can cause legibility issues and is considered in some circles an accessibility violation.

Likewise try to stick to just 400/700 weights and call them by name.

GOOD ON YOU for not loading anything below 400, as those are utter inaccessible illegible garbage for a lot of users, but the other intermediate sizes can also have issues ... but worse, they suck on bandwidth like candy. You want a fast loading easy to use site, including every single font-weight between 400 and 900 is just going to get you in trouble. I also advise against "condensed" fonts unless you're 100% certain what you're doing with it, as they too have accessibility issues. Though they can be fun/useful if you up their letter-spacing back to normal... which sounds weird, but it looks cool.

And yes I know you said "don't tell me what I can and cannot read" -- reality check, it's not about you. That's one of the HARDEST things to get over when you go from cutesy art to actual design. You should be trying to make it useful to everyone, not just yourself. When I was starting out 24 years ago I had the same mental failing. "I want it to look like that" is all well and good, so long as you aren't hampering other people's ability to use it. You have to draw the line there and we have rules (the HTML specification) and guidelines (like the WCAG, web content accessibility guidelines) to keep you from going off the rails.

Bottom line though is it is EXTREMELY difficult to figure out what the proper HTML should be for what you've shown in all your posts, because you have the process backwards. Content should be dictating the markup, content + markup + device/user limitations dictating structure/layout, then you bed it to your will with CSS to make it pretty. You complained in your first post that I didn't try and help -- NOBODY should have been trying to help because none of us could tell what your content WAS. And that's part of -- along with outdated practices -- why you're struggling so hard. When all you have is lorem-ipsum we cannot figure out what you're even asking for. What is the CONTENT? Mind you, lorem ipsum is great for filler paragraphs, but for headings, menu items, data inside a table or columnar section, it becomes impossible to say what HTML you should be using in the first place. ... and div soup loaded with classes and presentational use of tables for layout isn't it!

Don't get upset about that, just slow down, breathe, read, adopt better practices, and take the time to learn. There are better and easier ways of doing all of this, it just takes time to get you up to speed on it. I honestly believe EVERYONE is capable of this, but we live in an age of instant gratification where people try to race to the finish, then wonder why they landed in the ditch. LISTEN to what I've been trying to tell you, as there is no malice towards YOU in any of it.

It's actually one of the things I find so degrading about the framework malarkey. The people who create and promote that junk say none of us are smart enough to do any of this directly. How insulting is that? I find that more insulting than a truck stop full of expletives.

I don't believe that. We can all do better, so let's do it.

**semicodin** · Apr 30, 2022, 09:03 PM

Chris.
Pederick.
Rocks.

Egad, I’m agreeing with Deathshadow.
Whatever is the world coming to?

**semicodin** · May 1, 2022, 02:38 AM

Deathshadow, I will address your post later but right now: In the 14,853 characters that form your response was there a solution for why my ems are not expanding?

**deathshadow** · May 1, 2022, 11:54 AM

Originally posted by semicodin View Post

Deathshadow, I will address your post later but right now: In the 14,853 characters that form your response was there a solution for why my ems are not expanding?

Oddly there kind of was, see your other thread. You are missing having a viewport META... which is in the rewrite I showed. The outdated charset META could also be causing problems, as could the upper and lower case, and pretty much everything else I said.

And yes, Chris rocks. His tools have been a go-to of mine for nearly fifteen years now.

Side note, anyone else remember when forum users used to complain that 32k was too small a post size limit... now you give people 288 characters and they think they cup doth runneth over.

**semicodin** · May 1, 2022, 12:26 PM

Nope. Doesn’t work.

**deathshadow** · May 2, 2022, 05:03 PM

Originally posted by semicodin View Post

Nope. Doesn’t work.

Again, with all the failings I've mentioned across your codebase, there are dozens of mistakes, outdated code issues, and other problems that could be causing your problems. I know I dumped a lot at you at once, but that's because your pages are fundamentally flawed issues like this aren't exactly unexpceted.

THOUGH it could just be the device or browser. Inconsistencies across platforms is something we as developers fight all the time, and in a lot of cases there's jack-all you can do about it. What specific device and browser are you seeing this behavior on, and could you better explain the problem because how you worded it and your screencaps don't entirely explain things.

Admittedly, I seem to have that problem with a lot of your posts -- I often can't figure out what your problem even is.

That said, it could be as simple as "You're using xxx device, get used to things being broken". HTML and CSS are not a cure-all when the browser and device vendors seem to love telling users they don't matter. See crApple with their "our way or **** off" attitude to go with their "you don't even own the device you paid for" dirtbaggery.

Announcement

Something is wrong with one of my styles

Something is wrong with one of my styles

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment