Hacker News new | past | comments | ask | show | jobs | submit login
Introducing a new HTML element – welcome <clippy> (shkspr.mobi)
474 points by edent on June 13, 2019 | hide | past | favorite | 227 comments

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.

> Chrome is the new IE

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.

It is nothing remotely like the bad old days. I'm assuming you never had to support IE6.

I did. I remember when NN was big and IE was an afterthought. I remember when IE6 came onto the scene. I remember it all.

It's nothing remotely like the bad old days. You are correct.

It is however bad new days.

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!

IE6 was good until it wasn't anymore.

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.

No you didn't. You had to code exactly one copy: for IE6. Nobody cared about anything else.

Just like nowadays more and more pages only get coded for chrome and might or might not work on Firefox.

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.

It is, in fact, worse. We didn't have to support mobile platforms back then.

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.

Chrome still has some competition. So does AMP, if you count, you know, HTTP.

search and youtube are the two things I can think of.

> Devs old enough to recall the halcyon days of IE know it was quite different...

I'm old enough. It's not different. Chrome is the new IE.

> 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.

> they announce new products that are only known to work on Chrome initially.

Can you show any examples of these "features" that are forcing the hand of other browsers?

> think Outlook.com and the introduction of AJAX


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.

I'm old enough to remember there was a simple fix. Badges of honor you might even say!

"This website supports Netscape Navigator 4."

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.

It was a joke.

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.

With Chrome, you also get Chromium, and the ability to see inside(and contribute!) to development. This did not exist in the IE-dominated era.

Link to chromium dev: https://www.chromium.org/getting-involved/dev-channel

Out of curiosity, how much flows from Chromium to Chrome, compared to vice-versa?

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, and I'd caution others to think carefully before doing so.

> 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.

IE6 did none of that.

> IE6 did none of that

IE6 had just different users than Chrome has.

But MS did listen to them, even too much actually.

MS had their customers intranet developers to make happy, Chrome has its giant father, Google, the AD company.

Chrome is much worse in perspective for users freedom.

I try switching from Chrome to Firefox at least once a year, but the UI design keeps me firmly entrenched as a Chrome user.

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.

I have window title bar, minimal location bar, and tree style tabs (collapsible/hideable). The UI is about as minimal as it can get :)

Not sure how legit this is, I'm with another commenter, I don't care for the Chrome UI but maybe this might help:


Looks like somebody updated the Firefox Quantum UI to look more like 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.

I felt the same but honestly you get used to it in a couple days. I'm never going back!

What aspect of the Firefox UI bothers you?

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.

> No automatic keychain integration for login forms.

Chrome also stopped doing this, AFAIK.

Fun fact: I was subscribed to a firefox ticket "Password manager should support OS X Keychain" which is 18 years old, it got closed some months ago. https://bugzilla.mozilla.org/show_bug.cgi?id=106400

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.

> 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.

Same experience for me on Chrome on macOS too, so... You sure you didn't change those defaults somehow?

I usually open new tabs with Command + t or Control + t on Linux / Windows.

> 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.

I'm so confused. I'm on Chrome for mac right now and half of those things seem to not exist in Chrome either.

- The 'x' is on the right of every tab.

- When I press '+', the cursor ends up over the new tab - I cannot immediately click '+' again.

- Pressing esc does not do anything for full-screen mode.

> 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).

The close button has been on the left for years on mac?

What version are you using?

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:


On iOS, I keep trying to pull to refresh pages, but in Firefox it’s a specific button. But this is something that I could get used to.

> 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.

Note: this is different b/w the desktop and iOS versions too. The desktop seems to have gradually gotten better as it’s been trained more.

(And I have Firefox sync setup)

Type ‘news’, use the arrow keys to select the offending entry, and hit delete.

Just type news<space>y then until it gets used to it.

(And on a general note: some people here might want to verify they haven't touched the settings;-)

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?)

[0] https://bugzilla.mozilla.org/show_bug.cgi?id=1080682

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.

> "table.sort"

Just curious, are you developing in Lua? That would be my guess from that string.

Yes, I am actually. I'm trying to rewrite a game's codebase to use LuaJIT/LOVE for modding support.

Simply put: There's too much of it.

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).

FYI: I use Firefox for idealogical reasons.

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.

It used to be in settings. You could typically choose between something like:

- restore pages from last time

- start page (input url)

- default new page chrome

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.

This is and isn't an issue.

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.

(I worked at Opera a decade ago.)

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?

[1] https://en.wikipedia.org/wiki/Global_Internet_usage [2] https://www.businessinsider.com/richest-people-world-billion...

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.

[1]: http://sgmljs.net/blog/blog1701.html

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.

> What would it take?

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.

[0]: https://blog.samuelmaddock.com/posts/google-widevine-blocked...

What would it take to reverse engineer Widevine?

I don't know much about the law, but wouldn't reverse engineering Widevine be illegal, as it is protected by DRM?

Firefox has rewritten its entire rendering engine, and its entire CSS engine. Writing a browser is incredibly hard, but not infeasible.

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.)

Not as a single developer, but i'm certain a team of developers can do it even without having some big corporation behind them.

> 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.

Simply put: Don't write for chrome, write w3c conform.

Or better: Use standards which match most browsers at caniuse.com

That only works if everyone does it.

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".

> that only works if everyone does it

which is probably why OP is suggesting it

Even better : Develop for Firefox / Gecko in mind, and ignore Chrome / Chromium / Blink / V8 / Node.js

"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.

This is how you get to that situation. It's the "extend" in "embrace, extend, extinguish".

>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.

> 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.

I don't know - I kind of figured that was part of the joke - I thought it was pretty clever.

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).

You must have missed the post where we all took a blood oath to stick to standards when we develop.

Unlike the author, I do not think <toast> is a good idea. Elements are supposed to express semantics, but this just suggests behaviour. Not very descriptive behaviour either - since when does actual real-life toast smoothly rise and fall again? Possibly from the ceiling or coming in from the side?

Why not just call it <notification>?

Or even better, don’t add anything - it’s surely just a <div> that needs styling and animating with existing CSS and JS?

The name is the least concern here.

But it's called a toast because that's what many UX people have called it for years, because it pops up and toast pops up. It's a specific kind of notification, not any notification. (There's also "butter bar" and "modal dialog" and so on.)

And yes it's behavior, but <input> and <button> and <select> and <textarea> define plenty of behavior too.

I think the big concern here is standards and process... not its name or concept in themselves.

> But it's called a toast because that's what many UX people have called it for years, because it pops up and toast pops up.

Thanks for this, it hadn’t occurred to me why they chose this name

Agree name isn't primary concern, but by your own definition shouldn't it be called <popup>?

I've read the explainer but I still don't think I understand what this toast element is supposed to do. Also, am I correct in understanding that it is pretty much useless without javascript?

> Why not just call it <notification>?

In Android land, a "toast" is a particular implementation of a notification.


So if nothing else it's shockingly bad semantics. If Android called them Turds, would that be any better or worse semantically?

I imagine that would be a notification that slowly drops down, then clips off and falls below the bottom of the screen

Call it what it is: a pop-up. You know, the thing we've spent years trying to block on the web because it's an anti-pattern that malicious actors abuse to steal clicks and make interaction harder.

A "toast" means a few words of salutation. That's the purpose of the Toast UI element. A user requests an action, the action returns a successful response, the user receives a message consisting of a few words announcing the success.

Just because you are oblivious to the concept it doesn't mean it's bad. It just means you need to learn something before blindly asserting that stuff you don't know and are not familiar with is for some reason comparable to dog shit.

The point is, "because android does it" is terrible reasoning for naming the thing.

It's exactly the point the author here was trying to make. Google does not control the web or define HTML standards in a vacuum, nor is it the focal point of the internet.

> The point is, "because android does it" is terrible reasoning for naming the thing.

That was not the point at all. The point is that the concept of a toast exists and is already widely established. Android is one of those platforms. That's it. I fail to see the point of bitching about Android as if that would undo the dissemination of this particular UI pattern. I mean, Microsoft adopted the concept. Do you expect to undo that by bitching about Windows 10?


Toast has been a thing long before Android: https://en.wikipedia.org/wiki/Pop-up_notification

The connotations of "toast" as salutation are even worse here; hardly anything is similar between giving a toast and a transient message (that's in practice usually about failure, not success) showing up at the bottom of the screen.

Out of all the reasons why they could've named it "Toast", the most reasonable one to me would be "because it's another kind of a pop-up notification, and the phrase 'pop-up notification' is already taken".

> The connotations of "toast" as salutation are even worse here;

I don't understand your problem with the concept. It's pretty clear what it means and how it operates, and the UI concept has been extensively disseminated and adopted, not only in web-base UI and UX but also in GUI toolkits for mobile (android) and desktop (Windows 10).

Exactly where are you having problems understanding the concept?

>Exactly where are you having problems understanding the concept?

The concept is fine, I’m sure everyone understands that. The conflict is your assertion that it comes from the meaning related to “a small speech given while raising one’s glass.” It comes from the “bread that has been lightly re-cooked” meaning. Toast notifications would slide up from the bottom of the screen, then sink back down – moving like a piece of bread in a top-loading toaster. (The most common kind, at least in America, at least at the time.) This leads to bad semantics, on the web.

Here’s a citation from 11 years ago describing that: https://www.techrepublic.com/forums/discussions/whats-a-toas... I’m sure it’s even older, but “MSN Messenger” is my oldest personal reference, so I wasn’t sure what else to search for.

> since when does actual real-life toast smoothly rise and fall again?

Perhaps the inspiration came from the Sunbeam Radiant Control toaster:


Unlike modern toasters which rudely attempt to catapult your toast into orbit, the Sunbeam gracefully and almost silently presents your toast with the love and care it deserves.

OK, getting off topic, but: we had this toaster when I was a kid, and I hated everything about it. This is the worst toaster I ever used.

Getting it to engage was super finicky. I never saw anybody get it to work on the first try. You often had to whack it down pretty hard to make it work, while other times a light touch was sufficient. You could tell when someone was using it from across the house because you heard a metallic "whang, whang, whang, whang!", at various volumes, as they tried to get it to trigger.

Going up was super slow. (In his video, he shows it at "6x" or "12x" speed so viewers don't fall asleep.) Who would ever want that? It's done toasting. Don't make me wait 10 seconds to get my toast. Lots of singed fingers from impatient people reaching in to get their food.

The sensor wasn't very good, either. There was a razor thin margin where you'd get reasonable toast, and it was almost all the way to the "light" end. At even 25% to "dark", you'd get a block of charcoal. I'd set it all the way at "light", and toast my bread twice, if needed, because that was safest.

Lack of a manual up/down lever makes everything worse. It means you need to use the special "ONE SLICE" slot when you only have one slice. It also means if you see your bread start to catch fire (yeah), there's no easy way to get it out in a hurry. You could push the lightness all the way to "light" and hold it there (I think that was the official way), but that was unreliable. Usually, we'd just unplug it.

Also, as he notes in the video, the bread guides don't move so about all you can fit in here is a small generic white slice, and the outside gets as hot as the inside so be careful not to touch it.

This is the 2013 Mac Pro of toasters: very pretty, very clever, and a thermal nightmare. If I had infinite money and space, I'd buy one to show off, and never use it.

> You could tell when someone was using it from across the house because you heard a metallic "whang, whang, whang, whang!", at various volumes, as they tried to get it to trigger.

Lolol....reminds me of our first family toaster from the 70's.

But my dreams of owning one of these are now shattered :)

More importantly, the slider on it doesn't control time but rather doneness. It gages the reflectivity of the surface to determine how brown the item has become, meaning my frozen Eggo and my refrigerated sliced bread both come out how I want them without having to play with the dial each time.

But my, does it feel more fragile than my old Chinesium toaster!

I never even realized that that's why it was named toast. I thought it was named after the act of giving a toast (a speech).

Completely agree, toast implies style and behaviour. That’s not what HTML is.

what?? I thought he was just snarkily referring to some proposal/tag that he didn't want to actually name, likely <portal>. <toast> is a dreadful name.

Doesn't anyone there remember when <bold> and <italic> got deprecated in favor of <strong> and <em>??

Because it's cute and web standards need more tat.

Note, this is a sarcastic opening to a serious proposal — that Google not dump elements into the WHATWG HTML spec without user discussion and use cases:

    The way Google has gone about this seems to be…
    1. Ooh! I have a cool idea!
    2. Other people in Google agree with me!
    3. Other Google projects could benefit from this?
    4. Let's stick it in Chrome!
    5. Oh, guess we should tell the community what we're doing.
He thinks maybe <toast> is fine (pattern of a notification container showing up and disappearing again makes sense), but concerned how it’s been introduced.

I don't see how toast is different from the countless proposals for new declarative UI HTML elements that have been submitted over the years, and ignored or withdrawn (such as menu/menuitem), other than it coming from Google (and maybe Google not wanting to expose that functionality via a JavaScript API?) The reasoning against new UI elements has always been the same - they're inessential when JavaScript is needed anyway. I think this incident should make it very clear to everyone that HTML as seen by "browser vendors" (Google) is a very different thing from HTML the markup language as used all over the world for personal, business, medical, legal, and cultural documents, and which demands community representation and participation.

> I don't see how toast is different from the countless proposals for new declarative UI HTML elements that have been submitted over the years

The difference is that if Google introduces a new tag and starts using it, then every other vendor must implement the tag, or the [potentially popular] applications that use it [made by Google] will simply not work.

That's not a power that "countless proposals for new declarative UI HTML elements" have.

> I think this incident should make it very clear to everyone that HTML as seen by "browser vendors" (Google) is a very different thing from HTML the markup language as used all over the world for personal, business, medical, legal, and cultural documents, and which demands community representation and participation.

Google is not a browser vendor; they do not sell web browsers. Google sell advertising, and it's absolutely critical to Google's future to get everyone on the only web browser that has crippled ad blocking and privacy capabilities.

> The difference is that if Google introduces a new tag and starts using it

But Google isn't starting to use it? They're implementing it in Chrome to see whether any difficulties would arise when implementing the proposed API. If they do, that can serve as input. If not, input is still possible?

If Google implements something an Apple doesn’t on the iPhone then what?

iOS has less than 15% market share globally. https://www.idc.com/promo/smartphone-market-share/os

That’s a nice and (irrelevant) statistic. No one targets a “global” audience with a website. If I’m targeting North America, Europe, or Japan, why do I care that a billion people in India use Android phones? Even in countries where iOS is a sliver of the overall population like China and India, if you want to reach the affluent population, you still need to target iOS users.

How fast do you think someone creating a website in the US will get fired if they said they are going to ignore iOS users because iOS is only 15% of the global market?

If iOS didn’t matter do you think Google would be paying Apple a reported $9 billion a year to be the default search engine?

North America is about the only significant market where iOS has a ton of market share, and the world is not North America. If you're targeting Europe, iOS has only 25% [1]. Not sure why you said Japan instead of Asia, but iOS market share there is less than 15%; even worse than it is worldwide [2].

People don't have their browser choices etched in stone, and Google's services are a powerful form of persuasion. If they work in Chrome but not other browsers, people will just switch to Chrome.

It's not 2009 anymore. iOS simply doesn't give Apple the power to stop Google here.

[1] http://gs.statcounter.com/os-market-share/mobile/europe

[2] http://gs.statcounter.com/os-market-share/mobile/asia

Because “Asia” includes a lot of poorer countries. People go where the money is.


And that still doesn’t negate my other point, if you exclude iOS, you miss the most affluent users. Who do you think is the most profitable market segment? People buying $50 Android phones or people buying $700 iPhones?

Apple doesn’t have to “stop” Google. If Apple doesn’t support it, either web developers wont use it because no one is going to give up their most affluent customers or they are going to be forced to write an app.

Again, if I’m writing a website for the US, why do I care about the worldwide market share?

> And that still doesn’t negate my other point, if you exclude iOS, you miss the most affluent users. Who do you think is the most profitable market segment? People buying $50 Android phones or people buying $700 iPhones?

If your service is free and you monetize by selling users' data, they're all the same. You don't have to sell things to your users to make money. Just look at Google!

> Again, if I’m writing a website for the US, why do I care about the worldwide market share?

Again, the world is not the US. If I'm making a website for Europe or China [1] or South Korea [2] or Vietnam [3], why do I care about the US or Japan market share?

[1] http://gs.statcounter.com/os-market-share/mobile/china

[2] http://gs.statcounter.com/os-market-share/mobile/south-korea

[3] http://gs.statcounter.com/os-market-share/mobile/vietnam

If your service is free and you monetize by selling users' data, they're all the same. You don't have to sell things to your users to make money. Just look at Google!

Because users in the rest of the world who are not as affluent aren’t as attractive to advertisers. You are already seeing it with Google. Google just announced a year over year decline in net income as ad sales increased a lot slower than acquisition costs.

Google doesn’t “sell users data” it sells access to users to advertisers based on their data. Advertisers aren’t willing to pay as much for users data for much less affluent users


Again, the world is not the US. If I'm making a website for Europe or China [1] or South Korea [2] or Vietnam [3], why do I care about the US or Japan market share?

If you combine South Korea and Vietnam you probably have the GDP of a midsize state in the US. In China, if you want to reach the growing middle and upper class - you still have to support iOS.

"only" 25%? It's ok to ignore 25% of your users?

> If they work in Chrome but not other browsers, people will just switch to Chrome.

On iOS, Chrome is just a wrapper around WebKit. You can't ship third-party web rendering engines on iOS. So if Apple doesn't implement this tag for Safari, Chrome on iOS won't have it either.

>"He thinks maybe <toast> is fine (pattern of a notification container showing up and disappearing again makes sense), but concerned how it’s been introduced."

They really should have resurrected the blink tag and added a property for the number of iterations required.

...I do not need more new age HTML tags. If <toast> doesn't by default make a toast, it's useless. If I need to style it, I'll just make a <div> or <span> and do my thing.

That's fine if you're just worried about visual representation. But when you want to provide semantic meaning—for the visually impaired, search engine bots, and other non-traditional users—you want to convey more meaning than a div or span alone.

Of course, there are other ways (such as ARIA attributes) to accomplish this.

How brown is this toast, might I ask?

And from whence comes the bread?

The front-end in recent years has become an unintelligible mess between developers obsessing over toast (with no toaster in sight), and Hamburgers... Am I supposed to make a UI or order a meal?

And <clippy>? Did the mischevious little paperclip finally come back to irritatate me by making the noise of tapping on glass from an LCD screen?

From the chromium forum:

"Intent to Implement: Toast UI element"


>Firefox: No public signals

>Edge: No public signals

>Safari: No public signals

>Web developers: Positive (previously expressed privately; we've encouraged them to make their interest public on the WICG thread)

So basically, nobody at Google talked to anyone about this, asked only google engineers and then pushed those mentioned google engineers to make postive comments in the standards thread? And none of the other browser know shit about it?

What the fuck?

This is the start of the standards process. Intent to implement does not mean intent to ship, only that an engineer want to start writing some code. It's the public signal that the team is interested enough in this idea to prototype into the Chromium codebase, but it will be behind a flag.

The standardization process will undoubtedly change the shape of the thing altogether, or it could not even make it into the HTML spec.

One engineer shared the idea yesterday [1] of introducing a new element in Chrome behind an experiment flag to play with and you are mortified that Mozilla, Microsoft and Apple haven't responded with an official position within 24h?

[1] https://groups.google.com/a/chromium.org/forum/m/#!msg/blink...

The new reality, what people were talking about for a while now. Google owns the web now, they do whatever they want with it - and what they want is primarily improving their advertising revenue.

Every time I mention that Chrome is the new IE, people on HN keep saying that it is not true because IE was bad and Chrome is good.

Have these people and the google developers behind Chrome considerd that maybe they are the baddies?

It was frequently said that /at the time of release/ ie6 was better and more standards compliant than the other web browsers. Then it was left to rot for years.

Perhaps notably, it was actually faster and had lower memory usage than Firefox for a while (Firefox had many leaks). The issues were security, standards and NO TABS!

... Honestly if MS hadn't been so unbelievably deaf to users and web developers, Firefox and Chrome may have never succeeded. If Google doesn't completely screw up, Chrome won't go the way of IE. Maybe messing with adblockers qualifies?

For another and possibly more egregious example, look at Chrome's <input autocomplete=""> handling [0].

[0]: https://www.reddit.com/r/programming/comments/ar1qj1/x/egl52...

The user (via their user-agent) should be in complete control of autocomplete, and sites that think otherwise are broken. Mechanisms to specify the semantic nature of a field are great; by all means, make it easy for a user-agent to know what to fill in. But "autocomplete=off" was originally invented because a few large sites (archaic bank sites of the same type that did browser detection and rejected any browser they didn't recognize) wanted to prevent users from using their browser to remember their password. That's not something the site should have control over.

Ignoring "off" isn't so bad, though it could be smarter. Ignoring everything a site says about the nature of a field is awful. I shouldn't have to resort to weird hacks to get chrome to stop picking a random field on a form and pretending it's a username.

Unfortunately, it's not just Chrome doing stupid stuff with auto-complete.

The latest Safari (bundled with Mojave) tries to auto-complete email addresses using your address book. That's not at all a bad idea, except that like most things Apple of late, the implementation sucks. When you give the input box focus, it opens up some sort of weird dialog prompt, which pulls you out of full-screen mode if you had it enabled. Really messed up our 3D web viewer.

Someone who knows more and is more involved with all of this stuff should consider creating a site that documents all of these times Chrome has either actively broken standards (versus just "not being up to date", which every browser is guilty of and more alright) or actively pushed new standards seeking to strongarm other browsers into support. It would be very valuable to have a clear list as evidence.

I guess Microsoft's attempt to use their superior marketshare to kill web standards back in the 90s is too long ago for the irony of this to resonate.

Maybe MS wants to reconsider stopping development of Edge. I think it might give them a lot of positive publicity without astroturfing.

If google is the new Microsoft does that make bing the new google? I suddenly have the urge to try it for the first time.

Sadly, no. Any startups in the search engine business ?

The <toast> element might not be controversial, but the <portal> element certainly is, as seen recent discussions: https://news.ycombinator.com/item?id=19866584

With some UIs on the modern web, I’d love for clippy to appear and tell me what to do

"You seem to be having some trouble. The text over here is clickable, but the text right next to it, which looks basically the same isn't. Simple, right? I love 'buttons'!"

"You seem to be having some trouble. I find clicking on everything randomly until you figure out what each piece of the web-page does works best for me!"

"You seem to be having some trouble - have you tried using this website on a phone?"

Surely the last one should be:

"You don't seem to be having _enough_ trouble - have you tried using this website on a phone?"

"Tip: Long-form text entry works best on a 5" or smaller screen!"

It looks like you're having some trouble understanding the purposes of our many different circular icons with squiggly things inside them, would you like some help?

No thanks but sensible alt attributes and hover labels would be a great start ;)

How can we rehabilitate hover labels (and alt-text) when you would also expect a significant fraction of visitors using touchscreens ?

A familiar face in this brave new world of hamburger menus and hieroglyphs!

Reminds me of this music video https://www.youtube.com/watch?v=b4taIpALfAo

Ah great, will reduce code bloat and the need for https://www.smore.com/clippy-js

Chrome is garbage UI-wise, is not faster than Firefox or Safari as far as I can tell, and everything I use works fine in both those browsers. I do plan to have the Chromium version of Edge installed for the odd site that might be buggy without Chrome and I think that should be good enough.

> I think the chaps at Google probably think they're the good guys. That they're doing the web a favour. That users love them.

This. Apple is in this self-reflecting bubble too. Companies that start off user-focused and get big often become thoroughly narcissistic.

We had exactly this with the <portal> element https://news.ycombinator.com/item?id=19866584

It gets shipped in Chrome (often without a W3C spec or substantial discussion with other stakeholders), and then other browser vendors are forced to play catch up.

So, uh... fun web history time... this actually kinda existed.

When Internet Explorer 4 or 5 was released, Microsoft was in full-on Embrace and Extend mode, on their way to Extinguish. One of the ways they tried to appeal to businesses (and one of the ways IE4/5-ish ended up being installed well past its best-by date in certain places) was a technology they called ActiveX, basically a brushed up and simplified COM. (The "X" here was from DirectX, which they were trying to market all together; IIRC technically the Agent had nothing to do with DirectX.)

And one of the ActiveX objects they released for this functionality was, basically, Clippy. It was called the Microsoft Agent [1]. It included a number of characters, but you could bring up the real, actual-factual Clippy in Internet Explorer. You could also use text-to-speech to actually speak to the user. It had an API that allowed you to trigger certain pre-cooked animations, move it around the page, etc.

In an advanced mode, you could also specify your own graphics files. It also allowed you to specify graphics for something like 5 different mouth shapes, so you could reasonably lip-sync your new wizard object. I did this to my University's logo back in the day.

I say it "kinda" existed because, technically, this wasn't its own tag. It was an instance of the OBJECT tag [2]. But there was a time where at least in Internet Explorer there literally was HTML you could write that would put the literal Clippy on your web page.

A gallery of the available characters: https://www.youtube.com/watch?v=Rb9yBfDLjsI

I didn't find any videos of the Clippy character used in a web page, but it shipped in the default control, I'm fairly sure.

I never encountered the Microsoft Agent in the wild.

[1]: https://www.youtube.com/watch?v=UoCiSRQGJX4

[2]: https://docs.microsoft.com/en-us/windows/desktop/lwef/access... - "[Microsoft Agent is deprecated as of Windows 7, and may be unavailable in subsequent versions of Windows.]" "To keep Agent running between pages (and thereby keep a character visible), create another client that remains loaded between page changes. For example, you can create an HTML frameset and declare an tag for Agent in the parent frame." Remember frames?

"a technology they called ActiveX, basically a brushed up and simplified COM. (The "X" here was from DirectX, which they were trying to market all together; IIRC technically the Agent had nothing to do with DirectX.)"

This reminds me, one of the small enduring legacies of the 90s X-TREME! craze is that Microsoft still does a lot of marketing around the letter X, even today, like the XBox. And that goes back to ActiveX and DirectX being named in an era where that was intended to make Microsoft sound Hip and Cool and With It. I suppose at this point the XBox has transcended this, and is now just a name.

> I never encountered the Microsoft Agent in the wild.

Then you missed out on the silly games I wrote for it, or the way I got around having to speak my own class presentations by having PowerPoint narrate itself. (I wish I had more videos of that stuff that I did in school given that deprecation has bit rotted it all.)

Also, you never got accidentally talked into installing ~malware~ "friendly user assistance and downloader tools" like Bonzi Buddy.

"Also, you never got accidentally talked into installing ~malware~ "friendly user assistance and downloader tools" like Bonzi Buddy."

Ah, yes... clarification: I never encountered it in the wild on a webpage that wasn't specifically about the Microsoft Agent. I did have a couple of commercial programs that used it, though nothing huge.

It did require a machine with what at the time was a generous amount of RAM to handle everything that spun up to run that thing. Nowadays, of course, it would be nothing, lost in the noise of the fluctuation of your Slack window, but at the time, megabytes of RAM were still a pretty big deal.

It is true I never installed Bonzi Buddy, but I was aware it used the Microsoft Agent. ISTR someone thinking it must take a ton of programming to make that happen, and I actually showed them my animated school logo and how little code it took to prove the opposite.

A lot of people saw Agents (and Bob before it) and expected Alexa/Siri/Cortana-level interaction. Agents were very good in relatively simple animation techniques at conveying an outer complexity that belied the simplicity of most of the actual code written for them.

(That's part of why the "games" webpages I made with them, and the PPTs as well, impressed people a lot more than the rather rudimentary "screenplays" I was actually writing them as felt to me. I felt like I got more credit for that work than I probably deserved.)

I think a lot of people kind of assumed that that level of interaction did exist and was happening behind the curtain, hence some of the very loud and vocal disappointment with Agents, especially in the Office Assistant form that they were never smart enough. I think it was an uncanny valley effect between user experience and user expectations.

It's somewhat ironic that one of the reasons stopping us from applying as much animated "personality" to Alexa/Siri/Cortana seems to be that residual dislike of Agents/Office Assistants despite that in some cases at least it seems like we are ever closer to getting past that uncanny valley.

But, also, Clippy was using suboptimal tech, when they could have had a better version: https://machinelearningagents.com/2009/08/31/lumiere-project...

Similarly interesting, it's also interesting to note that even the Office Assistant animation engine and support for text-to-speech and speech-to-text was extremely stripped down and underpowered compared to the Agents engine bundled with Windows. One more of those areas where the Office team needing to support older versions of Windows and other platforms pushed them to use a half-baked fork of the full Windows feature rather than just rely on a Windows feature.

(It's interesting to see even today which Office features are getting UWP treatment and how, with the most interesting part of "how" being how much they are moving to React Native.)

Wow! Thanks for the history. I remember Polly The Parrot - I think as part of an early MP3 player.

It’s crap like this why I abandoned front end dev. I’ve not heard of <toast> before and as other commenters mention, the semantics are terrible. Binding externally OS/platform specific behavior to an agnostic browser tagset is an abomination.

I'm about as big a Firefox fanboy as they come, but... I don't understand the problem here?

The Chrome devs are thinking about whether a <toast> element would be useful. They float the proposal early on, and announce that they will implement (not ship! Web developers cannot use it) it to get some real-world experience with that to inform its design.

Still plenty of time for people to get involved, make objections, allow refinement, etc. Or am I missing something?

Just for the record. I am not ok with a toast element. It has no place in HTML at all.

I have a really hard time understanding why anyone would want it.

I never knew how much I wanted a <clippy> tag to put on websites until now... and I'm super disappointed this blog was a ruse.

Google also proposes a new toggle switch control element for html. A lot of new stuff coming from Google. Will Safari and Firefox give up? https://discourse.wicg.io/t/proposal-a-toggle-switch-control...

The <toast> element should be implemented this way as well.

Clippy should refer to how every app on your smartphone harvests what's in the device's clipboard for their own perusal.

Thought <toast> was about IoT light kitchen appliances. Turns out it's about asking will a person accept cookies. <clippy> element plus a $30 home speaker is the intended norm, except "Clippy" is now powered by the cloud, and our favorite foods have become digital identifiers.

This example would work better if they were pointing out an addition that really sucked.

Yes - google has been pushing web forward with QUIC and many many other elements.

Seeing Microsoft and other pushing back on something like toast (IE was a crapshow of stupidity for developers) is ironic. toast is going to be welcomed.

The problem is that microsofts additions are things like clippy or cortana in windows which few people want. Seriously, look at windows 10 and the cortana addition (forced in many cases) and ask -> did users WANT this, do users LIKE this.

Toast is going to be picked up happily. If microsoft tries to jam Cortana down IE users throats they are going to be in for a rude surprise.

The reason for google's dominance is in part because of how seriously they have taken the browser.

> Toast is going to be picked up happily.

Obviously YMMV and anecdotes isn’t data, but nobody I’ve seen here on HN cares about <toast>, and everyone seems to consider it more bad Googleism.

I can't remember when/if I've ever seen a "toast" UI notification pop up, either on desktop or mobile. Somehow a UI that's very rare, should be in the standard? Esoteric AF.

Another thing that scares me is how few people are involved in these standards. You will always see the same two or three people in the discussion of every standard.

I agree. It is mostly the people who have employers rich enough to sponsor them. Or some very dedicated amateurs doing it out of passion.

Some developers seem to think that "modern" web development is the same as using new features. (meanwhile they use old design paradigms and architecture)

honestly pretty devastated that there isn't actually a new <clippy> tag

Hello! It looks like you're reading HN - would you like help with that? chuckles

I foresee a great future for the <clippy> markup. So much friendlier than the bland <track action=spy> tag normally used.

There's little difference between <toast> and <marquee>.

Out of the loop and unable to Google it, but whats the toast tag?

"Fear not my friends! I don't work for MS and this isn't a real proposal."

Bummer :-( Is there a free JavaScript library that does that, by any chance? I miss clippy.

I do feel there is a real missed opportunity in not providing a skin for Cortana in Windows 10 as Clippy. Although I always liked the little Einstein guy better.

I find it interesting that part of the reasoning for the <toast> is this:

"Many libraries in a variety of frameworks implement a version of toast (see research), but the web has no built-in API to address the use case." [1]

One thing I would love to see as a browser handled web standard is the cookie notice and gdpr opt-in for a given web page. Every European site has a requirement to include that if they use cookies or ask for personal data, but there is no method of making it a web experience across the web.

Unless I can do this of course:

    <button>Accept cookies</button>
[1] https://github.com/jackbsteinberg/std-toast

'Me and my colleagues at Microsoft have decided'. 'Me' as a subject pronoun?

I read it—hilarious. Thanks. "move fast, break things" really got me.

'Me and my colleagues at Microsoft have decided'. Me - has decided?

I love it!

It probably would have helped enormously if they had given it a professional name other than "toast".

Toast is the official ux name for a popup notification.

Using the name "toast" for this is equivalent to emojis and has no place in professional software and its specifications.

Very clever move.

All other browser vendors put a lot of effort into making their browser better, and <CLIPPY> could very well mark the end of Google Chrome's monopoly--with what I guess is a pretty trivial feature to implement, in comparison.

I'm switching to Edge if I can have Clippy back.

As long as clippy isn't used to shovel adware, I'm down with that,

Applications are open for YC Winter 2021

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact