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.

Author Topic: When you were learning HTML....  (Read 315 times)

Jason Knight

  • Administrator
  • Sr. Member
  • *****
  • Posts: 379
  • Karma: +51/-1
    • CutCodeDown -- Minimalist Semantic Markup
When you were learning HTML....
« on: 19 Apr 2020, 09:13:18 pm »
What did you DISLIKE the most about the tutorial or book you were following? I'm looking for things to avoid as I'm going to be writing up a HTML tutorial for this site with a full and proper focus on "Say what things are, NOT what they look like".

HTML is so simple, I'm often shocked at how hard it is for some people to learn. I mean, sure if English isn't your native language, then fine.... but for Yanks and Brits alike it's as if everyone failed their fifth grade English classes.
Sorrow hides well in your shell. A fellow man with hurt to spare.
Dear one, here I am to share the fear. An act of kindness, without an amen.
Come in, the fire's warm. Burn the rope and dance some more.

mmerlinn

  • Junior Member
  • *
  • Posts: 37
  • Karma: +1/-0
  • Nutcake
Re: When you were learning HTML....
« Reply #1 on: 19 Apr 2020, 11:07:47 pm »
Personally, I have NEVER found a 'tutorial' that was worth the powder to blow it to hell.

I prefer a 'language reference' guide defining commands, etc. along with PERTINENT examples of how the command is SUPPOSED to be used and HOW to use it.  Most language references revel in making simple things complex as well as having a paucity of examples.  When they do include examples, it seems that they make them as complex as possible OR they include so few that it is often impossible to apply them to the problem at hand.

Further most gotchas are not even noted.  I just went through a gotcha in FoxPro that was driving me crazy until I accidentally found the solution while looking for something else.

Here is the FP example:

z = 'ABCDEF'
y = SUBSTR(z, 7, 1)

With SET TALK ON it throws the error 'beyond string'
With SET TALK OFF it returns an empty string

Someone dropped the ball there as it should be one way or the other, not both. Needless to say, I immediately added that gotcha to my notes on FoxPro commands.

Bottom line, if you know a gotcha, BE SURE TO INCLUDE IT and, if known, HOW to work around it.


The soul purr pus of a spell cheque cur is two valley date hour ignore ants.

GrumpyYoungMan

  • Full Member
  • ***
  • Posts: 201
  • Karma: +1/-0
    • GrumpyYoungMan
Re: When you were learning HTML....
« Reply #2 on: 20 Apr 2020, 03:39:27 am »
This is something you should be good at Jason as you like calling a spade a spade - and I like your no nonsense approach. So keeping it short and to the point?
Trying to learn a new trick to prove old dogs can learn new ones...

Total Novice have-a go Amateur Coder - not sure that is the right thing to say... but trying to learn...

Jason Knight

  • Administrator
  • Sr. Member
  • *****
  • Posts: 379
  • Karma: +51/-1
    • CutCodeDown -- Minimalist Semantic Markup
Re: When you were learning HTML....
« Reply #3 on: 20 Apr 2020, 11:29:36 am »
@mmerlin, good point with the "gotcha's" . HTML by itself doesn't have many obvious ones, but there are common mistakes and omissions that are commonplace just from a lack of understanding.

A lot of these aren't obvious because "normal people" don't use non-visual UA's. See how folks don't use numbered headings properly, or think the only tags that go inside a TABLE are TR and TD... or the general lack of understanding what FIELDSET and LABEL are for.

But those aren't going to blow up in your face in terms of "normal" users. They just flip the bird at usability and accessibility. The only major hiccup I can think of is how I keep seeing people putting their charset META after content-bearing tags like other META or TITLE... a complete failure to understand what the tag is for and how browsers are supposed to treat it. Even there all that does is force the browser to start over from the top on parsing the page.

It's only once you get into building with CSS that things tend to go pear-shaped. Issues like some older versions of IE and FF screwing up positioning if comments (yes, the things that should be ignored) are placed between sibling-level elements; or the oft unwanted gaps between display:inline elements,.. but these things should have little to do with the basics and choices made in choosing tags.

@GrumpyYoungMan -- some parts are likely to be short, others not so much. One thing I've noticed -- I've been researching other guides -- is how convoluted they all get in terms of explaining the GRAMMAR of HTML, something that shouldn't even take a screen-height or two worth of text that they break up into 12 pages of four 1080p screen-heights each. That type of nonsense needs a trim.

I've had a few false starts already on this -- hence my looking for ideas -- where it keeps turning into a reference. I think this is because like @mmerlin I prefer a decent reference with actual examples over tutorials. But that's me, and I know after trying to teach others in the past that doesn't float for Joe Sixpack and Susie Sunshine. It's like how because I had been programming for nearly 25 years BEFORE I learned JavaScript, I was able to pick up the language faster and better than most using nothing more than one of the old pocket references.

Oh how I wish MDN's reference had been around when I was learning JavaScript.

But overall I do want to keep it relatively short -- around the same size as my "progressive enhancement" article. Five pages of what I consider medium length. I want to explain the basics and instill good practices, not get bogged down in the nitty gritty of each and every tag... though I'm afraid it might come down to that. It's bad enough I'm going to HAVE to waste four to six paragraphs explaining to people what a paragraph is! An image is not a paragraph. An INPUT and LABEL are not a paragraph. The contents of a TD are not a huffing paragraph!

Maybe just a mini-reference? Tag Name, operational level (inline, block), valid parents, valid children, valid attributes, one or two paragraph explaining its purpose, examples?

Anyhow, this is still off on the horizon, I NEED to get the website for Elementals 4 completed in terms of content. Site design and Elementals 4 itself has been done since October. I only just polished off the reference last week for everything but the newest iteration of DOM-JON, but I need to write up and explanation of how "views" are implemented (yes, it has views) as well as examples since E4 is a radical departure from E3, bringing it back to my original intent as I kicked all the bad advice and worse code previous "collaborators" suckered me into. This version needed to stay pure and stay strong.

Still, I might post some drafts for review as I go.
Sorrow hides well in your shell. A fellow man with hurt to spare.
Dear one, here I am to share the fear. An act of kindness, without an amen.
Come in, the fire's warm. Burn the rope and dance some more.

benanamen

  • Global Moderator
  • Junior Member
  • *****
  • Posts: 30
  • Karma: +1/-0
Re: When you were learning HTML....
« Reply #4 on: 20 Apr 2020, 12:08:49 pm »
I would like to see the focus be on Accessibility. As you said, HTML is simple, but most people don't know a lick about Accessibility.
To save time, let's just assume I am never wrong.

Jason Knight

  • Administrator
  • Sr. Member
  • *****
  • Posts: 379
  • Karma: +51/-1
    • CutCodeDown -- Minimalist Semantic Markup
Re: When you were learning HTML....
« Reply #5 on: 21 Apr 2020, 03:15:07 am »
Accessibility is a semi-good topic, but would be an inherent part of "using HTML properly".

But that's REALLY the problem. The vast majority of people aren't... not even close. As evidenced by the train wrecks of 3i that are HTML/CSS "frameworks" that dial everything back to the worst of browser-wars era practices... created by people who never pulled their craniums out of 1997's rectum, and are CLEARLY unqualified to even flap their damned yap on the TOPIC of building websites.

Semantic markup and logical document structure, and the HTML side of accessibility will look after itself.
Sorrow hides well in your shell. A fellow man with hurt to spare.
Dear one, here I am to share the fear. An act of kindness, without an amen.
Come in, the fire's warm. Burn the rope and dance some more.

fgm

  • Junior Member
  • *
  • Posts: 37
  • Karma: +2/-0
Re: When you were learning HTML....
« Reply #6 on: 28 Jun 2020, 09:38:30 am »
Mixing content with presentation and inline programming (PHP and Javascript) and not specifying what HTML tags are designed to mean.

Even after reading and praising CutCodeDown I did my first take on Javascript programming using bad practices without thinking twice... people like me are somewhat hardcoded due to reading bad tutorials and following bad examples.

This industry is so full of bullshit that it's nearly mission impossible for a rookie to learn how to program a website in a sane way from zero... at least we have this gem resource to learn in a proper way.

Although not strictly related to HTML, I find difficult to program a website in PHP without having to continuously refactor the code until it turns into an unmaintainable mess. What I have learned is: first, define the data structures with future growth in mind and focus on a well defined topic.

It would be nice to have a big picture of how a website works, and how to build it in a way that it's maintainable.
« Last Edit: 28 Jun 2020, 10:41:34 am by fgm »

mmerlinn

  • Junior Member
  • *
  • Posts: 37
  • Karma: +1/-0
  • Nutcake
Re: When you were learning HTML....
« Reply #7 on: 28 Jun 2020, 11:48:05 am »

Although not strictly related to HTML, I find difficult to program a website in PHP without having to continuously refactor the code until it turns into an unmaintainable mess. What I have learned is: first, define the data structures with future growth in mind and focus on a well defined topic.

To avoid unmaintainable messes, I learned decades ago to make everything modular. Build it, test it, then use it forever without needing further tweeking. Not only is a program less likely to break, but it is often faster because there is less code to read.

Years ago I obtained some programs because I did not know how (at the time) to write the programs I needed. Those programs were full of spaghetti code.  I wound up re-writing them (and learning how they worked) in a modular fashion.  When done, they were 90% shorter (one went from 3000 bytes to 250 bytes), they ran faster, they had more options to do more jobs, and they never crashed again.  At the time I was using "state of the art" Apple II+ with 16k RAM, so size and speed were extremely important factors.
The soul purr pus of a spell cheque cur is two valley date hour ignore ants.

John_Betong

  • Jr. Member
  • **
  • Posts: 55
  • Karma: +2/-1
    • The Fastest Joke Site On The Web
Re: When you were learning HTML....
« Reply #8 on: 28 Jun 2020, 10:20:07 pm »
@Jason Knight,

Please write for an international audience especially for users whose native language is not English and not for just Yanks... who understand all about flying fish and purple unicorns.

I really like PHP's  documentation, easy lookup for a detailed single item, examples, "See also" and "user notes."



Retired in the City of Angels where the weather suits my clothes

 

Advertisement