Re: [XHTML2] CITELANG, TITLELANG attributes

On Wed, 28 Jul 2004, Jukka K. Korpela wrote:
> On Wed, 28 Jul 2004, Ian Hickson wrote:
>>
>> HTML pages are dynamic.
>
> I think you mean "HTML documents can be modified by client-side
> scripts". The word "dynamic" is just a buzzword, though sometimes
> useful.

HTML documents can be modified by client side scripts, yes.


>> Script can dynamically modify elements, attributes, and so forth, all
>> on the fly, even while the "title" is being displayed (and then authors
>> expect the UI to be updated on the fly too).
>
> And this implies some "cost", as compared with just displaying or
> analyzing a "static" document. The ease of implementing modifications
> should not be a decisive factor in markup language design, and it
> largely depends on the DOM and the scripting language more than on the
> markup language.

The scripting language is ECMA-262. The DOM is DOM3 Core.

As an implementor, I assure you that it is far easier to handle attributes
for this kind of markup than it is to handle elements. That isn't to say
that you can't do it with elements -- but it does mean that the element
case will be harder to implemenet, more likely to be buggy, and less
likely to get interoperability on.

As a markup language designer, I tend to consider how easy it will be to
get interoperability to be one of the most important aspects of the
language's design. If the language isn't implemented interoperably, then
it is useless to authors, however well-designed it otherwise seems.


>> It's pretty simply really. As a general rule, things you want to have
>> render inline should be in elements, and things you want to have render
>> in UI should be in attributes.
>
> That sounds like an awfully browser-technocratic view on the matter.
> Remember that there might be no UI proper. For example, a document might
> just get printed on paper, or scanned by an indexing robot. The markup
> language specification should define the meanings of elements and
> attributes, not the way they are processed.

It should do both, if it wants interoperability. This is especially
relevant for languages that host applications, such as HTML. (Where by
"applications" I mean things such as GMail or eBay.)


> I think we have exactly opposite views on this. Tag Soup mess is based
> on treating tags as commands, typically treating them as visual
> formatting commands more than anything else. It might have been a good
> idea to document such processing years ago, but it's too late to
> document Tag Soup HTML now. Still less do we need to document Dynamic
> Element Soup. If you modify an HTML document as a tree structure and
> produce something that does not comply with HTML syntax, you should be
> on your own; anything that says what _should_ happen then will just
> encourage authors to play such games.

As you say, we have exactly opposite views on this.


> > No, because in the case of <summary> I would expect the content to be
> > shown inline, instead of the rest of the table.
>
> Do you mean it should be treated as a <caption> of second grade?

No; I mean it would be rendered instead of the table content. That, at
least, is my reading of the spec's vague definition.


> The way I think <summary> should be defined is this: conforming user
> agents are required to present the content of the element in a manner
> that associates it with the table _or_ to indicate that a summary is
> available and make it optionally accessible (e.g., by displaying an icon
> that will show the summary on mouseover or when clicked); and speech
> browsers would normally be expected to take the first option. It should
> be optional but always accessible information. That way, authors could
> really make use of it and rely on it.

I don't understand why most users would care that a summary is available.


>> Much like "alt" should never have been an attribute.
>
> Indeed. But it was easier to implement as an attribute. :-)

Possibly true originally, but at the moment it being an attribute is more
of a pain than a help, because the contents of the attribute really is
inline content. The basic cases of <object> -- that is, ignoring plugins,
ignoring the fact that it is supposed to do all media types, ignoring
various backwards compatibility requirements due to quirks in legacy
implementations, etc -- are easier to do right than <img>.


> Pragmatically we might say that the summary attribute or element should
> be primarily written for those users who do not see the table (or do not
> see it as a whole). But it can be useful to explain the structure of a
> table even to those users who do see the table - not all people can
> intuitively see the structure as the author expects.

I would expect such content to just be adjacent to the table, not part of
the table summary.


>> Unicode language tags -- like Unicode BFCs -- will probably be quite
>> unpopular with experts, especially in a markup context.
>
> And completely unknown to others. Exactly my point; I tried to make a
> reductio ad absurdum: if the W3C requires markup of all language change
> (for compliance with WAI even at the most elementary level, A) _and_
> defines a markup language that does not permit such indications, then it
> is saying that authors should use Unicode language tags, which is
> undescribably absurd.

Actually I would have thought it made good sense. Unicode's strong
statement to the contrary notwithstanding, I would have thought tags made
perfect sense in a setting such as an attribute. It would also mean the
language information could be trivially preserved when passed to a
language-aware speech agent via non-language-aware APIs such as a basic
"tooltip" API that just wonts a string, something which would be
distinctly non-trivial in the element-based language tagging case.


>> How would you mark up mixed languages in text/plain documents?
>
> I would not. If I need to indicate language changes in text, I will use
> markup (or invent a markup of a kind of my own, using textual
> explanations instead of tags).

Yet BFCs are commonly used in plain text. So (again, Unicode's strong
statement to the contrary notwithstanding) why not language tags too?

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Wednesday, 28 July 2004 10:32:23 UTC