9 ms·

State of HTML 2023 now open

140 points by MzHN 3y ago

madacol 3y ago
- Survey link: https://survey.devographics.com/en-US/survey/state-of-html/2023 https://survey.devographics.com/en-US/survey/state-of-html/2... - State of HTML: https://stateofhtml.com/ https://stateofhtml.com/ It's the same organization (https://www.devographics.com/ https://www.devographics.com/) behind "State of Js" (https://stateofjs.com https://stateofjs.com) Took me a couple minutes to verify that
- codetrotter 3y ago
  > 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.
capableweb 3y ago
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.
- chrismorgan 3y ago
  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.
- bryanrasmussen 3y ago
  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?
- simonw 3y ago
  What have you used CSP for?
- wryanzimmerman 3y ago
  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?
sylware 3y ago
I cannot take the survey with my noscript/basic (x)html browsers. Expected? Or I missed the link?
- eric-burel 3y ago
  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 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.
- rs_rs_rs_rs_rs 3y ago
  >I cannot take the survey with my noscript/basic (x)html browsers. Good.
  - arcanemachiner 3y ago
    How do you figure?
    - decremental 3y ago
      [dead]
- SanderNL 3y ago
  The “state of HTML” is that it has become a glorified payload wrapper to deliver corporate JS shitware to you as efficiently as possible.
throwaway167 3y ago
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.
- deleted 3y ago
  [deleted]
- dgb23 3y ago
  HTMX is a JS library that perfectly illustrates how HTML is too limited and unfinished.
  - nsonha 3y ago
    [flagged]
    - PaulHoule 3y ago
      Definitely something better than HTMX is possible but to really reap the benefits of that approach you need an opinionated back end, probably more use of WebSockets, Phoenix is somewhat in that direction. A lot of it is backlash against React and various things like Vue and Svelte that are pretty much the same. People haven’t really grokked how much the hassles of working with React have to do with its very success, it is just so easy to have a big app with 7 different widget sets to master and not just that, the conceptual simplicity of React makes it a leaky enough abstraction that you can never really count on just using a widget set and having it look good but you have to mess with the CSS not just to please clients, managers and customers but even yourself as there are always cases where the spacing of things is just terrible without getting deep into it. Since CSS is not really appropriate for programming in the large you will also wind up sucking in widgets that use things like Emotion which never let you forget about CSS but rather give you more complicated things to learn.
butz 3y ago
Will be interesting to see results, as HTML did not evolve too much during last year, or last 5 years even. Also, what are JS APIs doing in this survey?
- EMM_386 3y ago
  This is covered halfway down the landing page.
MzHN 3y ago
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
- deleted 3y ago
  [deleted]
- tolciho 3y ago
  Where was that? All I got was a page with "Redirecting..." using w3m off the survey link.
Buttons840 3y ago
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 https://www.w3.org/TR/WD-DOM/introduction.html
- thefounder 3y ago
  I think there are efforts within the WebAssembly GC to expose the DOM API directly to WASM programs.
  - cloudwalk9 3y ago
    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.
    - thefounder 3y ago
      >> 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
promiseofbeans 3y ago
Kinda ironic that when you disable JS, the form about HTML doesn't work, despite HTML having built-in forms that work without JS.
- dgb23 3y ago
  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.
  - Devasta 3y ago
    https://www.w3.org/Bugs/Public/show_bug.cgi?id=10671#c16 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.
  - tln 3y ago
    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
    - dgb23 3y ago
      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.
hombre_fatal 3y ago
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.
- pwdisswordfishc 3y ago
  Is it that high? If it’s more that 75%, then indeed shame on you.
- danielvaughn 3y ago
  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
- chrismorgan 3y ago
  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).
pcurve 3y ago
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.
- wilkystyle 3y ago
  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.
tgv 3y ago
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.
- lucgagan 3y ago
  Can we not derive this information by looking at adoption of these APIs across the web?
- simonw 3y ago
  "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.
danielvaughn 3y ago
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.
- eastbound 3y ago
  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.
  - SanderNL 3y ago
    That’s not hard. Hard is solving world hunger, making cars drive themselves. You literally counted all major issues in one simple comment.
  - danielvaughn 3y ago
    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.
- SanderNL 3y ago
  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.
miiiiiike 3y ago
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.
- dragonwriter 3y ago
  > 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.
  - miiiiiike 3y ago
    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.
    - dragonwriter 3y ago
      > 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.
zagrebian 3y ago
Is the survey only available in dark mode?
- eric-burel 3y ago
  There is a ticket here feel free to add to the discussion: https://github.com/Devographics/Monorepo/issues/309 https://github.com/Devographics/Monorepo/issues/309
  - zagrebian 3y ago
    Yes, I created that ticket :-)
AtlasBarfed 3y ago
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.
- rezonant 3y ago
  This is pretty much what Web components is
peferron 3y ago
The "add to your reading list" feature is excellent, and a nice carrot/reward for completing the survey.
grncdr 3y ago
Why are none of the links in the "reading list" to MDN?

140 points by MzHN 3y ago

- Survey link: https://survey.devographics.com/en-US/survey/state-of-html/2023 https://survey.devographics.com/en-US/survey/state-of-html/2... - State of HTML: https://stateofhtml.com/ https://stateofhtml.com/ It's the same organization (https://www.devographics.com/ https://www.devographics.com/) behind "State of Js" (https://stateofjs.com https://stateofjs.com) Took me a couple minutes to verify that

codetrotter 3y ago
> 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.

capableweb 3y ago

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.

chrismorgan 3y ago
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.
bryanrasmussen 3y ago
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?
simonw 3y ago
What have you used CSP for?
wryanzimmerman 3y ago
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?

sylware 3y ago

I cannot take the survey with my noscript/basic (x)html browsers. Expected? Or I missed the link?

eric-burel 3y ago
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 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.
rs_rs_rs_rs_rs 3y ago
>I cannot take the survey with my noscript/basic (x)html browsers. Good.
- arcanemachiner 3y ago
  How do you figure?
  - decremental 3y ago
    [dead]
SanderNL 3y ago
The “state of HTML” is that it has become a glorified payload wrapper to deliver corporate JS shitware to you as efficiently as possible.

throwaway167 3y ago

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.

deleted 3y ago
[deleted]
dgb23 3y ago
HTMX is a JS library that perfectly illustrates how HTML is too limited and unfinished.
- nsonha 3y ago
  [flagged]
  - PaulHoule 3y ago
    Definitely something better than HTMX is possible but to really reap the benefits of that approach you need an opinionated back end, probably more use of WebSockets, Phoenix is somewhat in that direction. A lot of it is backlash against React and various things like Vue and Svelte that are pretty much the same. People haven’t really grokked how much the hassles of working with React have to do with its very success, it is just so easy to have a big app with 7 different widget sets to master and not just that, the conceptual simplicity of React makes it a leaky enough abstraction that you can never really count on just using a widget set and having it look good but you have to mess with the CSS not just to please clients, managers and customers but even yourself as there are always cases where the spacing of things is just terrible without getting deep into it. Since CSS is not really appropriate for programming in the large you will also wind up sucking in widgets that use things like Emotion which never let you forget about CSS but rather give you more complicated things to learn.

butz 3y ago

Will be interesting to see results, as HTML did not evolve too much during last year, or last 5 years even. Also, what are JS APIs doing in this survey?

EMM_386 3y ago
This is covered halfway down the landing page.

MzHN 3y ago

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

deleted 3y ago
[deleted]
tolciho 3y ago
Where was that? All I got was a page with "Redirecting..." using w3m off the survey link.

Buttons840 3y ago

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 https://www.w3.org/TR/WD-DOM/introduction.html

thefounder 3y ago
I think there are efforts within the WebAssembly GC to expose the DOM API directly to WASM programs.
- cloudwalk9 3y ago
  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.
  - thefounder 3y ago
    >> 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

promiseofbeans 3y ago

Kinda ironic that when you disable JS, the form about HTML doesn't work, despite HTML having built-in forms that work without JS.

dgb23 3y ago
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.
- Devasta 3y ago
  https://www.w3.org/Bugs/Public/show_bug.cgi?id=10671#c16 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.
- tln 3y ago
  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
  - dgb23 3y ago
    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.

hombre_fatal 3y ago

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.

pwdisswordfishc 3y ago
Is it that high? If it’s more that 75%, then indeed shame on you.
danielvaughn 3y ago
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
chrismorgan 3y ago
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).

pcurve 3y ago

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.

wilkystyle 3y ago
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.

tgv 3y ago

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.

lucgagan 3y ago
Can we not derive this information by looking at adoption of these APIs across the web?
simonw 3y ago
"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.

danielvaughn 3y ago

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.

eastbound 3y ago
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.
- SanderNL 3y ago
  That’s not hard. Hard is solving world hunger, making cars drive themselves. You literally counted all major issues in one simple comment.
- danielvaughn 3y ago
  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.
SanderNL 3y ago
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.

miiiiiike 3y ago

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.

dragonwriter 3y ago
> 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.
- miiiiiike 3y ago
  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.
  - dragonwriter 3y ago
    > 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.

zagrebian 3y ago

Is the survey only available in dark mode?

eric-burel 3y ago
There is a ticket here feel free to add to the discussion: https://github.com/Devographics/Monorepo/issues/309 https://github.com/Devographics/Monorepo/issues/309
- zagrebian 3y ago
  Yes, I created that ticket :-)

AtlasBarfed 3y ago

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.

rezonant 3y ago
This is pretty much what Web components is

peferron 3y ago

The "add to your reading list" feature is excellent, and a nice carrot/reward for completing the survey.

grncdr 3y ago

Why are none of the links in the "reading list" to MDN?