Re: [whatwg] Implement XMLHttpRequest interface subset onHTMLDocument
On Thu, 30 Oct 2008 08:21:10 +0100, Weston Ruter
[EMAIL PROTECTED] wrote:
I have an amendment to my proposal. There was a
posthttp://ajaxian.com/archives/language-jsonp-serviceon Ajaxian
today about a Language JSONP Service which calculates the
users language based on browser headers. This seems like a terrible
workaround since the Accept-Language header is sent from the same browser
that the script is running in; a script shouldn't have to make an HTTP
request just to find out what the browser's request headers are.
Did you read what kriszyp wrote in a comment to that post?
Therefore, I propose that in addition to implementing on HTMLDocument the
XMLHttpRequest interface subset I initially suggested, I see that it
would also be very useful for a script to obtain the request headers
that were
sent which resulted in the current document as the response. The current
version of XMLHttpRequest hints to a future version including a
getRequestHeader() method, a method which would complement
getResponseHeader(); there could also be a getAllRequestHeaders() method
that would correspond to the existing getAllResponseHeaders() method.
(Obviously it would not make sense to implement the setRequestHeader()
method.)
If these two methods ( getRequestHeader() and getAllRequestHeaders() )
were
implemented, then there would be no need for a Language JSONP Service
because there would be a better way to get the same result synchronously
without any HTTP request, for example:
document.getRequestHeader('Accept-Language')
I think we need more use cases than just this (especially since this one
seems addressed already) to consider this.
--
Anne van Kesteren
http://annevankesteren.nl/
http://www.opera.com/
Re: [whatwg] Implement XMLHttpRequest interface subset onHTMLDocument
On Wed, Dec 10, 2008 at 3:01 PM, Anne van Kesteren [EMAIL PROTECTED] wrote: On Thu, 30 Oct 2008 08:21:10 +0100, Weston Ruter [EMAIL PROTECTED] wrote: I have an amendment to my proposal. There was a posthttp://ajaxian.com/archives/language-jsonp-serviceon Ajaxian today about a Language JSONP Service which calculates the users language based on browser headers. This seems like a terrible workaround since the Accept-Language header is sent from the same browser that the script is running in; a script shouldn't have to make an HTTP request just to find out what the browser's request headers are. Did you read what kriszyp wrote in a comment to that post? Yes, and the answer to his question is: yes, there is a difference. First, those client-side properties give you one lang code only, which is clearly not enough for conneg. Let's say I have a GWT application available in dutch and english, where dutch is the default language (i.e. prefered over english). My navigator.language returns fr, but my Accept-Language reads fr-fr, fr, en. With navigator.language only, I'd have the dutch version, with Accept-Language I'd have the english one. Second, these client-side properties return the UI language, which is different from the user-preferred language. FF3.1b2 is now available in many languages but before that, only english was available. navigator.language in this case would return en, despite me having changed Accept-Language to fr-fr, fr, en. -- Thomas Broyer
Re: [whatwg] Use cases for Node.getElementById
Garrett Smith ha scritto: On Sat, Dec 6, 2008 at 7:09 PM, Calogero Alex Baldacchino [EMAIL PROTECTED] wrote: Simon Pieters ha scritto: On Fri, 05 Dec 2008 19:19:04 +0100, Calogero Alex Baldacchino [EMAIL PROTECTED] wrote: [...] (I'm currently the editor of that proposal, currently located at http://simon.html5.org/specs/web-dom-core ) I'm reading it :-) And I have a few questions. I did not see a proposal for Element.getElementById. I would not care about that much. I woud rather have Element.getElementsByName. It is perfectly valid for a doucment to have multiple elements w/the same name (though not generally a good idea). I've seen this before. Was this proposed? Garrett I don't remember what spec exactly stated this first, but I remind of a previous HTML version declaring the 'name' attribute as unique in the 'global scope' (or something like that), meaning the whole document; then, I remember 'name' was deprecated in favour of 'id'. I think 'getElementsByName' was retained from the past just because form elements scoped input names in a different manner (while the name of an anchor, for instance, had to be unique in the whole document), but it was a bit conflicting with the uniqueness of (at least some) elements' name. Anyway, this is what I remember (current specification no more defines a name attribute for every elements - it's not on the HTMLElement interface). However, the issue about Node.getElementById originated by noticing problems with duplicate ids in existing pages and the likelihood new pages may have duplicate ids (e.g. by repeatedly cloning and inserting nodes without caring of all attributes), thinking on the opportunity to address such an illegal state somehow. If non-unique identifiers have to be a deliberate and 'careful' choise, such to involve a dedicated attribute, perhaps the class attribute and [ HTMLDocument | HTMLElement | whatever_else_implementing ].getElementsByClassName() methods can address that: classes are non-unique not only for the whole document, but also for the same element, which may have multiple classes listed in its attribute (each class name is unique in the list), so they might be used for some non-style-related purposes, just appending a name to the list of styling classes (just to give some clearness, though unnecessary), and querying it with getElementsByClassName() would work the same way as resorting to the 'name' attribute and the 'getElementsByName()' method (perhaps a bit tricky, but should work fine). ~~ @ Simon Pieters (and everyone else on the list, of course). I was thinking again on 'getElementsByClassName()' moved to Web DOM Core: maybe a good place for it might be the Node interface, so to have the method working on Documents as well as on Elements; if the HTMLCollection interface were moved as well, perhaps such might be the return value, instead of a NodeList, since non-element Nodes should never be expected to have a class name, I guess (perhaps doing the same with getElementsByTagName might be consistent, but maybe problematic because of backward compatibility -- while getElementsByClassName would be a 'new entry' in the 'reign' of Core interfaces, thus a greater degree of freedom might be taken, if reasonable, of course - it may depend on a known need for different, specilized algorithms in Document and Element nodes, for instance). Best regards, Alex -- Caselle da 1GB, trasmetti allegati fino a 3GB e in piu' IMAP, POP3 e SMTP autenticato? GRATIS solo con Email.it http://www.email.it/f Sponsor: RC Auto? * Con Direct Line garanzia furto e incendio a soli 30 per un anno! Non perdere loccasione! * Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=8497d=10-12
Re: [whatwg] Use cases for Node.getElementById
On Wed, Dec 10, 2008 at 8:10 AM, Calogero Alex Baldacchino [EMAIL PROTECTED] wrote: Garrett Smith ha scritto: On Sat, Dec 6, 2008 at 7:09 PM, Calogero Alex Baldacchino [EMAIL PROTECTED] wrote: Simon Pieters ha scritto: On Fri, 05 Dec 2008 19:19:04 +0100, Calogero Alex Baldacchino [EMAIL PROTECTED] wrote: [...] (I'm currently the editor of that proposal, currently located at http://simon.html5.org/specs/web-dom-core ) I'm reading it :-) And I have a few questions. I did not see a proposal for Element.getElementById. I would not care about that much. I woud rather have Element.getElementsByName. It is perfectly valid for a doucment to have multiple elements w/the same name (though not generally a good idea). I've seen this before. Was this proposed? Garrett I don't remember what spec exactly stated this first, but I remind of a previous HTML version declaring the 'name' attribute as unique in the 'global scope' (or something like that), What? meaning the whole document; then, I remember 'name' was deprecated in favour of 'id'. Name is not deprecated. It is, as I said, perfectly valid. How else are you going to submit form values? Garrett
Re: [whatwg] Implement XMLHttpRequest interface subset onHTMLDocument
On Wed, Dec 10, 2008 at 6:01 AM, Anne van Kesteren [EMAIL PROTECTED] wrote:
I think we need more use cases than just this (especially since this one
seems addressed already) to consider this.
I agree we need more use cases. You understand that the Accept-Language
header is just one example of a header that needs to be read via scripting;
the use case addressed by Language JSONP Service highlights the need for
getRequestHeaders() since its solution is an inefficient (although clever)
hack. Ideally, scripts should be able to access all of the request and
response headers.
Another use case would be getting the Accept header to detect if the
client can be served XHTML.
Weston
On Wed, Dec 10, 2008 at 6:01 AM, Anne van Kesteren [EMAIL PROTECTED] wrote:
On Thu, 30 Oct 2008 08:21:10 +0100, Weston Ruter
[EMAIL PROTECTED] wrote:
I have an amendment to my proposal. There was a
posthttp://ajaxian.com/archives/language-jsonp-serviceon Ajaxian
today about a Language JSONP Service which calculates the
users language based on browser headers. This seems like a terrible
workaround since the Accept-Language header is sent from the same browser
that the script is running in; a script shouldn't have to make an HTTP
request just to find out what the browser's request headers are.
Did you read what kriszyp wrote in a comment to that post?
Therefore, I propose that in addition to implementing on HTMLDocument the
XMLHttpRequest interface subset I initially suggested, I see that it would
also be very useful for a script to obtain the request headers that were
sent which resulted in the current document as the response. The current
version of XMLHttpRequest hints to a future version including a
getRequestHeader() method, a method which would complement
getResponseHeader(); there could also be a getAllRequestHeaders() method
that would correspond to the existing getAllResponseHeaders() method.
(Obviously it would not make sense to implement the setRequestHeader()
method.)
If these two methods ( getRequestHeader() and getAllRequestHeaders() )
were
implemented, then there would be no need for a Language JSONP Service
because there would be a better way to get the same result synchronously
without any HTTP request, for example:
document.getRequestHeader('Accept-Language')
I think we need more use cases than just this (especially since this one
seems addressed already) to consider this.
--
Anne van Kesteren
http://annevankesteren.nl/
http://www.opera.com/
Re: [whatwg] Use cases for Node.getElementById
Garrett Smith ha scritto: On Wed, Dec 10, 2008 at 8:10 AM, Calogero Alex Baldacchino [EMAIL PROTECTED] wrote: Garrett Smith ha scritto: On Sat, Dec 6, 2008 at 7:09 PM, Calogero Alex Baldacchino [EMAIL PROTECTED] wrote: Simon Pieters ha scritto: On Fri, 05 Dec 2008 19:19:04 +0100, Calogero Alex Baldacchino [EMAIL PROTECTED] wrote: [...] (I'm currently the editor of that proposal, currently located at http://simon.html5.org/specs/web-dom-core ) I'm reading it :-) And I have a few questions. I did not see a proposal for Element.getElementById. I would not care about that much. I woud rather have Element.getElementsByName. It is perfectly valid for a doucment to have multiple elements w/the same name (though not generally a good idea). I've seen this before. Was this proposed? Garrett I don't remember what spec exactly stated this first, but I remind of a previous HTML version declaring the 'name' attribute as unique in the 'global scope' (or something like that), What? meaning the whole document; then, I remember 'name' was deprecated in favour of 'id'. Name is not deprecated. It is, as I said, perfectly valid. How else are you going to submit form values? Garrett I was referring to some elements using it as a global identifier, like a and img, and apologize for any lack of clearness. From http://www.w3.org/TR/html401/struct/links.html#adef-name-A This attribute names the current anchor so that it may be the destination of another link. The value of this attribute must be a unique anchor name. The scope of this name is the current document. Note that this attribute shares the same name space as the id attribute http://www.w3.org/TR/html401/struct/global.html#adef-id From http://www.w3.org/TR/html401/struct/objects.html#adef-name-IMG This attribute names the element so that it may be referred to from style sheets or scripts. Note.** This attribute has been included for backwards compatibility. Applications should use the id attribute to identify elements From http://www.w3.org/TR/html401/struct/links.html#anchors-with-id The id and name attributes share the same namespace.This means that they cannot both define an anchor with the same name in the same document. It is permissible to use both attributes to specify an element's unique identifier for the following elements: A, APPLET, FORM, FRAME, IFRAME, IMG and MAP. When both attributes are used on a single element, their values must be identical. You'll find neither html 4.01, nor html 5 declare a 'name' attribute for every element (some of html 5 elements have lost their older 'name' attribute, though it might be handled by the parser for backwards compatibility, i.e. for the a element representing a fragment of the document). -- Caselle da 1GB, trasmetti allegati fino a 3GB e in piu' IMAP, POP3 e SMTP autenticato? GRATIS solo con Email.it http://www.email.it/f Sponsor: CheBanca! La prima banca che ti dà gli interessi in anticipo. * Fino al 4,70% sul Conto Deposito, zero spese e interessi subito. Aprilo! Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=7918d=10-12
Re: [whatwg] Thoughts on video accessibility
And now we have a first demo of the proposed syntax in action. Michael Dale implemented SRT support like this: video src=sample_fish.ogg poster=sample_fish.jpg duration=26 text category=SUB lang=en type=text/x-srt default=true title=english SRT subtitles src=sample_fish_text_en.srt /text text category=SUB lang=es type=text/x-srt title=spanish SRT subtitles src=sample_fish_text_es.srt /text /video Michael writes: the demo: (tested on IE, Firefox, Safari ... with varying degrees of success ;) http://metavid.org/w/extensions/MetavidWiki/skins/mv_embed/example_usage/sample_timed_text.php (bottom example) If Firefox exposes timed text tracks in ogg media the script could query them and display them alongside any available markup text tracks (but of course other browsers like IE wont easily expose those muxed text tracks so its likely the least common denominator of text based markup / pointers will be dominate for some time) You will need to click on the CC button on the player and click on select transcripts to see the different subtitles in English and Spanish. Regards, Silvia. On Wed, Dec 10, 2008 at 3:49 AM, Silvia Pfeiffer [EMAIL PROTECTED] wrote: I heard some complaints about there not being any implementation of the suggestions I made. So here goes: 1. out-of-band There is an example of using srt with ogg in a out-of-band approach here: http://v2v.cc/~j/jquery.srt/ You will need Firefox3.1 to play it. The syntax of what Jan implemented is different to what I proposed, but I wanted to take it forward and make it more generic. 2. in-band There is also a draft implementation of srt inside Ogg through the OggText specification, but I it's not released yet. It is also not as relevant to this group as the out-of-band example. Cheers, Silvia. On Tue, Dec 9, 2008 at 7:33 PM, Robert O'Callahan [EMAIL PROTECTED] wrote: On Tue, Dec 9, 2008 at 6:20 PM, Martin Atkins [EMAIL PROTECTED] wrote: Silvia Pfeiffer wrote: I'm interested to hear people's opinions on these ideas. I agree with Ralph and think having a simple, explicit mechanism at the html level is worthwhile - and very open and explicit to a web author. Having a redirection through a ROE-type file on the server is more opaque, but maybe more consistent with existing similar approaches as taken by RealNetworks in rm files and WindowsMedia files in asx files. This (having a separate document that references other streams) is what I was thinking of. I guess which is more natural depends on who is doing the assembling. If it is the HTML author that takes the individual pieces and links them together then doing it in the HTML is probably easiest. For what it's worth, loading an intermediate document of some new type which references other streams to be loaded adds a lot of complexity to the browser implementation. It creates new states that the decoder can be in, and introduces new failure modes. It creates new timing issues and possibly new security issues. Rob -- He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all. [Isaiah 53:5-6]
Re: [whatwg] Thoughts on video accessibility
Yea as Silvia outlines in the intro to this thread we will likely continue to see external timed text files winning out over muxed timed text. Its just more flexible ... Javascript embedding libraries which are widely used today for flash video will be even more widely used with the emerging browser support of the video tag. So its not too big a deal... the complexity of transcript formats will be handled by dedicated javascript libraries. If the browser does expose some timed text tracks muxed with the media then the library will integrate that into the interface. That being said having some semantically meaningful source data representation is worthwhile. By supporting these proposed syntax with the embedding libraries we are promoting the idea that the syntax will eventually be adopted and natively handled by the browser. But in practice even if we do get native timed text support a javascript library will likely rewrite it to conform the sites layout and skinning anyway. The take-away point here is if people do mux text tracks that they should be exposed via javascript. Otherwise it will be of very limited value in the context of web media. peace, --michael Silvia Pfeiffer wrote: And now we have a first demo of the proposed syntax in action. Michael Dale implemented SRT support like this: video src=sample_fish.ogg poster=sample_fish.jpg duration=26 text category=SUB lang=en type=text/x-srt default=true title=english SRT subtitles src=sample_fish_text_en.srt /text text category=SUB lang=es type=text/x-srt title=spanish SRT subtitles src=sample_fish_text_es.srt /text /video Michael writes: the demo: (tested on IE, Firefox, Safari ... with varying degrees of success ;) http://metavid.org/w/extensions/MetavidWiki/skins/mv_embed/example_usage/sample_timed_text.php (bottom example) If Firefox exposes timed text tracks in ogg media the script could query them and display them alongside any available markup text tracks (but of course other browsers like IE wont easily expose those muxed text tracks so its likely the least common denominator of text based markup / pointers will be dominate for some time) You will need to click on the CC button on the player and click on select transcripts to see the different subtitles in English and Spanish. Regards, Silvia. On Wed, Dec 10, 2008 at 3:49 AM, Silvia Pfeiffer [EMAIL PROTECTED] wrote: I heard some complaints about there not being any implementation of the suggestions I made. So here goes: 1. out-of-band There is an example of using srt with ogg in a out-of-band approach here: http://v2v.cc/~j/jquery.srt/ You will need Firefox3.1 to play it. The syntax of what Jan implemented is different to what I proposed, but I wanted to take it forward and make it more generic. 2. in-band There is also a draft implementation of srt inside Ogg through the OggText specification, but I it's not released yet. It is also not as relevant to this group as the out-of-band example. Cheers, Silvia. On Tue, Dec 9, 2008 at 7:33 PM, Robert O'Callahan [EMAIL PROTECTED] wrote: On Tue, Dec 9, 2008 at 6:20 PM, Martin Atkins [EMAIL PROTECTED] wrote: Silvia Pfeiffer wrote: I'm interested to hear people's opinions on these ideas. I agree with Ralph and think having a simple, explicit mechanism at the html level is worthwhile - and very open and explicit to a web author. Having a redirection through a ROE-type file on the server is more opaque, but maybe more consistent with existing similar approaches as taken by RealNetworks in rm files and WindowsMedia files in asx files. This (having a separate document that references other streams) is what I was thinking of. I guess which is more natural depends on who is doing the assembling. If it is the HTML author that takes the individual pieces and links them together then doing it in the HTML is probably easiest. For what it's worth, loading an intermediate document of some new type which references other streams to be loaded adds a lot of complexity to the browser implementation. It creates new states that the decoder can be in, and introduces new failure modes. It creates new timing issues and possibly new security issues. Rob -- He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all. [Isaiah 53:5-6]
Re: [whatwg] Thoughts on video accessibility
On Wed, Dec 10, 2008 at 5:56 PM, Dave Singer [EMAIL PROTECTED] wrote: At 21:33 +1300 9/12/08, Robert O'Callahan wrote: For what it's worth, loading an intermediate document of some new type which references other streams to be loaded adds a lot of complexity to the browser implementation. It creates new states that the decoder can be in, and introduces new failure modes. It creates new timing issues and possibly new security issues. I'm not sure I agree; but if you believe that, we should address it no matter which way this discussion goes. It should absolutely be possible to reference a SMIL file, or an MP4 or MOV file with external data (to give only two examples) from a video or audio element, and have the DOM, events, states, and APis work correctly. I agree it should be done eventually, it's just significantly more complicated than what we have to deal with currently. Rob -- He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all. [Isaiah 53:5-6]
Re: [whatwg] Thoughts on video accessibility
At 14:40 +1300 11/12/08, Robert O'Callahan wrote: On Wed, Dec 10, 2008 at 5:56 PM, Dave Singer mailto:[EMAIL PROTECTED][EMAIL PROTECTED] wrote: At 21:33 +1300 9/12/08, Robert O'Callahan wrote: For what it's worth, loading an intermediate document of some new type which references other streams to be loaded adds a lot of complexity to the browser implementation. It creates new states that the decoder can be in, and introduces new failure modes. It creates new timing issues and possibly new security issues. I'm not sure I agree; but if you believe that, we should address it no matter which way this discussion goes. It should absolutely be possible to reference a SMIL file, or an MP4 or MOV file with external data (to give only two examples) from a video or audio element, and have the DOM, events, states, and APis work correctly. I agree it should be done eventually, it's just significantly more complicated than what we have to deal with currently. But if the state machine or other aspects are actually wrong for this case, then we should fix it now. We have, for example, tried to keep out these kinds of assumptions: a) all media is downloaded (no, it might be streamed or even arriving over non-IP, e.g. a TV broadcast) b) all delivery methods are self-contained (no, they might reference resources as well as contain them) c) all delivery is sequential in play order (no, some file formats decouple data timing and data ordering) Rob -- He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all. [Isaiah 53:5-6] -- David Singer Multimedia Standards, Apple Inc.
