I think it’s a bad idea to rely completely on js for something as fundamental as displaying page content. But I guess it would be great as a tool for live previewing of Textile content without resorting to ajax and serverside rendering – at least that’s what I would use it for…

Yeah, indeed—why, have you considered using it for RedHanded comment previews?

As regards semantic value, it shouldn’t lose much in principle. Textile gives you all the basic HTML tags (plus CSS classes!), which is about all the structure you’ll get in HTML anyway.

In practice, though? There just aren’t the sort of tools out there for interpreting/transforming Textile like there are for HTML . SAX for Textile? No.

Pretty much it would end up in the same camp as those Javascript HTML compressors/encryptors which peaked around the turn of the century, albeit perhaps a little less evil.

I’d have to say it loses semantic value.

If the content is all in textile, what would happen to spiders, screen readers, or other parsers that rely on well-structured HTML to make sense of a document?

For instance, I don’t think Google would evaluate the javascript on the page to turn the textile into HTML before indexing it.

Well, no, I take that back. The one important bit of semantic structure that Textile costs you is nesting. Correct me if I’m wrong, but Textile doesn’t really provide a way of nesting divs or block-level elements, does it?

My first thought was to agree with Careo, but upon some reflection, I’m beginning to think that while it does lose semantic value, it doesn’t matter. Well, it depends on how this is implemented, and I couldn’t figure it out in the scant seconds I spent looking at the code and page.

Anyway.

How well this would work all depends on where the text is stored. If the text is stored in a JS variable, then I would want to assume that it’s probably hidden from Google, or is otherwise not worth that much. On the other hand, if it’s stored in a valid html document, wrapped with a pre tag, and was somehow, through DOM manipulations, re-rendered, then Google has a very good chance of working with the text. As far as the semantic value of that text goes, it doesn’t, imho, affect page rankings at all that much. H1 and B tags do help, no question, so obviously you’d have to decide whether the tradeoff is worth it.

If enough people think it is worth it, then I’d bet Google’s staff would tweak their engine to more intelligently parse textiled text.

why, it’s not a full port [yet]... and of course it’s only textile (not markdown)... but the parts that aren’t their yet mostly involve handling HTML tags and stuff… if you’re just writing raw textile with some simple html, you’re probably good to go… oh, and I haven’t gotten to tables yet…

And the reason I wrote it was to preserve the speed of client-side rendering already present in TiddlyWiki (which the client of ServerSideWiki is based upon)... there is a HUGE speed difference between an app like ServerSideWiki and Backpack on dial-up… running back and forth to the server just to render some content is very slow, especially if I’m using the connection for something else.

I know dial-up isn’t in style these days, but some of us are stuck with it and just tring to make the best of it. :-)

Currently the library has some Tiddly specific stuff (Wiki links and stuff) but it should be easy enough to rip out for general use.

And yes, raw Textile would lose some semantics… but Google seems to index and find ServerSideWiki pages just fine…

Josh w/ServerSideWiki

Of course you still have to run back and forth to the server on saves… but returning “save ok” is a lot faster than shipping back HTML for even a moderately sized text sample… plus with client-side you can render while doing the save in the background… instead of waiting for the save to complete before you know what to render. That’s where the big speed increase is.

Josh: the rationale behind the library makes great sense and I’m hoping to have it working on comment preview here in a short time. Well done, good to know Google ingests it all okay.

The semantic question definitely wasn’t a criticism of the Javascript port. More just: isn’t it crazy that HTML ’s semantics are tied to the markup and the scripting often acts to subvert that? I wish it were contrary, that the scripting would often work to improve the semantics. But this is impossible without a Javascript interpreter built into search robots, text browsers, portables, etc. Maybe someday embedding an interpreter in these cases will be as natural as embedding the rendering engine. But, for now, it’s strange and difficult I guess.

why: I dunno… issues of CPU usage and security aside, having to go through Javascript to get the content brings turing-completeness into the picture, with all the analytical problems that entails.

There’s basically a tradeoff between the expressivity of the data format and the depth of analysis that can be performed on it.

F’r example, say we want to determine whether or not a particular document (after Javascript transformations) is valid according to some schema. Or even just contains some keyword or another.

Well, what if the attached script never finishes to give us a result we can check? We call that an invalid document, ok.

But… how do we distinguish that from a document (program now, really) that just takes a while to produce a valid result? How long do we wait?

I’ve worked quite a bit on web spiders, and i would be surprised if the Google spider didn’t include a javascript interpreter. There is simply too much content you can’t get to without javascript. Integrating a js interpreter in the spider we use certainly wasn’t very hard, although it’s a bit of a hack right now.

I like the reasons for doing this, and I like the possibilities that could result which I can’t forsee: that is, I think it is good that attempts are made to break the mould, giving more scope for creativity.

However, I have some reservations: Firstly, I often turn Javascript off, as it is frequently cited as a security hole, so I err on the side of caution. Secondly, does this really give more of a speedup than enabling compression (which is part of HTTP as standard and few sites actually implement)?

Accessibility and the widest possible browser compatibility are also issues, but others have addressed these already.

It might be that compression is insufficient on its own, or that you aren’t supporting it yet and could benefit from it, as well.

In the hope that this provides useful stimulation :-)...

I think the pages would tighten semantic value, not loosen them. BTW , you incorrectly wrote “loose them”.

why, it’s important, like every implementation of ajax you see these days, to provide a standard HTTP alternative to the non-javascript users.

Apart of that, having a page, where I could be able to select any text block, which could be replaced into a textile editor by a simple way (double-click). After clicking on save, after the async server response says ok, the editor would automatically change back into html with my changes highlighted . It would be really nice :)

I’ll use it to display locally (for offline browsing purposes) the export.xml file that backpackit.com accounts can export. I guess it makes sense in this context, because there’s no possibility for server scripting taking care of the (textilized) data the export.xml file already contains.