[
Lists Home |
Date Index |
Thread Index
]
From: Joshua Allen [mailto:joshuaa@microsoft.com]
>> VML doesn't use the <xml> tag. It uses the namespace decl
>> and a behavior CSS decl.
>> The solution needs to work from
>> those declarations, not a tag. OTW, the right way would be
>Well, this is why I think the <xml> tag is a better solution, though. I
>don't see why VML could not have done that. Specifying namespaced
>markup (or really, any XML) directly in an HTML 4.x document is a design
>flaw, IMO.
It is at the very least a gaping hole in the current web
architecture as realized by the aggregate specifications.
On the other hand, with care it does work. I used VML
precisely because I don't have to use a plugin and I have
access to the DOM. I can use a database emitter to
generate intelligent entity-relationship diagrams
with popups, bubbles, a right-click navigation menu,
and so on. Without the database source, the diagrams
are unaffordable and unmaintainable. From that
perspective, the technology is doing exactly what
I need and I and my customers are very pleased
because it is an impressive improvement over the
old schema document based purely on HTML (big table
monstrosity) both in look, ease of use, better
comprehension, and so forth, at zero cost except
for my coding time.
But it surprised me that a missing end-of-comment decl
could punch such a big hole into it. Given the emitter
source and web distribution, a small mistake is amplified
to a significant signal. So part of this is about
tools and expectations, and part of it is noting that
we have a seemingly permanent flaw in the web specifications.
>> to insist when a namespace is embedded, that the wrapper
>> document (HTML in this case) be conformant XML even if it
>> isn't XHTML should the developer insist on
>> well-formedness. We don't need more hacks.
>This is not a bad idea.
An XML system should behave as it
is spec'd to behave. That's the exspec'tation. I realize
that with HTML and XML being in conflict with regards to
the Draconian parse model, that's a problem. IOW, if it
doesn't work per spec for the simple applications like
mine, it's not going to work any better for more complex
apps. And I quite like the namespace approach using
CSS behaviors because it is so easy to do... until it
outs the parser collision.
>The main issues I see here are:
>A) It's a retroactive spec change for HTML user agents. As far as HTML
>4.x spec is concerned, a namespace decl is no different from any other
>attribute. So you would either have to change the spec, or come up with
>a new spec for a class of "xml-aware HTML user-agents".
Balmer just made a speech about how Microsoft will not become IBM
and will continue to innovate. Such a spec if followed by Microsoft
could be an important innovation. I realize the significance of
Longhorn, but moving into a new apartment while leaving messy
closets in the old one is really the kind of move IBM was famous
for. Given that even with a slip of 1%, IE still has over 94% of
the market, I don't think you have a fielding issue; you have a
market issue over breaking existing content.
>B) It's quite likely that the majority of web pages that contain VML are
>*not* wellformed. For example, people use <link> tags or <p> tags that
>are not closed. So even a change to the "xml-aware HTML user-agent"
>behavior could be a breaking change for many users.
Yes, but the reason for the Draconian parse rule was to get people
to fix content and not make more malformed content. It does work
as a strategy. I've seen some dramatic improvements here where
people who don't like to talk have to because the XML engines
won't let them ignore such things. Anyway, the <p> tags are in
the HTML namespace. The VML just gives their content a piece of pixel
space. So as TimBL is rumored to have said about URLs,
'let them break'.
>Also, if I were to write a spec for a class of "xml-aware HTML
>user-agents", my strong preference would be to go with the <xml>
>convention. Then from that, spec how user-agents validate the contents
>of <xml> block. I think the <xml> block could have been a really nice
>convention for plugging in extra validation, registering plugins based
>on namespace, etc.
Maybe but you can't use that string and not break the XML spec. If
you insist on using a tag, use another one:
<ms:container validate=".T." ></ms:container>
or even a poor old processing instruction (that's what they are
there for). If we have to break content to get a more reliable
web, it's worth it. (I wonder how much content out there is
static and how much is generated. Would it be worth fixing
the generators? I think it would but that's a good debating
point.)
>> What happens when we get to XAML?
>This is the other side of the coin. In the case of XAML and WordML,
>both of which can contain VML, the envelope already *is* XML, and is not
>processed by an HTML browser. The user-agent is already operating in
>draconian mode. So in that case, the <sml> convention would be
>unnecessary (and in fact non-wellformed).
Right although when I put VML into a Word doc, I get a nasty
scaling surprise and I haven't had time to work that one out.
However, the drift of this is that all of the innovation for
an NGbrowser will be in XAML and HTML will stay as it is.
If that is the message, so be it. I've doubts about that
as a market strategy although as the MID guy, I've confidence
that it is the right answer as long the rendering and
behavioral systems are separate but perfectly meshed.
It is risky but as Balmer said, we should only quit using
MS products when MS quits taking big risks.
Ok. I've done enough to keep Edd's Len rating in two
digit numbers.
len
|
