this really strikes me as evidence that something is wrong with the http standardization process. we should know if something's a good idea before immortalizing it in a standard.
It may be removed from chrome, but it's still in the standard.
It may be removed from chrome, but it's still in the standard.
Google then used its unique position as a) massive web server and b) massive web browser to perform real-world protocol experiments that _nobody_ else could possibly do. SPDY came out of that (really cool!) work, and had some great benefits, and the working group started with the spec and worked to evolve it.
The server-push originally comes from SPDY, and as I recall it seemed an obviously useful optimization at the time. It's a bit ironic that the same company that introduced it is now saying "we never really found a use for it".
Disclaimer: I was employed by Google and on the HTTP/2 working group at the time.
here's a more cynical take:
- "only google can do these huge experiments, and we've blessed the world by sharing our discoveries, so we can have confidence that our proposals are validated with real world experience."
- "That thing we standardized and got a bunch of other people to implement? yeah, i know we said it was really useful, but we meant it seemed really useful. We actually never found a use for it."
can't have it both ways
Other vendors do this too - the fundamental conceit at play is as old as the tech sector - but that doesn’t make it any less arrogant or reprehensible behaviour.
With that understanding, the process note above from an ex-Google employee amounts to a description of wilful abuse of market power.
The overall decision-making around how the web works is insane and getting more insane by the year. We have fairly trivial and absolutely universal problems unsolved for decades, while browsers get crammed full of features that aren't used by 99.9% of websites.
Worse, some problems are finally solved in such a half-assed way that it's almost worse than having no solution at all. (Input type="date", meter element, dialog element etc.)
This is not at all what I imagined the field would look like when I entered it nearly two decades ago.
Why is this surprising? Universal problems are hard to solve otherwise it wouldn't be a universal problem in the first place. Add to that large numbers of groups will have their own set of opinions on what the best solution is, and it will conflict with some ideas.
This is completely backwards. Universal problems on the web are routinely solved by everyone designing a standard website. They often have fairly standard solutions. Browser vendors routinely fail to generalize the experience of run-of-the-mill web developers. It's not about engineering. It's about misaligned incentives and operating from a bad frame of reference.
This describes most areas of applied computer science, honestly. Language design, build systems, operating systems, etc. When standards and/or widely used systems are involved, nothing is trivial. And the web is the most widely used and most standards-based system out there.
Because what I see is:
- A working element that only got half assed/ignored by one provider (Apple, but who's surprised?) which meant polyfills for years to fix it. - A niche element, there are plenty of those? - A relatively new element that solves a lot of issues with Z layer, accessibility etc and is a good basis for other components/libraries to use for their styled/enhanced modal dialogs.
Meter has a nonsensical data model and no standard way of styling it.
Dialog is a half-assed element that's useless without large amount of styling and code. For its sake they've added an additional form method, which will likely break many older JS libraries.
Mind you, we're talking about controls that have been faked or implemented on the web by developers for at least two decades. This is pitiful.
I’ll readily agree, however, that the meter element is trash, and date input an underspecified UX crapshoot.
My biggest beef with Apple’s standards engagement, however, is their intransigent and ill-considered refusal to implement customised built-in elements.
You're wrong on dialog though.
It's not half assed, it's the core functionality needed for a dialog, no more. It makes very few assumptions abouts you want your dialogs to look, or behave with closing/opening. You only have to build atop it, rather than strip it back (e.g. Like how you have to strip/reset lists to use as nav menu elements)
I've styled them and it's usually less css than equivalent bootstrap or homegrown dialogs.
I also doubt your claims that the new form method will break older js being a real problem. The method just allows js to get a standard way of how a dialog closed. I just don't see when you'd use old js that might have issues to handle that..
The purpose of a standardization process isn't to stamp approval on good ideas; it's to ensure interoperability. Server Push was a plausible idea. It very much could have been a good idea. It turned out not to be, after we tried it in the real world for many years, but that's okay. And we know one thing for sure - the reason it didn't work wasn't that people were afraid to use a nonstandard X-Chrome-Server-Push extension.
HTTP/2 was what? Something no one wanted, imposed by Google? Is that too strong?
Is bottom-up maybe better in practice?
However, in this case it being in the HTTP/2 standard is moot, since it's just a (premature) optimization and thus its removal results in a reasonable fallback, which is simply not using that particular optimization, and also because HTTP/3 is so far along already.
Not to get too tangential, but this seems similar to fetch removing support for reponse bodies for POST/PUT requests; a login POST, for example, might return information about the user's login or the state of the server, or even a per-tab/per-page token that isn't a cookie header, but fetch simply refuses to support it (even though XMLHttpRequest still does). Fetch removing this means that additional round-trips are needed, even over a multiplexed connection, and certain app designs are simply not possible. The solution seems to be to buck the trend and just use XHR instead of fetch, especially since fetch doesn't seem to be available on older Android Chrome (possibly 5-15% marketshare even now.)
this is a salient point. if it's just an optimization and not implementing it (or removal) doesn't change behavior of sites that have adopted it, then it's benign.
Wait what? I have never heard of that, do you have a link where this removal is documented?
Seems pretty short-sighted of a decision there, since XMLHTTPReq does it just fine, and it is in the HTTP RFC's
Sometimes specs are proved to be wrong, this is just one of those occasions.
No one uses it going forward. I'd hate to venture a guess at how many existing sites there are that use xhtml. Browsers are still expected to parse and render them properly.
What significant feature in XHTML is not supported by HTML5?
if you are only speaking about the syntax (so your statement includes XHTML5), I don't follow you neither: I don't see what's wrong with the XML version of HTML5.
`<b><p></b></p>` wouldn't stop HTML from rendering, but would stop XHTML. Plus the whole "XML parsers are very unsafe"
XML parsers are not that bad when you disable custom entities, which browsers could easily do.
It seems like the majority of developers have never really wanted to make that cost-benefit tradeoff, though. I ran tons of websites declaring an xhtml doctype through https://validator.w3.org/ back before HTML5 when xhtml was still trendy: almost all of the "xhtml" websites failed validation.
Yes, but there weren't many tools to "correctly" compose XHTML back then.
> XML parsers are not that bad when you disable custom entities, which browsers could easily do.
Yes, but it's another thing browser developers need to think of. A lot of CVEs already originate in browser. Even if it's actually safe, people who got burnt by XML, would have bad opinions about XML in mind.
Hiding errors is always a poor choice. Only if you are low paid developer not interested in making a quality product then probably you like browser's behaviour.
Some estimates say that 99% of HTML pages in the wild have at least one error in them. Yes, they errors would probably be fixed if it stopped browsers from rendering the page.
Browser plugins also had to speak valid XHTML and be able to modify documents correctly. In-line JavaScript was...funny looking. CSS also behaved differently in XHTML.
I, personally, liked XHTML behavior because errors in HTML were essentially Undefined Behavior. That resulted in different results from browser to browser (back when we had multiple browsers and not just Chrome). However, I also like Rust, so maybe it's a fetish? /s
We didn't really have good tools back then, and the way HTML was generated wasn't brilliant. Currently, I'm making a website in Yew, and it won't even compile if I don't have tags correctly placed and closed because everything inside `html!` macro gets turned into rust code and then HTML gets built. I think JSX behaves similarly?