Re: [whatwg] Quality Values for Media Source Elements
On Mon, Dec 14, 2009 at 4:08 AM, Silvia Pfeiffer silviapfeiff...@gmail.com wrote: I would almost consider simply using low quality and high quality as quality distinguishers (and maybe medium) and leave the actual choice of encoding to the hosting entity. Right now, may sites provide only two choices for Desktop: SD and HD, plus one for mobile. The device can be separated by the device-width as Eric described. Except it can't—at least, not entirely. Since the size of a video image is the result of multiplying the width and height by its pixel aspect ratio, the pixel count of the video does not necessarily match that of the device playing it back. For instance, on a DVD, both fullscreen and widescreen movies are stored at the same resolutions, but with different pixel aspect ratios (i.e., the shape of the pixels are not necessarily a 1:1 square, as on computers). According to the D1 DV standards, fullscreen pixels have a width-to-height ratio of 4320/4739 (~0.9). So a 720x480 fullscreen image on a square-pixel device would have to be displayed at ~656x480 pixels to retain its proper aspect ratio. By the same standards, widescreen pixels are 5760/4739 (~1.2), so a 720x480 widescreen image would have to be displayed at ~875x480 pixels. Therefore, screen and (min-device-width: 720px) would not work for all 480i/p content. Either the PAR would have to be read from the file itself—the storage of which differs from format to format—or the author would have to specify it. Which is also problematic since not everyone knows what PARs are, and even when they do, not everyone uses the same pixel shape definitions: MPEG-4 says widescreen pixels are 40/33, which is *close* to the D1/DV definition but not quite: this results in a ~873x480 square-pixel image. And due to rounding, there is also a conventional habit of specifying a PAR of 6/5 (exactly 1.2), resulting in 864x480. Apple on the other hand defines it as 32/27, resulting in ~853x480. So even with the same source content, you may be looking at as many as 4 different rendered sizes depending on the device manufacturer. So if you specify the PAR according to one standard, a device built according to another may not recognize it as playable material, even though it is fully capable of playing it back. Though this COULD potentially be solved by taking aspect ratio error into account when processing the media query. So say for any specified PAR that doesn't match a PAR the device can support exactly, if the ratios turned out to be the same rounded to a certain decimal point, that would count as a match and the device would simply render it according to its standards. This *somewhat* defeats the point of specifying PARs exactly, but at least it'd be good enough as the difference would be too insignificant for most people to notice. SD and HD - while also changing between aspect ratio - are mostly a choice between lower bandwidth use and higher bandwidth use, which are taken as equivalent to low and high quality by users. Since there will likely be a higher bitrate HD version joining in the future, it will then turn into SD, HD and HD2 - which equates to low, medium, high. Over time, SD will fall aside and leave medium and high. Then, if another higher quality comes in, they can be redefined to low and medium. Thus, keeping these fuzzy specifiers, we stay future-proof and leave the actual choice of what low and high means to the respective hosting site, which will make the format choice according to current standards. I'd prefer giving actual levels (low, medium, and high) rather than a number between 0 and 1, because they make it comparable between hosting sites. If I choose to have low on YouTube, I will likely want low on Dailymotion and Hulu, even if those sites decided to use completely different encoding parameters for their low and high quality versions. I can agree with this proposal as far as quality = data rate is concerned. As for any of the other criteria, they'd have to be addressed differently. On Mon, Dec 14, 2009 at 10:59 AM, Aryeh Gregor simetrical+...@gmail.com wrote: It depends on the application. But in any event, HTML can never possibly do everything JavaScript does, so at some point the answer needs to be use JavaScript. Nor should it. But if you're doing something in JavaScript, there *should* be a functional alternative in plain HTML when it's turned off. That means if you've got an AJAX application, even with JS turned off a user should still be able to interact with the server synchronously. If you had all of your content negotiation in JS, however, there could be no alternative, as the lack of one would have been the reason to use JS in the first place. I don't follow. If authors *were* willing to use content negotiation, to the contrary, there would be no need for source. You could just write video src=foo/video in your markup, and configure your server to serve foo.mp4 or foo.ogg depending on
Re: [whatwg] Inconsistent behavior for empty-string URLs
On Mon, 14 Dec 2009 20:08:40 +0100, Nicholas Zakas nza...@yahoo-inc.com wrote: It seems that thusfar, Jonas from Mozilla is open to this change. Is there anyone from Opera or WebKit that would like to chime in either in favor or opposition? It appears that Opera already does this (though I haven't tested SVG or CSS). I think it's ok, but I'd like it specced. :-) -- Simon Pieters Opera Software
Re: [whatwg] Inconsistent behavior for empty-string URLs
On Dec 14, 2009, at 11:08 AM, Nicholas Zakas wrote: It seems that thusfar, Jonas from Mozilla is open to this change. Is there anyone from Opera or WebKit that would like to chime in either in favor or opposition? I'd love to issue fewer useless loads, if sites don't actually rely on it. Does anyone have data on what, if any, compatibility impact this has? I can't imagine loading the base URL to be terribly useful in most cases, but perhaps there are wacky sites that do indeed rely on it. Regards, Maciej Thanks. -Nicholas __ Commander Lock: Damnit Morpheus, not everyone believes what you believe! Morpheus: My beliefs do not require them to. -Original Message- From: whatwg-boun...@lists.whatwg.org [mailto:whatwg-boun...@lists.whatwg.org] On Behalf Of Nicholas Zakas Sent: Friday, December 11, 2009 10:15 AM To: Simon Pieters; Anne van Kesteren; Aryeh Gregor Cc: whatwg@lists.whatwg.org Subject: Re: [whatwg] Inconsistent behavior for empty-string URLs I agree, automatic downloads are the real issue. a href= is fine because a user must initiate the action (and thus generate a real pageview). I'd think that the behavior should be the same in CSS and SVG for resources that are automatically downloaded. -Nicholas __ Commander Lock: Damnit Morpheus, not everyone believes what you believe! Morpheus: My beliefs do not require them to. -Original Message- From: Simon Pieters [mailto:sim...@opera.com] Sent: Thursday, December 10, 2009 10:57 AM To: Nicholas Zakas; Anne van Kesteren; Aryeh Gregor Cc: whatwg@lists.whatwg.org Subject: Re: [whatwg] Inconsistent behavior for empty-string URLs On Thu, 10 Dec 2009 19:22:43 +0100, Nicholas Zakas nza...@yahoo-inc.com wrote: I'd be happy to make the compromise that this applies to markup but not to JavaScript APIs. I think it shouldn't apply to markup that doesn't download things automatically; in particular a href= should work. What about URLs in CSS and SVG? -- Simon Pieters Opera Software
Re: [whatwg] Inconsistent behavior for empty-string URLs
If this change is made, what is the correct (explicit) way to refer to the current URL? . ? In terms of web compat, I do recall a web picture gallery package that returned a html information page with a self reference to show the actual image. -- James 2009/12/15 Maciej Stachowiak m...@apple.com On Dec 14, 2009, at 11:08 AM, Nicholas Zakas wrote: It seems that thusfar, Jonas from Mozilla is open to this change. Is there anyone from Opera or WebKit that would like to chime in either in favor or opposition? I'd love to issue fewer useless loads, if sites don't actually rely on it. Does anyone have data on what, if any, compatibility impact this has? I can't imagine loading the base URL to be terribly useful in most cases, but perhaps there are wacky sites that do indeed rely on it. Regards, Maciej Thanks. -Nicholas __ Commander Lock: Damnit Morpheus, not everyone believes what you believe! Morpheus: My beliefs do not require them to. -Original Message- From: whatwg-boun...@lists.whatwg.org [mailto:whatwg-boun...@lists.whatwg.org] On Behalf Of Nicholas Zakas Sent: Friday, December 11, 2009 10:15 AM To: Simon Pieters; Anne van Kesteren; Aryeh Gregor Cc: whatwg@lists.whatwg.org Subject: Re: [whatwg] Inconsistent behavior for empty-string URLs I agree, automatic downloads are the real issue. a href= is fine because a user must initiate the action (and thus generate a real pageview). I'd think that the behavior should be the same in CSS and SVG for resources that are automatically downloaded. -Nicholas __ Commander Lock: Damnit Morpheus, not everyone believes what you believe! Morpheus: My beliefs do not require them to. -Original Message- From: Simon Pieters [mailto:sim...@opera.com] Sent: Thursday, December 10, 2009 10:57 AM To: Nicholas Zakas; Anne van Kesteren; Aryeh Gregor Cc: whatwg@lists.whatwg.org Subject: Re: [whatwg] Inconsistent behavior for empty-string URLs On Thu, 10 Dec 2009 19:22:43 +0100, Nicholas Zakas nza...@yahoo-inc.com wrote: I'd be happy to make the compromise that this applies to markup but not to JavaScript APIs. I think it shouldn't apply to markup that doesn't download things automatically; in particular a href= should work. What about URLs in CSS and SVG? -- Simon Pieters Opera Software
Re: [whatwg] Quality Values for Media Source Elements
On Tue, Dec 15, 2009 at 3:17 AM, Hugh Guiney hugh.gui...@gmail.com wrote: Nor should it. But if you're doing something in JavaScript, there *should* be a functional alternative in plain HTML when it's turned off. Functional, sure, except where that's impossible (e.g., a client-side computer game) or you have good reason not to care (e.g., intranet app where you can require JS to be on). It doesn't have to provide all the same features, though. In general that's impossible, which is why we have script to start with. I don't know that nobody *wants* to do that; I think most of them simply don't know how. The ones who know how, or could easily find out, still overwhelmingly don't want to. I don't think it's a square wheel. A square wheel wouldn't work. HTTP CN works. The fact that people are willing to do something in HTML, but are unwilling to do the very same thing in HTTP, seems to suggest a lack of understanding of HTTP and/or its capabilities. A square wheel works, as long as you're willing to do a lot more work. HTTP content negotiation has the following problems compared to an HTML-based solution: * Authors already know how to edit HTML, since they need to for everything else. Changing HTTP headers requires them to also know how to configure their web server, or use a scripting language (which is harder to learn and much less performant than static resources). This makes it automatically harder to learn, which is bad. * Every web server is configured differently. There is no standard for configuring your server to do content negotiation (that I'm aware of). * Many users (e.g., on some shared hosts) don't have the ability to reconfigure their web server, or at least not easily. * Some web servers (e.g., lighttpd last I checked) require that the whole web server be restarted for any config change. * A solution in HTML will continue to work if you just copy the entire directory to a new server. The same is not reliably true of anything that relies on web server configuration. People avoid it for excellent reason. This is a nice interim solution, but it also forces the user to download a resource which may not necessarily be the most appropriate version for them. Only if you use autobuffer, which you don't have to.
Re: [whatwg] Inconsistent behavior for empty-string URLs
On Tue, Dec 15, 2009 at 6:16 AM, James May wha...@fowlsmurf.net wrote: If this change is made, what is the correct (explicit) way to refer to the current URL? . ? No, that will return the file in the current directory named .. This might be the current directory itself. You would have to say foo.html or such. This shouldn't be a big deal, given how crazy you'd have to be to use the same URL for an HTML file and an image (or whatever). In terms of web compat, I do recall a web picture gallery package that returned a html information page with a self reference to show the actual image. How did that work? It used a script that sniffed referers or something crazy like that?
Re: [whatwg] Inconsistent behavior for empty-string URLs
On Tue, Dec 15, 2009 at 6:55 AM, Aryeh Gregor simetrical+...@gmail.com wrote: On Tue, Dec 15, 2009 at 6:16 AM, James May wha...@fowlsmurf.net wrote: If this change is made, what is the correct (explicit) way to refer to the current URL? . ? No, that will return the file in the current directory named .. This might be the current directory itself. You would have to say foo.html or such. This shouldn't be a big deal, given how crazy you'd have to be to use the same URL for an HTML file and an image (or whatever). I think # should work as well. / Jonas
Re: [whatwg] Inconsistent behavior for empty-string URLs
On Tue, Dec 15, 2009 at 1:44 AM, Maciej Stachowiak m...@apple.com wrote:
Does anyone have data on what, if any, compatibility impact this has? I
can't imagine loading the base URL to be terribly useful in most cases, but
perhaps there are wacky sites that do indeed rely on it.
Given that opera has this somewhat deployed, would be interesting to
hear if they have had any compatibility issues.
The one place where I've seen this used is inside XSLT stylesheets,
where i've seen something like:
xsl:value-of select=document('')/foo/bar
to read data out of the stylesheet document.
/ Jonas
Re: [whatwg] Inconsistent behavior for empty-string URLs
On Tue, Dec 15, 2009 at 12:33 PM, Jonas Sicking jo...@sicking.cc wrote: I think # should work as well. Good point.
Re: [whatwg] Inconsistent behavior for empty-string URLs
Is it necessary to apply this within XSLT and CSS as well? Or is it
possible to have this be an HTML-only feature? I'd be happy with the
latter.
-Nicholas
__
Commander Lock: Damnit Morpheus, not everyone believes what you
believe!
Morpheus: My beliefs do not require them to.
-Original Message-
From: Jonas Sicking [mailto:jo...@sicking.cc]
Sent: Tuesday, December 15, 2009 9:37 AM
To: Maciej Stachowiak
Cc: Nicholas Zakas; whatwg@lists.whatwg.org; Aryeh Gregor; Simon Pieters
Subject: Re: [whatwg] Inconsistent behavior for empty-string URLs
On Tue, Dec 15, 2009 at 1:44 AM, Maciej Stachowiak m...@apple.com
wrote:
Does anyone have data on what, if any, compatibility impact this has?
I
can't imagine loading the base URL to be terribly useful in most
cases, but
perhaps there are wacky sites that do indeed rely on it.
Given that opera has this somewhat deployed, would be interesting to
hear if they have had any compatibility issues.
The one place where I've seen this used is inside XSLT stylesheets,
where i've seen something like:
xsl:value-of select=document('')/foo/bar
to read data out of the stylesheet document.
/ Jonas
Re: [whatwg] Inconsistent behavior for empty-string URLs
On Tue, Dec 15, 2009 at 11:14 AM, Nicholas Zakas nza...@yahoo-inc.com wrote: Is it necessary to apply this within XSLT and CSS as well? Or is it possible to have this be an HTML-only feature? I'd be happy with the latter. Nothing is required. But we do need a concrete proposal that everyone agrees on. / Jonas
Re: [whatwg] Web API for speech recognition and synthesis
It seems like there is enough interest in speech to start developing experimental implementations. There appear to be two general directions that we could take: - A general microphone API + streaming API + audio tag - Pro: Useful for non-speech recognition / synthesis applications. E.g. audio chat, sound recording. - Pro: Allows JavaScript libraries for third-party network speech services. E.g. an AJAX API for Google's speech services. Web app developers that don't have their own speech servers could use that. - Pro: Consistent recognition / synthesis user experience across user agents in the same web app. - Con: No support for on-device recognition / synthesis, only network services. - Con: Varying recognition / synthesis user experience across different web apps in a single user agent. - Con: Possibly higher overhead because the audio data needs to pass through JavaScript. - Con: Requires dealing with audio encodings, endpointing, buffer sizes etc in the microphone API. - A speech-specific back-end neutral API - Pro: Simple API, basically just two methods: listen() and speak(). - Pro: Can use local recognition / synthesis. - Pro: Consistent recognition / synthesis user experience across different web apps in a single user agent. - Con: Varying recognition / synthesis user experience across user agents in the same web app. - Con: Only works for speech, not general audio. /Bjorn On Sun, Dec 13, 2009 at 6:46 PM, Ian McGraw imcg...@mit.edu wrote: I'm new to this list, but as a speech-scientist and web developer, I wanted to add my 2 cents. Personally, I believe the future of speech recognition is in the cloud. Here are two services which provide Javascript APIs for speech recognition (and TTS) today: http://wami.csail.mit.edu/ http://www.research.att.com/projects/SpeechMashup/index.html Both of these are research systems, and as such they are really just proof-of-concepts. That said, Wami's JSONP-like implementation allows Quizlet.com to use speech recognition today on a relatively large scale, with just a few lines of Javascript code: http://quizlet.com/voicetest/415/?scatter Since there are a lot of Google folks on this list, I recommend you talk to Alex Gruenstein (in your speech group) who was one of the lead developers of WAMI while at MIT. The major limitation we found when building the system was that we had to develop a new audio controller for every client (Java for the desktop, custom browsers for iPhone and Android). It would have been much simpler if browsers came with standard microphone capture and audio streaming capabilities. -Ian On Sun, Dec 13, 2009 at 12:07 PM, Weston Ruter westonru...@gmail.com wrote: I blogged yesterday about this topic (including a text-to-speech demo using HTML5 Audio and Google Translate's TTS service); the more relevant part for this thread: I am really excited at the prospect of text-to-speech being made available on the Web! It's just too bad that fetching MP3s on an remote web service is the only standard way of doing so currently; modern operating systems all have TTS capabilities, so it's a shame that web apps and can't utilize them via client-side scripting. I posted to the WHATWG mailing list about such a Text-To-Speech (TTS) Web API for JavaScript, and I was directed to a recent thread about a Web API for speech recognition and synthesis. Perhaps there is some momentum building here? Having TTS available in the browser would boost accessibility for the seeing-impaired and improve usability for people on-the-go. TTS is just another technology that has traditionally been relegated to desktop applications, but as the open Web advances as the preferred platform for application development, it is an essential service to make available (as with Geolocation API, Device API, etc.). And besides, I want to build TTS applications and my motto is: If it can't be done on the open web, it's not worth doing at all! http://weston.ruter.net/projects/google-tts/ Weston On Fri, Dec 11, 2009 at 1:35 PM, Weston Ruter westonru...@gmail.com wrote: I was just alerted about this thread from my post Text-To-Speech (TTS) Web API for JavaScript at http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-December/024453.html. Amazing how shared ideas like these seem to arise independently at the same time. I have a use-case and an additional requirement, that the time indices be made available for when each word is spoken in the TTS-generated audio: I've been working on a web app which reads text in a web page, highlighting each word as it is read. For this to be possible, a Text-To-Speech API is needed which is able to: (1) generate the speech audio from some text, and (2) include the time indicies for when each of the words in the text is spoken. I foresee that
Re: [whatwg] Web API for speech recognition and synthesis
On Tue, 15 Dec 2009, Bjorn Bringert wrote: - A general microphone API + streaming API + audio tag - Pro: Useful for non-speech recognition / synthesis applications. E.g. audio chat, sound recording. - Pro: Allows JavaScript libraries for third-party network speech services. E.g. an AJAX API for Google's speech services. Web app developers that don't have their own speech servers could use that. - Pro: Consistent recognition / synthesis user experience across user agents in the same web app. - Con: No support for on-device recognition / synthesis, only network services. - Con: Varying recognition / synthesis user experience across different web apps in a single user agent. - Con: Possibly higher overhead because the audio data needs to pass through JavaScript. - Con: Requires dealing with audio encodings, endpointing, buffer sizes etc in the microphone API. FWIW I've started looking at this kind of thing in general (for audio and video -- see device in the spec for the first draft ideas), since it'll be required for other things as well. However, that shouldn't be taken as a sign that the other approach shouldn't also be examined. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Web API for speech recognition and synthesis
Great! As I've said, I'm definitely bias towards this approach. As Bjorn hinted AJAX APIs could be developed with all sorts of interesting features that will never make it down into the browser, e.g. pronunciation assessment, speech therapy, all those lie-detector apps for your phone :-). Still, I think that we're missing the biggest pro: - Pro: Speech recognition technology is data-driven. Improvements in the underlying technology are far more likely to occur with a network driven approach. To be fair, with that, you have to add a con: - Con: Less privacy. -Ian On Tue, Dec 15, 2009 at 3:37 PM, Ian Hickson i...@hixie.ch wrote: On Tue, 15 Dec 2009, Bjorn Bringert wrote: - A general microphone API + streaming API + audio tag - Pro: Useful for non-speech recognition / synthesis applications. E.g. audio chat, sound recording. - Pro: Allows JavaScript libraries for third-party network speech services. E.g. an AJAX API for Google's speech services. Web app developers that don't have their own speech servers could use that. - Pro: Consistent recognition / synthesis user experience across user agents in the same web app. - Con: No support for on-device recognition / synthesis, only network services. - Con: Varying recognition / synthesis user experience across different web apps in a single user agent. - Con: Possibly higher overhead because the audio data needs to pass through JavaScript. - Con: Requires dealing with audio encodings, endpointing, buffer sizes etc in the microphone API. FWIW I've started looking at this kind of thing in general (for audio and video -- see device in the spec for the first draft ideas), since it'll be required for other things as well. However, that shouldn't be taken as a sign that the other approach shouldn't also be examined. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Inconsistent behavior for empty-string URLs
Here's what I would propose: 1. Empty string attributes for HTML elements specifying resources to automatically download are considered invalid and don't cause a request to be sent. Examples: img, link, script, iframe, etc. This would not apply to a href= because it is a user-initiated request. 2. This also applies to manipulation of HTML elements through the DOM, so (new Image()).src= would not result in a request being sent. 3. This does not apply to JavaScript APIs that are unrelated to HTML elements, such as Web Workers, XMLHttpRequest, etc. -Nicholas __ Commander Lock: Damnit Morpheus, not everyone believes what you believe! Morpheus: My beliefs do not require them to. -Original Message- From: Jonas Sicking [mailto:jo...@sicking.cc] Sent: Tuesday, December 15, 2009 11:47 AM To: Nicholas Zakas Cc: Maciej Stachowiak; whatwg@lists.whatwg.org; Aryeh Gregor; Simon Pieters Subject: Re: [whatwg] Inconsistent behavior for empty-string URLs On Tue, Dec 15, 2009 at 11:14 AM, Nicholas Zakas nza...@yahoo-inc.com wrote: Is it necessary to apply this within XSLT and CSS as well? Or is it possible to have this be an HTML-only feature? I'd be happy with the latter. Nothing is required. But we do need a concrete proposal that everyone agrees on. / Jonas
Re: [whatwg] Web API for speech recognition and synthesis
Currently the W3C Device API WG is working on a Capture API which will include microphone capture and audio streaming capabilities. The current draft is at: http://dev.w3.org/2009/dap/camera/ It is pretty rough and still in working progress, so for instance streaming is not there. Thanks Dzung Tran On Sun, Dec 13, 2009 at 6:46 PM, Ian McGraw imcg...@mit.edumailto:imcg...@mit.edu wrote: I'm new to this list, but as a speech-scientist and web developer, I wanted to add my 2 cents. ?Personally, I believe the future of speech recognition is in the cloud. Here are two services which provide Javascript APIs for speech recognition (and TTS) today: http://wami.csail.mit.edu/ http://www.research.att.com/projects/SpeechMashup/index.html Both of these are research systems, and as such they are really just proof-of-concepts. That said, Wami's JSONP-like implementation allows Quizlet.com to use speech recognition today on a relatively large scale, with just a few lines of Javascript code: http://quizlet.com/voicetest/415/?scatter Since there are a lot of Google folks on this list, I recommend you talk to Alex Gruenstein (in your speech group) who was one of the lead developers of WAMI while at MIT. The major limitation we found when building the system was that we had to develop a new audio controller for every client (Java for the desktop, custom browsers for iPhone and Android). ?It would have been much simpler if browsers came with standard microphone capture and audio streaming capabilities. -Ian
Re: [whatwg] Inconsistent behavior for empty-string URLs
On Tue, Dec 15, 2009 at 4:11 PM, Nicholas Zakas nza...@yahoo-inc.com wrote: Here's what I would propose: 1. Empty string attributes for HTML elements specifying resources to automatically download are considered invalid and don't cause a request to be sent. Examples: img, link, script, iframe, etc. This would not apply to a href= because it is a user-initiated request. 2. This also applies to manipulation of HTML elements through the DOM, so (new Image()).src= would not result in a request being sent. 3. This does not apply to JavaScript APIs that are unrelated to HTML elements, such as Web Workers, XMLHttpRequest, etc. I'd prefer to explicitly enumerate the elements we're talking about, rather than giving rules which risk being interpreted differently by different people. For example not all links are automatically downloaded, such as link rel=prev. However I suspect that we'll want all links to behave the same. So the specific list would then be: img link script iframe video audio object embed source input type=image All of these would never attempt to fetch a resource if the src/href attribute is empty (even if the current baseuri is different from the document uri). However it would not act as if the attribute was not set (important for script). Does that sound right? / Jonas
Re: [whatwg] Inconsistent behavior for empty-string URLs
Yes, that sounds right. -Nicholas __ Commander Lock: Damnit Morpheus, not everyone believes what you believe! Morpheus: My beliefs do not require them to. -Original Message- From: Jonas Sicking [mailto:jo...@sicking.cc] Sent: Tuesday, December 15, 2009 5:22 PM To: Nicholas Zakas Cc: Maciej Stachowiak; whatwg@lists.whatwg.org; Aryeh Gregor; Simon Pieters Subject: Re: [whatwg] Inconsistent behavior for empty-string URLs On Tue, Dec 15, 2009 at 4:11 PM, Nicholas Zakas nza...@yahoo-inc.com wrote: Here's what I would propose: 1. Empty string attributes for HTML elements specifying resources to automatically download are considered invalid and don't cause a request to be sent. Examples: img, link, script, iframe, etc. This would not apply to a href= because it is a user-initiated request. 2. This also applies to manipulation of HTML elements through the DOM, so (new Image()).src= would not result in a request being sent. 3. This does not apply to JavaScript APIs that are unrelated to HTML elements, such as Web Workers, XMLHttpRequest, etc. I'd prefer to explicitly enumerate the elements we're talking about, rather than giving rules which risk being interpreted differently by different people. For example not all links are automatically downloaded, such as link rel=prev. However I suspect that we'll want all links to behave the same. So the specific list would then be: img link script iframe video audio object embed source input type=image All of these would never attempt to fetch a resource if the src/href attribute is empty (even if the current baseuri is different from the document uri). However it would not act as if the attribute was not set (important for script). Does that sound right? / Jonas
Re: [whatwg] Inconsistent behavior for empty-string URLs
On Tue, Dec 15, 2009 at 8:21 PM, Jonas Sicking jo...@sicking.cc wrote: For example not all links are automatically downloaded, such as link rel=prev. However I suspect that we'll want all links to behave the same. I'd say the rule should be that if the type is text/html or unknown, should work. If it's known to be some other type, like text/css, then it should fail. Alternatively, it should work for everything that doesn't actually fetch a resource automatically. After all, the rationale for this whole change is that as a source for images and such 1) makes no sense and is almost certainly an authoring mistake, and 2) causes extra HTTP requests -- but neither is true for all links. For instance, link rel=first href= makes perfect sense and causes no extra requests, so I don't think it should be prohibited.
Re: [whatwg] Inconsistent behavior for empty-string URLs
Shouldn't this proposal take into account the CSS3 content property? (
http://www.w3.org/TR/css3-content/)
E.g., figure[alt] { content: attr(href, url), attr(alt); }
This was discussed not too long ago, starting in this thread:
Adding a src attribute to all elements (
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-November/023955.html
)
-Mike
On Tue, Dec 15, 2009 at 8:37 PM, Nicholas Zakas nza...@yahoo-inc.comwrote:
Yes, that sounds right.
-Nicholas
__
Commander Lock: Damnit Morpheus, not everyone believes what you
believe!
Morpheus: My beliefs do not require them to.
-Original Message-
From: Jonas Sicking [mailto:jo...@sicking.cc]
Sent: Tuesday, December 15, 2009 5:22 PM
To: Nicholas Zakas
Cc: Maciej Stachowiak; whatwg@lists.whatwg.org; Aryeh Gregor; Simon
Pieters
Subject: Re: [whatwg] Inconsistent behavior for empty-string URLs
On Tue, Dec 15, 2009 at 4:11 PM, Nicholas Zakas nza...@yahoo-inc.com
wrote:
Here's what I would propose:
1. Empty string attributes for HTML elements specifying resources to
automatically download are considered invalid and don't cause a
request
to be sent. Examples: img, link, script, iframe, etc. This
would
not apply to a href= because it is a user-initiated request.
2. This also applies to manipulation of HTML elements through the DOM,
so (new Image()).src= would not result in a request being sent.
3. This does not apply to JavaScript APIs that are unrelated to HTML
elements, such as Web Workers, XMLHttpRequest, etc.
I'd prefer to explicitly enumerate the elements we're talking about,
rather than giving rules which risk being interpreted differently by
different people.
For example not all links are automatically downloaded, such as
link rel=prev. However I suspect that we'll want all links to
behave the same.
So the specific list would then be:
img
link
script
iframe
video
audio
object
embed
source
input type=image
All of these would never attempt to fetch a resource if the src/href
attribute is empty (even if the current baseuri is different from the
document uri). However it would not act as if the attribute was not
set (important for script).
Does that sound right?
/ Jonas
Re: [whatwg] Inconsistent behavior for empty-string URLs
On Tue, Dec 15, 2009 at 5:51 PM, Aryeh Gregor simetrical+...@gmail.com wrote: On Tue, Dec 15, 2009 at 8:21 PM, Jonas Sicking jo...@sicking.cc wrote: For example not all links are automatically downloaded, such as link rel=prev. However I suspect that we'll want all links to behave the same. I'd say the rule should be that if the type is text/html or unknown, should work. Interesting. I don't think we want to base it on the type attribute, since that should generally be possible to leave out. But I can certainly see a use for link rel=sitemap href=. So maybe just apply the don't-download rule rel=stylesheet (and rel=stylesheet alternate etc). / Jonas
