Inline style eradication programme

Bloke · 2012-03-15 19:12:36

As part of Textpattern 4.5.0, the admin side is undergoing some more stylistic changes. Changeset r3678 is the start of an attempt to remove all (or at least most of) the inline style rules that have plagued theme authors in recent times.

The tables are still there at the moment so it’s not quite the epitome of awesome it could be, but a lot of the rules have been farmed out to the stylesheet. Unfortunately, this will mean that existing themes are likely to require a small update as things like the multi-edit area, the pageby select list, and some titles (the Admin and Comment tabs, for example) now no longer have styles applied directly so they’ll just drop to their default locations unless you had the presence of mind to write a rule for them (or you based your theme on Classic and imported its stylesheet into your own theme).

r3678 is just the first pass. There are still some style tags in there, and I’ve not had a chance to ratify the class names yet — some may be able to be consolidated into single rules or be named better. So please don’t rush about tweaking your themes just yet, this is merely a heads-up that you will no longer be able to rely on the admin side to provide any (well, much) positional info from the next release and it all needs to be in your theme’s stylesheet(s).

If anybody does have anything to say on the changes, finds things aren’t quite right for themeing, or wishes to proffer some better names or consolidated rules, then please jot them here so I can tend to them.

Onwards and upwards…

Last edited by Bloke (2012-03-15 19:15:50)

maruchan · 2012-03-15 21:06:55

Awesome! Thanks Stef.

philwareham · 2012-03-15 23:34:20

Stef, I’ve just emailed you a couple of minor amends to r3678.

phiw13 · 2012-03-16 07:30:36

While you’re looking at all those inline styles (thanks for nuking them !)…

This is not really new, and has been bugging me for some time (but I forgot about it, until looking at again today). Any reason why on Preferences Tab > Basic, the second column has a class ‘pref-value’, but on Preferences tab > Advanced, this is not the case ?

philwareham · 2012-03-16 08:24:24

The preferences pages are going to get some love soon. I’m then going to audit and document all the class and id selectors in the system and their proper use cases.

Bloke · 2012-03-16 09:31:53

phiw13 wrote:

Any reason why on Preferences Tab > Basic, the second column has a class ‘pref-value’, but on Preferences tab > Advanced, this is not the case ?

No reason; an oversight. The labels also have pref-label (which is unused) and I added cell-label yesterday which was my attempt at a more generic term that can be applied to more than just the prefs panel so we can do things like set a labels’ text- and vertical-align, etc. But I realise now that’s a stupid name too because it implies some kind of table structure. Bah!

I wonder if aria-label is a better contender? Does that imply we should use aria-labelledby too on the destination control? But equally, what’s the point of labelling something with aria-label if the HTML tag in use is a <label>? Isn’t that just adding a class/role for the sake of it? Or is there some deep mystical reason for using roles in this context that I haven’t fully grasped yet?

Ultimately I want to:

remove the basic/advanced distinction
have the prefs in collapsible groups (open/closed state remembered between visits)
add a simple API for plugin authors to add prefs to the tab so we don’t need to go through the considerable pain of creating a new Extensions tab just to alter a few prefs
split the Languages off to its own top-level Admin tab

Doing the above helps everyone involved and gets rid of the 3rd tier navigation — a terrible usability barrier that slows things down unnecessarily, imo

Thoughts (or code/patches!) for all the above welcome :-)

Last edited by Bloke (2012-03-16 09:33:10)

philwareham · 2012-03-16 10:04:47

Not sure if you can lift some ideas from here for the prefs page. It’s obviously a work in progress and the layout is not at all done but I put some thought into the structure already. The various sections would be collapsible. I’ve also replaced radio buttons with checkboxes throughout but that might not be feasible for a point release.

With regard to the cell labelling, if we are sticking with the table-based layout for the near future then I can live with “cell-label” for now. Not much point in using roles when the table structure is totally unsemantic (screen readers, the main benefactor of roles, will be totally broken by a table-based layout anyway).

Once you move to a more modern structure there will be no need for a class on the label/label cell any more, so we can remove it at that stage. i.e. this kind of structure:

<section id="preferences-system">
  <h4 class="document-outline">System preferences</h4>
  <fieldset>
    <legend class="dropdown-toggle" data-toggle="collapse"><a href="#">Site</a></legend>
    <div class="collapse">
      <p>
        <label for="pref-sitename">Site name</label> <a href="#" rel="help" title="Show help">?</a><br>
        <input type="text" id="pref-sitename" name="pref-sitename" value="My Site">
      </p>
      <p>
        <label for="pref-site_slogan">Site slogan</label> <a href="#" rel="help" title="Show help">?</a><br>
        <input type="text" id="pref-site_slogan" name="pref-site_slogan" value="My pithy slogan">
      </p>
      ....
    </div>
  </fieldset>
</section>

Last edited by philwareham (2012-03-16 10:06:56)

philwareham · 2012-03-16 10:19:53

Also, while I’m thinking about it, the button classes need some thought, at the moment you have a mixture of publish, smallbox and smallerbox – not semantic.

Ideally you should use something like this (kind of how they do it on Twitter Bootstrap):

class="button-primary"

class="button"

class="button-delete"

Again, I’m not sure that is possible for a point release, due to backwards compatibility with themes.

Last edited by philwareham (2012-03-16 10:20:34)

Bloke · 2012-03-16 11:17:15

philwareham wrote:

Not sure if you can lift some ideas

That’s the sort of thing I had in mind. I did a mockup ages ago and actually scribbled some code to do it, along with the API I mentioned, but I dunno where I put it.

I’ve also replaced radio buttons with checkboxes throughout

I’m not sure that’s a hot idea for the simple reason that checkboxes work differently to radios in HTML form submissions. If a checkbox is unchecked, its entire entry is omitted from the POSTed stream so you don’t know it exists in order to clear its value. A radio button will always send a 0 or 1 (or the defined values).

Technically, one shouldn’t rely on iterating over the passed values. I prefer a system where the prefs are all defined in a structure and we iterate over that list, looking for values in the POSTed stream that match. If found, they are then set. That prevents injection of rogue new prefs values, but it still doesn’t help solve the checkbox issue, unless we assume that absence of a value in the POSTed stream implies setting a 0 or a '' to the missing item.

screen readers, the main benefactor of roles

Ah, that explains it, thanks.

Last edited by Bloke (2012-03-16 11:19:29)

Bloke · 2012-03-22 00:43:07

OK then. Try that and please let me know how you get on or if anything is amiss.

Once this set has been ratified and proven to work on classic and Remora, theme authors can start to build on it.

philwareham · 2012-03-22 08:29:28

Great work Stef, a few minor changes needed though…

Users page, ‘add new author’ table

Currently is:

<tr>
  <td align="left" valign="top" colspan="2"><h2>Add New Author</h2></td>
</tr>

Should be:

<tr>
  <td colspan="2"><h2>Add New Author</h2></td>
</tr>

Then in the CSS file add:

.edit-pane h2 {
text-align: center;
}

Links page, add new link

Same change as in users page above.

Diagnostics page, preflight check table and diagnostics table

Inconsistent with above, currently is:

<thead>
  <tr>
    <td><h2>Pre-flight check</h2></td>
  </tr>
</thead>
<tbody>
  <tr>
    <td></td>
    <td></td>
    ...
  </tr>
</tbody>

Should be:

<tr>
  <td><h2>Pre-flight check</h2></td>
</tr>
<tr>
  <td></td>
  <td></td>
  ...
</tr>

I’ve also raised issue 146 because the two tables on that page share the same id selector (and you can only have a single instance of an id per page).

Comments page, in txp-control-panel, the list banned IPs link

Currently is:

<a href="#">List banned IPs</a>

Should be:

<p id="list_banned_ips"><a href="#">List banned IPs</a></p>

Needs the paragraph tag and id selector put back on in case theme authors want to directly target that link for styling (for example I make that link look like a button in my theme – I’d have no easy way of targeting it without the id). The <p> tag also allows for some space before the search-form (at the moment they are too close together).

Image edit page and file edit page

The tables on these two pages have a id="list" when they should have id="edit", see issue 147.

Cheers,
Phil

Bloke · 2012-03-22 10:37:35

Pants, I just knew I’d have to have missed a load. I checked for the existence of style= on the page and forgot to look for align attributes. I’ll get onto it, thanks for spotting them.

Regarding the align="left" on the headings, that’s from the tdcs() (td colspan) function so it’ll affect every tag and plugin that uses the function. I’ll check what the fallout is.

Textpattern CMS

Textpattern CMS support forum

#1 2012-03-15 19:12:36

Inline style eradication programme

#2 2012-03-15 21:06:55

Re: Inline style eradication programme

#3 2012-03-15 23:34:20

Re: Inline style eradication programme

#4 2012-03-16 07:30:36

Re: Inline style eradication programme

#5 2012-03-16 08:24:24

Re: Inline style eradication programme

#6 2012-03-16 09:31:53

Re: Inline style eradication programme

#7 2012-03-16 10:04:47

Re: Inline style eradication programme

#8 2012-03-16 10:19:53

Re: Inline style eradication programme

#9 2012-03-16 11:17:15

Re: Inline style eradication programme

#10 2012-03-22 00:43:07

Re: Inline style eradication programme

#11 2012-03-22 08:29:28

Re: Inline style eradication programme

#12 2012-03-22 10:37:35

Re: Inline style eradication programme

Board footer