- From: Wingnut <wingnut@winternet.com>
- Date: Wed, 05 Mar 2003 15:49:36 -0600
- 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. Wingnut
Received on Wednesday, 5 March 2003 16:55:26 UTC