Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

and (2020)

danq.me

Post reply on HN
Print view View original

131–140 of 191 posts

Re: <Blink> and <Marquee> (2020)

#131

Post by mrweasel »

rdrd wrote: post #84
donatj wrote: post #21

I was there, 3,000 years ago. I remember fights over whether or not navigation in frames was bad practice. Not iframes, frames. Who here remembers frames? I remember using HTTP 204 before AJAX to send messages to the server without reloading the page. I remember building... image maps[1]... professionally in the early 2000. I remember spending multiple days drawing the borders of States on a map of the country in Dre…

I remember working for a client who needed to support IE6 (with all the insane bugs/quirks/limitations) and I’d despair every time the designers would hand over a Photoshop design with rounded corners. They also needed it to be responsive (at the time mostly just different desktop sizes). Would usually require cutting the corners out and positioning them in table cells. There’s a certain amount of dev resilience you…

We worked with an internal design team, but basically just one UX specialist who has zero comprehension of how HTML, CSS or and web related technologies worked. At one point we where meet with "I don't like that the site blinks!" ... What do you mean by "blinks", we built it, it doesn't blink. Turns out she didn't like that that switching pages would cause the browser to load the next page and in turn there would be an ever so brief moment where the browser would show a blank page while loading the next page. This was in the initial ASP.NET and Ajax days, to the end result was "wrap the whole damn thing in an update panel".

For those who doesn't know the ASP.NET update panel was basically HTMX before HTMX. The browser would do a background request and replace the content of the update panel with the html returned by the background request. Normally you'd just use if for a form submit, e.g. like a comment box. The user puts in their comment, the backend return all the comments, including the new one and the browser replace the current list of comments with the new one. We essentially put the entire site in to the update panel.

Re: <Blink> and <Marquee> (2020)

#132

Post by xnx »

ComplexSystems wrote: post #127
xnx wrote: post #76

Earlier quoted context omitted.

All content on the web should have a unique, linkable, URL. Frameset breaks that.

That ship has long since sailed. We live in a world of web apps with dynamically created content, AJAX, and so on. The main entry point for the app has a URL, and then within the app all bets are off. Same with framesets.

SPAs were a low point, but I've found consistent and linkable URLs has gotten better with developers recognizing the importance due to "SEO".

Re: <Blink> and <Marquee> (2020)

#133

Post by cardamomo »

donatj wrote: post #21

I was there, 3,000 years ago. I remember fights over whether or not navigation in frames was bad practice. Not iframes, frames. Who here remembers frames? I remember using HTTP 204 before AJAX to send messages to the server without reloading the page. I remember building... image maps[1]... professionally in the early 2000. I remember spending multiple days drawing the borders of States on a map of the country in Dre…

I've seen things you people wouldn't believe. Attack ships on fire off the shoulder of Orion. I watched C-Beams glitter in the dark near the Tannhäuser Gates. All those moments will be lost in time, like and .

Re: <Blink> and <Marquee> (2020)

#134

Post by catlifeonmars »

xnx wrote: post #132
ComplexSystems wrote: post #127

Earlier quoted context omitted.

That ship has long since sailed. We live in a world of web apps with dynamically created content, AJAX, and so on. The main entry point for the app has a URL, and then within the app all bets are off. Same with framesets.

SPAs were a low point, but I've found consistent and linkable URLs has gotten better with developers recognizing the importance due to "SEO".

Also crawlers can now evaluate SPAs. Googles crawlers will run JavaScript on the page making the SPA SEO issue much less of an issue now.

Idk if that counts as a low point or a high point.

Re: <Blink> and <Marquee> (2020)

#135

Post by layer8 »

divbzero wrote: post #17

Interestingly, the default doesn’t appear as smooth as a CSS animation would be? Playing with the scroll speed makes it feel smoother: scroll faster than default

I’m pretty sure that originally it was to reduce CPU load, and later was left that way for backwards compatibility.

Re: <Blink> and <Marquee> (2020)

#136

Post by echelon »

okanat wrote: post #126
echelon wrote: post #104

Earlier quoted context omitted.

We should have frozen the web from 2006 - 2010 or so. We had Ajax, lots of modern CSS, but weren't hell-bent on CSSifying and "SPA"-ing everything. Web standards hadn't yet jumped the shark. It's also before Steve Jobs murdered Flash. Killing Flash was one of the biggest mistakes we've made. The modern HTML/CSS/JS stack can't replicate how simple and functional it was. We're easily dealing with 100x the complexity no…

Flash was a bigger privacy hole than HTML5 canvas. I think we need to mandate browsers that block those APIs on default and only enable them via permission. is often used in fingerprinting. So blocking its introspection APIs would already benefit us.

That sounds like a big deal until you realize that nothing was private back then.

Most internet traffic wasn't even over SSL. It wasn't enforced until 2018!

No CORS (first standardized in 2014), no cross-site protection (first standardized in 2012).

Everything was the Wild West.

Flash was fine and could have adopted the same mechanisms.

If Adobe (or the earlier owners) had open sourced the player and the format standard, they could have won and had the best authoring tool for the format.

To this day, Flash is the only downloadable binary bundle format that can still run on your PC after being downloaded. You can't download and SVG animation. It's a bundle of brittle web tech slop.

Re: <Blink> and <Marquee> (2020)

#137

Post by rda2 »

InsideOutSanta wrote: post #68

I find marquee extremely useful, for one reason: HTML injection. I find it helpful to test for HTML injection vulnerabilities because marquee moves, and it's a tag that (almost) nobody intentionally uses, making it easy to identify when an attack works. I also find it helpful to show non-technical people the effects of HTML injection, because, again, it moves. "This moves and it really shouldn't move" is something pe…

I browse Hacker News through a custom aggregator. This post is how I found out it’s susceptible to HTML injection - a (2020) was marqueeing across my screen.

Re: <Blink> and <Marquee> (2020)

#138

Post by atum47 »

You can put a marquee inside a marquee and make the DVD bouncing logo.

Did that on my first day of college, inside an .hta file for windows and blew my classmates minds. #hackerman

Re: <Blink> and <Marquee> (2020)

#139

Post by no_wizard »

catlifeonmars wrote: post #134
xnx wrote: post #132

Earlier quoted context omitted.

SPAs were a low point, but I've found consistent and linkable URLs has gotten better with developers recognizing the importance due to "SEO".

Also crawlers can now evaluate SPAs. Googles crawlers will run JavaScript on the page making the SPA SEO issue much less of an issue now. Idk if that counts as a low point or a high point.

There se excretes to this, particularly if you value speedy vs delayed updates to your indexing

Re: <Blink> and <Marquee> (2020)

#140

Post by timpark »

bornfreddy wrote: post #61
timpark wrote: post #29

The blink tag was, of course, much hated back in the day, so as an experiment, I took the binary of whatever browser I was using (Netscape, I guess), searched for "blink", and changed it to "blonk". Tada, no more blinking!

Yeah, but if someone had used you would get... blonking I guess? :) Nice hack!

Exactly, haha! :) Thanks!
Post reply on HN