November 2007
From Jimbojw.com
Blog entries from October 2007.
Contents |
Don't use GTalk Emoticons v0.1
When I recently wrote How to get your old fast Gmail back I had assumed that using the old UI would correct the slowness that I was seeing. And it did - to a limited extent, but it wasn't as fast as it used to be, and often crashed Firefox if left open too long.
After investigating, I found that disabling my very own GTalk Emoticons extension resolved the issue. It must be that even though Google preserved the original UI, it is incompatible in some way with my extension.
So my standing advice is to DISABLE OR REMOVE GTALK EMOTICONS if you are experiencing a slowdown in Gmail with it installed - I know I did.
I have no immediate plans to create an updated version of the extension - however, if there is enough public outcry, I just might.
Sorry for the inconvenience. :(
[read more ...] -or- [leave a comment ...]
--Jim R. Wilson 15:02, 14 November 2007 (MST)
No more slow Gmail!
Update It's not Google's fault - it's mine. See Don't use GTalk Emoticons v0.1 for more details.
So, you're tired of how ridiculously SLOW the new Gmail UI is too, eh? Don't bother with Google's FAQ. Here's how to turn back the hands of time...
[read more ...] -or- [leave a comment ...]
--Jim R. Wilson 15:41, 13 November 2007 (MST)
Weekly Web Hack - Relative to What?
In this edition of the Weekly Web Hack, I'll explain the difference between the four possible values for the 'position' CSS attribute, focusing on the meaning of position:absolute...
By the end of this article, you should be able to:
- Understand what static, relative, absolute and fixed positioning are,
- Subvert the rules of 'position:absolute' to achieve proper element placement.
[read more ...] -or- [leave a comment ...]
--Jim R. Wilson 22:55, 12 November 2007 (MST)
Yet Another MediaWiki Parser Grammar Debate
In the last few days, the wikitech-l mailing list has seen a sizable amount of activity surrounding the "formalization" of the MediaWiki syntax by way of an established grammar. And as usual, the common arguments for and against are presented and a lot of points of view are espoused and defeated. Chances are that (as usual) nothing will come of this discussion besides perhaps a renewed commitment to revisit the issue later.
As I and at least one other contributor mentioned, all of this academic discourse is of limited real-world value. That is, arguing about whether or not the "problem" of formalizing the grammar is solvable using traditional tools (like EBNF) is patently pointless.
One assumption of the debate seems to be that wikitext is immutable. That is, that other than perhaps solidifying certain aspects by disambiguating edge cases, the current lexicon should not change. If this is strictly the case, then I have nothing further of value to add to the discussion. The existing PHP based MediaWiki Parser does a pretty good job of parsing and rendering MediaWiki syntax.
If, however, we assume that wikitext is *not* perfect, and that there could be better ways to meet the goals of the project, then we enter a realm where much more is possible.
For example, one "problem" that comes up quite often is the implementation of a proper WYSIWYG editor. In this context, "proper" usually refers to a round-trip proof schema whereby editing using either the WYSIWYG editor or a plain text editor has no effect on the other. Whenever this comes up, the usual community response is, "let's formalize the grammar first, then that'll be easy".
Personally, I think the following items are much easier to attain than formalizing wikitext, and have a much bigger immediate payout. I'd like to see:
- An unambiguous storage scheme (XML, light-markup, JSON, YAML - whatever)
- A method to allow lossy round-trips between this scheme and wikitext, Markdown, Textile, or whatever to allow experts to continue to edit in a standard <textarea>.
- A renderer that can output valid XHTML (and maybe someday FO or PDF)
- Alternative editors (Ajax, Flash/Flex, desktop apps - whatever).
All of this is probably not achievable maintaining full backwards compatibility with mediawiki syntax - so an initial setup script which does a decent job of converting wikitext to the unambiguous storage scheme would be necessary to convert existing articles. The Parser would have to be maintained in order to render old versions of articles prior to the advent of the new storage scheme.
Basically, rather than ask "what can we do to fix what we have?", I'd like to address the question of "given what we know, how would we do things differently?" Once an answer to that is established, then we can come up with an incremental game-plan to get there.
Anyway, those are just my two cents. As always, it's easy to throw tomatoes from up here in the cheap seats.
[read more ...] -or- [leave a comment ...]
--Jim R. Wilson 21:36, 12 November 2007 (MST)
Weekly Web Hack - Dynamic CSS Tag Filtering
In this Weekly Web Hack, I'll demonstrate how to use CSS classes for dynamic tag filtering. That is, showing and hiding page elements based on whether they've been tagged in a particular way...
By the end of this article, you should be able to:
- Understand how the browser's natural ability to filter elements can be used to your advantage,
- Implement a simple tag filtering mechanism using HTML/CSS and JavaScript.
[read more ...] -or- [leave a comment ...]
--Jim R. Wilson 23:29, 4 November 2007 (MST)
How to create Popup links in MediaWiki
One recurring question I've seen with respect to MediaWiki is "How do I create popup links?" That is, have links which when clicked launch a new window or browser tab.
Although there are some very good reasons NOT to allow this on a site, the following is one solution which requires only sysop permissions on a wiki. No extensions or other filesystem access is required...
[read more ...] -or- [leave a comment ...]
--Jim R. Wilson 14:45, 2 November 2007 (MST)
Category
Personal tools
Views
- This page was last modified 01:43, 27 December 2007.
- This page has been accessed 1,421 times.
- Privacy policy
- About Jimbojw.com
- Disclaimers