| 00:49 | <Yuhong> | # [16:32] <zewt> it sounded to me like he was equating "IE's encodings" to "the underlying codepage tables in Windows", which seemed wrong, but for legacy codepages it doesn't really matter to me which implementation to move towards, as long as we do |
| 00:50 | <Yuhong> | It is pretty close already anyway, and legacy encoding is not something people would develop new content to. |
| 00:50 | <Yuhong> | Nobody cares about JIS X 0212 support in EUC-JP. |
| 00:50 | <Yuhong> | For examle. |
| 05:07 | <hsivonen> | jgraham: I was not stating an official Mozilla position. I don’t even know by what mechanism Mozilla could develop an official position on something. Mozilla is a diverse community of people with a diversity of opinion. |
| 05:08 | <hsivonen> | jgraham: The word “our” you were wondering about referred to me and a non-zero number of other engineers who work on Gecko and who may identify themselves if they so choose. |
| 05:11 | <hsivonen> | Hixie_: When you get mutually contradictory feedback from multiple implementors who have an active interest in a feature, it makes sense to “carefully consider” and arbitrate one way of speccing it. |
| 05:11 | <Hixie_> | hsivonen: that's what i did |
| 05:11 | <Hixie_> | hsivonen: i just didn't arbitrate to the one way mozilla wants :-) |
| 05:11 | <Hixie_> | (in this particular case) |
| 05:12 | <hsivonen> | Hixie_: however, when you get negative implementor feedback and still choose to keep stuff in the spec, in practice the part of spec is waiting for another implementor to come along and implement what’s in the spec |
| 05:12 | <Hixie_> | everything in the spec is waiting for implementations, sure |
| 05:13 | <hsivonen> | Hixie_: pointing to Web SQL is not a great example. It should not be that hard to get something dropped. Moreover, it has not even been successfully dropped from all implementations. |
| 05:14 | <Hixie_> | hard? i dropped websql literally in the meeting where mozilla and microsoft said they weren't interested, iirc. |
| 05:16 | <hsivonen> | Hixie_: in any case, keeping stuff in the spec is not neutral even if the features still have the opportunity to fail to get implemented |
| 05:17 | <hsivonen> | Hixie_: if there is a dispute and you leave something in the spec, you are tilting the odds in favor of what’s in the spec getting implemented by someone |
| 05:17 | <Hixie_> | yes, that's the idea |
| 05:18 | <Hixie_> | the job of a spec editor is to be opinionated and to do what he thinks is best to improve the web the best way, not to be neutral. neutral is what gets you committee-driven wishy-washy design. |
| 05:20 | <hsivonen> | Hixie_: you think it’s your job to be opinionated against implementor feedback in cases where feedback from active implementors goes basically in one direction |
| 05:20 | <hsivonen> | ? |
| 05:20 | <hsivonen> | (as opposed to the case of arbitrating contradictory feedback from multiple active implementors) |
| 05:21 | <Hixie_> | hsivonen: i have feedback from multiple vendors on this particular issue |
| 05:21 | <hsivonen> | Hixie_: oh? |
| 05:21 | <Hixie_> | though yes, in the abstract, even if it was just one vendor, sure |
| 05:22 | <hsivonen> | Hixie_: are the other vendors actively implementing |
| 05:22 | <hsivonen> | ? |
| 05:22 | <Hixie_> | (i.e. if we have a use case X that everyone agrees should be done, and only one vendor has made a comment, and that comment is obviously wrong (not saying it's that stark in this case, of course), then obviously my job is to ignore that vendor's feedback) |
| 05:22 | <Hixie_> | hsivonen: i'm not aware of any actively implementing |
| 05:23 | <hsivonen> | Hixie_: uh. Firefox has had an implementation of context menu items (not the spec way) for months. (Probably on the release channel even, I don’t recall it getting turned off.) |
| 05:23 | <Hixie_> | yes |
| 05:23 | <Hixie_> | i meant any others |
| 05:24 | <hsivonen> | Hixie_: I see |
| 05:24 | <Hixie_> | sorry, thought that was clear :-) |
| 05:25 | <hsivonen> | Hixie_: well, to the extent I’ve talked with other Gecko engineers, this pattern in general (not necessarily in the context menu case in particular) is the top beef with the WHATWG way of working. |
| 05:25 | <Hixie_> | what other cases are there? |
| 05:28 | <hsivonen> | Hixie_: I forget right now, so can’t be too serious. |
| 05:29 | <Hixie_> | if there are cases of me doing something that mozilla people aren't happy with, please don't hesitate to immediately bring them to my attention, either in public or privately, so that i can make sure i review the situation |
| 05:29 | <Hixie_> | that applies now or in the future |
| 05:29 | <hsivonen> | Hixie_: the pattern that your opinion stays in the spec unless two implementors actively implement something else is the real annoyance with the WHATWG way of doing things |
| 05:30 | <Hixie_> | whose opinion should be in the spec instead? :-) |
| 05:30 | <Hixie_> | maybe we should get them to edit the spec :-) |
| 05:32 | <hsivonen> | Hixie_: well, if you get negative implementor feedback, I think the spec should change even before implementors show they are serious by implementing something that’s not specced |
| 05:33 | <hsivonen> | Hixie_: I’m pretty sure I’ve let you know when you’ve done something specific I wasn’t happy with |
| 05:33 | <Hixie_> | no, that i disagree with. what matters is what the feedback is, not just who says it. |
| 05:34 | <hsivonen> | Hixie_: or, at least, the spec text should now appear together with the well-baked stuff so that other implementors don’t accidentally implement disputed stuff out of not having paid attention to dispute |
| 05:34 | <Hixie_> | if i put something in the spec, and google tells me "hey you should make this work like X instead", where X is something that's good for google but bad for the web, then i think it'd be wrong for me to put X in. And I don't think it's worth putting a warning in the spec there for that kind of case. |
| 05:35 | <Hixie_> | we do have warnings for other things. |
| 05:35 | <Hixie_> | (usually though by the time i know it's controversial i can also fix it right then) |
| 05:35 | <hsivonen> | Hixie_: I can’t argue with that kind of formulation |
| 05:35 | <Hixie_> | heh |
| 05:35 | <Hixie_> | i'm just saying it's not black and white |
| 05:36 | <Hixie_> | i agree that there are cases where we should have warnings |
| 05:36 | <Hixie_> | i would even grant that we should have them more often |
| 05:36 | <Hixie_> | let me know if you think i should add one :-) |
| 05:36 | <Hixie_> | (last one i added i think was for bz) |
| 05:38 | <hsivonen> | FWIW, *my* personal latest beef is that when I was working on the script/stylesheet interblocking stuff, you (IIRC) insisted on keeping the unworkable spec text. So I had to make something up. Then a WebKit dude raised the same issue over a year (?) later and you found in favor of WebKit. |
| 05:38 | <hsivonen> | and now I’ve paged out all that stuff and moved on and Gecko is wrong per spec |
| 05:39 | <Hixie_> | the lag is definitely an issue. i'm actively working on reducing that. |
| 05:39 | <Hixie_> | not sure about the specifics of that case though |
| 05:39 | <hsivonen> | I think it’s a mild instance of the pattern of you keeping your way so that implementations end up differing |
| 05:40 | <hsivonen> | in that case, your way was always fictitious, AFAICT |
| 05:40 | <Hixie_> | if i didn't have good rationale for doing that, and it wasn't just that i hadn't gotten to it yet, then i apologise. (well i apologise in any case.) |
| 05:41 | <hsivonen> | Hixie_: ok. |
| 05:41 | <Hixie_> | (i don't recall that specific case so not sure what the situation was) |
| 05:41 | <Hixie_> | oh wait, was this the document.write() thing? |
| 05:41 | <hsivonen> | (what you wanted was the most consistent thing, IIRC. just unworkable with real event loops) |
| 05:42 | <hsivonen> | doc.write and parser-blocking sheets, yeah |
| 05:42 | <Hixie_> | wasn't what you wanted that the input stream track on a byte-by-byte basis whether the text was from document.write() or something else? |
| 05:43 | <hsivonen> | yeah, but I had to come up with *something* on my own, when you insisted on keeping the spec in a state that wasn’t going to fly |
| 05:43 | <Hixie_> | if it's that then the reason i didn't do what you wanted is that i thought that was a huge implementation burden, and i thought that there was a better way to do it. the reason it took so long to do is just that it took me forever to get around to it due to lag, which i am working to reduce |
| 05:43 | <Hixie_> | you should have found the better solution i eventually found :-P |
| 05:43 | <Hixie_> | wasn't just that i sided with webkit |
| 05:44 | <Hixie_> | i sided with IE, Gecko 3.6, Opera, and WebKit :-P |
| 05:44 | <Hixie_> | (er, Firefox 3.6) |
| 05:44 | <hsivonen> | not with IE, though, right? |
| 05:44 | <Hixie_> | well, IE's behaviour is pretty wacked iirc, but it didn't have any evidence of tracking per-byte source either |
| 05:52 | <hsivonen> | s/should now appear/should NOT appear/ above |
| 07:00 | <JonathanNeal> | Should the links inside a <nav> also be in a <ul> and <li>, or are there other appropriate elements they could be in? |
| 07:04 | <Hixie_> | <p> is fine too |
| 07:04 | <Hixie_> | or just nothing, if it's one paragraph |
| 07:06 | <jgraham> | hsivonen: Oh. The use of "our" to mean "an unnamed and hiterto unmentioned group of individuals distict from the organisation I nominally represent", was very unclear |
| 07:07 | <JonathanNeal> | Something bothers me about the readability of the <ul>. I want to have a collection of links, but I want them to be meaningful. I'm not sure if <nav> provides enough meaning to drop the <ul> or even <p>. |
| 07:07 | <JonathanNeal> | Thanks for the input, Hixie_. |
| 07:08 | <AryehGregor> | jgraham, generally in the W3C, David Baron seems to be the only one who presents official Mozilla positions. I think he normally says things like "Mozilla supports X" when he does so, like "Mozilla supports the publication of X as a FPWD." |
| 07:08 | <AryehGregor> | He's our AC rep, so he kind of has to speak officially sometimes. |
| 07:11 | <jgraham> | AryehGregor: Right. I *know* that Mozilla people don't claim to give official positions, which is why I asked. Someone who didn't know that could reasonably assume from the phrasing of the email that hsivonen was in fact giving a Mozilla position. |
| 07:11 | <AryehGregor> | I guess hsivonen might speak de facto officially for Mozilla on matters relating to parsing, since he owns that module. |
| 07:11 | <AryehGregor> | Well, yeah. |
| 07:11 | <AryehGregor> | The other thing about Mozilla is, we don't have a PR team haranguing us about how to phrase our communications. :) |
| 07:12 | <AryehGregor> | (at Google I was allowed to say whatever I wanted, but I was asked on at least one occasion to phrase something so that it couldn't be misconstrued as an official Google position) |
| 07:12 | <jgraham> | To be fair all of this is true at Opera as well |
| 07:12 | <AryehGregor> | It seems to be more true at Mozilla than anywhere. |
| 07:13 | <annevk> | Opera (used to have?) has one person per group that can speak for Opera |
| 07:13 | <AryehGregor> | Since really, there's nobody who *can* give an official position, generally speaking. |
| 07:13 | <jgraham> | annevk: Right, that person nominally exists, although I guess it is mainly LEB now |
| 07:14 | <annevk> | though whenever I had that position I rarely did |
| 07:14 | <jgraham> | But in general one should never assume that something you hear from someone at Opera is something official |
| 07:14 | <jgraham> | Unless they say something that makes it obvious |
| 07:16 | <jgraham> | (most of the time this is a somewhat academic question. If you say something like "we are implementing this" it is obviously de-facto the case that you are speaking for Mozilla/Google/whoever, even if you are not their oficial representative) |
| 07:17 | <AryehGregor> | I think we all understand this, but it's aggravating when you have to deal with people who don't and start interpreting everything you say as official. |
| 07:17 | <AryehGregor> | Shelley Powers isn't around anymore, is she? |
| 07:17 | <JonathanNeal> | How weird, "The menu element is not supported by browsers yet. It would probably be better to wait for implementations." I better not implement it if it hasn't been implemented yet? |
| 07:17 | <AryehGregor> | She would always do that back in the day. |
| 07:17 | <AryehGregor> | "Is that Google's official position?" "No. That's why I said 'I'." |
| 07:17 | <AryehGregor> | JonathanNeal, don't use it in pages if browsers don't support it yet. |
| 07:21 | <JonathanNeal> | Thanks AryehGregor. |
| 07:24 | <JonathanNeal> | Would this be semantically acceptable? <nav><a href="/1">Page 1</a> <a href="/2">Page 2</a> <a href="/3">Page 3</a></nav> |
| 07:25 | <JonathanNeal> | Coming from HTML4, I would think no. But if a <nav> defines a section that contains only navigation links, it seems game. |
| 07:27 | <AryehGregor> | JonathanNeal, of course it would be. You don't have to mark up every list with a list element. |
| 07:27 | <AryehGregor> | You can say "I like apples, oranges, and pears" without having to do "I like <ul><li>apples<li>oranges<li>pears</ul>" and adding the commas and "and" using CSS. |
| 07:28 | <AryehGregor> | If you're already using an element for some reason, like a block element for styling, then you should generally use a semantic element instead of <div>/<span>, if one exists that's appropriate. |
| 07:28 | <AryehGregor> | But you don't have to gratuitously add elements that you don't need. |
| 07:29 | <AryehGregor> | Same goes for <abbr>, which I never use. You can if you want, but you don't have to use it just because it's there. |
| 07:29 | <JonathanNeal> | How is a browser supposed to "support" <menu> ? |
| 07:29 | <AryehGregor> | Last I heard, they aren't interested. |
| 07:30 | <SimonSapin> | AryehGregor: isn’t the point of <abbr> to have the "long version" in the title attribute? |
| 07:30 | <AryehGregor> | But here's the spec, with conformance requirements, if you're interested: http://www.whatwg.org/specs/web-apps/current-work/multipage/interactive-elements.html#the-menu-element |
| 07:30 | <AryehGregor> | SimonSapin, sure, if you want it. Nothing in the spec requires that you use it. |
| 07:30 | <AryehGregor> | If you do use it, you have to use it according to its semantics, but it's not mandatory. |
| 07:31 | <JonathanNeal> | Yea, I was just there, reading about it. Without a type attribute, it's a kind of list of commands. |
| 07:33 | <JonathanNeal> | Not sure how liberal or conservative one is to take "commands". Are they UI commands, application commands, or commands related to the section or document, like a "best viewing" link under a video? |
| 07:35 | <AryehGregor> | JonathanNeal, don't use it until browsers support it. Otherwise your page will break when they do support it, because it will behave differently. |
| 07:35 | <AryehGregor> | Once browsers support it, decide if you need it based on functionality. |
| 07:35 | <AryehGregor> | Don't use semantics for the sake of semantics. |
| 07:35 | <JonathanNeal> | What behavior would they add. There's no behavior in the spec that seems to be troubling. |
| 07:35 | <AryehGregor> | (I've heard browsers aren't interested in supporting it) |
| 07:39 | <annevk> | JonathanNeal: I use <nav><a>... </nav> on my site |
| 07:39 | <annevk> | fwiw |
| 07:39 | <JonathanNeal> | Should I have multiple <nav> in a section? |
| 07:53 | <zcorpan> | AryehGregor: if IE10 have implemented the spec, why should the rest of us not follow suit? |
| 07:55 | <AryehGregor> | zcorpan, for one thing, we aren't sure it's web-compatible. |
| 07:55 | <AryehGregor> | IE has the option of falling back to a compatibility mode if the page doesn't work, which other browsers don't, so they can be relatively aggressive in matching specs. |
| 07:55 | <zcorpan> | AryehGregor: opera and webkit already seem to expose HTMLDocument members everywhere |
| 07:55 | <AryehGregor> | That's not the same issue. |
| 07:56 | <AryehGregor> | I mean, it's conceptually related, but compat-wise it's not. |
| 07:56 | <zcorpan> | true |
| 07:56 | <AryehGregor> | In any case, the spec matches no one but IE10. |
| 07:57 | <zcorpan> | what should happen for documents when there's no mime type (e.g. createDocument)? |
| 07:57 | <AryehGregor> | And IE10 has the code for its old mode of operation still lying around, so they can reduce codepaths if we go back to the IE9/Gecko/WebKit way. |
| 07:57 | <AryehGregor> | I didn't test that last night, I'll do so today. |
| 07:57 | <AryehGregor> | I volunteer to do all the testing, write and commit the spec, and write and commit tests. |
| 07:57 | <AryehGregor> | As long as no one objects. |
| 08:00 | <zcorpan> | i think it's sad to not try to implement the current spec. i mean, it's not clear that it's *not* compatible |
| 08:00 | <AryehGregor> | Why don't we spend our implementation efforts on things that matter more? |
| 08:01 | <AryehGregor> | Who honestly cares what namespace is produced by document.implementation.createDocument(null, "", null).createElement("x")? |
| 08:01 | <AryehGregor> | Let's try to do something worthwhile, like get rid of XSLT. |
| 08:01 | <AryehGregor> | I agree entirely that we should simplify where possible, but not if all major implementations agree. |
| 08:02 | <AryehGregor> | Unless it's something we really want to change. |
| 08:02 | <AryehGregor> | Like maybe Attr inheriting from Node or something. |
| 08:02 | <annevk> | zcorpan: why did Opera change to MIME type? |
| 08:02 | <zcorpan> | annevk: don't know |
| 08:03 | <zcorpan> | annevk: i've pushed for implementing the spec, but it hasn't happened yet |
| 08:03 | <annevk> | yeah, keeping different kind of documents around is just sad |
| 08:05 | <zcorpan> | AryehGregor: what namespace should be used for new Document().createElement('x') ? |
| 08:06 | <AryehGregor> | zcorpan, whatever we want, because that was just made up like five minutes ago and no one implements it, right? |
| 08:06 | <AryehGregor> | Let me test create(HTML)Document() first and I'll get back to you. |
| 08:06 | <zcorpan> | ok |
| 08:23 | <jgraham> | AryehGregor: Yeah, getting rid of XSLT isn't going to happen |
| 08:33 | <zcorpan> | AryehGregor: note that changing the xmlns attribute dynamically doesn't change the root element's namespace |
| 08:33 | <zcorpan> | AryehGregor: you'd have to swap out the element with a new one |
| 08:34 | <jgraham> | Seriously, can someone please fix the bugmail to be plain text by default again? |
| 08:35 | <MikeSmith> | hmm |
| 08:35 | <MikeSmith> | I can |
| 08:35 | <hsivonen> | jgraham: I agree my use of “our” was bad. :-( |
| 08:36 | <zcorpan> | AryehGregor: http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1838 |
| 08:37 | <hsivonen> | jgraham: however, if you read it really carefully, “our” presents a WHATWG problem, so there’s no “our” introducing any HTML WG-scoped opinion |
| 08:38 | <hsivonen> | jgraham: there is use of “we” nearby where “we” refers to the HTML WG |
| 08:39 | <MikeSmith> | fekking bugzilla should make the bugmail format an user option |
| 08:40 | <hsivonen> | am I the only one here who likes the new bugmail format? |
| 08:43 | <MikeSmith> | hsivonen: I don't mind it beacuse I see it in plain text still anyway |
| 08:43 | <jgraham> | hsivonen: I don't think the fact that it isn't a point about the HTMLWG per-se is very relevant. |
| 08:44 | <jgraham> | hsivonen: But probably it has now been discussed more than merited over the choice of one word in an email. |
| 08:49 | <zcorpan> | annevk: yeah i love the xml-stylesheet bug |
| 08:49 | <zcorpan> | such irony |
| 08:51 | <zcorpan> | annevk: i had to take out all UA conf requirements and i had to fight to have the authoring conf requirements in there |
| 08:51 | <zcorpan> | annevk: if the xml wg had their way, the spec wouldn't have any requirements at all |
| 08:53 | <zcorpan> | but at least we managed to get CONSENSUS in the end and publish a new REC, and that's what really matters |
| 08:56 | <hsivonen> | case. still a problem: https://bugzilla.mozilla.org/show_bug.cgi?id=800600 |
| 08:59 | zcorpan | recalls http://wiki.whatwg.org/wiki/Video_type_parameters |
| 09:01 | <Stevef__> | hsivonen: i like it too, find it much easier to read |
| 09:01 | <zcorpan> | how does one post on w3cmemes? |
| 09:02 | <paul_irish> | i think you talk to annevk or sgalineau |
| 09:02 | darobin | whacks paul_irish with the secret handshake handbook |
| 09:02 | <Stevef__> | hsivonen: also responded to your post about the 'plan' didn't touch most of your comments, leave that to the lawmakers |
| 09:02 | <zcorpan> | annevk: ^ |
| 09:03 | <annevk> | give me a sec |
| 09:03 | <paul_irish> | i'm just guessing based on the activity i see there :) no insider knowledge! |
| 09:03 | <MikeSmith> | wtf the eu got a nobel prize |
| 09:03 | <annevk> | paul_irish: you want the ability to post? |
| 09:03 | <paul_irish> | yesplz |
| 09:04 | <annevk> | MikeSmith: they should get one for privacy (well, when compared to the US) |
| 09:04 | <darobin> | MikeSmith: someone had to thank it before it disintegrates... |
| 09:04 | <annevk> | but there's no Nobel prize for that |
| 09:04 | <MikeSmith> | I'm pretty sure who posts the w3cmemes stuff is this guy: http://i.imgur.com/xADuy.jpg |
| 09:04 | <MikeSmith> | but not sure how to contact him |
| 09:05 | <MikeSmith> | sorry, I meant the guy in that picture is now the one who decides on all the nobel peace prizes |
| 09:10 | <jgraham> | Man, if you keep up all this memes stuff W3C will never get the Nobel Peace Prize it so obviously deserves |
| 09:11 | <Stevef__> | darobin: getting 404 on http://dev.w3.org/html5/spec/spec.html ? |
| 09:11 | <jgraham> | Stevef__: http://dev.w3.org/html5/spec/ |
| 09:12 | <darobin> | Stevef__: it's looking like there's a problem in the update script |
| 09:12 | <Stevef__> | ok thanks |
| 09:12 | <darobin> | I'm seeing very strange problems with our tools in general in fact |
| 09:12 | <darobin> | we're on it |
| 09:13 | <MikeSmith> | by "we're on it" darobin means that I create the strange problems and he finds ways to fix them |
| 09:13 | <darobin> | oh no that's not true |
| 09:13 | <darobin> | we both create strange problems :) |
| 09:14 | <darobin> | just not the same ones |
| 09:14 | <MikeSmith> | we're innovating! |
| 09:14 | <darobin> | yeah, HTML has too many solutions so we're building new problems |
| 09:15 | <MikeSmith> | taking it way out of the box |
| 09:16 | <MikeSmith> | the only way I could have constructed a worse document build setup would have been to add some RDF stuff in there |
| 09:16 | <darobin> | oooh great idea, let's do that! |
| 09:17 | <jgraham> | There *isn't* RDF? |
| 09:17 | <jgraham> | That is, in all seriousness, actually mildly surprising :) |
| 09:17 | <darobin> | jgraham: there will be when I'm done with it! |
| 09:18 | <darobin> | I think we should rewrite the algorithms in RDF so they're machine readable |
| 09:18 | <jgraham> | darobin: Well if anything gets to /TR/ then there will be RDF output at least, right? |
| 09:18 | <darobin> | besides, if there's a document suite in which adding a few namespace declarations won't be noticeable it's this one |
| 09:18 | <darobin> | jgraham: oh yeah, there's a script that builds tr.rdf |
| 09:19 | darobin | not sure if anyone uses that |
| 09:19 | <darobin> | but we don't get to touch it, the webmaster does |
| 09:19 | <zcorpan> | we should use RDF for all xrefs. then we don't even need to generate the xref links, it'll all just work |
| 09:19 | <darobin> | in fact, I don't know if the webmaster touches it, it just gets generated |
| 09:19 | <darobin> | I'm also a bit appalled at how this spec doesn't even use XML Schema |
| 09:19 | <darobin> | I mean it's a vocabulary — what better solution is there? |
| 09:20 | <darobin> | that plus some WSDL to replace WebIDL and my work here is done |
| 09:20 | <darobin> | I'll be finished WAAAAY before 2014 |
| 09:20 | jgraham | can't even find a link to the rdf data |
| 09:21 | <annevk> | zcorpan: heh |
| 09:21 | <jgraham> | Which I thought was ironic, but then I realised that I should have a autonomous UA that can crawl the web of linked data to do that for me |
| 09:22 | jgraham | discovers that Google in in fact such a UA |
| 09:22 | <jgraham> | http://www.w3.org/2002/01/tr-automation/tr.rdf |
| 09:24 | <darobin> | jgraham: I wonder if anyone ever actually checks that |
| 09:27 | <annevk> | zcorpan: the heh was actually in response to the meme, but it works here too I see |
| 10:13 | <darobin> | I'm getting confused — where is the latest and greatest version of Anolis? |
| 10:14 | <darobin> | ah, found it |
| 10:14 | <darobin> | it would be good to update gsnedders's site with the latest pointer |
| 10:21 | <annevk> | fantasai: hey, you there? |
| 10:22 | <annevk> | fantasai: I have these two encodings that when used with a slightly different name affect bidi |
| 10:22 | <annevk> | fantasai: I am guessing that should be defined in writing-modes, since it does not just affect HTML |
| 10:23 | <annevk> | fantasai: it's iso-8859-6 versus iso-8859-6-i and iso-8859-8 versus iso-8859-8-i |
| 10:23 | <annevk> | fantasai: hmm, I'm guessing you're asleep |
| 10:29 | <annevk> | If anyone else knows where in Gecko or WebKit the above is handled, please let me know! |
| 10:33 | <annevk> | WebKit has stuff like getPropertyValue("-webkit-rtl-ordering") == "logical" |
| 10:40 | <annevk> | heh, -webkit-rtl-ordering yields no results on Google |
| 10:40 | <annevk> | beverloo`: ^^ might be something for that table of yours? |
| 10:44 | <annevk> | http://en.wikipedia.org/wiki/ISO-8859-8 seems like complete bullshit |
| 10:44 | <annevk> | great |
| 10:47 | <hsivonen> | annevk: http://mxr.mozilla.org/mozilla-central/ident?i=IBMBIDI_TEXTTYPE_VISUAL |
| 10:48 | <hsivonen> | annevk: http://mxr.mozilla.org/mozilla-central/source/layout/base/nsPresContext.cpp#174 |
| 10:49 | <annevk> | so it does not happen for iso-8859-6? |
| 10:49 | <annevk> | haven't tested that actually |
| 10:50 | <hsivonen> | annevk: I suggest testing |
| 10:50 | <annevk> | can't get the text to reverse using the same bytes as I used for -8 |
| 10:50 | <annevk> | so this is only for iso-8859-8 versus iso-8859-i |
| 10:52 | <annevk> | however, Gecko does not treat them as labels for each other |
| 10:52 | <hsivonen> | annevk: maybe visual Arabic didn’t get popular, because it would be rather silly to have Arabic shaping support without ordering support and the result would look very wrong without shaping support |
| 10:52 | <annevk> | iso-8859-6-i is distinct from iso-8859-6-i somehow |
| 10:52 | <annevk> | from iso-8859-6 doh |
| 10:54 | <hsivonen> | the problem with 386 in Wikipedia is that expertise disqualifies you from editing |
| 10:54 | <annevk> | oh that's okay, some non-expert can quote my spec later |
| 10:55 | <hsivonen> | annevk: iso-8859-6-i is for email only in Gecko |
| 10:55 | <hsivonen> | annevk: http://mxr.mozilla.org/mozilla-central/source/intl/uconv/src/charsetData.properties#31 |
| 10:56 | <annevk> | but it's exposed somehow; e.g. unsupported labels get normalized away, this one stays |
| 10:56 | <annevk> | try entering it in http://dump.testsuite.org/encoding/label-test.html to see what I mean |
| 10:57 | <hsivonen> | adobe-symbol-encoding.LangGroup = el // wow |
| 10:57 | <hsivonen> | annevk: ghosts of things that are banned in charsetData.properties leak to browser charset alias handling, IIRC |
| 10:59 | <annevk> | other browsers e.g. treat the -e stuff as label for the non -e/-i stuff |
| 10:59 | <annevk> | In Opera csiso88598e gives iso-8859-8 but in Gecko it's iso-8859-8-e |
| 11:00 | <hsivonen> | x-sun-unicode-india-0 |
| 11:00 | <hsivonen> | weird stuff |
| 11:00 | <annevk> | Gecko has a lot of things nobody else has I think |
| 11:00 | <hsivonen> | whatever IBM contributed |
| 11:04 | <annevk> | ah so in Safari iso-8859-6-i gives iso-8859-6 |
| 11:04 | <annevk> | okay so lets only make iso-8859-8 crazy |
| 11:09 | <zcorpan> | Hixie_: shouldn't https://www.w3.org/Bugs/Public/show_bug.cgi?id=15133 be RESOLVED FIXED? |
| 11:09 | <annevk> | thanks hsivonen! |
| 11:09 | <annevk> | hsivonen: seems you were not listed in the acknowledgments yet o_O |
| 11:16 | <AryehGregor> | zcorpan, oh, thanks for the pointer. That makes sense -- the namespace of an element can't change, any more than its tag can. |
| 11:22 | <AryehGregor> | hsivonen, expertise doesn't disqualify you from editing, it just doesn't per se give you more authority than anyone else. |
| 11:22 | <AryehGregor> | (which may also be a problem, but it's not the same thing) |
| 11:23 | <hsivonen> | AryehGregor: expertise tends to come with COI |
| 11:23 | <AryehGregor> | You're allowed to edit if you have COI, last I checked. |
| 11:23 | <hsivonen> | ok |
| 11:23 | <AryehGregor> | http://en.wikipedia.org/wiki/WP:COI |
| 11:23 | <AryehGregor> | "This page in a nutshell: Do not edit Wikipedia to promote your own interests, or those of other individuals or of organizations, including employers. Do not write about these things unless you are certain that a neutral editor would agree that your edits improve Wikipedia." |
| 11:25 | <hsivonen> | I wonder if I should add a COI statement about my Mozilla and standards activities to https://en.wikipedia.org/wiki/User:Hsivonen |
| 11:50 | <annevk> | Filed https://www.w3.org/Bugs/Public/show_bug.cgi?id=19505 on CSS saying something about this encoding |
| 11:53 | <annevk> | hsivonen: for you: http://cdn.memegenerator.net/instances/400x/28235174.jpg |
| 12:00 | <jgraham> | "Browser implementors are participating in responsive images." - yeah, and Sam somehow avoided the carnage that occurred when the people working on it went from "no browser feedback" to "browser feedback" |
| 12:01 | <odinho> | :-) |
| 12:16 | <zcorpan> | hober: i think lxml is used because html5lib it too slow |
| 12:35 | <odinho> | Think I did something like try: lxml.parse(bla) except: html5lib.parse() once. Fallback to html5lib when lxml fails. |
| 12:43 | <MikeSmith> | I have other problems with html5lib in my Debian environment when trying to get it parse the HTML spec without failing |
| 12:43 | <MikeSmith> | different various weird fatal errors that I've not been able to figure out |
| 12:44 | <MikeSmith> | and as far as the slowness, it's not just a little bit slower -- it's like 10 times slower |
| 12:44 | <jgraham> | Yeah, it is |
| 12:44 | <jgraham> | Python is not really made for this kind of task |
| 12:44 | <MikeSmith> | yup |
| 12:44 | <MikeSmith> | maybe we should use phantom.js instead |
| 12:45 | <jgraham> | That's another way of saying "any browser and webdriver", right? |
| 12:46 | <MikeSmith> | for anolis and splitting |
| 12:46 | <MikeSmith> | write it all in JS |
| 12:47 | <MikeSmith> | could do in node instead but phantom.js already has a performant HTML parser and DOM |
| 12:54 | <zcorpan> | annevk: y u no post ur meme to w3cmemes? |
| 12:55 | <MikeSmith> | jgraham: yeah could be any browser and webdriver I guess. I'm just used to using phantom.js |
| 12:57 | <MikeSmith> | I wonder if the HTML bugmail is more accessible than the plain text |
| 12:57 | <MikeSmith> | I would think it'd have to be |
| 12:57 | <annevk> | zcorpan: the one above? could do I guess |
| 12:58 | <annevk> | i'm lazy |
| 13:17 | <darobin> | MikeSmith: in phantom.js the weird thing is the communication between the browser context and the primary script context |
| 13:17 | <darobin> | I would be shocked if we tried to use that and didn't trigger problems :) |
| 13:19 | <darobin> | and using jsdom from Node is unlikely to be all that good; apart from having trouble parsing some correct HTML5 it takes ~10min on my MBP to run https://github.com/w3c/html/blob/heartbeat-201210/scripts/minimal-pubrules.js |
| 13:21 | <MikeSmith> | darobin: yeah that's in line with what I found last time I tried to use jsdom |
| 13:22 | <darobin> | it may be that I could make it faster by not using jquery atop jsdom :) |
| 13:23 | <darobin> | jsdom also has this cool bug where it parses <a href=http://berjon.com/>robin</a>; as <a href=http://berjon.com></a>robin |
| 13:23 | <darobin> | (note the trailing slash in the attribute value) |
| 13:23 | <odinho> | Ah, helpful xmlism :P |
| 13:24 | <Ms2ger> | Does it support <foo/bar/ for <foo>bar</foo>? |
| 13:24 | <darobin> | I can tell you that it took me a while to figure out why the fuck some links broke and not others... |
| 13:24 | <SimonSapin> | Ms2ger: is that xml or sgml? |
| 13:24 | <Ms2ger> | SGML |
| 13:24 | <darobin> | Ms2ger: I doubt its SGML support is that good |
| 13:24 | <Ms2ger> | Aww |
| 13:25 | <darobin> | I don't think it does </> either :) |
| 13:25 | <odinho> | Ms2ger: Do anyone support that? |
| 13:25 | <darobin> | it's supposed to be HTML5 happy :) |
| 13:25 | <Ms2ger> | odinho, SGML parsers presumably do |
| 13:25 | <Ms2ger> | But then again, I've never seen one of those |
| 13:25 | <darobin> | odinho: SP does |
| 13:25 | <darobin> | there was only ever one |
| 13:25 | <MikeSmith> | that HTML parser is node is a one-person project I think |
| 13:26 | <darobin> | yeah it looks like it |
| 13:26 | <darobin> | it also has a weird interface |
| 13:26 | <MikeSmith> | SP does? |
| 13:26 | <darobin> | jsdom |
| 13:26 | <darobin> | (but SP too) |
| 13:26 | <MikeSmith> | heh |
| 13:26 | <darobin> | but on the plus side it runs scripts, which means you can get results for document.write() |
| 13:26 | <darobin> | not sure if they're correct though |
| 13:26 | <Ms2ger> | Plus side? |
| 13:27 | <MikeSmith> | hah |
| 13:27 | <darobin> | (and of course they fail for anything that isn't document.write or basic JS) |
| 13:27 | <darobin> | Ms2ger: it scared the shit out of me once when I was using it to spider content and I saw "Error: alert is not a function" in my log |
| 13:28 | <darobin> | thankfully it runs them in a sandbox |
| 13:29 | <MikeSmith> | friends the bugzilla guru from the systems team points out that there is a user pref for bugmail format |
| 13:29 | <MikeSmith> | https://www.w3.org/Bugs/Public/userprefs.cgi |
| 13:29 | <MikeSmith> | last option on that page |
| 13:29 | <Ms2ger> | People didn't know that? :) |
| 13:29 | <zcorpan> | why does MDN reference TR/ specs? |
| 13:29 | <MikeSmith> | Ms2ger: I didn't know that |
| 13:29 | <Ms2ger> | zcorpan, silly people |
| 13:30 | <Ms2ger> | MikeSmith, it's a Mozilla products, there are prefs for everything |
| 13:30 | <Ms2ger> | *product |
| 13:30 | <MikeSmith> | Ms2ger: it should be on the "Email preferences" page |
| 13:30 | <zcorpan> | Ms2ger: is there a bug about changing it? |
| 13:30 | <darobin> | MikeSmith: did you read the part about it being a Mozilla product? |
| 13:30 | <MikeSmith> | heh |
| 13:30 | <Ms2ger> | zcorpan, not that I know of |
| 13:31 | <odinho> | bugs.example.com/about:config |
| 13:31 | <darobin> | the only preferences that are categorised with any logic are in about:config |
| 13:37 | <zcorpan> | Ms2ger: https://bugzilla.mozilla.org/show_bug.cgi?id=800902 |
| 13:41 | <annevk> | MikeSmith: it should be set to Text I think for the mailing lists |
| 13:41 | <annevk> | and yeah, why it's not under email preferences... |
| 13:45 | <darobin> | MikeSmith, buddy, next time you see me using a nice, long, descriptive branch name like "heartbeat-201210" can you please shoot me? |
| 13:46 | <annevk> | W3C and their idea of putting dates in things |
| 13:47 | <annevk> | party like it's '99 with XHTML |
| 13:47 | <Ms2ger> | Dates make sense to me for dated snapshots |
| 13:47 | <Ms2ger> | Now, dated snapshots are silly, of course |
| 13:48 | <annevk> | but but but patents! |
| 13:51 | <darobin> | bah, you're just jealous because I get more dates than you do |
| 13:52 | <jgraham> | Mmm, dates |
| 13:52 | <gsnedders> | darobin: Yes, updating it with some link would be useful. :) |
| 13:52 | <jgraham> | Must be nearly Christmas |
| 13:52 | <gsnedders> | Ms2ger's bitbucket the recommended link nowadays? |
| 13:53 | <darobin> | gsnedders: yeah that would be sweet, as it's still what comes first in Google by far |
| 13:53 | <annevk> | jgraham: 19 days |
| 13:53 | <jgraham> | Haha |
| 13:53 | <darobin> | I reckon it's Ms2ger's — jgraham's hasn't changed since 2010 |
| 13:54 | <jgraham> | Not mine for sure |
| 13:54 | <darobin> | it's back from when jgraham used hg |
| 13:55 | <gsnedders> | Same with me. :) |
| 13:55 | <zewt> | heh i thought the bugmail to the lists was hard to read, being monospaced ... then i went to work and read one there, where i don't have my minimum-forced-font-size set up, and found it's actually 0.001pt monospace and an order of magnitude worse than I imagined |
| 13:58 | <gsnedders> | darobin: Better now? :) |
| 13:58 | <darobin> | gsnedders: you're a sweetie |
| 13:59 | gsnedders | bats eyelids |
| 13:59 | jgraham | needs therapy now |
| 14:00 | <gsnedders> | jgraham: Look, I know I don't update webpages, but… |
| 14:01 | <zewt> | ow my eyelids |
| 14:31 | <zcorpan> | MikeSmith: i'm told you're the go-to for getting new tests synced up on w3c-test.org. i has tests here: http://dvcs.w3.org/hg/quirks-mode/file/3397c5f9ad8d/tests |
| 14:31 | <Stevef__> | feedback on this <maincontent> appreciated https://dvcs.w3.org/hg/html-extensions/raw-file/3acee7f50663/maincontent/index.html |
| 14:33 | <zcorpan> | Stevef__: i don't understand the Contexts in which this element can be used |
| 14:34 | <zcorpan> | "child of 0 or more div elements" in particular |
| 14:34 | <zcorpan> | how can an element be a child of 0 div elements? or more than 1 div elements? |
| 14:35 | <Stevef__> | zcorpan: what I am attempting to do limit its use so it is not allowed inside nav/header/article etc |
| 14:36 | <Stevef__> | zcorpan: will try to make it clearer |
| 14:37 | <zcorpan> | Stevef__: it seems better in that case to ban the elements you don't want as ancestors |
| 14:37 | <zcorpan> | Stevef__: e.g. i don't see why <form> should be banned |
| 14:37 | <Stevef__> | zcorpan: thanks will rework it |
| 14:37 | <Stevef__> | zcorpan: yes you are right |
| 14:43 | <Stevef__> | zcorpan: "Flow content, but with no article, aside, footer, header or nav element ancestors." any better? |
| 14:47 | <zcorpan> | Stevef__: shouldn't it be under Contexts in which this element can be used? |
| 14:48 | <Stevef__> | zcorpan: am putting it there |
| 14:48 | <Stevef__> | zcorpan: based wording on http://dev.w3.org/html5/spec/the-footer-element.html#the-footer-element |
| 14:49 | <zcorpan> | Stevef__: that says "Where flow content is expected." |
| 14:49 | <Stevef__> | zcorpan: oh right yes, ok back to drawing board |
| 14:50 | <zcorpan> | so "Where flow content is expected, but with no article, ... ancestors" |
| 14:51 | <Stevef__> | zcorpan: right thanks again |
| 14:51 | <zcorpan> | and separately a requirement saying "There must not be more than one maincontent element in the document" or so |
| 14:54 | <zcorpan> | Stevef__: shouldn't the keyboard nav thing be part of the aria spec for "main" instead? |
| 14:56 | <zcorpan> | (also i guess <maincontent></maincontent><div role=main></div> should also be disallowed? what does aria say?) |
| 14:56 | <Stevef__> | zcorpan: have to think on those |
| 14:57 | <Stevef__> | zcorpan: aria says "Within any document or application, the author SHOULD mark no more than one element with the main role" |
| 14:58 | <zcorpan> | are there any good reasons for violating the should? |
| 14:58 | <Stevef__> | zcorpan: not that I know of |
| 15:00 | <Stevef__> | zcorpan: re the keybaord nav ARIA does not define browser UI requirements |
| 15:00 | <zcorpan> | Stevef__: html usually doesn't, either |
| 15:01 | <Stevef__> | zcorpan: right, thats why its a should, may be better to rephrase it |
| 15:02 | <Stevef__> | zcorpan: encouraged to... |
| 15:07 | <annevk> | TabAtkins: paul_irish: anyone: http://html5.org/temp/urlquery.txt |
| 15:08 | <annevk> | is that the interface we're thinking about for the query parameter? |
| 15:08 | <annevk> | zewt: ^^ |
| 15:08 | <annevk> | not sure my use of sequence is correct btw, always mess that up :/ |
| 15:09 | <zcorpan> | always returns an array on getting? |
| 15:09 | <annevk> | (looks like it's correct) |
| 15:09 | <annevk> | yes |
| 15:15 | <annevk> | zcorpan: type testing seems more annoying than using [0] |
| 15:15 | <zcorpan> | annevk: ok |
| 15:21 | <annevk> | arv and abarth|gardening: your feedback would be welcome too |
| 15:22 | <freddyb> | the current html5 draft says, that iframe sandbox disallows all plugins (and scripts, forms, popups, topnavigation, same-origin access) |
| 15:22 | <freddyb> | but there is no "allow-plugins" keyword defined to remove this restriction, like there is for the other ones |
| 15:22 | <freddyb> | why is that so? |
| 15:23 | <arv> | annevk: I don't like that at all |
| 15:23 | <arv> | annevk: We are trying hard to not add more things that cannot be expressed in JavaScript to the DOM |
| 15:24 | <freddyb> | and the second example (the one with src="http://maps.example.com/embedded.html";) explicitly says that allow-scripts does *not* remove the plugins restriction |
| 15:24 | <annevk> | arv: I thought these kind of interfaces can be expressed with proxies? |
| 15:24 | <arv> | annevk: This is another local storage mess where we are not keeping the interface and the data separate |
| 15:24 | <freddyb> | oh, and I guess it would have been polite to say hi, sorry.... hi folks :) |
| 15:24 | <arv> | annevk: Anything can be done with proxies... that is no excuse |
| 15:25 | <annevk> | arv: why not? they're JavaScript... this is way nicer than a bunch of methods |
| 15:25 | <annevk> | freddyb: because plugins don't implement sandboxing |
| 15:25 | <arv> | annevk: How do you get the number of parameters? |
| 15:25 | <arv> | annevk: And what happens when someone has a query parameter called "length"? |
| 15:26 | <freddyb> | annevk: so they'll never listen to the other restrictions in place, and therefore can't be whitelisted on their own? |
| 15:27 | <arv> | annevk: JS is really crippled in this space... no clean separations between data and interface |
| 15:27 | <Ms2ger> | freddyb, exactly |
| 15:28 | <freddyb> | so, when it says providing the "allow-scripts" and "allow-same-origin" keywords will actually remove all sandbox features, it still doesn't mean that plugins work -- just that using top.location = location.href might escape the sandbox and use plugins *then*? |
| 15:28 | <annevk> | arv: hmm mkay, refresh? |
| 15:30 | <arv> | annevk: better imo... needs has, remove too |
| 15:31 | <annevk> | and length? :-) |
| 15:32 | <arv> | annevk: One of the problem with this API compared to the old one is that get always returns a sequence. The common case is that you only have one param of a given name and having to always create a list and then extract the data from the list asks for a better api |
| 15:33 | <Stevef__> | zcorpan: updated https://dvcs.w3.org/hg/html-extensions/raw-file/a853b1a55aab/maincontent/index.html thanks again for your feedback. |
| 15:33 | <annevk> | arv: could do get / getAll similar to querySelector / querySelectorAll |
| 15:34 | <arv> | annevk: I don't know if length is the right term. Conceptually you want a way to iterate over the items. If you have length then it is expected to have indexed properties |
| 15:34 | <arv> | annevk: I like it |
| 15:35 | <annevk> | iteration is usually an item() method |
| 15:35 | <annevk> | btw, updated the proposal again |
| 15:35 | <annevk> | thanks for the feedback |
| 15:36 | <annevk> | e.g. like http://dom.spec.whatwg.org/#nodelist |
| 15:36 | <Stevef__> | MIkeSmith: hi mike how do i get an url for this https://dvcs.w3.org/hg/html-extensions/raw-file/3acee7f50663/maincontent/index.html that is always the latest version? |
| 15:36 | <annevk> | has item() / length |
| 15:37 | <annevk> | Stevef__: https://dvcs.w3.org/hg/html-extensions/raw-file/tip/maincontent/index.html |
| 15:38 | <Stevef__> | annevk: thanks |
| 15:39 | <freddyb> | thanks, guys :) |
| 15:40 | <arv> | annevk: One nit. Can we call it delete to match http://wiki.ecmascript.org/doku.php?id=harmony:simple_maps_and_sets |
| 15:40 | <annevk> | yeah |
| 15:41 | <zcorpan> | annevk: NodeList also has getter |
| 15:42 | <annevk> | but only numeric |
| 15:42 | <zcorpan> | true |
| 15:44 | <odinho> | Soo... I have "rebase" for hg. Now someone has pushed something so the origin is different from me. How do I make my 3 local commits rebased on top of origin in hg? |
| 15:45 | <arv> | I think conceptually we would want an iterator that returns [name, value] (just like Map.prototype.items) but that can be added when engines get there (Gecko is already there... they have iterators for NodeLists and other things) |
| 15:45 | <annevk> | arv: okay, so I'll leave it as it is now I suppose |
| 15:45 | <annevk> | this is already a huge improvement over .search anyway |
| 15:46 | <annevk> | and over the longish method name proposal from the older draft, imo |
| 15:47 | <odinho> | Ah-hah, was easy this time. Getting better at this. Nothing to see here. -- |
| 15:47 | <annevk> | arv: btw, do we really want has()? it's the same as get(name) != null |
| 15:47 | <arv> | annevk: good point |
| 15:47 | <arv> | annevk: leave it out for now in the name of simplicity |
| 15:47 | <annevk> | yup |
| 15:48 | <annevk> | thanks for this short session |
| 15:49 | <arv> | annevk: I guess it was good I never managed to finish the webkit implementation of the old draft |
| 15:49 | <annevk> | hopefully this one will end up in impls some day :-) |
| 15:49 | <annevk> | still need to write the text, not sure when I'll get around to that |
| 15:50 | <annevk> | not tonight |
| 15:50 | <annevk> | i'll put the IDL in the spec so people can look at it there at least |
| 15:59 | <annevk> | hmm, arv, everyone on the WHATWG list, including TabAtkins, did go the proxy route |
| 15:59 | <annevk> | oh well |
| 16:00 | <annevk> | I'll check this in and seek some more feedback |
| 16:12 | <Hixie_> | freddyb: there's no allow-plugins yet because plugins don't support being told to be sandboxed yet |
| 16:13 | <Hixie_> | freddyb: oh i see anne already replied, don't mind me |
| 16:15 | <Ms2ger> | Hixie_, we never do, don't worry :) |
| 16:34 | <TabAtkins> | annevk: What's "the proxy route"? |
| 16:46 | <annevk> | TabAtkins: to implement getter/setter/deleter/creator you need JavaScript proxies |
| 16:46 | <annevk> | TabAtkins: arv didn't like it and I seem to recall Brendan Eich also not liking ele.dataset / localStroage |
| 16:47 | <TabAtkins> | Oh, ok. Things like that are so useful, though! |
| 16:47 | <annevk> | TabAtkins: I'm kinda ambivalent myself |
| 16:48 | <arv> | TabAtkins: TC39 are opposed to adding more things that require proxies |
| 16:48 | <arv> | TabAtkins: The long term plan is to extend the language to allow separating [] from general property lookup |
| 16:50 | <annevk> | arv: I have to agree it's kinda sucky though, especially when there are no conflicts |
| 16:50 | <annevk> | arv: .query["x"] = "yada" is way more beautiful |
| 16:51 | <arv> | annevk: I'm completely with you on that |
| 16:52 | <annevk> | TabAtkins: I guess the one you can't have with proxies is the get/getAll design, you'd just have a getter that always returns an array |
| 16:52 | <arv> | and you can't have any methods on the object either |
| 16:53 | <arv> | that is why localstorage fails so badly |
| 16:53 | <annevk> | arv: looking at that map design you pointed to earlier, that does seem kinda fitting here |
| 16:53 | <annevk> | but I'm not gonna say I can predict the future (although we could put new methods on URLUtils instead) |
| 16:56 | <annevk> | the hard part here for me is going to be the algorithms; hopefully the mailing list bikesheds the API into shape :-) |
| 16:57 | <TabAtkins> | annevk: If you do go with methods rather than proxies, using has() is good just because it parallels the proper Map API. Gratuitous differences are bad - people would be constantly tripped up by the lack, I think. |
| 17:15 | gsnedders | wonders what __proto__ does on localStorage in old JSC/Carakan. |
| 17:26 | <annevk> | TabAtkins: dunno, I almost never saw hasAttribute() used myself |
| 17:26 | <annevk> | mostly people just do getAttribute(x) != null |
| 17:51 | <TabAtkins> | annevk: Interesting. When I'm using maps in other languages, I use has() for existing testing. Short and clearer. |
| 18:16 | <jgraham> | TabAtkins: Other languages tend not to return null when you try to get a missing value though |
| 18:16 | <jgraham> | Although I would use has even if they did |
| 18:17 | <jgraham> | Well maybe some do, I guess |
| 18:17 | <TabAtkins> | jgraham: Yeah, it varies. |
| 18:18 | <jgraham> | Wow, go returns the zero value for the map type |
| 18:19 | <TabAtkins> | What's the "zero value" in this context? |
| 18:19 | <jgraham> | Oh, but there is also an error parameter |
| 18:19 | <jgraham> | or return value I guess |
| 18:19 | <jgraham> | If you have a map of string->int, say it's 0 |
| 18:19 | <jgraham> | I imagine for string->string it's "" |
| 18:20 | <TabAtkins> | Okay, so default value. |
| 18:20 | <TabAtkins> | I was wondering if go maps are monoidal by default or something. |
| 18:24 | <jgraham> | rust seems to require you to check upfront |
| 18:26 | GPHemsley | pokes the WONTFIX bear. |
| 18:26 | <jgraham> | odinho: You do hg pull --rebase and then hg deletes all your data |
| 18:26 | <jgraham> | (or something) |
| 18:52 | <annevk> | TabAtkins: yeah I guess if you can do "x" in y that would be nice |
| 18:52 | <annevk> | TabAtkins: I kinda thing we should make this a proper map |
| 18:52 | <annevk> | TabAtkins: but I'll see what people come up with on the mailing list |
| 19:05 | <na8ur> | hi; there's no free posting anymore? I hadn't been here for ages, but abstract .. and cupid aka chris h. are guys who build me up? . how to get some voice. but besides I don't have questions at the moment.. just wondering |
| 19:17 | <TabAtkins> | That's an interesting markov generator example. |
| 19:22 | <na8ur> | my studies in physics are more than 20years .. over.. :) wuuhh.. also ages ago |
| 19:23 | <TabAtkins> | Yup, definitely a Markov bot. |
| 19:24 | GPHemsley | wonders about the influx from irccloud.com |
| 19:24 | <na8ur> | :) hehe |
| 19:24 | GPHemsley | then notices the few that are connected via IPv6 and is impressed. |
| 19:25 | <GPHemsley> | Hixie_: I'd like to request a wiki account, when you get a chance. |
| 19:25 | <na8ur> | getting closer: http://eflorenzano.com/blog/2008/11/16/writing-markov-chain-irc-bot-twisted-and-python/ thx.. but I never did bots .. just my girl :) |
| 19:48 | <annevk> | GPHemsley: I can get you one, pm username/email |
| 19:49 | <GPHemsley> | annevk: Oh, I didn't see you here, for some reason. |
| 19:50 | annevk | goes back into hiding |
| 19:51 | <GPHemsley> | :P |
| 21:48 | <gsnedders> | Has anyone experimented with replacing the locale-dependent character encoding guess with something based on public suffixes? |
| 22:02 | <zewt> | "public suffixes"? |
| 22:03 | <gsnedders> | As in the public suffix list. |
| 22:03 | <zewt> | sorry, but suffixes of what? |
| 22:03 | <gsnedders> | http://publicsuffix.org/ |
| 22:03 | <gsnedders> | 'A "public suffix" is one under which Internet users can directly register names. Some examples of public suffixes are .com, .co.uk and pvt.k12.wy.us. ' |
| 22:04 | <zewt> | ... you mean TLD? heh |
| 22:04 | <gsnedders> | It's not always the YLD. |
| 22:04 | <gsnedders> | *TLD |
| 22:04 | <gsnedders> | co.uk isn't a TLD, for example |
| 22:04 | <zewt> | i doubt co.uk and or.uk or whatever it is will have different language tendencies :) |
| 22:05 | <gsnedders> | No, but I can imagine that's not true everywhere. |
| 22:05 | <zewt> | while it'd be awesome if some non-system-dependent heuristic could replace the locale setting, i have a hard time seeing browsers ever doing it, since it's guaranteed to break lots of pages that work for their actual audience today :( |
| 22:06 | <gsnedders> | You basically need to add some telemetry in to get what encodings are being used for what pubsuffixes, when it's fallen through to locale-checking. I expect quite a few will be quite clear-cut. |
| 22:07 | <zewt> | the trouble is that any change to this is likely to change eg. "+++++++---" (where + is a correct guess and - is wrong) to "+++++-+++-" |
| 22:08 | <gsnedders> | Indeed. :( |
| 22:08 | <jwalden> | gsnedders: what would be guessed for .ch? |
| 22:08 | <zewt> | and those wrong guesses that you just fixed were ones nobody cared about (or else they'd have been fixed by the author) |
| 22:08 | <zewt> | so you end up fixing things nobody (-ish) cares about, and breaking ones people do |
| 22:08 | <gsnedders> | jwalden: That's the hard case I was thinking about |
| 22:09 | <jwalden> | heh |
| 22:09 | <zewt> | (having many times loaded japanese pages in browsers and had mojibake vomited upon me, i can claim myself of one of that -ish) |
| 22:10 | <gsnedders> | jwalden: Though .tw and .ch are separate, and zh-CH has GB18030, but dunno how much content overlaps between the two. |
| 22:10 | <gsnedders> | 台湾 and 台灣 should help in telling the two apart, I'd hope, though. :) |
| 22:11 | <zewt> | i think encoding heuristics could do a decent job (with TLD as one input to that heuristic), but it'll still run into the same basic problem |
| 22:11 | <jwalden> | gsnedders: erm, am I misremembering .ch as Switzerland (equal parts German, French, Italian as I remember)? sounds like you're thinking of .zh |
| 22:11 | <gsnedders> | Bleh! I meant .zh! |
| 22:11 | <zewt> | (where other inputs would be "number of bytes that failed to decode" and language pattern heuristics; I think some browsers do do some of that, not sure when or which) |
| 22:11 | <gsnedders> | jwalden: German/French equal, Italian smaller, and even less Romansh. |
| 22:12 | <jwalden> | okay, my memory's not quite right, but close enough for purposes of this discussion :-) |
| 22:13 | <gsnedders> | (Only one canton where any notable amount of Romansh is spoken) |
| 22:13 | <zewt> | i still think browsers should just force any page without a charset declaration to comic sans |
| 22:13 | <gsnedders> | jwalden: Basically all the locales on the spec suggested list corrospond nicely to countries, though, at least. |
| 22:15 | <zewt> | is .ca a mix of en+fr? |
| 22:17 | <gsnedders> | Neither en/fr have anything but the standard Windows-1252. |
| 22:18 | <zewt> | "standard" heh |
| 22:18 | <zewt> | i sort of wish we'd give up pretending that anyone uses real iso-8859-1 and just fold the windows cp characters into it for real |
| 22:19 | <zewt> | i wish we could get a bit of browser collusion on this problem |
| 22:19 | <zewt> | get every browser to make a breaking change simultaneously :P |
