UserCss

  • a general DIV markup would be nice and allow for a whole range of workarounds and also site-by-site changes to WikiMarkup. I must admit I am a bit concerned that introducing this kind of flexibility would greatly reduce the simplicity of the engine. -AndyFundinger
    • How about using @ to set off divs? Markup would run to end of line and the div class would be whatever follows the @ sign. i.e. @ToDo would become <div class='todo'>. I'm told this is similar syntax to *JavaDoc and it should be easy to parse out for data-related features like the todo example above. -APF
  • in ewiki_page() add an id to the title line so that it can be styled. I'm using "title" but perhaps ewiki_title would be better. 
(EWIKI_PRINT_TITLE) and ($o .= "<h2 id=\"title\"><a 
     href=\"".EWIKI_SCRIPT.'links/'.$id.'">' 
     .ewiki_page_title($id). "</a></h2>\n");

Known issue, but I didn't had any useful ideas on it yet. For example I'm still unsure if M$ finally managed to make IE support <div class="class1 class2">.

But there are of course a lot more tags than just the titles to put some CSS into in the future. I'm currently searching the web for some sort of standard (for) class names to adopt for ewiki. milky

According to http://www.blooberry.com/indexdot/css/syntax/selectors/spechtml.htm the multiple class selectors are available after IE 4.0. What did you need them for? -APF

CSS classes

milky Using @@ to start a css <span> area is probably a good thing

  • the @ sign can easily be associated to connect something, which CSS class names actually do
  • two @ characters should be used, as not to confuse the parse, people due to ambigiousity with email adresses or the @cahracter as it is used in some programming languages and code snippets (Perl)
  • <span> instead of <div> is a good thing, as we already have multiple ways to split paragraphs and "display:block" could easily be done inside the CSS definition also
  • so we will later use <AT><AT><STRING> ...content... <AT><AT>, where the STRING is in fact the CSS class name, and the last two @@ finish the CSS area
  • I think this scheme allowed also for nested CSS classes

Andy: I like the div element actually because it has a better support history and because I am envisioning a full paragraph markup, can the parser easily handle a full in-line implementation? Can it automatically close the tag at end of paragraph? My example application is ... to mark todo items in a consistent way. Also I'm hoping to be able to insert markedup comments for Javadoc for formatting and I believe that would be paragraph style.

I think the classes generated by these plugins should be set as ewiki_uc_{lower case of CLASSNAME} this makes them case insensitive and seperates them from all other markup. Anyone disagree? -Andy

CSS-CLASS support would be a good idea.

HL: Here a suggestion for CSS-Support

In ewiki.php i added to lines

<php>

$wm_text_style = array(
" => array("<span class=", "</span>"), // for span " => array("'", "'>"), // for class
</php>

Within the wiki text i insert "> some Text

I'd rather a lighter-looking markup, along the lines of I haven't looked at doing it yet but ideally:

and some text would be a div while

and some text some more text might be a span of "and some text."

-Andy

milky: I understand your problem with the <span>, but remember that only NN until 4.05 has bad support for it, but as the CSS support in those anitique NN versions usually also breaks links, we should be happy that those early versions do not style in <span> tags. Anyhow I think, starting with NN 4.5 or 4.7 CSS support stoped to break the Navigator and also was usuable with <span>. So I still believe it to be the better default decision.

If you anyhow do not like it, you could later change the ewiki_format (I'll try to make <span>/<div> configurable as soon as I get to implement it). But finally it is to complicated to have support for both, as you suggested above. And I'd rather like to use it like this: 

   ...some text goes here, and
  this  is colored text but
  here continues the css paragraph
  with  ...here...

The nesting looks awful, but I think this works (where one could leave out the last closing of each paragraph). And remember you could also have following in your.css to make <span> things act like <div>'s: 

  .wiki span, .content span {
     display:block;
  }

As it looks that awful (see above), is the @@ to be considered a good markup thingi?! (Even if CSS markup is anyhow designed for advanced users.) -- milky

I did some thinking about this over the weekend and I think it would be worth the doing to have both, @@ for SPAN as described above and @ for div at start of line (or equiv.) only. This allows us to parse and markup javadoc comment blocks which would be pretty nice for me and the @ is probably pretty rare at the beginning of the line. -AndyFundinger

milky: Rearranging my thoughts on the upcoming new parser, it would probably be possible to let the parser guess to throw a <div> instead of a <span> if it occours at the beginning of a paragraph (not line). Selecting the <div> or <span> per configuration constant seems also good idea.

Actually my current notion is a guess-free single @ for <DIV> at the start of a line. -AndyFundinger

I tried a single @ too for my " "> some Text solution. There have been conflicts with maillinks like name@Provider. --HL

AndyFundinger: Single @ would be only at start of line to avoid that just as * only forms a list only at start of line. Thus there should be no collision with e-mail addresses since those would be preceeded by the user name and thus not at the beginning of the line.

poor coder: I still vote against single-character markup. You're right there would be absolutely no ambiguosity with a single @ (would never clash with the email regex), but to follow one markup style it is better to use double at's for it. I did an initial (works out of the box) plugin which allows for the proposed CSS markup; it has support for <div>'s and <span>'s and works rather intuitive; check it out in the CVS version or try the attached version.

brother in coding: Looks like we both had the same idea, code it and move on, I'll merge my code into yours as an non-default option and e-mail it to you, keep it or toss it, I'll keep my version around just so I can say that "we can enable javadoc-like markup." Update, I've sent the file and another couple of fixes to Mario.

I put some test cases in EWikiCSSTestSet. Andy

&now; -- milky ;-)

per-page stylesheets

The distrib. folder fragments/css/ now can hold stylesheets and snippets for individual actions and page names. They are inserted into the yoursite.php layout, if the fragments/css.php script was loaded in the <head> part of a wrapper script.

This is already used by the *PlugInstall / XpiPlugins, initialization wizard and PowerSearch, ... and whatnot plugins.

meta stylesheets

the MetaMeta edit box would also make a good place to add per-page stylesheet commands - or maybe even a separate *StylingBox for that task - because style settings shouldn't be put into the page content part (you know, the separation thingy!) even with some magical invisible markup extension.

The fragments/css.php helper script could take care if this was a {meta} data entry.

EditThisPage BackLinks PageInfo Pages like this RSS/Atom last changed on Thu Jun 3 01:22:42 2004
bottom corner