Re: Fullscreen API

Honestly, I don't really care, but I don't see your justification.

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.

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

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

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

You keep saying "It is presentational" so I'll keep saying "No, it's not. It's an API".

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.

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

Again, let's find the correct place, not the most convenient.

>> 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 :)

Some may logically have agreed that it is just as appropriate in FX as it is in HTML, only because they don't think it belongs in either. You could have equally said the responses claim it is just as appropriate in FX as it is in the Party Planning Committee of the Australian W3C office.

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

> Incubators don't carry patent commitments, 

...

> 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? Do you think they'll mind you writing another deliverable into their charters? Will this new work slow down existing things?

Dean

Received on Tuesday, 8 February 2011 22:58:15 UTC