[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.