removing the wikkly- prefix

[jdlrobson]

Hi I am using the python version of WikklyText in a TiddlyWeb
implementation.

I do this
{{reputation{some text}}}

and it spits out:
<div wikkly-reputation'>some text</div>

Is there a way I can stop it adding the "wikkly-" prefix?

[Frank McIngvale]

Not at the moment at least. The idea (sorry if this is obvious) is that all class names are prefixed with 'wikkly-' to keep the output namespace safe from whatever environment it is embedded in, so you can use a define a single CSS file for use with the standalone wiki, inside TiddlyWeb, inside Drupal, etc. I'm not a CSS wizard by any means so if there is a better method to accomplish this, I'm open to suggestions.

Anyways, that's why its like it is. Technically you can change the 'wikkly' to something else (but editing the sources), but the concept of it being "PREFIX-name" is pretty well woven in right now.

What is your use case exactly -- do you have to use specific classnames in a CSS file you can't change for whatever reason?

frank

 

--
You received this message because you are subscribed to the Google Groups "WikklyText" group.
To post to this group, send email to wikkl...@googlegroups.com.
To unsubscribe from this group, send email to wikklytext+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/wikklytext?hl=en.

[jdlrobson]

My usecase is within TiddlyWeb/TiddlyWiki.

TiddlyWiki's implementation of Wikklytext does not prefix wikkly- to
the front of classes. I am trying to replicate TiddlyWiki with your
python library however due to this difference, in TiddlyWiki I have a
css definition for .reputation which is obviously ignored here.

Personally if I ask for {{reputation{some text}}}
I would want the class to be reputation as I have declared this.

As a css user, if .reputation had a css rule outside the context of
wikklytext that I would want to override I would write a more specific
css rule to prevent this from happening. One way you could aid this is
by wrapping the entire wikklytext output with a class eg.
wikklytext_world

So now if I want to change the css of something within wikklytext
world I could write a rule .wikklytext_world .reputation which would
override the default non-wikklytext world css rule .reputation due to
being more specific.

Would this not solve the problem you are proposing? If not apologies
for misunderstanding - maybe a concrete example could help.

In the mean time I will do a string replace on the output to strip
the class :S (not good code! :))
Thanks
Jon

> > wikklytext+...@googlegroups.com<wikklytext%2Bunsu...@googlegroups.com>

[Frank McIngvale]

On Fri, Jan 8, 2010 at 5:56 AM, jdlrobson <jdlr...@gmail.com> wrote:

My usecase is within TiddlyWeb/TiddlyWiki.

TiddlyWiki's implementation of Wikklytext does not prefix wikkly- to
the front of classes. I am trying to replicate TiddlyWiki with your
python library however due to this difference, in TiddlyWiki I have a
css definition for .reputation which is obviously ignored here.

I wasn't aware of that, I guess Chris edited the sources to remove the prefixing. That's fine for TiddlyWeb but in the general case some kind of prefixing or scoping is needed to prevent clashes when embedded in other environments. However ...

 

Personally if I ask for  {{reputation{some text}}}
I would want the class to be reputation as I have declared this.

As a css user, if .reputation had a css rule outside the context of
wikklytext that I would want to override I would write a more specific
css rule to prevent this from happening. One way you could aid this is
by wrapping the entire wikklytext output with a class eg.
wikklytext_world

OK maybe that's what I should have done ... like I say, no CSS wizard here :-) I'm adding that my TODO to figure out how the scoping rules work.

My concern at this point is breaking compatibility with custom CSS sheets others have defined as well as plugins that define __css__, etc. It might make sense to add it as a postprocessing step, like an internal XSLT transform, let me think about it some more.

 

In the mean time I will  do a string replace on the output to strip
the class :S (not good code! :))

An alternative, slower but easier to get it "right", would be to take the inner HTML that's produced (which is valid XML), load it into ElementTree or lxml and change the class attrs that way.

frank

 

To unsubscribe from this group, send email to wikklytext+...@googlegroups.com.

[chris...@gmail.com]

On Jan 8, 4:17 pm, Frank McIngvale <fmcingv...@gmail.com> wrote:

> On Fri, Jan 8, 2010 at 5:56 AM, jdlrobson <jdlrob...@gmail.com> wrote:
> > My usecase is within TiddlyWeb/TiddlyWiki.
>
> > TiddlyWiki's implementation of Wikklytext does not prefix wikkly- to
> > the front of classes. I am trying to replicate TiddlyWiki with your
> > python library however due to this difference, in TiddlyWiki I have a
> > css definition for .reputation which is obviously ignored here.
>
> I wasn't aware of that, I guess Chris edited the sources to remove the
> prefixing. That's fine for TiddlyWeb but in the general case some kind of
> prefixing or scoping is needed to prevent clashes when embedded in other
> environments. However ...

No, I didn't do that. I think there's confusion over what Jon's
saying.

He wants identical css files to be used whether a piece of tiddler
content is being rendered to HTLM by tiddlywiki or by WikklyText.

Somewhere there is a tiddler with

{{reputation{some text}}}

and somewhere in the context is css entry for

.reputation {
border: black;
}

and if I'm understanding Jon right, what he wants is that the same
piece of css can style the rendered version of that wikitext, whether
it is in the server side context (using wikklytext) or in the client
context (using tiddlywiki).

Because wikklytext is prepending the wikkly- prefix, he can't do this
without post-processing the output from wikklytext's rendering system.

Assuming I'm understanding what's going on here, at all.

[jdlrobson]

You understand correctly :)

[Frank McIngvale]

On Wed, Jan 20, 2010 at 8:34 AM, cd...@peermore.com <chris...@gmail.com> wrote:

On Jan 8, 4:17 pm, Frank McIngvale <fmcingv...@gmail.com> wrote:

> On Fri, Jan 8, 2010 at 5:56 AM, jdlrobson <jdlrob...@gmail.com> wrote:
> > My usecase is within TiddlyWeb/TiddlyWiki.
>
> > TiddlyWiki's implementation of Wikklytext does not prefix wikkly- to
> > the front of classes. I am trying to replicate TiddlyWiki with your
> > python library however due to this difference, in TiddlyWiki I have a
> > css definition for .reputation which is obviously ignored here.
>
> I wasn't aware of that, I guess Chris edited the sources to remove the
> prefixing. That's fine for TiddlyWeb but in the general case some kind of
> prefixing or scoping is needed to prevent clashes when embedded in other
> environments. However ...

No, I didn't do that. I think there's confusion over what Jon's
saying.

He wants identical css files to be used whether a piece of tiddler
content is being rendered to HTLM by tiddlywiki or by WikklyText.

Oh okay, that was confusing me because I thought the issue was WikklyText v TiddlyWeb not v TiddlyWiki.

 

I don't know a good way to solve this. Looking at the TiddlyWiki sources, I see it overrides root styles like h1,h2,h3,...,a,hr,ol ... etc. That works great because TiddlyWiki knows it is the only document, but doesn't work at all for embedding in other environments. I'm not opposed to commonality, I think it would be great to use the same CSS file everywhere, but I'm not enough of a CSS expert to know how to do it. Patches and/or help gladly accepted :-)

frank

Somewhere there is a tiddler with

{{reputation{some text}}}

and somewhere in the context is  css entry for

.reputation {
 border: black;
}

and if I'm understanding Jon right, what he wants is that the same
piece of css can style the rendered version of that wikitext, whether
it is in the server side context (using wikklytext) or in the client
context (using tiddlywiki).

Because wikklytext is prepending the wikkly- prefix, he can't do this
without post-processing the output from wikklytext's rendering system.

Assuming I'm understanding what's going on here, at all.

[FND]

> I don't know a good way to solve this. Looking at the TiddlyWiki sources, I
> see it overrides root styles like h1,h2,h3,...,a,hr,ol ... etc. That works
> great because TiddlyWiki knows it is the only document, but doesn't work at
> all for embedding in other environments.

Well, one could use more specific rules to limit the context of
certain rule sets.
Assuming there's a common container for all WikklyText output:
<div class="wikklytext">
<h1>Foo</h1>
<blockquote>lorem ipsum</blockquote>
</div>
Then you can use CSS like so:
h1 { /* applies to the entire document */
font-size: 2em;
}

.wikklytext h1 { /* applies only to descendants of elements with
class "wikklytext" */
font-size: 1.5em;
}

Not sure about the implications for backwards-compatibility though...

-- F.

[Frank McIngvale]

OK I'm still confused ... I understand what you explained but I'm having trouble applying it to the problem of common stylesheets. I need to break this into a list of steps so I can understand it :-) ...

1. TiddlyWiki renders links as <a> with no class= added. So in your StyleSheet you have a rule "a { ... }" to override its style.

2. WikklyText renders links as <a> but wraps it in a <div class="wikklytext"> so the rule ".wikklytext a {...}" applies. Also the rule "a {...}" WOULD apply if the rule ".wikklytext a{ ...}" was not present (true?!?).

3. Now, based on what you explained above, my WikklyText CSS with the ".wikklytext" rules will NOT work in the TiddlyWiki because ".wikklytext a {...}" will NOT be matched as a rule for <a> since it lacks the class=

4. Similarly the TiddlyWiki stylesheet won't work in WikklyText because using the "a {...}" rule will change ALL the <a> nodes not just the (possibly embedded) WikklyText content as intended.

 

So as best as I can understand it, TiddlyWiki and WikklyText would BOTH need to use a wrapper like <div class="tiddlywiki"> to enable a common CSS stylesheet to be used.

Does that make sense or am I getting it wrong?

frank

Not sure about the implications for backwards-compatibility though...


-- F.