| 00:20 | <smaug____> | pdr: whatwg.org is working fine ;) |
| 01:47 | SamB | boggles at the requirement that navigator.product == "Gecko" |
| 06:09 | <MikeSmith> | whatwg.org seems unresponsive at the moment |
| 06:10 | <MikeSmith> | Hixie: ↑ |
| 07:02 | <MikeSmith> | Hixie: nm, working fine for me now |
| 07:03 | <Hixie> | odd |
| 07:03 | <Hixie> | didn't see any issues on this side |
| 07:05 | <MikeSmith> | maybe just wonky connection on my side but it was weird because I couldn't get a response either over local Japan connection nor when tryining from my server in the UK |
| 07:06 | <Hixie> | might have been a connection on the incoming dreamhost pipe from outside california or something |
| 07:07 | <MikeSmith> | ok |
| 07:20 | <annevk-cloud__> | zcorpan: it is different, but you can pull it from the settings object which exists on the global environment |
| 07:22 | <zcorpan> | annevk-cloud: yeah |
| 09:33 | <zcorpan> | jgraham: r? https://critic.hoppipolla.co.uk/r/584 |
| 11:19 | <qFox> | can anybody point me to a reference why orphan </p> will cause an extra <p>? |
| 11:20 | <Ms2ger> | It won't? |
| 11:20 | <qFox> | <p><p></p></p> how many p's? |
| 11:21 | <Ms2ger> | Two |
| 11:21 | <qFox> | try . |
| 11:21 | <Ms2ger> | Mm |
| 11:21 | <qFox> | :) |
| 11:21 | <qFox> | Glad I'm not the only one |
| 11:22 | <qFox> | But now I'm looking for some reference that explains what/when/why/how/bla on this. |
| 11:22 | <jgraham> | Three |
| 11:22 | <jgraham> | <p> creates a <p> |
| 11:23 | <jgraham> | <p> creates a <p> |
| 11:23 | <jgraham> | </p> closes a <p> |
| 11:23 | <Ms2ger> | http://www.whatwg.org/specs/web-apps/current-work/multipage/tree-construction.html#parsing-main-inbody |
| 11:23 | <jgraham> | </p> with no open <p> creates a <p> |
| 11:23 | <Ms2ger> | 'An end tag whose tag name is "p"' |
| 11:24 | <qFox> | "If the stack of open elements does not have a p element in button scope, then this is a parse error; insert an HTML element for a "p" start tag token with no attributes." |
| 11:24 | <qFox> | thanks! |
| 11:26 | <qFox> | is "button scope" just confusing wording for me right now? |
| 11:27 | <jgraham> | qFox: Probably. It should be linked to a definition, but basically you go up the stack of open elements until you find an element in a particular set of elements, or the element you are looking for |
| 11:28 | <qFox> | Ok. Button reads for me like "if it's child of a <button>". but okay I get it, just terminology. Cheers |
| 11:28 | <Ms2ger> | I argued unsuccessfully that it's confusing at one point |
| 11:31 | <qFox> | It implies that it only refers to the scope of a <button>, imo, rather than the scope of a button or anything else. |
| 11:42 | <jgraham> | It would be very annoying to call it "in button or [list of other elements] scope" |
| 11:42 | <jgraham> | At some point you just have to follow the definitions and read the spec |
| 13:54 | <Ms2ger> | http://lists.w3.org/Archives/Public/www-archive/2014Feb/0014.html |
| 15:09 | gsnedders | wonders what IE/Fx do with something not in Windows-1252 |
| 17:04 | <dglazkov> | good morning, Whatwg! |
| 17:41 | Hixie | learns about importNode() |
| 17:41 | <Hixie> | dunno how i didn't realise it cloned before |
| 17:41 | <Hixie> | i think i thought it was just adoptNode() |
| 22:05 | <Hixie> | so, anyone care what window.focus() does? |
| 22:05 | <Hixie> | looks like we don't have interop, so if anyone cares, let me know... |
| 22:07 | <Hixie> | http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=2823 |
| 22:19 | <rniwa> | Hixie: focus is hard :/ |
| 22:19 | <Hixie> | yeah seriously |
| 22:19 | <Hixie> | i'm 80% done rewriting how focus is specced |
| 22:19 | <Hixie> | which should clean this kind of thing up |
| 22:48 | <miketaylr> | Hixie: i care. interested in what you spec. |
| 22:54 | <Hixie> | miketaylr: right now i'm matching firefox behaviour. |
| 22:54 | <Hixie> | miketaylr: which is, as far as i can tell, move the focus to whatever descendant of the window in question last had focus |
| 22:54 | <miketaylr> | cool |
| 22:57 | <Hixie> | spec is regenned if you want to check what it looks like |
| 22:57 | <MikeSmith> | Hixie: in other news I'm curious about in what cases a th element would be interactive content |
| 22:57 | <Hixie> | but it has a number of errors |
| 22:57 | <Hixie> | MikeSmith: when it's sortable |
| 22:57 | <MikeSmith> | ah |
| 22:57 | <MikeSmith> | yeah, of course. Hadn't thought about that |
| 22:59 | miketaylr | puts on todo list |
| 23:00 | <Hixie> | ok, spec's markup errors are fixed, at least. still lots of polish to do, but if anyone wants to see what the new focus stuff looks like, it's up on the single-page version. |
| 23:00 | <Hixie> | quick break then i'll try to finish it off |
| 23:15 | <esprehn> | annevk-cloud: rafaelw was supposed to reply to that thread, but I can reply too if you want |
| 23:20 | <Hixie> | i hope nobody minds my ghetto diagrams http://www.whatwg.org/specs/web-apps/current-work/#focus |
| 23:24 | <miketaylr> | beauty. |
| 23:24 | <MikeSmith> | Hixie: I like in your diagram how the spider tentacled person whose head looks like a "2" is grabbing up parts of the the user interface to take back as souvenirs to his home planet |
| 23:25 | <Hixie> | lol |
| 23:25 | <Hixie> | i should put that as the alt="" text |
| 23:26 | <MikeSmith> | +1 to that |
| 23:28 | <smaug____> | uh, <output>'s defaultValue handling is so odd |
| 23:29 | <esprehn> | Hixie: again, having the concept of <dialog> all tangled into the concept of focus is not something I support |
| 23:29 | <Hixie> | smaug____: how so? |
| 23:30 | <smaug____> | Hixie: defaultValue isn't initially textContent |
| 23:30 | <esprehn> | Hixie: that's what I was trying to convey about Android, the focus management system has no idea about dialogs. There's no special cases like this. |
| 23:30 | <Hixie> | esprehn: ? how else would you do it? |
| 23:30 | <esprehn> | Hixie: you can add a tabgroup attribute if you want to support groups, and you can spec focus traverses the top layer order when it jumps between things in the top layer |
| 23:31 | <Hixie> | smaug____: i think you're misreading it |
| 23:31 | <Hixie> | smaug____: oh, no, wait |
| 23:31 | smaug____ | was testing two different implementations and wondered why it is so odd |
| 23:31 | <Hixie> | smaug____: huh, yeah, that's weird. |
| 23:31 | <esprehn> | <dialog> should be something we can express as a module in the browser, if the "FocusController" needs to have lots of if (dialog) doDifferentThings() that's not possible |
| 23:31 | <Hixie> | smaug____: looks like it doesn't check the flag correctly on getting? |
| 23:32 | <smaug____> | Hixie: Gecko and Blink seem to follow the spec |
| 23:32 | <Hixie> | esprehn: it would have been hugely helpful if you could send this feedback before i spent 3 days writing this up, btw. |
| 23:32 | <Hixie> | esprehn: but i don't really understand what you're proposing |
| 23:32 | <Hixie> | esprehn: the special cases are only because the Web has a legacy we have to support as well |
| 23:33 | <Hixie> | esprehn: it's as separate as it can be, given the legacy, as far as i can tell |
| 23:33 | <esprehn> | <dialog> is not legacy |
| 23:33 | <Hixie> | esprehn: no, <dialog> is the only new thing here |
| 23:33 | <esprehn> | yes, and new things should not bleed into core algorithms like this |
| 23:33 | <Hixie> | esprehn: and that's why it's carefully kept on the side with dialog groups |
| 23:34 | <Hixie> | esprehn: what special case are you specifically concerned about? |
| 23:34 | <esprehn> | Android wouldn't accept code that put if (widget instanceof Version5Widget) doStuff() in the core platform either |
| 23:34 | <Hixie> | android works pretty much exactly as this describes. |
| 23:34 | <esprehn> | I'm sorry I wasn't clear, I thought I was clear when I said <dialog> shouldn't have any special cases in my previous emails |
| 23:34 | <Hixie> | which previous e-mails? |
| 23:36 | <Hixie> | the only e-mail i've seen from you about it was after i started editing, weeks after i asked for feedback, to a vendor-specific list, and didn't give any actionable feedback |
| 23:36 | <Hixie> | (and i replied straight away) |
| 23:36 | <esprehn> | "I think we should push back on the <dialog> spec to not introduce more magical behavior that cannot be explained in terms of our existing CSS primitives and JS" |
| 23:36 | <esprehn> | that was in the context of positioning |
| 23:36 | <esprehn> | but you're adding magic now for focus |
| 23:36 | <Hixie> | this isn't magic |
| 23:37 | <Hixie> | it's what android, windows, iOS, MacOS, X Windows, etc, all do |
| 23:37 | <esprehn> | none of them have instanceof checks inside the core focusing logic |
| 23:37 | <Hixie> | i'm not sure what you mean by instanceof checks |
| 23:37 | <Hixie> | what part of what algorithm is it you mean? |
| 23:38 | <esprehn> | ex. "Each dialog element that has an open attribute specified and that is being rendered " |
| 23:38 | <Hixie> | ? |
| 23:38 | <Hixie> | that's the same as other platforms |
| 23:38 | <esprehn> | "The focus chain of a focusable area or control group owner object subject" |
| 23:38 | <esprehn> | has a special case for dialogs |
| 23:39 | <Hixie> | that's a virtual call. |
| 23:39 | <Hixie> | not an instanceof |
| 23:39 | <Hixie> | it's just walking a tree |
| 23:39 | <Hixie> | same as every other platform |
| 23:39 | <esprehn> | "if current object is a dialog object" how is that a virtual call? |
| 23:39 | <Hixie> | it's the equivalent of "current object -> parent" |
| 23:39 | <esprehn> | you're saying because it's a big stack of cases, heh |
| 23:40 | <Hixie> | that step literally just walks up a tree, each node in which might have a different way to get its parent |
| 23:41 | <Hixie> | it's the same as, say, nodeName's definition: |
| 23:41 | <Hixie> | http://dom.spec.whatwg.org/#dom-node-nodename |
| 23:41 | <Hixie> | those aren't instanceof checks, it's just a virtual method defined for each subclass |
| 23:42 | <esprehn> | How do you implement <jquery-window> that has the same focusing behavior as dialog? |
| 23:43 | <Hixie> | you use <dialog> as the backing element. |
| 23:43 | <Hixie> | that's what <dialog> is for |
| 23:44 | <esprehn> | that means <dialog> is special |
| 23:44 | <Hixie> | every HTML element is special, except <span>. |
| 23:44 | <esprehn> | which is not true on Android or iOS |
| 23:44 | <Hixie> | um... you can't make a native-like dialog on Windows without using an actual dialog handle vended by the OS |
| 23:44 | <esprehn> | you can call the APIs that Android's Dialog uses |
| 23:44 | <Hixie> | how is that different? |
| 23:44 | <esprehn> | there's nothing special down there |
| 23:44 | <Hixie> | <dialog> is "the APIs that Android's Dialog uses" |
| 23:45 | <Hixie> | how do you implement <jquery-canvas> without <canvas>? |
| 23:45 | <Hixie> | or keyboard input without the keydown/keyup/keypress events? |
| 23:45 | <esprehn> | both of those are small self contained things |
| 23:46 | <Hixie> | or change the mouse cursor without using CSS 'cursor'? |
| 23:46 | <Hixie> | <canvas> is a heck of a lot less small than <dialog> :-) |
| 23:47 | <esprehn> | shrug, I'm not sure how to convince you, but I don't support this current path |
| 23:47 | <esprehn> | in the same way I think we should remove things like <details> |
| 23:48 | <Hixie> | ... |
| 23:48 | <esprehn> | you're too far up the stack |
| 23:48 | <Hixie> | i don't think it's necessarily wrong to have a platform where the main target is "lower down the stack", but, that's not how HTML works... |
| 23:49 | <Hixie> | i would love to replace HTML with something better |
| 23:49 | <esprehn> | That's the whole concept of the extensible web |
| 23:49 | <Hixie> | but i don't think changing the basic approach of how we design HTML 24 years in is going to lead to a sane platform |
| 23:49 | <Hixie> | so it wouldn't be a matter of "not having <details> and <dialog>" |
| 23:50 | <Hixie> | every time anyone has tried to make "extensible web" stuff, it's failed, so please forgive my lack of enthusiasm :-) |
| 23:50 | <Hixie> | q.v. xml, xhtml2, etc |
| 23:51 | <esprehn> | In blink our goal is to bunker down on explaining the platform |
| 23:51 | <wilhelm> | Please do pave the cowpaths here, so I can write less code. :) |
| 23:51 | <esprehn> | and building primitives, so I suppose I'll just keep pushing back on you |
| 23:52 | <Hixie> | esprehn: i think that's a misguided approach, fwiw. |
| 23:52 | <Hixie> | esprehn: i think we agree on many of the concrete implications, but the approach imho is poorly described as "explaining the platform" |
| 23:53 | <Hixie> | though fwiw, i think http://www.whatwg.org/specs/web-apps/current-work/#focus "explains the platform" in far more detail than we've ever had before for focus :-) |
| 23:53 | <esprehn> | That's great, remove <dialog> from that and ship it |
| 23:53 | <Hixie> | that's unhelpful |
| 23:54 | <esprehn> | Then add the tabgroup primitive, explain that dialog uses tabgroup and ship that |
| 23:54 | <Hixie> | i've no idea what you mean there |
| 23:54 | <Hixie> | tab groups are a presenational issue, which should be dealt with in CSS |
| 23:54 | <Hixie> | or web components |
| 23:54 | <Hixie> | doesn't seem related to dialogs |
| 23:55 | <esprehn> | I'm saying explain what you want for <dialog> in terms of a feature that web components can use |
| 23:55 | <Hixie> | (tab groups are really a media-specific overflow mechanism) |
| 23:56 | <Hixie> | esprehn: happy to. file a bug with use cases and explaining how it would integrate with the focus model, and i'll spec something up. |
| 23:56 | <Hixie> | esprehn: so far, i haven't heard anything regarding how web components wants to interact with focus except some bugs from apple |
| 23:56 | <esprehn> | It should work however you want <dialog> to work |
| 23:56 | <Hixie> | esprehn: (which weren't actionable, and had more to do with tabindex="" than the focus model) |
| 23:56 | <Hixie> | i want <dialog> to work as a native element...? that seems diametrically opposite to what web components is |
| 23:57 | <Hixie> | if you want a dialog, you can just use one in a component, i don't understand what you're asking for |
| 23:57 | <esprehn> | I don't support that, you want "native" to mean "unexplained magic APIs that JS can't get to" |
| 23:58 | <esprehn> | and I plan to push back on that |
| 23:58 | <Hixie> | esprehn: it's not "unexplained magic" dude, i just spent multiple days explaining it in excruciating detail. |
| 23:58 | <Hixie> | esprehn: and in more detail than has ever been specced before. |