CUTCODEDOWN
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.

Recent Posts

Pages: [1] 2 3 ... 10
1
HTML / CSS / Re: CSS Grid issues
« Last post by Exodus_AU on 28 Mar 2020, 06:22:33 pm »
Quote
Honestly though, if you're just making a normal every-day website, EVERYTHING except the traditional .ico file is pointless BS
Fantastic and much clearer than 'You need all of these for modern web stack'.

Thanks so much for your help. I will get to the modal work :D
2
node.js / Re: Problems installing node.js
« Last post by Jason Knight 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.
3
node.js / Re: Problems installing node.js
« Last post by jmrker on 25 Mar 2020, 09:40:12 pm »
So is your answer:
1 Node.js information on W3Schools is not worth the electrons it takes to display?
OR
2. Use the link from the "horses's mouth" to install if I still want to learn?
OR
3. Trying to install for Window is only for the gods and I should avoid it as much as possible?
OR
4. Node.js is not worth the effort to learn?

:confused:
4
node.js / Re: Problems installing node.js
« Last post by Jason Knight 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:
https://nodejs.org/en/docs/guides/

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.

5
node.js / Problems installing node.js
« Last post by jmrker on 25 Mar 2020, 04:56:55 pm »
I located a link to Node.js at: https://www.w3schools.com/nodejs/
And I followed the instructions to get started at:
https://www.w3schools.com/nodejs/nodejs_get_started.asp

But when I get to the step to verify that I have done all correctly, I get an error message
indicating that 'node' cannot be found.

I feel like I am missing a step, but I don't know what or who to ask what I am not doing.
Anyone else have this problem?
Is there a more comprehensive tutorial I should follow?
6
General Discussion / WCAG 3.0 Silver Web Accessibility Guidelines
« Last post by coothead on 22 Mar 2020, 06:46:53 am »

The WCAG 2.0 guidelines were published in 2008

It appears that Accessibility Guidelines 3.0 are approaching...

https://myaccessible.website/accessibility-expert/ag-3.0

coothead
7
HTML / CSS / Re: CSS Grid issues
« Last post by Jason Knight 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"?>
<browserconfig>
<msapplication>
<tile>
<square70x70logo src="/ms-icon-70x70.png"/>
<square150x150logo src="/ms-icon-150x150.png"/>
<square310x310logo src="/ms-icon-310x310.png"/>
<TileColor>#ffffff</TileColor>
</tile>
</msapplication>
</browserconfig>

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.
8
HTML / CSS / Re: CSS Grid issues
« Last post by Exodus_AU on 21 Mar 2020, 05:51:03 am »
No i 100% agree, I have been there with frameworks like BS (coming from ASP.NET back end).. It's how i had to learn.. It's making it much harder now to unlearn bad practice to come over to core standards.

On that note, how important is having multitude of spew around favicons? I started googling requirements on it and ended up stumbling upon a mess of:
Code: [Select]
        <link rel="shortcut icon" href="/favicon.ico">
<link rel="icon" sizes="16x16 32x32 64x64" href="/favicon.ico">
<link rel="icon" type="image/png" sizes="196x196" href="/favicon-192.png">
<link rel="icon" type="image/png" sizes="160x160" href="/favicon-160.png">
<link rel="icon" type="image/png" sizes="96x96" href="/favicon-96.png">
<link rel="icon" type="image/png" sizes="64x64" href="/favicon-64.png">
<link rel="icon" type="image/png" sizes="32x32" href="/favicon-32.png">
<link rel="icon" type="image/png" sizes="16x16" href="/favicon-16.png">
<link rel="apple-touch-icon" href="/favicon-57.png">
<link rel="apple-touch-icon" sizes="114x114" href="/favicon-114.png">
<link rel="apple-touch-icon" sizes="72x72" href="/favicon-72.png">
<link rel="apple-touch-icon" sizes="144x144" href="/favicon-144.png">
<link rel="apple-touch-icon" sizes="60x60" href="/favicon-60.png">
<link rel="apple-touch-icon" sizes="120x120" href="/favicon-120.png">
<link rel="apple-touch-icon" sizes="76x76" href="/favicon-76.png">
<link rel="apple-touch-icon" sizes="152x152" href="/favicon-152.png">
<link rel="apple-touch-icon" sizes="180x180" href="/favicon-180.png">
<meta name="msapplication-TileColor" content="#FFFFFF">
<meta name="msapplication-TileImage" content="/favicon-144.png">
<meta name="msapplication-config" content="/browserconfig.xml">
or similar generators doing this: https://realfavicongenerator.net/

this is surely not needed?
9
HTML / CSS / Re: CSS Grid issues
« Last post by Jason Knight 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:

https://cutcodedown.com/article/progressive_enhancement_part3

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;

or:

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.
10
HTML / CSS / Re: CSS Grid issues
« Last post by Exodus_AU on 20 Mar 2020, 06:29:51 pm »
Sorry for the delay, what a crazy busy few week!

Thanks so much for the breakdown.

I didn't even realise how much I was interchanging between em's and px's until you mention :/ derp...

Thanks for exlpaining the fonts, didn't realise i could give them the same font-family and assign the weight to differentiate.

Few questions for you.
Quote
#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.
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?

Quote
(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.
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?

Ive added an example of this on my test site: http://mitwc.com.au/testing

Mate, I want to thank you for all the time you have given me.

I am still playing (mainly with the flex components) to understand the impact of changing values like flex: 1 0 auto

Next I will be adding a Modal to the anchor tile tags from your article you wrote. Will keep you updated on that progress as i get there :)

Thanks again!
Pages: [1] 2 3 ... 10

Advertisement