I've looked carefully at the cost of implementing 1 character
shortrefs in the MATH element as proposed in the HTML 3 DTD, and I can
say with confidence that it's a _lot_ less work than writing a
structured HTML editor.
Remeber: HTML is _cheap technology_. If you _have_ to buy a license to
something to use HTML, we've done something wrong.
>> This is one of thse Dangerous Areas of SGML that is not widely supported,
>> and has, as we have seen, some unintuitive aspects.
>>
>> As HTML gets more sophisticated, the demands on HTML creation and editing
>> software become greater, and the motivation for using them increases.
>> Typing HTML tables and mathematics in vi or xedit or Windows notepad is
>> going to lead to increased sales of alcohol :-)
>>
>> I'd much rather see a simpler language that may be a little more cumbersome,
>> and if there turns out to be a need to provide shortcuts, add them later.
>
>I agree with Lee. As I've mentioned to Dave, I'm somewhat concerned about
>creating yet another math DTD fragment when choices like AAP and ISO 12083
>exist, but I'm even more concerned with using, as Lee puts it, the murkier
>aspects of SGML to theoretically make it "easier" for people to create
>HTML in vi. Maybe it is a reasonable goal to continue to make it feasible
>to edit textual HTML with vi, but as you add tables and math and other
>complex constructs, that goal become infeasible. And delving into more
>complex markup minimization to reduce keystrokes does not guarantee that
>you make it easier for people to understand how to code it correctly.
>
>I'm quite sure the trend will be toward user-friendly tools to create
>the more complex HTML constructs such as complex equations [of course,
>I would be, wouldn't I], and I don't see the advantage of complicating
>the language and parsers to save a few keystrokes.