John Boyer, IBM
Leigh Klotz, Xerox (minutes)
Nick van den Bleeken, Inventive Designers [irc only]
Steven Pemberton, CWI/W3C (chair)
Kurt Cagle, Invited Expert
Erik Bruchez, Orbeon
Kurt Cagle: There was an
announcement saying that the policy was no change to existing,
which was no extensions or elements.
Steven Pemberton: But if it's in the
DOM it's there but doesn't validate.
Kurt Cagle: Right
Steven Pemberton: OK, so it's in the
DOM.
Kurt Cagle: As far as I could tell.
The only question I could see is DOM interpretation. They will be
picked up by CSS, bindings, etc. They're just not "legitimate"
namespaces.
Nick van: There's one slight
difference. They changed the parsing a bit and now it will be more
difficult to get some constructs into the DOM. They are taking
stuff out of more elements. If you have HTML.
Steven Pemberton: One of the really
bad decisions of HTML5 is that it doesn't allow closing slash in
elements. If an element is empty, it has to be hard-coded into the
parser, which is as far as I'm concerned a real mistake, because it
messes up forward-compatibility.
Steven Pemberton: If they actually
remove elements or move them around, that's a problem.
Nick van: They do in some cases.
Steven Pemberton: For example?
Nick van: We discussed it a month ago;
elements of the same name in the HTML namespace that are
block-level elements in a non-block-level container will be moved
out. There are other parsing rules.
Steven Pemberton: So if you depend on
namespacing rules and change the default namespace.
Leigh Klotz: I think Norm Walsh's
comments are worth reading: http://norman.walsh.name/2011/02/08/html-xml
John Boyer: One of the big
headaches is that we can't put XForms markup in teh page and have a
validating document. There are a lot of government agencies looking
to W3C validation as a broad-sword effect on A11Y. That alone
limits us in a lot of accounts.
Steven Pemberton: I'm not pessimistic.
We can still specify that a valid document using XML rules. If you
give it to the HTML5 document it will still be consumed and
validates. I still think you can argue about validation and
serving.
Kurt Cagle: It gives more push to
saying that text/xhtml+xml is going to have to be the default for
validation for XForms, but with IE9 now supporting that MIME type,
it makes it a bigger case to say we can support it, which wasn't
true.
Steven Pemberton: So use the XML
mediatype and you're good to go.
Kurt Cagle: Yes. The interpretation of
XHTML5 isn't affected by this, as far as I understand, but it comes
down to the degree that implementors work with it.
John Boyer: There's a huge shift to
mobile devices, so IE9-only isn't good.
Steven Pemberton: Mobile devices are
XML friendly, including using an XML MIME type.
John Boyer: The second comment is ok
that IE9 now does it but that's not the majority.
Kurt Cagle: The one advantage of HTML5
effort is that it will produce significant market push to upgrade
browsers to a certain level of contemporary standards. Government
organizations will look seriously at current deployment.
Erik Bruchez: Can someone
summarize?
John Boyer: So is there a way to
inject XML?
Erik Bruchez: Is it limited to the
mechanism of embedding in XML?
Kurt Cagle: There are two big
problems: embedding, and the bigger one, PIs and XML Stylesheets.
I'm not sure where that stands right now. Is it there? Can we count
on it? Or is it being pushed away because it doesn't fit in
someone's ideas of use case?
Erik Bruchez: Does it work
today?
Kurt Cagle: More to the point, does it
work tomorrow/
Erik Bruchez: I thought the task force
was supposed to ask that.
Kurt Cagle: It's one of the use cases
that's being looked at and I don't think there's been any major
resolution.
Erik Bruchez: What about past
approaches we looked at? We've seen two approaches: the Ubiquity
approach (no XSLT) and the XSLT approach. If the XSLT approach
turns out not to work in ten years, is the other approach
satisfying? Are there specific problems there?
Kurt Cagle: Ubiquity sits on top of
the Yahoo UI JavaScript classes, so I don't think there's an issue
there.
John Boyer: The problem is that it
does pattern-matching with CSS-like patterns, looking for
XForms-based markup and attaches behavioral components. So the
point is that we deliver to the desktop a document that contains
XForms markup and those documents will never validate in
HTML5.
Erik Bruchez: That's fine if it
doesn't validate.
John Boyer: No, there are places where
validation is required for A11Y.
Steven Pemberton: The browser doesn't
validate. So you'd never notice. All we need is an XForms validator
that says it's correct.
John Boyer: (A) we have to create such
a validator and (B) we have to get people to allow XHTML+XForms
document validation. A validator from W3C makes it at least
feasible.
Erik Bruchez: I thought we were
talking about HTML, not XHTML.
John Boyer: We can't be guaranteed an
XHTML parse in an HTML5 document. Even if we could the document
doesn't validate.
Erik Bruchez: It's not going to
validate. How long until all the browsers support the HTML5 rules?
5-10 years? IE6 is still around. It's our experience too.
Inevitably people will have to migrate. But it may be in a long
time. Whatever HTML5 does, you still have IE6, IE7, IE8. The
deployed browsers won't support officially any type of valid
HTML+XForms combination.
Steven Pemberton: John, I think you're
being too pessimistic. You can deliver HTML+XForms as HTML and as
long as it's well-formed it will come out in the parse and the
JavaScript or whatever does its work. So we just describe the
validation rules. The HTML5 people don't really believe in
validation.
John Boyer: If the W3C came out with a
validation profile that says how to use HTML+XForms that's
ok.
Leigh Klotz: We're chartered to do
that.
Erik Bruchez: Nobody else would do it,
just us. I have no expectation that non-SVG,HTML,MathML would be
looked at by the HTML5 WG.
John Boyer: It would be better if they
had a decision for an extension mechanism.
Erik Bruchez: There's exciting stuff
that's going to happen. There's genuine interest in the successor
of XBL2, and that's an extension mechanism. You can say I want an
xforms:foobar control, but I can't call it xforms:foobar, and I can
implement something that looks like a native control. And that's
separate from the markup sent to the browser. There are people who
believe a component model for the web is necessary. That kind of
activity is going to help whoever wants to implement custom
controls and extensions in the browser. It might not help the
specific task of embedding an XML island into HTML but it is going
to help. But again, maybe in five years. If we can rely on it as a
WG, it will be maybe ten years.
Kurt Cagle: I'm not sure. There is an
XBL2 out now. It's JavaScript based, but there is one working.
There's Mozilla XBL1-esque. But those pieces are out there. The
real question I see is where the TAG was looking for XBL, and where
it's going. Is Ian going to change the rules?
Steven Pemberton: This is a good
segue.
Steven Pemberton: I haven't
confirmed yet, but I believe this Friday's HCG call will be on
XBL.
Leigh Klotz: I believe that we can use
XBL as Erik says to define XForms macros that expand into three
inputs and a setvalue, and also as Erik says in the browser (as in
Mozilla) to define components that implement XForms controls. The
form author can use namespaced bindings, and the XForms
implementors can use the in-browser implementation (which is
namespace blind). They can have namespaces as an optional feature
in XBL and the XForms implementors can deal with the namespaces
implement the namespace part at their layer.
Erik Bruchez: We do need to decide if
that's important; how can they remove namespaces? Perhaps they
can't remove namespaces?
Steven Pemberton: I think you should
read Ian's document and see what his proposal is.
Erik Bruchez: I don't know the
original Firefox XBL. It was an attempt to clean that up. It is
supposed to clean that up. The recent Google guy publication seemed
to be the usual use cases: custom controls, etc. As far as I know
that's what Chrome does. Complex behavior, but looks like an
element with attributes. Events, CSS, JavaScript. It seems to be
straightforward. Specifically with XForms, it's because we have
things you don't have in HTML, namely an XPath context (current
evaluation context): so how does that work crossing the component
boundary? With JavaScript? We just implemented an ad hoc solution
for that problem. It seems that the basic ideas, components with
private shadow DOM, seems to be quite sound.
Steven Pemberton: We're trying to
chivvy them on to do that. At one point we offered to take it on.
So Kurt?
Kurt Cagle: I have been working with
XBL for a long time now. It was one of the issues with SVG I worked
with DOM featuers. One of the biggest is the selection mechanism in
XBL. Hixie had pushed it to be only CSS. I pushed, succesfully, to
get that changed to the selector model be either CSS or XPath. At
that point Hixie quit the SVG working group.
Erik Bruchez: I agree about the
selection, at least partly. It's clear that using CSS to create a
destination tree is weaker than XPath. One reasons it that the
level of CSS supported (assume CSS3+). The main problem is that you
don't have a way to select attributes, such as @ref. There's no way
to copy the ref inside the result tree with CSS.
Kurt Cagle: That was one of my big
objections on the SVG side.
Erik Bruchez: So for template, they
chose CSS selectors and a couple of CSS and link/copy operations. A
more powerful transformation language, such as the XSLT extension
we support, is better. I see no way in browsers that they would
accept XPath 2.0 or XSLT. I'm pessimistic. The set of technologies
for those new features isn't going to be XPath/XSLT. If that
happens it will be done in libraries.
Steven Pemberton: To follow up on one
of the problems using CSS (and I was part of the group that
designed CSS selectors), CSS selectors are designed for streaming.
One reason they're bad for DOM is that you can only select
left-to-right, or following siblings but not preceeding-siblings.
It's ill-suited for the task. I think it's a mistake of CSS in the
first place that they made their decision. It should have been
people's choice to use that optimization or not, but then to carry
that mistake through to future technologies. Either CSS selectors
need to be fixed, or they should not be used.
Kurt Cagle: Can we write those
comments into the record?
Steven Pemberton: Yes, I've long had
in my head a paper that CSS has reached its sell-by date. A lot of
XForms decisions are driven by CSS problems. We should be designing
for the future.
Erik Bruchez: It won't help to say
it's no good.
Steven Pemberton: Right, I mean what
the future should hold for it.
ACTION-1777 Steven Pemberton to write paper on CSS futures.
Erik Bruchez: If XPath can be used for free, maybe, but as you can see it's not really "trendy" right now to push XML in the browser. We have to pick battles. If some people in the WG have the bandwidth to work on XBL, there are clear points: the transformation languge needs to be fixed, and here are examples. That might help. But just asking to use XPath 2.0 isn't going to fly.
Kurt Cagle: There's a case to look
at XBL beyond browser implementations. Look at Open Office, Libre
Office. There's a core specification and we need a framework that
says how you define it, integrate it with XML, mechanisms for HTML
integration. So we have a formal XBL2 (or XBL3!) mechanism, not
necessarily in the browser, but with library support. We have to
prove use cases in the browser to get it in the browser, but we
have use cases outside the browser and we have to show that those
use cases are important.
Erik Bruchez: It's all about spending
a lot of time and energy implementing and pushing stuff. Let's say
WebBL is done by Google and Mozilla with a few dedicated engineers
agreeing among themselves in some kind of forum. If anybody else
comes with a hypothetical use case, it's not going to make anything
change. It has to be pushed by someone implementing the use cases.
The point of view from Norm Walsh that it has to be fixed is
unrealistic. It doesn't work to say it has to be fixed because it
should be fixed. Clearly there are XBL use cases outside the
browser, but if there are no use case implementations it won't
happen.
Steven Pemberton: We need to wrap.
Kurt and Leigh, I'll invite you if it's on this topic.
Leigh Klotz: And it's an hour earlier
than this meeting on Friday?
Steven Pemberton: Yes.
Steven Pemberton: Do we need to
write something for HCG?
Leigh Klotz: I'd like to nominate
Kurt.
Kurt Cagle: Do we feel comfortable as
a WG taking on XBL?
Steven Pemberton: Not chartered, but
we could offer people to coordinate with the chartered group, I
believe WebApps, but I'm not sure now.
Leigh Klotz: I think there's two
levels: lower-level in browser non namespace aware, used for
implementing XForms. Upper-level in JavaScript libraries or
server-side, that macroexpands XForms namespace or other namespace
items into the lower-level markup.
Erik Bruchez: Unless we get fresh
faces in the group, it's OK to participate but we can't take it
on.
John Boyer: As we discussed two weeks ago, these are done.