Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo

Close

#111 Fix for input text not showing in some themes

open-works-for-me
nobody
None
2
2004-05-17
2003-12-17
No

I posted this a few versions ago in the help forum but the
affected files haven't been changed, so I'll post it here
too. In some themes (Mose's), entered text doesn't show
in textareas. The themes are geo.css, geo-light.css,
mose.css and trollparty.css. Here's a fix: remove the
commas in the font description for general form elements
textarea. In geo.css - line 470; in geo-light.css - line
410; in mose.css - line 481; in trollparty.css - line 444.
So, for example, 'font: normal 12px fixed, courier,
monospace;' becomes 'font: normal 12px fixed courier
monospace;'. Now text entered by the user can be seen.

Also, to get the background images to show in geo.css,
the background image URL should be changed from
'background-image: url(/styles/localis/backmap.png);' to
'background-image: url(/styles/geo/backmap.png);'.

-- Gary

http://phinixi.com

http://cunningham-lee.com

Discussion

  • Logged In: YES
    user_id=524646

    Hmm. These files aren't fixed again in 1.8rc3. It's only an extra
    comma in each file, guys ;-). Are other users fixing the css
    files themselves, using broken geo, mose, and trollparty
    themes (ie., no visible text in textareas), or avoiding these
    themes completely?

    -- Gary

     
  • Logged In: YES
    user_id=738765

    The background fix was done by Gustavo.
    I don't know CSS but I compared with moreneat and this one
    too uses commas. Also I tested all three and text was every
    time very readable.
    Please notice if I'm missing something.

     
    • labels: 544454 --> 465646
    • status: open --> pending-out-of-date
     
  • Logged In: NO

    The problem still exists in Tiki 1.8. At tikiwiki.org, try changing
    your theme preference to geo.css, for example. Then try
    editing a wiki page. At least in my experience, you won't be
    able to see the text in the editing textarea. This is the case
    for all the themes I listed. Also, check out these images if you
    like:
    http://cunningham-lee.com/tiki-browse_gallery.php?galleryId=8
    . They show examples of the problem at my family web site
    (Tiki 1.7), and an example after the fix is applied.

     
  • Logged In: YES
    user_id=738765

    I don't get it with frebird, maybe it handles better wrong
    syntax.
    Text appeared black on white on mose, black on ~~yellow on geo.

     
  • Logged In: YES
    user_id=524646

    I don't have Firebird installed, but tried with the earlier Phoenix
    browser. It doesn't show the text either. (All of these tries are
    on Windows BTW.) So it looks like Firebird is the most powerful
    browser around. ;-)

    -- Gary

     
    • status: pending-out-of-date --> open-out-of-date
     
  • Adam Shantz
    Adam Shantz
    2004-01-14

    Logged In: YES
    user_id=786280

    The suggested fix can't be used because it would create
    invalid CSS. ...could it be a browser bug?

    -Adam

     
  • Logged In: YES
    user_id=524646

    Maybe this is the problem: at least geo.css uses "fixed" as a
    font attribute for the textarea element. Deleting this word and
    the following comma ("monospace" and "courier" are retained
    as values) solves the problem and, I think, makes the file valid
    CSS.

    I don't think this is just a "browser bug". IE6 and Opera7 on
    Windows aren't exactly obscure useragents. If I can't edit my
    pages at tikiwiki.org or my own sites when I'm using those
    themes and some of the most common browsers and operating
    system, then I think there's a problem.

    Probably doing a search and delete of "fixed," in those files
    would do the job.

    -- Gary

     
  • Adam Shantz
    Adam Shantz
    2004-01-17

    • status: open-out-of-date --> open-works-for-me
     
  • Adam Shantz
    Adam Shantz
    2004-01-17

    Logged In: YES
    user_id=786280

    I just now tested each of the themes (in both Moz 1.5 & IE6
    in WinXPro) you identified having trouble with, and cannot
    reproduce the behavior at all. Even if the behavior could
    be reproduced, we couldn't remove the commas (like you
    suggested) because it would result in invalid CSS. Also, if
    the bug -could- be reproduced, and assuming removing the
    commas did fix the issue, it would still break rules for
    valid CSS.

    Also, I pulled up geo.css in my local CVS & the background
    image line (ln 27) says, "background-image:
    url(geo/backmap.png);".

    You may want to check to make sure your browser is up to
    date. The only thing I can think of suggesting (short of
    using another theme until 1.8final is released) is to
    download a CVS copy.

    -Adam

     
  • Logged In: YES
    user_id=524646

    > I just now tested each of the themes (in both Moz 1.5 & IE6

    in WinXPro) you identified having trouble with, and cannot

    reproduce the behavior at all.

    That's interesting. One variable is that I'm using the Japanese
    version of WindowsXP, which I guess could make a difference.

    > Even if the behavior could

    be reproduced, we couldn't remove the commas (like you

    suggested) because it would result in invalid CSS.

    Yes, that's been established already, which is why I suggested
    in an earlier comment which you apparently missed that,
    instead, "fixed" be removed as a property (since "monospace"
    is already specified) -- this also solves the problem in my
    testing. I can find documentation at w3.org for "monospace"
    but not for "fixed".

    > Also, I pulled up geo.css in my local CVS & the background

    image line (ln 27) says, "background-image:

    url(geo/backmap.png);".

    Right, that's been corrected for a while now, as Chealer's
    comment states. My original submission about the URL was in
    mid-December, when it still had the original localis.org path.

    > You may want to check to make sure your browser is up to

    date.

    Uh, my Opera and IE are sufficiently up to date (though I'll get
    a fresh Firebird to check with). They may not be the most
    recent point upgrades but they are certainly typical of what
    many people are using.

    > The only thing I can think of suggesting (short of

    using another theme until 1.8final is released) is to

    download a CVS copy.

    It's CVS copies that I've been testing (most recently Jan. 16),
    along with the earlier releases; and since the relevant sections
    of the stylesheets in question haven't been changed, obviously
    the problem would continue, at least in my checking. Clearly, if
    no one but me experiences this invisible text then some factor
    unique to my platform-browser set-up looks suspicious. As I
    stated, it's not only my own sites but also tikiwiki.org that I
    can't see input text in editing textareas in certain (ie., Mose's)
    themes. Maybe it's the OS localization difference on my
    computer, if nothing else turns up and no one else can
    reproduce the problem. In that case I'll just remove "fixed"
    from the textarea font properties in my own files and call it
    good, pending other comments.

    -- Gary

     
  • Logged In: YES
    user_id=524646

    I don't know why but this problem seems to exist only on my
    own computer. I thought it involved using Japanese Windows
    XP/browsers, and maybe it does, but I checked with other
    computers with the same OS/apps and I __can__ see the
    input text. Only on my laptop is it invisible, in tests of
    tikiwiki.org and other sites. So the mystery continues, but
    seems to involve only my machine on the client side. (The css
    file change I described -- deleting "fixed," from the textarea
    style -- does solve it, though, for my computer.)

    -- Gary

     
    • labels: 465646 -->
    • priority: 5 --> 2
    • milestone: 356877 -->