Textpattern CMS support forum
You are not logged in. Register | Login | Help
- Topics: Active | Unanswered
#13 2005-01-19 03:54:09
- Andrew
- Plugin Author
- Registered: 2004-02-23
- Posts: 730
Re: [plugin] [ORPHAN] zem_prblock
Eventually I see this becoming either a preference in admin_config.php or, if comments are broken out from their current form and become much more flexible, an optional attribute.
Offline
Re: [plugin] [ORPHAN] zem_prblock
If Zem has no objections to this, integrated into core TXP by default, and a attribute for the comment txp tag to turn it off; that would be ideal.
Offline
#15 2005-01-19 04:05:12
- zem
- Developer Emeritus
- From: Melbourne, Australia
- Registered: 2004-04-08
- Posts: 2,579
Re: [plugin] [ORPHAN] zem_prblock
It’s GPL, and I’ve already suggested it to Dean. And yes, I think on by default with an option to disable is the best solution.
Alex
Offline
Re: [plugin] [ORPHAN] zem_prblock
I know, this is why I’ve spoken of “objections”. Even if it’s legal to do so without even telling you, it may be simple courtesy (or clever open source project, imo TXP is much better with your work that without it).
It’s like Dean asking not to fork because he would like TXP to function well on Textdrive, or Olivier Meunier asking Free.fr to remove Dotclear (first french blog engine) from their automated install because they lack proper support of PHP, or Rickard asking people not to remove the link and copyright on punBB template, and so on.
It’s not a obligation, it’s just the author saying what he would like (or wouldn’t).
Offline
Re: [plugin] [ORPHAN] zem_prblock
zem: If you switch to XHTML Transitional you’ll validate with target on your links. It’s also possible to use JavaScript to “sneak” attributes past the validator by adding them dynamically if you want to stay with Strict.
You cooin’ with my bird?
Offline
Re: [plugin] [ORPHAN] zem_prblock
> ubernostrum wrote:
> zem: If you switch to XHTML Transitional you’ll validate with target on your links. It’s also possible to use JavaScript to “sneak” attributes past the validator by adding them dynamically if you want to stay with Strict.
It’s beyong the scope of the thread, but the w3c validator is not an end in itself.
It mean something. It mean we are all talking in the same language.
And by the way, if target was deprecated in html, it’s for a good reason. Where a link has to open should be, have to be in the hand of the people surfing, not in the hand of the webmaster.
If I want a link to open in a new window, fine. If I want a link to open in a new tab (something the target attribute can’t do by the way), fine. But it’s my choice.
Offline
Re: [plugin] [ORPHAN] zem_prblock
When trying to install the plugin, I get the error message: “
Parse error: parse error, unexpected $ in /tmp/phparafJd on line 5”
Offline
Re: [plugin] [ORPHAN] zem_prblock
Jeremie: There are two separate schools of thought here. One is the accessibility camp which says don’t open new windows and makes some convincing arguments for it.
Then there’s the pragmatist camp, which argues that for some cases a new window is the best solution; for example, when presenting a user with a dialog box which relates to the current page but should not replace it (many e-commerce confirmation dialogs fit this model).
And IIRC target was deprecated in HTML because it’s considered part of the behavior layer, not the content layer, and so is more appropriately handled in the DOM. Or at least that’s the ad-hoc argument that was grafted on to support the choice, and I think it’s a decent one.
Also, it’s still present in the Frameset versions of HTML 4.01 and XHTML 1.0.
Last edited by ubernostrum (2005-01-19 11:42:19)
You cooin’ with my bird?
Offline
Re: [plugin] [ORPHAN] zem_prblock
> ubernostrum wrote:
> Then there’s the pragmatist camp, which argues that for some cases a new window is the best solution; for example, when presenting a user with a dialog box which relates to the current page but should not replace it (many e-commerce confirmation dialogs fit this model).
Ecmascript is your tool then, when you really need it. But there are very, very, very few cases.
> And IIRC target was deprecated in HTML because it’s considered part of the behavior layer, not the content layer, and so is more appropriately handled in the DOM.
A more elegant way to say it, yes :)
> Also, it’s still present in the Frameset versions of HTML 4.01 and XHTML 1.0.
You know that frames are instruments of the Evil One, don’t you ? ;->
Offline
#22 2005-01-19 17:58:40
- Andrew
- Plugin Author
- Registered: 2004-02-23
- Posts: 730
Re: [plugin] [ORPHAN] zem_prblock
Something that might also be a very good idea is to include the ability to have a whitelist of acceptable domains or commenters that wouldn’t get the rel=“nofollow” appended to their links.
Last edited by compooter (2005-01-19 21:28:06)
Offline
#23 2005-01-19 21:19:38
- zem
- Developer Emeritus
- From: Melbourne, Australia
- Registered: 2004-04-08
- Posts: 2,579
Re: [plugin] [ORPHAN] zem_prblock
Marek,
If you’re installing via the new textarea copy&paste method, just copy the part of the plugin within the quotes.
Alex
Offline
Re: [plugin] [ORPHAN] zem_prblock
One thing that would be nice is if there was a protocol to tell spammer bots that your site uses rel=“nofollow”. At the moment it seems like this will just help Google’s index more than it will help me out.
Offline