[Bug 10902] <video> element needs to support some form of DRM solution

http://www.w3.org/Bugs/Public/show_bug.cgi?id=10902

--- Comment #44 from Shelley Powers <shelleyp@burningbird.net> 2010-10-13 19:20:29 UTC ---
(In reply to comment #43)
> (In reply to comment #41)
> > Please don't take offense at this, but this almost seems like you're saying
> > that we should just wait until the browsers determine what we should have, and
> > then they'll let us add this to a future version of HTML.
> 
> Basically, yes, that's what he's saying.  It's part of the normal spec
> development process for HTML5:
> 
> http://wiki.whatwg.org/wiki/FAQ#Is_there_a_process_for_adding_new_features_to_a_specification.3F
> 
> Interest by some notable implementers is essential in getting things added to
> the spec.  Otherwise you end up speccing things that no one cares about.
> 

True, but there are other groups that are impacted by changes to HTML. We need
implementation, yes, but we can't be constrained to asking five browser
companies their permission on how the web advances.


> > Remember, HTML isn't only consumed by browsers. And browsers aren't the only
> > gatekeeper for the spec.
> 
> If there were a substantial non-browser implementation that was interested,
> that would count too.  But hypothetical implementations that may or may not
> exist don't count.  Otherwise you wind up wasting your time writing a spec that
> almost no one will use in practice.  This is one of the core philosophical
> differences between HTML5 and XHTML2: spec what implementers want to implement,
> nothing more or less.
> 

Not necessarily. We need to also be a little visionary in our outlook, too. We
need to look not only at what we have today, but what we'll have, or need to
have, in a few years.

And what you're saying doesn't match what we have now in HTML5. Tell me, what
browser has implemented color input type? How about the Details element? Yet
many of these have been in HTML5 for over six years. There doesn't seem to be
any expressed concern about unimplemented objects when these were questioned. 

Consistency has always been my primary concern when it comes to specifications.


> > Bugs are not a particularly good place to have general discussions.
> > Unfortunately, with the HTML WG procedures, I'm not sure what other venue is
> > available for these discussions to take place.
> 
> public-html is the correct place within the HTML WG.  The whatwg list would
> also work, although of course that's part of the WHATWG and not the W3C. 
> However, you aren't going to make progress without a specific proposal, or list
> of goals and detailed explanation of the use-case, drafted with the input of
> someone who wants to implement it in a major implementation -- most likely a
> browser.

I agree that the email list would be okay, and one can also use
public-html-comment, in order to invite those who are not part of the HTML WG.
However, this approach has been discouraged by the HTML WG co-chairs, so John
has taken about the only approach he can--he submitted a bug.

I can agree on a more detailed use case and specific suggestions, but I don't
agree that we have to then ask, pretty please, permission of the browser
companies in order to submit the idea to the group. I would hate that the W3C
become nothing more than a rubber stamp tool to the five browser companies. It
wouldn't serve the needs of the community if it did.

This has been marked as WONTFIX. John, are you going to add the TrackerRequest
keyword?

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Wednesday, 13 October 2010 19:20:32 UTC