WordPress.org

Ready to get started?Download WordPress

Forums

Improving index.php (20 posts)

  1. Matt Mullenweg
    Troublemaker
    Posted 10 years ago #

    What do you think should be changed and why? Please refer to the CVS version for the sake of argument.

  2. arthuc01
    Member
    Posted 10 years ago #

    Personally I would be torn between adding an extra div (with individual ID's) for each ul in #menu and removing the nested lists or at a minimium adding a new class for ul and ul ul eg #nav and #subnav or something along those lines

  3. davidchait
    Member
    Posted 10 years ago #

    Well, some level of markup and ordering/subdivision approaching what I've done at http://www.chait.net would be nice. ;)
    Extra divs, spans, class and id tags where appropriate to segment sections to be stylized. Blocks around anything targeted for 'side' columns.
    But, I think the next step is to break out of the fixed index.php. The my_hacks thing is a start, but what I think is really needed is some kind of 'array' based layout. I'll probably write something up later in the week about how that might work, and it would encapsulate markup into individual files, and put the onus on 'section owners' to keep a given block type updated with the overall markup 'standard'.
    Of course, that means we need a 'markup standard'... a guide to how blocks should be encapsulated, where and when to require extra divs or spans, when to require a class or id tag on a particular markup, how to keep id's unique but come up with a base set of classes that are useful to share, etc.
    =d

  4. Anonymous
    Unregistered
    Posted 10 years ago #

    I agree most whole-heartedly with what David said. I have actually modified my index and related files to get rid of the ul and il tags completely. I think that 'listing' the entire menu is probably a mistake from a usability standpoint. Specifically, I have made everything into a div, and I do mean everything. All of the named sections in the menu have become divs, as well as all h(*) tags. I split the 'content' area into four divs. I have also reworked the code to be 1.0 strict (a minor issue really, and actually validates 1.1 too), and I included the w3c valid png into a seperate div with the idea being that I want to be able to do the same for css and WAI.

  5. Liquibyte
    Member
    Posted 10 years ago #

    Oops! Was me above.

  6. arthuc01
    Member
    Posted 10 years ago #

    I'm not sure that I agree with Dave on this - although having a split up themes seems appealing at first it would push WordPress towards a theme system like PHPNuke and POSTNuke with individual files for header, blocks, central content - which IMHO means that it quickly becomes unweildy to edit everything and to keep track of changes.
    I think Liquibyte point about spliting the content area into different divs is quite good - I do the same sort of thing on my site with each new post being included in its own div id=category name - although I haven't got round to doing anything with this it would allow a post say about Hibs football club having the background of the hibs badge...i.e. contextualising each post category
    It may also be an idea to put the footer in its own div

  7. davidchait
    Member
    Posted 10 years ago #

    I've kept the ul/il tags as it makes a lot of customization much easier. I haven't removed the orignal uses of h* tags, and actually want to increase usage -- I read a good article about using the explicit tags whenever possible, rather than replacing with a span or div, as it makes the markup self-defining in many ways. I haven't yet done it, but I'm thinking about how to. ;)
    People should feel free to grab my index.php (www.chait.net) and read it through. I've done my best to use clean tab-based indentations based on block levels, so it should be pretty easy to parse. I've also tried to use class and id to better identify divs and spans.
    As for Chris... Well, I guess I come from a different standpoint, as a software developer with stints in graphics/layout/prepress... ;) I see nothing wrong with organizing the system so that you don't HAVE to edit the php files much (if any), using an admin interface to activate blocks, base location/order, etc., and then what you really edit is just the CSS. It would also allow much easier adding/removing of given blocks or hacks, which is what the 'average' user really seems to want. That's just my opinion.
    (Oh, and things that make it so you only edit CSS and the db/admin stuff, and never need to change a php file, would be good things... right?)
    =d

  8. Matt Mullenweg
    Troublemaker
    Posted 10 years ago #

    David, if you could offer some specific suggestions instead of just pointing to your site that would be more helpful. We want the markup to be as simple and clean as possible, so redundant divs and spans like you have on your site are not going to happen. Besides, 95% of that can be avoided if you use the right CSS techniques.
    Liquibyte, we're not going to dilute the structure of the document.
    Authuc01, what would be the advantage of having the footer in a div instead of a paragraph like it is now?

  9. notthatugly
    Member
    Posted 10 years ago #

    I agree that it would allow a lot more flexibility in terms of CSS formatting if, instead of a single 'menu' div, there were several; one for navigation, one for the blogroll, one for categories, one for the calendar, one for archives, one for search and one for meta. People could then use {display:none} in the CSS if they didn't want to use a feature, rather than having to go into index.php, delete it, and paste it back in if they change their mind in the future. I don't think this would clutter up the document too much. They are different components; why shouldn't they have separate divs?
    And my own feeling is that I'd rather the footer were in a div; I'm not sure why, except that I'm not accustomed to thinking of paragraphs as structural units, more as semantic ones. In short, I feel more comfortable shifting it around the screen, changing the background colour, etc. etc. if it's a div. I know, it's weird.

  10. Matt Mullenweg
    Troublemaker
    Posted 10 years ago #

    If the menu list items were given IDs then it would be functionally equivilent to having them in stacked divs. You could move them around the page just like you would a DIV.

  11. Alex King
    Member
    Posted 10 years ago #

    I'm not 100% sure the side menu sections (categories, search, archives, etc.) should be presented as a list... maybe they really are independant sections.

  12. davidchait
    Member
    Posted 10 years ago #

    Will try to come up with more concrete examples for you. However, I can tell you already there are times where you need the extra spans or divs -- for the most part, the only cases I might truly have redundant divs are for grouping together things into a logical block so they move as one (which isn't redundant, by definition), or otherwise 'required' in order to do more CSS enhancement...
    All the image replacement stuff I've done so far requires an extra span to pull the background in with. The sliding doors stuff for the tabbed bars (or other graphical cat menus), and the similar methods I use for the side blocks, require extra div and span stuff in order to make the magic work. And generally, I like to apply and move divs rather than uls (just as a single example).
    I'd guess my:
    div sideblock
    div boxhead
    span title
    div boxbody
    ul
    ... style layout might seem excessive, but the inner div-span and div-ul combos are needed in order to apply the graphical bordering, and the outer div is required in order to group it all together and float (or otherwise position) it as needed.
    And just for argument's sake, I >just< took a quick walkthrough of my index.php, and while I'm guessing I could strip out a div or two (well... there's some stuff that is really more placeholders, rather than real encapsulation use...), for the most part all the 'functional' divs and spans are either required for some particular styling or grouping approach/feature/issue... I welcome critique of my site, style, approach, CSS, php, etc. If there are better ways to do what I've done, where I can in fact drop divs or spans, and not lose the ability to reposition, float, or stylize, I'm WAAAY open to the input! :)
    BTW, I do generally disagree with the display:none thing to just 'hide away' things. If there are sections that shouldn't be generated, well, they shouldn't be generated. There are cases where you want something in the html but 'obscured' from typical view -- but that's different from say generating a referral list and then just not displaying it. That's a waste of resources.. ;)
    Off the top of my head I'll throw out quick ideas (it may be that my objectives are just always a hack off of WP, since I'm going for more complex/configurable layout...):
    - have divs around the major 'areas'. header, main/content, right-block. footer is somewhat optional, as that depends on whether the footer is intended as part of the main/content or pulled out. (well, then I guess ordering it right after main would allow either approach, maybe...).
    - the type of post-subsection wrappering is pretty important. I'll give an example of where not having wrappering fails. Take the date. it's an h2. well, so are the headings for the comments section. one, the other, or both, need to be div wrappered. ;) breaking out the title as a div is similar, so that h3 isn't ever overloaded contextually. post-body, footer, and comments section, all follow the same rule. I >think< I'm making specific use of all that class/id markup.
    - the extra post-clear div is necessary for doing advanced floating within a block (thus every 'top' block probably wants a similar construct).
    - the sideblock/head/body system was taken originally from the examples of the graphical block boxes. the outer div is used for positioning, head and body are used to separate the top/bottom of the block, and any spans I then added, again, were necessary as there needs to be a second marker/anchor to apply the sliding doors style techniques.
    - I also changed other php to deal with some of these wrappering issues. Comments was one, as the whole block needed to be in a div, but the div should only show up if comments would -- thus, needed to be inside that php file. list_cats needed minor markup revisions internally to support the sliding doors menus (whether a top-bar like I have, or any of the many vertical spins).
    - I know I've broken this rule myself, but in adding divs to better break out areas/blocks, each div really should have a unique id tag whenever humanly possible. My rule of thumb is likely if it doesn't need/use/help-to-have a unique id, it could probably just as easily be a span or a p or other construct.
    Was that a helpful list? Obviously, I'm just contributing thoughts here. I'm really not expecting you'd implement much of this. Well, not until you (plural) see the need for allowing users to do more and more via CSS to really customize layouts, without need to each individually go and fight through 'what divisions are needed where'. I see the need, or at least the usefulness. But I also am not your average blogger... ;)
    =d

  13. Alex King
    Member
    Posted 10 years ago #

    Take the date. it's an h2. well, so are the headings for the comments section. one, the other, or both, need to be div wrappered

    I think adding a class to the h2 tags would be a better approach than wrapping them with meaningless div tags.

  14. TechGnome
    Moderator
    Posted 10 years ago #

    I think adding a class to the h2 tags would be a better approach than wrapping them with meaningless div tags.

    Why? I don't want my date to be the same 12pt height that my post title is. I want it itty bity, and part of a larger text string.
    Maybe having parameters that allow me to set "pre-text" and "post-text" would be sufficient.... Then if some one wants it as a H2, then set "pre-text" to <h2> and the "post-text" to </h2> If in a div tag, then <div> and </div> .... of, if like me, you want it as part of a larger string the "pre-text" and "post-text" can be set to empty strings.
    TG

  15. davidchait
    Member
    Posted 10 years ago #

    Alex -
    You're right, in certain situations. As I mentioned, I'm just starting to look at how to use the intrinsic html tags more, and add classes or ids to specialize.
    Frankly, even with the extra div, one should want to denote class/id on any blocks where it seems 'useful' (i.e. MOST ;) ).
    However, as I also mentioned, there are cases where in order to do certain CSS stylings you need either an extra div wrapper, or an extra span inner. I'm not currently doing anything special with the date, but I've considered it over the last few days.
    Keep up the comments... some good thoughts and brainstorming going on here!
    =d

  16. NuclearMoose
    Member
    Posted 10 years ago #

    About h1/h2 tags--my personal preference is that they be left as what they are in terms of HTML. I would rather see h2 and know that I am going to get a specific size of header text. Sure, it would be good to use CSS for color, font-family, font-style, text-decoration, and the like, but the h1 thru h6 tags "mean" something, so if you want to really go wild with them, then you should just make a separate class.
    Just my two cents.
    Craig.

  17. Alex King
    Member
    Posted 10 years ago #

    TechGnome, the class I mentioned would be used for styling - that is what would let you make it itty-bitty.

  18. Matt Mullenweg
    Troublemaker
    Posted 10 years ago #

    BTW, remember this discussion should revolve around index.php as it currently stands in the CVS. The date/author stuff is no longer in the heading tag.

  19. davidchait
    Member
    Posted 10 years ago #

    Craig -
    Actually, the 'use h tags' thing is being pushed by a number of what I might call 'top CSS people' around the web. The h tags give more meaning than a span or a div as they have some inherent meaning to them (the enclosed text is a header/title of some sort, basically).
    You can't really depend upon h tags giving you any specific size of text, frankly, especially not in the world of CSS, and definitely not in the world of browser text sizing or personal style sheets. Well, maybe I'm pushing it there... ;) But the whole purpose of CSS is that you can explicitly define the result you are looking for.
    That's my take on it at least. I'm currently looking at switching the spans on my side blocks that enclose the block titles to be h tags instead, as it gives more definition. (BTW, it also gives more definition to bots/crawlers/etc...)
    (And as for what the index.php is as it currently stands in CVS seems to have changed enough over the last few weeks... I'll have to go see what the new code/breakdown looks like now!)
    =d

  20. Laughinglizard
    Member
    Posted 10 years ago #

    I will throw a wrench into this interesting debate. I kinda like index.php the way it is in the CVS and the direction it is taking. It adds adherance to a clean cut, simple interface that WP is well known for, is very easy to customize and it follows a pattern from the old b2 to 0.72 and now 1.0. Non-programmers can somewhat recognize the places they had to make changes to get their templates back to where it was in b2. I would like to remind people of allusion's comment that many new users of WP will be non-techies and non-programmers. We should aim to keep this as straightforward as possible, not only try to make it standards compliant and lean, but also keep it within technical reach of the weekend blogger.
    That being said, I would like to agree with Alex. The list of items in the menu makes it quite difficult to customize without modifying the index.php. The most mangled part of the index.php in most incarnations of WP, has to be the appearance (and contents) of the menu and its' subsequent parts. I am not quite sure how to divide up the menu to serve everyone the best, but that is something that I would like to see implemented.

Topic Closed

This topic has been closed to new replies.

About this Topic

Tags

No tags yet.