???

From hsivonen at iki.fi Mon Jan 2 07:43:07 2012 From: hsivonen at iki.fi (Henri Sivonen) Date: Mon, 2 Jan 2012 17:43:07 +0200 Subject: [whatwg] [encoding] utf-16 In-Reply-To: References: <20111230055116241293.3b556db0@xn--mlform-iua.no> Message-ID: On Fri, Dec 30, 2011 at 12:54 PM, Anne van Kesteren wrote: > And why should there be UTF-16 sniffing? The reason why Gecko detects BOMless Basic Latin-only UTF-16 regardless of the heuristic detector mode is https://bugzilla.mozilla.org/show_bug.cgi?id=631751 It's quite possible that Firefox could have gotten away with not having this behavior. -- Henri Sivonen hsivonen at iki.fi http://hsivonen.iki.fi/ From hsivonen at iki.fi Mon Jan 2 07:26:55 2012 From: hsivonen at iki.fi (Henri Sivonen) Date: Mon, 2 Jan 2012 17:26:55 +0200 Subject: [whatwg] [encoding] utf-16 In-Reply-To: References: Message-ID: On Tue, Dec 27, 2011 at 4:52 PM, Anne van Kesteren wrote: > I ran some utf-16 tests using 007A as input data, optionally preceded by > FFFE or FEFF, and with utf-16, utf-16le, and utf-16be declared in the > Content-Type header I suggest testing with zero, one, two and three BOMs. I'd expect Gecko to have a bug that causes it to remove *two* BOMs but not more than that. -- Henri Sivonen hsivonen at iki.fi http://hsivonen.iki.fi/ From simonp at opera.com Mon Jan 2 00:39:40 2012 From: simonp at opera.com (Simon Pieters) Date: Mon, 02 Jan 2012 09:39:40 +0100 Subject: [whatwg] Feedback on Meta referrer In-Reply-To: <4EFF5A63.7080407@gmail.com> References: <4EFF49F5.9090208@gmail.com> <4EFF54BE.6030908@gmail.com> <4EFF5A63.7080407@gmail.com> Message-ID: On Sat, 31 Dec 2011 19:54:27 +0100, David Bruant wrote: > Le 31/12/2011 19:46, Adam Barth a ?crit : >> On Sat, Dec 31, 2011 at 10:30 AM, David Bruant >> wrote: >>> I think there could be a use case for same-origin+fragment-less URL >>> which allows for "internal" tracking but not external tracking. >> Yeah, that makes sense. I'm not sure whether we need to have the >> whole matrix though. Thoughts on a good name? > "internal", maybe? > I'm not 100% up to date with specific vocabulary regarding origins&DOM, > so I'm don't know if "internal" already has another meaning or could be > interpreted in another way in this context. It also seems plausible to want fragment-less URL for same-origin requests and origin-only URL for cross-origin requests. -- Simon Pieters Opera Software From simonp at opera.com Sun Jan 1 22:55:53 2012 From: simonp at opera.com (Simon Pieters) Date: Mon, 02 Jan 2012 07:55:53 +0100 Subject: [whatwg] Feedback on Meta referrer In-Reply-To: References: <4EFF49F5.9090208@gmail.com> Message-ID: On Sat, 31 Dec 2011 19:11:53 +0100, Adam Barth wrote: >> Another concern is what should happen if a request is sent before >> finding a meta referrer. For instance: >> >> >> >> >> In what conditions should the request for the css file be done? Ignore >> the meta tag? Wait until the end of in case there would be a meta >> element? > > The policy for a given network fetch is determined when the fetch is > made. In this case, the request for a.css will include the Referer > header. If you move the tag above the tag, then the > request will not include the Referer header. What about: ...and the browser speculatively fetches the stylesheet before the element is in the DOM? Should the speculative parser have knowledge of ? >> "TODO: This algorithm causes the most recently added meta element to >> control the referrer-policy. Should we support changing the policy by >> setting the content attribute? " >> => I think that allowing to change the policy by setting the content >> attribute would be a good idea, but a question can arise regarding what >> happens if there are several such elements in the document. > > Yeah. Is there some precedent we should look to here? Perhaps the > element? Perhaps this should even be an attribute on -- -- Simon Pieters Opera Software From hsivonen at iki.fi Tue Jan 3 00:33:02 2012 From: hsivonen at iki.fi (Henri Sivonen) Date: Tue, 3 Jan 2012 10:33:02 +0200 Subject: [whatwg] Default encoding to UTF-8? In-Reply-To: <20111222113601381254.d5beccfd@russisk.no> References: <20111222113601381254.d5beccfd@russisk.no> Message-ID: On Thu, Dec 22, 2011 at 12:36 PM, Leif Halvard Silli wrote: >> It's unclear to me if you are talking about HTTP-level charset=UNICODE >> or charset=UNICODE in a meta. Is content labeled with charset=UNICODE >> BOMless? > > Charset=UNICODE in meta, as generated by MS tools (Office or IE, eg.) > seems to usually be "BOM-full". But there are still enough occurrences > of pages without BOM. I have found UTF-8 pages with the charset=unicode > label in meta. But the few page I found contained either BOM or > HTTP-level charset=utf-8. I have to little "research material" when it > comes to UTF-8 pages with charset=unicode inside. Making 'unicode' an alias of UTF-16 or UTF-16LE would be useless for pages that have a BOM, because the BOM is already inspected before and if HTTP-level charset is unrecognized, the BOM wins. Making 'unicode' an alias of UTF-16 or UTF-16LE would be useful for UTF-8-encoded pages that say charset=unicode in if alias resolution happens before UTF-16 labels are mapped to UTF-8. Making 'unicode' an alias for UTF-16 or UTF-16LE would be useless for pages that are (BOMless) UTF-16LE and that have charset=unicode in , because the prescan doesn't see UTF-16-encoded metas. Furthermore, it doesn't make sense to make the prescan look for UTF-16-encoded metas, because it would make sense to honor the value only if it matched a flavor of UTF-16 appropriate for the pattern of zero bytes in the file, so it would be more reliable and straight forward to just analyze the pattern of zero bytes without bothering to look for UTF-16-encoded s. > When the detector says UTF-8 - that is step 7 of the sniffing algorith, > no? > http://dev.w3.org/html5/spec/parsing.html#determining-the-character-encoding Yes. >> ?2) Start the parse assuming UTF-8 and reload as Windows-1252 if the >> detector says non-UTF-8. ... > I think you are mistaken there: If parsers perform UTF-8 detection, > then unlabelled pages will be detected, and no reparsing will happen. > Not even increase. You at least need to explain this negative spiral > theory better before I buy it ... Step 7 will *not* lead to reparsing > unless the default encoding is WINDOWS-1252. If the default encoding is > UTF-8, then step 7, when it detects UTF-8, then it means that parsing > can continue uninterrupted. That would be what I labeled as option #2 above. > What we will instead see is that those using legacy encodings must be > more clever in labelling their pages, or else they won't be detected. Many pages that use legacy encodings are legacy pages that aren't actively maintained. Unmaintained pages aren't going to become more clever about labeling. > I am a bitt baffled here: It sounds like you say that there will be bad > consequences if browsers becomes more reliable ... Becoming more reliable can be bad if the reliability comes at the cost of performance, which would be the case if the kind of heuristic detector that e.g. Firefox has was turned on for all locales. (I don't mean the performance impact of running a detector state machine. I mean the performance impact of reloading the page or, alternatively, the loss of incremental rendering.) A solution that would border on reasonable would be decoding as US-ASCII up to the first non-ASCII byte and then deciding between UTF-8 and the locale-specific legacy encoding by examining the first non-ASCII byte and up to 3 bytes after it to see if they form a valid UTF-8 byte sequence. But trying to gain more statistical confidence about UTF-8ness than that would be bad for performance (either due to stalling stream processing or due to reloading). > Apart from UTF-16, Chrome seems quite aggressive w.r.t. encoding > detection. So it might still be an competitive advantage. It would be interesting to know what exactly Chrome does. Maybe someone who knows the code could enlighten us? >>> * Let's say that I *kept* ISO-8859-1 as default encoding, but instead >>> enabled the Universal detector. The frame then works. >>> * But if I make the frame page very short, 10 * the letter "?" as >>> content, then the Universal detector fails - on a test on my own >>> computer, it guess the page to be Cyrillic rather than Norwegian. >>> * What's the problem? The Universal detector is too greedy - it tries >>> to fix more problems than I have. I only want it to guess on "UTF-8". >>> And if it doesn't detect UTF-8, then it should fall back to the locale >>> default (including fall back to the encoding of the parent frame). >>> >>> Wouldn't that be an idea? >> >> No. The current configuration works for Norwegian users already. For >> users from different silos, the ad might break, but ad breakage is >> less bad than spreading heuristic detection to more locales. > > Here I must disagree: Less bad for whom? For users performance-wise. -- Henri Sivonen hsivonen at iki.fi http://hsivonen.iki.fi/ From hsivonen at iki.fi Tue Jan 3 00:50:26 2012 From: hsivonen at iki.fi (Henri Sivonen) Date: Tue, 3 Jan 2012 10:50:26 +0200 Subject: [whatwg] Default encoding to UTF-8? In-Reply-To: References: <20111222113601381254.d5beccfd@russisk.no> Message-ID: On Tue, Jan 3, 2012 at 10:33 AM, Henri Sivonen wrote: > A solution that would border on reasonable would be decoding as > US-ASCII up to the first non-ASCII byte and then deciding between > UTF-8 and the locale-specific legacy encoding by examining the first > non-ASCII byte and up to 3 bytes after it to see if they form a valid > UTF-8 byte sequence. But trying to gain more statistical confidence > about UTF-8ness than that would be bad for performance (either due to > stalling stream processing or due to reloading). And it's worth noting that the above paragraph states a "solution" to the problem that is: "How to make it possible to use UTF-8 without declaring it?" Adding autodetection wouldn't actually force authors to use UTF-8, so the problem Faruk stated at the start of the thread (authors not using UTF-8 throughout systems that process user input) wouldn't be solved. -- Henri Sivonen hsivonen at iki.fi http://hsivonen.iki.fi/ From manips2002 at gmail.com Tue Jan 3 01:32:22 2012 From: manips2002 at gmail.com (Mani) Date: Tue, 3 Jan 2012 04:32:22 -0500 Subject: [whatwg] A few questions on HTML5 Message-ID: Hi, I had a few quick questions on HTML5 (I have been looking at it for about a month now, and I am fascinated by the possibilities). 1. I believe HTML5 will use no DTD, is that right? So there will be rules for HTML5 processors (browsers) that they should follow? Can you also comment as to why?? (I believe the reason is to support not well-formed HTML and still not contradict other standards.??) 2. Will XHTML5 have a DTD, because XHTML5 must be well-formed? I will have a couple of more questions based on these responses. thanks and best, murali. From Bronislav.Klucka at bauglir.com Tue Jan 3 02:45:13 2012 From: Bronislav.Klucka at bauglir.com (=?UTF-8?B?QnJvbmlzbGF2IEtsdcSNa2E=?=) Date: Tue, 03 Jan 2012 11:45:13 +0100 Subject: [whatwg] A few questions on HTML5 In-Reply-To: References: Message-ID: <4F02DC39.7000707@bauglir.com> Hi On 3.1.2012 10:32, Mani wrote: > I had a few quick questions on HTML5 (I have been looking at it for > about a month now, and I am fascinated by the possibilities). I do not want to be rude, but such questions does not belong here, this is not generic or Q&A forum, this is spec. designers technical discussion group. see http://www.whatwg.org/mailing-list http://forums.whatwg.org/bb3/index.php > 1. I believe HTML5 will use no DTD, is that right? So there will be > rules for HTML5 processors (browsers) that they should follow? Can you > also comment as to why?? (I believe the reason is to support not > well-formed HTML and still not contradict other standards.??) http://dev.w3.org/html5/spec/syntax.html#syntax http://dev.w3.org/html5/spec/parsing.html#parsing HTML5 is self contained language, not based on SGML or XML. The reason is simply due to historical baggages, which are not according to specification yet which are industry standarts. WHATWG recognized the fact that some structures may be invalid according to SGML/XML, but still can be useful / the most obvious / etc. solutions. So WHATWG simply took the reality existing on the web for 2 decades and created (is creating) language, that will be completely specified and backward compatible. To put it simply, HTML has begun to be too large and important to be bound by certain constraining rules. > 2. Will XHTML5 have a DTD, because XHTML5 must be well-formed? http://www.w3.org/TR/html5/the-xhtml-syntax.html#writing-xhtml-documents http://wiki.whatwg.org/wiki/HTML_vs._XHTML > I will have a couple of more questions based on these responses. You can find lot of answers by reading specification and other resources Spec: http://dev.w3.org/html5/spec/spec.html Differences from HTML4: http://dev.w3.org/html5/html4-differences/ Guide for developers: http://dev.w3.org/html5/html-author/ HTML5 Design principles: http://dev.w3.org/html5/html-design-principles/ Bronislav Klucka From jkorpela at cs.tut.fi Tue Jan 3 03:07:00 2012 From: jkorpela at cs.tut.fi (Jukka K. Korpela) Date: Tue, 03 Jan 2012 13:07:00 +0200 Subject: [whatwg] A few questions on HTML5 In-Reply-To: <4F02DC39.7000707@bauglir.com> References: <4F02DC39.7000707@bauglir.com> Message-ID: <4F02E154.6030308@cs.tut.fi> 2012-01-03 12:45, Bronislav Klu?ka wrote: > On 3.1.2012 10:32, Mani wrote: [?] >> 2. Will XHTML5 have a DTD, because XHTML5 must be well-formed? > http://www.w3.org/TR/html5/the-xhtml-syntax.html#writing-xhtml-documents > http://wiki.whatwg.org/wiki/HTML_vs._XHTML To find an answer to the question that was asked, one needs to read quite a lot between the lines in the cited documents. The answer appears to be ?No, XHTML5 won?t have a DTD, since you?re supposed to use a validator specifically written for HTML5.? Allowing XHTML 1.0 and XHTML 1.1 DOCTYPEs as ?obsolete but conforming? and not saying a word about any DTD that sovers any of the HTML5 novelties looks like a clear indication of intent. Well-formedness requirement does not imply the need for a DTD at all. Au contraire, ?well-formed? is just a confusing term for conformance to generic XML rules (?well-formed XML? really means nothing but ?XML?), as opposite to any rules in a DTD for example. This appears to mean that when XHTML5 is used together with other XML tag sets, you cannot use a DTD-based validator just by adding the declarations for the other tags into an XHTML5 DTD. So the question really is: will someone want to validate, say, XHTML5 + MathML documents? Yucca From xn--mlform-iua at xn--mlform-iua.no Tue Jan 3 14:34:31 2012 From: xn--mlform-iua at xn--mlform-iua.no (Leif Halvard Silli) Date: Tue, 3 Jan 2012 23:34:31 +0100 Subject: [whatwg] Default encoding to UTF-8? Message-ID: <20120103233431654515.921c1a3c@xn--mlform-iua.no> Henri Sivonen, Tue Jan 3 00:33:02 PST 2012: > On Thu, Dec 22, 2011 at 12:36 PM, Leif Halvard Silli wrote: > Making 'unicode' an alias of UTF-16 or UTF-16LE would be useful for > UTF-8-encoded pages that say charset=unicode in if alias > resolution happens before UTF-16 labels are mapped to UTF-8. Yup. > Making 'unicode' an alias for UTF-16 or UTF-16LE would be useless for > pages that are (BOMless) UTF-16LE and that have charset=unicode in > , because the prescan doesn't see UTF-16-encoded metas. Hm. Yes. I see that I misread something, and ended up believing that the would *still* be used if the mapping from 'UTF-16' to 'UTF-8' turned out to be incorrect. I guess I had not understood, well enough, that the meta prescan *really* doesn't see UTF-16-encoded metas. Also contributing was the fact that I did nto realize that IE doesn't actually read the page as UTF-16 but as Windows-1252: . (Actually, browsers does see the UTF-16 , but only if the default encoding is set to be UTF-16 - see step 1 of '8.2.2.4 Changing the encoding while parsing' .) > Furthermore, it doesn't make sense to make the prescan look for > UTF-16-encoded metas, because it would make sense to honor the value > only if it matched a flavor of UTF-16 appropriate for the pattern of > zero bytes in the file, so it would be more reliable and straight > forward to just analyze the pattern of zero bytes without bothering to > look for UTF-16-encoded s. Makes sense. [ snip ] >> What we will instead see is that those using legacy encodings must be >> more clever in labelling their pages, or else they won't be detected. > > Many pages that use legacy encodings are legacy pages that aren't > actively maintained. Unmaintained pages aren't going to become more > clever about labeling. But their Non-UTF-8-ness should be picked up in the first 1024 bytes? [... sniff - sorry, meant snip ;-) ...] > I mean the performance impact of reloading the page or, > alternatively, the loss of incremental rendering.) > > A solution that would border on reasonable would be decoding as > US-ASCII up to the first non-ASCII byte Thus possibly prescan of more than 1024 bytes? Is it faster to scan ASCII? (In Chrome, there does not seem to be an end to the prescan, as long as the text source code is ASCII only.) > and then deciding between > UTF-8 and the locale-specific legacy encoding by examining the first > non-ASCII byte and up to 3 bytes after it to see if they form a valid > UTF-8 byte sequence. Except for the specifics, that sounds like more or less the idea I tried to state. May be it could be made into a bug in Mozilla? (I could do it, but ...) However, there is one thing that should be added: The parser should default to UTF-8 even if it does not detect any UTF-8-ish non-ASCII. Is that part of your idea? Because, if it does not behave like that, then it would work as Google Chrome now does work. Which for the following, UTF-8 encoded (but charset-un-labelled) page means, that it default to UTF-8: ??? While it for this - identical - page, would default to the locale encoding, due to the use of ASCII based character entities, which causes that it does not detect any UTF-8-ish characters: æøå As weird variant of the latter example is UTF-8 based data URIs, where all browsers (that I could test - IE only supports data URIs in the @src attribute, including > > > > > ...and the browser speculatively fetches the stylesheet before the > element is in the DOM? Should the speculative parser have > knowledge of ? I would say it should handle this just like it handles tags, whether that's through keeping track of it or through the speculation failing. >> Yeah. Is there some precedent we should look to here? Perhaps the >> element? > > Perhaps this should even be an attribute on -- Note that when you have multiple tags only the _first_ takes effect, which is not the proposed behavior for ... -Boris From annevk at opera.com Fri Jan 6 07:38:35 2012 From: annevk at opera.com (Anne van Kesteren) Date: Fri, 06 Jan 2012 16:38:35 +0100 Subject: [whatwg] Encodings and the web In-Reply-To: <20111222143335.GA17055@pickering.dbaron.org> References: <20111222143335.GA17055@pickering.dbaron.org> Message-ID: On Thu, 22 Dec 2011 15:33:35 +0100, L. David Baron wrote: > This seems like one of those areas where it may be substantially > easier to figure out what implementations do by looking at their > code than by reverse-engineering, at least for the implementations > whose code is available publicly. > > Gecko's code lives in > http://mxr.mozilla.org/mozilla-central/source/intl/uconv/ . There > are others who know it substantially better, but I or others could > probably answer questions you have about how it works and how to > understand it. > > I'm not the right person for pointers to other implementations, > though. Thanks, I'm doing a combination of code inspection, reverse engineering (especially for edge cases), and applying some lessons we learned (e.g. non-greedy error handling). So far I defined the to Unicode algorithms for hz-gb-2312, euc-jp, iso-2022-jp, and shift_jis. http://dvcs.w3.org/hg/encoding/raw-file/tip/Overview.html Feedback welcome! -- Anne van Kesteren http://annevankesteren.nl/ From ian at hixie.ch Fri Jan 6 15:18:15 2012 From: ian at hixie.ch (Ian Hickson) Date: Fri, 6 Jan 2012 23:18:15 +0000 (UTC) Subject: [whatwg] Spec with Implementation Details Highlighted? In-Reply-To: <20111229091849.GA14183@stripey.com> References: <20111229091849.GA14183@stripey.com> Message-ID: On Thu, 29 Dec 2011, Smylers wrote: > > Hi there. Is there still a version of the HTML5 spec with > implementation-only parts highlighted? > > This link no longer seems to provide that feature: > http://www.whatwg.org/specs/web-apps/current-work/multipage/?style=highlight > > And I see the link to it has been removed from the FAQ, though the > 'implementors' part of the question no longer answered: > http://wiki.whatwg.org/index.php?title=FAQ&diff=7213&oldid=7212 The annotations in the spec were incomplete -- they only covered the parts of the spec that are used to generate the developers.whatwg.org version, and do not include things like Workers or the Web Sockets API. So when I collapsed the WHATWG specs into just the one, rather than having the HTML spec and the "complete.html" spec, I removed the highlights feature. If it's something you'd find useful even in its incomplete state, I can add an alternative style sheet or make the ?style=highlight URL show the annotations that are present, though. It wouldn't be something we'd advertise but if it's useful for you I'm happy to keep it around. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From ojan at chromium.org Fri Jan 6 18:47:24 2012 From: ojan at chromium.org (Ojan Vafai) Date: Fri, 6 Jan 2012 18:47:24 -0800 Subject: [whatwg] Request for feedback: supported elements for formatBlock In-Reply-To: References:

<4DDEE741.1060607@mozilla.com> Message-ID: Coming to this discussion very late. Maybe this has already been resolved. FormatBlock should be dumb. It should not try to think about what the author's intended semantics are. It should work on all block elements and should just do the simple changing of the block from whatever type it currently is to the new one (and the associated wrapping of bare inlines in a block). In order to get the wrapping behavior, we should add a new command, e.g. WrapWithBlock, that is similarly dumb and just wraps the contents with the given block element. In my experience working on the Closure editor, I have wanted both behaviors. Blockquote specifically is a case where the Closure editor has a ton of custom code to work around browsers having different behavior (or not supporting the command at all). Having both commands and having them both be simple in what they do lets authors reason about what will happen and get the output they want. It is simplest for web developers and for browser developers. Ojan On Fri, May 27, 2011 at 10:52 AM, Aryeh Gregor wrote: > On Thu, May 26, 2011 at 7:50 PM, Ehsan Akhgari wrote: > > What is IE's behavior in this case? > > IE just ignores

as an argument to formatBlock, same as if > you pass or something. That matches my current spec, but > doesn't match any non-IE browser. Gecko and Presto both try to wrap > existing elements in some fashion, which means formatBlock to >
behaves differently from formatBlock to anything else. > From Smylers at stripey.com Sat Jan 7 00:15:15 2012 From: Smylers at stripey.com (Smylers) Date: Sat, 7 Jan 2012 08:15:15 +0000 Subject: [whatwg] Spec with Implementation Details Highlighted? In-Reply-To: References: <20111229091849.GA14183@stripey.com> Message-ID: <20120107081515.GH4514@stripey.com> Ian Hickson writes: > On Thu, 29 Dec 2011, Smylers wrote: > > > Hi there. Is there still a version of the HTML5 spec with > > implementation-only parts highlighted? > > The annotations in the spec were incomplete -- they only covered the > parts of the spec that are used to generate the developers.whatwg.org > version, As it happens, that's precisely what I'm interested in. > If it's something you'd find useful even in its incomplete state, I > can add an alternative style sheet Yes, please. I found this helped with reviewing/proofreading the developer-only view. Having the 'missing' parts of the spec available to consult makes checking some thing easier, and enables spotting where too much or too little text has inadvertently been marked for the developer-only edition. Thanks. Smylers -- http://twitter.com/Smylers2 From naruse at airemix.jp Sat Jan 7 16:37:14 2012 From: naruse at airemix.jp (NARUSE, Yui) Date: Sun, 08 Jan 2012 09:37:14 +0900 Subject: [whatwg] Encodings and the web In-Reply-To: References: <20111222143335.GA17055@pickering.dbaron.org> Message-ID: <4F08E53A.70903@airemix.jp> (2012/01/07 0:38), Anne van Kesteren wrote: > On Thu, 22 Dec 2011 15:33:35 +0100, L. David Baron wrote: >> This seems like one of those areas where it may be substantially >> easier to figure out what implementations do by looking at their >> code than by reverse-engineering, at least for the implementations >> whose code is available publicly. >> >> Gecko's code lives in >> http://mxr.mozilla.org/mozilla-central/source/intl/uconv/ . There >> are others who know it substantially better, but I or others could >> probably answer questions you have about how it works and how to >> understand it. >> >> I'm not the right person for pointers to other implementations, >> though. > > Thanks, I'm doing a combination of code inspection, reverse engineering (especially for edge cases), and applying some lessons we learned (e.g. non-greedy error handling). > > So far I defined the to Unicode algorithms for hz-gb-2312, euc-jp, iso-2022-jp, and shift_jis. = Legacy multi-octet Chinese (traditional) encodings Mozilla supports another Big5 variants, Big5-UAO. http://bugs.ruby-lang.org/issues/1784 = Legacy multi-octet Japanese encodings > The jis code point for a given number is: ... > The jis0208 index for a given octet is: I wonder about this description. I should explain the concept of JIS X 0208. The most important thing is that JIS X 0208 is on the context of ISO 2022. Its target is ISO/IEC 2022 double byte 94 characters set. It means its code space is 94 x 94. http://en.wikipedia.org/wiki/JIS_X_0208 At the top, there is kuten numbers. "ku" is row, expressed by the first one of double byte code. "ten" is cell, expressed by the second one of doubye byte code. So kuten number expresses a code-point. Both ku and ten is an integer from 1 to 94. For example Hiragana Character A, its kuten number is 04-01. ISO-2022-JP, EUC-JP, and Shift_JIS map a kuten number to bytes. ISO-2022-JP's double bytes are: first: ku + 0x20 second: ten + 0x20 EUC-JP's double bytes are: first: ku + 0xA0 second: ten + 0xA0 Shift_JIS's double bytes are: first: if 1 <= ku <= 62 then (ku-1) / 2 + 0x81 elif 63 <= ku <= 94 then (ku-1) / 2 + 0xC1 second: if ku is even if 1 <= ku <= 63 then ten + 0x3F elif 64 <= ku <= 94 then ten + 0x40 elif ku is odd then ten + 0x9E So theoretically, we should make a conversion table between kuten numbers and Unicode scalar values. But as you know, "JIS X 0208" in web context should be Windows Code Page 932, extended by Microsoft. http://msdn.microsoft.com/en-us/goglobal/cc305152 It is defined by Shift_JIS. > The jis0212 index for a given octet is: As written in Bugzilla at Mozilla Bug 600715, IE doesn't support JIS X 0212. https://bugzilla.mozilla.org/show_bug.cgi?id=600715 How treat X0212 in this Encoding spec will be a problem. == iso-2022-jp === The to Unicode algorithm ==== Based on iso-2022-jp state ===== ASCII state ====== Based on octet: ======= Otherwise > If the fatal flag is set, return failure. > Otherwise, emit the fallback code point. Just FYI, IE and Opera show these bytes as Katakana. If octet is greater than 0xA0 and less than 0xE0, value is octet + 0xFEC0. Moreover IE shows any shift_jis characters here. It seems that IE uses the same converter both iso-2022-jp and shift_jis. -- NARUSE, Yui From annevk at opera.com Sun Jan 8 06:32:47 2012 From: annevk at opera.com (Anne van Kesteren) Date: Sun, 08 Jan 2012 15:32:47 +0100 Subject: [whatwg] Encodings and the web In-Reply-To: <4F08E53A.70903@airemix.jp> References: <20111222143335.GA17055@pickering.dbaron.org> <4F08E53A.70903@airemix.jp> Message-ID: On Sun, 08 Jan 2012 01:37:14 +0100, NARUSE, Yui wrote: > = Legacy multi-octet Chinese (traditional) encodings > > Mozilla supports another Big5 variants, Big5-UAO. > http://bugs.ruby-lang.org/issues/1784 As part of the big5 encoding, right? It sounds like it's a good idea to adopt that. I don't think there's much concern about table size these days, though obviously the less complexity the better. > = Legacy multi-octet Japanese encodings > >> The jis code point for a given number is: ... >> The jis0208 index for a given octet is: > > I wonder about this description. > I should explain the concept of JIS X 0208. > > The most important thing is that JIS X 0208 is on the context of ISO > 2022. > Its target is ISO/IEC 2022 double byte 94 characters set. > It means its code space is 94 x 94. > http://en.wikipedia.org/wiki/JIS_X_0208 > > At the top, there is kuten numbers. > "ku" is row, expressed by the first one of double byte code. > "ten" is cell, expressed by the second one of doubye byte code. > So kuten number expresses a code-point. > Both ku and ten is an integer from 1 to 94. > For example Hiragana Character A, its kuten number is 04-01. > > ISO-2022-JP, EUC-JP, and Shift_JIS map a kuten number to bytes. > ISO-2022-JP's double bytes are: > first: ku + 0x20 > second: ten + 0x20 > EUC-JP's double bytes are: > first: ku + 0xA0 > second: ten + 0xA0 > Shift_JIS's double bytes are: > first: if 1 <= ku <= 62 then (ku-1) / 2 + 0x81 > elif 63 <= ku <= 94 then (ku-1) / 2 + 0xC1 > second: if ku is even > if 1 <= ku <= 63 then ten + 0x3F > elif 64 <= ku <= 94 then ten + 0x40 > elif ku is odd then ten + 0x9E > > > So theoretically, we should make a conversion table between > kuten numbers and Unicode scalar values. > > But as you know, "JIS X 0208" in web context should be Windows Code Page > 932, > extended by Microsoft. > http://msdn.microsoft.com/en-us/goglobal/cc305152 > It is defined by Shift_JIS. > >> The jis0212 index for a given octet is: > > As written in Bugzilla at Mozilla Bug 600715, IE doesn't support JIS X 0212. > https://bugzilla.mozilla.org/show_bug.cgi?id=600715 > How treat X0212 in this Encoding spec will be a problem. Yeah so currently I used Gecko's approach (roughly) towards Japanese encodings, including how they put both 0208 and 0212 in a single longish array. But maybe instead I should write it down as it has been done by Unicode.org, with double-octet sequence mapping to a Unicode character. Suggestions welcome. With respect to 0212, it's not that hard to support it and given how long it has been deployed this way it's probably safer to keep it there I think. > == iso-2022-jp > === The to Unicode algorithm > ==== Based on iso-2022-jp state > ===== ASCII state > ====== Based on octet: > ======= Otherwise >> If the fatal flag is set, return failure. >> Otherwise, emit the fallback code point. > > Just FYI, IE and Opera show these bytes as Katakana. > If octet is greater than 0xA0 and less than 0xE0, value is octet + > 0xFEC0. > > Moreover IE shows any shift_jis characters here. > It seems that IE uses the same converter both iso-2022-jp and shift_jis. I have filed a bug on Opera to become more strict like Webkit/Gecko. If there is some evidence that approach is wrong though, we can turn it around. -- Anne van Kesteren http://annevankesteren.nl/ From naruse at airemix.jp Sun Jan 8 07:20:45 2012 From: naruse at airemix.jp (NARUSE, Yui) Date: Mon, 09 Jan 2012 00:20:45 +0900 Subject: [whatwg] Encodings and the web In-Reply-To: References: <20111222143335.GA17055@pickering.dbaron.org> <4F08E53A.70903@airemix.jp> Message-ID: <4F09B44D.4080804@airemix.jp> (2012/01/08 23:32), Anne van Kesteren wrote: > On Sun, 08 Jan 2012 01:37:14 +0100, NARUSE, Yui wrote: >> = Legacy multi-octet Chinese (traditional) encodings >> >> Mozilla supports another Big5 variants, Big5-UAO. >> http://bugs.ruby-lang.org/issues/1784 > > As part of the big5 encoding, right? It sounds like it's a good idea to adopt that. I don't think there's much concern about table size these days, though obviously the less complexity the better. CC to the original reporter. Could you cooperate about current situation in Taiwan? >> == iso-2022-jp >> === The to Unicode algorithm >> ==== Based on iso-2022-jp state >> ===== ASCII state >> ====== Based on octet: >> ======= Otherwise >>> If the fatal flag is set, return failure. >>> Otherwise, emit the fallback code point. >> >> Just FYI, IE and Opera show these bytes as Katakana. >> If octet is greater than 0xA0 and less than 0xE0, value is octet + 0xFEC0. >> >> Moreover IE shows any shift_jis characters here. >> It seems that IE uses the same converter both iso-2022-jp and shift_jis. > > I have filed a bug on Opera to become more strict like Webkit/Gecko. If there is some evidence that approach is wrong though, we can turn it around. There is a old variant of ISO-2022-JP called "JIS8". JIS8 is used before RFC1468 is written, and still used in some area, for exapmle bank-to-bank information exchange. JIS8's "8" means 8bit byte to express Katakana, which is just described above. So I can't state it is a bug on Opera at this time. It is depend on how many sites uses such 8bit Katakana. -- NARUSE, Yui From naruse at airemix.jp Sun Jan 8 08:06:43 2012 From: naruse at airemix.jp (NARUSE, Yui) Date: Mon, 09 Jan 2012 01:06:43 +0900 Subject: [whatwg] Encodings and the web In-Reply-To: References: <20111222143335.GA17055@pickering.dbaron.org> <4F08E53A.70903@airemix.jp> <4F09B44D.4080804@airemix.jp> Message-ID: <4F09BF13.5030603@airemix.jp> Hi, thank you for quick reply, (2012/01/09 0:38), Lin Jen-Shin (godfat) wrote: > On Sun, Jan 8, 2012 at 11:20 PM, NARUSE, Yui wrote: >> (2012/01/08 23:32), Anne van Kesteren wrote: >>> On Sun, 08 Jan 2012 01:37:14 +0100, NARUSE, Yui wrote: >>>> = Legacy multi-octet Chinese (traditional) encodings >>>> >>>> Mozilla supports another Big5 variants, Big5-UAO. >>>> http://bugs.ruby-lang.org/issues/1784 >>> >>> As part of the big5 encoding, right? It sounds like it's a good idea to adopt that. I don't think there's much concern about table size these days, though obviously the less complexity the better. >> >> CC to the original reporter. >> Could you cooperate about current situation in Taiwan? > > I am not sure what I can do here, but I would try my best to > coordinate if there's anything I could help. > > So what are we trying to solve here, again? This is the thread from http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-December/034241.html And discussing about a spec about Encoding on the web. http://dvcs.w3.org/hg/encoding/raw-file/tip/Overview.html I'm interesting about whether web browsers other than Mozilla should implement Big5-UAO or not. Thanks, -- NARUSE, Yui From annevk at opera.com Sun Jan 8 11:49:56 2012 From: annevk at opera.com (Anne van Kesteren) Date: Sun, 08 Jan 2012 20:49:56 +0100 Subject: [whatwg] iso-2022-jp and octets over 0x7E In-Reply-To: References: <20111222143335.GA17055@pickering.dbaron.org> <4F08E53A.70903@airemix.jp> Message-ID: On Sun, 08 Jan 2012 15:32:47 +0100, Anne van Kesteren wrote: > On Sun, 08 Jan 2012 01:37:14 +0100, NARUSE, Yui > wrote: >> == iso-2022-jp >> === The to Unicode algorithm >> ==== Based on iso-2022-jp state >> ===== ASCII state >> ====== Based on octet: >> ======= Otherwise >>> If the fatal flag is set, return failure. >>> Otherwise, emit the fallback code point. >> >> Just FYI, IE and Opera show these bytes as Katakana. >> If octet is greater than 0xA0 and less than 0xE0, value is octet + >> 0xFEC0. >> >> Moreover IE shows any shift_jis characters here. >> It seems that IE uses the same converter both iso-2022-jp and shift_jis. > > I have filed a bug on Opera to become more strict like Webkit/Gecko. If > there is some evidence that approach is wrong though, we can turn it > around. So just to be sure I checked again and in Opera you can only get the "special" single-octet behavior if you active a particular state first. If you are in ASCII, Opera will simply emit the octet unless it is 0x1B (ESC) so maybe there is a system font that does something special for those characters? Or maybe you meant something else? -- Anne van Kesteren http://annevankesteren.nl/ From naruse at airemix.jp Sun Jan 8 13:03:37 2012 From: naruse at airemix.jp (NARUSE, Yui) Date: Mon, 09 Jan 2012 06:03:37 +0900 Subject: [whatwg] iso-2022-jp and octets over 0x7E In-Reply-To: References: <20111222143335.GA17055@pickering.dbaron.org> <4F08E53A.70903@airemix.jp> Message-ID: <4F0A04A9.2040906@airemix.jp> (2012/01/09 4:49), Anne van Kesteren wrote: > On Sun, 08 Jan 2012 15:32:47 +0100, Anne van Kesteren wrote: >> On Sun, 08 Jan 2012 01:37:14 +0100, NARUSE, Yui wrote: >>> == iso-2022-jp >>> === The to Unicode algorithm >>> ==== Based on iso-2022-jp state >>> ===== ASCII state >>> ====== Based on octet: >>> ======= Otherwise >>>> If the fatal flag is set, return failure. >>>> Otherwise, emit the fallback code point. >>> >>> Just FYI, IE and Opera show these bytes as Katakana. >>> If octet is greater than 0xA0 and less than 0xE0, value is octet + 0xFEC0. >>> >>> Moreover IE shows any shift_jis characters here. >>> It seems that IE uses the same converter both iso-2022-jp and shift_jis. >> >> I have filed a bug on Opera to become more strict like Webkit/Gecko. If there is some evidence that approach is wrong though, we can turn it around. > > So just to be sure I checked again and in Opera you can only get the "special" single-octet behavior if you active a particular state first. If you are in ASCII, Opera will simply emit the octet unless it is 0x1B (ESC) so maybe there is a system font that does something special for those characters? Or maybe you meant something else? Ah, you are correct. Opera's behavior is different from IE and it is clearly wrong. -- NARUSE, Yui From simonp at opera.com Mon Jan 9 00:53:51 2012 From: simonp at opera.com (Simon Pieters) Date: Mon, 09 Jan 2012 09:53:51 +0100 Subject: [whatwg] Feedback on Meta referrer In-Reply-To: <4F05DFC1.9010003@mit.edu> References: <4EFF49F5.9090208@gmail.com> <4F05DFC1.9010003@mit.edu> Message-ID: On Thu, 05 Jan 2012 18:37:05 +0100, Boris Zbarsky wrote: > On 1/2/12 1:55 AM, Simon Pieters wrote: >> What about: >> >> >> >> >> >> >> >> ...and the browser speculatively fetches the stylesheet before the >> element is in the DOM? Should the speculative parser have >> knowledge of ? > > I would say it should handle this just like it handles tags, > whether that's through keeping track of it or through the speculation > failing. OK, so the speculative parser needs to scan for the feature. My thinking was that the speculative parser currently doesn't need to look at , but it does look at , and usually there's zero or one but can be lots of s, so it could be slightly cheaper to put this on compared to . Maybe the difference is negligible, though. >>> Yeah. Is there some precedent we should look to here? Perhaps the >>> element? >> >> Perhaps this should even be an attribute on -- > referrer="..."> > > Note that when you have multiple tags only the _first_ takes > effect, Only for the same attribute -- if you have one and one they both get applied. (Which still isn't the proposed behavior for , I know.) > which is not the proposed behavior for ... -- Simon Pieters Opera Software From ian at hixie.ch Mon Jan 9 15:17:13 2012 From: ian at hixie.ch (Ian Hickson) Date: Mon, 9 Jan 2012 23:17:13 +0000 (UTC) Subject: [whatwg] Spec with Implementation Details Highlighted? In-Reply-To: <20120107081515.GH4514@stripey.com> References: <20111229091849.GA14183@stripey.com> <20120107081515.GH4514@stripey.com> Message-ID: On Sat, 7 Jan 2012, Smylers wrote: > > > > If it's something you'd find useful even in its incomplete state, I > > can add an alternative style sheet > > Yes, please. Roger. I've added an alternative style sheet set that has a rule for .impl sections for you. HTH. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From ian at hixie.ch Mon Jan 9 15:46:41 2012 From: ian at hixie.ch (Ian Hickson) Date: Mon, 9 Jan 2012 23:46:41 +0000 (UTC) Subject: [whatwg] [Bug 12287] Restrict sequence to operation argument types and return types In-Reply-To: <252ccf4477ffac6d67339189ebd5104c.squirrel@default> References: <252ccf4477ffac6d67339189ebd5104c.squirrel@default> Message-ID: On Mon, 23 May 2011, andrew at ado.is-a-geek.net wrote: > http://www.w3.org/Bugs/Public/show_bug.cgi?id=12287: > > sequence has undesirable behaviour in JS when used as an attribute > > value, so we should consider preventing its use there. > > HTML5 Section 10: > > typedef sequence MessagePortArray; > > > > interface MessageEvent : Event { > > readonly attribute any data; > > readonly attribute DOMString origin; > > readonly attribute DOMString lastEventId; > > readonly attribute WindowProxy source; > > readonly attribute MessagePortArray ports; > > void initMessageEvent(...); > > }; > > The WebIDL specification has been changed so the MessageEvent interface > in HTML5 is no longer valid. This only appears to have been implemented > by Opera at the moment, and it returns the same ECMAScript Array every > time it is called. I would guess this can still be changed given that > it is not widely implemented. > > Can MessagePortArray be changed to be some kind of collection like many > of the other places in DOM when we want a list of children? This would > probably be easiest for me, but perhaps there is a better way. I believe this has since been fixed; the spec now uses MessagePort[] as the type for MessageEvent.ports. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From ian at hixie.ch Mon Jan 9 15:52:50 2012 From: ian at hixie.ch (Ian Hickson) Date: Mon, 9 Jan 2012 23:52:50 +0000 (UTC) Subject: [whatwg] Proposal to remove a paragraph from canvas spec In-Reply-To: References: Message-ID: On Tue, 5 Jul 2011, Robert O'Callahan wrote: > On Tue, May 31, 2011 at 9:40 AM, Robert O'Callahan wrote: > > On Fri, May 13, 2011 at 5:53 PM, Ian Hickson wrote: > > > >> On Fri, 13 May 2011, Robert O'Callahan wrote: > >> > > >> > Can you put a note in the spec that we're thinking of changing this > >> > behavior, so developers are less likely to start depending on it, > >> > and we've got some cover in case it breaks some esoteric stuff that > >> > doesn't matter for compat? > >> > >> Done. > >> > > > > Thanks. I made this change on mozilla-central so it should appear in > > Firefox 7 about 18 weeks from now --- unless we detect that it breaks > > the Web. > > It breaks the Web, so we're backing it out. > > It turns out that a lot of canvas apps set up a shadow color and blur, > do some drawing, then disable the shadow by setting the blur to zero. > With the proposed change, those apps often render incorrectly, and > worse, they often render more slowly. Should we still make shadows only work in source-over mode, or should we leave the spec as is in this area? -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From ian at hixie.ch Mon Jan 9 16:10:26 2012 From: ian at hixie.ch (Ian Hickson) Date: Tue, 10 Jan 2012 00:10:26 +0000 (UTC) Subject: [whatwg] DOMContentLoaded, load and current document readiness In-Reply-To: <1306832542.2453.27.camel@shuttle> References: <1306832542.2453.27.camel@shuttle> Message-ID: On Tue, 31 May 2011, Henri Sivonen wrote: > > Recently, there was discussion about changing media element state in the > same task that fires the event about the state change so that scripts > that probe the state can make non-racy conclusions about whether a > certain event has fired already. > > Currently, there seems to be no correct non-racy way to write code that > probes a document to determine if DOMContentLoaded or load has fired and > runs code immediately if the event of interest has fired or adds a > listener to wait for the event if the event hasn't fired. > > Are there compat or other reasons why we couldn't or shouldn't make it > so that the same task that fires DOMContentLoaded changes the readyState > to "interactive" and the same task that fires load changes readyState to > "complete"? Fixed for 'load'. I don't see a good way to fix this for 'DOMContentLoaded', unfortunately. Note that 'readystatechange' events do fire synchronously with 'readyState' changes so you can always just use that instead of 'DOMContentLoaded' and 'load'. I haven't changed 'pageshow', so you could still get code running between 'load' and 'pageshow'. Let me know if you think we should merge those into one task as well. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From robert at ocallahan.org Mon Jan 9 18:41:32 2012 From: robert at ocallahan.org (Robert O'Callahan) Date: Tue, 10 Jan 2012 15:41:32 +1300 Subject: [whatwg] Proposal to remove a paragraph from canvas spec In-Reply-To: References: Message-ID: On Tue, Jan 10, 2012 at 12:52 PM, Ian Hickson wrote: > Should we still make shadows only work in source-over mode, or should we > leave the spec as is in this area? > It's probably not worth changing the spec at this time. I think it would be a bit simpler, and if we run into problems with shadows and non-over operators (author confusion, implementation issues) then I think we could still do it. Rob -- "If we claim to be without sin, we deceive ourselves and the truth is not in us. If we confess our sins, he is faithful and just and will forgive us our sins and purify us from all unrighteousness. If we claim we have not sinned, we make him out to be a liar and his word is not in us." [1 John 1:8-10] From tantek at cs.stanford.edu Mon Jan 9 21:48:03 2012 From: tantek at cs.stanford.edu (=?UTF-8?Q?Tantek_=C3=87elik?=) Date: Mon, 9 Jan 2012 21:48:03 -0800 Subject: [whatwg] should we add beforeload/afterload events to the web platform? Message-ID: WebKit supports a 'beforeload' event [1] which is supported in shipping Safari and Chrome[2] and apparently has (enabled) the real-world use-cases of: 1. Performance. Reducing bandwidth use / HTTP requests, e.g. AdBlock extension[2] 2. Clientside transformations, e.g. Mobify[3] As might be expected, there is at least one use-case for a complementary 'afterload' event: 1. Downloadable fonts - people who want to use custom fonts for drawing in the canvas element need to know when a font has loaded. 'afterload' seems like a good way to know that, since it happens as a side effect of actually using it and fonts don't have an explicit load API like images do.[4] Safari and Chrome have already shipped 'beforeload', and Mozilla is strongly considering implementing 'beforeload' and 'afterload'.[4] Should 'beforeload'/'afterload' be explicitly specified and added to the web platform? Rather than attempt to provide a specific detailed design at this point, I'd prefer to ask for the list's consideration/discussion, and leave detailed specification of the two events to the editor. Thanks, Tantek [1] http://developer.apple.com/library/safari/documentation/Tools/Conceptual/SafariExtensionGuide/MessagesandProxies/MessagesandProxies.html [2] http://google-chrome-browser.com/tags/beforeload [3] http://mobify.com/static/talks/client-side-transformations.html#27 [4] https://bugzilla.mozilla.org/show_bug.cgi?id=715695#c9 -- http://tantek.com/ - I made an HTML5 tutorial! http://tantek.com/html5 From bzbarsky at MIT.EDU Mon Jan 9 22:02:00 2012 From: bzbarsky at MIT.EDU (Boris Zbarsky) Date: Tue, 10 Jan 2012 01:02:00 -0500 Subject: [whatwg] should we add beforeload/afterload events to the web platform? In-Reply-To: References: Message-ID: <4F0BD458.1060701@mit.edu> On 1/10/12 12:48 AM, Tantek ?elik wrote: > Mozilla is strongly considering implementing 'beforeload' and 'afterload'.[4] It's more like one person in a Mozilla bug has suggested that it be implemented, while others, myself included, are a bit skeptical. The devil, of course, is in the details; if this event is specified very carefully it might simply slow down pageload a bit, more so as browsers introduce more parallelism because background threads or processes that might be able to perform the load will have to block on the main page JS thread to handle the event first. If done carelessly (e.g. the event target is the node the load is associated with), it'll be a pretty large slowdown. For example, that approach precludes the sort of speculative parsers UAs use nowadays to deal with having to block parsing on The slowResponse.cgi script takes N seconds to respond where N is passed in the "time" parameter. When I load this testcase in either Chrome or Safari, I see the "load of one" start at about 1ms into the timeline an finish about 4s into the timeline. I see the "load of two" start about 4s into the timeline and finish about 5s into the timeline. Since the "load of two" actually takes at least 5s from when it starts, that means that the load really started about 4s before the "beforeload" event fired. So in WebKit this event is only good for preventing _processing_ of the data in the page (e.g. preventing the script from executing when the target is a Firefox will still most likely start fetching foo.jpg (by design). That said, please do include the images, etc., you want fetched in the source. If you do want foo.jpg fetched, saying in the HTML source is a latency win over letting a script cause the fetch. To the extent the problem is that you don't know what you want fetched before probing the client characteristics, I think adding JS APIs is not the right solution. The right solutions are: 1) If cruft is optional, don't give the cruft to anyone. If there's a bunch of inessential scripts that you don't want mobile browsers to load, don't give them do desktop browsers, either. 2) Making the client probing declarative. If there is a true, broad and persistent (longer than, say, 2 years) need to load different images based on client characteristics, we should introduce a declarative way to pick the desired image. Something along the lines of -- Henri Sivonen hsivonen at iki.fi http://hsivonen.iki.fi/ From philipj at opera.com Fri Jan 13 05:34:53 2012 From: philipj at opera.com (=?utf-8?Q?Philip_J=C3=A4genstedt?=) Date: Fri, 13 Jan 2012 14:34:53 +0100 Subject: [whatwg] video element not ready for prime time In-Reply-To: References: Message-ID: On Fri, 13 Jan 2012 01:53:23 +0100, Aryeh Gregor wrote: > On Thu, Jan 12, 2012 at 12:46 PM, Francis Boumphrey > wrote: >> e.g.