SEUL-Leaders: icky html tags

["Luka@pop3.aracnet.com (Peter)" <luka@mit.edu>]

index:
 1. rambling
 2. rambling
 3. rambling
 4. what's happening
 next letter: revised specs for param parsing

1. rambling about params in general:
now i think i see how it is.  there doesn't seem to be any html tag
that allows arbitrarily named tag parameters.

eg, here is the actual applet tag spec:
<applet code=? [codebase=?] width=? height=?>
<param name=? value=?>
<param name=? value=?>
...
 (text for java-deficient browser)
</applet>

applet accepts code, codebase, width, and height params. period.
and additional params may be supplied via <param> tags, which
accept name and value params.  all very precise.  so the html parser
in all these cases knows exactly what is a param and what isn't
based on the tag.  i wonder if this is a practice we should try to keep?
i also wonder whether html parsers exploit it when doing their jobs.
(i notice the html dtd actually states the params for every tag explicitly too)

2. rambling about params for seul-header:
i'm not sure which way to go with seul-header.  either use seul-header
with a dynamically-defined param list, or have doc-type be the only
"real" param, and have other params specified on <param> lines.

going with <param> tags has the advantage that it's been done already.
but using the dynamic parameter lists may work better for seuldoc.
your input?
i get the increasing feeling that the dynamic param lists actually violate
standard html, though.  but i also get the feeling we're about ready to
ignore that fact, as long as this works.

3. tag params in general
either way, the right way to deal with <tag a = b = c> etc is still
unknown.  but it becomes more important now, since making all the potential
contents of the seul-header params work in the context of html params
is non-trivial.

i think we should just require that seul-tags have some sane parameter format.
eg, <tag p=""> indicates p is null, and <tag p=> is considered broken.
this will not be fully html-compliant, but it will work for us.
the only time we'd care is if someone comes along who knows html better than
us, and insists on writing seuldoc params the way he knows how.  at this
point, we ask him nicely to rewrite the parser for us to be html-compliant. :)
(at which point he will probably either rewrite the parser as requested,
or scream, run away, and continue writing seuldoc the simple way)

the thing is, none of these minor issues will actually break an html viewer
looking at raw seuldoc, b/c it will ignore seul tags, and the stuff being
debated here all disappears then.  (as opposed to the old seul-header format,
which obviously broke completely.)  the only thing this influences is that
a standard html paramlist may break a seuldoc tag, but we need not worry
about that as long as we don't try to say anything like "seuldoc is 100%
html-compliant", which i think would be gratuitous and unnecessary, at
least at this point.  if we end up with a seul team working on html lexer
code sometime in the future, it may be appropriate to let them rewrite seuldoc
at that point, but not today.

4. what's happening:
so unless anyone objects, i will now enumerate a simplified ruleset for parsing
the param values and pass it to roger.

let me know which format we like better for the <seul-header> params...
option 1:
<seul-header doc-type=?>
<param name=? value=?>
...
(text)
</seul-header>

option 2:
<seul-header
 doc-type=?
 foo=?
 bar=?
 ...>
(text)
</seul-header>

-luka
----------------------------------------------------------------------------
Simple End User Linux Leader Mailing list
----------------------------------------------------------------------------