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.
Not happening in 2.0 because it would make the XHTML invalid.
In 2.1... GitHub is ---> that way.
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.
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.
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?
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.
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?
Because in 2011 it was still the most modern.
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.
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.
since SMF 2.0 is not having features added to it, this will not be added to SMF 2.0.
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.
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.
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.
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.
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.
i do see it as a bad thing. either way this is not being done in SMF 2.0.
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.