On Mon, 10 Oct 2011, Dirk Pranke wrote:
On Wed, Sep 28, 2011 at 4:52 PM, Ian Hickson i...@hixie.ch 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
On Mon, 10 Oct 2011, Charles Pritchard wrote:
Will I be writing the following:
div is=button role=button
Hopefully not, on two counts:
First, you should reuse button if it's a button, as in:
button is=fancybutton
Secondly, I would presume whatever solution we use for shadow tree
On Tue, Oct 11, 2011 at 04:58, Ian Hickson i...@hixie.ch 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
On Tue, 11 Oct 2011, Roland Steiner wrote:
On Tue, Oct 11, 2011 at 04:58, Ian Hickson i...@hixie.ch 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
On Mon, Oct 10, 2011 at 4:55 PM, Erik Arvidsson a...@chromium.org 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
On Tue, Oct 11, 2011 at 10:01 AM, Dimitri Glazkov dglaz...@chromium.org wrote:
On Mon, Oct 10, 2011 at 4:55 PM, Erik Arvidsson a...@chromium.org 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
On Tue, 11 Oct 2011, Dimitri Glazkov wrote:
On Mon, Oct 10, 2011 at 4:55 PM, Erik Arvidsson a...@chromium.org 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
On Tue, 11 Oct 2011, Tab Atkins Jr. wrote:
On Tue, Oct 11, 2011 at 10:01 AM, Dimitri Glazkov dglaz...@chromium.org
wrote:
On Mon, Oct 10, 2011 at 4:55 PM, Erik Arvidsson a...@chromium.org wrote:
Splitting this up into two different things is great.
The specific meaning of splitting up
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
On Tue, Oct 11, 2011 at 11:25 AM, Erik Arvidsson a...@chromium.org 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
On Tue, 11 Oct 2011, Dimitri Glazkov wrote:
On Tue, Oct 11, 2011 at 11:25 AM, Erik Arvidsson a...@chromium.org 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
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.
script
function FancyButton () {}
// registration and whatevs
On Tue, 4 Oct 2011, Roland Steiner wrote:
On Tue, Oct 4, 2011 at 12:38 PM, Ian Hickson i...@hixie.ch wrote:
* Any case of taking an element with existing semantics (e.g. a select
showing a list of countries) and replacing its presentation with
something completely different (e.g. a
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
x-foo is more readable than div is=foo it is hard to
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
x-foo
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.
On Wed, Sep 28, 2011 at 4:52 PM, Ian Hickson i...@hixie.ch 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
On 10/3/11 5:32 AM, Roland Steiner wrote:
button IS=MYWIDGET
...
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
On Tue, Oct 4, 2011 at 12:38 PM, Ian Hickson i...@hixie.ch wrote:
* Any case of taking an element with existing semantics (e.g. a select
showing a list of countries) and replacing its presentation with
something completely different (e.g. a map selector), where the exact
binding could
If I may briefly summarize the pros and cons of every approach discussed:
X-MYWIDGET
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:
-
Is x-mywidget necessarily more performant? Why?
On Oct 3, 2011 5:33 AM, Roland Steiner rolandstei...@google.com wrote:
If I may briefly summarize the pros and cons of every approach discussed:
X-MYWIDGET
Pros:
- element name is inherently immutable
- can provide arbitrary API, can (but
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 disappear
On Wed, Sep 28, 2011 at 4:52 PM, Ian Hickson i...@hixie.ch wrote:
On Wed, 28 Sep 2011, Dimitri Glazkov wrote:
On Wed, Sep 28, 2011 at 3:54 PM, Ian Hickson i...@hixie.ch wrote:
On Wed, 28 Sep 2011, Dimitri Glazkov wrote:
On Wed, Sep 28, 2011 at 3:21 PM, Ian Hickson i...@hixie.ch wrote:
If you're talking about bz's second e-mail, then consider cases such as:
pFoo
div Bar /div
...vs:
pFoo
x-div Bar /x-div
Can you be a bit more specific and explain the problem you're trying
to highlight with this example?
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
http://wiki.whatwg.org/wiki/Component_Model_Use_Cases, most of them
would like to be block, or at maybe inline-block.
One
On Thu, Sep 29, 2011 at 6:38 PM, Dominic Cooney domin...@google.com 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. p has auto-closing behavior around several of the
existing
OK.
I understand div and x-foo 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 /p; if you insist on getting the parser to
close it, you can use div becomes=x-foo.
Dominic
On Fri, Sep 30, 2011 at
On Thu, Sep 29, 2011 at 7:05 PM, Dominic Cooney domin...@google.com wrote:
OK.
I understand div and x-foo 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 /p; if you insist on getting the parser
On Thu, 29 Sep 2011, Tab Atkins Jr. wrote:
On Thu, Sep 29, 2011 at 7:05 PM, Dominic Cooney domin...@google.com wrote:
OK.
I understand div and x-foo 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,
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 manager
On Fri, Sep 30, 2011 at 12:36 PM, Ian Hickson i...@hixie.ch wrote:
On Thu, 29 Sep 2011, Tab Atkins Jr. wrote:
On Thu, Sep 29, 2011 at 7:05 PM, Dominic Cooney domin...@google.com
wrote:
OK.
I understand div and x-foo are different in the respect of
automatically closing p-s.
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
On Wed, Sep 28, 2011 at 11:19 AM, Boris Zbarsky bzbar...@mit.edu 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
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 table and to do that I
have to write:
x-my-table
trtdContent/td/tr
x-my-table
and somewhere before that point register that
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 also
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 I am
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 exampleobject's API
can change dynamcially as it loads new plugins
This is
On Wed, Sep 28, 2011 at 1:02 PM, Ian Hickson i...@hixie.ch 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
transitive APIs.
Blergh! TRANSIENT, not transitive.
:DG
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
On Wed, 28 Sep 2011, Dimitri Glazkov wrote:
On Wed, Sep 28, 2011 at 3:21 PM, Ian Hickson i...@hixie.ch 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
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
exampleobject's API can
On Wed, Sep 28, 2011 at 3:54 PM, Ian Hickson i...@hixie.ch wrote:
On Wed, 28 Sep 2011, Dimitri Glazkov wrote:
On Wed, Sep 28, 2011 at 3:21 PM, Ian Hickson i...@hixie.ch wrote:
On Wed, 28 Sep 2011, Dimitri Glazkov wrote:
I think new elements are completely fine as long as they are
On Wed, 28 Sep 2011, Dimitri Glazkov wrote:
On Wed, Sep 28, 2011 at 3:54 PM, Ian Hickson i...@hixie.ch wrote:
On Wed, 28 Sep 2011, Dimitri Glazkov wrote:
On Wed, Sep 28, 2011 at 3:21 PM, Ian Hickson i...@hixie.ch wrote:
On Wed, 28 Sep 2011, Dimitri Glazkov wrote:
I think new
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
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
Hixie wrote:
snip
… 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
47 matches
Mail list logo
