The person writing this has to repeat frequently that they're OK with the <toast> element; it's quite funny how hard they try not to upset people.
But their view of the situation is completely correct; just because this one feature might be useful (heck, when Microsoft dumped XMLHttpRequest on us that was incredible too), doesn't change the fact that we're now living in a web where Google does whatever it wants, adds whatever it wants to Chrome, and the web is at its mercy. If they wanted to add <blink> it'd get added and supported, and other browsers would have to follow lest they become incompatible.
There's not really much of a difference between the web today and the "Best viewed in IE" web, and that's sad. There's a difference in developer goodwill, and of course things aren't as buggy as they were back then so it overall doesn't feel like you're "stuck" with Chrome like it did with IE, but... you are. You're just OK with it.
I have been repeating the Chrome is the new IE meme for the last few years. I even had a boss that only cared about our code working on Chrome and would lose it when I was demoing / developing from FireFox. I only ever demoed in Chrome just to feed that illusion that I was adhering to Chrome but I honestly dont see anything special or better and I still made sure it behaved and worked the same in both. I know people in my office use other browsers (these were internal tools).
It saddens me that people worship Chrome and yet Firefox has a lot more potential in some areas. Hell it was Mozilla and not Google that gave us WebAssembly through asm.js and other awesome efforts. Microsoft gave us AJAX when Mozilla reverse engineered it back when standards were not properly standardized which is why AJAX is so XML focused in the name despite being able to fetch other things.
Some software houses who supply the company I work for, are refusing to work with anything but Chrome. So it really does seem like the bad old days all over again.
I had to and I understand fully well what GP means:
Yes, Chrome is a better browser than IE 6 was, but getting everybody on a team, on every team to test cross browser compability is starting to get hard.
We're now seeing otherwise great developers who more or less openly admit they don't test in other browsers.
I call them out on it. It is unprofessional.
We've fought to get where we was a few years ago, where every modern browser was considered equal.
Don't let any web developer get away with Chrome only!
No, IE6 was far less terrible than IE4, but still amazingly awful. If was from the era of browsers where you had to essentially code up different copies of a page per-browser if you wanted any sort of graphical anything.
Except that IE6 didn't die when IE7 came out - it stuck around. I was working at a company that still had to support IE6 when IE8 was coming out - and firefox was quite popular by that point - we ended up dropping support for it shortly after chrome got popular.
IE6 outlived it's expected lifetime by leaps and bounds due to lots of customers stuck on machines locked into running old version of windows due to financial or corporate policy reasons.
Ever listen to Android web developers? The matrix of versions of Chrome to test if you need to "properly" support Android due to financial or corporate policy reasons is fascinating. It's not as bad today as supporting IE6 and IE11 side-by-side due to idiot corporate policy, but the wind shifts one way or another and it certainly could.
(Fun spitballing doomsday scenarios: LineageOS gets more traction and needs to harder fork; or, Huawei is forced into a hard fork and takes the entire Chinese market with it, which could snowball other markets across; or, some Android worm causes friction with the major carriers and they get back into the version/upgrade micromanagement game even worse than before.)
The scale is massively different though. When you make a page today 95% of it works on all browsers. Back in the IE6 days that wasn't even remotely true, which is why things like jQuery came into existence, not to mention the insane CSS hacks required. IE calculated padding differently to every other browser, requiring you to rewrite any code that used it. There's no equivalent to that today.
Today isn't a dreamland, but it is in no way as bad as the IE6 days.
But that's not the IE6 days. That was when other browsers were already well established and IE6 was that zombie feeding off corporations never upgrading that you just couldn't kill.
But in the early 2000s, you only ever targeted IE6 and maybe 5. Opera was that weird European thing, Netscape disappeared by 2003 and Firefox was that silly open source stuff used by people without friends or any sort of social skills. That was the IE days.
I don't really agree with the "Chrome is the new IE" sentiment. They participate in the Web Standards process the same as anyone else. That their voice has different gravity in the process due to the fact that they are often the ones pushing the standards forward isn't something they should be compared to IE for. Devs old enough to recall the halcyon days of IE know it was quite different...
IE definitely participated in web standards at the time. Certainly in CSS.
They were not as good at bending standards groups to their will as Google has been, for various reasons, which is why standards did not always match their proposed implementations. But trying to paint IE as not engaged in standards is pretty misleading.
(Now I don't think they were too engaged in things like XHTML2, but neither was any other browser, because that group was fundamentally not interested in browsers being engaged, as far as I can tell.)
It is different but not necessarily better. Where IE got really bad is when they stopped developing it. Development really slowed after 5.5 and once 6 was the undisputed champion they just left it to rot. Whatever else can be claimed about Chrome, they're not idle.
TBH I think if you want a slogan then "Google is the new AOL" is better. When you look at what their doing across technologies it looks more like reinventing AOL's walled browser for the modern age.
Obviously every Google product is different, but how many Google products have reached maturity only for Google to basically stop, and then eventually discontinue it after eliminating the competition in the interim?
Chrome and AMP do seem to be part of Google's long term strategy. I don't see them dropping either anytime soon. Well ok they may drop AMP if they finally get it all integrated into the various web specs. but that's a distinction without a difference.
> Devs old enough to recall the halcyon days of IE know it was quite different...
I'm old enough.
People sharing your view, are agreeing with a broad assumption that isn't based in reality. Ironically, the Chrome has had to adopt from the other direction (webasm) and hasn't created much whole-cloth that other browsers have had to adopt...and developer's certainly aren't hambstringed by these small additions that make Chrome a delight (for now). From a business perspective, the popularity monopoly is not the same as how IE was made "popular". It's VERY different from the old days in terms of quality and the state of the industry.
It's not just developers, just like Microsoft made web applications that only worked on IE (think Outlook.com and the introduction of AJAX) we've seen it here on HN all the time, they announce new products that are only known to work on Chrome initially. Some have even changed the user agent and it works on Firefox, so there's some old school Embrace Extend Extinguish nonsense going on from Google's end when they introduce new products.
I remember that every browser had an AJAX API, where IE had a specific API that was more straightforward. The AJAX capability was a forgone conclusion rather than a technical leapfrog. You could always had access to an HTML request and timers to code AJAX as a final backup.
That definitely didn't work. Features we wanted to use that were standardized could not be used. Even after the browser got updated, we couldn't use them because lots of people used the old browser.
Browser incompatibility was used to lock entire enterprises into using only Internet Explorer. Badges did nothing to help.
The only thing it seemed to do was let you know what browser the developer/s were using.
If you happened to have multiple browsers it was possibly of some benefit if you could switch to that browser.
Enterprises still lock users to one browser if possible for security & maintenance reasons. I do see multiple browsers allowed for certain individuals to support older software.
sure, but Chrome has the power of Google behind it and that makes the browser more attractive because users feel that if the browser comes from the search engine company they already use then it must be compatible with everything they do online. This is a perception which gives Chrome an advantage over other browsers.
It's a bit of a monopoly that Google has on the browser market and so now they have leverage over what gets approved and implemented in those browsers.
Since most people use Chrome then other browsers are forced to follow suit with compatibility.
Chrome is basically a distribution of Chromium; there are some extra bits added like DRM, but otherwise it's built straight from the Chromium tree. It's not like Android, where there's a private repo that occasionally gets thrown over the wall in the form of AOSP.
> I'm not going to give any assistance at all to Google
Neither am I, but I wanted to point it out anyway. If things like chromium-dev had existed back then, maybe we wouldn't have had the IE fiasco we all remember. Or maybe we would have anyway, who can tell :)
> Hell it was Mozilla and not Google that gave us WebAssembly through asm.js
And that shows why Chrome is not IE... Chrome jumped in and supported WebAssembly even though they already had a mature equivalent (pNaCl) which they have now deprecated.
I just don't understand why there is so much hate for Chrome out there. Sure, we don't always get our way.
To me the Chrome team seems to listen to developers and users, and to put the effort in to follow standards, and to keep improving Chrome in ways that I care about as a developer.
Interestingly I try Chrome once every which and go right back to Firefox for exactly the same reason. I find the Chrome UI intolerable. Tiny tabs, inflexible GUI, less interesting extensions, etc. I also tend to use _many_ tabs (grouped by topic I'm working on) so maybe I'm a bit of an unusual case.
It is probably a quite subjective thing. I use Firefox as main browser but test things in Chrome. Neither UI really bothers me, but I prefer Firefox for ideological reasons. The dev tools in chrome are better though imo.
I feel like Firefox's Dev Tools are better in so many small ways at the fundamentals it's really sad every time someone says they prefer Chrome Dev Tools. (Plus, Firefox's Dev Tools inherited from Firebug and at least from that sort of continuity perspective arguably are the most mature Dev Tools codebase.)
A lot of the reason so many people seem to like Chrome Dev Tools better seems to be exactly the sort of "Works best in IE6" mentality that so many devs only spend time testing in Chrome and customizing Chrome Dev Tools how they like and making sure Chrome Dev Tools work right that it just becomes inertia that that is what they like better.
Little tweaks to sourcemap generation options, for instance, can be all it takes to get Firefox Dev Tools working just as well as Chrome for code debugging, but so many devs work in Chrome only that the defaults in so many places are accidentally so Chrome-centric.
Similar goes for all the Chrome-only Dev Tools extensions. At this point even the Dev Tools Extension Models are close enough between Chrome and Firefox that it mostly just needs more people using Firefox for development to catch up on extensions.
Could well be.
I do very little web development, and I used chrome back in the days when that was my fulltime job. It might be more of a case of familiarity rather than them actually being better. :)
One thing I think Chrome is better at is emulating CSS media, so we can check layouts when printing, for example. I don't even see how to do that in Firefox.
I'm the opposite with tabs, I try to keep them as minimal and just away as much as possible. Thankfully ff is pretty customizable so my setup is fine now, but the default top bar felt just gigantic and distracting coming from Chrome.
Interesting, but it requires adding a file to your machine. I'm constantly on different machines. Being able to log in, get all my info and settings, and then log out leaving the machine in its original state is invaluable to me.
Not the OP, but I'll chip in with my $.02. I really want to like Firefox, but everything UI feels wrong (on macOS). From tabs, where the close button is on the wrong side (right) and if you click the + button to open a new tab the cursor ends up over the new tab, not over the + button so you can click again to open a new tab. The whole UI looks and feels non-native. Pressing ESC in full screen mode does not bring the window back to its original size. In-page search opens a clunky (javascript?) search field in the bottom status bar. Firefox does not support proper macOS dark-mode (try cmd-O). Cannot print to PDF. (Magic mouse) gestures does not work. No automatic keychain integration for login forms. Fonts are rendered different than in Chrome and Safari, e.g. thin fonts are tick and font's in general look more ugly (something with antialiasing?). The list goes on and on. Basically Firefox feels like browser version of Slack.
The other one that bugs me the most is lack of bouncy overscroll with my trackpad. Being used to that in the rest of the OS, it feels very jarring when you scroll up to the top of a page and it abruptly jerks to a stop.
> From tabs, where the close button is on the wrong side (right)
Chrome does this.
> and if you click the + button to open a new tab the cursor ends up over the new tab, not over the + button so you can click again to open a new tab.
Chrome does this too.
> The whole UI looks and feels non-native.
Yep, that describes Chrome.
It sounds to me like you're a Safari user, since the things you're describing are things Safari does correctly. I'm a die-hard Safari user, and both Chrome and Firefox feel wrong to me. But Chrome feels even worse than Firefox does.
> From tabs, where the close button is on the wrong side (right)
In Firefox, using the Customize option from the menu, you can move the new tab button to the left side of the tabs, or even to the far right side so that it doesn't move.
agreed, the list is huge and so many of them seem like minor fixes -- for example the white flash that appears when opening a new tab in dark mode can be fixed with userChrome.css. its been an issue for a year. i don't know if mozilla is just broke or what, but it sure feels like their projects are hanging together by a thread. i still use it because i want them to succeed. i would be happy to work on it personally if mozilla would have me lol (instead ive made lots of extensions).
I’m in the middle of trying this exercise now. Some of the differences are just getting used to new design.
For me the most jarring thing is how Firefox’s omnibar works. It isn’t good at showing me the sites I’m looking for after typing just a few characters. Instead, it shows absolutely every page I’ve recently visited at one of those sites.
Another design thing is the amount of information on the default new page has a ton more info than I’m used to seeing (or really want to see). Hence a question I posted yesterday:
> For me the most jarring thing is how Firefox’s omnibar works. It isn’t good at showing me the sites I’m looking for after typing just a few characters. Instead, it shows absolutely every page I’ve recently visited at one of those sites.
Interesting! I think this may be a case where, over time, as you use a search mechanism, you get used to the kinds of searches that work well with that mechanism. I've had similarly frustrating experiences with Chrome's address bar, which I'm not used to using.
Firefox has a concept of "frecency", a metric that combines frequency of visit and recency of visit to determine what you're most likely to want based on what you typed. (It also gives some preference to the starts of words/domains, and some other heuristics.) However, I can easily believe that before Firefox has enough information, typing at it would produce suboptimal results. That's something worth reporting as a bug: https://bugzilla.mozilla.org/enter_bug.cgi?product=Firefox&c... . Please feel free to use any of the text above to help describe the issue, if it helps.
> Another design thing is the amount of information on the default new page has a ton more info than I’m used to seeing (or really want to see).
Complete agreement. I disable the new tab page on desktop, as I really just want a blank page. (On mobile, I find the default new tab page more useful and usable.)
When I type in ‘news.’ Firefox still gives me ‘hackernewsgrid.com’ as the first result, even though I haven’t visited that page in years, and in fact it is completely down.
I’m not sure how the omnibar works, but I’m not extremely impressed.
When I type “n”, I’m likely either going to news.google.com or HN. Firefox will guess correctly that I’m thinking of HN and fills that in as the URL. However, the main HN URL and Google News are something like 8 and 9 in the list. Everything above those two is a mix of things that happen to have an “n” somewhere in the URL that I may have recently visited.
As the grandparent comment says, you just get used to how Firefox works. For example, I would've never even thought to type "news" to look for hackernews in the omnibar after using it so long-- I just instinctively know that Firefox will find it easier based on domain name, so I type "yc" for "ycombinator.com"
I can see how this is going to be confusing for a new Firefox user, but it's easy to get used to.
I have several sites that I visit daily. All of them can be accessed by typing in the first character, or, at most, two characters - the url then appears in the navbar, just hit <enter>.
The strange thing is, every nine months or so, FF will forget one of these urls. It doesn't do it for all of them at once, just one, and it's not related to upgrades. All I have to do is enter the full url and hit enter, and things are back to normal again for that particular url for many months.
Not the OP of that comment, but I feel the same way.
I use macOS, so maybe it’s different on Windows. A few things bug me, it’s hard to really pin it down. It just doesn’t feel finished. The Save File dialog window feels like it’s from Mac OS 9, or at least its sentiment is. The behaviour is confusing, because if you press cancel, you still end up with a file in you Downloads. It would better if it just dealt with it the way Safari and Chrome do. A lot of the dropdowns and other inputs feel a little old too, everything ends up looking like 2003, which isn’t terrible, but I would imagine it puts people off when switching from Chrome.
The address bar is also very odd, it almost always suggests the wrong thing for me. I’ve adjusted the settings, but even for a site I just visited with the exact name in the page title, I still end up with the search as the default result.
That's some very reasonable feedback. Please consider reporting those as issues (the latter perhaps coordinated with the other commenter's bug report). Emphasize that it substantially affects the first-time user / new user experience; that may help get appropriate attention.
The search bar in Firefox always assumes you're attempting to visit a URL if you type two words separated by a dot. It's incredibly frustrating trying to search things like "table.sort" and being redirected to a URL that doesn't resolve to anything and will almost certainly not for a while. Chrome doesn't have the same behavior (it ships with a list of valid TLDs). I get that you can work around it easily by typing a space, but the habit is ingrained for me due to switching from Chrome and this alone makes me want to switch back, if not for the desire for Mozilla to succeed. There is a bug for this issue[0] which has been open for 5 years.
For FF mobile the UI is less convenient than Brave. In Brave the icons for adding a new tab and switching tabs are at the bottom of the screen, while in FF they're in a menu at the top. Because I use my phone in portrait mode I have to reach my thumb up to the menu every time to create or switch tabs. It's really tiresome and I use Brave instead due to this. Also, the URL bar on mobile FF has the 'X', but its behavior is completely different from Brave. It closes the bar entirely rather than clearing it. I also get that it's a thing to get used to after switching, but why not just delegate cancellation to the Android back button? (Could it be due to iOS?)
One Firefox option I love but don't see used much is the optional search bar you can add next to the url bar. I MUCH prefer to use that for searching for two main reasons:
1. It always "just works". I've run into problems with both Chrome and Firefox getting confused by a search term I entered into the URL bar.
2. The search string persists even after clicking on results. This is particularly helpful when I'm having trouble finding a good result and want to make a slight change to my previous search string, or I want to remember exactly which search term brought up a specific result.
Chrome is dead simple, minimal, and predictable. When I want something, I look in the one menu. Firefox, on the other hand, has multiple bars, multiple menus, sidebars, icons plus text. It's too much.
What bothers me, are dialogs and windows not written in html and css (not sure what it is, maybe XUL?). Chrome basically eats it own dog food = everything is html. Firefox still has settings done in non html way. It may sound marginal problem to you, but IMO browser should be showcase for html and html should be used everywhere. Also amount of popup dialogs/windows should be reduced. Again settings, about, ... should be html page, instead of popup window, which cannot be until it's rewritten as html page (so it's related to my first point).
UI elements written in HTML are hella buggy. For example, Chrome's hamburger menu (I don't know if it's written in HTML but it sure feels like it):
1. Spacebar doesn't select items
2. Key equivalents don't work while it's open
3. Cut/Copy/Paste often does not work, depending on where the keyboard focus is
4. Inapplicable menu items don't disable properly
5. The caret continues blinking in text fields even though keyboard focus is in the menu
etc etc. This sort of basic bugginess is embarrassing and entirely avoidable by using the native platform controls, instead of re-inventing them poorly.
Have you tried customizing the UI? Last time I tried out-of-the-box Firefox it disgusted me pretty quickly due to how Chrome-like it was, but that's because I never liked the default Chrome UI. In any case I bring up customization since while I've never left Firefox, their last good out-of-the-box UI was like Firefox 1.4 or maybe 2. Firefox is incredibly customizable though (even if less so now) and so it looks and feels how I prefer which no other browser duplicates out of the box (not even Firefox) and no other browser even makes possible. I guess I'm a "power user" for wanting to fit the tool to my hands rather than my hands to the tool, and Firefox is the only browser that spares a thought for me.
Even extensions in Firefox can't customise the page you see when you open the browser! I used a "new tab" extension, but for some reason Firefox doesn't treat the first tab you open as a "new tab"(1). I quickly noticed heaps of annoyances like that when I recently tried to switch to Firefox.
1. I'm pretty sure there is an issue for this in their tracker but they don't seem to think it's important enough to fix.
Thank you. Unfortunately I've moved on to Vivaldi (happily). If your solution works I didn't find it, nor did any internet searching help me to find it.
I used to use Firefox but it blew chunks at doing intranet authentication. Auth prompts for days. I had to use an extension that loaded an IE browser pane so that I wouldn’t spend half my work day typing my password. I hope they have improved.
By default, intranet authentication (spnego) is disabled in Firefox. There are numerous guides explaining how to turn it on, and it takes all of a couple of minutes to set up correctly after which point it just works.
FWIW IE has this problem too, in that by default it only enables negotiation for unqualified hostnames. If you want people to use an FQDN, you have to go add that FQDN to a list buried behind a couple of advanced dialogs.
There is a difference though: when Firefox was launched, it was still possible to develop a browser from scratch (like Opera was doing back then), and hence lively competition. Nowadays, with WHATWG HTML's feature creep (the HTML "living standard" spec alone weighing in at 1250 pages and 13.3 MB as a PDF, plus tens of CSS specs all over the place, and JavaScript a moving target), that's infeasible for even a nation-state budget.
Opera wasn't a browser from scratch, though: Presto was older than KHTML (and WebKit, etc.).
And really, starting from scratch ten years ago you'd just run into Presto's big failing: site compatibility! Websites rely on all kinds of asinine edge-case behaviour, and if you don't match the majority behaviour, users will leave your browser for your competitors (and site compatibility was, along with crash bugs, always one of the top two reasons for users to switch away from Opera).
In many ways, the vastly larger HTML and CSS specs are a massive boon for minority browsers: when I started at Opera, a large proportion of the Presto team were QA staff who in reality spent almost all their time reducing site compatibility bugs and reverse-engineering other browsers. HTML5 and CSS2.1 made to a large degree that work go away: there was enough movement to converge behaviour (including from the larger browsers) on documented behaviour that reverse-engineering other browsers ceased being something consuming large amounts of resources on all browser teams.
What killed Presto is a variety of things, and the growth of the platform was only a small part of that.
And as mentioned in other sibling comments, all major browsers have rewritten major components at various occasions.
Major browser dev teams rewriting components over year-long periods of carefully planned integration points (with Mozilla even introducing a new programming language along the way) is hardly telling anything about the viability of developing a browser from scratch. Given the powers-that-be in so-called "web standards", by the time you've got anything to show odds are it'll be obsolete.
What would be helpful is if the whole web stack could be organized into profiles (eg. things working without JavaScript, without CSS "4" features, etc.), but WHATWG dismissed the idea of HTML/CSS versions or device profiles proposed by MS (hell they even can't be bothered to version their "living standard" specs). And W3C could start to give formal semantics for CSS (which is kindof "implementing" and verifying the spec) rather than prose about dozens of layout models in an untyped ad-hoc syntax. That is the role of standard bodies, not to lead us into a way-of-no-return for the benefit of very, very few people.
I keep seeing this come up, that it's practically impossible to write a brand new browser. This got me thinking, what would it take to make a better browser?
A browser is something that 1 out of every 2 people on earth [1] use frequently. That's a lot of people! All developers in the world use a browser. Lots of them really believe in open software. Some are 10x developers. A certain percentage are literal geniuses. Exactly one is the smartest developer alive today. I get that it's hard, but smart people mobilized at global scale hard?
Starting from scratch today developers would have better tools, modern languages, and a hindsight view of what worked and what didn't in previous browsers to work with. Wouldn't that make it somewhat easier?
Say the average person loads 10 websites per day, and a less optimized browser requires 100ms more to load each page. That's 415 million hours wasted per year. Say the average person makes $4 an hour, that's 1.6 billion dollars wasted!
If every browser user donated 50 cents, that would be 2 billion dollars. Would that be enough? There are 50 people worth more than 17 billion [2], would one of them bankrolling a new browser be enough? What would it take?
I welcome your attitude, bring it on and I'll be more than supportive of it. But still, I'm maintaining that you can't work against the likes of WHATWG and W3C churning out specs, when they are subverted and financially dependent on Google.
In other words, we're toast ;( But hey, that might be exactly the kind of situation that motivates developers after all.
With my project [1], I'm attempting something less ambitious: I'm trying to re-establish SGML as an authoring format (HTML is based on SGML, and SGML is the only standard that can tackle HTML), to at least bring back a rational authoring and long-term storage format for content that matters and that you'd like to be able to read in a couple of decades still without an ad company or even a failed, over-complicated all-in-one document and app format of the 2010's getting in your way.
IMO writing a better browser is not that hard. The trick is to just focus on reader view.
When you can click the reader button, it makes every website better. Reader view defeats modal dialogs and dickbars. Reader view renders faster than AMP, because it skips web fonts. Reader view always scrolls and zooms without jank.
Build a better browser by embracing the web as it was meant to be: the best document publishing platform. Let the other guys build the world's worst application platform with clippy and toast and the rest.
All the developers in the world combined can not solve a legal problem. You can't implement technologies like Widevine without a license, and if they simply won't give you one [0], you're dead in the water.
While writing rendering engine isn't easy to do, it's extremely easy compared to the HTML part. Even Mozilla isn't in a hurry to rewrite all that code.
Depends what you mean by the "HTML part". The HTML parser, which is the only HTML-specific part, was replaced in Firefox 4, with one implementing the algorithm defined in the WHATWG HTML spec.
The DOM code there's definitely less motivation to rewrite, in large part because there's a lot less benefit to be gotten from rewriting large parts of it (versus layout or style where there's much more entanglement across the codebase).
HTML parsing is not that hard compared to CSS/layout/fonts (or even figuring out layout), a competitive JavaScript engine, and the myriad of APIs and site compatibility problems OP talked about.
My HTML parser uses SGML which is more generic as it takes the HTML grammar (a DTD) as parameter and computes state machine tables etc. dynamically based on it, thus a bit harder, but still very much doable.
Does that HTML parser follow all the HTML5 parsing/error-handling rules, so that it conforms to the spec's behavior for random tag soup full of broken markup? Or are you assuming "clean" HTML?
No, it follows the normative description of HTML as specified in chapter 4 of the HTML spec. The redundant procedural spec for parsing HTML is strictly aimed at browser implementers, and in particular to reach same behaviour accross browsers in the presence of errors. Note that the covered fragment still contains the rich tag omission/inference rules for HTML and other minute details, based on formal SGML techniques, though.
Feature creep seems to be a common failure of many standards. Bluetooth or usb-c to name some others.
World is missing a standard, a good and lean one is created, multiple vendors implement it, there's an initial year of minor incompatibilities but otherwise all is gold and glory, everybody loves the standard. Standard becomes immensely popular so everything supports the standard and worse - the standard starts supporting everything because every vendor just has this one small extension they want to add. After adding thousands of such extensions, suddenly the standard isn't so lean anymore. Now the spec isn't just a single RFC that can be read over lunch. It's a whole collection of documents with thousands of pages, appendices, mandatory extensions and compatibility tests. You need few people employed just to keep up with organizing the documentation. Vendor implementations start becoming incompatible because of too high complexity. Only a few big players manage to stay afloat and they probably like it that way because it raises the barrier to entry and they get to keep their position.
I do not think it is impossible, Firefox alone has rewritten several of its major components at least once.
I see it more as a self-fulfilling prophecy and a constant stream of FUD from naysayers whenever such a thing is merely suggested (with popular topics being that it will never be finished, it will not be secure, if mozilla needs $500m/year how mere humans will ever be able to do it, etc).
I think that a lot of people nowadays forget that almost much every single piece of open source tech that existed since the 90s or early 2000s was started by naive young programmers trying to do something (have you seen KHTML's source code in KDE1?) without having assholes telling them they can't do it. Well, ok, they had some, but nowadays they are WAY more numerous and at the past they mostly came from (what was seen as) "evil corporations" so they were more easily dismissed. Today most people in open source (both users and programmers) dismiss most things that do not have some big commercial entity behind them.
This seems like a really strange position to fight over. OP is mainly complaining about the constant flux of the spec. At the time were KHTML was being implemented there weren't new features being released every week like we have now. In every aspect of the browser.
As a single developer it is impossible to implement a browser that is compatible with today's websites.
> As a single developer it is impossible to implement a browser that is compatible with today's websites.
Then don't make it "compatible with today's websites".
In fact, that should probably be the goal. That is, what should or could "tomorrow's internet" look like?
Think of the "time lag" between "The Mother of All Demos" and it's actual commercial realization: Arguably the Mac, but some might say the Apple Lisa, other's Xerox Star, and still others could pop their own in the timeline - but for the general consumer - that is "wide adoption" - it was the Mac in 1984.
That's a lag of almost 15 years - but one guy managed to see that future, and with some help, pulled it into the past (if you've never watched the demo, and put yourself in the shoes of that time, then you can't easily understand just what it took for it to occur; it's honestly awe-inspiring to me from a historical standpoint, I'm sure there were people in the audience who didn't understand they were seeing the future).
Try to do that, is what I'd propose.
And some people are. Where I believe that future lives is in the idea of the "distributed web" - which honestly is what the internet should have been all along, but apparently we're going to have to drag it back there. Part of the reason it didn't go that route was mainly because of "dial-up access" - the end nodes weren't looked at as "peers", when they should have been, just instead of "always-on" peers, as "ephemeral and temporary" peers. But they were kinda sold differently, and most people weren't made aware that they could be (and should be) peers. But rather, relegated to 2nd class "clients" and "consumers".
Now many people have the available bandwidth to be closer to real peers, run servers, etc - but are instead limited in a variety of ways (most notably by draconian TOS language, that while in many cases is "ignored" - it can be easily dragged out to deny service if and when an ISP feels like it).
I'm not sure the distributed web is the full answer (the full answer would include mesh networks - but there are logistical issues there with those, especially in the United States, that currently prevent them from transitioning beyond, at maximum, "city level") - but it's a start, I think.
> At the time were KHTML was being implemented there weren't new features being released every week like we have now. In every aspect of the browser.
KHTML was being implemented in 1999. That was an extremely fast moving and chaotic time in the development of the web! Browsers were shipping new features left and right, the specs didn't describe at all what browsers really did, and if you fell behind people would quickly switch to other browsers.
Even by 1999 you wouldn't have been able to make a competitive browser on your own, and especially not keep up with the rate of change.
(In the early 2000s, after Microsoft "won the first browser war" and disbanded the IE group, everything slowed way down, though.)
> when Firefox was launched, it was still possible to develop a browser from scratch
Firefox began as a version of the Netscape Suite stripped down to just the browser. The Gecko rendering engine long predates Firefox. No one has launched a full browser "from scratch" in nearly twenty years.
Today is the last opportunity actually thanks to polyfills for IE11. Also it must be modular architecture using several independent libraries. Once one is done, others can use and aid maintenance. But it's still very difficult.
There's not really much of a difference between the web today and the "Best viewed in IE" web, and that's sad
At least back then sites were not as reliant on JS, so I think that's one of the ways it was better; sure, sites often looked different in non-IE vs. IE, but you could still consume the mostly-static content (and what wasn't static was almost always ads...) Now there are far too many "appifications" of sites that shouldn't be anything but static pages, JS is required to render their content, and that JS is often very browser-specific.
There's a difference between now and the 90s/00s. And its worse now.
At least Microsoft's overarching goal was just to get developers to use their platform, by making their platform as useful as possible (even if many of the changes were ultimately misguided).
With Google, there's some of this, but there's also some very clear "we're an ads company and we want the ad experience on Chrome to favor us as much as possible, without regard for the user."
I would say that anyone who has spent an extensive amount of time writing code that needed to work with IE6 or below would disagree with your statement.
At the moment some people develop only for Chrome because it has the most market share. So they deploy their site using the <toast> thing and suddenly people using Firefox are wondering why things are broken. At this point Firefox can either implement the new feature(s) or lose users. And once FF etc. have implemented it suddenly it's on caniuse.com as "works in all modern browsers".
"There's not really much of a difference between the web today and the "Best viewed in IE" web, and that's sad. There's a difference in developer goodwill, and of course things aren't as buggy as they were back then so it overall doesn't feel like you're "stuck" with Chrome like it did with IE, but... you are. You're just OK with it."
I agree that the monopoly power situation is similar but there really is a big difference between IE hell and today's situation.
There is a big difference between one browser having a cool feature that may not be available in other browsers, versus the leading browser strangling everyone in a stasis of mediocrity, which was the case when IE/Microsoft owned the web.
>There's not really much of a difference between the web today and the "Best viewed in IE" web
This is a shallow comment. IE was closed-source, cornered the market and then abandoned all development. They stalled the web for years.
Today all browser vendors are active in the standardization process, open or nearly open source, and collaborate heavily to implement the same features.
Any feature that "only works in X browser" is a result of one browser implementing a feature first, rather than the result of a browser monopoly. For instance prefers-color-scheme was introduced by Safari, than Firefox, and next to-be Chrome.
So yes, for a period of one to two months a site might have "worked best in Safari" as a result of this feature adoption. But drawing a parallel to a web dominated by IE6 is completely ignoring all context of the situation. It shows a complete misunderstanding of how the web has evolved.
If I don't like something, I'm going to talk about it. The plusses, and the minuses. You can't have everything in life and that is the way I veiw everything (although that has little to do with these odd new html tags).
But their view of the situation is completely correct; just because this one feature might be useful (heck, when Microsoft dumped XMLHttpRequest on us that was incredible too), doesn't change the fact that we're now living in a web where Google does whatever it wants, adds whatever it wants to Chrome, and the web is at its mercy. If they wanted to add <blink> it'd get added and supported, and other browsers would have to follow lest they become incompatible.
There's not really much of a difference between the web today and the "Best viewed in IE" web, and that's sad. There's a difference in developer goodwill, and of course things aren't as buggy as they were back then so it overall doesn't feel like you're "stuck" with Chrome like it did with IE, but... you are. You're just OK with it.