Use less-specific tabledrag selectors

update and check locally to see if patch affects other..confirm no effects on other css

#1: block-css-clean-up-1662954.patch queued for re-testing.

re test the patch if failed again i will re-roll the patch because the error is related to search

+++ b/core/modules/block/block.admin.cssundefined
@@ -20,6 +20,7 @@ a.block-demo-backlink:link,
+  -webkit-border-radius: 0 0 10px 10px;

see #1290506: Remove webkit-specific border radius from CSS

EDIT (sorry, can you assign to yourself again)

Thanks droplet

updated patch attach...ignoring the one waning out of 7 warning..
the -webkit-border-radius

#blocks is point to TABLE
.block-admin-display-form is point to FORM

This is different but normally that's fine. lets keep it for one more reviewer

I guess it's fine. You know, the whole point of disallowing IDs in selectors is actually making styles reusable. What we've got here are headers for sorting widgets (something we use quite often in Drupal). So I guess the right thing would be to change it to something like .draggable-region. And hope contrib starts using it.

oh i didn't mean to RTBC yet.

+++ b/core/modules/block/block.admin.cssundefined
@@ -1,12 +1,12 @@
+.block-admin-display-form .region-title td {

This can be even shorter:

.block-admin-display-form .region-title { 
  font-weight: bold;
}

No need to target the inner td.

Plus, this exact same styling is used on the Field Display table, but then targeted with 'table.field-ui-overview tr.region-title td'.

Wouldn't it be better to have single draggable form styling (agree with #10), with a generic

.tabledrag .region-title {
font-weight: bold;
}

Then we only have to make sure drupal_add_tabledrag() adds a generic class 'tabledrag' to all forms calling it.

Yeah, that's what Object Oriented CSS is all about :D Let's do it.

Menu module? Shouldn't this be theme system?

@mjonesdinero: still working on it? If not, can I assign it to myself?

@BarisW problem is we can't just add a class to the form or table from within drupal_add_tabledrag, unless we hack the function.

Well, we can do that in tabledrag.js right? The class only has to be there when JS in enabled anyway, so I think that's the only place where we have to do it.
Let me look into it ;)

I made it a bit less specific by using selectors like 'table tr.region-message' instead of 'table.field-ui-overview tr.region-message td' and '#blocks tr.region-message'.

What do you think?

By the way; I've added the classes to an aexisting bunch of tabledrag class in system.base.css, but shouldn't all those tabledrag classes be in system.admin.css?

@BarisW I think the class should be there even if there's no JS.

@barraponto: they do. I've made the classes to that they should also work without javascript enabled.

And yes, they should probably move to base.admin.css

Ok, so let's push this. The actual CSS has come a long way, thanks a lot @BarisW.
As for moving it to admin.css, I've opened another issue for it: #1750134: Move tabledrag CSS into system.admin.css. Let's keep them separate to get this commited ASAP.

Hm. Are you sure this is right? My understanding is system.base.css was only for CSS styles related to functionality which would break if they weren't there. I'm confused why font bolding and italicizing would go there and not in system.admin.css.

I am probably missing a cluebat and if so, just mark back to RTBC with explanation.

Well, all the other tabledrag styles were already in system.base.css, so I just added the three extra lines there. In system.admin.css I couldn't find any tabledrag selectors, so I thought it wouldn't make sense to add those 3 lines just there.

The question is whether tabledrag is used in the frontend as well? If so, then we can leave it like this. If not, we need to move all tabledrag selectors to the system.admin.css, including the untouched existing ones.

@barisw tabledrag is used to sort multiple field values. Will system.admin.css be loaded then?
Anyway, shouldn't drupal_add_library sort that out for us?

Reroll to apply cleanly, RTBCing again.
Tabledrag stuff is irrevelant to the scope of this patch, particularly in light of #1524414: Rewrite tabledrag.js to use jQuery UI.

CSS changes need manual testing in all browsers and all affected core themes:

1. Test pages where the relevant classes are used without the patch applied.
2. Apply the patch, clear the site and browser caches, and test again. Confirm that there are no changes or regressions.

Post before-and-after screenshots for one browser/theme.

Looks like the Patch from #18 needs to be rerolled. It will not apply to the current D8-dev.

Try it: the changes were in line numbers.

This patch not only affects the Block admin page, but also fixes styles on the manage fields page. There are overlapping styles that are also in issue at #1662986: Clean up css in Field UI. Though the 2 might independently work, we will need a combined patch to actually test the same.

Patch no longer applies to 8.x-dev. Rerolling.

Rerolled, ready for review.

Reroll is successful and works against 8.x.

Issue still needs screenshots and manual testing per #30

CSS changes need manual testing in all browsers and all affected core themes:

Test pages where the relevant classes are used without the patch applied.
Apply the patch, clear the site and browser caches, and test again. Confirm that there are no changes or regressions.
Post before-and-after screenshots for one browser/theme.

Screenshots attached, using "Seven" theme. One quick note, the asterisk is not affected by this CSS change. It gets added when dragging the block from region to region or changing weight, not when moving from "disabled" into a region.

Before:

After:

I'm going along with #25's response to @webchick's question as why to put the code into system.base.css. The "we should put it where other the stuff like it is" reason makes sense to me. IMO this is still very much open to discussion.

Another discussion to have would be to adjust the class names used to be more general and tweak the Block module accordingly. Table that for now, in the spirit of getting this acute fix in place.

Feedback is very much welcomed.

No longer applies, probably due to #1987066: Rename files to match CSS file naming convention. Should be a quick reroll.

rerolled.

The patch applies ok.

Manual testing turned up a couple of things though:

1 - The color: #999 property of the 'tr.region-message' row is not set after the patch. (Check screenshots)

2 - Why has the font-style: italic of the 'tr.region-message' been added? In the admin/structure/blocks, it seems that the only text styled by this class is already wrapped in <em> tags.

Actually, in my opinion, the font-style is a more suitable way of doing this as I don't think the text is trying to be emphasised, but trying to appear different for readability purposes.

*Edit to embed screenies

Thanks @CaptainWonky! It's helpful if you embed your screenshots in your comment, Dreditor makes that easy.

Tweaking title, I keep having to do a double take thinking this is referring to http://lesscss.org/ :)

And as @CaptainWonky pointed out, this no longer needs a reroll.

I agree with #48, and i rerolled the patch to include his suggestions.

Updated issue summary.

It looks better now! Thank you!

52: clean-up-css-1662954-52.patch queued for re-testing.

By the way. we could make this even cleaner, as we probably don't need table tr. A tr is always part of a table, so why not just make it:

tr.region-title {
  font-weight: bold;
}
tr.region-message {
  color: #999;
}
tr.region-populated {
  display: none;
}
tr.add-new .tabledrag-changed {
  display: none;
}

Seems reasonable to do here.

I agree with #55. So i rerolled the patch again to include his suggestions.

Thanks @balis_m! Setting the status to 'Needs review' so the patch gets tested.

Please also remove the code in field UI css

I could find two classes in field ui css that appear to be obsolete given the changes to the system.module.css

Setting to review to trigger testbot.

The patch in #60 applied cleanly.
Both the block admin page and the field UI works well and looks ok.
I am attaching couple after/before screenshots.

Block admin before:

Block admin after:

Block admin after, block dragged from one region to another:

Field UI before:

Field UI after:

Field UI after, dragging a field to another position:

Setting status to RTBC, i hope it is ok.

hide my screenshots to allow more important files to show up in summary.

Committed cdcbb9d and pushed to 8.x. Thanks!