Talk:New requirements for user signatures

Jump to navigation Jump to search

About this board

Welcome! Please use this page to ask questions and share information.

This is a Structured Discussions (Flow) page. Click in "Start a new topic" or reply to an existing thread. Use the pencil icon to switch to wikitext mode. If you find a typo after you post, then the ••• menu is where you find the Edit button. Signatures are automatic.

Whatamidoing (WMF) (talkcontribs)

This change was made about three weeks ago, and the number of active editors with errors seems to have declined during this time. I suspect that this is mostly about new accounts, which can no longer make these mistakes.

I decided today to wait another ~10 days before trying to contact anyone else about fixing their sigs. Especially on the biggest wikis, I don't want to flood RecentChanges with hundreds of messages.

I've started a central help page at New requirements for user signatures/Help. Please put that page on your watchlist (and help me figure out the simplest, easiest ways to explain all of this).

DannyS712 (talkcontribs)

If you use MassMessage to send the notice, RC won't be any more flooded that with, eg, Signpost publications, and the edits should be marked as bot edits and hidden

Reply to "Status"

Talk page link as image link

4
Tacsipacsi (talkcontribs)

AntiCompositeNumber’s report for huwiki lists the following signature as not having a user/user talk link (the user page is Szerkesztő:HoremWeb):

[[kép:horemweb.png|HoremWeb|link=Szerkesztő:HoremWeb]] <sup>[[kép:dd-mdw-jn.png|14px|ḏd md.w jn: szavaknak mondása|link=Szerkesztővita:HoremWeb]]</sup>

Is this invalid according to MediaWiki as well, or it’s just the Toolforge tool that doesn’t recognize it? The resulting HTML has a proper <a> tag in it, so I don’t think that the reply tool (or any other tool) should have issues with it.

Matma Rex (talkcontribs)

You know, I have actually never considered that someone's entire signature might be images…

I tested it and it looks like the MediaWiki code recognizes the links, and this signature is valid.

Tacsipacsi (talkcontribs)

Thanks, I thought for some reason that the deprecation period will start tomorrow, so I didn’t test this myself. So it’s up to AntiCompositeNumber to recognize it in his tool, but this might be quite tricky… Is there a way for Toolforge tools to call a real MediaWiki? It would be a lot easier to simply check for

$validator = new \MediaWiki\PreferencesSignatureValidator(
 $user,
 $context,
 ParserOptions::newFromContext( $context )
);
$signatureErrors = $validator->validateSignature( $signature );

If not, probably this could be exposed as an API (which could be used on Special:Preferences as well to provide nearly real-time feedback about invalid signatures, instead of only on save).

AntiCompositeNumber (talkcontribs)

I'd be able to fix it by switching my parsing code from parsing Wikitext to parsing rendered HTML, but I don't really have the time/energy for that at the moment. As a personal opinion, I don't think it should be valid, but that obviously didn't make it into this round.

Reply to "Talk page link as image link"

No more new broken signatures

1
Whatamidoing (WMF) (talkcontribs)

It is no longer possible to save an invalid custom signature in Special:Preferences#mw-prefsection-personal-signature.

Some volunteers have already started encouraging editors at their home wikis to update their signatures. Please let me know if you are doing this, or if you would like to do this. Anyone is welcome to do this – it's very helpful! – but we should not accidentally contact the same editors multiple times.

Reply to "No more new broken signatures"
Trizek (talkcontribs)

Do you plan to avoid templates in signatures?

I recently came across a case on an archived page, where a user used a personalized template. this template changed overtime and the page was really confusing.

Matma Rex (talkcontribs)

No, that should still be allowed under the new requirements (as long as the output of the template has the links, doesn't have broken markup, etc.).

It's probably not a good idea to do that, and it's forbidden by policy on at least some wikis (e.g. English Wikipedia's signature policy), but we're not doing anything about that right now.

Trizek (talkcontribs)

Thank you! Maybe adding it on a future release, for safety purposes?

Reply to "Template transclusion"

Case of differences between the real username and the displayed username

5
Trizek (talkcontribs)

I wonder if your work will cover the case when someone displays a different username than theirs in their signature. Example: [[user:Foo|Bar]].

This shouldn't be allowed since it is very confusing for everyone. I've already seen people being wrongly pinged, or seeing Foo complaining because someone pinged user:Bar instead of them.

The counterargument "my username is already taken, I want to display my real identity" is a false one. No one complains because they get a phone number they don't like. When one wants to change their username, they can if the account is not taken, or if the account is not in use any more. It is done often. Already used and active usernames simply follow the "first arrived first served rule" and it is clearly not much of a big deal. It happen to me back in the days: my current username was my backup nickname on the Internet. I had the opportunity to built a new identity which was a great experience.

Tacsipacsi (talkcontribs)

I’ve seen various creative solutions that aren’t confusing IMO, including [[User:Foo|foo]] (lower case), [[User:Foo Bar|Foo_Bar]] (underscore instead of space), or [[User:FooBar|Foo]][[User talk:FooBar|Bar]] (user name spanning over the user page and talk page links); Tgr’s signature was at a time roughly [[User:Tgr|TG]][[User talk:Tgr|<sup>®</sup>]] (“registered trademark” logo instead of “r”). [[User:Foo|Bar]] is confusing indeed, but I’m not sure if allowable and non-allowable names can be differentiated using software.

AntiCompositeNumber (talkcontribs)

User:Foo using the signature <code>[[User:Foo|Bar]]</code> is not covered by these changes. That's something best enforced by local signature policies and guidelines, not by technical methods as Tacsipacsi described.

Whatamidoing (WMF) (talkcontribs)

[[User:Foo|Bar]] will be accepted, as long as your username really is "Foo". I agree that this can be confusing.


Trizek (talkcontribs)

Local policies need to be enforced. But honestly, who cares about them? Even on Meta, displaying a different username is perfectly accepted.

An a minima requirement would be to highlight the risk of confusion.

At least, we can expect to have a mention button like we have here on Structured Discussions, that would help quoting participants in the discussion. Hoping that would raise questions like "why this user is not listed?". And hoping that people won't tell themselves "I could change my name too". And lead to more confusion.

Reply to "Case of differences between the real username and the displayed username"
Whatamidoing (WMF) (talkcontribs)

And one of the devs kindly looked it over to make sure that I got the details correct. :-D

Please take a look at New requirements for user signatures#Outcome and let me know if you have any questions.

The first stage (the point at which people will stop accidentally creating broken signatures) could happen on the normal wikitech:Deployments train that will happen from Tuesday, June 30th to Thursday, July 2nd. The end of "grandfathering" (when invalid signatures will stop being added to pages) is at least several months from now.

Whatamidoing (WMF) (talkcontribs)

What I'd really appreciate from you: Please tell your local communities about this, especially:

  • your local Village Pump (technical) or similar tech forums,
  • editors who follow your wiki's signature policy, and
  • the people who will get questions about how to fix signatures.

I'll be making some general announcements, but specific messages to individuals and relevant pages would be helpful.

Reply to "Outcome posted"
Whatamidoing (WMF) (talkcontribs)

Just a quick heads-up to say that the team decided to implement most of this, but not all of it. Official announcements will be forthcoming, but the overall notion is this:

  • They will not disallow all obsolete HTML tags. That could be done later, but they wanted to keep it simpler at this stage.
  • Most of the work will happen during 2020.
  • After they make the initial changes to MediaWiki, we'll notify active editors if their signatures need to be updated.
    • I think that the most likely approach is a MassMessage for each separate problem ("you need to un-tick that box" to one list, "you need to get the template out of your sig" to another list, etc.). @AntiCompositeNumber has a good system for generating these lists, which means that anyone can start this work at any point, or you can wait for me to send messages.
    • If you can help with translation and localization of these messages, please watch this thread (click the star in the upper corner of *this* thread to make it blue, even if you're watching the whole page [which I recommend, too]).
WereSpielChequers (talkcontribs)

It would be good if you could composite media messages where editors are going to get multiple messages, alternatively phase the messages apart so that someone with three problems gets their messages a month or more apart - that would also spread the support side of this. But I do hope you change the signature box validation process first - so any new or changed signatures have to be fully compliant. We don't want a situation where people can fix one problem in their signature by replacing it with something that is about to be a problem

Whatamidoing (WMF) (talkcontribs)

Yes, I agree that the software changes come first.

Are you aware of any editors with three separate problems in their signatures?

WereSpielChequers (talkcontribs)

Hi WhatAmI, I would predict that if you make three changes to the software as to what is a valid signature there will be some editors to whom you cause three problems, but i don't know - I would hope the people who want to make these changes would know. However I would suggest a slightly more editor friendly approach re this - remember the foundation is making changes that are causing a problem to these people's signatures, not that these are editors with problematic signatures. A subtle nuance, but a very important one.

Jonesey95 (talkcontribs)

Some of these editors *do* have signatures that cause problems, like unclosed tags that cause the whole rest of the page to be rendered in a smaller font, or with strikeout text. I provided links on this page or a related page.

WereSpielChequers (talkcontribs)

Hi Jonesey, I don't know about all other projects, but on the wikis where I am most active, if you use a signature that causes the sorts of problems that you describe, people will point out that you have an invalid signature. Dealing with such signatures is not the problem area, the problem is with signatures that are currently valid, and have been valid for some years. Telling people that a change has been made that requires them to make a change to their signature is different than telling people they have made an invalid signature.

Jonesey95 (talkcontribs)

I think we agree then. This page is only about signatures that are invalid in some way.

Whatamidoing (WMF) (talkcontribs)

One of the problems is ticking a box to say how you want your custom signature interpreted, without having a custom signature for the software to interpret. This obviously won't be found in combination with any of the other problems, since the existence of any custom signature, including a problematic one, would make this non-problematic. (Now that I think of it, those messages could go out at any time.)

Nested substitution has been banned in policy since before any of us were baby editors, so I don't expect to find many unblocked/unbanned accounts with that problem. I can imagine the other two problems being combined in the same sig, but I don't remember anyone actually reporting an example of it.


MaxHarmony (talkcontribs)

To clarify, is this change being rolled into the publicly-available software, or is it an internal revision for Wikimedia? If it's being rolled in, will it be a configurable option?

Whatamidoing (WMF) (talkcontribs)

This will affect WMF wikis, e.g., the English Wikipedia. I am not certain if it will affect the default MediaWiki core for anyone who upgrades their private MediaWiki servers, but I believe that it will be. Do you have your own wiki?

Tacsipacsi (talkcontribs)

I think this should certainly be configurable for non-WMF wikis. I’ve had hard time disabling all password complexity rules, so that I can have 1234 as a sysop password in my own wiki, running on my own computer, in my own local network—nobody will ever try to hack that account, as only my family has even a chance to access the wiki. Similarly, different wikis may have different rules and customs; most wikis will probably never use DiscussionTools, so this change is not technically needed on them etc. (Just to reassure: I have a much stronger password than 1234 here on MediaWiki.org, as it’s a real possibility that someone tries to hack into my Wikimedia account.)

Reply to "Outcome"

Do you have an example signature?

28
Whatamidoing (WMF) (talkcontribs)

Is there a custom sig that you think should be accepted, or rejected, or you're just curious whether it would be accepted? You can post it here if you want to.

AntiCompositeNumber (talkcontribs)

For the requirement for a link to user/talk/contribs: can the link be an interwiki or interlanguage link? For example, users @GB fan and @DerSpezialist on enwiki currently use the signatures [[:en:User talk:GB fan|~ GB fan]] and [[:de:Benutzer:DerSpezialist|Spezialist]]<sup>([[:de:Benutzer Diskussion:DerSpezialist|talk]])</sup>, respectively.

Whatamidoing (WMF) (talkcontribs)

@Matma Rex, what do you think of this? It's not unusual for a MassMessage to be sent "from" m:User:Whatamidoing (WMF). Although that's done manually per-message, it's possible that some people might set their prefs that way, especially outside their home wiki.

AntiCompositeNumber (talkcontribs)

Note: I did see one editor in my dataset with an interlanguage link like [[en:User talk...]]. If IWLs/ILLs are allowed, an unprefixed ILL like that (which would show up in the sidebar, not as an inline link) should generate an error.

Whatamidoing (WMF) (talkcontribs)
AntiCompositeNumber (talkcontribs)

Yes (the one mentioned here). That specific link works, since it's already on enwiki. However, when that exact signature is copy-pasted to another wiki (or set globally), it might not work (depending on how the interwikis are set up).

Whatamidoing (WMF) (talkcontribs)

I'm wondering whether we might see more interwiki links at Meta.

AntiCompositeNumber (talkcontribs)

@Whatamidoing (WMF) They are more prevalent on Meta, but there are fewer signatures overall and 36 times fewer potentially problematic signatures of recently-active Meta users. data

Matma Rex (talkcontribs)

The main problem with these is that namespace names are translated, so we'd have to load localisation data for all the hundreds of languages, which is actually way slower in MediaWiki than you'd think (once upon a time I tried to do that in some unit tests, it took several seconds).

If folks really want this, then I suppose we could add an exception so that any signature with an interwiki link is valid, but we realistically can't validate that the link points to a user page (and DiscussionTools, Echo etc. won't be able to detect this signature).

I'm not sure if having a signature like this makes much sense these days. We have cross-wiki notifications, so why ask other users to reply to you on another wiki? (I actually used to have a signature like that on en.wp, e.g. … good times.)

Note also that you could easily have both a local and an interwiki link, which to me seems like the best of both worlds.

AntiCompositeNumber (talkcontribs)

Another question: what about links to redirects? On nl.wiktionary.org, @~riley uses -[[User:Riley Huntley|Riley Huntley]] [[Meta:SWMT|(SWMT)]]. That page is a redirect created during renaming, and I expect that there are plenty of similar signatures on other wikis.

Matma Rex (talkcontribs)

DiscussionTools would not follow the redirect, so it will detect the "wrong" user as the author of a comment. Right now that doesn't really cause any problems, but in the future we might want to send notifications about the reply or something. (And remember that after an account is renamed, a new account can be registered under the old name, so I don't think it would be correct for us to just follow the redirect.)

I think we should treat this as invalid.

Cabayi (talkcontribs)

that doesn't really cause any problems, except that the Navigation Popups gadget will be showing the credentials of the previous account (either a non-existent account, or zero if the user created a new account there to block misuse), and tools which highlight users based on their permissions won't work.

Perhaps the change username process should also blank non-default sigs to ensure they use the new username?

AntiCompositeNumber (talkcontribs)

The most user-friendly option would be to automatically replace User:OldUsername with User:NewUsername in fancy signatures, but that is likely to take the most development effort. Blanking the signature from an active user isn't going to be a great idea (I think we could just about get away with it with old accounts, but someone who just had their account renamed is likely to notice and complain), but the "ignored until fixed in preferences" state proposed by others here would work. Adding a message to the rename complete notification for users with fancy signatures would also be a good idea.

Tacsipacsi (talkcontribs)

As tools read existing signatures, the biggest problem is the comments signed before the renaming. This is a problem also for the vast majority of users who don’t use fancy signatures. This may be out of the scope of this project, but I think it has a much bigger impact than fancy signatures placed after the renaming. The latter will, in fact, be disallowed if the current proposal gets implemented, as not updated fancy signatures no longer contain a link to the new user page.

Cabayi (talkcontribs)
~riley (talkcontribs)

I honestly just don't have time to change my signature across 800 wikis. There should be technical support from Mediawiki to make this possible through preferences, a special page or a user script.

Tacsipacsi (talkcontribs)

Or a Toolforge tool. There is a grant named editmyoptions, which allows OAuth tools to change preferences.

Cabayi (talkcontribs)

Wondering, we have global user pages, global js, global css, why not global sigs?

~riley (talkcontribs)
AntiCompositeNumber (talkcontribs)
AntiCompositeNumber (talkcontribs)

Yeah, I've got another one. On de.wikipedia.org, @Doc Taxon has <small> {{ers:#timel:H:i, j. M Y (T)}}</small> at the end of their signature and appears to sign with ~~~ instead of the usual four tildes. This creates a correctly formatted (for dewiki) timestamp, but surrounds it with <small> tags. Looking for a properly-formatted date is one of the current methods for signature detection, and the extra markup might confuse that method.

Whatamidoing (WMF) (talkcontribs)

That's an interesting one. I don't know whether the Reply tool is looking for the timestamp to be at the very end of the line, but other tools might.

Doc Taxon (talkcontribs)

The reply tool handles my signature correctly. Is there a problem with it?

Whatamidoing (WMF) (talkcontribs)

In terms of this product, I don't know.  @Matma Rex would be the best person to answer that question. In terms of other tools (e.g., an archiving bot), it's possible that some of them are confused, but if you're not getting complaints, then it's likely that the more popular tools at the German-language Wikipedia can handle it.

Matma Rex (talkcontribs)

@AntiCompositeNumber @Doc Taxon I tried a similar signature locally and it doesn't seem to work with DiscussionTools (there is no "Reply" link for it). Are you talking about a different reply tool?

The code in DiscussionTools is intentionally quite strict to avoid incorrectly matching random userpage links as if they were signatures; we pretty much expect exactly the output of ~~~~. I don't think we should be adding special cases for other things, except possibly auto-signing bots with thousands of edits.

In general I'm not a fan of customizing the timestamp. I guess <small> is harmless, but I've seen user signatures that put the timestamp inside of the userpage link, or where the timestamp has a different date format, and I'd personally consider those disruptive. And it would be difficult to draw a line between those.

For the record, the proposed new validation here would not reject your signature or any of those I mentioned, though.

Doc Taxon (talkcontribs)

Oh, because I have been mentioned above to this topic, I thought, you're talking about tools like Ping or Replyto. I think it was a misunderstanding. Sorry!

Tacsipacsi (talkcontribs)

I think any tool should allow some closing HTML tags after the signature, as they might appear for several reasons: for example, when I post a side comment, I usually write it in small, including my signature ~~~~, or when someone reconsiders their opinion, they might strike through the old one ~~~~ and underline the new one ~~~~. In all these cases, the comment ends with a closing HTML tag, which doesn’t come from the preferences, by the way.

Pelagic (talkcontribs)

French Wikipedia's equivalent of sinebot wraps the date in a link to the revision. That could be reformatted to work with Discussion Tools, but @Tacsipacsi's use cases are something that hadn't occurred to me.

Ideally we'd have some explicit start-of-comment &/or end-of-comment markup, but whilst we rely on detecting timestamps, anything that doesn't end in Pelagic (talk) 21:54, 7 May 2020 (UTC) ~~~~ [good grief, I wasn't expecting Structured Discussions to translate the tildes!] has the potential to misbehave.

As @Matma Rex pointed out, sig. validation won't affect these, though.

Reply to "Do you have an example signature?"
156.57.13.33 (talkcontribs)

Signatures should be in a proper format. This is long overdue. ~~~~

Pine (talkcontribs)

I'm OK with the proposal, and I would explicitly give communities the option to enforce the requirement on existing signatures. My guess is that some communities would be willing to enforce the requirement on existing signatures after a grace period and after providing notifications to affected users who have noncompliant signatures.

Anomalocaris (talkcontribs)

The software should not allow any changes to a signature that leaves a signatures with any External links, line breaks, horizontal rule, unescaped pipe character, images, or lint error including font tags, or lacking a link to some user page. Users with signatures not in compliance with any of these should be given 60 days to fix their signature and after that the signature should be wiped and they get the default signature. There should be a link to a help desk where you can ask, among other things, "Please help me create a signature string that renders like my existing string but is in compliance with the new rules." On wipe-noncompliant-signature day, non-compliant signatures should be stored in an "Old Sig" field to help those on Wiki-breaks to develop a compliant signature when they return.

Whatamidoing (WMF) (talkcontribs)

Presumably, if you have a custom sig, you have also signed a comment. That means that you could find a copy of your custom sig in Special:MyContributions.

Pine (talkcontribs)
Reply to "Whole hearted support"

Support, but not sure about font

29
Headbomb (talkcontribs)

<font face="Helvetica">

is a lot shorter than

<span style="font-family: Helvetica">

Jonesey95 (talkcontribs)
Izno (talkcontribs)

I am on the same page as Jonesey. It is nice that it is short but browsers may stop supporting it at any time, in which case all those beautiful customized signatures will not be beautiful anymore.

AntiCompositeNumber (talkcontribs)

I definitely agree that <font> shouldn't be used anymore, but I'm also aware that there are probably still editors that are a) still using it, b) close to the character limit, and c) would run to the dramaboards because the evil WMF banned their personal signature out of spite. If anyone has any sort of data to say how prevalent font tags are in signatures, it would probably help guide this decision.

AntiCompositeNumber (talkcontribs)

Alright, I ran the numbers: there are 6705 enwiki editors with a font tag in their signature already. Some of them clearly haven't been changed in a while, since they predate the software-enforced 255 character limit. There are 1916 enwiki editors with a font tag and a signature longer than 200 characters. Nothing would break immediately for these editors if they did not change their signature, but many would be unable to make any edits to their signature without removing the existing formatting (because the span tags are too long).

Jonesey95 (talkcontribs)

Do you have a way of knowing how many of those 1,916 editors have made an edit in the last year? That would give us an idea of how many people may actually be affected by font tags being deprecated.

And FWIW, changing a font tag to a span tag if you are setting the font face, as in Headbomb's example above, adds 14 characters, but if you are just setting the color, it adds only 7 characters. The vast majority of editors should be fine, and a few might have to make do with a bit less customization.

Headbomb (talkcontribs)

It would probably also be a good idea to post suggested fixes to the signatures. For example a bot message like

Blah blah blah, linter error, html 5 blah blah blah, which is bad because of explosions, murder, and possibly jaywalking

  • Current signature: <b>[[User:Example]]</b>, which renders as User:Example
  • Suggested signature: '''[[User:Example]]''' which renders as User:Example

A message from FIX-YO-SIG Bot 00:41, 5 March 2020 (UTC)

Izno (talkcontribs)

I think I would tend toward a "see Project:Signature fix page for a list of common optimizations and feel free to ask on the talk page if you need help changing your signature."; even in your example, there might be context such as <span> elements with styling that could instead be turned into <b> elements with styling.

But, that's implementation details.

Headbomb (talkcontribs)

That's also a good potential workflow. Possibly with a bot posting basically a similar message and pointing them to that signature fixing page.

TheDJ (talkcontribs)

Well lint fixing experiences of the past show that you can't even write a bot for some of these things, so either we need a really smart AI, or we just have a page where some humans help out.

AntiCompositeNumber (talkcontribs)

363 editors have font tags and have made an edit since 2019-03-04T00:00:00Z.

Izno (talkcontribs)

I do not think 363 is really a sufficient quantity to support font, and eyeballing the majority of the cases pulled up in that query, I don't really think the signature lengths I'm seeing need it either given a number of optimizations I can see being made to most of those signatures. For the others, I don't think they should really be running around with such individuality as I'm seeing.

(But thank you for the tasty data.)

Headbomb (talkcontribs)

Also this editing interface is garbage. ~~~~

Whatamidoing (WMF) (talkcontribs)

This community prefers that people start in visual mode. The pencil icon in the corner by the "Reply" button will let you switch to wikitext mode (automatic sticky preference, so make it in your next reply, and it'll remember it until you change it).

AntiCompositeNumber (talkcontribs)

I'd definitely agree that prohibiting <font> tags will cause unnecessary complaints. The other requirements seem to be reasonable and enforced by policy and/or angry editors in many places already. The overall decision to deprecate and remove font tags as lint errors is probably outside the scope of this proposal though.

Headbomb (talkcontribs)

It's not only the familiarity of the font tags themselves, but also the length saving. The difference between font/span example above is a whopping 14 characters.

Everything else seems kosher.

Headbomb (talkcontribs)

It's really not evident in the least that a pencil icon switches between different editing interface.

AntiCompositeNumber (talkcontribs)

It is the standard button for it throughout OOUI.

Headbomb (talkcontribs)

I'd say it's equally confusing everywhere it's used then. Anyway, that's irrelevant to signatures, so let's stop here. Other fun fact about VE discussions, you can't collapse/archiving side discussions or re-indent them to make them follow one another. Yaaayyyy.

Whatamidoing (WMF) (talkcontribs)

(Technically, this is Flow, which happens to use a version of VisualEditor as one of its editing environments. I'm not sure that there's even a name for Flow's wikitext mode. I think that both desktop and mobile use the same tools in Flow, so you should only have two, rather than four, editing systems here.)

RexxS (talkcontribs)

I'd definitely get rid of <font>...</font> tags. All too often you get something like <font face="Helvetica">''' ... '''</font>, which translates to <b style="font-family:Helvetica"> ... </b>, which is only one character more. It's often possible to use style="font:Helvetica" if the other font property defaults are okay at that point, and that actually saves six characters net. When you get colour changes at the same point, you increase the savings, and because styles can be applied to <i>...</i>, <sup>...</sup>, <small>...</small>, etc. there are lots of opportunities for applying a style without adding a span. That very often results in a net decrease instead of a net increase in sig length.

Anomalocaris (talkcontribs)

Can you provide an example where style="font:Helvetica" actually works?

AntiCompositeNumber (talkcontribs)

It has to be "font-family:Helvetica", not "font:Helvetica". You probably won't see any difference with Helvetica anyway, since there's a good chance that it is or is very similar to your default sans-serif font. If we use "font-family:serif", like this, there is a clear effect.

Anomalocaris (talkcontribs)

In other words, when RexxS said,

It's often possible to use style="font:Helvetica" if the other font property defaults are okay at that point, and that actually saves six characters net.

this was entirely incorrect.

Izno (talkcontribs)
Anomalocaris (talkcontribs)

Izno: That shorthand requires a font size. Examples:

  • <font face="Times">The quick brown fox jumps over the lazy dog.</font>
The quick brown fox jumps over the lazy dog.
  • <span style="font:14px Times">The quick brown fox jumps over the lazy dog.</span>
The quick brown fox jumps over the lazy dog.
  • <span style="font: Times">The quick brown fox jumps over the lazy dog.</span>
The quick brown fox jumps over the lazy dog.

Without a font size, the markup doesn't work. In English Wikipedia, rather than 14px, I need 12.7px to make the lines the same, and although English Wikipedia uses a default font size=small, using "small" instead of 12.7 results in a slightly larger-than-default font size, unlike <span style="font-size:small">, which has no effect on size.

RexxS (talkcontribs)

Entirely incorrect - apart from all the documentation on the CSS font property, of course.

For example:

https://developer.mozilla.org/en-US/docs/Web/CSS/font

"The font CSS property is a shorthand for font-style, font-variant, font-weight, font-stretch, font-size, line-height, and font-family. Alternatively, it sets an element's font to a system font.

Nevertheless, as you say, it doesn't work if you only specify the name(s) of the font-family. Oddly enough, style="font:1em serif" actually works.

This is serif text

So I can only save 2 characters net (unless you also want to change the font size at that point). I have no idea why some combinations of properties work and others don't.

AntiCompositeNumber (talkcontribs)

because css

RexxS (talkcontribs)

Indeed

Reply to "Support, but not sure about font"