Wikipedia talk:HTML5

toptextcells
Is the toptextcells class defined on the English Wikipedia? --  Gadget850talk 02:59, 4 August 2014 (UTC)
 * not yet, I think. See MediaWiki talk:Common.css/Archive 14. On dewiki, it is available since 2009. Helder 03:34, 4 August 2014 (UTC)

Duplicate information
This is starting to look like Help:HTML in wikitext. Aren't we reinventing the wheel here? 09:24, 6 December 2014 (UTC)


 * Not reinventing, but there is some overlap, which occurs on all help pages. I see the intent here to help update obsolete markup to render proper HTML5, so this help page is much more specific. As this builds, we should add hatnotes to Help:HTML in wikitext directing here for more help. I have been adding cases that I see multiple times. --  Gadget850talk 13:55, 6 December 2014 (UTC)

See User_talk:Yobot for an almost ten years old discussion, clear is a div (block-element), - is a br (inline element). –Be..anyone (talk) 13:02, 2 February 2015 (UTC)

What's found
stated, "It's not about what's "found"; this is the correct syntax, albeit obsolete." Top of the articles states, This project serves to organize the adaptation of articles and other Wikipedia pages to HTML5. The page is about what is found in in Wikipedia articles and how to correct the issue.

90% of articles had not. If an person came here looking how to convert, there would be no answer. Converting into - is the correct syntax, but only if the  tag was applied correctly to begin with. It is not in the vast majority of cases. Thus, converting into clear would be more appropriate in the vast majority of cases. Bgwhite (talk) 19:42, 2 February 2015 (UTC)
 * I think that part of the confusion is that the two different syntaxes have slightly different sets of permitted values.
 * The  attribute (valid in HTML 3.2, deprecated in HTML 4.01, obsolete in HTML 5) allows values of       or
 * the  property of CSS 2.1 (valid within a   attribute in HTML 4.01 and HTML 5) allows values of       or   (also   which we won't worry about here).
 * It's the difference in that last value -  vs   which causes some people to use   or   and wonder why it doesn't work as intended. Of particular note is that the CSS spec indicates that the   property "applies to: block-level elements", and the  element is not block-level, but inline. -- Red rose64 (talk) 20:01, 2 February 2015 (UTC)
 * I corrected it because the page should list deprecated attributes, not "incorrectly used" ones. As to -, I feel it would be best to redirect it to clear anyway. Even tough works, it doesn't sit right with me for the same reason Redrose64 pointed out.   21:16, 2 February 2015 (UTC)
 * Redirecting an inline element to a block element is a seriously bad idea. About as odd as adding display:block to - or display:inline to clear. It's a difference, inline elements aren't allowed outside of all blocks (can't happen for wikitext, but still), and block elements are allowed in some places, where inline is allowed. The goal of this exercise is to get valid pages, if all you want is working (guaranteed by HTML5) just doing nothing would be fine. –Be..anyone (talk) 01:37, 4 February 2015 (UTC)
 * But  can only apply to block elements, so  basically forces the inline  element to behave as block. There is no difference in rendering, so why continue to use an invalid construct?   09:37, 4 February 2015 (UTC)
 * I think - adds a blank line where clear does not.  I most often see - at the bottom of an article, right before the navboxes.  People want the extra blank space between External links and the navboxes.   Neither one is used properly because 99% of the people don't understand the difference. One can argue about which is correct for when, but it is moot as nobody will uses it properly. - should just point to clear. Bgwhite (talk) 10:04, 4 February 2015 (UTC)
 * That is what I have been argueing :) I fixed the navbox margin issue long ago... in 2011.  12:08, 4 February 2015 (UTC)
 * Here is an example of a person only using it for a blank space. Bgwhite (talk) 19:19, 4 February 2015 (UTC)
 * I think I'll increase the margin. This is unintended use.  21:05, 4 February 2015 (UTC)
 * Thank you Edokter. They also use comments for blank space. My favourite example is in German submarine U-139 (1940). The same comment is in 4,400 articles.  Bgwhite (talk) 23:17, 4 February 2015 (UTC)
 * Wow... That seems to have no effect at all. If AWB is responsible, that task should be killed and replaced with one to remove them.   23:48, 4 February 2015 (UTC)
 * It has no effect because all it does is ensure the presence of a vertical gap (whose depth is equivalent to at least three blank lines) on the left of the page below the last EL. But that infobox on the right pushes the navbox down much further. Just remove the comment and two of the three blank lines. -- Red rose64 (talk) 00:22, 5 February 2015 (UTC)


 * The comment is intended to keep AWB and other scripts from removing the whitespace. I see thet Yobot fixed the break and was reverted. --  Gadget850talk 00:32, 5 February 2015 (UTC)
 * Yobot replaced the br tags with the template. In any case, adding whitespace should no longer be necessary, so those comments can go.  08:30, 5 February 2015 (UTC)

Folks, please stop this now,  is not the same as what clear does, i.e., an empty. As noted above the  forces a line break in addition to anything the   does, that's not the case for. The  will be invalid in some places, where the   is valid. The bot trying to fix obsolete tags should produce valid HTML5, not some "who knows and most of the clear is okay" effect. In doubt read the HTML3, HTML4, and HTML5 standards, look for inline, block, , and. Ignore CSS, everybody here agrees on how  work. –Be..anyone (talk) 22:45, 7 February 2015 (UTC)
 * You do know that not valid HTML, don't you?   can only be applied to block level elements, which  is not. Also, forcing a linbreak makes little sense when a div always starts a new block context. Do you have an actual use case where this invalid markup is actually needed?   23:31, 7 February 2015 (UTC)
 * No, I didn't know that, but I'll check it, after all - would have to be fixed. I tried to get the right side of the or right. Now after you fixed the left side, which I never touched, yes, of course clear matches , one line in both templates is easy enough for me. –Be..anyone (talk) 23:48, 7 February 2015 (UTC)
 * HTML5 says that  can have global attributes including style. Please post CSS links, why that's not as simple as it sounds. –Be..anyone (talk) 00:06, 8 February 2015 (UTC)
 * In HTML 4 and HTML 5, all HTML tags that are valid in the body may be given the  attribute, there are no exceptions. However, what is valid inside the attribute varies. I already provided some links, in my post of 20:01, 2 February 2015 - to save you reading the whole of my post, the relevant bits are 'the   property of CSS 2.1' and 'the CSS spec indicates that the   property "applies to: block-level elements"'. -- Red rose64 (talk) 00:24, 8 February 2015 (UTC)
 * Sounds good for CSS2.1 and whatever WD-css3-break tries to tell me, possible fixes for -:
 * The latter would cover the former HTML3 and XHTML1 transitional  edit history for this beast. –Be..anyone (talk) 13:44, 9 February 2015 (UTC)
 * Update: mw:Template:Clear/doc and mw:Template:-/doc should now be "clear", and notably "exist". Be..anyone (talk) 14:36, 9 February 2015 (UTC)
 * That (2) is ugly... adds nothing, so why keep using it?   14:53, 9 February 2015 (UTC)
 * Understood and seconded, but I don't trust that we got the "with" vs. "without" line break right, I don't trust that all popular browsers support a self-closing or empty, and I vaguely recall tricky layout fixes where the traditional - worked as expected recently and nine years ago. –Be..anyone (talk) 15:22, 9 February 2015 (UTC)
 * The  property is also in CSS 3, but that's a long time a-comin'. To speed up the process, they broke it down into modules, only few of which (like those for selectors and colour) are finalised as W3C Recommendation. The   property is in CSS basic box model which is a W3C Working Draft (i.e. a long way from approval, but not rejected either). Its last full revision was 9 August 2007 (previous versions were 24 October 2002 and 26 July 2001). -- Red rose64 (talk) 15:43, 9 February 2015 (UTC)
 * We've not (yet) arrived in Lala-land, checking WhatWG and HTML 5.1 I found this pearl of wisdom (unrelated to validity, only for rendering):
 * The  property is also in CSS 3, but that's a long time a-comin'. To speed up the process, they broke it down into modules, only few of which (like those for selectors and colour) are finalised as W3C Recommendation. The   property is in CSS basic box model which is a W3C Working Draft (i.e. a long way from approval, but not rejected either). Its last full revision was 9 August 2007 (previous versions were 24 October 2002 and 26 July 2001). -- Red rose64 (talk) 15:43, 9 February 2015 (UTC)
 * We've not (yet) arrived in Lala-land, checking WhatWG and HTML 5.1 I found this pearl of wisdom (unrelated to validity, only for rendering):

 "User agents are expected to support the 'clear' property on inline elements (in order to render br elements with clear attributes) in the manner described in the non-normative note to this effect in CSS2.1."
 * There's even a rule to consider clear=all and clear=both as clear:both. –Be..anyone (talk) 23:45, 9 February 2015 (UTC)
 * Source?  00:01, 10 February 2015 (UTC)
 * Maybe not only my Chrome refuses to show the  URL, but it's visible in the source editor; almost verbatim Hixie's WhatWG living standard as of January. Caveat: this is off topic (rendering, not validity.) –Be..anyone (talk) 15:53, 10 February 2015 (UTC)
 * The cite attribute is always invisible, and HTML5.1 is not relevant here.  16:35, 10 February 2015 (UTC)

Big
One should never use hardcoded pixels for font sizes, because they will derail on browsers that have their fontsizes set different form the default (16px on Windows). You can review the actualy effect at User:Edokter/fonttest. 12:27, 23 February 2015 (UTC)


 * Currently the advice for nested big is to use CSS with pixels. I did some testing with percentages using resize at User:Gadget850/big. Is there any official guidance? --  Gadget850talk 12:51, 23 February 2015 (UTC)
 * I examined the effects of and   in all major browsers, and fortunately, they all result in an increase of exactly 120%.  and   are not so consistent, but generally results in 85%. The non-relative keywords form   to   are hardcoded to 9, 10, 13, 16, 18, 24 and 32px respectively, regardless of default font size settings and scale with the browser font-size.   13:13, 23 February 2015 (UTC)
 * I see why this is complex. On my test page, measured with JRuler:
 * Firefox 36: x 5 shows as 195px wide, 249% is 122px, 400% is 194px (my original selection).
 * IE11: x 5 shows as 108px wide, 249% is 122px.
 * I see x 5 used in two articles to increase the size of a Unicode character. --   Gadget850talk 14:23, 23 February 2015 (UTC)
 * Bah, I never tested the nested bigs... it works in Chrome, but FF and Opera make them grow exponentially. I think this is all the more reason to 'ban' all uses of, especially the nested ones.  15:41, 23 February 2015 (UTC)
 * The official guidance from W3C is that  should be styled with the declaration, see the HTML 5 spec, section 10.3.4 Phrasing content. -- Red rose64 (talk) 16:54, 23 February 2015 (UTC)
 * Yes, but the issue at hand is nested big. The only thing I can find is "Font style elements may be nested and they must be properly nested. Rendering of nested font style elements depends on the user agent." Which does not give any specifics on the size of nested bigs. --  Gadget850talk 18:12, 23 February 2015 (UTC)
 * I would expect the font size to increase exponentially:  should give a "larger" size that is itself made "larger", and if on a given browser,  equates to 120%, then 120% * 120% is 144% and nesting five  should give 120%^5 or 248.832% -- Red rose64 (talk) 18:51, 23 February 2015 (UTC)
 * Added another test at User:Gadget850/big. Firefox expands x5 about 450% of standard and IE11 about 220%.
 * I agree with Edokter: nested big is a Bad Thing™. --  Gadget850talk 23:36, 23 February 2015 (UTC)

centering score and code tags
HTML5 doesn't list how to center or  tags. Could these be added to the list? Bgwhite (talk) 20:36, 23 February 2015 (UTC)
 * The  element is inline, so centring it is as effective and as useful as attempting to centre the  or </i> elements. As for <score ></score>, it apparently doesn't recognise the  attribute, but there's no reason you couldn't do this:


 * that is, wrap it in -- Red rose64 (talk) 21:22, 23 February 2015 (UTC)


 * Or center, which is cleaner in the markup. is a standard HTML element used to add semantics and presentation to text: use center just as you would with any other text. --   Gadget850talk 22:49, 23 February 2015 (UTC)


 * Thank you both. Bgwhite (talk) 00:13, 24 February 2015 (UTC)

Stats
It would be nice to have some sort of stats page that could keep a record of progress. I've been doing one for my own use for a number of attributes & tags in the template space. Template Progress. -- WOSlinker (talk) 21:23, 23 February 2015 (UTC)


 * I don't see that we are ever going to update all markup at this point. Editors are going to keep using the markup they know until they are forced to change. has been open for two years: The Vector toolbar big text button.png button on the editing toolbar adds.
 * I have seen some comments that obsolete HTML breaks with mobile browsers, but I have not been able to track any specifics.
 * There have been some proposals to automatically update HTML, but with the weird stuff I have seen that will probably just break a lot of things.
 * If you really want to make use obvious, change the site CSS so an element gets wrapped in a big red error. But this will just piss of a bunch of folks.
 * But if you really want stats, then use the search links I added and track uses. I'm sure you could do something with the API, but I have no experience there. --  Gadget850talk 23:56, 23 February 2015 (UTC)
 * For, and  tags in articles, you can look at CheckWiki errors #40, #42 and #2 respectively.  There is a CheckWiki error to find  tags, but it isn't turned on at the moment.  Also, unlike the first three tags that have been cleaned up, there are a ton of  tags still left in articles. Bgwhite (talk) 00:11, 24 February 2015 (UTC)
 * Some obsolete HTML does break in mobile browsers, but all the confirmed reports of this concern markup that was never a non-deprecated part of the formal HTML specs, such as the  attribute on tables. This attribute first appeared in the HTML spec in HTML 3.2 when it was only shown for the <body ></body> element; in HTML 4 it was also shown for certain table elements (<table ></table> <tr ></tr> <th ></th> <td ></td>) but marked as deprecated. I believe that the idea was that if it was formally described as deprecated, people would be discouraged from using it; but if it wasn't described at all, people might use it by copying bad practice from some webpage that they liked the look of, not being aware of its non-universal recognition. A bit like the <blink ></blink> element (only recognised by NetScape and Firefox) or <marquee ></marquee> (IE). -- Red rose64 (talk) 10:44, 24 February 2015 (UTC)

Changes to template search link
The first search  took 20 seconds. Even after I removed the i of case-insensitivity, it returns 125 thousand articles. I think using a search link like that to list articles in that quantity should be done at the time the WP:AWB is gonna be launched. Hey wait... they have there own download of the database and there own regexp search that will run their own automated remote-editor to do the code updates/replacements.

Many of the searches don't work. But wait... before we repair them, how about we agree to replace them each with their count? Run the search once, and record a count? I don't think a public button is a good idea unless for each button push, a record is made of the count in yet another table column, and the count has some public value. So I won't even recommend using  to give gawkers a quick feel for the scope of each detail of the project.

Please say something here or on the project page about these search links. I've got something like this going on at Val/units/test, but their purpose is clear, unlike here. At least say why both an article search-button and wiki-wide search-button is plunked down.

I only say all this because MediaWiki says that regex searches are so intense that only a few at a time are allowed to run at a time on the wiki—a regex search can actually kill a search cluster if the settings are not tweaked just right— and that case insensitive searches are even worse. And they say to always run these searches with filters, never alone. For example  &mdash;  Cp i r al  Cpiral  06:32, 22 July 2015 (UTC)


 * OK, search links it is. I've tightened them all up with all kinds of filters so the regex run fast. &mdash;  Cp i r al  Cpiral  08:21, 8 August 2015 (UTC)

How to change wikilink color using span element?

 * font element can change wikilink color
 * →  Cosmos
 * span element can NOT change wikilink color
 * → Cosmos
 * method for changing wikilink color using span element
 * → Cosmos

Is this OK? Or is there any other way? --Momijiro (talk) 00:56, 4 February 2017 (UTC)
 * It is true that they work differently; and as far as I know, the span must be inside the link in order to override the colour. But doing so may violate either or both of MOS:COLOUR and MOS:CONTRAST. -- Red rose64 &#x1f339; (talk) 11:03, 4 February 2017 (UTC)
 * OK, I understood. --Momijiro (talk) 17:01, 4 February 2017 (UTC)
 * Momijiro, Redrose64: When this topic started, the markup  caused the link to display in red, but it doesn't do that any more. This worked in the past because it relied on the Old behaviour of link-wrapping font tags lint error, in addition to the Obsolete HTML lint error for using <font ></font> tags. The above "method for changing wikilink color using span element" is the correct way to do it, within the requirements of HTML5. However, as detailed in Help:Link color, there are standard link colors, and as it says at MOS:LINKCOLOR, "Refrain from implementing colored links that may impede user ability to distinguish links from regular text, or color links for purely aesthetic reasons." One place where it is acceptable to override link colors is in user signatures. Old behaviour of link-wrapping font tags lint errors should be corrected by removing them entirely, if they appear in articles. If they appear in talk pages, they should be corrected (using the above method for changing wikilink color using span element), except where the discussion requires the error in order to make sense, which is why I am leaving the error in place in this discussion. —Anomalocaris (talk) 08:45, 23 May 2022 (UTC)
 * Why are you telling me this five years on, and which I fully understood at the time? -- Red rose64 &#x1f339; (talk) 22:24, 23 May 2022 (UTC)
 * Redrose64: The conversation needed updating to reflect the changed Mediawiki behavior regarding link-wrapping font tags, and to tell other lint fixers that this is a lint error not to fix. I thought it was a courtesy to mention you. I knew that you knew. Sorry for any implication that you didn't know. —Anomalocaris (talk) 00:25, 24 May 2022 (UTC)

Accessibility and HTML 5
Per a request by and in response to some practices in the wild that I've seen, I'm adding a section here about accessibility and HTML. One relevant problem that I have seen many times is the misuse of <small ></small>: note that in HTML 5, this is defined semantically to mean fine print which stylistically is generally smaller but is not the same thing as (e.g.). I recommend editors who typically look at this page review it for accessibility and semantic reasons and ensure that the text meets those needs. ―Justin ( koavf ) ❤T☮C☺M☯ 22:25, 29 June 2020 (UTC)

Template:Tooltip, Template:Hover_title, and Template:Abbr
Please see: Templates for discussion/Log/2020 December 3

Summary: — SMcCandlish ☏ ¢ 😼  00:26, 4 December 2020 (UTC)
 * (a wrapper for <abbr ></abbr>) has long been abused for non-abbreviation markup (against the HTML specs).
 * We had a template,, with for non-abbreviation use, but it was "merged" (not really) and redirected to.
 * The redir was then deprecated (for the reason mentioned above), but the community ignored the deprecation.
 * In the interim, was created to do the same thing, but with backwards parameters (and some additional features).
 * Both the then-redirect and  template have been transcluded in tens of thousands of articles, mainly via infoboxes and other templates.
 * I created a new template, with all the features of  but preserving the  parameter order (to not break deployed translcusions).
 * The TfM linked above would merge away, but it's going to require flipping the 1 and 2 parameters of its extant instances.
 * Oh, and the documentation would need updating after merger, of course.

Centered gallery parser tag
Is the centred gallery parser tag fix that is given in the article consistent across all devices? I had made this change and the galleries were correctly displayed centered in Android mobile view. But another user said there was display problems, that the galleries were neither centered nor fully to the left. I have reversed my changes for now. Any idea what could be the problem here?  AVS malnad 77  chat  12:39, 1 January 2021 (UTC)
 * AFAIK  won't work if   exists in the gallery tag. --Minorax (talk) 04:18, 3 January 2021 (UTC)

Font color
Some browsers will attempt to interpret an invalid color name as a hex value. For example, Firefox shows all of these as the same dark red colour: but all of these are displayed as black: It appears that valid hex digits (b, e) are taken as-is, whereas invalid digits (r, o, n, z) are treated as zero. -- Red rose64 &#x1f339; (talk) 16:35, 6 January 2022 (UTC)
 * font color=bronze
 * font color="#bronze"
 * span style="color:#b0000e;"
 * span style="color:b0000e;"
 * span style="color:bronze;"
 * span style="color:#bronze;"

Yes, this was the long discussion on discord they mentioned ;) —Th e DJ (talk • contribs) 16:39, 6 January 2022 (UTC)
 * I don't know what is the algorithm that font uses for invalid color names, but in Opera, font color="jade" renders a shade of green and font color="vermillion" renders a shade of red similar to their actual colors. So it does give the appearance that font accepts more color names than CSS. I have occassionally seen this type of non-standard color names being used in signatures. ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ (talk) 18:34, 6 January 2022 (UTC)


 * The algorithm is described (possibly incorrectly; when I follow it as described there for the value, I get the wrong color - #0A0E00 instead of the actual #A0E000) in the top answer on https://stackoverflow.com/questions/8318911/why-does-html-think-chucknorris-is-a-color, or, if you prefer an actual W3C/WhatWG standard, on https://html.spec.whatwg.org/multipage/common-microsyntaxes.html#rules-for-parsing-a-legacy-colour-value (I tried, but failed, to find where it was defined in the HTML 3.2 spec). 「 ディノ 奴  千？！ 」☎ Dinoguy1000 18:44, 6 January 2022 (UTC)


 * converts to  but then with step 14 in the W3C/WhatWG standard, since each part of the color starts with 0 and the length is more than 2, we have to trim off the leading zero to get   which is
 * is padded out with 0's to make the length a mutiple of 3, as  and then it converts to   which is    -- WOSlinker (talk) 19:58, 6 January 2022 (UTC)


 * Oh! The trim-leading-0's step wasn't included in the SO answer; that would be why I got the wrong value when I tried. 「 ディノ 奴 千？！ 」☎ Dinoguy1000 23:13, 6 January 2022 (UTC)
 * For those who prefer visuals, a good explanation was recently on Jake Archibald's v/podcast: https://www.youtube.com/watch?v=doeOKTZSX6A&t=150s —Th e DJ (talk • contribs) 23:28, 6 January 2022 (UTC)

Requested move 28 May 2023
<div class="boilerplate mw-archivedtalk" style="background-color: #efe; margin: 0; padding: 0 10px 0 10px; border: 1px dotted #aaa;">
 * The following is a closed discussion of a requested move. Please do not modify it. Subsequent comments should be made in a new section on the talk page. Editors desiring to contest the closing decision should consider a move review after discussing it on the closer's talk page. No further edits should be made to this discussion.

The result of the move request was: moved. (closed by non-admin page mover) – Material  Works  12:08, 4 June 2023 (UTC)

Wikipedia:HTML 5 → HTML5 – HTML5 without space after HTML5. Eurohunter (talk) 11:43, 28 May 2023 (UTC) <div style="padding-left: 1.6em; font-style: italic; border-top: 1px solid #a2a9b1; margin: 0.5em 0; padding-top: 0.5em">The discussion above is closed. <b style="color: #FF0000;">Please do not modify it.</b> Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
 * Support per . Nardog (talk) 11:59, 28 May 2023 (UTC)