Opened 14 years ago

Closed 12 years ago

#945 closed enhancement (wontfix)

Add ability for stylist to add ids to blocks

Reported by: guest Owned by: gogo
Priority: normal Milestone:
Component: Plugin_Stylist Version: trunk
Severity: normal Keywords: stylist
Cc: jeffreyd.davis@…


Right now with stylist I can do this:

xinha_config.stylistLoadStyles('div.inset {margin: 2em auto; width: 80%; padding: 2em; background-color: #eeeeee;}', {'div.inset' : 'Inset'});

And now I have insets that are nice and friendly and appear in my Stylist. If I select a block of text and click the style, it will add a *class* to that block. However, I cannot do the same thing with IDs. Something like this:

xinha_config.stylistLoadStyles('div#toc {margin-left: 5%; width: 500px; padding: 2em; background-color: #eeeeee; margin-bottom: 50px;}', {'div#toc' : 'Table of Contents'});

If I try to right now, it will correctly style a block that already has the ID, but the ID will simply not appear in my stylist.

Of course, if this is not too easy, just reply and I will dig into it myself. The code for stylist does not look incredibly complicated.


Attachments (1)

stylist.js (22.4 KB) - added by guest 14 years ago.
This is the modified code for stylist to add ids to blocks (in addition to classes)

Download all attachments as: .zip

Change History (6)

comment:1 Changed 14 years ago by guest

I have done this. Now I just need to figure out how to upload my changes :O. It nearly doubles the size of Stylist.js, so it could probably be done more efficiently, but I think it is an effective solution that others might find useful.

Changed 14 years ago by guest

This is the modified code for stylist to add ids to blocks (in addition to classes)

comment:2 Changed 14 years ago by jeffreyd.davis@…

Let me know if I am going about this post wrong. I will edit the js directly if you like.

Regardless, in addition to the modified stylist.js (which I have uploaded) the following function (and alias) needs to be added to Xinha_Core.js:

Xinha.addIDs = function(el, ids)

if ( el !== null )

var thiers =' ');
var ours = ids.split(' ');
for ( var x = 0; x < ours.length; x++ )

var exists = false;
for ( var i = 0; exists === false && i < thiers.length; i++ )

if ( thiers[i] == ours[x] )

exists = true;


if ( exists === false )

thiers[thiers.length] = ours[x];


} = thiers.join(' ').trim();



Xinha._addIDs = Xinha.addIDs;

comment:3 Changed 14 years ago by ray

I'd like to postpone this a bit and first do another release, because we have loads of changes that need testing, and this seems a heavy one.

comment:4 Changed 14 years ago by guest

Makes sense to me. By the way, this is pretty much just a copy of the relevant portions for adding/removing classes with anywhere I found class changed to id. Obviously, I had to do a little more thinking and tweaking than that, but most of the code is the same as that which had already been written.

comment:5 Changed 12 years ago by gogo

  • Cc jeffreyd.davis@… added
  • Resolution set to wontfix
  • Status changed from new to closed

This change has certainly been sitting around for a while.

I am -1 on it.

First Xinha has no way to enforce that the user is not going to assign the id twice by way at least of assigning it in two separate content areas edited by two separate Xinhas at two separate times but the content eventually brought into one html resultant by whatever on the server end.

Second it would in my opinion make the Stylist a bit confusing because if the user assigns this ID style to some thing in the Xinha then they would not be able to assign it to anything else until they unassigned it to the thing. There would need to be some user interface element to indicate to the user what is going on.

In a cursory look at the code attached to this ticket I see nothing which attempts to prevent the user from assigning the ID twice. This is certainly inappropriate.

In the the Xinha.addIDs code above it seems the user is allowing a single element to have multiple ids (splitting on space the same was as classes are) - I don't believe (correct me if I'm wrong) that this is appropriate.

In summary, I'm closing this as wontfix, if somebody disagrees and fixes the above items in the attached code, then perhaps it can be revisited.

Note: See TracTickets for help on using tickets.