W3C home > Mailing lists > Public > www-html@w3.org > March 2003

Re: Font Style Elements

From: Wingnut <wingnut@winternet.com>
Date: Wed, 05 Mar 2003 15:49:36 -0600
Message-ID: <3E6670F0.5020305@winternet.com>
To: "www-html@w3.org" <www-html@w3.org>
CC: Ian Hickson <ian@hixie.ch>

Ian Hickson wrote:
> On Tue, 4 Mar 2003, Wingnut wrote:
>>Ian Hickson wrote:
>>>semantic. The style information can always be split from the markup,
>>>because it is not part of it. (This is one of the many reasons [1] that
>>>the style attribute itself is unnecessary.)
>>>[1] http://lists.w3.org/Archives/Public/www-html/2003Jan/0277.html
>>Again, Ian... not necessarily true.  In a "node viewer"  application, it
>>might OFTEN be desireable that the style travel with the node.
> I am unsure what you mean by a "node viewer application". Could you expand
> on this?

I'll describe as best I can.  Lets pretend I have a Javascript app... 
that has an array of 10 anchors (URL + fragment identifiers?) ... 
targetted towards articles about... oh... The Golden Mean.  This 
javascript, by whatever means, has the ability to perform fragment HTTP 
GETS from these 10 different documents... extracting ONLY the HTML 
element(s) at that anchor, and no more.  In other words, the JS code can 
grab 10 DOM nodes, which could sub-contain any number of other HTML 
elements.  Using a XUL (Mozilla) gecko-like display (a node viewer, NOT 
a document viewer), I can potentially display this chunk of HTML.  BUT, 
I have an attribute in that borrowed HTML element that says... 
ID="my_div".  If I want to use my gecko-viewer to view this article... 
AND have it painted-up in the style that the author WANTED it 
styled-with (my_div), I will need to go back to that remote document 
(its style rules, internal or external) and somehow parse-out the 
author-wanted style rules pointed-to by ID="my_div".

Ok, lets say I manage to do that.  I was able to dig-out a pile of text 
from within the remote document's external stylesheet, or I was able to 
parse data out of the in-document style element.  How do I store that 
for the time being?  In a stylestring.  (style='blah/blah')
And yes, you COULD create a .css file that the node viewer can 
reference.  But remember... node viewers are not document viewers, so a 
true node viewer allows no HEAD/BODY-like things OUTBOUND to its 
display. (It DOES allow harvested nodes to be BODY or HEAD, though, of 
course).  Also, the node viewer would likely default to an HTML state... 
pick your dtd.

Ok, I am curious about The Golden Mean.  I open my Javascript node 
harvestor search engine, and I send it off to get the 10 chunks of html, 
and the styles that the authors wanted, if they indeed had a style 
preference for those HTML elements and/or their content elements.  It 
returns, triggering the Mozilla XUL node viewer application to launch, 
and begin showing me the articles, one at a time.  It first asks... "Use 
author-prefered styles, local default styles, or none?".  I choose 
AUTHOR.  My XUL node viewer displays the first article (node) using the 
gecko display... and since there IS NO DOCUMENT to the node viewer, its 
very clean to simply replace the ID="my_div" with the style rule 
(style='blah blah') that was harvested during the node retrieval 
performed by the javascript.

 From one view of the world, it does indeed look like there is no use 
for style attributes.  From another view, it is the ONE and ONLY CURRENT 
"POCKET" that can carry-around the author's preferences for a node (HTML 
element/chunk) that someone or something has harvested out-of-context 
from a webpage of his/hers.  There can be no ID/CLASS="whatever" sent to 
any ?ML chunk-viewer application... because the references are 
worthless.  If one wants to offer a "View in the way the author wanted 
it viewed?" option, then one must establish a string-of-style for EACH 
occurence of ID=??? or CLASS=??? in the base element and all elements 
contained within.  Again, it is likely that such an application would 
just paste the appropriate stylestring (our storage method for harvested 
stylerules) in place of each ID=??? and CLASS=???... and pipe it to 
gecko... which would likely display it correctly.  A REAL THOROUGH node 
harvestor would even try to parse-out the remote document's BODY 
background image or color... and try to honor that as well.

Author's are much more likely to anchor-up articles for willing 
transclusion to other places on the planet... IF we keep a mechanism in 
mind to honor author preferences.

>>In fact, I predict that MOST transcluded documents (made from pieces &
>>parts of other documents)  WILL have style attributes in the nodes...
>>instead of trying to translate stylesheets or style tags from many
>>sources... into the new transcluded document.
> Why would you have to merge stylesheets?

I think my foolish node viewer thoughts above have answered that. :)

> Style is independent of the content. There is no reason why your content
> should have headers than are 2em high and blue on white. Content authoring
> should concentrate on content authoring, not content styling.
> This is currently common-place with large content syndication systems. For
> example, RSS feeds do not include style information. Similarly, news feeds
> such as the Associated Press do not include style information with their
> articles. In both cases, the content publisher applies his _own_
> stylesheet to the content. Indeed, this is one of the ways content
> publishers compete against each other: restyling of syndicated content.

Yep, an appropriate system for data pushers.  Not for pullers, though.

>>Finding/extracting rules found in stylesheets, and rules in style
>>elements... and converting them to style attribute strings... will
>>become a common function of "node harvesting".  Just my opinion.
> That would be a sad day indeed. In any case, such "node harvesting" would
> lose much of the expressive power of style languages. For example, CSS can
> style elements based on whether they are targetted by the fragment
> identifier (:target pseudo-class) or whether they are currently contained
> in an element that follows another (combinators). Short of merging the
> entire stylesheet into the content, which can already be done by using
> <?xml-stylesheet?> PIs and data: URIs and doesn't require style attributes
> at all, there is little that can be done here.

Yes, harvesting stylerules from remote stylesheets might not be 
plausible. I suspect that the style tree dohicky is available for basic 
gecko applications.  It is likely that I would need to link-in all 10 
complete stylesheets and pray for no name collisions.  That's not really 
plausible either.  Much to learn.

Thanks for the interest, comments, and knowledge, Ian...  and others. 
Sorry for the topic drift if I have caused such.
Received on Wednesday, 5 March 2003 16:55:26 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:06:02 UTC