Allow span tag by default for language changes?

Makes sense to me. What are the possible concerns from a system perspective?

My concern is how to communicate this to authors. WTF does span mean?! Would be the response of most authors. Of course, this is likely similar for most tags.

This makes sense, but needs feedback from the maintainer. I do not really expect we can fully inform the user about this option, but we can do our best .

The actual use-case here is a citation, for which there is the cite tag already.

Which other actual use-cases are not covered by existing elements, for which we'd have to allow span tags?

That said, regardless of that answer, I'm pretty much opposed to this change, as it assumes that end-users (regular visitors/users of a site) would understand this detail of HTML, and, that they would actually markup their content accordingly. That's likely a fraction of <1%... For the other 99%, the span tag is needless visual clutter in filter tips.

I don't think adding <span> to the tag list is any markedly more cluttered than the clutter we already have.

I actually add <span> on multilingual sites for exactly this reason. Given that most users probably don't know they're supposed to do this, having a documented example in the filter tips seems reasonable. On the other hand, 99% of what <span> gets used for on the web is dubious inline CSS.

Attached just rerolls for core/.

-1

I think it's less than 1% of site use it. If you are the 1%, enable it yourself, super easy, no extra modules, no extra coding.
abbr tag is more valuable to add in but I opposed it too.

no one read drupal tips to learn how to type in C'est la vie. Even users know it, they may not use it. Try to open your own site and check how many abbreviation do not using ABBR.

C'est la vie

One could also point to the slippery slope here: If we add span for a very small use case, then how many other tags with very small use cases would we add if we were consistent?

Drupal has started down the road to provide enterprise support for multi-lingual sites since Drupal 6. In Drupal 8, as with Drupal 7, this is going to improve.

I'm guessing that less than 1% of all Drupal sites will be fully bilingual. ~95% of all Government of Canada sites will be. Same with the Netherlands I expect.

If we're looking at a 1% challenge (which frankly is a popular number toss about these days), let's look at the allowed code:

<a> <em> <strong> <cite> <blockquote> <code> <ul> <ol> <li> <dl> <dt> <dd>

I know that most folks haven't used definition lists in more than 1% of their posts. So why is that list there? Probably because it allows for good semantic presentation for 1% of content.

The main objection I can see to not including SPAN is that it makes the options slightly more complicated.

when do we add these tags:

<cite> <dl> <dt> <dd>

is multi-lingual sites the only reason to add this tag?? can't move to Locale module? (but I don't think it's the right way too, just an option better than add by default installation)

IMO, Filtered HTML should only included basic typography elements that could formatting text to provide visible effects.

1. The default allowed tags in Filtered HTML are mainly supposed for visual formatting. On a level that end-users of your site (i.e., visitors) are able to understand (hopefully). Even if a definition list might be a 1% use-case, the elements are clearly defined and produce a unambiguous formatting.
2. Just look at the patch, and at the filter tip. Now presume you don't know HTML. I can tell you what you're going to do:
   

   To say "Good morning" in German:
   <span lang="de">
   <blockquote>Guten Morgen!</blockquote>
   </span>
   
   Depending on the time of day, different variations are used:
   <span lang="de">
   <ul>
   <li>Guten Morgen!</li>
   <li>Guten Tag!</li>
   <li>Guten Abend!</li>
   </ul>
   </span>
   

   That's invalid HTML, regardless of how you look at it. And if I'm not heavily mistaken, the HTML Corrector filter will strip or destroy the markup.

I'd certainly agree that my end users pretty much never read the freaking filter tips, but that's another issue. :) I'm not sure users inputting invalid markup is really part of this issue either. That's going to happen no matter what we do.

Also, remember that we are just talking about a default value. It is very easy to add <span> to the allowed tags. I don't know much about the WCAG and what Drupal is expected to do out of the box, but I think that's the question here. Whether or not adding <span> as a default tag would enhance our compliance with: http://www.w3.org/TR/ATAG20/#principle_b2, or whether it's not relevant and it should be up to site builders to add the tag if they should use it.

I am on the fence on this issue.

On the one hand it is good to be more ATAG compliant out of the box. That being said lang="fr" can be used on any element currently allowed by the filter.

On the other hand, being technically compliant, but so doing in a way that means that we really haven't added any usability isn't really that beneficial. If almost nobody knows how to properly use <span lang="fr">bonjour</span> properly have we really added any value to the product?

I can somewhat confirm what xjm is saying that users hardly/don't notice the filter tips. It is likely we will use a different design for this in D8.

I share Everett his concerns whether we are truly adding value, if it is unlikely users will notice and actually use it.

@#19,

alright, if it get into default tags, I would suggest change tips and examples. lang="fr" is allowed & valid in every tags ?

+++ b/core/modules/filter/filter.moduleundefined
@@ -1275,6 +1275,7 @@ function _filter_html_tips($filter, $format, $long = FALSE) {
+    'span' => array(t('Group part of a text (i.e. for language)'), t('<span lang="fr">C\'est la vie</span>')),

18 days to next Drupal core point release.

Nice addition @droplet

#11: 1322906-11.patch queued for re-testing.

tagging

Might be interesting though to have a preconfigured WYSIWYG button. That would be a real enabler.

IMHO, we should definitely close and revert this one to its original scope, and followup on the new ticket.

@Hanno are you going to open a new ticket & link it to this one?

Nice to see this is in CKEditor now
http://dev.ckeditor.com/ticket/7987#comment:30
http://ckeditor.com/demo#full