Hacker News new | past | comments | ask | show | jobs | submit login

<blink> is no longer supported by browsers, but with a few css declarations it works just fine.

Removing support for presentational markup does not mean a loss of information. Browsers will still render tags they don't recognize, and re-applying the styling of those tags is often trivial. (I mention <blink> because it's one of the more difficult, but not terribly so)

As the web evolved, our needs changed. Do we still need the <font> tag?




I think you're missing the OP's point though.

It's true that you can just use some CSS to make up for the lost HTML feature, but than again you could also rewrite the HTML part.

Forgive me if I'm wrong, but I'm fairly sure that what the OP is trying to say, is that there are plenty of great websites out there, which were developed a long time ago, and for which there is no maintainer to do any work on it. Thus having HTML elements like this dropped, would make the content in a way lost.

Thinking about it some more, users can probably add plugins to add this css automatically, or some browsers might even keep those features in, but still, there will be users that don't know this, I think, resulting in a bad experience.


The "plenty of great websites" were developed long time ago. Having a degree of visual consistency of layout across different browsers was not possible then according to standards.

The content will not be lost. The tags will result in valid elements but the rendering may vary. This has always been a thing to be expected, since legacy elements (pre HTML5) never had uniform rendering and contained quirks.

Should the current/new standard have support for ambiguously rendered quirky elements? Is it even a standard then?

After HTML5 the end result will definitely be the same on most (if not all) layout engines. The standardization as a process requires non-conforming legacy to be dropped.


I may not have expressed myself clearly, but I understood what OP was saying. Never overnight and post, kids.

I was thinking about something like Stylish or the user stylesheet I've been hearing about in Firefox (for their UI IIRC, but still). Inject some global css on older/missing doctypes, and it's probably less than 200 total declarations to handle every older tag. I'd imagine <font> to be the hardest and/or longest, followed by <blink> and <marquee>.

Would be a small extension.

My other point I think I expressed clearly enough, that the loss of presentational markup is not a loss of content in most cases. If the title is in Times New Roman instead of Arial, most of the time it'll just look worse. Unless the content is meta, the presentation is to make things more pleasant to read.


Not sure I'm getting you… An extension to view old pages? This is the worst idea I've heard in a long time. The web is awesome partly because it's backwards compatible.


I'm not saying I want that, I'm saying it'd be super simple to do if things came to that.

My primary point is that presentational markup is not required to get value from all but the most meta of old pages.


Presumably new web browsers will only drop support for styling these elements in standards compliance mode?


The <font> tag is still necessary because of HTML for emails and Microsoft’s disappointing decision back in 2007 to regress Outlook to using the MSO renderer/editor, which is worse than IE 5.0.


There are a ton of uses for old-style <font>, <b>, etc tags. CSS is both more verbose and more abstract. When I do not care about the "reusability" of a given code fragment, give me presentational markup tags all day long


I unapologetically still use the font tag, because most of the time I have no desire to bother with CSS.


Even inline?

    <span style="color: #000; font-face: Whatever; font-size: 10pt">Blah</span>
vs.

    <font face="Whatever" size="2" color="#000000">Blah</font>


Just as a nit, "font-size:10pt" is a lot worse than <font size="2"> from an accessibility perspective. <font size="2"> is "one notch below the user's default size". If the user sets a 20pt font, it's going to be larger than 10pt.

You could use "font-size: small" to get the size="2" behavior.

(Also, "font-family: Whatever", not "font-face: Whatever".)


Note that your CSS example is longer and requires combining two different syntaxes. And for one change, the difference in length and complexity is much more apparent.

> <span style="font-size: 10pt">Blah</span>

vs.

> <font size="2">Blah</font>

Which is easier to remember? Which is more obvious at a glance?


The former. The problem is just that you've learned what the latter means better than the former. I'm the opposite.

Plus, the former is an absolute value where the latter is not, as far as I've been able to tell. I know that first span will always be 10pt font. I have no idea what "2" even means in this context.


Another commenter did you a favor and explained why using 10pt is worse than using 2: https://news.ycombinator.com/item?id=15927837


That may be true, but regardless of whether pt is a best practice, the point remains that it is still a unit. IMO that puts it ahead of the alternative example.


pt is for print and does not translate to the web. There are articles about this, specifically from the W3C https://www.w3.org/Style/Examples/007/units.en.html


<blink> has never been in any HTML specification since time began.


And yet it can be supported just fine.


To nit-pick, no. You can emulate it, not support it, cause it doesn't exist anymore.




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: