Since XBL2 wasn't getting much traction, I've taken an axe to the spec and
made a number of changes to the spec based on some discussions with some
browser vendors:
http://dev.w3.org/2006/xbl2/Overview.html
The main changes are simplification: I've dropped namespace support
Ian,
It's good news that you have re-opened the XBL2 effort. We still don't have
a reasonable component model for HTML, and XBL1 has proven its value for 10
+ years in the Mozilla world.
My first question is how to deal with the chicken-and-egg problem where
developers won't to
For what it's worth, it's a requirement for us to be able to use
namespaces of some sorts since we're planning on implementing XUL
using XBL2. There are however multiple ways we can do this and I'll
need to look into which approach XUL developers prefer.
I'm also not sure that we can do without
On Fri, 03 Sep 2010 19:24:03 +0200, Jonas Sicking wrote:
For what it's worth, it's a requirement for us to be able to use
namespaces of some sorts since we're planning on implementing XUL
using XBL2. There are however multiple ways we can do this and I'll
need to look int
On 9/3/10 1:37 PM, Anne van Kesteren wrote:
On Fri, 03 Sep 2010 19:24:03 +0200, Jonas Sicking wrote:
For what it's worth, it's a requirement for us to be able to use
namespaces of some sorts since we're planning on implementing XUL
using XBL2. There are however multiple ways we
On Fri, 03 Sep 2010 19:45:00 +0200, Boris Zbarsky wrote:
The relevant stylesheets are applied to all documents, because XUL can
be used in any XML document, obviously.
As a simple example, the binding used for xul:iframe shouldn't be used
for html:iframe.
I see. Though XUL is not exposed
On Fri, Sep 3, 2010 at 10:37 AM, Anne van Kesteren wrote:
> On Fri, 03 Sep 2010 19:24:03 +0200, Jonas Sicking wrote:
>>
>> For what it's worth, it's a requirement for us to be able to use
>> namespaces of some sorts since we're planning on implementing
On 9/3/10 1:48 PM, Anne van Kesteren wrote:
On Fri, 03 Sep 2010 19:45:00 +0200, Boris Zbarsky wrote:
The relevant stylesheets are applied to all documents, because XUL can
be used in any XML document, obviously.
As a simple example, the binding used for xul:iframe shouldn't be used
for html:if
On Fri, 3 Sep 2010, Jonas Sicking wrote:
>
> For what it's worth, it's a requirement for us to be able to use
> namespaces of some sorts since we're planning on implementing XUL using
> XBL2. There are however multiple ways we can do this and I'll need to
oss-site scripting in much the same way that prepared
SQL statements help mitigate SQL injection.
Adam
On Thu, Sep 2, 2010 at 6:23 PM, Ian Hickson wrote:
>
> Since XBL2 wasn't getting much traction, I've taken an axe to the spec and
> made a number of changes to the spec bas
Perhaps the spec should reference focusin/focusout instead of
DOMFocusIn/DOMFocusOut ?
http://dev.w3.org/2006/xbl2/Overview.html#the-focus-domfocusin-blur-and-domfocusou
ments help mitigate SQL injection.
>
> Adam
>
>
> On Thu, Sep 2, 2010 at 6:23 PM, Ian Hickson wrote:
>>
>> Since XBL2 wasn't getting much traction, I've taken an axe to the spec and
>> made a number of changes to the spec based on some discussions
6:23 PM, Ian Hickson wrote:
Since XBL2 wasn't getting much traction, I've taken an axe to the spec and
made a number of changes to the spec based on some discussions with some
browser vendors:
Since Jonas (surprisingly) wasn't among the browser vendors you
discussed this wit
On 9/4/10 6:36 AM, ext Doug Schepers wrote:
To that end, could you provide a link to the requirements document, or
if there isn't one, could you start one?
FYI: when the Web Application Formats WG transitioned XBL2 from Last
Call WD to CR (March 2007), the transition request include
Hi, Art-
Arthur Barstow wrote (on 9/8/10 1:55 PM):
On 9/4/10 6:36 AM, ext Doug Schepers wrote:
To that end, could you provide a link to the requirements document, or
if there isn't one, could you start one?
FYI: when the Web Application Formats WG transitioned XBL2 from Last
Call WD
one?
> > FYI: when the Web Application Formats WG transitioned XBL2 from Last
> > Call WD to CR (March 2007), the transition request included the
> > following re requirements:
> >
> > [[
> > 5. Evidence that the document satisfies group requirements:
> >
&
Do we have a sense yet regarding who supports XBL2 as in the 2007
Candidate version [CR] versus who supports the version Hixie recently
published in [Draft]?
Feedback from all (potential) implementers would be especially useful.
Thinking aloud here, perhaps [Draft] could be positioned more
On Fri, Sep 17, 2010 at 6:06 AM, Arthur Barstow wrote:
> Do we have a sense yet regarding who supports XBL2 as in the 2007 Candidate
> version [CR] versus who supports the version Hixie recently published in
> [Draft]?
>
> Feedback from all (potential) implementers would be es
On Jun 2, 2009, at 10:04 AM, ext StefanoC wrote:
Hello!
I'm wondering what's the roadmap for XBL2 support in FF - and any
other browser, should you know.
in this post:
http://groups.google.com/group/mozilla.dev.tech.xbl/browse_thread/
thread/961d8439d828dba1
Jonas Sicking me
Hi Art,
Planning is in full speed for our XBL2 implementation. Development
will start shortly. First design docs are available here:
https://wiki.mozilla.org/XBL2
(not sure if the docs will be very understandable for
non-gecko-developers. The target audience is XBL2 gecko implementors)
/ Jonas
On Jun 16, 2009, at 5:10 PM, ext Jonas Sicking wrote:
Planning is in full speed for our XBL2 implementation. Development
will start shortly. First design docs are available here:
https://wiki.mozilla.org/XBL2
(not sure if the docs will be very understandable for
non-gecko-developers. The target
rrect that.
But first things first: XBL2 is dead. To paraphrase
http://www.imdb.com/title/tt0093936/quotes?qt=qt0311047, there was a
funeral and we buried it.
There are chunks of it that are still viable and immensely useful.
However, there are large chunks that will have to be cut, some running
dee
> body { binding: url(example.xbl#nav-then-main); }
Adding active content via CSS is bad for security. For example, IE
has removed support for CSS expressions (which execute script) and
Mozilla has removed support for XBL bindings, which, like this
proposal, would allow for script execution from
On Thu, 22 Sep 2011 20:30:24 +0200, Dimitri Glazkov
wrote:
Further, instead of packaging Web Components into one omnibus
offering, we will likely end up with several free-standing specs or
spec addendums:
1) Shadow DOM, the largest bag of with XBL2's donated organs --
probably its own sp
pec addendums:
>>
>> 1) Shadow DOM, the largest bag of with XBL2's donated organs --
>> probably its own spec;
>> 2) Constructible and extensible DOM objects which should probably
>> just be part of DOM Core and HTML;
>> 3) Declarative syntax for gluing the
pec addendums:
>>
>> 1) Shadow DOM, the largest bag of with XBL2's donated organs --
>> probably its own spec;
>> 2) Constructible and extensible DOM objects which should probably
>> just be part of DOM Core and HTML;
>> 3) Declarative syntax for gluing the
Hi All,
The W3C's XBL2 Candidate spec [1] was published almost two years ago.
Since then, there has been some implementation activity reported
(e.g. [2],[3]) but nothing recently.
Does anyone have XBL2 implementation status they can share with us?
-Regards, Art Barstow
[1]
Hi André, All,
Below, André asks for XBL2 implementation status. I think the last
time this was discussed on public-webapps was June 2009 [1] (and a
somewhat related thread in March 2010 on www-tag [2]).
All - if you have some status information re XBL2 implementations,
please do share
On Sunday, September 5, 2010, 4:00:20 AM, Adam wrote:
>> body { binding: url(example.xbl#nav-then-main); }
AB> Adding active content via CSS is bad for security. For example, IE
AB> has removed support for CSS expressions (which execute script) and
AB> Mozilla has removed support for XBL binding
e light of that browser implementor feedback about the drawbacks of
> using CSS to add active content, maybe another method should be chosen. XPath
> for example might be useful here.
<>
Adam's comments are about binding with a stylesheet, not Selectors. XBL2
provides binding mechanisms
Arthur Barstow wrote:
Hi All,
The W3C's XBL2 Candidate spec [1] was published almost two years ago.
Since then, there has been some implementation activity reported (e.g.
[2],[3]) but nothing recently.
Does anyone have XBL2 implementation status they can share with us?
I don'
project) doesn't implement templates / shadow-trees yet.
cheers,
Sean
Arthur Barstow wrote:
Hi All,
The W3C's XBL2 Candidate spec [1] was published almost two years ago.
Since then, there has been some implementation activity reported (e.g.
[2],[3]) but nothing recently.
Does anyone
On Feb 10, 2009, at 00:39 , Sean Hogan wrote:
There are a few active JS implementation projects:
I don't know if there is precedent in counting JS-based
implementations as valid implementation to get a spec out the door
(maybe the Forms WG did it?) but I see no reason not to. In fact, I
Robin Berjon wrote:
I don't know if there is precedent in counting JS-based implementations
as valid implementation to get a spec out the door (maybe the Forms WG
did it?) but I see no reason not to. In fact, I could make the argument
that they should count *more* as they allow technology to b
On Feb 10, 2009, at 15:27 , Boris Zbarsky wrote:
Robin Berjon wrote:
I don't know if there is precedent in counting JS-based
implementations as valid implementation to get a spec out the door
(maybe the Forms WG did it?) but I see no reason not to. In fact, I
could make the argument that t
Robin Berjon wrote:
Oh, I fully agree with that, the point is not to water down the
interoperability requirements. I simply want to make sure that JS-based
implementations are counted as "real" as there often is a misperception
that they are somehow just hacks.
I think that should be fine as
We're interested in implementing XBL2 in WebKit as well, though I
can't give a specific timetable.
On Feb 10, 2009, at 6:39 AM, Robin Berjon wrote:
On Feb 10, 2009, at 15:27 , Boris Zbarsky wrote:
Robin Berjon wrote:
I don't know if there is precedent in co
On Wed, May 5, 2010 at 5:10 AM, Arthur Barstow wrote:
> Hi André, All,
>
> Below, André asks for XBL2 implementation status. I think the last time this
> was discussed on public-webapps was June 2009 [1] (and a somewhat related
> thread in March 2010 on www-tag [2]).
>
> A
On Wed, May 5, 2010 at 7:31 AM, Tab Atkins Jr. wrote:
> On Wed, May 5, 2010 at 5:10 AM, Arthur Barstow wrote:
>> Hi André, All,
>>
>> Below, André asks for XBL2 implementation status. I think the last time this
>> was discussed on public-webapps was June 2009
Hello, friendly elves that keep pushing the Web forward!
I spent a few days internalizing the XBL2 spec and here's my first set
of reactions.
First, the XBL2 spec is truly an amazing feat. While reading it, I
kept having visions of walking about an alien artifact, mesmerized by
its scale, w
On Sat, Dec 11, 2010 at 1:04 PM, Dimitri Glazkov wrote:
> Looking at the use cases, I couldn't think of anything that would
> require this type of functionality -- at least not at the cost of its
> complexity and performance implications.
>
> Perhaps something simpler, forward-only would be a bett
On Sun, Dec 12, 2010 at 12:52 AM, Robert O'Callahan
wrote:
> On Sat, Dec 11, 2010 at 1:04 PM, Dimitri Glazkov
> wrote:
>>
>> Looking at the use cases, I couldn't think of anything that would
>> require this type of functionality -- at least not at the cost of its
>> complexity and performance imp
dynamic DOM modification
> > (e.g. editing) with templates needs this. So you do need to record how
> > instances were created.
>
> Can you give a more specific example?
>
Suppose I use XBL2 to define , a container with elaborate
styling that I can't do with CSS alone. Cha
to a template instance has its
>> > subtree
>> > changed. Almost every application that combines dynamic DOM modification
>> > (e.g. editing) with templates needs this. So you do need to record how
>> > instances were created.
>>
>> Can you give a more
On 12/13/10 5:46 PM, Tab Atkins Jr. wrote:
Ah, you're thinking about changes to the normal DOM. We're afraid of
changes to the template.
I think roc explicitly said that he thinks the XBL2 spec's section on
this seems ... dispensable.
I agree with him, for what it's worth.
-Boris
On Mon, Dec 13, 2010 at 9:11 PM, Boris Zbarsky wrote:
> On 12/13/10 5:46 PM, Tab Atkins Jr. wrote:
>>
>> Ah, you're thinking about changes to the normal DOM. We're afraid of
>> changes to the template.
>
> I think roc explicitly said that he thinks th
On Tue, Dec 14, 2010 at 2:46 PM, Tab Atkins Jr. wrote:
> Then there's no problem. You don't need the templates to be live to
> make child changes work. You just need to maintain some record that
> any normal-DOM elements which match "*" should appear as children of
> the shadow node #three in th
On Mon, Dec 13, 2010 at 10:33 PM, Robert O'Callahan
wrote:
> On Tue, Dec 14, 2010 at 2:46 PM, Tab Atkins Jr.
> wrote:
>>
>> Then there's no problem. You don't need the templates to be live to
>> make child changes work. You just need to maintain some record that
>> any normal-DOM elements which
On Mon, Dec 13, 2010 at 10:33 PM, Robert O'Callahan
wrote:
> On Tue, Dec 14, 2010 at 2:46 PM, Tab Atkins Jr.
> wrote:
>> Then there's no problem. You don't need the templates to be live to
>> make child changes work. You just need to maintain some record that
>> any normal-DOM elements which ma
On 12/14/10 10:25 AM, Tab Atkins Jr. wrote:
Looking just at the problem itself, it's an open question as to
whether it would be simpler to hold a reference to the template or
just create the appropriate data structures out of the template.
Likely, you'll be doing the latter in C++ anyway, so push
On Tue, Dec 14, 2010 at 10:45 AM, Boris Zbarsky wrote:
> On 12/14/10 10:25 AM, Tab Atkins Jr. wrote:
>> Looking just at the problem itself, it's an open question as to
>> whether it would be simpler to hold a reference to the template or
>> just create the appropriate data structures out of the te
On 12/14/10 11:03 AM, Tab Atkins Jr. wrote:
Script should be able to walk and mutate
the shadow DOM for an element
I'm not sure I agree, in fact. Why should script be able to do this?
Sorta supporting this has been a constant source of problems in Mozilla'
XBL1 implementation, and significan
On Tue, Dec 14, 2010 at 11:14 AM, Boris Zbarsky wrote:
> On 12/14/10 11:03 AM, Tab Atkins Jr. wrote:
>>
>> Script should be able to walk and mutate
>> the shadow DOM for an element
>
> I'm not sure I agree, in fact. Why should script be able to do this? Sorta
> supporting this has been a constant
sync with the data structures that
represent insertion points (what I think XBL2 calls output ports) and
the like). After this, adding normal DOM children to the bound element
at best puts them in the wrong place in the shadow DOM; at worst we've
had exploitable crash issues we had to fix
run into is that the shadow DOM tree can get mutated, which
> makes the actual DOM get out of sync with the data structures that represent
> insertion points (what I think XBL2 calls output ports) and the like).
> After this, adding normal DOM children to the bound element at best puts
&g
On 12/14/10 11:40 AM, Tab Atkins Jr. wrote:
Hmm. I'm not well-versed enough in XBL1 to understand what all the
difficulties are, but what we're envisioning is pretty simple and
shouldn't lead to many problems.
Given a template with some output ports, it's instantiated by cloning
the shadow DOM
final flattened tree". The important bit is that
output ports point to an element which will act as a container for the
normal-DOM nodes, not a position in the tree where the normal-DOM
nodes will be inserted.
Multiple ports sharing the same selector is easy - XBL2 already
handles it. Por
ition of a
particular output port in its parent node.
I'm not sure I understand. Can you elaborate with a trivial example?
I've got a few things in mind that you could possible mean, but I'd
rather not guess.
Using XBL1 syntax, because I can't recall what the XBL2
gt; I'm not sure I understand. Can you elaborate with a trivial example?
>> I've got a few things in mind that you could possible mean, but I'd
>> rather not guess.
>
> Using XBL1 syntax, because I can't recall what the XBL2 one is off the top
> of my he
On 12/14/10 10:08 PM, Tab Atkins Jr. wrote:
Hm, good point. So then, no, there has to be an element in the shadow
DOM that represents an output port, which is then *replaced* with the
appropriate normal-DOM children in the final flattened tree.
So just to make sure we're on the same page... ar
On Tue, Dec 14, 2010 at 10:32 PM, Boris Zbarsky wrote:
> On 12/14/10 10:08 PM, Tab Atkins Jr. wrote:
>>
>> Hm, good point. So then, no, there has to be an element in the shadow
>> DOM that represents an output port, which is then *replaced* with the
>> appropriate normal-DOM children in the final
On Tue, 14 Dec 2010, Boris Zbarsky wrote:
>
> So that in this case there would be a span element in the shadow DOM and
> a different span element in the flattened tree?
As XBL2 is specced currently, the nodes in the explicit DOM and in the
shadow DOM are the same nodes as in
On Wed, Dec 15, 2010 at 1:18 PM, Ian Hickson wrote:
> On Tue, 14 Dec 2010, Boris Zbarsky wrote:
>>
>> So that in this case there would be a span element in the shadow DOM and
>> a different span element in the flattened tree?
>
> As XBL2 is specced currently, the nodes
On Dec 15, 2010, at 11:14 AM, Boris Zbarsky wrote:
>
>
>>> At least in Gecko's case, we still use XBL1 in this way, and those design
>>> goals would apply to XBL2 from our point of view. It sounds like you have
>>> entirely different design goals, rig
On 12/15/10 10:53 PM, Maciej Stachowiak wrote:
Are they really contradictory?
Good question. ;)
If they aren't, great.
Personally, I think it would be a huge win if XBL2-based components could be
more scalable than ones written in pure JavaScript using vanilla DOM calls.
That way,
On Wed, Dec 15, 2010 at 10:53 PM, Maciej Stachowiak wrote:
>
> On Dec 15, 2010, at 11:14 AM, Boris Zbarsky wrote:
>
>>
>>
>>>> At least in Gecko's case, we still use XBL1 in this way, and those design
>>>> goals would apply to XBL2 from our poi
d, with possibly many (tens of thousands) of instantiations of a
given template. Which means that memory usage for each instantiation is
a concern, which is why as much as possible is delegated to the shared
state in the template.
At least in Gecko's case, we still use XBL1 in this way, and thos
te.
> Which means that memory usage for each instantiation is a concern, which is
> why as much as possible is delegated to the shared state in the template.
>
> At least in Gecko's case, we still use XBL1 in this way, and those design
> goals would apply to XBL2 from our point of v
not what happens in our idea - the shadow is
>>> cloned from the template, and then it's the only source of truth.
>>
>> So here's the thing. XBL1 was originally designed as a reusable component
>> model with the idea that the components would actually be reuse
gs that can drift
>>>> out of sync. That's not what happens in our idea - the shadow is
>>>> cloned from the template, and then it's the only source of truth.
>>>
>>> So here's the thing. XBL1 was originally designed as a reusable component
way a caret works in text
controls; that too is an insertion point).
At least in Gecko's case, we still use XBL1 in this way, and those design
goals would apply to XBL2 from our point of view. It sounds like you have
entirely different design goals, right?
Sounds like it.
OK, so gi
being insertion points can happen without being elements.
> For example, an insertion point can be tracked conceptually as a collapsed
> range (e.g. similar to the way a caret works in text controls; that too is
> an insertion point).
>
>>> At least in Gecko's case, we s
o the shadow tree. Does the range go before or after the node?
Is there any way to make this obvious to an author?
I'm not wedded to the "output ports are elements in the shadow DOM"
idea, but I think it's a pretty strong idea.
>>> At least in Gecko's case, we stil
On 12/15/10 11:40 AM, Tab Atkins Jr. wrote:
If all you're doing is moving the output port, why wouldn't all the
associated normal-DOM elements end up in the same place?
Because the new parent of the output port can have a binding attached
itself, which puts them in different output ports under
On 12/15/10 11:29 AM, Dimitri Glazkov wrote:
That seems like an implementation detail. Metadata can be shared and
cloned as needed, just like styles in CSS.
Sort of. It would need to be cloned as soon as the shadow tree is
mutated, right? That seems like very fragile behavior from a web auth
On Thu, Dec 16, 2010 at 10:40 AM, Boris Zbarsky wrote:
> On 12/15/10 11:29 AM, Dimitri Glazkov wrote:
>>
>> That seems like an implementation detail. Metadata can be shared and
>> cloned as needed, just like styles in CSS.
>
> Sort of. It would need to be cloned as soon as the shadow tree is muta
don't mutate the
shadow.
With luck, enough use-cases will be solveable with the declarative
syntax that this will be an acceptable restriction.
Well, at least with XBL1 modifying the shadow tree is very common.
And I would assume that to be rather common with XBL2 too.
-Olli
~TJ
reflect on all
instances, but it you change it here, it won't) seem even more
fragile. That's why Hixie made XBL2's templates always-live, I think.
But I totally get the need of coming up with a solution that doesn't
end up being a memory hog.
:DG<
>
> -Boris
>
luck, enough use-cases will be solveable with the declarative
>> syntax that this will be an acceptable restriction.
>
> Well, at least with XBL1 modifying the shadow tree is very common.
> And I would assume that to be rather common with XBL2 too.
Yes.
>
>
> -Olli
>
>
>>
>> ~TJ
>>
>>
>
>
On 12/16/10 1:00 PM, Dimitri Glazkov wrote:
I agree that it's going to be difficult to get this right, but
semi-live templates (if you change it here, it will reflect on all
instances, but it you change it here, it won't) seem even more
fragile.
Sure. I'm proposing that templates be completely
On Thu, Dec 16, 2010 at 1:33 PM, Boris Zbarsky wrote:
> On 12/16/10 1:00 PM, Dimitri Glazkov wrote:
>>
>> I agree that it's going to be difficult to get this right, but
>> semi-live templates (if you change it here, it will reflect on all
>> instances, but it you change it here, it won't) seem eve
BTW, I moved the use cases page to
http://wiki.whatwg.org/wiki/XBL2UseCases. I ran through the discussion
and attempted to update the wiki with interesting outcomes. Please
feel free to edit/comment.
:DG<
On Thu, Dec 16, 2010 at 1:46 PM, Tab Atkins Jr. wrote:
> On Thu, Dec 16, 2010 at 1:33 PM, B
Hi Tab,
On Fri, Dec 17, 2010 at 6:46 AM, Tab Atkins Jr. wrote:
>> Sure. I'm proposing that templates be completely dead. I'm also proposing
>> that, for a first cut, shadow trees be completely dead (in the "will throw
>> exception if you try to add or remove nodes" sense), unless we can figure
On 12/16/10 6:28 PM, Hajime Morita wrote:
Please let me clarify - which can be done without live-ness?
- 1. Changing the tree structure (adding/removing the child)
No.
- 2. Changing the attributes of the node (via setAttribute() or some
property access)
Yes.
- 3. Changing the style direc
On Thu, Dec 16, 2010 at 6:28 PM, Hajime Morita wrote:
> Hi Tab,
>
> On Fri, Dec 17, 2010 at 6:46 AM, Tab Atkins Jr. wrote:
>>> Sure. I'm proposing that templates be completely dead. I'm also proposing
>>> that, for a first cut, shadow trees be completely dead (in the "will throw
>>> exception i
Boris, Tab, thank you for clarification.
I was confusing template and non-template (content) part of the shadow tree..
For template, it makes sense to let them dead and freeze the structure.
--
morrita
On Sat, Dec 18, 2010 at 2:35 AM, Tab Atkins Jr. wrote:
> On Thu, Dec 16, 2010 at 6:28 PM, Hajim
On 12/16/10 1:46 PM, Tab Atkins Jr. wrote:
On Thu, Dec 16, 2010 at 1:33 PM, Boris Zbarsky wrote:
On 12/16/10 1:00 PM, Dimitri Glazkov wrote:
I agree that it's going to be difficult to get this right, but
semi-live templates (if you change it here, it will reflect on all
instances, but it you
Hi All,
In case you haven't followed this thread (started at [HEAD]), my
extremely short summary is:
1. Hixie, based on discussions with David Hyatt, Tab Atkins and perhaps
some others, created a new Editor's Draft (ED) of XBL2 [XBL-Sep-2010]
that defines the XBL language as pa
Dear all,
Looking at the use cases and the problems the current XBL2 spec is
trying address, I think it might be a good idea to rename it into
something that is less legacy-bound? Hixie already cleverly disguised
the "X" as [X]engamous in the latest draft, and if this spec is to
beco
During WebApps' May 1 discussion about Web Components, a proposal was
made ([1],[2]) to stop work on the XBL2 spec and this is a Call for
Consensus to do do.
If you have any comments or concerns about this CfC, please send them to
public-webapps@w3.org by May 8 at the latest. Pos
quot; was typed in place of "XBL".
This message is in response to
http://lists.w3.org/Archives/Public/public-forms/2010Sep/0005.html
which reads in part
Since XBL2 wasn't getting much traction, I've taken an axe to the spec and
made a number of changes to the spec
t; was typed in place of
"XBL".
This message is in response to
http://lists.w3.org/Archives/Public/public-forms/2010Sep/0005.html
which reads in part
Since XBL2 wasn't getting much traction, I've taken an axe to the
spec and
made a number of changes to the spec
I'm with you :-) I really dislike the current name, and it keeps
reminding me of XBEL, the bookmark exchanging language.
Kenneth
On Tue, Dec 14, 2010 at 10:24 PM, Dimitri Glazkov wrote:
> Dear all,
>
> Looking at the use cases and the problems the current XBL2 spec is
> trying
On Tue, Dec 14, 2010 at 1:24 PM, Dimitri Glazkov wrote:
> Dear all,
>
> Looking at the use cases and the problems the current XBL2 spec is
> trying address, I think it might be a good idea to rename it into
> something that is less legacy-bound? Hixie already cleverly disguised
&
On 12/14/2010 01:24 PM, Dimitri Glazkov wrote:
Dear all,
Looking at the use cases and the problems the current XBL2 spec is
trying address, I think it might be a good idea to rename it into
something that is less legacy-bound? Hixie already cleverly disguised
the "X" as [X]engam
On Dec 14, 2010, at 22:24 , Dimitri Glazkov wrote:
> Looking at the use cases and the problems the current XBL2 spec is
> trying address, I think it might be a good idea to rename it into
> something that is less legacy-bound?
I strongly object. We have a long and proud tradition of
On Thu, 16 Dec 2010 14:51:39 +0100, Robin Berjon wrote:
On Dec 14, 2010, at 22:24 , Dimitri Glazkov wrote:
Looking at the use cases and the problems the current XBL2 spec is
trying address, I think it might be a good idea to rename it into
something that is less legacy-bound?
I strongly
gt;> Looking at the use cases and the problems the current XBL2 spec is
>>> trying address, I think it might be a good idea to rename it into
>>> something that is less legacy-bound?
>>
>> I strongly object. We have a long and proud tradition of perfectly
>> ho
in Berjon wrote:
>>>
>>> On Dec 14, 2010, at 22:24 , Dimitri Glazkov wrote:
>>>>
>>>> Looking at the use cases and the problems the current XBL2 spec is
>>>> trying address, I think it might be a good idea to rename it into
>>>>
On Tue, 1 May 2012, Arthur Barstow wrote:
>
> During WebApps' May 1 discussion about Web Components, a proposal was
> made ([1],[2]) to stop work on the XBL2 spec and this is a Call for
> Consensus to do do.
>
> If this CfC passes, the spec will be republished as a WG No
1 - 100 of 119 matches
Mail list logo
