Closed cvrebert closed 8 years ago
CLA bot is wrong, as per usual.
@cvrebert Umm that doesn't usually happen, could you please sign it with these details : Chris Rebert code@rebertia.com
Ur older commits to chassis were with Chris Rebert github@rebertia.com, I believe that is the email u signed CLA earlier with?
Signed the CLA yet again.
CLA check might fail when you've signed earlier with same email, but different name. I hope to have that addressed soon: https://github.com/jquery/jquery-license/issues/32
There, no longer invalid.
Super, thanks.
Rebased against master so that Travis succeeds.
Any substantive feedback on this proposal?
@cvrebert i agree im in favor of adding this.
Sorry, was trying to get to it in the meeting today, but the meeting ended up running long and we didn't get to this part of the agenda. I'll ping everyone to make sure they look at it.
Overall it looks good to me though.
Sorry, was trying to get to it in the meeting today, but the meeting ended up running long and we didn't get to this part of the agenda.
Understandable; no worries. Just wanted to ensure it hadn't gotten completely lost.
Discussed today during the meeting, pulling this in.
So not to throw a stick in the works but i was just reading the specs on this attribute and while i agree this could be useful some of the usages suggested here seem contrary to the W3C spec
"The hidden attribute must not be used to hide content that could legitimately be shown in another presentation. For example, it is incorrect to use hidden to hide panels in a tabbed dialog, because the tabbed interface is merely a kind of overflow presentation — one could equally well just show all the form controls in one big page with a scrollbar. It is similarly incorrect to use this attribute to hide content just from one presentation — if something is marked hidden, it is hidden from all presentations, including, for instance, screen readers." http://www.w3.org/html/wg/drafts/html/master/editing.html#the-hidden-attribute
so this is not really a replacement for display: none
as it has different semantic usage.
The One True Way to toggle the hiddenness of an element and communicate its shown/hidden status across frameworks.
@cvrebert the above makes it clear this is not something that should generally be toggled
the example of proper usage from the same section
a canvas element with the hidden attribute could be used by a scripted graphics engine as an off-screen buffer, and a form control could refer to a hidden form element using its form attribute.
We should be sure if we recommend the use of this that we recommend proper usage per the W3C guidelines this can get murky with examples like this
<h1>The Example Game</h1>
<section id="login">
<h2>Login</h2>
<form>
...
<!-- calls login() once the user's credentials have been checked -->
</form>
<script>
function login() {
// switch screens
document.getElementById('login').hidden = true;
document.getElementById('game').hidden = false;
}
</script>
</section>
<section id="game" hidden>
...
</section>
Even though the section is later shown ( toggled ) there is no valid presentation at the time that would show this information ( and also none that would hide it once logged in ) so this is a proper usage. I still think we should pull this in just need to be careful to explain the proper uses.
Okay yeah, my earlier statement needs to be qualified with a footnote:
The One True Way to toggle the hiddenness¹ of an element [...] ¹ in all presentations
so this is not really a replacement for
display: none
as it has different semantic usage.
The standard further defines it using display: none
. I'm sure the accessibility wonks who wrote the passage you quoted would equally disapprove of directly using display: none
for tabbed widgets.
the above makes it clear this is not something that should generally be toggled
I don't think it's so much about toggling as it is about different ways of presenting the same widget to users with(out) various disabilities.
We should be sure if we recommend the use of this that we recommend proper usage per the W3C guidelines
Agreed, extra docs/pointers are warranted.
Pulling this in, but I'm going to create an issue to make sure to include this information in the documentation
Although it looks like we'll need to tweak our csslint setting to deal with !important and unqalified attribute selectors.
The
[hidden]
attribute is pretty useless without this. With this, it has a chance at being The One True Way to toggle the hiddenness of an element and communicate its shown/hidden status across frameworks. This touches on some of the issues with.show()
/.hide()
mentioned in http://blog.jquery.com/2015/07/13/jquery-3-0-and-jquery-compat-3-0-alpha-versions-released/ See the comment in_hidden.scss
for more explanation.