[whatwg] A plan to enable Forms?
A plan to enable Forms? Does the SVG WG have a plan to enable Forms? what is the current status regarding sockets and SVG 1.2? regards ~: The popular SVG-native web browsers such as Opera, Mozilla and Webkit have not implemented xforms. HTML5 proposal: http://www.whatwg.org/specs/web-apps/current-work/multipage/forms.html#forms
Re: [whatwg] Remove addCueRange/removeCueRanges
Hi, The .start/.end properties were dropped in favor of media fragments, which the Media Fragments Working Group is producing a spec for. Who decided this? Has this decision been made public on this list? It will be something like http://www.example.com/movie.mov#t=12.33,21.16 var audioObject = new Audio(); audioObject.src ='data:audio/x-wav;base64,UklGRiIAAABXQVZFZm10IBABAAEAIlYAAESsAAACABAAZGF0Yf7///8A'; // play entire audio audioObject.play(); // play (0.54328,0.72636) media fragment ? See http://www.w3.org/2008/01/media-fragments-wg.html and http://www.w3.org/2008/WebVideo/Fragments/wiki/Syntax#Examples Did you look at these yourself? I couldn't find something that approaches a spec of comparable quality to WHATWG in these pages. Is there any provision for the dynamic case, where you want to change the media fragment after it has been loaded, with zero server interaction, and working for data URIs as well? Actually, out of curiousity: could gapless concatenation of several audio objects be added as well, e.g. audioObject1.append(audioObject2) or even audioObject.join([audioObject1,audioObject2,...,audioObjectN) There has been much discussion about audio canvas API:s and I trust this could fit into that scope. As the 'inventor' of the term, I am of course familiar with the discussion - here I was merely adding an item to the wishlist. View source at http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#video and search for v2 and you'll find some of these ideas. Could these be lifted from hidden HTML comments to something with better visibility somehow? -- Markus
Re: [whatwg] HTML 5 Script Tag
Tab Atkins Jr. schrieb: On Thu, Aug 6, 2009 at 6:14 PM, Cready, Jamesjcre...@rtcrm.com wrote: You make a great point. But whether or not you use the XML/XHTML syntax/ or the HTML 4 syntax doesn¹t matter much. Since like I showed in my previous example: the instant you specify a src attribute on your opening script tag the browser will not execute anything inside the tags. Regardless of whether or not you even specified a value for it. [snip] It seems like there should be some consistency between the two, either: A) Allow link to pull in all types of external files: CSS: link rel=stylesheet type=text/css href=style.css / JS : link rel=javascript type=text/javascipt href=script.js / or B) Allow ONLY script and style to pull in their external files: CSS: style src=style.css type=text/css/style JS : script src=script.js type=text/javascript/script I (and others in this thread, and probably a lot of people on the web as a whole) agree with you that it would be nice to have some consistency there (I favor the link approach myself). However, the world is neither kind nor just, and one of HTML5's explicit guidelines is to codify and standardize browser behavior in the wild. We can improve it when it's possible to do so in a backwards-compatible way, but otherwise it's out. The favored example: link rel=script type=text/javascript href=script.js would actually not break pages in legacy browsers, unless their functionality depends on the script. They would just not find and thus not execute the script, and possibly throw function does not exist errors. Authors are encouraged to code web pages in a way that the functionality is provided, or at least degrades nicely, in no-script environments. So I assume that a properly coded page would work or degrade nicely in legacy browsers with the link syntax. Anyway I am not sure about this, as I am aware of the fact that a missing script file is not the same as a user agent without script execution. At least the following example would work in Firefox - if the foo() function is not defined, otherpage.php will be called: a href=otherpage.php onClick=return foo()Click here/a
Re: [whatwg] Remove addCueRange/removeCueRanges
Silvia, 2009/8/13 Dr. Markus Walther walt...@svox.com: please note that with cue ranges removed, the last HTML 5 method to perform audio subinterval selection is gone. Not quite. You can always use the video.currentTime property in a javascript to directly jump to a time offset in a video. And in your javascript you can check this property until it arrives at your determined end time. So, there is a way to do this even now. How can polling approach that somehow monitors currentTime meet any halfway-decent accuracy requirements? E.g. to be accurate to 1-3 samples at 22050 Hz sampling frequency? I doubt your approach could fulfill this. To my mind, the current turn of events suggests simply to allow start/end attributes back into the WHATWG spec, eased by the fact that there were already browser implementations of it. -- Markus
Re: [whatwg] small element should allow nested elements
On Fri, 7 Aug 2009, Remy Sharp wrote: The HTML 5 spec says: Small print typically features disclaimers, caveats, legal restrictions, or copyrights. Small print is also sometimes used for attribution, or for satisfying licensing requirements. So I'm making a list of disclaimers for my site: ol liYou must agree to this term/li liAnd this term too/li liAnd don't break this term/li liAnd don't forget the milk/li /ol pBy reading this, you're agreeing to xyz/p To make this valid, and small print text, I need to individually wrap the inner HTML of each inline element (li and p elements). This is wasteful and very much like the situation that we had with the a element when we wanted the whole block to be clickable. I wouldn't bother wrapping any of the above as small print. If you're structuring this enough that you have numbered lists and paragraphs and everything, then it's either not small print, or it shouldn't be. Allowing elements to wrap both inlines and blocks is a huge can of worms which has caused all kinds of problems for ins, del, and a. I really don't want to start adding more elements to this list of complexity. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Remove addCueRange/removeCueRanges
2009/8/14 Dr. Markus Walther walt...@svox.com: Hi, The .start/.end properties were dropped in favor of media fragments, which the Media Fragments Working Group is producing a spec for. Who decided this? Has this decision been made public on this list? It will be something like http://www.example.com/movie.mov#t=12.33,21.16 var audioObject = new Audio(); audioObject.src ='data:audio/x-wav;base64,UklGRiIAAABXQVZFZm10IBABAAEAIlYAAESsAAACABAAZGF0Yf7///8A'; // play entire audio audioObject.play(); // play (0.54328,0.72636) media fragment ? Not in this way. In fact, the new way will be much much simpler and does not require javascript. All you need to do is: video src=http://www.example.com/movie.ogv#t=12.33,21.16; or audio src=http://www.example.com/sound.oga#t=0.54328,0.72636; Or if you really wanted to do it in javascript, you'd only need to reload the resource: video.src = http://www.example.com/movie.ogv#t=12.33,21.16;; or audio.src = http://www.example.com/sound.oga#t=0.54328,0.72636;; That would have the same effect as setting start and end time. Regards, Silvia.
Re: [whatwg] Textarea wrap=off
On Fri, 7 Aug 2009, Tab Atkins Jr. wrote: Proposal Add the off state to the @wrap attribute for textareas. Explanation === The off state prevents a textarea from wrapping text at all while displaying. Instead, text that is too long for the textarea trigger a horizontal scrollbar, but stays on one line. The only way for text to drop to a new line is with an actual carriage return. The value of a textarea with wrap=off is the same as wrap=soft. Reasoning = Every UA I've tested (FF3.5, IE7, Opera10B2, Safari4, Chrome2) already supports it. They offer slightly different displays of a wrap=off textarea, but the basic functionality as described above is identical and seemingly interoperable. Adding this to the spec shouldn't require any additional work from the UAs, it would merely be recognizing and enshrining a facility that is already common to all of them. The off value is already defined in HTML5 for the purpose of rendering [1]. However, it isn't a conforming value, because it appears to have no purpose other than a visual presentational effect. [1] Last paragraph of: http://www.whatwg.org/specs/web-apps/current-work/#the-textarea-element-0 -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] object behavior
- Should the type attribute take precedence over the Content-Type header? No, I believe what the spec says here is the preferred behaviour. Unless this is incompatible with legacy content, we should try to move towards this behaviour. OK, should the spec mention the change that Boris Zbarsky said had been made for Gecko? I guess this use makes up the majority of uses of object on the web (although the Content-Type header should be set to the same thing so it wouldn't normally matter). Presumably this would also change the rules for when to instantiate a new plugin, given that the current rules are essentially whenever a different plugin or data would be loaded. I'm also confused about the criteria for creating a nested browsing context. - If the resource type is an XML MIME type - If the resource type is HTML - If the resource type does not start with image/ Does that mean: - xml_mime_type OR html OR not_image this is the same as xml_mime_type OR not_image - xml_mime_type AND html AND not_image this would be application/xhtml+xml, application/ce-html+xml etc. but *not* text/html - (xml_mime_type OR html) AND not_image makes sense but would certainly need clarification in the spec Thanks for clarifying the other bits of the object spec. -- Andrew Oakley
Re: [whatwg] Remove addCueRange/removeCueRanges
Silvia Pfeiffer wrote: 2009/8/14 Dr. Markus Walther walt...@svox.com: Hi, The .start/.end properties were dropped in favor of media fragments, which the Media Fragments Working Group is producing a spec for. Who decided this? Has this decision been made public on this list? It will be something like http://www.example.com/movie.mov#t=12.33,21.16 var audioObject = new Audio(); audioObject.src ='data:audio/x-wav;base64,UklGRiIAAABXQVZFZm10IBABAAEAIlYAAESsAAACABAAZGF0Yf7///8A'; // play entire audio audioObject.play(); // play (0.54328,0.72636) media fragment ? Not in this way. In fact, the new way will be much much simpler and does not require javascript. With the code snippet given I was pointing out that it is not obvious (to me at least) how the proposed media fragment solution covers data URIs. If it is not meant to cover them, it is limited in a way that the solution it seeks to replace is not. Or if you really wanted to do it in javascript, you'd only need to reload the resource: Of course we want to do this dynamically in JavaScript - IMHO it would be the norm not the exeception to select fragments based on user input. Precomputed fragments are of limited use. I don't quite understand why the dynamic case is so often underrepresented in these discussions... -- Markus
Re: [whatwg] object behavior
On Thu, 13 Aug 2009 22:05:26 -0400, Ian Hickson i...@hixie.ch wrote:
- Should objects exist all the time whether they are attached to the
document or not?
Assuming you mean the plugins, as opposed to the elements themselves,
then
the way the spec is written, the plugin instantiates regardless of
whether
it is in the document or not.
Are you saying that in the following case (for the Netscape 6.4 WMP
plug-in (the liveconnect-supported one) for example):
script
var obj = document.createElement(object);
obj.setAttribute(type, application/x-mplayer2);
//document.documentElement.appendChild(obj);
window.onload = function() {
setTimeout(function() {
alert(obj.SetFileName);
//document.documentElement.removeChild(obj);
//alert(obj.SetFileName);
}, 1);
};
/script
that .SetFileName() (a function the plug-in supports), will be accessible
even if the object hasn't been attached yet? Are you also saying that if
it is attached and you remove it from the document that SetFileName will
still be callable?
If so, that's not what happens in Opera. Pulling the object out of the
document nukes the plug-in instance and an instance isn't created until
you append to the document. Firefox behaves that way with plug-ins too.
And, I think that behavior is required for compat.
--
Michael
Re: [whatwg] .tags on HTMLCollections
On Fri, 7 Aug 2009, Jonas Sicking wrote: I haven't removed HTMLCollection.tags yet, since it appears to be implemented by most browsers. If we can get Opera and WebKit to remove support, then I'll remove it from the spec. Given that we have some data indicating that .tags() is not needed for web compatibility (Firefox doesn't support it and has received no requests for it, or bugs indicating sites needing it), and so far only weak data indicating it is needed (UAs support it, but not clear why), why not leave it out of the spec for now? UAs are always free to continue supporting it if they so please. I have very little desire to add support for anything to gecko just in case, without any data indicating anyone would use it, much less needs it. HTMLCollection.tags is specified for the same reason keygen is -- a majority of browsers support it. I'd like to remove it, though. I encourage you to convince other browser vendors to drop support for this feature. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
[whatwg] Feature requests in WebSocket (Was: BWTP for WebSocket transfer protocol)
On Fri, 7 Aug 2009, Jonas Sicking wrote: I agree that these are very interesting features. Especially connection multiplexing is something that I think is a good idea, for the reasons you've mentioned elsewhere in this thread (multiple widgets on the same page). How do you envisage multiplexing working? It's not clear to me what we could do that would be easier to handle than just having the script manually do the multiplexing at the application layer. What would the API look like? What would the wire level look like? But even compression is nice if it was possible. It's not clear to me that compression would be particularly useful for short packets. I agree that it could be useful for bigger packets; maybe when we support binary frames we should say that the frames are compressed? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Remove addCueRange/removeCueRanges
On Fri, Aug 14, 2009 at 7:54 PM, Dr. Markus Waltherwalt...@svox.com wrote: Silvia Pfeiffer wrote: 2009/8/14 Dr. Markus Walther walt...@svox.com: Hi, The .start/.end properties were dropped in favor of media fragments, which the Media Fragments Working Group is producing a spec for. Who decided this? Has this decision been made public on this list? It will be something like http://www.example.com/movie.mov#t=12.33,21.16 var audioObject = new Audio(); audioObject.src ='data:audio/x-wav;base64,UklGRiIAAABXQVZFZm10IBABAAEAIlYAAESsAAACABAAZGF0Yf7///8A'; // play entire audio audioObject.play(); // play (0.54328,0.72636) media fragment ? Not in this way. In fact, the new way will be much much simpler and does not require javascript. With the code snippet given I was pointing out that it is not obvious (to me at least) how the proposed media fragment solution covers data URIs. If it is not meant to cover them, it is limited in a way that the solution it seeks to replace is not. I see no reason why they should not be applicable to data URIs when it is obvious that the data URI is a media file. This has not yet been discussed, but would be an obvious use case. BTW: Did the start and end attribute implementations that you refer to cover the data scheme, too? Or if you really wanted to do it in javascript, you'd only need to reload the resource: Of course we want to do this dynamically in JavaScript - IMHO it would be the norm not the exeception to select fragments based on user input. Precomputed fragments are of limited use. I don't quite understand why the dynamic case is so often underrepresented in these discussions... http://open.bbc.co.uk/rad/demos/html5/rdtv/episode2/index.html This example from the BBC shows how to dynamically jump to fragments based on user input by setting the currentTime of the video. I don't see a difference between using the currentTime and using start and end. Precision is influenced more strongly by the temporal resolution of the decoding pipeline rather than the polling resolution for currentTime. I doubt the previous implementations of start and end gave you a 3 sample accurate resolution even for wav files. Regards, Silvia.
Re: [whatwg] Remove addCueRange/removeCueRanges
On Fri, 14 Aug 2009 10:28:14 +0200, Dr. Markus Walther walt...@svox.com wrote: Hi, The .start/.end properties were dropped in favor of media fragments, which the Media Fragments Working Group is producing a spec for. Who decided this? Has this decision been made public on this list? It happened in November 2008: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2008-November/017157.html This is the specific spec change: http://html5.org/tools/web-apps-tracker?from=2400to=2401context=10 It will be something like http://www.example.com/movie.mov#t=12.33,21.16 var audioObject = new Audio(); audioObject.src ='data:audio/x-wav;base64,UklGRiIAAABXQVZFZm10IBABAAEAIlYAAESsAAACABAAZGF0Yf7///8A'; // play entire audio audioObject.play(); // play (0.54328,0.72636) media fragment ? See http://www.w3.org/2008/01/media-fragments-wg.html and http://www.w3.org/2008/WebVideo/Fragments/wiki/Syntax#Examples Did you look at these yourself? I couldn't find something that approaches a spec of comparable quality to WHATWG in these pages. Implementation (should) always comes before spec and there is no implementation yet. Given the simplicity of the most basic syntax, I am not at all worried by the lack of a proper spec yet. Is there any provision for the dynamic case, where you want to change the media fragment after it has been loaded, with zero server interaction, and working for data URIs as well? You can change the fragment with scripts at any time you want followed by load()/play(). data URI's with fragments are perfectly valid as far as I can see. The rest is up to proper implementation (caching). Actually, out of curiousity: could gapless concatenation of several audio objects be added as well, e.g. audioObject1.append(audioObject2) or even audioObject.join([audioObject1,audioObject2,...,audioObjectN) There has been much discussion about audio canvas API:s and I trust this could fit into that scope. As the 'inventor' of the term, I am of course familiar with the discussion - here I was merely adding an item to the wishlist. View source at http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#video and search for v2 and you'll find some of these ideas. Could these be lifted from hidden HTML comments to something with better visibility somehow? I agree that would be nice, perhaps on http://wiki.whatwg.org/ ? -- Philip Jägenstedt Opera Software
Re: [whatwg] Removing versioning from HTML
On Sun, 9 Aug 2009, Aaron Boodman wrote: I frequently see the comment on this list and in other forums that something is too late for HTML5, and therefore discussion should be deferred. I would like to propose that we get rid of the concepts of versions altogether from HTML. In reality, nobody supports all of HTML5. Each vendor supports a slightly different subset of the spec, along with some features that are outside the spec. This seems OK to me. Instead of insisting that a particular version of HTML is a monolithic unit that must be implemented in its entirety, we could have each feature (or logical group of features) spun off into its own small spec. We're already doing this a bit with things like Web Workers, but I don't see why we don't just do it for everything. Just as they do now, vendors would decide at the end of the day which features they would implement and which they would not. But we should never have to say that the spec is too big. If somebody is interested in exploring an idea, they should be able to just start doing that. I agree in principle. With HTML5, we had an anomalous event in that the HTML4 spec was unusable as a base, due to its woeful inadequacies in terms of precision in implementation requirements, and the large holes in terms of what the platform involves relative to what it specified. Moving forward, I would like to move to a model that is less tied to versions. I expect to start looking at this kind of thing next year. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Remove addCueRange/removeCueRanges
On Fri, 14 Aug 2009 10:42:50 +0200, Dr. Markus Walther walt...@svox.com wrote: Silvia, 2009/8/13 Dr. Markus Walther walt...@svox.com: please note that with cue ranges removed, the last HTML 5 method to perform audio subinterval selection is gone. Not quite. You can always use the video.currentTime property in a javascript to directly jump to a time offset in a video. And in your javascript you can check this property until it arrives at your determined end time. So, there is a way to do this even now. How can polling approach that somehow monitors currentTime meet any halfway-decent accuracy requirements? E.g. to be accurate to 1-3 samples at 22050 Hz sampling frequency? I doubt your approach could fulfill this. To my mind, the current turn of events suggests simply to allow start/end attributes back into the WHATWG spec, eased by the fact that there were already browser implementations of it. Highly accurate looping or fragment selection is something that requires a lot of work on the implementation side. I don't have a particular aversion to .start/.end, but think it would be wise to wait for implementor experience before (re)introducing any of start/end, addCueRange/removeCueRanges or a timed text API. Whatever the spec says before that is likely to be wrong. -- Philip Jägenstedt Opera Software
Re: [whatwg] Remove addCueRange/removeCueRanges
On Fri, 14 Aug 2009 12:48:59 +0200, Silvia Pfeiffer silviapfeiff...@gmail.com wrote: On Fri, Aug 14, 2009 at 7:54 PM, Dr. Markus Waltherwalt...@svox.com wrote: Silvia Pfeiffer wrote: 2009/8/14 Dr. Markus Walther walt...@svox.com: Hi, The .start/.end properties were dropped in favor of media fragments, which the Media Fragments Working Group is producing a spec for. Who decided this? Has this decision been made public on this list? It will be something like http://www.example.com/movie.mov#t=12.33,21.16 var audioObject = new Audio(); audioObject.src ='data:audio/x-wav;base64,UklGRiIAAABXQVZFZm10IBABAAEAIlYAAESsAAACABAAZGF0Yf7///8A'; // play entire audio audioObject.play(); // play (0.54328,0.72636) media fragment ? Not in this way. In fact, the new way will be much much simpler and does not require javascript. With the code snippet given I was pointing out that it is not obvious (to me at least) how the proposed media fragment solution covers data URIs. If it is not meant to cover them, it is limited in a way that the solution it seeks to replace is not. I see no reason why they should not be applicable to data URIs when it is obvious that the data URI is a media file. This has not yet been discussed, but would be an obvious use case. BTW: Did the start and end attribute implementations that you refer to cover the data scheme, too? To my knowledge/experience, there is nothing special about data URIs. Any differences in how they work with the DOM interface or media fragments are more than likely implementation bugs. -- Philip Jägenstedt Opera Software
Re: [whatwg] Alt attribute for video and audio
On Mon, 10 Aug 2009, Remco wrote: Shouldn't videos and audios (and maybe objects too?) also have an alt attribute? A quick Google search tells me this has not been discussed before. For users who can use audio but not video, authors should either provide audio descriptions in the video file as alternative tracks, or supplemental material provided in links available to everyone near the video. For users who can use video but not audio, authors should provide subtitles, captions, or transcripts either in the video or audio file as supplemental tracks, or in supplemental materials available to everyone in links near the video. For users who can use neither video nor audio, supplemental materials are likely the best thing for an author to provide, again, in links visible to all. For users of legacy UAs that don't support these features, feature-rich alternatives such as plugins can be provided as fallback content for video and audio. Captions and subtitles can be included either directly in the media file, or scripts can manually support external resources using the cue range API. Going forward, we will probably also support dedicated formats that UAs can merge with the video to handle showing external subtitles natively. I don't see a need for an alt= attribute here. What problem would it solve that is not solved by the above solutions? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Alt attribute for video and audio
On Fri, Aug 14, 2009 at 9:13 PM, Ian Hicksoni...@hixie.ch wrote: On Mon, 10 Aug 2009, Remco wrote: Shouldn't videos and audios (and maybe objects too?) also have an alt attribute? A quick Google search tells me this has not been discussed before. For users who can use audio but not video, authors should either provide audio descriptions in the video file as alternative tracks, or supplemental material provided in links available to everyone near the video. For users who can use video but not audio, authors should provide subtitles, captions, or transcripts either in the video or audio file as supplemental tracks, or in supplemental materials available to everyone in links near the video. For users who can use neither video nor audio, supplemental materials are likely the best thing for an author to provide, again, in links visible to all. For users of legacy UAs that don't support these features, feature-rich alternatives such as plugins can be provided as fallback content for video and audio. Captions and subtitles can be included either directly in the media file, or scripts can manually support external resources using the cue range API. Going forward, we will probably also support dedicated formats that UAs can merge with the video to handle showing external subtitles natively. I don't see a need for an alt= attribute here. What problem would it solve that is not solved by the above solutions? There is only one thing I can think about that an alt attribute could provide that nothing else does: as a blind user tabs onto a video element, the alt attribute's content could be read out and briefly describe what is visible in the poster image - or alternatively give a brief summary of the video. This is useful for all those cases where no surrounding text is given for whatever reason. Where a surrounding text is given, such as the video title and description, such text is likely not necessary. Cheers, Silvia.
Re: [whatwg] Alt attribute for video and audio
On Aug 14, 2009, at 16:06, Silvia Pfeiffer wrote: There is only one thing I can think about that an alt attribute could provide that nothing else does: as a blind user tabs onto a video element, the alt attribute's content could be read out and briefly describe what is visible in the poster image - or alternatively give a brief summary of the video. This is useful for all those cases where no surrounding text is given for whatever reason. Where a surrounding text is given, such as the video title and description, such text is likely not necessary. I believe aria-label addresses this. -- Henri Sivonen hsivo...@iki.fi http://hsivonen.iki.fi/
Re: [whatwg] Alt attribute for video and audio
On Fri, Aug 14, 2009 at 11:09 PM, Henri Sivonenhsivo...@iki.fi wrote: On Aug 14, 2009, at 16:06, Silvia Pfeiffer wrote: There is only one thing I can think about that an alt attribute could provide that nothing else does: as a blind user tabs onto a video element, the alt attribute's content could be read out and briefly describe what is visible in the poster image - or alternatively give a brief summary of the video. This is useful for all those cases where no surrounding text is given for whatever reason. Where a surrounding text is given, such as the video title and description, such text is likely not necessary. I believe aria-label addresses this. Excellent. Then I haven't seen a good argument to add it. Let's not. Regards, Silvia.
Re: [whatwg] Textarea wrap=off
On Fri, 14 Aug 2009 16:02:52 +0200, Tab Atkins Jr. jackalm...@gmail.com wrote: Is there some other place I should be looking in the multipage spec? http://www.whatwg.org/specs/web-apps/current-work/multipage/the-xhtml-syntax.html#the-textarea-element-0 -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] A plan to enable Forms?
2009/8/14 ~:'' ありがとうございました j.chetw...@btinternet.com: A plan to enable Forms? Does the SVG WG have a plan to enable Forms? what is the current status regarding sockets and SVG 1.2? regards ~: The popular SVG-native web browsers such as Opera, Mozilla and Webkit have not implemented xforms. HTML5 proposal: http://www.whatwg.org/specs/web-apps/current-work/multipage/forms.html#forms This isn't relevant to SVG, so I've removed them from the list. Opera currently implements several of the new input types, and some of the rest of the forms section. Webkit implements a couple of them. The annotation box on the left of each section will give you an idea of who implements what. ~TJ
Re: [whatwg] Textarea wrap=off
On Fri, Aug 14, 2009 at 10:02 AM, Tab Atkins Jr.jackalm...@gmail.com wrote: I can't load the full spec - it locks my browser - and I can't find any relevant text at http://www.whatwg.org/specs/web-apps/current-work/multipage/forms.html#the-textarea-element. Is there some other place I should be looking in the multipage spec? It's 11.4.15, Rendering, since it's a rendering hint and not a valid textarea attribute: http://www.whatwg.org/specs/web-apps/current-work/multipage/the-xhtml-syntax.html#the-textarea-element-0 Firefox doesn't seem to load the single-page version acceptably for me. Chrome is fairly slow -- especially if I accidentally do something that triggers reload of the page -- but mostly usable. If I want something that's really responsive, I resort to wget | less -- and searching through the whole text for a string once it's loaded into memory still takes a large fraction of a second.
Re: [whatwg] Textarea wrap=off
On Fri, Aug 14, 2009 at 9:09 AM, Aryeh Gregorsimetrical+...@gmail.com wrote: On Fri, Aug 14, 2009 at 10:02 AM, Tab Atkins Jr.jackalm...@gmail.com wrote: I can't load the full spec - it locks my browser - and I can't find any relevant text at http://www.whatwg.org/specs/web-apps/current-work/multipage/forms.html#the-textarea-element. Is there some other place I should be looking in the multipage spec? It's 11.4.15, Rendering, since it's a rendering hint and not a valid textarea attribute: http://www.whatwg.org/specs/web-apps/current-work/multipage/the-xhtml-syntax.html#the-textarea-element-0 Awesome, thanks guys. That was non-obvious to me. Firefox doesn't seem to load the single-page version acceptably for me. Chrome is fairly slow -- especially if I accidentally do something that triggers reload of the page -- but mostly usable. If I want something that's really responsive, I resort to wget | less -- and searching through the whole text for a string once it's loaded into memory still takes a large fraction of a second. Yeah, FF is the one I'm having trouble with. I can get it to *barely* load, but then I see 1-2 second delays in scrolling. Of course, I'm stuck on 3.0.12 since 3.5 auto-crashes on load on my work computer. ;_; ~TJ
Re: [whatwg] Alt attribute for video and audio
On Fri, Aug 14, 2009 at 3:09 PM, Henri Sivonenhsivo...@iki.fi wrote: On Aug 14, 2009, at 16:06, Silvia Pfeiffer wrote: There is only one thing I can think about that an alt attribute could provide that nothing else does: as a blind user tabs onto a video element, the alt attribute's content could be read out and briefly describe what is visible in the poster image - or alternatively give a brief summary of the video. This is useful for all those cases where no surrounding text is given for whatever reason. Where a surrounding text is given, such as the video title and description, such text is likely not necessary. I believe aria-label addresses this. Yes, I think that covers it. This also covers the most important, but apparently always ignored case: authors who don't have time for accessibility. A significant portion of web authors will not provide subtitles for every published video. Nor will they provide links to a transcript. Even if they care about accessibility, it's just not economically viable to do it. The best you can hope for is a sentence or two explaining what the video does. This also covers other non-text elements: iframe, embed, object. The only thing left is ARIA's integration with HTML. Have you had success with your draft? http://hsivonen.iki.fi/aria-html5/ I see you only had one reply to your first announcement. Will the remaining ARIA attributes be an explicit part of HTML? Will the aria- prefix be removed? Remco
Re: [whatwg] HTML 5 Script Tag
No elements in text/html can be self-closing. Except of course for the following: area base br col command embed hr input img link meta param and source And these obsolete elements still supported by legacy UAs: basefont bgsound and wbr Generally speaking I think we should avoid making the platform have too many redundant features, however illogical some of them might be. article == section == div aside == details == figure i == em b == strong span == mark caption == legend (if it was allowed inside table) I agree that some people expect this. I don't think that making it work with exactly one element and dependent on the presence of an attribute is the way to improve this situation, however. It already works this way. The browser ignores everything inside the script tag the moment you put these three letters inside the brackets: src -- James W Cready
Re: [whatwg] HTML 5 Script Tag
On Fri, Aug 14, 2009 at 10:48 AM, Cready, Jamesjcre...@rtcrm.com wrote: No elements in text/html can be self-closing. Except of course for the following: area base br col command embed hr input img link meta param and source And these obsolete elements still supported by legacy UAs: basefont bgsound and wbr None of those are self-closing in the HTML syntax; they're all null elements. They *have* no end tag, never did, and have no need to close anything at all. I agree that some people expect this. I don't think that making it work with exactly one element and dependent on the presence of an attribute is the way to improve this situation, however. It already works this way. The browser ignores everything inside the script tag the moment you put these three letters inside the brackets: src And that wouldn't be the situation settled on if the script element were being added today. But it is how it is, and you can't change legacy pages. ~TJ
Re: [whatwg] Textarea wrap=off
On Fri, Aug 14, 2009 at 9:23 AM, Tab Atkins Jr.jackalm...@gmail.com wrote: Of course, I'm stuck on 3.0.12 since 3.5 auto-crashes on load on my work computer. ;_; For everyone concerned, it's been fixed now. It was a rogue DLL. Thanks to LDB for pointing me to the correct KB article, and thanks to Shaver and Lachy for offering support and advice as well! Now to see if the same issue is plaguing my friend... ~TJ
Re: [whatwg] HTML 5 Script Tag
No elements in text/html can be self-closing. Except of course for the following: area base br col command embed hr input img link meta param and source And these obsolete elements still supported by legacy UAs: basefont bgsound and wbr Except, of course, that these are not self closing. Regards, Rimantas -- http://rimantas.com/
Re: [whatwg] Feature requests in WebSocket (Was: BWTP for WebSocket transfer protocol)
On Fri, Aug 14, 2009 at 3:45 AM, Ian Hickson i...@hixie.ch wrote: On Fri, 7 Aug 2009, Jonas Sicking wrote: I agree that these are very interesting features. Especially connection multiplexing is something that I think is a good idea, for the reasons you've mentioned elsewhere in this thread (multiple widgets on the same page). How do you envisage multiplexing working? It's not clear to me what we could do that would be easier to handle than just having the script manually do the multiplexing at the application layer. I could say the same thing about redirects and authentication. I think all of these features can be worked around , so they shouldn't be in v1, but they should be the first things considered for v2. That said What would the API look like? It seems like it could be done transparently to the web developer. If you open 2 sockets to the same server, the UA could just open another channel on the same connection. What would the wire level look like? It could be as simple as this: An extra byte or two at the beginning of every message that says which channel is transmitting. A way to send control messages, two of which would be used to open and close channels.
[whatwg] SharedWorkers and the name parameter
Currently, SharedWorkers accept both a url parameter and a name parameter - the purpose is to let pages run multiple SharedWorkers using the same script resource without having to load separate resources from the server. Per section 4.8.3 of the SharedWorkers spec, if a page loads a shared worker with a url and name, it is illegal for any other page under the same origin to load a worker with the same name but a different URL -- the SharedWorker name becomes essentially a shared global namespace across all pages in a single origin. This causes problems when you have multiple pages under the same domain (ala geocities.com) - the pages all need to coordinate in their use of name. Additionally, a typo in one page (i.e. invoking SharedWorker(mypagescript?, name) instead of SharedWorker(mypagescript, name) will keep all subsequent pages in that domain from loading a worker under that name so long as the original page resides in the page cache. I'd* like to propose changing the spec so that the name is not associated with the origin, but instead with the URL itself. So if a page wanted to have multiple instances of a SharedWorker using the same URL, it could do this: new SharedWorker(url.js, name); new SharedWorker(url.js, name2); Nothing would prevent a page from also doing this, however: new SharedWorker(other_url.js, name); So step 4 in section 4.8.3 would change from this: If there exists a SharedWorkerGlobalScope #sharedworkerglobalscope object whose closing #dom-workerglobalscope-closing flag is false, whose name attribute is exactly equal to the name argument, and whose location#dom-workerglobalscope-location attribute represents an absolute URL that has the same origin as the resulting absolute URL, then run these substeps: to this: If there exists a SharedWorkerGlobalScope #sharedworkerglobalscope object whose closing #dom-workerglobalscope-closing flag is false, whose name attribute is exactly equal to the name argument, and whose location#dom-workerglobalscope-location attribute represents an absolute URL that exactly matches the resulting absolute URL, then run these substeps: The downside of this change is pages might inadvertently create a second instance of a SharedWorker if they inadvertently use the wrong URL. It seems like this is an acceptable tradeoff given the problems described above. What do people think of this? -atw * Thanks to Darin Adler for suggesting this solution
Re: [whatwg] .tags on HTMLCollections
On Fri, Aug 14, 2009 at 3:35 AM, Ian Hicksoni...@hixie.ch wrote: On Fri, 7 Aug 2009, Jonas Sicking wrote: I haven't removed HTMLCollection.tags yet, since it appears to be implemented by most browsers. If we can get Opera and WebKit to remove support, then I'll remove it from the spec. Given that we have some data indicating that .tags() is not needed for web compatibility (Firefox doesn't support it and has received no requests for it, or bugs indicating sites needing it), and so far only weak data indicating it is needed (UAs support it, but not clear why), why not leave it out of the spec for now? UAs are always free to continue supporting it if they so please. I have very little desire to add support for anything to gecko just in case, without any data indicating anyone would use it, much less needs it. HTMLCollection.tags is specified for the same reason keygen is -- a majority of browsers support it. I'd like to remove it, though. I encourage you to convince other browser vendors to drop support for this feature. The difference is two-fold. First of all I thought we had indication that sites actually relied on keygen, i.e. we have some sort of data on that it's actually a used feature. Is that not the case? Second, .tags() arguably better belongs in a DOM-Core spec. So we could remove it for the same reason that HTML doesn't specify CSS quirks-mode behavior, that it's something better left to other specs. Why doesn't HTML for example define Element.children? That is also supported by a majority of other browsers (the exact same set of browsers even). In general, I suspect if the only criteria to having something in the spec was supported by a majority of browsers and not currently defined by any other spec, then I strongly suspect the spec is missing a lot of features. Put it another way, what is the downside of removing it from the spec? / Jonas
Re: [whatwg] Removing versioning from HTML
On Fri, 14 Aug 2009 12:01:31 +0100, Ian Hickson i...@hixie.ch wrote: On Sun, 9 Aug 2009, Aaron Boodman wrote: I frequently see the comment on this list and in other forums that something is too late for HTML5, and therefore discussion should be deferred. I would like to propose that we get rid of the concepts of versions altogether from HTML. In reality, nobody supports all of HTML5. Each vendor supports a slightly different subset of the spec, along with some features that are outside the spec. This seems OK to me. Instead of insisting that a particular version of HTML is a monolithic unit that must be implemented in its entirety, we could have each feature (or logical group of features) spun off into its own small spec. We're already doing this a bit with things like Web Workers, but I don't see why we don't just do it for everything. Just as they do now, vendors would decide at the end of the day which features they would implement and which they would not. But we should never have to say that the spec is too big. If somebody is interested in exploring an idea, they should be able to just start doing that. I agree in principle. I wholeheartedly agree with all the reasoning, but there are issues. From an implementor's point of view it is much harder to implement and keep up with a mutating specification. During implementation a stable spec is preferred. So versioning will allow an implementor to decide to implement the latest stable version of some spec, while work proceeds on a newer one. And when I refer mutating specification I'm not referring to the whole html5 spec, but each separate component, like web storage, web workers, video, etc... Currently, because specs are being edited and might take a while to get to CR, we have different implementors implement different parts of the specifications, and then meanwhile the specification mutates and implementors have to waste time updating their implementation which could have been right from the start. I understand that implementation feedback is necessary, but this is not very optimal. After a spec gets to CR it can't just mutate out of thin air, hence forking it into a new version is the way to go. Example: Gecko, Webkit and IE have localStorage, but the spec changed a few days ago to allow structured storage.
Re: [whatwg] Removing versioning from HTML
Hi, Versioning is a larger topic recently: http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0655.html http://lists.w3.org/Archives/Public/www-tag/2009Aug/0027.html http://lists.w3.org/Archives/Public/www-tag/2009Aug/0029.html I wonder whether there could be a consistent pattern through all the specs from WHATWG and W3C to handle versions. The issues and use cases are very similar if not the same everywhere. Thanks. Kind regards, Marcin From: whatwg-boun...@lists.whatwg.org [whatwg-boun...@lists.whatwg.org] On Behalf Of João Eiras [jo...@opera.com] Sent: Friday, August 14, 2009 9:35 PM To: WHATWG Subject: Re: [whatwg] Removing versioning from HTML On Fri, 14 Aug 2009 12:01:31 +0100, Ian Hickson i...@hixie.ch wrote: On Sun, 9 Aug 2009, Aaron Boodman wrote: I frequently see the comment on this list and in other forums that something is too late for HTML5, and therefore discussion should be deferred. I would like to propose that we get rid of the concepts of versions altogether from HTML. In reality, nobody supports all of HTML5. Each vendor supports a slightly different subset of the spec, along with some features that are outside the spec. This seems OK to me. Instead of insisting that a particular version of HTML is a monolithic unit that must be implemented in its entirety, we could have each feature (or logical group of features) spun off into its own small spec. We're already doing this a bit with things like Web Workers, but I don't see why we don't just do it for everything. Just as they do now, vendors would decide at the end of the day which features they would implement and which they would not. But we should never have to say that the spec is too big. If somebody is interested in exploring an idea, they should be able to just start doing that. I agree in principle. I wholeheartedly agree with all the reasoning, but there are issues. From an implementor's point of view it is much harder to implement and keep up with a mutating specification. During implementation a stable spec is preferred. So versioning will allow an implementor to decide to implement the latest stable version of some spec, while work proceeds on a newer one. And when I refer mutating specification I'm not referring to the whole html5 spec, but each separate component, like web storage, web workers, video, etc... Currently, because specs are being edited and might take a while to get to CR, we have different implementors implement different parts of the specifications, and then meanwhile the specification mutates and implementors have to waste time updating their implementation which could have been right from the start. I understand that implementation feedback is necessary, but this is not very optimal. After a spec gets to CR it can't just mutate out of thin air, hence forking it into a new version is the way to go. Example: Gecko, Webkit and IE have localStorage, but the spec changed a few days ago to allow structured storage. Access Systems Germany GmbH Essener Strasse 5 | D-46047 Oberhausen HRB 13548 Amtsgericht Duisburg Geschaeftsfuehrer: Michel Piquemal, Tomonori Watanabe, Yusuke Kanda www.access-company.com CONFIDENTIALITY NOTICE This e-mail and any attachments hereto may contain information that is privileged or confidential, and is intended for use only by the individual or entity to which it is addressed. Any disclosure, copying or distribution of the information by anyone else is strictly prohibited. If you have received this document in error, please notify us promptly by responding to this e-mail. Thank you.
Re: [whatwg] Removing versioning from HTML
On Fri, Aug 14, 2009 at 12:35 PM, João Eiras jo...@opera.com wrote: From an implementor's point of view it is much harder to implement and keep up with a mutating specification. During implementation a stable spec is preferred. As a browser implementer, I have certainly not found the dynamic nature of the spec to be a problem. In fact the opposite is true: problems in the spec can be fixed quickly when they're raised. Currently, because specs are being edited and might take a while to get to CR, we have different implementors implement different parts of the specifications, and then meanwhile the specification mutates and implementors have to waste time updating their implementation which could have been right from the start. I understand that implementation feedback is necessary, but this is not very optimal. As opposed to if we froze versions, which would mean implementers would implement part of the old specification, and meanwhile the new spec has changed it. In other words, I don't see how versioning reduces this problem at all in practice. Furthermore, you seem to be proposing versioning well in advance of CR status, since you say it will take time to reach CR. What is the metric by which we'd decide to freeze a spec, then? PK
Re: [whatwg] A plan to enable Forms?
Tab, your response is off-topic, if it's not related to forms in SVG ie off-topic for this email, rather than the lists.. cheers ~: On 14 Aug 2009, at 15:07, Tab Atkins Jr. wrote: 2009/8/14 ~:'' ありがとうございました j.chetw...@btinternet.com: A plan to enable Forms? Does the SVG WG have a plan to enable Forms? what is the current status regarding sockets and SVG 1.2? regards ~: The popular SVG-native web browsers such as Opera, Mozilla and Webkit have not implemented xforms. HTML5 proposal: http://www.whatwg.org/specs/web-apps/current-work/multipage/forms.html#forms This isn't relevant to SVG, so I've removed them from the list. Opera currently implements several of the new input types, and some of the rest of the forms section. Webkit implements a couple of them. The annotation box on the left of each section will give you an idea of who implements what. ~TJ
Re: [whatwg] Feature requests in WebSocket (Was: BWTP for WebSocket transfer protocol)
On Fri, Aug 14, 2009 at 3:45 AM, Ian Hicksoni...@hixie.ch wrote: On Fri, 7 Aug 2009, Jonas Sicking wrote: I agree that these are very interesting features. Especially connection multiplexing is something that I think is a good idea, for the reasons you've mentioned elsewhere in this thread (multiple widgets on the same page). How do you envisage multiplexing working? It's not clear to me what we could do that would be easier to handle than just having the script manually do the multiplexing at the application layer. What would the API look like? What would the wire level look like? Some advantages of putting it in the protocol: 1. More likely the UA implementors will make the effort of implementing multiplexing (and doing so correctly), than that website authors will. 2. There are much fewer UA implementors than website authors, so the level of code reuse would be much higher. 3. Scripts in different tabs, and even from different sites, that connect to the same server would be able to share TCP/IP channel. 4. If websocket is successful, websocket proxies will likely show up, allowing multiplexing across different users that share the same proxy. Looking at how much HTTP benefits from multiplexing in the form of connection: keep-alive, and how much more it would have benefitted from good multiplexing in the form of pipelineing, I'd be very surprised if websocket wouldn't benefit from it as well. But I agree that we need a concrete proposal before we can usefully get further in the discussion. But even compression is nice if it was possible. It's not clear to me that compression would be particularly useful for short packets. Indeed, short packets probably won't benefit from compression. Likely any frame that fits in a single IP packet probably stands little to gain from getting compressed. Except in the case when it allows fitting additional frames into the same IP packet. I agree that it could be useful for bigger packets; maybe when we support binary frames we should say that the frames are compressed? Well, I'm not sure all binary frames needs to be compressed. For example transmitting a jpeg over websocket should be done in a binary frame, but would unlikely benefit from being compressed. One possible solution is to keep the 0x80 frame type as a raw binary frame, 0x81 is a compressed frame, with the following contents: frame-type name-of-encoding 00 encoded-contents frame-type is a single byte indicating which frame-type is encoded. name-of-encoding is a US-ASCII encoded string indicating the name of the encoding, this could be 'gzip' for gzipped compression, etc. 00 is the single byte with value 0 encoded-contents is the actual contents, ending at the end of the frame. Once the frame has been decoded, the implementation treats the frame as if a frame with the given frame-type was received, with the contents being the decoded contents. There's a few things that needs to be defined. Such as: Is it allowed to put an 0x81 frame inside a 0x81 frame? What to do if the frame-type is 0x7f or lower, but the decoded contents contains a 0xff? What to do if the decoding produces an error? What to do if name-of-encoding is not recognized? What to do if no 00 is found? / Jonas
Re: [whatwg] Codecs for audio and video
I'm sorry - we cannot say anything about our plans at this point. Thanks, Jeremy On Mon, Aug 10, 2009 at 5:30 PM, Nils Dagsson Moskoppnils-dagsson-mosk...@dieweltistgarnichtso.net wrote: Am Dienstag, den 11.08.2009, 00:44 +0100 schrieb Sam Kuper: In recent news, Google may be about to open source On2 codecs, perhaps creating a route out of the HTML 5 video codec deadlock: http://www.theregister.co.uk/2009/08/06/google_vp6_open_source/ At this point, this seems to be pure speculation. Maybe Google representatives can chime in on this issue ? -- Nils Dagsson Moskopp http://dieweltistgarnichtso.net
Re: [whatwg] HTML 5 Script Tag
On Fri, Aug 14, 2009 at 11:48 AM, Cready, Jamesjcre...@rtcrm.com wrote: Except of course for the following: area base br col command embed hr input img link meta param and source And these obsolete elements still supported by legacy UAs: basefont bgsound and wbr Those are just unclosed, they're not self-closing. If you use the / syntax it's not closing the tag, it's just ignored. If this proposal were accepted, script would become the only tag in text/html where foo / is treated any differently from foo. article == section == div aside == details == figure i == em b == strong span == mark caption == legend (if it was allowed inside table) Those are not redundant. Each of the features you mention serves a different purpose from the one(s) you equate it to, and is defined to have different semantics. The proposal that Ian was responding to is to create a new link rel=script href=foo construct that would be defined to be *identical* to script src=foo/script, or style src=foo/style defined to be *identical* to link rel=stylesheet href=foo. It already works this way. The browser ignores everything inside the script tag the moment you put these three letters inside the brackets: src It does not work as desired. Browsers currently parse any content from the opening script up to the next /script as being inside the script element (and do nothing with it except stick it in the DOM). The desired behavior is that the browser close the tag immediately and treat any subsequent content as being outside the script.
Re: [whatwg] Redirects and draft-hixie-thewebsocketprotocol
On Sat, 8 Aug 2009, Adam Barth wrote: In fact, the situation is worse than the above because the websocket protocol supports cookies. Instead of relying on a firewall and IP authentication, the victim server could be on the public Internet and be relying upon cookie authentication. I think there are a number of ways of resolving this issue: 1) We could use Sec-From instead of Origin because Sec-From implicates the full redirect chain instead of just the origin that initiated the request. On IRC, Ian said he doesn't like this choice because servers might not validate this header properly. My concern here is that to confirm the server is checking Sec-From we'd want the server to include some sort of response, and I'm not really sure what that would be. Maybe just WebSocket-Sec-From: ..., where it contains the same value as Sec-From, but Sec-From only gets included on redirects? 2) Instead of handling the redirect inside the websocket protocol, we can report the redirect back to the web site making the request (in this case example.com). Then the trustworthy web site would then have the option of following or not following the redirect. If we did this, we would have to ensure that the redirecting server understands the websocket protocol (probably by requiring it to send WebSocket-Origin or some such) to avoid leaking the targets of already-existing redirects. Also, it's unclear on what basis the web site would decide whether to follow the redirect. 3) We could restrict redirects to the same origin. This has the disadvantage of not covering the full use case of redirects. 4) We could remove support for redirects. On Sun, 9 Aug 2009, Jeremy Orlow wrote: I feel like redirects add unnecessary complexity. We're already asking application developers to handle ACKing, keep alives, multi-plexing, connection limiting, authentication, etc themselves. To me, it doesn't seem like much of an additional burden to ask them to handle redirects. And by keeping the spec simple, I think we'll increase the chances of quick adoption by UAs, which will speed up the adoption by web apps, which will give us feedback on what features web developers actually want much quicker. The use case for redirects is if Google (say) provides a WebSocket service that lots of sites around the Web uses, and then Google wants to move the service to another host, without transparent redirects, all the pages using the service will break until they can be updated, whereas with redirects, we can just redirect and be done with it. I've removed redirect support for now, but I think we should have support for it at some point. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Minor presentational issue in draft-hixie-thewebsocketprotocol
On Sat, 8 Aug 2009, Adam Barth wrote: [[ Send the string WebSocket-Origin followed by a U+003A COLON (:) followed by the ASCII serialization of the origin from which the server is willing to accept connections, followed by a CRLF pair (0x0d 0x0a). For instance: WebSocket-Origin: http://example.com ]] The prose above is missing the space after the : that is present in the example. The next chunk of text, for WebSocket-Location, has the same issue. Fixed, thanks. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Redirects and draft-hixie-thewebsocketprotocol
On Fri, Aug 14, 2009 at 4:06 PM, Ian Hickson i...@hixie.ch wrote: On Sun, 9 Aug 2009, Jeremy Orlow wrote: I feel like redirects add unnecessary complexity. We're already asking application developers to handle ACKing, keep alives, multi-plexing, connection limiting, authentication, etc themselves. To me, it doesn't seem like much of an additional burden to ask them to handle redirects. And by keeping the spec simple, I think we'll increase the chances of quick adoption by UAs, which will speed up the adoption by web apps, which will give us feedback on what features web developers actually want much quicker. The use case for redirects is if Google (say) provides a WebSocket service that lots of sites around the Web uses, and then Google wants to move the service to another host, without transparent redirects, all the pages using the service will break until they can be updated, whereas with redirects, we can just redirect and be done with it. Or the protocol Google (or anyone else) creates to transport the data can support this. If an application has to deal with ACKs, it's only a small jump to insist it also handles the initial negotiation (authentication, redirects, etc) itself. This is why I think it's better to not have anything at all rather than have something that's half-baked. I whole-heartedly agree that these features should be in v2.
Re: [whatwg] Typo in 1.9 - attributed
On Mon, 10 Aug 2009, Chris Cressman wrote: From section 1.9: Each element in the DOM tree is represented by an object, and these objects have APIs so that they can be manipulated. For instance, a link (e.g. the a element in the tree above) can have its href attributed changed in several ways: _attributed_ instead of _attribute_ Thanks, fixed. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] .tags on HTMLCollections
On Fri, Aug 14, 2009 at 12:02 PM, Jonas Sickingjo...@sicking.cc wrote: On Fri, Aug 14, 2009 at 3:35 AM, Ian Hicksoni...@hixie.ch wrote: On Fri, 7 Aug 2009, Jonas Sicking wrote: I haven't removed HTMLCollection.tags yet, since it appears to be implemented by most browsers. If we can get Opera and WebKit to remove support, then I'll remove it from the spec. Given that we have some data indicating that .tags() is not needed for web compatibility (Firefox doesn't support it and has received no requests for it, or bugs indicating sites needing it), and so far only weak data indicating it is needed (UAs support it, but not clear why), why not leave it out of the spec for now? UAs are always free to continue supporting it if they so please. I have very little desire to add support for anything to gecko just in case, without any data indicating anyone would use it, much less needs it. HTMLCollection.tags is specified for the same reason keygen is -- a majority of browsers support it. I'd like to remove it, though. I encourage you to convince other browser vendors to drop support for this feature. The difference is two-fold. First of all I thought we had indication that sites actually relied on keygen, i.e. we have some sort of data on that it's actually a used feature. Is that not the case? Second, .tags() arguably better belongs in a DOM-Core spec. So we could remove it for the same reason that HTML doesn't specify CSS quirks-mode behavior, that it's something better left to other specs. The DOM core has getElementsByTagName. Kind of a long name, but the behavior is standard and though buggy in IE = 8, is more consistent. What exactly does .tags return? NodeList, StaticNodeList, TagsArray? What about .tags(*)? Why doesn't HTML for example define Element.children? That is also supported by a majority of other browsers (the exact same set of browsers even). Implementing children would be a mistake. This was discussed on comp.lang.javascript. Recently, in fact: http://groups.google.com/group/comp.lang.javascript/browse_thread/thread/18beac3cd1e06c29 To save the trouble of reading that thread, MSIE's children returns a list of DHTML Objects. Those objects include comment nodes. The test case in the linked thread shows that. Juriy followed up to post about Divergent behavior in Safari 2 and Richard mentioned divergent behavior in IceBrowser, and the example I posted demonstrates (with explanation) the problem with children and getElementsByTagName in IE = IE8. Any code that wanted to use .children would need to do more feature testing than it would be worth. If a feature is to be created to get child Elements, it should have a new name. AISB, childElements, in Jan 2008, | REally, all I want is | nextSiblingElement/previousSiblingElement/childElements properties so I | don't have to have library code or write a for() loop every time i want | to just find the next sibling element. I disagree with the decision to not include those properties. In general, I suspect if the only criteria to having something in the spec was supported by a majority of browsers and not currently defined by any other spec, then I strongly suspect the spec is missing a lot of features. Can you explain the Global Scope Polluter? :-D http://groups.google.com/group/comp.lang.javascript/msg/c46682d862939173 AYCS from that thread, we didn't quite figure out how the Global Scope Polluter works. Would be helpful to have the author or sr for that code, or anyone who understands it and has the time jump in on that and explain a little more. This Global Scope Polluter is an MSIE lets make it easy feature, sort of like callable collections. In retrospect, it seems to have caused more harm than good. Garrett
