From: Joel U. <uck...@no...> - 2005-10-12 11:52:05
|
It was suggested to me (by John Kershaw) that it would be useful to allow users to apply class and id attributes to the markup when editing pages. Something like {{foo #bar: Here is some text of class foo with id bar.}} would give you a span <span class="foo" id="bar">Here is some text of class foo with id bar.</span> where the classes and ids could be defined by the site maintainer in css as part of the theme, or for even more neato points, the css could be pulled from a page in the wiki so that the users could define it themselves. Mr. Kersahw has already hacked a very old version (1.3.0) to do something like this. Questions: 1. Do we want to extend the markup syntax to permit this? 2. If so, how should it be handled? As part of the basic syntax? As part of a plugin? Thoughts? -- J. |
From: Reini U. <rei...@gm...> - 2005-10-13 06:53:03
|
I would say, users should use RawHtml or write their own simple plugin to allow that. But generally I would like to add some kind of MarkupPlugin. As in mediawiki, where you can register new simple or extended transformati= ons. As I did with the %color=3D%% and {{template}} syntax recently. ENABLE_MARKUP_COLOR ENABLE_MARKUP_TEMPLATE See lib/InlineParser.php The only administrative problem would be to define a container (ini-like fi= le) with a list of additional Syntax plugins. And maybe another subdir. Or maybe it's enough to define ENABLE_MARKUP_CLASS (uppercase) and search for Markup_class.php (lowercase) in a special dir, which defines= the markup extension class Markup_class extends BalancedMarkup /* or SimpleMarkup */ (lowercase) IniConfig could then preg_match ENABLE_MARKUP_* or DISABLE_MARKUP_*, optionally look for the MarkupPlugin in the markup subdir, and fix the $markup_types =3D array('escape', 'bracketlink', 'url', 'interwiki', 'wikiword', 'linebreak', 'old_emphasis', 'nestled_emphasis', 'html_emphasis', 'html_abbr', 'plugin', 'isonumchars', 'isohexchars', /*'html_entities',*/ ); in lib/InlineParser.php. I'll try that in two weeks or someone else is faster :) ENABLE_MARKUP_TEMPLATE should be renamed to ENABLE_MARKUP_TEMPLATE _PLUGIN then for consistency though. Or better rename Markup_template_plugin to Markup_template PS: Note that from this Friday on I'll be on a film festival for two weeks, and I will probably not be able to fix things or add patches to CVS. So it's up to you Joel. PPS: But I'll try to find my start for the Mailer class and send it to you. It's not on my main machine. On 10/12/05, Joel Uckelman <uck...@no...> wrote: > It was suggested to me (by John Kershaw) that it would be useful to allow > users to apply class and id attributes to the markup when editing pages. > > Something like > > {{foo #bar: Here is some text of class foo with id bar.}} > > would give you a span > > <span class=3D"foo" id=3D"bar">Here is some text of class foo with id ba= r.</span> > > where the classes and ids could be defined by the site maintainer in css = as > part of the theme, or for even more neato points, the css could be pulled > from a page in the wiki so that the users could define it themselves. > > Mr. Kersahw has already hacked a very old version (1.3.0) to do something > like this. > > Questions: > > 1. Do we want to extend the markup syntax to permit this? > 2. If so, how should it be handled? As part of the basic syntax? As part > of a plugin? > > Thoughts? -- Reini Urban http://xarch.tu-graz.ac.at/home/rurban/ |
From: Matt B. <ma...@ma...> - 2005-10-13 08:43:17
|
On Wed, 2005-10-12 at 13:51 +0200, Joel Uckelman wrote: > 1. Do we want to extend the markup syntax to permit this? My feeling is no. It breaks the fundamental concept of separating markup from content. This concept is one of the huge strengths of a wiki. > 2. If so, how should it be handled? As part of the basic syntax? As part > of a plugin? If it was decided it should be implemented, it should definitely be a plugin so that only those users who are willing to break the content/markup separation can enable it. I think this goes for much of PHPwiki at the moment. There are heaps and heaps of features that are not used for many wikis and having them in the default installation makes it much more complex to maintain a PHPwiki installation. Breaking them out into plugins would make PHPwiki vastly superior. I have grand intentions to help out in this area, I'm just slightly tied up bringing the Debian packages into line at the moment, but as soon as I get that under control modularisation of PHPwiki is something I would quite like to look at. Cheers -- Matt Brown ma...@ma... Mob +64 275 611 544 www.mattb.net.nz |
From: Joel U. <uck...@el...> - 2005-10-16 16:52:13
|
Thus spake Matt Brown: > > I think this goes for much of PHPwiki at the moment. There are heaps and > heaps of features that are not used for many wikis and having them in > the default installation makes it much more complex to maintain a > PHPwiki installation. Breaking them out into plugins would make PHPwiki > vastly superior. > Have you singled out some features in particular? -- J. |
From: John K. <jo...@ke...> - 2005-10-13 10:00:36
|
At 21:42 +1300 13/10/05, Matt Brown wrote: >On Wed, 2005-10-12 at 13:51 +0200, Joel Uckelman wrote: >> {{foo #bar: Here is some text of class foo with id bar.}} >> >>would give you a span >> >> <span class="foo" id="bar">Here is some text of class foo with id >>bar.</span> >> >>1. Do we want to extend the markup syntax to permit this? > >My feeling is no. It breaks the fundamental concept of separating markup >from content. This concept is one of the huge strengths of a wiki. Matt, What I'm proposing (and using on some of my ancient phpwiki 1.3.0's) is 100% about keeping markup separate from content. CSS classes and ID attributes allow my users to add semantic meaning to their content without having to worry about how it's going to presented, either now or after some future site-wide stylesheet alterations. For instance, my <div> code looks like this: ==== pullquote What a great idea ==== which renders as <div class="pullquote"> and produces a pullquote. As far as the user is aware, this markup is defining what the item *is*, not how it should look or where it should appear on the page - which is what classes & ids are all about, eg http://csszengarden.com Surely the beauty of wiki is it allows the html-phobic (or html people who want something faster, more fluid - wiki=quick) to create the pages they want to create, in as simple a form as possible? I'd also advocate extending the markup to allow classes & id tags to be applied to every existing wiki markup item, eg: ! Ingredients List should generate* <h2 id='Ingredients-List'>Ingredients List</h2> On a modern, aggressively standards compliant, CSS-driven web-site, these kinds of things are essential. If my users want their Ingredients listed in a blue box with a graphical image-replacement gizmo in the site's font, I should be able to let them have that, seamlessly, and without them needing to learn any new syntax. But I believe there should also be the option, for power users who use wiki because it's a fast way to build & maintain a web site, who can happily handle increased complexity, to directly add ids & classes to *any* markup, maybe something like: Example 1: !{appendix less-important #app1} Appendix A would render as <h1 id='app1' class="appendix" class="less-important">Appendix A</h1> (space separated classes followed by a single #id since it must be unique) Example 2: this is *{warning}so dangerous* => this is <strong class="warning">so dangerous</strong> Example 3: ==== sidebar tip #shutdown Always use the Shutdown command before turning off your computer ==== would render as <div class="sidebar" class="tip" id="shutdown-tip"> and would allow the site's *designer* (not necessarily end-user) to create 'For Dummies' style sidebar content, using different icons for tips, warnings, etc and use an XSL transformer to extract all the tips into a pocket-size printable PDF. Currently, none of those things are possible with a wiki. BTW The markup used is entirely up for discussion - I'm only talking about the validity of the approach. Being able to create page(s) called, eg, css-fonts, css-positioning, css-colors and have those auto-included in the template would allow those power users to add/update styles to go with the enhanced content they just added. John. * I have my headings in reverse importance (!, !!, !!! = big, med, small) as people often create a ! tag first, then want to use the 'bigger' headings & have to go back through the document making their previously 'big' headings smaller. -- ------------------------------------------------------------------- T:01274 581519 / M:07944 755613 www.kershaw.org jo...@ke... skype:johnmkershaw AIM:johnkershaw MSN:joh...@ho... |
From: Matt B. <ma...@ma...> - 2005-10-13 10:25:40
|
On Thu, 2005-10-13 at 11:00 +0100, John Kershaw wrote: > What I'm proposing (and using on some of my ancient phpwiki 1.3.0's) > is 100% about keeping markup separate from content. CSS classes and > ID attributes allow my users to add semantic meaning to their content > without having to worry about how it's going to presented, either now > or after some future site-wide stylesheet alterations. OK. At least we're heading for the same goal here, 100% agree that good classes and IDs on attributes are necessary, but I have some reservations about allowing arbitrary specification.... > For instance, my <div> code looks like this: > > ==== pullquote > What a great idea > ==== <snip other examples> > BTW The markup used is entirely up for discussion - I'm only talking > about the validity of the approach. OK. I think you've mostly convinced me that I do agree with what you're proposing, I probably misunderstood the initial post a little. I'm still vaguely uncomfortable with the idea of allowing users to add arbitrary classes to objects. I can't pinpoint exactly why though. I guess it's the whole trade off between flexibility and correctness. If you let users define arbitrary classes/ids you can bet it's going to be misused quicker than you can blink your eye. I'm not sure that that is a strong argument against your proposal though... just thinking aloud here. Could it be split into two parts? - Some extra syntactical features to define some commonly used page elements - An extra plugin that when included allows precise specification of class names / ids for attributes. Regards -- Matt Brown ma...@ma... Mob +64 275 611 544 www.mattb.net.nz |
From: John K. <jo...@ke...> - 2005-10-13 11:29:06
|
At 23:25 +1300 13/10/05, Matt Brown wrote: >I'm still vaguely uncomfortable with the idea of allowing users to add >arbitrary classes to objects. I can't pinpoint exactly why though. I >guess it's the whole trade off between flexibility and correctness. If >you let users define arbitrary classes/ids you can bet it's going to be >misused quicker than you can blink your eye. I have two distinct kinds of user/site in mind. Person A: wiki = easy. These people don't know their html from their http, and don't want to. My mum is one of these - she runs a web site for the old folks at the nursing home where she works. She helps them put their war memories etc online for their far-flung children to read: http://sycamoreclose.com/Stan Person B: wiki = fast. People like me, my friend in the Physics Department, and the Head of ICT at my daughter's school. We can code html pages in a text editor, we embrace W3C recommendations, we test our sites in 10 different browsers (okay, these days more like 3). BUT WE DON"T WANT TO! For me, wiki means when the client phones for a minor text alt to his site, I can do it whilst he's on the phone. No invoice required(TM). I've converted a bunch of my old html sites to phpwiki cos they're easy to maintain and I can hand over some of the day to day to the people who hold the information. I want an easy life - wiki gives it to me, in spades. erson A and person B often work on the same site. I want to be able to fancy up the recipe page on my mum's site in a consistent fashion, using markup she can understand and reuse (with baby steps hand-holding the first couple of times). She doesn't need to mess with the css definitions, but she likes what happens to her dull-looking pages when I do (though on her site I'd probably leave them in .css files where she can't mess them up). A simple 'class' markup she could understand (and auto-ids) would enable us to work together to produce something visually spectacular without too much pain for her (no disrespect ma!). My mum *enjoys* making wiki pages - it only takes a few seconds and she's got something the old folks can appreciate. I know from experience that making & altering web pages has a very high indolence threshold (I avoid it unless absolutely necessary). I enjoy making wiki pages too, but I crave more power! Interestingly, though my mum started out completely computer-phobic, she's getting more savvy all the time. Sooner or later she could well end up being a Person B and I can hand over more of the site to her. But without the initial simplicity of wiki markup, she'd never have started. So yes, users are dangerous, and they can harm themselves if they're given too much too soon too easily. But the clumsy 7-year old you train to carefully handle wood-working tools may well outstrip you in years to come. Let them have that chance. I don't want my users to forever live in a dumbed-down, M$ wizards, Eating for Dummies world. Give them the option of infinite power, but let them start small. John. -- ------------------------------------------------------------------- T:01274 581519 / M:07944 755613 www.kershaw.org jo...@ke... skype:johnmkershaw AIM:johnkershaw MSN:joh...@ho... |