Useful HTML elements that 90% of all developers are unaware of

[Hierophant]

Also, an often-forgotten element: <pre>!
Use it for blocks of preformatted text, i.e. a block of code.

But should one put a lot of time in a deprecated element though?

[vgarcia]

But should one put a lot of time in a deprecated element though?

Pre is not deprecated, only certain attributes of the element .

[Webnauts]

Pre is not deprecated, only certain attributes of the element [img]images/smilies/smile.gif[/img].

Is the <PRE> tag accessible?

[vgarcia]

Is the <PRE> tag accessible?

I would think so. It's meant for preformatted text, like blocks of code. I don't know what the <pre> tag sounds like coming through a screen reader however . I would think that it's fine, as it goes something like this:

<p>Sample Java code:</p>
<pre>
public static void main (string[] args) {
  doThis();
}
</pre>

[Webnauts]

I would think so. It's meant for preformatted text, like blocks of code. I don't know what the <pre> tag sounds like coming through a screen reader however [img]images/smilies/frown.gif[/img]. I would think that it's fine, as it goes something like this:

<p>Sample Java code:</p>
<pre>
public static void main (string[] args) {
doThis();
}
</pre>

But I thought that the content of this tag produces an absolute width.
And that can cause problems at lower screen resolutions.

[JMulder]

Also, an often-forgotten element: <pre>

I always use <pre> to use it along with PHP's print_r() to output the contents of an array.

[Hierophant]

Pre is not deprecated, only certain attributes of the element .

Hmmm... Thought it was. Oh well. I don't run any technical sites anymore and so have no use for this particular tag.

[vgarcia]

Hmmm... Thought it was. Oh well. I don't run any technical sites anymore and so have no use for this particular tag.

<xmp>, <kbd>, and a lot of other tags similar to <pre> were deprecated for the sake of simplicity. Maybe it's one of those that you were thinking of?

[Hierophant]

Possibly... Would make since to deprecate <pre> though as well. It is a style related tag and since style should be done through CSS, it is no longer necessary. Any tag that imposes a style by default should be eliminated.

For the uses that <pre> fulfills a better tag to utilize would be the <code> tag as then it would be easier to handle alternative devices such as screen readers and printers to handle the code properly.

<kbd> is not deprecated according to the XHTML DTD though... It is a valid tag. Decided to take another look after my <pre> mishap.

<!ENTITY % special.pre
   "br | span | bdo | map">


<!ENTITY % special
   "%special.pre; | object | img ">

<!ENTITY % fontstyle "tt | i | b | big | small ">

<!ENTITY % phrase "em | strong | dfn | code | q |
                   samp | kbd | var | cite | abbr | acronym | sub | sup ">

<!ENTITY % inline.forms "input | select | textarea | label | button">

<!-- these can occur at block or inline level -->
<!ENTITY % misc.inline "ins | del | script">

<!-- these can only occur at block level -->
<!ENTITY % misc "noscript | %misc.inline;">

<!ENTITY % inline "a | %special; | %fontstyle; | %phrase; | %inline.forms;">

<!-- %Inline; covers inline or "text-level" elements -->
<!ENTITY % Inline "(#PCDATA | %inline; | %misc.inline;)*">

[vgarcia]

Well, the <code> tag is meant as an inline version of <pre>, which is a block-level element. I agree that <code> has more semantic meaning than "pre"-formatted text, but the whole thing is similar to the <q> vs. <blockquote> battle.

[beetle]

Any tag that imposes a style by default should be eliminated.

I disagree. That would get rid of h1-6, code, strong, em, blockquote, a, sub, sup, ul, ol, li, dl, dt, dd, etc, etc. DIV and SPAN would be the only ones left standing, really.

Non-CSS styled HTML should still have some presentational formatting. Use CSS to override it where necessary, but the <pre> tag provides a purpose - not only to let a human reader of the HTML know that it's preformatted text, but to let the browser know to preserve whitespace and not wrap lines. These extra HTML elements exist to give use a basic presentational format upon which we can build more complex layouts and appearances. Their default rendering can be controlled, thus, shouldn't be eliminated because of that default rendering.

[redux]

I disagree. That would get rid of h1-6, code, strong, em, blockquote, a, sub, sup, ul, ol, li, dl, dt, dd, etc, etc.

well, i dis-disagree (i.e. i agree with wayne ). PRE means preformatted, hence it's a tag that deals exclusively with formatting. h1-h6 etc have semantic meaning, PRE doesn't. KBD for instance has some semantic meaning...at least more than PRE.

[beetle]

I see what you're saying, but I think <pre> does have semantics.

pre This tag contains ALREADY FORMATTED text

Somewhat of an exception to a rule. In that way, I think it describes it's content just as well as any other tag.

Similar to say, sub and sup. Their name denotes visual format, and it's their formatting that visually defines them to a reader. Without that format, they might as well not exist.

Besides, I was mostly refuking his comment that I quoted, and not <pre> specifically.

[redux]

from a semantics purist point of view, it may be argues that sub and sup are presentational as well...but yeah, that's another discussion

[Hierophant]

Besides, I was mostly refuking his comment that I quoted, and not <pre> specifically.

Off Topic:


Unfortunately, I write my comments as a whole and they are interrelated. You pulled one sentence out of a paragraph and inferred something that was never said.

Why is it that people feel they need to do this? It doesn't add anything but confusion to a written discussion.

However, I do think that some tags such as H1-H6 should be replaced with style as well. Gives better control over layout. I am not doing anything to support browsers over 5 years old. Backwards compatibility can only go so far. Anything that is pre-5th generation is not worth my time. However that is an entirely different topic.

[beetle]

Wayne

I don't think my pulled comment diluted your post at all. Did I feel "the need" to do this? Certainly not. Explain to me how it has become confused.

If you'd like me to comment on other things you said, I will

For the uses that <pre> fulfills a better tag to utilize would be the <code> tag as then it would be easier to handle alternative devices such as screen readers and printers to handle the code properly.

Are ALL <pre> tags in use today encompassing code?

And although I can appreciate the following point of view

However, I do think that some tags such as H1-H6 should be replaced with style as well. Gives better control over layout.

I fail to see how "better control" is afforded by no default format. CSS can override anything that is set by default (I said this earlier) so their default style is clearly not an issue in regards to control.

People here keep talking about the semantics of the markup to whatever device reads it, but are complaining about only one such device (the browser). I submit that the issue is with how browsers render markup, not the actual semantic meaning of the markup itself. I think I'll clearly explained that <pre> does have semantics, but if I haven't, I'm interested in hearing your point of view.

[Hierophant]

If you'd like me to comment on other things you said, I will
Are ALL <pre> tags in use today encompassing code?

In my experience system code is the only thing that needs <pre> tags. Show me one piece of data that is not code that needs <pre> or is not represented better in another file format.

I fail to see how "better control" is afforded by no default format. CSS can override anything that is set by default (I said this earlier) so their default style is clearly not an issue in regards to control.

Actually, I am thinking of other devices. You get better control over your text when it is just that, text. You lose control when there are preconceived ideas on how it should be rendered by a programmer who doesn't have your best interests at heart. When you treat text as text, you do not have to worry about all the extra baggage people add on to it.

When a screen reader is reading something, having subheadings which are bullet points for onscreen reading, aren't always necessary. You only need a sub-heading when you are definately switching topics. This means in an Aural stylesheet you can do away with headings altogether. Of course you can overlay this on top of <h#> tags but it just makes messy code in my opinion. For code to be machine readable, like XHTML is, it should be clean. The fewer entities the better.

Alternatively, you can use a simple class to signify a pagebreak in a printer stylesheet or simply change all formatting completely on a mobile stylesheet using all the same HTML code in a document. This allows you to eliminate a browser as a middleman and make customized applets to fit a businesses needs without all the weight a visual browser brings. For that purpose visual tags get in the way because as you said, not everything is meant to work on visual browsers these days.

I guess we'll just have to agree to disagree on this point.

[beetle]

I don't necessarily think we have to disagree. I like alot of what you said - much of it is not in contrast to anything I've stated.

I did find a few things odd

In my experience system code is the only thing that needs <pre> tags. Show me one piece of data that is not code that needs <pre> or is not represented better in another file format.

Surely the status quo isn't set by your experience! (What about a tab-delimited file, or something of that nature?) Jofa, whom I consider a very knowledgable person, started this thread because of a new element he found. What if it were up to him to choose what elements we are all allowed to used in <form>s? We'd lose <fieldset>! (not trying to rag on ya, Jofa )

For that purpose visual tags get in the way because as you said, not everything is meant to work on visual browsers these days.

Yes, and everything I've seen with my own eyes, ignores visual tags it doesn't understand (such as Lynx). It doesn't try to render <sup> or <code> different, but it doesn't drop their content either. The text still comes through as text. Seems to be what we are both looking for already. (Example: XHTML, Lynx translated) Am I mistaken? I don't see how they "get in the way". I'd appreciate it if you can clarify.

You get better control over your text when it is just that, text. You lose control when there are preconceived ideas on how it should be rendered by a programmer who doesn't have your best interests at heart.

Doesn't this mean that the problem is with the implementation of the the software for these other devices, and not the semantics of the markup? (warning: crude analogy approaching!) That's akin to blaming shooting deaths on guns or gun makers, instead of the people wielding them.

If your text is just text, then why bother with anything other than <p> elements? Surely you don't propose that additional elements exist JUST so we can style them?

When a screen reader is reading something, having subheadings which are bullet points for onscreen reading, aren't always necessary. You only need a sub-heading when you are definately switching topics

I have no direct experience with screenreaders. Can you elaborate so I better understand? I already only use subheadings when switching topics -- isn't that the point?

Not trying to be a pill

[vgarcia]

Good discussion guys. I'm enjoying the reading

[Webnauts]

Preformatted Tables Using the <PRE> Tag
HTML browsers do not ordinarily render "whitespace" (e.g. spaces, tabs, carriage returns, etc.) in an HTML document as anything other than a single space. The HTML <PRE> tag provides a way of doing this. Anything between <PRE> and </PRE> tags is formatted exactly as typed. In this way a brief table can simply be "typed in," provided a monospace font is used. Here is an example:



To the sighted Web user, this is a plain version of the previous table. But to someone with a disability who is using a screen reader, this table is rendered as:

"Wages for Summer 2000 June July August Mark $360.30 $720.59 Judy $180.15 Bill $720.59 $720.59 Trina $720.59 $720.59 $720.59."

As noted earlier, this is not very useful. Accessible???

[Webnauts]

Good discussion guys. I'm enjoying the reading [img]images/smilies/smile.gif[/img]

Cool! Then go on reading...

[Paul_C]

That's a poor example. Why would you be marking up tabular data in anything but a table?
I fail to see why a screen reader should have problems with <pre>formatted text. If they can manage text that's broken up by <br />s (for example) what is the difficulty in reading the /n (newline)s between <pre> and </pre> the same way? If you're using <pre> to help out your ASCII art then removing it ain't gonna help you anyway.

[Webnauts]

That's a poor example. Why would you be marking up tabular data in anything but a table?
I fail to see why a screen reader should have problems with <pre>formatted text. If they can manage text that's broken up by <br />s (for example) what is the difficulty in reading the /n (newline)s between <pre> and </pre> the same way? If you're using <pre> to help out your ASCII art then removing it ain't gonna help you anyway.

My apologies for the poor example. But I thought that there are also here newbies in Web Design, who might have done this mistake...

[Paul_C]

Well, it is a fine example of improperly marking up content - something to avoid in general - but that's all it really illustrates. I don't see why <pre> is inherently evil just because it can be misused.

[Webnauts]

Another fact is, using <pre> for formatting means that you risk losing the formatting, and that you force people to scroll horizontally if they have smaller width than you did.

For example see here:

http://www.netmechanic.com/news/vol6...xample_no9.htm