- From: Robert Burns <rob@robburns.com>
- Date: Fri, 3 Aug 2007 22:06:25 -0500
- To: Jason White <jason@jasonjgw.net>
- Cc: public-html@w3.org
On Aug 3, 2007, at 8:23 PM, Jason White wrote: > > On Fri, Aug 03, 2007 at 07:07:12PM +0200, Sander Tekelenburg wrote: >> Ah, right. I get it. <alt for=idref>equivalent</alt> would then >> remove the >> need for the equiv attribute that I suggested. It would also not >> need @rel, >> and thus remove the need to refine the definition of @rel. (Or am I >> overlooking something?) > > No, I don't think you're overlooking anything; @rel is not needed > in this > proposal. >> >> Yeah, that would seem to be easier to author and easier to implement. >> >> A potential issue: thinking about the different types of >> situations in which >> publishing of equivalents would need to be possibe, it would seem >> to be >> necessary to allow <alt> as both block and inline. (Or not? I >> don't really >> 'see' that yet.) > > For flexibility, it would be best to allow it in both block-level > and inline > contexts, with a transparent content model, I think. Does this mean your proposal specifies a content model of "block- level or inline, but not both" (I'm still trying to understand what transparent means so perhaps that's the exact same thing). >> [...] >> >>> With all three proposals, there arises a need to specify how a >>> user agent >>> should treat multiple idrefs referring to the same element. As >>> you suggested >>> elsewhere, a type attribute could be introduced to distinguish >>> different >>> alternatives to the same media element. >> >> Right. But unless I'm mistaken, type is currently only for MIME >> types. It >> might not be wise to start allowing other sorts of values. Or would >> "application/video+caption" and such be appropriate? I don't know >> enough >> about MIME types to judge that. > > I agree that MIMe types may be insufficiently expressive for this > purpose. > Furthermore, if one media element is used as an alternative to > another, the > task of deciding whether the alternative can be retrieved and > rendered is the > same as for the original, so I don't think additional resource type > information needs to be disclosed in the proposed <alt> element. The @type attribute is not always a MIME type. The INPUT and BUTTON elements both have types that are not MIME types, but simple classifications just like this proposal. Though deprecated, LI, OL and UL all had @type attributes unrelated to MIME type, but rather classification types. Despite being deprecated fo some of these, the point is there is plenty of historical precedent in HTML for non- MIME type @type attributes. As for distinguishing between different equivalent types, I think a @type attribute would be good (we could also have @contenttype to provide two different ways to classify the element). Also we have the @title attribute available on the ALT element to provide human-readable information about the differences. I had earlier suggested a LONGDESC element (ALT, EQUIV, FALLBACK or LONGDESC all work for me). At least for a one-to-one relation, to me it makes more sense to use the @lkongdesc attribute from the original element. To go from primary ---URL---> fallback rather than referencing from fallback ---IDREF---> primary. Multiple equivalents could be handled by letting ALT have a content model that includes an initial ALT or adding a @longdesc attribute to ALT too. Advantages of this approach include: • @longdesc is already supported (backwards compatible) • @longdesc as a URL instead of an IDREF permits greater author flexibility (to optimize bandwidth usage and the like) by pointing @longdesc to either a local '#idref' URL or a remote document URL • authors can (I guess have to in some sense) express a ranked preference for equivalents that users and UAs can take into consideration. However, I think the for=IDREF approach works better for specifying a one-to-many relation between primary and equivalents (without any implicit or intended ranking). Another advantage for both approaches (specifying an ALT element whether Jason's way or the way I'm suggesting) is that either works easily in a backwards compatible way with an HTML5 specific style sheet (with style declarations like something like "ALT {visibility: hidden;}" or "@screen {ALT {display: none}}" With very minimal java scripting, we could probably even emulate the role we want UAs to play to provide a mechanism for users to switch between equivalents in non-HTML5 conforming UAs. I'm in total agreement about the problem. As I understand it, we want to provide a way for authors to explicitly markup equivalents (even from IMG) and expose those equivalents to users in a consistent way (like in the chrome as Sander says). I think it could work in a manner similar to switching among alternate style sheets in current browsers (like Firefox). For example, the frame dedicated to the original primary equivalent could be the same frame used to display the alternate equivalents. Authors could specify through CSS how alternates would get displayed in that frame (i.e., changing the frames metrics and reflowing the document or maintaining the frame metrics and providing a scrolling mechanism or other content overflow/ clip handling). Take care, Rob
Received on Saturday, 4 August 2007 03:06:36 UTC