Re: Fullscreen API

Hi, Dean-

Dean Jackson wrote (on 2/8/11 5:57 PM):
> Honestly, I don't really care, but I don't see your justification.

If you don't care, why are we spending time on this?


> On Feb 8, 2011, at 2:20 PM, Doug Schepers wrote:
>
>>> 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.
>
> Let's think about this.
>
> HTML - so fullscreen only applies to HTML elements? SVG - fullscreen
> is vector graphics, or only applies to SVG elements? CSS - fullscreen
> is styling, and is somehow part of the CSS language?
>
> It's pretty clear fullscreen is an API, and belongs in whatever group
> is doing APIs.

All 3 of those groups are doing APIs.

Any group could specify an API that an implementer could apply to the
Element and Document interfaces for any language.  For example, the
Element Traversal specification, done by the WebApps WG, doesn't
explicitly limit itself to any particular markup; it can apply to any of
them.  Some parts of the HTML5 spec are being applied to SVG content with
no problem.  It's all one platform.  A modular spec needs to take 
multiple languages into account as a use case, but that's going to apply 
no matter where it happens.


>> 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).
>
> No, it's not presentational, at least in the way the term is used at
> W3C.

It is about the presentation of the content.  You seem to associate the 
term "presentational" with a particular kind of markup (CSS presumably); 
I don't think that's a useful distinction, but I can simple say that it 
affects the presentation of the element, if that suits you better. 
(This is the same position Al McDonald has taken [1]).


>  It's an API. If you read the document you linked to
> (https://wiki.mozilla.org/Gecko:FullScreenAPI) you'll see that it
> talks about scripts, events, security options, new methods on the
> Document interface and the transition to fullscreen. Right at the end
> it mentions a CSS pseudo class.

The CSS WG is working on the CSS OM.  That's an API.


> That last bit is the only thing that is "presentational" - the
> elements in a document potentially changing their presentation based
> on the fact that the browser is fullscreen. This is actually
> orthogonal to fullscreen itself (this could equally be exposed as a
> media query).

Yes, it could.


> This isn't about reasonable experience. This is about finding the
> correct place for the work, given the W3C process. The SVG working
> group isn't the correct place for an API you expect to expose to
> every Web page. Same goes for FX.

You keep saying that, but you haven't said why.


>> 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.
>
> Again, let's find the correct place, not the most convenient.

What are the criteria you are using for "the right place"?  An explicit 
answer to this would help us move forward.


>>> 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.
>
> Every public response you received disagreed that it should be in the
> FX task force! At least three have suggested WebApps. I'm not sure
> what email list you're reading :)

Three people from Apple have suggested moving it to WebApps; I've also 
heard an offlist preference (before I started this thread) to that 
effect as well.

At least two people have publicly commented that they think this should 
be done in CSS, Alistair MacDonald [1] and João Eiras [2].  I've heard 
others suggest the same offlist.


>> 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.
>
> You seem to be suggesting that you want to ignore the W3C Process and
> put specs where the "right stakeholders" are.

What part of the W3C Process am I'm ignoring?  What is wrong with 
finding the right stakeholders... isn't that what we should be doing, to 
make sure it has adequate review?


>> 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.
>
> I think this is the problem. We (probably) all want to move onto the
> work stage, but there unfortunately are things that need to be sorted
> out before that can happen. Do you expect all the CSS and SVG WG
> participants to be happy with this new patent commitment?

Not necessarily.  That's why I sent this email (and come to that, I 
should probably send it separately to the SVG and CSS WGs).  If we are 
talking about concerns about patent commitments, that's a different 
conversation than where it "belongs".

I wouldn't expect Apple to have patent concerns about this, since you 
are suggesting moving it to the WebApps WG, where Apple is also a 
member, but if you do, your AC rep should contact the me or someone else 
from the W3C team.

Obviously, the same goes for any other member of these groups.


> Do you  think they'll mind you writing another deliverable into their
> charters?

Again, that's the question I'm putting to these groups.


>  Will this new work slow down existing things?

I don't see why it would slow down any other work here as opposed to 
some other group, such as WebApps.  In every group, it's usually a 
subset of the group that works on a particular spec.


[1] http://lists.w3.org/Archives/Public/public-fx/2011JanMar/0068.html
[2] http://lists.w3.org/Archives/Public/public-webapps/2011JanMar/0436.html


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

Received on Tuesday, 8 February 2011 23:42:30 UTC