- From: Orion Adrian <orion.adrian@gmail.com>
- Date: Tue, 7 Jun 2005 22:30:32 -0400
- To: www-html@w3.org
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