25 ms·

Canistilluse.com

555 points by sjs382 5y ago

styfle 5y ago
Parody aside, we actually need something like this. Here’s a non-exhaustive list of breaking changes to the web platform: https://github.com/styfle/breaking-changes-web https://github.com/styfle/breaking-changes-web
- buu700 5y ago
  I'd add HTTP Public Key Pinning (HPKP) to the list. I was burned by that one.
  - AnonHP 5y ago
    Could you elaborate more? I’ve seen advice that it’s not recommended (and not been recommended for some years), but I’ve also seen questions in recent times by app developers who are bent on using it to “increase the security” (as it relates to where the apps want to connect to securely without any interception/modification).
    - freeone3000 5y ago
      HPKP locks you into one public key forever, so you can't ever rotate private keys for your website. (You can rotate the cert, but this isn't the same.) Heartbleed was one time where your keys would be leaked and you'd have to rotate, but even normal business processes prefer key rotation (and heaven forfend you ever lose it!). Too much burden for too little gain.
      - rossy 5y ago
        No, HPKP didn't lock you into one public key forever. You could rotate keys. The HPKP header had an expiry date and let you specify multiple keys, so you could add a new key to the list and switch over when the previous key expired.
      - smnrchrds 5y ago
        Plus, I think it can make a domain unusable forever. You can end up buying a domain you cannot use because the previous owner had used HPKP.
      - toast0 5y ago
        It makes sense to use HPKP to pin to a CA (maybe a CA's intermediate, I can't remember what they let you do) or better, multiple. Depending on your expiration, and what terrible thing happens in the PKI universe, you should probably be able to resolve an issue if you've got multiple independent CAs pinned.
    - buu700 5y ago
      Sure, I'll just defer to an older comment on this: https://news.ycombinator.com/item?id=17779395 https://news.ycombinator.com/item?id=17779395 --- 8 points by buu700 on Aug 17, 2018 | parent | favorite | on: OpenPGPjs has passed an independent security audit We (Cyph) have been pretty disappointed in the Chrome team's decision to kill HPKP. Paraphrasing, but IIRC the reasoning pretty much boiled down to "it's a pain to maintain and Expect-CT is kind of similar anyway" — which I think is a really weak justification for harming end user security and breaking established APIs that people depend on in production. Fingers crossed that Firefox keeps it alive! [Narrator: They didn't.] That said, it doesn't entirely break WebSign in Chrome, just weakens a bit further below strict TOFU. https://www.cyph.com/websign https://www.cyph.com/websign goes into detail, but WebSign has some client-side logic to validate its own hash against a signed whitelist. The major downsides to relying on this are: 1. It depends on a caching layer, not a security feature. This means that any guarantees are potentially out the window if a browser vendor decides to do something crazy for performance reasons or whatever. 2. It opens up an attack vector where it can be forcibly unpinned by filling up the user's disk and making the browser evict the cached WebSign instance. All in all I think it's still basically fine, but shipping an optional browser extension for hardening WebSign is now a higher priority because of this.
      - bawolff 5y ago
        Hmm, https://www.cyph.com/websign-architecture https://www.cyph.com/websign-architecture the hkpk suicide bit is a beautiful hack, but is so far removed from the motivating purpose of hpkp, that i dont think you can really blame web browsers for not caring. Although i guess im kind of surprised that worked. I'd assume that service workers could fall out of cache before hkpk at random, and then your app would just be bricked (?) Seems like a bad failure case that could just happen without anything makicious going on, but maybe i just dont understand how service workers work well enough.
        buu700 5y ago
        Ah yeah, 100% agreed. I think it was a cool concept, but if we're being fair we were practically exploiting a vulnerability in HPKP to produce unintended behavior. (On that note, one of the HPKP Suicide demos we presented at Black Hat and DEF CON was actually a ransomware concept.) I'd assume that service workers could fall out of cache before hkpk at random, and then your app would just be bricked Well... that did actually happen on occasion, although IIRC it was considered to be an edge case browser bug in the ServiceWorker and/or Persistent Storage implementations rather than expected behavior, since the locally installed worker shouldn't have been wiped before its replacement had been successfully fetched. We had to set up a support page with instructions to unpin the keys through about:config / chrome://net-internals, which wasn't really ideal. (Both browsers did end up actually fixing this, not that it ultimately did us much good.)
- chrismorgan 5y ago
  > Forms with passwords marked Not Secure over HTTP It requires a rather curious definition of “breaking change” to consider this one. > A̶r̶r̶a̶y̶.̶p̶r̶o̶t̶o̶t̶y̶p̶e̶.̶f̶l̶a̶t̶t̶e̶n̶ ̶b̶r̶e̶a̶k̶s̶ ̶M̶o̶o̶T̶o̶o̶l̶s̶ renamed to Array.prototype.flat That doesn’t belong in the list at all; it’s a prime example of the platform bending over backwards to avoid a breaking change, for better or for worse (it means that future users are stuck with an inferior name, see also contains which got renamed to includes because of, if I recall correctly, MooTools again).
  - electroly 5y ago
    If I'm interpreting the list right, I think they agree with you about flatten. I think the strikeout is supposed to indicate that the struck portion would have made the list, but they took corrective action. I spelunked through the commit history and the struck portion was indeed unstruck originally, and then when the situation was resolved they crossed it out and added the description afterwards.
- kristopolous 5y ago
  Take the word "deprecated" with a grain of salt. I've got a project that utilizes an HTML tag deprecated in 1993! https://github.com/kristopolous/TopLevel https://github.com/kristopolous/TopLevel It's <plaintext> which basically means "stop parsing for rest of the page". There's no way to close the tag. It's super easy to implement which is probably why it's still around. Deprecated 28 years ago in HTML 1.1, yet still supported in all major browsers. Test page over here: http://9ol.es/TopLevel/example.html http://9ol.es/TopLevel/example.html reference rendering: http://9ol.es/tl.png http://9ol.es/tl.png There's some modern timing issue in chrome I think, it's intermittent Looks like there's a bug. My original post on the hack, blowing off the cyber dust from 2014: https://news.ycombinator.com/item?id=7850301 https://news.ycombinator.com/item?id=7850301
  - adzm 5y ago
    This is a crazy hack! I'm amazed it works.
    - kristopolous 5y ago
      appears to actually be flaky these days. I'll have to get back to it and figure it out. There's something subtle going on on mobile chrome. Things are being done differently. The image appears to get pre-fetched even though technically, according to the old-school <script> blocking rule, it shouldn't. I'll have to check the blink source whenever I have some free time. There's probably a strange way around it (for instance, maybe convincing the browser it's a really old website and it reverts to the traditional policy for compatibility or perhaps maybe there's another strange old feature I can leverage, I dunno I'll have to check). And yes, I know this is just pure theater and it's completely useless, I still want to do it well!
  - Sohcahtoa82 5y ago
    That'll be a fun tag to use the next time I find an XSS vulnerability.
    - kristopolous 5y ago
userbinator 5y ago
Personally, I think the web/browsers has churned far too much, and if that stopped happening, perhaps we would get more accessible sites and browser diversity as people "stop looking for new dogs and start teaching new tricks to the old ones." Of course, Google would try its hardest to never let that happen, since change is its weapon of monopoly. Related: Stop Pushing the Web Forward (2015) https://news.ycombinator.com/item?id=9961613 https://news.ycombinator.com/item?id=9961613
- rapind 5y ago
  It would be great to slow down on features and focus on securing the platform (browser) so it didn’t leak like a sieve.
  - judge2020 5y ago
    All the problems with security seem to come from JavaScript exploits intrinsic to the engine, not any of the new features (misty because the new features are strictly typed and have the power of hindsight with modern design principles), so it’s not like new features are strictly an antigen to security.
    - thefr0g 5y ago
      > All the problems with security seem to come from JavaScript exploits intrinsic to the engine Yes the classic memory-related bugs come from the engine, but the comment explicitely mentioned leaks and I don't think that was about the memory ones. Many of the new "features" turned out to leak sensitive or at least identification-enabling information. Imo having remote code execution without a big red warning that this is stupid and you should not do it that users can't click away without being forced to think about it just isn't a good idea, even if it is sandboxed. At the very least we should have a permission-based system where users need to authorize every single Javascript API, for every single connection/file/database/whatever and be unable to ignore it without disabling the APIs. That would imo be the best compromise since web-devs would be forced to think about what they are doing to users computers¹ while still allowing applications to be built. ¹ My hope being that they wouldn't include [bullshit fontend framework] except when absolutely necessary
noobermin 5y ago
Web developers should be angry that their craft has so much churn and leads to works that end up being ephemeral in nature. That people in the field exalt this state is upsetting because this state is bad for both users and developers.
- dannyw 5y ago
  Some web developers might get a decent amount of their income from maintenance.
- bawolff 5y ago
  Idk, i remember having to support IE6. That was not fun. Some churn is good.
- pengwing 5y ago
  Dear Mr. Client, a whole year has passed, the web app we developed for you is obsolete. Paying us a lot of money to develop a new version appears to be the only option.
  - xyzzyx 5y ago
    Dear Mr. User, a whole year has passed, in order to keep up with the latest trends we now require you to give permission for mining your user data via our new microservice every time you enter our site, we have made sure the experience will be a pleasant one, as we added 5 mb of JS and a full screen video to keep your browser occupied as we process your requests. Be aware that nothing substantial has changed, only the UI has again changed for no apparent reason, the site is now once again trice as large and hangs twice as much on previous generation mobile devices. Dear Mr. Software Developer, as you might know all useful software now runs on the web. Writing a web browser is no small task, this is why at Google and W3C we pride ourself in growing our spec beyond any reasonable proportions to make sure you don't try to create a competitor to render a simple HTML5 page. After all, why would you?
- AgentME 5y ago
  ... The article is about a single bit of potential churn that was significant because it was so unusual for the web to have churn in standardized features, and regardless the churn didn't end up happening. The web seems like a success story as far as backwards-compatibility goes.
xpressvideoz 5y ago
Wow, it is shocking to me that `substr` was depreciated. Searching for it, the function was not part of the standard in the first place.
- deleted 5y ago
  [deleted]
- masswerk 5y ago
  `substr()` is in Core JavaScript 1.2 (pre-ECMA standard), [del]introduced with Netscape Navigator 3.0, which was officially launched in Dec. 1996.[/del] Edit/correction: Core JS 1.2 was Netscape Communicator 4.0, which was in beta in 1996 and launched in June 1997! (The 4.0x series was still pre-ECMA, as opposed to the 4.x series.)
- andrey-p 5y ago
  Yeah that one caught me off guard too. Any idea why? The only reason I can think of is that it's very easy to confuse with `substring`.
qnxub 5y ago
Back in 2014, I built some very flashy interfaces using Polymer components just for fun. Fast forward to 2021, and these pages are completely broken. They don't even display the text that I wrote. I'm guessing that the depreciation of HTML imports is why they don't work anymore.
- chrismorgan 5y ago
  It was depending on Web Components v0 stuff that was enabled in Chrome before it was ready. You may find that the component does still work in Firefox (which never implemented the stuff that Chrome eventually removed, and for which Polymer included polyfills). Also, my hobby horse: HTML imports were removed, not just deprecated (or depreciated). Two (three!) very different things.
  - quickthrower2 5y ago
    Decimated?
    - chrismorgan 5y ago
      … and that word alone means two very different things because of incorrect metaphorical usage! (Its original sense, now rare, was killing one tenth of a group of people, and so metaphorically the destruction of a tenth of something; the typical meaning now refers to a much more drastic reduction than ⅒, very commonly almost complete.)
- spankalee 5y ago
  If the pages worked in Safari and Firefox then they would still work in Chrome now. The only pages that would have broken are those that didn't load the polyfills at all. It was a bad situation which I hope is never repeated.
pjmlp 5y ago
From humble point of view HTML 4 was just fine for the purposes of the Web, and everything else should be done via native applications and network protocols. Google, alongside all of those that push Chrome wrapped in whatever kind of package, have managed to turn the Web into ChromeOS. I expect job adverts for HTML 6 to be about years of experience developing ChromeOS applications.
- esrauch 5y ago
  I disagree at least about the part about native applications. It really is better to have this universal VM for ephemeral apps and not have to worry about if the thing supports Linux or if it's actually spyware or how much hard drive space is this thing going to take up. Recent things like Zoom native app being incredibly insecure but the same company's webapp being much better kind of proves the point.
  - pjmlp 5y ago
    All Web applications are spyware and security is not given, hence OWASP.
    - esrauch 5y ago
      Surely there's things that can be better with webapp model, but .exe or .msi are so drastically worse on the spyware front that it's not even close.
      - pjmlp 5y ago
        Every single HTTP request done by you is tracked down on the server, every single one!
        aidenn0 5y ago
        Plenty of native apps phone home (and won't work if they can't)
qiqitori 5y ago
Erm, alert() is being deprecated? Don't like half the "JavaScript for beginners" books use alert() for the first few "Hello World"-type programs?
- gkoberger 5y ago
  It's not! Just being able to trigger alert from an iFrame that is being reconsidered.
  - q-rews 5y ago
    > being able to trigger alert from an iFrame that is being singlehandedly removed by the Chrome team. Fixed that for you. It’s not being reconsidered; The Chrome team makes decisions for the web whether you agree with them or not. They might pull the “proposal” only to just do it again later. [1] More context on the same blog [2] 1: https://www.quirksmode.org/blog/archives/2017/09/chrome_breaks_v.html https://www.quirksmode.org/blog/archives/2017/09/chrome_brea... 2: https://www.quirksmode.org/blog/archives/2021/08/breaking_the_we.html https://www.quirksmode.org/blog/archives/2021/08/breaking_th...
    - bokan 5y ago
      Disclaimer: I'm the one who made the change in [1] so I'm biased but... IMHO the argument on the blog mischaracterizes the situation - Chrome didn't break these properties but changed how they're interpreted under pinch-zoom. This was done precisely to keep backwards compatibility (on desktop browsers): at the time, the vast majority of pages assumed pinch-zoom can't happen on desktop (something that was becoming more common). The status quo meant zooming in on a desktop page would cause it to "swim" as various "fixed" elements shifted around, JS drop-down menus appeared in the wrong place, etc. This happened virtually everywhere one looked: facebook, twitter, apple.com, etc. The blog basically argues for "make pages fix themselves" which, even if major sites do, is unrealistic in the long tail. > They might pull the “proposal” only to just do it again later It's not nefarious, this often happens in response to feedback and real world experience to try and minimize disruption. In this case, developers convincingly argued that there should be an API to better react to pinch-zoom before making the change.
javajosh 5y ago
Why do people think that the universality of decay can be stopped? I would even question the assumption that it should be stopped. On a long enough timeline, the survival rate of all APIs goes to zero. (Except Lisp, which is Eternal).
- quickthrower2 5y ago
  Lambda calculus API is eternal. There are multiple LISPs, so multiple APIs, changing over time.
  - deleted 5y ago
    [deleted]
- dannyw 5y ago
  One of the great things about the web is the fact that I can expect anything I create today, to be relatively forwards compatible, and I can build things in a way so they're either backwards compatible or degrade gracefully. The philosophies around entropy isn't really relevant here IMO. The web should continue to be evergreen.
  - DrSiemer 5y ago
    Supporting legacy constructs forever can be hugely detrimental to progress though. Something completely new would fasttrack innovation. It could leave out all the quirky workarounds and get advanced features built in or easily extensible. When adoption is high enough it could include a legacy box, to run good old HTML based content. Have any attempts at this sort of thing ever been made?
    - mod50ack 5y ago
      I don't think this is really a good idea. HTTP and HTML aren't perfect, but they've been made into ubiquitous standards already used by everyone. In order to switch to a new standard, you'd need to have a pretty convincing way in which it was better. And I don't think you can ultimately outbalance what we have now. Not to mention that the only way this could probably actually happen would be through Google doing it, which would be disastrous for the open nature of the standards.
tmwed 5y ago
unless i haven’t read deep enough into that groups thread. this seems overblown. alert, prompt, etc. isn’t being deprecated on the entire web, only in the context of cross-origin iframes. that being said, this post definitely strikes a chord with me. instead of adding a new index of deprecated features, it think it speaks more to the fact that caniuse needs to rethink how they approach deprecated features.
- alessioalex 5y ago
  No, they will be deprecated. The decision has been made: https://news.ycombinator.com/item?id=28310716 https://news.ycombinator.com/item?id=28310716
gkoberger 5y ago
Just a quick note, alert/prompt/etc are NOT in danger of being deprecated. Chrome is just considering not allowing them to be triggered from iFrames for security reasons.
- chrismorgan 5y ago
  No, blocking them from iframes is just the first step. alert/confirm/prompt are absolutely in danger of being deprecated and eventually removed. Browser makers have declared they’d like to remove them altogether: https://github.com/whatwg/html/issues/2894 https://github.com/whatwg/html/issues/2894. But they’re too popular to remove under current policies unless they’re really causing harm, and I do believe there’s serious risk of them classifying it that way. (They’re actually a bit of a maintenance burden, as three of the few remaining synchronous things.) Remember also the big difference between deprecation and removal. I’d go so far as to say I think it’s likely that alert/prompt/confirm will be deprecated and produce console warnings in at least one major browser before four years pass, though I don’t believe they’ll yet have justified going ahead and removing it.
  - gkoberger 5y ago
    Your link says the exact opposite of everything you wrote. The post is by a random dev who doesn't work at a browser, and it was closed by someone who does after they said they don't deprecate things unless they plan on removing them.
    - chrismorgan 5y ago
      It’s definitely not the best source—the best sources are scattered about the place and probably more just murmurings than clear statements of intent—but it does include one positive signal from browser and spec makers, annevk on the reason for reopening it: > I figured it deserved some more implementer input especially since there seems to be interest in removing them eventually It’s not spelled out clearly, but I believe from what I’ve seen of processes there and from what I’ve read elsewhere that he’s talking about implementer interest rather than just-anyone interest. Consider also how Chromium actively gathered usage statistics and Firefox wants to, which you only do if you want to remove the thing. They definitely want to remove it altogether, they just don’t reckon it’s feasible at this time, and it’s definitely not a high priority for them. There are other sources, most likely to be found in previous discussions on HN of this rough topic, but regular search for this stuff is just about impossible now because it’s been drowned by stuff pertaining to the block in cross-origin subframes. (bryik and anonydsfsfs have now found better citations, refer to their comments.)
ianlevesque 5y ago
It's already happening, with consequences. Remember Manifest V3 nerfing all the webextension APIs used by ad blockers?
- ximm 5y ago
  Last time I heard this only affected chrome. So if you want ad blocking, just use a different browser. Kinda obvious that the browser you get from the ad company for free is not for you if you do not like ads.
shp0ngle 5y ago
Chrome does not disable alert(). Alert() will still work, just not from cross-origin iframes.
- alessioalex 5y ago
  No, they will be deprecated. The decision has been made: https://news.ycombinator.com/item?id=28310716 https://news.ycombinator.com/item?id=28310716
  - shp0ngle 5y ago
    I don't consider some random Twitter thread an official messaging. Also the thread itself talks just about iframe alerts.
vmception 5y ago
my biggest chuckle is that he probably spent the most time trying to figure out how to center the div on his new parody site
- chrismorgan 5y ago
  Nah, `body { max-width: 400px; margin: 0 auto }` is the usual way of capping page width and centring it.
andrewmcwatters 5y ago
I author a CSS 2.1 rasterizer, and a partial implementation of it is used in a game engine my company's open source organization publishes. There's such a small number of people who have written their own pieces of visual web client technology, and an uncountable number who consume it. I've entertained the idea of writing a partially compliant web browser and releasing that for fun. It's still totally possible to write your own web browser today. You will of course need to put in effort than an exceptionally small number of people have, and even after you do that, you'll only have something partially compliant. But it will be valid! Hell, you could build an HTML5 valid web browser that didn't even use CSS. Invent your own thing. Make JSON style sheets or something. Anyway. We don't have enough people toying around with web tech. For years, I've only ever seen people toy around with the easy. Things like making little web clients to help you with API requests instead of turning to curl, or rehashing a CSS framework for the nth time. And frankly it's sad to see because its so uninspired and boring. Where are the people creating basic web browsers that use C# as a programming language instead of JavaScript? Or people inventing a new hypertext markup language as an alternative to HTML that still uses HTTP as a transport protocol?
- pjmlp 5y ago
  WPF and WinUI.
- zamadatix 5y ago
  SerenityOS probably has the most serious attempt I've seen at "Let's make our own web browser for the sake of it" (along with the rest of the OS). I think they are still working towards Acid 2 compliance but they also have a spattering of newer features supported as they hack at getting newer sites to work. Not a very whacky take though just a home grown one. http://serenityos.org/ http://serenityos.org/
teewuane 5y ago
Wait, why are alert, prompt, and confirm being deprecated? So we are going to need to write poly fills for old features?
- vanviegen 5y ago
  These functions are blocking, so they can't be polyfilled.
  - Dylan16807 5y ago
    Yet another reason it's bad for asynchronous functions to be a separate type from normal functions.
    - Thorrez 5y ago
      What do you mean? Do you think all functions should be asynchronous? Do you think no functions should be asynchronous?
      - int_19h 5y ago
        Ideally, all functions should be async-transparent. That is, it should be up to the caller to decide how to invoke it. This is usually done with some form of green threading. It all works great, right up until the moment you have to interop with another language/runtime that doesn't understand your bespoke async. Callbacks (and layers over them such as tasks/promises) are uglier and necessitate opt-in async, but you can interop them to anything that speaks the C ABI.
        Thorrez 5y ago
        Green threading is multithreading right? Isn't Javascript singlethreaded? I would assume adding multithreading would break tons of code that relies on it running singlethreaded.
        5y ago
yummybear 5y ago
I wonder - with all the limitations being imposed on IFRAMEs, what do people do when they have a product that needs to integrate UI with other peoples websites?
- onion2k 5y ago
  They use an iFrame, with the correct headers to enable what they need. If the site isn't trying to do something nefarious it'll work perfectly well.
- ximm 5y ago
  Put some JS on the host and use postMessage()
LAC-Tech 5y ago
Oh man HTML imports looked sweet. why was that deprecated?
- dmitriid 5y ago
  IIRC it was going to conflict with JavaScript imports. So now they are going all in on Javascript. See, e.g. CSS Modules: https://github.com/css-modules/css-modules https://github.com/css-modules/css-modules
osener 5y ago
Another example of this is SharedWorker. Here it is in the standard: https://html.spec.whatwg.org/multipage/workers.html#dom-sharedworker-dev https://html.spec.whatwg.org/multipage/workers.html#dom-shar... Safari/Webkit removed it in 2015 (edit: maybe even earlier!) and never reintroduced it: https://caniuse.com/sharedworkers https://caniuse.com/sharedworkers Here is the apparent reason for cherry picking features: > The implementation of Shared Web Workers was imposing undesirable constraints on the engine. It never gained any adoption. https://stackoverflow.com/a/48193804 https://stackoverflow.com/a/48193804 Edit: Here is the ticket for it’s reinclusion https://bugs.webkit.org/show_bug.cgi?id=149850 https://bugs.webkit.org/show_bug.cgi?id=149850 Turns out it was removed temporarily because of internal architecture changes, and never reintroduced because of lack of adoption. Of course the biggest barrier of adoption is Safari not supporting them, so talk about a self fulfilling prophecy. > This feature was originally removed temporarily during multiprocess bring-up, and actual usage on the web has been pretty low. We're willing to reconsider if there is significant demand.
- gsnedders 5y ago
  IIRC, it was only even available through WebKit1 (i.e., the single-process WebKit API) and never through WebKit2, so it will have gone from Safari when Safari moved to WebKit2, even though the implementation lived on in WebKit for longer. It was only 4+ years after it was dropped from Safari that anyone started to ask about Safari support for it again, so it had kinda fallen to the wayside due to lack of interest.
LeoPanthera 5y ago
HN loves to bitch about whatever Safari doesn’t support at the moment but I use Safari as my platonic ideal web browser. It’s the only one that is directly designed for users and not web devs, and the only one that has a simple “buy our hardware and get Safari” business model. I am automatically suspicious of web techs not supported by Safari.
- markmark 5y ago
  It's also the one made by the company that doesn't want web apps to compete against their app store monopoly.
- zamadatix 5y ago
  The bitching of lack of a lot of the features for web devs doesn't come from it being built for users instead of the devs rather it comes from Safari being built to not compete with the AppStore on iOS where they get a 30% cut of all transactions vs the 0% on the web.
severak_cz 5y ago
Why nobody mentioned window.open? It's not deprecated but there are popup blockers everywhere. This still makes problem with old apps.
- zamadatix 5y ago
  Popup blockers are user controlled, feature removals are not.
kccqzy 5y ago
Quick, add WebSQL to the list.
Doctor_Fegg 5y ago
E4X is another one: supported by Firefox way back when, but it never made it into any other browsers and FF eventually removed it. https://en.m.wikipedia.org/wiki/ECMAScript_for_XML https://en.m.wikipedia.org/wiki/ECMAScript_for_XML
one_comment 5y ago
> Note how browser support was short-lived. The author could have used the date relative view. 8 years (implemented in all major browsers 2012, deprecated in 2020) is not short-lived in my book.
jan_Inkepa 5y ago
Caniuse, rather infuriatingly, used to deliberately not track usability of obsolete/deprecated web stuff (it would just say something like "Feature X is obsolete, don't use it" instead of the browser support graph), but it seems to have changed course https://caniuse.com/?search=blink https://caniuse.com/?search=blink thanks, caniuse!
bugmen0t 5y ago
Have you heard of https://deprecate.it/ https://deprecate.it/? :)
captainmuon 5y ago
At some point, I started making a similar thing for C++ (arewemodernyet). I didn't even include a provision for the case that features go away - I think I just stored for each compiler the minimum version a draft (Nxxxx) is implemented in. The thinking that "everything becomes green over time" is just so ingrained.
kybernetikos 5y ago
Things that have bitten me (combinations of actual breaks and things where it seemed that progress was happening in a particular direction and then it changed): * use of geolocation & crypto APIs on http hosts * websql * changes in how browsers provided accelerometer data * multipart/x-mixed-replace
brundolf 5y ago
Does deprecation of web APIs actually mean anything in terms of support though? Last I checked, frame sets have been deprecated for something like a decade, but they still work fine. It seems like deprecation on the web really just means "if you're new here, know that this is considered bad practice now and we're only listing it for completeness"
ag8 5y ago
Since it looks like Chromium is set on removing alert() altogether[0], I don't see why this can't be handled in the same way browsers handle popup windows. If a website tries to open a pop-up, it gets blocked; but, on Firefox at least, I get a small notification in the toolbar, where I can choose to copy the popup window's URL, open the popup, or allow the website to open popups as much as it wants. Why not do the same exact thing for alert()s? [0]: https://news.ycombinator.com/item?id=28310716 https://news.ycombinator.com/item?id=28310716
- SimeVidas 5y ago
  The problem is that alert() blocks JavaScript from executing. If a web page fires an alert, it expects to be blocked in that moment. If the browser were to delay the alert, the page would be blocked unexpectedly at some later time. This would probably cause bugs.
  - Orphis 5y ago
    The problem is that people relied on a side effect of a function that isn't guaranteed to block execution all the time (browsers are allowed to ignore those prompts) and now they have to fix their code.
    - capableweb 5y ago
      > The problem is that people relied on a side effect of a function that isn't guaranteed to block execution all the time Yes, this is a problem when people code their websites against current iterations of a browser. It's not a problem regarding Chrome removing window.alert() but rather a problem that happened at development of the site, not at the iteration of browser (which is being discussed here) > browsers are allowed to ignore those prompts Unless previously marked as "Block future popups", is there any browser that currently (by default) doesn't block JS execution upon window.alert()? AFAIK, all browsers currently do. > now they have to fix their code Yeah, good luck maintaining the web with that mindset. There are countless of websites that will basically vanish (rather, stop working) if you change the execution model of browsers too much. But large swaths of the web currently are just online because someone set it up well 20 years ago and has never touched it since. Maybe they can't even modify it at this point. So any change needs to consider the historical impact the change can have. Hopefully the people working on browsers and standards have a bit better mindset than "now they have to fix their code", because otherwise we're utterly screwed.
deleted 5y ago
[deleted]
city17 5y ago
Not sure what's wrong with some aspects of an API being deprecated over time. Of course if it's not done prudently and you can't rely on core features to work anymore after a short period of time then it starts to get annoying. But opposing any deprecation at all seems like the other extreme.
- deleted 5y ago
  [deleted]
- fleddr 5y ago
  It isn't extreme at all, it's the basic contract of the web. If something works today and is standardized, it should keep working forever. The main reason is the gigantic size of the web and the state most of the web is in. Unmaintained. There's no team to update anything, so you're purposefully breaking the web.
nkjoep 5y ago
dupe of https://news.ycombinator.com/item?id=28302420 https://news.ycombinator.com/item?id=28302420
wildpeaks 5y ago
A pragmatic way to catch deprecated features during development are Typescript intellisense and Webhint.
swiley 5y ago
All my HTML still works. Just don't go overboard with frameworks and Javascript.
- superkuh 5y ago
  Yep. If you think like this the best can I use x site is: http://caniuse.xyz/ http://caniuse.xyz/. You can try it out like, http://caniuse.xyz/css-grid http://caniuse.xyz/css-grid . I whipped it up and registered the domain on a whim in about 30 minutes.
  - zamadatix 5y ago
    > Get a new one not controlled by mega-corps and their invalid profit-motive PKI assumptions. The very browsers that pushed that change founded Let's Encrypt to provide free certificates prior to pushing sites towards HTTPS. That's the opposite of a profit motive. There are also more free alternatives like ZeroSSL since.
    - superkuh 5y ago
      That's a reasonable misunderstanding since the site is fairly terse. To be clear, what I mean is that forcing HTTPS-only is something that is required by profit motivated corporations. They see the potential risk of an HTTP downgrade attack as being enough motivation to completely kill HTTP. And unfortunately even Mozilla is going along with it. HTTP has it's place for human persons and human person run sites. It allows free communication without having to exist only on the whim of some CA or your mega-corp browser's decision if your cert is too long, too short, or too something. I did not mean that the founding of LetsEncrypt was profit motivated. LetsEncrypt is good for what it is. But forcing HTTPS and not allowing HTTP at all is very, very bad for the web. Especially since cert CA usage follows a powerlaw like normal and nearly everyone centralizes in LetsEncrypt.
sente 5y ago
I'm red/green colorblind and cannot for the life of me tell the boxes apart
- harg 5y ago
  There is a colourblind friendly colour option that you can enable in the site footer
- Liquidor 5y ago
  > I'm red/green colorblind and cannot for the life of me tell the boxes apart You can change the box colors at the bottom of the site :)
- a3w 5y ago
  The boxes have (weak) stripes. But screenshots of a webpage are missing all accessibility features, so links to the actual caniuse.com articles would be helpful. I don't understand how e.g. reddit allows text-as-images when that is discriminatory for people with eyesight issues.
  - vdqtp3 5y ago
    I don't understand how any website allows images when they are discriminatory for people with eyesight issues. /s
- dredmorbius 5y ago
  I'm on a B&W grayscale e-ink device ... and I feel your pain.
pornel 5y ago
Actually, it would be nice if we could retire old image formats. For example, if/when JPEG XL becomes universally supported, the WebP format will be entirely redundant (lower quality, worse compression, no progressive, and it's not even faster to decode) and AVIF could be retired too (comparable compression, but much slower, and much more bloated HEIF container). But currently browsers are Katamari Damacy balls endlessly accumulating more and more code. How long can we keep just adding without removing anything?
- dmd 5y ago
  I sure hope so, because they're absolutely not a waste of bytes. Unless you personally are planning on converting all existing use of those old codecs everywhere? What you're suggesting is an archivist's nightmare.
- zamadatix 5y ago
  Redundancy assumes that either the original still exists, the encoded copy was lossless, the original was JPEG (which can be losslessly upgraded to JPEG XL), or that the new lossless copy of the old lossy intermediate will outperform. In reality the vast majority of AVIF and WebP images are lossy without the original copy meaning such a change will either force worse overall efficiency to now be a lossless reproduction of a lossy image or generational loss each time a new format takes over. Not to mention the breakage and work effort during such change periods.
EamonnMR 5y ago
Alert was always annoying, but it was never as annoying as sites asking for notification permissions.
- lkbm 5y ago
  Alerts steal and block focus. A notification permission request doesn't keep me from scrolling the page, or clicking a link. If alerts were as common as notification permission requests, it would be absolutely infuriating. Disabling notification requests is a simple browser setting and I haven't even bothered with it. If alerts were as common as notification requests, I'd do whatever it took to disable them.
  - EamonnMR 5y ago
    I'm salty that they where ever implemented in the first place.
GnarfGnarf 5y ago
Is Vivaldi not worth tracking?
- zamadatix 5y ago
  Something less that 0.1% of users and the default cutoff is 0.5%.
EMM_386 5y ago
> All green boxes indicating support, with a note at the bottom: “this feature is deprecated/obsolete and should not be used”. CanIUse should just color these deprecated features in orange, meaning "it works but don't use it".
chadlavi 5y ago
Wait a minute the lede is truly buried here — Chrome is killing alert/confirm??? This will break tons of stuff. What's the recommended replacement?
- paulryanrogers 5y ago
  Only from iframes
dpweb 5y ago
That link about killing alert() refers to only cross-origin iframe use of alert.
fleddr 5y ago
We should also make caniusebutdoesitactuallywork This to refer to my annoyance of browser makers leaving incomplete implementations stagnant for years. As an example, the <dialog> element, a browser-native standardized spec as promising replacement for alert. Except that it doesn't work, it's inaccessible at its core. And nobody fixes it, it's just left in this broken state forever. <section>, the element that was supposed to cut up an HTML document into multiple outlines, hence making componentized SEO-optimized headings easy and better, do nothing at all. CSS columns, a simple and easy way to distribute text, were unusable for 8 years because Mozilla refused to fix their own small bug. Which pales compared to the extraordinary amount of Webkit bugs that are absolutely never ever fixed. Form controls, since the very invention of them, are terrible. It has cost the world billions, as worldwide every single developer and project has to reinvent some of them, often breaking basic accessibility in the process. I could go on, but I'll sum it up as the failure to address extremely common real world problems, and to just let broken buggy solutions linger. When you accept a standard and implement it, bloody finish the implementation. Fix bugs. Otherwise, what is the point? I'd call this hardening the web. There's no reason I can see why you can't harden it whilst also making progress on new features.
- dylan604 5y ago
  Fixing bugs vs adding new features doesn't bring in new users, so it doesn't get prioritized. And if as you say these bugs are in features that nobody uses, why bother? Nevermind nobody might be using them because of the bugs, but the PR buz over those features has already been had, so on to the next.
  - fleddr 5y ago
    Not sure I fully agree. The features we're talking about here are in the developer space, not the end-user space. When a browser maker implements a brand new web standard, I don't think the correlation with new end-users is that strong. It takes forever before any new standard is popularized and widely used. Check release notes of browsers, almost all features no user will ever directly experience.
hutzlibu 5y ago
About chromium on cross origin remove of alert and co.(link in article): "We haven’t engaged with other browser vendors regarding this change yet, but plan to submit a spec change proposal once the change is approved for Chrome." So chrome just changes it. And then officially applys for the spec change, so other browsers might follow - or not. I mean, why pretending at all, that you care about the spec, when you are fat monopolist?
- zamadatix 5y ago
  Eh, I don't like how much influence Chrom(e|ium) has but this is either missing information or intentionally misleading to paint a picture. This is how the spec process works: 1. You find out if you want to implement something 2. You find out if others want to implement something 3. You implement your something (for simple things in a testbed for complex things as an experimental change over multiple development versions) 4. You demonstrate the something works 5. You demonstrate others are intending to ship as well (For complex things you may have to wait until others are comfortable with their working implementations) 6. If you had a bad experience and many discussion points in 4/5 you go back to 4 and refine until you had a good experience and your spec is merged. You imply the Chromium authors went 1, 3, ship because you read about step 1 happening. In reality they consulted with Firefox and Safari prior to merging code into the codebase or simply lobbing a spec proposal over the fence. https://github.com/whatwg/html/pull/6297 https://github.com/whatwg/html/pull/6297
  - hutzlibu 5y ago
    Ok, all I know is, that the site in question, Canistilluse.com, has as the main information, that in the next version of chrome 95, "alert" can not be considered, as working as expected by the standard. For me, that comes a bit out of the blue - and seems to be a "making facts" attitude by chrome, not discussing things.
    - zamadatix 5y ago
      That colored squares from canistilluse.com are not not "all you know" considering your original quote was pulled from the same page I pulled the above Firefox/Safari signals+timeline and spec PR link from: https://groups.google.com/a/chromium.org/g/blink-dev/c/hTOXiBj3D6A/m/1Q0TjPwWAwAJ https://groups.google.com/a/chromium.org/g/blink-dev/c/hTOXi... Also canistilluse makes no claim about whether the deprecation matches standards or not. For reference the standards change was actually approved back in February, per the link in my above comment, so it is actually according to standards.
jacquesm 5y ago
The bigger problem is that the web itself is rotting away as we speak. Yes, browsers no longer supporting old API calls is a huge problem, for instance for archived content that at some point will simply stop working, a bit like a 78 RPM record. Good luck finding a player. All the Flash content and so much other work that is part of our digital record is no longer working (and I absolutely loathe Flash). So whether or not you can still use it today, the bigger question is will you be able to use that website 10 years or longer into the future? Because any book ever printed can still be read today (assuming you know the script and the language it was written in), I think the longevity of the web will top out at a couple of decades at best before the digital termites and worms will consume the devices that could have rendered the content you are interested in. Plain ascii text will likely live the longest, with markdown as a good second. Anything that executes will likely simply die.
iKnowKungFoo 5y ago
I don't know that anyone should be worried about supporting anything in MSIE 11 unless site analytics reflect a significant number of users with that browser version. I annually audit a company's access patterns to see which browsers and resolutions we need to worry about. This affects development, QA and support at the very least. For example, global patterns in the US alone reflect 0.64% and dropping as of July. https://gs.statcounter.com/browser-version-partially-combined-market-share/all/united-states-of-america/#monthly-202007-202107 https://gs.statcounter.com/browser-version-partially-combine...
xibalba 5y ago
> recently reached the threshold of (mostly) supported everywhere: the .webp file format. Why has google (via lighthouse and pagespeed insights) been pushing webp so hard if it has only recently gone majority green?
- magicalist 5y ago
  <picture> has been green for more than five years now and can trivially fall back to jpg if you still need to support IE11.
xg15 5y ago
I honestly don't understand what great feats of technical debt removal or code simplification browser devs are hoping for after removing alert() etc. JS engines will still need the ability to stop-the-world, unless they want to get rid of breakpoints next. I'm also of the opinion that chrome devs should first try to write a "javascript for absolute beginners" tutorial before giving sage advice what such a tutorial should teach and what it shouldn't. ... though I can sort of understand the viewpoint. From a browser developer's PoV, you could probably never be too early in teaching about the event loop, promises, callbacks and async/await. Except that this seems at odds with how programming and JS is actually learned by users. This reminds me a bit of the Java language design, where you're in theory supposed to understand classes, objects and static methods before you can even write a "hello world" program.

555 points by sjs382 5y ago

Parody aside, we actually need something like this. Here’s a non-exhaustive list of breaking changes to the web platform: https://github.com/styfle/breaking-changes-web https://github.com/styfle/breaking-changes-web

buu700 5y ago
I'd add HTTP Public Key Pinning (HPKP) to the list. I was burned by that one.
- AnonHP 5y ago
  Could you elaborate more? I’ve seen advice that it’s not recommended (and not been recommended for some years), but I’ve also seen questions in recent times by app developers who are bent on using it to “increase the security” (as it relates to where the apps want to connect to securely without any interception/modification).
  - freeone3000 5y ago
    HPKP locks you into one public key forever, so you can't ever rotate private keys for your website. (You can rotate the cert, but this isn't the same.) Heartbleed was one time where your keys would be leaked and you'd have to rotate, but even normal business processes prefer key rotation (and heaven forfend you ever lose it!). Too much burden for too little gain.
    - rossy 5y ago
      No, HPKP didn't lock you into one public key forever. You could rotate keys. The HPKP header had an expiry date and let you specify multiple keys, so you could add a new key to the list and switch over when the previous key expired.
    - smnrchrds 5y ago
      Plus, I think it can make a domain unusable forever. You can end up buying a domain you cannot use because the previous owner had used HPKP.
    - toast0 5y ago
      It makes sense to use HPKP to pin to a CA (maybe a CA's intermediate, I can't remember what they let you do) or better, multiple. Depending on your expiration, and what terrible thing happens in the PKI universe, you should probably be able to resolve an issue if you've got multiple independent CAs pinned.
  - buu700 5y ago
    Sure, I'll just defer to an older comment on this: https://news.ycombinator.com/item?id=17779395 https://news.ycombinator.com/item?id=17779395 --- 8 points by buu700 on Aug 17, 2018 | parent | favorite | on: OpenPGPjs has passed an independent security audit We (Cyph) have been pretty disappointed in the Chrome team's decision to kill HPKP. Paraphrasing, but IIRC the reasoning pretty much boiled down to "it's a pain to maintain and Expect-CT is kind of similar anyway" — which I think is a really weak justification for harming end user security and breaking established APIs that people depend on in production. Fingers crossed that Firefox keeps it alive! [Narrator: They didn't.] That said, it doesn't entirely break WebSign in Chrome, just weakens a bit further below strict TOFU. https://www.cyph.com/websign https://www.cyph.com/websign goes into detail, but WebSign has some client-side logic to validate its own hash against a signed whitelist. The major downsides to relying on this are: 1. It depends on a caching layer, not a security feature. This means that any guarantees are potentially out the window if a browser vendor decides to do something crazy for performance reasons or whatever. 2. It opens up an attack vector where it can be forcibly unpinned by filling up the user's disk and making the browser evict the cached WebSign instance. All in all I think it's still basically fine, but shipping an optional browser extension for hardening WebSign is now a higher priority because of this.
    - bawolff 5y ago
      Hmm, https://www.cyph.com/websign-architecture https://www.cyph.com/websign-architecture the hkpk suicide bit is a beautiful hack, but is so far removed from the motivating purpose of hpkp, that i dont think you can really blame web browsers for not caring. Although i guess im kind of surprised that worked. I'd assume that service workers could fall out of cache before hkpk at random, and then your app would just be bricked (?) Seems like a bad failure case that could just happen without anything makicious going on, but maybe i just dont understand how service workers work well enough.
      - buu700 5y ago
        Ah yeah, 100% agreed. I think it was a cool concept, but if we're being fair we were practically exploiting a vulnerability in HPKP to produce unintended behavior. (On that note, one of the HPKP Suicide demos we presented at Black Hat and DEF CON was actually a ransomware concept.) I'd assume that service workers could fall out of cache before hkpk at random, and then your app would just be bricked Well... that did actually happen on occasion, although IIRC it was considered to be an edge case browser bug in the ServiceWorker and/or Persistent Storage implementations rather than expected behavior, since the locally installed worker shouldn't have been wiped before its replacement had been successfully fetched. We had to set up a support page with instructions to unpin the keys through about:config / chrome://net-internals, which wasn't really ideal. (Both browsers did end up actually fixing this, not that it ultimately did us much good.)
chrismorgan 5y ago
> Forms with passwords marked Not Secure over HTTP It requires a rather curious definition of “breaking change” to consider this one. > A̶r̶r̶a̶y̶.̶p̶r̶o̶t̶o̶t̶y̶p̶e̶.̶f̶l̶a̶t̶t̶e̶n̶ ̶b̶r̶e̶a̶k̶s̶ ̶M̶o̶o̶T̶o̶o̶l̶s̶ renamed to Array.prototype.flat That doesn’t belong in the list at all; it’s a prime example of the platform bending over backwards to avoid a breaking change, for better or for worse (it means that future users are stuck with an inferior name, see also contains which got renamed to includes because of, if I recall correctly, MooTools again).
- electroly 5y ago
  If I'm interpreting the list right, I think they agree with you about flatten. I think the strikeout is supposed to indicate that the struck portion would have made the list, but they took corrective action. I spelunked through the commit history and the struck portion was indeed unstruck originally, and then when the situation was resolved they crossed it out and added the description afterwards.
kristopolous 5y ago
Take the word "deprecated" with a grain of salt. I've got a project that utilizes an HTML tag deprecated in 1993! https://github.com/kristopolous/TopLevel https://github.com/kristopolous/TopLevel It's <plaintext> which basically means "stop parsing for rest of the page". There's no way to close the tag. It's super easy to implement which is probably why it's still around. Deprecated 28 years ago in HTML 1.1, yet still supported in all major browsers. Test page over here: http://9ol.es/TopLevel/example.html http://9ol.es/TopLevel/example.html reference rendering: http://9ol.es/tl.png http://9ol.es/tl.png There's some modern timing issue in chrome I think, it's intermittent Looks like there's a bug. My original post on the hack, blowing off the cyber dust from 2014: https://news.ycombinator.com/item?id=7850301 https://news.ycombinator.com/item?id=7850301
- adzm 5y ago
  This is a crazy hack! I'm amazed it works.
  - kristopolous 5y ago
    appears to actually be flaky these days. I'll have to get back to it and figure it out. There's something subtle going on on mobile chrome. Things are being done differently. The image appears to get pre-fetched even though technically, according to the old-school <script> blocking rule, it shouldn't. I'll have to check the blink source whenever I have some free time. There's probably a strange way around it (for instance, maybe convincing the browser it's a really old website and it reverts to the traditional policy for compatibility or perhaps maybe there's another strange old feature I can leverage, I dunno I'll have to check). And yes, I know this is just pure theater and it's completely useless, I still want to do it well!
- Sohcahtoa82 5y ago
  That'll be a fun tag to use the next time I find an XSS vulnerability.
  - kristopolous 5y ago

userbinator 5y ago

Personally, I think the web/browsers has churned far too much, and if that stopped happening, perhaps we would get more accessible sites and browser diversity as people "stop looking for new dogs and start teaching new tricks to the old ones." Of course, Google would try its hardest to never let that happen, since change is its weapon of monopoly. Related: Stop Pushing the Web Forward (2015) https://news.ycombinator.com/item?id=9961613 https://news.ycombinator.com/item?id=9961613

rapind 5y ago
It would be great to slow down on features and focus on securing the platform (browser) so it didn’t leak like a sieve.
- judge2020 5y ago
  All the problems with security seem to come from JavaScript exploits intrinsic to the engine, not any of the new features (misty because the new features are strictly typed and have the power of hindsight with modern design principles), so it’s not like new features are strictly an antigen to security.
  - thefr0g 5y ago
    > All the problems with security seem to come from JavaScript exploits intrinsic to the engine Yes the classic memory-related bugs come from the engine, but the comment explicitely mentioned leaks and I don't think that was about the memory ones. Many of the new "features" turned out to leak sensitive or at least identification-enabling information. Imo having remote code execution without a big red warning that this is stupid and you should not do it that users can't click away without being forced to think about it just isn't a good idea, even if it is sandboxed. At the very least we should have a permission-based system where users need to authorize every single Javascript API, for every single connection/file/database/whatever and be unable to ignore it without disabling the APIs. That would imo be the best compromise since web-devs would be forced to think about what they are doing to users computers¹ while still allowing applications to be built. ¹ My hope being that they wouldn't include [bullshit fontend framework] except when absolutely necessary

noobermin 5y ago

Web developers should be angry that their craft has so much churn and leads to works that end up being ephemeral in nature. That people in the field exalt this state is upsetting because this state is bad for both users and developers.

dannyw 5y ago
Some web developers might get a decent amount of their income from maintenance.
bawolff 5y ago
Idk, i remember having to support IE6. That was not fun. Some churn is good.
pengwing 5y ago
Dear Mr. Client, a whole year has passed, the web app we developed for you is obsolete. Paying us a lot of money to develop a new version appears to be the only option.
- xyzzyx 5y ago
  Dear Mr. User, a whole year has passed, in order to keep up with the latest trends we now require you to give permission for mining your user data via our new microservice every time you enter our site, we have made sure the experience will be a pleasant one, as we added 5 mb of JS and a full screen video to keep your browser occupied as we process your requests. Be aware that nothing substantial has changed, only the UI has again changed for no apparent reason, the site is now once again trice as large and hangs twice as much on previous generation mobile devices. Dear Mr. Software Developer, as you might know all useful software now runs on the web. Writing a web browser is no small task, this is why at Google and W3C we pride ourself in growing our spec beyond any reasonable proportions to make sure you don't try to create a competitor to render a simple HTML5 page. After all, why would you?
AgentME 5y ago
... The article is about a single bit of potential churn that was significant because it was so unusual for the web to have churn in standardized features, and regardless the churn didn't end up happening. The web seems like a success story as far as backwards-compatibility goes.

xpressvideoz 5y ago

Wow, it is shocking to me that `substr` was depreciated. Searching for it, the function was not part of the standard in the first place.

deleted 5y ago
[deleted]
masswerk 5y ago
`substr()` is in Core JavaScript 1.2 (pre-ECMA standard), [del]introduced with Netscape Navigator 3.0, which was officially launched in Dec. 1996.[/del] Edit/correction: Core JS 1.2 was Netscape Communicator 4.0, which was in beta in 1996 and launched in June 1997! (The 4.0x series was still pre-ECMA, as opposed to the 4.x series.)
andrey-p 5y ago
Yeah that one caught me off guard too. Any idea why? The only reason I can think of is that it's very easy to confuse with `substring`.

qnxub 5y ago

Back in 2014, I built some very flashy interfaces using Polymer components just for fun. Fast forward to 2021, and these pages are completely broken. They don't even display the text that I wrote. I'm guessing that the depreciation of HTML imports is why they don't work anymore.

chrismorgan 5y ago
It was depending on Web Components v0 stuff that was enabled in Chrome before it was ready. You may find that the component does still work in Firefox (which never implemented the stuff that Chrome eventually removed, and for which Polymer included polyfills). Also, my hobby horse: HTML imports were removed, not just deprecated (or depreciated). Two (three!) very different things.
- quickthrower2 5y ago
  Decimated?
  - chrismorgan 5y ago
    … and that word alone means two very different things because of incorrect metaphorical usage! (Its original sense, now rare, was killing one tenth of a group of people, and so metaphorically the destruction of a tenth of something; the typical meaning now refers to a much more drastic reduction than ⅒, very commonly almost complete.)
spankalee 5y ago
If the pages worked in Safari and Firefox then they would still work in Chrome now. The only pages that would have broken are those that didn't load the polyfills at all. It was a bad situation which I hope is never repeated.

pjmlp 5y ago

From humble point of view HTML 4 was just fine for the purposes of the Web, and everything else should be done via native applications and network protocols. Google, alongside all of those that push Chrome wrapped in whatever kind of package, have managed to turn the Web into ChromeOS. I expect job adverts for HTML 6 to be about years of experience developing ChromeOS applications.

esrauch 5y ago
I disagree at least about the part about native applications. It really is better to have this universal VM for ephemeral apps and not have to worry about if the thing supports Linux or if it's actually spyware or how much hard drive space is this thing going to take up. Recent things like Zoom native app being incredibly insecure but the same company's webapp being much better kind of proves the point.
- pjmlp 5y ago
  All Web applications are spyware and security is not given, hence OWASP.
  - esrauch 5y ago
    Surely there's things that can be better with webapp model, but .exe or .msi are so drastically worse on the spyware front that it's not even close.
    - pjmlp 5y ago
      Every single HTTP request done by you is tracked down on the server, every single one!
      - aidenn0 5y ago
        Plenty of native apps phone home (and won't work if they can't)

qiqitori 5y ago

Erm, alert() is being deprecated? Don't like half the "JavaScript for beginners" books use alert() for the first few "Hello World"-type programs?

gkoberger 5y ago
It's not! Just being able to trigger alert from an iFrame that is being reconsidered.
- q-rews 5y ago
  > being able to trigger alert from an iFrame that is being singlehandedly removed by the Chrome team. Fixed that for you. It’s not being reconsidered; The Chrome team makes decisions for the web whether you agree with them or not. They might pull the “proposal” only to just do it again later. [1] More context on the same blog [2] 1: https://www.quirksmode.org/blog/archives/2017/09/chrome_breaks_v.html https://www.quirksmode.org/blog/archives/2017/09/chrome_brea... 2: https://www.quirksmode.org/blog/archives/2021/08/breaking_the_we.html https://www.quirksmode.org/blog/archives/2021/08/breaking_th...
  - bokan 5y ago
    Disclaimer: I'm the one who made the change in [1] so I'm biased but... IMHO the argument on the blog mischaracterizes the situation - Chrome didn't break these properties but changed how they're interpreted under pinch-zoom. This was done precisely to keep backwards compatibility (on desktop browsers): at the time, the vast majority of pages assumed pinch-zoom can't happen on desktop (something that was becoming more common). The status quo meant zooming in on a desktop page would cause it to "swim" as various "fixed" elements shifted around, JS drop-down menus appeared in the wrong place, etc. This happened virtually everywhere one looked: facebook, twitter, apple.com, etc. The blog basically argues for "make pages fix themselves" which, even if major sites do, is unrealistic in the long tail. > They might pull the “proposal” only to just do it again later It's not nefarious, this often happens in response to feedback and real world experience to try and minimize disruption. In this case, developers convincingly argued that there should be an API to better react to pinch-zoom before making the change.

javajosh 5y ago

Why do people think that the universality of decay can be stopped? I would even question the assumption that it should be stopped. On a long enough timeline, the survival rate of all APIs goes to zero. (Except Lisp, which is Eternal).

quickthrower2 5y ago
Lambda calculus API is eternal. There are multiple LISPs, so multiple APIs, changing over time.
- deleted 5y ago
  [deleted]
dannyw 5y ago
One of the great things about the web is the fact that I can expect anything I create today, to be relatively forwards compatible, and I can build things in a way so they're either backwards compatible or degrade gracefully. The philosophies around entropy isn't really relevant here IMO. The web should continue to be evergreen.
- DrSiemer 5y ago
  Supporting legacy constructs forever can be hugely detrimental to progress though. Something completely new would fasttrack innovation. It could leave out all the quirky workarounds and get advanced features built in or easily extensible. When adoption is high enough it could include a legacy box, to run good old HTML based content. Have any attempts at this sort of thing ever been made?
  - mod50ack 5y ago
    I don't think this is really a good idea. HTTP and HTML aren't perfect, but they've been made into ubiquitous standards already used by everyone. In order to switch to a new standard, you'd need to have a pretty convincing way in which it was better. And I don't think you can ultimately outbalance what we have now. Not to mention that the only way this could probably actually happen would be through Google doing it, which would be disastrous for the open nature of the standards.

tmwed 5y ago

unless i haven’t read deep enough into that groups thread. this seems overblown. alert, prompt, etc. isn’t being deprecated on the entire web, only in the context of cross-origin iframes. that being said, this post definitely strikes a chord with me. instead of adding a new index of deprecated features, it think it speaks more to the fact that caniuse needs to rethink how they approach deprecated features.

alessioalex 5y ago
No, they will be deprecated. The decision has been made: https://news.ycombinator.com/item?id=28310716 https://news.ycombinator.com/item?id=28310716

gkoberger 5y ago

Just a quick note, alert/prompt/etc are NOT in danger of being deprecated. Chrome is just considering not allowing them to be triggered from iFrames for security reasons.

chrismorgan 5y ago
No, blocking them from iframes is just the first step. alert/confirm/prompt are absolutely in danger of being deprecated and eventually removed. Browser makers have declared they’d like to remove them altogether: https://github.com/whatwg/html/issues/2894 https://github.com/whatwg/html/issues/2894. But they’re too popular to remove under current policies unless they’re really causing harm, and I do believe there’s serious risk of them classifying it that way. (They’re actually a bit of a maintenance burden, as three of the few remaining synchronous things.) Remember also the big difference between deprecation and removal. I’d go so far as to say I think it’s likely that alert/prompt/confirm will be deprecated and produce console warnings in at least one major browser before four years pass, though I don’t believe they’ll yet have justified going ahead and removing it.
- gkoberger 5y ago
  Your link says the exact opposite of everything you wrote. The post is by a random dev who doesn't work at a browser, and it was closed by someone who does after they said they don't deprecate things unless they plan on removing them.
  - chrismorgan 5y ago
    It’s definitely not the best source—the best sources are scattered about the place and probably more just murmurings than clear statements of intent—but it does include one positive signal from browser and spec makers, annevk on the reason for reopening it: > I figured it deserved some more implementer input especially since there seems to be interest in removing them eventually It’s not spelled out clearly, but I believe from what I’ve seen of processes there and from what I’ve read elsewhere that he’s talking about implementer interest rather than just-anyone interest. Consider also how Chromium actively gathered usage statistics and Firefox wants to, which you only do if you want to remove the thing. They definitely want to remove it altogether, they just don’t reckon it’s feasible at this time, and it’s definitely not a high priority for them. There are other sources, most likely to be found in previous discussions on HN of this rough topic, but regular search for this stuff is just about impossible now because it’s been drowned by stuff pertaining to the block in cross-origin subframes. (bryik and anonydsfsfs have now found better citations, refer to their comments.)

ianlevesque 5y ago

It's already happening, with consequences. Remember Manifest V3 nerfing all the webextension APIs used by ad blockers?

ximm 5y ago
Last time I heard this only affected chrome. So if you want ad blocking, just use a different browser. Kinda obvious that the browser you get from the ad company for free is not for you if you do not like ads.

shp0ngle 5y ago

Chrome does not disable alert(). Alert() will still work, just not from cross-origin iframes.

alessioalex 5y ago
No, they will be deprecated. The decision has been made: https://news.ycombinator.com/item?id=28310716 https://news.ycombinator.com/item?id=28310716
- shp0ngle 5y ago
  I don't consider some random Twitter thread an official messaging. Also the thread itself talks just about iframe alerts.

vmception 5y ago

my biggest chuckle is that he probably spent the most time trying to figure out how to center the div on his new parody site

chrismorgan 5y ago
Nah, `body { max-width: 400px; margin: 0 auto }` is the usual way of capping page width and centring it.

andrewmcwatters 5y ago

I author a CSS 2.1 rasterizer, and a partial implementation of it is used in a game engine my company's open source organization publishes. There's such a small number of people who have written their own pieces of visual web client technology, and an uncountable number who consume it. I've entertained the idea of writing a partially compliant web browser and releasing that for fun. It's still totally possible to write your own web browser today. You will of course need to put in effort than an exceptionally small number of people have, and even after you do that, you'll only have something partially compliant. But it will be valid! Hell, you could build an HTML5 valid web browser that didn't even use CSS. Invent your own thing. Make JSON style sheets or something. Anyway. We don't have enough people toying around with web tech. For years, I've only ever seen people toy around with the easy. Things like making little web clients to help you with API requests instead of turning to curl, or rehashing a CSS framework for the nth time. And frankly it's sad to see because its so uninspired and boring. Where are the people creating basic web browsers that use C# as a programming language instead of JavaScript? Or people inventing a new hypertext markup language as an alternative to HTML that still uses HTTP as a transport protocol?

pjmlp 5y ago
WPF and WinUI.
zamadatix 5y ago
SerenityOS probably has the most serious attempt I've seen at "Let's make our own web browser for the sake of it" (along with the rest of the OS). I think they are still working towards Acid 2 compliance but they also have a spattering of newer features supported as they hack at getting newer sites to work. Not a very whacky take though just a home grown one. http://serenityos.org/ http://serenityos.org/

teewuane 5y ago

Wait, why are alert, prompt, and confirm being deprecated? So we are going to need to write poly fills for old features?

vanviegen 5y ago
These functions are blocking, so they can't be polyfilled.
- Dylan16807 5y ago
  Yet another reason it's bad for asynchronous functions to be a separate type from normal functions.
  - Thorrez 5y ago
    What do you mean? Do you think all functions should be asynchronous? Do you think no functions should be asynchronous?
    - int_19h 5y ago
      Ideally, all functions should be async-transparent. That is, it should be up to the caller to decide how to invoke it. This is usually done with some form of green threading. It all works great, right up until the moment you have to interop with another language/runtime that doesn't understand your bespoke async. Callbacks (and layers over them such as tasks/promises) are uglier and necessitate opt-in async, but you can interop them to anything that speaks the C ABI.
      - Thorrez 5y ago
        Green threading is multithreading right? Isn't Javascript singlethreaded? I would assume adding multithreading would break tons of code that relies on it running singlethreaded.
        5y ago

yummybear 5y ago

I wonder - with all the limitations being imposed on IFRAMEs, what do people do when they have a product that needs to integrate UI with other peoples websites?

onion2k 5y ago
They use an iFrame, with the correct headers to enable what they need. If the site isn't trying to do something nefarious it'll work perfectly well.
ximm 5y ago
Put some JS on the host and use postMessage()

LAC-Tech 5y ago

Oh man HTML imports looked sweet. why was that deprecated?

dmitriid 5y ago
IIRC it was going to conflict with JavaScript imports. So now they are going all in on Javascript. See, e.g. CSS Modules: https://github.com/css-modules/css-modules https://github.com/css-modules/css-modules

osener 5y ago

Another example of this is SharedWorker. Here it is in the standard: https://html.spec.whatwg.org/multipage/workers.html#dom-sharedworker-dev https://html.spec.whatwg.org/multipage/workers.html#dom-shar... Safari/Webkit removed it in 2015 (edit: maybe even earlier!) and never reintroduced it: https://caniuse.com/sharedworkers https://caniuse.com/sharedworkers Here is the apparent reason for cherry picking features: > The implementation of Shared Web Workers was imposing undesirable constraints on the engine. It never gained any adoption. https://stackoverflow.com/a/48193804 https://stackoverflow.com/a/48193804 Edit: Here is the ticket for it’s reinclusion https://bugs.webkit.org/show_bug.cgi?id=149850 https://bugs.webkit.org/show_bug.cgi?id=149850 Turns out it was removed temporarily because of internal architecture changes, and never reintroduced because of lack of adoption. Of course the biggest barrier of adoption is Safari not supporting them, so talk about a self fulfilling prophecy. > This feature was originally removed temporarily during multiprocess bring-up, and actual usage on the web has been pretty low. We're willing to reconsider if there is significant demand.

gsnedders 5y ago
IIRC, it was only even available through WebKit1 (i.e., the single-process WebKit API) and never through WebKit2, so it will have gone from Safari when Safari moved to WebKit2, even though the implementation lived on in WebKit for longer. It was only 4+ years after it was dropped from Safari that anyone started to ask about Safari support for it again, so it had kinda fallen to the wayside due to lack of interest.

LeoPanthera 5y ago

HN loves to bitch about whatever Safari doesn’t support at the moment but I use Safari as my platonic ideal web browser. It’s the only one that is directly designed for users and not web devs, and the only one that has a simple “buy our hardware and get Safari” business model. I am automatically suspicious of web techs not supported by Safari.

markmark 5y ago
It's also the one made by the company that doesn't want web apps to compete against their app store monopoly.
zamadatix 5y ago
The bitching of lack of a lot of the features for web devs doesn't come from it being built for users instead of the devs rather it comes from Safari being built to not compete with the AppStore on iOS where they get a 30% cut of all transactions vs the 0% on the web.

severak_cz 5y ago

Why nobody mentioned window.open? It's not deprecated but there are popup blockers everywhere. This still makes problem with old apps.

zamadatix 5y ago
Popup blockers are user controlled, feature removals are not.

kccqzy 5y ago

Quick, add WebSQL to the list.

Doctor_Fegg 5y ago

E4X is another one: supported by Firefox way back when, but it never made it into any other browsers and FF eventually removed it. https://en.m.wikipedia.org/wiki/ECMAScript_for_XML https://en.m.wikipedia.org/wiki/ECMAScript_for_XML

one_comment 5y ago

> Note how browser support was short-lived. The author could have used the date relative view. 8 years (implemented in all major browsers 2012, deprecated in 2020) is not short-lived in my book.

jan_Inkepa 5y ago

Caniuse, rather infuriatingly, used to deliberately not track usability of obsolete/deprecated web stuff (it would just say something like "Feature X is obsolete, don't use it" instead of the browser support graph), but it seems to have changed course https://caniuse.com/?search=blink https://caniuse.com/?search=blink thanks, caniuse!

bugmen0t 5y ago

Have you heard of https://deprecate.it/ https://deprecate.it/? :)

captainmuon 5y ago

At some point, I started making a similar thing for C++ (arewemodernyet). I didn't even include a provision for the case that features go away - I think I just stored for each compiler the minimum version a draft (Nxxxx) is implemented in. The thinking that "everything becomes green over time" is just so ingrained.

kybernetikos 5y ago

Things that have bitten me (combinations of actual breaks and things where it seemed that progress was happening in a particular direction and then it changed): * use of geolocation & crypto APIs on http hosts * websql * changes in how browsers provided accelerometer data * multipart/x-mixed-replace

brundolf 5y ago

Does deprecation of web APIs actually mean anything in terms of support though? Last I checked, frame sets have been deprecated for something like a decade, but they still work fine. It seems like deprecation on the web really just means "if you're new here, know that this is considered bad practice now and we're only listing it for completeness"

ag8 5y ago

Since it looks like Chromium is set on removing alert() altogether[0], I don't see why this can't be handled in the same way browsers handle popup windows. If a website tries to open a pop-up, it gets blocked; but, on Firefox at least, I get a small notification in the toolbar, where I can choose to copy the popup window's URL, open the popup, or allow the website to open popups as much as it wants. Why not do the same exact thing for alert()s? [0]: https://news.ycombinator.com/item?id=28310716 https://news.ycombinator.com/item?id=28310716

SimeVidas 5y ago
The problem is that alert() blocks JavaScript from executing. If a web page fires an alert, it expects to be blocked in that moment. If the browser were to delay the alert, the page would be blocked unexpectedly at some later time. This would probably cause bugs.
- Orphis 5y ago
  The problem is that people relied on a side effect of a function that isn't guaranteed to block execution all the time (browsers are allowed to ignore those prompts) and now they have to fix their code.
  - capableweb 5y ago
    > The problem is that people relied on a side effect of a function that isn't guaranteed to block execution all the time Yes, this is a problem when people code their websites against current iterations of a browser. It's not a problem regarding Chrome removing window.alert() but rather a problem that happened at development of the site, not at the iteration of browser (which is being discussed here) > browsers are allowed to ignore those prompts Unless previously marked as "Block future popups", is there any browser that currently (by default) doesn't block JS execution upon window.alert()? AFAIK, all browsers currently do. > now they have to fix their code Yeah, good luck maintaining the web with that mindset. There are countless of websites that will basically vanish (rather, stop working) if you change the execution model of browsers too much. But large swaths of the web currently are just online because someone set it up well 20 years ago and has never touched it since. Maybe they can't even modify it at this point. So any change needs to consider the historical impact the change can have. Hopefully the people working on browsers and standards have a bit better mindset than "now they have to fix their code", because otherwise we're utterly screwed.

deleted 5y ago

[deleted]

city17 5y ago

Not sure what's wrong with some aspects of an API being deprecated over time. Of course if it's not done prudently and you can't rely on core features to work anymore after a short period of time then it starts to get annoying. But opposing any deprecation at all seems like the other extreme.

deleted 5y ago
[deleted]
fleddr 5y ago
It isn't extreme at all, it's the basic contract of the web. If something works today and is standardized, it should keep working forever. The main reason is the gigantic size of the web and the state most of the web is in. Unmaintained. There's no team to update anything, so you're purposefully breaking the web.

nkjoep 5y ago

dupe of https://news.ycombinator.com/item?id=28302420 https://news.ycombinator.com/item?id=28302420

wildpeaks 5y ago

A pragmatic way to catch deprecated features during development are Typescript intellisense and Webhint.

swiley 5y ago

All my HTML still works. Just don't go overboard with frameworks and Javascript.

superkuh 5y ago
Yep. If you think like this the best can I use x site is: http://caniuse.xyz/ http://caniuse.xyz/. You can try it out like, http://caniuse.xyz/css-grid http://caniuse.xyz/css-grid . I whipped it up and registered the domain on a whim in about 30 minutes.
- zamadatix 5y ago
  > Get a new one not controlled by mega-corps and their invalid profit-motive PKI assumptions. The very browsers that pushed that change founded Let's Encrypt to provide free certificates prior to pushing sites towards HTTPS. That's the opposite of a profit motive. There are also more free alternatives like ZeroSSL since.
  - superkuh 5y ago
    That's a reasonable misunderstanding since the site is fairly terse. To be clear, what I mean is that forcing HTTPS-only is something that is required by profit motivated corporations. They see the potential risk of an HTTP downgrade attack as being enough motivation to completely kill HTTP. And unfortunately even Mozilla is going along with it. HTTP has it's place for human persons and human person run sites. It allows free communication without having to exist only on the whim of some CA or your mega-corp browser's decision if your cert is too long, too short, or too something. I did not mean that the founding of LetsEncrypt was profit motivated. LetsEncrypt is good for what it is. But forcing HTTPS and not allowing HTTP at all is very, very bad for the web. Especially since cert CA usage follows a powerlaw like normal and nearly everyone centralizes in LetsEncrypt.

sente 5y ago

I'm red/green colorblind and cannot for the life of me tell the boxes apart

harg 5y ago
There is a colourblind friendly colour option that you can enable in the site footer
Liquidor 5y ago
> I'm red/green colorblind and cannot for the life of me tell the boxes apart You can change the box colors at the bottom of the site :)
a3w 5y ago
The boxes have (weak) stripes. But screenshots of a webpage are missing all accessibility features, so links to the actual caniuse.com articles would be helpful. I don't understand how e.g. reddit allows text-as-images when that is discriminatory for people with eyesight issues.
- vdqtp3 5y ago
  I don't understand how any website allows images when they are discriminatory for people with eyesight issues. /s
dredmorbius 5y ago
I'm on a B&W grayscale e-ink device ... and I feel your pain.

pornel 5y ago

Actually, it would be nice if we could retire old image formats. For example, if/when JPEG XL becomes universally supported, the WebP format will be entirely redundant (lower quality, worse compression, no progressive, and it's not even faster to decode) and AVIF could be retired too (comparable compression, but much slower, and much more bloated HEIF container). But currently browsers are Katamari Damacy balls endlessly accumulating more and more code. How long can we keep just adding without removing anything?

dmd 5y ago
I sure hope so, because they're absolutely not a waste of bytes. Unless you personally are planning on converting all existing use of those old codecs everywhere? What you're suggesting is an archivist's nightmare.
zamadatix 5y ago
Redundancy assumes that either the original still exists, the encoded copy was lossless, the original was JPEG (which can be losslessly upgraded to JPEG XL), or that the new lossless copy of the old lossy intermediate will outperform. In reality the vast majority of AVIF and WebP images are lossy without the original copy meaning such a change will either force worse overall efficiency to now be a lossless reproduction of a lossy image or generational loss each time a new format takes over. Not to mention the breakage and work effort during such change periods.

EamonnMR 5y ago

Alert was always annoying, but it was never as annoying as sites asking for notification permissions.

lkbm 5y ago
Alerts steal and block focus. A notification permission request doesn't keep me from scrolling the page, or clicking a link. If alerts were as common as notification permission requests, it would be absolutely infuriating. Disabling notification requests is a simple browser setting and I haven't even bothered with it. If alerts were as common as notification requests, I'd do whatever it took to disable them.
- EamonnMR 5y ago
  I'm salty that they where ever implemented in the first place.

GnarfGnarf 5y ago

Is Vivaldi not worth tracking?

zamadatix 5y ago
Something less that 0.1% of users and the default cutoff is 0.5%.

EMM_386 5y ago

> All green boxes indicating support, with a note at the bottom: “this feature is deprecated/obsolete and should not be used”. CanIUse should just color these deprecated features in orange, meaning "it works but don't use it".

chadlavi 5y ago

Wait a minute the lede is truly buried here — Chrome is killing alert/confirm??? This will break tons of stuff. What's the recommended replacement?

paulryanrogers 5y ago
Only from iframes

dpweb 5y ago

That link about killing alert() refers to only cross-origin iframe use of alert.

fleddr 5y ago

We should also make caniusebutdoesitactuallywork This to refer to my annoyance of browser makers leaving incomplete implementations stagnant for years. As an example, the <dialog> element, a browser-native standardized spec as promising replacement for alert. Except that it doesn't work, it's inaccessible at its core. And nobody fixes it, it's just left in this broken state forever. <section>, the element that was supposed to cut up an HTML document into multiple outlines, hence making componentized SEO-optimized headings easy and better, do nothing at all. CSS columns, a simple and easy way to distribute text, were unusable for 8 years because Mozilla refused to fix their own small bug. Which pales compared to the extraordinary amount of Webkit bugs that are absolutely never ever fixed. Form controls, since the very invention of them, are terrible. It has cost the world billions, as worldwide every single developer and project has to reinvent some of them, often breaking basic accessibility in the process. I could go on, but I'll sum it up as the failure to address extremely common real world problems, and to just let broken buggy solutions linger. When you accept a standard and implement it, bloody finish the implementation. Fix bugs. Otherwise, what is the point? I'd call this hardening the web. There's no reason I can see why you can't harden it whilst also making progress on new features.

dylan604 5y ago
Fixing bugs vs adding new features doesn't bring in new users, so it doesn't get prioritized. And if as you say these bugs are in features that nobody uses, why bother? Nevermind nobody might be using them because of the bugs, but the PR buz over those features has already been had, so on to the next.
- fleddr 5y ago
  Not sure I fully agree. The features we're talking about here are in the developer space, not the end-user space. When a browser maker implements a brand new web standard, I don't think the correlation with new end-users is that strong. It takes forever before any new standard is popularized and widely used. Check release notes of browsers, almost all features no user will ever directly experience.

hutzlibu 5y ago

About chromium on cross origin remove of alert and co.(link in article): "We haven’t engaged with other browser vendors regarding this change yet, but plan to submit a spec change proposal once the change is approved for Chrome." So chrome just changes it. And then officially applys for the spec change, so other browsers might follow - or not. I mean, why pretending at all, that you care about the spec, when you are fat monopolist?

zamadatix 5y ago
Eh, I don't like how much influence Chrom(e|ium) has but this is either missing information or intentionally misleading to paint a picture. This is how the spec process works: 1. You find out if you want to implement something 2. You find out if others want to implement something 3. You implement your something (for simple things in a testbed for complex things as an experimental change over multiple development versions) 4. You demonstrate the something works 5. You demonstrate others are intending to ship as well (For complex things you may have to wait until others are comfortable with their working implementations) 6. If you had a bad experience and many discussion points in 4/5 you go back to 4 and refine until you had a good experience and your spec is merged. You imply the Chromium authors went 1, 3, ship because you read about step 1 happening. In reality they consulted with Firefox and Safari prior to merging code into the codebase or simply lobbing a spec proposal over the fence. https://github.com/whatwg/html/pull/6297 https://github.com/whatwg/html/pull/6297
- hutzlibu 5y ago
  Ok, all I know is, that the site in question, Canistilluse.com, has as the main information, that in the next version of chrome 95, "alert" can not be considered, as working as expected by the standard. For me, that comes a bit out of the blue - and seems to be a "making facts" attitude by chrome, not discussing things.
  - zamadatix 5y ago
    That colored squares from canistilluse.com are not not "all you know" considering your original quote was pulled from the same page I pulled the above Firefox/Safari signals+timeline and spec PR link from: https://groups.google.com/a/chromium.org/g/blink-dev/c/hTOXiBj3D6A/m/1Q0TjPwWAwAJ https://groups.google.com/a/chromium.org/g/blink-dev/c/hTOXi... Also canistilluse makes no claim about whether the deprecation matches standards or not. For reference the standards change was actually approved back in February, per the link in my above comment, so it is actually according to standards.

jacquesm 5y ago

The bigger problem is that the web itself is rotting away as we speak. Yes, browsers no longer supporting old API calls is a huge problem, for instance for archived content that at some point will simply stop working, a bit like a 78 RPM record. Good luck finding a player. All the Flash content and so much other work that is part of our digital record is no longer working (and I absolutely loathe Flash). So whether or not you can still use it today, the bigger question is will you be able to use that website 10 years or longer into the future? Because any book ever printed can still be read today (assuming you know the script and the language it was written in), I think the longevity of the web will top out at a couple of decades at best before the digital termites and worms will consume the devices that could have rendered the content you are interested in. Plain ascii text will likely live the longest, with markdown as a good second. Anything that executes will likely simply die.

iKnowKungFoo 5y ago

I don't know that anyone should be worried about supporting anything in MSIE 11 unless site analytics reflect a significant number of users with that browser version. I annually audit a company's access patterns to see which browsers and resolutions we need to worry about. This affects development, QA and support at the very least. For example, global patterns in the US alone reflect 0.64% and dropping as of July. https://gs.statcounter.com/browser-version-partially-combined-market-share/all/united-states-of-america/#monthly-202007-202107 https://gs.statcounter.com/browser-version-partially-combine...

xibalba 5y ago

> recently reached the threshold of (mostly) supported everywhere: the .webp file format. Why has google (via lighthouse and pagespeed insights) been pushing webp so hard if it has only recently gone majority green?

magicalist 5y ago
<picture> has been green for more than five years now and can trivially fall back to jpg if you still need to support IE11.

xg15 5y ago

I honestly don't understand what great feats of technical debt removal or code simplification browser devs are hoping for after removing alert() etc. JS engines will still need the ability to stop-the-world, unless they want to get rid of breakpoints next. I'm also of the opinion that chrome devs should first try to write a "javascript for absolute beginners" tutorial before giving sage advice what such a tutorial should teach and what it shouldn't. ... though I can sort of understand the viewpoint. From a browser developer's PoV, you could probably never be too early in teaching about the event loop, promises, callbacks and async/await. Except that this seems at odds with how programming and JS is actually learned by users. This reminds me a bit of the Java language design, where you're in theory supposed to understand classes, objects and static methods before you can even write a "hello world" program.