State of HTML 2023 now open
lea.verou.me
lea.verou.me
- State of HTML: https://stateofhtml.com/
It's the same organization (https://www.devographics.com/) behind "State of Js" (https://stateofjs.com)
Took me a couple minutes to verify that
Both pages say “made by devographics” at the bottom.
Not that I’ve personally heard about either State of HTML, State of JS, nor Devographics before.
Whenever I pick up a book to brush up on HTML it always a 98 chapter, 10,000 page tome book called "XYZ & HTML: The Complete Guide For Real". Chapter 1: HTML (pages 1-2). Chapters 2-98: CSS (pages 3-10,000).
I'd really like to see an "HTML: The Definitive Guide" that treats HTML as the nexus of web technologies that it is.
But the thing is just that: HTML sits at the nexus of a bunch of web technologies, but it itself is the simplest of them, especially when you consider that the DOM, which is part of the HTML standard, makes little sense for learning outside of the context of JavaScript, as it is a programming API and JS is the only language woth first-class support that has access to it. There is a reason that books intended as definitive rather than brief tend to include CSS and at least enough JS to contextualize the DOM APIs as well as HTML since about HTML5.
For years HTML has been evolving to take features that used to require heavy JavaScript (e.g. dialogs, popovers, as recent examples) and make them available to authors without needing to use any JavaScript.
HTML has enough of a complement from CSS/JS that it needs its own book. For example, semantic HTML doesn't make much sense in a JavaScript book. I end up going through the spec over and over again. Would rather have something open next to me on my desk.
There are tons of HTML-specific books, but complete/definitive ones will cover the DOM and other aspects of HTML that are only meaningful in the context of CSS and JS, and thus they will cover at least some CSS and JS, too.
Not sure why you want a work to be marketed as “definitive” but also be woefully incomplete, but I think that there is a very good chance that the reason that book does not exist is that you would be the entire market for it.
How many of those HTML books have been published since 2011? Have you read CSS or JavaScript The Definitive Guide? Complete? No. Useful? Yes.
ISBN 9781032413259
I also saw a lot of books from 2022.
edit
I'm not being contrarian for the sake of it, but the book you posted is exactly what I'm talking about when I say that there aren't very many good books on HTML. Just scanning it I'm finding errors (technical, spelling, and grammar) and they didn't even attempt to format the code samples: https://imgur.com/a/pLnbxt0
Look at the TOC. I wouldn't call this an especially focused book. It's a hodgepodge of front-end dev topics.
HTML is a tricky topic and it's not addressed well in any recent book I've seen. Watch Kevin Powell's video from yesterday: "Turns out I know less about HTML than I thought! " https://www.youtube.com/watch?v=sPWlakxKRm8 — and I guarantee that Kevin knows more than most.
How are you finding the additional titles? The search on the link you posted earlier isn't surfacing anything recent or relevant when I search "HTML".
Here, instead of search results, do you have an example of a good, recent, HTML book that you've found useful?
I didn't get to the point where I could say: stop adding lock-in features to Chrome, or remove the privacy invading stuff from it.
There's an open question for feedback on the last page you could use for that.
One of the values of frames was that it did that. Most "portal" frameworks I've seen are nightmares of spaghetti code trying to route around this, and it prevents any true fragment-consumption without the iframe.
It also would allow likely a lot more "rich widgets" where a mess of javascript was contained only in the section of the HTML document needed by that widget, so a library/zoo/collection of widgets could be safely put together.
I don't even want to reveal my "feature score" from the end of the survey.
1. The pareto effect holds true (I use a little over 20% of html's features)
2. There are a lot of interesting features in html that I should take advantage of more often
I wonder if a new browser that doesn't treat JavaScript as a special language will ever succeed? How long until the DOM is usable in languages other than JavaScript? Yesterday I read about someone writing their own browser, which they didn't expect to succeed, but I think a lot of people might jump at the first chance they get to leave big tech companies and JavaScript behind. I lump JavaScript and big tech companies together, but their problems are very different; it would be a breath of fresh air to leave either though.
The W3C says: "As a W3C specification, one important objective for the Document Object Model is to provide a standard programming interface that can be used in a wide variety of environments and applications. The Document Object Model can be used with any programming language."[0] How long until this is true in a practical way? Has there ever been a more widely used and important API that is constrained to only one language?
I would assume this is the direction WASM is trying to go? It sounds so much cleaner, and it does seem the DOM being limited to JS is one of the showstoppers.
Yes, that's it and more. WASM is runtime idependent so it can run on cloud platforms or(in theory) even on bare metal interacting with the host through WASI
But those are all JS flavors.
In that case, designers could work with templates that are pure HTML, loren ipsum and all (as opposed to the always somewhat disorganized mess you get with FreeMarker or Jinja2 that is never quite properly handled by Dreamweaver, IDEs, and such), and the tools would stick content into slots identified by id, CSS selectors and such. (not to mention transformations such as “replace the word ‘red’ in text with <span class=“red”>red</span>]
I have built prototypes that are a few orders of magnitude slower than plain text templating and that’s one reason this has never caught on. It is not terribly hard to do it in either Java or Puthon. If you take it seriously you run headlong into hygienic macro problems although namespace troubles in class names have always been a bugaboo in HTML and CSS that have led to all sorts of bad ideas culminating in “f it let’s just use tailwind”. Really though you ought to be able to transclude any HTML+CSS into another document and bring along the relevant formatting (with the caveat that you do have to consider things like the global availability of space) and not have name collisions.
An excerpt:
> If you don’t write any JS, we absolutely still want to hear from you! In fact, I would encourage you to fill out the survey even more: we need to hear from folks who don’t write JS, as they are often underrepresented. Please feel free to skip any JS-related questions (all questions are optional anyway) or select that you have never heard these features. There is a question at the end, where you can select that you only write HTML/CSS
Aside from forms being essentially broken and too limited from a UI perspective, it doesn’t even support all the basic HTTP methods.
Form validation on the client (helping the user to understand what valid input is before sending the form), is very limited without JS.
Extremely basic and widespread input components don’t exist, like proper combo boxes.
You can lean into HTML standards, and you probably should, especially with forms. But not using JS at all leads to bad UI.
Doesn't make sense that you would want to support other HTTP methods apparently.
How should a combo box behave? It's a windows control but the original behavior is barely used. Just curious what your definition is.
<selectlist> looks like a step in the right direction, since you will (if it gets implemented) be able to implement custom select lists with much more native/browser provided behavior
Again, client side form validation is all about guiding the user. It's a pure UI concern that should make it easy and obvious for the user to understand if they are about to make a mistake or similar.
Take "pattern" for example:
At which point is this useful for UI? Does it tell an average user what they _actually_ need to know to provide a correct input?
No of course not. Regex patterns are deemed black magic, even among some programmers. You are going to have to explain in words what the format (or pattern) is supposed to be.
Great, the user understands what is should be. But the error message is still a useless and generic "It's not correct".
We don't do that to ourselves btw. Our programming languages tell us exactly what the issue is and where it is. We also automatically insert characters and terms or at least suggest them.
Or other trivial stuff like date/time ranges (from/to) can't be expressed with native form fields.
The solution to this is of course to use JS: composite input fields, insert spacing or other characters to automatically structure inputs, make suggestions, underline errors etc.
But all of that is bespoke, subtle and sometimes hard to make accessible. It's 2023.
<input pattern="[A-Za-z_][A-Za-z_0-9]+">
<div role="alert" class="explain-invalid">Enter an identifier</div>
<style>
input:invalid {
border-color: red;
}
input:invalid + .explain-invalid {
display: block;
color: red;
}
.explain-invalid {
display: none;
}
</style>
A built-in date range would be nice. Perhaps you should suggest in the survey (if you didn't take it already)
But even in a simple case like this: if the user makes a mistake, say inserts a character that doesn't match the pattern, there's no way to tell the user which character exactly causes the problem.
Trivially, because the regex to validate, wouldn't be the regex (or parser) that finds the culprit and highlights it. You'd have to write a different regex for that (which is not natively supported anyways).
A slightly better example of this:
Say you let the user choose a password, but you limit the types of characters and also require that certain types of characters are inserted at least once.
(Aside from the fact that this is a terrible idea. You see this in the wild all the time and it's an example that illustrates the problem.)
Now the user's PW manager inserts a random, long password but the field doesn't validate. What's the message? How does the user find the culprit (character)?
There are all sorts of things like that, especially with inputs that require a specific format. Credit card numbers, social security numbers, stuff like that.
Again, I very much lean into HTML and Web standards when I can (and am aware) but at the same time you can't avoid JS if you want to make a good UI that helps the user and is accessible in many cases.
I quit JS for HTMX because time in JS, fully loaded time with framework knowledge and maintenance, is just not very important for my use case which is CRUD apps. The change to HTMX saves me time, it saves users' time, it gives a consistent experience for both.
That's not to say JS is bad. I'm not dying on that hill as it's not true - pick the tool for the job. But a HTML survey this is not, it's a HTML for JSers survey.
Expected? Or I missed the link?
Good.
Personally I don't see it as a good or bad thing, it's just one way of building web apps, and it so happens it's the one I know how to do.
It’s easy to make this work without JS. It’s telling that this is the state of ‘HTML’. These skills are rusting away and it’s a sad thing.
The truth is that building web apps is a large and complex enough field that it's quite hard for a single person to master all of it, and I think we should normalize the fact that any single developer will have their areas of strength and weakness.
Just do it on a single page, in one big form that's submitted at the end. Don't even bother with styling it.
If a version like that were available, I probably would've completed the survey because I could have more easily judged how long it would take to finish it.
If you want to browse openstreetmap (have an instance on my home server with my email): https://www.rocketgit.com/user/sylware/lnanohtmltiledmap (could be used as a base).
So if you haven't done anything to work with something can you say you've 'used' it.
Perhaps people just demonstrate a different opinion of linguistic usage?
There are a lot of ways you could send a valid response without including that header or tag, any policies are not one-size-fits all and could be different. Maybe you’re using a full-stack framework which is managing it for you?
Or maybe you’re confusing it with CORS?