All snark aside, I wonder what the rationale was for doing this. It'd be a shame to load a website in a browser 20 years from now, only to see the site render incorrectly due to no-longer-implemented tags. Next, <center>?

It's tough, obviously, because we can't have cruft build up all over. But this seems like a fairly straightforward case that a browser could shim out in JavaScript by default. Blink is a pretty straightforward piece of internet history. It's not like <applet>, which, while also a piece of history, actually carries legitimate complexity/security risks.

Gecko was, afaik, the last major browser engine that supported <blink>. Chrome and IE don't, at least. Opera won't, after switching to, ironically enough, the engine called Blink.

So it's not exactly the same as removing <center>: Other browsers already didn't support it.

Oddly enough Chrome/Blink still has the String.prototype.blink method to create a blink tag from a string. If I recall correctly it's actually part of an ES (not DOM) standard.

Wow. Because this surprised me so much, I just found out that if you open up a node REPL and type 'hello'.blink() you get '<blink>Hello</blink>' returned. So I guess it's an ES thing and it boggles my mind.

I was trying to find the ES standard where it's specified but I'll settle for this[1] instead. Interestingly enough you have quite a few HTML wrapping functions as part of the spec.

[1]: http://javascript.spec.whatwg.org/#string.prototype.blink

What could possibly be the use of that.

    <p style="color: red">
    <script>
        var str="&bull;";
        document.write(str.blink());
    </script>
    </p>

That would make a blinking red dot. It'd be good for status lights, I guess.

There were parameters threaded throughout random layout functions to record how long things were supposed to blink for. It was a maintenance burden.

Why would that be? Do blinked things ever leave the flow? I didn't think so, so layout should be unaffected.

Keep a VM with a vintage browser along for the ride, I have a feeling blink tags won't be the only thing different in 20 years.

I'm sure if it becomes well and truly missed, someone will make an add-on to interpret them properly.

You can do that in a user CSS stylesheet: http://stackoverflow.com/questions/13955163/imitating-a-blin...

The <center> tag has been deprecated for 13 years.

As far as I'm aware, the longest deprecated HTML elements are XMP, LISTING and PLAINTEXT: first deprecated in the IIIR HTML draft (Jun '93).

This one might be a bit more important....

"Enable JavaScript" preference checkbox has been removed and user-set values will be reset to the default

The people that disable javascript either do it by accident and then stop using the browser or are nerdy enough to figure out how to turn off javascript in the configs. Javascript will also be configurable using plugins.

Yeah, they're trying to remove the settings that people set to goof up their browsers from the look of this. There's this one, too:

"Load images automatically" and Always show the tab bar" checkboxes removed from preferences and reset to defaults

Let this day go down in history as the day we declared our independence from the tyrannical Mozilla organization and their corporate-interest driven and oppressive removal of our freedoms and ability to customize our browser. We shall not be stricken down by their restrictive and non-representational releases of firefox... instead we choose to be empowered by the option to disable things such as javascript, and tabbed browsing because we understand these options to be self-evident truths for all browser users.

I am tired of having my freedoms stripped from my browser without any representation into the process. As a user of the browser I was not adequately informed of the upcoming changes nor was I given an opportunity to choose not to upgrade.

THIS MUST END

Contact me for further information, the revolution begins today.

If you don't like the direction the Mozilla Corporation is taking Firefox, you're free to disable automatic updates, revert to a previous version of the browser, or even fork your own version of Firefox. It's not tyrannical to want new versions of Firefox to present a better user experience and be less confusing to everyday users.

... and not receive security patches.

Version 17 is the Extended Support Release and still gets security patches. Or, "I had those security holes right where I wanted them! Quit breaking my browser grr!"

there's bugs for each of these (which are open to the world and anyone can comment) all you have to do is to take a stance during the process. harder to do so after a bunch of various people (employed or not by mozilla) decided something.

pretty sure those options went off because enough people decided that the preferences/option panel was too complicated and these were the ones that telemetry indicated were the least used.

I would not be at all surprised if there was a high correlation between "People who turned off Javascript" and "People who declined to provide telemetry", so there could be some selection bias in those results.

People who understand what that setting did can still disable by going to about:config!

This is not a conspiracy, just making browser hard to break for people who check boxes and forget about these. For those, browser is broken!

Those who know what disabling JavaScript actually does still have a way to disable! Where does all the privacy talk come in between?

NoScript is a much better option all around. I know I've been using it since forever.

When I got my last company laptop without all these things set, I was surprised how painful it was to try and download anything without a proper adblocker and noscript. I don't know how people do it.

that's a good point

Bugzilla is not your personal soapbox. The revolution is a damp squib.

Surely he was kidding?

This is no joke brother... We will not rest until this issue is heard in the highest of courts. First they came for our <blink> tags and we laughed... then they came for our options to disable tabbed browser, and they said nothing... then they came for our option to not be tracked by online advertising agencies (javascript) and everyone was too busy sharing kitten photos on facebook to say a damned thing.

Yeah. It's satire about overreactions that are so prevalent on many tech sites (including this one). Colbert would be proud.

We have already begun to gather near Mozilla HQ in San Francisco...

https://socialcam.com/v/39HPvZde

Protesters can be heard chanting:

"WHAT DO WE WANT?"

"The ability to disable tabbed browsing"

"WHEN DO WE WANT IT"

"Possibly in the next point release, but the next major is cool too"

Are you being serious or is this supposed to be a joke?

Exactly, and if you're so inclined to have those options set in a certain (and don't want to do so through some other addon like NoScript) you can set it in about:config.

The primary problem is that the about:config flag for hiding tabs is ineffective so there is more to the solution than just looking deeper into the config menus.

I agree that these options are for power users, but my fear is that soon after they relegate the ability to disable javascript to the bowels of the application, they will soon remove it entirely. And that this decision is in fact not driven just by the fact that it is seldom used, but driven more-so by the corporate interests they hold with advertising and other online entities that serve not for the browser users, but their own corporate interests. This fundamentally collides with the intent of the Mozilla foundations purpose and this behavior must stop.

The ability to disable javascript has been on the main screen of the options panel because it serves a very important purpose.

Also the ability to not show tabs when browsing a single web page because for that use case, it is more optimal to not show a tab and waste the screen real estate on dead space.

They have fundamentally altered the Firefox browser in a fundamental way that is not configurable and have not provided reasonable alternative.

I refuse to accept any so called "Add-On". These features are not to be pushed off into to the extremities of the community and be forgot about. I firmly believe that any such browser serving only the interests of the user would see these features as being non-optional options and should exist in perpetuity for the life of that software.

> Always show the tab bar

Which way I'd this one going to go? On or of? And the fact that I have to ask tells me that maybe they should not have removed the option.

Tab bar will be always visible. The fact that you have to ask means nothing, because you are one person. Decisions get made based on data, not anecdotes.

The fact that I have to ask means I have no way to predict which they consider "better". It could have just as easily gone the other way.

Personally I'm glad it's in the visible direction though.

An option should only be removed if the "better" way is obvious.

Any ideas where the data is that showed this move was positive? Is all the browser usage data open?

NoScript continues to work fine and is much more functional than globally turning off JS. Anyone who intentionally turned off JS via the Firefox options will probably benefit from being forced to use NoScript instead anyway.

Personally I've set - for as long as I recall - the javascript options in the submenu all off. I don't see why a page should be able to move windows or change default menus. I'm assuming these options are being removed from the GUI too. What are the defaults (they're not mentioned on the OP's page).

NoScript doesn't appear to have these fine tuning options?

What a fitting farewell. If you check the source, the item is wrapped in the old blink tag.

`<blink>Dropped blink effect from text-decoration: blink; and completely removed <blink> element </blink>`

Start up firefox and give it a nice sendoff.

Aww, man. I love using <blink> (in FF) and <marquee> (in Chrome) when giving presentations, they're such crowd pleasers. At least Chrome still has <marquee>, I used it in a talk just 2 days ago. Hope they don't follow FF's lead.

Both of these effects can be recreated quite easily using CSS3 animations, by the way.

Plug: I wrote a JS lib that can be used to create a CSS3 <marquee> (please use sparingly): http://lukifer.github.com/HoverForMore.js

This creates some really nasty glitching when you hover over the text that scrolls in Safari 6.0.5

So it does. Strangely, the small example is unaffected. Thanks, I'll look into it.

Marquee caused a whole bunch of CSS errors in a website I delivered. Client found out you could run code via onscroll, and the CMS I used (DNN) didn't filter it out. Ugh!

I just used <blink> in a blog post last week. For my purpose it served as a visual pointer to the past. I'll be sorry to lose it too.

Are you trying to drive your audience to distraction?

Fare well old <blink> friend. My high school memories of webrings would not be the same without you.

Quite fitting that the <blink> tag originated with the Netscape browser[1] and now is removed in its descendant Firefox.

The idea was first discussed at a bar in Mountain View, CA.

[1] http://www.montulli.org/theoriginofthe%3Cblink%3Etag

It was as if millions of geocities sites suddenly cried out in terror and were suddenly silenced.

| Their tags shall blink until the end of days.

from The Book of Mozilla, 12:10

how about organizing a campaign to hire some protesters in front of mozillas office to bring it back?

( http://www.vice.com/read/its-now-possible-to-hire-fake-prote... )

What's neocities.org going to use now?

A lot of tissues to sop up our tears.

<marquee>?

I found BLINK and MARQUEE so infuriating irritant that I used to binary patch them out in the browser executable. This was before the era of signed executables.

Also worth noting: "New feature in toolbox: Network Monitor".

The lack of it was the last thing that was keeping me using Firebug.

I wonder what abused tags today we will have a moment of silence for 10 years from now?

<table> wasn't actually abused; it just happened to be the best way to do things until CSS 2.1 was rolled out.

There are still use-cases where using <table> is the cleanest way to achieve something without resorting to javascript (or a <div> soup tag).

Like what? I buy the use case of using a table for data, but are you implying there's other scenarios where using table elements are the best choice?

Here's an example, for one:

http://css-tricks.com/centering-in-the-unknown/

(talks about a CSS/divs solution, but as it mentions there are differences between the two). In general if you're dealing with a design that involves centering something with a dynamic size vertically, or one which involves having the height or width of two dynamic elements add up to the width of a third adjacent element (ie. "rowspan" and "colspan" in table-speak), there's a decent possibility that using a table might just be the least-hacky way to implement something. Bearing in mind that hackiness is a bit subjective :)

Yeah certainly, thanks for the examples. I think the first item you mentioned, vertical centering of a single dynamic object actually can be handled better than tables currently (see some techniques here: http://html5hub.com/centering-all-the-directions/) but when you add more elements into the mix I can see how rowspan / colspan equivalents are not easily implemented without JS.

A main content area and a sidebar with each having different colors and both maintaining the same height such that they expand vertically with the content (without having to hard-code pixel values).

I saw a page showing how it could be achieved using only divs, but really, it was a complete rube goldberg machine, the sole purpose of which, seems to be to adhere to the religion of not using tables.

I get that table layouts have their own issues but I think its silly to be dogmatic about refusing to use them where it's clearly the best hammer to drive in that nail.

Vertically centering floating content is a PITA without this dirty, dirty hack :)

Email for one.

I get it but I feel that's more of an imposed limitation by email clients and not a fair choice.

How else would you display data?

You're right, everything else I can think of is worse for data, tables are pretty good for that (minus the weird vertical centering thing that sometimes happens in cells.)

But seeing tables being used for layout annoys me far more than the blink tag.

> But seeing tables being used for layout annoys me far more than the blink tag.

How come? CSS positioning is pretty unintuitive, and sometimes it's just easier to get something working with tables. If the end results look fine, what's the problem? Table-based layouts aren't in-your-face like the blink tag was.

Oh, and don't view-source on HN ;)

When I rewrote the Coursera discussion forums and sent them through an accessibility audit, I was told to use <li>s instead of <div>s to represent the nested conversations, which makes a lot of sense when you think about it. Disqus also uses <li>s for their comments.

So, just FYI, if you find yourself generating HTML for something like HN anytime in your life.

I believe discouraging the use of tables for layouts is accessibility based. Screen readers have a really hard time parsing them correctly.

My problems are mostly how easy it is to get lost if you're dealing with nested tables within tables (especially inside templates), and that they have to be completely read before rendering... although that may no longer necessarily be an issue with modern browsers.

I find divs and spans easier myself but I guess, yeah, at the end of the day if it looks fine and it loads fine then it's fine. Too much pain from hand-coding too many tables has made me twitchy and curmudgeonly.

Oh, and don't view-source on HN ;)

Oh, i'm aware... It's just too bad html doesn't provide elements that handle nested lists. If only. Ah well.

Isn't <ol> <li> <ol> <///> Valid?

Yes, i was being sarcastic.

I've actually found CSS layout to be more intuitive than tables. maybe it's just that I have ages more experience with CSS than tables, but seriously, tables feel like a cludge for layout.

(views source)

as a <table> user, I feel vindicated :P

I'm using SlickGrid[1] in an internal tool. It uses divs and spans to display data, so there are certainly nice examples that do so.

1. https://github.com/mleibman/SlickGrid

But why would you want that? The whole point of moving from <table> to <div> for layout was that using <table> wasn't semantic and was the wrong tool for the job. But <table> is the right tool for displaying tabular data. That's its entire purpose for existing. Using <div> to display tabular data is a regression.

Edit: typo

I don't disagree, just pointing out that there are ways to achieve a tabular layout without an html table. Tables are for data right?

On the other hand, I like the idea of less and more generic constructs that can be adapted to achieve some need. Specialized tags like dd, address, details, summary, code, blockquote, etc just seem superfluous.

That would break HN.

Nah. It's basically an unordered list inside a block, tables are entirely unnecessary for a layout as simple as HN's.

I love the fact that in the release notes page, they used a <blink> tag around the message "Dropped blink effect from text-decoration: blink; and completely removed <blink> element".

Don't worry, we still have the Web 2.1 version:

http://cheese.blartwendo.com/web21-demo.html

;)

Mozilla didn't want to be responsible for causing seizures

Thanks god for the upcoming support of custom html tags.

Well, geocities will never look the same again.

Damn, I seriously thought about posting this :)

RIP