I've spent more time thinking about this than I meant to, but I can't think of a good way to combine those three languages into one without creating "three languages in a trench coat".
Each language fits a different niche. Assuming we're not going the Gemini "baby with the bathwater" approach and are retaining the capabilities of all three (more or less), you'll need three sub-languages that fill the three roles.
HTML is a content markup language and has, over the years, drifted increasingly towards being a semantic markup language (not full-on semantic web markup, but not the rather anemic semantic model it could describe 30 years ago). We've separated the formatting/layout to CSS for a reason, though you don't actually need CSS files or even <style> tags unless you want them. You can embed all that in the HTML elements as attributes. However, we separated that out (as an industry) for a good reason, if you embed it into the elements you have to update every page when you want a uniform change. That's a PITA, so you'll end up with separate markup and formatting anyways, at least if you want people to use your language for anything more than one off pages. And if you want adoption (and not the extremely low adoption of gemtext) then you'll end up doing this.
So you have two languages, content markup and formatting/layout. You can mash them together to be "one" language, but it'll be two sub-languages that aren't really the same at all, and we're just splitting hairs.
Then you get to JS. Its role is to be the procedural language giving you dynamic changes to the content and layout/formatting. You could make a declarative language for this, but those are (apparently, based on adoption) harder for people to reason about and use than conventional procedural languages. This gives us a sharp divide in our one language between the declarative portions and the procedural portion. And, again, you'll want to separate out this dynamic portions from the more static portions for better reuse.
In the end, you will likely have three separate file types even if they ostensibly contain the same language. You'll have content files, formatting/layout files, and dynamic content files, and some mechanism of including them into a page for rendering. And each will be described using a different sub-language of your one language.
This puts us right back where we started, but now we have 6 standards (ignoring the fact there are multiple versions of HTML, CSS, and JS already) instead of three.
So that brings us to the only way to move away from HTML, CSS, and JS that has a chance at actually replacing them: Three new languages that each fill the same roles as the current languages, but do it better. Potentially with greater uniformity of design between the three languages, but the sharp divide between the declarative HTML/CSS replacements and the procedural JS replacement will make this a very challenging language design problem.
----------
All that written, if you don't care about replacing them, you absolutely could do a weird mashup language and ignore all the reasons for separating the three out. You just won't get adoption outside of a niche community like Gemini has developed around their restricted formats.