Re: Font Style Elements

This post apparently fell thru the cracks in the maillist Friday 
morning... so I repost.  My apologies if duplicated.

Nigel Peck - MIS Web Design wrote:
> If I'm understanding this argument correctly if style is passed around like
> this and merged on a page I would imagine that the pages could just end up
> looking like a complete mess.

Likely so.  In the case of a "HTML chunk viewer" like I've been yacking
about, and using the example of 10 articles harvested from 10 different
remote webpages... the chunk viewer COULD display one article at a time.
The in-app style tree (gecko) would ONLY contain the stylesheet needed
for THAT ONE ARTICLE, and then when its time to display the next
article, load-in another style tree, etc.  I know it sounds innately
similar to having each article in a document of its own, using a browser
to view it, and having a LINK in the HEAD's to get the correct
stylesheets.  But unfortunately, documents tend to be made-up of
paragraphs, and sometimes, we want to get ONLY a paragraph of the
document.... especially used in quoting operations.  And again, we will
want to try to honor author styling preferences at least under certain
conditions.

> Surely content should be passed and styling
> should be the responsibility of the site merging the content.

Surely, three options should be available... author's style, local
transcluder's style, and none.

> 
> Users need consistency of deign on a site, not a mess of styles created by
> people with no communication between them.
> 

Yep, the transcluders need an option on how to transclude without making
a mess.  Here's my half-baked idea...

Web servers need to change.  First off, we'll need to allow document
fragment GETS.  I heard a rumor that HTTP 3 might do this already, but
I'm far from educated in that department.  Secondly, AT THE WEBSERVER,
we must have the abilities for the document to be grown into a DOM tree.
   I'm very new at this, but I'm quite sure that once a document is in
DOM tree form, get_element_by_ID/class can be performed to get a
reference to any HTML element in the tree.  After that, one can PEEK
(read the value-of) all 122 CSS1 properties on the STYLE OBJECT that is
attached to that element.  Thus, we have a contorted peek_style(element)
function that should be able... with the help of the new web server...
to return that data as a string or structure.  Placing the entire
document in a tree (ie, in a browser sub-structure) just before
delivering it to the remote requestor... opens up quite a few options.
One option could be GET STYLETREE for a given document.  A DOM tree on
each end, client side, and server side.... really opens up transclusion,
as well as cool remote document editing power with view-before-save
option as wanted.

> Do you have a link to one of these pages you've achieved this on, merging
> styles from various content providers, I'd be interested to see it?

I don't, Nigel.  That scares me. :)  Maybe Toby, or the others here do.

On a total tangent here... TimBL... could we have a statement from you
on the future of transclusion?  Have you seen Ted Nelson's website at
http://ted.hyperland.com ?  His documents and website have completely
evaporated from Keio U. Needless to say, the man is discouraged about
the direction of the web.  And we know WHY he's discouraged, don't we?
Lack of consideration for smooth transclusion.  We lost the original
vision, and went off on our own, and we are paying dearly for it right
now.  IMHO, we screwed this up, people.  Time to fix it.  Thoughts, Tim
and everyone?

Wingnut

Received on Saturday, 8 March 2003 03:01:47 UTC