# intertwingly

It’s just data

### Design By Attrition

Dave Orchard: I still have hopes that the HTML5 working group would listen to Sam Ruby and the TAG and add namespaces in HTML5.  Maybe MSFT’s features will prompt the group to start working on namespaces.

Indirectly, and when there are fewer good options to choose from, it eventually will happen.  But not because the HTML5 working group picks up this effort.

That WHATWG has consistently made it abundantly clear that the W3C is but one of many sources of input for HTML5.  What IE actually implements is another source.  Both clearly view namespace support as important.  Yet the WHATWG seems to assign no urgency to this issue.  The prevailing attitude is one of YAGNI.

So when will it happen?  When there is demand for it.  And, by that time, customers will have coded to IE’s quirks.  Quirks that will allow some demos of competing standards to work, but will cripple others.  At that time, the seductive calls of Don’t Break The Web will again be heard.

The WHATWG needs a Pastor Niemöller.

## Fri 07 Mar 2008

rubix.home? ;)

Posted by Jeff Schiller at

Ooopsie.  Fixed.  Thanks!

Posted by Sam Ruby at

“Cripple” still points to a rubix.home URL :)

Posted by Dave at

What’s your thought? That if we specify something now, in a rush, Microsoft will have implemented it by the time Internet Explorer 8 ships potentially breaking with the way they have done namespaces in HTML since IE 5.x or so? Given that their HTML DOM still has this “incest policy” (and various other major issues that have been there since IE 5.x or so) it seems unlikely to me they will change much there.

Also, unless you know some magic will happen and we get an SVG plugin that magically spreads across users around the globe, I wonder why you think this will have much impact. (More impact than namespace support in their HTML parser had so far, that is.)

Posted by Anne van Kesteren at

Also, unless you know some magic will happen and we get an SVG plugin that magically spreads across users around the globe,

Y’mean, like the Flash plugin?

I wonder why you think this will have much impact. (More impact than namespace support in their HTML parser had so far, that is.)

Is namespace support in their parser what allows the MathPlayer Plugin to work? (I assume what’s going on is a little more complicated, because you need to send the page as `application/xhtml+xml` to trigger the plugin.)

Posted by Jacques Distler at

Dave: fixed.  Thanks!

That if we specify something now, in a rush

Bingo. You have succinctly captured exactly why the fact that the WHATWG has been ignoring this issue for so long will inevitably cause considerable damage.

Posted by Sam Ruby at

FWIW, I have been consistently favorable to enabling SVG and MathML (even if not necessarily namespaces in general) in `text/html`. I have even posted a relatively concrete proposal.

However, as far as scheduling goes, I thought Firefox 3, Opera 9.5 and Safari.next were a generation that couldn’t make it anyway, so I thought it wouldn’t hurt to wait 6 months or so. I really didn’t see it coming that Microsoft would change their non-standard namespaces in `text/html` implementation to another non-standard thing without even trying to float the idea in the HTML WG first.

Posted by Henri Sivonen at

I really didn’t see it coming that Microsoft would change their non-standard namespaces in `text/html` implementation to another `non-standard` thing without even trying to float the idea in the HTML WG first.

Two things:

• If proposals and encouragement by myself and the TAG are ignored, what chances do you think Microsoft would have?  Yes, they are different, they are an implementer.  But they are also different, they are Microsoft.  With all the baggage that that label incurs.
• As long as the WHATWG’s position is that the W3C is merely but one of many inputs to the HTML5 specification, I wouldn’t be so casually throwing around the term non-standard.  As a substitute, I would suggest developed in a non-open manner.

Question: do you think that Microsoft is implementing this in the hopes that it might be used?  If history is any guide, Microsoft has concrete and specific use cases in mind.  Ones that they have validated with customers.  And ones that Microsoft intends to support, not just in the browser, but with tools.  Customers + tools = content.  Lots of content.  Content that other browsers will want to support.  Which rounds back to the point I made at the top of this post: make no mistake about it, it will make it into the HTML5 specification.  Perhaps later and rushed.  Or sooner and more carefully thought out.

Posted by Sam Ruby at

So you seem to be saying that because it is not in the specification we are not thinking about it. I think that’s a false statement. It is something, as you say, that has to be carefully thought out.

Posted by Anne van Kesteren at

So you seem to be saying that because it is not in the specification we are not thinking about it. I think that’s a false statement.

Yes, it is a false statement that I “seem to be saying that because it is not in the specification we are not thinking about it”.  That would be putting words in my mouth.  To do so would be somewhat rude.

The response to the TAG request was deafening silence.  That is an indication that “we” are not thinking about it.

Now, ponder for a moment, on your use of pronouns.

Posted by Sam Ruby at

What should we reply other than saying we don’t have an answer yet? We can’t just copy the XML syntax for compatibility reasons and we can’t just do what IE does without copying a large bunch of quirks. There’s a lot of questions to answer that require research and thought.

You also still haven’t answered my initial questions on why this would suddenly be adopted on a large scale. It hasn’t happened in the past ten years while IE was dominating. (Now I’m not saying here that we shouldn’t look at it, obviously we should, and are, but I’m just wondering why you think it’s suddenly different.)

Posted by Anne van Kesteren at

What should we reply other than saying we don’t have an answer yet? We can’t just copy the XML syntax for compatibility reasons and we can’t just do what IE does without copying a large bunch of quirks. There’s a lot of questions to answer that require research and thought.

I think you answered your own question there.  “We” can ask questions and do research and report on the results of that research.  In fact, some of “us” have.

You also still haven’t answered my initial questions on why this would suddenly be adopted on a large scale.

Did I say “suddenly"?  I thought I said "eventually”.

Posted by Sam Ruby at

It’s not clear to me that there is significant agreement on what the requirements here are. For example it would be simpler for compatibility to have something that looks distinctly unlike the xmlns syntax. As a positive sideffect, we might manage to design something that is significantly less hard to understand and author.

Also, it would be nice if proposals came with testcases so that their behaviour in extant systems could be easilly examined.

Posted by jgraham at

It’s not clear to me that there is significant agreement on what the requirements here are. For example it would be simpler for compatibility to have something that looks distinctly unlike the xmlns syntax. As a positive sideffect, we might manage to design something that is significantly less hard to understand and author.

Ah, yes.  The the “ignore the concrete proposals that have been made to date and propose something vague” approach.  Sorry if I seem snippy, but it is hard to compare and contrast something concrete and existing to, well, um, “something”.

Also, it would be nice if proposals came with testcases so that their behaviour in extant systems could be easilly examined.

I would like to see this page presented properly when served using a MIME type of `text/html`.  If that isn’t possible, I would like to see a list of changes that would need to be made to the body of that page to make it work.

Posted by Sam Ruby at

I still don’t quite get it.

What is the concrete proposal? I assume with existing you refer to what Internet Explorer does? Apart from the fact that I’m unsure if what IE does is desirable, I’m not sure if it can be implemented by other browsers given the DOM differences (IE has a non-XML DOM) that some sites rely on.

Also, what will eventually drive adoption of this on large scale if other browsers do nothing? It hasn’t happened when IE had more than 90% of the market so why would it happen when it has less?

I do think that using SVG and MathML without `data:` URIs in HTML would be extremely cool and that we should have that possibility, but I don’t see how “flaming” the WHATWG will help to achieve that goal.

Posted by Anne van Kesteren at

I would like to see this page presented properly when served using a MIME type of text/html

That’s more a suggested requirement than a testcase.

I had in mind small testcases that each cover single syntactic features used in your proposal, so it is trivial to examine how they behave in existing tools.

Posted by jgraham at

I still don’t quite get it.

Evidently.

What is the concrete proposal?

what will eventually drive adoption of this on large scale if other browsers do nothing?

I don’t see how “flaming” the WHATWG will help to achieve that goal.

Please point out the “flame” to which you refer.

I had in mind small testcases that each cover single syntactic features used in your proposal

Is the following small enough?

$Rank-2 Symmetric Tensor Representation \otimes Fundamental Representation = Adjoint Representation \oplus Rank-3 Symmetric Tensor Representation$
Posted by Sam Ruby at

Sam, here’s a suggestion - put a couple concrete examples into your proposal to make it absolutely clear what you’re proposing.  Someone who’s skimming the document will not get the gist.

Posted by Jeff Schiller at

I read those links. I don’t understand why demand for SilverLight means demand for namespaced HTML. Two of the three demand links (in the demand post) seemed to be about video on the Web. Video on the Web is indeed dominated by proprietary players and hopefully in due course the alternative to that will be good enough, but I don’t see the relation with namespaced HTML.

I also don’t think the proposal is “concrete”. Given that existing pages, as I said already, use such syntax already and expect user agents to behave in a certain way it’s not at all clear that this can be implemented. There are also lots of open questions there.

Now I suppose this may sound as “just say no”, but I’m still thinking about it and hope that sharing my thoughts helps a bit.

Posted by Anne van Kesteren at

Jeff: here’s a suggestion - put a couple concrete examples into your proposal

That’s a valid suggestion.  If I thought there was any chance that it would result in the proposal getting adopted or even more widely discussed, I would certainly pursue it.  Meanwhile, I have a single page and a single line use case that I have cited and included above.  Both are very semantically rich.  Saying that such must be accepted without modification would clearly be unreasonable.  But I have said that I’m open to alternative suggestions.

Anne: I’m still thinking about it

In the end, that’s all I can ask for.

Posted by Sam Ruby at

I don’t think there’s much point in getting upset about it now. It’s too late. By the time anyone has any idea what to put in HTML5, It’ll just be a reverse-engineering of IE’s implementation of it just as has been done with HTML5 so far. HTML5 might as well just be called “How the previous version of Internet Explorer interpreted HTML”.

Posted by Martin Atkins at

As an additional requirement, I’d like this and this to work the same, so that e.g. scripted SVG would work the same in any serialisation — it would be quite confusing if HTML copied the XML namespace syntax but not the XML DOM API.

I don’t believe I’ve seen a proposal that covers that issue yet. I’m not sure how to avoid requiring at least one browser to break compatibility with content that assumes the current handling of colons in names — I’d be happy if there was a good solution that doesn’t involve simply avoiding colons, but I haven’t had any ideas so far.

Posted by Philip Taylor at

Sam,

Forgive me, it’s possible I misunderstood your proposal.  I thought your proposal meant that all ‘foreign’ namespace elements and attributes had to have a prefix: on them and that the namespace prefix must be on an enclosing element.

Neither Jacques' page nor your one-line example include a prefix on the [itex] elements... also the xmlns:svg="http://www.w3.org/2000/svg" appears on the <svg:svg/> element itself - is that considered an “enclosing scope"?

Sam: "Saying that such must be accepted without modification would clearly be unreasonable.”

I didn’t understand this again, sorry.  Must be because it’s Friday.

Anne: “Given that existing pages, as I said already, use such syntax already and expect user agents to behave in a certain way it’s not at all clear that this can be implemented”

Can we just get one or two examples of text/html pages that use “such” syntax?

Thanks,
Jeff

Posted by Jeff Schiller at

Is the following small enough?

FWIW I had in mind something significantly more like Philip’s testcase - a minimal example that focuses on the handling of a single piece of the proposed syntax in existing browsers, to determine what can be made to work and what cannot.

Posted by jgraham at

Can we just get one or two examples of text/html pages that use “such” syntax?

This is one which appears to do quite a bit of namespace processing. (Somewhat relatedly, this is interesting to read.)

Posted by Philip Taylor at

Jeff:

I didn’t understand this again, sorry

Both cases are me being sloppy.

Another way to express what I desire: if you take that full page of Jacques' and read it using an XML parser, you get a DOM.  What I would like HTML5 to provide is a serialization for that DOM that, when parsed by an HTML5 parser, produced the same DOM as the XML parser did.

While that serialization may differ from the one that I specified, and in fact may differ from one that XML parsers will accept, what I really want is the ability to round-trip the DOM using a HTML5 syntax.

- Sam Ruby

Posted by Sam Ruby at

“The WHATWG needs a Pastor Niemöller.”

Consider “hearts and minds” as a preferable strategy.

Posted by Bill de hOra at

As I said last time you complained about this, namespaced content in HTML is not a high priority, and complaining about it won’t make it happen faster. (If anything, it’ll make me want to avoid the subject for longer, since I’ll have negative associations with it.) What we need is:

• A detailed list of use cases and use scenarios detailing what we want to handle. Just saying “extensibility” isn’t nearly enough, because there are many kinds of interoperability and we have to pick the appropriate model for the kinds of extensibility that we want to handle.
• A detailed examination of each use case to establish requirements for each one, and to establish whether the use cases are things we actually want to address (e.g. do we really want to allow mixing pure presentational, media-specific, non-accessible or only-theoretically-accessible languages like Presentational MathML, XSLFO or SVG into text/html?).
• A list of explicit non-goals, for example what we can learn from XML Namespaces (e.g. that prefixes are bad), and what we may not need to do (e.g. do we need to be syntax compatible with XML namespaces? Do we need to actually support arbitrary namespaces, or can we satisfy all our use cases by providing explicit support for a finite set of elements?).
• A study of what our constraints are given the existing parsing quirks (e.g. our inability to use the ‘xmlns’ attribute due to the conflict with IE’s wacky parsing).
• A serious consideration of whether we actually want to do any of this, given that it would basically remove the only remaining reason to use XML on the Web, and would thus likely kill XML for good in this ecosystem.

We had an e-mail thread about this many months ago where I basically said all this, back when I was actually trying to work on this. You never replied, so I’m still waiting for your use cases.

Posted by Ian Hickson at

namespaced content in HTML is not a high priority

Thank you for the confirmation.

Posted by Sam Ruby at

My pleasure, sorry if it wasn’t clear before.

Posted by Ian Hickson at

## Sat 08 Mar 2008

Ian Hickson said

non-accessible or only-theoretically-accessible languages like Presentational MathML

Could you please explain what the heck you mean by that?

I, for one, would like to understand your reasoning.

it would basically remove the only remaining reason to use XML on the Web, and would thus likely kill XML for good in this ecosystem.

And that would be bad because ...?

Posted by Jacques Distler at

WHATWG needs a public issues list, instead of Ian’s email program. That way, everyone can see what’s going on, and what feedback led to which change.

In this case, I’m not sure where or who those bullet points came from. Trac seems to be working for the HTTP WG.

Posted by Robert Sayre at

Sam Ruby wrote:

If proposals and encouragement by myself and the TAG are ignored, what chances do you think Microsoft would have?  Yes, they are different, they are an implementer.  But they are also different, they are Microsoft.  With all the baggage that that label incurs.

A TAG endorsement does not get an idea fast-tracked into HTML5. The TAG and the #whatwg regulars disagree on things.

The problem with your proposal was that it was pitched as a general distributed extensibility mechanism as opposed to a mechanism for enabling SVG (and MathML) in `text/html`. SVG is already a part of the interoperable Web platform implemented in Gecko, Opera and WebKit, but SVG is being held back by the requirement to go XML. Distributed extensibility, that is extensibility without cooperation on a mailing list overseen by Hixie or Tantek, can be seen as being bad for interop—something that leads to Babelization.

And yes, I do think people would have paid attention to Microsoft, since they are an implementor, if Microsoft had sent feedback to the HTML WG stating the desire to enable SVG and MathML in `text/html`. (Enabling Silverlight might not have been as popular a proposition.)

As long as the WHATWG’s position is that the W3C is merely but one of many inputs to the HTML5 specification, I wouldn’t be so casually throwing around the term non-standard.  As a substitute, I would suggest developed in a non-open manner.

OK.

Question: do you think that Microsoft is implementing this in the hopes that it might be used?

I rather not speculate on Microsoft’s motivation.

make no mistake about it, it will make it into the HTML5 specification.  Perhaps later and rushed.  Or sooner and more carefully thought out.

I agree. Like I said, I didn’t see this move by Microsoft coming. When this was discussed in the  HTML WG, no one from Microsoft bothered to participate in the thread mentioning that they were implementing this in IE8. I thought they’d keep their old namespace behavior. Indeed given what we know now, it would have been better to figure this out in the HTML 5 spec before Microsoft started implementing what they are implementing.

Martin Atkins wrote:

I don’t think there’s much point in getting upset about it now. It’s too late. By the time anyone has any idea what to put in HTML5, It’ll just be a reverse-engineering of IE’s implementation of it just as has been done with HTML5 so far.

The implementation in IE8 will certainly be a constraint now.

Hixie wrote:

A detailed examination of each use case to establish requirements for each one, and to establish whether the use cases are things we actually want to address (e.g. do we really want to allow mixing pure presentational, media-specific, non-accessible or only-theoretically-accessible languages like Presentational MathML, XSLFO or SVG into text/html?).

Presentationl MathML? Yes. XSL-FO? No. SVG? Yes.

Posted by Henri Sivonen at

Jacques: Heuristics that convert a presentational language to a passable speech rendering are common; indeed that’s how much of the Web is handled by speech browsers. That doesn’t make it a good design, nor one that we should advocate. (It also doesn’t automatically make it a bad design, the whole point is that this is something we have to make an educated decision about.)

Jacques: I didn’t say removing XML would be a bad thing. I said it was something we should consider carefully. I assure you many people do think it’s a bad thing.

Robert: The WHATWG issues list is at [link] and the HTMLWG issues list is at [link] — these are the mechanisms I use to track issues in HTML5. Both are very open; indeed the WHATWG one even has two public APIs, and at least one person has built an independent tool that interfaces with it.

Posted by Ian Hickson at

In this case, I’m not sure where or who those bullet points came from.

Me either.

The problem with your proposal was that it was pitched as a general distributed extensibility mechanism as opposed to a mechanism for enabling SVG (and MathML) in text/html... that is extensibility without cooperation on a mailing list overseen by Hixie or Tantek

Note that Ian said “use cases are things we actually want to address” (emphasis added).  First one has to ponder who we are, and consider the possibility that there may at times be requirements that are valid but don’t meet that bar.  While I am no fan of Microsoft or IE, I am developing a bit of empathy for people who do not want to play by those rules.

Posted by Sam Ruby at

Jacques: Heuristics that convert a presentational language to a passable speech rendering are common; indeed that’s how much of the Web is handled by speech browsers. That doesn’t make it a good design, nor one that we should advocate. (It also doesn’t automatically make it a bad design, the whole point is that this is something we have to make an educated decision about.)

And your “educated decision” will be based on what, exactly?

I gather (from discussions with the folks who actually implement this stuff) that all current work on mathematical AT (whether math→speech, math→braille, ...) is based on MathML.

You can dismissively wave your hand and say that all existing implementations are instances of “bad design.” But I don’t see you (or anyone else) proposing a ‘better’ design, much less building an implementation.

Jacques: I didn’t say removing XML would be a bad thing. I said it was something we should consider carefully. I assure you many people do think it’s a bad thing.

I’m sorry. That makes no sense whatsoever.

You are not “removing XML.” You are removing a particular use-case from the exclusive preserve of XML.

If that makes using XML in this ecosystem less compelling, so what? “Many people” will still find it compelling. Those, who no longer do, will hardly have cause to complain.

Saying that making HTML5 a more versatile serialization format will upset people, and that therefore “we” have to tread carefully, is the kind of dubious evidence-free assertion you would dismiss if it were made by others.

Posted by Jacques Distler at

It’s unfortunate that rather than work together based on the surprised of Microsoft’s IE8 release last week, the web design and development community is torn apart--both before the release of IE8 with that absurd meta tag, and after with the evidence of Microsoft’s “innovations”. Including the namespace change.

It’s unfortunate because unless we want to just give up and have Microsoft control the direction of web page design and development from this moment on, we need to work together. However, rather than work together, the community is fracturing along old lines of contention. Why don’t we just give it all over to Blue and give up, eh?

Ian/Anne, I’ve seen some good suggestions from folk in this thread about ways to ensure better visibility into the HTML5 effort, especially related to issues where there’s disagreement. I think you should consider improving on this. I’m sure you have people with organizational skills already in your group. If not, I’ll volunteer to help pull something together. I don’t necessarily have any irons in any fire, other than no, I don’t want XHTML to go away. Yes, I do want SVG. However, I don’t think this is necessarily an item of contention.

As for being forced to reverse engineer Microsoft’s IE namespaces just because its first--I think this is also absurd. If it’s a good idea, then sure. If not, then no. Microsoft specifically put this out as a challenge to the viability of the group, as well as a way of undercutting the ground underneath XHTML/SVG/MathML while it troops off doing its own thing. Personally, I’d rather offended if they were rewarded for such efforts, just because they acted unilaterally.

You know, acting unilaterally in this country usually has bad consequences.

Jacques, I want XHTML. I want XHTML because I know at a glance if I’m putting crap into my page. Though the tool support currently sucks, I want it. Best of all, we have it now. I would hate to see us lose it just because we’re currently facing a rough patch. Every time I toss a little SVG into one of my pages, it makes up for all the illegal unicode characters. So, I hope you’ll forgive me for continuing to want this.

“ While I am no fan of Microsoft or IE, I am developing a bit of empathy for people who do not want to play by those rules.”

There’s not playing by the rules and there’s acting without honor and integrity in furthering one’s own selfish gains. You should note the difference, Sam, in Microsoft’s recent activities.

Ian/Anne if you want my help, send me an email.

Posted by Shelley at

Jacques, I want XHTML. I want XHTML because I know at a glance if I’m putting crap into my page.

Perfectly fine, Shelley. For you, de-crapification is a compelling use-case. Long may you continue to use XML for that purpose.

For myself, I have content that I wish to convey (for the WhatWG folks, 'I have a DOM I wish to serialize.'). I could give a rat’s ass about any particular serialization format. But right now, there’s only one option available to me.

If there were another serialization format, one that did not require me to fill my brain with mind-numbing useless trivia, in order to use it, I, for one, would find that attractive.

Henri said:

I didn’t see this move by Microsoft coming. When this was discussed in the  HTML WG, no one from Microsoft bothered to participate in the thread mentioning that they were implementing this in IE8.

Perhaps because they had the impression that those discussions weren’t going anywhere.

Rather than hold back their own implementation, indefinitely, in the hope that the HTMLWG would, someday, turn its attention to boiling the ocean, they decided to proceed on their own.

Posted by Jacques Distler at

Ian: that looks pretty thin. For instance, I clicked on the “sql” entry, and I can’t find who added the feature, and who supported it.

Posted by Robert Sayre at

Oh, and one more thing.

Implicit in Ian’s previous comment is the assertion that the example quoted by Sam above is insufficiently semantic to be worthy of inclusion in `'text/html'`.

Leaving aside the humour inherent in trying to maintain the semantic purity of `'text/html'`, I would like to hear what a sufficiently semantic markup (one worthy of inclusion in `'text/html'`) of the above equation would look like.

To ease the comparison, here’s the markup (with the perculiar Namespacing conventions required by the W3C’s XHTML+MathML+SVG profile) used to create that example

```<math xmlns="http://www.w3.org/1998/Math/MathML" display="inline">
<semantics><annotation-xml encoding="SVG1.1">
<svg:svg xmlns:svg="http://www.w3.org/2000/svg" width="1.875em" height="1em" viewBox="0 0 30 16">
<svg:desc>Rank-2 Symmetric Tensor Representation</svg:desc>
<svg:g transform="translate(5, 5)" fill="#FCC" stroke="#000" stroke-width="2">
<svg:rect width="10" height="10"/>
<svg:rect width="10" height="10" x="10"/>
</svg:g>
</svg:svg>
</annotation-xml></semantics>
<mo>⊗</mo>
<semantics><annotation-xml encoding="SVG1.1">
<svg:svg xmlns:svg="http://www.w3.org/2000/svg" width="1.875em" height="1em" viewBox="0 0 30 16">
<svg:desc>Fundamental Representation</svg:desc>
<svg:g transform="translate(5, 5)" fill="#FCC" stroke="#000" stroke-width="2">
<svg:rect width="10" height="10"/>
</svg:g>
</svg:svg>
</annotation-xml></semantics>
<mo>=</mo>
<semantics><annotation-xml encoding="SVG1.1">
<svg:svg xmlns:svg="http://www.w3.org/2000/svg" width="1.875em" height="1.625em" viewBox="0 0 30 26">
<svg:g transform="translate(5, 5)" fill="#FCC" stroke="#000" stroke-width="2">
<svg:rect width="10" height="10"/>
<svg:rect width="10" height="10" x="10"/>
<svg:rect width="10" height="10" y="10"/>
</svg:g>
</svg:svg>
</annotation-xml></semantics>
<mo>⊕</mo>
<semantics><annotation-xml encoding="SVG1.1">
<svg:svg xmlns:svg="http://www.w3.org/2000/svg" width="2.5em" height="1em" viewBox="0 0 40 16">
<svg:desc>Rank-3 Symmetric Tensor Representation</svg:desc>
<svg:g transform="translate(5, 5)" fill="#FCC" stroke="#000" stroke-width="2">
<svg:rect width="10" height="10"/>
<svg:rect width="10" height="10" x="10"/>
<svg:rect width="10" height="10" x="20"/>
</svg:g>
</svg:svg>
</annotation-xml></semantics>
[/itex]```

Posted by Jacques Distler at

The bullet points come from me, when I wrote that blog comment... I’m just trying to help explain what we need to move forward. This isn’t anything particular to this issue; data gathering and informed decisions are how all aspects of HTML5 are being designed. By “we” I meant “the Web community” — that is, everyone.

Jacques: All educated decisions are made based on data gathered through research, studies, brainstorming, discussions, etc.

I’m not saying MathML is a bad design. I’m not saying it’s a good design. I’m saying something that should be blatently obvious to anyone doing spec development, or indeed any kind of development, which is that we don’t just design specs blindly without carefully considering all options.

I’m not trying to assert anything — indeed, if you think from reading these comments that I have a firm opinion on any of this issue, then you are missing my point entirely.

Some people are against HTML5 as a whole because it makes XHTML redundant. Some people are against it as a whole because it competes with XHTML2. In both of these cases we carefully considered what we were doing before moving forward. Here again, some people are against adding namespace support to text/html because it can make XML irrelevant on the Web. We should carefully consider what we’re doing before moving forward. That doesn’t mean we shouldn’t do it, it means exactly what I’m saying — that it should be considered carefully, with all the facts and opinions on the table. Right now, on this issue, we are missing the basic information we need to make the decision.

Robert: It’s the issue tracking database, it doesn’t track who was in support of what. (Indeed, I actually actively strip information about who proposed what, so as to not be biased by the source of ideas). If you would like something else, please feel free to join in and build whatever tools you think would help — I can provide you with any documentation you need, e.g. for the APIs to the database.

Jacques: And what does that example look like in Lynx? (As a heavy Lynx user, I care.)

Posted by Ian Hickson at

As I said last time you complained about this, namespaced content in HTML is not a high priority

I don’t like it when you make these types of statements, because it sounds like you’re setting the requirements of the spec, which you certainly do not.

If you would like something else, please feel free to join in and build whatever tools

I am not making a tools complaint. It looks like what you have will do fine. I am complaining that I don’t know why the SQL API was added to the document.

Posted by Robert Sayre at

I spoke to my partner about this and they suggested that maybe you think I’m feigning lack of opinion as a subtle way of disagreeing with the idea. Just for the record, I’m not subtle when I disagree with something. If I was against adding namespaces to text/html, there would be absolutely no doubt. I’d have dismissed the entire thing long ago. There wouldn’t be hundreds of e-mails of feedback on the topic sitting in the WHATWG issues list. I wouldn’t be asking for use cases, or talking about making decisions. I’d be listing all the reasons for the idea to be dismissed.

Posted by Ian Hickson at

“Perfectly fine, Shelley. For you, de-crapification is a compelling use-case. Long may you continue to use XML for that purpose.

For myself, I have content that I wish to convey (for the WhatWG folks, 'I have a DOM I wish to serialize.'). I could give a rat’s ass about any particular serialization format. But right now, there’s only one option available to me.

If there were another serialization format, one that did not require me to fill my brain with mind-numbing useless trivia, in order to use it, I, for one, would find that attractive.”

And the reason you’re getting caught up in the serialization format is because the tool you’re using doesn’t support XHTML, SVG, or MathML. In other words, if you don’t care about XHTML, you shouldn’t care if support for namespaces is added to HTML5. What you need is for tools to actually do whatever serialization format, HTML5, XHTML1.1, or XHTML5, correctly.

Am I reading what you’ve said accurately?

As for HTML5 making XHTML redundant, my understanding is that HTML5 is also XHTML5, so there is no redundancy. However, it would make more sense for their to be only one XHTML going forward and that it be compatible with HTML5. The W3C has left this all in a real mess, with a lot of confusion. This does not move us forward.

Out of curiousity, I have a general question to add to this thread: who among those reading this thread helped Microsoft design and/or implement their namespace solution?

Posted by Shelley at

Robert: SQL was added because of demand from browser vendors (including your employer) and from developers of big Web applications looking for ways to support offline access. I pushed against SQL in HTML for literally over a year, but people basically told me that either I specced something, or they would do their own thing without a spec. Interoperability is my primary goal, so I went the pragmatic route and defined an API for the various vendors to implement. (It shouldn’t be in HTML5. Hopefully when we can find someone to edit it we can take it out — though the dependencies on the browsing context definitions make it hard to really split out cleanly.)

Posted by Ian Hickson at

Jacques: And what does that example look like in Lynx? (As a heavy Lynx user, I care.)

It’s nice to have all of the relevant criteria clearly stated up front.

The example degrades quite gracefully in non-MathML/non-SVG-capable browsers. That’s because browsers hide unrecognized elements, and show you their content instead.

Lynx is an exception to that practice. (Why is there not even a commandline switch for this?) And so the example displays particularly poorly in Lynx (as would any alternative markup you’d care to suggest).

Posted by Jacques Distler at

Ian, you really need to consider using “I” a little less when you talk about the HTML5 group.

Don’t you mean "we"?

Posted by Shelley at

SQL was added because of demand from browser vendors (including your employer) and from developers of big Web applications looking for ways to support offline access.

I don’t think my employer supported it. Can you point to evidence of this, or any other public mail from anyone prior to its addition? Or is it an example of the closed feedback living in your mailbox that I complained about originally?

I pushed against SQL in HTML for literally over a year, but people basically told me that either I specced something, or they would do their own thing without a spec.

That is a false dichotomy. HTML5 is not the only spec in the world.

Posted by Robert Sayre at

I spoke to my partner about this and they suggested that maybe you think I’m feigning lack of opinion as a subtle way of disagreeing with the idea.

Using phrases such as “only-theoretically-accessible”, presenting new criteria in response to responses to your inquiries, and for that matter presenting a list of criteria for the first time as if it had been presented before all lend credence to this opinion.  As does the expression of personal options such as “not a high priority” as fact.

Posted by Sam Ruby at

I’m sorry, my input into this thread seems to have added little value. Background noise to the “real” discussion taking place. Sam feel free to delete everything you’d ignore anyway.

Have fun gentlemen. I’m sure that Microsoft appreciates the support.

Posted by Shelley at

I’m sorry, my input into this thread seems to have added little value.

It is not just you.  Being consistently told over a long period of time that requirements that are important to you are “not a priority” is a very effective demotivator.  And you are not the only one has been made to feel like you are ignored and your input is of little value.

For projects for my own personal use (like this one), I am increasingly using XHTML.  Why?  Because builder doesn’t understand which tags require RCDATA or require an explicit end tag.  But it does know about XML, because I did that work years ago.  And because HTML5 seems to always be in flux.

But I continue to bring up the issues with the way the HTML5 working group seems to casually throw around the term “we” when they sometimes mean everybody, sometimes mean a select few, and sometimes really mean “I”.  Not because I enjoy these discussions (I don’t), but because it gives ground-cover to various vendors (and not just Microsoft) to give up and go their own way.

Until there is a mechanism by which satisfies all four of the principles stated on the Atom road map (i.e., without skipping #3), this will always be a concern.  Yes, this would equally enable SVG, XUL, and Silverlight.  And no, XHTML5 is not an adequate response.  One should be able to do both document.write (at least of well formed fragments) and MathML.

Posted by Sam Ruby at

## Sun 09 Mar 2008

it gives ground-cover to various vendors (and not just Microsoft) to give up and go their own way.

I don’t think it’s just ground-cover for unsavory behavior. It is also a legitimate reason to route around the HTML5 WG for well-meaning implementors.

Posted by Robert Sayre at

Being consistently told over a long period of time that requirements that are important to you are “not a priority” is a very effective demotivator.

Perhaps you should form your own working group.

Posted by Mark at

Two small points, and then I will move on to more productive activities.

1) Per Ian’s request, here is how the example renders in a browser that supports neither MathML nor SVG:

Rank-2 Symmetric Tensor Representation ⊗ Fundamental Representation = Adjoint Representation ⊕ Rank-3 Symmetric Tensor Representation

which seems quite graceful, as graceful degradation goes. If the rendering is worse in Lynx, that’s Ian’s problem, not mine.

2) Ian wrote

I’m not saying MathML is a bad design. I’m not saying it’s a good design. I’m saying something that should be blatently obvious to anyone doing spec development, or indeed any kind of development, which is that we don’t just design specs blindly without carefully considering all options.

The Math-WG is currently working on MathML 3.0. If there are changes to MathML which would make embedding it in `text/html` more feasible, you should probably consider talking to them. Now, while the Spec is in WD, rather than years from now, when you get around to it.

Conversely, if you are contemplating some other (non-MathML) markup for math-in-HTML, as an alternative, that too might bear talking to the Math-WG folks about.

Posted by Jacques Distler at

I have no idea what changes we might need from MathML, if any. I have no idea what problem we’re trying to solve. I’ve yet to see any reply to my earlier comments, which are a prerequisite for making any further progress in this space. [link]

Posted by Ian Hickson at

Jacques Distler wrote:

Perhaps because they had the impression that those discussions weren’t going anywhere.

One crucial piece of information that the discussion needed was a thorough description of how namespaces in `text/html` work in IE 7.0. Microsoft could have provided that information but they didn’t.

Moreover, the (non-)communication pattern is the same in at least three W3C Working Groups (HTML WG, PFWG and WAF WG), so I don’t think the general pattern can be blamed on the appearances of any particular discussion in the HTML WG.

Hixie wrote:

As I said last time you complained about this, namespaced content in HTML is not a high priority,

Well, now at least one browser implementor is showing interest in the matter (in addition to the previous interest from writers of standalone parsers).

A detailed list of use cases and use scenarios detailing what we want to handle.

Use cases:

• Converting a typical LaTeX paper to `text/html` such that everything that wouldn’t get bitmapped in a pdfLaTeX workflow does not get bitmapped.
• Writing a similar document into `text/html` in a text editor copying and pasting the SVG figures from Inkscape XML output.
• Making Flash-like visually “high-impact” (sorry about the marketing BS term) sites using the openly specified Web platform but without the Draconianness of XML in such a way that the whole thing uses retained-mode graphics and lives in one DOM for easy scripting (i.e. no need for scripts to deal with `object` or `iframe` sub-DOMs).
• Publishing the kind of content that is published on Musings using a legacy PHP content management system that is not XML-ready.

The technical requirements that arise out of the above use cases are:

• Establishing a pseudo-XML parsing scope for `<svg>` and `math`.
• Putting elements in the SVG and MathML namespaces in the DOM in `<svg>` and `math` scopes, respectively.
• Establishing a nested "in body"-like parsing scope in `foreignObject` and `annotation-xml`.
• MathML entities in the pseudo-XML parsing scope (have the tree builder toggle a flag in the tokenizer).
• CDATA sections in the pseudo-XML parsing scopes (have the tree builder toggle a flag in the tokenizer).

do we really want to allow mixing pure presentational, media-specific, non-accessible or only-theoretically-accessible languages like Presentational MathML, XSLFO or SVG into text/html?).

Yes, to the extent they are already part of the open platform on the `application/xhtml+xml` side. That is, yes, I (I’m not claiming to represent a “we” on this point) want to allow Presentational MathML and SVG in `text/html`.

The presentationalness agrument makes no sense: If you’d be OK with including images by reference, moving presentatinal stuff into the same DOM and serialization does not magically make it worse than it was in the external HTTP resource.

As for accessibility, accessibility happens above the DOM, so the accessibility issues are the same regardless of whether the DOM was built from `text/html` or `application/xhtml+xml`.

I don’t want to allow XSL-FO in `text/html`, since it is not necessary when browsers already are fundamentally interactive CSS formatters.

A list of explicit non-goals, for example what we can learn from XML Namespaces (e.g. that prefixes are bad), and what we may not need to do (e.g. do we need to be syntax compatible with XML namespaces?

For the use cases I mentioned above, it wouldn’t be necessary to able to bind prefixes with an explicit syntax. Magic scoping on `svg`, `math`, `foreignObject` and `annotation-xml` would be enough. However, for the use cases to be satisfied, pasting in XMLNS-style default namespace declarations for `svg` and `math` should be allowed.

Do we need to actually support arbitrary namespaces, or can we satisfy all our use cases by providing explicit support for a finite set of elements?).

For the use cases I mentioned above, support for arbitrary namespaces is not necessary. However, for forward compatibility, I think the mechanism should be scope-based rather than based on a finite list in order to handle future expansions of MathML and SVG.

A study of what our constraints are given the existing parsing quirks (e.g. our inability to use the ‘xmlns’ attribute due to the conflict with IE’s wacky parsing).

I’m not equipped to do such a study.

A serious consideration of whether we actually want to do any of this, given that it would basically remove the only remaining reason to use XML on the Web, and would thus likely kill XML for good in this ecosystem.

It would be a shame to leave the SVG functionality in browsers mostly latent out of courtesy to the XML folks.

I’m not saying MathML is a bad design. I’m not saying it’s a good design. I’m saying something that should be blatently obvious to anyone doing spec development, or indeed any kind of development, which is that we don’t just design specs blindly without carefully considering all options.

I’m saying MathML above, because I think the WHATWG doesn’t have the bandwidth to reinvent math markup properly. It seems that partial solutions are not enough.

And what does that example look like in Lynx? (As a heavy Lynx user, I care.)

I think compatibility with shipped Lynx versions is an unreasonable constraint. We could do almost nothing if we chose to be constrained by already shipped versions of Lynx (or Links for that matter).

Posted by Henri Sivonen at

Henri: That’s a hugely useful step in the right direction, thanks. I’ll add it to the feedback pile — now that we have something solid to go on, it’ll be much easier to make progress.

My impression, for what it’s worth, is that what you describe isn’t what Sam is asking for.

(I didn’t necessarily mean a shipped version of Lynx, by the way. I just meant text browsers in general. It would be great if we could do something backwards compatible, but it’s even more important that HTML5-compliant text UAs can have decent fallback support.)

Posted by Ian Hickson at

“Henri: That’s a hugely useful step in the right direction, thanks. I’ll add it to the feedback pile”

Can I get the URL for that feedback pile?

Posted by Shelley at

Let me add some URLs to pad out Henri’s use-case list. Musings, The n-Category Café and xbeta are sites with heavy mathematical content. So is Terrence Tao’s blog.

Terrence Tao is a smart fellow (a Fields Medalist) but his blog is produced by “a legacy PHP content management system that is not XML-ready” (to use Henri’s phrase). Of necessity, all of his equations are output as inaccessible (and IMHO ugly) pictures.

One of the use-cases is to enable Tao to produce his blog, outputting his equations as MathML (which, despite your assertions to the contrary, is as accessible as any other content on the web).

Looking ahead, mixed SVG/MathML content is important (some examples are up-thread). This means support for <foreignObject> and <annotation-xml>.

I, personally, am willing to forgo MathML named entities and CDATA sections, if that’s what it will cost. But, if magic scoping makes them possible in embedded svg/mathml fragments, ...

Posted by Jacques Distler at

My impression, for what it’s worth, is that what you describe isn’t what Sam is asking for.

I’ll enthusiastically echo your comment that “That’s a hugely useful step in the right direction, thanks.”.  I’ll add that that would be sufficient to get an only slightly modified version of the test cases mentioned in this comment and this one to work.  It also would provide useful input to those who are continuing to evolve namespaces such as MathML, as well as pave the road for future extensions.

Ideally, it would be nice if this work could be done in time to produce useful feedback to Microsoft w.r.t. the recent IE8 beta.  I realize that that might be a bit much to ask; but it could be important factor in limiting the damage that Microsoft’s currently proposed limitations will have, if they are allowed to become a legacy that must be dealt with.

Establishing a pseudo-XML parsing scope for `<svg>` and `math`.

IE8’s approach seems to be “establish a pseudo-XML parsing scope for unknown elements which contain an attribute named `xmlns` that happens to match a list of known values”, where the list of known values may vary by user agent or installation.  IMHO, that approach merits exploration.

Secondly, if you look at a typical inkscape produced document, you will see a number of other namespaces defined and used.  At a minimum, such should cause no harm.  It would also be nice if such elements were not to inhibit the potential future evolution of SVG.

Finally, I’d like to echo Henri’s comment on CDATA.  Based on your feedback (I now forget where, perhaps on IRC?), I added CDATA into my figures here in order to ensure that this text does not appear in browsers that do not support XHTML+SVG.

Posted by Sam Ruby at

Shelley: I believe I included links to the feedback pile in the e-mail I sent you: [link]

Sam, Jacques: This is great input! Please, do send your comments here to the mailing list, like Henri did — it is difficult for me to track blog posts. The more input I have, the more reason there is for me to prioritise this. If you don’t want to join the lists, you can also e-mail me directly: ian@hixie.ch

Posted by Ian Hickson at

Please, do send your comments here to the mailing list, like Henri did — it is difficult for me to track blog posts.

Done and done (the latter by Henri).

Posted by Sam Ruby at

## Mon 10 Mar 2008

Excerpt from del.icio.us/rogerjohansson at

## Tue 11 Mar 2008

Thanks for the e-mails, I have added them to my pile of namespace feedback and will increase the priority for this stuff.

Posted by Ian Hickson at

## Mon 24 Mar 2008

FYI, I’m now working on this issue. For details, see this WHATWG blog post (or recent e-mail to the mailing lists):