Re: [whatwg] Feature Request: Media Elements as Targets for Links

[Nils Dagsson Moskopp]

Silvia Pfeiffer  schrieb am Mon, 26 Nov 2012
00:01:52 +1100:

> Can you provide an example markup and an example URL that you think
> will solve your use case?

Example markup. Assume I have an audio element in a blog:


  
  


Someone could comment it like:

When Alice mentioned Bob …

When someone clicks the link, the browsing context would not change,
but the media element would jump to that point (and possibly play).

> I'm asking because we don't use the name attribute any more in HTML5,
> because we have the id attribute on all elements. Thus, it is always
> possible to hyperlink directly to a video element using a hash on a
> URL and the value of the id element. But I still wonder what you
> think is missing.

I want to hyperlink directly to a embedded media content at a specific
time while preserving the context without going through brittle
JavaScript hoops. Maybe an element-specific second-hash is possible?

Something like  could
link to the audio element on the page at a specific point in time. (I
am just conjecturing now, though – is that even legal URL synthax?)


Greetings,
-- 
Nils Dagsson Moskopp // erlehmann

Re: [whatwg] Make stepUp() and stepDown() more developer-friendly

[Scott González]

On Tue, Nov 20, 2012 at 5:55 PM, Ian Hickson  wrote:

> > I can list out the steps we take for all conditions, but I'd like to
> > hear everyone's thoughts on the various cases where you're suggesting
> > that the methods do nothing.
>
> Mostly I agree with Mounir here, but I'm curious about what you think
> should happen for the case where there's no value, and the case where the
> control isn't a numeric/date/time type. I could see an argument for
> stepping from the default in the former case (Mounir, what do you think
> about doing that?) but for the latter case I don't really see any point
> doing anything but throw an exception, as Mounir suggested.


For any non-parsable value (including no value), we start at 0, take the
step, then confine to a valid step within min/max.

I think it makes sense to throw if the control doesn't support stepping.

Re: [whatwg] Feature Request: Media Elements as Targets for Links

[Silvia Pfeiffer]

Can you provide an example markup and an example URL that you think will
solve your use case?

I'm asking because we don't use the name attribute any more in HTML5,
because we have the id attribute on all elements. Thus, it is always
possible to hyperlink directly to a video element using a hash on a URL and
the value of the id element. But I still wonder what you think is missing.

Regards,
Silvia.

On Sun, Nov 25, 2012 at 7:19 AM, Nils Dagsson Moskopp <
n...@dieweltistgarnichtso.net> wrote:

> Excuse me if I am doing something wrong by submitting this by mail. I
> am doing this for the first time, trying to fill in the template given
> at  as good as I could.
>
> Use Case Description:
>
>   Linking to specific fragments of media is possible via media fragment
>   URIs [1]. However, it is not possible to apply a link to embedded
>   media declaratively, for example to link to a specific point in time
>   for a media element on a page.
>
>   [1] 
>
> - Current Limitations:
>
>   Linking to media using media fragment URIs changes browsing context.
>
> - Current Usage and Workarounds:
>
>   1. metavid (Videos of United States Congress) uses JavaScript, even
>   though they have CMML transcripts and SRT.
>
>   2. I have a podcast ”Warum nicht?“ generated by a software called
>   redokast. Annotations need JavaScript: Click on the timestamps.
>   
>   
>
> - Benefits: Declarative markup would make referring to timed
>   annotations easier. Referring to a specific point in time in a podcast
>   on the same comments, for example, could be possible.
>
> Proposed Solutions:
>
> - My Solution:
>   Give HTML media elements a name attribut. Make them valid targets for
>   links with a target attribut.
>
>   - Processing Model:
> Processing for media elements and the  element needs to change.
>
> <
> http://www.whatwg.org/specs/web-apps/current-work/multipage/links.html#attr-hyperlink-target
> >
> Change “The target attribute, if present, must be a valid browsing
> context name or keyword. It gives the name of the browsing context
> that will be used.” to “The target attribute, if present, must be a
> valid browsing context name or keyword or the name of a media
> element in the current browsing context. It gives the name of the
> browsing context or media element that will be used.”
>
> <
> http://www.whatwg.org/specs/web-apps/current-work/multipage/links.html#following-hyperlinks-0
> >
> Append after “If the user indicated a specific browsing context when
> following the hyperlink, or if the user agent is configured to
> follow hyperlinks by navigating a particular browsing context, then
> that must be the browsing context that is navigated.” the paragraph
> “If the user indicated a media element on the current page when
> following the hyperlink, then change the currentSrc attribute of
> the media element to the absolute URL given by the href attribute
> relative to the URL given by the currentSrc of the media element.”.
>
> (I am unsure about relative URIs. Would we need to change only the
> media fragment, and not re-run the initialization steps? What about
> the media formats given by  elements?)
>
>   - Limitations
> (No idea.)
>
>   - Implementation:
> (I am not a very clever guy. Someone would need to fill this in.)
>
>   - Adoption:
> Users could easily link to parts of media resources on a page. The
> solution would be backwards compatible for existing UAs that are
> able to process media fragment URIs as long as absolute URIs are
> used. A JavaScript polyfill could be used while not all UAs support
> this feature. Consumers of web pages could easily see what a
> discussion about a media resource refers to.
>
> --
> Nils Dagsson Moskopp // erlehmann
> 
>

Re: [whatwg] URL testing

[Anne van Kesteren]

On Sat, Nov 24, 2012 at 11:49 PM, Chris Weber  wrote:
> There also appears to be some differences in Unicode normalization
> (assuming I tested this enough), see:
>
> http://web.lookout.net/2012/03/unicode-normalization-in-urls.html
>
> In my tests:
>
> Safari applied NFC normalization to the path, query, and fragment.
> Chrome applied NFC normalization to the fragment only.
> MSIE, Firefox, and Opera did not apply normalization anywhere.

I don't think we should allow normalization (other than for the host
name). Since you are testing fragment, you might want to compare .hash
and .href. The results are different there. I've not yet reached a
conclusion there for what the specification should align with.
(Currently both are percent-escaped, but I could go with neither, or
one or the other I suppose).


>> * IDNA is a rathole.
>
> But it makes for interesting test cases :-)

The problem is that it's not clear what to test (or define in the
specification): http://wiki.whatwg.org/wiki/URL#IDNA


> I plan to do it slowly over the course of the next week or two.

Cool! Having some kind of infrastructure in place for setting (and
getting I suppose) individual components would also be good to have.
Are you planning on adding that? I'll try to allocate some time to
review the tests in more detail.


-- 
http://annevankesteren.nl/