| 01:25 | <dlongley> | TabAtkins: throwing and calling reject aren't exactly the same -- particularly not in that scenario |
| 01:25 | <dlongley> | the error happens at a different time |
| 01:28 | <dlongley> | the difference is in whether or not the future is actually invoked (via then/done) |
| 01:29 | <dlongley> | try { var future = foo(); } catch(ex) {} |
| 01:29 | <dlongley> | vs. |
| 01:29 | <dlongley> | try {var future = foo(); future.then(a, b);} catch(ex) {} |
| 01:29 | <dlongley> | the idl test harness is looking for the future to happen when foo() is called, not when .then() is called. |
| 01:29 | <dlongley> | (via the rejection callback passed to .then) |
| 01:30 | <dlongley> | s/for the future/for the error |
| 04:01 | <tantek> | TabAtkins, added stub spec for registry entry for rel=discussion: http://microformats.org/wiki/existing-rel-values#HTML5_link_type_extensions |
| 04:41 | <rcombs> | where do I go to find out whether or not JS's handling of Unicode is going to get better? |
| 04:42 | <rcombs> | also, regexes |
| 04:43 | <rcombs> | also, proper Unicode handling _in_ regexes |
| 07:31 | <zcorpan> | should specs reference CSS specs on dvcs.w3.org or dev.w3.org? |
| 09:06 | <Ms2ger> | zcorpan, dev. |
| 09:07 | <zcorpan> | Ms2ger: ok. do you know why? |
| 09:08 | <Ms2ger> | I don't remember |
| 09:08 | <jgraham> | Everyone loves CVS? |
| 09:09 | <Ms2ger> | dev. just mirrors dvcs. for CSS, fwiw |
| 09:21 | <annevk> | TabAtkins: you could just make it conditional on the URL having a path in the first place |
| 09:21 | <annevk> | TabAtkins: data URLs for instance will only have "scheme data" |
| 09:22 | <annevk> | TabAtkins: so either the first n segments match, or they don't, or there are no segments to begin with |
| 09:24 | <annevk> | TabAtkins: Hixie: also, on a more general point, URL hasn't received much review yet so I first want to know if all the concepts are correct before adding makeup and such |
| 10:31 | <annevk> | zcorpan: it seems you're no longer updating the xref database with CSSOM references? |
| 10:31 | <annevk> | zcorpan: for some reason the links to getClientRects() and such from DOM went dead :( |
| 10:32 | <zcorpan> | annevk: glenn forked it. i tried to switch back to xref but something didn't work right and then i gave up |
| 10:40 | <SimonSapin> | annevk: Is http://example.com/foo//bar the same URL as http://example.com/foo/bar ? |
| 10:40 | <annevk> | SimonSapin: no |
| 10:41 | <SimonSapin> | so servers that consider them the same decide that on their own |
| 10:41 | <SimonSapin> | if that makes sense |
| 10:42 | <gsnedders> | Right. A server could equally decide foobar and /fo/b/a/r are the same. :) |
| 10:42 | <jgraham> | Or foo/bar and foo/bar/ :) |
| 10:43 | <SimonSapin> | so, on my TODO list: detailed review of selectors4’s :local-link and :local-link(2) |
| 10:43 | <SimonSapin> | I think it’s doing weird normalization |
| 10:43 | <annevk> | SimonSapin: yeah, just like servers treating / and /index.html identically sometimes |
| 10:44 | <SimonSapin> | indeed, that too |
| 10:44 | <annevk> | SimonSapin: more happenstance than actual architecture |
| 10:44 | <annevk> | (well, it's related to the architecture of the server, but not that of URLs) |
| 10:45 | <gsnedders> | Or and /randomweirdindexpage |
| 10:45 | <SimonSapin> | /Overview.html ;) |
| 10:47 | <annevk> | I recommend making :local-link map directly to the working of URLs |
| 10:47 | <SimonSapin> | So if you’re on /foo#bar, clicking on href="/foo#baz" only scrolls, but href="/foo/#baz" triggers a navigation/page load, right? |
| 10:47 | <annevk> | and not any kind of server architecture |
| 10:47 | <gsnedders> | SimonSapin: Yes. |
| 10:47 | <SimonSapin> | annevk: agreed |
| 10:47 | <annevk> | basically you want to use a parsed URL's path array I reckon |
| 10:47 | <SimonSapin> | right now :local-link(1) matches both, but I think it should only match the former |
| 10:48 | <annevk> | what does 1 mean? |
| 10:48 | <SimonSapin> | means 1 leading path segments |
| 10:48 | <annevk> | so 0 would match data URLs and such? |
| 10:49 | <SimonSapin> | annevk: that’s what it does, but with additional steps like remove a trailing empty path segment, ie. a trailing slash |
| 10:49 | <annevk> | ooh |
| 10:49 | <annevk> | sounds more like :apache-local-link |
| 10:50 | <SimonSapin> | yeah, I’ll send a review on www-style |
| 10:50 | <SimonSapin> | I think a functional :local-link() never matches data: and such URLs |
| 10:50 | <SimonSapin> | (that’s why Tab was asking about relative schemes) |
| 10:52 | <annevk> | well every URL will have at least one path segment |
| 10:52 | <annevk> | except if it's a data URL and such |
| 10:52 | <annevk> | so your idea would be that :local-link(0) matches nothing? |
| 10:53 | <SimonSapin> | that’s what I’m reading in the draft |
| 10:53 | <SimonSapin> | not sure what it *should* do |
| 10:54 | <SimonSapin> | :local-link(0) basically means "same domain name". (Not sure if eg. the scheme should be considered or is in the draft) |
| 10:56 | <annevk> | it says to ignore scheme / username / password / port / query string / fragment |
| 10:56 | <SimonSapin> | not sure it should |
| 10:56 | <annevk> | that seems kinda flawed |
| 10:57 | <annevk> | I think we should define some kind of URL comparison API and CSS should hook into that |
| 10:57 | <annevk> | this kind of adhoc approach works, but is not great |
| 10:57 | <SimonSapin> | should it be considered "local" to go from HTTP to HTTPS on the same domain? |
| 10:58 | <SimonSapin> | yes, if Selectors can just refer to URL for this that would be great |
| 10:58 | <annevk> | well you'd still need to define some kind of CSS syntax |
| 10:58 | <SimonSapin> | sure |
| 10:58 | <SimonSapin> | for the comparison I mean |
| 10:59 | <SimonSapin> | I think Selectors 4 is doing ad-hoc comparison because there was not enough in URL to refer to |
| 10:59 | <annevk> | given that everything on the web is origin-scoped I don't think ignoring scheme/port is a good idea |
| 10:59 | <annevk> | treating origin as a single entity is a much better approach |
| 10:59 | <annevk> | yeah maybe |
| 11:00 | <annevk> | nobody emailed me their requirements for URL comparison though despite repeated requests :/ |
| 11:00 | <annevk> | okay, lets look around the web and see what people are doing |
| 11:02 | <SimonSapin> | So far WeasyPrint only needs to tell apart local/internal links from external ones |
| 11:03 | <SimonSapin> | with corner cases like href="#foo" without a base URL (eg. parsing an HTML string from memory) |
| 11:32 | <annevk> | SimonSapin: I emailed www-style/public-webapps with some thoughts |
| 12:22 | <zcorpan> | annevk: DOMStringList is to be replaced with DOMString[] still, right? What about StyleSheetList, CSSRuleList, MediaList? https://www.w3.org/Bugs/Public/show_bug.cgi?id=16111 |
| 12:41 | <annevk> | haven't really thought about that lately |
| 12:41 | <annevk> | we need some kind of generic list solution but we don't |
| 12:49 | <Ms2ger> | Maybe we should make annevk implement webidl arrays in Gecko... |
| 12:52 | <annevk> | Ms2ger: so I'm not sure IDL arrays are the right solution here |
| 12:55 | <annevk> | I'm not a big fan of IDL arrays. I think JavaScript basically needs some new Array types... |
| 13:11 | <annevk> | I'm hoping JSIDL will magically fix it |
| 13:12 | <Ms2ger> | Ehehehehe |
| 13:12 | <annevk> | I know I know |
| 13:13 | <Ms2ger> | I'll believe it when I see it |
| 13:30 | <annevk> | http://lists.w3.org/Archives/Public/www-style/2013Apr/0592.html my @opera.com email is still going strong it seems |
| 13:37 | <odinho> | ^_^ Good times |
| 13:38 | <annevk> | I reckon /dev/null always has good times |
| 13:39 | <SimonSapin> | annevk: still going strong as in you’re still getting mail addressed to it, or as in people are still using it? |
| 13:40 | <odinho> | SimonSapin: The /dev/null comment should indicate to you where those mails go ;-) |
| 13:40 | <odinho> | So I vote for #2 |
| 13:40 | <SimonSapin> | ok |
| 13:42 | <annevk> | http://five-gt-two.spreadshirt.com/ is still alive |
| 14:06 | <annevk> | I learned today that the W3C at one point considered RAND licensing: http://www.w3.org/TR/2001/WD-patent-policy-20010816/ (authors include Microsoft, HP, Philips, and Apple) |
| 14:07 | <annevk> | Glad that went nowehre |
| 14:07 | <annevk> | nowhere* |
| 14:08 | <tantek> | annevk - it used to be a per WG choice (RAND vs RF) |
| 14:09 | <tantek> | as in, defined in the WG charter |
| 14:09 | <annevk> | oh wow |
| 14:09 | <tantek> | was quite a fight to get RF across the org |
| 14:09 | <SimonSapin> | what are RAND and RF? |
| 14:10 | <Ms2ger> | "reasonable and non-discriminatory terms" for RAND |
| 14:10 | <Ms2ger> | royalty-free for rf |
| 14:10 | <Ms2ger> | Both licensing terms for patents |
| 14:13 | <jgraham> | That needs more scare quotes |
| 14:13 | <jgraham> | "reasonable" |
| 14:15 | <Ms2ger> | "'reasonable' 'and' 'non-discriminatory' 'terms'" |
| 14:15 | <Ms2ger> | More? :) |
| 14:16 | <marcosc> | :) |
| 16:06 | <cwilso__> | (man, the above convo on RAND/RF licensing suddenly made me feel very, very old) |
| 16:06 | <cwilso__> | annevk: yt? |
| 16:06 | <annevk> | cwilso__: yeah |
| 16:08 | <cwilso__> | I'm not trying to be obtuse on fingerprinting re: MIDI API; I don't understand how it enables reviving cookies any more than other available info |
| 16:09 | <cwilso__> | (Note that I was originally against having an ID, because you can't guarantee across sessions, necessarily) |
| 16:10 | <annevk> | so Gamepad only exposes the vendor string |
| 16:10 | <dglazkov> | good morning, Whatwg! |
| 16:10 | <annevk> | MediaStream seems to be doing something else |
| 16:10 | <annevk> | you guys are doing something else |
| 16:10 | <cwilso__> | um, Gamepad has a DOMString id. |
| 16:10 | <annevk> | and nobody seems to think it's a problem |
| 16:10 | <annevk> | cwilso__: did you read the description? |
| 16:10 | <annevk> | (which is way too vague, imo) |
| 16:10 | <cwilso__> | Sure - typically USB vendor and product id. |
| 16:11 | <cwilso__> | The point of the ID in MIDI is simply so you can find the same one next time. |
| 16:11 | <cwilso__> | E.g. in my prollyfill it just appends index, manufacturer and name (should really hash, left it for debugging) |
| 16:13 | <annevk> | oh you think it's not an actual string for Gamepad? hmm |
| 16:13 | <cwilso__> | I initially was against ID because I said you could look up from index, name and manufacturer. If there's significant risk added, I'd probably just drop ID again, because an ID that gets regenerated "randomly" is going to be confusing ("I cleared my cookies, so of course my sequencer forgot its config" is not going to occur to an end user) |
| 16:14 | <annevk> | what's index? |
| 16:14 | <cwilso__> | I don't know what Gamepad has in practice in implementations; the spec implies it's an identifier for THAT gamepad, and would persist - but you're completely right that it does not state uniqueness (e.g. if you have two of the same gamepad, are the IDs identical?) |
| 16:15 | <cwilso__> | index = position in the inputs or outputs list. like position in the getGamepads() []. |
| 16:15 | <annevk> | could that not change over time? |
| 16:17 | <annevk> | Anyway, if we're going to hook all these devices up that's great, but we should have a somewhat consistent story for them. |
| 16:17 | <cwilso__> | Yes, of course. If you unplugged a device, e.g.. There's no cross-OS unique identifier that's the same. CoreMIDI has persistent IDs, IIRC, and it turns out that the Windows MIDI HMIDI handles are persistent, but they're not the same, and I don't think there's a consistent ID coming straight from USB-MIDI. |
| 16:18 | <annevk> | cwilso__: so you wouldn't want to generate the ID based on index then |
| 16:18 | <cwilso__> | I'd +1 that. Gamepad pretty much just relies on index, really. |
| 16:18 | <cwilso__> | My initial take on Web MIDI was that it should, too, and could additionally look up based on product name. |
| 16:21 | <annevk> | Per your configuration example. It sounds like this is something that ought to be defined in detail. So you don't lock users to a single browser. |
| 16:22 | <annevk> | E.g. given some hardware, irrespective of the browser you'll get the same ID for it. |
| 16:22 | <cwilso__> | MediaStreams apparently generate a GUID; not clear how persistent it would be. |
| 16:23 | <cwilso__> | Well, yes - although if you move the hardware to a different machine you might not. |
| 16:23 | <annevk> | Yeah, web security seems like lalaland for most people... Push notification proposal does not even mention the word "origin". |
| 16:23 | <cwilso__> | I think OSX and Windows both keep track of devices they've seen before. |
| 16:23 | <cwilso__> | E.g. if you plug in A, B and C in that order... |
| 16:23 | <cwilso__> | then remove B |
| 16:24 | <Ms2ger> | Glenn Adams only came for the beer? |
| 16:24 | <cwilso__> | Obviously you'll get [A,C]. If you plug B back in, you'll get [A,B,C]. |
| 16:24 | <cwilso__> | If you'd never plugged B in at all, you'd get [A,C,B] |
| 16:25 | <annevk> | But is there some way to know that B is not A? Assuming neither has been plugged in and I plug in one at random? |
| 16:25 | <cwilso__> | I think this system would err on the side of messing up the config sometimes, actually. :) Or needing to re-lookup. |
| 16:26 | <cwilso__> | If they're all the same type of device (I mean, they're identical devices - the same make/model of keyboard, say), no, I don't think so, not across all systems anyway. |
| 16:27 | <cwilso__> | It's not really even a globally unique ID, just a "globally at this time" ID. |
| 16:28 | <cwilso__> | that's not a universal statement, you realize - you can figure out how to do that, by using the handles in Windows and the identifiers under the covers in OSX. |
| 16:28 | <Ms2ger> | Ooh, XHR/PE discussion |
| 16:29 | <cwilso__> | I presume it's based on the USB serial number (but that's not exposed, of course, as MIDI devices can be non-usb) |
| 16:29 | <annevk> | Ms2ger: hmm? |
| 16:29 | cwilso__ | back in 5, need coffee |
| 16:29 | <Ms2ger> | WebApps F2F |
| 16:30 | <annevk> | cwilso__: anyway, it'd be good if this was coordinated across everyone introducing access to devices |
| 16:30 | <annevk> | cwilso__: I guess I don't really have strong opinions on the specifics, other than that privacy/fingerprinting and whether any of it needs origin-scoping or not is looked into and is called out in some way in the specification |
| 16:30 | <annevk> | cwilso__: well, and if use cases like persisting a configuration survive, it would be great if we could make that cross-browser |
| 16:32 | Ms2ger | wonders where sicking got lost |
| 16:32 | <annevk> | Ms2ger: Present+ Ms2ger, really? :-) |
| 16:34 | <annevk> | Wait http://www.w3.org/2013/04/25-webapps-minutes.html nobody from Apple or Google? |
| 16:35 | <Ms2ger> | Some guy said he was from Google |
| 16:35 | hober | is here |
| 16:35 | annevk | is here |
| 16:36 | Ms2ger | is here |
| 16:36 | divya | is here |
| 16:36 | cwilso__ | is back |
| 16:36 | <hober> | (i meant, i'm at the webapps f2f, though I'm not listed. grr) |
| 16:36 | <annevk> | Is this our "I'm Spartacus!"? |
| 16:36 | <annevk> | aw, cwilso__ did a combo-breaker |
| 16:37 | <annevk> | hober: but you're at every standards meeting :p |
| 16:37 | <Ms2ger> | hober, good way to avoid actual work? :) |
| 16:38 | <cwilso__> | C-C-C-C-C-C-COMBO BREAKER!! |
| 16:39 | <cwilso__> | annevk: yeah. The privacy/fingerprinting stuff is gone into in some detail in Web MIDI, but could certainly be expanded. Keeping sync of config across engines is a goal, although hard; will help when another engine gets interested enough to discuss implementation concerns. :) |
| 16:40 | <Ms2ger> | Sounds like the Google-Mozilla bus arrived |
| 16:41 | <cwilso__> | Except that I'm 697miles from the main campus (until June), yeah. :) |
| 16:41 | <Ms2ger> | sicking, tut tut, you should be on time |
| 16:42 | <hober> | annevk: not at all of them, fortunately, but yeah, most of them |
| 16:43 | <cwilso__> | ms2ger: oh, duh, you mean at the ftf |
| 16:43 | <Ms2ger> | Yeah |
| 16:53 | <TabAtkins> | SimonSapin: In :local-link, we only normalize by dropping the hash. In :local-link(n), we normalize by dropping the scheme, hash, query, and userdata, and if the final path segment is empty, drop it too. |
| 16:53 | <TabAtkins> | (So "example.com" and "example.com/"; are the same.) |
| 16:53 | <TabAtkins> | That last one is technically not valid, but in practive it's fine, and I think if we didn't do it, it would make the feature much less useful. |
| 16:54 | <TabAtkins> | annevk: Yes, we want to make :local-link work on URLs. It can't rely on server structure anyway. ^_^ |
| 16:55 | <annevk> | example.org already has / via the parser |
| 16:55 | <TabAtkins> | annevk: :local-link(n) never matches "opaque" urls, like data:. :local-link(0) matches when the domains match, :local-link(1) matches when the domains and first path segment match, etc. |
| 16:55 | <annevk> | the problem is treating example.org/foo and example.org/foo/ the same |
| 16:55 | <TabAtkins> | annevk: If you defined a URL comparison API, we'd gladly hook it. |
| 16:56 | <annevk> | see my email |
| 16:56 | <annevk> | I was wondering why you were doing certain things, seems one part of it was a misunderstanding |
| 16:57 | <annevk> | dropping scheme/port also seems wrong |
| 16:58 | <TabAtkins> | annevk: Just tell us what's right (on the list), and we'll change. The current text is a result of fantasai or I deciding what seemed "reasonable". |
| 16:59 | <annevk> | TabAtkins: k, I'd be interested in knowing whether you'd want query comparison stuff and such as well |
| 16:59 | <annevk> | TabAtkins: did you guys collect much feedback from developers? |
| 17:00 | <TabAtkins> | For the unparametrized, probably want query comparison so we can tell what the "same page" is. For the parametrized, definitely want queries stripped. |
| 17:00 | <TabAtkins> | Dunno what feedback we may have explicitly collected, but there's been requests for some time for more url-matching pseudoclasses. |
| 17:00 | <TabAtkins> | People wanting "local" links to be selectable, for some definition of "local". |
| 17:01 | <TabAtkins> | The parametrized one lets you define "local" relative to your personal url scheme - in github's case, :local-link(1) means "same user", :local-link(2) means "same repo", etc. |
| 17:01 | <SimonSapin> | TabAtkins: http://example.com and http://example.com/ are parsed the same, while /foo and /foo/ should be different |
| 17:01 | <TabAtkins> | SimonSapin: For most sites that's not true, though. :/ |
| 17:02 | <SimonSapin> | well, that’s an apache thing |
| 17:02 | <SimonSapin> | clicking on the link will still navigate rather than just scroll |
| 17:02 | <annevk> | TabAtkins: but at that point you're embedding server semantics into the comparison |
| 17:02 | <TabAtkins> | Ah, hm. |
| 17:02 | <TabAtkins> | annevk: Well, not quite server semantics. Common de facto url semantics, perhaps. |
| 17:02 | <SimonSapin> | … which should be the criteria for :local-link (non fonctional), I think |
| 17:02 | <annevk> | TabAtkins: e.g. / and /Overview.html might be the same too |
| 17:02 | <TabAtkins> | SimonSapin: Yeah, makes sense for :local-link |
| 17:03 | <TabAtkins> | annevk: Yeah, but that's impossible to tell. |
| 17:03 | <SimonSapin> | trailing slash also changes meaning of path-relative URLs |
| 17:03 | <TabAtkins> | Oh man, you're right abuot that. |
| 17:03 | <TabAtkins> | Never mind, then. |
| 17:03 | <SimonSapin> | gotta go, bye |
| 17:04 | <annevk> | TabAtkins: I think that should be an incentive for people to clean that up though |
| 17:04 | <annevk> | TabAtkins: e.g. by having the server do a redirect |
| 17:05 | <TabAtkins> | annevk: I'm not too interested in providing that sort of incentive, but I am interested in making things consistent across the platforms. |
| 17:05 | <TabAtkins> | platform/usage |
| 17:05 | <TabAtkins> | So yeah, example.com/foo and example.com/foo/ should be different. |
| 17:05 | <annevk> | well we cannot normalize e.g. /foo//bar to /foo/bar |
| 17:05 | <annevk> | even though Apache will treat them as identical iirc and not redirect |
| 17:06 | <TabAtkins> | Is the /foo/../bar == /bar thing also apache-specific? |
| 17:06 | <annevk> | W3C does appear to redirect for http://www.w3.org/2001//tag/ that's cool |
| 17:06 | <annevk> | TabAtkins: no, that's the URL parser |
| 17:06 | <TabAtkins> | annevk: Cool. |
| 17:06 | <karlcow> | note that you can deactivate Apache default behavior |
| 17:06 | <karlcow> | → curl -sI http://www.la-grange.net/2013 |
| 17:06 | <karlcow> | HTTP/1.1 403 Forbidden |
| 17:07 | <TabAtkins> | So yeah, my preferred solution is to just lean *fully* on your spec for all the necessary parsing and terminology. |
| 17:07 | <karlcow> | → curl -sI http://www.la-grange.net/2013/ |
| 17:07 | <karlcow> | HTTP/1.1 200 OK |
| 17:07 | <annevk> | TabAtkins: cool, if you have feedback on the API thing I sketched out that'd be welcome |
| 17:08 | <annevk> | TabAtkins: I'll about providing hooks soonish |
| 17:08 | <TabAtkins> | annevk: Where did you outline this? |
| 17:08 | <annevk> | http://lists.w3.org/Archives/Public/www-style/2013Apr/0588.html (also on webapps) |
| 17:08 | <TabAtkins> | Oh, sorry, I was only skimming for www-style-tagged threads. |
| 17:08 | <karlcow> | http://httpd.apache.org/docs/2.2/mod/mod_dir.html#DirectorySlash |
| 17:10 | <annevk> | karlcow: what about //foo ? |
| 17:11 | <karlcow> | annevk: good question, I haven't tried |
| 17:11 | <annevk> | http://www.la-grange.net//2013/ aaah |
| 17:11 | <annevk> | even karlcow is not canonical |
| 17:12 | <annevk> | just found numerous bugs in my own URLs too, which were already broken |
| 17:12 | <TabAtkins> | For shame! |
| 17:12 | <karlcow> | you meant la-grange ;) |
| 17:12 | <annevk> | (for different reasons) |
| 17:12 | <annevk> | karlcow: maybe ;) |
| 17:12 | <hober> | TIL sicking eats every day |
| 17:12 | <karlcow> | karlcow is extremely faaaaaar to be canonical :p |
| 17:13 | <karlcow> | This slash-slash on Apache is interesting |
| 17:14 | <karlcow> | → curl -sI http://www.la-grange.net///2013/ |
| 17:14 | <karlcow> | HTTP/1.1 200 OK |
| 17:14 | <karlcow> | you can add as many as you want |
| 17:15 | gavinc | accepts challenge |
| 17:15 | <gavinc> | 414 Request-URI Too Large woohoo! |
| 17:16 | <annevk> | I wonder if the URL is too long or it simply has too many segments... |
| 17:17 | <karlcow> | "Regarding double slashes: Most Web servers silently collapse multiple slashes into a single slash early in the request processing pipeline. This is true for at least Apache, Tomcat and Jetty. " — http://stackoverflow.com/questions/4514627/apache-rewrite-rule-leading-slash/4514696#4514696 |
| 17:17 | <karlcow> | gavinc: how many? :) |
| 17:17 | <annevk> | http://www.la-grange.net/////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////// |
| 17:17 | <annevk> | /////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////// |
| 17:17 | <annevk> | /////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////// |
| 17:17 | <annevk> | /////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////// |
| 17:17 | <annevk> | /////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////// |
| 17:17 | <annevk> | /////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////// |
| 17:17 | <annevk> | /////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////// |
| 17:17 | <annevk> | //////////////////////////////////////////////////////////////////////////////////////////////////////http://www.la-grange.net///////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////// |
| 17:17 | <annevk> | /////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////// |
| 17:18 | <annevk> | /////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////// |
| 17:18 | <annevk> | /////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////// |
| 17:18 | <gavinc> | gee thanks annevk :P |
| 17:18 | <annevk> | /////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////// |
| 17:18 | <annevk> | /////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////// |
| 17:18 | <annevk> | /////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////// |
| 17:18 | <annevk> | /////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////// |
| 17:18 | <karlcow> | mwahahaha |
| 17:18 | <annevk> | ////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////2013/2013/ does the trick |
| 17:18 | <annevk> | oops |
| 17:18 | <TabAtkins> | Thanks for flooding, bro. |
| 17:18 | <karlcow> | :D |
| 17:18 | <TabAtkins> | I went to get a coke, and when I came back I thought something terrible was happening to my computer. |
| 17:18 | <annevk> | seems like I even made a typo |
| 17:18 | <karlcow> | :D |
| 17:18 | <annevk> | oh well |
| 17:18 | <karlcow> | When I slash, I do it with typos! |
| 17:19 | <annevk> | TabAtkins: I hope you didn't spit the coke all over it |
| 17:19 | <TabAtkins> | Luckily no. |
| 17:20 | <karlcow> | TabAtkins: it's a message. Coke is no good ;) |
| 17:20 | <TabAtkins> | karlcow: Diet Coke, even! |
| 17:21 | <karlcow> | collapsing the slash in Diet Coke. |
| 17:21 | <rillian> | TabAtkins: we should alter our clients to collapse multiple tabs early in the message display pipeline |
| 17:21 | <rillian> | s/tabs/slashes/ |
| 17:22 | <TabAtkins> | About to say, there's rarely more than one of me. |
| 17:22 | <TabAtkins> | And even if there was, you wouldn't want to collapse us. |
| 17:22 | <rillian> | typoes ruin the joke |
| 17:22 | <rillian> | TabAtkins: you'd scale well on parallel jobs? |
| 17:22 | <TabAtkins> | Pretty sure I would. |
| 17:23 | <TabAtkins> | With some message-passing latency, I think I'd do fine as a hive. |
| 17:23 | <TabAtkins> | (It's one of my pre-planned genie wishes.) |
| 17:23 | <tantek> | WTF |
| 17:23 | <TabAtkins> | Hahaha |
| 17:23 | tantek | scrolls up and sees a slash-attack |
| 17:24 | <rillian> | "He's just hive-curious." |
| 17:24 | <TabAtkins> | Hm, trying to think of a case where I'd want to ignore query but pay attention to fragment. |
| 17:24 | <TabAtkins> | rillian: It's a degenerate case of poly-amory. |
| 17:24 | <tantek> | TabAtkins - let me know if you find any other rel values you have problems with and I'll take care of specing/registering them. |
| 17:24 | <tantek> | We've been pretty active with that recently |
| 17:24 | <TabAtkins> | tantek: That's the only one I see in our specs so far. |
| 17:25 | <tantek> | based on all the #indiewebcamp distributed comments scenarios / progress |
| 17:25 | <tantek> | ok cool |
| 17:25 | <gavinc> | http://paste.ofcode.org/XZBCb4MUzrL2Hwtjh9pHkw ;) |
| 17:25 | tantek | waves from the WebApps WG f2f |
| 17:25 | <TabAtkins> | annevk: There are times when the query is just used for passing random information into the page, such that different queries still represent the same "page". Then, I think you'd want to just omit query, but match on everything else. |
| 17:26 | Ms2ger | waves at tantek |
| 17:26 | <tantek> | :) |
| 17:26 | <TabAtkins> | Like, using query to set the background-color of the page, or something equally silly. |
| 17:27 | <tantek> | TabAtkins - having trouble following the :read-write discussion in Bugzilla |
| 17:28 | <tantek> | I think my intent there was always to reflect user-alterability of the state of the inputs |
| 17:28 | <tantek> | so to that extent, I'm pretty sure I intended it to apply to checkboxes and radio buttons that the user can change the state of |
| 17:28 | <TabAtkins> | tantek: Yes, but now define that in terms of what precise HTML elements match it. ^_^ |
| 17:28 | <TabAtkins> | Yes, agree. |
| 17:28 | <annevk> | TabAtkins: yeah, but in case of e.g. Bugzilla it's essential |
| 17:28 | <tantek> | TabAtkins - ok, sure we can add more details |
| 17:28 | <TabAtkins> | I'm only excluding the button-typed inputs. |
| 17:28 | <TabAtkins> | annevk: Yes, certainly. |
| 17:28 | <tantek> | I wanted to see if we had highlevel / conceptual agreemtn too |
| 17:29 | <TabAtkins> | I'm sending feedback on the thread, just saying that "upto" as the only way to drop components probably isnt' sufficient. |
| 17:29 | <tantek> | or rather first, before specifying |
| 17:29 | <annevk> | TabAtkins: k, will look tomorrow |
| 17:29 | <annevk> | or tonight, we'll see |
| 17:29 | <tantek> | TabAtkins - where should the definition of what precise HTML elements match it go? |
| 17:29 | <tantek> | in CSS3-UI? Selectors? HTML? |
| 17:29 | <tantek> | or should I just write it up on a wiki page and we can decide later |
| 17:32 | <TabAtkins> | tantek: HTML. |
| 17:32 | <TabAtkins> | We're deciding it in the bug right now. |
| 17:32 | <tantek> | Bugzilla is not a good place for deciding things - sorry to say |
| 17:32 | <TabAtkins> | Well, "deciding". |
| 17:33 | <tantek> | hence IRC! :) |
| 17:34 | <tantek> | annevk - I want to add onfullscreenchange and onfullscreenerror to the Fullscreen API IDL - any objection? |
| 17:35 | <TabAtkins> | No objection from me, though I wish we had event streams. :/ |
| 17:35 | <tantek> | ok I'll do it then and annevk can revert it if he disagrees :) |
| 17:35 | <tantek> | the event firings etc. are already in the spec |
| 17:35 | <Ms2ger> | Clearly fullscreen should use futures |
| 17:35 | <tantek> | they're just missing from the IDL |
| 17:35 | <TabAtkins> | No, it shouldn't really. |
| 17:36 | <TabAtkins> | Repeated events, like fullscreenchange, are not a good match for futures. |
| 17:36 | <tantek> | Ms2ger - how can I capture that as an open issue? |
| 17:36 | <Ms2ger> | tantek, I jest |
| 17:36 | <tantek> | Ms2ger - thanks, a bit slow this morning. |
| 17:37 | <Ms2ger> | Shouldn't you be having coffee with the rest of the wg? :) |
| 17:37 | <tantek> | oh oops, right, maybe that would help |
| 17:37 | <tantek> | brb |
| 18:32 | <Hixie> | cabanier1: yt? |
| 18:43 | <gavinc> | karlcow: 8173 |
| 18:46 | <cabanier1> | Hixie: pong |
| 19:17 | <Hixie> | cabanier1: so i'm finally getting around to the fillrule feedback |
| 19:17 | <tantek> | someone here with a working Anolis, could you update Overview.html in fullscreen? |
| 19:18 | <tantek> | I just spent over an hour updating my Anolis (and some dependencies) and still got stuck |
| 19:18 | <Hixie> | tantek: http://anolis.hoppipolla.co.uk/aquarium.py |
| 19:18 | <tantek> | logged errors and solutions until I got stuck here: http://wiki.whatwg.org/wiki/Anolis#Troubleshooting |
| 19:19 | <Ms2ger> | Hixie, that's too old, unfortunately |
| 19:19 | <Hixie> | cabanier1: am i wrong in presuming that we should also have a fillrule argument for fill() when fill() is passed just a Path object? |
| 19:19 | <Hixie> | Ms2ger: it's what HTML uses :-) |
| 19:19 | <tantek> | Hixie, A problem occurred in a Python script. |
| 19:19 | <Ms2ger> | Hixie, yeah, and you don't have cross-spec references :) |
| 19:20 | <Hixie> | well, i do, but anolis' version of those don't work the way i want :-) |
| 19:22 | <tantek> | Hixie, interesting, it worked via URL but not upload |
| 19:24 | <tantek> | uh, by "worked" I should say - it gave me something that looked like a spec |
| 19:24 | <tantek> | however it is VERY different from the previous Overview.html - much more different than the edits I made should have caused |
| 19:25 | <tantek> | I suppose I could check it in and just let annevk update/fix it next time he commits |
| 19:25 | <tantek> | what could possibly go wrong |
| 19:25 | <Ms2ger> | Just checkin the source and leave the generated one alone |
| 19:30 | <tantek> | well it looked reasonable in the browser so I committed it |
| 19:31 | <tantek> | seemed worse to have them be out of sync |
| 19:31 | <tantek> | changes seemed minor, (un)quoted attributes, numeric entities vs. utf-8 |
| 19:31 | <tantek> | whitespace |
| 19:32 | <zcorpan> | why can't i mark the remaining bits in https://critic.hoppipolla.co.uk/r/5 as reviewed? |
| 19:37 | <zcorpan> | tantek: i ran make with an up-to-date (i think) anolis. diff was empty |
| 19:38 | <Ms2ger> | zcorpan, probably because it didn't run anolis |
| 19:38 | <Ms2ger> | zcorpan, try touch Overview.src.html && make |
| 19:39 | <zcorpan> | Ms2ger: ah, yeah |
| 19:40 | <Hixie> | MikeSmith: i'm gonna try putting "blocked awaiting responses to comment 15 (please remove this when replying)" in the status whiteboard for now |
| 19:41 | <zcorpan> | tantek: pushed |
| 19:44 | <MikeSmith> | Hixie: works for me :) |
| 19:44 | <zcorpan> | tantek: onfullscreenchange is listed in http://www.whatwg.org/specs/web-apps/current-work/multipage/webappapis.html |
| 19:45 | <zcorpan> | tantek: also it's nice to have separate commits for normative changes and for fluffing |
| 19:47 | <zcorpan> | (also, dunno if anne approves of pushing like this or if he prefers pull requests) |
| 19:50 | <divya> | hober: MikeSmith when is this SF plan going to happen |
| 19:50 | <divya> | i need to add it to my calendar |
| 20:14 | <tantek> | thanks for your help zcorpan |
| 20:17 | <tantek> | pushing works |
| 20:22 | <Hixie> | i wish bugzilla had a column in search results for "last person to touch this bug" |
| 20:25 | <tantek> | Hixie, a radio button is more like part of a select |
| 20:26 | <tantek> | than it is a button |
| 20:26 | <jgraham> | zcorpan: critic bug, I think |
| 20:26 | <jgraham> | But if you have reviewed them, I can mark them as reviewed |
| 20:26 | <tantek> | radio buttons and checkboxes should be :read-write if their state is changeable by the user |
| 20:26 | <tantek> | re: https://www.w3.org/Bugs/Public/show_bug.cgi?id=17812 |
| 20:28 | <zcorpan> | jgraham: i haven't actually reviewed interfaces.html but i guess it's just c/p |
| 20:28 | <zcorpan> | jgraham: i have reviewed everything else |
| 20:28 | <jgraham> | zcorpan: Actually I fixed the assignments |
| 20:28 | <jgraham> | You can mark everything now |
| 20:28 | <zcorpan> | ah |
| 20:28 | <jgraham> | So not really a bug, perhaps |
| 20:29 | <Hixie> | tantek: this is a definition of "write" quite foreign to me |
| 20:29 | <tantek> | Hixie - don't misinterpret the label for the meaning |
| 20:29 | <tantek> | would you have preferred :user-modifiable? |
| 20:29 | <TabAtkins> | Hixie: You're being a weird kind of overly-literable. |
| 20:29 | <TabAtkins> | s/able/al/ |
| 20:29 | <jgraham> | literable? |
| 20:29 | <tantek> | we're about 10 years past bike-shedding these selectors |
| 20:29 | <jgraham> | You could write books about him? |
| 20:30 | tantek | is old enough to remember when "writing" a bit of information was perfectly normal. |
| 20:32 | <Hixie> | TabAtkins: the term "readonly" has never applied to radio buttons as far as i am aware. There's a reason, for example, that neither HTML radio buttons nor Win32 radio buttons (the ones I'm familiar with) have a "read-only" mode. |
| 20:32 | <Hixie> | TabAtkins: they can be disabled, but not made read-only |
| 20:32 | <TabAtkins> | Hixie: ...and? |
| 20:32 | <Hixie> | TabAtkins: this is why i'm confused, because i would never have guessed that :read-write and :read-only would apply to radio buttons |
| 20:32 | <Hixie> | TabAtkins: and i'm still skeptical that they should |
| 20:33 | <TabAtkins> | Which is why it's a good thing you asked, and I told you what they should apply to. |
| 20:33 | <Hixie> | but i think you're wrong :-) |
| 20:33 | <tantek> | they apply to radio buttons, as as a group, they act semantically similar to a select, which certainly has read/readwrite semantics |
| 20:33 | <TabAtkins> | Well, 2-1 support for me, with tantek. |
| 20:33 | <TabAtkins> | And yes, what tantek said. |
| 20:33 | <TabAtkins> | (And checkboxes act like a multiselect.) |
| 20:34 | <Hixie> | list boxes and check boxes also don't have a concept of "read-only" |
| 20:34 | <Hixie> | only disabled vs enabled |
| 20:34 | <tantek> | Hixie, you're stubbornly arguing linguistic semantics from labels, rather than what the things in questions actually do / how they behave |
| 20:34 | <Hixie> | tantek: i don't understand the distinction. We're talking about what labels mean here. |
| 20:35 | <TabAtkins> | We're defining what they mean. You're claiming that the names don't match. This is a mismatch in argument goals. |
| 20:35 | <tantek> | what Tab said |
| 20:35 | <zcorpan> | jgraham: seems like i still can't mark quite everything as reviewed |
| 20:35 | <Hixie> | i'm having two arguments. one is about what the selectors spec should say, the other is about what it does say. |
| 20:35 | <TabAtkins> | The concept which is being labeled, however (in)accurately, by :read-write, applies equally to text inputs and checkboxes. |
| 20:36 | <Hixie> | i think the selectors spec _should_ say that :read-only and :read-write apply to text fields only. |
| 20:36 | <Hixie> | i think the selectors spec _does_ say basically nothing about what they apply to, it being too vague to unambiguously interpret. |
| 20:37 | <tantek> | I'm fine with adding more detailed description to Selectors, CSS3-UI etc. |
| 20:38 | <TabAtkins> | I'm not fine with defining it in terms of specific HTML elements. |
| 20:38 | <tantek> | even if that means we have to resort to explicitly listing HTML elements as one example of an applicable host language |
| 20:38 | <TabAtkins> | I'm fine with pointing to HTML's definition as an example for other languages to lean on. |
| 20:38 | <Hixie> | i don't think we need to list elements, just define what it is you want to match |
| 20:38 | <tantek> | TabAtkins - not even non-normative example? like the UA style sheet? |
| 20:38 | <tantek> | :read-write = user-modifiable |
| 20:39 | <tantek> | :read-only = user-viewable but not modifiable |
| 20:39 | <TabAtkins> | tantek: We have non-normative examples all over the place, referencing HTML quite a lot. No problem there. |
| 20:39 | <jgraham> | zcorpan: Oh. Which files? Can you change things in the "manage assignments" dialog (on the review page) |
| 20:39 | <tantek> | TabAtkins - ok cool |
| 20:39 | <Hixie> | e.g. "text fields whose contents can be edited when the control is focused match :read-write; text fields whose contents cannot be edited when the control is focused match :read-only. Other controls, disabled controls, and non-controls match neither." |
| 20:40 | <zcorpan> | jgraham: elements-embedded.js |
| 20:40 | <TabAtkins> | I disagree with that definition, and wont' use it. It is being overly specific to text fields, when the definition isn't intended to be limited to text. |
| 20:40 | <zcorpan> | jgraham: i opened manage assignments, checked all the boxes, saved. no difference |
| 20:40 | <Hixie> | TabAtkins: then define what it is you do mean :-) |
| 20:40 | <TabAtkins> | omg i did |
| 20:40 | <TabAtkins> | I gave you an explicit list over in the bug. |
| 20:41 | <Hixie> | right now it just says "An element matches :read-write if it is user-alterable, as defined by the host language" |
| 20:41 | <jgraham> | zcorpan: OK, *this* is a critic bug :) |
| 20:41 | <jgraham> | I can mark that as reviewed though |
| 20:41 | <tantek> | user-alterable sounds like user-modifiable |
| 20:41 | <tantek> | so that's good |
| 20:41 | <Hixie> | "user-alterable" is one of the least specific definitions ever |
| 20:41 | <Hixie> | i have no idea what it means |
| 20:41 | <TabAtkins> | Yes, becasue that is the most specific I can get without getting into a specific host language. |
| 20:41 | <TabAtkins> | That's your problem, Hixie. The rest of us seem to agree on it pretty well. |
| 20:42 | <zcorpan> | jgraham: reflection-original.html in the first commit also says "Pending", might also be a bug? |
| 20:43 | <Hixie> | ok well if the spec is remaining as "it's up to the host language", i really don't see anything wrong with what HTML says now |
| 20:43 | <Hixie> | so i guess the bug is WORKSFORME. |
| 20:43 | <Hixie> | since i think what you are describing neither matches the spec nor is sensible |
| 20:43 | <TabAtkins> | Dude. For godssake. |
| 20:44 | <TabAtkins> | I will override you and put an explicit list of HTML elements and states in the Selectors spec with a note that says "Note: this list exists because Hixie is being difficult" if you keep doing this. |
| 20:44 | <TabAtkins> | You disagree on what the word "user-alterable" means. I get that. Get over it. I'm telling you what elements HTML should associate with that word. |
| 20:45 | <zcorpan> | i'm gonna override both of you in the quirks spec!! |
| 20:45 | <Hixie> | it's not what you tell me that matters dude |
| 20:45 | <Hixie> | that's not how specs work |
| 20:45 | <Hixie> | it's what the spec says that matters |
| 20:45 | <Hixie> | it's not about HTML elements, it's about control types |
| 20:45 | <TabAtkins> | Yes it is. You write something in the spec. You asked me what should be written, I told you. |
| 20:45 | <tantek> | how about principle of least surprise? I think web devs would be surprised if checkboxes, radio button groups, select elements matched :read-only when the user was able to modify them |
| 20:45 | <Hixie> | HTML is not the only language to which selectors applies |
| 20:45 | <zcorpan> | In quirks mode, :read-write matches your mom. |
| 20:45 | <tantek> | HTML is the only language with UI elements to which selectors applies. XForms has been abandoned. |
| 20:45 | <jgraham> | I guess you could write on my mom with marker pen |
| 20:46 | <Hixie> | tantek: i agree that they'd be surprised if :Read-only matched those controls, but i think they'd be even more surprised if :Read-write matched them. they're not read-write controls nor read-only controls. they're not text fields. |
| 20:46 | <TabAtkins> | A <select> element is equivalent to a text input with a pattern on it. A radio group is equivalent to a select. A checkbox group is equivalent to a multi-select. All of these are just UI variances for the same underlying concept. |
| 20:46 | <jgraham> | But really why would you? |
| 20:46 | <Hixie> | TabAtkins: that is not consistent with how UI controls are conventionally described. |
| 20:46 | <TabAtkins> | An <input type=color> is equivalent to a text input, even if it's exposed only as a button that opens up a color picker. |
| 20:46 | <jgraham> | (FWIW I think I would expect :read-write to match selects/radio buttons) |
| 20:47 | <jgraham> | (I think that in my head :read-write really means :mutable) |
| 20:47 | <Hixie> | wait, type=color should match :Read-write too?! |
| 20:47 | <TabAtkins> | The concept of "input with text in it" that you're harping on is just bizarrely specific, and has no connection with the actual wording of the Selectors spec. |
| 20:47 | <TabAtkins> | ... |
| 20:47 | <TabAtkins> | Yes. It's in the list of things I said should be read-write in the bug. |
| 20:48 | <TabAtkins> | Seriously, where are you getting this notion that it only applies to text? Why? How? |
| 20:48 | <TabAtkins> | (When? What?) |
| 20:48 | <Hixie> | The concept of "input with text in it" that I'm talking about is the about what the definition of "Readonly" in UI is, it's not about CSS' current text. It's abotu what CSS _Should_ say |
| 20:48 | <jgraham> | Don't UAs do something already here? |
| 20:48 | <lecuyer> | Hixie wouldn't that be something like input[type=text]:not(:empty) ? |
| 20:49 | <Hixie> | Controls have several states, relevant here are "enabled", "readonly", and "disabled". Most controls only have the first and third of these. Text fields are the exception, they can be readonly. |
| 20:49 | <tantek> | an author could use <input type="number" min="1" max="10" step="1" value="5"> e.g. for a 1-10 rating input, and a UA could render that as a select list, while non-supporting UAs would fallback to having it be a text input |
| 20:49 | <tantek> | in both cases - it's read-write |
| 20:49 | <Hixie> | let me put this another way |
| 20:49 | <tantek> | whether the user is typing characters, or picking from a menu of options, the input is read-write |
| 20:49 | <TabAtkins> | Or it could be a range, or it could be a spinner. |
| 20:50 | <tantek> | right |
| 20:50 | <Hixie> | what's the point of having :enabled/:disabled of :read-only/:read-write are the same? |
| 20:50 | <Hixie> | s/of/if/ |
| 20:50 | <tantek> | the point is, the text field presentation vs. the select list presentation DOES NOT impact the :read-write - ness |
| 20:50 | <TabAtkins> | They're not. :disabled only matches disabled things. |
| 20:50 | <TabAtkins> | :read-only happens to *also* match disabled things (because you can't alter their state). |
| 20:50 | <Hixie> | can you point me to a :read-write:disabled control? |
| 20:50 | <tantek> | so that's the proof of why a select can be read-write |
| 20:50 | <TabAtkins> | No, because of what I just said. |
| 20:50 | <tantek> | and since radio button groups are just another presentation of select |
| 20:50 | <Hixie> | or a :read-only:enabled control that isn't a text field? |
| 20:50 | <tantek> | that's why radio buttons can be read-write |
| 20:51 | <TabAtkins> | In HTML, the readonly attribute only applies to text inputs. So, no. |
| 20:51 | <tantek> | similarly with a group of checkboxes and a multi-select |
| 20:51 | <TabAtkins> | That's not a generic argument, Hixie. |
| 20:52 | <TabAtkins> | So we're back again to you obviously arguing solely about naming. You're attached to the name "readonly" referring to the specific "readonly" state that HTML uses, and are refusing to wrap your head around the concept possibly being more general. |
| 20:52 | <TabAtkins> | Mutable vs immutable. |
| 20:52 | <TabAtkins> | User-alterable vs Static. |
| 20:52 | <TabAtkins> | Whatever. |
| 20:52 | <TabAtkins> | The names are the least important part of this, because we're stuck with them (they're very old). So stop hanging importance on them. |
| 20:52 | <Hixie> | this isn't just about HTML, e.g. Win32 has the same distinctions. |
| 20:52 | <Hixie> | I think your definition is bad, but putting that aside, how about "An element matches :read-write if it is enabled, and, for text fields, is not read-only; all other elements match :read-only"? or some such? |
| 20:53 | <Hixie> | where "enabled" and "read-only" can be host-language concepts |
| 20:53 | <Hixie> | (and the "enabled" state matches the one used for :enabled) |
| 20:54 | <TabAtkins> | That means that buttons will be :read-write, which is silly, because they're not mutable. They're *enabled*, yes, but they've got no user-alterable state. |
| 20:54 | <Hixie> | they have hte state of being pushed in or not |
| 20:54 | <TabAtkins> | That's not a significant state that we wish to care about. |
| 20:54 | <TabAtkins> | (And it's already covered generally by :active.) |
| 20:55 | <Hixie> | this is a really strange definition you're trying to have, i'm not surprised you're having trouble describing it normatively |
| 20:55 | <Hixie> | what's the use case? maybe that's a better starting point for figuring out what the definition should be |
| 20:55 | <TabAtkins> | Good lord, no. It's the intuitive definition that I, fantasai, tantek, jgraham, and I expect almost anyone I ask would have. |
| 20:56 | <TabAtkins> | You're the only one in this conversation so far who seems to be having trouble with it, and *I can't figure out why*. |
| 20:56 | <tantek> | Hixie - what's the use case in leaving them out? |
| 20:56 | <tantek> | based on principle of least surprise, writability = modifiability |
| 20:56 | sgalineau | grabs popcorn |
| 20:57 | <TabAtkins> | Tantek made a great argument by analogy just a few lines ago. Just read that. |
| 20:57 | <Hixie> | the text field vs select list thing? That's the same one you said earlier. |
| 20:58 | <TabAtkins> | Yes, number vs range vs select vs text input, and how they're all *the exact same thing*, just with different displays. |
| 20:58 | <tantek> | one might even say … different *appearances* ;) |
| 20:59 | <Hixie> | they're the same underlying data type, but they're no the same control |
| 20:59 | <lecuyer> | are there any non-modifiable inputs other than button? |
| 20:59 | <TabAtkins> | Duh. But they all have the same notion of "user-alterability". |
| 20:59 | <Hixie> | i mean by that argument a <button> that when clicked alters the value of a <span> between two values, is equivalent to a radio button and equivalent to a text field and should be :read-write |
| 20:59 | <TabAtkins> | lecuyer: All the button types: button/reset/submit/image. Also, hidden. |
| 21:00 | <TabAtkins> | Hixie: If we could magically and reasonably tell when JS was turning a button into something that altered state in the page in that way, I would agree with you. |
| 21:00 | <TabAtkins> | We can't, so I don't, and we don't. |
| 21:00 | <Hixie> | and technically <input type=submit> changes state (it changes what is submitted if it has a name) and <input type=reset> is clearly "user-alterable" since it affects every field in the form |
| 21:01 | <Hixie> | TabAtkins: oh wow, you'd actually want that button matching :read-write if you could?? |
| 21:01 | <tantek> | OH: "Google+ is write-only, no one reads it." |
| 21:01 | <Hixie> | i really don't understand what you expect people to use this pseudo-class for |
| 21:01 | <Hixie> | if it only matched read-only-able elements, i could see the use case |
| 21:01 | <Hixie> | but having it match everything means you'd only ever be able to use it with more selectors to narrow it down |
| 21:02 | <TabAtkins> | Hixie: In the imaginary world where the halting problem was cheap to solve, and AI was just a library that you called? Sure, knock yourself out. |
| 21:02 | <TabAtkins> | Please, god, stop willfully misinterpreting me. The list of :read-write elements is finite, and explained in the bug. |
| 21:03 | <Hixie> | what am i misinterpreting? |
| 21:03 | <Hixie> | (i swear it's not willful) |
| 21:03 | <TabAtkins> | "having it match everything..." |
| 21:03 | <tantek> | clearly you guys would be having more fun in the WebApps WG f2f :) |
| 21:03 | <lecuyer> | It's right in the title |
| 21:03 | <Hixie> | you want :read-only, :read-write { } to match everything, no? |
| 21:05 | <tantek> | Hixie, why, what's the use case behind that reasoning? |
| 21:06 | <Hixie> | i have no idea what the use cases are for these pseudos, that's what i'm trying to determine. In the absence of use cases, I default to assuming that they should match what their names imply they should match. |
| 21:06 | <Hixie> | as far as i can tell, the spec says ":read-only, :read-write { }" should match everything. |
| 21:06 | <TabAtkins> | Text inputs have a state, .value, which the user can alter. So do color inputs, range inputs, number inputs, etc. Checkboxes have a state, .checked, which the user alters. Selects have a state, .selectedIndex, which the user alters. |
| 21:06 | <Hixie> | ("An element matches :read-write if it is user-alterable, as defined by the host language. Otherwise, it is :read-only.") |
| 21:07 | <TabAtkins> | That's the unifying thread which we keep repeating, over and over again, and which you keep claiming to not understand. |
| 21:07 | <Hixie> | TabAtkins: i understand (though i have difficulty figuring out where you draw the line, hence wanting the spec to be clearer); my question is, why would you want that definition? What use is the pseudo with that definition? |
| 21:07 | <TabAtkins> | Submit buttons are questionable (they are sometimes used instead of a radio group), but I fall on the side of not including them in the group. They alter the state of the form, not themselves, and their effect is transient and part of the submission process, not an independent state. |
| 21:08 | <TabAtkins> | Man, I don't know the use for half of the user-input pseudos. I'm too long out of webdev, and I never liked forms much anyway. I'm just giving them reasonable definitions. |
| 21:08 | <Hixie> | :enabled and :disabled only apply to controls that _can_ be enabled and disabled, right? Why would :read-only and :read-write apply to everything? |
| 21:08 | <Hixie> | ok. I disagree that this definition is "reasonable". |
| 21:09 | <TabAtkins> | One issue at a time, please. Whether :read-only is :not(:read-write) can be discussed later. |
| 21:09 | <Hixie> | i think it's the same issue, personally. |
| 21:09 | <TabAtkins> | Right now we're covering the elements which are reasonably one or the other, and talking about which category they're in. |
| 21:09 | <lecuyer> | In all the large web projects I've worked on, I dont' think I've ever seen someone use :read-write |
| 21:10 | <TabAtkins> | lecuyer: I wouldn't define it if I were starting from scratch. But these are legacy pseudos. |
| 21:10 | <lecuyer> | or :read-only for that matter. People use :enabled |
| 21:10 | <Hixie> | maybe we can drop them? I wonder how commonly used they are. |
| 21:10 | <Hixie> | do we have metrics on this? |
| 21:10 | <Hixie> | (does chrome instrumentation track individual pseudos?) |
| 21:11 | <lecuyer> | you're at google, just 'grep :read-only -r /dev/interwebs' |
| 21:11 | <Hixie> | unfortunately we don't crawl CSS as far as I know |
| 21:11 | <TabAtkins> | Hixie: It can track individual pseudos that we're interested in. |
| 21:12 | <lecuyer> | TabAtkins: has nobody ever been interested in :read-only? telling? |
| 21:13 | <TabAtkins> | lecuyer: No idea. |
| 21:13 | <Hixie> | TabAtkins: we should do this for these pseudos |
| 21:14 | <Hixie> | TabAtkins: since apparently none of us know what the use cases are, or how often they are used, we probably need more data to work out what to do. |
| 21:17 | <lecuyer> | How do you guys collect data on that? Apart from announcing that it's being EOL'd and that you need usecases for not removing |
| 21:17 | <TabAtkins> | In Chrome, we can instrument it to count usage. |
| 21:21 | <lecuyer> | From what I can tell, most uses of uses of readonly is actually using the attr selector div[readonly] *not* using pseudos |
| 21:23 | <lecuyer> | s/most uses/the first page of search results/ |
| 21:23 | <cabanier1> | Hixie: adding a fillrule to 'fill(path)' makes sense |
| 21:24 | <cabanier1> | Hixie: however, I think there should be an object that takes a path + fillrule, or a path + strokeparameters |
| 21:24 | <cabanier1> | Hixie: and you pass this object to fill |
| 21:25 | <cabanier1> | hixie: that way you can do the heavy lifting of stroking and resolving of the winding rules offline |
| 21:26 | <cabanier1> | hixie: that object would also accurately describe an area so you can associate it with a region |
| 21:35 | <lecuyer> | Has there been any discussion of aliasing/inheriting rules from another otherwise-unrelated class? |
| 21:37 | <lecuyer> | I have the problem of not being able to use classes in my html (lots and lots of data selectors), so it'd be really nice if we could somehow define a bunch of classes and then in an attribute selector apply a predefined class |
| 21:37 | <lecuyer> | If that makes any sense |
| 22:05 | <TabAtkins> | lecuyer: I recommend using SASS and the @extend directive for now. |
| 22:05 | <TabAtkins> | lecuyer: I'm slowly pursuing putting @extend in CSS itself. |
| 22:08 | <Hixie> | d'oh, cabanier left |
| 22:10 | <krit> | Hixie: he just came back from a travel |
| 22:12 | <lecuyer> | TabAtkins SASS is nice, and also generates about 1900 LOC I was hoping there could be an actually css solution in the future |
| 22:13 | <lecuyer> | TabAtkins: Want help with that? :) |
| 22:13 | <TabAtkins> | There's a reason it generates that much. ^_^ |
| 22:13 | <annevk> | tantek: the handlers are defined by HTML already |
| 22:13 | <annevk> | tantek: also, you're destroying blame :/ |
| 22:13 | <TabAtkins> | Nah, I'm already friends with Chris Eppstein. Got all the help I need right now. |
| 22:15 | <annevk> | hober: time for design.spec.whatwg.org? |
| 22:16 | <hober> | annevk: i thought about picking it back up in the html wg |
| 22:16 | <hober> | annevk: but then i realized what i was thinking |
| 22:16 | <TabAtkins> | What's that for? |
| 22:16 | <annevk> | hober: don't do it there :) |
| 22:17 | <Hixie> | design spec? |
| 22:17 | <hober> | TabAtkins: the Living Standard of HTML Design Principles |
| 22:17 | <Hixie> | probably more wiki material |
| 22:17 | <hober> | yeah |
| 22:17 | <TabAtkins> | Ah, kk. |
| 22:20 | <lecuyer> | TabAtkins: any plans to allow nesting of rlues like in regions sans-'flows-from'? |
| 22:21 | <lecuyer> | ie how in SASS I can just put rules inside of each other and it'll automatically do the nesting for me? |
| 22:21 | <TabAtkins> | That's inherently ambiguous, grammatically. Can't be done without magic or unlimited lookahead. |
| 22:22 | <TabAtkins> | SASS is okay with the latter. |
| 22:22 | <TabAtkins> | (You can't tell whether, in "foo { bar:baz ... }", the "bar:baz" part is a property whose value starts with "baz", or the start of a selector for a "bar" element with a ":baz" pseudoclass.) |
| 22:25 | <lecuyer> | TabAtkins you could simplify that by not allowing mixing of child selectors and actual rules, though couldn't you? |
| 22:25 | <tantek> | annevk - why split where the handlers are vs. where the other attributes are? |
| 22:25 | <TabAtkins> | That's not very useful, then. It means you have to do "foo { color: blue; ...} foo { bar { ... } }", repeating yourself every time. |
| 22:25 | <tantek> | e.g. fullscreenEnabled, fullscreenElement ? |
| 22:25 | <TabAtkins> | And it's still ambiguous - how do you tell the difference between the two cases? |
| 22:26 | <annevk> | tantek: also, you didn't define the attributes |
| 22:26 | <tantek> | apologies for the blame destroying |
| 22:26 | <lecuyer> | a ; vs a { |
| 22:26 | <annevk> | tantek: because HTML defines all the attributes on Document/Element already |
| 22:26 | <TabAtkins> | That requires looking forward an arbitrary amount of tokens, and prevents us from ever using {} inside of a declaration. |
| 22:26 | <tantek> | annevk - but it doesn't define fullscreenEnabled, fullscreenElement |
| 22:26 | <annevk> | tantek: in any event, there's some outstanding issues around the events |
| 22:26 | <TabAtkins> | The CSS grammar is specially tuned to only require a single token of lookahead, because that helps performance and maintainability. |
| 22:26 | <annevk> | tantek: well those are not event handlers |
| 22:27 | <tantek> | annevk - but you said "HTML defines all the attributes on Document/Element" |
| 22:27 | <annevk> | tantek: HTML doesn't define everything... just event handlers and HTML stuff (such as the allowfullscreen attribute) |
| 22:27 | <lecuyer> | gotcha, where is that doc'd? |
| 22:27 | <tantek> | they're attributes right? |
| 22:27 | <TabAtkins> | lecuyer: http://dev.w3.org/csswg/css-syntax |
| 22:27 | <tantek> | ok I'm confused on how the split works then |
| 22:27 | <annevk> | tantek: I meant event handler attributes, not the other kind |
| 22:27 | <TabAtkins> | The fact that it's a 3-character lookahead tokenizer and 1-token lookahead parser isn't explicitly documented, but it's a property I tried hard to maintain while writing it. |
| 22:27 | <lecuyer> | Awesome. now I can stop busting into a conversation with things to get shot down :) |
| 22:28 | <annevk> | anyway, I'll sort this out at some point |
| 22:28 | <tantek> | annevk - sorry - that's what I get for trying to improve things ;) |
| 22:28 | <tantek> | i'm fine with wherever the definition/declarations go |
| 22:29 | <tantek> | if onfullscreenchange and onfullscreenerror are defined in HTML, then can we at least put references to those definitions in Fullscreen? |
| 22:29 | <tantek> | (hyperlinks) |
| 22:29 | <tantek> | so they're discoverable? |
| 22:29 | <tantek> | as a webdev I don't expect to go poking through HTML just in case it might define things that my spec might specifically need/use that's so spec-specific |
| 22:30 | <annevk> | yeah I guess, once we sort out the details |
| 22:30 | <tantek> | ok cool |
| 22:30 | <annevk> | i generally try to avoid adding makeup until stuff is somewhat implemented |
| 22:31 | <tantek> | well those eventhandlers are implemented in webkit and gecko so... |
| 22:31 | <Hixie> | am i right in assuming that it's not possible to convert any path plus either the nonzero rule or the oddeven rule to an equivalent path that is the same in both evenodd and nonzero modes? |
| 22:32 | <Hixie> | seems like you'd have to do something that affects where dashes are drawn, at a minimum |
| 22:32 | <hober> | in general that's not possible, yeah |
| 22:32 | <Hixie> | k |
| 22:32 | <Hixie> | wonder what cabanier wanted then |
| 22:32 | <TabAtkins> | Yeah, you can have a path that is equivalent for filling, but not the rest. |
| 22:33 | <TabAtkins> | It can't be equivalent even for solid strokes unless you convert the strokes into filled regions. |
| 22:33 | <Hixie> | maybe he just wanted an object that remembered a particular state so you didn't have to keep passing that around |
| 22:33 | <Hixie> | not a Path, but a new object |
| 22:33 | <Hixie> | that would make sense i guess |
| 22:33 | <Hixie> | for some future version |
| 22:41 | <Hixie> | cabanier: thanks |
| 22:42 | <cabanier> | hixie: I just reconnected. will read the log |
| 22:45 | <cabanier> | hixie: yes, the object would remember the state. I made a proposal on whatwg a couple of months ago and wrote a blog entry: http://blogs.adobe.com/webplatform/2013/01/31/revised-canvas-paths/ |
| 22:45 | <cabanier> | hixie: just some ideas |
| 22:47 | <Hixie> | cabanier: yeah the union thing is something that would indeed be helpful |
| 22:47 | <Hixie> | cabanier: but defining exactly what the resulting path is seems non-trivial |
| 22:48 | <cabanier> | Hixie: that's true. You have to calculate the intersection |
| 22:48 | <cabanier> | Hixie: there are libraries out there that do it |
| 22:48 | <Hixie> | cabanier: you have to define it in enough detail that dashed lines end up the same |
| 22:49 | <cabanier> | Hixie: google's skia people are working on a good one |
| 22:49 | <cabanier> | Hixie: yes. that should be no problem. |
| 22:49 | <Hixie> | i think "no problem" is probably optimistic |
| 22:49 | <Hixie> | but ok :-) |
| 22:49 | <cabanier> | Hixie: are you thinking about where the path would start? |
| 22:50 | <Hixie> | for instance |
| 22:50 | <Hixie> | and what direction it's in, and everything like that |
| 22:50 | <cabanier> | yes |
| 22:50 | <cabanier> | true |
| 22:50 | <Hixie> | incidentally, i don't think we need a new object for this -- seems like you should be able to use Path for this, since the shape is basically just a path, still |
| 22:50 | <cabanier> | I guess that would be hard to define |
| 22:51 | <Hixie> | it's really just another way to add a path, one that happens to be destructive to the existing data |
| 22:51 | <cabanier> | it's not really a path anymore |
| 22:51 | <Hixie> | if you can stroke it, it seems very pathy |
| 22:51 | <cabanier> | true. maybe you shouldn't be able to stroke it :-) |
| 22:51 | <Hixie> | that's the only example you gave :-P |
| 22:52 | <Hixie> | i gotta go, meeting |
| 22:52 | <cabanier> | k |
| 22:52 | <Hixie> | but this is definitely something we should do eventually |
| 22:52 | <Hixie> | if we can define it convincingly |
| 22:52 | <Hixie> | bbl |
| 23:11 | <annevk> | heh http://polyglotconf.com/ |
| 23:12 | <annevk> | (don't worry, it's not about XHTML) |
| 23:53 | <Hixie> | i'm starting to really not like positional arguments |
| 23:54 | <Hixie> | if only named arguments weren't so damn verbose |
| 23:54 | <TabAtkins> | I agree, but options objects make it hard to justify named arguments now. :/ |
| 23:57 | <cabanier> | TabAtkins: how many API's are using option objects these days? |
| 23:57 | <Hixie> | options objects are essentially named arguments |
| 23:57 | <TabAtkins> | A decent number. |
| 23:57 | <TabAtkins> | Hixie: Yeah. |
| 23:57 | <Hixie> | and they're really verbose :-) |
| 23:57 | Hixie | is possibly even less of a fan of those |
| 23:58 | <cabanier> | really? last time I checked, they were very broken in the webkit/blink preprocessor |
| 23:58 | <cabanier> | Hixie: JS people love them |
| 23:58 | <Hixie> | my problem right now is isPointInPath() |
| 23:58 | <cabanier> | yeah |
| 23:58 | <Hixie> | which up to now has had the syntax (x, y) or (path, x, y) |
| 23:59 | <Hixie> | everything else that optionally takes a path becomes (), (path), (fillRule), (path, fillRule) |
| 23:59 | <Hixie> | so where the heck do i put the fillRule on isPointInPath? |