[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [ProgSoc] Easy / dumb (take your pick) dyn-HTML question



Myles Byrne wrote:
although we'd all like to select our parents (see what I did there?)

You made me groan. What do you think you did? :)

I just checked the spec a such a feature was never proposed. Shame.

Yeah, that is surprising. I wonder what the rationale for omitting such a feature was. (i.e. maybe resolving cycles becomes too difficult?)


This is the closest you'll get

Nice, um, hack. :P

I often get caught out being unsure where to nest various parts of my HTML content too.

I.e. what happened in your example was that the content is 'logically' dependant on the anchor, but also 'logically' dependant on a 'content' container.

When you render your content to HTML, you need to choose a single logical hierarchy.

Sometimes I lament that HTML doesn't have a facility for symbolic links.

Writing something like:

#somediv { background: red; }
#somediv li { list-style: square; }
#somediv p { line-height: 1.5; }
#somediv div.someclass p { color: blue; }

gets pretty tiresome.

Meh.

It would be nice to do:

#somediv { background:red; } @descendants {
    li { list-style: square; }
    p { line-height: 1.5; }
    div.someclass p { color: blue; }
}

Less repetition, easier to read.

Arguably.

I've been toying with the idea of writing a parser that converts the second syntax to the first, anyone want to have a crack at the regular expression? ;)

I wouldn't take the decision to invent your own DSL lightly, especially in light of the fact that there is already an open-standard which adequately covers your requirements.


(That said... I've done it. :)

(I have an XML-based language for describing a CSS document with nested dependencies, and an XSLT for turning it into CSS. I'd post it, except it's all the way over there. I've never put it into production though, mind.)

Also John's javascript, like his emails, was too verbose

Bah!

It's good to know you are actually capable of writing short sentences ;)

Sure.

there was a lot of whitespace). If you use the prototype library (essentially a bunch of js extensions) you could do it inline

Is this [1] the one? Do you use it?

Yep. I include it pretty much every time I need to write some javascript. It's not very well documented but it kind of makes up for that by having clean, easy to understand source.

I'm very trepedatious when it comes to using other people's js libraries.

As you know, I've been playing about with js for quite some time now, so I'm pretty familiar with all the things you can do with it. I've written a whole heap of my own 'framework' stuff over the years, too.

It's fun while you're learning, but in the end it just doesn't matter.

My philosophy is more along the lines of "Remember much less, and write slightly more."

You wait and see. These js hackers will end up abandoning their frameworks once they've finished learning js. It'll take another year or two.

You mean you didn't write your tests first!?

Actually, I'm finally (after about 20 tries) getting into the test first swing. Mostly at the interaction level, occasionally at the functional/unit level. Any recommendations for a js testing suite?

I have actually stumbled on one in my travels. ('jsunit', maybe?)

It's not my thing, though.

Not interested in an I.E only one though.

Are you referring to Watir?

Also do you know if there's a tool that allows you to inspect the js object space of a single page? Without objects from the chrome or other open pages getting in the way? Essentially some form of js profiler?

The JavaScript Debugger that comes with (or is available as an add-on for?) Firefox is fairly decent.


Just add a watch for an expression like 'window', or 'document'.

Or, you could always start here:

 for ( var i in document ) { alert( i + ": " + document[ i ] ); }

Then make it a recursive function which enumerates child elements too, with an 'stack' context designating the current 'path' through the tree, then lookup the '===' operator, allocate object ids, emit <a name> tags for unique objects, add <a href=#name> tags when you encounter something already on the stack, open a frame in a new window, spit HTML in the xoxo microformat, and BYO document state interrogator.

I've been meaning to get around to that for some time now. :P

One thing John is right on: Javascript isn't the tool of the devil.

You mean another thing, right? ;)

What was the other thing?

Can I buy a plural? :)

You might be interested in this [2], if you haven't seen it before.

Yeah, seen it before. It's a good idea, I'd probably use it on a small mostly-static site but I wouldn't trust it with a js heavy web app

That's much the situation I find too. I always feel like I *want* to use it, but never feel quite happy to actually do so.


The author (Dean) is actually quite a good js hacker though. Have you see his Base class (http://dean.edwards.name/weblog/2006/03/base)? pretty nifty.

This is the sort of thing I'm suspect of. I've done this sort of thing myself. At the end of the day, what he's trying to do (and what I was trying to do) was to make js something that it basically isn't.


(That would be kinda like implementing turing machines in lambda calculus, right? Fun, but not actually a very good idea.)

I don't know if you've ever seen it, but there are some classic cases of people using C++ meta-programming to turn C++ into Pascal, for example. In the end, that's just a silly thing to do.

JavaScript is for hacking, not building cathedrals. :)












- You are subscribed to the progsoc mailing list. To unsubscribe, send a message containing "unsubscribe" to progsoc-request@xxxxxxxxxxxxxxxxxxx If you are having trouble, ask owner-progsoc@xxxxxxxxxxxxxxxxxx for help.