[whatwg] <blockquote cite> and <q cite>

[Sander Tekelenburg]

At 14:42 +1300 UTC, on 2007-01-07, Matthew Paul Thomas wrote:

> On Jan 7, 2007, at 7:13 AM, Sander Tekelenburg wrote:

[...]

>> It's still entirely unclear to me *why* the cite attribute needs a
>> replacement. What is wrong with it?
>
> First, it's hard for UAs to present cite= in a way that is both usable
> and backward compatible.

I'm assuming your "unusable" refers to the text in parenthesis (below), but
it's not clear to me what you mean with "backward compatible presentation of
the cite attribute by UAs". Are you talking about a new UA version doing
something different with the cite attribute than the previous version did?

> (Just changing a cursor isn't discoverable
> enough.

Agreed.

I won't claim I know the solution, although I do think that if a UA would use
one single method of indicating that some metadata is available for *any*
element/attribute, that might already very well be a usable solution. I doubt
it is truly necessary to use different indicators for each and every
different sort of hidden meta information.

The fact that UI problems like this aren't solved yet does not mean they
cannot be solved. Just that they haven't been solved yet. I'm sure that to a
large extend this has to do with UA vendors having spent resources on browser
wars and ESP engines for the past 10 years, at the cost of other development.

Another aspect is that it simply takes time and experimentation to figure out
how to do some things 'right'. I consider the Web to still be in its early
infancy. Only since about a year or 2 does a relatively large group of users
(though still a clear minority) use relatively decent webbrowsers; on the
authoring tools front we're not even at that stage.

Lastly, it takes users time to get comfortable with new technology.
Especially those who grew up before the technology existed. It doesn't seem
unlikely to me that a next generation will grow up considering it only
natural that digital objects often contain initially invisble properties (and
that that is a sensible authoring approach).

In other words, I prefer to be cautious about making specs less ambitious as
long as there seems to be room for UA and authoring tool authors to improve
their products such that the ambitions of current specs are met better. (Also
because it's much easier to obsolete a browser (version) than (aspects of) a
spec.)

>  Putting any extra button etc in the page might mess up page
> layouts

As might the user's default font-size. Welcome to the reality of the Web.

(The way I see it is authors still need to learn "liquid design". It's a big
mental step from WYSIWYG, so it's natural that this takes time. Having better
UAs and authoring tools will help, but even then it may be that, as with so
many new things, this will take 10 or 20 years -- the time for a new
generation to grow up with "liquid design" as a natural aspect of life.)

> , though it might work if it was placed in-line at the end of
> the quote.)

That would seem entirely appropriate to me, yes.

> Second, it's hard for authors to use it in a way that is
> backward-compatible. That is, if the source information is important
> enough that it needs to be accessible in those UAs that don't (yet)
> support cite=, the author has to provide the information in some other
> fashion too.

Yeah, but as a spec writer you then risk entering the terrain of dumbing down
the Web for everyone, just because some people are still using lousy UAs.
Some of us feel that such information should be *available* but not *visible*
per se, because making it visible will often only lead to distraction from
the actual text.

Think of the small screens of palmtop browsers. Even on an iPhone you don't
want to be forced to waste screen space on cite attribute values. You want
that accessible, but only when you want to actually interact with it. (This
is the same reason why a while ago I argued for some way to have sites'
navigation menus be authored as 'meta data', hidden or hidable -- use space
only for content that's actually needed at that moment.)

So even just adding some method to mark up the source of quote such that it
is presented visually by default, without removing the cite attribute, will
likely impover the Web for everyone. *Unless* such markup can be presented as
dynamically as the cite attribute can. But I think that would require the
spec to state that UAs MUST by default present such content hidden.

So returning to your earlier suggestion:

| <blockquote>
|   <p>
|     <q>rhubarb rhubarb rhubarb</q>
|     [<cite><a href="www.example.com">Nemo, Works, IV</a></cite>]
|   </p>
| </blockquote>

Provided HTML 5 would state that HTML 5 UAs MUST by default hide the contents
of an A element in this situation, this might be a solution. But not without
that provision, IMO.

(Btw, in this case that would lead to the UA presenting 2 empty square
brackets. I don't know what the spec should state to ensure such ugliness
doesn't happen.)

> And third, it requires the existence of an IRI of some sort. Often you
> won't have this, for example when the source information for your quote
> is something as vague as "attributed to Mark Twain".

I think that in such a case it would be appropriate to have the cite
attribute's content point to the source that attributes it to Twain, like so:

<q cite="URL">To be, or not to be</q>, as Mark Twain supposedly said.


-- 
Sander Tekelenburg
The Web Repair Initiative: <http://webrepair.org/>