Re: Fullscreen API

Hi, Dean-

Dean Jackson wrote (on 2/8/11 3:12 PM):
>
> On Feb 8, 2011, at 11:35 AM, Doug Schepers wrote:
>
>> Simon Fraser wrote (on 2/8/11 2:18 PM):
>>>
>>> I agree that CSS or SVG don't seem like the right places for the
>>> fullscreen API. There are some other more script-driven APIs that
>>> fall into the same boat, like the animation proposal:
>>> <http://webstuff.nfshost.com/anim-timing/Overview.html>.
>>>
>>> Web Apps seems most appropriate to me.
>>
>> I've explained already the difficulties of adding them to WebApps
>> WG. We've all seen how time-consuming and painful it is to
>> recharter.
>>
>> If we have the right stakeholder in the FX TF (which we seem to),
>> what is your specific concern about doing them here?  You are
>> speaking about impressions, but facts would be more useful in
>> coming to a decision.
>
> You seem to agree that it probably belongs in WebApps,

No, I can see it being in WebApps, but I can equally see it being in 
HTML, SVG, or CSS.

It is presentational.  To me, the logical place for presentational specs 
is CSS WG, but CSS WG, for whatever reason, doesn't work on APIs much 
(though I think they should, considering how CSS is being used in 
webapps today).


>but that it
> would be frustrating to make that happen because it isn't in the
> charter. So you suggest FX, for which is doesn't seem to fit,

I don't see why it wouldn't fit in the FX TF.  It is presentational, and 
the current participants of the SVG WG have reasonable experience in 
working on APIs.  I really don't see the problem, which is why I asked 
for specific clarification.


>other
> than that group may have the right set of people (I assume simply
> because CSS + SVG gives you many browser vendors), and that a task
> force has a more liberal approach to charters.

No, it's because the SVG and CSS WGs are both going to be rechartering 
within a month or so, so we could explicitly add it to their charters now.


> It seems the answer is to simply create a task force or working group
> with a completely open-ended charter, so that it can do whatever it
> wants. I'm obviously joking.

That seems to be what people want the WebApps WG to do.  As one of the 
Team Contacts for that group, I can say that it doesn't scale... I'm 
having a hard time keeping up with the specs we have now, and others in 
the group have complained to me offlist about the same thing; I'll have 
to track this one too, either way, of course.


> I think if you want the API to be taken seriously it should be in the
> group where it is most appropriate. Not the group where it is most
> convenient.

I believe, and some others seem to agree, that it's just as appropriate 
to work on the Fullscreen API in a CSS-SVG task force as it would be for 
the HTML or WebApps WGs.

Ultimately, the question of whether a spec is "taken seriously" is that 
it got feedback from the right stakeholders, and is being implemented. 
Is there a reason to believe that won't happen in the FX TF?  If so, 
then we should indeed move it somewhere else, but I don't see an easy 
solution, unless it's put in the already-overwhelming HTML5 spec.


> (I partly wonder if the whole WG approach is too heavyweight since
> they cover multiple specifications. Why not have a WG per
> specification? That would allow people to make the IP commitment on a
> much finer grain. I guess that is what Incubator Groups are for, so
> why isn't this an incubator if you're worried about charters?)

Incubators don't carry patent commitments, nor do they work on 
Recommendation Track deliverables.  I agree that it would be good if we 
had a more lightweight approach; I've argued for that before, and been 
shot down every time.

However, there does seem to be some attractor to particular groups, 
whether it's some sort of momentum, or the right 
stakeholders/IP-holders, or some other factor.  For whatever reason (and 
I'd be genuinely curious to know the answer), many companies seem to 
want work to be concentrated in one of a few groups, specifically HTML, 
WebApps, and CSS WGs.  (Some participants even complain about having to 
join a new email list, though there would be no net increase in their 
own email load and a decrease in that of those participants who are only 
on the new list.)

Starting each group from scratch takes quite a lot of effort (writing a 
charter, getting review, having companies do their own internal patent 
review and discussion, finding a chair and team contact, recruiting 
participants, setting up a group page, etc.), and requires getting the 
attention of the right people.  Alternately, we could just have one big 
list, like WHATWG, where everything is discussed; there are advantages 
to that, but it doesn't seem it would be compatible with a fine-grained 
patent commitment.

In any case, I don't want to boil the ocean just to start work on this 
one spec.  I just want to move forward on it.  Rather than use cycles in 
discussing new structures for W3C, or debating which group seems the 
best fit for a spec, I think it would be more productive to discuss 
critical details like who will edit the spec, and determining use cases 
and requirements.

Regards-
-Doug Schepers
W3C Team Contact, SVG, WebApps, and Web Events WGs

Received on Tuesday, 8 February 2011 22:20:41 UTC