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

Devon Y. wrote:

> Wingnut wrote: 
>> 
>>  One, is changing the order of elements IN the BODY element. Isn't
>>  ORDER OF ELEMENTS a presentational style?

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.  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).

> 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'. 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.

>>  Should an author have the right to put a horizontal rule as one of 
>> the 'order of elements' (content) in a BODY element?  Yes.
>>  Should that be deemed as mixing content and presentation?  Yes-No. :)
> 
> 
> 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. :)

>> BODY almost needs a prefs param, or maybe we need a prefs element
>> in the HEAD. Keep in mind that we also have VERTICAL rules to deal
>> with too, as CONTENT in a web author's preferred order of elements
>> in a BODY element.   A PREFS tag might have content that describes the 
>> preferred BASIC
>>  PRESENTATIONAL STYLE of a document.  A PREFS tag would describe...
>> a TREE structure in a way.
> 
> 
> Why is it so neccessary to suggest a preferred style of any kind like 
> this? If I wanted to suggest a preferred style for a document I made, 
> I'd put some CSS in a <style> element, and give the element a title 
> attribute with a value of "Author's Style" or maybe "Preferred Style". 
> Or do something similar.
> 

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.  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.

> 
>> And therein lies the problem.  XSL'ers have dreams of massaging the
>> life force out of dom trees once they're parsed into existence from
>> a document.  They think they are going transcluding (look it up)
>> and making their own web pages from pieces of others.  And this is
>> where the author should have some say as to what another does to 
>> hack-up the author's preferred document layout and WHOLE content. Do 
>> you think the author of Whistler's Mother would want to know,
>> and/or have kyboshing rights... if some xsl-crazy transcludian
>> wants to display the empty rocking chair instead of the full
>> painting in its proper context and order?  YES!
> 
> 
> But a prefs element or attribute, won't stop an XSLT'er from ignoring 
> the preferences completely and transforming the document or any part of 
> it, in whatever way he or she wishes/needs. Sounds like what you need is 
> a change in the XSLT spec so no one can change a document.
> 

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?  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?

> 
>> Also... BOX is as presentational or non-presentational as HR...
>> so lets include or disclude that too.  What does 'BOX' do?  It
>> 'positions' two vertical rules and two horizontal rules in such
>> a way as to RULE-UP some content.  One can't use the BOX MODEL
>> stuff in CSS, because that's not parallel in a
>> content/presentation-wise thinking... to HR and VR. Likely
>> some browser-in-a-coffeemaker will try to style it itself... and mess 
>> with my BODY element's content.
> 
> 
> I fully agree with you that the box concept, is very presentational. 
> I've often thought that it makes no sense for XHTML to have block level 
> & inline level elements, BUT I find it also does make sense. Since 
> paragraphs, lists, tables, and headings have always had line breaks for 
> centuries, one could argue that the line break in those types of 
> elements are actually part of the content or at least make sense in 
> their elements' context. So I'm not too concerned about it. As long as 
> the semantics of XHTML make sense, then things remain sane and code 
> remains/becomes readable.
> 
Ah yes... whitespace is presentational... err.

>> Is there indeed some very glaring barriers between 'positioning' and 
>> 'styling'?  As hypertext has been divided into content and style, 
>> maybe so should CSS be divided into 'positioning' (contexting)
>> and 'styling'?
> 
> 
> Well, I've often heard of the positioning stuff referred to as CSS-P.
> 

This isn't 'positioning' in the 'physical location' sense of the word. 
It is 'positioning' as it relates to other content within the body 
element or other container elements.  I think its correct term is 
'context'... but correct at will. :)

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

Received on Tuesday, 31 December 2002 17:48:22 UTC