> I originally wrote this guide for my daughter, then 12 years old
I like the idea of this as an introduction for a child to web development, but I feel like it (in isolation) is wanting. One of the most jarring bits of this page is that there is an almost immediate jump from this page to MDN, which is drastically too much for most 12 year olds. There is a lot of "do this, and then do that" style of instructure, but not very much child-friendly explanation as to why to do that. Most things described here are trivial to people who are familiar with the subject, but not anything obvious or natural or intuitive without the necessary context or experience.
Further, there is a significant push into HTML semantics before describing the simplest workflow of creation -> publishing that may lose the target audience's attention; I feel that describing a process more abstractly and then expounding on the details may be more helpful if you're teaching children how to make a website (websites are documents on another computer that you can ask for, this is an example of a very simple document, the document goes on a computer that talks to other computers and responds to their requests for documents, other computers then can see the document when they are responded to, etc.).
34 days ago [-]
mg 34 days ago [-]
I made this html editor with instant preview and it turned out useful when I show friends how make their very first html page:
Originally, I made it for myself. To quickly do HTML/CSS/JS experiments. And I still use it for that use case.
Often when I show it to non-developer friends, I can see how they light up to coding for the first time. I think it is because it is so accessible. No signup, no setup, no long page load. Everything is instant, and they see each change the moment they type it.
egeozcan 34 days ago [-]
This is great, but maybe you can add a sandbox to that iframe you use for displaying? Nothing to do with security, just that people copy pasting snippets can actually lock the page up with broken scripts. I speak from experience :)
A sandbox could be an interesting idea. Especially as a dropdown with options what should be blocked.
I am not sure if anything should be blocked by default, because that could always end in frustration when something that should work does not for mysterious reasons.
But it might make a good default to block all external requests when the editor gets a feature to link to code directly. Like ...html_editor/?code=<!doctype html><html>...
Then it could display an info box like "Initial code was loaded from your link and the sandbox was activated. Use the Sandbox menu to enable more features the code can use"
There was a bit of a discussion about this on HN two months ago here:
My problem with 'data:' urls is that I have never found a way to add them to the homescreen on Android.
sumo89 34 days ago [-]
It's the same reason I always recommend people to start with CodeAcademy if they want to start learning web dev. The interactive, live preview is perfect and the UI is nice enough to outsiders. There are other sites with preview boxes but they look very code-y. Once they can see how setting a background colour or adding a new <p> works in real time it helps the beginning of understanding.
manuel_w 34 days ago [-]
Pretty cool, nice job!
And wouldn't it be semantically more correct to put the <style> tag into the <head> and turning the <span> into a <p>aragraph?
Since this is targeting beginners I'd think it's important to convey such fundamentals. But it might as well be that the HTML rules have changed since I left the game. It has been many years for me!
mg 34 days ago [-]
I would say <style> in the body is so widely used that one can call it "generally accepted". Google, Amazon, Wikipedia ... look at the source of any website, and you will see a lot of <style> elements in the body.
The reason is that it often makes the structure of websites much more logical. Often you want to define a piece of content, its layout and behavior in one specific place, not spread out across multiple places. Then the best solution is to have a <style> element right before the other DOM elements for that piece of content.
And for the html editor, it saves the user from thinking about one more element (<head>) which does not do anything that is visible to the user.
34 days ago [-]
xp84 34 days ago [-]
Oh, this thing is perfect. Thank you.
harry8 34 days ago [-]
Elegantly cool. Good job.
tommica 34 days ago [-]
This is a really good article - this is the kind of thing I would link to a person that wants to build a website. I'd hate to be a noob developer, and having to learn to build a react site as my very first thing.
nhatcher 34 days ago [-]
I always like mentioning neocities in this context:
Oh wow, I didn't know about it.
That is another shiny corner of the Internet.
You can use your own web domain for free!
BenChoopao 34 days ago [-]
This looks fun. I shared it with my niece.
Brajeshwar 34 days ago [-]
An aspiring founder asked me what to read/study when everything around is AI—which AI tools or AI Framework? My answer was HTML. HTML ain’t gonna go nowhere.
braggerxyz 34 days ago [-]
In Germany we have Self HTML (https://wiki.selfhtml.org/wiki/SELFHTML) since 1995. I learned all the web dev basics with it as a 12 year old. It was the kickstart for my career, and 28 years later I can safely say I was successful. And it all started with that.
Keep up the great work with such a guide, maybe you kickstart some careers with it!
manuel_w 34 days ago [-]
Wow this is bringing back youth-hood memories. Great to see this page is still around. Thanks for bringing this up. SelfHTML has been an invaluable tool for my younger self.
greazy 34 days ago [-]
Creating a website is the easy bit. The publishing and continually updates, even for a basic website, that's the bit that will make you stop and give up.
I think this is why wordpress or drupal services are multimillion dollar companies.
The web is hard.
My experience as someone who programs but was never formally trained even if my job requires the skill set.
Lanolderen 34 days ago [-]
As long as you keep the innovation boner in check it's fine tbh. I've noticed all of my problems in web come from trying to do sexy things. Stupid sexy things should be kept offline unless you sell stupid sexy things.
greazy 29 days ago [-]
> innovation boner
That made me laugh. I don't know, I still struggle with point a website to github.io.
steren 34 days ago [-]
No, we should teach React to beginners! ;)
zelphirkalt 34 days ago [-]
Better to put that /s or so there, before someone takes this literally.
egeozcan 34 days ago [-]
This is amazing! However, for the 99% of the non-developer people in my circle who started this journey, it goes on like this: Learn basics of HTML & CSS, start creating stuff on some free host, "oh my deity, this is too much to handle" moment comes, they create a wordpress blog, something in it gets broken after a year or two, they ask for help from a developer friend or give up.
For the developers, we are busy writing our own static site generators and blogging about it (which is a lot of fun too!)
susam 34 days ago [-]
This is pretty much how I began developing my own websites back in the early 2000s. Except that it was Notepad on a Windows 98 machine, and it was customary to write HTML tags in all uppercase. Layout was done with <TABLE> tags. The hosting was done on 20m.com which provided a free subdomain and 20 MB of hosting space. Remarkably, that silly website is still up at <http://encoders.20m.com/>!
caspper69 34 days ago [-]
That site gives me flashbacks to my 1994 O’Reilly HTML book. That and the Perl one (was that the Camel book?)
I am glad to see something like this though. You might reach some people.
You see folks, when you had to live through doing this shit by hand, and if memory serves, this was even pre-css (or maybe pre separate css files, shit, maybe just pre-css2?) and your only dynamism was through cgi with C or Perl, because Cold Fusion cost waaay too much for mere mortals (and the Sun server costs were even more eye watering), you welcomed things like Linux, PHP, MySql and Apache with open arms. It was like being rescued from a refugee camp and being given prime rib. And think about this- if someone thinks PHP back in the version 3/4 days was salvation, that person has seen some real shit.
Point being, we came OUT of the woods. We knew better than to build rube goldberg machines that would lead us right back in, lol. We have a word for that- masochism.
Take what you know now, and simplify. Untangle the knots. Spring clean. Throw away the cruft. Free your minds.
And I know y’all can. Don’t be pretending like you don’t rewrite all your shit every year anyway ;)
zelphirkalt 34 days ago [-]
Very accessible. I don't need to load tons of third party JS to view this website. It doesn't hold its content hostage. It also makes use of things like the details element, instead of resorting to JS for such things. Basically, this is what one could expect from a website, that teaches HTML. To actually know the stuff it teaches, and apply that. This will also be more responsive than 95% of the websites out there. Nicely done.
iLoveOncall 34 days ago [-]
> This will also be more responsive than 95% of the websites out there.
Except it's really not.
zelphirkalt 34 days ago [-]
State your device, browser and resolution. For me it floats perfectly fine, as expected, because it is mostly text and uses the elements in the way they are meant to be used. I narrowed the browser (with the responsive mode toggled in inspector) window to something like 250px and it still showed everything nicely. Most websites break way before that width, making elements overlap and unreadable.
iLoveOncall 34 days ago [-]
Chrome on an iPhone 13. The buttons at the top linking to different sections are a mess and the code is simply unreadable because of the indentation and the large characters.
soupfordummies 34 days ago [-]
Ah this is nice! Fond memories coming back of learning HTML and web design with HTMLGoodies and LissaExplains. Anyone remember those?
abetusk 34 days ago [-]
Jesus, what a refreshing site. People are so terrified of getting their hands dirty with HTML that they've forgotten how straight forward it is.
Abstractions, frameworks, static site builders, etc. are all great but we shouldn't shy away from understanding the basics.
defanor 34 days ago [-]
A few things in it that I would not put into a beginner's (or any) guide:
- Semantic tags (header, footer, main, section): machine-readable semantics can be fun to play with if one is so inclined, one can go even for RDFa, but AFAICT they will not do anything visible or useful, especially for a small beginner's website, but they complicate the guide.
- CSS: the page itself uses low-contrast pink text on a pink background, which is hard to read (and goes against W3C accessibility guidelines, which can be checked with one of the online contrast checkers as well), and provides similar low-contrast examples. It also makes links bold on hover, which moves the texts that follow them, and which is annoying.
- Viewport meta tag: this can be controversial, I think, but the tag itself is rather a hack to tell a browser "this page is not too broken, it can be rendered with a legible font size without breaking the markup". Teaching beginners to repeat that feels wrong both as promotion of such bad browser behavior, and as a road to potential misuse even of that (and the next version of the guide will have to include a new "this page really is not broken" invocation).
MrJohz 34 days ago [-]
> but AFAICT they will not do anything visible or useful
They are very useful for people using reader mode. I wouldn't worry about sections, though, they're not really used by many tools, as far as I'm aware.
> Viewport meta tag
It is not a hack, it is part of the html specification. You don't have to include it, but the browser defaults aren't great, and will not be changed due to backwards compatibility. Please always specify this tag, do not rely on browsers to break backwards compatibility because they won't.
chrismorgan 34 days ago [-]
>> Viewport meta tag
> It is not a hack, it is part of the html specification. You don't have to include it, but the browser defaults aren't great, and will not be changed due to backwards compatibility. Please always specify this tag, do not rely on browsers to break backwards compatibility because they won't.
It’s not part of the HTML Standard; what little underspecification there is is in the CSS Viewport Module Level 1 draft <https://drafts.csswg.org/css-viewport-1/#viewport-meta>. The HTML Standard refers to it once, while essentially talking about something completely different <https://html.spec.whatwg.org/multipage/parsing.html#speculat...>. The spec is incomplete and atrocious, and no one seems interested in improving it—it’s sat stagnant for more than a decade. It does things like use strtod to parse numbers, so that in theory (unless there’s some other document I don’t know about that replaces the meaning of “strtod”) an English user will parse initial-scale=1.5 correctly, while French would parse it as 1.0—but I hope no one has actually implemented it that way.
(Why is it part of CSS? Rendering stuff is mostly shifted into CSS’s domain, and also most of the things that started in meta tags arguably because of bad decisions end up being shifted into CSS proper, and that was the idea with @viewport, which was part of CSS Device Adaptation Module Level 1; but since everyone was apparently so supremely bored by the whole thing, they gave up <https://github.com/w3c/csswg-drafts/issues/4766>. But because it’s rendering, CSSWG is still probably the best place for it.)
—⁂—
Anyway: although it’s underspecified, it is… sufficiently consistent and settled, and absolutely invaluable. Every document being started from scratch, which has any intention of caring about mobile-sized screens at all, should include <meta name=viewport content="width=device-width,initial-scale=1">.
puchatek 34 days ago [-]
the page itself uses low-contrast pink text on a pink background, which is hard to read
Well, the author does say about herself that she loves making things pink so I guess this is a feature.
assimpleaspossi 34 days ago [-]
They are also inconsistent and wrong about the usage of a closing slash on the <img> tag. No HTML tag uses or needs a closing slash and never has in any HTML standard. The W3C Validator will flag this and even warn about potential problems doing it that way.
And before anyone replies, "But...but...XHTML!", XHTML is XML, not HTML.
assimpleaspossi 34 days ago [-]
They are also inconsistent and wrong about the usage of a closing slash on the <img> tag. No HTML tag uses or needs a closing slash and never has in any HTML standard.
And before anyone replies, "But...but...XHTML!", XHTML is XML, not HTML.
I'm happy I didn't start with those, or I would have probably never become a web developer.
It's surprising how often people recommend especially the MDN Web Docs to total beginners, when I've never seen any beginner enjoy or be able to use them. It's an amazing resource, but their content is not good for beginner web devs or people new to coding.
From my experience, beginners have a much better time with something like the InternetingIsHard guide.
You point to some very dense documentation sites. I am glad I didn't have to wade through those when I was a kid. This is the sort of site you can navigate when you know you have something to look up, most often not when you start out.
I like the idea of this as an introduction for a child to web development, but I feel like it (in isolation) is wanting. One of the most jarring bits of this page is that there is an almost immediate jump from this page to MDN, which is drastically too much for most 12 year olds. There is a lot of "do this, and then do that" style of instructure, but not very much child-friendly explanation as to why to do that. Most things described here are trivial to people who are familiar with the subject, but not anything obvious or natural or intuitive without the necessary context or experience.
Further, there is a significant push into HTML semantics before describing the simplest workflow of creation -> publishing that may lose the target audience's attention; I feel that describing a process more abstractly and then expounding on the details may be more helpful if you're teaching children how to make a website (websites are documents on another computer that you can ask for, this is an example of a very simple document, the document goes on a computer that talks to other computers and responds to their requests for documents, other computers then can see the document when they are responded to, etc.).
https://no-gravity.github.io/html_editor/
Originally, I made it for myself. To quickly do HTML/CSS/JS experiments. And I still use it for that use case.
Often when I show it to non-developer friends, I can see how they light up to coding for the first time. I think it is because it is so accessible. No signup, no setup, no long page load. Everything is instant, and they see each change the moment they type it.
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/if...
I am not sure if anything should be blocked by default, because that could always end in frustration when something that should work does not for mysterious reasons.
But it might make a good default to block all external requests when the editor gets a feature to link to code directly. Like ...html_editor/?code=<!doctype html><html>...
Then it could display an info box like "Initial code was loaded from your link and the sandbox was activated. Use the Sandbox menu to enable more features the code can use"
There was a bit of a discussion about this on HN two months ago here:
https://news.ycombinator.com/item?id=42448964
The editor is open source, so if you like, you can add the features you have in mind:
https://github.com/no-gravity/html_editor
data:text/html,<body oninput="i.srcdoc=h.value+'<style>'+c.value+'</style><script>'+j.value+'</script>'"><style>textarea,iframe{width:100%;height:50%}body{margin:0}textarea{width:33.33%;font-size:18}</style><textarea placeholder=HTML id=h></textarea><textarea placeholder=CSS id=c></textarea><textarea placeholder=JS id=j></textarea><iframe id=i>
My problem with 'data:' urls is that I have never found a way to add them to the homescreen on Android.
And wouldn't it be semantically more correct to put the <style> tag into the <head> and turning the <span> into a <p>aragraph? Since this is targeting beginners I'd think it's important to convey such fundamentals. But it might as well be that the HTML rules have changed since I left the game. It has been many years for me!
The reason is that it often makes the structure of websites much more logical. Often you want to define a piece of content, its layout and behavior in one specific place, not spread out across multiple places. Then the best solution is to have a <style> element right before the other DOM elements for that piece of content.
And for the html editor, it saves the user from thinking about one more element (<head>) which does not do anything that is visible to the user.
https://neocities.org/
It's one if those gems in the Internet
https://nekoweb.org/
You can use your own web domain for free!
Keep up the great work with such a guide, maybe you kickstart some careers with it!
I think this is why wordpress or drupal services are multimillion dollar companies.
The web is hard.
My experience as someone who programs but was never formally trained even if my job requires the skill set.
That made me laugh. I don't know, I still struggle with point a website to github.io.
For the developers, we are busy writing our own static site generators and blogging about it (which is a lot of fun too!)
I am glad to see something like this though. You might reach some people.
You see folks, when you had to live through doing this shit by hand, and if memory serves, this was even pre-css (or maybe pre separate css files, shit, maybe just pre-css2?) and your only dynamism was through cgi with C or Perl, because Cold Fusion cost waaay too much for mere mortals (and the Sun server costs were even more eye watering), you welcomed things like Linux, PHP, MySql and Apache with open arms. It was like being rescued from a refugee camp and being given prime rib. And think about this- if someone thinks PHP back in the version 3/4 days was salvation, that person has seen some real shit.
Point being, we came OUT of the woods. We knew better than to build rube goldberg machines that would lead us right back in, lol. We have a word for that- masochism.
Take what you know now, and simplify. Untangle the knots. Spring clean. Throw away the cruft. Free your minds.
And I know y’all can. Don’t be pretending like you don’t rewrite all your shit every year anyway ;)
Except it's really not.
Abstractions, frameworks, static site builders, etc. are all great but we shouldn't shy away from understanding the basics.
- Semantic tags (header, footer, main, section): machine-readable semantics can be fun to play with if one is so inclined, one can go even for RDFa, but AFAICT they will not do anything visible or useful, especially for a small beginner's website, but they complicate the guide.
- CSS: the page itself uses low-contrast pink text on a pink background, which is hard to read (and goes against W3C accessibility guidelines, which can be checked with one of the online contrast checkers as well), and provides similar low-contrast examples. It also makes links bold on hover, which moves the texts that follow them, and which is annoying.
- Viewport meta tag: this can be controversial, I think, but the tag itself is rather a hack to tell a browser "this page is not too broken, it can be rendered with a legible font size without breaking the markup". Teaching beginners to repeat that feels wrong both as promotion of such bad browser behavior, and as a road to potential misuse even of that (and the next version of the guide will have to include a new "this page really is not broken" invocation).
They are very useful for people using reader mode. I wouldn't worry about sections, though, they're not really used by many tools, as far as I'm aware.
> Viewport meta tag
It is not a hack, it is part of the html specification. You don't have to include it, but the browser defaults aren't great, and will not be changed due to backwards compatibility. Please always specify this tag, do not rely on browsers to break backwards compatibility because they won't.
> It is not a hack, it is part of the html specification. You don't have to include it, but the browser defaults aren't great, and will not be changed due to backwards compatibility. Please always specify this tag, do not rely on browsers to break backwards compatibility because they won't.
It’s not part of the HTML Standard; what little underspecification there is is in the CSS Viewport Module Level 1 draft <https://drafts.csswg.org/css-viewport-1/#viewport-meta>. The HTML Standard refers to it once, while essentially talking about something completely different <https://html.spec.whatwg.org/multipage/parsing.html#speculat...>. The spec is incomplete and atrocious, and no one seems interested in improving it—it’s sat stagnant for more than a decade. It does things like use strtod to parse numbers, so that in theory (unless there’s some other document I don’t know about that replaces the meaning of “strtod”) an English user will parse initial-scale=1.5 correctly, while French would parse it as 1.0—but I hope no one has actually implemented it that way.
(Why is it part of CSS? Rendering stuff is mostly shifted into CSS’s domain, and also most of the things that started in meta tags arguably because of bad decisions end up being shifted into CSS proper, and that was the idea with @viewport, which was part of CSS Device Adaptation Module Level 1; but since everyone was apparently so supremely bored by the whole thing, they gave up <https://github.com/w3c/csswg-drafts/issues/4766>. But because it’s rendering, CSSWG is still probably the best place for it.)
—⁂—
Anyway: although it’s underspecified, it is… sufficiently consistent and settled, and absolutely invaluable. Every document being started from scratch, which has any intention of caring about mobile-sized screens at all, should include <meta name=viewport content="width=device-width,initial-scale=1">.
And before anyone replies, "But...but...XHTML!", XHTML is XML, not HTML.
And before anyone replies, "But...but...XHTML!", XHTML is XML, not HTML.
It's surprising how often people recommend especially the MDN Web Docs to total beginners, when I've never seen any beginner enjoy or be able to use them. It's an amazing resource, but their content is not good for beginner web devs or people new to coding.
From my experience, beginners have a much better time with something like the InternetingIsHard guide.
- https://internetingishard.netlify.app/