PM subject field

Started by Sir Osis of Liver, October 01, 2017, 06:04:17 PM

Previous topic - Next topic

Sir Osis of Liver

A nitpicky thing, but just had to fix it again.  The default text in Subject field in pm editor - (No subject) - must be deleted before you can type a subject.  It's easily fixed by changing this -



<input type="text" name="subject" value="', $context['subject'], '" tabindex="', $context['tabindex']++, '" size="40" maxlength="50" />



to this -



<input type="text" name="subject" placeholder="', $context['subject'], '" tabindex="', $context['tabindex']++, '" size="40" maxlength="50" />



in PersonalMessage.template.php.  This clears the field when you click in the box.


Ashes and diamonds, foe and friend,
 we were all equal in the end.

                                     - R. Waters

Arantor

Not happening in 2.0 because it would make the XHTML invalid.

In 2.1... GitHub is ---> that way.

Sir Osis of Liver

Quote from: Arantor on October 01, 2017, 06:05:38 PM
Not happening in 2.0 because it would make the XHTML invalid.

What does it do?  I've used it in several forums and not seen any problems.
Ashes and diamonds, foe and friend,
 we were all equal in the end.

                                     - R. Waters

Arantor

Break the page because it's invalid XML (because that's what XHTML means, XML+HTML)

It's also, incidentally, the reason why SMF uses ; in all the URLs, so it didn't have to deal with correctly encoding & in all the URLs which would break the page if any single instance were done wrong because a page then becomes an XML document rather than tag soup.

Browsers can decide to treat it not as XML but this can cause other things to break.

Sir Osis of Liver

So it's valid HTML5, but invalid in XHTML 1.0 transitional?  I've seen this used on many websites in login fields, shopping carts.  Works differently in IE and FF, but doesn't seem to break anything.  Is there another way to do it?
Ashes and diamonds, foe and friend,
 we were all equal in the end.

                                     - R. Waters

Arantor

Of course it's invalid XHTML, it didn't exist nearly 20 years ago when XHTML 1 was written...

Most sites these days use HTML5 where it's absolutely fine. Like 2.1 does.

Sir Osis of Liver

#6
This works -



<input type="text" name="subject" value="', $context['subject'], '" onfocus="value=\'\'" tabindex="', $context['tabindex']++, '" size="40" maxlength="50" />



I suppose it's rude to ask, but why is SMF using a 20 year old doctype in 2.0?
Ashes and diamonds, foe and friend,
 we were all equal in the end.

                                     - R. Waters

Arantor

Because in 2011 it was still the most modern.

Sir Osis of Liver

Still don't see why this was never fixed.  It's an obvious, annoying glitch in a feature that's used regularly, and there seem to be many solutions available, at least one of which must be compatible with the 2.0 code.  I've seen devs argue interminably of much less significant minutae.
Ashes and diamonds, foe and friend,
 we were all equal in the end.

                                     - R. Waters

Arantor

Because it's not possible TO fix in 2.0 without gutting the theme, sorry.

All of the other solutions require JavaScript, which no-one wanted to use for this because of cross browser compatibility.

Your solution also *requires* people to type a subject whereas the current one does not require the user to actually do anything.

Illori

since SMF 2.0 is not having features added to it, this will not be added to SMF 2.0.

Sir Osis of Liver

Quote from: Arantor on October 02, 2017, 01:33:12 PM
Your solution also *requires* people to type a subject whereas the current one does not require the user to actually do anything.
Only if you click in the field, otherwise it still uses '(no subject)' as subject text.  Don't think that's a bad thing.

Quote from: Illori on October 02, 2017, 01:41:04 PM
since SMF 2.0 is not having features added to it, this will not be added to SMF 2.0.
Didn't think it would be, but it's actually a fix, not a new feature.
Ashes and diamonds, foe and friend,
 we were all equal in the end.

                                     - R. Waters

Arantor

Huh, didn't see you'd updated it with an edit, I was going off the original placeholder attribute which definitely wouldn't work.

And no, it's not a bug fix.

Sir Osis of Liver

Quote from: Arantor on October 02, 2017, 01:45:29 PM
And no, it's not a bug fix.

Didn't say it was, it works badly because it's designed to work badly. 
Ashes and diamonds, foe and friend,
 we were all equal in the end.

                                     - R. Waters

Arantor

But that's why it's not being included, it isn't broken. You just dislike how it works.

I couldn't recommend the "fix" for it that would remove the title if I were to click back into it to, say, fix a typo.

Sir Osis of Liver

Quote from: Arantor on October 03, 2017, 02:50:34 AM
But that's why it's not being included, it isn't broken. You just dislike how it works.
I can't remember ever seeing an input field that required manually deleting default text.  Spent an hour or so last night on 6 or 8 websites making a couple of purchases and renewing magazine subscriptions, all had input fileds with default text, and all cleared when I clicked in the box.

Quote
I couldn't recommend the "fix" for it that would remove the title if I were to click back into it to, say, fix a typo.

I don't see that as a bad thing, either.
Ashes and diamonds, foe and friend,
 we were all equal in the end.

                                     - R. Waters

Illori

i do see it as a bad thing. either way this is not being done in SMF 2.0.

Arantor

Now we have placeholders, it's super easy to do. But this is only a recent phenomenon, unlike SMF which has done this consistently for the last 14 years, long before HTML5 was ever a thing, and back then it was done inconsistently and badly and invariably bad for accessibility.

Advertisement: