| 00:59 | <Hixie> | TabAtkins: you still want cssElementMap, right? |
| 01:03 | <TabAtkins> | Hixie: Yes. I know I want it on the HTML side, though I'm still not 100% sure how I'll use it on the CSS side. |
| 01:03 | <TabAtkins> | Damn conflict between type selectors and idents. |
| 01:03 | <Hixie> | roger. |
| 01:04 | <Hixie> | TabAtkins: just checking for references while running my garbage collector over here, don't mind me :-) |
| 01:04 | TabAtkins | thinks that he'll probably just fall back to Moz's behavior of having it be a shadowing ID. |
| 01:04 | <Hixie> | i need to work out what to do about http://wiki.whatwg.org/wiki/New_Features_Awaiting_Implementation_Interest |
| 01:05 | TabAtkins | unless we decide we never want to do arbitrary selectors in element(), in which case idents are still free from ambiguity. |
| 01:06 | <TabAtkins> | Hixie: Make a periodic status ping on the list to remind people about them, and see if new interest has appeared? |
| 01:07 | <Hixie> | TabAtkins: i was thinking more that i should ping the (relevant) people _not_ on the list, to see if they have interest they haven't expressed |
| 01:07 | <Hixie> | whence my starting http://wiki.whatwg.org/wiki/Who_to_ask_about_stuff |
| 01:09 | <TabAtkins> | Welp, time to continue my record of being the spammiest person in the W3C. |
| 01:10 | <TabAtkins> | Also, +1 on .currentScript, woo! I've got a use-case that would kill for it. |
| 01:24 | <jsbell> | Oh, yay on .currentScript as well |
| 01:28 | <smaug____> | .currentScript? |
| 01:28 | smaug____ | wonders how that maps to the events sicking implemented for <script> |
| 01:28 | <TabAtkins> | smaug____: It's just the <script> element for the currently executing script. |
| 01:29 | <smaug____> | sicking added before/afterscriptexecute |
| 01:29 | <smaug____> | it was discussed in whatwg mailing list |
| 01:29 | <smaug____> | so, sounds like similar feature |
| 01:30 | <smaug____> | oh, we have also .currentScript :) |
| 01:31 | <Hixie> | smaug____: both of those features are now in the spec and in firefox |
| 01:32 | <smaug____> | good good |
| 01:32 | smaug____ | is checking whether he reviewed the patch |
| 01:33 | <smaug____> | no, I didn't |
| 01:33 | <smaug____> | and sorry, I missed the latest email to whatwg |
| 01:44 | <TabAtkins> | Sigh, and I'm |
| 01:44 | <TabAtkins> | Sigh, and I'm a good 17% of all email to www-style this month. |
| 01:45 | <Yuhong> | Hixie: on http://html5.org/tools/web-apps-tracker?from=7529&to=7530 |
| 01:46 | <Yuhong> | Hixie: I'd say that WHATWG realized that versioning HTML don't make sense. |
| 01:47 | <Yuhong> | Hixie: And they realize that pace of evolution of the web is not controlled by a central body. |
| 02:01 | GPHemsley | wonders if Hixie's use of "amongst" in the History section is non-en-US |
| 02:40 | <TabAtkins> | Hixie: Would you mind sending a short email to www-style explaining what needs to be done on the CSSOM side for the <link rel=stylesheet crossorigin> additions? |
| 03:14 | <Hixie> | TabAtkins: yeah, i have a bunch of stuff to request, not sure what yet. there's a bug about CSSOM integration. |
| 08:14 | annevk | likes implementas |
| 08:25 | <MikeSmith> | is element.dispatchEvent(event) supported across browsers? |
| 08:25 | <MikeSmith> | and how far back? |
| 08:26 | <MikeSmith> | not in IE8 I guess |
| 08:28 | <MikeSmith> | hmm or maybe the click() method is more widely supported |
| 08:28 | <annevk> | what's this for? |
| 08:31 | <annevk> | Ms2ger++ |
| 08:32 | <annevk> | Abstracting out the getElementsBy* methods makes it very easy to put them all on RootNode |
| 08:48 | <MikeSmith> | annevk: for dispatching an event to elements other than its target |
| 08:52 | <rniwa> | annevk: put getElementsBy* on where? |
| 08:53 | <rniwa> | annevk: i think we want to discourage the use of those functions since they return HTMLCollection with named getters |
| 08:53 | <annevk> | rniwa: http://dom.spec.whatwg.org/#rootnode but yeah, I'm having second thoughts |
| 09:02 | <Ms2ger> | Btw, we're getting new Document() pretty soon |
| 09:06 | <annevk> | cool, next is new Range() I guess |
| 09:11 | <annevk> | MikeSmith: any chance we get rid of https://www.w3.org/Bugs/Public/buglist.cgi?product=WebAppsWG&component=URL ? |
| 09:12 | <annevk> | MikeSmith: apparently people keep filing bugs there |
| 09:12 | <annevk> | :/ |
| 09:12 | <MikeSmith> | ok |
| 09:12 | <MikeSmith> | I will need to make sure Art is OK with that |
| 09:12 | <MikeSmith> | with removing it |
| 09:16 | <annevk> | well I'm gonna keep moving bugs so they stay on my radar for fixing |
| 09:17 | <annevk> | seems less hassle to just have one place |
| 09:18 | <annevk> | if he feels like fixing the bugs though, I guess we can arrange something |
| 10:29 | <hsivonen> | Opera’s usage share would look better on StatCounter if Opera rebranded its releases as “rapic” and got version combined like Chrome and Firefox |
| 10:30 | <hsivonen> | *rapid |
| 10:34 | <odinho_> | Hmmmm... |
| 10:34 | <darobin> | hmmmmmmmmm |
| 10:34 | <odinho_> | darobin: Hey, that's my thing. |
| 10:35 | <darobin> | hmm mm |
| 10:35 | <reggna_> | Mmmhm! |
| 10:35 | <darobin> | oh yeah |
| 10:36 | <annevk> | http://www.youtube.com/watch?v=0wwHl3OKyFU looks like fun darobin |
| 10:36 | <annevk> | now I'm kinda sad I missed it |
| 10:36 | <darobin> | annevk: it was a *lot* of fun |
| 10:36 | <darobin> | there'll be others |
| 10:36 | <odinho_> | annevk: It was fun :D I'm looking stupid in many of the clips ;D |
| 10:36 | <darobin> | and not just odinho_ :) |
| 12:15 | <jgraham> | http://clokep.blogspot.se/2012/11/javascript-typed-arrays-pain.html |
| 12:18 | <annevk> | Film at 11? |
| 12:19 | <jgraham> | Well yes |
| 12:20 | <jgraham> | "I told you so" would be the uncharitable response |
| 12:21 | <annevk> | http://calculist.org/blog/2012/04/24/the-little-endian-web/ |
| 12:22 | <jgraham> | Well yes, but this is a real developer trying to solve a real problem and being bitten by crazy defaults |
| 12:31 | <annevk> | Sorry, wasn't trying to be dismissive, just saying that I had not expected anything else |
| 12:52 | <zcorpan> | what happened to origin cookies? no interest? |
| 12:53 | <annevk> | you mean cake? |
| 12:54 | <annevk> | not entirely sure what happened |
| 12:54 | <annevk> | little interest I suppose |
| 12:54 | <annevk> | and prolly a lot of bikeshedding on what else ought to be taken into consideration |
| 13:21 | <annevk> | heycam: yo |
| 13:22 | <annevk> | heycam: for Christmas, or maybe a bit earlier, I'd like dictionary where all the members match "DOMString : (DOMString or sequence<DOMString>)", are ideally ordered (dunno how that works these days in JavaScript land), and unconstrained otherwise |
| 13:23 | <annevk> | heycam: well, I want to add the "convert to code points" attribute to it, once you add that to DOMString |
| 13:36 | <annevk> | so URLQuery... |
| 13:36 | <annevk> | -> has underlying string |
| 13:37 | <annevk> | -> underlying string can be URL's query of an associated URLUtils object (if any) |
| 13:37 | <annevk> | -> if associated with URLUtils needs to invoke URLUtils' update steps |
| 13:38 | <annevk> | I suppose technically you only need the underlying string if there's a URLUtils thingie involved |
| 13:39 | <annevk> | should it take query encoding into account? or should it screw over query encoding? |
| 13:55 | <annevk> | hmm more questions |
| 13:55 | <annevk> | ?test vs ?test= |
| 13:55 | <annevk> | what does get() return? |
| 13:55 | <annevk> | get("test") |
| 13:56 | <annevk> | null / "" would make it indistinguishable from when "test" was not specified at all |
| 14:01 | <zcorpan> | "" |
| 14:01 | <zcorpan> | and null when absent |
| 14:02 | <zcorpan> | not being able to distinguish ?test and ?test= seems OK |
| 14:02 | <smaug____> | yeah |
| 14:02 | <smaug____> | unless someone has really good use case |
| 14:02 | <smaug____> | which I doubt |
| 14:04 | <zcorpan> | we don't distinguish between different syntaxes in HTML that result in the same DOM, either |
| 14:04 | <smaug____> | well, this is not HTML. |
| 14:06 | <annevk> | and this does not result in the same serialization |
| 14:06 | <annevk> | but I reached the same conclusion |
| 14:07 | <annevk> | smaug____: if you have opinions on DOMTokenList: https://www.w3.org/Bugs/Public/show_bug.cgi?id=20104 |
| 14:47 | <annevk> | I updated http://url.spec.whatwg.org/#urlquery a bit. Also made .query settable. Logic was a bit complicated to figure out, but should be straightforward now. |
| 15:38 | <djdingo14> | Seems like WebSockets have JUST now become usable? |
| 17:11 | smaug____ | needs to remember to reply to that <menu> thread |
| 17:12 | GPHemsley | wonders why the wiki is MIT License if a lot of it is intended to go into CC0 specs |
| 17:17 | <JonathanNeal> | smaug____: what's the haps with menu? |
| 17:23 | <smaug____> | JonathanNeal: ? |
| 17:23 | <smaug____> | Hixie tries to figure out what to do with <menu> |
| 17:23 | <smaug____> | I think we should keep at least contextmenu |
| 17:23 | <smaug____> | I don't see too good reasons for other menu types |
| 17:24 | <JonathanNeal> | I thought they were basically <ul> for apps. |
| 17:25 | <TabAtkins> | annevk: Re ?test vs ?test=, this is why you need a .has() method like every other Map in the world. The former should return null (or undefined), the latter should return "", and you can distinguish both from not specifying test at all by calling .has('test'). |
| 17:25 | <TabAtkins> | JonathanNeal: <ul> is <ul> for apps. ^_^ |
| 17:26 | <TabAtkins> | I agree with Smaug that context menu has to stay. I kinda like the button-driven popup menu case. |
| 17:28 | <JonathanNeal> | TabAtkins: what about for toolbars? |
| 17:28 | <smaug____> | unless toolbars are something which integrates with browser ui, I don't see reason for them |
| 17:29 | <JonathanNeal> | do context menus integrate with browser ui? |
| 17:29 | <smaug____> | they do |
| 17:30 | <smaug____> | at least in the only implementation |
| 17:30 | <JonathanNeal> | <menu type="context"> example? |
| 17:32 | <smaug____> | JonathanNeal: http://thewebrocks.com/demos/context-menu/ |
| 17:32 | <JonathanNeal> | It's all the same in Chrome. Do I need to use Firefox, Opera? |
| 17:33 | <smaug____> | Firefox |
| 17:33 | <smaug____> | I think contextmenu is implemented only in Gecko |
| 17:33 | <TabAtkins> | So far, yeah. |
| 17:34 | <JonathanNeal> | Right. Okay, now I see it. If you drop all the other use cases for <menu> why even include type? |
| 17:34 | <smaug____> | TabAtkins: if we had menu buttons too, do you think page should be able style the opened menu? |
| 17:34 | <GPHemsley> | TabAtkins: ?test and ?test= should be treated as equal IMO |
| 17:35 | <TabAtkins> | smaug____: That's a good question. I'm not sure. I think I'd prefer that it be a native menu? |
| 17:35 | <smaug____> | in which case it would be quite close to <select> |
| 17:35 | <smaug____> | styling of <select> isn't defined anywhere, I think |
| 17:35 | <TabAtkins> | Correct, it's not. |
| 17:35 | <smaug____> | and implementations support different things |
| 17:35 | <TabAtkins> | As they should. |
| 17:35 | <TabAtkins> | GPHemsley: I could be convinced of that. |
| 17:36 | <GPHemsley> | TabAtkins: Because ? and ?test are not the same. |
| 17:36 | <TabAtkins> | Of course not, but I already said as much. |
| 17:36 | <TabAtkins> | The important thing is that I think ?test and ?test= are indistinguishable on the server side. |
| 17:37 | <TabAtkins> | So probably ?test should have u.get('text') === '' |
| 17:37 | <GPHemsley> | TabAtkins: Oh, so are you saying taht .has('test') returns false for ?, but true for ?test and ?test= ? |
| 17:37 | <GPHemsley> | (ack, so many question marks) |
| 17:38 | <TabAtkins> | Yes, of course. |
| 17:38 | <JonathanNeal> | Or you could create a new element, like <context> |
| 17:38 | <TabAtkins> | JonathanNeal: We could, but what's the value in that over reusing the existing <menu>? |
| 17:38 | <GPHemsley> | TabAtkins: OK, then I take back my objection. |
| 17:39 | <JonathanNeal> | TabAtkins: backwards compatibility |
| 17:39 | <TabAtkins> | JonathanNeal: Elaborate? |
| 17:39 | <TabAtkins> | (Note that <menu> does literally nothing in old UAs. It was just another type of list.) |
| 17:41 | <JonathanNeal> | Well, a lot of folks have used <menu> to differentiate menus from content lists. Disqus, for example, does this. My own company, Liferay, does this as well. It's deployed this way on a lot of sites. |
| 17:42 | <TabAtkins> | JonathanNeal: And as long as you didn't put type=context on those elements, you'll be fine. |
| 17:42 | <TabAtkins> | <menu> by itself still acts in the legacy fashion. |
| 17:43 | <JonathanNeal> | That's a confusing spec for an element. To declare that an element is deprecated, except when a certain attribute is applied. |
| 17:43 | <TabAtkins> | I assume it's undeprecating. |
| 17:44 | <smaug____> | how is <menu> deprecated ? |
| 17:45 | <smaug____> | I see 'compact' attribute in <menu> is obsolete |
| 17:45 | <JonathanNeal> | Would <menu>, by itself, be valid? |
| 17:45 | <smaug____> | why not? |
| 17:45 | <TabAtkins> | Yes, as it defaults to type='list', which is a newly added and valid type. |
| 17:46 | <GPHemsley> | For those wondering about my mailman feature request: http://mail.python.org/pipermail/mailman-developers/2012-November/022500.html |
| 17:46 | <GPHemsley> | and http://mail.python.org/pipermail/mailman-developers/2012-November/022501.html |
| 17:47 | <JonathanNeal> | I must have read too much into "I don't see too good reasons for other menu types" |
| 17:47 | <TabAtkins> | There isn't a very good reason for plain menus, except for back-compat. |
| 17:49 | <JonathanNeal> | By plain menus do you mean type list? |
| 17:51 | <TabAtkins> | Yeah. |
| 17:55 | <JonathanNeal> | Do you see any good reason for a menu that isn't context? |
| 17:56 | <TabAtkins> | Possibly - like I said, a pop-up button menu might be useful. |
| 18:28 | <Hixie> | smaug____: most of hte proposals in my mail on this recently suggested dropping the toolbar feature of <menu>, i agree we should just let CSS handle that |
| 18:29 | <Hixie> | smaug____: (basically rename type=list to type=toolbar, but leave the legacy processing intact) |
| 18:29 | <annevk5> | I would be interested in transitioning the wiki content to CC0 |
| 18:30 | <annevk5> | Is there a way we can enforce it for new pages and moves pages towards it once all contributors agree? |
| 18:30 | <GPHemsley> | I'm not sure... |
| 18:31 | <GPHemsley> | I recall Wikipedia having a heck of a time trying to transition away from GFDL. |
| 18:31 | <GPHemsley> | I think pages are still dual-licensed. |
| 18:31 | <TabAtkins> | The transition part is hard. The enforcing part is easy. |
| 18:33 | <annevk5> | We don't have to transition everything. Just new stuff would be a win. |
| 18:37 | <Ms2ger> | GPHemsley, that was easy, actually... They just got the GFDL include an escape clause for them :) |
| 18:37 | GPHemsley | wonders why no one has responded to his message about sniffing archive types |
| 18:38 | <annevk5> | Read up on Warnock ;) |
| 18:39 | <GPHemsley> | Ah, interesting. |
| 18:39 | <GPHemsley> | I'm gonna assume (1). |
| 19:27 | <smaug____> | Hixie: ping |
| 19:29 | <smaug____> | Hixie: what do you mean with menu buttons exactly? Would that be effectively left-click opening a menu (on top of the viewport, not part of the viewport) ? |
| 19:30 | <TabAtkins> | smaug____: I think so, yeah. I assume the intention is to allow standard app alt-menus as multiple <menu type=button>. |
| 19:33 | GPHemsley | wonders why people reply to posts without having read the rest of the thread. |
| 19:37 | <jwalden> | GPHemsley: I didn't read the conversation leading up to this, but surely it's obvious that people want to say their thing without doing the homework |
| 19:49 | <GPHemsley> | jwalden: Yeah, I suppose it was a bit of a rhetorical question. |
| 19:50 | <jwalden> | hmm, was I really too subtle with my irony there? :-\ |
| 19:50 | <jwalden> | ;-) |
| 19:53 | <GPHemsley> | jwalden: Oh, sneaky. Went right over my head. |
| 20:01 | <Hixie> | smaug____: Like, in GMail, the "Mail v" button under the Google logo |
| 20:01 | <Hixie> | smaug____: or the "More..." button above the messages, or even the checkbox button over on the left above the messages, though that one wouldn't be supported by what I'm proposing |
| 20:02 | <smaug____> | uh, you're forcing me to log in to google |
| 20:02 | <smaug____> | :) |
| 20:02 | <smaug____> | maybe I won't die if I do that |
| 20:02 | <Hixie> | -_- :-P |
| 20:02 | <Hixie> | most sites have something like this |
| 20:02 | <Hixie> | what site would you prefer :-) |
| 20:03 | <Hixie> | Twitter: |
| 20:03 | <Hixie> | the cog in the toolbar |
| 20:03 | <smaug____> | Hixie: ah, but that is in the page |
| 20:03 | <smaug____> | that menu |
| 20:03 | <smaug____> | not something like <select> |
| 20:03 | <Hixie> | ok? |
| 20:04 | <smaug____> | I was just thinking the type="button" proposal was about having something similar to <select> |
| 20:05 | <Hixie> | "similar" in what sense? i mean, those buttons are "similar" in some sense, and unrelated in another... |
| 20:05 | <Hixie> | <select> is about selecting an option, it's the equivalent of a series of radio buttons |
| 20:05 | <smaug____> | well, Gmail shows some stuff in the page |
| 20:05 | <Hixie> | <menu> is about selecting a command |
| 20:05 | <smaug____> | nothing pops up from the viewport |
| 20:05 | <smaug____> | I'm talking about the UI part |
| 20:05 | <Hixie> | oh well the exact UI is a separate issue. I think if GMail could get the popup to be a real popup then they would |
| 20:06 | <Hixie> | i mean, if you push the button when it's at the bottom of the window, you'd expect it to go over the bottom of the window |
| 20:06 | <Hixie> | just like a native menu button |
| 20:06 | <Hixie> | you on mac, linux, windows? |
| 20:06 | <smaug____> | linux |
| 20:06 | <Hixie> | gtk? |
| 20:06 | <Hixie> | as in, gnome? |
| 20:06 | <smaug____> | yup |
| 20:06 | <smaug____> | yup |
| 20:07 | <smaug____> | so type="button" would be something close to back button in FF |
| 20:07 | <smaug____> | except that back button requires one to press the button for some time |
| 20:08 | <Hixie> | yeah, similar to that |
| 20:08 | <Hixie> | basically it's like a context menu but it's anchored to a particular position and appears when you activate another control, rather than right clicking |
| 20:08 | <smaug____> | do we need to button part |
| 20:08 | <smaug____> | or could it be like contextmenu |
| 20:09 | <Hixie> | we could maybe have an attribute on <button> that turns <button> into a menu button, or some such |
| 20:09 | <Hixie> | hadn't really thought about that |
| 20:09 | <Hixie> | (and points to a <menu>) |
| 20:09 | <smaug____> | where say in <div menu="foobar">click me</div> <menu type="dropdown" id="foobar">... |
| 20:10 | <Hixie> | aha, here we go. the "Display your bookmarks" button in Firefox's toolbar. That's what I mean. |
| 20:10 | <Hixie> | smaug____: yeah, though hopefully not <div> |
| 20:10 | <smaug____> | why not in all the elements? |
| 20:10 | <smaug____> | why limit to certain elements? |
| 20:11 | <Hixie> | why all elements? |
| 20:11 | <Hixie> | that'd be... weird |
| 20:11 | <Hixie> | what would it mean for a radio button to have one of these? |
| 20:11 | <Hixie> | or a <select>? |
| 20:11 | <smaug____> | how is that different to contextmenu ? |
| 20:15 | <smaug____> | radio button could have one. It might just not make much sense. But it would be up to the web application |
| 20:18 | <smaug____> | so in XUL there is popup and context attributes |
| 20:25 | <Hixie> | smaug____: context menu is triggered by a different UI than the UI that interacts with the control |
| 20:25 | <Hixie> | smaug____: in general i'm not a fan of making things that don't make sense be possible, because web authors will always do it |
| 20:27 | <smaug____> | don't understand "context menu is triggered by a different UI than the UI that interacts with the control" |
| 20:27 | <Hixie> | context menu is triggered by right click, typically |
| 20:27 | <Hixie> | radio button is selected by left click |
| 20:27 | <smaug____> | (but in general I agree with not-making-silly-things-possible) |
| 20:28 | <Hixie> | menu buttons are triggered by left click -- it's their action, just like checking the radio button is the action of a radio button |
| 20:29 | <smaug____> | sure |
| 20:29 | <Hixie> | why did twitter shrink my url by two characters? the tweet fit in 140 characters already. wtf twitter. |
| 20:29 | <Hixie> | their url is unreadable. |
| 20:30 | <Velmont> | I hate that. identi.ca always did that correctly. |
| 20:32 | <smaug____> | Hixie: I'm just a bit worried that if menu is for buttons only, pages will have hard time to use it |
| 20:33 | <Hixie> | can you elaborate? |
| 20:33 | <smaug____> | I can imagine some <canvas> app which wants to show menu when clicking the <canvas> |
| 20:33 | <smaug____> | not very differently contextmenu would be supported |
| 20:33 | <Hixie> | well you can already bind a part of a canvas to a control |
| 20:34 | <Hixie> | we would just extend that to support binding canvas hit regions to menu buttons |
| 20:34 | <Hixie> | s/would/could/ |
| 20:35 | <smaug____> | well, same thing with even div |
| 20:35 | <smaug____> | there could be a menu for translation for example |
| 20:35 | <smaug____> | click the text and you get list of languages |
| 20:35 | <jochen__> | does somebody know why MediaQueryList defines this MediaQueryListListener interface, instead of just defining an onchanged event? |
| 20:36 | <Hixie> | smaug____: google translate does something like that. I would expect each of those to just be a styled menu button, not a div or span. |
| 20:36 | <smaug____> | but you limit the UI then |
| 20:36 | <smaug____> | one would need to click the button |
| 20:36 | <smaug____> | not just the text |
| 20:37 | <Hixie> | what's the difference? |
| 20:38 | <smaug____> | you need to have some hidden button above the text |
| 20:38 | <Hixie> | no just put the text in the button |
| 20:38 | <smaug____> | or have the text inside the button |
| 20:38 | <smaug____> | which prevents selecting |
| 20:38 | <Hixie> | http://translate.google.com/#auto/fr/seems%20to%20me%20the%20yellow%20boxes%20are%20in%20fact%20buttons |
| 20:39 | <TabAtkins> | ??? |
| 20:39 | <Hixie> | looks like actually in that case it's not a menu button |
| 20:39 | <smaug____> | Hixie: yes. I don't think all those yellow things should be buttons |
| 20:39 | <Hixie> | it's more that you can click to turn the spans into text edit boxes with a list="" autocomplete menu |
| 20:40 | <TabAtkins> | Oh, yellow boxes. I see. |
| 20:40 | <Hixie> | do you have an example of what you mean then? i can't think of any other site that does something like that |
| 20:40 | <Hixie> | in other news, my mail server is being a bitch today. |
| 20:41 | <smaug____> | that google translate is a good example |
| 20:41 | <smaug____> | those yellow things are spans |
| 20:41 | <Hixie> | yeah but there's no menu there it turns out |
| 20:41 | <Hixie> | so it's not a good example |
| 20:42 | <Hixie> | when you click, they turn into the equivalent of <input type=text list="suggestions"> |
| 20:42 | <Hixie> | (though in practice they actually use contenteditable currently) |
| 20:44 | <smaug____> | Hixie: another question. How the contents of <menu type="button"> would be handled? |
| 20:44 | <Hixie> | that's the question, indeed |
| 20:45 | <Hixie> | my e-mail had some strawman proposals |
| 20:45 | <Hixie> | i'm not married to any of them |
| 20:46 | <smaug____> | hmm, which email |
| 20:46 | <smaug____> | I must be reading some wrong one :) |
| 20:46 | <Hixie> | the one you replied to saying you liked #3 :-) |
| 20:48 | <smaug____> | "The <menu> element in "context" and "button" modes would only have three elements as descendants" |
| 20:49 | <smaug____> | Is that the proposal? |
| 20:49 | <smaug____> | how would the button menu look like? |
| 20:49 | <smaug____> | well, the button which triggers the menu |
| 20:50 | <smaug____> | <button popup="id_if_some_menu">foobar</button> would ofc solve this problem |
| 20:50 | <smaug____> | but doesn't feel right |
| 20:51 | <Hixie> | in the e-mail, the suggestion is that the <menu> itself would be the element that's the button, but using <button> seems fine to me too |
| 20:51 | <Hixie> | i don't have a preference one way or the other |
| 20:51 | <Hixie> | and haven't studied the latter idea in depth yet |
| 20:51 | <Hixie> | there are various things we could do, e.g. <button type=menu> Label <menu> ... </menu> </button> |
| 20:52 | <Hixie> | or <button type=button menu=mid> Label </button> <menu id=mid hidden> ... </menu> (and drop the <menu type=""> attribute altogether) |
| 20:53 | <Hixie> | or <menubutton popup=mid> instead of using <button> |
| 20:53 | <Hixie> | or <input type=menu> |
| 20:54 | <TabAtkins> | I'm actually not sure how <menu> being the button would work. Would you use the text not in <menuitem> as the button text? |
| 20:54 | <Hixie> | text would come from label="" |
| 20:54 | <TabAtkins> | Oh, okay. |
| 20:54 | <Hixie> | contents would be unrendered |
| 20:54 | <Hixie> | (not sure i like this) |
| 20:54 | <Hixie> | (in fact, pretty sure i don't) |
| 20:54 | <Hixie> | (i just hadn't really thought about it one way or the other -- my e-mail was really more intended to get feedback from implementors about what they'd be willing to do) |
| 20:55 | <smaug____> | for now <button type="menu"> might be enough |
| 20:55 | <smaug____> | er |
| 20:55 | <smaug____> | no |
| 20:55 | <smaug____> | <button type="button" menu="mid"> |
| 20:55 | <smaug____> | that one |
| 20:56 | <smaug____> | if generic menu handling is needed, that could be added later |
| 20:56 | <smaug____> | to other elements |
| 20:56 | <Hixie> | the gmail checkbox thing could actually work like this: <button type=menu menu=mid> <input type=checkbox> Open Menu </button> <menu id=mid> <menuitem ...> <menuitem ...> <menuitem ...> </menu> |
| 20:57 | <Hixie> | yeah |
| 20:57 | <Hixie> | that seems pretty solid |
| 20:57 | <Hixie> | (what smaug____ said, not what i said) |
| 20:57 | <Hixie> | actually if we only allow <menu> and <menuitem> in <menu>, you wouldn't even need <menu hidden> or <menu type> to hide the menu contents |
| 20:57 | <Hixie> | since they'd be invisible |
| 20:57 | <Hixie> | they'd have to only be at flow level, since they'd introduce a line break |
| 20:58 | <TabAtkins> | I... did not know you could put checkboxes inside of buttons. |
| 20:58 | <Hixie> | in the default rendering |
| 20:58 | <Hixie> | TabAtkins: per spec you can't, but browsers are surprisingly flexible with contents of <button> |
| 20:58 | <Hixie> | and parser doesn't care |
| 20:58 | <Hixie> | gotta go, meeting, bbiab |
| 20:58 | a-ja | arrived mid-conversation.....what's menu=mid proposal? |
| 20:58 | <smaug____> | TabAtkins: but the checkboxes won't actually work in button |
| 20:59 | <TabAtkins> | smaug____: They sure do in Chrome. |
| 20:59 | <smaug____> | at least not in most implementations |
| 20:59 | <smaug____> | TabAtkins: I believe that is a bug in webkit |
| 21:00 | <TabAtkins> | a-ja: Read the WHATWG thread about <menu> - menu=foo is one possible way to do Hixie's "menu opened from a button" idea. |
| 21:01 | <a-ja> | n/m....hixie's 14:57:25 comment answered my question |
| 21:01 | <TabAtkins> | smaug____: Ooh, and you can even, as normal, stop the click from propagating up to the button. |
| 21:02 | <TabAtkins> | I find this functionality interesting. |
| 21:02 | <smaug____> | Gecko explicitly prevents that |
| 21:02 | <smaug____> | the contents of <button> are there just for presentation |
| 21:03 | <smaug____> | events go to <button> |
| 21:03 | <smaug____> | because that is how at least some old spec said it should work |
| 21:57 | <dglazkov> | w3.org is down. Finally, someone put kibosh on this whole world wide web thing. |
| 21:57 | <Hixie> | smaug____: we can probably change that, though |
| 21:57 | <smaug____> | Hixie: change what? |
| 21:58 | <smaug____> | handling the contents of <button> ? |
| 21:58 | <Hixie> | yeah |
| 21:58 | <Hixie> | TabAtkins: any idea what this guy means? https://twitter.com/briankardell/status/274252456655978497 |
| 21:58 | <smaug____> | not sure which behavior I prefer |
| 21:58 | <smaug____> | probably Gecko's |
| 21:58 | <smaug____> | Gecko + Opera |
| 21:59 | <smaug____> | IE seems to have odd behavior |
| 21:59 | <TabAtkins> | Hixie: Since I can't see anything on w3.org right now, no. |
| 21:59 | <TabAtkins> | I think he's just agreeing with you. |
| 22:01 | <Hixie> | TabAtkins: not sure what he meant by the star and microformats |
| 22:01 | <TabAtkins> | I think he's confusing microformats/microdata. No clue what the gold star thing is about. |
| 22:02 | <Hixie> | k |
| 22:03 | <scor> | dglazkov: there seems to be a power outage here in cambridge, possibly related |
| 22:03 | <TabAtkins> | scor: Yes, w3.org is down because of MIT losing power. |
| 22:03 | <TabAtkins> | scor: Twitter confirms from multiple people. |
| 22:04 | scor | wonders how he'll get home |
| 22:04 | <TabAtkins> | scor: You need electrical power to get home? |
| 22:05 | <scor> | TabAtkins: I could walk, but usally take the subway |
| 22:05 | <scor> | which is down too |
| 22:05 | <tantek> | wait, what about all those TR pages we depend on to get our work done? |
| 22:05 | <TabAtkins> | Ah, kk. |
| 22:05 | <TabAtkins> | tantek: GUESS YOU'LL HAVE TO GO WITHOUT. |
| 22:05 | <tantek> | is there a mirror on github? |
| 22:06 | <Velmont> | Of some stuff :-) |
| 22:27 | <annevk> | tantek: http://spec.whatwg.org/ is the new /TR/ but without the lack of updated content |
| 22:30 | <annevk> | Hixie: that guy has some interesting ramblings on his site http://briankardell.wordpress.com/2012/06/14/the-blind-architect/ |
| 22:30 | <annevk> | Hixie: also "Tim Berners-Lee Needs Revision" |
| 22:31 | <annevk> | miketaylr: "Whitespace strategist at Opera Software." so you're responsible for it being different in every standard! :-) |
| 22:32 | <miketaylr> | TODO: fix whitespace |
| 22:53 | <annevk> | TabAtkins: btw, I updated http://url.spec.whatwg.org/#interface-urlquery |
| 22:53 | <annevk> | TabAtkins: basically whenever you do a modifying operation, such as delete/append/set, "update steps" are invoked is the plan |
| 22:54 | <annevk> | TabAtkins: I guess I'll add has too, although I think for ?test / ?test= we want to return the empty string in both cases |
| 22:54 | <annevk> | TabAtkins: makes more sense to align with getAttribute for missing altogether (and return null there) |
| 22:58 | <Hixie> | abarth: in http://wiki.whatwg.org/wiki/AllowSeamless you mention "using Frame-Options or ancestor-origins" as ways to do origin-whitelisting |
| 22:58 | <Hixie> | abarth: are these at pre-parse (HTTP header) time? Can you elaborate on these? |
| 22:59 | <Hixie> | (my guess is by Frame-Options you mean X-Frame-Options, but that seems to not have a whitelist, and that by ancestor-origins you mean ancestorOrigins but that is post-parse) |
| 23:00 | <TabAtkins> | annevk: Yes, there was discussion while you were out of the room. ?test and ?test= should both have the empty string, since they're indistinguishable on the server-side. |
| 23:01 | <Hixie> | how are they indistinguishable? |
| 23:01 | <Hixie> | <input name=isindex value="test"> and <input name=isindex value="test="> should result in different pages being served |
| 23:01 | <TabAtkins> | Hixie: In PHP, for example, you'll just get $_GET['test'] == '' |
| 23:01 | <Hixie> | oh well if you're using a library that sucks, sure |
| 23:01 | <TabAtkins> | I have no clue what isindex does. |
| 23:02 | <TabAtkins> | That's most query param handling. ^_^ |
| 23:02 | <annevk> | Hixie: if you include the = in the value it will be percent-encoded so that's different |
| 23:02 | <SamB> | Lots of things can see the whole query string |
| 23:02 | <Hixie> | TabAtkins: you said "indistinguishable", not "ignored" |
| 23:02 | <Hixie> | or "Treated as the same by some libraries" |
| 23:02 | <TabAtkins> | Hixie, I have no idea what you're saying, but think you've confused param names for param values. |
| 23:03 | <annevk> | Hixie: I guess the question here is whether application/x-www-form-urlencoded allows values that are either null or the empty string; I guess it does |
| 23:03 | <Hixie> | isindex doesn't have names of values |
| 23:03 | <Hixie> | annevk: all i'm saying is ?foo and ?foo= are distinguishible on the server, i've no idea what this means for your spec :-) |
| 23:03 | <TabAtkins> | Then what annevk said is right - in your example, the = is part of the param name and will be percent-encoded. |
| 23:04 | <gavinc> | ... isindex is a name? I thought it was an element... |
| 23:04 | <annevk> | Hixie: ah, no disagreement there |
| 23:04 | <annevk> | gavinc: it's a macro in the parser |
| 23:04 | <TabAtkins> | gavinc: You're getting confused, but don't worry, because noone cares about isindex. ^_^ |
| 23:05 | <Hixie> | TabAtkins: yeah using isindex was poor choice on my part |
| 23:05 | <Hixie> | my point still holds though |
| 23:05 | <Hixie> | http://software.hixie.ch/utilities/cgi/test-tools/echo?test= and http://software.hixie.ch/utilities/cgi/test-tools/echo?test aren't the same |
| 23:06 | <annevk> | Hixie: yeah, but per application/x-www-form-urlencoded they are (at least per your spec for it) |
| 23:06 | <annevk> | Hixie: and application/x-www-form-urlencoded is the API we're gonna provide for .query |
| 23:06 | <annevk> | Hixie: if you want something more complicated, you can build your own API on top of .search (which is the raw data); that's the gist of the plan |
| 23:07 | <Hixie> | ah yeah, that's fine |
| 23:07 | <Hixie> | semantically i agree that ?test and ?test= should be treated the same |
| 23:08 | <annevk> | good good, then we were just miscommunicating |
| 23:10 | <annevk> | Hixie: Frame-Options is an HTTP header which provides embedding prevention |
| 23:10 | <gavinc> | ahh! isindex was an element as is now a name and was a name too, learning every day |
| 23:10 | gavinc | fears isindex |
| 23:11 | <annevk> | Hixie: I'm guessing ancestor-origins is a CSP thing that does something similar, but not sure about that |
| 23:11 | <Hixie> | aah, could be CSP... |
| 23:12 | <annevk> | maybe the new name for frame-ancestors |
| 23:12 | <annevk> | if there's something I fear, it's CSP |
| 23:12 | <annevk> | sooo complex |
| 23:13 | <annevk> | gavinc: use http://software.hixie.ch/utilities/js/live-dom-viewer/ and understand <isindex>; better than fearing it |
| 23:14 | <annevk> | gavinc: while you're there you might want to try <image> and </br>, and maybe for extra fun a lone </p> |
| 23:14 | <Hixie> | isindex is reasonably straightforward and trivial to search for in the html spec |
| 23:14 | <gavinc> | annevk: those others I've come to terms with ;) <isindex>... |
| 23:16 | <Hixie> | anyone got a copy of hte csp spec i can use? |
| 23:17 | <annevk> | csp.spec... oh wait |
| 23:17 | <Hixie> | google has a cache of an old version |
| 23:17 | <TabAtkins> | annevk: Seems inconsistent that set() can take an array, but append() can't. |
| 23:17 | <Hixie> | i'll use that for now |
| 23:18 | <annevk> | Hixie: http://webcache.googleusercontent.com/search?q=cache:UUvG4IpmatkJ:www.w3.org/TR/2012/CR-CSP-20121115/+&cd=4&hl=en&ct=clnk |
| 23:18 | <annevk> | ah |
| 23:18 | <TabAtkins> | And unfortunately, set() taking an array violates the Map API. |
| 23:19 | <Hixie> | ok the old version of CSP isn't good enough for what i want |
| 23:19 | <annevk> | my idea was that append is just for adding a new pair, and set was for overwriting a bunch of stuff |
| 23:20 | <TabAtkins> | Actually, hm. I'd probably assume that a MultiMap would allow an array to be passed. |
| 23:20 | <TabAtkins> | (Meaning that if you wanted to store an array itself as a value, you'd have to wrap it in an array.) |
| 23:20 | <annevk> | the shitty thing is that we don't know what MultiMap will look like |
| 23:20 | <TabAtkins> | Yeah, I'm guessing at what a good API woudl be. |
| 23:20 | <annevk> | and also, this is a multimap, but we want to optimize for map usage |
| 23:20 | <TabAtkins> | While trying not to make it too inconvenient for a pure string->string map API. |
| 23:22 | <TabAtkins> | (Or string->[string], I guess.) |
| 23:23 | <annevk> | it's really [(string,string)] |
| 23:23 | <Hixie> | ok based on what i can read about 1.1, it doesn't do what i want either |
| 23:23 | <Hixie> | hmmmm |
| 23:23 | <TabAtkins> | annevk: Other multimap apis seem to have both a .set and .setAll. |
| 23:24 | <annevk> | Hixie: just postpone until Adam is around |
| 23:24 | <annevk> | TabAtkins: that sounds interesting |
| 23:24 | <annevk> | TabAtkins: we already have getAll |
| 23:24 | <TabAtkins> | Basically just *All variants of every method. |
| 23:24 | <annevk> | TabAtkins: is there documentation on how they operate? |
| 23:24 | <TabAtkins> | So I guess delete can change from being {1,2} arg to being two-arg, with a 1-arg deleteAll. |
| 23:24 | <TabAtkins> | http://google-collections.googlecode.com/svn/trunk/javadoc/com/google/common/collect/Multimap.html |
| 23:25 | <annevk> | I think remove we should just do with an optional arg |
| 23:25 | <annevk> | like it's now |
| 23:26 | <TabAtkins> | That's likely fine. |
| 23:26 | <TabAtkins> | Hm, I can't parse what the hell this Scala documentation is trying to tell me about its multimap class. |
| 23:26 | <annevk> | yeah me neither |
| 23:27 | <annevk> | the putAll method there seems like append() |
| 23:27 | <TabAtkins> | Oh, looks like Scala just doesn't treat it like a normal map at all. |
| 23:27 | <TabAtkins> | It does everything in terms of the value being a Set. |
| 23:28 | <annevk> | the underlying model is Collection<Map.Entry<K,V>> |
| 23:28 | <annevk> | aaah |
| 23:29 | <annevk> | what I call set, they call replaceValues |
| 23:29 | <TabAtkins> | But yeah, the Java class from Apache does the same thing, with both put() and putAll(). |
| 23:29 | <annevk> | but they don't have documentation for replaceValues |
| 23:29 | <annevk> | or at least not documentation in detail |
| 23:29 | <annevk> | who write this stuff? |
| 23:29 | <annevk> | writes* |
| 23:29 | <TabAtkins> | A machine, most likely. |
| 23:30 | <annevk> | oh, it says "Jared Levy" |
| 23:30 | <TabAtkins> | Wait,w hat page are you looking at? |
| 23:30 | <annevk> | the one you linked? |
| 23:30 | <TabAtkins> | Oh, the google one. |
| 23:31 | <annevk> | oh this is fun, but I should get some sleep |
| 23:31 | <TabAtkins> | annevk: Should I file a bug? |
| 23:31 | <annevk> | if you figure out an API, let me know, otherwise I'll struggle on with the algorithms that are required either way |
| 23:31 | <TabAtkins> | Assuming w3.org is up before I leave? |
| 23:31 | <annevk> | TabAtkins: bug/email/rants on IRC all work |
| 23:36 | <TabAtkins> | annevk: Okay, got it worked out with one question. I think this is reasonable for a generic MultiMap, *and* is compatible with treating it as a Map. |
| 23:37 | <TabAtkins> | get(k), getAll(k), set(k,v), append(k,v), appendAll(k,[v]), delete(k, v?), has(k) |
| 23:37 | <TabAtkins> | Only question is whether you want a setAll(k,[v]) or not. You can just do .delete(k); .appendAll(k,[v]) instead. |
| 23:38 | <annevk> | set overwrites the first key/value pair; if no key is found, appends? |
| 23:39 | <TabAtkins> | Yes. |
| 23:39 | <annevk> | append/appendAll can be merged by doing append(k, (v or [v])) |
| 23:39 | <TabAtkins> | In other words, set is *always* equivalent to just doing a full delete, followed by an append. |
| 23:39 | <TabAtkins> | annevk: That only works in your string-limited case. It doesn't work for a general MultiMap. |
| 23:39 | <annevk> | equivalent, but not identical because of the underlying data model |
| 23:40 | <TabAtkins> | Oh, you're right, I forgot about the data model. In that case, yes, your formulation is great. |
| 23:40 | <TabAtkins> | In that case, you probably want a setAll(). |
| 23:40 | <annevk> | I was thinking of maybe not having setAll/appendAll for now |
| 23:40 | <TabAtkins> | That's fine too. |
| 23:40 | <annevk> | as they can be implemented and we expect the common case to be get/set |
| 23:40 | <annevk> | so just keep it very basic for now, and expand later |
| 23:41 | <annevk> | thanks, will update stuff tomorrow |
| 23:41 | <TabAtkins> | getAll() and delete() with an optional arg seem like *clearly* the right answer for a generic multimap, so shouldn't be controversial. |
| 23:41 | <TabAtkins> | Also .append() as a single k/v addition. |
| 23:41 | <annevk> | yeah |
| 23:41 | <annevk> | those we should keep |
| 23:42 | annevk | likes design time in #whatwg |
| 23:42 | <annevk> | really nn now :) |
| 23:42 | <Hixie> | nn |
| 23:55 | <Hixie> | how does caniuse not have <style scoped> |