[pmwiki-users] New Skin - YAML

[Ed W]

It was deliberately provocative, don't rise too high ...

> Nothing prevents PmWiki from generating the full range of HTML tags,
> it's simply that PmWiki doesn't generate them all by default.
>   

Agreed

>> (hint, hint, tables should have TH rows, 
>>     
>
> TH *rows*?!?  I thought that <th> represented individual cells...?
>   

Well, you know what I mean. 

There is a gap in functionality though between || tables and 
(:tables:).  Would love to see that gap narrow, which would largely 
eliminate the "Advanced tables" recipe.  (Most of the zebra stripes 
thing can easily be done with some CSS and a slightly adapted table output)

(Basically I think the tables are good, just not sure why the resistance 
to allowing full range of output from the (:table:) markup?)


>> also >>div<< syntax should just 
>> nest because there surely can't be any real needs for divs with 
>> automatic closing tags?? 
>>     
>
> False -- I use >>div<< with automatic closers a lot.  For many of
> the things I write, it's much more natural to simply go from
> one div to the next without having to worry about nesting/closing.
>   

Bah, it still feels like a hack.  pmwiki tries to guess closing tags 
everywhere and it does a good job, but generally it just feels like it's 
a hack and personally I think there whould be explicit closing tags on 
block elements (meaning tables and divs)

Curious for a real example though... Seems unusual to have multiple 
block level elements all butting up against each other giving you the 
opportunity to dodge the closing tags?  In contrast it would seem more 
*probable* that nested block level elements were desired (on average?)


>> Also %apply=a% should be in the default syntax 
>> and link syntax should automatically acquire an inner span by default - 
>> this is all mostly fixable with some addons though)
>>     
>
> It's very difficult to get %apply=a% to work properly in the
> general case, because HTML link syntax is a bit weird.

It works well enough on average as is, although I notice that it's not 
collapsing multiple "class=blah" constructs, which from memory the code 
was attempting to do?  Haven't debugged it though

>   I also
> disagree that link syntax should automatically acquire an inner span--
> a link _already_ represents a span, so I don't quite see why it needs
> an additional set of tags to style it.
>   

Because of IE...

Depends on your goals of course, but if you read all the cool cat's 
blogs then it becomes easier to do fancy styling of your link tags if 
you have an inner span to play with.  Most of the fancy techniques to 
add background graphics, icons make them into buttons (sliding doors 
technique especially) require a second element to play with.

Probably this won't be needed on FF4 and IE12, but it seems helpful 
right now

Example of turning a link into a button (orange buttons inline):
http://www.mailasail.com/Shop/IridiumPhones

Can't see any negatives in doing it either...

Just my 2p anyway

Ed W

P.S.  Thanks for PMWiki
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.pmichaud.com/pipermail/pmwiki-users/attachments/20090520/517c9086/attachment.html