| 08:38 | <asmodai> | Damn, must say that Opera mobile at least works very well on my tablet. |
| 10:33 | <smaug____> | Does Dart already run in Chromium ? |
| 10:50 | <kapowaz> | Hello there. I'd like to share some thoughts regarding input[type=date], and how the HTML standard for these might be improved. |
| 10:50 | <kapowaz> | I've been working with implementing these for mobile browsers (targeting specifically iOS and Android for now, but potentially others later) and so came across a few things which I think could be better |
| 10:51 | <kapowaz> | first of all, it appears that the placeholder attribute is verboten. I was wondering if anyone knew why? |
| 10:52 | <kapowaz> | it seems to me that in the absence of a more detailed specification on *how* input[type=date] is implemented, placeholder text is still a valuable thing to have, particularly where a UA implements it as similar to an input[type=text] |
| 10:53 | <kapowaz> | secondly, the spec doesn't make any reference to how else a date input might present itself. We already have one good example (iOS 5.0) where the datepicker and the presented chosen date are independent — i.e. you get a spinner control to choose the date, and then a box shows the selected date. |
| 10:54 | <kapowaz> | for whatever reason, Apple have decided to show the selected date in the format “Jan 17th, 2012” rather than the ISO format. The element still maintains the ISO formatted date in the DOM, but for presentational purposes it uses (in my opinion, at least) a better format |
| 10:55 | <jgraham> | The spec doesn't mandate UI, ever |
| 10:55 | <kapowaz> | how about adding an attribute to the spec, allowing a display format to be specified? |
| 10:55 | <kapowaz> | jgraham: yes, which is why I am confused that placeholder is verboten from that element |
| 10:57 | <kapowaz> | I would naturally much rather the spec allowed more useful components that could then be implemented in any given way, than less (or that it said *how* to implement them) |
| 10:59 | <jgraham> | If you think there is a usecase for putting a placeholder in date inputs, even though it won't work in some implementations, please email the list |
| 11:00 | <kapowaz> | okay, I'll do that. |
| 11:04 | <kapowaz> | jgraham: which specific mailing list would you recommend? the whatwg.org site pushed me in the direction of Help, which looks to me like the wrong audience... |
| 11:05 | <Ms2ger> | whatwg⊙wo |
| 11:05 | <kapowaz> | okay, thanks |
| 11:41 | <asmodai> | Interesting browser bug/behaviour |
| 11:42 | <asmodai> | So we go http://www.erim.eur.nl/ERIM/Research/Centres/Learning_Agents/Research/Publications#axzz1jiOciWJ7 |
| 11:43 | <asmodai> | Reference to another page within an iframe |
| 11:43 | <asmodai> | The publication years anchors work with all browsers, except Firefox. |
| 11:43 | <asmodai> | I assume that such anchors should keep working regardless of an iframe, right? |
| 11:44 | <asmodai> | I need to submit a bug report about this, if correct. |
| 11:51 | <jgraham> | kapowaz: So one problm with your example is that it doesn't really work |
| 11:52 | <jgraham> | If you say date of birth [DD/MM/YYYY] but the browser only accepts MM/DD/YYYY input, people will get stuff wrong |
| 11:58 | <kapowaz> | jgraham: not sure I follow — why would the browser only accept that format? I thought the spec mandates that it has to accept ISO 8601 formatted dates? |
| 11:59 | <kapowaz> | I'm not sure what you mean by ‘if you say date of birth [DD/MM/YYYY]’ — do you mean, if I were to specify a dateformat attribute of that format? |
| 11:59 | <jgraham> | It has to submit dates in ISO format |
| 11:59 | <jgraham> | The UI can accept anything |
| 12:00 | <kapowaz> | so you're concerned about a situation where the UA accepts a given format, but the element is displaying a different format? |
| 12:00 | <jgraham> | It is totally fine to have a UI that accepts the string "yesterday", for example |
| 12:00 | <kapowaz> | maybe I wasn't clear enough — the dateformat attribute I'm suggesting is purely for display, not for entry |
| 12:01 | <kapowaz> | yeah, that makes sense. |
| 12:01 | <jgraham> | I am concerned with the situation where the page author makes assumptions about the format based on their local testing |
| 12:01 | <jgraham> | That aren't valid for their users |
| 12:01 | <jgraham> | and then use that to write placeholder text |
| 12:03 | <jgraham> | Of course it can be safe if you can also specify the format that any text entry should accept. But that could break consistency between sites in the same UA |
| 12:03 | kapowaz | nods |
| 12:04 | <kapowaz> | so, although existing implementations of input[type=date] use ISO format for entry, there is no reason why they should always do this, and so using that format as placeholder text could create broken expectations. |
| 12:04 | <kapowaz> | that is a valid reason to be concerned. |
| 12:06 | <kapowaz> | curiously enough, if the browser doesn't support input[type=date] but does support placeholders, you'll get the desired effect by mandating (say) ISO formatted date strings, and giving a placeholder value alongside it. |
| 12:06 | <kapowaz> | but as soon as the browser supports that type, it'll (potentially) break |
| 12:06 | <kapowaz> | annoying. |
| 13:33 | <asmodai> | curious |
| 13:34 | <asmodai> | so apparently this same-page anchor in iframe thing is disabled in Firefox due to security issues: https://bugzilla.mozilla.org/show_bug.cgi?id=583889 |
| 13:35 | <asmodai> | Curious that all other browsers don't disable it though. So I wonder if the FF method is a bit too heavy-handed in trying to fix it, since it disabled legitimate use. |
| 16:34 | <AryehGregor> | Ms2ger, what's the policy for changing approved tests in the WebApps WG? |
| 16:34 | AryehGregor | has been avoiding it |
| 16:35 | <AryehGregor> | (In fact, I already fixed that bug in submissions/AryehGregor/Range-surroundContents.html) |
| 16:35 | <Ms2ger> | Yeah |
| 16:36 | <Ms2ger> | I updated the approved tests because of the bugs Opera filed |
| 16:36 | <AryehGregor> | Right. |
| 16:36 | <AryehGregor> | I don't know if we're supposed to do that, or un-approve them. |
| 16:37 | AryehGregor | looks for policy documents |
| 16:38 | <Ms2ger> | Either is fine with me, but I'd prefer not having known-buggy tests just sit there |
| 16:38 | <AryehGregor> | Oh, look, I'm the Test Facilitator. |
| 16:38 | <AryehGregor> | I forgot. |
| 16:38 | <Ms2ger> | Heh |
| 16:38 | <AryehGregor> | So maybe I'll just make up policy. |
| 16:39 | <jgraham> | The policy should make it easy to fix tests :) |
| 16:39 | <AryehGregor> | New policy: if there are known bugs in my tests, I'll unapprove them, and occasionally I'll issue a RfR on the tests in my submissions. |
| 16:45 | <AryehGregor> | Actually, let me revise that. |
| 16:48 | <AryehGregor> | Can we just say everything in approved/ has been approved by an editor of the spec, but maybe not the WG? |
| 16:49 | <Ms2ger> | wfm |
| 16:52 | jgraham | thiks the whole approved folder model is wrong fwiw |
| 16:52 | <jgraham> | +n |
| 16:52 | <jgraham> | It's not files that get approved, it's specific sets of commits |
| 16:54 | AryehGregor | invites jgraham to set up proper code review for the W3C |
| 16:55 | jgraham | would love to but can't find the tools to save us |
| 16:56 | <jgraham> | You need a tool to track which commits have review and which don't |
| 16:56 | <AryehGregor> | jgraham, gerrit? |
| 16:56 | <Ms2ger> | shepherd? |
| 16:57 | <jgraham> | AryehGregor: gerrit might work if we seriously started using git |
| 16:57 | <AryehGregor> | jgraham, hg-git? |
| 16:57 | <AryehGregor> | (note: I've found hg-git to be flaky, YMMV) |
| 16:58 | <jgraham> | AryehGregor: Yeah, I know it is *possible*, see https://github.com/jgraham/html-testsuite |
| 16:58 | <jgraham> | (also the java stack scares me) |
| 16:59 | <jgraham> | shepard is a bit of an unknown quantity. I worry that it is being developed too much around the needs of CSS |
| 16:59 | <jgraham> | But maybe it will turn out OK |
| 16:59 | <jgraham> | I don't think it is likey to become a kickass review tool though |
| 17:00 | <jgraham> | It might be an acceptable one |
| 17:12 | <AryehGregor> | "Acceptable" seems vastly better than "nonexistent". |
| 19:21 | <AryehGregor> | TabAtkins_, 0 seems to parse okay as an <angle> in implementations, at least for transforms. E.g., transform: scale(2) rotate(0); is the same as transform: scale(2) rotate(0deg);, not a parse error. |
| 19:21 | <AryehGregor> | This is not what CSS Values and Units says. |
| 19:21 | <AryehGregor> | Has this been discussed? Should I mail www-style? |
| 19:21 | <AryehGregor> | All implementations seem to agree. |
| 19:21 | <Ms2ger> | Has been discussed a few times, I think |
| 19:21 | AryehGregor | is looking |
| 19:21 | <TabAtkins_> | AryehGregor: Yes, I know. It's an impl bug in Transforms that's unfixable at this point. Transforms needs to explicitly define that. |
| 19:22 | <AryehGregor> | That was my recollection. |
| 19:22 | <AryehGregor> | TabAtkins_, why isn't it a Values and Units bug? "0" can already be either <number> or <length>, why not <angle> too? |
| 19:22 | <TabAtkins_> | Because it creates more possibilities for ambiguity. |
| 19:22 | <AryehGregor> | So it's really just futureproofing, or we have a property where it matters? |
| 19:22 | <TabAtkins_> | It would have been a problem for an earlier draft of gradient syntax, for example. |
| 19:23 | <AryehGregor> | Makes sense in principle. |
| 19:23 | <TabAtkins_> | So we have existence proof of problems. |
| 19:23 | AryehGregor | files bugs on the transform specs |
| 19:25 | <TabAtkins_> | (The gradient syntax issue was that one of the arguments could, among other things, be either "<length> <length>" or "<length> <angle>".) |
| 19:25 | <TabAtkins_> | With significantly different behavior based on which way the 0 was translated.) |
| 19:27 | <TabAtkins_> | Even unitless lengths sometimes cause problems - it means we always need to ensure that a property that accepts lengths and numbers gives the exact same interpretation to "0" for both types. |
| 19:33 | <AryehGregor> | https://www.w3.org/Bugs/Public/show_bug.cgi?id=15598 |
| 19:34 | <TabAtkins_> | MikeSmith: Yo, I sent you an email a few days ago (early Saturday your time) asking for a bunch of new components for bugzilla. |
| 19:34 | <TabAtkins_> | MikeSmith: Any news? |
| 19:49 | <Ms2ger> | MikeSmith, and did ddahl ask for his repo? |
| 22:12 | <jgraham> | AryehGregor: Well the code review tool on github exists |
| 22:12 | <jgraham> | AFAICT it sucks |
| 22:12 | <jgraham> | But it exists |
| 22:15 | <jgraham> | I guess it would work better if we used it in a more distributed way |
| 22:15 | <jgraham> | So instead of having a single big repo with everything, one would have a testsuite-stable repo |
| 22:15 | <jgraham> | And people would make pull requests on that with code they wanted to be committed |
| 22:17 | <jgraham> | Then everything in the main repo would be stable, submitting a test would be submiting a pull request, and an issue on a test would be an issue in the bugtracker |
| 22:18 | <jgraham> | I'm not sure how much I like the thought of trying to convice W3C that they should give up all their existing infrastructure |
| 22:18 | <jgraham> | But that solution does at least sound like it will work |
| 22:20 | <jgraham> | (ofc one can do the same thing without needing the priprietary infrastructure using gitorious) |
| 22:21 | <jgraham> | Wow major vowel fail there |