| 04:21 | <rniwa> | Hixie: yt? |
| 04:38 | <Hixie> | yo |
| 04:43 | <MikeSmith> | rniwa: 上 |
| 04:43 | <rniwa> | MikeSmith: thanks |
| 04:43 | <rniwa> | Hixie: hi |
| 04:43 | <rniwa> | Hixie: so i was reading your spec change |
| 04:43 | <rniwa> | Hixie: for form element |
| 04:44 | <rniwa> | Hixie: http://www.whatwg.org/specs/web-apps/current-work/#has-an-element-in-scope |
| 04:44 | <rniwa> | Hixie: doesn't seem to list the form element |
| 04:44 | <Hixie> | right? |
| 04:44 | <Hixie> | why would it? |
| 04:45 | <rniwa> | Hixie: your change in http://html5.org/tools/web-apps-tracker?from=8330&to=8331 |
| 04:45 | <rniwa> | Hixie: refers to "If the stack of open elements does not have a form element in scope, then this is a parse error; abort these steps and ignore the token." |
| 04:45 | <Hixie> | right? |
| 04:45 | <Hixie> | i'm confused |
| 04:45 | <rniwa> | Hixie: what does "have a form element in scope" in this context mean? |
| 04:46 | <rniwa> | Hixie: does it mean that the local name "form" is in the scope? |
| 04:46 | <Hixie> | there's an algorithm |
| 04:47 | <Hixie> | i don't understand what's confusing here |
| 04:47 | <Hixie> | is there a specific step that's confusing? |
| 04:47 | <Hixie> | or? |
| 04:47 | <rniwa> | Hixie: my question is just about whether we should be checking the namespace of form element or not |
| 04:47 | <rniwa> | Hixie: when we're checking whether form element is in the scope or not |
| 04:48 | <rniwa> | Hixie: because the code we have in webkit currently doesn't check the namespace |
| 04:48 | <Hixie> | you check if it's an HTML <form> element, yes, like for all the other "have a ... element in scope" cases that reference specific elements from specific namespaces |
| 04:49 | <rniwa> | Hixie: oh nvm |
| 04:49 | <rniwa> | Hixie: I misread the code :( |
| 04:49 | <Hixie> | phew |
| 04:49 | <rniwa> | Hixie: the stack thing only contains html element |
| 04:49 | <rniwa> | Hixie: sorry about the confusion |
| 04:58 | rniwa | is making the parser change in webkit |
| 04:58 | <Hixie> | nice |
| 06:28 | <marcosc> | Hixie: yesterday you said that you didn't understand what problem I was trying to solve. Can you explain let me know what part of the proposal you don't understand? Maybe I can explain it better. |
| 06:29 | <marcosc> | or is it more about why are people not using what HTML already provides to achieve the use case? |
| 09:48 | <Ms2ger> | rniwa: yeah, the "have a form element in scope" bits are really confusing |
| 09:48 | <Ms2ger> | I tried to convince Hixie to make it clearer, but he didn't want to |
| 10:20 | <marcosc> | you know it's serious if Ms2ger cc's himself on it |
| 10:20 | <marcosc> | :) |
| 10:20 | <Ms2ger> | Yay, exceptions |
| 10:21 | <Ms2ger> | I'd make heycam|away take over speccing them, but you probably want it fixed this century :) |
| 10:21 | <zcorpan> | should we just ignore isindex in templates? |
| 10:21 | marcosc | imagines Ms2ger's thought process "Yeah... this aught to be amusing enough... I'll cc myself" |
| 10:22 | <marcosc> | Ms2ger: given that Im in Australia... I could just hop down to Melb and bug him to fix stuff |
| 10:22 | <Ms2ger> | Do it :) |
| 11:02 | <Ms2ger> | jgraham, so even though I broke critic with https://critic.hoppipolla.co.uk/r/449, want to merge? :) |
| 11:17 | <jgraham> | Ms2ger: I don't like the extra newline in object literals :p |
| 11:17 | <jgraham> | foo = {a:b |
| 11:17 | <jgraham> | } |
| 11:17 | <jgraham> | Rather than |
| 11:17 | <jgraham> | foo = {a:b} |
| 11:17 | <jgraham> | (or at least multiline object literals) |
| 11:19 | <Ms2ger> | You mean |
| 11:19 | <Ms2ger> | { |
| 11:19 | <Ms2ger> | a:b |
| 11:19 | <Ms2ger> | } |
| 11:19 | <Ms2ger> | Instead of |
| 11:19 | <Ms2ger> | {a:b, |
| 11:19 | <Ms2ger> | c:d}? |
| 11:20 | <jgraham> | Something like that |
| 11:20 | <Ms2ger> | I think the first is more readable |
| 11:21 | <jgraham> | Well |
| 11:21 | <jgraham> | I'm not going to fight about it |
| 11:21 | <jgraham> | But you are wrong ;) |
| 11:22 | <jgraham> | I mean I think it's more readable in the way that extra whitespace normally is: it is locally more readable, but reduces the code density which can hurt global readability, and makes formatting more of a pain |
| 11:22 | <Ms2ger> | :D |
| 11:23 | <jgraham> | Would be nice if gh didn't make this impossible to review :( |
| 11:23 | <Ms2ger> | Given the number of lines I'm removing, I think the few lines I'm adding there are fine :) |
| 11:23 | <jgraham> | I guess I just have to trust you |
| 11:24 | <Ms2ger> | I think it should be fine |
| 11:24 | <Ms2ger> | But I'd think that :) |
| 11:24 | <Ms2ger> | Anyway, heading off |
| 11:25 | <jgraham> | Merged |
| 11:25 | <jgraham> | thanks |
| 11:28 | <Ms2ger> | Thank you |
| 12:39 | <hsivonen> | annevk-cloud: wow. so one character difference prevents ISO-8859-8-I from being a label of windows-1255? sad. |
| 12:42 | <gsnedders> | hsivonen: So I'm going to try and do something when it comes to dealing with unlabelled content over xmas/New Year. No promise I'll get very far. Also limit as to how much I'm willing to spend on cluster time. :) |
| 12:47 | <hsivonen> | gsnedders: cool |
| 12:48 | <gsnedders> | hsivonen: Any opinions on ways to try and detect? TLD-level defaults and byte bi-grams of the first 1024 bytes? |
| 12:51 | <hsivonen> | gsnedders: I was thinking of producing reasonable-sized lists of URLs for unlabeled pages and eyeballing the pages to be sure |
| 12:51 | <hsivonen> | gsnedders: otherwise, you have to develop *reliable* bigram data first |
| 12:52 | <gsnedders> | hsivonen: So I think that's probably doable. |
| 12:52 | <hsivonen> | the delta between Windows-1253 and ISO-8859-7 is frustratingly small, too |
| 12:52 | <hsivonen> | and explains how Firefox and Chrome get away with falling back to ISO-8859-7 when IE falls back to windows-1253 |
| 13:03 | <gsnedders> | hsivonen: So we can afford to do more expensive identification to generate correct labelling for unlabelled content, and then attempt to construct an algorithm that can get that within only 1024 bytes of data (because that's what <meta pre-parse uses). |
| 13:04 | <hsivonen> | gsnedders: I'd look at the whole page whether by code or by eyes |
| 13:05 | <gsnedders> | hsivonen: Indeed, that's the plan. But ideally we'd want whatever we standardise to be able to do it from 1024 bytes. |
| 13:06 | <hsivonen> | gsnedders: oh you want to standardize bigram guessing? I thought you wanted to do research for TLD-based guessing. |
| 13:06 | <gsnedders> | hsivonen: Ideally, yes. |
| 13:07 | <gsnedders> | hsivonen: Because it avoids TLD-dependence, which doesn't like. Also worthwhile investigating TLD-based guessing, too. |
| 13:07 | <gsnedders> | hsivonen: And possibly a combination of the two. |
| 13:08 | <hsivonen> | research and data don't hurt, but I'm negatively predisposed towards the idea of guessing between multiple single-byte encodings |
| 13:09 | <hsivonen> | since it's not exact like validating the byte sequences of multi-byte encodings |
| 13:09 | <gsnedders> | hsivonen: I don't think we can avoid it, tbh. |
| 13:09 | <gsnedders> | hsivonen: I think there's too much content under .com and the like to avoid having to. |
| 13:10 | <hsivonen> | gsnedders: oh you want to make .com not subject to localization-based guessing |
| 13:11 | <gsnedders> | hsivonen: Yeah. |
| 13:11 | <gsnedders> | hsivonen: I want to totally get rid of locale-based guessing. |
| 13:11 | <hsivonen> | gsnedders: I'm pretty worried about introducing even a small number of misguesses to .com sites that require windows-1252 and that now work fine in windows-1252-affiliated localizations |
| 13:12 | <gsnedders> | hsivonen: We could potentially add some code to do the guessing to Gecko, but not use it, and just send telemetry on whether it agrees. |
| 13:13 | <gsnedders> | hsivonen: I think we may well have to have per-TLD bigram feature vectors, but I dunno. Need data. |
| 13:13 | <hsivonen> | gsnedders: potentially, but we can't collect URLs that way due to privacy. So there'd be no way of understanding *what* broke. |
| 13:14 | <gsnedders> | hsivonen: Indeed, but it would at least allow us to get some data on accuracy (esp. relative to times when people then manually override the encoding, whether it returns the same as that). |
| 13:18 | <gsnedders> | hsivonen: Besides, we should have some sort of data of detected-identically-to-expensive-detection v. detected-incorrectly once we have some hard data. |
| 13:45 | Ms2ger | is rather confused by Bj�rn |
| 13:48 | jgraham | is rather confused |
| 13:49 | <Ms2ger> | In general? |
| 13:49 | <jgraham> | Yes |
| 13:49 | <Ms2ger> | Or by the relative sanity of people who use hg? |
| 13:50 | <jgraham> | Björn is merely behaving consistently with the theory that he is not an individual, but a shady cult-like entity |
| 13:50 | <jgraham> | Pretty sure that hg never caused sanity |
| 13:51 | <jgraham> | See also: hatters |
| 13:51 | <Ms2ger> | That's a reference I missed |
| 13:53 | <jgraham> | http://en.wikipedia.org/wiki/Mad_as_a_hatter |
| 13:56 | <Ms2ger> | I see |
| 14:25 | <hsivonen> | annevk-cloud: is there a Blink bug analogous to https://bugs.webkit.org/show_bug.cgi?id=125225 ? |
| 15:55 | <Hixie> | marcosc: i couldn't find mention of a use case. i'm not saying it's bad, i just don't know what the use case is. maybe i missed it? |
| 15:55 | <Hixie> | Ms2ger: it's not that i didn't want to make it clearer, it's that i don't understand what's unclear |
| 15:56 | <Ms2ger> | Right |
| 16:45 | <Hixie> | ms (i would love nothing more than to make it clearer...) |
| 16:45 | <Hixie> | er, s/ms/ms2ger:/ |
| 18:26 | <SimonSapin> | http://www.whatwg.org/specs/web-apps/current-work/multipage/commands.html#anchor-points what is the alignment point? |
| 18:58 | <Hixie> | SimonSapin: you mean where is it defined? |
| 18:58 | <Hixie> | SimonSapin: or what? |
| 19:05 | <SimonSapin> | Hixie: this property defines the alignment point for an element, but I don’t know what kind of alignment this is about |
| 19:06 | <Hixie> | it's for <dialog>, read the previous section :-) |
| 19:06 | <Hixie> | (that's why it's a subsection of <dialog>) |
| 19:06 | <SimonSapin> | Ok. (I got a deep link to that and was missing some context.) |
| 19:10 | <SimonSapin> | Hixie: perhaps s/alignment point/anchor point/g in the last two paragraphs? |
| 19:19 | <rniwa> | aklein: yt? |
| 19:27 | <Hixie> | SimonSapin: possibly. can you file a bug? http://whatwg.org/newbug -- i'm on my way out the door or i'd do it myself. thanks! |
| 19:28 | <SimonSapin> | Hixie: will do |
| 20:02 | <aklein> | rniwa: now I am |
| 20:02 | <rniwa> | aklein: hi |
| 20:02 | <rniwa> | aklein: are you happy with https://code.google.com/p/chromium/issues/detail?id=326058? |
| 20:02 | <rniwa> | aklein: or http://html5.org/tools/web-apps-tracker?from=8330&to=8331 |
| 20:02 | <rniwa> | sicking: hi sicking! |
| 20:04 | <aklein> | rniwa: Hixie's response in email seemed reasonable to me, I haven't had a chance to look at the spec edit yet... |
| 20:04 | <rniwa> | aklein: okay. |
| 20:04 | <rniwa> | aklein: basically, it made form element pointer moot inside template elements |
| 20:04 | <rniwa> | aklein: so that we now allow nested form elements inside template |
| 20:05 | <rniwa> | aklein: form controls are still associated with the closest form ancestor though |
| 20:06 | <aklein> | rniwa: so previously, we weren't associating elements inside templates with forms outside |
| 20:06 | <aklein> | is the change just that <form><template><form> results in a <form> inside the template? |
| 20:11 | <rniwa> | aklein: no, the problem was that previously we were having form element pointer being not null even if we entered a template element |
| 20:11 | <rniwa> | aklein: so if we had <form><template><form> |
| 20:11 | <rniwa> | aklein: then we'll rip off the inner form |
| 20:11 | <rniwa> | aklein: because it's a nested form element |
| 20:11 | <rniwa> | aklein: if we had <isindex>, we won't generate a new form element as long as there is an outer form element even if it was outside the template element |
| 20:12 | <rniwa> | aklein: e.g. <form><template><isindex> |
| 20:15 | <aklein> | I think we're saying the same thing, you're just saying it more precisely :) |
| 20:15 | <aklein> | so yes, I think we're fine with that change |
| 20:16 | <aklein> | it is a _little_ weird that you can put <form><form> inside a template, but I don't expect it to cause any trouble |
| 20:27 | <Ms2ger> | Is it just me, or does https://twitter.com/OperaLunchMenu suggest you don't get to eat a lot at Opera? |
| 20:28 | <gsnedders> | Ms2ger: In what way? Lack of options? |
| 20:29 | <Ms2ger> | In the sense that "Monday - Tomato soup" doesn't sound like a full meal to me :) |
| 20:31 | <gsnedders> | Well, it's based on what's published on the intranet, AFAIK, which doesn't always reflect what actually appears in the canteen. And there's quite often more options (though typically similar dishes) than it gives. And at least here soup and bread isn't that unusual as a meal. Even if I'd complain it's too small. :) |
| 20:31 | <gsnedders> | There again, speaking to someone who often has four meals a day probably isn't a good judge of what "too small" means :) |
| 21:15 | <Ms2ger> | Looks like hypermail doesn't like IDN: http://lists.w3.org/Archives/Public/www-archive/2013Dec/ |
| 21:34 | <Domenic_> | <isindex>: the gift that keeps on giving. |
| 21:58 | <Hixie> | SimonSapin: thanks for the bug |
| 21:59 | <Hixie> | aklein: you know you've spent too much time with the html parser when you think the weird behaviour is that <form><form> works, not that <form><form> ignores the second <form> :-P |
| 22:03 | <zcorpan> | i think it's a bit weird that it works differently inside <template> |
| 22:04 | <Hixie> | it's weird that it works differently _outside_ template :-P |
| 22:04 | <Hixie> | (but yes, i agree) |
| 22:05 | <Hixie> | (lots is weird about html parsing :-( ) |
| 22:13 | <a-ja> | Hixie: fyi, dholbert just landed multi-line flex on moz inbound...along with last of the shortcuts, best i can tell |
| 22:14 | <Hixie> | last of the shortcuts? |
| 22:14 | <a-ja> | flex has some shortcut properties |
| 22:15 | <Hixie> | oh, right |
| 22:15 | <Hixie> | cool |
| 22:15 | <Hixie> | i really should learn flex one of these days |
| 22:16 | <Hixie> | i worked on a far ancestor of it back in the day, and when i handed that off i kind of shut off that part of my brain |
| 23:20 | <JonathanNeal> | @Hixie is there a particular place for me to make change proposals to the HTML5 spec? |
| 23:21 | <Hixie> | http://whatwg.org/newbug or http://whatwg.org/mailing-list#spec or here or ian⊙hc |
| 23:22 | <JonathanNeal> | The /newbug link redirects me to w3.org, am I in fact reporting it to them? |
| 23:23 | <Hixie> | the whatwg uses the w3.org bugzilla, just make sure the component is WHATWG |
| 23:23 | <Hixie> | product is WHATWG, rather |
| 23:23 | <Hixie> | component is HTML |
| 23:23 | <JonathanNeal> | Got it. Thanks. I'll setup an account. |
| 23:23 | <Hixie> | you can also use the little widget in the bottom right of the spec |
| 23:23 | <Hixie> | that files a bug for you |
| 23:23 | <Hixie> | without you having to have an account |
| 23:23 | <JonathanNeal> | In the meantime, if you have any particular thoughts, especially positive/negative effects that immediately come to mind, I'm working on http://www.w3.org/html/wg/wiki/ChangeProposals/subhead |
| 23:24 | <Hixie> | isn't that redundant with <hgroup>? |
| 23:25 | <JonathanNeal> | If you haven't clicked the link yet, the TOC has links that attempt to describe the differences between <subhead> and <hgroup>, as well as <aside>, and <small>. |
| 23:26 | <Hixie> | the part about <hgroup> on that page is just wrong |
| 23:26 | <JonathanNeal> | I more-or-less wrote it myself, so I am more than happy to correct it. What did I get wrong? |
| 23:26 | <Hixie> | the hgroup element does not force a pattern upon the markup where none previously existed |
| 23:26 | <Hixie> | and it doesn't exist simply to support a newly created outline algorithm |
| 23:27 | <JonathanNeal> | I agree that "simply" is unnecessary and a bit insulting. I'm sorry. |
| 23:27 | <Hixie> | it doesn't exist to support a newly created outline algorithm at all |
| 23:28 | <Hixie> | at best, the outline algorithm exists to support it |
| 23:28 | <JonathanNeal> | I do think the outline algorithm + hgroup redefines <h2>. |
| 23:28 | <Hixie> | well yeah, that's the idea |
| 23:28 | <Hixie> | people were using <h2> in that way |
| 23:28 | <Hixie> | this paves the cowpath |
| 23:28 | <Hixie> | as people say |
| 23:31 | <JonathanNeal> | Okay, I'm working on that section now. I'll let you know when it's updated. |
| 23:31 | <Hixie> | for the whatwg, the most important thing to do when filing a bug is to describe the problem |
| 23:31 | <JonathanNeal> | I presume you'll completely disagree with that point regardless. |
| 23:32 | <jamesr__> | TabAtkins: process and maintenance are implementor / spec writer concerns, which should be at the bottom of the hierarchy of constituents. |
| 23:32 | <Hixie> | the basic approach we take is first we describe the problem, and once we're agreed on what that is, and only then, we start looking at proposals for solutions |
| 23:32 | <Hixie> | and we evaluate them based on our understanding of the problem |
| 23:33 | <Hixie> | so the single most important thing to do is to make sure the problem is well described |
| 23:33 | <Hixie> | ("once we're agreed" meaning once the editor of the relevant spec has been convinced there's a problem) |
| 23:34 | <Hixie> | certain problems are very easy to convince editors of, e.g. "browsers don't do what the spec says" |
| 23:34 | <Hixie> | or "the spec contradicts itself" |
| 23:34 | <Hixie> | or "this is a use case that the spec doesn't support, and here is evidence that this use case matters" |
| 23:35 | <JonathanNeal> | @Hixie right, and that's more a matter for http://www.w3.org/html/wg/wiki/index.php?title=ChangeProposals/hgroup&oldid=14091 |
| 23:36 | <Hixie> | well, the whatwg doesn't really use the change proposals approach at all, that's more a w3c thing |
| 23:36 | <Hixie> | i'm just saying if you want to file a bug (and please do!), it's important to include in the bug a description of what the problem is. more important than anything else. |
| 23:37 | <Hixie> | i would generally recommend only including a problem description |
| 23:37 | <Hixie> | without a proposal to go with it |
| 23:46 | <JonathanNeal> | @Hixie more accurate? http://www.w3.org/html/wg/wiki/ChangeProposals/subhead#Difference_from_.3Chgroup.3E |
| 23:47 | <Hixie> | the <hgroup> element does not force a grouping pattern upon the markup where none previously existed |
| 23:47 | <Hixie> | the whole point of <hgroup> is that the grouping pattern _does_ previously exist |
| 23:47 | <Hixie> | we're just replacing what people are doing today with <div>, with <hgroup> |
| 23:48 | <Hixie> | obviously if people want to not do it with <hgroup> they don't have to -- they can e.g. use <p> |
| 23:48 | <JonathanNeal> | Several of the examples on http://wiki.whatwg.org/wiki/Hgroup_element do not replace a <div> |
| 23:49 | <Hixie> | (bylines and subheadings are very distinct things, by the way. i wouldn't recommend addressing them with the same solution.) |
| 23:50 | <Hixie> | which ones don't replace a <div>? |
| 23:50 | <JonathanNeal> | So the two bugs would be that hgroup does not address all real world scenarios, and it may create a situation where two different elements <hgroup>+<h2> vs <p> are used to markup the same kind of content. |
| 23:50 | <Hixie> | as far as i can tell, all those examples work great with <hgroup> |
| 23:50 | <tantek> | people still arguing about hgroup? |
| 23:50 | <Hixie> | nothing will address "all real world scenarios". that's not a worthy goal. it's incompatible with the goal of "a simple language". |
| 23:51 | <Hixie> | tantek: hey man, i'm just glad they stopped arguing about <acronym>. |
| 23:51 | <tantek> | LOL |
| 23:51 | <JonathanNeal> | Gutenberg, A Tale of Two Cities, one Apple example - I'm scrolling and noting them, there may be more. |
| 23:51 | <Hixie> | the gutenberg one works perfectly with hgroup? what am i missing |
| 23:51 | <tantek> | I've used hgroup. I put hgroup on the cover of my HTML5 book. However with all my experience hgroup is too esoteric to be included in "a simple language". |
| 23:51 | <jamesr__> | i put longdesc on my hgroups |
| 23:52 | <tantek> | It's not useful enough often enough. |
| 23:52 | <Hixie> | tantek: it's certainly not as mainstream as, say, <h1>, but i've been amazed at how many pages have subheadings. |
| 23:52 | <JonathanNeal> | @Hixie sure? http://viewsource.in/http://www.gutenberg.org/files/36/36-h/36-h.htm#L54-56 |
| 23:52 | <tantek> | Hixie - yeah it fell to the rarer/esoteric side for me |
| 23:52 | <Hixie> | JonathanNeal: you just stick an <hgroup> around it and you're done. what's the issue? |
| 23:53 | <tantek> | I wanted to like hgroup. But it's just not relevant in practice. |
| 23:53 | <JonathanNeal> | You may enjoy http://viewsource.in/http://motherfuckingwebsite.com/#L15 for an interesting approach, @tantek |
| 23:54 | <Hixie> | tantek: i think on the samp to p axis, it's on the samp side, but nowhere near as far as things like dfn, or q, or the advanced ruby stuff that some people think is critical enough to add to html. |
| 23:54 | <tantek> | oh I'm a huge user of <aside> |
| 23:54 | <tantek> | like nearly EVERY blog post |
| 23:54 | <tantek> | it's so common |
| 23:54 | <tantek> | Hixie, disagreed, I used dfn quite often |
| 23:54 | <tantek> | and q |
| 23:54 | <tantek> | well blockquote (I lump them together) |
| 23:55 | <Hixie> | tantek: and that's why we don't rely only on anecdata :-P |
| 23:55 | <Hixie> | (blockquote is much more common than q) |
| 23:55 | <tantek> | the advanced ruby stuff gets a pass because none of us here regularly publish japanese text on the web (except maybe MikeSmith?) |
| 23:55 | <Hixie> | that's the problem |
| 23:56 | <Hixie> | the people who would normally say no think "oh, i don't know enough about this, i'll just assume they know better" |
| 23:56 | <Hixie> | despite the fact that "they" don't know any better than the people who make proposals for esoteric english things |
| 23:56 | <tantek> | though that being said it would have been fine as an extension IMO |
| 23:56 | <Hixie> | (ruby itself is fine, i'm just talking about the extreme esoteric stuff) |
| 23:56 | <tantek> | re: samp - ironically I've even used samp and kbd more than hgroup in the past year |
| 23:56 | <Hixie> | (for the record) |
| 23:57 | <tantek> | Hixie - I'd put all of ruby into an extension |
| 23:57 | <Hixie> | basic and even semi-advanced ruby (basically, what WHATWG HTML supports today) is actually quite often used in CJK texts |