This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 15133 - Please explain how hidden=true interacts with plugin loading. Should it be treated as display:none?
Summary: Please explain how hidden=true interacts with plugin loading. Should it be t...
Status: RESOLVED FIXED
Alias: None
Product: WHATWG
Classification: Unclassified
Component: HTML (show other bugs)
Version: unspecified
Hardware: Other other
: P3 normal
Target Milestone: Unsorted
Assignee: Ian 'Hixie' Hickson
QA Contact: contributor
URL: http://www.whatwg.org/specs/web-apps/...
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-12-09 23:19 UTC by contributor
Modified: 2012-10-12 16:15 UTC (History)
3 users (show)

See Also:

Attachments

Description contributor 2011-12-09 23:19:46 UTC 
Specification: http://www.whatwg.org/specs/web-apps/current-work/multipage/editing.html
Multipage: http://www.whatwg.org/C#the-hidden-attribute
Complete: http://www.whatwg.org/c#the-hidden-attribute

Comment:
Please explain how hidden=true interacts with plugin loading.  Should it be
treated as display:none?

Posted from: 173.164.128.209
User agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_2) AppleWebKit/535.11 (KHTML, like Gecko) Chrome/17.0.963.0 Safari/535.11
Comment 1 Eric Seidel 2011-12-09 23:23:15 UTC 
See https://bugs.webkit.org/show_bug.cgi?id=56575 for context on how WebKit currently has trouble with hidden=true plugins, since we need to not load display:none plugins:
http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2011-November/033732.html
but at least that author expects hidden=true to not act like display: none.
Comment 2 Ian 'Hixie' Hickson 2012-01-31 22:55:54 UTC 
Well first, hidden=true is bogus. hidden="" is a boolean attribute, meaning it's either present or absent, and its value, if any, has to be the same as its name.

But that's irrelevant here since this is a legacy page, not a page using the new hidden="" attribute.

If we have to address this, I propose doing it by changing the [hidden] rule in ua.css to:

   [hidden]:not(object):not(embed), ... { }

   object[hidden], embed[hidden] { width: 0; height: 0; }
   object[hidden] { overflow: hidden; }

...in the ua.css file.
Comment 3 contributor 2012-07-18 18:00:43 UTC 
This bug was cloned to create bug 18299 as part of operation convergence.
Comment 4 Ian 'Hixie' Hickson 2012-08-09 16:41:02 UTC 
I need a way to test whether an <embed> element is instantiating a plugin or not before I can test implementations enough to know what to do here.
Comment 5 Ian 'Hixie' Hickson 2012-10-11 19:52:46 UTC 
Anne found me this:
   http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=1836

IE and Gecko play audio but show nothing (display:inline height:0 width:0 as far as I can tell, though neither made it very easy to determine what exactly was going on), Opera plays no audio, WebKit doesn't hide it.

I'll go with the Gecko/IE behavior.
Comment 6 contributor 2012-10-11 19:55:55 UTC 
Checked in as WHATWG revision r7453.
Check-in comment: Improve compatibility for <embed hidden>
http://html5.org/tools/web-apps-tracker?from=7452&to=7453
Comment 7 Simon Pieters 2012-10-12 11:10:11 UTC 
FTR...

grep -aPic "<object(\s[^>]*)?\shidden\s*=" web200904
0
$ grep -aPic "<embed(\s[^>]*)?\shidden\s*=" web200904
199