Decrease Panels IPE CSS & JS specificity to allow "button" elements

I followed your example and rolled a patch that fixes this and sets up an array for other button element ids that need to be inputs. It's a bit expensive but will work for now. I wonder if theres already a patch for panels that ameliorates this issue.

Bootstrap modifies theme_button() to actual use the modern HTML5 <button> tag. This allows for consistent x-browser styling compatibility. We won't start adding these kinds of "exceptions" into Bootstrap. They should be changed at the source where the actual issue lies: Panels (http://drupalcode.org/project/panels.git/blob/refs/heads/7.x-3.x:/js/dis...)

Change from:

    // Bind buttons.
    $('input#panels-hide-all', context).click(Drupal.Panels.clickHideAll);
    $('input#panels-show-all', context).click(Drupal.Panels.clickShowAll);

to:

    // Bind buttons.
    $('#panels-hide-all', context).click(Drupal.Panels.clickHideAll);
    $('#panels-show-all', context).click(Drupal.Panels.clickShowAll);

Bootstrap modifies theme_button() to actual use the modern HTML5 <button> tag. This allows for consistent x-browser styling compatibility. We won't start adding these kinds of "exceptions" into Bootstrap. They should be changed at the source where the actual issue lies: Panels (http://drupalcode.org/project/panels.git/blob/refs/heads/7.x-3.x:/js/dis...)

Change from:

    // Bind buttons.
    $('input#panels-hide-all', context).click(Drupal.Panels.clickHideAll);
    $('input#panels-show-all', context).click(Drupal.Panels.clickShowAll);

to:

    // Bind buttons.
    $('#panels-hide-all', context).click(Drupal.Panels.clickHideAll);
    $('#panels-show-all', context).click(Drupal.Panels.clickShowAll);

Good lookin out, I figured that it would look something like this. I'm working on a patch for panels that fixes the dependency where you mentioned and in a handful of other places, but it doesn't look like it's taking. I'll check in once it's good and ready.

Heres an incomplete patch for panels, however because of some weird issues I'm having with cacheing I can't for the life of me get the panels_ipe.js script to load with the changed selectors. Speaking of which, the change at 218 could use a more creative selector as well. So yeah, can't confirm this works yet.

FYI, if anyone is still having this issue with the bootstrap theme, the #1 patch applied to the bootstrap theme is a temporary workaround until a more sustainable solution is reached with a patch to panels. It is currently the only working patch.

No, the patch from #1 shouldn't be used. Use patch #5.

What I'm saying is that the #5 patch is untested, and #1 is a temporary workaround until I or someone else can confirm that #5 works.

I'll give the automated testing a try against the patch in case there are client side tests

https://drupal.org/node/1887918#closing

Avoid using the id selector in CSS. There is no general benefit to using the 'id' attribute as a CSS hook, and it has serious downsides in the form of increased selector specificity.

The patch in #5 converted all the CSS selectors to use IDs instead of their respective classes. This is not best-practice.

Thanks for the tip! Currently very busy and the first patch, although it is a total hack, it is serving the purpose of allowing me to build a site with IPE and bootstrap and to iterate some style plugins for a specific project with a tight timeline.

I'll come back and finish this up later in the week.

Warning: do NOT use the #5 patch as Mark instructed. Just tried it. There is still a lot more work to do. Unfortunately I don't have time and am just patching bootstrap to get around it. My client could care less if its an input or button element, especially on the backend. I do care, but I don't have time to go down the rabbit hole on this one. I would prefer to have the participation of folks from panels but I don't see them jumping on this one.

Really?Thats actually #5, the one I wrote that wasn't working for me! Congrats! haha. With everything - styles, layout, save, cancel, etc? Is the button css working (i.e. are the icons working)? In that case, I'll give it another quick test and make some more css standardization fixes. I was inches from giving up on this!

Ok finally a working patch! Awesome, thanks for everyone's help on this. Let me know if it needs any changes for standardization purposes, but I believe we can consider this RTBC, thus a candidate for a commit

Oh hmmmm... I guess I could be more creative about the jquery selectors at line #133 (panels_ipe.js line 218). But besides input or button, what else would they be? This seems to be the most performant means to handling ajax processed elements, unless I'm overlooking something.

This is our best bet for applying the css.

Needs a few more eyes on it before we can commit. I'll see if I can reproduce and test after other RTBC issues are resolved. If others can test this and verify its functionality, that'd be great!

Patch in #20 working for me.

Patch in #20 worked for me. I was using bootstrap and panopoly together, which don't seem to work well with each other as of yet. But the patch definitely fixed the save / cancel buttons on the IPE

Changing title to something that actually describes what this patch does. Also, I don't think the elements were that religious to begin with :-p

Moving back to RTBC per #23 and #24.

The patch in #20 does work, but it does break buttons background CSS, and use first child selector to select inputs in .panels-ipe-control container which I think is not necessary.

Ah, great catch! Even I missed that one. Agreed, using child specificity is rarely needed (>) in CSS.

The patch in #27 works for me. I'm using Bootstrap theme 7.x-3.x-dev, and without this patch, IPE is broken. Can we get it committed?

The patch in #27 works over here aswell. I've been waiting for this one to get committed for a while so panopoly can finally work great with bootstrap.

Good catch on that adjustment to the css! I'm not sure why I chose child selectors, I think there was something going on where some of the button classes were re-used on multiple elements, but everything appears fine.

Before we commit it, let's just make it clear what this patch does for the panels team in general: It allows themes to use the more modern HTML5 compliant approach of using a <button> element instead of <input type="submit"> element. This is not just a patch for bootstrap interoperability, but a patch that will give theme developers the option of adopting more contemporary standards without breaking IPE.

Not HTML5 specific. I don't know what I was thinking that day. <button> elements have been around forever. Maybe I was just thinking it because they're becoming more readily/appropriately used in HTML5 markup.

Could someone please provide the patched files from #27 for me?
I don't have a clue how to patch on win7 :-(

Thanks in advance.

Sweenyy, I've added patched version of Panels 7.x-3.4

Could somebody check what happens if you try to edit same thing multiple times. For me first save is ok, then if you edit something again, ckeditor won't activate and for third try the modal is empty.

Tested #27 using simpletest.me

Added patch
Installed bootstramp theme

enabled page manager
enabled panels IPE

created a test panel and used the IPE

Works like a charm.
Would be great if we could get this committed since everyone who is using a bootstrap based theme will get stuck in this.

Also confirm that with latest dev this patch fixes the IPE problem on bootstrap. Now a part of our make file.

Thanks!

Works like a charm :-) Hoping for a commit soon....

Just re-applied after upgrading panels using the patch in #27 on the same project that originated the first patch :) works great! Time to commit it!

I agree with @rerooting, let's get this committed! Also, I too can confirm the patch in #27 is still working.

As patch #27 fail the patch in /panels_ipe/css/panels_ipe.css, the reroll patch should work on the latest 7.x-3.x branch.

Git repo: https://github.com/drupal-issue/panels/tree/2120849

+1 for #42 Patch. Worked for me!

another +1

big +1 to RTBC, thank you!

+1 for #42

#42 works nicely, though it would be practical for many if it was mentioned that this patch is aimed for the dev-version.

+1 for #42

Okay the overwheming support seems to be good here, Committed in dev!