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