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

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

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


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


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


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


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

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



Devon


_________________________________________________________________
MSN 8: advanced junk mail protection and 3 months FREE*. 
http://join.msn.com/?page=features/junkmail&xAPID=42&PS=47575&PI=7324&DI=7474&SU= 
http://www.hotmail.msn.com/cgi-bin/getmsg&HL=1216hotmailtaglines_advancedjmf_3mf

Received on Tuesday, 31 December 2002 01:01:20 UTC