On mar, 2002-02-12 at 01:57, Jan Hidders wrote:
From: "Brion Vibber"
<brion(a)pobox.com>
* Nested tables now work.
* == Section headers == at the edges of HTML tags
Do we want this to work? I'd prefer it if we took a conservative stance
towards the mark-up: we don't allow it unless it is needed. This is becuase
once you allow something it will be used, and then it will be hard to
unallow. This might one day become important when we try to optimize the
parser. So I feel we should discuss extensions of mark-up publicly before
implementing them.
The section headers bit was a bugfix to replicate the previous behavior
of of usemodwiki. Not strictly necessary though, I suppose. I'll take it
back out.
Tables are certainly in very active use as it is, and I see no reason to
break nested tables, which at least someone seems sufficiently
interested in to write a bug report about them not working. Nonetheless,
making them work was simply a side effect of my changes to remove the
dangerous scripting attributes, which previous too-simple versions let
pass through.
Now, we *know* we don't want scripting. What *do* we want? Good
question. Here's what was allowed under usemodwiki:
Font effects: b i u font big small sub sup cite code em s strike
strong tt var
Paragraph formatting: br p hr pre center blockquote div
Headings: h1 h2 h3 h4 h5 h6
Lists: ol ul dl li dt dd
Tables: table caption td th tr
all with any attribute you cared to stuff in, including evil JavaScript
tricks. The first version of the PHP script that went online allowed
*everything* except a, script, title, html, body, and header (including
malicious scripting attributes). The next version replicated the
usemodwiki behavior exactly, broken tables and scripting attributes and
all.
Too much? Not enough? For the time being I've trimmed the allowed tags
back to the usemodwiki list (I'd slipped in some additional table tags
and some semantic markup tags that could theoretically be used to help
eg voice-based browsers for the blind render things more clearly), but
I'm sure as heck keeping those scripts out, and I can't imagine why we'd
want to break perfectly well-formed tables.
As always we should strive for correctness and
simplicity. The two go hand
in hand.
Sorry if I sound too critical, but I have strong feelings about this.
Agreed, which is why I'm not entirely happy with my current
implementation of the function, which is too complicated in places. But
the previous one, while relatively simple, was definitely not correct.
-- brion vibber (brion @
pobox.com)