Re: separator/seperator Re: About XHTML 2.0

On 6/3/05, Jukka K. Korpela <jkorpela@cs.tut.fi> wrote:
> 
> On Fri, 3 Jun 2005, Orion Adrian wrote:
> 
> > Can you give me an example of anywhere, anywhere that styling groups
> > of paragraphs has been used other than in the case of separators. Then
> > ask yourself, how rare are those?
> 
> How often have lines been styled other than by separators (line breaks)?
> Well, rather often in fact, but people don't think about that if they have
> to use separators, <br />, and not containers.
> 

I think line is better than br, so let's avoid the needless discussion
here. What I argue with that one can calculate an entire set of rules
from this one element.

> Paragraph groups are actually styled rather often. For example, in a book,
> italics might be used for a passage (group of paragraphs) to indicate it
> as different from the main flow of narration. Or a passage might be
> printed indented and in smaller font to indicate it as less important.
> 

These usually have semantic classes above and beyond that of
separator. These can use div's as a solution, but in this particular
case you wouldn't want separators before and after you indented text
or your italicized text. You just want to represent the semantics you
want. The cases you just presented are mixing semantics.

> > Empty elements do not garuntee a move into presentation and I'll prove
> > it right now.
> >
> > <img>
> >
> > Wow, what a shocker.
> 
> Indeed, it proves just the opposite of your claim. The <img> element was
> badly designed (or just invented) from the beginning. HTML 4 tried to
> replace it by <object>, which is _not_ an empty element, but failed since
> people were used to <img> and browsers sabotaged <object> with horrendous
> implementations.
> 

I thoroughly object to this statement. Img did not have a bad design
because it was empty. It may not be as nice because it didn't handle
certain elements as nicely as you would like. However choosing that a
fallback mechanism be the random content of the object element is pure
something (and no not genius). There is no truth behind what you say.
I could just as easily say that putting the fallback mechanism as the
child of the element is a bad design (actually as an aside I do
believe this). Either way it's someone's choice. Object's non-empty
content model is a choice someone made somewhere.

> > Empty elements as SMGL spec says represent
> > replaced content
> 
> Yes, that was the original idea - for purposes other than those of HTML.
> There was never any good reason to make <img> an empty element, as the
> more recent history shows
> 
> > like our wonderful <separator>/<transition>/<sep>
> > element (whatever you want to call it).
> 
> No, that's not what the original SGML idea means, not at all. It's not a
> placeholder for content that comes from somewhere else. It's just
> presentational markup (in more disguise than <hr>, which was naively
> honest in its _name_).
> 

Images and sub-documents aren't content? This is news to me and is
news to the WAI group which states that they are in fact content. The
fallback mechanism is saying, hey: here's this space that will do the
job, let's put it here.

> > What content data am I throwing into attributes? I don't even
> > undestand this one.
> 
> Think about <meta>. Or even <img>. Surely the alt attribute's value is
> (alternate) _content_, not a property of the element.
> 

Attributes were always a stupid idea, but it's too late for that now.
Every piece of meta data can be further described so placing a cap on
it with attributes was always a bad idea.

Seriously though, back it up. You say img was a bad design, back it up
with data. You say fallback mechanisms are the most appropriate
content, back it up. The problem is you can't back it up because no
one has done a study on it that anyone has cited in the last year or
more.

There are no universal truths here because we're working with
statistics... likelyhoods. That I can back up with millenia of
philosophers.

Orion Adrian

Received on Friday, 3 June 2005 16:59:11 UTC