Wikipedia talk:HTML5

On 28 May 2023, it was proposed that this page be moved from Wikipedia:HTML 5 to Wikipedia:HTML5. The result of the discussion was moved.

Is the toptextcells class defined on the English Wikipedia? --  Gadget850 ^talk 02:59, 4 August 2014 (UTC)[reply]

@

Helder 03:34, 4 August 2014 (UTC)[reply

]

This is starting to look like Help:HTML in wikitext. Aren't we reinventing the wheel here? -- [[User:Edokter]] {{talk}} 09:24, 6 December 2014 (UTC)[reply]

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. --  Gadget850 ^talk 13:55, 6 December 2014 (UTC)[reply]

See

Edokter 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 <br clear=both /> not <br clear=all />. If an person came here looking how to convert <br clear=both />, there would be no answer.
Converting <br clear=both /> into {{

I think that part of the confusion is that the two different syntaxes have slightly different sets of permitted values.

• The clear= attribute (valid in HTML 3.2, deprecated in HTML 4.01, obsolete in HTML 5) allows values of none left right or all
• the clear: property of CSS 2.1 (valid within a style="" attribute in HTML 4.01 and HTML 5) allows values of none left right or both (also inherit which we won't worry about here).

It's the difference in that last value - clear=all vs style="clear:both;" which causes some people to use clear=both or style="clear:all;" and wonder why it doesn't work as intended. Of particular note is that the CSS spec indicates that the clear: property "applies to: block-level elements", and the <br /> element is not block-level, but inline. --Redrose64 (talk) 20:01, 2 February 2015 (UTC)[reply]

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 <br style="clear:all" /> works, it doesn't sit right with me for the same reason Redrose64 pointed out. -- [[User:Edokter]] {{talk}} 21:16, 2 February 2015 (UTC)[reply

]

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

]

But clear can only apply to block elements, so <br style="clear:all" /> basically forces the inline <br /> element to behave as block. There is no difference in rendering, so why continue to use an invalid construct? -- [[User:Edokter]] {{talk}} 09:37, 4 February 2015 (UTC)[reply]

I think {{

-}} should just point to {{clear}}. Bgwhite (talk) 10:04, 4 February 2015 (UTC)[reply

]

That is what I have been argueing :) I fixed the navbox margin issue long ago... in 2011. -- [[User:Edokter]] {{talk}} 12:08, 4 February 2015 (UTC)[reply]

Edokter Here is an example of a person only using it for a blank space. Bgwhite (talk) 19:19, 4 February 2015 (UTC)[reply]

I think I'll increase the margin. This is unintended use. -- [[User:Edokter]] {{talk}} 21:05, 4 February 2015 (UTC)[reply]

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

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. -- [[User:Edokter]] {{talk}} 23:48, 4 February 2015 (UTC)[reply]

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. --Redrose64 (talk) 00:22, 5 February 2015 (UTC)[reply]

The comment is intended to keep AWB and other scripts from removing the whitespace. I see thet Yobot fixed the break and was reverted. --  Gadget850 ^talk 00:32, 5 February 2015 (UTC)[reply]

Yobot replaced the br tags with the template. In any case, adding whitespace should no longer be necessary, so those comments can go. -- [[User:Edokter]] {{talk}} 08:30, 5 February 2015 (UTC)[reply]

Folks, please stop this now, <br style="clear:…" /> is not the same as what {{clear}} does, i.e., an empty <div style="clear:…"></div>. As noted above the <br> forces a line break in addition to anything the style= does, that's not the case for <div>. The <div> will be invalid in some places, where the <br> 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, <br>, and <div>. Ignore CSS, everybody here agrees on how style="clear:… work. –Be..anyone (talk) 22:45, 7 February 2015 (UTC)[reply]

You do know that <br style="clear: ..." /> not valid HTML, don't you? clear can only be applied to block level elements, which <br /> 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? -- [[User:Edokter]] {{talk}} 23:31, 7 February 2015 (UTC)[reply]

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 <div style="clear:…"></div>, one line in both templates is easy enough for me. –Be..anyone (talk) 23:48, 7 February 2015 (UTC)[reply

]

HTML5 says that <br> 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)[reply]

In HTML 4 and HTML 5, all HTML tags that are valid in the body may be given the style= 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 clear: property of CSS 2.1' and 'the CSS spec indicates that the clear: property "applies to: block-level elements"'. --Redrose64 (talk) 00:24, 8 February 2015 (UTC)[reply]

Sounds good for CSS2.1 and whatever WD-css3-break tries to tell me, possible fixes for {{

-

}}:

1. #REDIRECT [[Template:Clear]] {{R from template shortcut}}
2. <br style="display:block;clear:both" />

The latter would cover the former HTML3 and XHTML1 transitional <br clear="all" /> edit history for this beast. –Be..anyone (talk) 13:44, 9 February 2015 (UTC)[reply]

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

That (2) is ugly... <br> adds nothing, so why keep using it? -- [[User:Edokter]] {{talk}} 14:53, 9 February 2015 (UTC)[reply]

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 <div />, 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)[reply

]

The clear: 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 clear: 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). --Redrose64 (talk) 15:43, 9 February 2015 (UTC)[reply]

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

Source? -- [[User:Edokter]] {{talk}} 00:01, 10 February 2015 (UTC)[reply]

Maybe not only my Chrome refuses to show the <blockquote cite="http://www.w3.org/TR/html51/rendering.html"> 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)[reply]

The cite attribute is always invisible, and HTML5.1 is not relevant here. -- [[User:Edokter]] {{talk}} 16:35, 10 February 2015 (UTC)[reply]

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. -- [[User:Edokter]] {{talk}} 12:27, 23 February 2015 (UTC)[reply]

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? --  Gadget850 ^talk 12:51, 23 February 2015 (UTC)[reply]

I examined the effects of <big> and font-size: larger; in all major browsers, and fortunately, they all result in an increase of exactly 120%. <small> and font-size: smaller; are not so consistent, but generally results in 85%. The non-relative keywords form font-size: xx-small; to font-size: xx-large; 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. -- [[User:Edokter]] {{talk}} 13:13, 23 February 2015 (UTC)[reply]

I see why this is complex. On my test page, measured with JRuler:

• Firefox 36: <big> x 5 shows as 195px wide, 249% is 122px, 400% is 194px (my original selection).
• IE11: <big> x 5 shows as 108px wide, 249% is 122px.

I see <big> x 5 used in two articles to increase the size of a Unicode character. --  Gadget850 ^talk 14:23, 23 February 2015 (UTC)[reply]

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 <big>, especially the nested ones. -- [[User:Edokter]] {{talk}} 15:41, 23 February 2015 (UTC)[reply]

The official guidance from W3C is that <big>...</big> should be styled with the declaration font-size: larger;, see the HTML 5 spec, section 10.3.4 Phrasing content. --Redrose64 (talk) 16:54, 23 February 2015 (UTC)[reply]

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."[1] Which does not give any specifics on the size of nested bigs. --  Gadget850 ^talk 18:12, 23 February 2015 (UTC)[reply]

I would expect the font size to increase exponentially: <big><big>...</big></big> should give a "larger" size that is itself made "larger", and if on a given browser, font-size: larger; equates to 120%, then 120% * 120% is 144% and nesting five <big>...</big> should give 120%^5 or 248.832% --Redrose64 (talk) 18:51, 23 February 2015 (UTC)[reply]

Added another test at User:Gadget850/big. Firefox expands <big> x5 about 450% of standard and IE11 about 220%.

I agree with Edokter: nested big is a Bad Thing™. --  Gadget850 ^talk 23:36, 23 February 2015 (UTC)[reply]

Font size templates

Wikipedia:HTML5#Parser tags doesn't list how to center <score> or <code> tags. Could these be added to the list? Bgwhite (talk) 20:36, 23 February 2015 (UTC)[reply]

The <code>...</code> element is inline, so centring it is as effective and as useful as attempting to centre the <b>...</b> or <i>...</i> elements. As for <score>...</score>, it apparently doesn't recognise the class=center attribute, but there's no reason you couldn't do this:

that is, wrap it in <div class=center>...</div> --Redrose64 (talk) 21:22, 23 February 2015 (UTC)[reply]

Or {{center}}, which is cleaner in the markup. <code> is a standard HTML element used to add semantics and presentation to text: use {{center}} just as you would with any other text. --  Gadget850 ^talk 22:49, 23 February 2015 (UTC)[reply]

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

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

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. T40487 has been open for two years: The button on the editing toolbar adds <big>.

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. --  Gadget850 ^talk 23:56, 23 February 2015 (UTC)[reply]

For <font>, <strike> and <br clear> tags in articles, you can look at CheckWiki errors #40, #42 and #2 respectively. There is a CheckWiki error to find <big> 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 <big> tags still left in articles. Bgwhite (talk) 00:11, 24 February 2015 (UTC)[reply]

@Gadget850: 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 bgcolor= 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). --Redrose64 (talk) 10:44, 24 February 2015 (UTC)[reply]

The first search insource:/\<big/i 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

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 prefix:A 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 insource:"div align" insource:/\<div align/ — CpiralCpiral 06:32, 22 July 2015 (UTC)[reply]

OK, search links it is. I've tightened them all up with all kinds of filters so the regex run fast. — CpiralCpiral 08:21, 8 August 2015 (UTC)[reply]

• font element can change wikilink color
  • <font color="red">[[Cosmos]]</font> → Cosmos
• span element can NOT change wikilink color
  • <span style="color:red;">[[Cosmos]]</span> → Cosmos
• method for changing wikilink color using span element
  • [[Cosmos|<span style="color:red;">Cosmos</span>]] → Cosmos

Is this OK? Or is there any other way? --Momijiro (talk) 00:56, 4 February 2017 (UTC)[reply]

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:CONTRAST. --Redrose64 🌹 (talk) 11:03, 4 February 2017 (UTC)[reply

]

Thank you OK, I understood. --Momijiro (talk) 17:01, 4 February 2017 (UTC)[reply]

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

]

@Anomalocaris: Why are you telling me this five years on, and which I fully understood at the time? --Redrose64 🌹 (talk) 22:24, 23 May 2022 (UTC)[reply]

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

Per a request by Guy Macon 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.) {{small}}. 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)[reply]

FYI

 – Pointer to relevant discussion elsewhere.

Please see: Wikipedia:Templates for discussion/Log/2020 December 3#Template:Hover title and Template:Tooltip

Summary:

• {{Abbr}} (a wrapper for <abbr>...</abbr>) has long been abused for non-abbreviation markup (against the HTML specs).
• We had a template, {{Tooltip}}, with <span>...</span> for non-abbreviation use, but it was "merged" (not really) and redirected to {{Abbr}}.
• The redir was then deprecated (for the reason mentioned above), but the community ignored the deprecation.
• In the interim, {{
  Hover title
  }} was created to do the same thing, but with backwards parameters (and some additional features).
• Both the {{Tooltip}} then-redirect and {{
  Hover title
  }} template have been transcluded in tens of thousands of articles, mainly via infoboxes and other templates.
• I created a new {{Tooltip}} template, with all the features of {{Hover title}} but preserving the {{Abbr}} parameter order (to not break deployed translcusions).
• The TfM linked above would merge away {{
  Hover title
  }}, 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.

 — SMcCandlish ☏ ¢ 😼  00:26, 4 December 2020 (UTC)[reply]

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?

AFAIK class=center won't work if perrow= exists in the gallery tag. --Minorax (talk) 04:18, 3 January 2021 (UTC)[reply]

@Dinoguy1000: 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:

• font color=bronze
• font color="#bronze"
• span style="color:#b0000e;"

but all of these are displayed as black:

• span style="color:b0000e;"
• span style="color:bronze;"
• span style="color:#bronze;"

It appears that valid hex digits (b, e) are taken as-is, whereas invalid digits (r, o, n, z) are treated as zero. --Redrose64 🌹 (talk) 16:35, 6 January 2022 (UTC)[reply]

Yes, this was the long discussion on discord they mentioned ;) —TheDJ (talk • contribs) 16:39, 6 January 2022 (UTC)[reply]

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

The algorithm is described (possibly incorrectly; when I follow it as described there for the value harlequin, 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)[reply]

harlequin converts to 0A0-0E0-000 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 A0-E0-00 which is #A0E000

jade is padded out with 0's to make the length a mutiple of 3, as jade00 and then it converts to 0A-DE-00 which is #0ADE00 -- WOSlinker (talk) 19:58, 6 January 2022 (UTC)[reply]

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

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 —TheDJ (talk • contribs) 23:28, 6 January 2022 (UTC)[reply]