[pmwiki-users] on the Light Skin

Patrick R. Michaud pmichaud at pobox.com
Sat Mar 5 16:31:37 CST 2005


On Sat, Mar 05, 2005 at 02:44:43PM -0700, H. Fox wrote:
> On Sat, 05 Mar 2005 13:01:29 -0500, Radu <radu at monicsoft.net> wrote:
> > At 06:14 PM 3/4/2005, haganfox wrote:
> > the little 'v' link is not a button, is it? You may make it more explicit
> > by adding alt text and making the v stick to the preview button rather than
> > the reset button (move the space after the v link).
> 
> The little 'v' link isn't a button because it cannot be one.  

It can be made to work if all the buttons are images, but with
text it's still a little difficult.  (And I think it's better to
have text for Preview/Reset/Save.)

> I wanted
> the Preview  button to scroll down to the #anchor automatically, but
> according to Pm that isn't possible.  

Well, "isn't possible" often just means "I haven't figured out a good way
to do it yet".  :-)

The browser is the thing responsible for scrolling to an #anchor,
and it only does that as part of the url.  But for a form, the browser
gets its target url from the form's action= attribute, and if you add
#anchor there, then you'll end up scrolling to the preview section 
for every submit button, and not just Preview.

Of course, we generally only have two submit buttons -- Preview and 
Save, so perhaps it'd be okay to let the form's action include the 
#anchor target, since a successful save results in a page redirect
anyway.  However, an unsuccessful save (think edit conflicts) does
return the author back to the edit form, and I think an author would
be fairly confused if the thing he/she sees after pressing "Save"
is a page preview.

We could consider having a "disappearing anchor" -- i.e., an anchor 
that is generated at the beginning of the preview section except when there's
an edit message or something that indicates we shouldn't jump there.
In this case the browser would be left at the top of the page unless
a preview was requested and there weren't any errors.  But that seems
a bit too hackish.  And we'd still want the "jump to preview" (v) button
available for the times when that does occur.

> Adding alt text (actually a title since it's a link) is a good
> suggestion.  I originally didn't come up with a good title string. 
> Also, it makes one more thing someone will need to ferret out to
> change the language of the string.  (Using $[language] doesn't work
> for the upper one.)  

Ummm, why doesn't it work?  Seems like it should.

Also note that as of beta22, it's possible to add arbitrary HTML buttons
and links into $GUIButtons, which of course get i18n translated.
I did this for the SpellChecker and ExcelPaste recipes, but also so that 
one could put text or iconic save and preview buttons in the button bar.  
See, for example, http://www.pmwiki.org/wiki/Test/GUIButtons?action=edit .

> Now that the PmWiki edit page is pending a significant refactoring
> (see http://www.pmwiki.org/wiki/PITS/00308 ) I've lowered the priority
> of working on the Light Skin edit page.  I'll resume when when the
> underlying PmWiki edit page design stabilizes in its new form.

Unfortunately, so far I haven't come up with many good ideas for
how to refactor the Edit Page, and most of the good once require
breaking some existing stuff.  But that's partially why we're still
in beta.  :-)

It may just be that I'll refactor the entire Edit Page to work
similar to the GUIButtons -- i.e., as an array of things to be
output with an indexing value for each that specifies position relative
to the other items in the page.  (I could also see about doing it
the way that Markup() handles the ordering of multiple markup rules,
but somehow that seems like overkill and has other problems.)

Pm



More information about the pmwiki-users mailing list