On Mon, Oct 16, 2000 at 11:22:40PM +0100, Matt Sergeant wrote:
> On Mon, 16 Oct 2000, Kaiserovi wrote:
> > Matt:
> >
> > > Second it means that elements with a *null* namespace URI, but that aren't
> > > recognised as a HTML element, should be output as a non-empty element . So,
> > > <foo/> should be output as <foo></foo>, and <foo><bar/></foo> should be
> > > output as <foo><bar></bar></foo>.
> >
> > yeah that's what I took "a non-empty inline element such as span" to
> > mean. but why "such as span", for god's sake? isn't it misleading?
>
> A couple of reasons, probably. The primary one being that its probably
> what the spec writer thought of first :-) But other reasons include that
> it is one of the HTML elements that requires an end tag (lots of HTML tags
> don't), and also that HTML in the future is having a lot of its elements
> removed in favour of <span> + CSS, so they were probably being forward
> looking, being careful that any tag they did list wasn't going to
> disappear from the spec. Having said all that, they do include other HTML
> tags in the spec that may be deprecated in the future, so I'm wildly
> speculating :-)
Speaking of which, what about XHTML output? XML output method doesn't
necessarily put the space in with all tools:
<foo><bar/></foo> => <foo><bar /></foo>
^
to deal with crappy old browsers - but HTML output method produces something
that then has to be run through a HTML to XML converter if you want to
post-process it.
Well - it's something I've hit anyway. My solution (for now) is XML until
the last stage parse, then HTML output method then - controlled by command
line parameters.
--
Bron ( too busy fighting evil client code to write tools at the moment :( )
