Talk:HTML element

message: At the top of the article it says "For the chemical compound, see Nitrosyl bromide". Why is this and what does that chemical have to do with HTML elements?109.149.80.240 (talk) 14:10, 24 October 2012 (UTC)
replies: text: It was added in July in this unexplained edit. There is no relationship between these two subjects (as far as I can tell). I'm removing it. Mindmatrix 15:50, 24 October 2012 (UTC)
replies: text:  It's presumably a paste from a past article on the <nobr> tag (not part of standard HTML, but quite widely used). Delete it, it's an irrelevance here. Andy Dingley (talk) 16:59, 24 October 2012 (UTC)
replies: text: I put in a more self-explanatory hatnote.  There should be one because if you are search for the article on the chemical and type "nobr" instead of "NOBr" (the chemical formula for nitrosyl bromide) you end up on this page instead of the one you were looking for. -- Beland (talk) 15:24, 24 June 2014 (UTC)
thread_title:  Nitrosyl bromide 

message: Hitting CTRL+++++... to increase the text size in one's Firefox 22 browser causes some lines to overprint the box at the right... Jidanni (talk) 01:21, 1 May 2013 (UTC)
thread_title:  text overprints box 

message: The list of "all" tags needs to be updated:
* B does not define bold text in HTML5.
* DATA is missing.
* HGROUP is no longer part of HTML5.
* ISINDEX (and friends) is missing (since the table claims to include not only HTML5 tags...).
* MAIN is missing.
* SMALL doesn't define "smaller text" in HTML5.
If tags from 'obscure' specifications/drafts are to be listed as well, then there are a lot of missing elements: BANNER, TAB, FIG, OVERLAY, MATH, NOTE, FN (from HTML 3.0), DI (from XHTML 2.0), ... --Andreas Rejbrand (talk) 23:08, 21 August 2013 (UTC)
replies: text: I deleted this section since it also appears to be a copyright violation. -- Beland (talk) 15:11, 24 June 2014 (UTC)

text: * I restored the section as it is significantly different and http://tools.wmflabs.org/dupdet/compare.php?url1=https%3A%2F%2Fen.wikipedia.org%2Fw%2Findex.php%3Ftitle%3DHTML_element%26oldid%3D614074417&url2=http%3A%2F%2Fwww.w3schools.com%2Ftags%2Fdefault.asp&minwords=2&minchars=13 confirms to my satisfaction it is not a CV. —  (e • t • c) 15:49, 24 June 2014 (UTC)
replies: text: * If you use your eyes instead of the tool, https://en.wikipedia.org/w/index.php?title=HTML_element&oldid=614074417#List_of_all_HTML_elements is nearly a word-for-word copy of http://www.w3schools.com/tags/default.asp.  There were other unrelated edits clobbered when this removal was reverting, so I'm restoring the previous version. -- Beland (talk) 17:33, 24 June 2014 (UTC)

text: * I'll also note that the list is redundant with the rest of the article, which already lists all elements, sorted into sections with explanations. -- Beland (talk) 17:35, 24 June 2014 (UTC)
replies: text: * , it's all basic information about the tags, all of which can be found on MDN's HTML developer guide (which uses CC-BY-SA 2.5, which is a compatible license). Since this information can't be copyrighted as it is already released under an open use (albeit attribution) license, there is no CV here. —  (e • t • c) 17:53, 24 June 2014 (UTC)
replies: text: *Technical 13, I don't see where on developer.mozilla.org for example the phrase "Defines a comment" (from the first line of the table) appears.  http://www.w3schools.com/tags/default.asp does not attribute any source, so if that table does exist on developer.mozilla.org under an attribution-required license, then w3schools.com has an unauthorized copy.  It looks to me like the table is original to w3schools.com and is fully copyrighted by them.  Though the content concerns the HTML 5 standard, just because that standard or its official documentation has a copyleft license doesn't mean any given book or web page about HTML 5 must also have a copyleft license.  That would only be true in the case of substantial verbatim copying. --  Beland (talk) 18:21, 24 June 2014 (UTC)
replies: text: * That's the whole point, it is not suppose to be verbatim "Defines a comment", that would be my summary of The Importance of Correct HTML Commenting. The table doesn't need to exist, the information in the table just needs to be available on the multitude of different pages (each row in the table has its own page on MDN).  I don't see any of the formatting and the tool doesn't find any of the exact wording on w3schools of which the content there is common knowledge to anyone in the HTML world and the source upon which it is defined (the legal [=Any&pub_date_type=any rfc] documents for HTML) is actually open source to all. —  (e • t • c) 18:43, 24 June 2014 (UTC)
replies: text: * Copyright only attaches to the exact words used to express an idea, not to the idea itself.  So if we agree that the specific words that w3schools.com put into their table were written by them, then the copyright on that table text belongs to w3schools.  It looks like w3schools does not use an open license, so their specific words cannot be copied into Wikipedia in their entirety. -- Beland (talk) 21:46, 24 June 2014 (UTC)

text: Agreed. I've caught them in errors before, too.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  12:02, 12 June 2015 (UTC)
thread_title:  List of "all" tags 

message: The new layout tags in HTML5 are not present, nor are any other new HTML5 tags. Could someone please find and add them, or provide a reason why they are not here?
Also, I can't find the ... tag. Is it deprecated or nonstandard?  — Preceding unsigned comment added by AnAwesomeArticleEditor (talk • contribs) 21:43, 22 April 2016 (UTC)
replies: text: by me (a while ago). —AnAwesomeArticleEditor (talkcontribs) 02:44, 28 February 2018 (UTC)
thread_title:  What about HTML5 tags? 

message: This article needs a lot of work. A large portion of it is written like a tech manual - so please see what Wikipedia is not. There is no intro. And this article is for writing about the topic based on sources. For the most part I don't see this happening here. Please, bring this into agreement with the WP:MOS. Steve Quinn (talk) 19:33, 19 September 2016 (UTC)
thread_title: Article needs a lot of work

message: I added a new section to the article entitled "Various elements". Feel free to revert if this is not acceptable. Steve Quinn (talk) 21:22, 19 September 2016 (UTC)
thread_title: Added a new section

message: In this section is paragraph ""Elements" and "tags" are terms that are widely confused. HTML documents contain tags, but do not contain the elements. The elements are only generated after the parsing step, from these tags."
I really do not ever hear that. Please source that or delete. Every source I found talks the opposite:
* https://developer.mozilla.org/en-US/docs/Glossary/HTML
* https://www.w3.org/TR/html51/syntax.html#syntax (last paragraph)  — Preceding unsigned comment added by 94.143.171.33 (talk) 18:46, 11 March 2017 (UTC)
replies: text: I second that. This dubious claim has to be either properly sourced oder removed. It confuses users who wish to understand the difference between tags and elements. 2003:6:33B6:D895:B9A1:8144:44FD:DBB2 (talk) 15:11, 26 August 2017 (UTC)

text: At the risk of being a "me too" I "third" it. The article then goes on to talk about "closing tags" on elements. If we consider elements to exist only post-parse there's no reason to consider an element to have a closing tag. If we instead consider an element the start tag, the content, and the end tag then this contradiction is resolved.  — Preceding unsigned comment added by 205.189.3.143 (talk) 19:24, 13 November 2018 (UTC)
thread_title:  Elements vs. tags 

message: Some recent changes seem to be moving this article away from being a description of HTML elements, to being a list of all HTML tags. I see this as a very bad move. We do not need such a list: it is less encyclopedic and also duplicates far better primary sources already out there, such as the W3C and innumerable web tutorials (of varying quality). More importantly though, it dilutes the quality of this important article, which is on the concept of elements, rather than tags, and on their concept, rather than listing those defined. Andy Dingley (talk) 14:19, 23 August 2017 (UTC)
replies: text: So what are the criteria for inclusion/exclusion? - dcljr (talk) 17:39, 23 August 2017 (UTC)
replies: text:  Being an encyclopedic article on the concept of the element, rather than duplicating any number of pre-existing sites by just listing tags, with no discussion of their meaning. The start of this article is useful, almost everything after §Lists (with a few exceptions) is just listcruft. I'm not averse to such a slab of repeated, unsourced listery, but it doesn't belong in this article. Andy Dingley (talk) 18:36, 23 August 2017 (UTC)
replies: text:  The problem is, if we're going to, say, warn editors against adding unnecessary information to the article, there should be a clear, logical guideline for them to follow. It seems that "theoretically" one could be promulgated in this case, it just hasn't been (AFAIK). - dcljr (talk) 02:57, 24 August 2017 (UTC)
thread_title:  Move towards "List of HTML tags" 

message: An important consideration for mainspace in particular is that WP:MOS, like all professional-grade, formal-writing style guides, is dead-set against introducing extraneous stylization of any kind, and is minimalist for good reasons (especially MOS:Accessibility ones, but others as well, including MOS:TONE, WP:NOT#BLOG, and others.)  Color is used sparingly and for limited purposes in Wikipedia prose.  Same goes for other font effects (see MOS:TEXT); we don't even permit more than a few prescribed uses of boldface, and we avoid many text effect entirely, like underlining.  (See also MOS:ICONS: We do not want decorative icons, dingbats, and emojis all over our articles, either.)
The HTML element article has pretty much forever been using markup like: '%block; and %inline; are groups within the HTML DTD that group elements as being either "block-level" or "inline".'  It's unobtrusive, helpful, and what W3C and WHATWG actually recommend and intend.  
We later started marking up the code blocks with the then-new . As long as it works properly (and it does have bugs, though I don't know if any are affecting this particular article), this is arguably helpful, in that it can make complex code easier to understand for the reader. (Honestly, I'd like to see an accessibility analysis of the color choices, but I presume on good faith that one has been done at some point.)
However, someone(s) since then have done something not helpful at all: they've gone around and put  (directly or via the  or  templates) around every single thing, in mid-sentence, where they can get it to do anything. This "colorize everything! woo hoo!" approach is causing distracting and potentially confusing outbursts of pointless color all over the place, and even producing sentences with grossly inconsistent markup, as in 'Lists with  are %block; elements ...'  This is not helpful to any readers, and is not an encyclopedic approach. It's just haphazard  for its own sake and needs to be undone.  The point of syntax highlighting is to make syntax in blocks of code easy to parse; it is not a replacement for basic semantic HTML markup in prose, which is a simple and no more visually intrusive than it needs to be. — SMcCandlish ☏ ¢ 😼  12:25, 25 June 2018 (UTC)
replies: text: Checking the  reveals that many of the changes you seem to be objecting to were introduced by User:Nøkkenbuer in a series of edits on June 1 and April 23–24.  do you want to revert/undo any of those edits, or discuss any of them with Nøkkenbuer? Because otherwise you're just asking no one in particular to do nothing in particular, and I don't think much is going to result from your comment. - dcljr (talk) 01:18, 26 June 2018 (UTC)
replies: text: I already have a thread open at User talk:Nøkkenbuer, and have raised the issue more broadly at Wikipedia talk:Manual of Style#Misuse of code syntax highlighting.  While I could just WP:BRD it here, might as well let the discussion play out. For all I know, consensus may say "Oh, we really want syntax highlighting applied as much as possible."  Wouldn't bet on it, but there's no real hurry.  — SMcCandlish ☏ ¢ 😼  01:43, 26 June 2018 (UTC)

text: There is much to cover here, , so I again apologize for the length. Given that the discussion here is about this particular article, however, I think it is due to provide a full explanation of my rationale and perspective for the edits I made here. I only need to do this once, after all. Regardless, a (frustratingly truncated) TL;DR is below for you and anyone else who cares to read (just not  much). It is indented with  for visual clarity.Although I agree that  is generally a clear violation of the Manual of Style guidelines, I think that syntax highlighting—at least, as implemented within this article, both inline and within code blocks—is not that because it serves a  purpose that assists reader comprehension and reduces ambiguity. This is particularly so for readers who are completely unfamiliar with basic programming, such as those likely to encounter this article.Specifically, beyond the general benefits of syntax highlighting (some of which are detailed in the discussion about this on my talk page ), I think that highlighting all highlightable code syntax in this article ensures clear consistency within the article so long as we highlight syntax within code blocks. This, I believe, helps readers understand the relationship between the inline code within prose and the code in nearby code blocks; and provides clear visual markers for when a given code fragment is being mentioned, which assists readers with quickly locating information while skimming the text. Contrary to your concern about this , I think that the clear visual markers draw attention in ways useful to reading without being visually disruptive; that inconsistent syntax highlighting is far more confusing, especially for those unfamiliar with code and syntax highlighting; and that highlighting all applicable code syntax has a very important point, namely to apply the benefits that syntax highlighting provides and to conform all code within the article to a consistent style.I do not think that the syntax highlighting usage in this article is a violation of MOS:COLOR because I think the coloring serves a clear function for readers, as described above. Even partially or fully color-blind readers can potentially benefit from the highlighting because the boldfacing provides a visual indicator of some syntax regardless of coloring. Syntax highlighting is specifically a benefit as a visual aid, so it is irrelevant to blind readers, who are unaffected if even they do not benefit from the programming language specifications being read by screen readers (I do not know if they do). The only situation I can imagine in which inline syntax highlighting would be a detriment to blind readers is if the screen reader output is garbled or disruptive, but that then sounds like a problem with the extension itself and not just its implementation here. As for whether the colors themselves are sufficiently contrasting, that is beyond the scope of this discussion unless part of the discussion here is whether 's own syntax highlighting library is sufficiently compliant with the English Wikipedia's accessibility guidelines. If so, then that may have project-wide implications for modifications and reversions of the extension's use as a violation of MOS:COLOR rather than it just being problematic in this article. Similarly, I think that inline syntax highlighting like in this article is fully compliant with Wikipedia:Manual of Style/Text formatting § Color, including §§ In prose. I do not see how MOS:TONE and WP:NOT#BLOG are at all relevant here.Regarding the , I completely agree and continue to be frustrated with the fact that inline  markup does not conform to the gray background of , , and even block , which is inexplicable to me; and that the latter extension does not competently highlight certain code fragments, such as tagless attributes. I mentioned both of those in my most recent reply to you on my talk page. I believe the response to this should be to address these glaring problems in the syntax highlighting extension, however, and not to roll back inline syntax highlighting to its previously inconsistent application simply because of these much smaller visual inconsistencies in an otherwise  more internally consistent article version.On the latter point, and this is where this reply is most relevant to 's comments above, my edits did not  inline syntax highlighting, even for single HTML elements. Feel free to peruse the last version before I first edited this article and compare it to the most recent version by me, which is the live version of this article as of this publication. As can be clearly seen, inline syntax highlighting was  present in places (including the  you noted above) but was  inconsistent, likely due to haphazard insertions from various editors over time who never checked the prevailing style in the article or bothered to address it. Not only is syntax highlighting inconsistent (some complex inline code was not highlighted), but code elements and attributes themselves were inconsistent, some being boldfaced without angle brackets (e.g., em rather than ), others being wrapped in  but without angle brackets (e.g., em rather than ), even others using escaped HTML entities in various formatting, others still using , and still others without any formatting at all. Moreover, some of the wikitext source, particularly regarding curly brackets in CSS code, was needlessly verbose due to the use of s. I addressed all these issues and now, were all the syntax highlighting I added reverted, it would be a simple task that can largely be done with simple string substitutions, which was impossible before. To see the full extent of my changes, see the following two diff groups: Group 1 and Group 2.Lastly, despite the frankly perplexing state of the article before I arrived, my edits were an attempt at  the implicit consensus in the article, as I noted in the edit summary of my first edit to the article. The other option I considered to achieve the same goal was to remove  syntax highlighting, or at least all inline syntax highlighting, but it was not clear to me whether that was the majority position in the implicit consensus. I judged that it was not, so I proceeded with my edits.In my opinion, I  the  use of code markup to the fullest extent I know possible given the limitations of  (from which  is derived). Even before I began editing this article, however, I did not consider the inline syntax highlighting to have been merely ; it served the same function as I described above and elsewhere, just far more haphazardly, and that now-largely-resolved inconsistency was perhaps the most cogent justification for concerns about confusing, distracting, and misleading readers. That is why I began editing.I understand that you believe that syntax highlighting is only appropriate for  and for  and . I also believe I understand  you do and consider that rationale to be both reasonable and defensible. However, I support more permissive usage so long as there is a justified rationale for doing so within a particular case or context. I think that such a rationale is available for this article (and for the HTML article and others). Moreover, I think such formatting is entirely encyclopedic and does not detract from Wikipedia's status as one. Nonetheless, if there is clear consensus against the syntax highlighting I have implemented on this article and elsewhere, I will proceed to revert my changes to the extent that the consensus requires. Thank you for your time. Hopefully, for anyone reading, that TL;DR was not too long to be worth reading; it is reduced by roughly 60%. If it still is for anyone, then I guess just skim the TL;DR? I can only compress and omit so much before even the most important points are lost and it comes across as uncivilly curt, and I would rather be taken as verbose than as dismissive and rude. —Nøkkenbuer (talk • contribs) 03:21, 27 June 2018 (UTC)
replies: text: This is too much "there isn't a  what I want to do" lawyering for me to wade through. This is a WP:Common sense matter more than anything else. You're attempting to apply a "consistency" you made up out of nowhere, which directly conflicts with much more important article-writing consistency rules and practices we've been using for 17+ years, all on the basis of trying to impose a colorization scheme intended for one single purpose (distinguishing this part of code from that different part of code ) onto contexts for which was not designed and is very unhelpful.  There is no encyclopedic purpose to this colorization when applied to individual terms (elements, attributes) of code in running text; WP has no interest of any kind in trying to impress upon readers that "elements are green" or "attributes are grey", etc.  It's meaningless, arbitrary noise, that sharply conflicts with our already barely-tolerated use of a few key colors to indicate links of various sorts.  Per the earlier part of this thread, I've raised the issue at the MoS talk page, since this really isn't an article-specific matter, and I didn't actually know until someone told me above that it was all imposed by a single editor, and isn't the result of general editorial "creep" toward colorization.  What you're doing is contested; I just haven't bothered to do the R in WP:BRD yet, since the D part is already happening, and WP:There is no deadline.  — SMcCandlish ☏ ¢ 😼  03:40, 27 June 2018 (UTC)
replies: text: I am sorry that you consider this as . That is not my intent. The consistency I was trying to apply to this article was what I believed to have been the majority implicit consensus within the article. I considered the syntax highlighting used in the article to have been a constructive improvement to the article. If I had not, I would have not proceeded with doing so; I would have probably reverted at least most of the inline syntax highlighting, just as I suspect you would have done were you in my situation. Perhaps it is just incompetence on my part, but I genuinely do not understand how the changes being discussed contravene current policies and guidelines or otherwise damage the encyclopedia. Hopefully, that will be elucidated through further discussion; regardless, I will abide by the consensus.Thank you for your time and for giving this contested issue the opportunity to be discussed. I look forward to further input from others, whether here, on my talk page, or at the MoS talk page discussion (permanent link). —Nøkkenbuer (talk • contribs) 01:48, 28 June 2018 (UTC)
thread_title:  Misuse (gross overuse) of syntax highlighting 

message: A whitespace problem has existed in this article for an indeterminate amount of time (mostly from the "Tables" section down) due to the use of semicolon (definition-term) wiki markup with the ( and)  template(s). I've just edited the article to make it look consistent throughout. As discussed at Template talk:XMLElement, something (reportedly) needs to be done to that template to fix this problem; then the "correct" wiki markup can be reintroduced throughout the article. - dcljr (talk) 06:01, 27 July 2018 (UTC)
thread_title:  Whitespace problem 

message: My edition to this article was reverted because I made a mistake: for Cite web the parameter website has an alias named work and I changed it, I am sorry. Now I learned that parameter work is used too for COinS.  Thanks for the correction! --Jimmy Olano (talk) 23:12, 1 September 2019 (UTC)
thread_title:  My mistake 

message: I saw that Reference 25 does not have the source linked to the text [HTML 4 for dummies, 5th ed., 2005, by Ed Tittel, Mary C. Burmeister; p. 96.]. I have question about where the anchor element definition (source with [^25] directing to 'inline elements' [] came from. Also, for Reference 60's source [ "<nextid>: The NeXT ID element (Obsolete)". MDN Web Docs ], the hyperlink brings me to a page where page is not found []. Reference 58's source hyperlink has the same error as Reference 60's source hyperlink []. Is this suppose to be normal?Kuroko19148 (talk) 03:21, 9 October 2021 (UTC)
replies: text: The sources for  for  appeared to go away sometime. I updated the references to point to WHATWG's Obsolete tags list. As far as your question about the reference to HTML 4 For Dummies, I'm not sure what you're asking. I added an archive.org link to the book.  — sbb (talk) 21:18, 7 August 2022 (UTC)
thread_title:  References 

message: W3C and WHATWG had dueling specs for some time but since 2019 W3C has ceded the matter to WHATWG, the body behind the de facto HTML Living Standard. This page has since encountered very serious rot; for example the <menu> element has been marked deprecated for a long time, and the page makes frequent mention of the outdated W3C spec as current. This has a very negative impact on Wikipedia's credibility.
I propose an incremental, section-by-section update of this page from the historical W3C spec to the current WHATWG spec. SirMeowMeow (talk) 21:28, 6 November 2023 (UTC)
thread_title:  W3C to WHATWG Living Standard