| 02:46 | <MikeSmith> | Hixie: mobile safari was released in June 2007 I think |
| 02:46 | <MikeSmith> | https://github.com/whatwg/web-history/blob/master/README.md#2007-06-to-2007-12 |
| 02:47 | <Hixie> | k |
| 04:51 | <TabAtkins> | annevk: When you get the chance, look over http://dev.w3.org/csswg/selectors/#data-model and see if you're happy with my attempt at defining selectors on top of DOM? |
| 04:51 | <TabAtkins> | The rest of the spec isn't matched up yet; I'll do that after. |
| 10:03 | <annevk> | Whoa, Hixie wrote a lenghty blogpost on www-archive |
| 10:08 | <annevk> | http://lists.w3.org/Archives/Public/www-archive/2014Apr/0034.html |
| 10:08 | <annevk> | Hixie++ |
| 10:10 | <annevk> | Hixie: it's pretty annoying people keep misspelling WHATWG; might be a personal pet peeve |
| 10:29 | <jgraham> | Does that mean that Hixie is secretly Björn? |
| 10:29 | <jgraham> | Or are mailing list archives the blog platform of the future? |
| 10:30 | <jgraham> | Certainly they have a number of advantages over other popular choices |
| 11:38 | <annevk> | Standards discussion, support forums, or blogs? |
| 11:50 | <jgraham> | Imagine that, a medium flexible enough that it could be all three. |
| 11:55 | <annevk> | How do people make decisions between a boolean adjusting the behavior of a state and introducing an additional state? |
| 11:55 | <annevk> | E.g. it makes some sense to me to simply fold "force preflight flag" into the request's "mode" concept, but having "CORS-with-forced-preflight" as a mode |
| 11:55 | <annevk> | s/but/by/ |
| 11:58 | <jgraham> | annevk: I guess it depends what's simpler |
| 11:59 | <jgraham> | Generally if you have two orthogonal concepts and all combinations of them are allowed it doesn't make sense to flatten them |
| 12:00 | <annevk> | jgraham: right, which is why it makes some sense to flatten them here, as mode being tainted cross-origin does not pair with a forced preflight flag |
| 12:11 | <hsivonen> | annevk: amazing how much stuff there is to remove under uconv/ thanks to the Encoding Standard |
| 12:11 | <hsivonen> | and thanks to just paying attention to stuff that FreeType obsoleted on X11 |
| 12:11 | <annevk> | hsivonen: yeah, the file savings are great |
| 12:12 | <annevk> | hsivonen: I think it has helped that other implementers took a fresh look at encodings |
| 12:12 | <annevk> | hsivonen: Opera having their own implementation, Chrome being conservative with ICU |
| 12:12 | <hsivonen> | yeah |
| 12:13 | <hsivonen> | it's sad that TrueType fonts can have the font name encoded in any of the Mac legacy encodings |
| 12:20 | <hsivonen> | you know you are reading good code when "4.x behavior" refers to Netscape 4.x |
| 12:23 | <jgraham> | heh |
| 12:39 | <IZh> | Hixie: Hi. |
| 12:40 | <Ms2ger> | A little early, herpahs |
| 12:40 | <Ms2ger> | perhaps |
| 12:40 | <IZh> | I'll wait. :-) |
| 12:42 | <annevk> | IZh: http://www.nohello.com/ |
| 12:43 | <IZh> | annevk: My "hello" was personalized. So nobody except Hixie shouldn't wait for continuation. ;-) |
| 12:44 | <annevk> | same difference |
| 13:07 | <Domenic_> | Great post Hixie. |
| 13:07 | <Domenic_> | annevk: +1 on the WHATWG mispelling; I feel the same way. |
| 13:25 | <Ms2ger> | WhatWG? |
| 13:29 | <MikeSmith> | so I'm trying to run test from http://w3c-test.org/tools/runner/index.html in IE11 in a VM and they're all failing with the error "Could not complete the operation due to error 80700019." If anybody else has run into this, some clue would be appreciated |
| 13:32 | <SteveF> | MikeSmith: FYI completed test run but couldn't download JSON have html output |
| 13:33 | <MikeSmith> | SteveF: oh |
| 13:33 | <MikeSmith> | SteveF: yeah please send me what you got |
| 13:33 | <SteveF> | you got skype open? |
| 13:35 | <MikeSmith> | ah no |
| 13:35 | <MikeSmith> | will open it now |
| 13:35 | <SteveF> | nevermind saved the file didn't save the results |
| 13:35 | <SteveF> | will run again |
| 13:35 | <SteveF> | and mail you |
| 13:35 | <MikeSmith> | ok thanks |
| 14:04 | <MikeSmith> | so the problem I'm running into with IE11 seems to be due to .postMessage failing |
| 14:04 | <MikeSmith> | wonder if there's some known issue and some way to work around it |
| 14:09 | <jgraham> | MikeSmith: http://stackoverflow.com/questions/21070553/postmessage-still-broken-on-ie11 |
| 14:10 | <jgraham> | I think the way to fix it is probably to pick an IE developer at random and show up at their house and start mooning until a fix is forthcoming |
| 14:10 | <MikeSmith> | jgraham: thanks |
| 14:10 | <MikeSmith> | heh |
| 14:11 | <SteveF> | MikeSmith: hey once I followed your original instructions correctly(unchecking ref/manual), started test and nothing appears to happen aprt from button changing from start to stop, just sits there |
| 14:12 | <MikeSmith> | SteveF: odd |
| 14:12 | <MikeSmith> | SteveF: thanks for trying it, I guess I'll give up for now |
| 14:12 | <SteveF> | MikeSmith: looks like a window opens but diappears |
| 14:13 | <MikeSmith> | oh |
| 14:13 | <SteveF> | MikeSmith - worked it out had space before / |
| 14:14 | <MikeSmith> | SteveF: yeah, that'll do it |
| 14:14 | <SteveF> | working again now will mail you once done |
| 14:20 | <MikeSmith> | SteveF: thanks |
| 14:34 | <Hixie> | IZh: got your mail, will be responding today. sorry for the delay, been out of town. |
| 14:35 | <IZh> | Hixie: No problems. :-) |
| 14:50 | <annevk> | JakeA: what's the idea with shared workers and service workers again? |
| 14:51 | <annevk> | JakeA: a shared worker is controlled by a service worker matching its URL scope? |
| 14:51 | <annevk> | JakeA: whereas a dedicated worker is controlled by a service worker controlling its document? |
| 14:51 | <JakeA> | agreed |
| 14:52 | <annevk> | JakeA: should the register API be available from workers? |
| 14:52 | <annevk> | JakeA: also, that seems to mean we should distinguish worker from sharedworker in .context (the new purpose), no? |
| 14:53 | <JakeA> | annevk: I don't see why the register API can't be in shared workers, but don't think it's essential |
| 14:55 | <annevk> | JakeA: agreed I guess, what about the second question? |
| 14:55 | <JakeA> | annevk: good spot. I think it's another reason to bring back .isNavigation or similar |
| 14:55 | <JakeA> | annevk: Since "child" can be both Worker or SharedWorker |
| 14:55 | <annevk> | JakeA: we also have "worker" |
| 14:56 | <annevk> | JakeA: I thought "navigate" was child/popup/navigate |
| 14:56 | <annevk> | s/"navigate"/isNavigate/ |
| 14:58 | <JakeA> | annevk: hmm, not sure "worker" should be there. I thought the intention was to stick with CSP terms, except for "navigate" when they don't have. |
| 14:58 | <JakeA> | annevk: CSP uses "child" for workers |
| 14:59 | <annevk> | JakeA: the idea was to have a superset |
| 14:59 | <annevk> | JakeA: that way we have flexibility to hang of different semantics later |
| 15:00 | <annevk> | JakeA: or where we already know we need different semantics we can do so right away |
| 15:00 | <JakeA> | annevk: you're right, isNavigate shouldn't be for workers… |
| 15:00 | <annevk> | JakeA: as you pointed out above, "child" is different from "worker" as "child" is navigate while "worker" is not (unless it's a shared worker, in which case I'm not quite sure what to call it) |
| 15:01 | <annevk> | JakeA: fetching a shared worker doesn't invoke HTML's navigate algorithm, but we do want equivalent service worker semantics |
| 15:01 | <JakeA> | annevk: Yep. In that case, yeah, we should have separate purposes |
| 15:02 | <annevk> | JakeA: contexts* ;-) |
| 15:02 | <annevk> | JakeA: I will add sharedworker to the list I'm about to add to Fetch |
| 15:02 | <JakeA> | hah. yeah. sorry, was staring at the .ts |
| 15:02 | <JakeA> | annevk: works for me |
| 15:02 | <annevk> | JakeA: slowly upgrading the vocabulary in Fetch for the eventual integration |
| 15:03 | <annevk> | JakeA: still trying to think about what the best way to deal with the request object vs the request concept is |
| 15:03 | <JakeA> | annevk: I'm writing a talk, which feels really unhelpful this close to FWD, but gotta be done for Saturday |
| 15:03 | <annevk> | JakeA: no worries, I don't care about FPWD |
| 15:04 | <annevk> | JakeA: I can stop bugging you this week |
| 15:04 | <annevk> | Maybe I can get jungkee to join this chat |
| 15:04 | <JakeA> | annevk: no no, I didn't mean that. Just trying to justify the lack of useful I've been |
| 15:04 | <annevk> | oh, no, you've been very useful |
| 15:14 | <Hixie> | it's amusing to watch the showModalDialog() thing |
| 15:14 | <Hixie> | because all these developers are acting as if the feature was a long-standing standard API |
| 15:15 | <Hixie> | it's probably the clearest indication of the lack of importance of specs for a long time... |
| 15:24 | <Domenic_> | I'm glad Blink seems to be holding the line on killing that one, unlike the Attr changes |
| 15:27 | <zcorpan> | i'd expect a more thought-through round of Attr changes later |
| 15:29 | <Domenic_> | I kind of thought that making small changes now and seeing the reaction would be OK---getting people used to the idea that Chrome will remove such rarely-used APIs---instead of trying to do everything at once. |
| 15:29 | <Hixie> | ojan posting about that recently |
| 15:29 | <Hixie> | posted |
| 15:30 | <Hixie> | talking about how bigger fewer changes was better than more smaller changes |
| 15:30 | <Hixie> | oops, edited the spec forgetting that i already had an edit in flight |
| 15:31 | <Hixie> | well, the next checkin is gonna suck for everyone |
| 15:31 | <Hixie> | sorry about that |
| 15:32 | <zcorpan> | one response i saw to the whateverAttributeNodeNS removal was to write a "polyfill" that used another fooAttributeNode method that was also removed from the dom spec but not yet from the impl |
| 15:32 | <Hixie> | heh |
| 15:33 | <Hixie> | i wasn't following the Node stuff |
| 15:33 | <Hixie> | what are we trying to remove, and why? |
| 15:33 | <zcorpan> | we're primarily trying to make Attr not inherit from Node |
| 15:33 | <zcorpan> | and secondarily removing methods related to Attr that "nobody" uses |
| 15:34 | <Hixie> | i thought the Node thing was done long ago |
| 15:34 | <Hixie> | is that failing? |
| 15:34 | <zcorpan> | i don't think it has been done in the impl yet |
| 15:34 | <zcorpan> | so it's not failing yet |
| 15:35 | <zcorpan> | removing one of the methods failed (but might be attempted again later) |
| 15:35 | <Hixie> | ah |
| 15:35 | <Hixie> | MikeSmith: i think the 408 thing might be a chrome dev bug |
| 15:36 | <Domenic_> | Hixie: I didn't really feel strongly or clearly enough to object on-list, but my gut feeling was that I wasn't sure Ojan's "We shouldn't remove APIs that have small value on the path towards a removal that has significant value" made sense. |
| 15:36 | <Domenic_> | Basically, gradually easing people in to a change seems potentially valuable? |
| 15:36 | <Hixie> | i don't know that i have an opinion either way |
| 15:36 | <Hixie> | just pointing out that there was a post on the subject :-) |
| 15:39 | <Domenic_> | Wow did not realize <textarea> had three values |
| 15:40 | <annevk> | Hixie: we made the Attr spec change long ago, but implementations are slow to clean up old code |
| 15:41 | <Domenic_> | When I Google "whatwg html textarea" google shows the page titles as having "WhatWG" O_o |
| 15:41 | <Domenic_> | Also when I click the little dropdown in the Google search it says "WHATWG: Programming Language Developer" |
| 15:43 | <Hixie> | well i guess that's accurate |
| 15:43 | <Hixie> | for some definition of "programming language" |
| 15:46 | <annevk> | Domenic_: yeah, seems WHATWG ended up as WhatWG in some Google systems |
| 15:48 | <annevk> | WHATWG's Google+ page is not to blame |
| 15:56 | <annevk> | JakeA: <object> can create a nested browsing context too; but can also load plugins |
| 15:57 | <Hixie> | and images |
| 15:57 | <Hixie> | <object> is a disaster of overloaded behaviour |
| 15:58 | <JakeA> | annevk: hm, yeah. Object is badly named then. Nested browsing context via object should have the same context as iframe. I guess "object" means object/embed with no better match |
| 15:58 | <JakeA> | ugh |
| 15:59 | <JakeA> | "The object-src directive restricts from where the protected resource can load plugins" |
| 15:59 | <JakeA> | Do we know if it's going to load a plugin at request time? |
| 15:59 | <JakeA> | Or is that dictated by the content-type? |
| 15:59 | <zcorpan> | embed can also be a browsing context |
| 16:00 | <JakeA> | "It is not required that the consumer of the element's data be a plugin in order for the object-src directive to be enforced" ughhghgh |
| 16:00 | <zcorpan> | JakeA: if typemustmatch and type are both present, you can know beforehand, iirc |
| 16:00 | <zcorpan> | JakeA: but otherwise the content-type wins |
| 16:01 | <JakeA> | "This is true even when the element data is semantically equivalent to content which would otherwise be restricted by one of the other directives, such as an object element with a text/html MIME type." |
| 16:01 | <JakeA> | annevk: so "object" means "comes from an <object> or <embed>", even if it doesn't load a plugin |
| 16:02 | <JakeA> | I don't think we should do something different. |
| 16:03 | <annevk> | JakeA: the problem is that it can be a browsing context |
| 16:03 | <JakeA> | If you're using object/embed you're opening the Ghostbuster's Containment Unit anyway |
| 16:03 | <annevk> | JakeA: and if it's a browsing context, it needs its own service worker |
| 16:03 | <JakeA> | Ah, good point |
| 16:03 | <annevk> | JakeA: however, you don't know whether it needs its own browsing context until you have examined the response |
| 16:04 | <Domenic_> | I kind of was looking forward to the world where <object> replaced <img>, <video>, <audio>, and all other such things. That was XHTML2 right? |
| 16:04 | <annevk> | Domenic_: yes, it had src on all elements |
| 16:04 | <annevk> | Domenic_: given what we know now that made little sense |
| 16:05 | <Domenic_> | src on everything too? I knew about href on everything... |
| 16:06 | <JakeA> | annevk: This is tough. Trying to think of something better than "SW responses to <object>/<embed> cannot create browsing contexts" |
| 16:07 | JakeA | goes to read the spec for <object> |
| 16:07 | <annevk> | Domenic_: yes |
| 16:08 | <Domenic_> | well that's just crazysauce |
| 16:08 | <jgraham> | "When a service worker is active the <object> and <embed> elements must have their UA conformance criteria replaced by those of the <div> element" :p |
| 16:08 | <annevk> | JakeA: it seems kind of sucky that enabling a service worker renders two elements partially obsolete |
| 16:08 | <zcorpan> | anyone know if anyone is implementing aria 1.1? |
| 16:09 | <annevk> | JakeA: or makes two elements wormholes |
| 16:10 | <SteveF> | zcorpan: which bit(s) |
| 16:12 | <annevk> | JakeA: https://github.com/slightlyoff/ServiceWorker/issues/249 |
| 16:12 | <annevk> | JakeA: filed that issue for object/embed |
| 16:16 | <zcorpan> | SteveF: role="switch checkbox" being switch rather than checkbox |
| 16:16 | <annevk> | Hixie: https://twitter.com/rillian/status/455859796160151552 |
| 16:18 | <Hixie> | hrm |
| 16:18 | <Hixie> | where are the absolute URLs coming from, that's the question... |
| 16:18 | <annevk> | ooh, might very well be the splitter script |
| 16:18 | <Hixie> | there's some in the spec source, i'll fix those first |
| 16:18 | <Hixie> | i just change http://blabla to //blabla, right? |
| 16:19 | <annevk> | yeah that ought to work |
| 16:19 | <Hixie> | the images on images.whatwg.org aren't gonna work this way |
| 16:19 | <Hixie> | since that doesn't have ssl |
| 16:19 | <annevk> | yeah :/ |
| 16:19 | <annevk> | ssl + put everything on a subdomain = fail |
| 16:20 | <SteveF> | zcorpan: don't think switch is in the spec yet - as in can't find it, know its been raised, i think by james craig so coming from apple/webkit direction |
| 16:20 | <zcorpan> | SteveF: or any other value that's not in 1.0 |
| 16:21 | <zcorpan> | context is http://lists.w3.org/Archives/Public/www-style/2013Jul/0099.html |
| 16:21 | <annevk> | dglazkov: I think I missed that status email |
| 16:22 | <annevk> | dglazkov: and it shipping without being settled is somewhat odd |
| 16:23 | <SteveF> | zcorpan: right, its still very early days for 1.1 and don't think anything has been agreed upon apart from describedat |
| 16:24 | <zcorpan> | SteveF: ok thanks |
| 16:25 | <SteveF> | zcorpan: editors draft http://www.w3.org/WAI/PF/aria-1.1/ |
| 16:25 | <annevk> | JakeA: so if shared worker is not a navigate request, but is a request that gets its own service worker, do we have a good term for that? |
| 16:26 | <annevk> | JakeA: resource request seems like an obvious name for the other type of request |
| 16:27 | <JakeA> | annevk: remind me why shared worker doesn't count as "navigate". It has the same restrictions, it can't be an OpaqueResponse |
| 16:28 | <annevk> | JakeA: it doesn't use the "navigate" algorithm |
| 16:29 | <annevk> | JakeA: and I guess it can be an OpaqueResponse if it's a same-origin redirect |
| 16:29 | <Hixie> | ok, styles and scripts now load relatively |
| 16:29 | <JakeA> | annevk: that's true for navigations too right? |
| 16:29 | <annevk> | JakeA: confirm |
| 16:30 | <JakeA> | annevk: I think shared workers would go through the navigate part of the SW algorithms |
| 16:30 | <dglazkov> | good morning, Whatwg! |
| 16:30 | <JakeA> | which probably means this is a naming issue |
| 16:30 | <JakeA> | dglazkov: Morning! |
| 16:30 | <annevk> | JakeA: HTML has an algorithm called "navigate" which is only for navigating browsing contexts |
| 16:31 | <annevk> | Explaining this stack of turtles to someone new to web development is going to be insane |
| 16:31 | <JakeA> | annevk: yeah, whereas SW means "selects a registration" |
| 16:32 | <annevk> | JakeA: "registration request" |
| 16:32 | <annevk> | ? |
| 16:33 | <JakeA> | annevk: sounds too much like "request for a registration". All the terms I can think of are balls. "top level", "initial", "browser contexting" urgh |
| 16:34 | <annevk> | JakeA: maybe controller? |
| 16:34 | <annevk> | JakeA: as the window/worker will be the controller for future requests? |
| 16:35 | <annevk> | JakeA: but maybe that's confusing with the document being controlled by the service worker |
| 16:35 | <JakeA> | annevk: yeah, we may even end up with a navigator.serviceWorker.controller for the controlling SW instance |
| 16:37 | <Domenic_> | can we call it navigationController |
| 16:37 | <JakeA> | haha |
| 16:37 | <annevk> | oh my |
| 16:37 | <annevk> | oooh |
| 16:38 | <annevk> | JakeA: how about client request? |
| 16:38 | <JakeA> | annevk: it doesn't really mean anything to me, but it's the least-bad so far |
| 16:38 | <annevk> | JakeA: well, client is where resource requests originate from |
| 16:39 | <annevk> | JakeA: and is the terminology we are introducing to mean either window or worker, right? |
| 16:39 | <JakeA> | annevk: that's true actually |
| 16:40 | <JakeA> | annevk: fetchEvent.isNewClient |
| 16:41 | <JakeA> | annevk: maybe just fetchEvent.newClient |
| 16:41 | <annevk> | JakeA: yeah, just trying to introduce terminology at this point |
| 16:43 | <annevk> | JakeA: http://fetch.spec.whatwg.org/#concept-request-client |
| 16:44 | <JakeA> | annevk: yes! That works |
| 16:44 | <annevk> | JakeA: just need to make sure we have enough contexts now |
| 17:06 | <Hixie> | MikeSmith: http://platform.html5.org/ - Typed Array is in JS, now, I think |
| 17:07 | <Hixie> | thanks to IZh, we have a PDF version of the spec again! :-D |
| 17:10 | <MikeSmith> | Hixie: thanks yeah I'll update http://platform.html5.org/ tomorrow |
| 17:11 | <MikeSmith> | Hixie: btw yeah I've noticed 408s recently in Chrome from sites other than bugzilla |
| 17:32 | <zcorpan> | Hixie: the pdf link points to http://www.whatwg.org/specs/web-apps/current-work/ |
| 18:04 | <annevk> | I hope people do not actually print and put that on their Kindle or whatever |
| 18:14 | <annevk> | "Once the spec is finalized and released, the latest version will be clear and obvious - just as it is for other W3C specs." |
| 18:15 | annevk | snickers |
| 18:21 | <tantek> | lol |
| 18:21 | <tantek> | annevk - URL? I need more material to humor the AB ;) |
| 18:21 | <tantek> | s/humor/inform ;) |
| 18:21 | <annevk> | tantek: https://www.w3.org/Bugs/Public/show_bug.cgi?id=25421 |
| 18:22 | <tantek> | oh Travis |
| 18:23 | <tantek> | too bad he didn't make it to the HTMLWG f2f, was hoping for more interesting avoid spec divergence discussions |
| 18:24 | <annevk> | Gary said this actually, guy from Google |
| 19:18 | <Ms2ger> | OH "As useful & full of potential as hashtags." |
| 19:18 | <Ms2ger> | Not sure if sarcastic |
| 20:28 | <SamB> | hmm, I don't suppose anyone knows a good channel to talk about problems involving docbook-xsl -- my valgrind(1) manpage has, um, issues ... |
| 20:35 | <estellevw> | clarification request: my understanding was that "novalidate" can be on any form field or the form itself, and formnovalidate is only for type=submit and <button>. |
| 20:35 | <estellevw> | However, deeper spec reading seems to indicate that novalidate is on the element's form owner, so is novalidate only valid on <form>? |
| 20:41 | <annevk> | estellevw: yes, novalidate is on form |
| 20:41 | <annevk> | estellevw: formnovalidate is on input/button |
| 20:42 | <estellevw> | thanks annevk |
| 20:42 | <annevk> | estellevw: it has a form prefix on input/button just like action et al have because otherwise we'd be breaking sites |
| 20:42 | <SamB> | I think if you want some control not to be validated, you don't use a control type with validation? |
| 20:44 | <annevk> | SamB: novalidate is more if you want to save intermediate input |
| 20:45 | SamB | should probably read more before talking ... |
| 20:48 | <estellevw> | so, if you want to suggest the user include a number from 5 to 10, but want to allow for any data for that field only, and want the rest of the form to be validated, how would you say "validate the entire form except foo where foo is <input type="number" name="foo" min="5" max="10">? |
| 20:50 | <estellevw> | is there a way to exclude just one form element from a form validation constraints, |
| 20:50 | <annevk> | estellevw: there's no such feature |
| 20:50 | <estellevw> | hmm mph. Now I want one |
| 20:50 | <estellevw> | didn't want it until I found out I couldn't have it ;) |
| 20:51 | <annevk> | hah |
| 20:51 | <annevk> | estellevw: whatwg⊙wo ; though don't ask for a specific feature, mention a scenario you find hard to accomplish |
| 20:52 | <Domenic_> | why can't this just be accomplished with <input type="number"> with no min or max? If they're not used for validation what are they used for... |
| 20:53 | <annevk> | https://mail.mozilla.org/pipermail/es-discuss/2013-April/030412.html bah |
| 20:54 | <estellevw> | Domenic_ I was just coming up with an example scenario: when you want to allow for any data entry, but you want to take advantage of the GUI |
| 20:55 | <Domenic_> | What GUI? |
| 20:55 | <estellevw> | the number spinner |
| 20:56 | <annevk> | estellevw: there's also <input inputmode=numeric> |
| 20:56 | <estellevw> | http://codepen.io/estelle/pen/fAKJa |
| 20:56 | <estellevw> | ah, that I did not know about |
| 20:56 | <Domenic_> | The number spinner is still there with no min or max.... |
| 20:57 | <estellevw> | even though it was right there on http://www.whatwg.org/specs/web-apps/current-work/multipage/the-input-element.html#input-type-attr-summary |
| 21:12 | <SamB> | hmm, #the-blink-element should maybe bring me to http://www.whatwg.org/specs/web-apps/current-work/multipage/obsolete.html#dfnReturnLink-0 ? |
| 21:20 | <SamB> | Hixie: have I ever told you that the "comment" box on the HTML spec is awfully small |
| 21:20 | <zcorpan> | SamB: #dfnReturnLink-0 is a script-generated id that won't work for anyone else loading that url |
| 21:21 | <SamB> | zcorpan: oh |
| 21:21 | <Hixie> | samb: if you have more to say, just type in a title and submit the bug |
| 21:21 | <Hixie> | SamB: then edit the bug to add more :-) |
| 21:21 | <SamB> | Hixie: yeah, I realize I can do that ... |
| 21:21 | <Hixie> | SamB: (in my experience, if i give people a multiline field, i get more rambling BS bugs) |
| 21:22 | <SamB> | might be nice to have a "prefill this section in bugzilla" button or something? |
| 21:22 | <Hixie> | if you click on the spec section, that is the section ID used |
| 21:22 | <Hixie> | just click anywhere in the spec |
| 21:24 | <SamB> | I know I can get the ID easily enough |
| 21:24 | <zcorpan> | SamB: do you prefer the behavior of http://resources.whatwg.org/file-bug.js ? |
| 21:24 | <SamB> | I guess you're hinting that I should implement my own damn button? |
| 21:24 | <SamB> | or steal his |
| 21:25 | <zcorpan> | Hixie's thing is good in that it doesn't require people to create a bugzilla account to give feedback |
| 21:25 | <SamB> | zcorpan: I know |
| 21:25 | <Hixie> | yeah that was my main priority |
| 21:26 | <Hixie> | (though if you have one, and are logged in to the spec annotation system, it does cc you) |
| 21:26 | <SamB> | I think I had sort of noticed it but not gotten around to thinking about where it got my email address |
| 21:28 | <zcorpan> | but i sort of agree with SamB that it'd be nice to be forwarded to bugzilla to fill in the details and tweak the title or whatever before actually filing the bug |
| 21:28 | <SamB> | zcorpan: so if I wanted to use this thing from a userscript, I'd need to insert the link and THEN a script element? |
| 21:29 | SamB | pictures a red button marked only "BZ" |
| 21:29 | <zcorpan> | SamB: it wasn't designed to be a userscript, so maybe it can be tweaked a bit |
| 21:29 | <SamB> | I know that |
| 21:30 | <zcorpan> | i mean maybe i can tweak it and upload it so that it works as a userscript out of the box :-) |
| 21:30 | <SamB> | if it were designed to be a userscript, it would ... need to insert elements on its own, and also have a way for the user to configure the bugzilla addresses |
| 21:30 | <Hixie> | zcorpan: why does it matter if it's before or after filing the bug_? |
| 21:32 | <zcorpan> | Hixie: it's less noisy for other people |
| 21:32 | <Hixie> | zcorpan: the only people who get cc'ed are me and mike |
| 21:32 | <Hixie> | mike is cc'ed on like half the universe so i doubt he's affected one way or the other by the few people who want to edit the bugs |
| 21:32 | <Hixie> | and i have filters that delete bugmail from open bugs assigned to me |
| 21:32 | <zcorpan> | Hixie: lots of people read the bugs |
| 21:33 | <Hixie> | sure but they're not affected by title changes |
| 21:33 | <Hixie> | or the initial comment being split in two |
| 21:33 | <zcorpan> | i mean read as in get emails |
| 21:33 | <zcorpan> | i get emails for new bugs and new comments and title changes |
| 21:34 | SamB | is just a bit OCD |
| 21:34 | <Hixie> | who do you watch? me? |
| 21:34 | <Hixie> | if you watch me you're in for a world of trouble if you don't have scripts to manage your bugmail :-) |
| 21:34 | <zcorpan> | Hixie: don't remember how i set it up, but maybe |
| 21:38 | <zcorpan> | i also think there's some negative force against filing a bug before having thought through the issue, and it's hard to think it through by just writing a title. it's easier to flesh it out and then realize that it was just a misunderstanding or whatever and not file the bug |
| 21:46 | <SamB> | zcorpan: yeah |
| 21:47 | <SamB> | and sometimes you'd rather not write the title first, too ... |
| 21:48 | <SamB> | on a tangent: it's really cool that bugzilla actually supports prefilling stuff |
| 21:51 | <Hixie> | zcorpan: figure out a way to make it work without people having to have a bugzilla account, and i'll see what i can do :-) |
| 21:52 | <Hixie> | honestly though, the overhead of filing a bug that you then immediately close is nearly zero, to me |
| 21:53 | <SamB> | what, just wasting bug numbers??? |
| 21:53 | <SamB> | well, I guess if it wasn't the *plan* to close them it's different ... |
| 21:59 | <zcorpan> | Hixie: replace the hide button with a resize thingie so when you make the comment box bigger you get title+textarea :-) |
| 22:09 | <Hixie> | zcorpan: interesting idea |
| 22:11 | <MikeSmith> | I support zcorpan's idea, especially since zcorpan's one of the main actual productive users of that form |
| 22:11 | <zcorpan> | Hixie: if you're going to tweak things here, i'd also like to have the link to the filed URL stay somewhere because i want to copy it or follow it later, and it's annoying when it's gone and i have to search in bugzilla or check my email to find it |
| 22:12 | <Hixie> | zcorpan: k |
| 23:20 | <benschwarz> | Hixie: yt? |