WebKit Bugzilla
New
Browse
Search+
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED DUPLICATE of
bug 69014
191581
Hidden attribute does not apply to optgroup and option
https://bugs.webkit.org/show_bug.cgi?id=191581
Summary
Hidden attribute does not apply to optgroup and option
Dev Eloper
Reported
2018-11-13 00:49:42 PST
The spec defines[0] on all HTML elements (subclasses of HTMLElement), including optgroup (HTMLOptGroupElement) and option (HTMLOptionElement) a hidden attribute. Unlike Firefox, Edge, and Chrome, Safari does not (visually) reflect the semantics of setting this attribute: "User agents should not render elements that have the hidden attribute specified." In the following demo, optgroup and option are visible in Safari:
http://jsfiddle.net/c1nzxm8e/
[0]
https://html.spec.whatwg.org/multipage/interaction.html#the-hidden-attribute
Attachments
Add attachment
proposed patch, testcase, etc.
Chris Dumez
Comment 1
2018-11-13 08:57:32 PST
Web Inspector properly reports that both the <option> and <optgroup> have "display: none" computed style, yet they are indeed visible :/ If I add "hidden" attribute the the <select> element then the <select> also becomes "display: none", and then it becomes indeed hidden. The issue is therefore specific to <option> and <optgroup> elements somehow. Also, I do not believe this is actually a DOM/HTML issue since the CSS style was properly set. This is more likely a CSS or rendering issue.
Chris Dumez
Comment 2
2018-11-13 08:59:56 PST
Both HTMLOptionElement and HTMLOptGroupElement have the following override: bool rendererIsNeeded(const RenderStyle&) final { return false; } Not sure why they do not need a renderer.
Chris Dumez
Comment 3
2018-11-13 09:04:38 PST
The default definition of rendererIsNeeded is: bool Element::rendererIsNeeded(const RenderStyle& style) { return style.display() != DisplayType::None && style.display() != DisplayType::Contents; }
Chris Dumez
Comment 4
2018-11-13 09:09:10 PST
This may also be relevant: bool HTMLSelectElement::childShouldCreateRenderer(const Node& child) const { if (!HTMLFormControlElementWithState::childShouldCreateRenderer(child)) return false; #if !PLATFORM(IOS_FAMILY) if (!usesMenuList()) return is<HTMLOptionElement>(child) || is<HTMLOptGroupElement>(child) || validationMessageShadowTreeContains(child); #endif return validationMessageShadowTreeContains(child); }
Simon Fraser (smfr)
Comment 5
2018-11-13 09:18:16 PST
See also
bug 169039
. Our <option> rendering seems wonky.
Chris Dumez
Comment 6
2018-11-13 09:22:34 PST
Relevant rendering code seems to be in void RenderListBox::updateFromElement(). It grabs text from options and optgroup elements without taking into consideration their visibility.
Chris Dumez
Comment 7
2018-11-13 09:25:08 PST
Moving to Layout & Rendering. I do not think I am the right assignee.
Radar WebKit Bug Importer
Comment 8
2019-07-24 11:36:42 PDT
<
rdar://problem/53505809
>
Alexey Proskuryakov
Comment 9
2020-12-06 10:59:44 PST
*** This bug has been marked as a duplicate of
bug 69014
***
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug