XML-slash-like behavior in HTML mode

[RobFreundlich]

Code: [Select]

[code][code][code]If I'm in XML mode and I type the following:

[code]
<abc>
    <def>123</def>
    <

and then hit the forward slash, I'll end up with this:

Code: [Select]

<abc>
    <def>123</def>
</abc>

Forward slash is bound to the xml-slash command which seems to know what open tag you are closing, and inserts it and sets the line's indentation properly to match the open tag.

Is there any way to get this behavior in HTML mode?  I have many tags which auto-insert their close-tag and so on, which covers many cases.  But I also have cases where I don't always use this.  For example, I might have deleted the close-tag, or might be using a custom tag.  In those cases, it'd be really useful to have the XML-like behavior.[/code][/code][/code][/code]

[PlanetPratt]

I would definitely second the request for that feature.  I find it annoying that it doesn't act the same for all markup languages.
  (*Chris*)

[ScottW, VP of Dev]

I talked this over with the team today, and providing this type of functionality for HTML is more complicated than for XML. Unless you are writing XHTML, HTML is rarely well-formed. People often use <p> to separate paragraphs rather than enclosing them with <p> ... </p>. Lists are another area that are often not balanced. So there would be many situations where the XML slash behavior does the wrong thing.

I'll file a feature request for this. Maybe we can handle this if there is a list of unbalanced tags that are used. The editor would skip those tags when searching backward for the matching open tag. Let me know if you have any ideas for how we can effectively handle this.

--Scott

[PlanetPratt]

As long as it can be turned off (or tuned) for those people who insist on writing bad HTML, I think promoting balanced HTML would be a benefit.
  (*Chris*)

[RobFreundlich]

I talked this over with the team today, and providing this type of functionality for HTML is more complicated than for XML. Unless you are writing XHTML, HTML is rarely well-formed. People often use <p> to separate paragraphs rather than enclosing them with <p> ... </p>. Lists are another area that are often not balanced. So there would be many situations where the XML slash behavior does the wrong thing.

Good point, although my team writes properly formatted HTML even though we aren't officially doing XHTML.  However, I'd agree with PlanetPratt that letting it be turned off would probably be enough for the poorly-formed-HTML folks.

I'll file a feature request for this. Maybe we can handle this if there is a list of unbalanced tags that are used. The editor would skip those tags when searching backward for the matching open tag. Let me know if you have any ideas for how we can effectively handle this.

There used to be an option in the HTML setup called something like "End Tag Required".  If you resurrected that (or maybe it's still there but I can't find it?), it could be a flag such as you describe.

Although, as I think about it, parens highlighting works in HTML files, even if there are unbalanced contained tags, so couldn't the logic that's used for highlighting be used somehow?

[ronburk]

It occurs to me that, in actual practice, there's a set of common HTML tags that virtually always need closing. This suggests it might be fine to just keep a list of such tags, scan backwards until you find such a tag and, if any was found, close it when the user types "</". These are tags like <a>, the font attribute tags (<font>, etc.) etc.

Wouldn't be perfect, but might be acceptable (especially if the main "error" is simply failing to supply any tag closure). Fancier heuristics are possible, but I wonder if that one alone might not be good enough.