I’m using WebYep on a website - which is HTML 4.01 Strict. I’ve just tried to validate the HTML code. Everything is fine apart from breaks (shift-returns) done within the TinyMCE rich text editor.
This is the message I get:
Warning Line 141, Column 53: NET-enabling start-tag requires SHORTTAG YES
…1>
Nailsworth Community Workshop The Subscription Rooms Bath Road,…
The sequence can be interpreted in at least two different ways, depending on the DOCTYPE of the document. For HTML 4.01 Strict, the ‘/’ terminates the tag <FOO (with an implied ‘>’). However, since many browsers don’t interpret it this way, even in the presence of an HTML 4.01 Strict DOCTYPE, it is best to avoid it completely in pure HTML documents and reserve its use solely for those written in XHTML.
Any ideas why breaks generated by TinyMCE / WebYep are not valid?
They are valid, but this warning is saying that the <br /> sequence should be reserved for XHTML. Try changing your page to use that encoding instead. It shouldn’t have any impact on the rest of your page, and you will lose this warning. I don’t know if you’re going to be able to shift the settings in WebYep to have it emit <br> in place of <br /> any time soon, as the latter is just what PHP creates when you run the nl2br() function.
Walter
On Oct 26, 2011, at 9:07 AM, Mark wrote:
Any ideas why breaks generated by TinyMCE / WebYep are not valid?
I’ve used the edit HTML capability within TinyMCE rich text editor to change the “ ” to “ ”. But when I look at the source code it has changed / remains “ ” - which I think is why the HTML is not validating.
Great. That’s solved that. But there is another issue. The HTML Validater says:
Line 188, Column 19: document type does not allow element “noscript” here; missing one of “object”, “ins”, “del”, “map”, “button” start-tag
pam(AT)practicalintelligence.o…
The mentioned element is not allowed to appear in the context in which you’ve placed it; the other mentioned elements are the only ones that are both allowed there and can contain the element mentioned. This might mean that you need a containing element, or possibly that you’ve forgotten to close a previous element.
One possible cause for this message is that you have attempted to put a block-level element (such as “
Great. That’s solved that. But there is another issue. The HTML Validater says:
Line 188, Column 19: document type does not allow element “noscript” here; missing one of “object”, “ins”, “del”, “map”, “button” start-tag
pam(AT)practicalintelligence.o…
The mentioned element is not allowed to appear in the context in which you’ve placed it; the other mentioned elements are the only ones that are both allowed there and can contain the element mentioned. This might mean that you need a containing element, or possibly that you’ve forgotten to close a previous element.
One possible cause for this message is that you have attempted to put a block-level element (such as “
As I suspected. Your noscript is landing a div inside a p. That’s what the error means. How are you masking e-mail addresses? Is this being done directly by you, or is it part of a content management system? The normal Freeway e-mail masking doesn’t use JavaScript, so it doesn’t look like this.
If you have access to it, change the masking system to use a span in place of a div. That will be valid and everything should just work.
However, something else is nagging at me here – I suspect that if you clear this boulder, the next one might be that the script tag itself is sort of a block-level tag, and it shouldn’t be inline of a p either. You may fix the div and end up still being castigated for the script.
I have ‘Email Hidding: Encode with Entities’ turned on in FW. There are some email addresses within my FW file.
And I have ‘Email Encoding’ turned on on the WebYep Rich Text Action. Some email addresses (like the one in question) will be input via TinyMCE / WebYep. Is this the problem?
If I turn the Email Encoding off in the WebYep Action, will emails input via the CMS be encoded by the FW Email Hidding?
I have ‘Email Hidding: Encode with Entities’ turned on in FW. There are some email addresses within my FW file.
And I have ‘Email Encoding’ turned on on the WebYep Rich Text Action. Some email addresses (like the one in question) will be input via TinyMCE / WebYep. Is this the problem?
Yes. This is a rather clever attempt to confuse the bots, but its implementation isn’t taking standards into account.
If I turn the Email Encoding off in the WebYep Action, will emails input via the CMS be encoded by the FW Email Hidding?
No. Freeway can only encode that which it creates, and the WebYep system runs on the server, not your Mac.
Will this leave email addresses typed into the CMS open to spam?
If you disable the protection, yes, that would be the outcome. It would be extremely hard to prove the spam came from you exposing those addresses (as opposed to all the myriad other ways our addresses leak into the wild), but yes it would probably raise the odds very slightly.
What’s worse email addresses with no encoding or invalid HTML (which works on my Mac)?
Definitely e-mail, unless you are worried about applying JavaScript effects to this particular part of the page, you’re probably completely safe. Browsers are remarkably capable of putting up with crap code.
Could you not (in Tiny/MCE) edit the source HTML and add in the obscured characters Freeway creates on the same email address? Put the email into Freeway > look at the HTML output…
Sure, but that’s a hard thing to ask a client to do when writing posts to his or her site. Maybe the WebYep engine could simply scrub e-mail addresses in PHP while generating the dynamic page code, and let the user enter them (and the system store them) in the clear. That way the JavaScript hack, clever as it is, could simply disappear.
Walter
On Oct 26, 2011, at 12:01 PM, David Owen wrote:
Could you not (in Tiny/MCE) edit the source HTML and add in the obscured characters Freeway creates on the same email address?
Sorry, I was thinking this being a bit of a “set once option” on a contact page, but of course email addresses just might appear all over the place in a CMS.
Looks like CKEditor and WebYep gives the same result with hiding email address adding a div but looking at CKEditor you can change it (remove the div) with config.js by using…
// href="e-mail"
config.emailProtection = 'encode';
~~~~
I assume TinyMCE might have a similar option?
--
David
On 26 Oct 2011, at 17:05, Walter Lee Davis wrote:
> Sure, but that's a hard thing to ask
_______________________________________________
freewaytalk mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options
Thanks for your advice. I’ll keep the email addresses with encoding. And as you say, I’m sure the invalid HTML code won’t be noticed by anyone using the site.
