Bug 191581 - Hidden attribute does not apply to optgroup and option
Summary: Hidden attribute does not apply to optgroup and option
Status: RESOLVED DUPLICATE of bug 69014
Alias: None
Product: WebKit
Classification: Unclassified
Component: Layout and Rendering (show other bugs)
Version: Safari 12
Hardware: Mac macOS 10.13
: P2 Normal
Assignee: Nobody
URL: https://html.spec.whatwg.org/multipag...
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2018-11-13 00:49 PST by Dev Eloper
Modified: 2020-12-06 10:59 PST (History)
8 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Dev Eloper 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
Comment 1 Chris Dumez 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.
Comment 2 Chris Dumez 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.
Comment 3 Chris Dumez 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;
}
Comment 4 Chris Dumez 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);
}
Comment 5 Simon Fraser (smfr) 2018-11-13 09:18:16 PST
See also bug 169039. Our <option> rendering seems wonky.
Comment 6 Chris Dumez 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.
Comment 7 Chris Dumez 2018-11-13 09:25:08 PST
Moving to Layout & Rendering. I do not think I am the right assignee.
Comment 8 Radar WebKit Bug Importer 2019-07-24 11:36:42 PDT
<rdar://problem/53505809>
Comment 9 Alexey Proskuryakov 2020-12-06 10:59:44 PST

*** This bug has been marked as a duplicate of bug 69014 ***