[whatwg] <video> element feedback
Sander Tekelenburg
st at isoc.nl
Thu Mar 22 18:30:21 PDT 2007
At 19:46 +0000 UTC, on 2007-03-22, Nicholas Shanks wrote:
> On 22 Mar 2007, at 19:23, Sander Tekelenburg wrote:
[...]
>> We're not talking about IDs, just fragment identifiers. My point
>> was that
>> with video, you could use fragment identifiers *without* the need
>> for the author to provide IDs.
>
> I see your point, but i would like for fragment identifiers within a
> video to be equal to fragment IDs in text fallback content.
I completely agree that that would be ideal. But I consider it an argument to
try to find a solution for that, or if that's not possible, live with that. I
don't see it as an argument to give up on such a useful feature for users who
do not need/choose to fetch non-video fallback content.
(Note that a mechanism to allow authors to define anchors in videos is not a
solution, because it's then still the author who is in control. What I'm
suggesting is about giving the user control.)
[...]
>> the client doing the request should be smart enough to know to
>> escape the colon
>
> Wikipedia section IDs have lots of escaping, but it's all done by the
> wiki server, not the UA. I don't know if this is because UAs can't be
> trusted to get it right or not.
I'm getting the impression from RFC 3986 that it is up to the app that sends
the request to ensure the URL is properly percent-encode (meaning special
characters are escaped). For instance Section 2.2: "[...] URI producing
applications should percent-encode data octets that correspond to characters
in the reserved set [...]". And section 2.4: "[...] Under normal
circumstances, the only time when octets within a URI are percent-encoded is
during the process of producing the URI from its component parts. This is
when an implementation determines which of the reserved characters are to be
used as subcomponent delimiters and which can be safely used as data. Once
produced, a URI is always in its percent-encoded form [...]"
--
Sander Tekelenburg
The Web Repair Initiative: <http://webrepair.org/>
More information about the whatwg
mailing list