Laurens Holst wrote:
Paul
Mitchell schreef:
Surely Paul meant for such a <script>
and <style> element to be in their own namespace, e.g.
<xml:script> or <css:style> or whatever…?
Yes and no, I meant the global namespace. Plain old <script> and
<style>, tantamount to reserved words. I would prefer, once and
for all, to make these two elements mean "text intended for browser
presentation" and "text intended for broswer execution", both universal
idioms, and deter anyone from trying to make them mean anything else,
anywhere. Any /other/ use requires a namespace.
Well, that’s a very bad idea then. I frankly can’t even believe you’re
making such a proposal.
Oh dear. Ayes 1, Noes 2. Still, it is early days! If I could be certain
that Anne and Kelly were talking about the same
thing, I would have counted their votes already, but I'm not.
As far as I know, I'm describing how two things have been done in HTML
for a long time, and proposing extending that to XML and all derivative
tagged document formats, no exceptions, forever, as a good idea.
Namespaces exist for a reason, that is to prevent naming conflicts, and
your solution would make life a lot harder for everyone who is using
the ‘global namespace’ (I assume with this you mean the empty
namespace?).
Yes - the empty namespace. The one place where everyone has to agree
with each other for things to work properly, and the very reason
namespaces exist, for the many and various XML applications to avoid
unnecessary conflict in that domain.
Some things are universal, and deserve a special place in the world.
Style and script are universal to browsers, so I just accept that HTML
was right first time, at least in terms of what the respective elements
were called, what they represented, how people understand those things
and how browsers implement them already.
It
will also cause the feature not to be implemented by implementors, in
fear of breaking existing content.
If the standard were something like "unless explicitly specified
otherwise, in all tagged documents, in all contexts, <style> and
<script> elements are browser directives and not
to be considered part of document content", don't you think
implementors everywhere would cheer and get busy adapting,
designing and coding?
It's not a novel concept. <style> and <script> are in-line,
out-of-band data, which are easy to deal with, because once you know to
expect them, you also know whether you can safely ignore them without
detriment to the main signal. Like body language.
--
Paul Mitchell
www.paul-mitchell.me.uk