This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
If < video > is to see widespread adoption by commercial content providers, then there must be a means to support some form of native filtering system (aka Parental Controls) that content producers can use
I formally object to adding this.
<img> has no parental control, and neither do text nodes, even though both can and do contain material that parents might want to control.
Do Flash, Silverlight, or other competing video delivery technologies provide a built-in parental controls mechanism?
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Rejected Change Description: no spec change Rationale: The parental control mechanism is for the parent to be responsible for their kid.
(In reply to comment #4) > > Status: Rejected > Change Description: no spec change > Rationale: The parental control mechanism is for the parent to be responsible > for their kid. Now that the kids have had their little childish chuckle can we get back to real technical discussions please? This bug was not filed for the amusement of a gaggle of engineers - it is a legitimate and appropriate question and issue, and one that the W3C has dealt with previously. The W3C already has a means to deliver this requirement: POWDER (http://www.w3.org/2007/powder/), which supersedes PICS (http://www.w3.org/PICS/), a technology that Microsoft Internet Explorer has supported since IE6. When can we expect the editor to take these requests seriously? ******** Child Protection Online child protection, as well as the continuation of offline child protection, is a priority for any responsible site or service provider, whether directed at children or not. A service provider may include a feature that offers parents the ability to determine the type or level of content they would allow their child to view. In today's market, most, if not all, service providers do offer some degree of parental controls. A hypothetical Web site that sells an array of merchandise can use POWDER to accurately describe their content as either being child appropriate or intended just for adults. While most of their content and products are appropriate for all ages, there are also numerous pages showing "adult" toys. When a child whose setting allows him only to view content that is age appropriate accesses this online retailer through the family network he will only be able to view the content that is deemed age appropriate and not that in the adult category. - http://www.w3.org/TR/2009/NOTE-powder-primer-20090901/#Child ********** The solution seems pretty simple and straight forward to me: a) ensure that POWDER can be supported natively in HTML5 by addressing the 'concern' over name-spacing in a fashion similar to that done for MathML and SVG b) allow the video element to contain the <link> element as a child element: <link rel="describedby" href="/powder.xml" title="ICRA labels" /> (conversely, if HTML5 supports POWDER natively, the containing page could be linked/describedby the POWDER statement - is there a technically preferred method of doing this?) How difficult can that be? REOPENED and expecting a reasonable technical resolution (or at least discussion) to the bug issue: once again closing a bug based on personal opinion and politics is unacceptable.
(In reply to comment #2) > <img> has no parental control, and neither do text nodes, even though both can > and do contain material that parents might want to control. Given that, it makes sense to make the mechanism more general, so it can apply to any element. The feature seems valuable to me, on reflection. There are plenty of pictures that I'd prefer not to see even briefly, and if even a modest subset of those can be marked up so that my browser can hide them by default, that would be nice. However, wouldn't microdata (or maybe RDFa) be the correct way to do this? I don't think there's need for yet another full-blown semantic annotation protocol to be supported in any fashion. What does POWDER give us that microdata doesn't, for this use-case? Briefly glancing at the POWDER primer <http://www.w3.org/TR/2009/NOTE-powder-primer-20090901/>, it seems like POWDER has various fancy features including certification, but is this actually worth the added complexity? It looks like RDFa all over again, with namespaced custom vocabularies and so on. I think it would make more sense for someone to write up a microdata spec patterned after the ICRA's vocabulary or something. You should already be able to use it with RDFa, since apparently there's already an RDF vocabulary. All this has the typical problems of hidden metadata, though. Like John, I would appreciate it if the editor would try to deal with this issue substantively and not brush it off and force everyone to go through the decision process. My current line of thinking is that HTML5's current extensibility mechanisms (particularly microdata and RDFa) are enough to support this feature, and no further built-in support is needed. If the W3C spec doesn't contain vocabularies for licensing or vCard or whatnot, why should it contain any details about other semantic vocabularies like parental controls?
TrackerRequest and reopening the bug are mutually exclusive. RTFM?
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Rejected Change Description: no spec change Rationale: I wasn't joking before. The right way to do parental controls is to actually be a responsible parent and watch your kid (or get someone else to watch your kid). Relying on technical solutions here is irresponsible. I'm not going to write a spec that lets you avoid your parental duties, sorry.
(In reply to comment #6) > > Like John, I would appreciate it if the editor would try to deal with this > issue substantively and not brush it off and force everyone to go through the > decision process. My current line of thinking is that HTML5's current > extensibility mechanisms (particularly microdata and RDFa) are enough to > support this feature, and no further built-in support is needed. If the W3C > spec doesn't contain vocabularies for licensing or vCard or whatnot, why should > it contain any details about other semantic vocabularies like parental > controls? (In reply to comment #8) > I wasn't joking before. The right way to do parental controls is to > actually be a responsible parent and watch your kid (or get someone else to > watch your kid). Relying on technical solutions here is irresponsible. I'm not > going to write a spec that lets you avoid your parental duties, sorry. What part of this bug appears to be a joke? Perhaps with some real experience as a parent you will come to understand how laughable your response actually is. Parents are unable to monitor their children 24 hours a day, and as part of being a good parent you *shouldn't* be doing so. None-the-less, responsible parents will seek ways and means to keep their children be safe, whether it is buying a bicycle helmet so that they can safely ride to school each day, or installing "nanny-cams" to remotely monitor their home environment while both parents work, or checking a setting on their browser that blocks X-Rated videos being streamed to the desktop. It is not even about the complete effectiveness, but rather that a method, even if imperfect, exists: a bicycle helmet does not instantly make riding a bicycle 100% safe, but it does help mitigate potential harm. As well, public institutions such as libraries, schools or other public terminals might rightly want to have such a safe-guard available to them to avoid exposure to content deemed inappropriate, and even potential litigation, over accidental or deliberate actions by individuals. In cases such as these, the institutions would seek to not necessarily protect "a child", but rather their reputation and community standing by being responsible and taking precautionary measures to avoid embarrassment As Aryeh notes in comment #6, a real technical discussion around this topic is both warranted and possible, and I respectfully but forcefully request that such a discovery and discussion take place with a goal of finding *some* mechanism that can address the need presented. Failing that, this will be escalated to the Issue Tracker.
Let's not get sidetracked discussing parenting philosophy, shall we? No matter what we think about the issue, <video> is the wrong place to solve this on, and it makes no sense for HTML as a whole either. There is virtually no incentive for publishers to mark up their content as being unsuitable for certain audiences, so they won't. A more likely solution to this kind of problem is along the lines of ad-blockers or fraud/malware protection such as http://www.opera.com/browser/tutorials/security/fraud/. Both rely on huge databases of evil URL patterns or similar, requiring no cooperation from publishers of the targeted content. If you think this is an awesome idea, you should lobby browser vendors, not the HTML WG. Without some concrete idea about how you would solve this technically *in HTML*, I assume the chairs won't allow this to be escalated to an ISSUE...
(In reply to comment #10) > Let's not get sidetracked discussing parenting philosophy, shall we? No matter > what we think about the issue, <video> is the wrong place to solve this on, and > it makes no sense for HTML as a whole either. There is virtually no incentive > for publishers to mark up their content as being unsuitable for certain > audiences, so they won't. Sites like YouTube already flag some videos as appropriate only for adult audiences, so they'd presumably have no objection to using this markup if it were actually useful. Sites could also be required to include the metadata by law or by industry guidelines, the way it works in some countries for movies and games. Clearly not everyone would use such markup, but if it had a useful effect, I expect some sites might use it. (But it might not have a useful effect, because *implementers* wouldn't bother because it doesn't work reliably enough given how many small sites are out there.) > Without some concrete idea about how you would solve this technically *in > HTML*, I assume the chairs won't allow this to be escalated to an ISSUE... From what I've observed, the chairs allow issues like this to be escalated and then just die on the call for proposals since no one has anything concrete to say. Presumably this is so that they don't have to make judgment calls except in the minority of cases that actually proceed to a survey.
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Rejected Change Description: no spec change Rationale: This is both philosophically and technically inappropriate in this context.
mass-moved component to LC1