-
Notifications
You must be signed in to change notification settings - Fork 7.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Use classes instead of inline styles for hiding / showing #1681
Changes from 2 commits
9d5f283
0ec742b
9338863
e2c5378
ff7337a
0222766
06c178c
7488e82
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -845,7 +845,7 @@ vjs.Component.prototype.removeClass = function(classToRemove){ | |
* @return {vjs.Component} | ||
*/ | ||
vjs.Component.prototype.show = function(){ | ||
this.el_.style.display = 'block'; | ||
this.removeClass('vjs-hidden'); | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. There's a subtle difference here in that something that was hidden by default could no longer be shown. I wonder if that will be an issue. The more accurate name for this new approach would be There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. That's a very good point...I think in all actuality, this would still work here (if There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. An example would be how the control bar used to be before using the state classes. By default it had 'display:none' defined in the CSS, and then show() was used to add display:block. That's the piece that wouldn't work anymore with this change. There's no internal examples of that anymore, and any external skins couldn't rely on that anymore since we're not calling show() anymore on anything, so I don't think we'll break people, but we might want to glance through the plugins and see if there's any use cases like this, where something's hidden by default. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I agree. If it looks like we'd break other folks in plugin-land, maybe we just plan for this in for version 5 to avoid making a backwards-incompatible change? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yeah, we can do that. But I don't really don't expect to find issues in the plugins. I doubt many or any are extending Component and using the hide/show methods. |
||
return this; | ||
}; | ||
|
||
|
@@ -855,7 +855,7 @@ vjs.Component.prototype.show = function(){ | |
* @return {vjs.Component} | ||
*/ | ||
vjs.Component.prototype.hide = function(){ | ||
this.el_.style.display = 'none'; | ||
this.addClass('vjs-hidden'); | ||
return this; | ||
}; | ||
|
||
|
@@ -1148,4 +1148,3 @@ vjs.Component.prototype.enableTouchActivity = function() { | |
this.on('touchend', touchEnd); | ||
this.on('touchcancel', touchEnd); | ||
}; | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like that this makes the class usable for components that might exist outside of the player div. At the same time it reduces the specificity to where this could have no effect in potentially a lot of cases. I'm pretty sure vjs-hidden would have no effect if something was defined as such.
I'm not totally sure if we should worry about that. Or maybe if we should use
!important
in this case.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My initial reason for removing this was that I wanted to avoid having a utility class like this be theme-specific, but the specificity issue is real. Maybe we make note of utility classes that should be included in any theme? This would also let people hide / show things however they want, such as display or visibility.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What specificity issue? :P
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lol, nice. Of the options I'd prefer using the !important flag. This seems like a reasonable enough use case for it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Personally, I'd much rather avoid
!important
and instead just double or triple the class name.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Double classes feels hackier to me than using !important.
http://css-tricks.com/when-using-important-is-the-right-choice/
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not inherently opposed to it for this usecase.