Talk:HTML element/Archive 1

Archive 1

(Early comments)

I removed the Wikipedia logo image example under the Images section for a few reasons.

First, it is a somewhat confusing example - being an image linking to a document with seemingly the same name as the image (the image description page), a fact which must be qualified, at the cost of making the example harder to understand.

Second, because the formatting is ugly (an inline image that disrupts text flow) and I couldn't think of a way to make it non-ugly; I thought about putting it in a floating div as a sort of factoid, but with monospaced text to show code, it would most likely run off the edge. Related to this is the fact that it disrupts the flow of term/definition that is now used throughout the article. There may be a way to make it fit within the definition of the img element, but it's not really part of the definition.

Third, because I couldn't really see what the example was intended to illustrate. If the goal is to show the difference between the title and alt attributes, it doesn't work, since "alt text" specified in a Wikicode image (i.e., [[Image:Wiki.png|Some text]]) is not actually alt text, but title text, making the immediately preceding snippet of code incorrect. According to the example code, <img src="http://en.wikipedia.org/upload/b/bc/Wiki.png" title="example of an image" alt="Wikipedia logo">, one would expect the tooltip text to be "example of an image", when, as rendered, it's actually "Wikipedia logo". If the goal of the example is to show when an image is or isn't a link, it doesn't work for that either; it's stated that this code generates no link--strictly speaking, if that code were used alone, no link would be generated--but that code isn't used; instead, the image wikicode is used, which always generates a link.

Finally, whether the example is for illustrating image linkage, tooltip text, or whatever, it only peripherally has anything to do with understanding the img element. I don't think this example should be here at all. Comments? -- Wapcaplet 17:39, 9 Sep 2004 (UTC)

• Since there have been no comments on the above, I've removed the example in question. If anyone has problems with it, please discuss here. -- Wapcaplet 20:42, 1 Oct 2004 (UTC)

• • Just as a reply to the above: <img src="http://en.wikipedia.org/upload/b/bc/Wiki.png" title="example of an image" alt="Wikipedia logo"> should have the tooltip "example of an image". Any browser that shows "wikipedia logo" as a tooltip is getting it wrong :) porges 20:51, May 2, 2005 (UTC)

It pisses me off when every source uses the "inline" term without defining it. lysdexia 23:46, 23 Oct 2004 (UTC)

I suppose you are saying that you wish there was a definition of "inline" in the article. Done. By the way, what aspect of this article do you find in need of cleanup? I recently did a complete overhaul of this article and think it's in pretty good shape. If you have suggestions for improvement, please don't hesitate to bring them up, or implement them yourself. -- Wapcaplet 03:49, 24 Oct 2004 (UTC)

The text at the top should direct the reader to a page about which html elements can be used in Wikipedia? Chira 22:58, 26 Oct 2004 (UTC)

Done.--Patrick 01:49, 2004 Oct 27 (UTC)

Lovely! Thanks so much! Chira 21:14, 27 Oct 2004 (UTC)

Thanks

Thanks for this great information!→ JarlaxleArtemis 05:38, 1 Feb 2005 (UTC)</math>

"Deprecated"

I dispute that all the presentational tags are "deprecated". <i> and <b> have valid uses which make more sense than their 'equivalent CSS' (for example, <i lang="fr">j'ai besoin de</i> versus <span lang="fr">j'ai besoin de</span> with supporting CSS rules; the first has implicit styling information for older, non-CSS browsers)... and sub/sup, while listed in the presentational module, can carry important logical information - (e.g. H₂O vs. H<span class="enumerator">2</span>O with supporting CSS.) The only elements that are deprecated in HTML 4.01 are 'applet', 'basefont', 'center', 'dir', 'font', 'isindex', 'menu', 's', 'strike', and 'u'. porges 05:00, Mar 14, 2005 (UTC)

• True enough. I've fixed it (and moved some of them to the more appropriate "structured text" section). -- Wapcaplet 01:21, 15 Mar 2005 (UTC)

• • Good work, thanks :) porges 03:53, Mar 21, 2005 (UTC)

The use of "<i>" and "<b>" tags "is discouraged in favor of style sheets"[1]. There is no reason to continue to use them. For example, instead of <i lang="fr">j'ai besoin de</i> , I would write something like <em lang="fr">j'ai besoin de</em> which will render adequately (typically in italics) even on older non-CSS browsers. I agree that "sub" and "sup" tags are still useful[2]. --DavidCary 05:16, 20 December 2005 (UTC)

Unless j'ai besoin de is something you want to emphasize, using span or i is in fact more correct. Semantic markup is about meaning — don't use it unless you mean it. Aapo Laitinen 10:02, 20 December 2005 (UTC)

I know this is an old conversation, but I couldn't help but insert my 2¢ here. I agree using <em> is wrong for the example “j’ai besoin de”, however I would say its still not semantic to use <i> which you cannot possibly ‘mean’ in the sense you use above. Italics are purely presentational so you cannot mean italics in the semantic sense. if the phrase in french has no other elementt marking its beginning and end then it is precisely the purpose of the <span> element. By adding the lang="fr" attribute a stylesheete can style this apporpiately. In fact, one can use the stylesheet to select any element that has a lang attribute set, style it in the manner you choose. And then add selectors for the languages you want excluded (e.g., lang="en"). In this way any foreign phrases (in terms defined in the stylesheete) wil be presented in the same manner. Using <i> instead doesn't imply enough about presentation. Someone using an aural browser for instance cannot hear the italics. So I would say that italics and bold elements really serve no purpose in a well composed semantic HTML document.

Also on the exmaple of H₂O, this too could be more meaningful. In certain contexts where many molecular compounds are being described, one could use an HTML element like <span class='atomic-count' > or even <sub class='atomic-count' > or something along those lines. The styleshseet could then select those and apply s subscript to them. The added structure provides a way to know the precise meaning of this HTML element rather than simply how its styled.;

Could someone update how to bold a word or phrase with css correctly here HTML_element#Official. I gather its using <span>, but the example replacement of <b> doesn't tell how to completely replace it. Thanks Noelpleon 19:29, 20 March 2007 (UTC)

Article on each element?

Should elements link to an article on each? I created DIV (HTML tag) because it was a red link in div. --Singkong2005 12:21, 8 January 2006 (UTC)

• Judging by some of the discussions here, I would think there is enough to say about most of them to justify a (short) article on each. However I would argue against creating each of them until someone has the time/energy to create a decent start for the article - not just dozens of brief stubs. There might be enough to justify quite a few articles on (X)HTML attributes too - like 'target', 'title', 'lang', the event-based ones like 'onmouseup', etc. On that score, I would say that the others should be named like 'DIV (HTML element)', rather than 'tag'. It's a shame that 'div (HTML element)' is not feasible; I don't think that 'Div (HTML element)'...'this article should be named... but can't be for technical reasons' is a good compromise. --Nigelj 15:28, 23 April 2006 (UTC)

• Regarding the naming of such articles: Most "standards" articles follow the convention "Mainpage:Subpage" (e.g. ISO 639:a) so it would be good to do the same thing here : HTML Element:div. --Iancarter 08:06, 17 June 2006 (UTC)

I'd prefer to see elaboration on these elements, butt keeping them all on the same page. The task of loading a page for each element will be quite tedious. If the size of the main page gets unwieldsy, then i could see separating out different sectiont to their own page: like block, inline, presentation, etc.). --Cplot 21:37, 7 July 2006 (UTC)

Wrong nesting in HTML?

<p>Lucy kissed <em>Jimmy</p></em> is not wrong in HTML, but rather wrong in XHTML. Nesting the way <p>Lucy kissed <em>Jimmy</p></em> does is not "wrong". Understand that only XML and XHTML makes the user have to nest <a><b></b></a>, however, HTML does not, <a><b></a></b> is fine in HTML. Any way of nesting is fine in HTML, it's just that you may not get the exact thing that you wanted it to display.

-- 21:42, 26 April 2006 (UTC)

Mismatched nesting is wrong in HTML. Try it out at http://validator.w3.org/ . Your example fails to pass (using the less strict HTML 4.01 Transitional). Eric119 22:27, 26 April 2006 (UTC)

"</p>" is wrong on HTML, and in 's example with that removed, 'nesting' would not apply. The rules of SGML to a DTD (e.g. HTML) are just as strict as the rules of X(HT)ML or any other computer language, just different. So "Any way of nesting is fine..." is patent nonsense. Browsers were always designed to be as forgiving as possible - but that doesn't mean that authors should push their luck by being as slapdash as their one version of IE will let them be! --Nigelj 20:39, 27 April 2006 (UTC)

Incorrect: </p> is not wrong in HTML. It's optional, but it is as correct to include it as to leave it out. 81.178.65.121 14:00, 13 June 2006 (UTC)

Links and anchors

I added a link from fragment to its defining article. I also slightly reworded a sentence to avoid implying that the fragment is part of the URL—they are separate. The main practical difference is that a Web browser typically processes the fragment itself and does not send the fragment to the Web server with the rest of the URL when requesting a resource such as a Web page. The distinction can matter if, for example, a Web server redirects a URL; the server knows nothing about the fragment, and the browser may not be able to apply the fragment to the page it ultimately receives. Teratornis 20:03, 15 June 2006 (UTC)

Wiki permitted HTML elements

I'm not sure why this table appears so prominently on this page, So I'm going to remove it and add mention of the Wiki help page in its place. --Cplot 18:24, 7 July 2006 (UTC)

Wrong data entered in page?

I am no expert in HTML code, but under the Frames subheading in the main article, it says:

     <noframes>…</noframes>
     Contains a normal <body> element with children that will appear in web browsers that don't support frames.

Now I'm no expert in HTML, but I doubt that children appearing in webpages is incorrect, is this article wrong? Please correct me if I am wrong. --Dave 21:26, 17 August 2006 (UTC)

Children=subelements. Jaxad0127 02:29, 17 July 2006 (UTC)

I think maybe it would be better to use the phrase child elements over children. Even though I wrote that, I can see how it would be ambiguous to an uninitated reader (and maybe even an initiated one). --Cplot 00:23, 18 July 2006 (UTC)

Thanks for pointing this out, you've been very helpful --Dave 21:26, 17 August 2006 (UTC)

HTML, not XHTML

The article uses XHTML tags which are not valid HTML, e.g., <base/>, <link/>, <meta/>, <img/>. If this article is about HTML elements, I think that the pure HTML forms should be used (<base>, <link>, <meta>, <img>). Furthermore, <br/> and <area/> have the note "XML compatible". Shouldn't this say "XHTML compatible"? —Ksn 19:41, 25 July 2006 (UTC)

Change them to <img />, which is HTML compatible and the prefered XHTML method. Jaxad0127 20:26, 25 July 2006 (UTC)

You miss my point. Yes, <img /> (with or without that space) is valid XHTML, but it is invalid HTML and consequently should not be used in this HTML-specific article. —Ksn 01:17, 1 August 2006 (UTC)

No it isn't. I just tried (using the W3C's validator and HTML 4.01 Strict doctype) and it was accepted. Just because it isn't standard doesn't mean it isn't valid. Jaxad0127 02:17, 1 August 2006 (UTC)

Okay, maybe "valid" wasn't the right word. The point I'm trying to make remains: syntax such as <tag/> is XHTML syntax; you won't find it in any HTML reference. This article is about HTML, not XHTML, therefore it should use standard HTML syntax, not XHTML syntax that just happens to pass some HTML validator. —Ksn 00:25, 5 August 2006 (UTC)

If you look through the article you'll see its about HTML in both forms the SGML diretly descended HTML and the XML descended XHTML. XHTML uses a root HTML element and It declares itself in its DTD as html. The article discusses the differences and similarities between these two specifications of HTML. It also explains the use of the self-closing tag shortcut. I'm not sure what's gained by trying to convince peopple that XHTML is something vastly different than HTML. The article chronicles the difference between HTML 4.01 and XHTML 4.01 and there are only a few very minor syntacti differences. But as I've said before, those syntactic differences make HTML much more flexible and easily extended.

And BTW, the reason the HTML validators have virtually all been converted to support the self-closing tag shortcut. Placing <img/> is the same as <img></img> which is valid HTML 4.01 though cumberrsome to type. --Cplot 01:31, 5 August 2006 (UTC)

Let me add one more point. The W3C recommends using self-closing tags for elements defined to be empty even in HTML 4.01 to ease the transition to XHTML 1.1 and beyond. (which is why they needed the validators to recognize this syntax) --Cplot 01:34, 5 August 2006 (UTC)

This is completely bogus. The reason it's valid is because /> is a shorthand syntax. See http://hixie.ch/advocacy/xhtml for an explanation. Anne van Kesteren 15:10, 17 December 2006 (UTC)

Nice picture

Maybe it would be good to include the nice picture HTML_element_structure.png‎ from this article also in the article about HTML and create a similar picture for the article about XML. The figure is really instructive. Ajgorhoe 23:20, 21 October 2006 (UTC)

Name of <a> element

Why was the <a> element named that? What does the "a" stand for? Does the naming have a history? Thanks, -- Creidieki 14:53, 21 November 2006 (UTC)

'a' is short for anchor, referring to an end of a link. -- 82.46.154.93 05:49, 10 December 2006 (UTC)

Center tag help

I'm trying to center, most info pointing me to this article here for the HTML tag but the HTML tag is "Deprecated" and it says for the use of <div> and the best thing is there is not a decent link or explanation how to use that "div" tag, with all that jargon and lots of overwhelming CSS information when i just want to be able to center something. So can some one point me out because after so much reading frustration I'm like exploding. --189.149.42.87 05:40, 11 December 2006 (UTC)

It's not the 'div' that's important, but a CSS instruction in a 'style' attribute. If it's a paragraph, <p style="text-align:center">This is centred text</p> will do it. If it's not anything, or is several things, then maybe wrap it up in a 'div' just to style it: <div style="text-align:center"><h1>This is centred text</h1><p>And so is this</p><div>. Hope this helps. --Nigelj 22:06, 11 December 2006 (UTC)

That will only work for centering text. If you use margin:auto on a block element (IIRC) it should work for even images and other non-text. A bit more precise: <div style='margin: 0 auto;'> should be a good start tag. You can make an element block using display:block. If you are doing much web development, you should learn CSS. Ealex292 00:26, 21 December 2006 (UTC)

Lost content

Apparently, some content was lost in September 2006 due to spam edits and never fully restored:

• http://en.wikipedia.org/w/index.php?title=HTML_element&diff=next&oldid=75894832
• http://en.wikipedia.org/w/index.php?title=HTML_element&diff=next&oldid=75902024

Is this intentional? — Tobias Bergemann 16:39, 21 February 2007 (UTC)

I have restored the lost content (description of lists and general containers). Now it needs to be integrated with the rest of the article again. —Tobias Bergemann 15:38, 22 February 2007 (UTC)

Article on XHTML element

I think it would be a good idea to make an article like this on XHTML elements, and leave out all the deprecated and discouraged stuff. I would do it myself but the W3C website is like a jungle and it's almost impossible to find stuff there, so therefor I don't know for sure which elements are 100%ly XHTML and which are not. --Stefán Örvarr Sigmundsson 23:00, 17 October 2007 (UTC)

Official tags

I think all unofficial tags should be removed and only W3C ones be included. There are loads of unofficial tags and there is a specific article for those. I see no reason why only 3 should be included in this article. --Stefán Örvarr Sigmundsson 03:06, 7 November 2007 (UTC)

Missing Elements

Should we include all official W3C tags on this page? Why are FIELDSET and LEGEND neglected in the form section? I will add them unless there is some objection . . . I'm sure there are other missed tags. This could be an awesome reference guide if completed thoroughly. 192.147.57.6 (talk) 17:22, 20 October 2008 (UTC)

The following XHTML1/HTML4 Strict elements are not covered in this page: bdo, body, button, fieldset, head, html, legend, noscript, optgroup. Also, iframes is deprecated, in the sense of not being in Strict (it is in Transitional, I know; maybe the article should clarify the different stages of deprecation as this seems to be a point of previous contention). Maybe if I find time... Anihl (talk) 01:59, 13 March 2009 (UTC)

That line about iframe being deprecated does seem a bit mis leading. Honestly I expected iframe to have it's own wikipedia page, and for that page to be marked controversial ;) A quick google search to check the veracity of the claim that iframe was deprecated in html 5 lead me to believe the opposite, that new features were added to iframe. Mathiastck (talk) 22:30, 3 May 2010 (UTC)

Not a 'How to'

Currently this article is sporting a "This article is a How To..." banner. (Added 26 Jan 2009)

I do not agree with this. As far as I can see, the article is describing the (significant) HTML tags and formats that might be encountered and explaining their correct usage. This is no different to providing a mathematical equation to explain a scientific concept, or program code syntax to explain a software construct. No sane person would take this article and try to use it to create a webpage without further reference elsewhere...

Hymek (talk) 13:09, 23 February 2009 (UTC)

Parts of the article could be moved to Wikipedia:HTML elements or Wikipedia:List of tags, for instructions to the users, but then some of the tags needs to be removed. /Poxnar ^(talk) 14:09, 28 February 2009 (UTC)

Following the re-write (see next section below), remaining wording that suggests 'how-to' has been removed, hence I have removed the 'how-to' banner.

Hymek (talk) 09:44, 25 March 2009 (UTC)

Workplan

I rather think the article needs tidying and clarifying in various areas, so have penned this list of proposals, which I can undertake to carry out the bulk of over the next week or two if no-one has any objections:

1. Revise Hierarchy and complete list:

a. Tables and Forms sections include both block and inline elements, so should be separated.

b. There is no section for principal document structure elements (html, head, body).

c. isindex is not included under document head.

d. Some elements which can be either block or inline (ins, del), or can be either document head or body (script) are shown only under one section; I would prefer to mention them wherever they occur.  I favour a separate section for style, script and noscript as their usage is complex. (Should mention the principle of separation of structure/semantics from presentation and behaviour.)

e. br is not an image-related element, should be moved to an appropriate inline position.

f. there are some historic elements which were part of TBL's early HTML, which were deprecated in HTML 2.0 and 3.2; these should be mentioned, but they were never actually part of standards-recommended practice, so I would propose leaving them in a new “historic” section.

g. collect the frames elements in one section with a little detail on their usage.

Proposed revision: (including missing and historical elements; asterisked elements occur more than once in this hierarchy)

Document Structure: html, head, body

Document Head Elements: title, base, basefont, isindex, link, meta, object*, script*, style*

Document Body Elements

Block Elements

Basic Text: p, h1-h6

Lists: dd, dir, dl, dt, li, menu, ol, ul

Other Block Elements: address, blockquote, center, del*, div, hr, ins*, noscript*, pre, script*

Inline Elements

Anchor: a

Phrase Elements

General: abbr, acronym, dfn, em, strong

Computer : code, kbd, samp, var

Presentation: b, big, font, i, s, small, strike, tt, u

Span: span

Other Inline Elements: br, bdo, cite, del*, ins*, q, script*, sub, sup

Images and Objects: img, object*, applet, param, map, area

Forms: form, button, fieldset, select, optgroup, option, input, label, legend, textarea

Tables: table, tr, th, td, caption, colgroup, col, tbody, tfoot, thead

Frames: frameset, frame, iframe, noframes

Presentation and Behaviour with style*, script* and noscript*, and briefly, WHY

Comment

Historic Elements: LISTING, NEXTID, PLAINTEXT, XMP

Non-standard Elements: - blink, marquee, blackface, shadow, nobr, wbr, embed, noembed

2. Add detail to ensure that every element has its standardisation and deprecation status fully indicated.  (e.g.: html - standardised in HTML 2.0 - still current.)

3. Add references!  These are published, freely available standards; shouldn’t be hard.

4. Note the origin of Tables in RFC1942 "HTML Tables", and any other standards documents which went into the development of elements.

5. Add brief explanation of the concept of deprecation in introduction.

Ambitious?  Yes...  Presumptious?  Maybe...  ;-)  I'll leave it a few days for comments/improvements.

Anihl (talk) 19:56, 18 March 2009 (UTC)

You seem to know what you're doing and have obviously put a lot of thought into this. I would say go for it. Watch your language so that the page will not attract a 'this is a how-to page' banner in the future. (In one place I spotted a "Use element xxxx to do this", which is the sort of text that will attract the banner. Most of it is purely descriptive, which we should get away with.) If the page becomes too long, don't be afraid to break itnto sub-pages, or direct readers to the definitions at W3C and elsewhere.

With a big change such as this it might be appropriate to create something in your sandbox to avoid filling the history with small edits. On the other hand, editing the article carefully in stages could show how the structure has changed.

Hymek (talk) 08:38, 19 March 2009 (UTC)

Excellent! In particular, the addition of information showing the history of each element elevates this document way beyond a mere 'how-to'. Once you're done, could you check you have added a reason for each element that is now deprecated/invalid (isindex, for example)? Also, some of the shorter definitions might benefit from fleshing-out. Hymek (talk) 09:35, 25 March 2009 (UTC)

Glad you like it. ;-) I'm wary of adding too much more as I think this is now a large article, but you have a point. Anihl (talk) 01:54, 31 March 2009 (UTC)

Access key

the html element access key is totally missing. maybe you are able to add this in you're revision! mabdul 0=* 15:42, 28 March 2009 (UTC)

In HTML 4.01/XHTML 1.0 accesskey is an attribute, not an element. There is no HTML attributes article, so this would possibly be best in an article on accessibility, such as Web_accessibility. There has been a suggestion that an access or accesskey element could be developed as part of XHTML 2, but that's a long way off and not really the topic of this article. Anihl (talk) 00:20, 31 March 2009 (UTC)

Span and div

The article on Span and div has been 'converted' to a redirect to here (hence the removal of the 'main' tag from this page). (See this diff)

I am not convinced that that was a correct move (I found it a very helpful article). Should it be restored?

Hymek (talk) 11:10, 30 March 2009 (UTC)

I think the article was good in a sense — but perhaps too helpful in the howto sense. It would certainly be good to have a clear comparison of span and div available, but even a simple form of that would risk lengthening this article too much. Anihl (talk) 02:05, 31 March 2009 (UTC)

Perish the thought that Wikipedia might be helpful to someone!!

I haven't investigated, but perhaps there's scope in transferring the old page content to WikiBooks/Wikiversity/WikiHow? - you could then restore a link from here...that might help address your page length concerns too.

Hymek (talk) 10:48, 31 March 2009 (UTC)

As the person who blanked the Span and div page has been told a few times on his talk page, there are procedures and guidelines that apply to the speedy or otherwise deletion of existing pages in WP. They begin with applying a template to nominate the page for deletion, then arguments for and against are collated before admins make the final decision, including the possibility that the text and maybe the edit history may be kept elsewhere. None of these processes were followed. The page is linked from about 100 places in various namespaces, and has been edited by several people over some years. It is sorely in need of references and citations, and the style and content may be improved, but in my opinion it is not a dead duck and is not inaccurate or misleading in any way. I don't think it is too technical, or any more a how-to than this article. It is a discussion of many of the issues related to the use and misuse of these related tags in modern web design - not something that everybody is interested in, but a valid topic for those who are. So I have restored it. Please feel free to help improve it. --Nigelj (talk) 19:11, 1 April 2009 (UTC)

element name formatting

Thanks & kudos to Svartman for clarifying the PLAINTEXT element's usage.

Regarding format – I originally followed the practice on this page for proprietary elements, and avoided the htmlelement template for this section, as these elements were never standards-based practice and I thought it best to avoid the impression that they could be used in current HTML. This may not be the best approach. I am not sure that making them a code element is the best either, but if this is to be done, I think it should include the ellipsis, as this is how the template appears. (I'm agnostic regarding three-dots vs. the actual hellip character. I am however in favour of consistency, and would appreciate views about which is preferable.) Possibly a new NotAnHTMLElement template would be useful for this and the proprietary elements...?

Anihl (talk) 12:05, 6 May 2009 (UTC)

Tables

I was redirected to this article when I looked up "HTML tables". I was looking for information on specifying borders, cellpadding, etc., but I don't see it here, and don't know where to look. I'm disappointed. Unfree (talk) 19:50, 20 August 2009 (UTC)

I understand. Probably due to WP:HOWTO. There is always Help:Table. Plastikspork _―Œ^(talk) 20:11, 20 August 2009 (UTC)

A Tonne of errors, repeats and vandilism

I'm too lazy to name it all, but this page needs to be cleaned and semi-protected. Chairsenses (talk) —Preceding undated comment added 22:45, 7 January 2010 (UTC).

Block level

The article seems to conflate HTML block/inline level with block/inline values for the display CSS attribute (as do most online tutorials). HTML block and inline level elements are defined in the DTD, and they are constraints on the document structure (generally, inline elements must be wrapped in block elements and cannot contain block elements, but the actual rules are much more complicated); for example, <p><center></center></p> is not valid HTML because center is block level and p cannot contain block level elements (Firefox will actually change it to <p></p><center></center><p></p> when it builds the document tree). The CSS display attribute is largely unrelated, though user agent default stylesheets usually assign block display to block level elements and inline display to inline level elements, but that can be overriden by other CSS rules. --Tgr (talk) 22:36, 28 January 2010 (UTC)

I agree. Do you feel confident to make the necessary fixes to the article wording where required? If so, please go ahead. Some citations (to standards docs or to secondary sources) are important too. --Nigelj (talk) 22:42, 28 January 2010 (UTC)

Twice <ins>...</ins>

The tag <ins>…</ins> is explained in two sections within the same article:

• HTML_element#Other_block_elements
• HTML_element#Other_inline_elements

To avoid rudenduncy, we should keep a single one... Oliver H (talk) 08:06, 3 August 2010 (UTC)

Props

Just wanted give thanks to you who have made this article. Very pleasant. —Preceding unsigned comment added by 96.33.135.123 (talk) 06:55, 10 October 2010 (UTC)

Irrelevant Off-topic Links Contribute to a Low-grade Article

As the reader may know, TheFreeDictionary.com mirrors Wikipedia.org for much of its content. I happened upon this article as a part of a whimsical browse through TheFreeDictionary.com, at which point my reading slowed to a grinding halt: the writing is obviously amateur, as it reads like a high-school B-minus, closed-book essay on HTML. I insist on blunt commentary in this, or any instance of public responsibility concerning the dissemination of standard information, and for the disheartening apparent lack of concern for quality in much of the "web"-related topical content (i.e. a serious critic would regard "high-school", and "B-minus", as a generous assessment).

Some of the remarkable failures which caught my eye follow. The article strays from the topic sentence, arguably, as early as the second sentence. The reader is forced to process irrelevant material in a markup example which links to "Finding Nemo". As if to rehearse this week's vocabulary words, the reader is presented with "an example of synecdoche". Would we not question the motives of an author whose book on HTML included synecdoche in the glossary? It's nonsensical, distracting, and does nothing for the quality of this resource.

It is not my desire to bruise egos, or to flex my own. I find no thrill in the appearance of my own words, yet I feel some responsibility to write them for you. I do not wish to hack apart the text, especially while-- like so many others who provided commentary before me-- I am not motivated to improve it. Perhaps, because its a lot of work, we do not wish to engage the endeavor of editing an article titled "HTML Element". Do we allow the content to remain, for it's more than we would do? If the experienced authors / web developers involved in this discussion were willing to be honest, as readers expect from them; as readers are encouraged to expect reliability from Wikipedia, I suspect we'd have seen stronger proposals than those existing. Surely, I am not prepared to contribute something better, yet I must question this lack of initiative. Jsabarese (talk) 06:23, 2 February 2011 (UTC)

Comparison and Contrast as Element of Editing

I understand that part of the desirability of a resource like Wikipedia is the liberty to contribute one's own ideas, as a meaningful act in the construction of the dynamic whole. I believe, within this context, the dynamic nature of Wikimedia resources, the initiative (and/ or motivation) of an author, his or her resulting contribution, and the maintenance thereof (whether maintained by the original author, or other contributors), each at least must be present that the unique amalgamation of a contributed entry might exist. If this is true, perhaps the reader is imposed with an obligation, should he or she choose to read with a critical eye, to regard the resource in a non-traditional manner; to consider author initiative and article completion apart from skillful writing; to provide some constructive recommendation along with critical commentary.

As one who does engage in occasional writing for a variety of audiences, for various motivations, I often find myself in the process of editing my text. Having some years of experience in the activity, disregarding the benefit of an educated background in the English Language, I admit I likely take for granted some of the techniques I employ as I attempt to better my results, and-- as might be inferred from my commentary, above-- I suppose I expect the quality of other authors' work to demonstrate adequate skill, equal to or better than my own, in writing. It occurs to me that contributing authors might not have the benefit of English as a native Language (for en.wikipedia.org); might exercise great initiative, without reliance upon experience, education, or rudimentary technique for skillful editing when authoring a composition.

Comparison and Contrast: How-to

Assuming the obligation, as a model for future discourse, I offer this anecdote as a recommendation. Sometimes, as part of the editing process, I find value in an objective comparison and contrast between the affect of my writing, and that of an existing sample.

Comparison

Excepting instances where subjective reporting is appropriate, the articles which make up Wikipedia /should/ be unbiased, and objective. In a comparison effort, I might analyze other articles for rhetorical approach to subjectivity. Sometimes, the topic of an article is so broad, it is difficult to find elements for comparison, or so it may seem at least. If not the most important element of any informative resource, it is critical that a topic sentence introduce the article and, furthermore, that the text adheres to that topic. The sole purpose of the body, beyond the topic sentence, is to illustrate, or draw-out that topic, and define it. Any text which is not written to support the topic sentence is superfluous.

Contrast

The toils, or-- for crazy people, the joy-- of Comparison and contrast need not be an exercise in self-loathing deprecation. In other words, the writer might take the opportunity, in contrast, to seek out elements of his or her article which contrast favourably against an existing example, or sample text. How does the rhetoric of your text fair against the sample text? In other words, is the author's text more, or less accessible than the text of the example? You know your audience: how well would the sample text fall upon your readers, in contrast?

Recommended Sample Text

On this instance of my directly referencing the Wikipedia for more information about the NSA's Secure Hash Algorithm, it occurred to me that the article is well-written. For example, the Applications section provides appropriate use of off-topic URL's, and includes citations.

Best wishes... Jsabarese (talk) 14:48, 5 February 2011 (UTC)

Title tag

In this article is stated that the Title tag may only occur once in a document. This is not the case. A title tag can be used to create a tool tip when hovering over an image, in the same manner an alt tag used to display text when hovering over an image. You can test this by duplicating an alt tag and changing <alt>yourtext</alt> to <title>yourtext</title>. This use is not documented at W3C, however all modern browsers will display the tool tip text using the title element in this manner.

Flybert (talk) 23:56, 7 March 2011 (UTC)

Probably a deprecated use. The correct way to do this is <img title="abc"> or <a title="def">… --Izno (talk) 00:09, 8 March 2011 (UTC)

How bout some coverage

re: Other HTML keywords search foundit Like many today subjected to the occasional slings and arrows of HTML source edits sans the benefits of a class in the topic, I've pondered the meanings of certain HTML terminology —which I dare call "keywords".

Case in point, someone writing a very different style used cellpadding, cellspacing, and such tag modifiers in some code I unwillingly had to update. This was largish effort, involves a cumbersome embedded applications system with intricate embedded tables and limited ability to experimentally proceed, and updating the browser facilities to CSS and JAVA are laughably unrealistic. Fiddling was taxing. Resorting to here, I find the terms aren't listed.

OK... I get that they aren't "tags" in the Computer Science sense, but might I suggest a table of modifiers like these, with possible links to appropriate articles covering same would be a truly good idea for those of us who studied more circuits and less codes in our technical education—or the poor kid just trying to get the gist, and who needs the next place to turn for expanding his education.

• While you're building your table, please include all terms once a keyword for any and all versions of HTML... some of us get stuck in the real world where an update costs tens or hundreds of thousands, while the machines in the factory need to keep going.

Secondly, whilst this project is not a def-nor-dic website, why not cross link all the paras herein to a wikibook site which could handle exactly that as a project. I once wrote a macro (Wb,Wd,Wp etc—same syntax's, see deleted page(s) for boilerplate) which could easily be modified to link to a specific topic page on said keyword/HTML tag. best regards, // FrankB 16:04, 18 May 2011 (UTC)

<del>...</del>

Two sections are headed <del>...</del>. That needs to be explained or corrected. 94.30.84.71 (talk) 11:21, 13 June 2011 (UTC)

Archive 1

Abbreviation vs. acronym

I believe the two terms are used incorrectly in the main article. The example says HTML is an abbreviation and abbr is an acronym -- that is the opposite usage that I am used to.

mahima kapoor —The preceding unsigned comment was added by 209.147.168.2 (talk) 03:15, 28 March 2007 (UTC).

I've just changed the example to NATO (before seeing this comment).

• The term "HTML" is the initials of the expression, sometimes called an initialism. I've sometimes come across this being called "hot metal", but that's not an acronym, I don't know if it has a name. ("hot meal" seems closer, and is what HTML provides for some pros). Another example is "IBM", eye-bee-em.
• "abbr" is neither initials nor acronym, but an abbreviation.
• "NATO" (nay-toe) is an acronym. Computing examples are RAM, ROM, BIOS, etc.

Pol098 (talk) 16:34, 17 March 2013 (UTC)

• As is DIRECTLY pulled from the page right now (17:04, 17 March 2013 (UTC)):

<abbr>...</abbr>

Marks an abbreviation, and can make the full form available:

<abbr title="abbreviation">abbr.</abbr>

Standardized in HTML 4.0; still current.

<acronym>...</acronym> (deprecated)

Similar to the abbr element, but marks an acronym:

<acronym title="HNorth Atlantic Treaty Organization"><NATO/acronym>

Standardized in HTML 4.0; still current, not supported in HTML5.

Coded as:

{{Anchor|abbr|abbr_tag}}{{XMLElement|abbr|Abbreviation|...}}
:Marks an [[abbreviation]], and can make the full form available:
::<code>&lt;abbr title="abbreviation"&gt;abbr.&lt;/abbr&gt;</code>
:'''Standardized''' in [[#HTML401|HTML 4.0]]; still current.

{{Anchor|acronym|acronym_tag}}{{XMLElement|acronym|Acronym|...|deprecated=1}}
:Similar to the <code>abbr</code> element, but marks an [[acronym]]:
::<code>&lt;acronym title="HNorth Atlantic Treaty Organization"&gt;&lt;NATO/acronym&gt;</code>
:'''Standardized''' in [[#HTML401|HTML 4.0]]; still current, not supported in [[HTML5]].

Your change to acronym is wrong, and "<acronym title="Hyper Text Markup Language">HTML</acronym>" is right, why change it? I'm going to revert your broken example change, please finish discussing the issue here before breaking the content again, thank you. — T13   ( C • M • Click to learn how to view this signature as intended ) 17:04, 17 March 2013 (UTC)

"HTML" isn't an acronym (as far as I know it's not pronounced as a word; I could conceivably be wrong, but I don't see how). The answer to the question "why change it?": because it's wrong. It's easy enough to change it to a genuine acronym without changing anything substantial; why use an incorrect example unnecessarily? If the "acronym title" element is also used for initialisms, then it should be so stated in the article, in which case HTML would be a correct example. Pol098 (talk) 17:25, 17 March 2013 (UTC)

Ummm.. The first sentence of our own Acronym article reads, "An acronym is an abbreviation formed from the initial components in a phrase or a word." Also, according to the article; "CEO", "URL", "IRA", "SAT", "SQL", "BBC", "OEM", "USA", "PHP", "ASP", and quite frankly the list goes on... None of those are pronounced as a word and I've never seen anything stating that is a requirement of an acronym. w3schools offers <acronym title="as soon as possible">ASAP</acronym> as an example of acronym (not pronounced as a word), htmlquick uses <acronym title="Telecomunications and informatic">Telematic</acronym>, <acronym title="Hyper Text Markup Language">HTML</acronym> (our very disagreement and not pronounced as a word), and <acronym title="Light Amplification by Stimulated Emission of Radiation">Laser</acronym> as examples, html dog uses <acronym title="Cascading Style Sheets">CSS</acronym> as an example (not pronounced as a word), and finally for my list Mozilla uses <acronym title="World Wide Web">WWW</acronym> as it's example (not pronounced as a word)... Consensus in the world seems to be that there is no requirement that an acronym must be pronounceable as a word. — T13   ( C • M • Click to learn how to view this signature as intended ) 18:20, 17 March 2013 (UTC)

You seem to have confused an initialism for an acronym. An iniialism is an acronym, but the reverse is not true. The question is rather moot though, since HTML5 deprecates acronym for abbr, as an acronym (and yes, an initialism) is a more special case of an abbreviation. --Izno (talk) 18:27, 17 March 2013 (UTC)

This is getting confusing; who has confused initialism for acronym according to Izno? Is the statement "An initialism is an acronym, but the reverse is not true." intended, or an error (I'd say the opposite is true). The position as I understand it is in the first sentence of Acronym#Nomenclature. Acronym was created, as a useful word, to distinguish "words" like NATO from initials like "IBM". It is sometimes misused. Misuse is regrettable, because we no longer have a term to describe pronounceable initials; we have destroyed the unique word acronym to provide an unneeded synonym for "initials". It's not terribly important, but it's easy enough in a reference encyclopaedia to use an example which is definitely an acronym rather than one which is, at best, doubtful. Pol098 (talk) 20:03, 17 March 2013 (UTC)

"If the "acronym title" element is also used for initialisms, then it should be so stated in the article." ← I have no problem with you adding that in if it makes you feel better as that is part of what the acronym tag was for. — T13   ( C • M • Click to learn how to view this signature as intended ) 20:46, 17 March 2013 (UTC)

HTML5 missing!

How about elements, attributes, and attribute values introduced in HTML 5, such as <input type="date" ...>? 94.30.84.71 (talk) 11:33, 13 June 2011 (UTC)

Heck, this doesn't even link to the HTML5 specs! Is everyone asleep around here? — SMcCandlish Talk⇒ ʕ(^Õل^ō)ˀ Contribs. 01:11, 4 February 2012 (UTC)

Strike-through on deprecated tags

I haven't changed this myself since I'm not sure of the best way to do it, but striking out deprecated tags just makes the tag very hard to read! 212.9.31.12 (talk) 10:49, 20 July 2011 (UTC)

Use {{grey}} for this. Use {{deprecated code}} (alias {{dc}}) for this. Greying out text is pretty much a universal sign in computing for "this doesn't work", "this is disable", "this should be disregarded", etc. Hmm... I'm of half a mind to make a {{{1}}} template, that would use <del>...</del>, but use CSS to make it grey out instead of strikethrough... — SMcCandlish Talk⇒ ʕ(^Õل^ō)ˀ Contribs. 01:15, 4 February 2012 (UTC)

I was actually of more than half a mind to do it, and did it: {{dc}}. It will be very useful in template documentation and such, too. See the docs for the nifty |title= feature. — SMcCandlish Talk⇒ ʕ(^Õل^ō)ˀ Contribs. 01:45, 4 February 2012 (UTC)

Well, it looks like the structure of Template:XMLElement and Template:HTMLElement is too complicated to just use the simple code in Template:Deprecated code, just because of the "clever" way it is structured to take advantage of the cascade. The test in the code for deprecation is going to have to be moved around. I have other stuff to do, so I'll let someone else deal with it. In the interim, I'm made the really annoying red strikethough grey so it's less bothersome. — SMcCandlish Talk⇒ ʕ(^Õل^ō)ˀ Contribs. 02:08, 4 February 2012 (UTC)

Removing the strikethrough as it's fairly ridiculous. Wikipedia is an encyclopedia, not an online tutorial. Deprecated code tag should be used in examples, not header listing. This is a listing of tags, past and present. Yclept:Berr (talk) 18:24, 11 February 2013 (UTC)

<br> vs. <br /> -- Is one better than, or preferred over, than the other?

One of the other Administrators and I are having a debate on our wiki. I say <br /> is safer, he says it wastes bytes of server space and <br> is preferred in wikitext because it gets parsed automatically. Comments. Perhaps someone can tell me where it says DO NOT CLOSE <br> TAGS LIKE <br />!!!!!! Perhaps I'm being stubborn, but strict DTD HTML standards say ALL tags must be closed. So, I think it is a good practice regardless. -- — T13   ( C • M • Click to learn how to view this signature as intended ) 07:56, 3 April 2012 (UTC)

The MediaWiki parser accepts <br />, <br>, <br/>, and I think even </br>, and outputs the correct xhtml <br />. From the point of view that one is safer or another is not, that is simply incorrect. As for server space, that's also incorrect, as the only space that matters is the one sent to the user; any good server running a wiki will have caching, so that also won't matter. As for automatically, see first point. --Izno (talk) 17:20, 3 April 2012 (UTC)

Tags vs elements

This article begins "An HTML element is an individual component of an HTML document. "

This needs correction. HTML documents don't contain elements, they contain tags. As HTML is an SGML application, the elements (and their closing) can't be inferred from the document alone, but require the document, the DTD and an SGML parser. HTML doesn't have elements until this processing step has been completed, until the supplied HTML document has been parsed and transformed into the internal representation or DOM.

Andy Dingley (talk) 10:03, 18 March 2013 (UTC)