Why should I close my HTML tags?

Mason_Wheeler

@blakeyrat said:

@Mason Wheeler said:
Yes, there might not have been as many Geocities pages, but is that really a bad thing?

Yes.

Why?

blakeyrat

@bgodot said:

I've been wondering if '123' is valid or not... It offends me, but is it technically wrong?

Depends on what type of file it's in. HTML4, XHTML, XML, HTML5? Definitely wrong.

Pretty sure that was acceptable in earlier versions. I could be wrong.

blakeyrat

@Mason Wheeler said:

Why?

Why is limiting the access of people to a fee service that allows them to voice their options to the world a bad thing? Is that seriously a question?

How about, "because I'm not a fucking Nazi".

Cassidy

@bgodot said:

I've been wondering if '123' is valid or not...

Invalid on two accounts:

incorrect nesting - the tags "overlap"
deprecated tags - should be using and now, which are definable styles rather than style components.

Nonetheless, it'll still render (unless it's XML)

Mason_Wheeler

@blakeyrat said:

@Mason Wheeler said:
Why?

Why is limiting the access of people to a fee service that allows them to voice their options to the world a bad thing? Is that seriously a question?

How about, "because I'm not a fucking Nazi".

Aha! There's the Blakeyrat we all know and love. I was starting to think something had happened to you. Your posts so far in this thread have been all helpful, and well-thought-out, and... constructive. You had me worried there for a while...

@Mason Wheeler said:

if a strong demand for good WYSIWYG tools existed--which it would if a strong standard enforced by strict parsers existed--we wouldn't have messes like this.

There is no "strong standard". The standard that exists is a mess. Yes, you are absolutely correct, IF such a "strong standard" existed things would be wonderful. But it doesn't, and it never will <-- and those last 4 words are the key. It means you have to stop worrying about what-if fantasy land and deal with reality.

boomzilla

@blakeyrat said:

Welcome to reality. Sorry.

Nooooooooooooooooooooo! It's the evil blakeyrat with the goatee!

Cat

@Mason Wheeler said:

Is there a newer and better way to render text with arbitrary colors, without using ? (Serious question,
not trying to troll anyone here.)

The better way is not to render text with arbitrary colors to begin with. My company learned that one the hard way. Mixing stylesheet-derived colors and hard-coded colors is just too much of a headache. In the best case, the only problem is clashing colors; in the worst, important text can be lost entirely due to losing sufficient contrast with the background.

Better is to use a palette of maybe 6-8 shades of 6-8 basic hues. Have your graphics designers set up a few good color schemes, and just use the ones you have. Makes supporting alternate themes vastly easier.

Ben L.

@Cassidy said:

@bgodot said:
I've been wondering if '123' is valid or not...

Invalid on two accounts:
incorrect nesting - the tags "overlap"
deprecated tags - should be using and now, which are definable styles rather than style components.
Nonetheless, it'll still render (unless it's XML)

‹b› and ‹i› were not deprecated.

error

@Cassidy said:

@joe.edwards said:
Just look at what happens when you paste from Word into a contenteditable element.
I've no idea what that means - but if you're talking about "$thing does a bad job because there's no real reason to do a good job and it doesn't seem to have any effect anyway" shock horror - I've read that headline many times.

Most web based WYSIWYG editors don't start from scratch, they use the browser's in-built editor by setting the contenteditable attribute of an HTML element. The problem is more difficult than just building a WYSIWYG that does things cleanly, because now it has to scrub the markup generated by the browser or pasted in from the user. Except each browser engine has different cruft to scrub, and also each application that you can copy rich text from also has to be scrubbed with a different algorithm. I cited Word as a particularly egregious offender here.

The problem is complex, because you can't just nuke everything pasted in, some of that stuff is important. I've seen and evaluated many web WYSIWYG editors but none that have solved this problem perfectly.

Bulb

@bgodot said:

I've been wondering if '123' is valid or not... It offends me, but is it technically wrong?
123

I am almost certain the original specification required that to be parsed like 123, i.e. closing a tag would close all non-matching tag inside matching tag and therefore should have rendered as “123” (I don't know whether your browser can kern, but mine can't and has top of the 2 overlap with the 3). But most browsers actually left the  tag open and major part of HTML5 is about making the most common interpretation official. I am not sure it is “legal” now, but believe it now does have standard rendering.

It's of course the same case with the  and <td> in that page.

Cassidy

@Ben L. said:

‹b› and ‹i› were not deprecated.

Gah, correct. I'm thinking of and <s> and for some reason keep lumping and into the "deprecated" rather than "do not use".

List of deprecated stuffs.

Cassidy

@joe.edwards said:

The problem is complex, because you can't just nuke everything pasted in, some of that stuff is important.

Granted, but part of the problem comes from the fact that a loose standard permitted many different ways to skin a cat so there's no consistent way of turning textual content into markup.

.. and even if there was a tight standard, you're still in the territory of reverse-engineering an answer back to a question where there are plenty of roads leading to Rome, so which to pick?

Zemm

@BlueKnot said:

Some of the worst HTML I've ever seen contained FONT tags with style attributes...

My new boss likes to do that. I've been replacing them with span tags as I see them. I think it's Dreamweaver.

This new boss also didn't see a problem with this: print qq~<input type="hidden" name="something" value="$FORMDATA{something}">~; (this is from our perl system, where %FORMDATA is basically the same as $_REQUEST in PHP) and said the WAF will stop XSS attempts. But what if "something" contains a double quote character?

MiffTheFox

@Cassidy said:

@Ben L. said:
‹b› and ‹i› were not deprecated.

Gah, correct. I'm thinking of and <s> and for some reason keep lumping and into the "deprecated" rather than "do not use".
List of deprecated stuffs.

My understanding is you use em to provide emphasis and i to italicize something (as in, things like book titles) such as in the sentence "Atlas Shrugged was way too long.*

Speaking of <s> by the way, for whatever reason Tumblr, despite using fancy HTML5 tags like section, will only accept strike of all things for striking out text when rendering posts on the dashboard. Not s. Not del. Not text-style: line-through.

* Not an endorsement. Libertarianism is a fancy word for anarchy.

boomzilla

@MiffTheFox said:

* Not an endorsement. Libertarianism is a fancy word for anarchy.

Only if you change the meaning of one or both words.

dhromed

@boomzilla said:

@MiffTheFox said:
* Not an endorsement. Libertarianism is a fancy word for anarchy.

Only if you change the meaning of one or both words.

I... I... agg—

ggng

aggr...

gngh

aGREE!

aaaaugh

hangs self

boomzilla

@dhromed said:

@boomzilla said:
@MiffTheFox said:
* Not an endorsement. Libertarianism is a fancy word for anarchy.

Only if you change the meaning of one or both words.

hangs self

That's...unfortunate. I'm still wondering how we got to this talking about Ayn Rand, since Objectivism is distinct from both of those things, too.

Lorne Kates

@Cassidy said:

@smxlong said:
@Cassidy said:
Yesssssss! That's the fellah!

Thanks a lot -- the above link redirected to AdultFriendFinder.

No idea why. Sounds like you have DNS hijacking issues.

Holy shit, there's a SECOND PAGE!

@Cassidy said:

The issue isn't how easy it is to muck it up, it's your response to it being mucked up. With browsers being in their current relaxed state, there's no pressure to fix the muckups - the markup will still render.
If browsers became draconian overlords then markup will be treated much like programming languages in the sense of muckups need to be ironed out before deployment to production. Similarly, that 100% figure you rarely see will quickly become commonplace.
Yeah, I know it ain't gonna happen, but don't you think the tolerant nature of browsers is contributing to the problem? It certainly doesn't discourage it.

The way I see it, browsers could accept bad markup as they do now, but show a summary of all the mistakes. Sure, there are validators, but only people who care use them. I'm talking about a validation report shown by default to any browser user.

I think a good level of public humiliation could do wonders about people's willingness towards learning and/or being mindful of proper markup.

error

@BlueKnot said:

Some of the worst HTML I've ever seen contained FONT tags with style attributes...

I swear I've seen things like .

blakeyrat

@Zecc said:

Sure, there are validators, but only people who care use them. I'm talking about a validation report shown by default to any browser user.

What purpose would that serve?

"Here, user: here's some information you can't do anything about, you don't care about, and you don't understand. Wow what a great gift from me to you!"

toon

@Zecc said:

I think a good level of public humiliation could do wonders about people's willingness towards learning and/or being mindful of proper markup.

I suspect too few people realize that proper markup and good CSS use go a long way towards cross-browser compatibility. If more people realized that, perhaps markup would be better.

serguey123

@joe.edwards said:

Draconian policies on markup would have had a chilling effect on the growth of the web, and it may have never entered the mainstream if it required years of education and careful attention to detail just to publish a web page. As much as I hate tagsoup markup, if browsers didn't tolerate it the web would be a pretty barren place, and that would cut its popularity down to vanishing.

You talk of this as if this was a bad thing

The_Bytemaster

@toon said:

I suspect too few people realize that proper markup and good CSS use go a long way towards cross-browser compatibility. If more people realized that, perhaps markup would be better.

Very true, but people also do not remember (and have a very short memory) of how the web was built in the first place. Browser makers constantly added new items to their set, and closing tags were almost optional in the early days. Javascript was invented and added to one browser product and the others eventually coppied them. Some things went over well and persisted as standards, such as iFrame, etc. Others didn't make it very far, such as Layers.

The most recent example of this I can think of is the Cavnas tag... but pretty much all tags were done in this way. If you waited for the "tight standards" the web would never get anywhere, and there would not be any preasure to push a new standard without people implementing new ideas ahead of the standards.

error

@The Bytemaster said:

closing tags ~~were almost~~are still optional ~~in the early days~~for many elements including <html>, <head>, <body>, and <li>,

Valid HTML 5:

<!DOCTYPE html>
<head>
<title></title>
<body>
<ul><li>Hello, world!</ul>

Valid HTML 4.01 Strict:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
<head>
<title></title>
<body>
<ul><li>Hello, world!</ul>

(The highlighted text can be omitted and still validate as well.)

error

@The Bytemaster said:

The most recent example of this I can think of is the Cavnas tag.

The purpose of this element mystifies me. It's completely opaque, so without running the script there's no telling what content it contains; without script it's basically a div, but with script you could instantiate and insert the object anywhere in the DOM directly, so the element itself is superfluous. So why does there need to be a special canvas element, why do you need a special placeholder in the DOM to getContext( '2d' )? It seems like you could just have the API work with plain old divs and it wouldn't be any different.

It's not the only new HTML5 element I've seen that is used for accessing special APIs, either. Today I was playing with dialog elements. Again, I'm wondering why couple the functionality with the special tag.

toon

@The Bytemaster said:

@toon said:
I suspect too few people realize that proper markup and good CSS use go a long way towards cross-browser compatibility. If more people realized that, perhaps markup would be better.
Very true, but people also do not remember (and have a very short memory) of how the web was built in the first place. Browser makers constantly added new items to their set, and closing tags were almost optional in the early days. Javascript was invented and added to one browser product and the others eventually coppied them. Some things went over well and persisted as standards, such as iFrame, etc. Others didn't make it very far, such as Layers.
The most recent example of this I can think of is the Cavnas tag... but pretty much all tags were done in this way. If you waited for the "tight standards" the web would never get anywhere, and there would not be any preasure to push a new standard without people implementing new ideas ahead of the standards.

Yeah, I believe you're talking about when you weren't supposed to use end tags for the element. I remember those days well, I made my first website with HTML 2. That was 16 years ago: I personally think the web has changed slightly since those days. Seriously, you can't compare today to the times when people were still using dial-up and Windows 95 was almost out.

spamcourt

@joe.edwards said:

Draconian policies on markup would have had a chilling effect on the growth of the web, and it may have never entered the mainstream if it required years of education and careful attention to detail just to publish a web page. As much as I hate tagsoup markup, if browsers didn't tolerate it the web would be a pretty barren place, and that would cut its popularity down to vanishing. Also, consider the business implications to a company if a content-entry intern could crash their production website by being a bit careless with the markup.

What if

what if web sites were generated by software?

No seriously, listen: you write a page in broken HTML-ish language. You run "xhtmlgen myBrokenFile.html". You open the file with a web browser and confirm it still shows the way you intended it. You publish. Since browsers don't have to deal with broken crap, the probability of your page showing the same way in all of them is also higher. Naturally you don't have to do all those steps one by one manually, you could type the code and be able to see the result in one or fewer keystrokes.

I mean... it is the way we do everything else after all.

Mason_Wheeler

@spamcourt said:

I mean... it is the way we do everything else after all.

Yes it is, and there's a good reason why that's how we do it. Because it works. Because it's stood the test of time as a proven methodology to allow human beings, with their well-known tendencies to make mistakes and forget details, to produce working code.

And then the Mosaic and Netscape folks decided to throw decades of accumulated knowledge about making things that work out the window, and we're still paying for it today.

MiffTheFox

@The Bytemaster said:

The most recent example of this I can think of is the Cavnas tag... but pretty much all tags were done in this way. If you waited for the "tight standards" the web would never get anywhere, and there would not be any preasure to push a new standard without people implementing new ideas ahead of the standards.

The most recent example is the Canvas tag? Try any "HTML5" feature at all. New elements and data- attributes? Gecko has been letting you just make up any element or attribute. contenteditable? Mozilla's version of IE's designMode. Local Storage? Google Gears. webkit-linear-gradient/moz-linear-gradient? The original webkit-linear-gradient had a completely different syntax even! text-shadow? Apple (hence why it doesn't have a vendor prefix).

Note how the "new" elements in HTML5 that have boolean values are a mismash of true/false, yes/no, on/off, and simply only able to be turned off in markup by omitting it. HTML5 is just the W3C trying to consolidate all the proprietary features Microsoft, Apple, Google, and Mozilla have been inventing since the last browser war.

On the note of what to do about bad HTML, keep in mind that Chrome and IE have been messing up sites with inconsistent HTTPS for a while now.

ekolis

@spamcourt said:

What if

what if web sites were generated by software?

No seriously, listen: you write a page in broken HTML-ish language. You run "xhtmlgen myBrokenFile.html". You open the file with a web browser and confirm it still shows the way you intended it. You publish. Since browsers don't have to deal with broken crap, the probability of your page showing the same way in all of them is also higher. Naturally you don't have to do all those steps one by one manually, you could type the code and be able to see the result in one or fewer keystrokes.
I mean... it is the way we do everything else after all.

This is the way we do it - it's just that "xhtmlgen" is built into the user's browser, instead of being something that the developer of the site has to run manually on his legacy code.

Automation is good, yes. MORE automation is MORE good.

dhromed

@Mason Wheeler said:

Yes it is, and there's a good reason why that's how we do it. Because it works. Because it's stood the test of time as a proven methodology to allow human beings, with their well-known tendencies to make mistakes and forget details, to produce working code.
And then the Mosaic and Netscape folks decided to throw decades of accumulated knowledge about making things that work out the window, and we're still paying for it today.

...so that's exactly what Blakey's saying.

dhromed

@ekolis said:

it's just that "xhtmlgen" is built into the user's browser, instead of being something that the developer of the site has to run manually on his legacy code.

That's a good point.

@ekolis said:

Automation is good, yes. MORE automation is MORE good.

It's what computers are for, after all.

blakeyrat

@dhromed said:

@ekolis said:
it's just that "xhtmlgen" is built into the user's browser, instead of being something that the developer of the site has to run manually on his legacy code.
That's a good point.

And people seem to be ignoring my post on the last page where I propose the "HTML compatibility must die!!!!!" people could accomplish that without actually compromising their perfect browsers of perfectness by using a simple web service.

But that's ok, my brain works so fast I'm always like 20 steps ahead of the conversation. Also: handsome.

dhromed

@blakeyrat said:

Also: handsome.

Lies.