[pmwiki-users] New Skin - YAML
lists at wildgooses.com
Wed May 20 15:26:27 CDT 2009
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.
>> (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
Example of turning a link into a button (orange buttons inline):
Can't see any negatives in doing it either...
Just my 2p anyway
P.S. Thanks for PMWiki
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the pmwiki-users