Re: separator abuse

On 6/7/05, Christoph Päper <christoph.paeper@tu-clausthal.de> wrote:
> Orion Adrian:
> > On 6/1/05, Christoph Päper <christoph.paeper@tu-clausthal.de> wrote:
> >> Orion Adrian:
> >>
> >> We don't want to say: "Stop the ocean waves sound¹ at 'separator' and
> >> start with the birds' singing²," but: "Play the ocean waves sound for
> >> the first part and the birds' singing for the second."
> >
> > And how, praytell, do you expect to determine where the viewer is
> > reading at the time? If this is an aural reader I don't think playing
> > sound would be very popular.
> 
> I was thinking about an audio book, which (sometimes) do have
> background/ambient sounds.

There are other organization methods that will be used and can be used.

> > I cannot stress this enough. The usage of separator doesn't
> > necessarily comply with any sort of regular organization.
> 
> That's why I'm against its inclusion into XHTML.

There are quite a few things that don't follow standard technical
writing organization. Authors often feel that they have the right to
use structure as art.

> > It's content, not structure, and as such could have a near infininte
> > number of reasons for use. Content cannot be regulated as its usage
> > changes from generation to generation.
> 
> Content should not be inserted by (empty) elements. Maybe use entity
> references instead. I'd be fine (read: "would not care about") with
> '&separator;'. However, I don't think the WG thinks 'separator' was
> content but structural.

I would ask that you back this up. This is where I have a lot of
trouble. Empty elements have yet to be proven to me to be bad. I deny
that empty elements are necessarily presentation, but rather represent
semantic elements that can't be represented with standard English text
or at least it becomes difficult. Though under this thinking <br>
should have been an entity and it could be as it's in Unicode. But
unicode is hard to address and this is where the problem arises.

I'd rather not have to specify all my separators as
<span class="separator">&separator;</span>
just because you don't like empty elements.

> > Organization however tends to be similar from generationto generation
> > which means one set of markup can cover most organizational structures
> > for documents throughout the ages.
> 
> Exactly. The alledged use cases for 'separator' (PoV, timeline,
> elsewhere, ...) are structural and thus require structural mark-up and
> not an empty element that gets replaced by some other content.

I do not agree with the assesment that separator is structural. The
reason I disagree with this is that it appears in places
inconsistently given a single set of categorizations (PoV, Topic,
etc). At least I've seen it that way.

> > If there is an aspect of the
> > document that is regular that can be addressed in such a way, a <div>
> > with an appropriate class attribute should suffice,
> 
> ACK.
> 
> > but that use case
> > is much rarer than the use case for a generic <separator /> element.
> 
> I have yet to see such a use case, where 'separator' was appropriate,
> but not grouping elements. Even if I did, I would still have to be
> convinced that such rare cases demand their own XHTML element type,
> whereas much more common structures don't have one.

I'm not much of a fiction reader. I'll try to find some. Others would
probably be more suited to the task.

> > Even if no one ever used a separator (e.g. ~~~) ever again there would
> > still be a huge number of documents that would require it.
> 
> IMHO it's a question of PoV: Do you rather describe a border as a
> one-dimensional object (line) or as the common boundary of two (or more)
> two-dimensional objects (areas)? HTML is more about the latter.

Actually I describe it as pattern around an object that may collapse
if so desired. But here, the line is purely presenational, unless it's
artwork and then it should be in a raster or vector format and not
HTML.

> > Why separators are used where they are used cannot necessarily be
> > known. Since they cannot be represented by a concrete set of words, we
> > can only guess at why there were used where they were used. It is also
> > not the place of the W3C to dictate how content is written, simply how
> > it is marked up. No one should be suggesting the removal of the
> > authors ability to simply place a separator where they think it's
> > appropriate.
> >
> > Authors often don't know why they write what they write, so asking
> > them to determine why they placed the three tildes isn't particularly
> > an easy thing to ask of them.
> 
> You have just questioned the whole point of mark-up. We must assume that
> the mark-up author knows and understands the structure of any given
> document.

I don't feel this is true. Markup can be invaluable without requiring
all authors to spend a long time contemplating the reasonings for why
every decision was made. Here why they put a separator there. If an
author were to say to me, because it felt right, then I'd have to let
is slide because HTML cannot be about questioning the creative
process.

Markup is still useful simply from the ability to address what I care
about. It's also useful for putting a document into perspective and
for linking to and from in important areas.

But I wonder what are we going to do when deciding the reasoning
behind why an author choose to use a separator when that author has
been dead for hundreds of years?

I would imagine many would feel better about
<separator>~~~</separator>. Though I consider this to be silly as
well. Whether or not it's structure or content seems to be point of
view. I'm guessing to the other camp the reasoning is just as clear as
my reasoning is to me.

Beyond the technical concerns involved with addressing (an important
concern always), I find using <separator> or <transition> to simply be
easier to read, write and comprehend. <pargroup> has attached to it a
complex addressing scheme (trying to address the stuff inbetween) and
side effects that aren't obvious when using it. Does every <pargroup>
produce its own separator? Visually? Aurally? I feel that the
additional grouping structure adds more problems than it solves and
therefore I oppose its inclusion.

Orion Adrian

Received on Wednesday, 8 June 2005 02:30:35 UTC