Bug 191581 – Hidden attribute does not apply to optgroup and option

• Component: Layout and Rendering
• Status: RESOLVED DUPLICATE

[Dev Eloper]

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

[Chris Dumez]

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]

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]

The default definition of rendererIsNeeded is:
bool Element::rendererIsNeeded(const RenderStyle& style)
{
    return style.display() != DisplayType::None && style.display() != DisplayType::Contents;
}

[Chris Dumez]

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)]

See also bug 169039. Our <option> rendering seems wonky.

[Chris Dumez]

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]

Moving to Layout & Rendering. I do not think I am the right assignee.

[Radar WebKit Bug Importer]

<rdar://problem/53505809>

[Alexey Proskuryakov]

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