Re: Behavior Attachment Redux, was Re: HTML element content models vs. components

On Tue, 11 Oct 2011, Erik Arvidsson wrote: > > I think one thing that is missing from this table/proposal is how the > prototype chain is hooked up. > > For the permanent case I would like to see the user defined object on > that chain. > > > function FancyButton () {} > // registration and what

Re: Behavior Attachment Redux, was Re: HTML element content models vs. components

On Tue, 11 Oct 2011, Dimitri Glazkov wrote: > On Tue, Oct 11, 2011 at 11:25 AM, Erik Arvidsson wrote: > > By splitting I meant (and I think Ian did as well) that we have > > decorators that does not change the interface and then we have > > components which can change the shadow tree and define a

Re: Behavior Attachment Redux, was Re: HTML element content models vs. components

On Tue, Oct 11, 2011 at 11:25 AM, Erik Arvidsson wrote: > By splitting I meant (and I think Ian did as well) that we have > decorators that does not change the interface and then we have > components which can change the shadow tree and define a new interface > (API). > > The decorators can be att

Re: Behavior Attachment Redux, was Re: HTML element content models vs. components

By splitting I meant (and I think Ian did as well) that we have decorators that does not change the interface and then we have components which can change the shadow tree and define a new interface (API). The decorators can be attached and detached at runtime using css and maybe even an imperative

Re: Behavior Attachment Redux, was Re: HTML element content models vs. components

On Tue, 11 Oct 2011, Tab Atkins Jr. wrote: > On Tue, Oct 11, 2011 at 10:01 AM, Dimitri Glazkov > wrote: > > On Mon, Oct 10, 2011 at 4:55 PM, Erik Arvidsson wrote: > >> Splitting this up into two different things is great. > > > > The specific meaning of "splitting up" is where the things get > >

Re: Behavior Attachment Redux, was Re: HTML element content models vs. components

On Tue, 11 Oct 2011, Dimitri Glazkov wrote: > On Mon, Oct 10, 2011 at 4:55 PM, Erik Arvidsson wrote: > > Splitting this up into two different things is great. > > The specific meaning of "splitting up" is where the things get > interesting. As far as I understand Hixie's idea, the component (whic

Re: Behavior Attachment Redux, was Re: HTML element content models vs. components

On Tue, Oct 11, 2011 at 10:01 AM, Dimitri Glazkov wrote: > On Mon, Oct 10, 2011 at 4:55 PM, Erik Arvidsson wrote: >> Splitting this up into two different things is great. > > The specific meaning of "splitting up" is where the things get > interesting. As far as I understand Hixie's idea, the com

Re: Behavior Attachment Redux, was Re: HTML element content models vs. components

On Mon, Oct 10, 2011 at 4:55 PM, Erik Arvidsson wrote: > Splitting this up into two different things is great. The specific meaning of "splitting up" is where the things get interesting. As far as I understand Hixie's idea, the component (which exposes API) and the binding (which supplies shadow

Re: Behavior Attachment Redux, was Re: HTML element content models vs. components

On Tue, 11 Oct 2011, Roland Steiner wrote: > On Tue, Oct 11, 2011 at 04:58, Ian Hickson wrote: > > > > On Tue, 4 Oct 2011, Roland Steiner wrote: > > > On a second note, what you essentially seem to demand is swapping > > > out entire HTML sub-branches based on presentation. > > > > It's not how

Re: Behavior Attachment Redux, was Re: HTML element content models vs. components

On Tue, Oct 11, 2011 at 04:58, Ian Hickson wrote: > On Tue, 4 Oct 2011, Roland Steiner wrote:> On a second note, what you > essentially seem to demand is swapping out > > entire HTML sub-branches based on presentation. > > It's not how I would describe it (I wouldn't expect the shadow trees to be

Re: Behavior Attachment Redux, was Re: HTML element content models vs. components

On Mon, 10 Oct 2011, Charles Pritchard wrote: > > Will I be writing the following: > Hopefully not, on two counts: First, you should reuse if it's a button, as in: Secondly, I would presume whatever solution we use for shadow tree definitions would be where you put all the roles. If we

Re: Behavior Attachment Redux, was Re: HTML element content models vs. components

On Mon, 10 Oct 2011, Dirk Pranke wrote: > On Wed, Sep 28, 2011 at 4:52 PM, Ian Hickson wrote: > > If an author invents a new element, it doesn't matter what it inherits > > from. It won't have fallback behaviour, it won't have semantics that > > can be interpreted by search engines and accessibi

Re: Behavior Attachment Redux, was Re: HTML element content models vs. components

On Wed, Sep 28, 2011 at 4:52 PM, Ian Hickson wrote: > If an author invents a new element, it doesn't matter what it inherits > from. It won't have fallback behaviour, it won't have semantics that can > be interpreted by search engines and accessibility tools, it won't have > default renderings, an

Re: Behavior Attachment Redux, was Re: HTML element content models vs. components

On Mon, 10 Oct 2011, Erik Arvidsson wrote: > > Splitting this up into two different things is great. > > Allowing attaching an alternative shadow tree through CSS but disabling > any JS to be run seems like the right thing to do. You wouldn't want to disable any JS. Just the API defining aspects

Re: Behavior Attachment Redux, was Re: HTML element content models vs. components

On 10/10/2011 4:55 PM, Erik Arvidsson wrote: Splitting this up into two different things is great. Allowing attaching an alternative shadow tree through CSS but disabling any JS to be run seems like the right thing to do. I'm also in favor of the "is" attribute. Even though I think that is mo

Re: Behavior Attachment Redux, was Re: HTML element content models vs. components

Splitting this up into two different things is great. Allowing attaching an alternative shadow tree through CSS but disabling any JS to be run seems like the right thing to do. I'm also in favor of the "is" attribute. Even though I think that is more readable than it is hard to argue about the

Re: Behavior Attachment Redux, was Re: HTML element content models vs. components

On Tue, 4 Oct 2011, Roland Steiner wrote: > On Tue, Oct 4, 2011 at 12:38 PM, Ian Hickson wrote: > > > > * Any case of taking an element with existing semantics (e.g. a > > showing a list of countries) and replacing its presentation with > > something completely different (e.g. a map selecto

Re: Behavior Attachment Redux, was Re: HTML element content models vs. components

On 10/3/11 5:32 AM, Roland Steiner wrote: ... Cons: - harder to implement: there's a window during parsing (before reading the button) where it's still an ordinary button, requiring binding to be added afterwards I assume you meant "before setting the attribute"? I think working around th

Re: Behavior Attachment Redux, was Re: HTML element content models vs. components

On Tue, Oct 4, 2011 at 12:38 PM, Ian Hickson wrote: > * Any case of taking an element with existing semantics (e.g. a > showing a list of countries) and replacing its presentation with > something completely different (e.g. a map selector), where the exact > binding could depend based on

Re: Behavior Attachment Redux, was Re: HTML element content models vs. components

On Fri, 30 Sep 2011, Dominic Cooney wrote: > > > > My point was just that the parsing differences have nothing to do with > > whether you're creating a component that inherits from HTMLElement. > > There are parsing issues regardless of where in the DOM you are. > > Parsing issues which disappea

Re: Behavior Attachment Redux, was Re: HTML element content models vs. components

Is x-mywidget necessarily more performant? Why? On Oct 3, 2011 5:33 AM, "Roland Steiner" wrote: > > If I may briefly summarize the pros and cons of every approach discussed: > > > > Pros: > - element name is inherently immutable > - can provide arbitrary API, can (but does not have to) derive f

Re: Behavior Attachment Redux, was Re: HTML element content models vs. components

If I may briefly summarize the pros and cons of every approach discussed: Pros: - element name is inherently immutable - can provide arbitrary API, can (but does not have to) derive from arbitrary HTML element - best performance (in instantiation, CSS selector matching) Cons: - accessibility onl

Re: Behavior Attachment Redux, was Re: HTML element content models vs. components

On Fri, Sep 30, 2011 at 12:36 PM, Ian Hickson wrote: > On Thu, 29 Sep 2011, Tab Atkins Jr. wrote: > > On Thu, Sep 29, 2011 at 7:05 PM, Dominic Cooney > wrote: > > > OK. > > > > > > I understand and are different in the respect of > > > automatically closing p-s. > > > > > > Is this a serious p

Re: Behavior Attachment Redux, was Re: HTML element content models vs. components

On Thu, 29 Sep 2011, Dimitri Glazkov wrote: > > c) an API to manipulate the layout programmatically (turn page, advance > to next panel, etc.) [...] > > Once you're operating on the layout programmatically, you need logical > primitives that explain and expose the functionality of a layout manag

Re: Behavior Attachment Redux, was Re: HTML element content models vs. components

On Thu, 29 Sep 2011, Tab Atkins Jr. wrote: > On Thu, Sep 29, 2011 at 7:05 PM, Dominic Cooney wrote: > > OK. > > > > I understand and are different in the respect of > > automatically closing p-s. > > > > Is this a serious problem? It seems like if you want the p to be > > closed, you can write ;

Re: Behavior Attachment Redux, was Re: HTML element content models vs. components

On Thu, Sep 29, 2011 at 7:05 PM, Dominic Cooney wrote: > OK. > > I understand and are different in the respect of > automatically closing p-s. > > Is this a serious problem? It seems like if you want the p to be > closed, you can write ; if you insist on getting the parser to > close it, you can

Re: Behavior Attachment Redux, was Re: HTML element content models vs. components

OK. I understand and are different in the respect of automatically closing p-s. Is this a serious problem? It seems like if you want the p to be closed, you can write ; if you insist on getting the parser to close it, you can use . Dominic On Fri, Sep 30, 2011 at 10:53 AM, Tab Atkins Jr. wro

Re: Behavior Attachment Redux, was Re: HTML element content models vs. components

On Thu, Sep 29, 2011 at 6:38 PM, Dominic Cooney wrote: > So, to make this really explicit: > > div’s default display is block, but x-div’s default display is inline. > > Is there anything else that I missed? Not quite. has auto-closing behavior around several of the existing elements. It does

Re: Behavior Attachment Redux, was Re: HTML element content models vs. components

So, to make this really explicit: div’s default display is block, but x-div’s default display is inline. Is there anything else that I missed? Looking at use cases , most of them would like to be block, or at maybe inline-block. One philoso

Re: Behavior Attachment Redux, was Re: HTML element content models vs. components

>> If you're talking about bz's second e-mail, then consider cases such as: >> >>   Foo >>   Bar >> >> ...vs: >> >>   Foo >>   Bar > > Can you be a bit more specific and explain the problem you're trying > to highlight with this example? http://software.hixie.ch/utilities/js/live-dom-viewer/sa

Re: Behavior Attachment Redux, was Re: HTML element content models vs. components

On Wed, Sep 28, 2011 at 4:52 PM, Ian Hickson wrote: > > On Wed, 28 Sep 2011, Dimitri Glazkov wrote: > > On Wed, Sep 28, 2011 at 3:54 PM, Ian Hickson wrote: > > > On Wed, 28 Sep 2011, Dimitri Glazkov wrote: > > > > On Wed, Sep 28, 2011 at 3:21 PM, Ian Hickson wrote: > > > > > On Wed, 28 Sep 2011,

Dynamic behavior attachment does not work, subtyping elements could work (Was: Re: Behavior Attachment Redux, was Re: HTML element content models vs. components)

Hixie wrote: … The pure JS side of things, which is all that is needed for what we're talking about here, needs nothing more than just adding a prototype, something which is not only well-supported by all browsers, but defined in increasingly careful detail. Interoperability is only improving her

Re: Behavior Attachment Redux, was Re: HTML element content models vs. components

On 9/28/11 7:02 PM, Ian Hickson wrote: There are specific problems in both those cases because of interaction with the C++ layer, as far as I can tell. Those are there, sure. But they're not the only problems... The pure JS side of things, which is all that is needed for what we're talking

Re: Behavior Attachment Redux, was Re: HTML element content models vs. components

On 9/28/11 6:54 PM, Ian Hickson wrote: Yes, for instance. Basically any use cases that is about presentation rather than logic. Do such use cases need to expose new API on the element? -Boris

Re: Behavior Attachment Redux, was Re: HTML element content models vs. components

On Wed, 28 Sep 2011, Dimitri Glazkov wrote: > On Wed, Sep 28, 2011 at 3:54 PM, Ian Hickson wrote: > > On Wed, 28 Sep 2011, Dimitri Glazkov wrote: > > > On Wed, Sep 28, 2011 at 3:21 PM, Ian Hickson wrote: > > > > On Wed, 28 Sep 2011, Dimitri Glazkov wrote: > > > > > > > > > > I think new elements

Re: Behavior Attachment Redux, was Re: HTML element content models vs. components

On Wed, Sep 28, 2011 at 3:54 PM, Ian Hickson wrote: > > On Wed, 28 Sep 2011, Dimitri Glazkov wrote: > > On Wed, Sep 28, 2011 at 3:21 PM, Ian Hickson wrote: > > > On Wed, 28 Sep 2011, Dimitri Glazkov wrote: > > > > > > > > I think new elements are completely fine as long as they are > > > > inheri

Re: Behavior Attachment Redux, was Re: HTML element content models vs. components

On Wed, 28 Sep 2011, Boris Zbarsky wrote: > On 9/28/11 4:02 PM, Ian Hickson wrote: > > I don't buy the argument that an element's API can't change. > > To be more precise, such changes are very undesirable. > > > We have many counter-examples already in the platform, for > > example's API can ch

Re: Behavior Attachment Redux, was Re: HTML element content models vs. components

On Wed, 28 Sep 2011, Dimitri Glazkov wrote: > On Wed, Sep 28, 2011 at 3:21 PM, Ian Hickson wrote: > > On Wed, 28 Sep 2011, Dimitri Glazkov wrote: > > > > > > I think new elements are completely fine as long as they are > > > inheriting directly from HTMLElement. It's when we start dealing > > >

Re: Behavior Attachment Redux, was Re: HTML element content models vs. components

On Wed, Sep 28, 2011 at 3:21 PM, Ian Hickson wrote: > > On Wed, 28 Sep 2011, Dimitri Glazkov wrote: > > > > I think new elements are completely fine as long as they are inheriting > > directly from HTMLElement. It's when we start dealing with sub-typing > > HTMLTableElement and such is when they g

Re: Behavior Attachment Redux, was Re: HTML element content models vs. components

On Wed, 28 Sep 2011, Dimitri Glazkov wrote: > > I think new elements are completely fine as long as they are inheriting > directly from HTMLElement. It's when we start dealing with sub-typing > HTMLTableElement and such is when they get into trouble. New elements are not fine, for reasons that

Re: Behavior Attachment Redux, was Re: HTML element content models vs. components

> transitive APIs. Blergh! "TRANSIENT", not transitive. :DG<

Re: Behavior Attachment Redux, was Re: HTML element content models vs. components

On Wed, Sep 28, 2011 at 1:02 PM, Ian Hickson wrote: > On Wed, 28 Sep 2011, Dimitri Glazkov wrote: >> >> Hi Ian! :) >> >> I already enumerated and hopefully addressed most of your concerns in >> http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/1156.html >> and >> http://lists.w3.org/Ar

Re: Behavior Attachment Redux, was Re: HTML element content models vs. components

On 9/28/11 4:02 PM, Ian Hickson wrote: I don't buy the argument that an element's API can't change. To be more precise, such changes are very undesirable. We have many counter-examples already in the platform, for example's API can change dynamcially as it loads new plugins This is actually

Re: Behavior Attachment Redux, was Re: HTML element content models vs. components

On Wed, 28 Sep 2011, Dimitri Glazkov wrote: > > Hi Ian! :) > > I already enumerated and hopefully addressed most of your concerns in > http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/1156.html > and > http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/1187.html, > but

Re: Behavior Attachment Redux, was Re: HTML element content models vs. components

On 9/28/11 2:55 PM, Dimitri Glazkov wrote: So, this is really a parsing issue, right? Parsing is one side of the issue, yes. Only matters for declarative markup, of course. Hixie, is this the same problem you were mentioned as "doesn't have fallback behavior"? I would assume Hixie is als

Re: Behavior Attachment Redux, was Re: HTML element content models vs. components

On Wed, Sep 28, 2011 at 11:30 AM, Boris Zbarsky wrote: > On 9/28/11 2:24 PM, Dimitri Glazkov wrote: >> >> Can you help me understand what the issues with fallback are? > > Sure.  If I want to attach a component to a and to do that I have to > write: > >   >    Content >   > > and somewhere before

Re: Behavior Attachment Redux, was Re: HTML element content models vs. components

On 9/28/11 2:24 PM, Dimitri Glazkov wrote: Can you help me understand what the issues with fallback are? Sure. If I want to attach a component to a and to do that I have to write: Content and somewhere before that point register that x-my-table should be treated as a table, the

Re: Behavior Attachment Redux, was Re: HTML element content models vs. components

On Wed, Sep 28, 2011 at 11:19 AM, Boris Zbarsky wrote: > On 9/28/11 2:08 PM, Dimitri Glazkov wrote: >> >> So, we need a way to express in markup that a particular element is to >> be created with a particular behavior. > > Yes. > >> Since the tagName is the only >> identifying property of a DOM el

Re: Behavior Attachment Redux, was Re: HTML element content models vs. components

On 9/28/11 2:08 PM, Dimitri Glazkov wrote: So, we need a way to express in markup that a particular element is to be created with a particular behavior. Yes. Since the tagName is the only identifying property of a DOM element that can't be changed, this brings us to... custom tag names. Or

Behavior Attachment Redux, was Re: HTML element content models vs. components

> The way to solve this is not to change the content models, it's to use an > actual and bind it to the component. We should not have authors > inventing new elements. It doesn't have fallback behaviour, it doesn't > have semantics that can be interpreted by search engines and accessibility > tool