This is one of the first things I always say to the FE teams I manage when we form the team and start talking about the project, well not actually this, but actually "the web is held together with gum, duct tape and prayers". They don't understand it at this point, but pretty soon enough they do get it. Shenanigans ensue.
"...held together with gum, duct tape and prayers". They don't understand it at this point, but pretty soon enough they do get it. Shenanigans ensue." ^ Speedrun your team's "getting it" by making Theo's rant here Required Reading during their first week.
ikr, its only something who didn't bother learning HTML first jumped straight into these JS Frameworks would do. The current implementation is really good for me, I just close everything. For self-closing tags it doesn't bother them, just one extra / to deal with. e.g.: and for "closing" closing tags, welp, I simply close them after their job is done. e.g.: meh
@@shivendrasauravand any self-closing element that is not closed just to throw an alert to the console and done, to not break old code using amd . Everything sorted
Yeah... and it is an error if you put it in the W3C HTML validator. I don't see how it would make sense in any language to expect "Hello" to be inside the div... if the language does support self closing tags then any content after the closing slash should be outside the element... isn't that the point of a closing slash? The fact that browsers ignore the self closing slash and fix your invalid markup should never have been interpreted as some valid syntax.
13:17 "How many people are actually writing an html file?" **Looks at my personal website which uses plain html with no frameworks** Uhhhhh probably some people
@@acf2802 that might depend on how one defines "webdev". Some of us have been writing HTML by hand since the mid 1990's, and, while we may use frameworks of various sorts for some things, we're quite content to hand-code HTML for other things. 🤷🏻♀
For a very very long time my personal website was just a few PHP files with includes that were filled with good ol' hand written HTML. It's now just pre-rendered NEXT.js to get around pesky full page refreshes. Nothing like having to compile your god damn site just because you changed a few words.
As someone building it’s 100% the fault of the framework creator. If you’re building a language wrapper it’s YOUR job to fully understand the details, especially the fine ones, of the language that you’re wrapping. It’ll be like building a C++ framework with a pointer object that is actually a reference under the hood.
exactly my thinking its on the Framework people to do and understand the thing they are wrapping to the extreme detail - pretier et al be damned follow the spec's and implications
@@techobservations8238 counterpoint. If MOZILLA, the actual developers of one of the oldest and most respected browsers, do this wrong, then the language is wrong and needs to be fixed. That would either be a temporary annoyance now, or we're going to permanently keep having this annoyance in the future. People 200 years from now will look back and ask themselves, why didn't they just fix this.
That's not all! Introducing HTML... with Styles™! Cascading your way from context free, to more powerful models of computation! HTML+CSS, the dataflow programming language of choice!* (*among masochists)
Just to clear up a bit of confusion with the terminology used in the article referenced in this video. There is no such thing as a "self-closing" tag in HTML (i.e SGML). They don't exist: they only exist in XML. What's being referred to in the case of e.g in HTML is not a "self closing" tag but a "standalone" tag - something completely different to a self closing tag in XML (and doesn't exist in XML). That's partly the reason for the confusion, and it's why is just as much a syntax error (in HTML, if you didn't know) as .
I went to MDN to see the list of self-closing (which they call Void Elements) and they indicate that the /> is invalid HTML. I clicked on embed, one of these elements and the example had the invalid />. 😂
Also SHTML (server side includes) where you could easily embed other HTML files (as well as doing other things) without even needing a PHP backend! Just slap in and you're sorted. It even supports arbitrary execution of shell commands and echoing environment variables! XSS and user submitted content wasn't exactly a concern when SSI was introduced...
@@arthurcarchi4045 I mean, it kinda makes sense, assuming not all browsers are the same, and the other browsers don't have browser-specific syntax. You put the code specific to your browser in a special comment so that other browsers ignore it. A similar technique was used to allow JavaScript to work in old HTML, before all browsers had JS support. You would put your JavaScript inside of a special HTML comment. Similarly, XML doesn't like raw text strings, so SVG would put them inside of CDATA tags. Notice how it starts with
"If the guy who made the HTML ++ framework thought that this is how it worked, that's a fault of the language, not a fault of the individual." Ummm, no? It's really incumbent on the individual to know how the language works.
@@nickfarley2268 because we treat HTML as human-readable language, so it must be easily readable for humans as well. If that was only machine readable language (like e.g. bytecode) then you would be right.
@@proosee are you saying html is not human readable because you have to write instead of ? Why do we need to redefine HTML syntax so we can save 5 characters of text?
@@nickfarley2268 no, I didn't say that, I said that if you consider language a human-readable one then opinions of people on how confusing it is actually matter, if spec for is for most people confusing then you need to take it into account and you just disregarded it by "meh, machine can read it so it doesn't matter".
I was one of the XHTML proponents. But it had one huge problem on every browser that even supported it (at least it did back in the day): a single syntax error made the browser shit itself and refuse to render anything. But in my opinion they threw the baby out with the bathwater. They could have made HTML5 xml-like and xml compatible while also making it fault tolerant like it is today.
4:30 showing zero appreciation of what was done with pre-ANSI C++ in a semi-green field environment. The web needed a decent front-end so users could actually see the value of the internet and use it. Netscape was also in competition with Microsoft, so they had to make choices and execute. Mistakes were made, but the biggest mistake was probably the rewrite. Context matters.
You keep saying "attribute" with the verb pronunciation (emphasis on the second syllable) when you mean the noun (pronunciation should have emphasis on the first syllable). Just a heads up because it trips me up every time. Sorry to be "that guy" but I'd want someone to let me know, just like if I had something in my teeth and didn't know. Great videos!
As for YAML, it only became a superset of JSON with version 1.2, YAML 1.1 has some minor incompatibilities. What doesn't help is that there are tons of libraries that still only support 1.1, and the fact that many YAML libraries do not adhere 100% to the spec anyway. As for mistaken self-closed tags, I'd expect most mistakes involve textarea, as it's often empty.
HTML5 has an XML serialization mode (XHTML5) when you add an tag at the start. That is in part for compatibility with XHTML, but also with XML pipelines (e.g. transforming JATS to HTML with XSLT). It's also used in various places like EPUB 2 files.
Except not really because 99% of people who used XHTLM did not serve it with the "application/xhtml+xml" mime type which means it was always being parsed as HTML and relying on HTML's lackadaisical handling of syntax errors to "just work."
the video goes into this. But, yeah, I'm finding myself wanting to start explicitly using xhtml instead of html5 from now on, and keeping (with or without the space, ideally) as being what I expect it to be.
in what way is that less clear? (Inherently -- ignoring what things do with it for the sake of this question.) To me, is _more_ clear than , if only because I don't have to mentally make sure that the tag names are the same, I can just read one of them and see that it's self-closing. No?
Wait? You can self-close? I've always explicitly closed all enclosable tags. It's consistant with the XML. I work so often With XML that it's easier for me to just write code exactly as they should do. Not relying on an asumption that the computer not f*** up your purpose.
@@davidroddini1512 amen to that. HTML is not the world! we can't be inconsistant in our expressions, and if it's a problem in one place it's 100%, a problem everywhere the self-enclosed tags are used.
i feel like we should not call a self closing tag but a short closing tag because is a self closing tag, the tag _closes itself_ without you needing to do anything, meanwhile divs need end tags, which you can _shorten_ in some tools to idk this is just a random brain spew but i feel like if we make a clear distinction it could make future discussions easier
Yeah, for theo /> means self-closing tag even if it doesn't close right away. In HTML5 br and input are self-closing, div isn't regardless whether there's a slash.
you know the right way to write hr and br tags are and right? as somone says they are void elements.. will it blow your mind that tag does not need to be closed ?
I feel like you missed the obvious interpretation of br... br isn't an element it's an in-stream text formatting tool, it should be a character like a perhaps.... &lnbk; (instead xml spec of
)
The argument for img, is an img in an inline block element, the sorta obvious behavior would be that if an img is a block level element, then it should be able to have children, and the image would act like a inline-block element with fixed size and a background image
I do not like writing /> in HTML. HTML and XML are and always were 2 different languages. HTML was built on top of SGML, not XML. And XHTML is practically dead (and probably a bad idea to start with). HTML is a language to write hypertext, and tags are called tags not as a coincidence, but because they are things you add in a text to structure it, it was not designed to structure data. If you see like them, it make perfectly sense that some elements are self-closing and some other are not, like in LaTeX (for example), the principle is very similar (you have tags that produce an immediate effect, and others that affect what is next, and these you can wrap in brackets to have them apply to more stuff). Closing tags are confusing to the user, why the user shall write something like ? It makes no sense. It also creates confusion, because the user then discovers that is not a valid syntax. Better avoid confusion, and treat XML and HTML as two separate languages, with they own rules. Beside that, it's just faster to avoid typing one useless character, and you transmit 1 byte less on the network (that multiplied for all the in your page, for all the requests made to load a document, can add up to several traffic saved.
I may be missing something, but as I started waaaay back when html started, I know the , , etc is a single tag and not an open/close set of tags * I learned that some tags were single, some had open/close * when came out I never assumed any thing other than a single tag that represented itself as a single tag for human reference (xml aside) * Seeing does not make me thing it means , it makes me thing its a single tag and not an open/close tag
I honestly don't see the point. I don't need my variable names to be cute with emojis everywhere. If anything, I think having them in variable names will make it harder to actually use that variable in the first place. I'm glad other languages don't support that.
@@CatFace8885 Julia is designed to solve math problems, and for this is very nice for a language to support math related symbols. And Julia does it very nicely. Not emojis per say
I was a big fan of XHTML at the time. I wanted HTML parsing to be predictable and for browsers to print warnings in the console for invalid XHTML. Obviously I was on the losing side. Pragmatic concerns kept the technical debt of all this stupid HTML parsing.
@@RandomGeometryDashStuff That's not the point. If we would have switched to XHTML or XML we would have saved ourselves a lot of pain and suffering (it would also cause a lot of pain and suffering to transition but that would only be a period and now we're stuck with HTML).
At the very least in TypeScript, I get an error when trying to use emojis. At one point I was trying to write code using some custom Unicode characters and I had to make a custom parser just to reformat it (it would change the unicode characters into variable names that had bytes written out like identifier_u1234_u2345 etc, which was awful to debug of course)
I like to do `` because the first div is passing the baton to the closing tag, and look you can see the closing tag got it Edit: I read the issue posted by Rich and his main concern is about copy and pasting Svelte into HTML and not HTML into Svelte, people consistently miunderstood him. While Svelte adds language features, if you delete the Svelte parts you should be able to paste it into HTML and be the same. In that case it makes sense. They seem to be leaning towards warning people against self closing tags for tags that don't self close, and then later making it error. I think it seems reasonable, and that the disagreement comes from people misunderstanding the direction of code. Nobody is actually writing `` in HTML to cause a problem in Svelte, but people are using `` in Svelte to cause a problem in HTML. While I don't see it being a realistic error, and that it would be better for browsers to fix it, it's fair enough to be consistent with the older format.
Good video, I would add that self closing tags can be dangerous doors for threat actors. I like closing my tags cause I like a sense of symmetry to it for security and aesthetics.
that's because when the parser checks the content the img, video, , etc are pointers to resources and not the resource itself. while div, p, etc are not pointers but wrappers for the content. When you write the text in a you will have the resource shipped with the bundle... if was self-closing means that the text was coming from a text file located elsewhere and not with the .html
I preferred xhtml. It allowed for simpler parsing rules, which allowed pages to be easily parsed on low power devices like cell phones, brail readers, printers and so on.
Personally, I think we should be embracing xHTML more. Browsers didn't abandon it. It's still works. It's web developers that abandoned it, because they didn't want to risk displaying parsing errors when their buggy templating systems rendered the page wrong.
xHTML is the only version of HTML that operates the way people expect it to. I find the parsing errors “issue” to be overblown, as you opt into it and you’d want to know during dev if you are serving broken XML (HTML). That’s how everything else works.
In 12:39 in my opinion the prettier formatter should follow the html parser when formatting html, self closing tags in list turn from opening tags and closing tags to self closing, and other tags turn into auto closed, with the exception of foreign elements hierarchies like embedded svg and MathMl.
The amount of lavaflows in the web is definitely annoying as fsck. I would prefer to adopt some kind of XML standard which uses the old XHTML "strict"/"transitional" or "relaxed" DTDs to deal with webpages that would otherwise generate parsing errors. This is just another reason why I hate coding crap for the web. All the hidden "gotcha" side effects that even the "experts" / "creators" don't know about themselves. Ugh.
@@DarrenJohn10X It's a commonly-used software development term -- unfortunately. :) It usually refers to code or design that was done in a haphazard or expedient way (the "flow" part), and has since hardened into an unchangeable standard. Also can refer to multiple layers of the same thing, since you can't change the "hardened" mess below, you just pave over it with more lava. :P
So I just need to wrap everything in for it to work as expected? I've made web documentation with xml for content with appropriate ddt for it, xslt with formatting and design and css, so self-closing tags is a given...
The only reason why I’d use this, would be in some kind of: And self closing would mean for me that it is the beginning and the end of this object. It has no innerHTML.
To be fair, when I was a teen a long time ago, having the browser be so forgiving actually helped me learn HTML. Hey guess what, that move led me into my career. So there is a point for it to be more forgiving in the past. Also, I guess it's easier to parse when tags themselves defined if they were self closing or not. Could very well be an "at that time, it was a fair idea" thing.
Fault-tolerance is a foundational design principle of the web - everything from network protocols to CSS and HTML parsing and parts of JavaScript. BSOD on an HTML syntax error is what the web would have got with Microsoft-style thinking. Thank you to every early web pioneer who pushed hard for an open and fault-tolerant platform!
Self-closing only applies to inline tags without an explicit closing tag (like img and br). For blocks, everything after the tag is included inside it until it runs into the next opening block-style tag.
I ran into a lot of these things in the late 90s. At which point I learned that HTML and XML are kissing cousins in that they both derive from SGML - the grammar says so. And then committees took over and we ended up with the web version of some of the math conventions we have learned to live with. +1 for the kudos to the browser vendors making the web fault tolerant and self-healing. Even though some of the design decisions leave us scratching our heads. -1 for the slam on Netscape. For many years they were the only game in town. Not only browser, but server - which was arguably more important. The first web server (with promptly added support for Java Servlets / Applets - yeah, they were bad but innovative) with enterprise support. The first commercial web server I worked with was Netscape's on HP/UX circa 1998. The web would not have grown as fast without Netscape the company - full stop. The question in my mind, is if we could re-invent the browser today; what would it look like? And what tech do we need? Think mobile, Web Assembly, etc. None of those things were even thought of back then
I did not know people didn't know divs can't be self closing. I actually specifically test that in frameworks I am using (at the time of when I could use it) just to know how it is handled
@@marioprawirosudiro7301 I digress with your statement, self closing divs can be useful i.e. when you fill them later with js so it does make sense for them to sometimes be self-closing
@@xelspeth By that, did you mean putting script inside of a div, or did you mean dynamically populate the div later on? I still think they shouldn't be self-closing either way. Not even for readability - nothing says "empty div" that seeing the closing div tag _right after_ the opening tag with nothing in between.
@@marioprawirosudiro7301 I meant dynamically populating the div later on. Apart from that I don't think is more explicit than a self closing would be. For me it's the same as function() {} vs () => {}*. Just shorter and simpler for the same* *obv "this" is different in anonymous and arrow function but that's besides the point here
I think code indentation is a good analogy for self-closing tags. In some languages, indentation matters. In others, it's completely cosmetic. In languages where it's cosmetic, it's possible to indent incorrectly and confuse yourself. But that doesn't mean it's not useful to have. Also, I don't want emojis in my code, because the emoji picker in Windows doesn't work right when I'm in an RDP session.
Self-closing tags are a construct coming from XML / XHTML. In HTML 5, many tags either don't need a closing tag depending on their placement, or simply don't *HAVE* a closing tag (and adding one would be an error), like , ... EDIT: posted that at the start of the video, glad the video got it right too. "self-closing tags" are not a HTML syntax, but it's a fine syntax to have for superset language which parse your markup and support it, such as jsx / angular / w/e. EDIT 2: The point about "faster to parse" is valid, and the counter-argument itself is invalid. An XML parser simply have no notion of "some elements are self-closing". The XML parser know that an element is closed specifically due to either the "/" at the end of the tag, or when reaching a closing tag. Not having a notion of "self-closing elements", it never try to find if the element name is inside a list of self-closing elements; it doesn't have to care at all about the name of the element, no matter what it is, for parsing purposes (although it obviously need to do so when validating against the schema, but you don't have to necessarily validate against the schema when you parse the document)
But then i had a very good idea. I closed my tags myself. See, closing my tags myself gave me a whole new perspective in coding and i was able to see skills that i couldve not see before.
18:52 - you might like ruby, then. ;) Here's an actual session log from an irb ("interactive ruby" -- ruby's way of getting a REPL) session I just did, just for fun: irb(main):001:0> « = 3 => 3 irb(main):002:0> » = 5 => 5 irb(main):003:0> «+» => 8 Perhaps it would have been better to use emoji than those symbols, but, I know how to type those, and somehow thought it created an amusing final expression.
Oddly enough, I have learnt about the peculiarities of closing tag of div from school and how it works and have seen it in production before. But after years of React, somehow that knowledge has been forgotten
Browsers never had to (and still don't have to) blurt out an error message. The xml parser reports an error... oh geez, wow, what do we do? I know! Let's show it to the user instead of logging it and rendering the page as HTML! This was a vendor power-play, so was getting rid of XSLT support due to "increased size of initial download of the browser package" lol.
And yeah, I'm that one guy uses application/xhtml+xml. Never in production. But my example work in Wayback from the aughties? Still works. Still well-formed and valid XHTML 1.1. Still renders faster than engaging the tag-soup parser in the browser. Browsers still have XML parsers they tried doing away with, for exactly the reasons they were told at the time -- MathML and SVG shouldn't be "foreign" because they've always been "native."
@@geoffreyvanpelt6147 Exactly! Imagine if the browser workflow was to compile the XSLT and stash *that* in cache? I was awesome at compact, recursive stylesheets and cascading. Meanwhile, Javascript in the browser has become such a dumpster fire that we're now *compiling* dynamic code?
Of course, part of the FUD at the time was that XML didn't compress as well as JSON. Ummm... got brot? Server's gonna have all those tagsets in the ol' dictionary. Now who compresses down further? It's a wash... edge to brotli on inflate at the user-agent, and I'm all about user perceived performance i.e. latency is my enemy, and REST != CRUD is my motto.
On the server side, I used the same XSLT stylesheet as the client side, to generate HTML instead of XHTML. Another XSLT template stripped the if request method = HEAD... start with identity template, add one line of code. Fast.
when i was still in college the first programming language i learned was c, then c++, then c# i think of semicolon as the period in a phrase or a sentence which indicates the end of a line which is logical. every start should have and end that's for me. even with javascript even if it's a javascript one-liner i still put semicolon at the end of each line of code. it's a preference but my rule of thumb is to treat each line of code like a phrase or a sentence which should have a period at the end.
It's time to introduce: HTML6 Where closing tags actually work. That, or a keyword or something, that similar to an tag would treat the contents as foreign code and therefore honor the />
I think I encountered something like this where I was using and it didn't work. After hours of trying to debug it, someone said you need to explicitely close it. I never understood why, but it worked. I probably had the same misunderstanding as the one in this video.
How about "Hello" The struggle seems to be with how Prettier handles these cases: "Hello" -> "Hello" "Hello" -> "Hello" "Hello" -> Error: Unexpected closing tag "body" The first case reproduces what a browser does, it injects a closing tag where it should be. The third case does what browsers can't do, it throws an error But shouldn't these all be handled the same way? And out of the 3 options, the second case doesn't make any sense to me. It's leaving the HTML invalid. Changing it to "Hello" would be expected imo. It keeps the author's intent (assuming the author is familiar with jsx or xml) while making it valid. It's also minimal work to figure out. Changing it to "Hello" or throwing an error would both be acceptable too but all the scenarios should do the same thing.
Btw, with Vue templates, starting from: I'm rendered outside after rendering I'm rendered outside input We get: I'm rendered outside after rendering I'm rendered outside input Thumbs up for rendered as IMHO thumbs up for forbidding non-self-closing , ...
In 2000 till 2010 i read a lot of w3c, see the rise and fall of xhtml, people that like xhtml was strict, but also other people that like html5 wasnt strict. For me it was a period where i learn s lot about the markup languages. I build a lot from scratch and without frameworks, and all my site are valid markup. I think a lot of frontend developers have hard times to build without a framework, just with html and css. I like to build without frameworks.
With a lot of browsers converged on webkit it seems like it would be pretty easy to fix this now. Maybe just log an error to the console about it to start then progress to full blown errors a year or two down the line?
Never touched JSX before, so I was pretty aware of the weird conventions that XHTML left behind. Very interesting how this affects front end frameworks. I personally agree with Rich Harris -- it's better to be simple than to be convenient. Edit: Replaced 2nd "JSX" with "front end frameworks"
but that's the opposite of simple. It means that the syntax cannot be parsed without knowing which elements are self-closing and which aren't. That means it's not backwards compatible and it means it cannot be parsed generically - for example for the purpose of extension.
So here's the thing, JSX is very much not like HTML. It gets compiled to a bunch of React.createElement calls (If you're using React). This also kind of decouples the element kinds from the self-closingness, which would be a mess to deal with in typescripts type system (for TSX). And every time the spec would add a new HTML element, you'd need to update the JSX parser itself. In this way, the JSX spec is kind of decoupled from the HTML spec, which I believe is a good thing. In case of Svelte I can understand this, because, as Rich said, it's a superset of HTML. JSX is not a superset of HTML, it is a superset of XML and doesn't even compile to HTML (unless you use something like SolidJS, which compiles them to HTML templates)
@@hamm8934 In most cases, it doesn't even compile to HTML. It's not an abstraction of HTML, it's an abstraction of the (virtual) DOM that looks like HTML
I don't care what Svelte is, but means , because the point is I'm NOT writing HTML. I'm writing a non-HTML something that only looks like HTML will eventually _become_ HTML and I expect the framework to handle it correctly to generate the HTML I expect, NOT the incorrect HTML it thinks is compliant with my non-HTML thing. If I wanted Hello. I would NOT write Hello. Because that's just stupid. I would read that and understand it to be Hello. Who wouldn't? The fact that it would be interpreted _IN_ HTML as Hello is **IRRELEVANT**. Because I'm NOT writing HTML. I'm writing a non-HTML something that will eventually become HTML. And I expect my non-HTML to do what I think it does, not what someone else think it does. Why is this even a debate? It's stupidly obvious.
Regarding its faster, that depends on implementation. I could see an alternative approach: Sees BR - Identifies it as a BR tag. Sees /> - closes tag. Moves on. Vs Sees BR - Identifies it as a BR tag. See / - Ignores it. See > - Closes tag. Checks if it is in the list of elements that can't have children and because of that self-closes. The article seems to just ignore this possibility and think the only way it could do it is if it ignores the slash and then checks anyway, but that is not the only case.
Sorry, no. When I write Hello, I don't want it to suddenly become Hello. If Prettier is going to do something, it should make it Hello, because that's my expectation. And if it is not, then I can correct that by actually moving Hello inside.
The web is built on a mountain of tech debt.
Quote of the year
That's not technical debt, it's technical neglect
This is one of the first things I always say to the FE teams I manage when we form the team and start talking about the project, well not actually this, but actually "the web is held together with gum, duct tape and prayers". They don't understand it at this point, but pretty soon enough they do get it. Shenanigans ensue.
Most of software. Not just the web
"...held together with gum, duct tape and prayers". They don't understand it at this point, but pretty soon enough they do get it. Shenanigans ensue."
^ Speedrun your team's "getting it" by making Theo's rant here Required Reading during their first week.
Hello
Will always look like an error for me.
ikr, its only something who didn't bother learning HTML first jumped straight into these JS Frameworks would do. The current implementation is really good for me, I just close everything. For self-closing tags it doesn't bother them, just one extra / to deal with. e.g.: and for "closing" closing tags, welp, I simply close them after their job is done. e.g.: meh
@@shivendrasauravand any self-closing element that is not closed just to throw an alert to the console and done, to not break old code using amd . Everything sorted
@@Slashx92 yes why not, just show a warning, it can at least be a great starting point.
looks kind of like pug which I find awesome
Yeah... and it is an error if you put it in the W3C HTML validator. I don't see how it would make sense in any language to expect "Hello" to be inside the div... if the language does support self closing tags then any content after the closing slash should be outside the element... isn't that the point of a closing slash? The fact that browsers ignore the self closing slash and fix your invalid markup should never have been interpreted as some valid syntax.
13:17 "How many people are actually writing an html file?"
**Looks at my personal website which uses plain html with no frameworks**
Uhhhhh probably some people
Right? I don't use frameworks unless I have to.
based and react pilled
No frameworks?! No frameworks to manage your frameworks? Do you even webdev?
@@acf2802 that might depend on how one defines "webdev". Some of us have been writing HTML by hand since the mid 1990's, and, while we may use frameworks of various sorts for some things, we're quite content to hand-code HTML for other things. 🤷🏻♀
For a very very long time my personal website was just a few PHP files with includes that were filled with good ol' hand written HTML. It's now just pre-rendered NEXT.js to get around pesky full page refreshes. Nothing like having to compile your god damn site just because you changed a few words.
As someone building it’s 100% the fault of the framework creator. If you’re building a language wrapper it’s YOUR job to fully understand the details, especially the fine ones, of the language that you’re wrapping. It’ll be like building a C++ framework with a pointer object that is actually a reference under the hood.
exactly my thinking
its on the Framework people to do and understand the thing they are wrapping to the extreme detail - pretier et al be damned follow the spec's and implications
@@techobservations8238 counterpoint. If MOZILLA, the actual developers of one of the oldest and most respected browsers, do this wrong, then the language is wrong and needs to be fixed. That would either be a temporary annoyance now, or we're going to permanently keep having this annoyance in the future. People 200 years from now will look back and ask themselves, why didn't they just fix this.
Enters HTML, the programming language
That's not all! Introducing HTML... with Styles™! Cascading your way from context free, to more powerful models of computation!
HTML+CSS, the dataflow programming language of choice!*
(*among masochists)
Just to clear up a bit of confusion with the terminology used in the article referenced in this video. There is no such thing as a "self-closing" tag in HTML (i.e SGML). They don't exist: they only exist in XML. What's being referred to in the case of e.g in HTML is not a "self closing" tag but a "standalone" tag - something completely different to a self closing tag in XML (and doesn't exist in XML).
That's partly the reason for the confusion, and it's why is just as much a syntax error (in HTML, if you didn't know) as .
SGML has had self closing tags since at least the last millennium. See Annex K.3.5.1.
Something about an issue being "Library does the thing it's meant to do completely wrong" is really amusing to me
I went to MDN to see the list of self-closing (which they call Void Elements) and they indicate that the /> is invalid HTML. I clicked on embed, one of these elements and the example had the invalid />. 😂
"If a comment could change what the code does"... May I remind you of Internet Explorer's conditional comments?
What the ... ?
Also SHTML (server side includes) where you could easily embed other HTML files (as well as doing other things) without even needing a PHP backend! Just slap in and you're sorted. It even supports arbitrary execution of shell commands and echoing environment variables!
XSS and user submitted content wasn't exactly a concern when SSI was introduced...
html email building still has to use conditional comments for some stylings on outlook clients lol
JDSL (tom is a genius)
@@arthurcarchi4045 I mean, it kinda makes sense, assuming not all browsers are the same, and the other browsers don't have browser-specific syntax. You put the code specific to your browser in a special comment so that other browsers ignore it.
A similar technique was used to allow JavaScript to work in old HTML, before all browsers had JS support. You would put your JavaScript inside of a special HTML comment.
Similarly, XML doesn't like raw text strings, so SVG would put them inside of CDATA tags. Notice how it starts with
"If the guy who made the HTML ++ framework thought that this is how it worked, that's a fault of the language, not a fault of the individual." Ummm, no? It's really incumbent on the individual to know how the language works.
If only we had a tool to show the browser what language version we’re using so it could parse accordingly… you know, like doctype and head meta tags 🙃
http content-type header
I would do my part and never use it!
I handwrite HTML for work.
Also, my personal website doesn't use any framework, just handwritten HTML, CSS, and a tiny bit of JS.
Same here. I find that frameworks convolute code with boiler plate and makes the project more complicated.
Hey, when I started writing HTML we used , so that doesn't look so bad now, does it?
Retrocompatibility is the best worst thing that happen in software development, that's why we have new tools each week.
HTML is already compatible. Self closing elements would require new tools. Why do we need this??
@@nickfarley2268 because we treat HTML as human-readable language, so it must be easily readable for humans as well. If that was only machine readable language (like e.g. bytecode) then you would be right.
@@proosee are you saying html is not human readable because you have to write instead of ? Why do we need to redefine HTML syntax so we can save 5 characters of text?
@@nickfarley2268 no, I didn't say that, I said that if you consider language a human-readable one then opinions of people on how confusing it is actually matter, if spec for is for most people confusing then you need to take it into account and you just disregarded it by "meh, machine can read it so it doesn't matter".
@nickfarley2268 it's less human readable if you re-watch rhe examples with the div tag. Or this is inside
Brs are not the problem
I still handwrite html manually, what's wrong with that?
How dare write HTML instead of... let me check... JSX
Yeah, my documentation is just HTML and JSX hand written in Composition notebooks. My code reviewers just use red pen.
I was one of the XHTML proponents. But it had one huge problem on every browser that even supported it (at least it did back in the day): a single syntax error made the browser shit itself and refuse to render anything. But in my opinion they threw the baby out with the bathwater. They could have made HTML5 xml-like and xml compatible while also making it fault tolerant like it is today.
With every video I realise Theo knows React, but not frontend. Backend devs raised on JSX are just now learning the basics.
@5:20 - a-TRI'-bute is a verb; A'-tri-bute is a noun.
I try not to care, but the number of times he said it in this video was killing me 😭
@@charliecarrot went and looked for these comments when i just couldnt anymore (5 minutes in)
a-tri-butÉ is French
I hear people use the verb pronunciation for the noun so much, it always bumps me.
Oh GOD YES!!!!!! This was KILLING ME!
Theo's "Just never write html" argument misses the point.
4:30 showing zero appreciation of what was done with pre-ANSI C++ in a semi-green field environment. The web needed a decent front-end so users could actually see the value of the internet and use it. Netscape was also in competition with Microsoft, so they had to make choices and execute. Mistakes were made, but the biggest mistake was probably the rewrite. Context matters.
You keep saying "attribute" with the verb pronunciation (emphasis on the second syllable) when you mean the noun (pronunciation should have emphasis on the first syllable). Just a heads up because it trips me up every time. Sorry to be "that guy" but I'd want someone to let me know, just like if I had something in my teeth and didn't know. Great videos!
I was just about to be that guy - thanks Reverend!
As for YAML, it only became a superset of JSON with version 1.2, YAML 1.1 has some minor incompatibilities. What doesn't help is that there are tons of libraries that still only support 1.1, and the fact that many YAML libraries do not adhere 100% to the spec anyway. As for mistaken self-closed tags, I'd expect most mistakes involve textarea, as it's often empty.
it comes from the old XHTML standard that was based on XML, we've mostly abandoned it, but it is valid XHTML to do and expect it to render properly
HTML5 has an XML serialization mode (XHTML5) when you add an tag at the start. That is in part for compatibility with XHTML, but also with XML pipelines (e.g. transforming JATS to HTML with XSLT). It's also used in various places like EPUB 2 files.
Except not really because 99% of people who used XHTLM did not serve it with the "application/xhtml+xml" mime type which means it was always being parsed as HTML and relying on HTML's lackadaisical handling of syntax errors to "just work."
the video goes into this. But, yeah, I'm finding myself wanting to start explicitly using xhtml instead of html5 from now on, and keeping (with or without the space, ideally) as being what I expect it to be.
I don't like self-closing tags because it is less clear than explicitly closing.
in what way is that less clear? (Inherently -- ignoring what things do with it for the sake of this question.)
To me, is _more_ clear than , if only because I don't have to mentally make sure that the tag names are the same, I can just read one of them and see that it's self-closing. No?
Wait? You can self-close? I've always explicitly closed all enclosable tags. It's consistant with the XML. I work so often With XML that it's easier for me to just write code exactly as they should do. Not relying on an asumption that the computer not f*** up your purpose.
did you really want two of these??
Personally, I lean towards all or nothing. If not all tags can be self closing due to security concerns, then none of them should be. Be consistent.
@@davidroddini1512 amen to that. HTML is not the world! we can't be inconsistant in our expressions, and if it's a problem in one place it's 100%, a problem everywhere the self-enclosed tags are used.
i feel like we should not call a self closing tag but a short closing tag
because is a self closing tag, the tag _closes itself_ without you needing to do anything, meanwhile divs need end tags, which you can _shorten_ in some tools to
idk this is just a random brain spew but i feel like if we make a clear distinction it could make future discussions easier
Yeah, for theo /> means self-closing tag even if it doesn't close right away.
In HTML5 br and input are self-closing, div isn't regardless whether there's a slash.
In html, these (, , ) are not called self-closing. Technically they are called void tags.
To be even more pedantic, they are called void elements, not void tags. Shame on me for not double checking before commenting 😞
you know the right way to write hr and br tags are and right? as somone says they are void elements.. will it blow your mind that tag does not need to be closed ?
Another proof that React devs don't know js, html, css and in general how browser works :D
To bake an apple pie from scratch, first invent the universe
Its more like… to bake an apple pie from scratch you need to now how to use an oven.
There's really handful of people who really do though
We should not be requiring tooling. The power of the web is that you can get started without anything other than an editor.
I feel like you missed the obvious interpretation of br... br isn't an element it's an in-stream text formatting tool, it should be a character like a perhaps.... &lnbk; (instead xml spec of )
The argument for img, is an img in an inline block element, the sorta obvious behavior would be that if an img is a block level element, then it should be able to have children, and the image would act like a inline-block element with fixed size and a background image
18:43 Fun fact: emojis are valid characters in selector names and variable names in CSS. 👀
also as keys of objects or symbols
I do not like writing /> in HTML. HTML and XML are and always were 2 different languages. HTML was built on top of SGML, not XML. And XHTML is practically dead (and probably a bad idea to start with).
HTML is a language to write hypertext, and tags are called tags not as a coincidence, but because they are things you add in a text to structure it, it was not designed to structure data. If you see like them, it make perfectly sense that some elements are self-closing and some other are not, like in LaTeX (for example), the principle is very similar (you have tags that produce an immediate effect, and others that affect what is next, and these you can wrap in brackets to have them apply to more stuff).
Closing tags are confusing to the user, why the user shall write something like ? It makes no sense. It also creates confusion, because the user then discovers that is not a valid syntax. Better avoid confusion, and treat XML and HTML as two separate languages, with they own rules.
Beside that, it's just faster to avoid typing one useless character, and you transmit 1 byte less on the network (that multiplied for all the in your page, for all the requests made to load a document, can add up to several traffic saved.
XML is an ISO-compliant subset of SGML
html should just be fixed.
used to throw me for a loop. All I wanted to do was include an external js file. And simply does not work. It drove me nuts.
I used to serve XHTML with application/xhtml+xml, except when the user agent was IE7 or lower, cause it would just render the XML as text file.
In HTML 6 you'd be able to write to force self close without breaking compatibility
It just is so mind boggling that we had a bunch of browsers and no html parser spec for years
Theo is really brand new
I may be missing something, but as I started waaaay back when html started, I know the , , etc is a single tag and not an open/close set of tags
* I learned that some tags were single, some had open/close
* when came out I never assumed any thing other than a single tag that represented itself as a single tag for human reference (xml aside)
* Seeing does not make me thing it means , it makes me thing its a single tag and not an open/close tag
This is a basics. Just remember the meaning of DOCTYPE, it has a lot of strict configurations, where will treat as error, but will be fine.
Btw. Swift supports emoji characters in variable, function, and class names
I think Julia do that as well
I honestly don't see the point. I don't need my variable names to be cute with emojis everywhere. If anything, I think having them in variable names will make it harder to actually use that variable in the first place. I'm glad other languages don't support that.
@@CatFace8885 Julia is designed to solve math problems, and for this is very nice for a language to support math related symbols. And Julia does it very nicely. Not emojis per say
@@CatFace8885 different languages, different purposes
PHP supports it too, funnily enough.
I was a big fan of XHTML at the time. I wanted HTML parsing to be predictable and for browsers to print warnings in the console for invalid XHTML. Obviously I was on the losing side. Pragmatic concerns kept the technical debt of all this stupid HTML parsing.
browsers still support xhtml so no losing
@@RandomGeometryDashStuff That's not the point. If we would have switched to XHTML or XML we would have saved ourselves a lot of pain and suffering (it would also cause a lot of pain and suffering to transition but that would only be a period and now we're stuck with HTML).
I'm glad someone else posted this too. XHTML should have been the path forward. HTML5 should be referred to as Hyper Trashcan Markup Language.
"Almost no languages support using Emojis" What is he talking about? Javascript is very much able to use them for variable names. Just not JSX...
At the very least in TypeScript, I get an error when trying to use emojis. At one point I was trying to write code using some custom Unicode characters and I had to make a custom parser just to reformat it (it would change the unicode characters into variable names that had bytes written out like identifier_u1234_u2345 etc, which was awful to debug of course)
@@electra_ Number one reason I'll never move on to typescript, can't use emojis. It's incredibly important to my workflow. .js files or bust.
I like to do `` because the first div is passing the baton to the closing tag, and look you can see the closing tag got it
Edit: I read the issue posted by Rich and his main concern is about copy and pasting Svelte into HTML and not HTML into Svelte, people consistently miunderstood him. While Svelte adds language features, if you delete the Svelte parts you should be able to paste it into HTML and be the same. In that case it makes sense. They seem to be leaning towards warning people against self closing tags for tags that don't self close, and then later making it error.
I think it seems reasonable, and that the disagreement comes from people misunderstanding the direction of code. Nobody is actually writing `` in HTML to cause a problem in Svelte, but people are using `` in Svelte to cause a problem in HTML. While I don't see it being a realistic error, and that it would be better for browsers to fix it, it's fair enough to be consistent with the older format.
Why would anyone copy-paste Svelte into HTML?
What, one can't use emoji in JS ? Even with all those transpiling layers
Yes you can. Just not in JSX. He would have shut himself up real quick if he tried it in a .js document lol
Good video, I would add that self closing tags can be dangerous doors for threat actors. I like closing my tags cause I like a sense of symmetry to it for security and aesthetics.
that's because when the parser checks the content the img, video, , etc are pointers to resources and not the resource itself. while div, p, etc are not pointers but wrappers for the content. When you write the text in a you will have the resource shipped with the bundle... if was self-closing means that the text was coming from a text file located elsewhere and not with the .html
I still do it out of habit because of those XHTML days.. Self-closing the the and and it's dang hard to undo that bit of muscle memory 😭
I preferred xhtml. It allowed for simpler parsing rules, which allowed pages to be easily parsed on low power devices like cell phones, brail readers, printers and so on.
There are no self-closing tags in HTML, so I never used them. Good for you, the svelte guy and all the people finding out about this.
the first few seconds hurt me physically
Personally, I think we should be embracing xHTML more. Browsers didn't abandon it. It's still works. It's web developers that abandoned it, because they didn't want to risk displaying parsing errors when their buggy templating systems rendered the page wrong.
xHTML is the only version of HTML that operates the way people expect it to.
I find the parsing errors “issue” to be overblown, as you opt into it and you’d want to know during dev if you are serving broken XML (HTML). That’s how everything else works.
When writing html, sometimes I omit my close tags for and just to annoy jsx-enthusiasts.
18:31 Swift supports emojis in code, you can use emojis as var names.
This video just makes me feel old since I knew this 😂
In 12:39 in my opinion the prettier formatter should follow the html parser when formatting html, self closing tags in list turn from opening tags and closing tags to self closing, and other tags turn into auto closed, with the exception of foreign elements hierarchies like embedded svg and MathMl.
I feel like linters should also include this as a standard warning/error, at least when using and alike
An ideal opportunity to dump JS too. So rendering outside the or for fun?
I stumbled upon this github discussion myself a few days ago. It wasn't Rich who reported this btw, but a good that it's being discussed...
The amount of lavaflows in the web is definitely annoying as fsck.
I would prefer to adopt some kind of XML standard which uses the old XHTML "strict"/"transitional" or "relaxed" DTDs to deal with webpages that would otherwise generate parsing errors.
This is just another reason why I hate coding crap for the web. All the hidden "gotcha" side effects that even the "experts" / "creators" don't know about themselves. Ugh.
I really like that, "lavaflows". Instantly makes sense, like "footguns".
@@DarrenJohn10X It's a commonly-used software development term -- unfortunately. :)
It usually refers to code or design that was done in a haphazard or expedient way (the "flow" part), and has since hardened into an unchangeable standard.
Also can refer to multiple layers of the same thing, since you can't change the "hardened" mess below, you just pave over it with more lava. :P
I'm sorry, what lie? You mean misconception?
So what you're saying is that there's no end to ?
I feel like your video is trying to convince me to just get rid of all the self-closing tags, I've been doing for years. :-)
So I just need to wrap everything in for it to work as expected?
I've made web documentation with xml for content with appropriate ddt for it, xslt with formatting and design and css, so self-closing tags is a given...
You didn't get the memo about XHTML going out of fashion?
The only reason why I’d use this, would be in some kind of:
And self closing would mean for me that it is the beginning and the end of this object. It has no innerHTML.
To be fair, when I was a teen a long time ago, having the browser be so forgiving actually helped me learn HTML. Hey guess what, that move led me into my career.
So there is a point for it to be more forgiving in the past. Also, I guess it's easier to parse when tags themselves defined if they were self closing or not. Could very well be an "at that time, it was a fair idea" thing.
Fault-tolerance is a foundational design principle of the web - everything from network protocols to CSS and HTML parsing and parts of JavaScript. BSOD on an HTML syntax error is what the web would have got with Microsoft-style thinking. Thank you to every early web pioneer who pushed hard for an open and fault-tolerant platform!
Awesome! So happy you acknowledge that HTML exists! 🎉
you can define variables and stuff as emojis in python and swift (maybe others but idk)
I once copied some JSX to HTML, only to have the strangest error. I spent sooo long debugging nested div issues because of this.
I've been crying myself to sleep every night since I transitioned into web development...
Self-closing only applies to inline tags without an explicit closing tag (like img and br). For blocks, everything after the tag is included inside it until it runs into the next opening block-style tag.
1:00 The issue’s status at that time is “Open” but why is it red? I was confused for a while 😅
He’s using a color blind theme
I ran into a lot of these things in the late 90s. At which point I learned that HTML and XML are kissing cousins in that they both derive from SGML - the grammar says so.
And then committees took over and we ended up with the web version of some of the math conventions we have learned to live with.
+1 for the kudos to the browser vendors making the web fault tolerant and self-healing. Even though some of the design decisions leave us scratching our heads.
-1 for the slam on Netscape. For many years they were the only game in town. Not only browser, but server - which was arguably more important. The first web server (with promptly added support for Java Servlets / Applets - yeah, they were bad but innovative) with enterprise support.
The first commercial web server I worked with was Netscape's on HP/UX circa 1998.
The web would not have grown as fast without Netscape the company - full stop.
The question in my mind, is if we could re-invent the browser today; what would it look like? And what tech do we need? Think mobile, Web Assembly, etc. None of those things were even thought of back then
Is there a language that bundles and minifies to HTML? Like how typescript get built as javascript min?
I did not know people didn't know divs can't be self closing.
I actually specifically test that in frameworks I am using (at the time of when I could use it) just to know how it is handled
True. Divs are used for structure and allows nesting, so shouldn't it be obvious that it has a closing tag?
@@marioprawirosudiro7301 I digress with your statement, self closing divs can be useful i.e. when you fill them later with js so it does make sense for them to sometimes be self-closing
@@xelspeth By that, did you mean putting script inside of a div, or did you mean dynamically populate the div later on?
I still think they shouldn't be self-closing either way. Not even for readability - nothing says "empty div" that seeing the closing div tag _right after_ the opening tag with nothing in between.
@@marioprawirosudiro7301 I meant dynamically populating the div later on.
Apart from that I don't think is more explicit than a self closing would be. For me it's the same as function() {} vs () => {}*. Just shorter and simpler for the same*
*obv "this" is different in anonymous and arrow function but that's besides the point here
@@xelspeth Well, in that case it becomes a matter of personal taste. For me, just looks like a malformed div at first glance.
I think code indentation is a good analogy for self-closing tags. In some languages, indentation matters. In others, it's completely cosmetic. In languages where it's cosmetic, it's possible to indent incorrectly and confuse yourself. But that doesn't mean it's not useful to have.
Also, I don't want emojis in my code, because the emoji picker in Windows doesn't work right when I'm in an RDP session.
I am fascinated that younger devs think that browsers should do things that make sense to devs. Anyone hear about JScript? ::shudders::
Web brower creators are premarily funded by advertisers and that has an effect on what a browser does and doesn't do.
Self-closing tags are a construct coming from XML / XHTML. In HTML 5, many tags either don't need a closing tag depending on their placement, or simply don't *HAVE* a closing tag (and adding one would be an error), like , ...
EDIT: posted that at the start of the video, glad the video got it right too.
"self-closing tags" are not a HTML syntax, but it's a fine syntax to have for superset language which parse your markup and support it, such as jsx / angular / w/e.
EDIT 2: The point about "faster to parse" is valid, and the counter-argument itself is invalid. An XML parser simply have no notion of "some elements are self-closing". The XML parser know that an element is closed specifically due to either the "/" at the end of the tag, or when reaching a closing tag. Not having a notion of "self-closing elements", it never try to find if the element name is inside a list of self-closing elements; it doesn't have to care at all about the name of the element, no matter what it is, for parsing purposes (although it obviously need to do so when validating against the schema, but you don't have to necessarily validate against the schema when you parse the document)
I also have written a JavaScript framework and also require the empty tags to be closed. Simply because the framework code becomes less complex
But then i had a very good idea. I closed my tags myself. See, closing my tags myself gave me a whole new perspective in coding and i was able to see skills that i couldve not see before.
nooooooooooo...
Is this a Kanadian/Seawattgaming reference?
I wasn't expecting to find that meme here, of all places.
@@lts0703 I saw that too, really good one lol
@@lts0703 Yes.
18:52 - you might like ruby, then. ;)
Here's an actual session log from an irb ("interactive ruby" -- ruby's way of getting a REPL) session I just did, just for fun:
irb(main):001:0> « = 3
=> 3
irb(main):002:0> » = 5
=> 5
irb(main):003:0> «+»
=> 8
Perhaps it would have been better to use emoji than those symbols, but, I know how to type those, and somehow thought it created an amusing final expression.
Oddly enough, I have learnt about the peculiarities of closing tag of div from school and how it works and have seen it in production before. But after years of React, somehow that knowledge has been forgotten
Thank goodness I came across this video before I discovered self closing tags
Browsers never had to (and still don't have to) blurt out an error message. The xml parser reports an error... oh geez, wow, what do we do? I know! Let's show it to the user instead of logging it and rendering the page as HTML! This was a vendor power-play, so was getting rid of XSLT support due to "increased size of initial download of the browser package" lol.
And yeah, I'm that one guy uses application/xhtml+xml. Never in production. But my example work in Wayback from the aughties? Still works. Still well-formed and valid XHTML 1.1. Still renders faster than engaging the tag-soup parser in the browser. Browsers still have XML parsers they tried doing away with, for exactly the reasons they were told at the time -- MathML and SVG shouldn't be "foreign" because they've always been "native."
I loved xslt. I was how I embeded navigations bars and banners in web page documents without modifying the original document source.
@@geoffreyvanpelt6147 Exactly! Imagine if the browser workflow was to compile the XSLT and stash *that* in cache? I was awesome at compact, recursive stylesheets and cascading. Meanwhile, Javascript in the browser has become such a dumpster fire that we're now *compiling* dynamic code?
Of course, part of the FUD at the time was that XML didn't compress as well as JSON. Ummm... got brot? Server's gonna have all those tagsets in the ol' dictionary. Now who compresses down further? It's a wash... edge to brotli on inflate at the user-agent, and I'm all about user perceived performance i.e. latency is my enemy, and REST != CRUD is my motto.
On the server side, I used the same XSLT stylesheet as the client side, to generate HTML instead of XHTML. Another XSLT template stripped the if request method = HEAD... start with identity template, add one line of code. Fast.
when i was still in college the first programming language i learned was c, then c++, then c#
i think of semicolon as the period in a phrase or a sentence which indicates the end of a line which is logical.
every start should have and end that's for me.
even with javascript even if it's a javascript one-liner i still put semicolon at the end of each line of code.
it's a preference but my rule of thumb is to treat each line of code like a phrase or a sentence which should have a period at the end.
It's time to introduce: HTML6
Where closing tags actually work.
That, or a keyword or something, that similar to an tag would treat the contents as foreign code and therefore honor the />
Bro, are u using Batik? your shirt (what it called in your place?)
I think I encountered something like this where I was using and it didn't work. After hours of trying to debug it, someone said you need to explicitely close it. I never understood why, but it worked. I probably had the same misunderstanding as the one in this video.
laughed so hard when you say its been so old since html5 ... i feel the same ... haha
As someone who has been using pug for the last 5 years, I can't relate to anything here mattering
How about "Hello"
The struggle seems to be with how Prettier handles these cases:
"Hello" -> "Hello"
"Hello" -> "Hello"
"Hello" -> Error: Unexpected closing tag "body"
The first case reproduces what a browser does, it injects a closing tag where it should be.
The third case does what browsers can't do, it throws an error
But shouldn't these all be handled the same way?
And out of the 3 options, the second case doesn't make any sense to me. It's leaving the HTML invalid.
Changing it to "Hello" would be expected imo. It keeps the author's intent (assuming the author is familiar with jsx or xml) while making it valid. It's also minimal work to figure out.
Changing it to "Hello" or throwing an error would both be acceptable too but all the scenarios should do the same thing.
React bug brains are a hell of a drug 😉
Btw, with Vue templates, starting from:
I'm rendered outside after rendering
I'm rendered outside input
We get:
I'm rendered outside after rendering
I'm rendered outside input
Thumbs up for rendered as
IMHO thumbs up for forbidding non-self-closing , ...
In 2000 till 2010 i read a lot of w3c, see the rise and fall of xhtml, people that like xhtml was strict, but also other people that like html5 wasnt strict.
For me it was a period where i learn s lot about the markup languages.
I build a lot from scratch and without frameworks, and all my site are valid markup.
I think a lot of frontend developers have hard times to build without a framework, just with html and css.
I like to build without frameworks.
With a lot of browsers converged on webkit it seems like it would be pretty easy to fix this now. Maybe just log an error to the console about it to start then progress to full blown errors a year or two down the line?
Never touched JSX before, so I was pretty aware of the weird conventions that XHTML left behind. Very interesting how this affects front end frameworks. I personally agree with Rich Harris -- it's better to be simple than to be convenient.
Edit: Replaced 2nd "JSX" with "front end frameworks"
but that's the opposite of simple. It means that the syntax cannot be parsed without knowing which elements are self-closing and which aren't. That means it's not backwards compatible and it means it cannot be parsed generically - for example for the purpose of extension.
@@Luxalpaabstracting away from the standard is not simpler. This is basic html knowledge. We can agree to disagree
So here's the thing, JSX is very much not like HTML. It gets compiled to a bunch of React.createElement calls (If you're using React). This also kind of decouples the element kinds from the self-closingness, which would be a mess to deal with in typescripts type system (for TSX). And every time the spec would add a new HTML element, you'd need to update the JSX parser itself. In this way, the JSX spec is kind of decoupled from the HTML spec, which I believe is a good thing.
In case of Svelte I can understand this, because, as Rich said, it's a superset of HTML. JSX is not a superset of HTML, it is a superset of XML and doesn't even compile to HTML (unless you use something like SolidJS, which compiles them to HTML templates)
@@hamm8934 In most cases, it doesn't even compile to HTML. It's not an abstraction of HTML, it's an abstraction of the (virtual) DOM that looks like HTML
@@spicybaguette7706 its an abstraction of knowledge leading to many of the fundamental misunderstands devs have with html vs jsx and xml
emojis aren't a single character code, is usually multiplebyte character codes which when joined add up and make the emoji.
Just in time for my F5
I don't care what Svelte is, but means , because the point is I'm NOT writing HTML. I'm writing a non-HTML something that only looks like HTML will eventually _become_ HTML and I expect the framework to handle it correctly to generate the HTML I expect, NOT the incorrect HTML it thinks is compliant with my non-HTML thing. If I wanted Hello. I would NOT write Hello. Because that's just stupid. I would read that and understand it to be Hello. Who wouldn't? The fact that it would be interpreted _IN_ HTML as Hello is **IRRELEVANT**. Because I'm NOT writing HTML. I'm writing a non-HTML something that will eventually become HTML. And I expect my non-HTML to do what I think it does, not what someone else think it does. Why is this even a debate? It's stupidly obvious.
18:46 - Fortunatelly Python allows you to define emojis as variables.
Biggest pain in the ass is conditionally self-closing tags like
Regarding its faster, that depends on implementation.
I could see an alternative approach:
Sees BR - Identifies it as a BR tag.
Sees /> - closes tag. Moves on.
Vs Sees BR - Identifies it as a BR tag.
See / - Ignores it.
See > - Closes tag.
Checks if it is in the list of elements that can't have children and because of that self-closes.
The article seems to just ignore this possibility and think the only way it could do it is if it ignores the slash and then checks anyway, but that is not the only case.
Sorry, no. When I write Hello, I don't want it to suddenly become Hello. If Prettier is going to do something, it should make it Hello, because that's my expectation. And if it is not, then I can correct that by actually moving Hello inside.
It's time for HTML 6