<br /> redundant?

[duniyadnd]

I was going through the w3.org site, and it had a bunch of listings of elements and specified if they were redundant, still used, or dead.

http://www.w3.org/TR/html401/index/elements.html

They listed <br> tag as redundant. I was curious what would we be using in its place if it is so.

Duniyadnd

[liorean]

Whatever block tags best describe the situation. In XHTML2 we will get the new line tag that should be used to wrap the text to go on one line, instead. (You can always emulate br using <line/>.)

The thing is, block tags can provide that linebreak automagically, so we should use the block tag that is semantically best for wrapping the line, instead of br. Since not all text lines have clear such semantic meaning, they added the line tag to make the br tag fully redundant.




The img tag is also one of the redundant ones...

[Grant Palin]

Originally posted by liorean
...The img tag is also one of the redundant ones...

Aw, geez! So how are we supposed to insert images? Or do they want us to give those up too?!?

[Saj]

In XHTML 2, you use the <object> tag for images, just like flash and java applets.

[Catman]

Even now you can use <object> in this way -- pretty much any MIME format will display (including HTML) in 5+ browsers.

[Grant Palin]

That's going to take a LOT of getting used to. I'm so used to just typing <img src="...>

[liorean]

Iew doesn't really support object tag in the way W3C intended. You can use it, but it's far more like applet or iframe than it's intended functionality. And it's full of glitches. Try including a png image through an object tag, for instance, and see what happens and how it's rendered.

[bazz]

When you say redundant, do you mean that pages already using <br> or <img src= etc will stop working or is it just that new browsers will not recognise them?

thanks

[liorean]

With redundant, they mean that are not needed as other elements with stronger semantic meaning can already do their work, and may be removed from xhtml2.

It's also a statement to the effect that you should only use them if there is no better choice.

[zoobie]

I just validated my HTML 4.0 which was fine. For the heck of it, I tried it with 4.1 and it wanted me to add all this code bloat just to pass. Seeing as I want to make the most efficient page possible, I can't see where this is necessary...and then I even took out the doc type and char code for my 4.0. :D

[swmr]

Since it is being discussed here, I thought to ask why semantic markup is important... I haven't yet read a description that wasn't just a bunch of jargon.

Take, for example, the <b></b> tag vs. <strong></strong>: why would <strong> convey any more meaning than <b> when they both render bold text?
Would it not be apparent that the designer's intent was to give stronger weight to the text, whether it was in a <b> or <strong> tag? Why use a longer tag to accomplish the same thing? What is the purpose of adding new tags that replace existing ones, when they effectively do nothing different? Using <line /> instead of <br /> seems more confusing than helpful, or necessary. Although, as I'm pretty new to this stuff, I may be missing the point; perhaps someone can enhance my understanding.

By the way, isn't the phrase "semantic meaning" redundant? ;)

[pardicity3]

What does a b mean? Bob? Burn? Bilbo?

What does strong mean? Only one thing, strong. The point here is that b has no real meaning. Yes it is easy to figure out what it means and it may be shorter but that isn't what standards are concerned about. A web programmer uses strong when he or she wants to make a block of text convery more meaning.

In a way, it doesn't matter what the user sees, it is all about what the coder is conveying. Thus, arguing that <b> and <strong> look the same to a user is a moot point. It's not about that, it's about giving meaning to the code.

I have a terrible time trying to convey the importance of semantics to people and I am sure liorean or bro' will be here soon to give you a better answer. All I can say is that it's not what the processed code looks like it's what the unprocessed code looks like.

[meow]

I managed to get at least one person to get it with faked tags. :D

In western cultures black is the color of death and grief, right? Well, in some other cultures white has that meaning. As far as I know grief can be green somewhere on earth.

So, to a westerner using a graphical browser these two would look the same:
<black>sorrow</black>
<death>sorrow</death>

But the Martians' browsers may be configured to show death as green and all of the sudden they don't look alike at all.

In the same way B is just how that bit of text looks. Font weight is type setting and belongs in CSS. EM means that the element is emphasized and that could be denoted in numerous ways. Bold, red, italic, spoken in a stronger voice - the context decides. But to every piece of software that can read HTML it _will_ mean emphasized. That software may be a user agent of any kind, a search engine or a script that maybe looks for certain structural parts just like EM.


pardicity3, where did you see that list of redundant elements? I don't see it denoted in the elements list you posted the URL to.

[swmr]

I sort of get the idea now; however, there are mixed-messages in there: one of you said that the end-user content was a moot point, and the other basically said it was all about how content would be interpreted and displayed for the end-user (even Martians?)... so which one is it?

[mouse]

I don't get it. <b> stands for bold <i> stands for italic, all very simple. How will we do italic now? I don't see how it matters whether the tag conveys a message as the tags are translated by the browser first. The phrase "If it ain't broke, don't fix it" springs to mind.

[meow]

You style whatever it is in italic. The styling doesn't affect what the element is, just how it looks. It's just makeup.

I think we mean the same thing, swmr. It doesn't matter how it looks to the end user, it matters what it means to him (or it :D )

[brothercake]

Semantics is the rub of it:

<strong> has semantic meaning - it means "strong emphasis"; <b> only has visual meaning - darker text.

<em> also semantic meaning, where <i> only has visual meaning.

And so it is with <br /> - it has no real semantic meaning; that's why it's being scrapped.

But I still use it sometimes; afaik there's no other way of doing something like this:

<address>
Street<br />
Town<br />
Country<br />
</address>

So i'd generally say, try to avoid it, but use it if you have to.

[ronaldb66]

Mouse,

suppose you need a sentence with a strong emphasis; you could use <b>:
<b>Strongly emphasized line here!</b>
Now, what if you want to emphasize one word even stronger?
<b>Strongly <b>emphasized</b> line here!</b> sure isn't going to work!
If you use elements with semantic meaning, CSS will allow to supply any style for any combination of elements, nested or not; elements like <b> and <i> have a presentational meaning and should therefore be avoided.

[cg9com]

This seems like a debate more for this (http://www.codingforums.com/showthread.php&threadid=19333) thread ...

as far as the breaking, if you really wanted to, you could avoid them completely.

brothercake:
But I still use it sometimes; afaik there's no other way of doing something like this:

<address>
Street<br />
Town<br />
Country<br />
</address>


could you not use a pre element? or even white-space:pre; CSS.

[cg9com]

Since we are in a discussion on semantics the question will arise:

Where will semantics be when <object> replaces <img> ?
Should we even worry about it? It seems as though they dont.

[brothercake]

Originally posted by cg9com
as far as the breaking, if you really wanted to, you could avoid them completely - could you not use a pre element? or even white-space:pre; CSS.
Not in this case, because it's an address, hence the <address> tag ;)

Every tag means something - <p> <table> <strong> <em> <cite> <address> <blockquote> <q> and so on ... they all mean something. The point is to use each tag to its fullest semantic purpose, and not to use tags for incorrect semantic purpose (such as table for layout or blockquote purely for indentation).

Some tags like <b> <i> <br /> and <font> have no semantic meaning at all; that's why you should avoid using them. <b>, <i> and <font> it's not a problem because there are alternatives; <br /> is more of a problem because somtimes there isn't an alternative.

It helps not to think of a webpage as a visual presentation at all - visual presentation is arbitrary; merely one possible output. What a webpage really is is a semantic logical entity.

[liorean]

If it hadn't been the case that address tag was inline, there is one tag that is just the one you want: div. On the contrary to puplic belief, div has a semantic meaning: it's a division of an element. Since dividing the address into phone, email, country, region, municipality, (sorting directive: zip/postal code), street address is just logical, it's semantically logical to use div for that.

Well, now address doesn't allow divs, so you can't do that. But, semantically, that would be the correct thing, given you can't give it more precise semantic meanings, such as the tags phonenumber, emailaddress etc. that you possibly would have used in the corresponding xml tree.

[brothercake]

Originally posted by liorean
Well, now address doesn't allow divs, so you can't do that. But, semantically, that would be the correct thing, given you can't give it more precise semantic meanings, such as the tags phonenumber, emailaddress etc. that you possibly would have used in the corresponding xml tree.
Well actually <address> is block level, but it doesn't seem to allow other block-level elements inside it. And you can't wrap it in a paragraph either. I remember bemoaning this only recently http://www.codingforums.com/showthread.php?s=&threadid=17847

More specifics would be nice, if arguably beyond the scope of default XHTML. But I'm surprised there's no <date> tag.

[meow]

Originally posted by cg9com
Since we are in a discussion on semantics the question will arise:

Where will semantics be when <object> replaces <img> ?
Should we even worry about it? It seems as though they dont.

I think the main reason they do away with IMAGE isn't lack of semantics but that it is an empty element. OBJECT isn't. Markup should <mark>something</up>, or so they say. :p

[duniyadnd]

So for redundant tags, where do we find information for those tags which we can use for replacements? (<line /> tag wasn't working for <br />)

And if they're redundant, are we in danger of future browsers for not recognizing them?

I'll have to go with mouse by saying if it ain't broke, don't fix it. Just going back and changing the code all over again for code commonly used in so many pages because it doesn't have "semantic meaning" seems absurd.

Duniyadnd

[meow]

But it is broke.

I doubt that old style pages will stop to work in major browsers any time soon though. They have to support tag soup. That's why they have two rendering modes since a couple of years back (Opera too since a few months back) I guess.

[liorean]

Well, I for one would like the standards mode to be far stricter, and to use a validating xml parser when appropriate.

As for the line tag, have a look at XHTML2 WD <http://www.w3.org/TR/xhtml2/> (last updated yesterday), it's an XHTML2 invention. Also note that W3C doesn't intend XHTML2 to be fully backwards compatible - it's an entirely new language that just happens to have much in common with [XHTML1]. This is further emphasised by the fact that it has it's own namespace, "http://www.w3.org/2002/06/xhtml2".

Also, XHTML2 should never be sent as text/html.

[My 500th post! Yihaaa!]

[jkd]

Originally posted by liorean
Also, XHTML2 should never be sent as text/html.

Nor should XHTML 1.1.

[meow]

Well, it may and most certainly almost always is. The latter is what makes XHTML 1.0 pretty pointless in my mind. It's hard to see it as much else than yet another transitional state or a learning experience.

http://www.w3.org/TR/xhtml-media-types/#summary

[brothercake]

iirc:

XHTML 1.0 may be served as XML;
XHTML 1.1 should be served as XML;
XHTML 2 must be served as XML.

Don't underestimate the importance of transitional stages - you might be ready to jump straight into XHTML 2 - good for you - but most people won't be. XHTML 1 provides the framework for serving web pages as XML, without requiring it, and makes the long-term transition to XHTML 2 much easier to manage, both for browser vendors and webpage authors

[liorean]

The fact that XHTML2 is just a working draft, and thus far lacks stability, reliability and full specification of it's announced features, not to speak of a complete DTD of the current version, makes it no better than an arbitrary XML language for the moment - in practice. It's namespace is supported in no browser right now, and that makes it practically useless. Any interest in it for the moment must be either to see what way to go, to implement, what old features don't seem to make it, and the reasoning W3C put behind it.

In other words, XHTML2 is the future, but for now it's only theory at it's best.



XHTML2 lacks a serious features that HTML had - HTML was easy to learn by look-and-learn, trial-and-error methods. All XML languages, XHTML2 no less, are far more complicated to learn and sport more rigid and less fault-tolerant syntax. That makes the learning curve steeper. Thus, the transitional states makes a good way to gradually transform from SGML HTML to XML XHTML2. In the same time, it's a good way to show the path to separation or content and pretentation, and how to make your pages semantically more correct. It also enforces the document structure, to ease parsing of and computation on documents.

[jkd]

Originally posted by liorean
not to speak of a complete DTD of the current version

AFAIK there is a RelaxNG definition, and once with specs stabilize a bit, equivalent XML Schema and DTDs will be written. But you can validate XHTML 2 with the RelaxNG Schema, which does not make it as useless as an arbitrary XML language.

I'm looking forward to XHTML 2, but no one can really use it until Candidate Recommendation status...

[liorean]

Yes they can - but they'd have to realise that it may possibly get changed both in regard to implementation and specification without any notice. It's the same as with any other non-frozen language.

As for RELAX NG, I don't know of any RELAX NG validator, and only a few full XML Schema validators. DTD validators on the other hand exist in pretty much every language that is used by some part of the general public. Also, I don't know of any user agent supporting RELAX NG.