I had pointed out that using <RENDER ...>
to define new tags would represent a problem
IFF we expected that the HTML language and
all conforming document instances would be
parseable by an SGML parser, even if not
necesarily including a parser in every browser
or server.
Dan and Terry reminded me how one might add new
elements to the DTD, using accepted SGML rules.
And that <RENDER ...> was only intended to be
used to provide some formatting hints to the browser.
Based upon their comments, I assumed that I had
misunderstood the intention of <RENDER ...>.
So, I left it at that.
However, now it seems that Tim thinks that it
will be possible for a document instance
to "encounter a RENDER tag for an undeclared element".
It seems that things are not so clear again.
At least to me?
So, what is the story going to be? I think that
we have to decide and commit right now. Either
we are going to define HTML 2.0 and 3.0 as strictly
conforming SGML DTDs and not provide trivial mechanisms
for extending the language at the whim of information
providers or browser developers, OR we are going to use
SGML as a language of convenience for defining HTML 2.0
and 3.0 and then provide simple but effective ways to
formalize a mechanism for the extension of the language.
As I said in my earlier mail, both approaches have some appeal
and both have some drawbacks. But we can't have our cake
and eat it too.
Comments?
Murray
>
> TBL writes:
> |> | <render tag="COMMENT" style="i">
> |> | <render tag="FUNCTION" style="b,u">
> [...]
> |> Now the remaining question is: what will/should browsers do when they
> |> encounter a RENDER tag for an undeclared element? A good guess might
> |> be to simply assume the syntax is the same as for the EM tag.
> |
> |So are we assuming full DTD parsing is mandatory for all HTML+
> |clients of 3.0+? If so, you are getting quite bogged down in SGML
>
> No, the answer that I gave ("assume the *syntax* of the EM element"),
> was meant to express my intuition that browsers do *not* need to parse
> the DTD. In most (all?) cases the content model for the new elements
> will be a subset of that of the EM element.
>
> |and to think that the rebndering will be defined by simply the
> |EM attributes is simpliistic. To reall describe the rendering,
> |you have to cope with
> |
> [fancy style description omitted]
> |
> |I exagerate but I have found style sheets need more power,
> |and it seems RENDER should hook into style sheet langauge.
>
> I'm not so sure. Style sheets should indeed be able to specify the
> layout in as much detail as your example, but RENDER is perhaps better
> kept as a hint, specifically for use when there is no style sheet.
>
> Style sheets should have only a single point of attachment, probably a
> LINK tag in the HEAD. All other relations between the text and the
> style are given by pointers from the style sheet into the text, and
> never the other way round.
>
>
> Bert
> --
> __________________________________
> / _ Bert Bos <bert@let.rug.nl> |
> () |/ \ Alfa-informatica, |
> \ |\_/ Rijksuniversiteit Groningen |
> \_____/| Postbus 716 |
> | 9700 AS GRONINGEN |
> | Nederland |
> | http://tyr.let.rug.nl/~bert/ |
> \__________________________________|