Live data from Hacker News

Marquee HTML Element

developer.mozilla.org

11–20 of 30 posts

Re: Marquee HTML Element

#11
post #2

In Safari, "This text will bounce" (two marquees in orthogonal directions, both with behavior="alternate") only moves left-to-right - it seems the inner marquee cancels the outer one. In Chrome it moves diagonally and bounces in both directions like an old-school screen saver. The article doesn't clarify whether this is intended behavior, should it?

> In Safari, "This text will bounce" (two marquees in orthogonal directions, both with behavior="alternate") only moves left-to-right

Well, not for me, at least. Currently using Safari 12.1. Maybe you're using the Catalina beta with a higher Safari version?

Re: Marquee HTML Element

#12
post #10

There isn't a good argument for considering marquee deprecated anymore. Not when a element is being considered[0]. So I'd use it whenever I want a marquee. After all, and are both shorthands for stuff that could be implemented in CSS/JS - except marquee is well supported, well specified, and more semantically different than other elements compared to (which is pretty similar to and arguably [1]). [0] https://github.c…

Except that I haven't seen a marquee used on a web page anywhere in years. Except in incredibly specific contexts (like a long title in a music player app), it's generally considered bad UX design.

Whereas toasts are everywhere, a common, useful, established and recommended UX design pattern. So it's a genuine convenience to developers for browsers to provide it, in the same way browsers provide buttons, combo boxes, and date pickers. (Even though all of those also can be, and sometimes are, implemented in JS.)

The "good argument" to me boils down to use and convenience, and removing cruft.

Re: Marquee HTML Element

#13
post #2

In Safari, "This text will bounce" (two marquees in orthogonal directions, both with behavior="alternate") only moves left-to-right - it seems the inner marquee cancels the outer one. In Chrome it moves diagonally and bounces in both directions like an old-school screen saver. The article doesn't clarify whether this is intended behavior, should it?

> In Safari, "This text will bounce" (two marquees in orthogonal directions, both with behavior="alternate") only moves left-to-right Well, not for me, at least. Currently using Safari 12.1. Maybe you're using the Catalina beta with a higher Safari version?

I'm on 12.1.2 on Mojave. Weird!

Re: Marquee HTML Element

#14
post #10

There isn't a good argument for considering marquee deprecated anymore. Not when a element is being considered[0]. So I'd use it whenever I want a marquee. After all, and are both shorthands for stuff that could be implemented in CSS/JS - except marquee is well supported, well specified, and more semantically different than other elements compared to (which is pretty similar to and arguably [1]). [0] https://github.c…

Except that I haven't seen a marquee used on a web page anywhere in years. Except in incredibly specific contexts (like a long title in a music player app), it's generally considered bad UX design. Whereas toasts are everywhere, a common, useful, established and recommended UX design pattern. So it's a genuine convenience to developers for browsers to provide it, in the same way browsers provide buttons, combo boxes,…

Well, a marquee (not necessarily the HTML element per se but the design element) is often used on news sites/forums, at least amongst those I visit currently - it's used there as a news ticker.

I could go on and argue that it's far more common than a toast (which I barely see at all. Than again I don't like PWAs and try to avoid browsing from mobile when I can). But the sites I visit are not remotely representative at all, so I could well be wrong. I guess the sites you visit are also not remotely representative.

IMHO, The fact that was added and supported for so long (despite 'deprecation') is the best indication there's some demand for it, a better indicator than our browsing habits. Marquee is definitely more distinctive than is from other elements and better supported. So IMHO there's a much better case for including it compared to .

P.S. The browser provided date pickers are so poorly designed and inconsistent I wish they didn't provide them at all. It's something I always override when I have time to do it.

Re: Marquee HTML Element

#15
post #10

There isn't a good argument for considering marquee deprecated anymore. Not when a element is being considered[0]. So I'd use it whenever I want a marquee. After all, and are both shorthands for stuff that could be implemented in CSS/JS - except marquee is well supported, well specified, and more semantically different than other elements compared to (which is pretty similar to and arguably [1]). [0] https://github.c…

marquee is a presentational HTML element and for that reason should probably still be forever-deprecated, but CSS should be improved to provide equivalent functionality. I think CSS animations can maybe do something similar but it's not as easy as it should be…

Re: Marquee HTML Element

#16
post #10

There isn't a good argument for considering marquee deprecated anymore. Not when a element is being considered[0]. So I'd use it whenever I want a marquee. After all, and are both shorthands for stuff that could be implemented in CSS/JS - except marquee is well supported, well specified, and more semantically different than other elements compared to (which is pretty similar to and arguably [1]). [0] https://github.c…

marquee is a presentational HTML element and for that reason should probably still be forever-deprecated, but CSS should be improved to provide equivalent functionality. I think CSS animations can maybe do something similar but it's not as easy as it should be…

That's a consistent and reasoned argument, and also the one advanced at the turn of the century to deprecate .

I'd have agreed with you, had the standard kept this approach. But it's obviously not the direction the committees are going for, not anymore. It seems we're going to add more and more presentational elements. I can't think of single argument for including that doesn't apply at least as well for (and the same criticism should have applied to too).

So maybe we can just stop the charade and agree to not deprecate presentational HTML. Obviously we don't mean it anymore.

Re: Marquee HTML Element

#19
post #16

Earlier quoted context omitted.

marquee is a presentational HTML element and for that reason should probably still be forever-deprecated, but CSS should be improved to provide equivalent functionality. I think CSS animations can maybe do something similar but it's not as easy as it should be…

That's a consistent and reasoned argument, and also the one advanced at the turn of the century to deprecate . I'd have agreed with you, had the standard kept this approach. But it's obviously not the direction the committees are going for, not anymore. It seems we're going to add more and more presentational elements. I can't think of single argument for including that doesn't apply at least as well for (and the sam…

Toasts have common semantics: they are responses to user behavior, they are ephemeral, and they take precedence over the underlying content.

Marquees have no semantics beyond "more text than fits in this space".

Re: Marquee HTML Element

#20
post #10

There isn't a good argument for considering marquee deprecated anymore. Not when a element is being considered[0]. So I'd use it whenever I want a marquee. After all, and are both shorthands for stuff that could be implemented in CSS/JS - except marquee is well supported, well specified, and more semantically different than other elements compared to (which is pretty similar to and arguably [1]). [0] https://github.c…

The situation of is different. Most of the modal dialog implementations don’t have focus trap which is a problem for accessibility. I’m ok with the tag in that case, the combination of aria-hidden/tabindex tweaks required to do a proper modal dialog is too hacky and bug prone. (Perhaps a better focus handling model will be much better than the tag)
Post reply on HN