4 ms·

> My personal opinion on this is to stop feeding the monopoly and refuse to use anything other than basic HTML for static content sites. That's not going to wo

> My personal opinion on this is to stop feeding the monopoly and refuse to use anything other than basic HTML for static content sites. That's not going to work for one simple reason: despite HN's obsession with plain HTML/CSS, these new standards _are_ actually useful. They're being created with the express purpose of solving practical problems that developers, site operators, and users are experiencing in the real world. Those stakeholders aren't going to just ignore a practical solution to their problem over some esoteric concerns about "feeding the monopoly". I share your concerns about the proliferation of web standards making it difficult for browser vendors to compete, but if the only alternative you can offer is stagnation I think it's completely unsurprising that your concerns go unheeded.

lucideer 7y ago
> these new standards _are_ actually useful I don't necessarily disagree, but it would help your case if you includes some examples in your comment (if only to build a discussion upon).
- lstamour 7y ago
  You have to take the mindset that "giant bundles of JavaScript" aren't how we want to build the web but to begin to ship more and more of the web baked into browsers instead. And that even "static HTML" requires accessibility improvements and adaptations to new device types. For example, split screen phones, where you've a mobile device that starts at one size, but then can open up to a larger size. Tiny watch apps, new camera APIs, Responsive @media queries, better support for print media, less onscroll jank through the use of IntersectionObserver, new authentication APIs to support Windows Hello, advancements to link tags for prefetching resources and DNS, CORS security enhancements, discussion about proprietary browser implementations of features so they're not proprietary, using origin trials (Chrome) or the Develop menu (Safari) or preferences (Firefox) to encourage web developers to try new features on their sites and report back on how they work (origin trials make this trivial), non-vendors building new features for the web such as Intel and Facebook, and ... well, it's hard to summarize how many advancements there have been in web standards since HTML5 became a thing. I'd also point to a useful parallel in how ECMAScript versions their spec, it's in a constantly evolving state also as new proposals move between stages. To me, this reflects how standards bodies now can use git much more easily and effectively as a versioning mechanism and how they've learned to try and use the best of open source instead of locking up versions behind paywalls and private interest groups. Literally anyone can contribute to these specifications, see https://www.youtube.com/watch?v=y1TEPQz02iU https://www.youtube.com/watch?v=y1TEPQz02iU
  - lucideer 7y ago
    > You have to take the mindset that "giant bundles of JavaScript" aren't how we want to build the web but to begin to ship more and more of the web baked into browsers instead. "giant bundles of JavaScript" weren't how we shipped the web before the HTML5 process began. The solution to "we're loading too much overengineered bloated redundant logic over HTTP" isn't "lets bundle all of that logic", it's "stop overengineering simple webpages". > even "static HTML" requires accessibility improvements and adaptations to new device types Accessibility standards predate and are still external to HTML5, and have actual fixed specs. They're relatively simple to implement from a parser perspective, and individual tools implementing functionality on top of that are ancillary to mainstream browsers. The only exception here is support for things like MSAA, etc. and that's also completely separate to HTML5 et al. You go on to list a bunch of CSS stuff (again, some pre-dating HTML5, none coming from WHATWG), proprietary browser settings (not a part of any spec, living or static). > better support for print media Now this would be great to see. However this is something we definitely have not gotten since the advent of HTML5. What are you referring to here? CORS pre-dates HTML5 (was later subsumed into HTML5), but the newer auth APIs you mention are nice; I'll give you that. Things like IntersectionObserver however are one perfect example of extra feature-creep in HTML5, building hacks on top of an ecosystem overrun with overengineering. You should not need IntersectionObserver to get basic, usable performant scrolling. If you feel you do, you've overengineered your webapp: try actually addressing your performance bottlenecks.
    - lstamour 7y ago
      I was speaking more generally about live standards, but if you want to focus specifically on the HTML spec and notable changes for newer devices and accessibility: https://github.com/whatwg/html/commits https://github.com/whatwg/html/commits Let’s see, right off the top we’ve inputmode attr which helps support different keyboards on plain input text controls, we’ve enterkeyhint which lets you pick from a list of options for the enter key on virtual keyboards - both of these changes improve the usability and accessibility of the keyboard on newer touch screen devices. Form-associated custom elements let you create your own HTML elements that can participate in forms (the goal of custom elements is to help you build your own custom LEGO pieces instead of relying on the basic blocks the HTML spec includes — one could think of this as an eventual replacement of JSX components with HTML-based ones), autocomplete=one-time-code (thanks, iOS!), more granular control over file downloads, updating the spec to match reality (what browsers actually implemented for compatibility vs what was written in advance), srcset for retina (which reminds me, lazy loading images as a simple img tag attribute), WeakMap/WeakSet to help reduce memory leaks from stale DOM node references, requestAnimationFrame and other enhancements to the page lifecycle, CSP headers and related HTML attribute changes, and well, the list doesn’t end. ;-) For accessibility there’s the inert attribute that prevents focus to child content which is great if you need more flexibility than the dialog element provides by default but don’t want to get into setting tabindex manually or controlling all focus with JS, etc.
- hiccuphippo 7y ago
  The Web Authentication standard [0] seems super useful and something we really need in the web. [0] https://developer.mozilla.org/en-US/docs/Web/API/Web_Authentication_API https://developer.mozilla.org/en-US/docs/Web/API/Web_Authent...
  - lucideer 7y ago
    Yeah, this is pretty great. It's also comes from the W3C, not the WHATWG. (it might be a bit lost in the hierarchy of the thread by now, but the original comment was about the WHATWG taking over and monopolising the normal considered and democratic standardisation process of the W3C with their HTML5 "living" spec.)
    - tialaramex 7y ago
      W3C was a good fit for WebAuthn because the W3C is a body for corporations and by its nature WebAuthn is built and primarily implemented by corporations. Not a criticism, by the way, sometimes that's just the right fit.
      - wahern 7y ago
        Huh? The WHATWG steering committee is Apple, Mozilla, Google, and Microsoft. WHATWG's legitimacy (such as it is) doesn't come from being non-corporate, it comes from being entirely controlled by the top corporate browser vendors and thus reflecting the de facto state of affairs regarding how and when and why features are defined and implemented. If the WHATWG disappeared nothing would change because the top vendors are going to pick & choose W3C standards, anyhow.
        tialaramex 7y ago
        Sorry, I was thinking out loud, I was contrasting the other obvious place to standardise this - the distinctly non-corporate IETF. WHATWG makes no sense for something like WebAuthn
CM30 7y ago
This times a million. And for anyone who needs some bona fide examples of new standards and updates that are useful from the WHATWG specifications, well how about: New semantic elements like header, footer, section, article, nav, aside, main, etc. These are far better for making logically structured pages than a ton of divs with class names would be. The various new input types and attributes. Now you can have input fields which validate email addresses and phone numbers, present the right keyboard for the type of input you want, do various other validation checks or even provide things like a nifty date picker without JavaScript. Picture and srcset too. No more having to load giant images on mobile devices or have blurry ones on devices with retina support, you can choose which image displays on which type of device. The preload attribute and what not. Being able to load content the user will likely need in the background is helpful. The built in video and audio elements, obviously. Again, object was a terrible solution for this, which was unsemantic, was awkward to use and struggled in certain browsers. These elements don't. The canvas tag and things you can do with it. And this will be a controversial one, but... most of the old elements that were made official by 'paving the cowpaths' were nice to see added too. The whole fiasco involving embed/object in the old days and how supporting multiple browsers meant invalid HTML was a bit of a farce really, especially as neither were particularly 'semantic' to begin with. Seeing them both made official and better alternatives provided just puts a lifelong issue at rest.
- clairity 7y ago
  if only all of those things were fully flushed out in the various browsers... for instance, it disheartening to realize that it's been 15 years already and useful form elements like date(-time), phone, and email still don't have reliable and complete cross-browser behaviors, validation (i know it's hard, but still), and styling/event hooks.
  - CM30 7y ago
    True, support still isn't perfect. The calendar/date picker stuff is especially annoying here, since it really should be easier to customise and more similar cross browser than it currently is. But most of the things mentioned do work in more browsers than not, and you can use them without worrying the site will break in almost all cases. The new semantic elements will never have issues (unless you're trying to target IE8 or below), the validation works fine in pretty much all modern browsers (as do simple styles for it) and support for the picture element and srcset are pretty good too. The likelihood of anyone using the Blackberry browser or IE mobile is small enough to ignore.

lucideer 7y ago

> these new standards _are_ actually useful I don't necessarily disagree, but it would help your case if you includes some examples in your comment (if only to build a discussion upon).

lstamour 7y ago
You have to take the mindset that "giant bundles of JavaScript" aren't how we want to build the web but to begin to ship more and more of the web baked into browsers instead. And that even "static HTML" requires accessibility improvements and adaptations to new device types. For example, split screen phones, where you've a mobile device that starts at one size, but then can open up to a larger size. Tiny watch apps, new camera APIs, Responsive @media queries, better support for print media, less onscroll jank through the use of IntersectionObserver, new authentication APIs to support Windows Hello, advancements to link tags for prefetching resources and DNS, CORS security enhancements, discussion about proprietary browser implementations of features so they're not proprietary, using origin trials (Chrome) or the Develop menu (Safari) or preferences (Firefox) to encourage web developers to try new features on their sites and report back on how they work (origin trials make this trivial), non-vendors building new features for the web such as Intel and Facebook, and ... well, it's hard to summarize how many advancements there have been in web standards since HTML5 became a thing. I'd also point to a useful parallel in how ECMAScript versions their spec, it's in a constantly evolving state also as new proposals move between stages. To me, this reflects how standards bodies now can use git much more easily and effectively as a versioning mechanism and how they've learned to try and use the best of open source instead of locking up versions behind paywalls and private interest groups. Literally anyone can contribute to these specifications, see https://www.youtube.com/watch?v=y1TEPQz02iU https://www.youtube.com/watch?v=y1TEPQz02iU
- lucideer 7y ago
  > You have to take the mindset that "giant bundles of JavaScript" aren't how we want to build the web but to begin to ship more and more of the web baked into browsers instead. "giant bundles of JavaScript" weren't how we shipped the web before the HTML5 process began. The solution to "we're loading too much overengineered bloated redundant logic over HTTP" isn't "lets bundle all of that logic", it's "stop overengineering simple webpages". > even "static HTML" requires accessibility improvements and adaptations to new device types Accessibility standards predate and are still external to HTML5, and have actual fixed specs. They're relatively simple to implement from a parser perspective, and individual tools implementing functionality on top of that are ancillary to mainstream browsers. The only exception here is support for things like MSAA, etc. and that's also completely separate to HTML5 et al. You go on to list a bunch of CSS stuff (again, some pre-dating HTML5, none coming from WHATWG), proprietary browser settings (not a part of any spec, living or static). > better support for print media Now this would be great to see. However this is something we definitely have not gotten since the advent of HTML5. What are you referring to here? CORS pre-dates HTML5 (was later subsumed into HTML5), but the newer auth APIs you mention are nice; I'll give you that. Things like IntersectionObserver however are one perfect example of extra feature-creep in HTML5, building hacks on top of an ecosystem overrun with overengineering. You should not need IntersectionObserver to get basic, usable performant scrolling. If you feel you do, you've overengineered your webapp: try actually addressing your performance bottlenecks.
  - lstamour 7y ago
    I was speaking more generally about live standards, but if you want to focus specifically on the HTML spec and notable changes for newer devices and accessibility: https://github.com/whatwg/html/commits https://github.com/whatwg/html/commits Let’s see, right off the top we’ve inputmode attr which helps support different keyboards on plain input text controls, we’ve enterkeyhint which lets you pick from a list of options for the enter key on virtual keyboards - both of these changes improve the usability and accessibility of the keyboard on newer touch screen devices. Form-associated custom elements let you create your own HTML elements that can participate in forms (the goal of custom elements is to help you build your own custom LEGO pieces instead of relying on the basic blocks the HTML spec includes — one could think of this as an eventual replacement of JSX components with HTML-based ones), autocomplete=one-time-code (thanks, iOS!), more granular control over file downloads, updating the spec to match reality (what browsers actually implemented for compatibility vs what was written in advance), srcset for retina (which reminds me, lazy loading images as a simple img tag attribute), WeakMap/WeakSet to help reduce memory leaks from stale DOM node references, requestAnimationFrame and other enhancements to the page lifecycle, CSP headers and related HTML attribute changes, and well, the list doesn’t end. ;-) For accessibility there’s the inert attribute that prevents focus to child content which is great if you need more flexibility than the dialog element provides by default but don’t want to get into setting tabindex manually or controlling all focus with JS, etc.
hiccuphippo 7y ago
The Web Authentication standard [0] seems super useful and something we really need in the web. [0] https://developer.mozilla.org/en-US/docs/Web/API/Web_Authentication_API https://developer.mozilla.org/en-US/docs/Web/API/Web_Authent...
- lucideer 7y ago
  Yeah, this is pretty great. It's also comes from the W3C, not the WHATWG. (it might be a bit lost in the hierarchy of the thread by now, but the original comment was about the WHATWG taking over and monopolising the normal considered and democratic standardisation process of the W3C with their HTML5 "living" spec.)
  - tialaramex 7y ago
    W3C was a good fit for WebAuthn because the W3C is a body for corporations and by its nature WebAuthn is built and primarily implemented by corporations. Not a criticism, by the way, sometimes that's just the right fit.
    - wahern 7y ago
      Huh? The WHATWG steering committee is Apple, Mozilla, Google, and Microsoft. WHATWG's legitimacy (such as it is) doesn't come from being non-corporate, it comes from being entirely controlled by the top corporate browser vendors and thus reflecting the de facto state of affairs regarding how and when and why features are defined and implemented. If the WHATWG disappeared nothing would change because the top vendors are going to pick & choose W3C standards, anyhow.
      - tialaramex 7y ago
        Sorry, I was thinking out loud, I was contrasting the other obvious place to standardise this - the distinctly non-corporate IETF. WHATWG makes no sense for something like WebAuthn

CM30 7y ago

This times a million. And for anyone who needs some bona fide examples of new standards and updates that are useful from the WHATWG specifications, well how about: New semantic elements like header, footer, section, article, nav, aside, main, etc. These are far better for making logically structured pages than a ton of divs with class names would be. The various new input types and attributes. Now you can have input fields which validate email addresses and phone numbers, present the right keyboard for the type of input you want, do various other validation checks or even provide things like a nifty date picker without JavaScript. Picture and srcset too. No more having to load giant images on mobile devices or have blurry ones on devices with retina support, you can choose which image displays on which type of device. The preload attribute and what not. Being able to load content the user will likely need in the background is helpful. The built in video and audio elements, obviously. Again, object was a terrible solution for this, which was unsemantic, was awkward to use and struggled in certain browsers. These elements don't. The canvas tag and things you can do with it. And this will be a controversial one, but... most of the old elements that were made official by 'paving the cowpaths' were nice to see added too. The whole fiasco involving embed/object in the old days and how supporting multiple browsers meant invalid HTML was a bit of a farce really, especially as neither were particularly 'semantic' to begin with. Seeing them both made official and better alternatives provided just puts a lifelong issue at rest.

clairity 7y ago
if only all of those things were fully flushed out in the various browsers... for instance, it disheartening to realize that it's been 15 years already and useful form elements like date(-time), phone, and email still don't have reliable and complete cross-browser behaviors, validation (i know it's hard, but still), and styling/event hooks.
- CM30 7y ago
  True, support still isn't perfect. The calendar/date picker stuff is especially annoying here, since it really should be easier to customise and more similar cross browser than it currently is. But most of the things mentioned do work in more browsers than not, and you can use them without worrying the site will break in almost all cases. The new semantic elements will never have issues (unless you're trying to target IE8 or below), the validation works fine in pretty much all modern browsers (as do simple styles for it) and support for the picture element and srcset are pretty good too. The likelihood of anyone using the Blackberry browser or IE mobile is small enough to ignore.