Re: [whatwg] Attribute for holding private data for scripting
On Apr 12, 2007, at 01:45, Michael A. Puls II wrote: On 4/11/07, Henri Sivonen [EMAIL PROTECTED] wrote: I was thinking of establishing an attribute such as script-private where authors would be free to stick anything for retrieval by scripts. What would happen with embed script-private=something? Would the data be passed to the plug-in as a script-private param or would script-private be reserved; causing any plug-in using script-param not to get the data? (A prefix could possible avoid this.) In old browsers at least, the script-private=something would be passed to the plug-in. Is it a problem? -- Henri Sivonen [EMAIL PROTECTED] http://hsivonen.iki.fi/
Re: [whatwg] IE/Win treats backslashes in path as forward slashes
Maciej Stachowiak schrieb: ... Besides the backslash thing, there are a number of URI processing rules that browsers must follow for web compatibility which are either not required by or directly contradictory to the URI RFCs. Documenting these and fixing the relevant RFCs would be a valuable goal, but possibly beyond the scope of WHATWG. ... Interesting. Details please. In doubt, on the URI mailing list (http://lists.w3.org/Archives/Public/uri/). Best regards, Julian
Re: [whatwg] Give guidance about RFC 4281 codecs parameter
On 4/11/07, Dave Singer [EMAIL PROTECTED] wrote: We had to settle on one type that was valid for all files, to deal with the (common) case where the server was not willing to do introspection to find the correct type. We decided that audio/ promises that there isn't video, whereas video/ indicates that there may be. It's not optimal, agreed. I agree that video/xxx and audio/xxx are useful distinctions. Another point is that as IE ignores MIME types in favour of extensions, in practice we end up with multiple extensionss pointing to the same filetype, to give a cue for differentiation: .wmv vs .wma .m4v vs .m4a (also .m4p for DRM'd and .m4b for audiobooks, no?) That these distinctions keep being made, despite neutral formats with extensions like .mov, .avi, .mp4 and .ogg implies that there is some utility there.
Re: [whatwg] IE/Win treats backslashes in path as forward slashes
Anne van Kesteren schrieb: On Thu, 12 Apr 2007 10:43:55 +0200, Julian Reschke [EMAIL PROTECTED] wrote: Maciej Stachowiak schrieb: ... Besides the backslash thing, there are a number of URI processing rules that browsers must follow for web compatibility which are either not required by or directly contradictory to the URI RFCs. Documenting these and fixing the relevant RFCs would be a valuable goal, but possibly beyond the scope of WHATWG. ... Interesting. Details please. In doubt, on the URI mailing list (http://lists.w3.org/Archives/Public/uri/). See this thread from last month for instance: http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2007-March/thread.html#10088 ... Thanks for the pointer. It seems to me that at least this thread does not point out bugs in RFC3986 or RFC3987, but problems in user agents that do not follow these specs. Or stated otherwise: in reality, URIs in HTML documents are not RFC-compliant URIs or IRIs, but something else. It's up to the working group to either deprecate these kinds of references, or to specify how they should be handled. In any case, this doesn't seem to be a problem with the URI/IRI RFCs. Best regards, Julian
Re: [whatwg] IE/Win treats backslashes in path as forward slashes
On Thu, 12 Apr 2007 11:24:54 +0200, Julian Reschke [EMAIL PROTECTED] wrote: It seems to me that at least this thread does not point out bugs in RFC3986 or RFC3987, but problems in user agents that do not follow these specs. Or stated otherwise: in reality, URIs in HTML documents are not RFC-compliant URIs or IRIs, but something else. It's up to the working group to either deprecate these kinds of references, or to specify how they should be handled. In reality, most URIs can be found in HTML documents. In any case, this doesn't seem to be a problem with the URI/IRI RFCs. Your point of view is interesting though... -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [whatwg] Give guidance about RFC 4281 codecs parameter
On 4/12/07, Dave Singer [EMAIL PROTECTED] wrote: At 12:12 +1000 11/04/07, Silvia Pfeiffer wrote: On 4/11/07, Maciej Stachowiak [EMAIL PROTECTED] wrote: Wouldn't it be simpler to use video/ogg and audio/ogg as the base types here? That would already tell you the intended disposition. Please note that rfc4281 also mentions the problem that video/* bucket types could have audio only included in them: With each bucket type, a receiving agent only knows that it has a container format. It doesn't even know whether content labeled video/3gpp or video/3gpp2 contains video; it might be audio only, audio and video, or video only. Therefore, the video/* type does not clearly indicate which application would be most suitable to be used with such a contant type. But it does at least indicate that we have a time-based multimedia container on our hands, and that it might contain visual presentation. application/ suffers that it does not say even that, and it raises the concern that this might be arbitrary, possibly executable, data. We discussed whether application/ was appropriate for MP4 and decided that it masked important characteristics of the format -- that it really is a time-based multimedia presentation -- and raised unwarranted concerns. We had to settle on one type that was valid for all files, to deal with the (common) case where the server was not willing to do introspection to find the correct type. We decided that audio/ promises that there isn't video, whereas video/ indicates that there may be. It's not optimal, agreed. Neither video/x-theora nor audio/x-vorbis actually tell you in what container (bucket) your stream comes. These seem to be unregistered (x-) types that attempt to identify a codec in a container-independent way (a problem that the 'bucket' RFC struggled with), right? Mime types for multimedia are a complicated field because of the container formats. Will audio/vorbis imply a parsable containter format as is required by UA applications, or will it just describe the codec as is required by streaming applications? We are all in our own way trying to solve these issues in the least ambiguous way. Xiph has not registered any MIME types yet because the best way has not been determined yet and the use of x- unregistered types is fully functional. What I reported on was our current state of discussion and I believe it is relatively unambiguous. A similar discussion can be had around file extensions. Both of which I believe are rather off topic for WHAT WG. I totally agree - file inspection is not workable in many cases and therefore the MIME type has to indicate all of this information: the bucket type, the contained codecs, and the suggested type of application to use. Unfortunately, those parameters in the mime type relayed from the server are derived by ... file inspection. Yes, types embedded in the page can be more accurate. Deriving mime types for nearly all files can only be done through file inspection if the file extension is ambiguous. I'm with my colleague here; I think application/ is needlessly vague, raises unwarranted concerns, and avoids using acceptable, more specific types. Maybe I should have said so on the IETF list when the I-D was becoming an RFC... A container format that can have a multitude of tracks inside it should have its own mime type. Unfortunately application/ is the closes match for describing container formats. This does not restrict from using more specific mime types for files using this container format that are specific. E.g. audio/x-vorbis+ogg has been used to specify Ogg Vorbis files, and video/x-theora+ogg for Ogg Theora/Vorbis files. When creating Ogg files with e.g. 2 theora tracks, 4 vorbis tracks, and 2 speex tracks, you still need a MIME type for this beast - and since the beast can auto-identify itself through the skeleton and the mime types inside itself, a media framework such as GStreamer or QuickTime or DirectShow can still deal with it generically. It is an issue of finding the balance between providing for the generic and specific. The best way is to allow both, IMHO. I'm not sure how pertinent this is to whatwg, though... Agree - even though a Web communication relies heavily on the use of MIME types both at the server and the client side. Regards, Silvia.
Re: [whatwg] Web Archives
On 11-Apr-07, at 9:35 PM, Michael A. Puls II wrote: On 4/11/07, Lachlan Hunt [EMAIL PROTECTED] wrote: Michael A. Puls II wrote: It's a really good way to archive, but IE won't handle it and most plug-ins don't accept data URIs, so there are problems with that use-case. (unless browsers can help with that in a secure way.) I made a suggestion about this on the Opera forums a while ago when Opera didn't even support .mht. http://my.opera.com/community/forums/topic.dml?id=72718 (The actual working example links are broken, but the idea was..) So because data URIs are unsupported by IE and MHT isn't supported by some others, you propose this new feature which is equally unsupported all browsers? If IE supported data URIs, I still don't think HTML + data URIs would be the best format for archiving. (Just saying that if IE did, we could use HTML + data URIs now for *some* archiving situations, but there'd still be problems with plug-ins and data bloat from encoding the resources.) If every browser supports .mht, I still don't think it's the best format for archiving. I suppose if I could (outside of a browser) select index.html and all its files, right-click and choose Generate .mht file from selection and do the opposite of generate files from .mht file to get the original content back, it might be better and feel more like a zip archive. However, even then, I don't think generating a mail message, possibly using quoted printable and a bunch oh headers is the best way to archive an html page and its content. What I do think is that the mozila archive format or something like the widget packaging Karl mentioned http://www.w3.org/TR/WAPF-REQ/#requirements_packaging would be a better format for archiving. So, yes, in that I'm suggesting something else that may not be supported much or at all yet, but not because of current support with other formats. I agree. The point is to get consistency between vendors, not to wait until they're already consistent. If we waited for everyone to support the same thing, nothing then would be supported. Thank you Karl for pointing out the Widgets draft. I can appreciate the similarities, but I'm not convinced that that implementation would work in this case (as it reads today). While Microsoft Sidebar, Google Desktop, Apple Dashboard or any other widget runtime environment would recognize the file and try to open it, there is nothing in the draft that promotes Internet Explorer, Firefox, Safari or any other browser to do the same. For example, Safari can't even be used to open a .wdgt file. For an archived website or an HTML-based document, you would want to be able to rely on the user having a viewer on his or her system that would recognize the file. In most cases, other than a widget, that viewer would be their browser. Maybe there needs to be a draft for web documents that is virtually identical to the widget draft, but aimed at browser runtime environments and with a different file extension? Any thoughts? - Tyler
Re: [whatwg] Web Archives
Michael A. Puls II schrieb: ... If every browser supports .mht, I still don't think it's the best format for archiving. ... What exactly is the problem with .mht (RFC2557)? Are they fixable? How about trying to gather a group of people interested in fixing it? Best regards, Julian
Re: [whatwg] Web Archives
On Apr 12, 2007, at 18:33, Julian Reschke wrote: What exactly is the problem with .mht (RFC2557)? Are they fixable? Compared to a zip-based solution, .mht expands data (base64) and the parts of .mht cannot be extracted with ubiquitous zip utilities. -- Henri Sivonen [EMAIL PROTECTED] http://hsivonen.iki.fi/
Re: [whatwg] Web Archives
Hello, Do any of the existing web archive formats out there store the ETag or Last-Modified of the resources it is archiving? See ya On 4/11/07, Tyler Keating [EMAIL PROTECTED] wrote: Hi, I apologize if I've missed this in the specification or mailing archives, but I have a suggestion related to standardizing web archives in HTML5. Currently, I know that Firefox uses Mozilla Archive Format (.maf), Internet Explorer and Opera use MIME HTML (.mht) and Safari uses its own format (.webarchive) for saving a web page and all of its resources into a single file. So clearly a standard would be beneficial in ensuring archive compatibility between browsers and I think it's suitable for that standard to reside in HTML5. I don't believe this would be very difficult to standardize and the solution may be nothing more than a collection of random files wrapped into a ZIP compressed archive with a unique extension similar to a JAR or ODF file. The unique extension would be recognized by browsers, email clients and editors, which could then extract and display the root file directly (ex. index.html). The root file would obviously contain relative URIs to any other HTML, JavaScript, CSS, images and other files in the archive so the internal structure may not be important and the browser would not need any new rules to interpret individual files once it has uncompressed the archive into memory. This would facilitate passing HTML based documents around that could be viewed with any browser, yet appear as a small single file. -Tyler -- Charles Iliya Krempeaux, B.Sc. charles @ reptile.ca supercanadian @ gmail.com developer weblog: http://ChangeLog.ca/
Re: [whatwg] Give guidance about RFC 4281 codecs parameter
On Wed, Apr 11, 2007 at 05:45:34PM -0700, Dave Singer wrote: But [video/*] does at least indicate that we have a time-based multimedia container on our hands, and that it might contain visual presentation. application/ suffers that it does not say even that, and it raises the concern that this might be arbitrary, possibly executable, data. We discussed whether application/ was appropriate for MP4 and decided that it masked important characteristics of the format -- that it really is a time-based multimedia presentation -- and raised unwarranted concerns. I guess we made the opposite decision. Because Ogg was a container and could contain anything, including executable content, we went with the most generic option, based on analogy with application/octet-stream, application/pdf, etc. That we were working only on audio at the time may have coloured our judgement; the video-contains-audio argument didn't fit. I've noticed application/rss as a newer example, but I think that's more to encourage handoff from browsers without native support than an attempt at classification. Maciej's suggestion (registering all three) would work for Ogg, but I was under the impression that multiple registrations for the same format were discouraged. The disposition hinting proposal also works for general media types, without requiring registration of a suite of media types for every container. I also think it's a better solution for playlists, which are and aren't time-based media. Would you also go with video/x-m3u, video/rss for those text-based formats? Overloading the base types works, but so does a separate indication. Both are backward-compatible extensions to the media-type field, and both require software changes to implement. One however, requires registering new types, including audio/quicktime. :) Thanks for explaining your rationale, it's interesting to hear. -r
Re: [whatwg] Give guidance about RFC 4281 codecs parameter
Hello, This reminds me of when Lucas Gonze was arguing that MIME types (and Content Types) were dead. http://tech.groups.yahoo.com/group/videoblogging/message/48276 See ya On 4/12/07, Kevin Marks [EMAIL PROTECTED] wrote: On 4/11/07, Dave Singer [EMAIL PROTECTED] wrote: We had to settle on one type that was valid for all files, to deal with the (common) case where the server was not willing to do introspection to find the correct type. We decided that audio/ promises that there isn't video, whereas video/ indicates that there may be. It's not optimal, agreed. I agree that video/xxx and audio/xxx are useful distinctions. Another point is that as IE ignores MIME types in favour of extensions, in practice we end up with multiple extensionss pointing to the same filetype, to give a cue for differentiation: .wmv vs .wma .m4v vs .m4a (also .m4p for DRM'd and .m4b for audiobooks, no?) That these distinctions keep being made, despite neutral formats with extensions like .mov, .avi, .mp4 and .ogg implies that there is some utility there. -- Charles Iliya Krempeaux, B.Sc. charles @ reptile.ca supercanadian @ gmail.com developer weblog: http://ChangeLog.ca/
[whatwg] Negative tabindex
According to:
http://www.whatwg.org/specs/web-apps/current-work/#negative-tabindex
A negative integer specifies that the element should be removed from
the tab order. If the element does normally take focus, it may still
be focused using other means (e.g. it could be focused by a click).
That appears not to be true in IE7, see:
div tabindex=-1 onfocus=alert('div')click me/div
This triggers the alert in IE7.
So it seems to me the If the element does normally take focus,
should be removed.
Regards,
Martijn
--
Martijn Wargers
Help Mozilla!
http://weblogs.mozillazine.org/qa/
http://www.mozilla.org/contribute/
[whatwg] Semantic use of the font element
I have a website which discusses typography, web design, and computer fonts. It recently occurred to me that my use of spans with style elements was not really the most semantic method of getting across my meaning, and I would be better using the font element. My content goes something like this: span style=font-family:HelveticaThis is a sample of Helvetica/ spanbr span style=font-family:ArialThis is a sample of Arial/span Which loses its visual meaning if the CSS is stripped, overridden, or not understood, and further more I cannot supply fallback fonts (since that would create a misleading visual appearance) and so here contradict the CSS guidelines for the font-family property. Would it not be more correct to use: font face=HelveticaThis is a sample of Helvetica/fontbr font face=ArialThis is a sample of Arial/font In this instance I am saying to the browser that the font is the critical part of that run of text, and the fact that font doesn't support fall-back works in my favour here, as well as the usage being fully compatible with graphical UAs. - Nicholas. smime.p7s Description: S/MIME cryptographic signature
Re: [whatwg] Semantic use of the font element
That's an interesting one - but the idea of semantics for html is to use an element of meaning, which the font tag lacks in every case as it's a visual not a content representation? This is the same failure as using a span tag for your example, since span has no meaning. The sad part here is that if you want to have a visual representation in your HTML, you're going to have to use CSS or an image to display the example. So span is just as bad as font in this case, it lacks meaning, though I get what you're implying. Side note, there's no point in a break either if you're using a block level element, which implies the structure of the content. In the end, you've got a header element, and that's what the html should be displaying - it's the header of a document or document portion. How it looks is not semantic, even if it's a visual representation of a subject, that's the reason for CSS and/or images. If your way were true I could argue: blue type=squareThis is a blue square/blue Nicholas Shanks wrote: I have a website which discusses typography, web design, and computer fonts. It recently occurred to me that my use of spans with style elements was not really the most semantic method of getting across my meaning, and I would be better using the font element. My content goes something like this: span style=font-family:HelveticaThis is a sample of Helvetica/spanbr span style=font-family:ArialThis is a sample of Arial/span Which loses its visual meaning if the CSS is stripped, overridden, or not understood, and further more I cannot supply fallback fonts (since that would create a misleading visual appearance) and so here contradict the CSS guidelines for the font-family property. Would it not be more correct to use: font face=HelveticaThis is a sample of Helvetica/fontbr font face=ArialThis is a sample of Arial/font In this instance I am saying to the browser that the font is the critical part of that run of text, and the fact that font doesn't support fall-back works in my favour here, as well as the usage being fully compatible with graphical UAs. - Nicholas.
Re: [whatwg] Semantic use of the font element
On Apr 12, 2007, at 5:24 PM, Nicholas Shanks wrote: My content goes something like this: span style=font-family:HelveticaThis is a sample of Helvetica/ spanbr span style=font-family:ArialThis is a sample of Arial/span If the sense of the text absolutely depends on its being displayed in a particular font, might it be better to display it in an image? Helvetica and Arial are on almost every computer, but an image would leave no doubt, and since the content is, essentially, the visual representation of itself, an image would seem to me to be semantically appropriate. David
Re: [whatwg] Semantic use of the font element
David Walbert wrote: On Apr 12, 2007, at 5:24 PM, Nicholas Shanks wrote: My content goes something like this: span style=font-family:HelveticaThis is a sample of Helvetica/spanbr span style=font-family:ArialThis is a sample of Arial/span If the sense of the text absolutely depends on its being displayed in a particular font, might it be better to display it in an image? Helvetica and Arial are on almost every computer, but an image would leave no doubt, and since the content is, essentially, the visual representation of itself, an image would seem to me to be semantically appropriate. Agreed. Since the visual representation *is* the content, the font demo should definitely be an image or other graphic object. This has the further advantage of being UA, platform and resident-font agnostic. If the UA is non-graphic, the user would still have the opportunity to open the image in a viewer. There is no such option if you're dependent on style properties or upon the font tag. cheers, gary
Re: [whatwg] Semantic use of the font element
David Walbert wrote: On Apr 12, 2007, at 5:24 PM, Nicholas Shanks wrote: My content goes something like this: span style=font-family:HelveticaThis is a sample of Helvetica/spanbr span style=font-family:ArialThis is a sample of Arial/span If the sense of the text absolutely depends on its being displayed in a particular font, might it be better to display it in an image? Helvetica and Arial are on almost every computer, but an image would leave no doubt, and since the content is, essentially, the visual representation of itself, an image would seem to me to be semantically appropriate. Using an image would also avoid the issues that would come up if you were demonstrating a font via markup that a user doesn't happen to have installed. The browser could wind up defaulting to a completely different font than what you were attempting to illustrate. -- Bill Mason Accessible Internet [EMAIL PROTECTED] http://accessibleinter.net/
Re: [whatwg] Semantic use of the font element
At 18:12 -0700 12/04/07, Bill Mason wrote: Using an image would also avoid the issues that would come up if you were demonstrating a font via markup that a user doesn't happen to have installed. The browser could wind up defaulting to a completely different font than what you were attempting to illustrate. I think we are all in violent agreement here. If you are trying to say something visual (it looks like this), then nothing works quite like a picture. Sounds like a truism, I know. -- David Singer Apple Computer/QuickTime
