Jake Archibald is the best. 6 years ago he gave a talk on the JS event loop which made the subject way clearer than I thought possible with great humour
The XML world has abandoned doctype tags and DTDs too, in favour of `xsi:noNamespaceSchemaLocation="urn:company:product:bla:bla:bla"`. Much better! (genuinely, it's way better for many reasons!)
@@t3dotgg Are you suggesting that Prime's videos are only entertaining and not educational? I'm pissed off by realizing the fact that I hadn't leant any useful information at all😡!
Anybody else remember going through great lengths to make sure all code was strictly XHTML compliant for consistent rendering, then having to serve the page with the "transitional" tag/header anyway because Internet exploder would crash the whole page if an image was missing a closing tag?
HTML5 makes this easy: Self-closing tags DO NOT EXIST. The parser merely tolerates the closing slash to not error out. Every element needs to be closed with a separate end tag, except for void elements. (img, br, input... uhhh, probably some more)
My friend had a weird class in university, where his HTML had to be validated by an XML parser I learnt so much helping him that day. It was a crazy new undiscovered parallel world with languages like XSLT
20:22 "It can't remove it" Yes it can! It shouldn't remove the div part of the , it should remove the " /" part and leave an open div tag and possibly indent everything below it so people realize they left an unmatched open tag.
19:95 Ideally, issue a warning in cli and replace the self-closing bit of any elements that are not on the 'self-closing' list with a correct end tag without affecting surrounding text. Warning: Self-closing indicated on inappropriate element. Corrected to include an end tag. Then in your formatted text: Hello Should become Hello
This is video is something that should be on youtube / general tech media much more often: Documenting how you start with one assumption and then show how your mind is thoroughly changed by new information. You took us onto a journey where you became (a tiny bit of) a better engineer and we could witness that and grow a bit ourselves. Bravo. Funnily enough, I opened up this video with the feeling that the suggestion in the title is absolutely ridiculous. Then you brought up ASI and compared it to stuff like being closed automatically to make an argument for self-closing tags. But tbh, this kind of convinced me the other way. Regarding ASI, I think you shouldn't manually put semicolons (unless they're needed), because putting them at the end of lines doesn't free you from knowing how ASI works, as you can't just turn it off. And in the same manner, just because you use self-closing tags doesn't mean that you can forget about the weird rules like closing itself automatically and a closing a previously opened . So I'd rather make use of the "magic" where it's present, because I can't opt out of it anyways.
the first person who thought "we should guess what this mess means instead of just spitting out an error message" ruined browsers and web platform forever
I started in 2001. Oh, man... there were specs, and they were all over the place. The amount of "why?!" I asked... I'll never know. Crazy doctypes too. I was impressed with the direction HTML5 seemed to take, but it was a pain in the beginning. I used to have HTML Validator for Firefox to make sure I don't trigger quirks mode, and once HTML5 came out it was really annoying that there was no offline validator for the browser. I mean it's nice to see the warnings and errors on live pages, but back then I didn't always have internet at home, and I had to validate the HTML I was making. 🙃 But I rarely had issues with it. After dealing with plenty of HTML 4, I became confident enough to switch from Transitional to Strict. 😆 And of course it was a bit painful, but what's life if you don't brave it? Boring!
@@kneekooSo you guys too developed through the pain of IE6? Nothing, even the extra work that got dumped on us when responsive web dev became a thing, was worse than dealing with that browser!
@@Sandromatic The validator gives you comprehensive information about anything that doesn't conform with the doctype chosen for an HTML document. Try "w3c validation" and give it a URL to analyze it. That kind of feedback was possible with HTML4, but when HTML5 came out only online validation was possible with that Firefox extension.
10:35 "One of the great things about browser is they're error-tolerant, and browsers weren't interested in giving that up." I disagree. There are two types of HTML out there. The ones which are written like browsers aren't error tolerant. These are pretty nice to work with, especially if you haven't written the HTML document yourself. And the ones which are written in a way that browsers have to do a LOT of work at dealing with it. These suck to work with and contain way too many bugs from my experience (to a point where I would prefer it to just crash/error out; it would at least put it considerably higher on a priority list for fixing).
I get what you mean, but-like Jake mentioned with the surgeon hours example-it's better for browser to at least display _something_ rather than nothing, especially for critical web pages. Browsers ought to be error-tolerant, but web dev tools/environments should lean towards crashing on error. It's the best of a bad situation.
@@Yxcell There could be a happy middle ground of displaying giant red lettered error page in the background of all the properly displayed content. The surgery hours would be visible, however every user will also know that there is something wonky with the page.
@@TelhiasYes, that could work. One concern would be that it might confuse people even more if they see the error being shown but don't see the actual problem with the webpage. Perhaps it would require some A/B testing by browser devs to make sure it isn't too confusing for people.
Interresting video. When I took my education in web development, it was right around the time where we switched from XHTML to HTML5, actually right around that time, so some of the stuff we did was in XHTML and some other stuff was in HTML5, very confusing time. But even then it seemed like even academia got the closing tag wrong.
I had someone import my HTML code into their own workflow project. The first thing they said was "This could be a bit prettier" and time slowed down as a slow "NOOOOOOO" came out of me unable to reach their mousehand to slap it away before they clicked "Prettify"… my eyes watered up as I saw so many /> appear in my already valid html.
Wait this guy didn't know Jake before? How? He's literally been on every Google IO stream, he did HTTP203, tons of articles etc. He's like the one guy I thought people know.
And it's actually inspired me to write my own system based around Yew that checks XHTML+XML (which has access to all of the HTML5 tags and features, still) as opposed to HTML. XML/XHTML can be parsed at compile time, and, necessarily, guarantees that any combination of a component based approach ends up valid in the final document, including via AJAX patterns.
This brings me back to the Chrome for Developers videos with Jake and Surma. Always some good info on quirks and upcoming features. Good stuff, I miss it. Jake sure knows his browsers.
Ya in general I don't close any html tags unless I have to. Browsers are good enough at guessing where to place em and you should always be looking to save every byte before anything else
I'm working on a templating engine that has an HTML-like syntax, and I have some tags that have different semantics depending on whether they're self-closing or not. Because of that, I made the decision to require the slash at the end for all such tags, to make it less confusing.
20:22 : Text [no close tag] is perfectly valid HTML5, sadly. the will span until the next close div, open div, close body, close html, or failing that the end of the document. (it may or may not close at the next close block-tag, but I don't remember) It's the same thing as first second third and it's garbage, don't do that...
No, that's wrong. Leaving out the is valid because it's an optional tag that the spec explicitly allows to be omitted in certain situations. However, is not optional, and leaving it out is invalid HTML. The only reason you don't see an error message is because the HTML spec also specifies how to handle invalid HTML. If you run each example through an HTML5 validator you will see the difference.
20:27 Prettier could just remove the / in the div, and then give an error to the user instructing him/her to add an explicit closing tag (while informing about self-closing tags not being supported).
1:40 When I first started learning HTML, that was EXPLICITLY what scared me out of understanding what it was for...copy-paste was my friend, unless I was offline/paper, and then I just used the no-no " -> ". I was a happy camper when html5 said "back to basics".
No elements that can have content can self close. That's why you can't self-close a tag even when you have a `src` attribute. Self closing tags are ONLY for readability, and they do work for that.
Great video. I always knew you didn't need the / in HTML, but didn't know that explicit self closing tags were totally invalid in HTML. Awesome video and article.
On the keyboard and RSI pain, just switching to a mechanical keyboard with tactile feedback made a massive difference. I used a Model M based keyboard until it broke around 2000 and for the better part of a decade tried so many other keyboards... I found out about Unicomp and went back... So much better. Today I tend to use Cherry MX Brown switch keyboard as they are less noisy but don't feel as good. Much more silent though. I tend to type relatively light and don't generally bottom out on key presses. So typing doesn't create the stress events for me. I've tried a few knock off brown switch and similar keyboards and it's not nearly as good. The tactile bump is really important as is not bottoming out when typing.
When I first learned about how self-closing tags in HTML always self-close and those who can't never do I literally screamed. That actually made me feel pain. What the f_ck!? Those hours I spent debugging because of one little div that I self-closed...
The journeys are started by someone saying "Fuck it, let's make this right this time", the routes taken and destinations reached are defined by the tag-alongs saying"Fuck it, that's good enough".
No space before /> just looks weird. I do use though. But... not , only . Because it looks right and it doesn't tickle me in a wrong way. As Uncle Roger says: "just use feeling".
It always made sense to me. If an element doesn't contain anything, you would not have an "opening" or "closing" tag. Just a tag to insert it. Different kinds of tags :)
I am a victim of this as well when I was student, some uses image tag using short-hand self closing tag approach and it became a problem as the tool that we are using cannot recognize it.
prettier problem: I would claim that 'hello' should be converted to 'hello' as that is what the developer intended. It also solves the problem of where to place the tag.
The developer would test on a browser, so when the page is done and then prettier changes it to it could break the page for no reason. Especially if prettier is part of CI. Also, if you open any old project and prettier does this transformation, it'd mess things up. Messing things up is maybe the only way to teach people, but it'll never happen. Oh well.
What's missing from the article/video is that at 8:14 if you save the file as .xhtml, the browser will actually parse it correctly (as an xml). In this case the behaviour is the same as the JSX talked about later in the article/video. To me it isn't really a surprising behaviour, it's analogous to serving a text file that happens to have html markup and being surprised the browser renders it as plain text. In these cases the browser does what it's told to do. That said, yes, it is surprising/misleading having self-closing tags when using html.
What the /> does is give context and information especially to a new learner. When you're learning HTML, you don't know which elements can have children but when you see a self-closing tag and learn to recognize it that way, it very explicit.
I did not know about either, but many formatters glitch. So I do that to look correctly.... Someone can open it in VS or Notepad++,something arcane never take a risk over one character.
This comment section has really helped redirect my learning path a few times. Lately I've been going down this "I need to master HTML before I learn JavaScript" rabbit hole. How good should you be at HTML and CSS before switching focus to JavaScript. I didn't start programming to make websites, but this journey down the HTML rabbit hole has inspired me to make some fun websites (once I have the JavaScript skills). Thank you amazing person in advance 🙏
I agree with the first reply. If you are comfortable with the basic concepts of html and css (open and closing tags, nesting, and referencing css for styles) Which is like the very basics, then you can start adding js too. You’ll grow in all of them as you practice
You don't need to master anything to start your journey; just learn basics of stuff and start working on stuff. I'd say 2 days of HTML, 2 days of CSS, two weeks of JS is enough to get starting. Don't forget that these are the tools, not the job itself; knowing your tools can be good in some cases, but if you don't know how to do stuff, there is no point in knowing your tools. And even in the case of knowing your tools, the thing in the article with self closing tags is just a niche artifact that you probably will never need to know to work with it.
Nothing like a good reminder of why I got away from web dev. I didn't know why I hated it so much back then, but now that I look back, it's because it's all just so janky... But, give me some C with raw pointers, on an embedded system with barely any memory and I'm as happy as a pig in sh | t.
Actually, putting slash on self closing tags is defined as ignored because of the error tolerance, but as some said: - Being a good programmer is not about writing code that works, but also code your team and your future you can read. - Learn how to paint the regular way then paint the way you want The slash is not for computer parsing, it's for human understanding and formating, all thoses newlines, indentations and whitespace alignment are ignored, but make it easier to understand Sure anyone should learn how the parser works, Removing informations useful for humans is the job of minimifiers, Adding informations useful for humans is the job of beautifiers, So I would never leave to add ending slash the same I would never stop indenting and aligning the code
@@snorman1911 First idea is that BR is easy because it's everywhere, but what about embed ? if you broke a general rule with exception, it can lead to ugly code, I had junior devs writing html with pair img, self closing video and a lot of atrocity to html and they couldn't find why it didn't work, why their layout where so broken, I teached them the general rule of pair and orphan like in xthml and their code where at least parsable, but also readable, it was more obvious that this div shouldn't be self closing but an opening whith a closing tag As a joke, do you know that html specify that closing tags are totally optionnal, do you put pair li or only open li ? Which one is more readable ?
Was completely shocked to learn this about self closing divs debugging a production bug a few months ago. That prettier chose to do this in Vue templates is an awful awful awful decision.
I once saw a bug report that someone filed against a screen reader because the screen reader wouldn't label when they wrote They wanted to label a line break lmaoooooooo.
i don't get why disabled="disabled" and selected="selected" is so funny. It is just how XHTML and HTML still works. If you don't set a value, the value is equal to the key, so disabled is the same as disabled="disabled". 6:23 "The bug you hate" is not a bug. It's just how JS works. It's a feature.
I'm so old, I didn't know the kids didn't write (or copy/paste) all that xml version/DOCTYPE/Strict crap at the top anymore, like I had to do back around 2000.
That's not the point of the analogy. The point is that HTML should be treated as its own separately thing from XML, even if HTML could be written as XML-compliant and parsed with an XML parser. Likewise, JSON should be treated as separately from YAML, even if it is a subset of YAML and can be parsed by a YAML parser.
@@Yxcell Clarification: that is your point... and since you aren't the creator of the video, it isn't the point here. And, I am going to disagree with you. If they're designed to be compatible or a superset, they aren't treated separately. Why would the creator of YAML go through all of the trouble to make it a superset of JSON if you're not supposed to ever think of JSON? That statement is kind of stupid on its face.
@@dus10dnd To be clear, it was Jake's point (the blog author), not Primeagen's (video creator). While I don't know what the reasoning behind YAML's design decisions, from what I've read it wasn't even a _perfect_ superset of JSON prior to YAML 1.2 and not all implementations of YAML parsers correctly handle JSON data. (I'd post a few links but YT seems to remove comments with links, unfortunately.) More broadly, developers should prefer the tool that tightly corresponds to their requirements. Use HTML parsers for parsing HTML, not XML parsers. Likewise, use JSON parsers for parsing JSON, not YAML parsers. As an analogy, functionality-wise, your hand is a superset of a hammer. But, if you're trying to drive a nail into a piece of wood, you should use a hammer instead of your hand, as it's better suited for the task.
@@Yxcell Why do you want to continue this conversation and prove your foolishness? Take a seat, kid. Nobody implied, let alone said, that it was Prime's. You're reading into far too many things that were never said. Perhaps you have DID and you've been having a conversation with yourself. You should seek the assistance of a medical professional.
@@dus10dnd Your original comment wasn't relevant to the video either, buddy. All I was trying to do was to give your worthless comment some value by responding to it. Is that clear enough for you?
But classname="foo" isn't a thing in regular html or js. (well, you can put in on an html element but it doesn't do anything) It's jsx just adding its own special thing when class="foo" would've been much more direct.
@@cameron7374 the name "className" is use by the DOM Standard to avoid conflict with the class keyword in many languages that are used to manipulate the DOM. Class and ClassName are different, class is an HTML Attribute and className is a DOM property
That type of lower arm pain is often seen in parents of babies. Afaik from the static load of carrying the little one(s). And bad ergonomics at a computer probably don't help.
I got back into web dev here after a long hiatus, and I was still in XHTML thinking. I always thought closing tags like was just annoying. Finding out that was outdated was like a burden lifted off my back! I'm glad that the XML experiment of the 2000s is gone.
You can't even parse it with an XML parser because of HTML named entities like nbsp that don't exist in XML. For XML you can use hex or decimal but not html names.
I had to learn xhtml in school when html 5 was already there... I hated it like I hate xml nowadays... I like stuff being short and compact and that insane expressiveness felt just wrong...
XML is great for document markup (bold, italic, etc) just like in HTML. Most of the hate for XML comes from people trying to use it to represent structured data when it's really for document markup.
That's why I always hand typed semicolons and closing tags untill Prettier. Imagine having you engine insert a million semicolons, that's going to make your program humanly slow, you will feel it, not to mention the bugs.
3:10 WHAT!? Was this man a professional web developer? Was he hired to spread misinformation? is a void tag. It does NOT have a closing tag in HTML. There is no "Void elements only have a start tag; end tags must NOT be specified for void elements."
I don't of any other language where the syntax allows opening without closing, if you use a "{" and don't have a corresponding "}" and "sod it" is a valid response.
Calling SVG 'savage', why did I not come up with that 😂
This one took me out.
Savage, squeal, chatgippity... It's interesting to learn the Primeagen jargon.
I’m hearing John Malkovich speak with a french accent.
Idk maybe because you're low on IQ?
My fav of his pronounciations for some time.
Jake Archibald is the best. 6 years ago he gave a talk on the JS event loop which made the subject way clearer than I thought possible with great humour
I was a new comer scared by the "Doctype"...
Then I learnt about "quirks mode"...
Lets just keep the doctype where it is :D
The XML world has abandoned doctype tags and DTDs too, in favour of `xsi:noNamespaceSchemaLocation="urn:company:product:bla:bla:bla"`. Much better!
(genuinely, it's way better for many reasons!)
Very true. I learned last week that ommiting the doctype will make things like :has() behave very weirdly.
this video belongs on the list of ThePrimeagen content that is genuinely educational, and not merely entertaining.
What’s the point of making a list with 1 video in it?
(That was a joke please don’t sue me)
@@t3dotgg LULZ !
@t3dotgg got'em!
@@t3dotgg Are you suggesting that Prime's videos are only entertaining and not educational? I'm pissed off by realizing the fact that I hadn't leant any useful information at all😡!
what the fuck I did not know that either, I equally switched opinion just as hard at the exact same moment lmfao
I am shooketh. I remember the push toward XHTML, guess I just didn't realize it was over.
pog omk
Same
Didn't realize it's from Jake, he's such web OG. I learned so much from his stuff (especially stuff they did with Surma)
Jake is the developers developer. I REALLY enjoy his content (and Surma too!).
Yeah, imagine thinking Jake might be wrong about this! 😂 I didn't realise he wasn't working on Chrome/at Google any more
Was a huge fan of Jake and Paul in HTTP203, and later Surma. Definitely OG. Just learned they started another podcast OTMT
I was just about to recommend the HTTP203 podcast. Love to see it has already been done!
he is the legend
Anybody else remember going through great lengths to make sure all code was strictly XHTML compliant for consistent rendering, then having to serve the page with the "transitional" tag/header anyway because Internet exploder would crash the whole page if an image was missing a closing tag?
The IDE did the job. Why would it be missing anything?
I was using NetBeans and some other one for PHP that I can't remember anymore.
"Internet exploder" - is that a deliberate typo? Since it's quite fitting...
@@steffahn internet exploder is a long-honored term of art. as is "windows exploder", but don't confuse the two.
@@steffahn It is canon.
@@y00t00b3r..Hey, I'll take Windows Explorer over the poorly-named "Finder" for macOS any day.
HTML5 makes this easy:
Self-closing tags DO NOT EXIST.
The parser merely tolerates the closing slash to not error out.
Every element needs to be closed with a separate end tag, except for void elements. (img, br, input... uhhh, probably some more)
I was burnt so many times by trying to self close a .
Honestly I still have to keep reminding myself.
and that is exactly why self closing tags SHOULD become a thing in HMTL. There are tags and even custom tags that you might want to self close.
My friend had a weird class in university, where his HTML had to be validated by an XML parser
I learnt so much helping him that day. It was a crazy new undiscovered parallel world with languages like XSLT
20:22 "It can't remove it"
Yes it can!
It shouldn't remove the div part of the , it should remove the " /" part and leave an open div tag and possibly indent everything below it so people realize they left an unmatched open tag.
is it work on only?? , but my html like that, i am searching but nothing how to solve this
SGML had optional closing tags and the pain it caused is the reason XML was created
19:95 Ideally, issue a warning in cli and replace the self-closing bit of any elements that are not on the 'self-closing' list with a correct end tag without affecting surrounding text.
Warning: Self-closing indicated on inappropriate element. Corrected to include an end tag.
Then in your formatted text:
Hello
Should become
Hello
Now here the question is: should it be fixed to what it means in xml or what it means in html? if the first, why not just use xhtml?
To me it feels like HTML and JavaScript are racing to be the weirdest one 😂😂😅
God, remembering how often I got in trouble for not using in my CS class, this infuriates me xD
I appreciate articles written by people who have esoteric knowledge on common and established technologies and share their insights with us mortals.
This is video is something that should be on youtube / general tech media much more often: Documenting how you start with one assumption and then show how your mind is thoroughly changed by new information. You took us onto a journey where you became (a tiny bit of) a better engineer and we could witness that and grow a bit ourselves. Bravo.
Funnily enough, I opened up this video with the feeling that the suggestion in the title is absolutely ridiculous.
Then you brought up ASI and compared it to stuff like being closed automatically to make an argument for self-closing tags.
But tbh, this kind of convinced me the other way. Regarding ASI, I think you shouldn't manually put semicolons (unless they're needed), because putting them at the end of lines doesn't free you from knowing how ASI works, as you can't just turn it off.
And in the same manner, just because you use self-closing tags doesn't mean that you can forget about the weird rules like closing itself automatically and a closing a previously opened . So I'd rather make use of the "magic" where it's present, because I can't opt out of it anyways.
the first person who thought "we should guess what this mess means instead of just spitting out an error message" ruined browsers and web platform forever
Jake Archibald articles always hit me with tons of facts and logic
What a read!
2004 was a very cursed year to learn HTML. I'm forever broken for it.
It's like a bad touch. Stays with you for the rest of your life.
I started in 2001. Oh, man... there were specs, and they were all over the place. The amount of "why?!" I asked... I'll never know. Crazy doctypes too. I was impressed with the direction HTML5 seemed to take, but it was a pain in the beginning. I used to have HTML Validator for Firefox to make sure I don't trigger quirks mode, and once HTML5 came out it was really annoying that there was no offline validator for the browser.
I mean it's nice to see the warnings and errors on live pages, but back then I didn't always have internet at home, and I had to validate the HTML I was making. 🙃 But I rarely had issues with it. After dealing with plenty of HTML 4, I became confident enough to switch from Transitional to Strict. 😆 And of course it was a bit painful, but what's life if you don't brave it? Boring!
@@kneekooSo you guys too developed through the pain of IE6? Nothing, even the extra work that got dumped on us when responsive web dev became a thing, was worse than dealing with that browser!
@@kneekooI mean... Could you not just open the local html file in the browser? You don't need internet for that.
@@Sandromatic The validator gives you comprehensive information about anything that doesn't conform with the doctype chosen for an HTML document. Try "w3c validation" and give it a URL to analyze it.
That kind of feedback was possible with HTML4, but when HTML5 came out only online validation was possible with that Firefox extension.
Ayyy Jake Archibald!
VueJS actually enforces (through ESLint) not using the slash for self-closing tags. It's pretty interesting.
Wrist/hand pain really is quite scary when you depend on your hands for your livelihood
Cant wait for LLM/ML/AGI so i can just speak stuff and it writes it and modifies it in real time.
I'm a professional sperm donor and can 100% relate to this.
10:35 "One of the great things about browser is they're error-tolerant, and browsers weren't interested in giving that up."
I disagree.
There are two types of HTML out there.
The ones which are written like browsers aren't error tolerant. These are pretty nice to work with, especially if you haven't written the HTML document yourself.
And the ones which are written in a way that browsers have to do a LOT of work at dealing with it. These suck to work with and contain way too many bugs from my experience (to a point where I would prefer it to just crash/error out; it would at least put it considerably higher on a priority list for fixing).
I get what you mean, but-like Jake mentioned with the surgeon hours example-it's better for browser to at least display _something_ rather than nothing, especially for critical web pages.
Browsers ought to be error-tolerant, but web dev tools/environments should lean towards crashing on error. It's the best of a bad situation.
@@Yxcell There could be a happy middle ground of displaying giant red lettered error page in the background of all the properly displayed content. The surgery hours would be visible, however every user will also know that there is something wonky with the page.
@@TelhiasYes, that could work. One concern would be that it might confuse people even more if they see the error being shown but don't see the actual problem with the webpage. Perhaps it would require some A/B testing by browser devs to make sure it isn't too confusing for people.
Disagree. Working with user inputted XML is a major pain exactly for this reason.
perfect zoom in
Interresting video. When I took my education in web development, it was right around the time where we switched from XHTML to HTML5, actually right around that time, so some of the stuff we did was in XHTML and some other stuff was in HTML5, very confusing time. But even then it seemed like even academia got the closing tag wrong.
I knew that I recognized that blogpost style! I was the great Jake Archibald!! a truly master of obscure browser issues
I had someone import my HTML code into their own workflow project. The first thing they said was "This could be a bit prettier" and time slowed down as a slow "NOOOOOOO" came out of me unable to reach their mousehand to slap it away before they clicked "Prettify"… my eyes watered up as I saw so many /> appear in my already valid html.
Wait this guy didn't know Jake before? How? He's literally been on every Google IO stream, he did HTTP203, tons of articles etc. He's like the one guy I thought people know.
Razor syntax bit me in almost exactly the same way as the JSX example. It brought me down the same rabbit hole.
And it's actually inspired me to write my own system based around Yew that checks XHTML+XML (which has access to all of the HTML5 tags and features, still) as opposed to HTML.
XML/XHTML can be parsed at compile time, and, necessarily, guarantees that any combination of a component based approach ends up valid in the final document, including via AJAX patterns.
"The foe's DISABLE was Disabled!"
This brings me back to the Chrome for Developers videos with Jake and Surma. Always some good info on quirks and upcoming features. Good stuff, I miss it. Jake sure knows his browsers.
Ya in general I don't close any html tags unless I have to. Browsers are good enough at guessing where to place em and you should always be looking to save every byte before anything else
I keep the /> because for my selfwritten parsers I don't want to walk through the hell that is HTML
I'm working on a templating engine that has an HTML-like syntax, and I have some tags that have different semantics depending on whether they're self-closing or not. Because of that, I made the decision to require the slash at the end for all such tags, to make it less confusing.
Have you considered using XML? Though if it's for educational purposes only, full steam ahead!
Gunna be honest, wasn't ready for Luke Smith chilling in the corner flexing on us lowly pleabs.
20:22 : Text [no close tag] is perfectly valid HTML5, sadly. the will span until the next close div, open div, close body, close html, or failing that the end of the document. (it may or may not close at the next close block-tag, but I don't remember)
It's the same thing as first second third and it's garbage, don't do that...
No, that's wrong. Leaving out the is valid because it's an optional tag that the spec explicitly allows to be omitted in certain situations. However, is not optional, and leaving it out is invalid HTML. The only reason you don't see an error message is because the HTML spec also specifies how to handle invalid HTML. If you run each example through an HTML5 validator you will see the difference.
20:27 Prettier could just remove the / in the div, and then give an error to the user instructing him/her to add an explicit closing tag (while informing about self-closing tags not being supported).
Amazing article by Jake, who uses Arch and is Bald.
1:40 When I first started learning HTML, that was EXPLICITLY what scared me out of understanding what it was for...copy-paste was my friend, unless I was offline/paper, and then I just used the no-no " -> ". I was a happy camper when html5 said "back to basics".
No elements that can have content can self close. That's why you can't self-close a tag even when you have a `src` attribute. Self closing tags are ONLY for readability, and they do work for that.
Great video. I always knew you didn't need the / in HTML, but didn't know that explicit self closing tags were totally invalid in HTML. Awesome video and article.
On the keyboard and RSI pain, just switching to a mechanical keyboard with tactile feedback made a massive difference. I used a Model M based keyboard until it broke around 2000 and for the better part of a decade tried so many other keyboards...
I found out about Unicomp and went back... So much better. Today I tend to use Cherry MX Brown switch keyboard as they are less noisy but don't feel as good. Much more silent though.
I tend to type relatively light and don't generally bottom out on key presses. So typing doesn't create the stress events for me.
I've tried a few knock off brown switch and similar keyboards and it's not nearly as good. The tactile bump is really important as is not bottoming out when typing.
When I first learned about how self-closing tags in HTML always self-close and those who can't never do I literally screamed. That actually made me feel pain. What the f_ck!? Those hours I spent debugging because of one little div that I self-closed...
The journeys are started by someone saying "Fuck it, let's make this right this time", the routes taken and destinations reached are defined by the tag-alongs saying"Fuck it, that's good enough".
15 years of HTML programming and i didn't know that doesn't work... But i knew right the way that this 💯 works in React 🎉
HTML is not programming xD
I have a bad surprise for you. 15 years and not knowing the absolute basics?
W3c spec explains it.
Skill issue :D@@ZelenoJabko
This is actually Prime's joke i just stole it :D@@GreyDeathVaccine
No space before /> just looks weird. I do use though. But... not , only . Because it looks right and it doesn't tickle me in a wrong way. As Uncle Roger says: "just use feeling".
Jake Archibald is a legend
It always made sense to me. If an element doesn't contain anything, you would not have an "opening" or "closing" tag. Just a tag to insert it. Different kinds of tags :)
0:25 wow a 5 gentlemen of the apocalypse. Who wouldve thought wed be hit with this collab
I am a victim of this as well when I was student, some uses image tag using short-hand self closing tag approach and it became a problem as the tool that we are using cannot recognize it.
prettier problem: I would claim that 'hello' should be converted to 'hello' as that is what the developer intended. It also solves the problem of where to place the tag.
The developer would test on a browser, so when the page is done and then prettier changes it to it could break the page for no reason. Especially if prettier is part of CI. Also, if you open any old project and prettier does this transformation, it'd mess things up.
Messing things up is maybe the only way to teach people, but it'll never happen. Oh well.
The self-closing div issue had me so confused on this one project I was working on; truly, a menace
What's missing from the article/video is that at 8:14 if you save the file as .xhtml, the browser will actually parse it correctly (as an xml). In this case the behaviour is the same as the JSX talked about later in the article/video. To me it isn't really a surprising behaviour, it's analogous to serving a text file that happens to have html markup and being surprised the browser renders it as plain text. In these cases the browser does what it's told to do. That said, yes, it is surprising/misleading having self-closing tags when using html.
What the /> does is give context and information especially to a new learner. When you're learning HTML, you don't know which elements can have children but when you see a self-closing tag and learn to recognize it that way, it very explicit.
I did not know about either, but many formatters glitch. So I do that to look correctly.... Someone can open it in VS or Notepad++,something arcane never take a risk over one character.
I still prefer Lisp.
Emacs Lisp for me 🙂
Lisp enjoyers are the vegans of software dev. Not an insult, just an observation
I was expecting this to be a Pug/Jade Article
I was not expecting luke smith in the video
This comment section has really helped redirect my learning path a few times. Lately I've been going down this "I need to master HTML before I learn JavaScript" rabbit hole. How good should you be at HTML and CSS before switching focus to JavaScript. I didn't start programming to make websites, but this journey down the HTML rabbit hole has inspired me to make some fun websites (once I have the JavaScript skills). Thank you amazing person in advance 🙏
If you can implement some very basic things in HTML and CSS then you're ready to start JS
I agree with the first reply. If you are comfortable with the basic concepts of html and css (open and closing tags, nesting, and referencing css for styles)
Which is like the very basics, then you can start adding js too.
You’ll grow in all of them as you practice
You don't need to master anything to start your journey; just learn basics of stuff and start working on stuff. I'd say 2 days of HTML, 2 days of CSS, two weeks of JS is enough to get starting. Don't forget that these are the tools, not the job itself; knowing your tools can be good in some cases, but if you don't know how to do stuff, there is no point in knowing your tools. And even in the case of knowing your tools, the thing in the article with self closing tags is just a niche artifact that you probably will never need to know to work with it.
@@Average-Lizard thank you 👍
@@kulkalkul I appreciate the advice. 🙏
0:25 flip you are doing a great job 👍
I never even thought about this, but now I completely agree with that guy.
Nothing like a good reminder of why I got away from web dev. I didn't know why I hated it so much back then, but now that I look back, it's because it's all just so janky...
But, give me some C with raw pointers, on an embedded system with barely any memory and I'm as happy as a pig in sh | t.
Actually, putting slash on self closing tags is defined as ignored because of the error tolerance, but as some said:
- Being a good programmer is not about writing code that works, but also code your team and your future you can read.
- Learn how to paint the regular way then paint the way you want
The slash is not for computer parsing, it's for human understanding and formating, all thoses newlines, indentations and whitespace alignment are ignored, but make it easier to understand
Sure anyone should learn how the parser works,
Removing informations useful for humans is the job of minimifiers,
Adding informations useful for humans is the job of beautifiers,
So I would never leave to add ending slash the same I would never stop indenting and aligning the code
What about makes that any more meaningful to a human than ? Or am I misunderstanding you?
@@snorman1911 First idea is that BR is easy because it's everywhere, but what about embed ? if you broke a general rule with exception, it can lead to ugly code, I had junior devs writing html with pair img, self closing video and a lot of atrocity to html and they couldn't find why it didn't work, why their layout where so broken, I teached them the general rule of pair and orphan like in xthml and their code where at least parsable, but also readable, it was more obvious that this div shouldn't be self closing but an opening whith a closing tag
As a joke, do you know that html specify that closing tags are totally optionnal, do you put pair li or only open li ?
Which one is more readable ?
10:21 the one that displays opening hours of the surgery and a warning in console
This is the developer version of "Would you still love me if I was a worm"
I've been down this rabbit hole before, it was open on the other side. Honestly I'm not sure if I ever really left the hole
6:40 this isn't a bug because you deserve broken code if you put opening braces on new lines 😊
This explained a lot. Now I know why would never work even though, in my mind, it had everything it needed.
Was completely shocked to learn this about self closing divs debugging a production bug a few months ago. That prettier chose to do this in Vue templates is an awful awful awful decision.
21:30 The name??!
After watching this, I think I'll still continue explicitly closing my brs imgs and inputs, but I might give the content type header a try. 😅
I guess I dont think having a "list" of container elements that can't self close is that wild. Maybe I've just accepted my fate.
I once saw a bug report that someone filed against a screen reader because the screen reader wouldn't label when they wrote
They wanted to label a line break lmaoooooooo.
I'm impressed by how consistent you are with your video uploads! Do you manage to do this daily while also holding down a job?
6:10 that bug drives me nuts as well!
i don't get why disabled="disabled" and selected="selected" is so funny. It is just how XHTML and HTML still works. If you don't set a value, the value is equal to the key, so disabled is the same as disabled="disabled".
6:23 "The bug you hate" is not a bug. It's just how JS works. It's a feature.
Does anybody have a link to the computerphile video he mentioned about html being hyper-resilient?
If I could go back in time, I wouldn't take out evil leaders - I'd just go to tech companies and yell "fix your sh*t !!!!" and make them fix it...
That hard cut to "IT'S IN THE DIV" OMG
I'm so old, I didn't know the kids didn't write (or copy/paste) all that xml version/DOCTYPE/Strict crap at the top anymore, like I had to do back around 2000.
POV: You and your team in discord at 3AM trying to fix broken prod 0:28
Uh... YAML is a superset of JSON... so you can (well, should be able to) parse JSON with a YAML parser, as long as it meets the full spec.
That's not the point of the analogy. The point is that HTML should be treated as its own separately thing from XML, even if HTML could be written as XML-compliant and parsed with an XML parser.
Likewise, JSON should be treated as separately from YAML, even if it is a subset of YAML and can be parsed by a YAML parser.
@@Yxcell Clarification: that is your point... and since you aren't the creator of the video, it isn't the point here. And, I am going to disagree with you. If they're designed to be compatible or a superset, they aren't treated separately. Why would the creator of YAML go through all of the trouble to make it a superset of JSON if you're not supposed to ever think of JSON? That statement is kind of stupid on its face.
@@dus10dnd To be clear, it was Jake's point (the blog author), not Primeagen's (video creator).
While I don't know what the reasoning behind YAML's design decisions, from what I've read it wasn't even a _perfect_ superset of JSON prior to YAML 1.2 and not all implementations of YAML parsers correctly handle JSON data. (I'd post a few links but YT seems to remove comments with links, unfortunately.)
More broadly, developers should prefer the tool that tightly corresponds to their requirements. Use HTML parsers for parsing HTML, not XML parsers. Likewise, use JSON parsers for parsing JSON, not YAML parsers.
As an analogy, functionality-wise, your hand is a superset of a hammer. But, if you're trying to drive a nail into a piece of wood, you should use a hammer instead of your hand, as it's better suited for the task.
@@Yxcell Why do you want to continue this conversation and prove your foolishness? Take a seat, kid. Nobody implied, let alone said, that it was Prime's. You're reading into far too many things that were never said. Perhaps you have DID and you've been having a conversation with yourself. You should seek the assistance of a medical professional.
@@dus10dnd Your original comment wasn't relevant to the video either, buddy. All I was trying to do was to give your worthless comment some value by responding to it.
Is that clear enough for you?
17:30 those are not really "secret" those are just mor "DOM" like names because we are doing html in js
But classname="foo" isn't a thing in regular html or js. (well, you can put in on an html element but it doesn't do anything)
It's jsx just adding its own special thing when class="foo" would've been much more direct.
@@cameron7374 the name "className" is use by the DOM Standard to avoid conflict with the class keyword in many languages that are used to manipulate the DOM. Class and ClassName are different, class is an HTML Attribute and className is a DOM property
Is the self closing div ( This is inside the div) real or is the browser going into quirks mode and fixing it for you?
6:56 Brendan Eich*?
You need to start telling Flip to do exactly the opposite of what you want. 😂
That type of lower arm pain is often seen in parents of babies. Afaik from the static load of carrying the little one(s). And bad ergonomics at a computer probably don't help.
I went into this article pretty solidly in disagreement and finished in total agreement.
Hey, where is the link to the keyboard? LOL
I got back into web dev here after a long hiatus, and I was still in XHTML thinking. I always thought closing tags like was just annoying. Finding out that was outdated was like a burden lifted off my back! I'm glad that the XML experiment of the 2000s is gone.
> "Flip zoom in"
> Zooms out
I went in dubious, but at the very end - where he explains it's misleading to what actually happening - I was fully on board.
You can't even parse it with an XML parser because of HTML named entities like nbsp that don't exist in XML. For XML you can use hex or decimal but not html names.
I had to learn xhtml in school when html 5 was already there... I hated it like I hate xml nowadays...
I like stuff being short and compact and that insane expressiveness felt just wrong...
XML is great for document markup (bold, italic, etc) just like in HTML. Most of the hate for XML comes from people trying to use it to represent structured data when it's really for document markup.
That's why I always hand typed semicolons and closing tags untill Prettier. Imagine having you engine insert a million semicolons, that's going to make your program humanly slow, you will feel it, not to mention the bugs.
Jake Archibald is an absolute G. Surprised he hasn't heard of him.
3:10 WHAT!?
Was this man a professional web developer? Was he hired to spread misinformation?
is a void tag. It does NOT have a closing tag in HTML. There is no
"Void elements only have a start tag; end tags must NOT be specified for void elements."
I don't of any other language where the syntax allows opening without closing, if you use a "{" and don't have a corresponding "}" and "sod it" is a valid response.
What's wrong with prettier's switch statements?