Roadnode Rodeo

Hi gang!  Good replies over in "'style' attribute" and "Simplicity of 
Concept" threads!  You kids are just now getting back on subject after 
my last hijacking attempt, so I figured I'd better start a new thread.

I have to agree that CSS, especially the 'cascading' of it, and its 
contorted property names for box model manipulation... is less than 
optimal for my wants.  Aside, I could use Björn's CSS schema thing [1] 
in a hurry too, as I build authoring tools with "switch to css spec xxx" 
rotary switches on them... but that's another subject.  I'd like to 
stick to my needs for the core attributes for phrase elements like EM 
and transclusion point indicators like P elements.

Today, I'm going to try to convince a few thousand of you, that the web 
is headed for 'nodeserving'.  This, again, is the act of pulling or 
pushing... single or tree-hierarchies-of xml/html elements around from 
place to place.  Ted Nelson calls it 'transclusion' [2].  I call it 
COMING SOON.

I believe there is a 'force' against nodeserving, and that is 
advertisers.  Let's face it.  When a person can build a "my start page" 
homepage using pieces of other people's documents from all over the web, 
I suspect IMG tags with ad banners will NOT be one of the transcluded 
nodes in that page.  NodeGETting has the abilities to 'request' any 
section (element or hierarchical branch) of any static or dynamic 
document exposed to nodeserving.  I have been nodeserving on MOO Canada 
for awhile now... mostly serving object tags with media in them... to 
moo users who drive MOOzilla, an html/telnet node-viewing moo client. 
It is a js/xul telnet with a gecko canvas atop, and a pile of media 
plugins.  Because of MOOzilla's current design, any node or tree section 
sent from the moo, to the user's client, must contain its style 
information within the style attribute of that element (and its 
underlying nodes).  And, this makes perfect sense in a way, because 
nodes such as these object tags... need to keep a sort of independency. 
  They need to be able to 'travel' with everything they need, the same 
metaphorical example I used in another post.

After recently looking at xhtml's core attributes (like those for the EM 
element), and seeing only class, id, and title... I feel the need to say 
something. (What's new?)  Although its likely my ideas are easily shot 
down, I do indeed still need places in the core attributes to store both 
style and meta information.  Without these two "storage areas", the W3C 
is boxing-out nodeserving as a future technology, in my opinion... and 
I'll want to know why.  In fact, there is movement to box-out some 
CURRENT technology I have in use already.  I am currently using the 
style attribute in my moo nodeserving, and I NEED the meta attribute 
NOW... and to have its contents viewable under a choice on a browser's 
RIGHT CLICK ON ELEMENT pane.  Wouldn't that be SWEET!  Anyhow, here's 
some of my ideas...

The TITLE attribute is meta data... and so is CLASS and ID.  In fact, 
class and id should both be JUST id.  Make it so that if id is to be a 
class, its used as @id="blah" or something akin to that.  Now, that 
leaves us with... nothing.  No core attributes on the EM element... 
except... meta and style (which need to be added).  Even the 
uncompressable up-to-122-css-property style STRING that gets put into 
the style attribute for my sent MOOzilla object (and other) tags... 
COULD be a member of meta's key/value set.  It could be right there 
alongside class, id, title, author, node-sent-from, date-sent, etc etc. 
  Would this be so bad?  A giant 'about' collection of dublincore-like 
stuff, all possibly crammed into the lone meta attribute of ANY 
tag/element?  In my opinion, if you don't want tag soup, you will need 
attribute soup.  And how does one keep attribute soup under control?  By 
putting all possible attributes plus some... into the single meta 
attribute.  At least that's one way of looking at it. :)

Now, back to this peeking (retrieving) of 'computed style' FOR an 
arbitrary transcludable element in an arbitrary open-for-transclusion 
document.  Folks, it doesn't look like any content management system or 
webserver will be able to gather the value of all 122 css property 
values that WOULD be applied to a certain document element if that 
document were rendered in a browser.  This is one of the weaknesses of 
css, in my opinion.  Or maybe, the 'feature' of 'cascading' caused this 
problem.  Either way, if its not changed, NodeServers Of Minnesota (NOM) 
will be forced to come up with another styling system... because NOM 
members always offer to send author-preferred style WITH nodes, and 
always send metadata about a node, with the node as well.  When I say 
"WITH" it, I mean INSIDE its opening tag.  Its our 'standard package'. 
We can hmm and haw all we want, but that's still going to remain the 
standard package of a NOM-compliant nodeserver.  Now, will the W3C in 
all their infinite wisdom WANT us NOM folk involved in their specs, or 
not?  Will they consider NOM's need for nodeserving-grade attributes in 
xhtml?  In HTML 5?  Whatever way its done is of no consequence to me, as 
long as its done.  NOM-grade info must be able to travel with 
road-nodes... and I wouldn't change that hardened law even if I could. 
I, and likely others, will want to use web-browser-made applications to 
view nodes.  Using a specialized client to process the style and 
metadata of specialized elements would be such a waste, and a loss to 
the technology of html.  We can avoid that by keeping nodes' core 
attributes road-ready.

Ok, I'm the only member of NOM, and the moos I use to serve nodes are in 
Canada and Tennessee, so I really don't serve nodes from Minnesota. 
Nonetheless, darnit, I want to be heard!  I have needs!  So does the 
world when it realizes how wonderful nodeserving is... unless you work 
in the web advertising industry, of course.  PLEASE consider the 
inclusion of the meta (and maybe style) attribute within the core 
attributes of elements in future html-related specs.  I, at minimum, 
have a future-applicable technology I want to explore... one that is 
highly dependent upon these subjects.  Please don't box me and others 
out... who might want to experiment in nodeserving.

Wingnut

[1] - http://www.websitedev.de/css/schema/draft/
[2] - http://ted.hyperland.com/TQdox/zifty.d9-TQframer.html

Received on Saturday, 28 February 2004 09:33:17 UTC