Textpattern CMS support forum
You are not logged in. Register | Login | Help
- Topics: Active | Unanswered
New UI changes overusing HTML IDs? Your take?
I like the new changes and appreciate the hard work you devs did to the backend GUI. Pretty helpful and makes targeting elements easier.
That said, is there a reason for the use of IDs? To me it seems that the markup could be slightly overusing IDs and making it more complicated than it should.
I’m talking about the individual elements that are used on wide variety of pages but on every page the element has a different unique ID. Is that really needed to use different ID on every page?
After all the body tag has the #page-$event ID which in my eyes makes it somewhat waste of space and time. Do the #$event_control need to be there and also have a class? Does the same form inputs need different IDs on every page? Is there a reason for this? And if so, shouldn’t tagbuilder, lists, all inputs and such have different IDs too (#css-tagbuilder etc)?
That aside, there are couple real things that got my eye; one being the separators the IDs use. To me it would make more sense if the ID/classes used same separators, either _ or -, not a mix bag of happyness, even that I like sweets. Makes it whole lot easier to actually remember the IDs and classes. The second is the position of $event. It varietes. I would like it either appending or prepending the ID.
Just my thoughts.
Last edited by Gocom (2010-10-11 04:41:44)
Offline
Re: New UI changes overusing HTML IDs? Your take?
Gocom wrote:
is there a reason for the use of IDs?
Not explicitly, no. A lot of the IDs/classes were there already and I didn’t want to remove them in this release in case they were in use by plugins. I approached it like this:
- Look at the existing IDs and classes, sigh heavily at their names, take note of the way they were constructed (underscore/dash used, etc) and where they were employed
- Consolidate the above information to get a picture of what it looked like in 4.2.0
- Figure out what it would be nice to put in 4.3.0 to target individual elements and make classes applicable across pages
- Sigh heavily when it isn’t very pretty
- Figure out what can be removed in TXP 5
- Do the best I can to present something consistent(ish) around the existing markup that plugin and theme authors can use that can then be tweaked in TXP 5 to remove the cruft
My main aim was to class common items across pages. So a date is a date is a date. If you really want to target a date on one specific page, as you say, prepend the rule with the page ID. Individual element IDs are usually only there if they existed already in 4.2.0.
The primary exception was the control areas (though there were others). I added the IDs because this area is probably going to be used more in TXP 5 for housing stuff that will control the presentation of the rest of the page (e.g. filters). It also often has pluggable_ui() in it so people can add extra stuff there and have it all nicely collapsible if real estate is at a premium. If you want to add stuff via jQuery then an ID is less typing than #page-file .txp-control-panel. And since it’s likely to be used fairly frequently I though direct access would be more useful.
Does the same form inputs need different IDs on every page?
Can’t do much about this unfortunately. It’s in the function which has been in place since it was introduced so every Browse… form has it. Didn’t want to rock the boat too much by removing it.
And if so, shouldn’t tagbuilder, lists, all inputs and such have different IDs too (#css-tagbuilder etc)?
Maybe. Perhaps I overlooked those. The tagbuilder does have #tagbuild_links wherever it occurs. Actually, I guess technically that should be class="tagbuild-links", perhaps with a specific ID as you say. Rats. I should probably fix that (which will likely break Stuart’s Vitraux theme…)
the separators the IDs use
I tried to be consistent. Most of the existing IDs used underscores and most of the existing classes used hyphens so I continued that tradition. Sadly not all of them followed that convention originally so they are the same as they always have been. If, however, I’ve screwed up and got it wrong with the new classes/IDs, please shout now or we’re stuck with it.
the position of
$event
Again, this may have been due to previous (poor) naming. But if I’ve added new ones that don’t fit a pattern then please highlight the specific ones now and I’ll fix them asap before 4.3.0 final. Thanks!
The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.
Txp Builders – finely-crafted code, design and Txp
Offline
Re: New UI changes overusing HTML IDs? Your take?
Thank you for the thorough reply, Stef :-)
Bloke wrote:
Again, this may have been due to previous (poor) naming. But if I’ve added new ones that don’t fit a pattern then please highlight the specific ones now and I’ll fix them asap before 4.3.0 final. Thanks!
No, there isn’t really. More of so the overall existing inconsistency which might take puzzle solving skills in the future. I’m not expecting anything for the closing 4.3.0.
Offline
Re: New UI changes overusing HTML IDs? Your take?
Gocom wrote:
More of so the overall existing inconsistency which might take puzzle solving skills in the future
:-) Yeah, when TXP 5 rolls around and the markup is thinned, some of the old skool IDs and classes might magically just disappear. I do want to try and maintain the newer names as far as we can. To that end I’m going to put together a ‘best practice’ document on the wiki about this under the Plugin Development Guidelines area.
The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.
Txp Builders – finely-crafted code, design and Txp
Offline
Re: New UI changes overusing HTML IDs? Your take?
Don’t worry about Vitraux. I can always make the necessary mods no problem, however I would disagree about the naming of the main container div. In my opinion this should be the same on all pages so that they can all be targeted in the CSS with a single selector block. If someone needs to target a specific block then they can always use the “body” id as a separator. This makes for more efficient CSS in my opinion.
Stuart
In a Time of Universal Deceit
Telling the Truth is Revolutionary.
Offline