Deprecated Elements, or not?

Reading the HTML Reference, marquee is not in the deprecated list, but in another area it is mentioned as the “worst element ever!” and that it should not be used. Personally, I like it. But if it is to be deprecated, I know I should move on, but I have a major problem.

I’m not into great web design, I’m not kidding anyone there. But I maintain the old high school class web site that is hosted by a provider that does NOT want any <script></script> tags on the Free web sites they allow us to use. The basic layout is common to all the class sites is the same, but each of us “admins” can customize the site to some degree.

Example: I like to create a slideshow of all the old class mates with birthdays in the same month. AH-h… new to me is using images in the Marquee, so I’ve done so. It’s cute :smiley: & different & fairly unique. I run the images in one direction and the text containing the names & dates in the opposite direction. They don’t match, but that adds the cuteness to the display.

So, if I’m to deprecate Marquee and can’t use <script> or Javascript, or some other script, then what am I to do to get the same type of effect?

Deprecation is a status applied to a computer software feature, characteristic, or practice indicating it should be avoided, typically because of being superseded.

That being said, in my opinion, if you have no other choice, as in your case, as long as it works use it.

I’m sure many wouldn’t agree, but as I said it’s my opinion.

Personally I think “blink” is worse…

No MARQUEE in NOT “Deprecated”, since it’s Propriety MS nonsense it NEVER was in the Recommendation to start with - because it was so badly designed.

The appropriate way to achieve the same type of effect is via JavaScript. I suspect nowadays something like CSS 3 could be used to animate text in some modern browsers. Though I doubt it will solve the issue of your photo slide-gallery though I know some CSS image slide shows have been made. For example: http://www.cssplay.co.uk/menu/cssplay-radio-left-right-click.html

To mark something as obsolete and about to be removed from the standard (which is what deprecated means) it has to be a part of the standard in the first place. It isn’t possible to remove the marquee tag from the standards as it has never been a part of any standard.

Marquee is a behaviour and JavaScript is the appropriate language to define web page behaviour. It is rather easy to add some JavaScript to your pages that will allow any part of the page to be converted to a marquee simply by adding a class to the tag. See http://www.felgall.com/jstip109.htm for an example.

To xhtmlcoder: if it is so badly designed, why is it still around? Why didn’t it get non-supported at some point because of the bad design. OR, better yet, why didn’t someone sometime rewrite it into a good design? AND your link to “menu/cssplay-radio-left-right-click.html” had me confused. I saw the slideshow, but I want something that is turned on and left to run without any user clicking the little arrows to go to the next slide.
And, as originally stated, I can’t use Javascript, the host of our free web sites forbids it.

The people who created the browsers don’t want their users switching to a different browser because they have ceased supporting something that some web pages use and which those users are used to seeing work. Even if all the HTML tags that shouldn’t be used any more were to be completely removed from the standard the browsers that support them would continue to do so simply so as to not break all the prehistoric web pages that use them.

Sounds good in theory, but I lived thru the early days when Netscape was the only viable alternative to the Internet Exploder. And I think I have on my book shelf a web master manual whose reference section to HTML lists ones used in IE and the alternatives used in Netscape. People didn’t mind too much then.

But having worked in the SW industry for lots of years, I have to say that one of my irritations has always been when big updates “have to include” all the old stuff they don’t support, but users use.

As for HTML, if something is being used a lot, then maybe it should be part of the “standard of the day.” And some simple things ought to be included just because they’d make everyone’s life a lot simpler… my choice here is a simple way to “include” a block of common HTML code to my page.

All I’ll say here is that I’ll use Marquee until it is Deprecated, or until something else is introduced that does the job that is not some script that requires some extra executable, like Java.

Looked at your “marquee” at the above URL. I have a few comments, if you don’t mind.

The quotes you use in the marquee example should read:

The quick brown fox jumped over the lazy dogs. <– the typing idea for this was to hit every letter of the alphabet.
She sells sea shells down by the sea shore. <– just a missing word.

And, since your code was all run together and I don’t know Javascript, the question is Can you run your images then have the text either above or below the images, like having your name below your picture? If so, can you insure the text will line up correctly?

As noted prior MARQUEE will never be deprecated because it was never even official - part of the reason was because it wasn’t structural but presentational and caused web accessibility issues. Obviously not all browsers support it.

Warning! the following link may cause motion strobe and flicker leading to epileptic episodes: http://www.goer.org/htmlhorror/htmlhorror1.html of course BLINK has been replaced by CSS {text-decoration: blink} and the scroll animation won’t work in Fx in the absence of JavaScript.

Like said, you can get some scrolling effects with CSS 3 animation. Though probably the nearest direct mapping CSS to marquee would be: http://www.w3.org/TR/css3-marquee/ People made a lot of mistakes in the Browser Wars and so did the vendors last century. HTML5 includes the “junk” many people were wishing to get rid off or thought they had in the Strict Doctypes. HTML5 is ‘descriptive’ rather than ‘proscriptive’, which undoubtedly will lead to a lot of authors using “bad practice”. Like Stephen said there is still some legacy support for various ancient “proprietary” tags. Perhaps even ILAYER if you can remember that far back, in Netscape 4.x series. Someday EMBED will probably be made official.

In HTML, there is obsolete, and there is deprecated, and they are not the same thing (well, they probably are, but someone wanted to change the terminology… deprecated was supposed to mean “thrown out of the spec” while obsolete seems to mean “it’s in the spec but it should not be used EVAR”).

Marquee in HTML5 is, like, obsolete-obsolete*. It will throw an error in the validator. As opposed to the obsolete-but-conforming elements, who’ll only give you a warning.
Well and watch out, there are two specs we’re dealing with… W3C and WHATWG. An example of weirdness is the <u> element. **
Still, there is an “implementation” page for vendors (browser makers) with specific instructions on how to support these things. There’s one for marquee.

Most of them do. The big non-supporter I know of is Chrome, who does support marquee, but doesn’t seem to hold to the implementor’s rules. Or something. It misses some attributes and features IE originally had in marquee that most of the earlier browsers has supported… I forget which ones, and I only know this because someone came over here to SitePoint and asked why his marquee wasn’t doing x and y in Chrome. It was lawlz.

But, I mean, it scrolls.

WHATWG did just that. They gave it the smelly name of “paving the cowpaths”. It was via this manner that <iframe>,<embed>, and XMLHttpRequest were brought into the HTML spec (iframe back from deprecation; embed who like marquee was never in the spec at all and brought in; same for XHR). They were brought in because they were so much in use, the spec writers decided there ought to be a specification for something used so much. Because specifications tell you how browser vendors (implementors) should deal with that markup and how authors should write it.

Marquee never got that because, like blink, it was probably considered a monstrosity that should have been killed while incubating over at MS.

That said…

Like scout, I’m curious why you care. You have a fiendish hoster who doesn’t allow the correct implementation, Javascript, and CSS transitions require user interaction, so you should probably use… a marquee.
My biggest issue with marquee is, I can’t turn it off. It’s not Javascript, and you can’t add a stop button to it. I hate carousels and make sure I hit them off or stick to Javascript blocked for new pages… nothing is worse than trying to read something and sh*t keeps moving at the side of my eye. I suppose with CSS you can let someone click on something and a solid colour appears to sit over the carousel. But I don’t see anyone bothering to do stuff like that.

Long ago I noticed in Firefox (back in … 3.0?) that the page XhtmlCoder linked to, the Evan Goer’s OH POINTY BIRDS page, that not all the blinking and marqueeing elements were actually moving. The browser had blocked many by default it seemed… only a few of the elements appeared. Take a look in an older browser and you’ll see about twice as many.

But anyway, so what if it’s deprecated? Or obsolete? That’s for validators anyway. If you have such a child-eating hoster, and you are not an HTML writer, validation is not one of your worries.

** It’s deprecated in the W3C HTML5 spec: http://www.w3.org/TR/html401/appendix/changes.html#idx-deprecated
It is not deprecated in the WHATWG HTML5 spec: http://www.whatwg.org/specs/web-apps/current-work/multipage/text-level-semantics.html#the-u-element

No - deprecated means obsolete now and will be removed completely from the language when the next version comes out. With programming languages you know that when something is marked as deprecated in version 4 that if you try to run the code using version 5 that it will crash because it no longer recognises the previously deprecated command at all. Unfortunately with HTML the browsers and those developing HTML 5 are disregarding that HTML 4 flagged a whole series of unnecessary tags for complete removal in HTML 5 and they have un-deprecated them by not removing support for them. After all they were deprecated for a reason and that reason still applies - just with too many novices still writing HTML 3.2 and wanting to call what they are writing HTML 5 actually removing the tags flagged for removal would break too much of the web.

Of course embed is only needed to support Netscape 4 and earlier and iframe is only necessary to support IE7 and earlier - all more recent browsers support the object tag properly for those uses. Still, it seems many people are still writing their web pages with Netscape 4 and earlier as their target browsers rather than bringing their code up to date. By the time that HTML 5 becomes a standard the browsers that need you to use embed or iframe will be long dead (one is already and the other almost is now).

You just need to add a single line to the CSS attached to your browser to turn off all marquee tags on the entire web. See http://www.felgall.com/marquee.htm for instructions on how to do it in several different browsers. With that one liner in your browser the browser will ignore all marquee tags and treat the content the same as if it were in any other HTML tag.

The text could be easily changed and for the purpose of showing how the marquee works the content doesn’t matter. After all it is just text inside of the appropriate HTML tag that is converted into a marquee by attaching class=“marquee” to the container tag.

That particular marquee script converts whatever is in the content into a single line of text/images. To put the text above or below the images using that script you’d need to set them up as two separate marquees. They would stay aligned one below the other provided that the total width of the content of each when placed on a single line is the exact same width (since all the marquees in the page will move at the same speed). No matter how many marquees you have in the page you’d still only need the one copy of that script attached as it converts all the tags in the page that have class=“marquee” into marquees…

Not in HTML. There’s deprecated, a term used by the W3C. There’s obsolete, a (new) term used by the WHATWG and in general for HTML5. They are both writing HTML specs. W3C actually still calls it by version number: we are on 5.0 and they are currently writing 5.1. Things deprecated will (likely) remain deprecated, but they are never removed. Obsolete things are not removed; they are marked as obsolete, and then vendors are told how to implement it anyway. Some obsolete things will bring a warning in the validator (the “conforming” ones) while the others will bring an error like deprecated elements did back in the day of HTML4.

As far as authors are concerned, with HTML5, there is no more “deprecated”. Despite there being a W3C page about it.

which HTML isn’t, never will be, and only sorta slightly half-a$$edly follows the slightest rules for.

They have never removed support for them. Only reason Chrome hadn’t everything for marquee had pretty much everything to do with it being the sole baby browser in the world at the time. They had no legacy, except whatever they inherited from KHTML (I think they threw a lot out, especially after the spat KHTML guys had with Apple… which btw seems to have been somewhat patched up, or so I heard in a rumourz on teh interwebs).
The “un-deprecation” is the WHATWG either re-creating new meanings for some tags (which were not actually deprecated in any case, like em, strong, b and i), bringing wholly new things into the spec (XHR, embed) and making things the W3C had labeled “deprecated” just in the spec. In the spec means in the spec for WHATWG.

That’s awesome, though I used to actually write user stylesheets, I stopped that about when I stopped using bookmarks because every new machine needed new copies and every new browser and blah blah and I was lazy. I just hit the back button with sites with scrolling crap I can’t turn off. It’s way easier for me. But! Most people don’t switch machines or browsers as much as I’ve been doing recently so I think it’s a pretty valuable piece of CSS, so thanks. I might twot that.

So basically the HTML standards people have changed the meaning of deprecated to suit themselves. It has had the specific meaning that I mentioned with respect to all programming languages for several decades and presumably still had that meaning for HTML when HTML 4 became the current standard.

For example when PHP 4 was released there were a number of things from PHP 3 that were marked as deprecated. When PHP 5 was released those things marked as deprecated in PHP 4 no longer existed and so code that used them would no longer run.

It is going to be confusing for anyone writing both markup and programming languages if the same term has a different meaning for markup languages to what it has for programming languages.

I suppose the HTML 5 standards people will next define “flying pigs” to mean something that you see every day of the week.

It’s as if HTML is afraid if it removes stuff in later versions, it’ll forget who it is and resort to tattooing itself and taking polaroid photos to know what’s going on… and not to trust Apple.

I suppose the HTML 5 standards people will next define “flying pigs” to mean something that you see every day of the week.

Probably but only if Hixie doesn’t say No.

I think that the real problem is with the way browsers implement HTML. Instead of looking at the web page to see which version of HTML it is supposed to be usingand then use that particular version to display the page the web browsers instead have their own version of HTML built into the browser itself - which therefore needs to be able to cope with whatever version of HTML that the page uses.

So in reality there is no browser that supports HTML 3.2, HTML 4 or HTML 5. Instead you have IE7 supporting HTMLIE7, IE10 supports only HTMLIE10, Chrome 25 supports only HTMLC25, Opera 12 supports only HTMLO12 and so on.

Only if browsers were to actually start implementing the various versions of HTML (and most of the web still uses HTML 3.2 so they’d all need to support back that far at least) can HTML tags ever be truly dropped from a particular version of HTML. If Opera 19 were to actually support HTML 3.2, HTML 4, HTML 5 and HTML 6 instead of HTMLO19 then it would be possible for HTML 6 to not support any of the totally useless HTML 5 tags and the browser would either allow of ignore the tags depending on the version of HTML that the page actually uses. Of course that could only be done if HTML 5 is reworked to actually comply with the SGML markup standards to that the browsers would actually have a way of determining what tags they should and shouldn’t support for a particular version of JavaScript by actually reading the doctype file.

I think that the real problem is with the way browsers implement HTML. Instead of looking at the web page to see which version of HTML it is supposed to be usingand then use that particular version to display the page the web browsers instead have their own version of HTML built into the browser itself - which therefore needs to be able to cope with whatever version of HTML that the page uses.

Which I think they did as a practical answer to the fact that they feel they can’t afford to be like a C compiler. You know the phisherman’s dilemma?

If all phishermen are causing people to stop reading mail which will in turn devistate all phishermen, and one or several decide to stop phishing or phish less… this does not benefit them, but only benefits the all-out phishers since now they have much less competition. In the end, the phishers who stopped phishing fail entirely and still eventually the scammed quit reading mail and all phishers die out anyway and the world ends due to global warming blah blah.

Well nobody wants to be the one or one of the browsers who shows a Yeller Screen O Death instead of some band’s myspace page, because users will switch to the One Who Works, and therefore everyone is doomed anyway.

It only works when it’s like a C compiler: always always always dies a horrible loud obvious error-prone death every single time no matter which platform you’re on. We don’t have this in HTML. Because Postel blah blah. Damn him.

You’re in the wrong section in the WHATWG spec. Check the “obsolete features” section. Also, the W3C version you’re looking at is several years old.

Um, that’s HTML 4.

Lawlz, why yes it is. What I get for drinking in the evening and posting on forums.

And someone else also asked me “why you looking at old specs?” and sent me to a more-newer-better W3C draft page.