Support Forum

Yellow Swordfish said

Ah thanks for that. Our W3C validation checks missed that one clearly. After a quick check I believe the height should not be there anyway but I will correct that of course.

Any inline styling - unless I have missed something - is only ever used for forcing a minimum height or a width. The minimum height has been set to be below what should ever be needed and the width I believe is always set to 100% of the column width made available.

Is this necessary? Well in most cases no and I would agree with you. But the vast majority of our users, as we know, are not coders so this is like a safety net.
In an ideal world I could define a div and know it would take up the space as specified in it's css. Does that actually happen in practice?

No worries, thats why I pointed it out

100% of the column width available in a specific theme format, but with the theme templates you have introduced the ability to have any element in a different place in the theme which may or may not have the same width limitations.

For example, I have a new theme I am designing where I place the top posters stats in a sidebar interface rather than where it currently resides. It is hard-coded at width at 15% no worries, simple css override to make it 100% for where I am using it or even a specific pixel size, but and this is the bigger problem, it now changes the hard-coded width of everything that was around it in the ORIGINAL theme so its not one override it is 4 or 5 just to move one element for customization of my theme, so it makes it harder to customize than it does to not customize even though the whole point of the template process is to be able to customize.

I complete agree that the safety net is needed for a lot of users who want to use it pretty close to out of the box, the only place we diverge is where that safety net is applied, as a hard-coded inline style (mainly width not minimums) the safety net works for the initial standard themes and users who don't want very much customization, but it wraps customizers in the net and holds back a lot of the usefulness of the modular nature of the theme/plugin redesign.

But if you move the same inline styles out of hard-coding and into the css file then the safety net catches the low end user and doesn't limit the ability to customize layouts and themes in new and unthought of ways.

Having moved away from tables and to divs/plugin/modular themes you have made Simple press 2/3 of the way to fully customizable. Completely separating css and code output, so that the html/div are raw, no styles, is the final step and still allows for the safety net in the standard theme css file for the low change users.

As to div location specifics of css, divs do generally end up where you want them when you move away from inline styles and even more when you move to pixel specific widths and heights away from percentage layouts, which by the way you can not do with the current hard-coded inline style percentage widths.

Hope this makes sense, it is not a criticism of a great project or what is obviously a ton of hard work to bring it to fruition, its just an observation that it appears there is one more step to reach the goal of customizing ability that I believe you were working towards, by putting all styles in external css files, not hard-coded inline, allowing all output to be raw html to be moved and styled by the css, it frees up and widens the possibilities of customization by another magnitude.

Yep better than 2/3 but percentage precision is a little tricky 🙂

Here is the solution I came up with to strip out all inline style in the content for the current situation (beta 5.0.0 build 7392)

I replaced the simple the_content() call in my WP forum template with

<?php

My quick code from yesterday had some limitations due to a change in the behavior of saveHTML since I originally learned its usage, so here is the proper code to output the proper content validated up to