| 02:12 | <Hixie> | anyone know if any browser supports accesskey on non-focusable elements? |
| 02:18 | <Hixie> | hm, it suddenly started working, wtf |
| 02:23 | <jcranmer> | computers are like that |
| 07:28 | <zcorpan> | Ms2ger: in quirks mode, red. otherwise, the link's color |
| 07:29 | <zcorpan> | http://simon.html5.org/specs/quirks-mode#the-font-element-text-decoration-color-quirk |
| 07:29 | <zcorpan> | some browsers make that quirk conditional on the color attribute and its value, but i thought that was pointless so didn't spec it |
| 07:31 | <zcorpan> | iirc webkit has this quirk in all modes |
| 07:36 | <MikeSmith> | zcorpan: http://qa-dev.w3.org:8888/?doc=data%3Atext%2Fhtml%3Bcharset%3Dutf-8%2C%3C%21doctype%2520html%3E%250D%250A%3Ctitle%3E%3C%252Ftitle%3E%250D%250A%3Cinput%2520type%253Dimage%2520value%253Dfoo%2520alt%253Dbar%3E&showsource=yes |
| 07:36 | <zcorpan> | woah |
| 07:36 | <zcorpan> | quite the message |
| 07:37 | <MikeSmith> | yeah, verbose |
| 07:37 | <zcorpan> | tl;dr? :-) |
| 07:37 | <MikeSmith> | well, the existing message takes up the same amount of vertical space |
| 07:38 | <zcorpan> | but maybe it's good enough for noscript users, and then you can shave off the non-interesting bits with a script |
| 07:38 | <MikeSmith> | not sure it makes sense to do that actually |
| 07:38 | <zcorpan> | maybe not |
| 07:39 | <MikeSmith> | the problem being that lacking the context, I think some users are still going to file bugs |
| 07:39 | zcorpan | switching trains |
| 07:40 | <MikeSmith> | k |
| 07:43 | <annevk> | MikeSmith: maybe just list the allowed attributes for type=image? |
| 07:43 | <annevk> | MikeSmith: and state it depends on the type, with a link to the table in the HTML draft? |
| 07:44 | <MikeSmith> | the problem if we do that is I think we are still going to get people filing bugs saying, e.g., the spec says the value attribute is allowed on image |
| 07:44 | <MikeSmith> | because it's actually pretty hard to tell from the spec that it's not |
| 07:45 | <MikeSmith> | but if we show it in context with the other types, the users can see, yeah, value is allowed for most types, but it's not allowed for image |
| 07:46 | <MikeSmith> | and the other technical problem with only showing the allowed attributes for type=image in this message is that the current Java code does not have access at that point to the other attributes |
| 07:47 | <MikeSmith> | the exception that's thrown has information about the element name, but not the attributes |
| 07:48 | <MikeSmith> | and this weekend I looked at changing the code so that the attribute information is available at that point, but it turns out that doing that adds a lot of extra code that's not useful for anything else except this one special case of the input element |
| 07:48 | <zcorpan> | MikeSmith: i guess it's good enough, although i think the ideal message i'd want is along the lines of "Attribute value not allowed on element input with type=image. value is only allowed when type is button, checkbox, color, [etc]" |
| 07:50 | <zcorpan> | MikeSmith: but maybe it's possible to do that while still having all the information, by rewriting the message with javascript :-) |
| 07:50 | <MikeSmith> | yeah |
| 07:50 | <MikeSmith> | so I may end up doing that |
| 07:50 | <zcorpan> | you'd need to parse the highlighted extract with innerHTML to find out the used type |
| 07:50 | <MikeSmith> | right |
| 07:50 | <MikeSmith> | that is simple enough to do, though hacky |
| 07:51 | <zcorpan> | yeah |
| 07:52 | <MikeSmith> | the Java code we are using to parse the attributes information out from the spec is pretty hacky too |
| 07:52 | <MikeSmith> | and that's where I made the change for this |
| 07:53 | <MikeSmith> | because I think it's better to keep new hacks isolated in the places where existing ones are |
| 07:54 | <MikeSmith> | rather than burdening the currently mostly un-hacky parts with extra code for this special case |
| 07:54 | <MikeSmith> | anyway, for now I'll send what I have to hsivonen for review, and see what he thinks |
| 07:56 | <zcorpan> | maybe a less hacky approach is to let the schema allow everything and have a java checker check the constraints and emit useful messages |
| 08:01 | <kennyluck> | annevk, regarding the question "What do Chrome users do when they face big5-uao content?" you asked a few days ago, I got some answers from a helpdesk forum. See http://krijnhoetmer.nl/irc-logs/whatwg/20120414#l-294 |
| 08:02 | <annevk> | yeah saw that |
| 08:02 | <annevk> | le sigh |
| 08:03 | <kennyluck> | k |
| 08:04 | <annevk> | though the data Philip had suggested this only affects very few pages |
| 08:04 | <annevk> | ugh |
| 08:05 | <kennyluck> | Oh, one guy suggested that charset=big5 should use the intersection of big5-2003 and big5-hkscs. |
| 08:05 | <kennyluck> | Yeah, that's the main reason why people don't really care. |
| 08:05 | <annevk> | I think that's the definition of big5 at the moment |
| 08:06 | <annevk> | afaik it includes the ETEN extensions and such |
| 08:10 | <MikeSmith> | https://twitter.com/#!/ruvebal/status/191800323050971136 |
| 08:10 | <MikeSmith> | "Any repository @w3c for downloading the whole bunch of xhtml2 rng schema? The goal to convert modules to rnc for nxml-mode validation @emacs" |
| 08:19 | <annevk> | I wonder how much IE supports of iso-2022-jp |
| 08:20 | <annevk> | if it does not support JIS X 0212 there either, maybe that index should be removed altogether |
| 08:42 | <annevk> | anyone with an even better idea on how to organize the external indexes? |
| 08:42 | <annevk> | should I define some kind of names for them in the draft so I only need to use the links once? |
| 08:42 | <annevk> | #firstworldproblems |
| 08:42 | <annevk> | or maybe more like #anneproblems |
| 08:47 | <zcorpan> | yeah have a table that lists the indexes with <dfn>s in left column and link in right, or some such |
| 08:47 | <foolip> | kennyluck, thanks for the questions on ptt.cc! |
| 08:48 | <annevk> | <dfn>index big5</dfn> <a href=index-big5.txt>index-big5.txt</a> could work I suppose |
| 08:48 | <annevk> | and then I can add the notes there too about how these indexes are unusual |
| 08:49 | <zcorpan> | #anneproblemsolved |
| 08:50 | <kennyluck> | foolip, nope. By the way, I am running your scripts for .hk sites too. It might turn out that big5-uao is as prevalent there |
| 08:50 | <foolip> | kennyluck, oh, I'm already doing that actually :) |
| 08:50 | <foolip> | but go ahead and play, independent results would be great! |
| 08:52 | <annevk> | another problem |
| 08:52 | <annevk> | can a specification use language like |
| 08:52 | <foolip> | kennyluck, I can check in the list of hk URLS if you haven't generated your own yet |
| 08:52 | <annevk> | (x / 94) + 0xA1 |
| 08:53 | <annevk> | (x % 94) + 0xA1 |
| 08:53 | <annevk> | remainder of dividing x by 94 (as integers) but that just seems so lame |
| 08:53 | <kennyluck> | foolip, I am using Bing API too so I am afraid that there wouldn't be any different. I am at about 30% of getting the urls. |
| 08:54 | <foolip> | kennyluck, ok, let's see what you find :) |
| 08:55 | <foolip> | my suspicion is that a lot more HK pages depend on Big5-HKSCS than TW pages depending on Big5-UAO |
| 08:56 | <annevk> | I'm so happy I got you guys excited about sorting this out :) |
| 08:56 | <annevk> | actually, you just got excited, I didn't have to do much apart from sending a few emails |
| 08:57 | <kennyluck> | foolip, no prediction from me except that I doubt "a lot" is true :p I guess we'll ending leaning to big5-uao for non-zh locales, if we are going locale-dependent. |
| 08:58 | <foolip> | kennyluck, from annevk's initial data from dotnetdotcom.org HKSCS was certainly a lot more common than UAO |
| 09:00 | <kennyluck> | foolip, let's see. I don't bet any money on this :p |
| 09:03 | <annevk> | fwiw, first non-utf-8, non-utf-16, non-single-byte encoder: http://dvcs.w3.org/hg/encoding/raw-file/tip/Overview.html#euc-jp-encoder |
| 09:03 | <kennyluck> | foolip, by the way, it surprises me that https://gitorious.org/whatwg/big5/blobs/master/big5-hkscs-vs-uao.txt doesn't have many Japanese sentences. Is it simply because these pages get lower page rank or there's bugs in Bing API in this regard? |
| 09:04 | <foolip> | kennyluck, I don't know, possibly it's because of Market=zh-TW, if Bing thinks that these pages are in Japanese |
| 09:04 | <foolip> | Or these pages just aren't in the top 50 pages of the top ~3k Taiwan sites? |
| 09:05 | <kennyluck> | foolip, I think I'll stop my script and re-run that with Market=zh-TW taken away now. |
| 09:06 | <foolip> | kennyluck, yeah, I just removed that when searching .hk |
| 09:06 | <kennyluck> | I missed that :( |
| 09:25 | <kennyluck> | foolip, my feeling is that Bing API filters out a good portion of big5-uao… For example, http://www.bing.com/search?q=site%3Awww.ptt.cc+%E3%81%82&qs=n&form=QBRE&filt=all&pq=site%3Awww.ptt.cc+%E3%81%82&sc=0-0&sp=-1&sk= give no hit. |
| 09:26 | <kennyluck> | big5-uao or perhaps all big5 beyond CP950... |
| 09:26 | <foolip> | kennyluck, that just means that Bing doesn't decode Big5-UAO content properly, not that it's excluded from the results |
| 09:26 | <annevk> | maybe search engines would benefit from this standard too |
| 09:27 | <annevk> | kind of lame nobody has attempted to solve this thus far and just said "use Unicode" |
| 09:27 | <kennyluck> | foolip, ah, true. (Google handles a good amount of Kanas though). |
| 09:28 | <kennyluck> | annevk, every machine benefits from an encoding standard ;) |
| 09:29 | <foolip> | kennyluck, perhaps comparing the relative amount of Japanese content in .tw domains with the dotnetdotcom.org would give a clue if it's being discriminated against or not |
| 09:40 | <kennyluck> | In Google, site:www.ptt.cc gives me 14,100 results if I click "search all Japanese pages", and 17,800,000 if I don't. (This number is different in the zh-TW Google, very strange). This is about 0.08%. |
| 09:40 | <kennyluck> | (www.ptt.cc is arguably biased towards having more Japanese content, but I am not sure) |
| 09:54 | <kennyluck> | I guess I am willing to believe that BingAPI doesn't discriminate misencoded pages. |
| 10:11 | <annevk> | ok done: http://dvcs.w3.org/hg/encoding/raw-file/tip/Overview.html#indexes |
| 10:18 | <AryehGregor> | Has anyone ever proposed that CSS support "font-size: xxx-large" to match <font size=7>? |
| 10:18 | <AryehGregor> | The lack of such a value is really annoying for editing. |
| 10:18 | <annevk> | yes |
| 10:19 | <annevk> | not sure if it has been done formally |
| 10:19 | <AryehGregor> | Are there any objections? |
| 10:19 | <AryehGregor> | I mean, have there been? |
| 10:21 | <annevk> | don't remember |
| 10:21 | AryehGregor | will ask again |
| 10:27 | <annevk> | references.json does not include Unicode |
| 10:28 | <annevk> | go figure :) |
| 10:43 | AryehGregor | submits some feedback |
| 11:45 | <zcorpan> | does the table nesting guy on help@ want <datagrid>? |
| 11:55 | <zcorpan> | or maybe something like http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1465 ? |
| 12:16 | <annevk> | hmm |
| 12:16 | <annevk> | http://dvcs.w3.org/hg/encoding/raw-file/tip/Overview.html#index-gb18030-code-point is incorrect |
| 12:17 | <annevk> | in particular "Let offset be the last pointer in index gb18030 that is equal to or less than pointer and let code point offset be its corresponding code point." would not select the last pointer/code point pair |
| 12:17 | <annevk> | I cannot think of better wording without special casing the last range |
| 12:17 | <annevk> | anyone? |
| 12:17 | <annevk> | oh wait, that does work, lol |
| 12:23 | <annevk> | okay, gbk/gb18030 encoders defined |
| 12:26 | <annevk> | foolip: defined them in such a way btw that merging them is trivial |
| 12:45 | <annevk> | is this correct: |
| 12:45 | <annevk> | "emit two bytes whose value is 0x7E each" |
| 12:46 | <AryehGregor> | "is each 0x7E" |
| 12:47 | <annevk> | thanks, still sounds weird :) |
| 12:47 | <AryehGregor> | A little. |
| 12:49 | <jgraham> | s/is/are/ |
| 12:49 | <jgraham> | Surely? |
| 12:49 | <jgraham> | Need plural agreement with "two" |
| 12:50 | <jgraham> | Otherwise I don't understand what you're trying to say, so it is confusing |
| 12:50 | <Philip`> | "emit the two bytes 0x7E 0x7E"? |
| 12:50 | <jgraham> | Yeah, or be shorter and more explicit :) |
| 12:51 | <gsnedders> | I'd drop the "each", at lesat |
| 12:51 | <gsnedders> | *least |
| 12:51 | <Philip`> | "emit(0x7E); emit(0x7E);" |
| 12:51 | <Philip`> | English is a rubbish language for pseudocode |
| 12:51 | <gsnedders> | So ill-defined. |
| 12:53 | <jgraham> | It's OK, some people have asked for specs to be written in javascript |
| 12:53 | <jgraham> | I can't wait for the great flame war of 2015 about whether it is acceptable to rely on ASI in a spec document |
| 12:53 | gsnedders | would quite like a spec that defined stuff in terms of algorithms in a formally defined language |
| 12:54 | <jgraham> | That's more or less like saying "I want a reference implementation" |
| 12:54 | <jgraham> | Not sure that the history of those is great |
| 12:55 | <Philip`> | To avoid the unfairness of picking a language that some people like and other people don't, all specs should write their algorithms in ABC |
| 12:56 | <jgraham> | The nice thing about English is because it's clearly ambiguous, people are more likely to yell at you if it is stupid rather than blindly assuming it is right just because it is written down |
| 12:56 | <Philip`> | (as per http://www.w3.org/TR/css3-color/#hsl-color) |
| 12:56 | <gsnedders> | jgraham: Well, how are the algorithms in HTML5 not a reference implementation, albeit in English? |
| 12:57 | <jgraham> | I guess Steven Pemberton likes ABC |
| 12:57 | <jgraham> | gsnedders: Because they are in English therefore not executable so people are less likely to blindly follow them without engaging their brain |
| 12:58 | <gsnedders> | jgraham: see the </sarcasm> bug in WebKit |
| 12:58 | <jgraham> | gsnedders: "less likely" |
| 13:01 | <smaug____> | hmm, html spec refers still to setAttributeNode |
| 13:02 | <smaug____> | kind, at least mentions it |
| 13:02 | <smaug____> | s/kind/kind of/ |
| 13:05 | <annevk> | known bug |
| 13:05 | <AryehGregor> | gsnedders, wait, didn't the spec say to do nothing special for </sarcasm>? Was that really them following the spec? |
| 13:09 | <gsnedders> | AryehGregor: They did do something special. |
| 13:09 | <AryehGregor> | Yes, which the spec didn't say to do. |
| 13:09 | <AryehGregor> | So they weren't blindly following the spec, right? |
| 13:10 | <AryehGregor> | Or did the spec originally say to do something special? |
| 13:10 | <gsnedders> | Indeed. |
| 13:10 | <gsnedders> | If they blindly followed the spec they wouldn't have had a bug, but as it was they deviated frm it. |
| 13:10 | <gsnedders> | *from |
| 13:11 | <Philip`> | The spec said to take a breath then process it like the "any other close tag" case, and they did the first step but not the second, I think |
| 13:11 | <annevk> | http://dvcs.w3.org/hg/encoding/raw-file/tip/Overview.html#hz-gb-2312-encoder |
| 13:11 | <Philip`> | Do the html5lib tests have coverage of that case now? |
| 13:12 | <gsnedders> | Philip`: Yes |
| 13:14 | <Philip`> | Good |
| 13:17 | <gsnedders> | (abarth wrote some which got upstream when fixing the bug) |
| 13:25 | <zewt> | adding "calling mime types media types" to the list of things people seem to insist on doing only to add to the net level of confusion in the world |
| 13:27 | <zewt> | in there with "calling KB KiB" and "python backtraces being upside down" |
| 13:35 | <annevk> | zewt: I have vague plans to define a better MIME spec at some point |
| 13:35 | <annevk> | prolly post URL |
| 13:55 | <zewt> | (whoops, that's another big one: URL/URI) |
| 13:56 | <annevk> | encoding -> charset? :p |
| 13:57 | <zewt> | that one's a bit different, since they really are just synonyms |
| 13:58 | <annevk> | in practice, sure |
| 13:58 | <zewt> | whereas there's the suggestion of subtle differences with the others (except nobody cares) |
| 13:58 | <annevk> | but a charset is like an index, and an encoding is like an encoding, in Encoding Standard terms |
| 13:58 | <zewt> | (well, minus backtraces; that's just some Python designer who hates everyone else) |
| 14:00 | <zewt> | i'd say if someone wants to mean something other than "a string protocol to encode a series of codepoints", they shouldn't use either of those words |
| 14:02 | <zewt> | anyway, off to work |
| 14:02 | <annevk> | yeah, agreed |
| 14:02 | <annevk> | but http://en.wikipedia.org/wiki/Character_encoding#Character_sets.2C_code_pages.2C_and_character_maps |
| 14:03 | <zewt> | i'd disagree with "distinct meanings" (a few people might try to use them like that, but I don't think that actually gives it a new meaning) |
| 14:04 | <zewt> | (except for codepage, which to me is very specifically Windows encodings) |
| 14:04 | <zewt> | (and IBM and DOS too I guess, if we go back far enough) |
| 14:04 | <zewt> | oh yeah. work. later :) |
| 14:21 | <MikeSmith> | zcorpan, annevk : please take a look at http://qa-dev.w3.org:8888/?doc=data%3Atext%2Fhtml%3Bcharset%3Dutf-8%2C%3C%21doctype%2520html%3E%250D%250A%3Ctitle%3E%3C%252Ftitle%3E%250D%250A%3Cinput%2520type%253Dimage%2520value%253Dfoo%2520alt%253Dbar%3E&showsource=yes now |
| 14:21 | <MikeSmith> | and let me know what you think |
| 14:23 | <zcorpan> | MikeSmith: A+ |
| 14:24 | <MikeSmith> | yay |
| 14:26 | <zcorpan> | MikeSmith: what's the rule for "all types except ..." vs "... types only"? whatever's shorter? |
| 14:26 | <MikeSmith> | yep |
| 14:26 | <MikeSmith> | the list of allowed types for autocomplete is just ridiculously long |
| 14:30 | <MikeSmith> | I guess I can try having them all be "... types only" and see how it looks |
| 14:30 | <MikeSmith> | hmm, no, almost certain it's going to cause line breaks for many screens |
| 14:30 | <zcorpan> | "all types except file and image" looks nice but i'm less comfortable with "all types except hidden, range, color, checkbox, radio, file, submit, image, reset, and button" |
| 14:30 | <MikeSmith> | yeah |
| 14:30 | <MikeSmith> | ah yeah, the one for value would be huge too |
| 14:30 | <MikeSmith> | hugest |
| 14:30 | <MikeSmith> | if we listed the valid types instead of the invalid ones |
| 14:39 | <annevk> | MikeSmith: looks good, formatting could be better though |
| 14:40 | <annevk> | "accept file type only" does not make accept and file look distinct enough |
| 14:41 | <zcorpan> | annevk: why do they need to look more distinct? |
| 14:43 | <annevk> | I don't get what's going on when looking at it |
| 14:44 | <zcorpan> | ah. maybe it should be phrased differently? |
| 14:44 | <zcorpan> | "only when |type| is file"? |
| 14:45 | <annevk> | maybe, or maybe the conditions should be smaller, gray, or some such |
| 14:46 | <zcorpan> | that'd make people not read them, which seems opposite of what we want :-) |
| 14:48 | <annevk> | just different color then or parenthesis, dunno |
| 14:48 | <annevk> | something that makes them offset from the attribute |
| 14:52 | zcorpan | filed https://bugs.webkit.org/show_bug.cgi?id=84036 |
| 14:59 | <zcorpan> | the typed array spec is a bit confusing in how it has IDL with variables |
| 15:00 | <zcorpan> | "interface TypedArray : ArrayBufferView {" where TypedArray is not the interface name, but is to be replaced with one of Int8Array, Uint8Array, etc |
| 15:01 | <zcorpan> | i don't understand why the members aren't all defined on ArrayBufferView and then the specific interfaces have no members |
| 15:02 | <zcorpan> | except the constant |
| 15:04 | <zcorpan> | maybe the setters need to be different? |
| 15:08 | <annevk> | so BlobBuilder is not even implemented unprefixed? |
| 15:08 | <annevk> | whoa |
| 15:10 | <gsnedders> | zcorpan: You need to do modulo arithmetic, so you need some internal property if they're all on ArrayBufferView. |
| 15:10 | <gsnedders> | (giving what your base is) |
| 15:10 | <jgraham> | annevk: And Microsoft won't drop it? |
| 15:10 | <gsnedders> | s/base/modulus/ |
| 15:13 | <zcorpan> | annevk: i see WebKitBlobBuilder and MozBlobBuilder, no BlobBuilder (in webkit and gecko) |
| 15:14 | <zcorpan> | gsnedders: k |
| 15:45 | <annevk> | where's Gecko's implementation of iso-2022-kr to Unicode? |
| 15:55 | <dglazkov> | good morning, Whatwg! |
| 16:16 | <jgraham> | Things I have learnt: it is important not to get confused between ancestors and children |
| 16:18 | <Philip`> | Have you accidentally buried your children? |
| 16:20 | <ksweeney> | whoa…dark |
| 16:23 | <annevk> | every encoder apart from iso-2022-kr and big5 is now defined |
| 16:23 | <annevk> | the former because I should fix the decoder some and the latter because well, because it's big5 really |
| 16:23 | <annevk> | and big5 sucks |
| 16:56 | <jgraham> | http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=1468 <--HTML is awesome |
| 16:57 | <jgraham> | (try that in WebKit/Gecko) |
| 16:57 | <annevk> | it's actually nice in that <frameset> is just another element |
| 16:58 | <annevk> | special casing <frameset> as HTML does is actually far less elegant I think |
| 16:58 | <annevk> | (that sites rely on any of this is absurd) |
| 16:58 | <annevk> | are you gonna file a bug on HTML jgraham? |
| 16:59 | <jgraham> | Well I assume this behaviour isn't deliberate but happened because (non-Opera) browsers didn't special case <frameset> |
| 16:59 | <jgraham> | I'm OK if you want to file the bug :) |
| 16:59 | <jgraham> | (but I can if you don't want to) |
| 17:16 | <TabAtkins> | jgraham: You'll want to subset CSS3 Text more carefully - there may still be some instability in some part of that. The rest should be stable. |
| 18:17 | <jzaefferer> | hey MikeSmith, any news on the html validator? |
| 18:17 | <MikeSmith> | hey jzaefferer |
| 18:18 | <MikeSmith> | I'm waiting on hsivonen to review some patches I want to land |
| 18:18 | <MikeSmith> | but he seems to be busy lately |
| 18:18 | <MikeSmith> | I'll ping him again |
| 18:18 | <MikeSmith> | in the mean time, I will give you guys some jars you can use |
| 18:20 | <MikeSmith> | my main concern is that about if we actually release jars that contain a bunch of 3rd-party code, how to make sure we are complying with the licenses for all that 3rd-party stuff |
| 18:21 | <MikeSmith> | jzaefferer: anyway I will aim to have something for you this week |
| 19:19 | <jgraham> | TabAtkins: Thanks. Personally I don't want to subset anything at all :) Also I am a bit surprised that flexbox is now considered stable. Is that something that the WG agree with or is it just that there are a few implementations so you would have to be insane to change it now? |
| 19:20 | <TabAtkins> | The latter. |
| 19:20 | <TabAtkins> | I'm not changing anything without "OMG IT BROKEN" bugs. |
| 19:35 | <annevk> | jsbell: http://code.google.com/p/stringencoding/ looks awesome :) |
| 19:35 | <jsbell> | annevk: thanks. it's gone a bit overboard for proof-of-concept. |
| 19:37 | <jsbell> | annevk: I have tests for most of the encodings (via an index->python->encode->decode->encode->js pipeline); having issues with both kr encodings, not sure where the problem lies yet |
| 19:37 | <jsbell> | (haven't pushed that yet tho) |
| 19:37 | <annevk> | I guess the math could be wrong for the Korean encodings :/ |
| 19:37 | <annevk> | I hope not, and I did check but it's not exactly pretty at the moment |
| 19:39 | <jsbell> | I'll ping you if I fail to make progress. |
| 19:43 | <annevk> | cool, the Encoding standard itself is almost complete now |
| 19:43 | <annevk> | iso-2022-kr encoder is the only encoder not defined |
| 19:43 | <annevk> | well and big5, still awaiting some research in that area |
| 19:44 | <annevk> | but prolly good enough for integration into HTML, DOM, XHR, etc. |
| 19:45 | <annevk> | and see if there's interest in defining "encoding sniffing" |
| 19:46 | <jgraham> | TabAtkins: OK, I guess you might be less insane than the group as a whole :) |
| 19:47 | <jgraham> | annevk: Cool |
| 19:47 | <TabAtkins> | Hey, don't write me off the crazy list. I *did* rewrite the entire spec already. |
| 19:47 | <gsnedders> | TabAtkins: you be mad. |
| 19:51 | <annevk> | jgraham: yeah, I'm happy with progress today :) |
| 19:51 | <jwalden> | I believe "u mad bro" is the proper Internet lingo for that sentiment |
| 19:52 | <TabAtkins> | jwalden: Nah, that's a different sentiment. |
| 19:52 | <TabAtkins> | Alternate use of "mad". |
| 19:52 | <jwalden> | it can be repurposed |
| 19:52 | <jwalden> | memes are made to be repurposed |
| 19:54 | <gsnedders> | jwalden: Your face is made to be repurposed |
| 19:54 | <jwalden> | on that note, anyone who hasn't seen http://webkitmemes.tumblr.com/ and http://mozillamemes.tumblr.com/ and now http://qtmemes.tumblr.com/ and http://pulseaudiomemes.tumblr.com/ prepare to squander your free time for a bit :-D |
| 19:54 | <jwalden> | gsnedders: *trollface* |
| 19:55 | <jwalden> | quality varies for each, of course |
| 19:55 | jwalden | actually kind of agrees with kling that mozillamemes could do for more quality over quantity |
| 19:56 | <jwalden> | on the other hand, not sure I really want arbitrary-ish quality controls in place here, either :-) |
| 19:58 | <jgraham> | Hmm, I thought the only pulseaudio meme was "killed pulseaudio, sound started working" |
| 20:04 | <jgraham> | annevk: Happily the order thing is harder to get wrong than right since HTML defines an ordered list of descendant browsing contexts |
| 20:05 | <annevk> | normal traversal order? |
| 20:05 | <annevk> | I wonder what I did for Fullscreen |
| 20:06 | <jgraham> | Yeah, depth first |
| 20:06 | <jgraham> | Did you file a bug about the frameset thing btw? |
| 20:07 | <annevk> | let me check if it isn't already filed |
| 20:07 | <annevk> | I thought it was filed already, guess it isn't |
| 20:11 | <annevk> | jgraham: https://www.w3.org/Bugs/Public/show_bug.cgi?id=16750 |
| 20:13 | <jgraham> | annevk: Thanks |
| 20:29 | <zcorpan> | jgraham: do we have urls for the frameset thing? |
| 20:41 | <TabAtkins> | sync XHR during onbeforeunload is high on the list for why we're killing sync XHR, right? |
| 20:43 | <zcorpan> | can we make it throw in onbeforeunload? |
| 20:43 | <jwalden> | bite your tongue |
| 20:43 | <zcorpan> | i guess the answer is "no" |
| 20:43 | <annevk> | sync XHR in general is why we're killing it :) |
| 20:43 | <jwalden> | four-letter words are not to be spoken in this channel |
| 20:43 | <gsnedders> | jwalden: My tongue already hurts from doing that earlier, do I have to do that again? |
| 20:43 | <jwalden> | gsnedders: it gets easier and less painful the more you do it |
| 20:43 | <TabAtkins> | I'm just responding to the sync getImageDataHD thread where someone defends sync XHR by offering an example where he uses it in beforeunload. |
| 20:43 | <gsnedders> | Ah! Practice, right! |
| 20:43 | <annevk> | jwalden: y u no like HTML |
| 20:44 | <jwalden> | annevk: I spell it XHTML |
| 20:44 | <jgraham> | zcorpan: urls? |
| 20:44 | <jgraham> | Oh you mean sites that actually do that? |
| 20:44 | <jwalden> | or HTML5 |
| 20:44 | <zcorpan> | jgraham: yeah |
| 20:44 | <zcorpan> | former |
| 20:44 | jwalden | imagines a slowpoke meme |
| 20:45 | <annevk> | you win :) |
| 20:45 | <annevk> | nn all! |
| 20:45 | <gsnedders> | nn! |
| 20:47 | <jwalden> | THE DAY IS MINE |
| 20:47 | <gsnedders> | jwalden: MINE is a four letter word. |
| 20:47 | <jwalden> | :-P |
| 20:49 | <zcorpan> | TabAtkins: so where's your parser spec? |
| 20:49 | <TabAtkins> | I'm in the middle of writing it. |
| 20:49 | <TabAtkins> | The completed tokenizer is at http://dev.w3.org/csswg/css3-syntax |
| 20:51 | <zcorpan> | TabAtkins: have you looked at http://simon.html5.org/specs/quirks-mode#the-hashless-hex-color-quirk and http://simon.html5.org/specs/quirks-mode#the-unitless-length-quirk ? |
| 20:51 | <TabAtkins> | zcorpan: I have! I've modified the tokenzier to handle the hashless hex color quirk better (it retains the full representation of a number, so "000000" doesn't just collapse into "0"). |
| 20:52 | <zcorpan> | TabAtkins: nice! btw there's also the style="{ color:red }" quirk that i haven't specified because i hope it can be dropped |
| 20:52 | <TabAtkins> | The unitless length quirk algorithm seems incomplete - I know Firefox supports unitless lengths in the 'font' shorthand and uses a simple heuristic to distinguish it from <number> line-height. |
| 20:53 | <TabAtkins> | Is that considered unnecessary? |
| 20:53 | <zcorpan> | TabAtkins: yeah i looked at some data and didn't find any page relying on this quirk working for the 'font' shorthand in web200904 |
| 20:53 | <TabAtkins> | (If so, I can totally handle the unitless length quirk really easily to.) |
| 20:53 | <TabAtkins> | Okay, cool. |
| 20:53 | <TabAtkins> | That'll be in the parser stage. |
| 20:54 | <zcorpan> | nice |
| 20:54 | <TabAtkins> | I'm wondering if it makes sense to define parsing of Selectors and individual at-rules in Syntax, or delegate it? |
| 20:55 | <zcorpan> | dunno. i'll have to read css3-syntax some day |
| 20:55 | <TabAtkins> | Gimme another week or two and I'll be done enough for you to review the whole thing. |
| 20:55 | <TabAtkins> | Or you can review now, if you want. Simon Sapin has been giving me feedback on the tokenizer. |
| 20:56 | <jgraham> | Dammit I guess I have to implement this :) |
| 20:56 | <zcorpan> | yeah it won't be right now since i'm gonna go to bed now :-) |
| 20:56 | <TabAtkins> | jgraham: If your current strategy produces the same output, no change is needed. ^_^ |
| 20:58 | <jgraham> | TabAtkins: I personally don't have a current strategy :) |
| 20:59 | <jgraham> | I just need to imeplemt it due to an inability to see a Hixie-style parsing spec without wanting to implement it |
| 20:59 | <TabAtkins> | Oh, okay! |
| 20:59 | <Ms2ger> | zcorpan, wdyt about making the <font>/underline thing apply in all modes? Feasible? |
| 20:59 | <zcorpan> | Ms2ger: probably is, yeah |
| 20:59 | <zcorpan> | Ms2ger: do you know of any standards-mode pages relying on it? |
| 20:59 | <jgraham> | zcorpan: BTW I don't know of any sites that break due to having both frameset and body at once |
| 21:00 | <zcorpan> | jgraham: k |
| 21:00 | <jgraham> | But http://www.geoffchappell.com/ breaks in Opera due to replacing <body> with <frameset> at runtime |
| 21:00 | <Ms2ger> | zcorpan, no, I just don't like mode-differences |
| 21:00 | <zcorpan> | same here :-) |
| 21:00 | <jgraham> | And overall it should be a simplification when we fix that to just make frameset like a normal element rather than giving it special rules (I think) |
| 21:01 | <jgraham> | (which is presumably what other browsers do) |
| 21:01 | <zcorpan> | jgraham: yeah i can see that it can make layout simpler |
| 21:01 | <Ms2ger> | I can poke around a bit after I've removed <font font-weight> and BlobBuilder |
| 21:06 | <zcorpan> | ok i've made http://simon.html5.org/specs/quirks-mode#the-font-element-text-decoration-color-quirk always apply |
| 21:07 | zcorpan | -> sleep |
| 22:54 | <Hixie> | !summon abarth |
| 22:54 | <Hixie> | anyone got IE10? |
| 22:55 | <Hixie> | http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1470 |