Archive for the ‘script’ Category

Do NOT attach “target” through script!

Friday, July 28th, 2006

Using target in (X)HTML Strict. If you need to use the target attribute, either stick with Transitional DOCTYPEs, or add the target attributes dynamically using semantic scripting, e.g. based on semantic class names.


NO NO NO NO NO! Your page is just as invalid if you add target in with script as if you put it in your markup.

If you absolutely must open a new window, make it a normal <a href=""> and use and cancel the default action for the link. But if you weren’t providing any size or chrome info (which are impossible with target anyway), then you don’t have any reason to be opening a window in the first place. Just don’t do it.

HTML is not an “Application Language”

Tuesday, June 13th, 2006

Part of the reason is of course that HTML was originally a document language and is slowly evolving in being both that and an application language.

I’ve said it before and I’ll say it again: It shouldn’t be. HTML is fundamentally a language for displaying information. Accepting input should not be a part of HTML because a) It’s out of scope, and b) it’s useful in places that HTML isn’t. Manipulating information is also out of scope (and thankfully has never been mushed in). An application requires bits from all three: Accepting, manipulating, and displaying (it also benefits from a fourth: styling).


Wednesday, October 12th, 2005

Blah, this is my third time writing my post, and I’m not really feeling writerly right now, so I’m just going to say what I need to quickly and get it over with.

Basically, the “Markup / Style / Behavior” split that everyone always talks about is wrong. The split really should be Document / Presentation / Application. Presentation is split into Styling—CSS—and for lack of a better word Branding—templates, a spec for which is yet to be developed. Application is split into UI—Forms—and (again for lack of a better word) Programming—client-side or server-side, or one as a fallback for the other.

Because of this I’m not really happy with any of the specs currently out there or currently being developed, with the one exception of CSS, which fits nicely into Presentation: Styling. I first started noticing this with WF2, which, although it’s one of the closest to being good, extremely bugged me by having the template attributes apply to all HTML elements, instead of just fieldsets like I said it should. I haven’t read the WA1 spec enough to comment well on it, but from passively reading the mailing list I get the vague impression that it fails to stay in one category in a bunch of ways. I haven’t read any of XFORMS, but from what I’ve heard of it it sounds like it has not only that problem but plenty of others.

Actually the first sentence of that last paragraph is wrong. XML is okay, since it doesn’t give any of the categories, it just standardizes markup. The Document, Style: Branding, and Application: UI categories will all be markup based, and having a standard markup is good. Javascript I’m only just becoming familiar with, but it seems like a good fit for Application: Programming (client-side). That’s not saying those don’t have other problems, just that as far as I can tell they’re not fundamentally flawed in the way I’m discussing.

Going to end this before I start rambling, since like I said I really don’t feel like writing, so much so that I’m not even going to proofread. So.

Reasoning for paragraph 2 left as an excersize for the reader. (Basically, this whole post is telling you what to think, you have to figure out why to think that.)

I’m currently getting more blog spam than email spam, so if you post a comment please also email as it’s less likely to get lost that way.

Bug 192891 was fixed!!

Thursday, September 22nd, 2005

Bug 192891 was fixed! Woohoo!

Sandboxing javascript for user comments

Sunday, July 10th, 2005

It would be nice to be able to sandbox user comments so that they could include more than just plain markup. For styles this is trivial: provide a [this-comment] selector, and cut out any selector that doesn’t start with it (would fail IFF a future version of css introduced a parent selector, but even then could be easily fixed). For scripts, I’d assume it’s quite a bit less trivial. It would be really nice for us web geeks, though.

I even wish I could offer a bounty on this. It would really be worth it, I think, if it were done correctly. Unfortunately I’m too young for most things financial—credit card, paypal, etc. Oh well. Hopefully someone will find it an interesting challenge.

Clean Source vs. Clean DOM

Thursday, June 30th, 2005

You know what bugs me? When people talk about keeping the source clean and then go and do something like this. (No offense to the author, as it was just the first example I found and because obviously a clean source is important.)

The point is, it’s not about the source, it’s about the DOM. When I point my obscure-yet-relevant-standards-conformant tool at your page—be it lynx (bad example, so make that lynx-made-perfect), a screenreader, or even just my Firefox-with-a-userContent.css-file—it should work. And to do that you need a clean DOM the whole way through: start with a clean DOM (clean source), and then when you do your styling and your scripting, keep it clean.

Javascript Things

Saturday, June 11th, 2005

I now have a new part of my site devoted to the things I make with Javascript. At the moment, this includes one thing—the thing I needed help on in my last javascript post. (Thanks again, Anne!). Hopefully, as I learn more and get ideas for new things to do, it will grow.

The easiest way to get to it is from my homepage, it should be two clicks away.