stargeek
Simple markupSimple markupSimple markup 03/11/2003 11:53 AM Timothy Appnel: I have a new appreciation for the elegeance and simplicity of XML markup. Not that I didn't have one before its just grown the size of the Empire state building and illuminated in neon. Obviously, I'm currently embarking on a similar mission, and share Tim's appreciation for XML. My goals, however, are much lower than Tim's: I'm not trying to create a full markup language. I'm applying 80/20 whenever I can: e.g., unordered lists are enough. The times when full functionality is required, I'll personally use full XHTML. I'm currently looking into textile for inspiration. This is a GrokNews Entry: (what is grok?)Simple markupGrok Headline matches for Simple markupQ: Markup format?Q: Markup format? 03/14/2005 05:10 PM Q: Which markup format do you use when posting? Both Textile and Markdown are installed and I flip between them. When I want to post a lot of code without hassle I'll use Markdown because it seems smarter about that kind of thing. Most of the time, however, I want to just write so I'll use Textile; I find that it's a quick and mildly-intuitive way to access the various classes in my stylesheet for the myriad of things I do within this little block of space. Each has a purpose, so each gets used. I rarely enter raw HTML, and when I do it's typically to get around something broken in either markup format. Et toi? This entry was in Textile, for those keeping score. It
is much easier to enter p(ps). or p(note). rather than <p
class="ps"> or <p class="note">. Markup-Tree-1.1.0Markup-Tree-1.1.0 11/12/2003 06:50 PM Markup-TreeNode-1.1.0Markup-TreeNode-1.1.0 11/12/2003 06:50 PM Markup in titles in RSS?Markup in titles in RSS? 12/13/2003 08:14 AM The RSS 2.0 spec and its predecessors may not say clearly enough if you can or can't include markup in titles. But I don't think you should include markup in titles. Titles are like file names (not exactly of course). They are a happy medium between software and people. Both must be able to read them and make sense of them, in all contexts, and do so easily. While it seems reasonable that a description may contain markup, it also seems reasonable that a title should not. So, if I were writing a validator for RSS, and encountered markup in a title, I'd warn the author that many processors would not be happy about this and it would be safer to strip the markup from the title. Disclaimer: Scripting News is a weblog, not a spec. If you interpret it as a spec you will be making a mistake. I think I've said this quite a few times, but a few people still treat it as if I were writing a spec here. Not so. And not fair. A postscript. I went back to see what the spec actually says, and it turns out it's not really a problem with the spec, rather with my recollection of what the spec says. Scroll to elem ents of item. It says descriptions may contain entity-encoded HTML. It doesn't say that a title may. So if that's the biggest problem people can find with the spec (which many were flaming about when I wrote it, it's not like they offered any help, btw) then it's a pretty damned good spec if you ask me. FML: Fiction Markup LanguageFML: Fiction Markup Language 01/16/2004 11:33 AM When is someone going to come up with Fiction Markup Language — an XML spec solely for annotating fiction? For example: Take perhaps the greatest novel ever written: Ian Fleming's 1953 classic "Casino Royale." Let's break this down from a big chunk of text to make up something more usable. Obviously, you could mark the chapters and section numbers, but let's go further into the actual content of the narrative. Begin by surrounding all spoken text with tags. For example: <quote speaker="James Bond">My
name is Bond, James Bond</quote>
Perhaps you can have another attribute for "target" to identify to whom he's speaking. Then I could do an XPath query to find everything James Bond said to Vesper Lynd in the entire book. And how about locations? Surround passages with their physical location, like the casino floor, Bond's hotel room, etc. (where appropriate — wouldn't work in all situations). I could then use XPath to find all the unique locations in the book (this would be great for the globe-hopping James Bond novels). Identify "action" passages and mark them. How about the death of a character? Mark them so I can immediately find out where Le Chiffre was killed and read how it happened. Introductions of characters are another thing. Mark the first appearance of each character so if I can't remember who someone is, I can go back and find where they first appeared and who they are. I'm reading Tom Clancy's "Politika" right now, and I can hardly keep track of everyone. It'd be handy to be able to print a "report" showing who everyone is. (A good ebook client implementation of this would know what page the reader was on and not report anything past that page as to not spoil anything.) Maybe mark the beginning and ending of pages as they appeared in the original publication. And have some way for an expert to insert commentary about the text. James Bond novels are one thing, but imagine if someone did this for, say, "War and Peace". It would be like Cliffs Notes embedded in the text of the book. There's unexplored potential here. I can't be the first person to think of this. (And another question: is this just an attempt to completely suck the soul right out of fiction? Should we just leave it the hell alone?) Click here to comment on this entry Serenity through markup (ADTmag.com)Serenity through markup (ADTmag.com) 10/02/2002 10:55 AM MRL (Markup Recipe Language)MRL (Markup Recipe Language) 01/25/2004 08:35 PM Web site updated Keep 'em separated: Layout and markup.Keep 'em separated: Layout and markup. 10/28/2003 11:06 PM So, my idea was to follow the nice development models that often exist at a platform level in UI architecture and apply them to the view components of a design pattern - particularly with an focus on extensibility. But I... W3C Markup Validator UpgradedW3C Markup Validator Upgraded 05/06/2004 09:47 PM 2004-05-06: W3C is pleased to announce an upgrade to the W3C Markup Validation Service. The new release is easier to use and install. It features new documentation and navigation, and offers helpful explanations and recovery mechanisms instead of fatal errors. Managed by a team of volunteers and the W3C Quality Assurance Activity, and supported by a large community, this validator is the single most popular resource on the W3C Web site. Read the announcement. (News archive) A myriad of markup systemsA myriad of markup systems 04/12/2004 11:15 PM It's hard to avoid the legions of custom markup systems out there these days. Every Wiki has it's own syntactical quirks, while packages like Markdown, Textile, BBCode (in dozens of variants), reStructuredText offer easy ways of hooking markup conversion in to existing applications. When it comes to being totally over-implemented and infuratingly inconsistent, markup systems are rapidly catching up with template packages. Never one to miss out on an opportunity to reinvent the wheel, I've worked on several of each ;) My most recent markup handling attempt has just been published as part of my SitePoint article on Bookmarklets (cl iché). It's a structured markup language in a bookmarklet: activate the bookmarklet to convert the text in any textarea on a page to XHTML. The syntax is ridiculously simple, and serves my limited needs just fine: = This is a header Here is a paragraph. * This is a list of items * Another item in the list Converts to: The algorithm is simple, and easily portable to any language you care to mention:
The bookmarklet comes in two flavours: Expand HTML Shorthand (the full version) and Expand HTML Shorthand IE, which loses header support in order to fit within IE's rippling 508 character limit. A more capable bookmarklet could be built using the import-script-stub method described in my article, but the implementation of such a thing is left as an exercise for the reader (I've always wanted to say that). Incidentally, there's a very common bug in markup systems that
allow inline styles that proves extremely difficult to fix: that of
improperly nested tags. Say you have a system where
*text* is bold and _text_ is italic; what
happens when the user enters
_italic*italic-bold_bold*? Most systems (and that includes Markdown, Textile and my
home-rolled Python solution) use naive regular expressions for inline
markup processing and will output vadly formed XHTML: New Generation of the W3C Markup
|
Also check out: |
