Make Your Own Website: A beginner's guide
web.pixelshannon.com
web.pixelshannon.com
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:
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.
It's one if those gems in the Internet
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">.
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.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.