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

151–160 of 191 posts

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

#151

Post by AlienRobot »

atesti wrote: post #91
Timwi wrote: post #73

Earlier quoted context omitted.

I developed web software with frames and I thought it was perfectly fine. To this day I still don't understand the issue with frames. People sometimes mention accessibility for screen readers, but nothing more specific than that, so I still don't know what the actual problem is.

If you right click a link and open in new window (or middle click), the frameset was gone and only the piece in the frame was visible. Also you could not bookmark anything. I remember doing a frameset per content frame url automatically and also redirecting to that frameset from inside the page via javascript if the content frame's url was directly opened.

If browsers got around to actually implementing basic features on browser level like making a frame navigation work instead of coming up with new CSS properties that nobody is going to use we could be all building websites without any javascript.

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

#152

Post by username223 »

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!

Binary editing was/is good fun. I remember replacing "__gnu_warning" with "__gnu_whining" to quiet some dumb nannying around gets(). Yeah, sure, buffer overruns, but if I'm writing some throwaway program, I can just not overrun the buffer.

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

#153

Post by GuB-42 »

echelon wrote: post #104
Timwi wrote: post #73

Earlier quoted context omitted.

I developed web software with frames and I thought it was perfectly fine. To this day I still don't understand the issue with frames. People sometimes mention accessibility for screen readers, but nothing more specific than that, so I still don't know what the actual problem is.

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…

Adobe killed Flash by letting it die. It had plenty of issues, none of them unfixable. Adobe didn't fix these issues (security, accessibility,...) all while keeping everything proprietary. It was unsustainable and unfortunately, Flash had to go.

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

#154

Post by sparkie »

satiric wrote: post #3

Considering the marquee tag works in basically all browsers [1], has anyone here actually found a good, unironic use for it in today's world of crazy CSS animations? [1]: https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/...

They can be useful in a tabbed interface. Since the width of a tab is limited, and may not be large enough to fit in the text, scrolling the text in the active tab title may be better than hovering to show a tooltip (Though we should use the tooltip for the inactive tabs).

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

#155

Post by DoctorOW »

moralestapia wrote: post #149
DoctorOW wrote: post #56

Earlier quoted context omitted.

It's really simple, moving text is hard to read. As an example, turn on the local news (bear with me, I work for a TV station). You'll notice the scrolling ticker is likely simplified to focus on one headline at a time, with more pauses in between.

So, it's bad on web but good on TV?

The opposite. It's been phased out of TV, (more pauses, less scrolling text) around the same timeframe that it phased out on the web. I threw together a visual comparison: https://gifrun.azureedge.net/video/4e99ff8b27414bbb93c3cc297...

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

#156

Post by moralestapia »

DoctorOW wrote: post #155
moralestapia wrote: post #149

Earlier quoted context omitted.

So, it's bad on web but good on TV?

The opposite. It's been phased out of TV, (more pauses, less scrolling text) around the same timeframe that it phased out on the web. I threw together a visual comparison: https://gifrun.azureedge.net/video/4e99ff8b27414bbb93c3cc297...

Wow. Great comparison, thanks!

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

#157

Post by sedatk »

Timwi wrote: post #73
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 developed web software with frames and I thought it was perfectly fine. To this day I still don't understand the issue with frames. People sometimes mention accessibility for screen readers, but nothing more specific than that, so I still don't know what the actual problem is.

> so I still don't know what the actual problem is.

1. Not adaptable to the variety of display form factors we have today. In other words, not responsive enough.

2. As others mentioned, not being able to link a specific page. Maybe it can be overcome with modern browser history replacement API's nowadays.

3. A link to one of the frames not opening with necessary navigation elements. That used to be solved by redirecting the user to another page that would decorate the same page with the frames around it. Quite cumbersome.

4. Since all frame components are individual web pages, the communication between them isn't straightforward except for opening a link in another frame. Programming more complicated logic (such as dragging from one to another, or sharing components in other ways) would be quite difficult.

5. Every frame has its own scrollbar. It's less accessible, and looks terrible too.

6. Analytics is harder to track.

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

#158

Post by emfrosztovis »

rdrd wrote: post #109
layer8 wrote: post #97

Earlier quoted context omitted.

At least table rows didn't unexpectedly wrap to a new line like float-based layouts.

Even though it was a long time ago I still have IE6/7 workarounds burned into my brain, most of them float related but also having a whole stylesheet for that damn browser... : https://code.google.com/archive/p/universal-ie6-css/

I’m only 20 but when I immediately recognized this I felt so old.

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

#160

Post by pixl97 »

distances wrote: post #45
vanviegen wrote: post #39

Earlier quoted context omitted.

I managed to get real-time chat (and other real-time colab) working on IE4+ using long polling, by continuously adding tags from JavaScript. The server would delay answering until there were new messages available, or some timeout. This was even before xmlhttprequest. Who needs websocket? :-)

Sounds fancy! My solution back then was infinitely auto-updating a frame with a meta refresh tag. It would receive a new block that would update the contents of other frames. This of course wouldn't give real-time functionality.

Fun, until you had dial up so slow the refresh happened again before anything on the page fully loaded (mostly an issue with images)
Post reply on HN