[whatwg] Ongoing work on an editing commands (execCommand()) specification

[Brett Zamir]

On 3/4/2011 3:53 AM, Aryeh Gregor wrote:
> On Wed, Mar 2, 2011 at 8:27 PM, Brett Zamir<brettz9 at yahoo.com>  wrote:
>> In any case, spans with inline styles are much less likely to conflict with
>> other styling
> I'm not sure what you mean by this.  Functionally, in what way is
> <span style="font-style: italic">  less likely to conflict with other
> styling than<i>, for instance?  Possibly some authors do things like
> i { color: green }, but they might do the same for span as well --
> either seems equally unlikely to me.
>
Since span is meant to be a generic container with no inherent meaning 
or formatting of its own (except being understood as being of inline 
display), formatting a span without reference to class would be a pretty 
broad stroke to paint, whereas styling an <i> (or <em>) would be 
reasonably targeted. The only problem is that the advantages for styling 
specificity which formatting tags offer are the same reasons why they 
will more likely conflict when placed in another document. I think the 
nicest solution would be <span class="italic" 
style="font-style:italic;">, but I don't know that the need to export 
contents for external style usage is one worth complicating the markup 
even further for everyone using it.

>> If one wishes to allow convenient export of the internally generated mark-up
>> for the sake of the user (e.g., to allow them to copy the markup for use on
>> their own site), it is nice for there to be choice at least between
>> non-formatting-committal (semantic) markup and non-semantically-committal
>> (formatted) mark-up
> The commands we have are clearly presentational.  E.g., we have an
> "italic" command, and don't have "emphasize" or "citation" or
> "variable" commands.  If there were demand for it, semantic commands
> could be added, but currently I'm assuming the use-case is only
> presentational markup.  If someone would like to argue that there's
> substantial author demand or implementer interest in adding semantic
> commands, we could do that, but they'd have to be separate features,
> and we'd still have to deal with the commands that are presentational
> only.
Personally, I'm not sure why there needs to be the redundant API with 
insertHTML in the first place, if insertHTML can be standardized (maybe 
with a removeHTML to target specific inserted tags?), so I don't see a 
need for adding the semantic ones on top of that.

> On Thu, Mar 3, 2011 at 12:51 AM, Roland Steiner
> <rolandsteiner at google.com>  wrote:
>
>> Paraphrasing Julie's point
>> from our original exchange: you want to be consistent to make it easy to
>> hand-edit the resultant HTML (by the user, say), or for server-side
>> post-processing. For these purposes pure markup is often easier. OTOH, in
>> general, styles are more powerful.
> I get the hand-editing argument.<b>  is much nicer to hand-edit than
> <span style="font-weight: bold">, and also fewer bytes.  But why would
> anyone want<span style="font-weight: bold">?  Styles are more
> powerful in general, but that's not a reason to prefer them in the
> specific cases where they aren't more powerful.

In relation to <strong>, the reason is simply to avoid committing that 
the usage of bold is for <strong> text. What is the practical use of 
using <strong/>? Besides possible clarity in code, for richly semantic 
documents, akin to the detailed level of markup present in TEI documents 
used for marking up classical texts and the like, a browser user (or 
programmer) can shape XQueries (or jQueries)--directly or by a 
user-friendly wrapping GUI--which selectively extract that information.

If one wishes to find all passages in a work of Shakespeare where there 
was indication in the original that there should be strong emphasis, one 
can make a single elegant (and semantic) query which grabs that 
information, while silently ignoring the <span 
style="font-weight:bold;"> (or <b>) tags which were instead used to 
provide styling of say unmeaningful but bolded text in say the imprint 
or wherever. (The reason to use span over <b>, on the other hand, is 
simply to avoid the tag being at least semantically unamenable to 
alteration by the designer given its always being assumed to be tied to 
boldness by its use of "b". )

Granted, a user or application might actually wish to search for text of 
a particular formatting rather than a particular meaning, but if they 
are not distinguished, only the former is possible.

Brett