Jump to content

Talk:HTML element

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia

Nitrosyl bromide

[edit]

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)[reply]

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)[reply]
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)[reply]
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)[reply]

text overprints box

[edit]

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)[reply]

  • That's not a problem that is the fault of anyone except those that want to hit Ctrl++++++... If you've accidently done that and want to reset it to the "normal" font size so it fixes those issues, simply press Ctrl+0. — {{U|Technical 13}} (e • t • c) 15:59, 24 June 2014 (UTC)[reply]

List of "all" tags

[edit]

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)[reply]

I deleted this section since it also appears to be a copyright violation. -- Beland (talk) 15:11, 24 June 2014 (UTC)[reply]
  • 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)[reply]
  • 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. — {{U|Technical 13}} (e • t • c) 18:43, 24 June 2014 (UTC)[reply]
  • 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)[reply]
Agreed. I've caught them in errors before, too.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  12:02, 12 June 2015 (UTC)[reply]

The DL element

[edit]

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

An association list (or description list) consisting of name–value groups[1] (known as a definition list prior to HTML5).[2]

References

  1. ^ "4.5 Grouping content — HTML5". World Wide Web Consortium. Retrieved 22 May 2013.
  2. ^ "Lists in HTML documents". HTML 4.01 Specification W3C Recommendation. 24 December 1999. 10.3 Definition lists: the DL, DT, and DD elements. Retrieved 2 May 2015.

notice the extra ref, for the wording of HTML 4.01. --Redrose64 (talk) 12:49, 2 May 2015 (UTC)[reply]

"Troubling" seems a bit hyperbolic. There's probably an easy way, e.g. with Archive.org, to dig up old versions of HTML5. The present version of the DL entry in the HTML5 spec says "The dl element represents a description list.", with no mention of "association list".  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  20:08, 3 May 2015 (UTC)[reply]
That's a W3C Working Group Note, i.e. an abandoned project (see Ending Work on a Technical Report or Publishing a Working Group or Interest Group Note). But we shouldn't need an archive site: W3C have permalinks to all but the "Nightly editors draft" pages, and I gave some above. They're the ones with dates (formatted CCYYMMDD) in the URLs, like http://www.w3.org/TR/2008/WD-html5-20080122/#the-dl There's a list up to and including 17 December 2012 at HTML5 W3C Candidate Recommendation 17 December 2012; there have been seven subsequent versions, finishing with HTML5 W3C Recommendation 28 October 2014. --Redrose64 (talk) 21:01, 3 May 2015 (UTC)[reply]
@Redrose64: OK, though I would go with:
A description list (a.k.a. association list) consisting of name–value groups ...
Regardless of the order in which these terms appear in whatever version of whichever spec we're looking at, virtually everyone knows these as description lists (if not definition lists, which seems to be deprecated/abandoned terminology), and it corresponds to the names of the elements. Maybe they'll rename them to <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)[reply]

What about HTML5 tags?

[edit]

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)[reply]

 Done by me (a while ago). —AnAwesomeArticleEditor (talk
contribs) 02:44, 28 February 2018 (UTC)[reply]

Article needs a lot of work

[edit]

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)[reply]

Added a new section

[edit]

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)[reply]

Elements vs. tags

[edit]

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:

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)[reply]
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)[reply]

Move towards "List of HTML tags"

[edit]

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)[reply]

So what are the criteria for inclusion/exclusion? - dcljr (talk) 17:39, 23 August 2017 (UTC)[reply]
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)[reply]
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)[reply]

American vs. British English spellings

[edit]

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)[reply]

And just because "you think it's silly" you've already twice changed the spellings in this article to US, even after being reverted? Andy Dingley (talk) 02:56, 28 February 2018 (UTC)[reply]
What arguments do you have for leaving it as British English? —AnAwesomeArticleEditor (talk
contribs) 14:36, 28 February 2018 (UTC)[reply]
FWIW, I, too, am interested in whether there is any argument at all for using British English, other than personal preference. According to MOS:ARTCON, we should pick one variant and stick with it. There is an actual argument (whatever you think of it) for using American spelling; is there an actual argument for using British spelling? - dcljr (talk) 04:06, 1 March 2018 (UTC)[reply]
WP:ENGVAR exists to prevent pointless edit wars. An RfC should be used if a change is wanted. Johnuniq (talk) 04:38, 1 March 2018 (UTC)[reply]
Invoking WP:ENGVAR doesn't magically resolve disputes. If it did, this would already be resolved. AFAICT, ENGVAR does not recommend using RfC's in place of normal talk page discussion, and that's what we are trying to do here. As for the characterization that "a change is wanted", the only "change" being "wanted" here is to pick a variety of English and stick with it. AFAICT this article has had mixed spelling (color/colour, etc.) for quite a while, and it was only very recently that editors have tried to standardize it to one variety (and then the other). (Although that may also have been done before, years ago, and the change didn't stick.) In other words, I don't think established convention can be the controlling factor here. OTOH, MOS:RETAIN says, "When no English variety has been established and discussion does not resolve the issue, use the variety found in the first post-stub revision that introduced an identifiable variety." In that case, it would be American English, since the original destubbification of this article seems to have used American English. Andy, what is your argument for preferring British spelling? - dcljr (talk) 07:34, 1 March 2018 (UTC)[reply]
Please just make the case to show that there is no established style, then make a case for what the style should be. If there is no agreement on the first point, the second is not relevant until a wider discussion (RfC) is underway. Johnuniq (talk) 07:54, 1 March 2018 (UTC)[reply]
@dcljr - if you can show that the first non-stub version was clearly in US English, then I'm happy to go with that, per ENGVAR.
What I'm not happy about is edit-warring across ENGVAR, just because, "I think it's silly to use British English". Andy Dingley (talk) 10:10, 1 March 2018 (UTC)[reply]
You are misrepresenting my argument. I said that was only one of the factors. The other, more important factor, is HTML's preference for American English. Anyway, I'm going to go ahead and put back the American English notice on the talk page, because that seems to be what the consensus supports. —AnAwesomeArticleEditor (talk
contribs) 13:15, 1 March 2018 (UTC)[reply]
In response to Johnuniq: Really? OK… consider the last version of the article attributed to you in the page history (as you reverted simple vandalism/test-editing): revision 816436305 of 21 December 2017. In that version, there are (by my count) 9 instances of "behavior" (including a section heading) and 3 of "behaviour"; 5 "color" (not counting mentions of the "color" HTML attribute) and 3 "colour"; 3 forms of the word "center" (not counting mentions of the "center" element) and no forms of the word "centre". Similar results can be found in many other revisions going back at least 2 years. For example, Andy Dingley's revision 729906336 of 15 July 2016 (also a revert) has 2 "behavior" (again, including section heading), 14 "behaviour", 3 "color", 3 "colour", 2 forms of "center", and 1 form of "centre". Even farher back, your (Johnuniq) revision 503906311 of 24 July 2012 (yet another revert — none of these cited reverts are changing varierties of English in the article, BTW) appears to have 6 "behavior", no "behaviour", 5 "color", no "colour", 3 forms of "center", and no forms of "centre" (thus, AFAICT, entirely American). (I'm sure I could find other revisions from years ago that have only British spelling of these words, although I didn't come across any in the handful of revisions I checked. The point is, there has been a lot of back and forth regarding spelling with little [or simply ineffective] effort put forth to keep the article consistent.) As for showing "that the first non-stub version was clearly in US English", as requested by User:Andy Dingley: as I linked to (as a diff) before, revision 3059657 of 4 April 2004 was the first major expansion of the article beyond a stub; it contains no "behavior" nor "behaviour", 1 "color", no "colour", 4 forms of "center", and none of "centre". If someone has other ideas for American–British differences to look for, go for it. (And finally, Johnuniq, regarding "[making] a case for what the style should be", AnAwesomeArticleEditor addressed that in his very first post in this discussion: HTML itself prefers American spelling over British. You may not feel that it's a very compelling argument, but in the light of all other evidence, it does seem to me to aid in tipping the scales toward American spelling.) - dcljr (talk) 06:59, 2 March 2018 (UTC)[reply]
Thanks for looking into the matter, and that is much more helpful than the OP which is definitely not the way to establish a style. What HTML prefers would be largely irrelevant if the article used UK spellings consistently. It is ok to change a style where the subject matter warrants such a change, but doing that requires more than an ex cathedra announcement. Johnuniq (talk) 07:59, 2 March 2018 (UTC)[reply]

Misuse (gross overuse) of syntax highlighting

[edit]

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)[reply]

Checking the page history 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. @SMcCandlish: 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)[reply]
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)[reply]
There is much to cover here, SMcCandlish, 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 that much). It is indented with {{block indent}} for visual clarity.
Although I agree that "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.
(TL;DR)  I agree that "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.
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)[reply]
This is too much "there isn't a policy against 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 inside a code block) 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)[reply]
I am sorry that you consider this as "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)[reply]

Whitespace problem

[edit]

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)[reply]

My mistake

[edit]

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)[reply]

References

[edit]

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[reply]

The sources for <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)[reply]

References

  1. ^ https://wiki.riteme.site/w/index.php?title=HTML_element&action=edit&section=18
  2. ^ https://developer.mozilla.org/en-US/docs/Web/HTML/Element/nextid
  3. ^ https://developer.mozilla.org/en-US/docs/Web/HTML/Element/listing

W3C to WHATWG Living Standard

[edit]

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)[reply]

Retrieved from "https://wiki.riteme.site/w/index.php?title=Talk:HTML_element&oldid=1252288920"