Live data from Hacker News

Introducing a new HTML element – welcome

shkspr.mobi

141–150 of 234 posts

Re: Introducing a new HTML element – welcome <clippy>

#141

Earlier quoted context omitted.

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…

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

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

Re: Introducing a new HTML element – welcome <clippy>

#142

Earlier quoted context omitted.

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

Re: Introducing a new HTML element – welcome <clippy>

#143
post #26

Earlier quoted context omitted.

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 an…

> 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 declarat…

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

Re: Introducing a new HTML element – welcome <clippy>

#144
post #77

Earlier quoted context omitted.

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…

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

What version are you using?

Re: Introducing a new HTML element – welcome <clippy>

#146
post #78
post #53

Earlier quoted context omitted.

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…

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.

Re: Introducing a new HTML element – welcome <clippy>

#147

Earlier quoted context omitted.

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

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

Re: Introducing a new HTML element – welcome <clippy>

#148
post #28

Unlike the author, I do not think 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 ? Or even better, don’t add anything - it’s surely just a that needs styling and animating with existing CSS…

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

Doesn't anyone there remember when and got deprecated in favor of and ??

Re: Introducing a new HTML element – welcome <clippy>

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

Re: Introducing a new HTML element – welcome <clippy>

#150

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…

> 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 , and everyone seems to consider it more bad Googleism.

Post reply on HN