Re: [whatwg] base elements, again
Jonas Sicking wrote: On Mon, Jan 24, 2011 at 10:33 AM, Boris Zbarsky bzbar...@mit.edu wrote: On 1/24/11 11:23 AM, Henri Sivonen wrote: Why did/does this markup work in other UAs? Or does it not? According to the Chromium bugs about Unicenter, Unicenter doesn't work in Opera or in WebKit-based browsers--only in Firefox and IE. Exciting. :( When base target follows the a, IE6 ignores the target, because IE6 honors the most recent base. That's the Gecko 1.9.2 and earlier behavior as well, right? For the level of detail that's relevant here, yes. (In IE6, base becomes a container that doesn't close until the end of the document. In Gecko 1.9.2, base is empty but takes effect on the nodes that follow it in the tree order.) IE7 and later ignore base outside head, so a base following an a gets ignored due to that reason. Right, and that breaks other sites, which is why we changed away from that behavior... I can't say I like the IE6/old-Gecko behavior, but it may be the most web-compatible. :( So how does IE7/8 deal with the sites which broke for us when we didn't honor base outside head? (United.com, right?) So there are two distinct things here: base href and base target. United.com is base href. It works in IE7, because base href ends up being in head, because the element before it that makes Firefox 4 / Chrome 8 / spec break out of head is of the form foo:bar /, where the colon makes IE7 treat / as self-closing syntax. Furthermore, apparently stuff with colons doesn't break out of head in IE7. United.com is on the Microsoft-maintained blacklist of sites that need to be in the EmulateIE7 mode, so the parsing changes for foo:bar / in IE9 don't apply. Unicenter and hyperlatex are base target. Hyperlatex output is broken in IE7 and later. In Unicenter, the base target is after the a href, so the target doesn't take effect in IE6, because the target comes later. In IE7, the target doesn't take effect, because the target isn't given in head. (Note that IE quirks mode, which Unicenter is in, does honor base target in head for the evaluation context of javascript: URLs, so this isn't about that.) I'd really like to avoid going back to Gecko/IE6 behavior. It's bad both for browsers and authors. I agree. Since Unicenter reportedly uses an EmulateIE7 X-UA-Compatible, presumably the product was still being maintained when IE8 was released. Maybe there's a slight chance that they could take out the bogus base target if asked nicely. Is it known if CA Technologies can push automatic updates to their Unicenter customers? One 100% browser-side option (that I don't like but am mentioning for completeness) that would make both Unicenter and hyperlatex work without introducing code for keeping track of multiple base targets in the tree order would be limiting base target to head in the quirks mode but honoring the first base target in the other modes. -- Henri Sivonen hsivo...@iki.fi http://hsivonen.iki.fi/
Re: [whatwg] base elements, again
On 1/25/11 3:09 AM, Henri Sivonen wrote: Since Unicenter reportedly uses an EmulateIE7 X-UA-Compatible, presumably the product was still being maintained when IE8 was released. Maybe there's a slight chance that they could take out the bogusbase target For what it's worth, it looks like their base target comes right before some sort of footer... and I bet in IE6 the links in that footer actually target the toplevel window, which I also bet is the reason they have the base tag there. Of course that's all broken in IE7 One 100% browser-side option (that I don't like but am mentioning for completeness) that would make both Unicenter and hyperlatex work without introducing code for keeping track of multiplebase targets in the tree order would be limitingbase target tohead in the quirks mode but honoring the firstbase target in the other modes. Hmm. I might be willing to deal with his quirk -Boris
Re: [whatwg] Small consistency issue with HTML5 nav element examples
On 1/24/11, Ian Hickson i...@hixie.ch wrote: On Mon, 24 Jan 2011, Bjartur Thorlacius wrote: But then, when should hyperlinks be created with links? More or less never. link links don't show on most Web browsers. IMO browsers should implement link. link should be implementable cross-browser in CSS. And what happened to @rel=related being the default relation? Not sure to what you are referring. Sorry, my memory failed me. There is no default relation in HTML 4. Navigation links are clearly metadata, belonging to head. How do you distinguish what is data vs what is metadata? Generally, I categorize everything which isn't mentioned in the title or Content-Description (or would be, as there's usually none). No document would be described as My actual concern regard navigation links not forming a part of the linear body of the document, but still being in body. Navigation links will most likely be rendered out of band, potentially only on demand and paged/scrolled seperately from the body, or at the end of the document in one dimensional renderings (such as audio and text streams). They might even be triggered without being rendered at all, such as by scrolling out of range of the current document. For the record links and links2 render all hyperlinks (including ones with unrecognized values of @rel). Noted.
Re: [whatwg] File API Streaming Blobs
On 01/24/2011 04:24 AM, Anne van Kesteren wrote: (I removed the Chromium related list as I am not subscribed there.) On Fri, 21 Jan 2011 21:35:53 +0100, Adam Malcontenti-Wilson adman@gmail.com wrote: XHR2 is one part of the APIs required for my use case as that is the easiest way to download for example a music file. However, while downloading, there's no way to pipe the download(ing) blob to the HTML5 Audio element as to play Audio it requires an object URL, and an object URL can (currently) only point to a static Blob, as well as the fact that a Blob cannot be appended. This would be important for listening streaming audio that needs to be processed in JavaScript or cached to persistant storage using the Filesystem APIs without having to wait for the entire file to be downloaded into an ArrayBuffer or Blob. There is a plan of allowing direct assigning to IDL attributes besides creating URLs. I.e. being able to do: audio.src = blob (The src content attribute would then be something like about:objecturl.) I am not sure if that API should work differently from creating URLs and assigning those, but we could consider it. I don't see the point of that, if all it does is save one call to URL.createObjectURL() (and also one call to revokeObjectURL())? In any case, making this behave differently than the URL API seems like a bad idea. My suggestion was for another alternative version of Blob and/or createObjectUrl that mimicks how a HTTP request can be parsed and (in the case of audio or video) start playing before it has finished downloading (e.g. got to the content-length or had a connection close) by pushing content when it is appended to the blob and then the virtual connection can be closed when the Blob has finished being built by calling a close() function. I've also thought of other alternatives, but I'd make sure that there isn't already a way to do this with the current (specified) APIs, and I think this has the most other use cases as any data that takes a while to process can be streamed to the user or other parts of the browser. Is there actually a good reason for the URL API to have behave in this way? Adam's use case--to be able to download, play and cache audio data at the same time--seems like a pretty compelling one. I think this is fundamentally an issue with the Blob API, not the URL API. Blobs just seem like they ought to stream. When you get a blob in the onprogress handler of an XHR2, you ought to be able to fire up a FileReader on it and have it automatically read from the blob as the XHR2 writes to the blob. But currently (I think) you have to slice the blob to get only the new bytes and start a new FileReader each time onprogress is called. (Or wait for onload, of course.) Similarly, when you get your first onprogress event for a Blob download, you ought to be able to create a URL for that Blob that remains valid while the download is in progress. So you can use that url with an audio element, for example. Also: BlobBuilder seems to me as if it ought to be a streaming API. It feels like it ought to work like this: var bb = new BlobBuilder(); var b1 = bb.getBlob(); var u1 = URL.createObjectURL(b1); bb.append(hello world); var b2 = bb.getBlob(); var u2 = URL.createObjectURL(b2); b1 === b2 // They ought to be equal, but they're not u1 === u2 // Ought to be equal, but they're not bb.close(); // New method: now no more appends are allowed. David P.S. This is probably the wrong list for this discussion, isn't it?
Re: [whatwg] File API Streaming Blobs
On 1/21/11, Roger Hågensen resca...@emsai.net wrote: Hmm! And I guess it's very difficult to create a abstract in/out interface that can handle any protocol/stream. Although an abstract in/out would be ideal as that would let new protocols to be supported without needing to rewrite anything at the higher level. stdio2?
Re: [whatwg] base elements, again
On Tue, Jan 25, 2011 at 8:11 AM, Boris Zbarsky bzbar...@mit.edu wrote: On 1/25/11 3:09 AM, Henri Sivonen wrote: Since Unicenter reportedly uses an EmulateIE7 X-UA-Compatible, presumably the product was still being maintained when IE8 was released. Maybe there's a slight chance that they could take out the bogusbase target For what it's worth, it looks like their base target comes right before some sort of footer... and I bet in IE6 the links in that footer actually target the toplevel window, which I also bet is the reason they have the base tag there. Of course that's all broken in IE7 One 100% browser-side option (that I don't like but am mentioning for completeness) that would make both Unicenter and hyperlatex work without introducing code for keeping track of multiplebase targets in the tree order would be limitingbase target tohead in the quirks mode but honoring the firstbase target in the other modes. Hmm. I might be willing to deal with his quirk This sounds like the best option so far. Or simply doing nothing and keeping what we currently have. I can't really gauge how much stuff we so far know will break if we do that though. / Jonas
Re: [whatwg] AppCache feature request: An https manifest should be able to list resources from other https origins.
Would the public-webapps list be better for discussing appcache feature requests? This could be as simple as the presence of an 'applicationcaching_allowed' file at the top level. An https manifest update that wants to retrieve resources from another https origin would first have to fetch the 'allow' file and see an expected response, and if it doesn't see a good response, those xorigin entries would be skipped (matching today's behavior). The request... GET /applicationcaching_allowed Referer: manifestUrl of the cache trying to include resources from this host The expected response headers... HTTP/1.x 200 OK Content-Type: text/plain The expected response body... Allowed:* On Thu, Jan 13, 2011 at 3:08 PM, Michael Nordman micha...@google.com wrote: AppCache feature request: An https manifest should be able to list resources from other https origins. I've got some app developers asking for this feature. Currently, it's explicitly disallowed by the the spec for valid security reasons, but there are also valid reasons to have this capability, like a webapp that uses resources hosted on gstatic. Seems like a robots.txt like scheme where a site like gstatic can declare that its OK to appcache me from elsewhere is needed. I've opened a chromium bug for this here... http://code.google.com/p/chromium/issues/detail?id=69594
Re: [whatwg] FYI: HTML usage data from Disqus websites
Anything in particular or just general overview of HTML5 tags usage? Anton On 22 January 2011 07:21, Odin odin.om...@gmail.com wrote: On Wed, Jan 19, 2011 at 12:05 PM, Anne van Kesteren ann...@opera.com wrote: On Wed, 19 Jan 2011 11:59:12 +0100, Anton Kovalyov an...@disqus.com wrote: make it happen. Of course, the data will be completely anonymous and it has to be related to WHATWG's main focus. Results will be published probably by me on behalf of the company. If you could give the same kind of data webstats gathered but for your dataset that would be great. But anything really might give some insight into what is going on on the Web. :-) What about testing usage of html5-features? Tag usage etc? Guess it will be very small, but it'd be interesting to see. And maybe someone could do trending of it after a few years. -- Beste helsing, Odin Hørthe Omdal odin.om...@gmail.com http://velmont.no
Re: [whatwg] FYI: HTML usage data from Disqus websites
On Tue, Jan 25, 2011 at 11:43 PM, Anton Kovalyov an...@disqus.com wrote: Anything in particular or just general overview of HTML5 tags usage? Well, I find HTML5 video tags particulary interesting. As well as how they use fallback, -- what types of video people use inside it etc. It'd be very interesting. Of course, very early, I guess you'll find very few, so maybe it isn't interesting. But, well. -- Beste helsing, Odin Hørthe Omdal odin.om...@gmail.com http://velmont.no
