On Sat, Sep 3, 2011 at 4:31 AM, Anne van Kesteren ann...@opera.com wrote:
On Fri, 02 Sep 2011 20:47:27 +0200, Dimitri Glazkov dglaz...@chromium.org
wrote:
BTW, I really ought to put this fears list on the Wiki.
Yeah that would probably be a good idea.
Done:
On Sat, Sep 3, 2011 at 8:20 PM, Ian Hickson i...@hixie.ch wrote:
On Sat, 3 Sep 2011, Dominic Cooney wrote:
I think the XBL approach is far superior here -- have authors use
existing elements, and use XBL to augment them. For example, if you
want the user to select a country from a map,
On 7/09/11 7:20 AM, Alex Russell wrote:
On Sat, Sep 3, 2011 at 8:20 PM, Ian Hicksoni...@hixie.ch wrote:
On Sat, 3 Sep 2011, Dominic Cooney wrote:
I think the XBL approach is far superior here -- have authors use
existing elements, and use XBL to augment them. For example, if you
want the user
On Sun, Sep 4, 2011 at 1:56 PM, Dimitri Glazkov dglaz...@chromium.orgwrote:
The offsetWidth query could've triggered an event
handler execution
I don't think offsetWidth should be able to trigger synchronous execution
of an event listener in the content. How would that happen?
Rob
--
If we
On 3/09/11 4:47 AM, Dimitri Glazkov wrote:
On Fri, Sep 2, 2011 at 2:30 AM, Anne van Kesterenann...@opera.com wrote:
Examples of elements that should not be replaced but could be changed by a
binding: Having a sortable binding fortable; Exposing cite= on
blockquote; Turning aselect listing
On Fri, 02 Sep 2011 20:47:27 +0200, Dimitri Glazkov
dglaz...@chromium.org wrote:
Fear 6: Accessibility. Accessibility! Accessibility!?
I contend that the Component Model does not make accessibility any
worse. And likely the opposite.
By allowing ATs to traverse into shadow subtrees, and
On 9/2/2011 6:39 PM, Alex Russell wrote:
Similarly, WCAG is a series of principles for designing usable, high quality
applications.
ARIA presents a set of semantic roles that don't exist in HTML, and
for those, alignment with custom element implementations is
outstanding. Components that
On Tue, 30 Aug 2011, Dominic Cooney wrote:
I'm proposing we add something that lets script extend the set of tag
names, so there is less of a bright line between elements defined in the
HTML spec and elements defined in script. Something like:
HTMLElement.register('x-contacts',
On Fri, 2 Sep 2011, Anne van Kesteren wrote:
What we need is not a becomes= attribute (that renames an element and
therefore forgoes its semantics) but rather a way to get complete
control over a semantic element and tweak aspects of it. Otherwise
creating such controls is prohibitively
On Sat, Sep 3, 2011 at 12:04 PM, Ian Hickson i...@hixie.ch wrote:
On Tue, 30 Aug 2011, Dominic Cooney wrote:
I'm proposing we add something that lets script extend the set of tag
names, so there is less of a bright line between elements defined in the
HTML spec and elements defined in script.
On Sat, Sep 3, 2011 at 12:08 PM, Ian Hickson i...@hixie.ch wrote:
On Fri, 2 Sep 2011, Anne van Kesteren wrote:
What we need is not a becomes= attribute (that renames an element and
therefore forgoes its semantics) but rather a way to get complete
control over a semantic element and tweak
On Sat, 3 Sep 2011, Dominic Cooney wrote:
I think the XBL approach is far superior here -- have authors use
existing elements, and use XBL to augment them. For example, if you
want the user to select a country from a map, you can use a select
with a list of countries in option
Be careful with the big words. It can't be that inferior if it
satisfies use cases that XBL2 can't.
:DG
On Sat, Sep 3, 2011 at 8:20 PM, Ian Hickson i...@hixie.ch wrote:
On Sat, 3 Sep 2011, Dominic Cooney wrote:
I think the XBL approach is far superior here -- have authors use
existing
On Sat, Sep 3, 2011 at 8:20 PM, Ian Hickson i...@hixie.ch wrote:
On Sat, 3 Sep 2011, Dominic Cooney wrote:
I think the XBL approach is far superior here -- have authors use
existing elements, and use XBL to augment them. For example, if you
want the user to select a country from a map,
On Wed, 31 Aug 2011 19:29:28 +0200, Dimitri Glazkov
dglaz...@chromium.org wrote:
To put it differently, you want to start with a well-known element in
markup, and, through the magic of computing, this element _becomes_
your component in the DOM tree. In other words, the markup:
button
On Fri, Sep 2, 2011 at 2:30 AM, Anne van Kesteren ann...@opera.com wrote:
On Wed, 31 Aug 2011 19:29:28 +0200, Dimitri Glazkov dglaz...@chromium.org
wrote:
To put it differently, you want to start with a well-known element in
markup, and, through the magic of computing, this element _becomes_
Since Dimitri has already said everything I would, and better, I just
want to very quickly second his point about where we are today vs.
where we fear we might be: non-trivial apps have *already* given up on
HTML. Suggesting that there's an un-semantic future that will be
*caused* by the component
On 9/2/11 12:10 PM, Alex Russell wrote:
Since Dimitri has already said everything I would, and better, I just
want to very quickly second his point about where we are today vs.
where we fear we might be: non-trivial apps have *already* given up on
HTML. Suggesting that there's an un-semantic
On 9/2/11 3:00 PM, Alex Russell wrote:
On Fri, Sep 2, 2011 at 1:40 PM, Charles Pritchardch...@jumis.com wrote:
On 9/2/11 12:10 PM, Alex Russell wrote:
Since Dimitri has already said everything I would, and better, I just
want to very quickly second his point about where we are today
On Fri, Sep 2, 2011 at 3:58 PM, Charles Pritchard ch...@jumis.com wrote:
On 9/2/11 3:00 PM, Alex Russell wrote:
On Fri, Sep 2, 2011 at 1:40 PM, Charles Pritchardch...@jumis.com wrote:
On 9/2/11 12:10 PM, Alex Russell wrote:
Since Dimitri has already said everything I would, and better, I
Splitting off to its own thread, because this deserves a good discussion.
On Wed, Aug 31, 2011 at 12:00 AM, Anne van Kesteren ann...@opera.com wrote:
On Wed, 31 Aug 2011 07:33:16 +0200, Dominic Cooney domin...@chromium.org
wrote:
Thanks for reading this far! These proposals aren't formal or
On Wed, Aug 31, 2011 at 10:29 AM, Dimitri Glazkov dglaz...@chromium.org wrote:
I will write up the exact algorithm in a wiki shortly.
Here it is: http://wiki.whatwg.org/wiki/Component_Model_Progressive_Enhancement
:DG
On Tue, Aug 30, 2011 at 10:33 PM, Dominic Cooney domin...@chromium.org wrote:
Components (see
http://wiki.whatwg.org/wiki/Component_Model_Use_Cases for examples of
what I mean) need to present an API to script. For example, a
contacts component might want to expose a refresh() method that
On Tue, Aug 30, 2011 at 10:33 PM, Dominic Cooney domin...@chromium.org wrote:
Components (see
http://wiki.whatwg.org/wiki/Component_Model_Use_Cases for examples of
what I mean) need to present an API to script. For example, a
contacts component might want to expose a refresh() method that
On Wed, Aug 31, 2011 at 1:38 PM, Erik Arvidsson a...@chromium.org wrote:
On Tue, Aug 30, 2011 at 22:33, Dominic Cooney domin...@chromium.org wrote:
You will notice that this says nothing about how prototypes are wired
up. It should. Maybe the argument to extend should have an optional
second
Referencing a note dated 2003 may not sound strong any more - web-based
applications (or to be more specific - their UI) have evolved significantly
since the date. Today limiting developers to an extremely low level markup
API, such as SVG or HTML only leads to huge, hardly manageable JavaScript
26 matches
Mail list logo
