Initial comments on XBL (12 November 2005 draft)
Anne van Kesteren
camelcase attribute names, "applyAuthorSheets", are used. I propose to
hyphenate all of them. (And also the element names that are currently
using camelcase.)
I propose that the specification uses the "xml:id" attribute instead of
"id" on elements in the XBL namespace per section 4.5.3[1] of Architecture
of the World Wide Web, Volume One.
3.3 "If a src attribute is present, it overrides the contents of the
element (even if fetching the specified URI failed)."
Isn't it easier to say "If a src attribute is specified, the contents of
the element must be ignored." The word "overrides" is not really clear.
(Also in 2.12.)
[1]<http://www.w3.org/TR/webarch/#xml-namespaces>
--
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>
Ian Hickson
>
> Both hyphenated attribute names, "style-type", "script-type", and
> camelcase attribute names, "applyAuthorSheets", are used. I propose to
> hyphenate all of them. (And also the element names that are currently
> using camelcase.)
Renamed shadowTree to shadow-tree, applyBindingSheets to
apply-binding-sheets, applyAuthorSheets to apply-author-sheets, and
allowSelectorsThrough to allow-selectors-through. Are there any others?
> I propose that the specification uses the "xml:id" attribute instead of
> "id" on elements in the XBL namespace per section 4.5.3[1] of
> Architecture of the World Wide Web, Volume One.
I don't see any advantages to requiring namespaces to be used when setting
the ID attribute.
foo.setAttribute('id', 'bar');
...is much simpler than:
foo.setAttributeNS('http://www.w3.org/xml/1998/namespace', 'id', 'bar');
Even in the markup,
<binding id="bar">
...is easier than:
<binding xml:id="bar">
In fact I don't understand why you would want the second one in a Web
spec. xml:id is useful for proprietary specs, just like XLink. It isn't
something that should be exposed to Web authors, IMHO. It's useful in
all-XML workflow pipeline that use things like Schemas and automated tools
to handle arbitrary XML. XBL, on the other hand, is a spec describing a
technology that binds deeply into the DOM; it will only rarely be
processed by arbitrary-XML processors and even more rarely will such
processors need to be aware of IDness of attributes in XBL.
(Note that if you didn't spot the deliberate mistake in the above examples
or prose before reading this paragraph then you are now officially banned
from promoting xml:id for two months, on the basis that you don't know
what you're promoting. :-P)
(If you didn't spot the mistake within five minutes even after reading the
previous paragraph, then it's four months instead. :-P)
> 3.3 "If a src attribute is present, it overrides the contents of the
> element (even if fetching the specified URI failed)."
>
> Isn't it easier to say "If a src attribute is specified, the contents of the
> element must be ignored." The word "overrides" is not really clear. (Also in
> 2.12.)
Good call. Fixed.
--
Ian Hickson U+1047E )\._.,--....,'``. fL
http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Anne van Kesteren
> Renamed shadowTree to shadow-tree, applyBindingSheets to
> apply-binding-sheets, applyAuthorSheets to apply-author-sheets, and
> allowSelectorsThrough to allow-selectors-through. Are there any others?
The attributes on the xbl:handler element:
<http://www.mozilla.org/projects/xbl/xbl2.html#handler0>
Specifically, "defaultAction", "clickCount", "keyLocation", "prevValue",
"newValue", "attrName" and "attrChange".
>> I propose that the specification uses the "xml:id" attribute instead of
>> "id" on elements in the XBL namespace per section 4.5.3[1] of
>> Architecture of the World Wide Web, Volume One.
>
> I don't see any advantages to requiring namespaces to be used when
> setting
> the ID attribute.
>
> foo.setAttribute('id', 'bar');
>
> ...is much simpler than:
>
> foo.setAttributeNS('http://www.w3.org/xml/1998/namespace', 'id',
> 'bar');
foo.id = 'bar'
...would be even simpler. Adding an XBLElement interface with some simple
shortcuts should not be that hard.
> Even in the markup,
>
> <binding id="bar">
>
> ...is easier than:
>
> <binding xml:id="bar">
Depends. If some markup languages are naming the attribute differently I
would have to remember per namespace which attribute in no namespace I
could use. If every language would just work with xml:id I would not have
to think as an author.
Another comment. In 3.2.1. XForms Actions the specification first states
that the scripting language is "application/x-xforms-actions+xml" and
later drops the +xml suffix. (The current specification would allow
xbl:implementation to be used.)
Ian Hickson
> On 15 nov. 2005, at 20:03, Anne van Kesteren wrote:
> > >
> > > Even in the markup,
> > >
> > > <binding id="bar">
> > >
> > > ...is easier than:
> > >
> > > <binding xml:id="bar">
> >
> > Depends. If some markup languages are naming the attribute differently
> > I would have to remember per namespace which attribute in no namespace
> > I could use. If every language would just work with xml:id I would not
> > have to think as an author.
>
> leverages a foundation XML familiy specification, which in my opinion is
> a bonus.
This kind of cargo-cult spec design scare the heck out of me.
I highly recommend taking three or four steps back from the ivory tower
and looking at the real world. Web authors use only a few languages: HTML,
JS, CSS, _maybe_ SVG in the future, and presumably (since that's what
we're talking about here) XBL.
JS and CSS aren't tag-based languages. HTML uses "id". SVG uses "id".
None of the above use "xml:id".
Why would XBL want to use xml:id?
Read the abstract of xml:id. It's designed for cases where the processor
is a generic XML processor, not for the Web where the user agents are all
special-purposed and have intimate knowledge of the namespaces involved.
Anne van Kesteren
> JS and CSS aren't tag-based languages. HTML uses "id". SVG uses "id".
> None of the above use "xml:id".
>
> Why would XBL want to use xml:id?
SVG is going to use xml:id. XHTML2 is going to use it as well (although
that might not be an argument). XFrames uses it. I'm not aware of any
language that is being developed or released after xml:id became a Rec
that does not reuse it. It is the same as with "lang". Why would any
language define its own "lang" attribute as there is a generic one. Or a
"base" attribute for that matter.
Neil
> Both hyphenated attribute names, "style-type", "script-type", and
> camelcase attribute names, "applyAuthorSheets", are used.
Out of interest, where else would I have been most likely to encounter
hyphenated attribute names?
--
Warning: May contain traces of nuts.
Boris Zbarsky
> SVG is going to use xml:id.
So it's dropping support for the attribute "id" in the null namespace (which is
what SVG 1.1 and SVG 1.2 Tiny use)? Or is it just that you can specify an ID in
both ways (which would also be the case with the current XBL spec)?
> XHTML2 is going to use it as well (although
> that might not be an argument).
So XHTML2 is also dropping the XHTML "id" attribute?
> Or a "base" attribute for that matter.
Good example, actually. xml:base is an incredible pain to implement and imposes
significant performance penalties; I rather wish we did NOT implement it.
HTML's <base> tag covers the 99% use case, without causing all the issues.
-Boris
Anne van Kesteren
> Anne van Kesteren wrote:
>> SVG is going to use xml:id.
>
> So it's dropping support for the attribute "id" in the null namespace
> (which is what SVG 1.1 and SVG 1.2 Tiny use)? Or is it just that you
> can specify an ID in both ways (which would also be the case with the
> current XBL spec)?
I believe SVG 1.2 Tiny uses xml:id too. I believe they invented some hack
that setting the id DOM attribute would cause both attributes ("id" in the
null namespace and in the XML namespace) to be setted and therefore
invalidate the document.
And for documents that do not need to be backwards compatible using
"xml:id" is fine. However, I heard this from someone, I have not checked
the internal draft myself.
>> XHTML2 is going to use it as well (although that might not be an
>> argument).
>
> So XHTML2 is also dropping the XHTML "id" attribute?
They are using both at the moment I believe. Not sure, XHTML2 is a weird
specification.
>> Or a "base" attribute for that matter.
>
> Good example, actually. xml:base is an incredible pain to implement and
> imposes significant performance penalties; I rather wish we did NOT
> implement it. HTML's <base> tag covers the 99% use case, without causing
> all the issues.
:-) Did not know that. I hardly use it myself. (Same for <base> by the
way.)
Cheers,
Anne
Boris Zbarsky
> I believe SVG 1.2 Tiny uses xml:id too. I believe they invented some
> hack that setting the id DOM attribute would cause both attributes ("id"
> in the null namespace and in the XML namespace) to be setted and
> therefore invalidate the document.
The point is, they allow both to be used. Why shouldn't XBL do that?
-Boris
Boris Zbarsky
> Because XBL2 has a new namespace
So does XHTML2, no?
> there is no need for being backwards compatible.
But there is need for being usable.
-Boris
Anne van Kesteren
> Anne van Kesteren wrote:
>> Because XBL2 has a new namespace
>
> So does XHTML2, no?
I never said I agreed with that. And that specification is nowhere near as
mature as XBL2 is. (Although I believe they plan to enter LC soonish
now...) XHTML2 also re-introduces all kinds of elements to make it
completely similar to XHTML1 only then different. (xhtml2:img for
example...)
>> there is no need for being backwards compatible.
>
> But there is need for being usable.
Why would xml:id not be usable? xml:lang is usable. xml:base is usable,
albeit a pain to implement.
Anne van Kesteren
wrote:
>> Why would xml:id not be usable? xml:lang is usable. xml:base is
>> usable, albeit a pain to implement.
>
>
> We should not require any qualification for XBL2. It should be a
> self-contained single-namespace XML language.
XBL2 already uses namespaces and for certain things, like xbl:lang and
xbl:pseudo, namespace-prefixes are already required. And therefore
additional namespace declarations as well. xml:id, as opposed to that,
does not require namespace declarations.
It is also in line, as previously pointed out, with the Architecture of
the World Wide Web, Volume One.
(Besides that you probably want to use other namespaces inside your XBL
widgets, like the XHTML namespace, SVG perhaps, et cetera.)
Boris Zbarsky
>> But there is need for being usable.
>
> Why would xml:id not be usable?
See Ian's examples in a preceding mail. In short, it's a lot harder for authors
to use.
xml:lang and xml:base have the same issues from an authoring perspective -- a
lot more typing needed for simple results. A common problem with the DOM. :(
-Boris
Ian Hickson
> > >
> > > there is no need for being backwards compatible.
> >
> > But there is need for being usable.
>
> albeit a pain to implement.
xml:lang and xml:base are a pain, especially compared to their
non-prefixed equivalents.
Anne van Kesteren
I see your point. However, for such cases it would probably be more
convinient for authors to have a specific/general element interface
anyway, like with DOM2HTML.
That the sole reason for not using it would be because the DOM is flawed
does not seem like a good argument. Furthermore, as pointed out, you can
work around that.
Ian Hickson
>
> does not seem like a good argument. Furthermore, as pointed out, you can
> work around that.
That's not the sole reason, it's a secondary reason. The main reason is
that "xml:id" is longer than "id". That disadvantage outweighs all the
advantages of xml:id (such as they are).
As I said already. xml:id, like XLink, XInclude, XPath, etc, is a
technology aimed at the generic XML world. The Web is not the generic XML
world. The advantages that these technologies convey -- mostly the ability
for arbitrary vocabularies to be processed by arbitary XML processors in
XML workflows -- don't apply on the Web, where UAs are very vocabulary-
aware, with specific namespaces being supported in depth.
xml:id is relevant when you have a proprietary, limited-domain language
that you want other people to be able to process without them having to
know the semantics of your language. XBL is not such a language.
Just because a spec exists doesn't make it relevant.
Ian Hickson
> On Tue, 15 Nov 2005 19:44:39 +0100, Ian Hickson <i...@hixie.ch> wrote:
> > Renamed shadowTree to shadow-tree, applyBindingSheets to
> > apply-binding-sheets, applyAuthorSheets to apply-author-sheets, and
> > allowSelectorsThrough to allow-selectors-through. Are there any others?
>
> The attributes on the xbl:handler element:
> <http://www.mozilla.org/projects/xbl/xbl2.html#handler0>
>
> Specifically, "defaultAction", "clickCount", "keyLocation", "prevValue",
> "newValue", "attrName" and "attrChange".
Fixed.
> > > I propose that the specification uses the "xml:id" attribute instead
> > > of "id" on elements in the XBL namespace per section 4.5.3[1] of
> > > Architecture of the World Wide Web, Volume One.
> >
> > I don't see any advantages to requiring namespaces to be used when
> > setting the ID attribute.
> >
> > foo.setAttribute('id', 'bar');
> >
> > ...is much simpler than:
> >
> > foo.setAttributeNS('http://www.w3.org/xml/1998/namespace', 'id', 'bar');
>
> foo.id = 'bar'
>
> ...would be even simpler. Adding an XBLElement interface with some simple
> shortcuts should not be that hard.
I'd rather avoiding adding any new interfaces if possible.
> > Even in the markup,
> >
> > <binding id="bar">
> >
> > ...is easier than:
> >
> > <binding xml:id="bar">
>
> Depends. If some markup languages are naming the attribute differently I
> would have to remember per namespace which attribute in no namespace I
> could use.
Sure, but of the languages you might use here -- HTML, SVG, MathML
(maybe!), and XBL -- you don't have to remember this.
And you shouldn't be using any other languages, because otherwise you
would be sending languages unsupported by Web UAs, which is an
accessibility problem.
> If every language would just work with xml:id I would not have to think
> as an author.
Sure. But every language doesn't work with xml:id, indeed the most common
one (HTML) doesn't.
> Another comment. In 3.2.1. XForms Actions the specification first states
> that the scripting language is "application/x-xforms-actions+xml" and
> later drops the +xml suffix. (The current specification would allow
> xbl:implementation to be used.)
Good catch, fixed.
Ian Hickson
>
> Anne van Kesteren wrote:
>
> > Both hyphenated attribute names, "style-type", "script-type", and camelcase
> > attribute names, "applyAuthorSheets", are used.
>
> Out of interest, where else would I have been most likely to encounter
> hyphenated attribute names?
CSS (though in the CSS syntax they are called properties, not attributes).
SVG uses hyphenated attributes some of the time. I can't work out if there
is a pattern to when they use hyphenated attributes and when they use
camelCase, though.
XHTML2 uses hyphenated attributes some of the time, but then they also
use lowercasewordsmushing, camelCase, and namespaced:attributes, so I
guess they're just hedging their bets.
MathML uses hyphenated attribute names on a few occasions (though, like
XHTML2, they seem to use whatever feels best).
Web Forms 2 uses hyphenated attribute names for the repeat-* attributes as
a kind of namespacing mechanism to prevent clashes with other attributes.
Other than the repeat-* attributes, HTML also has hyphens in http-equiv
and accept-charset. (Other than those, it uses all-lowercase
smushedwords, e.g. onmouseover="", contenteditable="", etc).
So anyway. Yes. There seems to be ample precedent to do whatever we like,
and hyphenated words are definitely easier to read, and only slightly
harder to search for in search engines.
Neil
>So anyway. Yes. There seems to be ample precedent to do whatever we like
>
>
I see you worked out what my question really meant ;-)
Anne van Kesteren
> That's not the sole reason, it's a secondary reason. The main reason is
> that "xml:id" is longer than "id". That disadvantage outweighs all the
> advantages of xml:id (such as they are).
Well ok... I'm not really convinced because of
<http://www.w3.org/TR/webarch/#xml-namespaces> but I can live with it.
However, I think the following needs to be changed:
<http://www.mozilla.org/projects/xbl/xbl2.html#id12>
# If the attribute's value is the empty string,
# the element has no ID.
It can still have an ID even though the attribute 'id' is empty.
Ian Hickson
>
> However, I think the following needs to be changed:
>
> <http://www.mozilla.org/projects/xbl/xbl2.html#id12>
> # If the attribute's value is the empty string,
> # the element has no ID.
>
> It can still have an ID even though the attribute 'id' is empty.
Changed to "If the attribute's value is the empty string, the attribute
must not set an ID. Otherwise, the attribute's value must be treated as
(one of) the element's ID(s)."
Bjoern Hoehrmann
>On Tue, 15 Nov 2005, Anne van Kesteren wrote:
>> On Tue, 15 Nov 2005 19:44:39 +0100, Ian Hickson <i...@hixie.ch> wrote:
>> > Renamed shadowTree to shadow-tree, applyBindingSheets to
>> > apply-binding-sheets, applyAuthorSheets to apply-author-sheets, and
>> > allowSelectorsThrough to allow-selectors-through. Are there any others?
>>
>> The attributes on the xbl:handler element:
>> <http://www.mozilla.org/projects/xbl/xbl2.html#handler0>
>>
>> Specifically, "defaultAction", "clickCount", "keyLocation", "prevValue",
>> "newValue", "attrName" and "attrChange".
>
>Fixed.
I note that these were probably chosen to be consistent with the names
of the relevant DOM attributes and the XML Events attributes; that's not
such a bad idea. Thanks to search and replace you've also changed the
names of the DOM attributes...
--
Björn Höhrmann · mailto:bjo...@hoehrmann.de · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/