| 00:02 | annevk | tries to participate in the WebSockets debate for a bit |
| 00:02 | annevk | should go to sleep really |
| 00:04 | <TabAtkins> | Awesome. http://www.fileformat.info/convert/text/punycode-encoder-decoder.htm doesn't declare a charset, and so is autodetecting to something other than unicode, making it impossible to use the page for what it is intended for. |
| 00:06 | <Lachy> | HTTP/1.x 200 OK |
| 00:06 | <Lachy> | Content-Type: text/html;charset=utf-8 |
| 00:06 | <Lachy> | seems to be declaring it for me |
| 00:07 | <TabAtkins> | Hmm. Well, something's wrong then. It's giving me back a bad punycode. |
| 00:07 | <Lachy> | check which encoding your browser is actually using |
| 00:08 | <Lachy> | the bug appears to be a problem with the site's cgi script. |
| 00:09 | <TabAtkins> | Yeah, looks like it. Luckily I haven't submitted the feedback yet! |
| 00:09 | <Lachy> | I guess it's trying to read the input as if it were encoded as ISO-8859-1 instead of UTF-8 |
| 00:14 | <TabAtkins> | That'd be my guess, since it's turning "bücher" into "bücher". |
| 00:14 | <TabAtkins> | Also: there appears to be only a single working online punycode encoder. >_< Luckily it's the first google result. |
| 02:26 | <MikeSmith> | Hixie: spec says the content model of figure is limited to figcaption and phrasing content |
| 02:26 | <MikeSmith> | but you have an example there of a figure that contains a p element |
| 07:58 | <hsivonen> | annevk: Is Opera's current initial about:blank loading into a browsing context behavior considered sufficiently Web-compatible by Opera devs? |
| 08:18 | <gsnedders> | hsivonen: Wich part of it? There are parts that aren't. |
| 08:19 | <foolip> | Lachy: I'm here |
| 08:19 | foolip | has a look |
| 08:20 | <hsivonen> | gsnedders: 1) creating the initial about:blank DOM synchronously, 2) not scheduling a normal load for about:blank that'd overwrite the initial about:blank, 3) firing a 'load' event for the initial about:blank and 4) firing the 'load' event async |
| 08:20 | <hsivonen> | gsnedders: can you say which parts aren't? |
| 08:21 | <hsivonen> | as far as I can tell, there a the four behaviors out there: Gecko, WebKit/IE, Opera and spec |
| 08:22 | <hsivonen> | given the data available to me, I tentatively consider Opera's behavior most desirable here |
| 08:22 | <foolip> | Lachy: I'm afraid I'm just doing what the spec says: http://www.whatwg.org/specs/web-apps/current-work/multipage/microdata.html#conversion-to-vcard |
| 08:22 | <gsnedders> | hsivonen: That's fine |
| 08:22 | <foolip> | Lachy: only the first additional-name is used |
| 08:22 | <hsivonen> | although it's scary that WebKit/IE have their behavior in common |
| 08:22 | <gsnedders> | hsivonen: The problems relate to iframes created through DOM before the body element |
| 08:22 | <hsivonen> | gsnedders: thanks |
| 08:22 | <gsnedders> | hsivonen: (at least I'm unaware of any issues with it) |
| 08:22 | <gsnedders> | (and I spent a while looking at this a few months ago) |
| 08:23 | <foolip> | Lachy: write to the list and I'll align with whatever the spec changes to |
| 08:26 | <Lachy> | foolip, ok. I was looking at the actual vCard RFC, which allows multiple occurrences of those fields, so I'll report the spec bugs shortly |
| 08:27 | <foolip> | Lachy: good, perhaps you can look over the other fields and see if there are other discrepancies too? |
| 08:27 | <hsivonen> | Is Google's JSON-C still JSON but with more compact structures that in their existing JSON APIs_ |
| 08:27 | <hsivonen> | ? |
| 08:28 | <hsivonen> | or is JSON-C modifying JSON itself? |
| 08:42 | <Lachy> | foolip, unfortunately, RFC 2426 isn't entirely clear. :-( It states: |
| 08:42 | <Lachy> | Type special note: The structured type value corresponds, in |
| 08:42 | <Lachy> | sequence, to the Family Name, Given Name, Additional Names, Honorific |
| 08:42 | <Lachy> | Prefixes, and Honorific Suffixes. The text components are separated |
| 08:42 | <Lachy> | by the SEMI-COLON character (ASCII decimal 59). Individual text |
| 08:42 | <Lachy> | components can include multiple text values (e.g., multiple |
| 08:42 | <Lachy> | Additional Names) separated by the COMMA character |
| 08:44 | <Lachy> | It doesn't explicitly specify which fields allow multiple values and which cannot, suggesting they all cane. Although with it using the plural of Additional Names, Honorific Prefixes and Suffixes, suggesting that it's only those 3 that can. |
| 08:44 | <Lachy> | s/cane/can/ |
| 08:44 | <jgraham> | But it has the character names in all caps! |
| 08:44 | <jgraham> | What could be clearer than that |
| 08:44 | <jgraham> | ? |
| 08:46 | <Lachy> | I do know someone here in Norway with 2 first names and 2 last names, and she insists that they're not middle names even though they're not hyphenated. So I'm inclined to say that all fields can contain multiple values. |
| 09:06 | <virtuelv> | Lachy: that person would be wrong |
| 09:06 | <virtuelv> | unless hyphenated, the last name is one word only |
| 09:06 | <virtuelv> | you can have as many first and middle names as you want |
| 09:09 | <virtuelv> | § 7. Doble etternavn |
| 09:09 | <virtuelv> | To navn som kan tas som etternavn, kan tas som et dobbelt etternavn der de to navnene er satt sammen med bindestrek. I forhold til §§ 3 og 4 regnes et dobbelt etternavn som to adskilte etternavn. |
| 09:10 | <virtuelv> | § 7 Doble surname |
| 09:10 | <virtuelv> | Two names that can be taken as a last name, can be taken as a double last name, where the two names are put together with a hyphen. In relation to § § 3 and 4 is considered a double last name as two separate surnames. |
| 09:10 | <virtuelv> | From http://www.lovdata.no/all/tl-20020607-019-002.html |
| 09:10 | <hsivonen> | virtuelv: what's the semantic role of Wium in howcome's name? |
| 09:10 | <virtuelv> | it would be his middle name |
| 09:11 | <virtuelv> | there might be exceptions for some names |
| 09:11 | <hsivonen> | virtuelv: is it the same kind of middle name as in English and not the kind of middle name that occurs in Danish? |
| 09:11 | <virtuelv> | von Tetzchner, or von Koengisegg |
| 09:12 | <virtuelv> | hsivonen: this is covered by § 9 |
| 09:12 | <virtuelv> | which says that all acceptable last names are acceptable middle names |
| 09:13 | <hsivonen> | virtuelv: ah. so that permits Danish names in Norway |
| 09:14 | <virtuelv> | colloquially, though, people may refer to an unused first name as a middle name |
| 09:15 | <hsivonen> | it seems to me that the Norwegian statute has the same bug as the Finnish statute |
| 09:15 | <hsivonen> | it doesn't state the permitted character repertoire and length of the names |
| 09:16 | <hsivonen> | (or I'm bad at skimming Norwegian text) |
| 09:16 | <virtuelv> | there is no limit on the length |
| 09:16 | <virtuelv> | and there is, as far as I can tell no limit on the character repertoire |
| 09:16 | <virtuelv> | on the length thing: http://www.huffingtonpost.com/2009/09/11/julius-andreas-gimli-arn_n_284276.html |
| 09:17 | <hsivonen> | virtuelv: if a Russian-born person gets Norwegian citizenship, are cyrillic letters printed on the passport? |
| 09:17 | <virtuelv> | (Yes, he did indeed misspell Chewbacca) |
| 09:17 | <virtuelv> | hsivonen: I don't know |
| 09:19 | <hsivonen> | an Estonian-born person with a Russian name who got the Finnish citizenship told me that there was a mandatory algorithmic mapping to the Latin script |
| 09:19 | <virtuelv> | note that for that guy, only elessar-jankov is last name, as evidenced by the first line of his driver's license |
| 09:19 | <hsivonen> | it bothers me that I can't find the specs for this stuff |
| 09:19 | <virtuelv> | hsivonen: if there is, it isn't written in law, at least |
| 09:20 | <virtuelv> | then again, I live in a country where the tax algorithm is described in terms of a 1300-line COBOL program |
| 09:23 | <hsivonen> | there's definitely a limit on how many characters fit on the optically-readable part of a passport |
| 09:23 | <virtuelv> | yeah |
| 09:23 | <foolip> | virtuelv: there are plenty of Swedes with two surnames without hyphen |
| 09:23 | <virtuelv> | he had to drop highlander from his passport |
| 09:24 | <hsivonen> | and there's a German-oriented ASCII-ification of names for the optically readable part |
| 09:24 | <foolip> | (mostly people who couldn't decide which name to take when getting married) |
| 09:25 | hsivonen | has wondered what happens if a person with an umlauted name tries to travel to the U.S. these days and applies a conversion that Finns or Swedes would apply naturally |
| 09:33 | <pesla> | What are the main reasons for the html5 spec to not demand closing your tags? |
| 09:34 | <Hixie> | which tags? |
| 09:34 | <pesla> | Tags of which the end tag can now be omitted |
| 09:34 | <hsivonen> | pesla: backward compat with HTML4 authoring |
| 09:35 | <Hixie> | didn't seem to be helpful to require them |
| 09:35 | <Hixie> | i like omitting tags |
| 09:35 | <Hixie> | :-) |
| 09:35 | <hsivonen> | pesla: those tags were optional in HTML4, too |
| 09:35 | <hsivonen> | pesla: also, it's nice to less to type when writing test cases |
| 09:35 | <pesla> | I know, but what problems would arise if the html5 spec demands it? |
| 09:35 | <hsivonen> | s/to less/to have less/ |
| 09:35 | <Hixie> | pesla: i'd be less happy |
| 09:35 | <Hixie> | pesla: and my fingers would hurt more |
| 09:35 | <pesla> | But I think a lot of frontend devvers would be happier |
| 09:35 | <hsivonen> | pesla: migrating from HTML4 to HTML5 becomes more tedious for no good reason |
| 09:36 | <Hixie> | pesla: they can include them if they like |
| 09:36 | <hsivonen> | pesla: they are free to do the additional typing |
| 09:36 | <Hixie> | pesla: they can even write validators that warn if you omit them |
| 09:36 | <pesla> | There is no benefit to omit the closing tag is there? Apart from writing less ;) |
| 09:36 | <pesla> | (Mind my crappy english :() |
| 09:36 | <hsivonen> | (or they can wait for Firefox to ship with the HTML5 parser and then me fixing the validator) |
| 09:37 | <hsivonen> | pesla: writing less is a benefit |
| 09:37 | <hsivonen> | pesla: check out the SGML spec |
| 09:37 | <hsivonen> | pesla: it's full of "to avoid repetitive keying" |
| 09:37 | <virtuelv> | hsivonen: although, reading the sgml spec is a cruical part on the path to insanity :D |
| 09:37 | <Lachy> | virtuelv, Norwegian rules about naming don't apply everywhere. My sister in law, when she married my elder brother, changed her last name from Wedgewood to Wedgewood Hunt. So technically, she has two last names now. |
| 09:38 | <virtuelv> | Lachy: yes, but I was refering to Norway, and what the law here says on names |
| 09:38 | <virtuelv> | either way, and back to microdata and contact formats |
| 09:38 | <virtuelv> | it's so complex that |
| 09:39 | <virtuelv> | a) Devising an algorithm for extracting names from a single field is not feasible |
| 09:39 | <virtuelv> | b) Having format constraints for first/middle/last names is not feasible |
| 09:39 | <hsivonen> | names in hCard are a rathole unless the name is of the form Given Surname |
| 09:39 | <virtuelv> | c) You can't use the terms I used in b) for names |
| 09:39 | <virtuelv> | because of countries where the last name is the first |
| 09:40 | <qfox> | hi |
| 09:40 | <hsivonen> | hi |
| 09:40 | <virtuelv> | as I understand it, people in Iceland don't really have last names |
| 09:40 | <virtuelv> | their phone book is sorted by first name |
| 09:40 | <qfox> | pesla's question was kind of because of me, i guess |
| 09:40 | <jgraham> | No they have names like Jonsdottir |
| 09:40 | <pesla> | lol |
| 09:40 | <jgraham> | sp? |
| 09:40 | <jgraham> | (Mean's Jon's daughter) |
| 09:41 | <virtuelv> | jgraham: yes, but I'm not sure they qualify as "last" names |
| 09:41 | <jgraham> | *meaning |
| 09:41 | <virtuelv> | because they are certainly not last names in the sense we use last names in the rest of the world, which is "family name" |
| 09:41 | <jgraham> | virtuelv: Well not in the traditional sense of family names. But they are typically written after their given name |
| 09:41 | <qfox> | so the only reason for closing tags not being in the spec would be to prevent cruft? |
| 09:41 | <hsivonen> | jgraham: aren't the *dottir names just for compat with the rest of the world? |
| 09:42 | <qfox> | apart from potential compat problems between html5 and older versions... |
| 09:42 | <annevk> | hsivonen, I recall we had some trouble with it in the past, but our current behavior is ok afaik |
| 09:42 | <hsivonen> | qfox: they are a compat problem in these cases: <p><table>, <p><article> |
| 09:42 | <hsivonen> | annevk: thanks |
| 09:42 | <jgraham> | hsivonen: I was under the impression that they were a long-time naming tradition. But it's not like I'm an iceland guru or anything |
| 09:43 | <qfox> | hsivonen: in what regard exactly? |
| 09:43 | <hsivonen> | qfox: so omitting </p> is contextually dangerous |
| 09:43 | <qfox> | yes, but that's not against putting it in the standard... |
| 09:43 | <Lachy> | virtuelv, the spec uses given-name and family-name anyway, so the cultural issues of first vs. last names is irrelevant. |
| 09:43 | <qfox> | i'm wondering why the tags arent forced to be closed by the spec |
| 09:43 | <hsivonen> | qfox: omitting <html>, </html>, <body>, </body>, <head>, </head>, <tbody> or </tbody> is totally safe |
| 09:43 | <qfox> | i understand that |
| 09:44 | <qfox> | but it is also very error prone |
| 09:44 | <virtuelv> | Lachy: "family-name" is a cultural issue |
| 09:44 | <hsivonen> | qfox: <p><table> depends on quirks vs. standards |
| 09:44 | <qfox> | especially to people new to html |
| 09:44 | <jgraham> | http://en.wikipedia.org/wiki/Icelandic_name |
| 09:44 | <hsivonen> | qfox: <p><article> depends on legacy parser vs. HTML5 parser |
| 09:44 | <qfox> | i'm sure it is, however, those should have a doctype telling the browser what behavior should be executed |
| 09:44 | <virtuelv> | Lachy: see jgraham's wikipedia link |
| 09:44 | <qfox> | anythng else would fall into quirksmode anyhow |
| 09:45 | <qfox> | (or should) |
| 09:45 | <hsivonen> | qfox: well, if the doctype makes <p><table> a non-concern, then the only actually problematic case is <p><article> |
| 09:45 | <qfox> | and there's absolutely no workaround for that? i mean, the spec isnt finalized yet? |
| 09:46 | <hsivonen> | qfox: the workaround is writing <p></p><article> |
| 09:46 | <qfox> | ok so i guess an article cant be wrapped by p? sorry if that sounds like a silly question :) |
| 09:46 | <qfox> | and also. how is that still an argument _against_ forcing the closure of open tags..? |
| 09:47 | <hsivonen> | qfox: can't in HTML5-compliant text/html parsing (without magic intervening tags) |
| 09:47 | <qfox> | because then it wouldnt be a workaround, it'd be a rule. |
| 09:47 | <zcorpan> | hsivonen: omitting <body> isn't totally safe in ie |
| 09:47 | <Lachy> | virtuelv, that's true, but using family-name for "Jónsson" (from the wikipedia example) is semantically close enough |
| 09:47 | <zcorpan> | hsivonen: nor old firefox |
| 09:47 | <hsivonen> | zcorpan: how? |
| 09:48 | <qfox> | ok. i'm not talking about omitting tags here. i dont care about that right now. i'm just talking about closing a <p> when you open it. what problems arise when that would be enforced? |
| 09:48 | <zcorpan> | hsivonen: ie inserts some tags to the head and then creates a non-tree |
| 09:48 | <hsivonen> | qfox: you'd have to typo </p> more often when editing HTML by hand |
| 09:48 | <qfox> | yeah |
| 09:48 | <qfox> | that sounds like a real sound reason |
| 09:48 | <hsivonen> | zcorpan: eww. |
| 09:48 | <zcorpan> | hsivonen: e.g. for <!doctype html><div><form>lol |
| 09:48 | <qfox> | </sarcasm> . but are there any other reasons? |
| 09:49 | <zcorpan> | hsivonen: firefox puts scripts in head for <!doctype html><div></div><script>alert(document.body)</script> |
| 09:49 | <hsivonen> | qfox: not having to add </p> tags when upgrading pre-existing HTML5 content to HTML5 |
| 09:49 | <qfox> | because that seems to be the only reason people come up with. that and "well it's part of the spec" |
| 09:49 | <qfox> | when upgrading, a lot has to be rewritten anyways |
| 09:49 | <Lachy> | anyway, I assume the conclusion from all of this is that we shouldn't try and restrict the *-name properties to single occurrences since the rules and conventions for names vary so much |
| 09:49 | <hsivonen> | zcorpan: ouch. I *think* I've seen a bug report about that |
| 09:49 | <qfox> | the adding of closing tags should not be a problem at that point |
| 09:50 | <hsivonen> | zcorpan: in the "will be fixed by HTML5 parser" bucket |
| 09:50 | <qfox> | in fact, if its so "difficult" it only proves the necessity |
| 09:50 | <qfox> | or supports it, at least. |
| 09:50 | <gsnedders> | How so? |
| 09:51 | <qfox> | because if the code would be properly closed, the format and scoping would be easier to read |
| 09:51 | <qfox> | and thus better to maintain |
| 09:51 | <qfox> | like this example above |
| 09:51 | <qfox> | to upgrade from html4 to 5 |
| 09:52 | <qfox> | a lot has to be rewritten anyways, right? |
| 09:52 | <qfox> | so you'd have to be able to read the existing code |
| 09:52 | <qfox> | scoping and everything |
| 09:52 | <gsnedders> | If you're compliant HTML 4.01 Strict, you have to change very little |
| 09:52 | <annevk> | I only had to change the DOCTYPE |
| 09:52 | <qfox> | doing so in code that's not properly closed is a ... far more difficult. |
| 09:52 | <hsivonen> | to read markup, you need to infer the close tags anyway |
| 09:52 | <qfox> | yes, but if you're compliant with html4, you're not. |
| 09:53 | <hsivonen> | if you trust on what's explicitly written, you'd be fooled, since the inference rules still apply |
| 09:53 | <gsnedders> | I'd say <p>foo\n<p>bar is just as clear as <p>foo</p>\n<p>bar</p> |
| 09:53 | <qfox> | with all the new tags in html5, can html4 be truly upgraded by just replacing the doctype? |
| 09:53 | <virtuelv> | yay |
| 09:53 | <virtuelv> | russian patronymics are even worse |
| 09:53 | <qfox> | that's like saying c++ is like c. |
| 09:53 | <hsivonen> | qfox: a lot of HTML4 content can, yes |
| 09:53 | <virtuelv> | they are neither first, nor middle or last names |
| 09:53 | <qfox> | yes, a lot. but not all. |
| 09:53 | <qfox> | which was my point. |
| 09:53 | <hsivonen> | qfox: a lot of C code can be assimilated to C++, too |
| 09:53 | <hsivonen> | by design |
| 09:54 | <qfox> | aye |
| 09:54 | <virtuelv> | mongolian names are nouns or adjectives |
| 09:55 | <qfox> | so far i've not heard any argument against it that's worth more than pro's of a properly structure html document. especially in regard of people new to the language and the error prone-ness of not closing tags. |
| 09:55 | <qfox> | laziness is not an argument that outweights that, imo. |
| 09:56 | <qfox> | (and there's IDE's for that :p) |
| 09:56 | <virtuelv> | some cultures do not seem to use sur/last/family names at all |
| 09:56 | <virtuelv> | http://en.wikipedia.org/wiki/Surname |
| 09:59 | <annevk> | qfox, laziness is a great argument |
| 09:59 | <annevk> | also backcompat with HTML4 |
| 09:59 | <annevk> | no reason to break that over aesthetics |
| 10:00 | <qfox> | there's more to it than just aesthetics. |
| 10:00 | <pesla> | qfox: Most of it is personal preferene |
| 10:00 | <qfox> | but maybe pesla was right, they're more of a point to corporate environment.. |
| 10:00 | <qfox> | and a coder's point of view. |
| 10:01 | <qfox> | but either your job is to write html, in which case the extra keys to press to write a closing tag comes natural for you, or you use an IDE to do this for you |
| 10:01 | <qfox> | or its not your job and the extra keypresses should not impact the rest of the cycle |
| 10:01 | gsnedders | notes there are plenty of us who write HTML professionally who omit tags |
| 10:02 | <qfox> | yeah, i could comment on that, but i guess i'll leave it at that probably being part of the reason this discussion started in the first place. |
| 10:02 | <annevk> | my job is writing HTML and it does not come natural... |
| 10:03 | <Hixie> | the main reason the "allow tags to be optional" camp wins the argument is that if tags are optional, youcan still write software that acts as if they're not |
| 10:03 | <annevk> | in fact, what comes natural is omitting stuff :) |
| 10:03 | <Hixie> | but if they're not optional, you can't write software that acts as if they are |
| 10:03 | <Hixie> | so it's a simple tradeoff |
| 10:03 | <workmad3> | omitting tags isn't a problem, as long as you follow the spec wrt what tags can have their close omitted |
| 10:03 | <Hixie> | one way, you can get both behaviours, the other way you can only get one |
| 10:03 | <Hixie> | 2>1 |
| 10:04 | <qfox> | i can hardly believe that not closing tags is preferred from a professional point of view. starting at code maintainability and error proneness. exit at creating code for other people to use. |
| 10:04 | <qfox> | there's just so many things wrong there.. |
| 10:04 | <hsivonen> | qfox: gsnedders, annevk, Hixie and I write test cases as part of our professional activities |
| 10:05 | <hsivonen> | qfox: and I can assure you that people who write all the tags in profession test cases don't make their test cases immune to gotchas |
| 10:05 | <zcorpan> | hsivonen: test cases don't need to be valid though |
| 10:06 | <Hixie> | including the <head> and <body> and <html> tags leads to more errors in my experience |
| 10:06 | <hsivonen> | qfox: see http://twitter.com/hsivonen/status/7979756782 |
| 10:06 | <qfox> | hsivonen: testcases (especially larger, complexer ones) would only benefit from closing tags because there's less chance of introducing bugs in your testcases. |
| 10:07 | <qfox> | and i'm not sure what that status update has to do with this discussion. but that's probably just me. |
| 10:08 | <hsivonen> | qfox: the relevance of the tweet is that writing <head> or </body> explicitly didn't make test cases resilient to gotchas |
| 10:08 | <Hixie> | qfox: you're more likely to have bugs if you have the tags included |
| 10:08 | <hsivonen> | qfox: because white space moves magically even if you have the tags |
| 10:08 | <Hixie> | qfox: how can you have bugs if you omit them? |
| 10:08 | <Hixie> | qdat least for <html>, <head>, and <body> |
| 10:08 | <Hixie> | er |
| 10:08 | <Hixie> | s/qdat/qfox:/ |
| 10:08 | <qfox> | ... testcases arent imune for bugs. |
| 10:09 | <qfox> | why do you need testcases if you omit bugs from your production code? |
| 10:09 | <Hixie> | i mean how can omitting the tags introduce bugs that would be avoided by including them |
| 10:09 | <qfox> | :/ |
| 10:09 | <qfox> | because you can make errors in scoping? |
| 10:09 | <Hixie> | not for <html>, <body>, and <head> |
| 10:09 | <qfox> | maybe. but if you do it for any other tag, why not those three as well. |
| 10:10 | <Hixie> | because it avoids bugs |
| 10:10 | <Hixie> | and because i don't do it for hte other ones |
| 10:10 | <Hixie> | again, the spec allows you to include them, just as you want |
| 10:11 | <Hixie> | why do you want to change the spec to disallow me from omitting them, as i want? |
| 10:11 | <pesla> | To protect people who don't know exactly what they are doing |
| 10:11 | <Hixie> | how does that protect them |
| 10:11 | <Hixie> | if they don't know what they're doing, they're not gonna be using a validator, and they'll never know |
| 10:11 | <qfox> | make a better organized document, prevent people from making mistakes in scoping, especially when editing code later |
| 10:12 | <Hixie> | the conformance rules don't prevent the authors from doing anything if they don't know what they're doing |
| 10:12 | <Hixie> | they'll just make invalid documents |
| 10:12 | <hsivonen> | qfox: the thing is that scoping mistakes aren't prevented, because the parser will still perform tag inference |
| 10:12 | <qfox> | how's that? |
| 10:12 | <qfox> | the whitespace example? |
| 10:13 | <hsivonen> | qfox: well, people write <p> ... <table> ... </table> ... </p> |
| 10:13 | <hsivonen> | qfox: now it looks like scoping is right |
| 10:14 | <hsivonen> | qfox: but it'll still parse as <p> ... </p><table> ... </table> ... |
| 10:14 | <hsivonen> | qfox: so you can't just wish this stuff awy |
| 10:14 | <hsivonen> | away even |
| 10:14 | <zcorpan> | the trailing stray </p> will actually be parsed as <p></p> |
| 10:15 | <qfox> | shouldnt the parser either throw you in quirksmode in such case, or throw some kind of parsing error somehow? |
| 10:15 | <qfox> | rather than accept it, do what you say it will, and still be in "standards mode" ? |
| 10:15 | <hsivonen> | zcorpan: excellent point |
| 10:15 | <hsivonen> | qfox: no |
| 10:15 | <qfox> | i guess i'm thinking too idealy then. |
| 10:17 | <Lachy> | I can't believe how poorly written the vCard RFC is. It's contradictory, doesn't define things clearly at all and forces readers to make assumptions based on examples and ambiguous wording. |
| 10:17 | <Lachy> | I suppose that makes it a typical RFC then. |
| 10:17 | <foolip> | Lachy: sounds like most specs |
| 10:17 | <Hixie> | you should let the hybi group know, they want me to change websockets to use the style more commonly used by RFCs |
| 10:18 | <Lachy> | Hixie, ok. Who is the hybi group? |
| 10:18 | <Lachy> | anyway, I don't have time to finish reviewing it now. Maybe later tonight. But when I finish, I will have a lot of changes for you to make to the vcard conversion algorithm. |
| 10:18 | <Hixie> | 238 people |
| 10:19 | <qfox> | oh. i didnt read that topic. silly me. sorry for that :p |
| 10:21 | <hsivonen> | soooo. Where does the <script event="..."> stuff come from? |
| 10:22 | <hsivonen> | Microsoft? the XHTML2 WG? |
| 10:22 | <Lachy> | XMLEvents, probably |
| 10:22 | <Hixie> | wasn't it a mozilla invention? |
| 10:22 | <Hixie> | actually no i think IE did it first |
| 10:22 | <Hixie> | and mozilla's is incomplete or something |
| 10:23 | <hsivonen> | Hixie: CVS blame points to it being an IE compat thing: https://bugzilla.mozilla.org/show_bug.cgi?id=174404 |
| 10:24 | <pesla> | Is cp1252 always exchangable with windows-1252? |
| 10:24 | <pesla> | Err, interchangeable |
| 10:25 | <gsnedders> | It's an alias for it. |
| 10:25 | <hsivonen> | Hixie: the scary part is that there's still code in the tree from handing the event attribute content to the script engine |
| 10:25 | <hsivonen> | dunno if that's dead code, though |
| 10:25 | <pesla> | gsnedders: Yea, but I wasn't sure if windows-1252 caused problems. |
| 10:25 | <pesla> | In my memory it did, somewhere ;) |
| 10:28 | <workmad3> | anything non unicode will probably cause problems at some point |
| 10:28 | <workmad3> | anything unicode will probably cause problems straight away though :P |
| 10:28 | <pesla> | Migration to utf8 is a todo for this year :D |
| 10:28 | <pesla> | Huge operation :/ |
| 10:37 | <Hixie> | sweet jesus the hybi list beats even public-html in terms of people talking about minutiae that doesn't matter |
| 10:37 | <Hixie> | people are arguing about the reference to use for ASCII! |
| 10:41 | <annevk> | Hixie, I think you play it somewhat close to what is described as "asshole" here though: http://diveintomark.org/archives/2004/08/16/specs :) |
| 10:42 | <annevk> | though you just argued your reference is more useful, so maybe not |
| 10:42 | <Hixie> | my argument here is that i really couldn't care less and think the entire argument is a complete waste of everyone's time |
| 10:44 | workmad3 | likes the moron-asshole analogy :) |
| 10:54 | <annevk> | oh lol |
| 10:54 | <annevk> | the TAG said Web-keys might not be the best idea |
| 10:55 | <annevk> | well, Noah from the TAG said that |
| 10:55 | <annevk> | long emails follow |
| 10:55 | <hsivonen> | are web keys like secret cruft in flickr image file urls? |
| 10:57 | <Hixie> | nn |
| 10:57 | <annevk> | hsivonen, yes, but in addition they're supposed to not leak |
| 10:57 | <annevk> | of course URLs leak everywhere |
| 10:58 | <annevk> | which as Noah's point |
| 10:58 | <annevk> | was* |
| 10:58 | <hsivonen> | flickr private photo urls arem't supposed to leak, either |
| 10:58 | <annevk> | I see |
| 10:59 | <hsivonen> | same design on facebook too, i believe |
| 11:08 | <jgraham> | Hmm, I thought CanvasPixelArray clamped rather than taking the modulus. Did that change or am I misreading something? |
| 11:14 | <Philip`> | jgraham: It used to clamp |
| 11:14 | <Philip`> | Now it seems to defer to WebIDL's octet definition, which moduluses |
| 11:16 | <Philip`> | (I think some people wanted it to match WebGL's typed arrays instead, but I don't know what they do) |
| 11:16 | <Philip`> | (Probably best to converge in the long term) |
| 11:26 | <hsivonen> | do JS engines optimize the return value of charAt to a unsigned short type or does it really create a string object? |
| 11:27 | <hsivonen> | or is one supposed to use charCodeAt for high perf code? |
| 11:31 | <Philip`> | TraceMonkey seems to have lots of specialisations for charCodeAt (for getting/returning ints and doubles) but none for charAt |
| 11:32 | <hsivonen> | I see |
| 11:35 | <Philip`> | (and charAt always returns a new dependent string) |
| 11:35 | <Lachy> | foolip, another bug in your live microdata tool. The data URIs for download links should use charset=UTF-8 instead of encoding=utf-8 |
| 11:36 | Philip` | wishes he knew why X randomly decides to stop receiving any keyboard input for no apparent reason |
| 11:36 | <Philip`> | and usually fixes itself randomly after a few minutes |
| 11:36 | <Philip`> | (The keyboard's fine since I can switch to a text console) |
| 11:51 | <Wes_> | hi |
| 11:52 | <foolip> | Lachy: another? the first one wasn't mine ;) does capitalization of utf-8 matter for mime types, or would charset=utf-8 also be OK? |
| 11:53 | <Philip`> | It's case-insensitive |
| 11:53 | <Philip`> | and uppercase is ugly :-p |
| 11:53 | <foolip> | I agree |
| 11:54 | <Philip`> | It's typically --insensitive and _-insensitive too |
| 11:54 | <Wes_> | but once upon a time we wrote.... <FONT> |
| 11:54 | <Wes_> | and uppercase was cool |
| 11:54 | <Philip`> | so I can never define whether I prefer utf8 or utf-8 |
| 11:55 | <Wes_> | font tag too :) |
| 11:55 | <Philip`> | Wes_: I don't remember it ever being cool |
| 11:55 | <Philip`> | It was just what one did because it's what everyone else did :-) |
| 11:56 | <Philip`> | I guess it made more sense in the early web, where you had more content than markup |
| 11:56 | <Philip`> | and so it was handy to make the markup stand out more |
| 11:56 | <Philip`> | but now it's the other way round |
| 11:57 | <Philip`> | and you often write whole pages with no textual content whatsoever |
| 11:57 | <Wes_> | eheh... nice era |
| 11:58 | <Wes_> | true! |
| 11:58 | <Wes_> | lot of pages are full-xmlhttp |
| 11:58 | <Wes_> | just tags and scripts |
| 11:59 | <Wes_> | hey... it's my first time here, english is not my first language and i'm sorry for this |
| 12:00 | <Wes_> | the flexible box model is part of whatwg? |
| 12:00 | <foolip> | Wes_: that would be the CSS WG |
| 12:01 | <Lachy> | foolip, lowercase "utf-8" is ugly. |
| 12:02 | <foolip> | Lachy: OK, as you wish |
| 12:02 | <Wes_> | and whatwg does not collaborate with csswg? |
| 12:02 | <Lachy> | foolip, I don't mind that much. It's up to you |
| 12:02 | jgraham | rather likes lowercase utf-8 |
| 12:02 | <Lachy> | I was just countering Philip`s unsupported argument with one of my own. |
| 12:03 | <hsivonen> | Wes_: collaboration with the CSS WG happens informally or formally with HTML WG hats on |
| 12:11 | <Wes_> | what do you think about aside element? |
| 12:11 | <hsivonen> | Wes_: seems to address a common use case (pull quotes) |
| 12:12 | <zcorpan> | and sidebars |
| 12:13 | <Wes_> | but is visual, not structural... i mean... i believe in convergence of html and xhtml |
| 12:16 | <Wes_> | the mean is "not so important"? xD its a floated element placed before the real content... so parsers like search engines can identify "real content" and "additional content"? |
| 12:17 | <foolip> | Lachy: fixed |
| 12:19 | <jgraham> | Wes_: It seems pretty important to me. See e.g. the BBC which has lots of stuff like <p>Some text</p><div class=aside>A random quote</div><p>Some text that follows the previous paragraph</p> |
| 12:19 | <jgraham> | (their markup doesn't look quite like that but the idea is the same) |
| 12:20 | <jgraham> | So a UA reading the page would likely want to skip the <div> first time around and just read the main content |
| 12:22 | <Wes_> | maybe it is too generic |
| 12:23 | <Wes_> | an "asided" element can be a paragraph |
| 12:23 | <Wes_> | <p aside="aside"> |
| 12:23 | <Wes_> | <p class="aside"> |
| 12:24 | <Wes_> | a standard classname |
| 12:24 | <jgraham> | Wes_: But it can also be several paragraphs as in a pull-out box that you get in magazines |
| 12:24 | <jgraham> | And people really don't like standard classnames |
| 12:24 | <jgraham> | (because they can clash with authour-defined classnames) |
| 12:26 | <Wes_> | and what people think about aside? and browser vendors? |
| 12:26 | <hsivonen> | Wes_: I believe "people" are divided on aside |
| 12:27 | <hsivonen> | Wes_: I don't recall browser vendors objecting to it |
| 12:27 | <jgraham> | I'm not sure that "browser vendors" have officla opinions on it |
| 12:27 | <hsivonen> | Wes_: and browser vendors usually don't promise support |
| 12:27 | <Wes_> | lol, usually just one vendor |
| 12:27 | <Wes_> | xD |
| 12:27 | <jgraham> | e.g. I work for a browser vendor and I like <aside> but that's not any sort of official position |
| 12:28 | <jgraham> | I mean, it's not clear that desktop browsers will do a lot with it. Behaviourally it is more useful for search engines and AT and so on |
| 12:28 | <Wes_> | but whatwg isn't a consortium of browser vendors? |
| 12:30 | <Wes_> | and big it companies? |
| 12:30 | <hsivonen> | Wes_: the whatwg is an informal gathering of people initiated by a group of people working for browser vendors |
| 12:30 | <Wes_> | *IT |
| 12:30 | <Wes_> | ah |
| 12:30 | <foolip> | Wes_: kind of, but only people have opinions and they tend to differ (even when sharing the same employer) |
| 12:30 | <Wes_> | so none is changed |
| 12:30 | <foolip> | for example, I work for the same browser vendor as jgraham, but think <aside> is kind of ugly (not ugly enough to care though) |
| 12:33 | <Wes_> | why not web polls? so users can decide, not implementors |
| 12:33 | <Wes_> | ? |
| 12:33 | <hsivonen> | Wes_: users don't have commit access to the code repositories that browsers are built from |
| 12:34 | <Wes_> | no.. just "do you like aside?" yes|no |
| 12:34 | <Dashiva> | That wouldn't be very useful |
| 12:34 | <foolip> | Wes_: if you're able to organize fair and representative polls that gather real opinions of real web authors, I'm sure it would be taken into account |
| 12:34 | <Dashiva> | You'd have to make sure everyone answering had a proper and full understanding of what aside is, and what it is meant for |
| 12:35 | <foolip> | but I don't know how that wouldn't turn into a big cheating fest though |
| 12:35 | <Dashiva> | Just look at OOXML to see what happens when you do voting :P |
| 12:35 | <Wes_> | it is difficult... but with collaboration can be done |
| 12:35 | <Wes_> | lol |
| 12:37 | <jgraham> | It is not clear that design-by-poll leads to the best outcome |
| 12:37 | <Wes_> | anyway... browser wars made the web... so this is not so bad |
| 12:39 | <Wes_> | and... what about html5 served as xml? |
| 12:39 | <Wes_> | it can be done? |
| 12:40 | <Wes_> | can i use my own xml namespaces with html5? |
| 12:41 | <foolip> | Wes_: only if you serve it as XML |
| 12:41 | <jgraham> | But first you should realise that you probably son't want to |
| 12:41 | <jgraham> | *don't |
| 12:43 | <Wes_> | why not? |
| 12:46 | <Philip`> | Because it's more complex and fragile, and in most cases it doesn't give you any useful benefits |
| 12:47 | <zcorpan> | and because Philip` will break your site by posting U+FFFE in a comment |
| 12:47 | <Wes_> | LOL? |
| 12:49 | <Wes_> | we use namespaces for browser based apps. not public websites... some of my developers works without collaboration on the same thing... and everyone works on a different namespace, |
| 12:49 | <Wes_> | for readability too |
| 12:49 | <Wes_> | custom tags are cool... class="" its hard to manage |
| 12:49 | <hsivonen> | Wes_: different XML namespace? |
| 12:49 | <hsivonen> | Wes_: for each developer? |
| 12:49 | <Wes_> | yes |
| 12:50 | <hsivonen> | wow |
| 12:50 | <Wes_> | lol... namespace for every feature |
| 12:50 | <Wes_> | not for every developer xD |
| 12:54 | <Wes_> | anyway i'm using a lot of html5 features, drag & drop is cool, file apis too |
| 12:54 | <Wes_> | do you will write someting about clipboard management? |
| 13:48 | <annevk> | Hixie, when is something dom-x versus dom-window-x? |
| 13:53 | jgraham | wonders if a snowstorm makes it enough like Christmas that if he closes his eyes and wishes hard enough for a window.atob and window.btoa spec, it might come true |
| 13:55 | <annevk> | are they complicated? |
| 13:55 | <Philip`> | I thought nobody uses them |
| 13:55 | <Philip`> | except for feature detection |
| 13:55 | <Philip`> | s/feature detection/browser sniffing/ |
| 13:56 | <foolip> | function atob(s){return s.replace(/a/g, 'b');} |
| 13:56 | <foolip> | is that it? |
| 13:56 | <Dashiva> | Worst function names ever |
| 13:56 | foolip | looks up what they really are |
| 13:57 | <Dashiva> | base64 stuff |
| 13:57 | <workmad3> | ah, 'ascii to binary' :) |
| 13:58 | <workmad3> | yeah, worst names ever |
| 13:58 | <Dashiva> | And surely no one would ever think the 'b' is for base64 |
| 13:58 | workmad3 | wonders what's wrong with base64encode and base64decode |
| 13:59 | <gsnedders> | foolip: Why not just s.replace("a", "b")? |
| 13:59 | hsivonen | notes that atoi does something very different in C |
| 13:59 | <foolip> | gsnedders: doesn't that just replace the first occurence? |
| 13:59 | <gsnedders> | jgraham: Should it not be in HTML 5 on the Window interface? |
| 13:59 | <gsnedders> | foolip: I don'th tihnk so, but I get things like that wrong often, so it's possible |
| 14:00 | <jcranmer> | Dashiva: I actually implemented those backwards |
| 14:00 | <annevk> | hixie thought they should be in ECMA |
| 14:00 | <annevk> | that's not going to happen of course |
| 14:00 | <foolip> | gsnedders: http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0D%0A%3Cscript%3Ew('aa'.replace('a'%2C'b'))%3C%2Fscript%3E |
| 14:01 | <foolip> | silly default in my opinion (I was right) |
| 14:02 | <AryehGregor> | I don't get anything written to the log in Chrome 4. Maybe because of XSS prevention? |
| 14:27 | <jgraham> | AryehGregor: I have to do something like w("some string constant") to get the log working in Chrome for some reason |
| 15:27 | <AryehGregor> | This is getting ridiculous. Now it's registered users changing the dates around too. http://en.wikipedia.org/wiki/User_talk:Resistor#Your_change_to_HTML5 |
| 15:31 | <gsnedders> | But that's what the charter says! |
| 15:31 | <annevk> | who cares anyway |
| 15:32 | <AryehGregor> | If nobody cared about fixing mistakes in Wikipedia, it wouldn't be a very useful resource, would it? |
| 15:33 | <annevk> | it's not that useful for Web standards I think |
| 15:33 | <annevk> | and I know ideally I should help fix it, but conflict of interest would be pretty high |
| 15:34 | <AryehGregor> | It's useful for web standards if you don't know anything about web standards, which most people don't. |
| 15:34 | <AryehGregor> | Not if you idle in #whatwg all the time, of course. |
| 15:37 | <AryehGregor> | And it's not a conflict of interest just because you're a WHATWG/HTMLWG member. If that sort of thing counted, nobody could edit anything they knew much about. |
| 15:39 | <AryehGregor> | Also, is this article awesome or what: http://en.wikipedia.org/wiki/Tables_of_vampire_traits |
| 15:39 | <AryehGregor> | Totally useless, but, awesome. |
| 15:42 | <annevk> | I still don't like that they killed the unique page for each Pokemon thing |
| 15:42 | <AryehGregor> | Yeah, I hate deletionists. |
| 15:42 | <AryehGregor> | :( |
| 15:46 | <MikeSmith> | I like how just about every Wikipedia article of any importance contains a reference to some dumbassed video game |
| 15:46 | <MikeSmith> | e.g., http://en.wikipedia.org/wiki/Sakamoto_Ryōma |
| 15:47 | <AryehGregor> | http://xkcd.com/446/ |
| 15:47 | <AryehGregor> | Those sections need to be killed with fire. |
| 15:47 | <MikeSmith> | "In the video game Live A Live, Sakamoto Ryōma appears as a playable character." |
| 15:47 | AryehGregor | checks for policies |
| 15:47 | <AryehGregor> | It seems like "kill them with fire" isn't the current policy, more like "do actual work to improve them", so I guess I'll leave it. |
| 15:48 | <annevk> | MikeSmith, yeah, popular culture is always funny |
| 15:49 | <MikeSmith> | I think the Wikipedia edtards should create a special admoninition: "This Wikipedia article currently contains no references to any dumbassed video games. Therefore because it can't possibly important, it is being consider for deletion." |
| 15:49 | <meledin> | Don't knock it! Wikipedia is the world's foremost resource on fiction. |
| 15:53 | <jgraham> | Not to mention dumbassed video games |
| 15:54 | <AryehGregor> | Those count as fiction. |
| 15:54 | <AryehGregor> | They have free-speech protection in the US and everything! |
| 15:54 | gsnedders | wonders if it's bad to be eating ceral at 5 pm because he's peckish |
| 15:55 | <AryehGregor> | I read a Ninth Circuit decision that mentioned, in passing, that even if you could come up with definitive evidence that playing violent video games increased crime rates, you still couldn't restrict them because of that, because the harm is too indirect and tenuous. |
| 15:55 | <jgraham> | No but it would be bad to be eating birdseed because you were peckish |
| 15:55 | gsnedders | almost spits out cereal on to his laptop laughing at that |
| 15:56 | <AryehGregor> | Careful, it will end up like Hixie's. |
| 15:57 | gsnedders | doesn't remember Hixie's laptop looking noticably bad |
| 16:00 | <MikeSmith> | "In the video game This Could be You, a Wikipedia contributor suffers a life-threatening ass kicking after adding one too many dumbassed non-sequitor junk-culture references to a Wikipedia aricle." |
| 16:06 | <meledin> | Citation needed. |
| 16:33 | <MikeSmith> | AryehGregor: the title text on http://xkcd.com/446/ is especially good |
| 16:33 | <crankharder> | say I wanted to implement an "offline" version of my app that was used primarily for bare-bones data entry -- when the user reconnects this data would then be sent up to the server somehow. I was thinking of using HTML5's client-side DB, how stable is that at this point in Chrome/Safari/FF(?)? What other hoops do you think there might be? |
| 19:23 | <jgraham> | http://hacks.mozilla.org/2010/02/an-html5-offline-image-editor-and-uploader-application/ is a neat demo |
| 19:24 | <AryehGregor> | I like how the blog post says "You'll need Firefox 3.6". Standards are great, right? (It's probably not true, though.) |
| 19:26 | <jgraham> | Does webkit have CORS? |
| 19:26 | <jgraham> | I think it has the other bits needed |
| 19:27 | <jgraham> | Oh does it use the file API? I guess only firefox has that at the moment |
| 19:27 | <AryehGregor> | Hmm, maybe. |
| 19:27 | AryehGregor | wonders why WebKit and Gecko tend to implement roughly the same sets of features, while Opera often implements totally different parts of the same specs or entirely different specs. |
| 19:29 | <jgraham> | AryehGregor: I don't think that's really true, is it? |
| 19:29 | <AryehGregor> | I don't know, I've noticed it in a bunch of cases. |
| 19:30 | <AryehGregor> | Like border-radius, Gecko and WebKit both implemented that way before Opera. |
| 19:30 | <AryehGregor> | But Opera implemented Web Forms way before either of them, for instance. |
| 19:30 | <AryehGregor> | (not that those two examples are comparable in scope) |
| 19:30 | <jgraham> | It's not really fair to compare with 10.10 because that is rather old (from a Core point of view) |
| 19:31 | <AryehGregor> | Compare what with 10.10? |
| 19:31 | <AryehGregor> | Gecko/WebKit implemented border-radius long before 10.10 was released, right? |
| 19:31 | <jgraham> | The current tate of gecko and webkit |
| 19:31 | <jgraham> | *state |
| 19:31 | <AryehGregor> | Also both implemented video/audio before Opera did. |
| 19:31 | <AryehGregor> | I'm not, I'm comparing who implemented what first. |
| 19:32 | <AryehGregor> | And Opera implemented <datalist>, Gecko/WebKit not. |
| 19:32 | <jgraham> | AryehGregor: It is pretty difficult to tell when Opera implements things because they have not always shipped soon after implementation |
| 19:32 | <AryehGregor> | Hmm, I see. |
| 19:32 | <jgraham> | although the plan is to do better at that |
| 19:32 | <AryehGregor> | Well, forget implemented, let's say released. |
| 19:33 | <AryehGregor> | border-radius: Firefox 1.0, Safari 3.0, Opera what? 9.50? |
| 19:33 | <jgraham> | Web Forms is certianly a fair example. I don't know the details but I guess Opera betted on other people implementing it and that didn't happen |
| 19:33 | <jgraham> | Or hasn't happened yet |
| 19:34 | <AryehGregor> | video: Firefox 3.5, Safari ?, Opera 9.50. |
| 19:34 | <AryehGregor> | WebKit is starting to implement WF2.0. |
| 19:35 | <AryehGregor> | Maybe WebKit and Gecko are more public about their under-development features, and tend to track each other because they're more prominent? Dunno. |
| 19:35 | <AryehGregor> | I implement cool features if at least one browser supports them, even if it's only Opera, so Opera will get the fancy Web Forms stuff when Wikipedia switches to HTML5 (whenever that is). |
| 19:36 | <hsivonen> | Validator.nu uses type=url |
| 19:36 | <jgraham> | AryehGregor: You are atypical in that respect. Most people only care if x% of browsers by marketshare implement something where x is typically larger than Opera alone (on desktop) |
| 19:37 | <AryehGregor> | jgraham, yeah, I know. |
| 19:37 | <jgraham> | (in western europe and north ameria) |
| 19:37 | <AryehGregor> | I'm implementing because it's cool, not because it's a pragmatically good use of my time. :P |
| 19:38 | AryehGregor | is sad about <datalist> not working well in Opera for search suggestions, but WebKit might get it reasonably soon. |
| 19:39 | <AryehGregor> | Nobody does anything useful for type=url except the iPhone, I think. MediaWiki uses search, number, email, and maybe a couple others. A bit of pattern. And lots and lots of autofocus. :) |
| 19:40 | <jgraham> | AryehGregor: If there is a problem with the feature you should file a bug |
| 19:40 | <AryehGregor> | jgraham, I did. |
| 19:40 | <jgraham> | AryehGregor: Oh, good |
| 19:40 | <jgraham> | thanks |
| 19:41 | <AryehGregor> | Same as I did with the pattern attribute when I figured out that it's not very handy for password fields. |
| 19:42 | <AryehGregor> | If another browser implements either feature, I'm going to have to uncomment the code with a browser version check, so I hope you guys fix it before then. |
| 19:42 | <AryehGregor> | (neither problem can be feature-sniffed from JS AFAICT) |
| 19:50 | <AryehGregor> | Okay, seriously, why are Chromium people calling their notification system "HTML5 notifications"? |
| 19:51 | <AryehGregor> | Are they specced anywhere vendor-neutral? |
| 19:51 | <AryehGregor> | I thought it was just an error in their Chrome 4 announcement, but it's here too: http://dev.chromium.org/developers/linux-technical-faq |
| 19:52 | <jgraham> | Maybe because the notifications themselves are HTML? |
| 19:52 | jgraham | i being generous |
| 19:59 | <hsivonen> | AryehGregor: everything new is HTML5 |
| 19:59 | <virtuelv> | AryehGregor: because hixie tried to add it to html5 at some pojnt |
| 19:59 | <virtuelv> | point, even |
| 19:59 | <AryehGregor> | hsivonen, I'm okay with that as long as it's on a standards track. |
| 19:59 | <virtuelv> | it's not |
| 20:00 | <AryehGregor> | I assume they'll try to get it standardized at some point, but still. |
| 20:00 | <virtuelv> | because hixie ripped it out again |
| 20:00 | <AryehGregor> | Oh, well, at least it was in HTML5 at some point, then. |
| 20:01 | <virtuelv> | I would like to see notifications as well[1], but I recall having some objections to the notifications that were there |
| 20:02 | <virtuelv> | [1] Opera implements the following: http://dev.opera.com/articles/view/opera-widgets-specification-fourth-ed/#wo_getAttention |
| 20:05 | <hsivonen> | virtuelv: does showNotification() go to Growl on Mac and D-Bus on Ubuntu? |
| 20:05 | <virtuelv> | currently, I think not |
| 20:06 | <virtuelv> | Gnome's notifications are problematic, since you can't acknowledge them |
| 20:06 | <virtuelv> | hsivonen: although, 10.50 uses Growl |
| 20:07 | <hsivonen> | virtuelv: nice (growl), but why do you need to ack? |
| 20:07 | <hsivonen> | my growl stuff fades away |
| 20:07 | <virtuelv> | hsivonen: you don't need to |
| 20:07 | <virtuelv> | hsivonen: the use case would be something like |
| 20:08 | <virtuelv> | "I have 2214 new messages, take me to my inbox because I chose to acknowledge" |
| 20:09 | <hsivonen> | I think clicking the bubble on growl should bring the originator tab to front |
| 20:09 | <virtuelv> | hsivonen: also note that notifications in Opera are used in Opera unite |
| 20:09 | <virtuelv> | which don't have a visible window |
| 20:14 | <roc> | I'm not sure that supporting HTML in notifications is a good idea |
| 20:14 | <roc> | given it means you can't use Growl or libnotify |
| 20:14 | <roc> | the use-cases for arbitrary HTML in notifications would have to be pretty strong |
| 20:18 | <jgraham> | virtuelv: I am quite the fan of the new ubuntu notifications |
| 20:18 | <jgraham> | Well not really but they seem very clean, which is nice |
| 20:21 | <roc> | I have to say that mentioning "HTML5 notifications" in an FAQ is a much less egregious error than others I've seen |
| 20:23 | <jgraham> | On the subject of large numbers of messages, I wonder why thunderbird persists in telling me that I have 6147 unread emails by labelling the dock icon. I obviously don't care so why add the visual noise? |
| 20:59 | <virtuelv> | jgraham: it's thunderbird's way of telling you you should switch to an e-mail client where inbox 0 is achievable :-) |
| 21:04 | <Hixie> | AryehGregor: i told them to experiment and prove their idea before we add it to html5 |
| 21:12 | zcorpan | predicts a Translation From PR-Speak to English of Selected Portions of http://blogs.adobe.com/conversations/2010/02/open_access_to_content_and_app.html |
| 22:06 | <karlushi> | MikeSmith? |
| 22:06 | <karlushi> | # The “scope” attribute on the “th” element is obsolete. Use the “scope” attribute on a “th” element instead. |
| 22:06 | <karlushi> | -- http://dev.w3.org/html5/markup/th.html#th |
| 22:11 | <zcorpan> | v.nu doesn't seem to have that bug |
| 22:35 | <karlushi> | http://css4design.com/html5-une-orientation-encore-trop-litteraire-et-pas-assez-web French article complaining about the choice of new elements in html5 |
| 22:35 | <roc> | "If HTML could reliably do everything Flash does that would certainly save us a lot of effort" ==> "If HTML could reliably do everything Flash does that would certainly nuke our business from orbit" |
| 22:35 | <karlushi> | the person is argueing for example that there is a missing "basket" (ecommerce) or "logo" element |
| 22:52 | <jgraham> | What is upposed to happen if I delete an index property from a CanvasPixelArray? |
| 22:52 | <jgraham> | *supposed |
| 22:54 | <jgraham> | I can't see anything special in the spec which suggests it works like an ordinary js object i.e. the property gets removed |
| 22:56 | <jgraham> | But I wonder if that is detrimental to performance |
| 23:00 | <jgraham> | (Needless to say cross browser compatibility here is negligible, but Opera, Safari and Chrome seem to agree that properties should not be deleted by 'delete' even though Chrome and Safari return 'true' for the delete operation. Also Safari doesn't seem to support hasOwnProperty on the CanvasPixelArray) |
| 23:02 | <Dashiva> | jgraham: There's no deleter operator on the interface, so delete wouldn't do anything (unless there was a real JS property to delete) |
| 23:03 | <jgraham> | Dashiva: Interesting. But why does an index property not count as a real property? It returns true for hasOwnProperty? |
| 23:03 | <jgraham> | s/?// |
| 23:04 | <KevinMarks> | roc: not really; then they could keep selling their dev tools, but output HTML5 and stop maintaining their runtime (which they give away) |
| 23:05 | <roc> | sure |
| 23:05 | <jgraham> | Dashiva: Specifically in http://dev.w3.org/2006/webapi/WebIDL/#delete we must get to step 3 because otherwise properties with deleter set wouldn't be deleted |
| 23:05 | <roc> | I think they'd face more competition in HTML5 tools |
| 23:05 | <jgraham> | Dashiva: But step 3 doesn't apply so we end up in step 5 |
| 23:05 | <Hixie> | i wish they'd face competition in HTML5 tools |
| 23:07 | <Dashiva> | jgraham: The way the interface is specified, there is no JS property/ies respresenting the actual data |
| 23:07 | <Dashiva> | It's like a java object with only getValue and setValue |
| 23:08 | <jgraham> | Dashiva: I see your argument but it is wholely unclear to me that that is how it is intended to work |
| 23:08 | <Dashiva> | Well, it has been a long time since I read WebIDL, let me check that it hasn't changed incompatibly underneath me |
| 23:09 | <jgraham> | It also leads to the strange behaviour where delete CanvasPixelArray[index] unconditionally does nothing yet always returns true |
| 23:10 | <Dashiva> | Oh, here it is |
| 23:10 | <Dashiva> | I was partially wrong. The properties for the indexes are indeed created. However, they are created with { DontDelete } |
| 23:10 | <jgraham> | Ah, that sounds promising |
| 23:11 | jgraham | finds that |
| 23:12 | <Dashiva> | It should return false on delete, though |
| 23:12 | <jgraham> | Dashiva: Thanks |
| 23:12 | <Dashiva> | (Since they're DontDelete) |
| 23:12 | <jgraham> | Dashiva: Sure. WebKit browsers are wrong |
| 23:12 | <jgraham> | (and Firefox is very wrong) |
| 23:13 | jgraham | is happy because this is how he assumed it would work in the first place :) |
| 23:14 | <Dashiva> | (I suppose their code might be based on earlier webidl where the properties didn't exist at all) |
| 23:17 | <jgraham> | Yeah, that probably sounded criticl in a way that I din't intend |
| 23:17 | <jgraham> | *critical |
| 23:18 | jgraham | is looking forward to the new version of WebIDL based on ES5, hopefully with the same improvements to algorithm readability |
| 23:20 | <Dashiva> | I don't envy anyone the task of making it compatible with both es3 and es5 :) |