Re: SEUL-Leaders: icky html tags

[Cyber Link <cl@txcc.net>]

why not make a perl script that askes the right questions and then sends
the email to us in the right format.. save our group members the trouble..


------------------------------------------------------------------------------
"/" is the beginning "kill" is the end and "kill -HUP" is the reberth. init is 
eturnal truth everlasting.

cl@txcc.net
------------------------------------------------------------------------------

On Thu, 24 Jul 1997, Luka wrote:

> 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
> ----------------------------------------------------------------------------
> 

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