(why, oh why do i get into these ridiculous args online... one day
i'll learn...)

On 2/6/06, Plasma Studii <office@plasmastudii.org> wrote:
> >>> You don't see the utility of CSS?
>
> >> nope. just the opposite. think it does more harm than good. because it forces people to think of "web pages" as pages, not simply collections of data (in some order, but not a layout)
>
> > argh! That's what CSS does!
>
> ??? (maybe you thought we were referring to XML here?)
>

do you just want to be difficult? This is totally ridiculous!

ah no, xml in the form of XHTML is the strucure, what allows this
structure to be presented? Currently on the web it's done with CSS.

>
> >>> CSS's value in a nutshell: separate the structure of the data
> from it's presentation.
>
> >> that's a great goal, but not what styles ultimately do. they neither simplify the design process (a supposed benefit of separating it from the HTML (which was designed so anyone could easily learn it)), nor speed up the processing.
>
> > You make this statement 'not what styles ultimately do' but you don't
> back it up with any examples or any reasoning whatsoever. See
> http://www.csszengarden.com/ for an example of how different styles
> can completely change the way an XHTML file, using the same exact
> mark-up, can be presented.
>
> use a browser for the blind. content is not just design. and design isn't the only vehicle for content.
>

ARGH! THAT'S MY POINT! The CONTENT, ie, MARKED-UP DATA is separate
from the presentation. So a blind person can use a screen reader
without a bunch of tabular hacky cruft and someone with a nice big
monitor can see a beautiful layout. This is precisely what CSS media
types are for (http://www.w3schools.com/css/css_mediatypes.asp)!

Why you continue not to access this simple idea is beyond me.

>
>
> >> div tags alone would be great. but styles make for "spaghetti code" and put far too much emphasis on print-like rigid layout. that much layout control isn't neccessary, it's a chosen addition. serves no actual purpose, just an inability to see things without it.
>
> > How do styles make 'spaghetti code?' A well marked-up XHTML file
> combined with a well-structured stylesheet is very simple to read. No
> ziti, no spaghetti, not even a caeser salad to start.
>
> the style declarations are in the header or sometimes in a separate file. then often referred to in the javascript. then again in the body. then there's #def section that is often after the script. why remember?
>

to each his own i suppose, i guess it's a subjective thing. it seems
you're talking more about all the diff web tech than CSS in
particular.

> Flash is far worse in this respect, but i like to know where all the code is in one consistent spot without hunting around. the BASIC command GOTO usually instigates complaints about encouraging "speghetti code". you have to follow it as it jumps from section to section.
>
> makes debugging more clear when you don't have to guess where some code would be. i'm sure CSS can be done neatly, but usually isn't. but that's hardly the worst problem. the worst is the conceptuaol page layout vs. screenful of info thing.
>
>
> >>> If I had known about it
> when making '1 year performance video,' it would have helped with
> sending data to the server to increment viewer's time (it used a
> hidden iframe to do it -- a bad hack IMO).
>
> >> trivia: actually, the whole thing could have easily been done with a couple lines of code. assumed that's the way you used. But whatever works.
>
> > Please elaborate -- I had to talk to the DB on the server, it wasn't
> much data to send, but I couldn't reload the page everytime, it would
> have completely destroyed the viewer experience (I probably could have
> and should have done it in the flash movie, but I didn't). So I ended
> up sending it thru a hidden frame. XMLHTTPRequest would have worked
> better but the techniques hadn't been developed fully at the time.
>

I have no idea what you were tryiing to communicate with that little
PHP script below..

> the wonderful thing about PHP is it is so readable. The actual mechanics of this aren't crucial to get the idea...
>
> ---
>
> <html> <! <- you don't really need this or it's end tag, but this illustraters the idea>
> <body>
>
> check out the artists now!<p>
>
> <?
>
> $Now = date("h"); // or whatever letter for hour in military is, but you get a number 0-23
> $RandomNo = rand(1,9); // for fun
> print ("<embed src=clips/$RandomNo/clip$Now.mov width$0 height0><p>");
>
> ?>
>
> </body>
> </html>
>

Perhaps you've never seen the piece? That's fair. It has two videos
playing in flash embedded in an XHTML page. These videos are loaded
dynamically by talking to a php script on the server. Part of the
piece is that a user is supposed to watch it for a year. The site
keeps track of how long they've watched it. How does it keep track?
Every minute the client needs to tell the server that the page is
still open and being viewed. If the page refreshes, that could do it,
but that would ruin the streaming video effect. So i use hidden frame
to load a php script that increments the veiwer's time in the db. My
point was simply that it would have been better to do it with
XMLHTTPRequest instead of the hidden frame for reasons i don't feel
like going into.

--
<twhid>www.mteww.com</twhid>

On 2/6/06, Plasma Studii <office@plasmastudii.org> wrote:
> t.whid wrote:
> > <this may be flame-ish>
>
> no prob. from anyone else, i might be taken aback. but i've known you smell funny for a while, so i don't take it personally!
>
> >

I'm glad you don't take it personally. And you're right, just ask my
friends and co-workers, I smell funny.

> > +++
> >
> > quoting plasma:
> > In many cases, like CSS, there was no problem, but a new wave of users
> > (in about '99-'02), were impatient to make HTML more like print,
> > rather than see they are very different animals.
> >
> > +++
> >
> > You don't see the utility of CSS?
>
> nope. just the opposite. think it does more harm than good. because it forces people to think of "web pages" as pages, not simply collections of data (in some order, but not a layout)
>

argh! That's what CSS does! There is no layout in XHTML except the
default styles that the browser gives it. There is an order
<head><body><h1>, but no layout -- CSS provides the layout and you can
make styles for all different ways to display it.

> > CSS's value in a nutshell: separate the structure of the data
> > from it's presentation.
>
> that's a great goal, but not what styles ultimately do. they neither simplify the design process (a supposed benefit of separating it from the HTML (which was designed so anyone could easily learn it)), nor speed up the processing.
>

You make this statement 'not what styles ultimately do' but you don't
back it up with any examples or any reasoning whatsoever. See
http://www.csszengarden.com/ for an example of how different styles
can completely change the way an XHTML file, using the same exact
mark-up, can be presented.

>
> div tags alone would be great. but styles make for "spaghetti code" and put far too much emphasis on print-like rigid layout. that much layout control isn't neccessary, it's a chosen addition. serves no actual purpose, just an inability to see things without it.

How do styles make 'spaghetti code?' A well marked-up XHTML file
combined with a well-structured stylesheet is very simple to read. No
ziti, no spaghetti, not even a caeser salad to start.

>
> > If I had known about it
> > when making '1 year performance video,' it would have helped with
> > sending data to the server to increment viewer's time (it used a
> > hidden iframe to do it -- a bad hack IMO).
>
> trivia: actually, the whole thing could have easily been done with a couple lines of code. assumed that's the way you used. But whatever works.

Please elaborate -- I had to talk to the DB on the server, it wasn't
much data to send, but I couldn't reload the page everytime, it would
have completely destroyed the viewer experience (I probably could have
and should have done it in the flash movie, but I didn't). So I ended
up sending it thru a hidden frame. XMLHTTPRequest would have worked
better but the techniques hadn't been developed fully at the time.

--
<twhid>www.mteww.com</twhid>

<this may be flame-ish>

+++

quoting plasma:
In many cases, like CSS, there was no problem, but a new wave of users
(in about '99-'02), were impatient to make HTML more like print,
rather than see they are very different animals.

+++

You don't see the utility of CSS? If you don't even understand the
benefit of CSS than this really is an impossible converstation to
have. CSS's value in a nutshell: separate the structure of the data
from it's presentation. In this way the data can be transformed in
it's presentation to handle different media: large screen, small
screen, print, screen reader etc.

Ajax is simply a technique. One that is being used to create user
interfaces that user's like better (when it is done well). Yes it's
'hot' right now, it has faddish glory. But it became popular because
developers understood that they could make platform-agonsitic web
applications that felt and acted like desktop applications to the end
user.

It's utility for artists is up to individual artists to decide. Some
examples of how i could have or will use it: If I had known about it
when making '1 year performance video,' it would have helped with
sending data to the server to increment viewer's time (it used a
hidden iframe to do it -- a bad hack IMO). I'm also doing a piece that
requires voting. I send the vote to the server using XMLHttpRequest
then receive the current tally back to the browser and display it
without having to reload the entire page (like Digg).

On 2/6/06, Plasma Studii <office@plasmastudii.org> wrote:
> ha ha. "to Ajax or not to Ajax" will probably be a moot point in a few years anyway. that's really not my question though. no, i don't mind obsoletism. though higher end tech, rarely becomes obsolete. C was around before most of us were born. Perl was probably around before the net. Java has existed since it was created. PHP is relatively new, but i do hope it survives (not because i can't learn a new thing?) but because it's a useful solution. (CGI bins can be a pain for everyone, not just the server programmer)
>
>
In many cases, like CSS, there was no problem, but a new wave of users
(in about '99-'02), were impatient to make HTML more like print,
rather than see they are very different animals.
>
> It's great Google can use Ajax and the world map thing is a perfect example for them. But it's not one that applies to any of us. We don't have nearly that much info, or an audience as big who need to explore that much info. Even if we created an exact replica of the gooogle map, we just don't need to waste that much time creating millions of details, when maybe a thousand will ever be seen at most.
>
>
> I am not arguing against knowing it though. remember image maps (before slices). that was cool, but now you rarely see em. browsers will still read em. you could surely run into a problem, where that'd be a good solution (needed it for a phrenology map a while ago). there are maybe 1 in 100 times, using meta tags for "push" animation has come up. hell, i bet there's a use for the <blink> tag (remember that?) things so rarely actually become obsolete.
>
> i was just asking when could this possibly be useful? there aren't that many cases where you have a table of thousands of pieces of info, one would need scrolling precision to view, where a choice of buttons wouldn't be fine (though obviously a linear "forward", "back" buttons are just plain bad design). someone may really like info to slowly pan across the screen, rather than a "jump cut". but how is it worth the extra work to add that feature for this, if it means using the convoluted option instead of the easy one? ajax is hardly "neat" or "efficient". if it takes 5 times the work to add scrolling, it better be worth it.
>
> if there's a practical reason to use it, i'm all for it. but if it's just "we climbed it because it was there", ... just keep quiet.
>

--
<twhid>www.mteww.com</twhid>

Yes, you are totally baffled.

You are confused btw code that is executed on the server-side (PHP,
Eric's Java code) and that which is executed on the client-side
(javascript, XHTML).

For example, AJAX techniques would allow someone to load the PHP
scripts you've been posting, read a the flat file and then write the
contents to a web page without re-loading that web page. The
HTTPrequest object is basically acting like a little browser within a
browser: it goes to the server, gets new info and returns it into a
javascript object. What most developers are using this for is to
create UIs for web applications that act more like UIs of desktop
applications -- there isn't this whole send to server/wait/reload page
paradigm that has been the web til recently.

For example, Google maps. As you drag around the map the page is
constantly making requests to the server and getting the images you
need to build the map as you drag around. Go give it a try, you can
drag your ass all the way from San Fran to NYC -- this wouldn't be
possible without using Ajax techniques because Google would need to
download an entire map of the US to your browser if they didn't want
to reload the page everytime you dragged off the current frame of
reference. With Ajax you just get the parts you request. This makes it
much more responsive.

On 2/5/06, Plasma Studii <office@plasmastudii.org> wrote:
> for most of us, we're not dealing with thousands of pieces of info.
>
> it'd make sense for google to use a db, no need to read every map. there must be thousands. but why use Ajax to read em, when there are far more straight foreward ways? we don't have any use for the features Google needs, but if we really do want em, they they are easy to find.
>
>
> here's how to read the 3rd line (start from 0) only of a page. loads nothing.
>
>
> $Open = fopen("somePath/somePage.whatever", "r");
> if ($Open) {
> $Data = file ($Path);
> $Line3 = $Data[2];
> }
>
>
> am still baffled?????
>
>
>
>
> Pall Thayer wrote:
>
> > I think you're missing the point. It's not the ability to read or
> > write data to the server but the ability to do so in a way that
> > doesn't require reloading the entire page. Lets say person A in
> > Arkansas does something on the page that rewrites the data in your
> > anything.txt file. Person B in Botswana isn't going to see those
> > changes unless they reload the page. AJAX lets you do the reloading
> > in the background. Probably the best use of AJAX to this day, and
> > almost certainly a contributing factor to it's renewed rise to
> > stardom (it's been around for a while) is Google maps. It has
> > revolutionized the way maps are presented on the web. The interface
> > is absolutely brilliant and a huge leap away from the old method of
> > clicking on N, E, S or W to reload an image.
> >
> > Palli
> >
> > On 5.2.2006, at 10:09, Plasma Studii wrote:
> >
> > >> You will need to add the xmlrpc classes to your classpath, but
> > >> thats trivial.
> > >
> > >
> > > hey eric,
> > >
> > > probably, i'm just not getting this, but seems like the same result
> >
> > > would be SO much easier with PHP? PHP is super clear, whereas Ajax
> >
> > > just isn't at all. It's kinda the diff between intuitive and
> > > memorized. most folks don't even notice how much they memorize(as
> > > opposed to understand), but a lot seem like just arbitrary steps.
> > > sorta why reading/writing C is actually FAR more intuitively
> > > comprehensible (though compilers are usually convoluted) than
> > > anything in Flash.
> > >
> > > the steps to write to a file (any file on the web, not just XML) in
> >
> > > PHP are clear. seems it would be a lot more "available to
> > > artists"? is there some perk i'm missing here? Seems like
> > > bafflingly convoluted MS design?
> > >
> > >
> > >
> > >
> > > <?
> > >
> > > $FileOpen = fopen( "anything.txt", "w" ); // specify file to write
> > to
> > > if ( $FileOpen ) {
> > > fwrite( $FileOpen, "write whatever you want, including HTML, XML
> > > or javascript code" );
> > > }
> > >
> > > ?>
> > >
> > >
> > > that's ALL the code it takes!
> > >
> > > upload it to a server running php (and about all of em do) this
> > > shows up on the page (or it's included with osX, a download, etc).
> >
> > > the code doesn't. if the page doesn't exist, it'll create it
> > > (though there's also a file_exists() function you can use if you
> > > don't want that to happen) the php could go absolutely anywhere on
> >
> > > your HTML page. just name it x.php instead of x.html. it's
> > > designed with the coder in mind, not the code (which is why i say
> > > an MS thing, they seem to be incapable of thinking any way but from
> >
> > > their own perspective)
> > >
> > >
> > > reminds me of depreciating the <center> tag. what possible
> > > improvement could you make by replacing it?! if it's off by a
> > > pixel one in a thousand times, who cares?! (Web design just isn't
> > > print design and CSS and XHTML are just blatantly dumb code
> > > design) the tag is well worth it just because it works so clearly
> > > and without memorizing. Design utility extends to a lot more than
> > > just Italian coffee makers and German cars. Code is another
> > > appliance.
> > > +
> > > -> post: list@rhizome.org
> > > -> questions: info@rhizome.org
> > > -> subscribe/unsubscribe: http://rhizome.org/preferences/
> > > subscribe.rhiz
> > > -> give: http://rhizome.org/support
> > > +
> > > Subscribers to Rhizome are subject to the terms set out in the
> > > Membership Agreement available online at http://rhizome.org/info/
> > > 29.php
> > >
> >
> >
> >
> > --
> > Pall Thayer
> > p_thay@alcor.concordia.ca
> > http://www.this.is/pallit
> >
> >
> >
> >
> +
> -> post: list@rhizome.org
> -> questions: info@rhizome.org
> -> subscribe/unsubscribe: http://rhizome.org/preferences/subscribe.rhiz
> -> give: http://rhizome.org/support
> +
> Subscribers to Rhizome are subject to the terms set out in the
> Membership Agreement available online at http://rhizome.org/info/29.php
>

--
<twhid>www.mteww.com</twhid>

total agreement

tour de force de web art

le jimpunk est magnifique

On 1/9/06, M. River <mriver102@yahoo.com> wrote:
> jimpunk wrote:
> > http://www.jimpunk.com/www.pulp.href/
>
> Nice. Very very nice. Thx.
> +
> -> post: list@rhizome.org
> -> questions: info@rhizome.org
> -> subscribe/unsubscribe: http://rhizome.org/preferences/subscribe.rhiz
> -> give: http://rhizome.org/support
> +
> Subscribers to Rhizome are subject to the terms set out in the
> Membership Agreement available online at http://rhizome.org/info/29.php
>

--
<twhid>www.mteww.com</twhid>