Last modified: 2014-09-12 00:34:04 UTC
The "clear formatting" button returns bold and italic text to its plain state, as expected. However it also removes any links in the selection, which is not expected, rather there should be a separate "unlink" button to do this job - conceptually I regard a link as an attribute not as formatting. For example selecting a bolded sentence with an italicised title and a linked word in it. I clicked the clear formatting intending to clear the bold and italic, which it did but it also removed the link. Similarly if using it to remove a link it also removes bold/italic which is unlikely to be the intention.
This is exactly as designed. It also removes language settings (lang=fr and dir=rtl), superscript/subscript/underline/strikethrough/big/small/code formatting, and <span>s setting arbitrary formatting annotations (like "color: red;" or "font-family: serif;" or …). It's modelled against the same function in other editors, rendering the text down to completely plain text (except for objects like references or templates). Do you think each of these formatting options should have a "remove" function? Only some of them? Only those that trigger an inspector rather than just a boolean state (like links, language and arbitrary settings)? Only links? Why/why not? Happy to change direction but it would need to be a pretty strong reason to change (amongst other things, we'd need to give users ways to break out of the other kinds of pre-annotations as well as removing the selected annotation).
Well "superscript/subscript/underline/strikethrough/big/small/code formatting and <span>s setting arbitrary formatting annotations (like "color: red;" or "font-family: serif;" are all just different sorts of text decoration formatting like bold and italic so the clear formatting button is appropriate for all of them. "language settings (lang=fr and dir=rtl)" are not in my mind the same thing as bold, strikethrough, etc, but equally they're not the same thing as links. I haven't thought about them before now and I at this point I just don't know what my opinion is and I don't really know what the arguments for an against are, so more thinking needed before I can you a proper answer for those, sorry. I think possibly the difference in our opinions about links is that you are approaching this from a "make it like a popular word processor that can edit Wikipedia" whereas I'm thinking of it from "make it an editor for Wikipedia that works like word processors". There might not sound much different in those philosophies, and in most cases I don't think there is. However from a word processing POV links are useful-to-have additional metadata, whereas from a Wikipeida editor POV links are fundamental to the structure and essence they don't conceptually fit with decoration.
I agree that links are fundamental to Wikipedia (and other wikis). However, I think it is quite reasonable that 'clear formatting' removes links. If you want to remove something in particular, you can use the individual buttons (click bold to unbold, etc.) in most cases. Part of this is that I've already become used to using 'clear formatting' for links in VE. But I don't think this seemed unintutive even when I started using VE. Also, removing a link takes three clicks if you don't use 'clear formatting'. 'Clear markup' would be more descriptive, but probably less user-friendly.
(In reply to comment #3) Also, removing a link takes three clicks if you don't use 'clear > formatting'. Which is why I said there should be a separate button to remove links with a single click. > 'Clear markup' would be more descriptive, but probably less user-friendly. "Clear markup" doesn't describe what it does either, because it doesn't remove paragraph style, text size, templates, colour, etc. It only removes text formatting and links. My point is that bold and italic, etc. are a subset of formatting, but links aren't. I want the ability to remove formatting without removing links, and the ability to remove links without removing formatting.
(In reply to comment #4) > (In reply to comment #3) > > Also, removing a link takes three clicks if you don't use 'clear > > formatting'. > > Which is why I said there should be a separate button to remove > links with a single click. We're meant to be in the business of removing user confusion, not adding to it. More buttons make things harder to understand, in general. In this specific case I'm not sure. > > 'Clear markup' would be more descriptive, but probably less user- > > friendly. > > "Clear markup" doesn't describe what it does either, because it > doesn't remove paragraph style, text size, templates, colour, etc. > It only removes text formatting and links. Actually, this is wrong. Specifically, "clear formatting" removes everything that's an annotation (things that take text and fiddle with it in some way), and not objects or structure - in VisualEditor language, "styles". I.e., things that are removed: * Bold, italics, underlines, strikethrough, superscript, subscript, code style * Text size (big/small and font-size attributes) * Rich text annotations - links, language (lang="fr"), direction (dir="rtl"), … * Colours (foreground and background highlight) on text * Arbitrary paragraph settings (<span>s with style tags, etc.) … and things that remain: * Formats (paragraph/heading/preformatted/blockquote/…) * Structure (numbered list/bulleted list/definition list/table/…) * Objects (media items/galleries/transclusions/equations/…) > My point is that bold and italic, etc. are a subset of formatting, > but links aren't. In your meaning of the term "formatting". I don't use it that way, and neither do similar functions in other rich editors like Word or Google Docs, I believe. > I want the ability to remove formatting without removing links, and > the ability to remove links without removing formatting. I understand the request. :-) I just don't think that it's a need that is sufficiently widely-held that we should burden all users with an extra button and a confusing "everything except not that one sorry" cognitive step.
*** Bug 59191 has been marked as a duplicate of this bug. ***
*** Bug 70739 has been marked as a duplicate of this bug. ***
