Re: [dev] [sw] Suckless web-framework

On Mon, Apr 5, 2010 at 6:34 PM, Charlie Kester <corky1951_AT_comcast.net> wrote:
> On Mon 05 Apr 2010 at 08:29:24 PDT Connor Lane Smith wrote:
>>
>> On 5 April 2010 15:13, Uriel <lost.goblin_AT_gmail.com> wrote:
>>>
>>> Actually, modern browsers parse HTML much faster than XHTML (yes, I
>>> was fooled by the XML scam once too, and it was not until recently
>>> that I discovered even the myth of it making parsing of webpages
>>> faster was totally bunk).
>>
>> My point was not that we should write XHTML, but that we should write
>> simple HTML, and that simple does not solely mean "fewer characters".
>> (Nor does it solely mean "efficiency". I have a dog on my shelf
>> telling me: simplicity, clarity, generality.) I was considering from
>> the point of view of the author of a new, say, htmlfmt. To quote,
>>
>> On Mon, Apr 5, 2010 at 1:38 PM, Connor Lane Smith <cls_AT_lubutu.com> wrote:
>>>
>>> I'm not even sure how "fewer characters" equates as "simpler": LOC is
>>> only an approximation of how suckless our code is. When given a
>>> trade-off between two simple lines or one complex one, write two. A
>>> paragraph makes sense as <p>text</p>: it opens, it closes. Quotes are
>>> nice too. I'm not saying it should validate as XHTML, but simplicity
>>> is more profound than wc.
>
> While pondering the import of your message, and thinking about how
> ordinary language uses quotation marks to both open and close a quote,
> it struck me that my email client was giving me an elegant example of
> how the need for a closing tag can be eliminated.  See how the '>'
> character is used?

Regardless of the strengths and weaknesses of HTML, the '>' style has
it's own problems. Firstly, unless you've got an editor programmed for
the syntax it means you can't cut and paste just the "content" of a
quoted region. Secondly, don't forget that you've got to figure out
how to "allow" literal '>' characters at the start of a line if you
want it to be able to work with absolutely any data someone wants to
display in there (such as >>>>>>>>>>>>>>>>>8 visual cut markers).

> As for paragraphs, separating them with blank lines always made more
> sense to me than <p> tags, and here again, no closing tag is required.

Of course, if there are other reasons why one might want to have
elements within a "semantic paragraph" which are one separated lines
then one needs to come up with a syntax for having visual blank lines
which aren't (as witnessed by the use of "comment blank lines" in
TeX/LaTeX:

preceding paragraph

start of paragraph content
%
$$displayedEqn$$
%
end of paragraph content

following paragraph

, which again spoils the simplicity. And note how I've just used some
blank lines in order to present an example within what is semantically
one paragraph). None of this is to say that a different markup
mechanism than HTML might work better, but it's easy to have an
initially simple proposal that suddenly sprouts a lot of complexity
when you add mechanisms for corner cases.

Personally, the ONE, SINGLE thing XML (and specialisations) had going
for it was that, for all it's annoyances, it was hoped to be dominant
enough that you only had to learn techniques, common bugs and
libraries for one syntax. Unfortunately the multiple ideas about how
to do a "better" markup language mean that that even that advantage
has gone.

-- 
cheers, dave tweed__________________________
computer vision reasearcher: david.tweed_AT_gmail.com
"while having code so boring anyone can maintain it, use Python." --
attempted insult seen on slashdot