This article is written in American English, which has its own spelling conventions (color, defense, traveled) and some terms that are used in it may be different or absent from other varieties of English. According to the relevant style guide, this should not be changed without broad consensus. |
This article is rated C-class on Wikipedia's
content assessment scale. It is of interest to the following WikiProjects: | ||||||||||||||||||||||||||||||||||
|
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)
<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)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)
The list of "all" tags needs to be updated:
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)
Regarding this edit by SMcCandlish ( talk · contribs) from thirteen months ago. The phrase "and called an association list in early versions of HTML5" which was added to the parenthesis is troubling me. The cited source says "The dl element represents an association list consisting of zero or more name-value groups (a description list)", so it doesn't support the claim for early versions, nor does it imply that the structure is termed a description list in preference to an association list.
The version of HTML 5 that was approved as a W3C Recommendation on 28 October 2014 says exactly the same thing. It's no different in HTML 5.1: the latest published version of the Working Draft, 17 April 2015 and of the Nightly Editor's Draft, 23 March 2015 both use the same wording again. If we go right back to the earliest published versions of HTML 5, Working Draft 22 January 2008, it says "The dl element introduces an unordered association list consisting of zero or more name-value groups (a description list)"; the next published version ( Working Draft 10 June 2008) says "The dl element introduces an association list consisting of zero or more name-value groups (a description list)" - that is, the word "unordered" was removed; and in the version after that ( Working Draft 12 February 2009), the word "introduces" was replaced by "represents", and so it took on the present wording at that point. So it's not that it was "called an association list in early versions of HTML5" - it always has been called an association list in those versions of HTML5 that are readily available.
Therefore, I think that the first sentence of the paragraph should be simplified to
References
notice the extra ref, for the wording of HTML 4.01. -- Redrose64 ( talk) 12:49, 2 May 2015 (UTC)
<al>
, <at>
, and <ad>
someday, but I doubt it. :-) Changed "or" to "a.k.a.", since "or" can be ambiguous in such constructions (implying two different things instead of two names for the same thing). Not anticipating an objection, I stuck that in, with some more consistent citation formatting. —
SMcCandlish ☺
☏
¢ ≽ʌⱷ҅ᴥⱷʌ≼ 11:59, 12 June 2015 (UTC)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
<mark>...</mark>
tag. Is it deprecated or nonstandard? — Preceding unsigned comment added by AnAwesomeArticleEditor ( talk • contribs) 21:43, 22 April 2016 (UTC)
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)
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)
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:
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)
I think we should use American English spellings throughout this article, because HTML uses American English (specifically the "color" attribute"). It looks silly to see color=colour
in the article. —
AnAwesomeArticleEditor (
talk
contribs) 02:49, 28 February 2018 (UTC)
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 <
syntaxhighlight>
. 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 <
syntaxhighlight>
(directly or via the {{
code}}
or {{
syntaxhighlight}}
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 <ul><li> ...
are %block;
elements ...' This is not helpful to any readers, and is not an encyclopedic approach. It's just haphazard decoration 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)
"introducing extraneous stylization"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 functional 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 [ permanent link]), 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
"causing distracting and potentially confusing outbursts of pointless color", 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
<
syntaxhighlight>
'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 "grossly inconsistent markup", I completely agree and continue to be frustrated with the fact that inline
<
syntaxhighlight>
markup does not conform to the gray background of <code>
, <
pre>
, and even block <
syntaxhighlight>
, 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 far more internally consistent article version.On the latter point, and this is where this reply is most relevant to
dcljr's comments above, my edits did not introduce 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 already present in places (
including the "grossly inconsistent markup"you noted above) but was wildly 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
<em>
), others being wrapped in <code>
but without angle brackets (e.g., em
rather than <em>
), even others using escaped HTML entities in various formatting, others still using {{
tag}}, 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 <
nowiki>
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 enforcing 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 all 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 resolved the "haphazard"use of code markup to the fullest extent I know possible given the limitations of
<
syntaxhighlight>
(from which {{
code}} is derived). Even before I began editing this article, however, I did not consider the inline syntax highlighting to have been merely "decoration for its own sake"; 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
"blocks of code"and for
"complex"and
"'extended' inline cases". I also believe I understand why 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.
"introducing extraneous stylization"is generally inappropriate, but I think that is not the case here, especially since I do not think this is merely
"extraneous stylization". Syntax highlighting here serves a functional purpose in improving reader comprehension and reducing ambiguity, especially for those unfamiliar with coding. Specifically, it ensures clear consistency, which prevents confusion resulting from inconsistent formatting and presentation. Inline syntax highlighting also helps reinforce the relationship between the prose and the code blocks it wraps, and the clear visual display assists readers with quickly finding information when skimming the text. Thus, I think it is not
"distracting and potentially confusing outbursts of pointless color"; if anything, it is the contrary, especially when compared to the previously inconsistent state of the article. Syntax highlighting in this way does not violate MOS:COLOR because it is functional and not merely decorative. Color-blind readers can even benefit from the boldfacing implemented in syntax highlighting and, since this is a strictly visual aid, it will probably not impact blind readers. If it does, it may even be beneficial by specifying the programming language, assuming their screen readers do not output garbled or disruptive renderings of the highlighted code. Regardless, all of this seems to be more so an issue beyond the scope of this discussion, since it's more about the extension itself and not just its implementation in this article. I do not understand the relevance of MOS:TONE and WP:NOT#BLOG here.I agree that the
"grossly inconsistent markup"you noted is a problem (and it already existed before I arrived), but that is a frustrating limitation of
<
syntaxhighlight>
and {{
code}}. I think this can be better resolved by addressing those limitations than by reverting its use. Please compare the
the version before I started editing here and
the most recent version I edited (which is currently the live version) and review the totality of my edits on this article with these two diff groups:
Group 1 and
Group 2. As can be clearly seen, inline syntax highlighting was already inconsistently used in the article; in fact, all coding in the article was inconsistently formatted in nearly half a dozen different ways. I fixed all this by enforcing what I believed was
implicit consensus within the article when I arrived, which I noted in the edit summary of
my first edit to the article. It was either that or remove all syntax highlighting, or at least inline syntax highlighting, which seemed to me to be against the implicit consensus of the article. As a result, I believe I resolved the "haphazard"use of code markup to the extent possible given the extension limitations.I understand your position and believe I also understand why you maintain it. It is both reasonable and defensible. However, I think that in this case and in cases like it, more permissive usage of syntax highlighting is due. Regardless, I will abide by whatever consensus (if any) results from these discussions to the extent required by that consensus. Thanks for your time.
"lawyering". 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)
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 ({{ Anchor}} and) {{ XMLElement}} 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)
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)
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' [[ [1]]] 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 [[ [2]]]. Reference 58's source hyperlink has the same error as Reference 60's source hyperlink [[ [3]]]. Is this suppose to be normal? Kuroko19148 ( talk) 03:21, 9 October 2021 (UTC)Jenny Chen
<listing>
for <nextid>
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)References
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)
This article is written in American English, which has its own spelling conventions (color, defense, traveled) and some terms that are used in it may be different or absent from other varieties of English. According to the relevant style guide, this should not be changed without broad consensus. |
This article is rated C-class on Wikipedia's
content assessment scale. It is of interest to the following WikiProjects: | ||||||||||||||||||||||||||||||||||
|
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)
<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)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)
The list of "all" tags needs to be updated:
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)
Regarding this edit by SMcCandlish ( talk · contribs) from thirteen months ago. The phrase "and called an association list in early versions of HTML5" which was added to the parenthesis is troubling me. The cited source says "The dl element represents an association list consisting of zero or more name-value groups (a description list)", so it doesn't support the claim for early versions, nor does it imply that the structure is termed a description list in preference to an association list.
The version of HTML 5 that was approved as a W3C Recommendation on 28 October 2014 says exactly the same thing. It's no different in HTML 5.1: the latest published version of the Working Draft, 17 April 2015 and of the Nightly Editor's Draft, 23 March 2015 both use the same wording again. If we go right back to the earliest published versions of HTML 5, Working Draft 22 January 2008, it says "The dl element introduces an unordered association list consisting of zero or more name-value groups (a description list)"; the next published version ( Working Draft 10 June 2008) says "The dl element introduces an association list consisting of zero or more name-value groups (a description list)" - that is, the word "unordered" was removed; and in the version after that ( Working Draft 12 February 2009), the word "introduces" was replaced by "represents", and so it took on the present wording at that point. So it's not that it was "called an association list in early versions of HTML5" - it always has been called an association list in those versions of HTML5 that are readily available.
Therefore, I think that the first sentence of the paragraph should be simplified to
References
notice the extra ref, for the wording of HTML 4.01. -- Redrose64 ( talk) 12:49, 2 May 2015 (UTC)
<al>
, <at>
, and <ad>
someday, but I doubt it. :-) Changed "or" to "a.k.a.", since "or" can be ambiguous in such constructions (implying two different things instead of two names for the same thing). Not anticipating an objection, I stuck that in, with some more consistent citation formatting. —
SMcCandlish ☺
☏
¢ ≽ʌⱷ҅ᴥⱷʌ≼ 11:59, 12 June 2015 (UTC)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
<mark>...</mark>
tag. Is it deprecated or nonstandard? — Preceding unsigned comment added by AnAwesomeArticleEditor ( talk • contribs) 21:43, 22 April 2016 (UTC)
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)
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)
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:
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)
I think we should use American English spellings throughout this article, because HTML uses American English (specifically the "color" attribute"). It looks silly to see color=colour
in the article. —
AnAwesomeArticleEditor (
talk
contribs) 02:49, 28 February 2018 (UTC)
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 <
syntaxhighlight>
. 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 <
syntaxhighlight>
(directly or via the {{
code}}
or {{
syntaxhighlight}}
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 <ul><li> ...
are %block;
elements ...' This is not helpful to any readers, and is not an encyclopedic approach. It's just haphazard decoration 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)
"introducing extraneous stylization"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 functional 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 [ permanent link]), 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
"causing distracting and potentially confusing outbursts of pointless color", 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
<
syntaxhighlight>
'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 "grossly inconsistent markup", I completely agree and continue to be frustrated with the fact that inline
<
syntaxhighlight>
markup does not conform to the gray background of <code>
, <
pre>
, and even block <
syntaxhighlight>
, 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 far more internally consistent article version.On the latter point, and this is where this reply is most relevant to
dcljr's comments above, my edits did not introduce 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 already present in places (
including the "grossly inconsistent markup"you noted above) but was wildly 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
<em>
), others being wrapped in <code>
but without angle brackets (e.g., em
rather than <em>
), even others using escaped HTML entities in various formatting, others still using {{
tag}}, 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 <
nowiki>
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 enforcing 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 all 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 resolved the "haphazard"use of code markup to the fullest extent I know possible given the limitations of
<
syntaxhighlight>
(from which {{
code}} is derived). Even before I began editing this article, however, I did not consider the inline syntax highlighting to have been merely "decoration for its own sake"; 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
"blocks of code"and for
"complex"and
"'extended' inline cases". I also believe I understand why 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.
"introducing extraneous stylization"is generally inappropriate, but I think that is not the case here, especially since I do not think this is merely
"extraneous stylization". Syntax highlighting here serves a functional purpose in improving reader comprehension and reducing ambiguity, especially for those unfamiliar with coding. Specifically, it ensures clear consistency, which prevents confusion resulting from inconsistent formatting and presentation. Inline syntax highlighting also helps reinforce the relationship between the prose and the code blocks it wraps, and the clear visual display assists readers with quickly finding information when skimming the text. Thus, I think it is not
"distracting and potentially confusing outbursts of pointless color"; if anything, it is the contrary, especially when compared to the previously inconsistent state of the article. Syntax highlighting in this way does not violate MOS:COLOR because it is functional and not merely decorative. Color-blind readers can even benefit from the boldfacing implemented in syntax highlighting and, since this is a strictly visual aid, it will probably not impact blind readers. If it does, it may even be beneficial by specifying the programming language, assuming their screen readers do not output garbled or disruptive renderings of the highlighted code. Regardless, all of this seems to be more so an issue beyond the scope of this discussion, since it's more about the extension itself and not just its implementation in this article. I do not understand the relevance of MOS:TONE and WP:NOT#BLOG here.I agree that the
"grossly inconsistent markup"you noted is a problem (and it already existed before I arrived), but that is a frustrating limitation of
<
syntaxhighlight>
and {{
code}}. I think this can be better resolved by addressing those limitations than by reverting its use. Please compare the
the version before I started editing here and
the most recent version I edited (which is currently the live version) and review the totality of my edits on this article with these two diff groups:
Group 1 and
Group 2. As can be clearly seen, inline syntax highlighting was already inconsistently used in the article; in fact, all coding in the article was inconsistently formatted in nearly half a dozen different ways. I fixed all this by enforcing what I believed was
implicit consensus within the article when I arrived, which I noted in the edit summary of
my first edit to the article. It was either that or remove all syntax highlighting, or at least inline syntax highlighting, which seemed to me to be against the implicit consensus of the article. As a result, I believe I resolved the "haphazard"use of code markup to the extent possible given the extension limitations.I understand your position and believe I also understand why you maintain it. It is both reasonable and defensible. However, I think that in this case and in cases like it, more permissive usage of syntax highlighting is due. Regardless, I will abide by whatever consensus (if any) results from these discussions to the extent required by that consensus. Thanks for your time.
"lawyering". 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)
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 ({{ Anchor}} and) {{ XMLElement}} 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)
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)
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' [[ [1]]] 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 [[ [2]]]. Reference 58's source hyperlink has the same error as Reference 60's source hyperlink [[ [3]]]. Is this suppose to be normal? Kuroko19148 ( talk) 03:21, 9 October 2021 (UTC)Jenny Chen
<listing>
for <nextid>
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)References
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)