Re: [whatwg] Bookmarking videos
This is indeed a topic relevant to HTML5, but not in its scope to address. When we developed Annodex (see http://annodex.net/TR/draft-pfeiffer-temporal-fragments-03.txt), we researched this topic intensively and discussed it within the URI mailing list and here are the results in summary: The means to do offsets into videos (both temporally and through markers) using URIs are limited. You can only use fragment identifiers and query identifiers on resource names for such purposes. Fragment identifiers are not sent to the server, so when doing, e.g. a temporal offset on a video, the server will still send the full video, but the UA (the browser) will be able to do the offset locally. This is useful though probably not what the general user would expect from a temporal offset, since there is potentially a large download delay. Query identifiers otoh are sent to the server, so they make sense to be used for delivery of a subsection of a video from a temporal or named offset. However, there is no means of standardisation of query identifiers for resource classes (such as e.g. for all resources of mime type video/*). Instead, query identifiers can only be standardised for a specific resource type (such as e.g. for video/ogg) by the entity that controls such specifications (e.g. Xiph for anything in Ogg, ISO/MPEG anything in mpeg, Apple for Quicktime etc.). Hope that helps clarify the issue. Regards, Silvia. On Oct 13, 2007 8:45 AM, Ian Hickson [EMAIL PROTECTED] wrote: On Wed, 21 Mar 2007, Kornel Lesinski wrote: This however is a little help to users who want to bookmark videos or share links to certain parts of them - without a standard way of doing it UA's won't be able to provide UI for it. Even if you implement that for yourself using UserJS, you won't be able to share those links, etc. There are RFCs that cover fragment identifiers for videos which may be of interest here. I'm not sure that it's really within the scope of HTML5, though. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Context help in Web Forms
On Oct 30, 2007, at 6:01 PM, Ian Hickson wrote: ... On Mon, 13 Jun 2005, Matthew Thomas wrote: Or perhaps a ... rel=help for=phone-number, to be consistent with the for= attribute in label. This is a possibility, but is it really needed? In general it seems we'd want to encourage authors to put the links near the text and controls to which it applies. Sure, but I don't see how it's different from label in that respect: we want to encourage authors to put label near the control to which it applies, but label already has for=. (label can have weak semantic value even when not related to a particular control, but then so could rel=help.) Many applications provide inline help which is not a label, and the same attributes would be appropriate here: div rel=help for=phone-numberpThe full number, including country code./p pExample: samp+61 3 1234 5678/samp/p/div How would UAs use this? UAs likely wouldn't, but scripts could. For example, a form might include sparing help by default, with a style sheet hiding more exhaustive help (as indicated by rel=help). Then a script could add a small help button after each control that has associated help (i.e. each control with name=x where there exists an element on the page with rel=help for=x). When a control's help button was clicked, the control's help would be shown. Another possible presentation would be reserving whitespace to the right of the form, and making whatever rel=help for=x visible in that space whenever input name=x was focused. http://uxmatters.com/MT/archives/000191.php shows these and other examples of dynamic help. The cite= attribute was also mentioned in this thread as one that is practically useless because there is no good way of presenting it. (Sometimes authors use JavaScript to pull it out of a blockquote and present it as a link underneath. But that still has accessibility problems, because it doesn't work without JavaScript, and the resulting link text is either a raw URL or the same text for every quote. These problems make the technique even more unworkable for q.) As a result, authors usually use an a link to the resource they're quoting (look at most self-hosted Weblogs for examples), and there ends up being no machine-readable connection between the link and the quote. This could similarly be achieved in the a element with a for= attribute giving the ID of the blockquote or q element. Interesting idea. The majority of authors still wouldn't use these attributes, because it would give them no presentational benefit. But at least authors would be slightly more likely to use them than to use attributes that they have to re-present using extra elements or JavaScript. We should probably aim higher than that though... ... I'm suggesting either replacing foo cite=url/foo with bar rel=citation for=id-of-foo, or dropping cite= altogether. Cheers -- Matthew Paul Thomas http://mpt.net.nz/
