| 00:00 | <isherman> | Hixie: What are your thoughts on adding cc-type to the autocomplete type hint spec? |
| 00:00 | <isherman> | We definitely want to support autofilling this data in Chrome, and at the same time we'd really prefer to remain consistent with the hint types listed in the spec… |
| 00:01 | <Hixie> | i think i have pending feedback for it |
| 00:02 | <Hixie> | i expect i'll add it, but it seems the most magical in terms of what browsers are to do with the values |
| 00:02 | <Hixie> | and so the least likely to work reliably |
| 00:02 | <Hixie> | we should imho provide some commentary in the spec regarding what reasonable values might be |
| 00:02 | <Hixie> | and how a browser might want to convert from one set to another |
| 00:03 | <Hixie> | also would this be the first time we have something that could be autocompleted that's a radio button? |
| 00:03 | <Hixie> | should it complete each button in the group separately, or is the group somehow magically supposed to be treated as one? |
| 00:03 | <Hixie> | isherman: ^ |
| 00:04 | <isherman> | I think it's the first time that we could (reasonably) be filling a radio button, yes |
| 00:04 | <isherman> | I'm not following your question about the group |
| 00:05 | <isherman> | I don't think this is more magical than filling any other <select> dropdown though — especially country and state names, which might be localized |
| 00:05 | <Hixie> | say you have <input type=radio name=a autocomplete="section-foo cc-card" value=visa> <input type=radio name=a autocomplete="section-bar cc-card" value=mastercard>, and in section "foo" the user selected a visa and in section "bar" he selected a mastercard |
| 00:05 | <Hixie> | which radio button do you select? |
| 00:06 | <Hixie> | each radio button can give its own autocomplete attribute, unlike with <select> |
| 00:07 | <isherman> | Hmm, interesting |
| 00:07 | <isherman> | I'm having a hard time understanding why a website would ever use markup like that, though... |
| 00:07 | <Hixie> | hahaha |
| 00:07 | <Hixie> | see the /topic |
| 00:07 | <Hixie> | and welcome to the web |
| 00:07 | <isherman> | heh |
| 00:07 | <isherman> | So the way that radio buttons are grouped is by name? |
| 00:07 | <Hixie> | yeah |
| 00:07 | <isherman> | (I'm not actually very familiar with radio buttons...) |
| 00:08 | <isherman> | That's… interesting |
| 00:08 | <Hixie> | i'm not saying it'll be common, but we should at least give guidance, if not strict normative requirements on how this should be handled |
| 00:08 | <Hixie> | radio buttons are very "interesting", yeah |
| 00:08 | <Hixie> | fwiw what we did with required="" IIRC is that each one is handled separately, but each one looks at the group. |
| 00:08 | <Hixie> | so if one radio button is required and another is not, and neither is checked, the one that's required will be :invalid and the other won't. But if one is checked, then both will be fine. |
| 00:09 | <Hixie> | regardless of which is checked |
| 00:09 | <Hixie> | but that doesn't help us hugely here |
| 00:09 | <Hixie> | with the default checked="" what happens is you check each one that is checked="" as you insert it, IIRC |
| 00:09 | <Hixie> | so the last one inserted wins |
| 00:09 | <isherman> | I'm tempted to say that if there are mismatches between autocomplete attributes on buttons in the same group, we would just want to treat that as bad input (i.e. we'd have unspecified behavior) |
| 00:09 | <Hixie> | we specify behaviour for bad input |
| 00:10 | <Hixie> | that's kind of our thing :-) |
| 00:10 | <Hixie> | but we can certainly say that if all the radio buttons in a group don't have exactly matching autocompletes, you ignore the whole lot |
| 00:10 | <Hixie> | (of radio buttons) |
| 00:10 | <isherman> | yeah, that seems reasonable :) |
| 00:10 | <Hixie> | or that you treat each one on a case by case basis, deciding check/no-check |
| 00:10 | <Hixie> | and last one wins |
| 00:10 | <Hixie> | last one checked wins, that is |
| 00:11 | <Hixie> | i can come up with something arbitrary, if you don't have a strong opinion on this |
| 00:11 | <Hixie> | the other thing is what values should we tell UAs to expect here? |
| 00:11 | <isherman> | I don't think that case-by-case is likely to be helpful here — it makes it more likely that a site author would test their page and think things are working, because they happened to test with the one case that worked |
| 00:11 | <Hixie> | yeah that makes sense |
| 00:12 | <Hixie> | re values -- "visa" "mastercard" "discover" etc ? "v", "m", "d" etc? 4, 5, 3 etc? What do people do? |
| 00:12 | <isherman> | I think people mostly use something like fully spelled out values |
| 00:12 | <isherman> | But we don't really provide guidance on what values <select>s have, and I think there are similar problems there |
| 00:13 | <isherman> | Ideally you'd have a <label> for the <input>, and that label would be a human-readable name, like "Visa" |
| 00:13 | <Hixie> | presumably the UA isn't looking at the label, though, right? |
| 00:13 | <Hixie> | or is it? |
| 00:13 | <isherman> | Chrome looks at the label |
| 00:14 | <Hixie> | wow |
| 00:14 | <Hixie> | that's interesting |
| 00:14 | <isherman> | It's the first thing we check |
| 00:14 | <isherman> | Then the name, then the value |
| 00:14 | <Hixie> | for cc-type? |
| 00:14 | <Hixie> | or generally? |
| 00:14 | <isherman> | generally |
| 00:14 | <Hixie> | huh |
| 00:15 | <isherman> | Well, that's when trying to infer the field's type |
| 00:15 | <Hixie> | oh |
| 00:15 | <Hixie> | i mean when there's an autocomplete="" attribute |
| 00:15 | <isherman> | For filling, the only parallel case is <select> dropdowns |
| 00:15 | <isherman> | and there, we look at the human-readable text first, I think |
| 00:15 | isherman | checks that |
| 00:16 | <isherman> | Mmm, looks like we look at the value first, but then at the human-readable text immediately after that |
| 00:17 | <isherman> | For radio buttons, the only human readable text is the <label>, right? |
| 00:17 | <Hixie> | well |
| 00:17 | <Hixie> | most pages sadly don't have a label |
| 00:17 | <Hixie> | they just do e.g. <p><input...> label</p> |
| 00:17 | <isherman> | right |
| 00:18 | <isherman> | Chrome uses heuristics to try to pick out that sort of label |
| 00:18 | <Hixie> | that's human readable, but i don't think we want to even remotely go there |
| 00:18 | <Hixie> | yikes |
| 00:18 | <Hixie> | we're not hoping for much interop on this feature then i assume :-P |
| 00:18 | <isherman> | But if you're specifying autocomplete type hints, you should use a <label> too |
| 00:18 | <Hixie> | i would have expected the UA to only look at value="", but that's another story |
| 00:19 | <isherman> | I'd love to not have the heuristics to parse out labels, but Chrome Autofill started out as 100% heuristics |
| 00:19 | <Hixie> | yeah |
| 00:19 | <Hixie> | i hate that we're basically half specifying this feature. One half precise detail, the other half dark magic that each UA has to determine for itself. |
| 00:19 | <Hixie> | (but i don't see a good alternative) |
| 00:19 | <isherman> | Yeah :/ |
| 00:20 | <Hixie> | anyway |
| 00:20 | <Hixie> | long story short, go ahead with cc-type, and i'll spec it when i get to that part of the spec |
| 00:20 | <isherman> | ok, sounds good |
| 00:20 | <isherman> | thanks |
| 00:21 | <Hixie> | let's say that if radio buttons in a group have different autocomplete attributes, we just forget about the attribute altogether |
| 00:21 | <isherman> | yeah, that sounds reasonable |
| 00:21 | <Hixie> | and don't autocomplete that group |
| 00:21 | <Hixie> | as if it's false |
| 00:21 | <Hixie> | off |
| 00:21 | <Hixie> | whatever it's called |
| 00:21 | <isherman> | the one possible exception is if one of the buttons has an autocomplete attribute, and the rest are empty |
| 00:21 | <Hixie> | hm yeah |
| 00:21 | <isherman> | should we give that special treatment? |
| 00:21 | <Hixie> | maybe only look at the buttons with the attribute |
| 00:21 | <Hixie> | to determine the group's type |
| 00:22 | <isherman> | yeah, that sounds reasonable to me |
| 00:22 | <Hixie> | if all the specified values are agreed, they apply to the entire group, otherwise hte entire group is off |
| 00:22 | <Hixie> | i guess this happens after the attribute is parsed? |
| 00:22 | <Hixie> | so e.g. autocomplete="section-a section-b name" and "section-b section-a name" are the same? |
| 00:23 | <Hixie> | (order doesn't matter right?) |
| 00:23 | <Hixie> | (or can there not even be wo sections) |
| 00:23 | <Hixie> | (i forget) |
| 00:23 | <isherman> | there can't be multiple sections |
| 00:23 | <Hixie> | then autocomplete="shipping name" vs "shipping name" |
| 00:23 | <Hixie> | (different numbers of spaces) |
| 00:23 | <Hixie> | i'm saying, compare after processing |
| 00:24 | <isherman> | right, that makes sense |
| 00:26 | <isherman> | For filling, the best idea I have is for the spec to strongly recommend <label> elements, and otherwise fall back to the UA's black magic. |
| 00:26 | <isherman> | Asking websites to change their input values is too invasive, since it has implications for the backend (DB) |
| 00:27 | <isherman> | and it doesn't look like there's anywhere else that the values could reasonably be specified — though perhaps I'm overlooking an appropriate attribute |
| 00:29 | <Hixie> | don't most sites use icons? |
| 00:30 | <isherman> | That's a good point |
| 00:30 | <isherman> | I have no good ideas then :/ |
| 00:30 | <Hixie> | heh |
| 00:30 | <Hixie> | we should look to see what values sites typically use |
| 00:30 | <Hixie> | maybe it's more uniform than we think |
| 00:31 | <isherman> | ok, I'll keep an eye out for it |
| 00:32 | <isherman> | unfortunately, this isn't one of the types that we used to fill, so we don't have a lot of regression test data for it |
| 00:32 | <Hixie> | ...and of course all the sites i just checked aren't dumb and work out the card type themselves -_- |
| 00:32 | <isherman> | FWIW, I think most of the sites I've seen asking for CC type recently have been using <select> dropdowns rather than radio buttons |
| 00:32 | Hixie | tries some florists instead |
| 00:33 | <Hixie> | christ this is a painful checkout process interflora |
| 00:33 | <isherman> | heh |
| 00:33 | <Hixie> | blimey that's a lot of fields before i can type in credit card info |
| 00:34 | isherman | is wondering whether it would be better to just not support autocomplete type hints on radio buttons after all, given how hard it is to come up with anything sane for filling them… |
| 00:34 | <Hixie> | hey btw is there a way to tell chrome to autofill passwords even on sites with autocomplete=off? |
| 00:34 | <isherman> | (and just recommend using <select> instead) |
| 00:34 | <Hixie> | drives me crazy that these sites don't trust my browser |
| 00:35 | <isherman> | Peter Kasting wrote an extension to help with that — one sec |
| 00:35 | <isherman> | https://chrome.google.com/webstore/detail/autocomplete-on/ecpgkdflcnofdbbkiggklcfmgbnbabhh?hl=en-AU |
| 00:36 | Hixie | installs |
| 00:36 | <Hixie> | ok this site uses "MasterCard", "Visa", and "AmEx" |
| 00:40 | <Hixie> | ok seriously all these merchants redirect me to ebay when i click buy |
| 00:40 | <Hixie> | not helpful |
| 00:41 | <isherman> | paypal, or straight-up ebay? |
| 00:42 | <Hixie> | ebay |
| 00:42 | <Hixie> | ok i give up, these sites all want way more information than i'm willing to spend time faking before showing me the credit card form |
| 00:43 | <Hixie> | anyway, yeah, if you're ok with not doing radio buttons, i am too |
| 00:43 | <Hixie> | i can just say autocomplete isn't allowed on radio buttons |
| 00:43 | <isherman> | I'd be fine with that |
| 00:43 | <Hixie> | oh i already have in fact |
| 00:43 | <Hixie> | that was easy |
| 00:43 | <Hixie> | moving on! |
| 00:44 | <isherman> | heh |
| 00:44 | <isherman> | where does it say that? |
| 00:46 | <Hixie> | under type=radio, "The following content attributes must not be specified and do not apply to the element: accept, alt, autocomplete, ...." |
| 00:46 | <isherman> | ah, ok :) |
| 00:47 | <isherman> | (I was looking at the autocomplete part of the spec, not the radio button part of the spec) |
| 00:48 | <Hixie> | crap, out of battery. back in an hour or so. |
| 00:48 | <Hixie> | i'll probably add cc-type tonight |
| 00:48 | <Hixie> | bbl |
| 00:51 | <zewt> | Hixie: from my perspective: it's my choice whether forms should autocomplete, sites should have no say in the matter |
| 01:01 | <TabAtkins> | Hixie: Discussed anchor positioning, and posted a response to the list thread with conclusions. |
| 01:09 | <MikeSmith> | othermaciej: if you're around can you please gimme editbugs on bugs.webkit.org? I have a patch with some tests that I'd like to get reviewed. |
| 01:09 | <othermaciej> | MikeSmith: ok |
| 01:10 | <MikeSmith> | thanks |
| 01:10 | <othermaciej> | done |
| 01:17 | <MikeSmith> | othermaciej: thanks much |
| 01:27 | <Hixie> | TabAtkins: thanks |
| 01:27 | <Hixie> | zewt: yeah, well, the reality is that unless you can convince all the browsers to do that, the banks are holding each one hostage by refusing to be compatible with browsers that don't support =off |
| 05:10 | <rniwa> | Hixie: it seems like http://lists.whatwg.org/options.cgi/whatwg-whatwg.org is broken. |
| 05:10 | <rniwa> | Hixie: it doesn't send either password remainder or unsubscribe email :/ |
| 05:10 | <rniwa> | Hixie: i'm pretty much stuck receiving emails on my old email address. |
| 05:10 | <Hixie> | odd |
| 05:12 | <Hixie> | what's the address and what do you want done to it? |
| 05:27 | <rniwa> | Hixie: i want to unsubscribe it on rniwa @ webkit.org |
| 05:28 | <rniwa> | Hixie: and add my @apple.com address instead. |
| 05:28 | <rniwa> | Hixie: adding part is easy. |
| 05:28 | <Hixie> | rniwa @ webkit.org is not subscribed |
| 05:28 | <Hixie> | so that explains that :-) |
| 05:28 | <rniwa> | Hixie: huh, odd :/ |
| 05:28 | <rniwa> | Hixie: so it did delete me |
| 05:28 | <Hixie> | nor is the other one, fwiw |
| 05:28 | <rniwa> | Hixie: despite of the fact it said emailed me. |
| 05:31 | <Hixie> | rniwa: mailman is a mess, and this version of it doubly so |
| 05:32 | <Hixie> | but it is essentially free, so what can one do ;-) |
| 05:35 | <karlcow> | and http://www.sympa.org/ |
| 05:37 | <karlcow> | http://www.sympa.org/release_note last realease note 6.1.16 November 16, 2012 |
| 07:38 | <rniwa> | Hixie, MikeSmith: I'm back to the business on WHATWG, HTML5, & WebApps :D |
| 08:01 | <MikeSmith> | rniwa: excellent, man |
| 08:01 | <MikeSmith> | glad you're back |
| 08:01 | <kochi_> | welcome back, niwa-san |
| 08:02 | <rniwa> | kochi_, MikeSmith: thanks. |
| 08:03 | <kochi_> | I may ask you review webkit cl in near future. |
| 08:03 | <rniwa> | kochi_: LOL. |
| 08:03 | <rniwa> | kochi_: ok. |
| 08:03 | <kochi_> | i am working on ime api. |
| 08:04 | <rniwa> | kochi_: in js? |
| 08:04 | <MikeSmith> | oh hey it's kochi_ ! |
| 08:04 | <kochi_> | hi Mike |
| 08:04 | <rniwa> | kochi_: or yet-another webkit browser? |
| 08:04 | <kochi_> | rniwa: yes, i am taking over hbono's spec'ing work for W3C IME API |
| 08:04 | <MikeSmith> | kochi_: hey, hadn't seen you here before |
| 08:05 | <rniwa> | kochi_: ah, i see. |
| 08:05 | <rniwa> | kochi_: so... this is something i said while i was still at google |
| 08:05 | <rniwa> | kochi_: but we need to make sure that IME API works well on all devices |
| 08:05 | <kochi_> | so very probably i have to make some addition in IDL |
| 08:05 | <rniwa> | kochi_: including iOS devices. |
| 08:06 | <rniwa> | kochi_: where IME isn't really a thing. |
| 08:07 | <kochi_> | mike: yes, I've been around in this room for a while but this is first to speak here. |
| 08:07 | <MikeSmith> | cool |
| 08:08 | <kochi_> | rniwa: yeah, but if we cover all the devices, spec cannot define anything useful... |
| 08:09 | <kochi_> | I guess on iOS the operating system is taking care of most thing for IME and apps can control very little |
| 08:09 | <rniwa> | kochi_: i think we need to do that though. |
| 08:10 | <rniwa> | kochi_: else, developers to have to write two completley different code paths for desktop & mobile devices |
| 08:10 | <kochi_> | you can add external IME interface on iOS to control from browser:) |
| 08:10 | <rniwa> | kochi_: what if we came up with yet another way of typing in text? |
| 08:11 | <rniwa> | kochi_: i don't think making iOS and Android devices behave like desktop devices is the way to go. |
| 08:11 | <rniwa> | kochi_: we need to make sure new APIs behave nicely with mobile devies |
| 08:11 | <rniwa> | kochi_: instead of devices behave well with APIs |
| 08:11 | <rniwa> | making* |
| 08:12 | <rniwa> | kochi_: but i haven't had a chance to look into the details of the API to make concrete suggestions :( |
| 08:12 | <rniwa> | kochi_: there is the latest spec hosted? |
| 08:12 | <rniwa> | where* |
| 08:13 | <kochi_> | http://www.w3.org/TR/ime-api/ |
| 08:13 | <kochi_> | this is the published latest, but |
| 08:13 | <MikeSmith> | ED is at http://dvcs.w3.org/hg/ime-api/raw-file/default/Overview.html |
| 08:14 | <kochi_> | mike: the link is still the same as the published one. |
| 08:14 | <kochi_> | http://dvcs.w3.org/hg/ime-api/raw-file/default/TR.html |
| 08:15 | <kochi_> | is the latest. |
| 08:15 | <kochi_> | the difference is in "6. Composition Dictionary" |
| 08:15 | <MikeSmith> | ah OK |
| 08:15 | <kochi_> | text and caret are no longer special interface, but DOM node and range. |
| 08:18 | <rniwa> | kochi_, MikeSmith: is developing IME on js still a thing? |
| 08:18 | <rniwa> | as far as I know, baidu dropped the feature from their website. |
| 08:19 | <Ms2ger> | kochi_, can you please update the one that doesn't say "TR", give it the ED style, and update the date? |
| 08:22 | <rniwa> | kochi_: i've gotten more skeptical about IME in js since baidu stopped doing it. |
| 08:24 | <MikeSmith> | Ms2ger: I will do that |
| 08:25 | <MikeSmith> | rniwa: I think that after the feedback at the WebApps WG f2f, addressing the IME-in-js use case has become a lower priority |
| 08:25 | <rniwa> | MikeSmith: ok. good. |
| 08:32 | <kochi_> | sorry, i was distracted a bit |
| 08:34 | <rniwa> | strange :/ |
| 08:34 | <rniwa> | i can never unsubscribe from public-html⊙wo |
| 08:37 | <kochi_> | rniwa: I didn't know baidu javascript ime |
| 08:38 | <kochi_> | did they try to implement their IME in js? |
| 08:39 | <kochi_> | Found this one: http://ime.baidu.jp/type/about/onlineime.html |
| 08:39 | <kochi_> | they provide a bookmarklet that can work as IME for other sites. |
| 08:39 | <MikeSmith> | kochi_: they had one on their main search engine before |
| 08:40 | <rniwa> | kochi_: they had one on baidu.com without requring any plugsin |
| 08:40 | <MikeSmith> | they were maybe the first big site that had something like that |
| 08:40 | <MikeSmith> | it would be interesting to find out why the yanked it |
| 08:41 | <kochi_> | they bought simeji, which is another IME for Japanese (though for Android) and they might have changed the strategy |
| 08:41 | <MikeSmith> | rniwa: I think the IME-in-js is rightly lower-priority but at the same time I think you guys are maybe being a bit too harsh on it |
| 08:41 | <MikeSmith> | kochi_: ah, OK |
| 08:41 | <rniwa> | MikeSmith: i mean there could be some compelling use cases |
| 08:41 | <rniwa> | MikeSmith: but given the complexity it adds to the platform |
| 08:41 | <rniwa> | MikeSmith: they got to be really compelling. |
| 08:42 | <rniwa> | MikeSmith: using IME correctly is really hard. |
| 08:42 | <MikeSmith> | rniwa: agreed. but at least I think othermaciej is being too harsh in pretty much categorically denying there's ever a good reason to do it |
| 08:42 | <rniwa> | MikeSmith: implementing IME is even harder. |
| 08:42 | <rniwa> | MikeSmith: i don't think so. i think he was emphasizing the fact it's hard to get IME right. |
| 08:42 | <MikeSmith> | yeah, agreed there too. You really can't do it well in JS |
| 08:43 | <MikeSmith> | yeah, there's a lot you need to sacrifice if you do it, I think |
| 08:43 | <rniwa> | MikeSmith: right. |
| 08:43 | <rniwa> | MikeSmith: i would have been convinced if baidu had to do that for their users, etc... |
| 08:43 | <rniwa> | MikeSmith: but now that they've moved away from it |
| 08:43 | <MikeSmith> | yup |
| 08:43 | <kochi_> | rniwa: some simple IME such as simple transliteration can be a compelling use case. |
| 08:43 | <rniwa> | MikeSmith: there isn't any big website providing such a feature now. |
| 08:43 | <rniwa> | kochi_: why would you want to implement that as an IME? |
| 08:44 | <rniwa> | kochi_: sounds like you want to use some other mechanism for it. |
| 08:44 | <MikeSmith> | rniwa: what about Google Translate? It has those keyboard widgets. Which admittedly are not full IMEs |
| 08:44 | <kochi_> | rniwa: do we have any way to do that in current JS? |
| 08:44 | <rniwa> | kochi_: well, the question i'm asking is why you'd ever want to implement transliteration as an IME. |
| 08:45 | <rniwa> | kochi_: that doesn't sound like a good idea. |
| 08:45 | <rniwa> | kochi_: i've done many transliteration myself and it doesn't really fit the way IME works |
| 08:46 | <rniwa> | kochi_: when you're doing transliteration, you have to re-order words and sentences, or even the entire paragraphs. |
| 08:46 | <rniwa> | kochi_: consider transliterating something from English to Japanese or Japanese to English. |
| 08:46 | <rniwa> | kochi_: it's almost never the case that you can just replace Japanese word by its equivalent in English |
| 08:47 | <rniwa> | kochi_: you have to re-order almost everything |
| 08:47 | <rniwa> | kochi_: just like UBA would do on each bidi-level |
| 08:47 | <kochi_> | rniwa: i supposed simpler ones, like ta -> 'た' |
| 08:47 | <rniwa> | kochi_: oh, that's basically IME, right? |
| 08:48 | <rniwa> | kochi_: it's like pinyin or yamli |
| 08:48 | <kochi_> | rniwa: I might be confused.. |
| 08:48 | <rniwa> | kochi_: i mean ta -> た is just a romaji conversion |
| 08:48 | <rniwa> | kochi_: i wouldn't call that transliteration. |
| 08:49 | <kochi_> | rniwa: ok, i used 'transliteration' as just a simple 1:1 or some:1 mapping |
| 08:49 | <rniwa> | kochi_: oh, maybe i'm the one misusing the term :. |
| 08:49 | <rniwa> | :/ |
| 08:49 | <rniwa> | sorry, |
| 08:50 | <rniwa> | okay, yeah. |
| 08:50 | <kochi_> | rniwa: probably you meant 'translation' |
| 08:50 | <kochi_> | :) |
| 08:50 | <rniwa> | I meant literal translation |
| 08:50 | <rniwa> | anyway |
| 08:50 | <rniwa> | kochi_: i mean that has the same problem as regular IMEs |
| 08:51 | <rniwa> | kochi_: what are compelling use cases for implementing transliteration in JS? |
| 08:53 | <kochi_> | rniwa: okay, that is same as Japanese IME on English-only environment.. |
| 08:53 | <SimonSapin> | rniwa: I think that romaji → hiragana would be "transliteration", and maybe romaji → kanji too. English → Japanese is "translation". |
| 08:54 | <rniwa> | SimonSapin: not sure romaji -> kanji is really transliteration :/ |
| 08:54 | <rniwa> | SimonSapin: the number of characters change there. |
| 08:54 | <kochi_> | rniwa: romaji to hiragana also changes the number of characters :/ |
| 08:54 | <SimonSapin> | yeah, and there is more than one possible answer. That’s why I said maybe |
| 08:55 | <SimonSapin> | changing the number of characters is not really a problem for transliteration |
| 08:55 | <kochi_> | anyway, |
| 08:57 | <rniwa> | kochi_, SimonSapin: ok. |
| 08:57 | <MikeSmith> | rniwa: hmm, I just re-noticed that Google Translate does in fact still have a custom IME for Japanese and Chinese input. Not just the simpler keybaord thingey it has for other languages. |
| 08:58 | <kochi_> | implementing IME in JS may have more difficulties than merits, so low-priority now. |
| 08:58 | <MikeSmith> | if you click that "Allow phonetic typing" checkbock |
| 08:58 | <MikeSmith> | *checkbox |
| 08:58 | <rniwa> | MikeSmith: oh yeah :/ |
| 08:59 | <zcorpan> | heycam|away: re https://www.w3.org/Bugs/Public/show_bug.cgi?id=18909 the script in comment 1 moved to http://resources.whatwg.org/file-bug.js |
| 09:00 | <MikeSmith> | rniwa: but even if you check it, it only appears if you have your system IME off. Which is the right behavior I guess. |
| 09:00 | <MikeSmith> | kochi_: yeah, I think the positioning use-case is by far the biggest priority |
| 09:00 | <kochi_> | MikeSmith: maybe translate is using the same one as http://www.google.co.jp/transliterate/japanese |
| 09:02 | <MikeSmith> | kochi_: ok |
| 09:02 | <MikeSmith> | kochi_: and it's not clear to me yet how to practically spec and implement a positioning-control mechanism for the system IME |
| 09:02 | <rniwa> | MikeSmith: i don't think we should spec that... |
| 09:03 | <rniwa> | MikeSmith: since it really depends on how system IME works. |
| 09:03 | <MikeSmith> | hmm |
| 09:03 | <MikeSmith> | well that's the main problem that we all seem to want to solve |
| 09:03 | <rniwa> | MikeSmith: well, there's an extent to which we want to allow some freedom to implementors |
| 09:03 | <MikeSmith> | I mean the problem of the system-IME candidate list overlapping the suggest-list from a Web app |
| 09:04 | <rniwa> | MikeSmith: otherwise we'll end up creating another write-once run-nowhere framework |
| 09:04 | <MikeSmith> | rniwa: ah yeah, agreed about that, sure |
| 09:04 | <rniwa> | MikeSmith: oh, sure. |
| 09:04 | <rniwa> | MikeSmith: that, we need to solve. |
| 09:07 | <kochi_> | explicitly controlling the candidate/suggest window position is impossible on some platforms including mobile |
| 09:10 | <zcorpan> | heycam|away: ah i see you included it, ok |
| 09:11 | <rniwa> | kochi_: that's why we have to be very careful here :) |
| 09:12 | <rniwa> | kochi_: hopefully we can refine the API so that it works on those mobile devices as well |
| 09:12 | <MikeSmith> | kochi_: rniwa :yeah but the positioning issue is maybe also different on mobile |
| 09:12 | <rniwa> | MikeSmith: right. |
| 09:12 | <rniwa> | MikeSmith: so we need to come up with some solution that works on both desktop & mobile |
| 09:12 | <MikeSmith> | yeah |
| 09:12 | <rniwa> | MikeSmith: otherwise, we'll be adding yet another craziness to the platform. |
| 09:13 | <rniwa> | given how crazy dealing with IME already is, i don't think we want to complicate it any further. |
| 09:14 | <MikeSmith> | frankly I do most of my Google searches from the browser address bar, and it's the same problem there as it is for the in-app case, but of course we can't the address-bar case through a standards API (not as far as I understand it at least) |
| 09:14 | <kochi_> | one idea might be just JS gives a hint to IME, that JS wants to use some UI property for typing help (suggest etc.) |
| 09:15 | <kochi_> | MikeSmith: yes, chrome's omnibox has some code for controlling IMEs (for windows only) |
| 09:15 | <rniwa> | kochi_: that's an interesting idea. |
| 09:15 | <rniwa> | kochi_: doesn't chrome's ominibox do something along that line? |
| 09:15 | <rniwa> | omnibox API* |
| 09:16 | <kochi_> | rniwa: you mean chrome extension api for omnibox? |
| 09:16 | <MikeSmith> | rniwa: it doesn't seem to be doing anything smart for me at least. I get overlap with Chrome |
| 09:17 | <rniwa> | MikeSmith, kochi_: no, with respect to instant search |
| 09:17 | <rniwa> | or whatever that flashing pages on key downs |
| 09:17 | <rniwa> | is called. |
| 09:17 | <MikeSmith> | oh |
| 09:17 | <rniwa> | like.. |
| 09:17 | <rniwa> | when omnibox expands |
| 09:17 | <rniwa> | the google.com moves the results down so that it's still visible to the user. |
| 09:18 | <MikeSmith> | yeah |
| 09:18 | <zcorpan> | do i understand correctly from http://www.score.is.tsukuba.ac.jp/~minamide/papers/minamide-FM2012.pdf that they didn't implement AAA? |
| 09:18 | <MikeSmith> | rniwa: I have seen that behavior for some cases but not in others where I would expect it |
| 09:19 | <zcorpan> | "However, we exclude formatting elements from our formalized specification be- |
| 09:19 | <zcorpan> | cause of difficulties with the destructive manipulation of the stack." |
| 09:19 | <kochi_> | yeah, the instant integration for omnibox isn't so great. |
| 09:19 | <kochi_> | (especially for IME using languages) |
| 09:20 | <MikeSmith> | zcorpan: hmm, is that what they meant by that? It wasn't clear to me. But I guess I don't know what else they could have meant by it. |
| 09:20 | <rniwa> | zcorpan: that's pretty lame... |
| 09:21 | <rniwa> | zcorpan: those manipulation of the stack is what makes html5 parsing algorithm interesting. |
| 09:21 | <rniwa> | s/those/that/ |
| 09:21 | <kochi_> | MikeSmith: do you use windows version of chrome? |
| 09:22 | <MikeSmith> | kochi_: rniwa : so as far as mobile, on my Android handset I do most of my searches from the devicse homescreen using the Google widget. And there at least I notice they seem to have a semi-smart way of handling it, in that the system IME doesn't completely obscure the system IME. It gives you separately scrollable areas for each. |
| 09:24 | <MikeSmith> | kochi_: no, I use the mac version of Chrome. And I also build Chromium on mac from the sources, and use that quite a lot. Because it's faster, for one thing :) |
| 09:24 | <MikeSmith> | I don't have a Windows environment at all these days |
| 09:25 | <kochi_> | MikeSmith: unfortunately mac version of omnibox doesn't control IME |
| 09:25 | <MikeSmith> | ah, OK |
| 09:25 | rniwa | away |
| 09:25 | <kochi_> | thanks rniwa-san for your input! |
| 09:26 | <rniwa|away> | kochi_: np. i'll try to find a time to read the spec. |
| 09:26 | <kochi_> | thanks again! |
| 09:28 | <MikeSmith> | (for the record so that nobody gets PO'ed at me, I also run Firefox and Nightly releases, and build and run a Mozilla Nightly from sources. And run two versions of Opera, and would build that from sources too, if I could. And run Safari too. Though sadly can't run WebKit nightlies any more due to the requirement to have OS X 10.7 for that.) |
| 09:28 | <hsivonen> | uh oh: https://bugzilla.mozilla.org/show_bug.cgi?id=116882#c4 |
| 09:29 | <MikeSmith> | hsivonen: wow. Never knew about that one before. |
| 09:31 | <MikeSmith> | hmm yeah https://bug116882.bugzilla.mozilla.org/attachment.cgi?id=64382 ain't so pretty. Unless like the aesthetic quality of the diamond-with-question-mark glyph a lot. |
| 09:32 | <MikeSmith> | hsivonen: wha? this is an old bug though. So what did the fix end up being? |
| 09:33 | zcorpan | glosses over most of section 3 |
| 09:35 | <hsivonen> | MikeSmith: the fix ended up being that bogus byte sequences in Shift_JIS produce middot instead of REPLACEMENT CHARACTER |
| 09:36 | <hsivonen> | hmm. annevk is not on IRC |
| 09:37 | <MikeSmith> | hsivonen: ah, OK |
| 09:37 | <Ms2ger> | Hm |
| 09:38 | <Ms2ger> | Didn't emk just file a bug to revert that? |
| 09:38 | <Engin> | darobin: btw, I got what you meant wrong the other day. Yes, using POST on a fixed URL to conduct cross domain communication is a good idea. As it requires a single preflight sequence. |
| 09:38 | <Ms2ger> | Oh no, you filed it years ago |
| 09:39 | <hsivonen> | Ms2ger: right |
| 09:39 | <darobin> | Engin: that would be my hope yes, if implementations support the spec correctly |
| 09:39 | <Engin> | darobin: I checked, it works. |
| 09:40 | <Engin> | with chrome, at least. |
| 09:40 | <darobin> | Engin: sweet |
| 09:40 | <zcorpan> | hsivonen: also https://bugzilla.mozilla.org/show_bug.cgi?id=127275 |
| 09:40 | <MikeSmith> | hsivonen: btw after seeing a recent Hixie checkin, I'm only just now noticing the baroque set of values that constitute the microsyntax for the autocomplete attribute. Is anybody actually implementing support for any of that stuff? |
| 09:40 | <darobin> | I wonder if we have a test for preflight caching |
| 09:40 | <zcorpan> | MikeSmith: it's pretty new i think |
| 09:41 | <Ms2ger> | [eta 8/28] |
| 09:41 | <MikeSmith> | zcorpan: ah, OK |
| 09:41 | <Engin> | darobin: that approach brings the best of both worlds... being able to use XHR for cross domain means 1) better error handling 2) as HTTP POST is available you can send big loads of data as opposed to GET only JSONP approach has about 2k limit |
| 09:41 | <Ms2ger> | I wonder which year |
| 09:41 | <MikeSmith> | hsivonen: for reference, http://www.whatwg.org/specs/web-apps/current-work/multipage/association-of-controls-and-forms.html#autofilling-form-controls:-the-autocomplete-attribute |
| 09:41 | <Ms2ger> | Looks like 2002 |
| 09:41 | <darobin> | Engin: sure, for that sort of API POST is really the way to go |
| 09:41 | <Engin> | and given that CORS is already implemented in IE8, Chrome and FF is a good market penetration. |
| 09:42 | <Engin> | but this spec renders most of the framework designs inefficient. |
| 09:43 | <Engin> | i.e. many MVC frameworks has the design pattern to create uniqwue resources for everything... if you use those frameworks to build your API, your API has too much overhead for cross domain communication |
| 09:43 | <jgraham> | darobin: Still looking for me? |
| 09:43 | <darobin> | jgraham! |
| 09:43 | <Engin> | I still don't see why specs don't allow domain wide access control... and override when necessary for each resources, as each request has Origin header in it, access control be done per resource and can override server wide rules. |
| 09:44 | <darobin> | jgraham: I was wondering if you had some more finalised ideas on how to reorg the HTML test suite than when we last talked |
| 09:44 | <darobin> | given that I have time to do it now |
| 09:45 | <MikeSmith> | holy god reading through that autocomplete stuff it's hard to see it as anything but serious overengineering. on the fact of it, at least |
| 09:45 | <Ms2ger> | I hear krisk wants to talk about it tonight |
| 09:45 | <MikeSmith> | *face of it |
| 09:45 | <jgraham> | darobin: Yeah, so appasrently we are discussing it again on yet another IRC meeting today; see Kris' message to public-html-testsuite |
| 09:45 | <jgraham> | *apparently |
| 09:45 | <Ms2ger> | I have been lucky enough to miss the previous meetings :) |
| 09:45 | <darobin> | Ms2ger, jgraham: yup but unfortunately while you're talking about it tonight I'll be at a conference |
| 09:46 | <Ms2ger> | Can we just put everything in dirs per section already? |
| 09:46 | <darobin> | but that's no reason not to get stuff done before then :) |
| 09:47 | <darobin> | Ms2ger: I want to do that, I've just been wondering about the best way to do it |
| 09:47 | <jgraham> | Yeah, directories per section, with a short name derived from the section name, in some reasonable depth of heirachy |
| 09:47 | <jgraham> | Is, I think, what people were happy with |
| 09:47 | <darobin> | one way is to just have one dir per root section, which leads to huge numbers of tests in some; at the other end there's the option of one dir all the way to every h6 section, which is a bit deep |
| 09:48 | <jgraham> | Well |
| 09:48 | <Ms2ger> | darobin, I've gone 3 deep, fwiw |
| 09:48 | <jgraham> | I think it should to some extent be up to individuals |
| 09:48 | <darobin> | derived short name: I think the easiest is to just use the ID in the spec, with some replacement |
| 09:48 | <jgraham> | But one per top level section doesn't help much |
| 09:48 | <hsivonen> | MikeSmith: I haven’t followed the autocomplete stuff |
| 09:48 | <jgraham> | The id in the spec doesn't work |
| 09:48 | <hsivonen> | MikeSmith: volkmar might have followed it |
| 09:48 | <MikeSmith> | ok |
| 09:49 | <jgraham> | Because it's autogenerated. And not always very readable |
| 09:49 | <darobin> | jgraham: the problem of leaving it up to individuals is that it can lead to cases where someone starts putting stuff at level 1 because there aren't that many tests, and then we have to move stuff to subsections because it's getting crowded |
| 09:49 | <zcorpan> | MikeSmith: also nice that the spec includes timbl's cc number, expiration date and cvc |
| 09:49 | <MikeSmith> | zcorpan: heh |
| 09:49 | <darobin> | I'd like to avoid having to move tests as much as possible, ever if possible |
| 09:49 | <darobin> | Ms2ger: 3 deep wfm |
| 09:49 | <jgraham> | darobin: Well I agree with that |
| 09:50 | <darobin> | jgraham: most of them are reasonably readable methinks; they're generated from the section title initially |
| 09:50 | <darobin> | using section numbers won't fly very well IMHO |
| 09:50 | <Ms2ger> | darobin, just move my submissions to the top level, and move everything else into the dirs I have set up, then ;) |
| 09:50 | <jgraham> | darobin: Maybe you could generate an actual directory structure to look at and see how well it works |
| 09:51 | <darobin> | jgraham: one of the advantages of using the IDs is that we have all the data that maps from IDs to specific spec pages already generated for us |
| 09:51 | <MikeSmith> | hsivonen, zcorpan : I just really wonder who's asking for all that stuff, and if it has a chance in hell of ever getting implemented cross-browser. Or even any-browser. Especially given that our track record so far for getting new features impelemented in browsers is not exactly a sterling record. |
| 09:51 | <darobin> | jgraham: that's exactly my plan, I just wanted to narrow the options down before doing so |
| 09:51 | <jgraham> | darobin: What are these spec "pages" of which you speak? :p |
| 09:51 | <darobin> | I'll get to it now, thanks |
| 09:52 | <darobin> | jgraham: for the wusses who don't like the single page version, or have devices equipped with less than 16Go ;) |
| 09:53 | <zcorpan> | MikeSmith: http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2012-August/036791.html |
| 09:53 | <MikeSmith> | track record so far for getting new *forms* features |
| 09:54 | <MikeSmith> | zcorpan: thanks |
| 10:18 | <hsivonen> | MikeSmith: pushing stuff from svn.chromium.org to specs |
| 10:20 | <MikeSmith> | hsivonen: well, I think most would agree that ain't the best way to be doing things |
| 10:22 | <MikeSmith> | if that stuff ends up going into iOS prematurely that's gonna suck for all of us |
| 10:24 | <darobin> | MikeSmith: IIRC Mozilla is implementing the inputmode side of things at least, but with different keywords from those in the spec |
| 10:25 | <MikeSmith> | darobin: yeah but that's quite a bit less complicated at least |
| 10:25 | <darobin> | to say the least |
| 10:25 | <MikeSmith> | and I think for that we have basic agreement about the problem and need for a solution |
| 10:25 | <darobin> | but if they felt the need for divergence on the simple bits, the odds that they align to the complex stuff are a bit low |
| 10:26 | <MikeSmith> | yeah |
| 10:26 | <darobin> | seems like an area begging to have a vendor prefix problem a little while down the line |
| 10:34 | <MikeSmith> | darobin: clearly it often makes sense to have concrete spec text to review, even if the outcome is going to be that some implementors say, thanks for giving us something detailed to review but there's no way we are going to implement this any time soon |
| 10:37 | <darobin> | oh sure, far from me to say the contrary |
| 11:01 | <MikeSmith> | the thing of Mozilla unilaterally implementing different keywords is another kind of distressing thing |
| 11:06 | <hsivonen> | MikeSmith: isn’t “go ahead and implement something different” the official way appeal Hixie’s decisions? |
| 11:07 | <hsivonen> | s/way/way to/ |
| 11:09 | <Stevef> | hsivonen: is filing a bug on firefox to implement <main> a reasonable course of action at this stage? |
| 11:11 | <hsivonen> | Stevef: I really don’t know. |
| 11:12 | <Stevef> | hsivonen: anybody that would know? |
| 11:14 | <hsivonen> | Stevef: I don’t think there’s anyone who’d give you a clear and definitive yay or nay |
| 11:14 | <hsivonen> | Stevef: about the processing model... |
| 11:15 | <hsivonen> | Stevef: https://dvcs.w3.org/hg/html-extensions/raw-file/tip/maincontent/index.html says to map <main> to role=main |
| 11:15 | <Stevef> | hsivonen:right |
| 11:15 | <hsivonen> | Stevef: what’s the processing model of multiple role=main occurrences? |
| 11:16 | <hsivonen> | tantek: do you have plans to reply to http://lists.w3.org/Archives/Public/public-html/2012Dec/0027.html ? |
| 11:18 | <Stevef> | hsivonen:for role=main they are all mapped regardless, there is discussion on limiting <main> to one instance, but would be useful to see how it is sued in wild before adding extra complexity (i think) |
| 11:20 | <hsivonen> | Stevef: so what do screen readers do if the user asks to skip to main and there are multiple role=main elements? |
| 11:22 | <Stevef> | hsivoen: well they don't skip to main as such landmarks are presented as a tree they navigate to landmarks using a keystroke or via a list represntation see screenshots and stuff here http://www.paciellogroup.com/blog/2010/10/using-wai-aria-landmark-roles/ |
| 11:25 | <Stevef> | hsivonen: so in the case where a main landmark is not present it is not represented in the tree or in the case where only a main landmark is present pressing the appropiate key would move the user to the start of the main content |
| 11:27 | <Stevef> | hsivonen: thus skipping over any link menus etc |
| 11:29 | <Stevef> | hsivonen: i.e. its the presence of main that provides the 'skip' not the presence on nav etc |
| 11:32 | <MikeSmith> | hsivonen: I would think hope the “go ahead and implement something different” would be reserved for cases where it's clear that Hixie has decided to quit listening and it's become a waste of time to continue trying to discuss it with him |
| 11:39 | <Engin> | darobin: also, if your client library does not introduce custom headers... POST does not require preflight at all (provided that the server sends Access-Control-Allow-Origin header all the time -- otherwise it raises a security exception in the client) |
| 11:51 | <Stevef> | hsivonen: thanks for feedback to list! will sketch out some concept of when browser should map role=main to <main> and when not |
| 12:02 | <hsivonen> | Stevef: FWIW, I’m now writing a patch for <main> for Gecko to see if it really is as easy as I thought |
| 12:05 | <Stevef> | hsivonen: i was able to write a patch for webkit (with help from mike) which was pretty simple i just used the nav implementation as a guide. |
| 12:06 | <Stevef> | hsivonen: it was only a few lines of code, it was the tests that mike did that were the work |
| 12:07 | <hsivonen> | Stevef: I’m not volunteering to write the unit tests for this :-) |
| 12:08 | <Stevef> | hsivonen: MikeSmith is waving :-) |
| 12:24 | <odinho> | If there's several, then I'd take the first and outermost one as primary. |
| 12:25 | <hsivonen> | odinho: what if the first isn’t the outermost? |
| 12:25 | <odinho> | I could see authors doing <header></> <main> <article><header></><main></></article> <article><header></> <main></> </article> </main> <footer> |
| 12:26 | <hsivonen> | hmm. yeah, the idea of copying <article>s into one doc and having <main> in there is a problem |
| 12:30 | <hsivonen> | Stevef: can you test a build with Windows+JAWS if I ask the tryserver to make one? |
| 12:30 | <Stevef> | hsivonen: definitely! |
| 12:33 | <hsivonen> | Stevef: OK. Pushed to try: https://tbpl.mozilla.org/?tree=Try&rev=b8a2d5d608e0 It will take some time for the build to become available. |
| 12:35 | <Stevef> | odinho:hsivonen: webkit has implemented some simple rules for when header/footer should expose landmark roles, same could be done for <main>, but I reckon its worth seeing how it is used first as data from role=main usage are encouraging that devs understand the simple concept of once per page |
| 12:35 | <Stevef> | hsivonen: OK a few hours? |
| 12:37 | <hsivonen> | Stevef: something like that |
| 12:37 | <Stevef> | ok will let you know when i have tested |
| 12:40 | <odinho> | Stevef: Well, some systems will do automatical includes... I'm sure there will be several mains. And also, it can be context dependent, there's the main of the document, and potentially the main of each article etc. |
| 12:50 | <Stevef> | odinho: i hear you, but the data on id usage to indicate main content does not point to its use in that way, but will only know if it is used in the wild |
| 12:55 | <Stevef> | odinho: the spec/conformance requirements are unambiguous which is a start, there is no room for interpretation, the issue with elements like article and section is they are specced to be open to misuse |
| 12:59 | <hsivonen> | \o/ got the <template> spec review off my todo list |
| 13:01 | <MikeSmith> | hsivonen: congrats on that |
| 13:50 | hsivonen | blinked at SVG path checking for a moment before realizing SVG is not PostScript |
| 13:52 | <zcorpan> | is <!-- specced in ES proper yet? |
| 13:58 | <gsnedders> | zcorpan: On the to-do list for ES6, I believe |
| 13:58 | <zcorpan> | ok, thanks |
| 14:02 | <gsnedders> | Though some things in Web ECMAScript may well not get in as IE has never supported them and doesn't feel the heat from not doing so. |
| 14:02 | <gsnedders> | e.g., not supporting __proto__ is hurting them; __defineGetter__ is not. |
| 14:06 | <gsnedders> | Related: https://bugzilla.mozilla.org/show_bug.cgi?id=647423 |
| 14:23 | <Stevef> | hsivonen: tried build <main> works as expected with NVDA and JAWS |
| 14:24 | <hsivonen> | Stevef: great. Thanks. |
| 14:24 | <Stevef> | hsivonen:the parsing behaviour looks ok as well |
| 14:25 | <hsivonen> | (sorry. I have to step away from IRC) |
| 14:25 | <Stevef> | hsivonen: also acc info expsoed when checked suing inspect tool is correct |
| 14:49 | <hsivonen> | Stevef: ok. I'll try to get a bug filed later today |
| 14:50 | <Stevef> | hsivonen: thanks |
| 15:59 | <Ms2ger> | darobin, there's a few tests under submissions/, go ahead :) |
| 16:02 | <darobin> | Ms2ger: I plan to! |
| 16:03 | <Ms2ger> | darobin, I like to believe mine are pretty good ;) |
| 16:13 | <darobin> | Ms2ger: yeah, I was planning on just trashing them |
| 16:14 | <darobin> | if we agree on the new organisation, I'll have to first replay the submissions as pull requests |
| 16:14 | <darobin> | it's a bit of an annoyance but I'm guessing it won't take too long |
| 16:39 | <jgraham> | (to avoid disrupting the htmlt meeting any more, I will mention here that "HTML!" made me think "HTML-factorial? I guess that must have been a Dave Ragget thing") |
| 16:41 | <jgraham> | (I think I might be over-tired) |
| 16:43 | <darobin> | ROFL |
| 16:44 | <gsnedders> | jgraham: There's a solution for this, I believe it's called "going to bed". Certainly, whatever it is, my niece seems not to understand this concept. |
| 16:45 | <Ms2ger> | darobin, not 1 either! |
| 16:46 | <darobin> | :) |
| 17:04 | <MikeSmith> | I think we need a "Like" button for test cases |
| 17:04 | <MikeSmith> | that will make people write more |
| 17:05 | <MikeSmith> | either that or move all test cases to Google+ |
| 17:06 | <Ms2ger> | jgraham, ... by git |
| 17:07 | <Ms2ger> | MikeSmith, anyone uses Google+? |
| 17:07 | <darobin> | Google what? |
| 17:07 | <tantek> | MikeSmith - you should build that - a social network for test cases. You probably know some folks who would happily beta test it for you. ;) |
| 17:07 | darobin | notices that some memes tend to work only for a really small number of people with the right context |
| 17:08 | <tantek> | pitch it as "a social network for enterprise certification" and get some angel funding |
| 17:08 | <MikeSmith> | I just want the Likes |
| 17:08 | <tantek> | exactly - that's the MVP |
| 17:09 | <MikeSmith> | that would be sufficient reward |
| 17:09 | <tantek> | ability to friend, post test cases, and like test cases |
| 17:10 | <tantek> | hmm, actually "test case" as a content posting type could be interesting for the #indiewebcamp crowd. |
| 17:15 | <MikeSmith> | ability to de-friend a test case would be good |
| 17:17 | <jgraham> | A testcase social network would need an "unlike" button for sure |
| 17:17 | <tantek> | and then you make a leaderboard of the most popular test cases and then blam - competition to make better test cases |
| 17:17 | <tantek> | "test case of the week" etc. |
| 17:17 | <jgraham> | It could be automatically checked if "BOM" appeared in the TC title |
| 17:17 | <gsnedders> | jgraham: An unlike button? That's just idealism. |
| 17:18 | <tantek> | people that liked this test case also liked these other test cases... |
| 17:18 | <gsnedders> | tantek: Unfortunately, zcorpan would be the constant winner of "most evil TC". |
| 17:18 | <gsnedders> | So that would get rather dull. |
| 17:18 | <tantek> | of course you'd want to allow anyone to "tag" test cases as well with arbitrary tags, and give each test case its own tag cloud |
| 17:19 | <Ms2ger`> | gsnedders, bz sometimes writes tests too ;) |
| 17:20 | <jgraham> | OMG, they could have a test-off |
| 17:20 | <gsnedders> | Ms2ger`: Ah, but zcorpan's manage to not only be evil in what they test, but in *how* they test it. Testcases in a single file, HTML, CSS, and Javascript, depending on how you parse it. |
| 17:20 | <jgraham> | That would be epic |
| 17:21 | <Ms2ger`> | gsnedders, fair |
| 17:21 | <Ms2ger`> | I've seen too many of those |
| 17:46 | <dglazkov> | good morning, WhatWg! |
| 17:46 | <dglazkov> | sorry for screwing up your rhythm, odinho |
| 17:46 | <Ms2ger`> | Good night, dglazkov |
| 22:17 | <Hixie> | TabAtkins: yt? |
| 22:18 | <Hixie> | anyone know what css spec would define things like text outlines? |
| 22:23 | <Hixie> | looks like css text |
| 22:23 | <SimonSapin> | Hixie: do you mean text-shadow? |
| 22:28 | <Hixie> | i meant text-outline, but text-shadow is in the same spec |
| 22:41 | <SimonSapin> | Hixie: text-shadow is in http://dev.w3.org/csswg/css-text-decor-3/ which was split out of css3-text. I can’t find outline in either |
| 22:44 | <SimonSapin> | Hixie: it’s removed in http://www.w3.org/TR/2011/WD-css3-text-20110901/ |
| 23:16 | <TabAtkins> | Hixie: text-outline doesn't exist in CSS yet. |
| 23:17 | <TabAtkins> | Hixie: There's a -webkit- property for text-stroke, which is what you're talking about (though it's not very good, as it tends to *reduce* the legibility of text if you make it thick enouch to make the text pop against a similar-color background). |
| 23:17 | <TabAtkins> | But 4/8 text-shadows tends to work pretty good for putting an outline on text. |
| 23:44 | <Hixie> | TabAtkins: k |