Eric Van Dewoestine wrote:
Is there a particular reason why <xxx/> tags are skipped when using
"at" (:h at)?
The tag-blocks documentation notes that this is by design but offers
no reasoning behind it. For html where the only self closing tags are
usually <p/> or <br/>, I could see how this behavior might be
justified. However given a larger xml tag:
<sometag attr1="one" attr2="two" attr3="three" attr4="four"/>
It would be very helpful if "at" could be used for selection.
Thoughts?
at and it skip not only <xxx/> self-closing tags, they also skip <p> and <li>
when they don't have a corresponding </p> or </li> (<p/> is invalid in HTML),
<meta ... > and <br> even when they aren't ended by />, etc.
The idea is that at "a tag block" needs means to define where a block begins
and ends, i.e., a begin tag and an end tag. A self-closing tag has by
definition no "block of text", no "content" that it could select.
With the cursor within a self-closing tag such as, let's say, <meta
http-equiv="Content-Type" content="text/html; charset=utf-8" />, which is
typical for HTML and not "trivially short", you could select the tag itself
with a<
Outside the span of any tag, you can find the next tag with /<
The only problem is having at select e.g. from within an HTML paragraph,
leftwards to and including the <p> tag, and rightwards to where a </p> tag
ought to be but is missing, e.g. just before the <p> tag for the next
paragraph, or just before a closing tag for an enclosing block-level tag such
as </div>. Such "missing closing tags" are allowed in HTML but not in XHTML;
but having at and it work like that would require a detailed knowledge of HTML
syntax, and I think it is too complex a task for a "simple" command like it or
at .
IMHO it is "the trend of the future", and therefore "good form" to include
</p> at the end of paragraphs, </li> at the end of bulleted or numbered list
items, </td> at the end of table cells, etc., and /> at the end of unpaired
tags. Doing so also solves the problem mentioned in the above paragraph.
Best regards,
Tony.
