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

Re: <hr /> and WD-xhtml2-20021218

From: Devon Y. <vehementpetal@hotmail.com>
Date: Sun, 05 Jan 2003 01:48:39 -0500
To: wingnut@winternet.com
Cc: www-html@w3.org
Message-ID: <F377wo95EFk2H3b98Kt00002d95@hotmail.com>

>In a loose definition of 'style', the order of elements in a body tag, or 
>another container-like tag... is the STYLE of the author.

  Coding style, yes. Which is unrelated to how the authors' document can be 
presented to a human reader.


>In an article written by an author, the author might start with an EM with 
>some opening remarks... then another EM with some definition of terms, and 
>then another EM might contain the meat of the article.
>  This is a writing style, and one might call it CONTEXT as well.
>The author chose this order of elements because of their personal writing 
>style, and because that order is integral to the 'construction' or 'flow' 
>of the CONTAINER'S content (the whole article).

  But would it make sense when viewing the code in a text editor? Can a 
person glance down through the code and know just what is a paragraph? which 
part is a citation? what's used for emphasis or what's used for different 
subsections of the article? There's be no point in marking up an article 
with em's for definitions or the entire meat of an article.


>>Am I missing something? The order of elements in a document is called 
>>'code structure' or 'code design'. It's completely unrelated to any 
>>documents' presentation, style, or display (thanks to CSS and/or XSLT).
>
>And it could be called 'content presentational order'.

  I don't think so, because one could present the content in any order they 
wish to present it. It doesn't neccessarily have to follow procedurally 
through the code & content. Even for a browser like Lynx, which has no CSS 
abilities (as far as I'm aware), one could use XSLT on the server or maybe 
even PHP to reorder the content for a lynx user (if need be).


>As I mentioned above, the order of elements within any container is indeed 
>related to its presentation.  It is the 'order of events' wanted by the 
>author. There appears to be no other way than CONTAINING (DIVing?) for an 
>author to 'request' that certain elements be displayed as a WHOLE versus 
>any other method.  In our example, the author does not want the meat of the 
>article to happen BEFORE the opening remarks and definition of terms. This 
>is presentation... based upon order.  The position of the EM's to each 
>other, is related and presentational.

The author can make a stylesheet to accompany the article, so the EM's will 
appear first...no matter where the EM's actually are among the code and 
content.


>>I just can't see how an <hr /> element is anything but presentational. 
>>Anyone can mimic the <hr />'s effect using CSS. For me, that means <hr 
>>/>'s are just code clutter.
>
>Ok, so... a GIF, JPG, or PNG of a horizontal line... is considered content, 
>and a HR tag isn't?  Well won't that make for quite a large pile of 
>horzrule.gif pics out there over the course of the next few years?  BOX 
>will become so impossible to accomplish that people will go back to writing 
>un-searchable text ONTO pics again, (text within a box) like PDF's.  Ouch.  
>Yes, css can do most of that stuff... but I've always felt that whatever an 
>author can do with a pen or pencil, is content. That means lines, boxes, 
>arrows, circles, all things that can be scribbled onto a paper/document as 
>indicators of something. Ask any 3rd grade class 'grader' if the circles, 
>dashes, sidenotes, and arrows on a graded paper... are content or 
>presentation. They'll say... "That's content from me... headed for the 
>student.  To remove these goofy marks... changes/kills the CONTENT which is 
>data meant for the student's eyes and mind."  Scribblins' is sometimes 
>content!  Doodle art does not apply. :)

  In that particular case, I think the doodles would be content. I basically 
see content as all essential information directed to the reader. Which would 
be most or all text, and also images which might relate closely to what 
you're reading - like those used for examples or pictures of whatever the 
text talks about.
  Formatting, Layout, coloring, other kinds of images, and most anything 
that can be generated (like table lines or quote marks), aren't content in 
my eyes. Probably because I'm so drenched in XML & XSLT, I see it all in an 
almost database or Object Oriented Programming kind of way.


>CSS cannot tell a transcludian that an author REQUESTS that one keep the 
>order of elements in a section of the document... together... in order to 
>have the content keep its meaning and context.

  Actually in CSS, one could use an '!important' value(?), as a way of 
requesting certain styles. Grouping related information in div's, p', etc... 
with id's and/or class's, can also go a long way with keeping related 
information/text together.


>As was said somewhere here, one cannot keep a xsl transcludian from 
>whackin' the order of elements in a document into any arbitrary order.  But 
>a method COULD be divised OTHER than container elements... to tell the 
>transcludian that the author would like his stuff presented in the manner 
>(order) that it was originally presented-in... something a trans-person 
>COULD take into consideration out of fairness.

  There already is. It's called proper code structure.



>That's not going to happen.  People will traverse trees.  We started as 
>kids and we're not about to stop now. :)  Let's look at an example.  You 
>parse a doc, and you have the tree.  Now, you want to re-present the tree 
>in your own order.  Now, do you try to honor any 'contained' nodes by only 
>re-presenting them in their container?  Or do you ignore the author-made 
>container node level, and go grab nodes in any way you want?  Either, 
>right?

  It would depend on what my reason for re-presenting this document is. If I 
want to grab a sample, say, the first paragraph. Then I'll just grab that 
and display on the website's main page with a more link after it. If I want 
just a quote, then I could search for related words and grab only a couple 
sentences from the document. If I want to re-present the entire thing in a 
totally different markup language, then I'd probably just grab most of the 
document, and take my cues from the element/tag names & their attributes.
  I'd likely be most interested in grabbing the information & presenting it 
in whatever style my website or other documents are already in, so I 
wouldn't need any new element or attribute and would probably just ignore it 
if there was one. An XSLTer has a specific purpose for transforming a 
document, and if they just reorder the entire thing in some arbitrary 
order... they're probably doing it for some needed purpose (an online toy 
perhaps or maybe art?). I doubt anybody would just re-present something in 
some arbitrary way that would serious anger the author or confuse the 
intended audience. So I don't see why anyone would have such a problem with 
someone doing anything like this, as long as the person isn't misquoting or 
misrepresenting the author of the document.


>Now IF the author could say "I'd like tranzers to keep my elements in this 
>container and re-present them in that method... at the container node level 
>of the tree.... then what?  Would you consider honoring the author's 
>request IF your re-presenter knew how to look for such preferences?  
>*shrug*  Should/could/would the author have a say?

  In all honestly, I'd just ignore it. Because it would save me time, and 
assume it has no bearing on my purposes for presenting the 
information/article/data.


>Thanks Devon... excellent comments and ponderings!  Best wishes in 2003 to 
>you and all listees!  Wingnut

  Thank you! All the best to you too.


Devon

PS. sorry I couldn't reply to this until today. Some things came up
    in life and my comp was being a pain.

_________________________________________________________________
MSN 8 helps eliminate e-mail viruses. Get 2 months FREE* 
http://join.msn.com/?page=features/virus
Received on Sunday, 5 January 2003 01:49:11 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 27 March 2012 18:15:53 GMT