State of HTML 2023 now open(lea.verou.me)
lea.verou.me
State of HTML 2023 now open
https://lea.verou.me/blog/2023/state-of-html-2023/
87 comments
> 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.
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.
I learn from books and for front-end development I learned from O'Reilly's "The Definitive Guide" series. There's a recent edition for both CSS and JavaScript but not for HTML. Just look at the survey, HTML is huge and touches or at least rubs against everything.
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.
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.
> 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.
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.
I completely disagree with the premise of your comment.
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.
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.
> HTML has enough of a complement from CSS/JS that it needs its own book.
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.
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.
> There are tons of HTML-specific books
How many of those HTML books have been published since 2011? Have you read CSS or JavaScript The Definitive Guide? Complete? No. Useful? Yes.
How many of those HTML books have been published since 2011? Have you read CSS or JavaScript The Definitive Guide? Complete? No. Useful? Yes.
One recent example (just a random search result): https://www.routledge.com/HTML-The-Ultimate-Guide/Uzayr/p/bo...
404’d. Searching on that site tho, I’m seeing 2012, 2011, and 2014 for the HTML books. That’s my point, almost all of the books on HTML are 10+ years old at this point.
HTML The Ultimate Guide, By Sufyan bin Uzayr, Published July 28, 2023 by CRC Press
ISBN 9781032413259
I also saw a lot of books from 2022.
ISBN 9781032413259
I also saw a lot of books from 2022.
Neat. I'll give it a look.
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?
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?
Towards the end of the survey, they asked us to choose 3 html features we'd like to see supported in the future. Infinite scroll was one of the options, but I really wish they threw in pagination as well. If I never had to code a pagination widget again, I'd be a happy man.
Pagination is so hard. It deserves a book on its own. Do you show row numbers (100-200 of 800) or page numbers? Do you have the total count? Do you go to the next page with a cursor (an undecipherable hash) or with a page number? Can you go to the previous page? Can you go to the first page? Can you change pagination size? What options do you display given the room for the widget? It seems so specific that it might be a non-generalizable feature, as surprising as it could be. That, or some Apple guy, after a lot of research, will find a multifeature widget, where each details means a different thing.
That’s not hard. Hard is solving world hunger, making cars drive themselves. You literally counted all major issues in one simple comment.
Good point, with complex UI it's hard to satisfy everyone. You end up with the html date picker, which technically works though I imagine most people end up implementing their own anyways.
It’s sad a proper table is not in the standard. We got a kinds of ridiculously complicated bullshit CSS transitions, but some kind of basic lazy-loading table with pagination is beyond us apparently.
Hats off to whoever created the landing page. It is crystal clear in explaining its intent and benefits for the audience. It’s like the author is reading my mind as I’m scrolling down.
Agreed. Aesthetically pleasing, and generally a pleasure to read. No disruptive visual gimmicks or strange font/color choices that so many websites use, prompting me to immediately reach for the reader mode button.
I've done a few pages, but it just asks "do you know this feature?". Do you know document.getElementThatWasClicked2SecondsAgo()? Do you know document.getElementThatWasClicked3SecondsAgo()? And document.getElementThatWasClicked4SecondsAgo()? Etc.
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.
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.
"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.
There's an open question for feedback on the last page you could use for that.
Can we not derive this information by looking at adoption of these APIs across the web?
Was there ever anything added to HTML that would make <script> tags defined inside a div or other container tag essentially lexically scoped to tags and elements only within that div?
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.
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.
This is pretty much what Web components is
Oof, this should be pretty humbling to most web developers.
I don't even want to reveal my "feature score" from the end of the survey.
I don't even want to reveal my "feature score" from the end of the survey.
Yeah this was an eye-opening experience for me. I'm not necessarily humbled, but it points out two things to me (for the record I got a 35%).
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
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
Look, most of the surface area it’s talking about is quite new, often still nominally experimental, and quite a bit not supported across all browsers (most commonly Chromium-only, with some Chromium-and-Safari-since-March-but-not-Firefox-yet; and note that none of them have an implementation but lack a Chromium implementation, even though there are a few possible features that meet these criteria—this is one of a few things that show the heavy Chromium bias in the survey).
Is it that high? If it’s more that 75%, then indeed shame on you.
The "add to your reading list" feature is excellent, and a nice carrot/reward for completing the survey.
I see a lot of pent up frustration towards JavaScript and the large companies that control our browsers and the internet (perhaps because I see a lot of myself :).
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?
[0]: https://www.w3.org/TR/WD-DOM/introduction.html
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?
[0]: https://www.w3.org/TR/WD-DOM/introduction.html
I think there are efforts within the WebAssembly GC to expose the DOM API directly to WASM programs.
I don't have much skin in the game, not being a web developer, but something I find intriguing about WASM is the possibility for JS to merely become one of many possible languages to use instead of being the end-all-be-all language of the web. That is, WASM being a successor to JS insofar as being the primary runtime, instead of being dependent on JS.
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.
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.
>> I would assume this is the direction WASM is trying to go?
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
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
JavaScript, JScript, ActionScript
But those are all JS flavors.
But those are all JS flavors.
There’s definitely the possibility that an SSR system can use the DOM model or something very close to manipulate HTML as a substitute for the many different text-based templating systems.
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.
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.
[deleted]
Is the survey only available in dark mode?
There is a ticket here feel free to add to the discussion: https://github.com/Devographics/Monorepo/issues/309
Yes, I created that ticket :-)
Why are none of the links in the "reading list" to MDN?
Since there are a few comments on JS, I recommend reading this section in the article: "Why are there JS questions in an HTML survey?"
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
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
Where was that? All I got was a page with "Redirecting..." using w3m off the survey link.
[deleted]
Kinda ironic that when you disable JS, the form about HTML doesn't work, despite HTML having built-in forms that work without JS.
That’s because HTML is severely neglected.
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.
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.
Form validation isn't too bad these days IMO. Required, pattern, email, url, numbers, dates, etc.
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
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
In terms of form validation: Those things are all useful, but also trivial, scoped to a single element and in some cases near useless from a UI/UX perspective on its own.
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.
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.
I'm not sure what feature you want to add to "tell the average user" in anything other than "explaining in words". In this example, pattern lets me show some explanation, in text, when the input doesn't match, without using Javascript
A built-in date range would be nice. Perhaps you should suggest in the survey (if you didn't take it already)
<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)
That's fine, but it's also a relatively easy to understand pattern that most can follow. You can explain it trivially in text.
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.
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.
https://www.w3.org/Bugs/Public/show_bug.cgi?id=10671#c16
Doesn't make sense that you would want to support other HTTP methods apparently.
Doesn't make sense that you would want to support other HTTP methods apparently.
[deleted]
For a HTML survey, there was a heck of a lot about JS in there so I quit it. Not for me.
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.
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.
I cannot take the survey with my noscript/basic (x)html browsers.
Expected? Or I missed the link?
Expected? Or I missed the link?
The “state of HTML” is that it has become a glorified payload wrapper to deliver corporate JS shitware to you as efficiently as possible.
I'm one of the developers of the survey app. While I would love to have the app work seamlessly without JavaScript, the reality is that when you build apps with a React/Next.js stack the path of least resistance does usually take you in a direction that requires JS to work.
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.
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.
Nothing against you, but it’s kind of depressing to me.
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.
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.
Taking the survey myself definitely showed me my own HTML skills are rusty as a consequence of building JavaScript apps for the last decade.
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.
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.
Agreed. I think the two of us can talk all day about the necessity of it becoming a “large and complex field”. I accept I am an old miser about it, but it is indeed the reality.
I only got part-way through the survey before moving on, but based on what I did see of it, it doesn't look like an alternative HTML-only/non-JavaScript version should be that hard to put together at all for future surveys.
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.
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.
I would recommend 2D semantic HTML documents (using a table), and no, HTML tables are not harmful (https://webaim.org/techniques/tables/ with a real life example https://iroiro.neocities.org/ ). People with visual impairment can still navigate easily (see webaim page above) with screen readers.
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).
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).
How do you detect which version to serve in this case? Using User-agent server-side, or something else client-side? Or maybe letting the user decide using a separate website?
It's a bit ironic to host the state of html survey in an environment that absolutely requires JavaScript. It is also a pretty bad thing since progressive enhancement is a key principle of the web.
Yep, I am going to explain exactly that to my administration, with my lawyer.
Hi, the State of HTML survey is built upon the same code as State of JS, State of CSS, State of GraphQL, and very soon State of React. Those surveys involve highly interactive components for some questions.It's implemented using Next.js and React, which until the advent of App Router less than one year ago would have required a JavaScript hydration step to be interactive. So having it to work without JS enabled is not top-priority. Also there is still a lot of legacy code around (it was previously a MeteorJS app, it has been a long way).
However we are really keen on improving and learning new stuffs. All suggestions are welcome on our GitHub repo: https://github.com/Devographics/Monorepo/issues
I would be very interested to know more about your setup, so I can test the app with a similar setup.
With Next.js 13 and App Router, it might become easier to server pure HTML. However I've noticed that with streaming enabled (when you have a loading page or use Suspense) you still need a tiny bit of JS (just to remove the "hidden" state of your content) even with RSC, so it's still not that easy.
[deleted]
>I cannot take the survey with my noscript/basic (x)html browsers.
Good.
Good.
I hope 100% of the respondents answer that they've used "Content-Security Policy (CSP)" as it's there by default and by answering anything else, they probably out themselves as basically not knowing their own space where they work.
Are you thinking of something else? Perhaps the same-origin policy, the thing that requires CORS if you need to do various cross-origin stuff? Because CSP is not something there by default.
What do you mean by there by default?
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?
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?
I mean there are things you do like turn it on the server etc.
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?
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?
What have you used CSP for?
- 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