Ability of assign IDs to blocks

Actually you can do that now in the theme layer. Example from Bluemarine's block.tpl.php:

<div class="block block-<?php print $block->module; ?>" id="block-<?php print $block->module; ?>-<?php print $block->delta; ?>">
    <h2 class="title"><?php print $block->subject; ?></h2>
    <div class="content"><?php print $block->content; ?></div>
 </div>

Note that first line. The div gets an id that consists of "block", the module the block is coming from, and the delta within that block. That creates a completely unique key for the block. The delta is often numeric, but that's just convention from what modules are using. Modules are free to use non-numeric deltas if they wish (and I do, myself).

Setting won't fix, since there's nothing to "fix". :-)

True.
I also do it in theme, but generate an id by scrunching the block title.

Block weight has nothing to do with the delta. I use non-numeric ids for my own blocks, also.

Yup, I think you're mistaken.

Try editing your block.tpl.php to include a dump of the entire block:

  <div class="block block-{?php print $block->module; ?}" 
    id="block-{?php print $block->module; ?}-{?php print $block->delta; ?}">
    <h2 class="title">{?php print $block->subject; ?}</h2>
    <div class="content">{?php print $block->content; print_r($block); ?}</div>
 </div>

(slightly munged code to get through the formatter)

I get:

  <div class="block block-block" id="block-block-2">
    <h2 class="title">delta?</h2>
    <div class="content">stuff:
stdClass Object
(
    [module] => block
    [delta] => 2
    [theme] => coders
    [status] => 1
    [weight] => 6
    [region] => right
    [custom] => 0
    [throttle] => 0
    [visibility] => 0
    [pages] => 
    [subject] => delta?
    [content] => stuff:

)
</div>

The delta is 2 (the second block-block I've made today) and the weight is 6.
My ID always says block-block-2, independant of the block position/weight, and I key the CSS on that.
Other module-suppled blocks (like menu) work the same. Delta is not weight. Delta (annoying name) is a module-relative block id.

Nope.
It is unique, and static - within the context of that module.

There's two ways delta happens.

Normally, a module like image provides a cople of hard-coded blocks:
block delta-0 : latest image
block delta-1 : random image

Whether you use 'latest' or not, 'random image' is always image.modules block number '1'
Most modules do this, providing one or two non-mutable blocks.

Advanced block modules, including menu and block.module, allow new user-defined blocks to be added, and it just happens to give them numerical IDs.
These are IDs - not ordinal positions.
Delta is a misleading, stupid name for this, if that's what's confusing you.

You can make block #1, block #2, and block #3.
Going back later and deleting or disabling block #2 will not renumber the blocks any more than deleting node 7 will cause node 8 (and the rest) to slip down a slot.
Module-block ids are just the same as term ids, vocab ids, and the rest.

In fact, if you try a lot of trial and error (as I did once) you may find yourself editing block#16 when there are no other user blocks at all.

Have you tried testing any of this? Look at the URLs and you'll see what's happening pretty quick.

+1 from me. While it's not strictly needed since you can just use the number, a friendly class name for it would make the css file read better. I just customized to of my blocks and had to write a comment in the css so I could remember what -9 and -10 were. Self commenting is always nicer, I think.

Michelle

I AGREE that it would be nice if blocks have string ids, not numeric ones. The ones I create do, so I can invoke them by name, and find them in the css. That's good.

I was mostly explaining some clear misunderstandings you had on the system as it works now.

It is probably possible to patch block.module dto do this - without breaking anything. It just requires that you expose the 'delta' (which is already varchar(32) in the DB) for editing in the form.

However, as above, it's also possible to get an almost-identical result by changing your theme slightly
Instead of

id="block-{?php print $block->module; ?}-{?php print $block->delta; ?}"

I use

id="block-{?php print preg_replace('|[^a-zA-Z0-9_]+|','-',$block->subject) ?}"

and so my block titles become exposed as the block id. Great for css.
Forget 'delta', it's an internal ID, and not semantically significant, you are right. The code above, however, is.
1/2 a line in your theme.

I would like to get_block_by_name() programatically sometimes however, and have had to write my own tools to do so.

I'm not sure about user-created blocks off hand, but for pre-existing blocks, it's easy. In the code for hook_block of the module in question, change the deltas from numeric to strings. :-) That's something you'd submit as a patch against the module in question. If you did core, contrib modules would probably follow suit in time.

There's been talk of this before. In fact, I thought it already happened for some reason. :-) I doubt such a patch would get in right now, so close to feature freeze, but it probably wouldn't be a huge challenge in the next release.

I'm not sure about user-created blocks off hand, but for pre-existing blocks, it's easy. In the code for hook_block of the module in question, change the deltas from numeric to strings. :-) That's something you'd submit as a patch against the module in question. If you did core, contrib modules would probably follow suit in time.

There's been talk of this before. In fact, I thought it already happened for some reason. :-) I doubt such a patch would get in right now, so close to feature freeze, but it probably wouldn't be a huge challenge in the next release.

I don't rename my blocks too often after they are made, so I don't really consider a blocks label to be a mutable part of the content.
If I create a user block, labelled 'Contact Details' and that can be found and styled via CSS as the id #block-contact-details ... well I'd call that semantic enough.
.. although I've also met designers who created style sheets that were nothing BUT a series of content-id-anchored special cases :( . If your title reflects the purpose of the block, I don't mind that approach.

Classification is (appropriately enough) done via class. The class is 'block' and 'block-block' (block-module supplied user block) so those are good CSS hooks to work with.

What is it that you are doing that you have a large number of user-defined blocks that you change the titles for a lot?
To get any more fine-tuned on this, and sub-classify user-defined boxes into groups - a layer of detail between what it is (.block-block) and what it does (#block-contact-details) would seem to suggest you may want a taxonomy classification going on here.

Whatever, look into editing the block delta. It is quite possible, and even shows up correctly in URLs when in the admin/block/* area

Unless there's a patch, or an entirely new layer of block administration module methods forthcoming, I think this issue has reached a bit of a dead end.
Something to keep in mind for forthcoming Admin UI developments possibly. As above, I'd vote for just making the id itself (the mis-named 'delta') directly editable by admins.
Closing

This module probably provides something like the required functionality - essentially it lets you add an additional "tag" to a block which you can then pick up in your CSS in various ways, or use a different block template. http://drupal.org/project/blocktheme

I agree something like this should be in core really since for user defined blocks, picking up the ID in the CSS is pretty inflexible. It's doable for an admin with FTP access, but for a content creator it's hopeless. We can do this sort of thing with nodes and node/page template - why not for blocks too?

Related: http://drupal.org/node/257032#comment-878738.