Re: Mutation events replacement

[Tab Atkins Jr.]

On Fri, Jul 8, 2011 at 6:55 AM, Sean Hogan  wrote:
> On 8/07/11 10:21 PM, Sean Hogan wrote:
>> - ARIA support in JS libs currently involves updating aria-attributes to
>> be appropriate to behavior the lib is implementing. Attribute mutation
>> listeners would allow an inverse approach - behaviors being triggered off
>> changes to aria-attributes.
>
> As has been mentioned, listening for attribute mutations is horrendously
> inefficient because your handler has to receive every mutation, even if only
> interested in one attribute.

This is a limitation of current mutation events.  We don't have to
repeat this mistake.  Allowing a script to listen for changes to a
specific attribute is a big low-hanging fruit.

~TJ

Re: Element.create(): a proposal for more convenient element creation

[Tab Atkins Jr.]

On Mon, Aug 1, 2011 at 7:05 PM, Charles Pritchard  wrote:
> Can we have it 'inherit' a parent namespace, and have chaining properties?
>
> Element.create('div').create('svg').create('g').create('rect', {title: 'An 
> svg rectangle in an HTML div'});

Ooh, so .create is defined both on Element (defaults to HTML
namespace, just creates an element) and on Element.prototype (defaults
to namespace of the element, inserts as a child)?  That's pretty
interesting.  Presumably the new element gets inserted as a last child
of the parent.

I like it.

~TJ

Re: Element.create(): a proposal for more convenient element creation

[Tab Atkins Jr.]

On Mon, Aug 1, 2011 at 8:52 PM, João Eiras  wrote:
> On , Tab Atkins Jr.  wrote:
>
>> On Mon, Aug 1, 2011 at 7:05 PM, Charles Pritchard  wrote:
>>>
>>> Can we have it 'inherit' a parent namespace, and have chaining
>>> properties?
>>>
>>> Element.create('div').create('svg').create('g').create('rect', {title:
>>> 'An svg rectangle in an HTML div'});
>>
>> Ooh, so .create is defined both on Element (defaults to HTML
>> namespace, just creates an element) and on Element.prototype (defaults
>> to namespace of the element, inserts as a child)?  That's pretty
>> interesting.  Presumably the new element gets inserted as a last child
>> of the parent.
>>
>> I like it.
>>
>
> While the idea is interesting, "create" is a too simple name to add on
> something as polluted as Element.
>
> I wonder if there is enough demand for this kind of chained coding to
> actually spec an API for this. I've rarely seen it being used, plus the
> notable exception that is jquery code.
>
> Perhaps createChild, would be better, but then one would need to
> differentiate Elements from Text.

createChild works for me too.  The important part is the chaining; it
makes it slightly terser and easier to read than nesting
Element.create() calls.

~TJ

Re: Element.create(): a proposal for more convenient element creation

[Tab Atkins Jr.]

On Tue, Aug 2, 2011 at 12:36 AM, Jonas Sicking  wrote:
> I'm not sure if it's better to include the children as a var-args
> list, or as an array. Certainly when typing things normally var-args
> saves you the "[" and "]", but when coding, if you've built the child
> list dynamically and have an array, you have to make awkward .apply
> calls.

Read again - the idea is to auto-expand arrays.

(I don't have much of a preference between "just use an array" and
"use varargs, but expand arrays".  I agree that using only varargs
without expansion would be bad.)

~TJ

Re: Element.create(): a proposal for more convenient element creation

[Tab Atkins Jr.]

On Tue, Aug 2, 2011 at 9:48 AM, Aryeh Gregor  wrote:
> On Mon, Aug 1, 2011 at 9:33 PM, Maciej Stachowiak  wrote:
>> In an IRC discussion with Ian Hickson and Tab Atkins, we can up with the
>> following idea for convenient element creation:
>> Element.create(tagName, attributeMap, children…)
>>    Creates an element with the specified tag, attributes, and children.
>
> How does this compare to popular JS helper libraries like jQuery?  It
> would be useful to know what convenience APIs authors are using now
> before introducing our own.

jQuery's element creation is basically driven by innerHTML.  That is,
to create an element, you just make a call like "$('')".
I doubt that's a pattern we actually want to copy, as it's kinda
dirty, and inconvenient in some cases.  (For example, to apply a bag
of properties as attributes, you have to first create the element,
then call attr() on it.  You can't pass the attrs as an initial arg
without string-building.)

Prototype's element creation is almost identical to what is proposed
here, except it uses something that looks like a constructor.  You
create an element with "new Element('p',{class:'foo'})".  You can't
set children as part of the initial call; they have to be appended in
later calls.

MooTools is basically identical to Prototype, except that you can
additionally set listeners on the element during creation by using a
magical "events" property in the attribute bag, which takes an object
of event names and functions.  This would be nice to look into adding.

Dojo uses a factory method fairly similar to what's proposed (with the
same name, even - Dojo.create()).  Its first two arguments are the
tagname and an attribute bag, same as the proposal.  Its next two
arguments are used to set a parent node and offset within that parent
node, for automatic DOM insertion after creation.  I don't think it's
valuable to have this in the constructor, though the facilities that
the libraries offer for easier DOM insertion should definitely be
looked at separately.

I think those are the major libraries to pay attention to.  It looks
like jQuery's model is probably not something we want to emulate,
while the other three libraries are almost identical to this proposal.
 The one thing I suggest looking into is the ability to set listeners
on an element during creation, like MooTools allows.

~TJ

Re: Element.create(): a proposal for more convenient element creation

[Tab Atkins Jr.]

On Tue, Aug 2, 2011 at 11:26 AM, Glenn Maynard  wrote:
> On Tue, Aug 2, 2011 at 2:18 PM, Tab Atkins Jr.  wrote:
>> MooTools is basically identical to Prototype, except that you can
>> additionally set listeners on the element during creation by using a
>> magical "events" property in the attribute bag, which takes an object
>> of event names and functions.  This would be nice to look into adding.
>
> Is this much better than just saying eg. Element.create("a", {href:
> "http://link";, onclick: function(e) { ... } }, "link"}?

Hmm, is everything exposed as on* attributes now?  If so, then yeah,
just do that; no need to mess around with a magic property in the
attributes bag.

~TJ

Re: Element.create(): a proposal for more convenient element creation

[Tab Atkins Jr.]

On Wed, Aug 3, 2011 at 8:46 AM, Glenn Maynard  wrote:
> On Wed, Aug 3, 2011 at 3:34 AM, Anne van Kesteren  wrote:
>> On Tue, 02 Aug 2011 20:31:04 +0200, Tab Atkins Jr. 
>> wrote:
>>> Hmm, is everything exposed as on* attributes now?  If so, then yeah,
>>> just do that; no need to mess around with a magic property in the
>>> attributes bag.
>>
>> This would still be magical as it is setting an IDL attribute rather than
>> a content attribute.
>
> What's the difference?  I'd expect this:
>
> a = Element.create("a", {href: "http://link";, onclick: function(e) { },
> custom: "value" }, "link");
>
> to be essentially equivalent to
>
> a = document.createElement("a");
> a.appendChild(document.createTextNode("link"));
> attrs = {href: "http://link";, onclick: function(e) { }, custom: "value" };
> for(key in attrs) a[key] = attrs[key];

Yes, because there you're setting the IDL attributes.  Anne's assuming
that the intended virtual implementation instead has this as the final
line:

for(key in attrs) a.setAttribute(key,attrs[key]);

This would obviously produce a different result here, as the function
would be stringified into something useless.

For most attributes, there's no difference between the two approaches,
but a handful have significant differences.

~TJ

Re: Element.create(): a proposal for more convenient element creation

[Tab Atkins Jr.]

On Wed, Aug 3, 2011 at 12:34 AM, Anne van Kesteren  wrote:
> On Tue, 02 Aug 2011 20:31:04 +0200, Tab Atkins Jr. 
> wrote:
>> On Tue, Aug 2, 2011 at 11:26 AM, Glenn Maynard  wrote:
>>> On Tue, Aug 2, 2011 at 2:18 PM, Tab Atkins Jr. 
>>> wrote:
>>>> MooTools is basically identical to Prototype, except that you can
>>>> additionally set listeners on the element during creation by using a
>>>> magical "events" property in the attribute bag, which takes an object
>>>> of event names and functions.  This would be nice to look into adding.
>>>
>>> Is this much better than just saying eg. Element.create("a", {href:
>>> "http://link";, onclick: function(e) { ... } }, "link"}?
>>
>> Hmm, is everything exposed as on* attributes now?  If so, then yeah,
>> just do that; no need to mess around with a magic property in the
>> attributes bag.
>
> This would still be magical as it is setting an IDL attribute rather than a
> content attribute.

Hmm.  onclick is a content attribute, no?  Or do you just mean that
assigning a function directly (rather than a string of code) is
something that can only be done via an IDL attribute?

If so, then good point, but I also expect that this wouldn't be very confusing.

~TJ

Re: Element.create(): a proposal for more convenient element creation

[Tab Atkins Jr.]

On Sat, Aug 6, 2011 at 9:05 AM, Dominic Cooney  wrote:
> Third, is the order of attributes significant for XML namespace
> declarations? eg does this:
> 
> mean the same thing as
> 
> ? If not, including namespaces in the attribute dictionary is fraught,
> because the iteration order of properties is undefined.

The order is unimportant when setting them via markup, but important
when setting them via successive setAttribute calls.  I'd prefer that
the attribute bag be handled like markup attributes, where xmlns
attributes are handled "early" so that later attributes fall into the
correct namespace.

~TJ

Re: Element.create(): a proposal for more convenient element creation

[Tab Atkins Jr.]

On Mon, Aug 8, 2011 at 1:17 AM, Jonas Sicking  wrote:
> Is there a reason to support namespaced attributes at all? They are
> extremely rare, especially on the web.
>
> Ideally I'd like to deprecate them, but I suspect that's not doable.
> But I see no reason to support them in new APIs.

SVG requires namespaced attributes for xlink, at least.  We're
planning to get rid of that in SVG2, but for now it would be
necessary.

We could, of course, just say "Too bad, don't write things that need
the xlink namespace, and wait for SVG2 to get rid of them".  I don't
think this would be very bad.

~TJ

Re: Mouse Lock

[Tab Atkins Jr.]

On Thu, Aug 11, 2011 at 10:14 PM, Robert O'Callahan
 wrote:
> If your implementation had to warp the mouse cursor on Windows to get
> accurate delta information, the mouse position in the existing mouse
> events would no longer be very meaningful and a new event type seemed
> more logical. But assuming Klaas is right, we no longer need to worry
> about this. It seems we can unconditionally add delta information to
> existing mouse events. So I withdraw that comment.

I suspect that, while locked, we still don't actually want to expose
the various x and y properties for the mouse.  I agree with Vincent
that the *other* mouseevent properties are all useful, though, and
that the delta properties are really useful in non-mouselock
situations.

We should just zero all the position information.  Even if we can
switch all OSes to a delta mode, the position will be arbitrary and
meaningless.  This seems easier than making a new type of mouse event
that exposes all of normal mouse events except the position, and
ensuring that the two stay in sync when we add new info.

~TJ

Re: Mouse Lock

[Tab Atkins Jr.]

On Fri, Aug 12, 2011 at 1:19 PM, Jonas Sicking  wrote:
> On Fri, Aug 12, 2011 at 9:53 AM, Tab Atkins Jr.  wrote:
>> On Thu, Aug 11, 2011 at 10:14 PM, Robert O'Callahan
>>  wrote:
>>> If your implementation had to warp the mouse cursor on Windows to get
>>> accurate delta information, the mouse position in the existing mouse
>>> events would no longer be very meaningful and a new event type seemed
>>> more logical. But assuming Klaas is right, we no longer need to worry
>>> about this. It seems we can unconditionally add delta information to
>>> existing mouse events. So I withdraw that comment.
>>
>> I suspect that, while locked, we still don't actually want to expose
>> the various x and y properties for the mouse.  I agree with Vincent
>> that the *other* mouseevent properties are all useful, though, and
>> that the delta properties are really useful in non-mouselock
>> situations.
>>
>> We should just zero all the position information.  Even if we can
>> switch all OSes to a delta mode, the position will be arbitrary and
>> meaningless.  This seems easier than making a new type of mouse event
>> that exposes all of normal mouse events except the position, and
>> ensuring that the two stay in sync when we add new info.
>
> If we expose delta information in all mouse events, which seems like
> it could be a good idea, then what is the usecase for the success
> callback for mouselock?
>
> I was under the impression that that was so that the page could start
> treating mousemove events differently, but if all mousemove events
> have deltas, then that won't be needed, no?

No, it's still definitely needed.  You can't do an FPS with non-locked
deltas; the user will end up moving their mouse off the screen.

The use-cases for delta-without-mouselock are pretty separate from
those for delta-within-mouselock.

~TJ

Re: Mouse Lock

[Tab Atkins Jr.]

On Fri, Aug 12, 2011 at 2:06 PM, Jonas Sicking  wrote:
> On Fri, Aug 12, 2011 at 1:54 PM, Tab Atkins Jr.  wrote:
>> On Fri, Aug 12, 2011 at 1:19 PM, Jonas Sicking  wrote:
>>> If we expose delta information in all mouse events, which seems like
>>> it could be a good idea, then what is the usecase for the success
>>> callback for mouselock?
>>>
>>> I was under the impression that that was so that the page could start
>>> treating mousemove events differently, but if all mousemove events
>>> have deltas, then that won't be needed, no?
>>
>> No, it's still definitely needed.  You can't do an FPS with non-locked
>> deltas; the user will end up moving their mouse off the screen.
>>
>> The use-cases for delta-without-mouselock are pretty separate from
>> those for delta-within-mouselock.
>
> Sure, I wasn't saying that mouselock wasn't needed. I was asking what
> the use case for the 'success' callback to the mouseLock was.

So you can tell that you're locked.  Without that assurance, you can't
do a game using WASD+mouselook, because if the mouse isn't locked the
user will end up scrolling out of your active area.  You'll have to
make sure the mouse is actually locked *somehow*; might as well be via
a success callback.

~TJ

Re: Mouse Lock

[Tab Atkins Jr.]

On Fri, Aug 12, 2011 at 3:14 PM, Jonas Sicking  wrote:
> And if the user doesn't approve the lock you do what? Not let them
> play your game?

Maybe.  It really is impossible to play a game with a control scheme
based on WASD+mouselook if you can't get a lock.

Alternately, you can switch to a different (less good) control scheme
if you can't acquire a lock.  This is not acceptable behavior for the
default case, though.  WASD+mouselook is a very entrenched and natural
control scheme; anything else will  be much harder to use.

The difference isn't always quite this extreme; sometimes the
experience is only moderately degraded, instead of majorly, if you
can't get a lock.  For example, edge scrolling in StarCraft,
Civilization, or similar games is really useful.  You could play the
game without it, it would just be annoying.  (The gamedev would have
to implement some other way to do scrolling, either a modifier key +
arrows, or dedicating the drag action to scrolling, or similar.)

~TJ

Re: xdash name prefixes (was Re: Component Model Update)

[Tab Atkins Jr.]

On Wed, Aug 24, 2011 at 5:12 PM, Adam Barth  wrote:
> On Wed, Aug 24, 2011 at 2:30 PM, Dominic Cooney  wrote:
>> On Thu, Aug 25, 2011 at 2:03 AM, Dimitri Glazkov  
>> wrote:
>>> On Tue, Aug 23, 2011 at 9:19 PM, Adam Barth  wrote:
 This section 
 says "When an unknown DOM element with an "x-"-prefixed tagName is
 encountered ...".  It seems unfortunate to special-case tag names that
 begin with "x-".  The IETF has a lot of experience with "x-" prefixes,
 and they're somewhat unhappy with them:

 http://tools.ietf.org/html/draft-saintandre-xdash
>>>
>>> I can't seem to draw a parallel between prefixing author-defined
>>> custom DOM elements and prefixing HTTP parameters -- other than the
>>> prefix itself, that is. There's a clear meaning of the prefix in the
>>> Component Model -- this element was defined by an author.
>>> Additionally, we are explicitly trying to avoid a registry-like
>>> situation, where one has to announce or qualify for the right to use a
>>> tag name. Can you help me understand what your concerns are?
>>
>> That RFC is interesting, but I didn’t find it a perfect parallel either.
>>
>> In protocol headers, clients and servers need to agree on the meaning
>> of headers, and require migration from non-standard to standard
>> headers with attendant interoperability issues. Components are
>> different, because both the x-name and its definition are under
>> control of the author. The intent is that if HTML standardizes an
>> x-name, it will be christened with the un-prefixed name; the UA can
>> continue supporting old x-names and definitions using the generic
>> component mechanism.
>>
>> I guess we could get into interoperability difficulties if user agents
>> start to rely on specific x-names and ignoring or augment their
>> definitions. For example, if a crawler ignores the scripts that define
>> components but interpret a common x-name a particular way. Or if a
>> browser automatically augments the definition of a given x-name for
>> better security or accessibility.
>
> Yeah, the parallel breaks down a bit because in HTTP the "X-" names
> are used by two parties and here we're only talking about one party.
> Maybe a better parallel is data attributes, which are also segmented
> into their own namespace...

Yes, the data-* attributes are the correct thing to draw parallels to here.


> On the other hand, it seems likely that some of these xdash names will
> come into multi-party use.  For example, the following use cases
> involve xdash names chosen by one party and then used by another:
>
> http://wiki.whatwg.org/wiki/Component_Model_Use_Cases#Widget_Mix-and-Match
> http://wiki.whatwg.org/wiki/Component_Model_Use_Cases#Contacts_Widget
> http://wiki.whatwg.org/wiki/Component_Model_Use_Cases#Like.2F.2B1_Button
>
> That's something like 40% of the use cases...

These are fine as well; the important case where prefixing causes
problems is when one of the parties is the browser itself, where it
will eventually want to change from recognizing the prefixed name to
recognizing the unprefixed name.

~TJ

Re: Component Model Update

[Tab Atkins Jr.]

On Thu, Aug 25, 2011 at 1:41 AM, Olli Pettay  wrote:
> One thing missing is some kind of declarative way to define
> shadow trees, similar to XBL1's .
>
> It would be rather strange if one needs to explicitly construct
> shadow tree after the element is created.

I know we plan to add a declarative syntax similar to XBL, but the
scripted syntax gets into the details better, so it's better to focus
on that first.  It's also easy, when you start from a declarative
solution, to accidentally build in magic that's hard to replicate
imperatively.  Starting from imperative has similar risks, but I think
they're easier to manage.

~TJ

Re: RfC: how to organize the DOM specs [Was: CfC: publish new WD of DOM Core]

[Tab Atkins Jr.]

On Sun, Sep 4, 2011 at 6:12 AM, Arthur Barstow  wrote:
> Hi All,
>
> Thanks for the comments and discussion! I finally reviewed all of the
> responses and here are my thoughts on moving forward ...
>
> Some members of the group consider the D3E spec as the highest priority of
> our DOM-related specs and they have put considerable resources into that
> spec. Doug and Jacob will continue to lead that spec effort, and as I
> understand it, a CR for D3E is imminent. I expect the group to help progress
> that spec.
>
> At the same time, others members have put substantial resources into DOM
> Core (and closely related functionality such as DOM Range). Naturally, they
> want to preserve that investment and I support that work continuing.

I would like to publicly register that I find the sentiment expressed
in the above paragraphs (regarding the work editors have put into the
spec) as deeply troubling.

I am also a spec editor.  I, reasonably, do not want a spec I have
poured substantial time into to be discarded.  However, my desires in
this regard have *absolutely no bearing on whether or not it's a good
idea to do so, and should not be taken as an input to the decision.

The editor is the *lowest* level in the hierarchy of constituencies.
*Everything* else matters more, and that's as it should be.  I
respectfully request that the amount of work an editor has put into a
spec never again be referenced in a discussion about whether to
continue working on a spec or not.  We should make these kinds of
decisions *solely* on technical grounds.

(Art, I meant to say this last time you brought up the amount of work
Doug and Jacob put into D3E, but I procrastinated so much that it
would have been weird to bring it up by the time I was ready to say
something.  Thanks for giving me the opportunity to speak up again.)

~TJ

Re: RfC: how to organize the DOM specs [Was: CfC: publish new WD of DOM Core]

[Tab Atkins Jr.]

On Tue, Sep 6, 2011 at 4:32 AM, Arthur Barstow  wrote:
> On 9/5/11 3:34 PM, ext Tab Atkins Jr. wrote:
>>
>> We should make these kinds of
>> decisions *solely* on technical grounds.
>
> Well surely making decisions on technical grounds is important. However, it
> seems a bit simplistic to consider it the only factor. (I seem to recall
> some previous decisions were based, for example, on existing implementations
> and deployments.)

I consider those technical grounds.  Existing implementation and
deployment usually affects the viability of a feature.

Even if you disagree on the particulars, it's clearly more technical
than personal.  There's a clear difference between that and an
editor's personal attachment to their work.

~TJ

Re: Reference to the HTML specification

[Tab Atkins Jr.]

On Tue, Sep 6, 2011 at 11:32 AM, Charles Pritchard  wrote:
> Lets get a public version repository on the official w3c website. They
> pulled off incorporating bugzilla, surely they can pull off incorporating
> git. It's quite easy.

We have them.

dev.w3.org is the older CSS repository (still used by many groups,
such as the CSSWG).  dvcs.w3.org is the newer Hg repository.

Both repos are public.

~TJ

Re: [editing] Using public-webapps for editing discussion

[Tab Atkins Jr.]

On Fri, Sep 16, 2011 at 10:44 AM, Charles Pritchard  wrote:
> Yes, you have a public domain document, and yes, you're likely in the same
> boat as Tab Atkins:
> http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/1265.html
> "The editor is the *lowest* level in the hierarchy of constituencies"
>
> The "vendor" implementation is the highest level... Your company has the
> full vertical.

Incorrect.  Browsers are below authors, who are below users.  The full
hierarchy of constituencies that I and several others subscribe to is:

1. Users
2. Authors
3. Implementors
4. Spec Authors / Theoretical Purity (these two levels are close
enough that they're not really useful to distinguish, I think)


> They use that position to knock-down use cases. When a use case serves
> Google Docs, or Gmail, it's heard. When it does not, it's shuttered.

That's quite a forceful statement.  It's also completely untrue.  For
example, I have never talked to the Gmail team about my work.  I've
talked to Docs, but only about CSSOM measurement APIs because it's
hard to gather concrete use-cases for some of these things even though
they're obviously useful.

I would appreciate not being publicly slandered in the future.

~TJ

Re: Notes from a component model pow-wow

[Tab Atkins Jr.]

On Tue, Sep 20, 2011 at 7:47 PM, Boris Zbarsky  wrote:
> A comment on use cases that was brought up over here.
>
> There's a use case that is not addressed by XBL1 and impossible to quite
> address in a JS library that goes as follows.  Say you have some data in a
> .  Semantically it's a data table.  But you may want to present it as
> a graphic (SVG or canvas).
>
> XBL1 will let you construct a block or inline box for the  and then
> stick a shadow tree containing just an  or  inside. But it
> would be nicer if that wrapper block/inline box were not there and if the
> box that were created were just the  or  box...  So
> effectively, treating the element the component is attached to as a
>  element in terms of box tree construction.
>
> Is this a use case we want to address?

I think this is properly a CSS issue.  You want an element to not
exist in the box tree, but to still have its children in the tree,
which should be controllable with a display value, perhaps called
'transparent'.  It's a more complex version of display:none.

This sort of functionality would be useful outside of this specific
use-case as well.  For example, it seems that the most natural and
easy way to handle the  element is to produce a shadow
wrapper around its non- contents.  That way, one can do a
simple "details:not(:open) > magic-wrapper { display: none; }".  But
you don't want this wrapper to show up and interfere with styling when
the  is open.  display:transparent would help here.

~TJ

Re: Adding Web Intents to the Webapps WG deliverables

[Tab Atkins Jr.]

On Thu, Sep 22, 2011 at 3:28 PM, James Hawkins  wrote:
> When designing the format of the Web Intents action string, we got a lot of
> feedback that the java namespacing is not native to the web and that URLS
> would be a better namespacing scheme.  This gave us the added benefit that,
> by setting precedence with the default list actions, action URLs serve both
> as a namespace mechanism and the page at the URL contains documentation for
> the particular action.  If a developer wants to find out more about
> http://webintents.org/share, all she has to do is visit that URL (try it!).
> If, for example, Twitter decided to add a new action, say 'tweet', they
> could set the action string to http://dev.twitter.com/tweet which would
> contain the input/output specification for this action.

URLs are really, really not a good namespacing mechanism, because URLs
are not names in practice.  Names are compared with string-equality,
generally.  URLs are compared  as URLs, which is a lot crazier.  Is
"http://dev.twitter.com/tweet"; the same action as
"http://dev.twitter.com/tweet/";?  What about
"https://dev.twitter.com/tweet"; or "//dev.twitter.com/tweet" or
"/tweet" (assume this last one is on a page within dev.twitter.com)?
There's a decent chance that all of these are considered "the same
url" by devs, and devs will probably attempt to use them.  I haven't
even mentioned yet the presence/absence of "www" in urls.

Will this mistake be caught when it doesn't work?  Some of the time,
yeah.  A lot of devs won't go through and test every intent they add.
Even if they do, they may just test with the same incorrect URL they
registered with, and then be bewildered when they're not getting the
traffic they think they should be (and it's even worse for users, who
thought they let the page register for tweeting, but it only works
some of the time, when other devs accidentally use the same incorrect
url).

~TJ

Re: Adding Web Intents to the Webapps WG deliverables

[Tab Atkins Jr.]

On Fri, Sep 23, 2011 at 1:13 PM, Julian Reschke  wrote:
>> There's a decent chance that all of these are considered "the same
>> url" by devs, and devs will probably attempt to use them.  I haven't
>> even mentioned yet the presence/absence of "www" in urls.
>
> Contrary to what you say, I don't see anybody confused by URI comparison
> when URIs are used as identifiers.

It's hard to say "willful blindness" without sounding mean, so I'll
just point and nod at Boris' email.

~TJ

Re: Adding Web Intents to the Webapps WG deliverables

[Tab Atkins Jr.]

On Fri, Sep 23, 2011 at 2:20 PM, Julian Reschke  wrote:
> Namespace names are things I copy from templates and never type from memory.

Exactly, which means namespaces aren't memorable.  The only reason to
give up memorability is if you require the name to be both
collision-free and context-free (see Zooko's Triangle).  Both of those
are nice (as they always are), but they're not really required for a
workable namespace.  Giving up memorability for no real benefit is a
loss all around.

In the specific case of intents, the same applies.  We don't need them
to be securely collision-free (collisions are slightly annoying for
the user, but should be fairly rare in practice, and can be resolved
by the user without a lot of trouble).  They should be context-free,
as they apply across the whole web.  And they should be memorable,
because authors have to type these and they get non-memorable things
wrong.

~TJ

Re: Mutation Observers: a replacement for DOM Mutation Events

[Tab Atkins Jr.]

On Fri, Sep 23, 2011 at 2:16 PM, Adam Klein  wrote:
> [Constructor(in MutationCallback callback)]
> interface MutationObserver {
>   void observe(in Node target, in MutationObserverOptions options);
>   void disconnect();
> };

It would be nice to have both of these return the MutationObserver
rather than void, so you can chain calls.

~TJ

Re: Mutation Observers: a replacement for DOM Mutation Events

[Tab Atkins Jr.]

On Fri, Sep 23, 2011 at 4:46 PM, Adam Klein  wrote:
> On Fri, Sep 23, 2011 at 4:44 PM, Tab Atkins Jr.  wrote:
>> On Fri, Sep 23, 2011 at 2:16 PM, Adam Klein  wrote:
>>> [Constructor(in MutationCallback callback)]
>>> interface MutationObserver {
>>>   void observe(in Node target, in MutationObserverOptions options);
>>>   void disconnect();
>>> };
>>
>> It would be nice to have both of these return the MutationObserver
>> rather than void, so you can chain calls.
>
> I don't think that makes sense for disconnect() (at least the version
> specced here), since it stops observation of all nodes so chaining
> wouldn't make sense.  But I definitely see that chaining observe could
> be convenient.

// Resetting the observation list
observer
  .disconnect()
  .observe(node1,{...})
  .observe(node2,{...});

~TJ

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

[Tab Atkins Jr.]

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 not auto-close for components, though.

It has nothing to do with 'display' - it's an effect of parsing.

~TJ

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

[Tab Atkins Jr.]

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 use .

I agree that it's not a serious problem, and that it's trivial to fix
for yourself.  There's no legacy pain, either.

~TJ

Re: Question about implementing DataTransfer.addElement

[Tab Atkins Jr.]

On Fri, Oct 7, 2011 at 2:45 PM, Daniel Cheng  wrote:
> For technical reasons, animating the drag image is non-trivial and not
> likely to be implemented in the near future, if it is ever implemented.

I would think that it's basically identical, technically, to
implementing the element() function from CSS Image Values, which I
believe we're planning to do.

~TJ

Re: Question about implementing DataTransfer.addElement

[Tab Atkins Jr.]

On Fri, Oct 7, 2011 at 3:18 PM, Daniel Cheng  wrote:
> The way drag images work today is we take a snapshot and then hand it off to
> the system. To support addElement(), we'd need:
> 1. Some way to detect when that element has changed in visual appearance so
> we can update the drag image.
> 2. Some way to actually update the drag image in the middle of a drag. This
> is (as far as I'm aware) impossible with the documented interface for
> Windows DnD, and I'm not aware of an undocumented way to do it either.
> I'm more concerned about the latter, and while I don't believe it's
> impossible to solve, I think it would be difficult to make performant in
> case of things like video or other embedded content.

Ah, I wasn't aware that we simply handed the image off to the system
and let it handle the drag.  Ignore my message, then.

~TJ

Re: Mutation Observers: a replacement for DOM Mutation Events

[Tab Atkins Jr.]

On Mon, Oct 10, 2011 at 7:51 PM, Sean Hogan  wrote:
> On 24/09/11 7:16 AM, Adam Klein wrote:
>> - Is free of the faults of the existing Mutation Events mechanism
>> (enumerated in detail here:
>> http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/0779.html)
>
> A simpler solution that is free from the faults listed in that email would
> be to have (at max) one mutation observer for the whole page context. I
> guess this would be called at the end of the task or immediately before page
> reflows.
>
> If a js lib (or multiple libs) want to provide finer grained mutation
> handling then let them work out the details.

That seems unworkably restrictive.  It's very easy to imagine multiple
libraries listening for different kinds of things at the same time.
Libraries would just end up re-implementing event distribution, which
is something we can avoid by doing it correctly now.

~TJ

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

[Tab Atkins Jr.]

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 component (which
> exposes API) and the binding (which supplies shadow tree) aren't
> coupled, which means they can share no internal state. For example,
> you can't close over a set of event listeners that interact with
> shadow DOM in a component method, because the listeners are applied
> separately. I don't think that's workable.
>
> It seems to me that  we should have a way to create a shadow DOM
> subtree inside of the component -- component's own tree (aka element
> behavior attachment).
>
> Then, there could be a separate method to decorate a component with
> one additional shadow tree using CSS (aka decorator behavior
> attachment).
>
> The component model is explicitly interested in the former, not the latter.

Agreed.  Having the shadow tree entirely separate from the component
is explicitly bad in many cases.  It prevents you from doing native
implementation of many of the shadow-using HTML elements, like , which need to hook the controls markup together with the
scripting.

Being able to decorate an element with a script-free shadow tree
declaratively might be useful, but it's separate from the component
use-cases.

~TJ

Re: QSA, the problem with ":scope", and naming

[Tab Atkins Jr.]

On Tue, Oct 18, 2011 at 4:46 PM, Sean Hogan  wrote:
> On 19/10/11 7:20 AM, Yehuda Katz wrote:
>>
>> I agree entirely.
>>
>> I have asked a number of practitioner friends about this scenario:
>>
>> 
>> Content
>> 
>>
>>  document.getElementById("child").querySelectorAll("div span"); // returns
>> #inline
>>
>> In 100% of cases, people consider this behavior *broken*. Not just
>> "interesting, I wouldn't have expected that", but "who came up with that!?".
>> In all cases involving JavaScript practitioners, people expect
>> querySelectorAll to operate on the element as though the element was the
>> root of a new document, and where combinators are relative to the element.
>>
>
> It matches the definition of CSS selectors, so I don't think it can be
> called broken. For this case, node.querySelectorAll("div span") finds all
> span's (in document order) which are contained within the invoking node and
> checks that they match the selector expression, in this case simply checking
> they are a descendant of a div.
>
> The new definition being promoted is:
> - start at the containing node
> - find all descendant div's
> - for every div, find all descendant span's.
> - with the list of span's, remove duplicates and place in document-order
>
> Once you understand the proper definition it is hard to see this new
> definition as more logical.
> To me, the problem here is some (not all) Javascript practitioners not
> learning the proper definition of CSS selectors.

Not at all.  I'm not sure why you think this is somehow an "improper"
way to think about things.

There are two ways you can "scope" a selector.  The first is to filter
the results of a selector match to only those under a certain element
(what QSA does today).  The second is to scope the entire selector to
only apply underneath the scoping element, which is what Alex is
proposing.

An alternative view of this is that current QSA restricts the final
compound selector in a selector to match only elements in the scope,
while allowing the rest of the selector to match elements anywhere in
the document.  Alex's proposal (and every other JS selector engine)
restricts all of the selector component to matching only elements in
the scope.

There is nothing unnatural or improper about this.  The fact that
every JS selector engine works in the latter fashion, and that JS devs
are regularly surprised by the former behavior, suggests strongly that
the latter behavior is the better default behavior.

Based on discussion on the mailing list, 

Re: QSA, the problem with ":scope", and naming

[Tab Atkins Jr.]

On Wed, Oct 19, 2011 at 5:17 AM, Lachlan Hunt  wrote:
> 1. Syntax
>
> In , selectors still can't begin with a combinator, but in the
> proposed API, they can.

I agree with Lachy here.  I think it's valuable to have consistency
with