| 04:14 | <MikeSmith> | I think this month is the 5th anniversary of the beta release of Google Maps |
| 07:29 | <wycats> | hey Hixie |
| 07:30 | <Hixie> | hi |
| 07:30 | <wycats> | just providing some much-needed traffic :) |
| 07:31 | <meledin> | You're using up my electrons! |
| 07:31 | <wycats> | oh noes |
| 07:31 | <wycats> | you guys are doing a helluva job |
| 07:31 | <wycats> | not sure how much you hear that but I think whatwg saved the web :P |
| 07:31 | <Hixie> | thanks :-) |
| 07:32 | <wycats> | Hixie: earlier I was chatting with othermaciej about CORS and getting support for it in Rails |
| 07:32 | <wycats> | (specifically, what the right defaults would be) |
| 07:32 | <Hixie> | neat |
| 07:32 | <wycats> | we've been throwing in as much support as we can for 3.0 :) |
| 07:33 | <wycats> | oh... and we're using the hell out of data- attributes |
| 07:33 | <wycats> | :-D |
| 07:34 | <wycats> | when we switched to HTML5 doctype people freaked out :P |
| 07:34 | <Hixie> | oh, cool, glad the data- attributes are helping |
| 07:34 | <Hixie> | are you finding you need other things we haven't added yet? |
| 07:34 | <wycats> | Hixie: yeah... we couldn't have done "valid" UJS stuff without it |
| 07:34 | <Hixie> | like other extensions mechanisms or the like? |
| 07:35 | <wycats> | Hixie: we haven't had a lot of need for any of the "extension" mechanisms, but maybe we're not doing fancy enough things |
| 07:35 | <wycats> | we're just catching up with stuff like audio/video |
| 07:35 | <Hixie> | cool |
| 07:35 | <wycats> | well... we caught up with that ages ago |
| 07:35 | <wycats> | but you get the idea |
| 07:35 | <wycats> | https://rails.lighthouseapp.com/projects/8994/tickets/2843-patch-add-video_tag-to-actionview |
| 07:36 | <wycats> | I like how the ticket has info about the codec thing in it ;) |
| 07:37 | <wycats> | http://github.com/rails/rails/commit/51d7b3070c68492f5376c19d24d8e5a2d746d7ea <- if you look at the comments on bottom you can see some of the tension about how to deal with fallback content |
| 07:38 | <meledin> | Monkey has a stupid question. I'm doing ridiculous stuff such as for(i=0; i<65535; i++) string+=String.fromCharCode(i) |
| 07:39 | <meledin> | AFAIK this should be a proper (albeit stupid) string. Should I be able to send it via a websocket and get the same string back? |
| 07:39 | <Hixie> | no |
| 07:39 | <wycats> | Hixie: if you had to pick, what do you think the top priorities for HTML support in frameworks would be? |
| 07:40 | <Hixie> | meledin: because it's not a valid thing to do :-) |
| 07:40 | <wycats> | (obviously we figure most of it out via user feedback, but just curious) |
| 07:40 | <Hixie> | meledin: there are a number of non-characters in the range 0..65535 that you can't express in UTF-8 |
| 07:40 | <Hixie> | meledin: specifically, all the surrogate halves |
| 07:41 | <Hixie> | meledin: (JS doesn't deal in Unicode characters, it deals in UTF-16 words) |
| 07:41 | <meledin> | I see. Thanks. I guess I'll need to look into what the valid characters are |
| 07:41 | <wycats> | Hixie: I guess I can address my only real HTML5 spec criticism to you? I've spoken with Jonas and some others but probably should just tell ya :P |
| 07:41 | <meledin> | (Trying to send stupid strings back and forth to see if I can break it) |
| 07:42 | <wycats> | it's extremely hard for practitioners to participate, because the spec is mostly written for implementors |
| 07:42 | <wycats> | so often we catch issues way too late in the process |
| 07:42 | <wycats> | one quick win would be to explain the motivation behind features more fully (because then the practitioners who motivated the feature would more easily notice that the issue is addressed) |
| 07:43 | <Hixie> | meledin: specifically, the 0xD800-0xDFFF range will cause an exception to be thrown |
| 07:43 | <meledin> | Oh, that's fine then |
| 07:43 | <meledin> | I'm failing in the range 0-1000 even |
| 07:44 | <Hixie> | wycats: does the author view of the spec help? |
| 07:44 | <wycats> | link |
| 07:44 | <wycats> | ? |
| 07:44 | <Hixie> | http://www.whatwg.org/specs/web-apps/current-work/multipage/?style=author |
| 07:45 | <wycats> | what is the difference? |
| 07:45 | <wycats> | am I being dense? |
| 07:45 | <Hixie> | it hides the implementation details |
| 07:45 | <wycats> | ah |
| 07:45 | <Hixie> | if you look at the top right there's a set of radio buttons -- if you pick the third one, it highlights the bits that are removed in the version above |
| 07:46 | <Hixie> | (which is the second radio button, iirc) |
| 07:46 | <wycats> | so an example of a problem I was having: I was trying to figure out how the change event operates for different kinds of elements |
| 07:46 | <wycats> | I'm pretty sure it's in there SOMEWHERE |
| 07:46 | <Hixie> | how do you mean? |
| 07:46 | <wycats> | I just wanted a clear description of how it's meant to operate |
| 07:46 | <wycats> | for different elements |
| 07:47 | <wycats> | I often go looking at http://www.whatwg.org/specs/web-apps/current-work/multipage/section-index.html#events-0 |
| 07:47 | <Hixie> | hm i don't think we have any text intended for authors describing how specific events work |
| 07:47 | <wycats> | right... it's all there in impl'speak |
| 07:47 | <wycats> | but it's hard to figure out what's going on |
| 07:48 | <wycats> | Hixie: I wouldn't complain, except that it's useful for authors to participate at this stage |
| 07:48 | <wycats> | unless you disagree? |
| 07:48 | <Hixie> | authors are the most important people to get feedback from |
| 07:48 | <Hixie> | i wonder how to add text about events |
| 07:48 | <wycats> | Hixie: and right now it's virtually impossible to understand large chunks |
| 07:48 | <Hixie> | i guess we could do it in the same way we do the API explanations |
| 07:48 | <Hixie> | the green boxes |
| 07:49 | <wycats> | drag and drop is really cryptic to me, and speaking with other authors I've heard that there are serious issues |
| 07:49 | <wycats> | I can't tell though |
| 07:49 | <wycats> | :/ |
| 07:49 | <wycats> | (btw, I work on jQuery as well as Rails) |
| 07:49 | <Hixie> | drag and drop is totally ridiculous, but that's because the model is crazy, not cos the spec is poor, i think |
| 07:49 | <Hixie> | though i did write an intro section for drag and drop which is somewhat ok |
| 07:50 | <Hixie> | are the event summary tables for media elements and appcache ok? |
| 07:50 | <wycats> | Hixie: lemme look at appcache |
| 07:50 | <wycats> | I've been working with that API |
| 07:50 | <wycats> | Hixie: I found the canvas spec to be really readable btw |
| 07:51 | <wycats> | I was stuck on an airplane with just the canvas spec and Webkit and was able to get my job done |
| 07:51 | <wycats> | Hixie: I'm really happy to hear you say that about authors but I haven't gotten that impression |
| 07:51 | <wycats> | I'm happy to lead a charge to getting more feedback from my peers even |
| 07:51 | <wycats> | but there's a fair bit of defeatism :/ |
| 07:52 | <wycats> | I think app cache could use a better description of the intended use cases for each section |
| 07:52 | <Hixie> | i try to trawl the blogs for feedback |
| 07:52 | <wycats> | Hixie: I can post :P |
| 07:53 | <wycats> | Hixie: my biggest annoyance with the cache manifest is the required mime type, which isn't a pain for me personally (as I write frameworks) but it adds a step to setup for people who just want to serve static iphone apps |
| 07:53 | <Hixie> | (but it's hard to make a spec that's both useful for implementors and authors) |
| 07:53 | <wycats> | Hixie: 100% |
| 07:53 | <wycats> | that was essentially what Jonas said |
| 07:53 | <wycats> | "we had to pick, and implementors won" |
| 07:53 | <Hixie> | re appcache i specifically meant the section with the table explaining the events |
| 07:53 | <wycats> | Hixie: yah |
| 07:53 | <wycats> | I'm going through the section |
| 07:54 | <wycats> | Hixie: what section #? |
| 07:54 | <Hixie> | well it's not so much that implementors won, so much as if we write a tutorial and not a spec, you guys lose out because the implementations will be buggy as hell |
| 07:54 | <wycats> | 6.6.1.1? |
| 07:54 | <wycats> | Hixie: yep |
| 07:54 | <wycats> | Hixie: what's missing most of all is use-case motivation |
| 07:54 | <hsivonen> | fwiw, the app cache is semi-broken in Gecko when html5.enable=true, so one needs to set html5.enable to false to do app cache stuff |
| 07:54 | <wycats> | so I can see if a section actually addresses a concern I actually have |
| 07:54 | <wycats> | the event summary looks good |
| 07:54 | <Hixie> | um, section numbers differ in all the different versions so dunno the number. The section is titled "Event summary". |
| 07:55 | <Hixie> | 6.6.1.1 in the complete.html version of the spec |
| 07:55 | <wycats> | http://www.whatwg.org/specs/web-apps/current-work/multipage/offline.html#appcacheevents |
| 07:55 | <wycats> | ? |
| 07:55 | <Hixie> | yeah |
| 07:55 | <wycats> | Hixie: what's unclear to me from that table is what order the events will be in |
| 07:55 | <wycats> | for instance, if I go to a page which has some changes |
| 07:55 | <wycats> | what events are fired? |
| 07:55 | <wycats> | and in what order? |
| 07:56 | <wycats> | the latter more than the former |
| 07:56 | <wycats> | I guess I can figure it out |
| 07:56 | <wycats> | now that I'm looking at it |
| 07:56 | <wycats> | like an LSAT logic game ;) |
| 07:56 | <Hixie> | the "Next events" column is trying to help with that |
| 07:56 | <wycats> | yep |
| 07:56 | <wycats> | "6 people are sitting across a table from each other" |
| 07:56 | <wycats> | "john cannot sit to the right of lisa" |
| 07:56 | <wycats> | ;) |
| 07:56 | <Hixie> | i'd make a flowchart but the problem is every time i make a diagram, i end up having to change the spec the next day and then the diagram is all wrong and so i have to remake the diagram which takes hours |
| 07:57 | <Hixie> | "checking" is first |
| 07:57 | <Hixie> | I guess I should say that |
| 07:58 | <wycats> | Hixie: maybe there's a way to automate? |
| 07:58 | <wycats> | Hixie: I'd say use cases are of large import |
| 07:58 | <Hixie> | that'd be awesome |
| 07:58 | <wycats> | for instance, what is MOTIVATING the ping attribute |
| 07:59 | <wycats> | I read it cover to cover and can't figure it out ;) |
| 07:59 | <wycats> | it seems like a Google hax |
| 07:59 | <Hixie> | search for "the ping attribute provides these advantages" |
| 07:59 | <Hixie> | (under "Hyperlink auditing") |
| 08:00 | <wycats> | right |
| 08:00 | <Hixie> | one of the reasons we don't have use cases is that sometimes people agree on what the spec should require, but disagree on why |
| 08:00 | <wycats> | that's just hypothetical |
| 08:00 | <wycats> | perhaps UAs may do useful things |
| 08:00 | <wycats> | Hixie: sure |
| 08:00 | <wycats> | that seems bad |
| 08:00 | <wycats> | the why seems important |
| 08:00 | <wycats> | for instance, if I agitate for a feature and it gets in |
| 08:00 | <Hixie> | at the end of the day, for hte spec, the what is what matters :-) |
| 08:00 | <wycats> | I should be able to detect that ;) |
| 08:00 | <wycats> | Hixie: sure |
| 08:00 | <wycats> | but it's hard for authors to figure out what's going on from just the what |
| 08:01 | <Hixie> | i'd really like someone to maintain a parallel document with the motivations for many of the reasons for the decisions, though |
| 08:01 | <Hixie> | there's unfortunately never been anyone who had the time to work on that :-( |
| 08:01 | <Hixie> | (doing it myself would like halve my editing speed) |
| 08:01 | <wycats> | Hixie: totally |
| 08:01 | <wycats> | Hixie: it's tricky |
| 08:01 | <wycats> | I almost started doing it a while ago, but it seems hard |
| 08:01 | <wycats> | :P |
| 08:02 | <wycats> | Hixie: I work with Sam on Rails btw |
| 08:02 | <wycats> | have had some of these conversations with him |
| 08:03 | <wycats> | the response I got in general was that authors just weren't important yet and someone would write a book |
| 08:03 | <wycats> | and then I could read it |
| 08:03 | <wycats> | :P |
| 08:04 | <wycats> | Hixie: I'd humbly submit re: d&d that if the problem isn't the spec so much as the model that something has gone horribly wrong |
| 08:05 | <Hixie> | authors are critical, it's very sad that we haven't been able to get the author-facing materials off the ground as fast as the implementor-facing stuff |
| 08:05 | <Hixie> | Lachy's been working on some stuff, as have others |
| 08:05 | <Hixie> | but we really need more man-power |
| 08:06 | <Hixie> | the d&d stuff is literally just describing what IE does |
| 08:06 | <Hixie> | no argument that something is horribly wrong with what IE does :-) |
| 08:06 | <wycats> | haha |
| 08:06 | <wycats> | Hixie: I offer up my services |
| 08:07 | <wycats> | not sure if you saw the back and forth with me about WebIDL btw? |
| 08:07 | <wycats> | that conversation went horribly wron |
| 08:07 | <wycats> | wrong |
| 08:07 | <wycats> | (speaking of horribly wrong) |
| 08:07 | <wycats> | I was trying to make the point I'm making here but got baited into bashing WebIDL |
| 08:07 | <Hixie> | not sure |
| 08:08 | <wycats> | I was that petulant dude who was trying to overturn the order |
| 08:08 | <wycats> | I got smacked down pretty hard |
| 08:08 | <wycats> | pretty much left with my tail between my legs |
| 08:08 | <Hixie> | there's been a lot of webidl talk recently and i try to ignore who's saying what generally speaking so as not to be biased against facts based on who's bringing them forward |
| 08:08 | <Hixie> | so i probably saw it but didn't know it was you :-) |
| 08:08 | <wycats> | Hixie: I made two points, both author-centric |
| 08:09 | <wycats> | 1) the fact that WebIDL represents things that can't be represented in ES proper is very confusing |
| 08:09 | <wycats> | 2) WebIDL itself is not an ideal description for authors |
| 08:09 | <wycats> | (corollary: absent anything else, authors are confused) |
| 08:10 | <wycats> | it's not really a comment about WebIDL at all |
| 08:11 | <wycats> | I was asked something like "don't talk unless you have a counterproposal" which is where everything went downhill |
| 08:11 | <wycats> | also something like "don't talk unless you read the entire history of the mailing lists" ;) |
| 08:11 | hsivonen | wonders if Opera got Apple's pre-approval for http://www.opera.com/press/releases/2010/02/10/ or if they are going to take a gamble with Apple |
| 08:12 | <wycats> | uh... that's not gonna happen... |
| 08:13 | <Hixie> | wycats: webidl really shouldn't ever be seen by authors ideally |
| 08:13 | <Hixie> | wycats: i mean, unless they want to see the nitty gritty |
| 08:13 | <wycats> | Hixie: 100% |
| 08:13 | <Hixie> | wycats: it's meant purely as a way to describe impl requirements |
| 08:13 | <wycats> | Hixie: it's nice for me to be able to peer into the UA stuff sometimes |
| 08:13 | <wycats> | but it shouldn't be the first line of attack |
| 08:14 | <Hixie> | wycats: i tried making the appcache bit make more sense, take a look |
| 08:14 | <wycats> | just refresh? |
| 08:15 | <Hixie> | yeah |
| 08:15 | <wycats> | Hixie: in general, do you think it makes sense to have a parallel thing for authors? |
| 08:15 | <wycats> | Hixie: what part did you update? |
| 08:15 | <wycats> | the event table? |
| 08:16 | <Hixie> | wycats: event table and the text before it |
| 08:16 | <Hixie> | wycats: i think it would be best to have a parallel thing, i think we should also make sure the spec makes sense for authors |
| 08:16 | <wycats> | Hixie: right now it is possible to understand for a few authors |
| 08:17 | <wycats> | Hixie: I kind of want to see the diff |
| 08:17 | <wycats> | it's hard to see what changed |
| 08:17 | <Hixie> | http://html5.org/tools/web-apps-tracker?from=4685&to=4686 |
| 08:17 | <wycats> | yay |
| 08:17 | <wycats> | still a little passive voice... who's firing the events ;) |
| 08:18 | <wycats> | +1 on the <strong> |
| 08:19 | <Hixie> | wycats: i'd love to make the spec better for authors in general, just not sure what exactly to do |
| 08:19 | <Hixie> | wycats: if you have specific ideas, you can file them by using the review tool at the bottom |
| 08:19 | <wycats> | Hixie: understood |
| 08:19 | <Hixie> | wycats: the kind of feedback that is most helpful is things like "as an author looking at this section, i couldn't easily tell which event was the first one to fire in this sequence" |
| 08:19 | <wycats> | Hixie: I'd say the biggest thing is just that it conceptually is organized differently from how authors think |
| 08:19 | <wycats> | so I was looking for "when does a change event get triggered" |
| 08:20 | <Hixie> | well we can add intro sections that handle that |
| 08:20 | <wycats> | as opposed to "when the user does X Y Z follow algorithm A" -> "In algorithm A: an event is fired with the N name" <- N resolves to change |
| 08:20 | <Hixie> | file bugs using the spec review tool along the lines of "as an author, i tried to find the answer to the question 'when does the change event fire?' and i couldn't figure out the answer." |
| 08:20 | <wycats> | haha |
| 08:20 | <wycats> | absolutely |
| 08:20 | <Hixie> | that would be really helpful for me in terms of making the spec better |
| 08:20 | <wycats> | where is the review tool? |
| 08:20 | <Hixie> | bottom left of the window |
| 08:21 | <Hixie> | when looking at the spec |
| 08:21 | <wycats> | specification annotation system? |
| 08:21 | <Hixie> | bottom left, not top left :-) |
| 08:22 | <wycats> | ah |
| 08:22 | <wycats> | comment |
| 08:22 | <wycats> | that always looked like it would end up in the black hole |
| 08:22 | <Hixie> | oh, no, not at all |
| 08:22 | <zcorpan> | i use it all the time |
| 08:23 | <Hixie> | so do i :-) |
| 08:23 | <wycats> | :) |
| 08:23 | <wycats> | good to know |
| 08:23 | <Hixie> | that's actually the most reliable way of sending feedback |
| 08:23 | <wycats> | I should take a day and do a full review |
| 08:23 | <Hixie> | irc tends to get lost, and e-mail to whatwg always gets a reply but it can take years |
| 08:23 | <wycats> | another thing that's really confusing is the verbiage around <input> |
| 08:23 | <wycats> | yeah totally |
| 08:24 | <wycats> | the "password state" is totally unintuitive to authors I feel |
| 08:24 | <Hixie> | yeah the whole forms section is definitely aimed more at implementors than authors |
| 08:25 | <wycats> | Hixie: and it's one of the most interesting/exciting parts |
| 08:25 | <wycats> | and one that people are most interested in emulating in Js |
| 08:25 | <wycats> | JS* |
| 08:25 | <Hixie> | the most helpful thing for me in terms of feedback would be reports like "as an author, i tried to find the answer to the question ... and couldn't find the answer" |
| 08:25 | <Hixie> | that gives me something very actionable to deal with as i can specifically find the best place to answer it and put the answer in clearly |
| 08:26 | <wycats> | Hixie: I'll happily file such things |
| 08:26 | <Hixie> | sweet |
| 08:26 | <Hixie> | that would be awesome |
| 08:26 | <wycats> | there's an entire other set of "as an author, I am interested in learning more about the new form controls and I can't figure it out" |
| 08:26 | <wycats> | which can totally be broken down a bit |
| 08:29 | <Hixie> | yeah an intro section for the forms section could help |
| 08:29 | <wycats> | worried about making it even larger |
| 08:29 | <Hixie> | it would be very helpful to have a list of questions to answer for such an intro section |
| 08:29 | <wycats> | Contexts in which this element may be used: |
| 08:29 | <wycats> | Where http://www.whatwg.org/specs/web-apps/current-work/multipage/content-models.html#phrasing-content is expected. |
| 08:30 | <wycats> | ^^ example of something that makes no sense to me as an author |
| 08:30 | <wycats> | which is stupid -- I'm being lazy as an author :/ |
| 08:30 | <Hixie> | what doesn't make sense? |
| 08:30 | <wycats> | so you go click on the phrasing content |
| 08:30 | <wycats> | right? |
| 08:31 | <Hixie> | hm? |
| 08:31 | <wycats> | maybe it's just all the jumping around |
| 08:31 | <wycats> | to try and figure out what's happening |
| 08:31 | <wycats> | sorry for not having my thoughts fully together here |
| 08:31 | <wycats> | http://www.whatwg.org/specs/web-apps/current-work/multipage/content-models.html#phrasing-content |
| 08:31 | <wycats> | is actually not too bad |
| 08:31 | <wycats> | maybe it would be good to have stuff like that pop up right there |
| 08:31 | <wycats> | to avoid losing the flow |
| 08:32 | <Hixie> | i've kinda lost track of what you mean |
| 08:32 | <wycats> | ok |
| 08:32 | <wycats> | so... when I'm reading, I often encounter alien language |
| 08:32 | <wycats> | which is defined elsewhere |
| 08:32 | <wycats> | before I know it I've jumped 2 or 3 times |
| 08:32 | <wycats> | and I've lost track of what's going on |
| 08:32 | <wycats> | (ADD?) :P |
| 08:33 | <Hixie> | not sure how to fix that |
| 08:33 | <wycats> | "phrasing content" is also known as "inline content" in CSS? |
| 08:33 | <wycats> | Hixie: I was suggesting having it pop up |
| 08:33 | <wycats> | right there |
| 08:33 | <wycats> | maybe have an <acronym> for things like phrasing content |
| 08:33 | <wycats> | this is good enough: "Phrasing content is the text of the document, as well as elements that mark up that text at the intra-paragraph level. Runs of phrasing content form paragraphs" |
| 08:33 | <Hixie> | phrasing content has nothing to do with inline content in CSS, it's similar to what HTML4 called "inline elements" but we renamed it because it was very confusing having CSS and HTML both call things "inline" that had nothing to do with each other |
| 08:34 | <wycats> | Hixie: I see |
| 08:34 | <wycats> | presumably phrasing content normally defaults to being styled as inline content? |
| 08:35 | <wycats> | Hixie: what do you think about making things like "phrasing content" just have a little popup with the summary |
| 08:36 | <wycats> | am I going off the rails here/ |
| 08:36 | <wycats> | ? |
| 08:37 | <Hixie> | most phrasing content elements usually default to display:inline |
| 08:37 | <Hixie> | i suppose we could have a popup |
| 08:37 | <Hixie> | but someone would have to figure out what the popups should say :-) |
| 08:38 | <Hixie> | the problem is that i don't want to mislead people by giving them simplified explanations that aren't correct |
| 08:38 | <wycats> | Hixie: there's already a summary up top of each |
| 08:38 | <wycats> | you can click for more info |
| 08:39 | <wycats> | presumably "Phrasing content is the text of the document, as well as elements that mark up that text at the intra-paragraph level. Runs of phrasing content form paragraphs." is correct? |
| 08:39 | <wycats> | For "embedded content" it would make more sense to just list the elements |
| 08:39 | <Hixie> | phrasing content is described by that reasonably briefly, yeah |
| 08:39 | <Hixie> | but many things have complicated definitions |
| 08:39 | <wycats> | for all cases but phrasing content actually |
| 08:39 | <wycats> | agree |
| 08:39 | <wycats> | we don't have to bite it all off at once |
| 08:42 | <Hixie> | i suppose we could have a floating iframe or something that when you click links it jumps the iframe to that link rather than jumping the main spec or something |
| 08:45 | <wycats> | hm |
| 08:45 | <wycats> | Hixie: back when I was getting myself into trouble over WebIDL I was considering spiking out what a section would look like if it was focused on authors |
| 08:45 | <wycats> | maybe I should do that for web forms? |
| 08:47 | <Hixie> | i'm not sure what you mean. In general, the spec is intended for everyone, but generally that's done by having intro sections for authors, followed by requirements for implementors. |
| 08:47 | <Hixie> | i'd be happy to add more intro sections for authors in the forms section, i just need to get a better idea of what kind of questions need answering |
| 08:49 | <wycats> | absolutely |
| 08:49 | <wycats> | ok... so I'll go through the spec and start throwing in comments |
| 08:49 | <wycats> | preferably not at 1am ;) |
| 08:49 | <Hixie> | cool, i look forward to them :-) |
| 08:49 | <wycats> | Hixie: the tricky part is that sometimes the sheer amount of info makes it hard to read -- +1 on the author view |
| 08:49 | <wycats> | yep |
| 08:49 | <Hixie> | when you file a bug it gives you the bug number with a URL, btw |
| 08:50 | <Hixie> | you can follow the bug (Cc yourself, etc) if you want, which would be helpful in case I need to ask further questions before I can fix the problem |
| 08:50 | <Hixie> | glad the author view helps |
| 08:50 | <Hixie> | tell people about it :-) |
| 08:50 | <Hixie> | we haven't done a good job about spreading that info around |
| 08:50 | <Hixie> | btw if you want to participate more, we have a blog that you can post on, and a wiki you can use if you need scratch space |
| 08:51 | <Hixie> | we'd love to get authors more involved |
| 08:51 | <Hixie> | but we kinda need someone to lead such an effort |
| 08:51 | <wycats> | whoa I submitted a comment and it was like 4 steps |
| 08:51 | <wycats> | link to the blog? |
| 08:51 | <wycats> | Hixie: I'm already set up with permissions and such |
| 08:51 | <wycats> | I went through the process a few months ago |
| 08:51 | <Hixie> | blog.whatwg.org and wiki.whatwg.org |
| 08:52 | <Hixie> | is 4 steps a lot or not? not sure if you're saying it's too much or too little :-) |
| 08:52 | <wycats> | too much :) |
| 08:52 | <wycats> | I want to type something and hit enter |
| 08:52 | <wycats> | Hixie: I can only have one comment per sectin? |
| 08:52 | <Hixie> | you can have as many as you like, just file them separately |
| 08:52 | <wycats> | or is it just not clearing it? |
| 08:52 | <Hixie> | not clearing |
| 08:52 | <wycats> | how can I see what I submitted? |
| 08:52 | <Hixie> | i added the prompts because people were filing bogus bugs |
| 08:53 | <Hixie> | the last alert should give you a link |
| 08:53 | <Hixie> | looks like http://www.w3.org/Bugs/Public/show_bug.cgi?id=8914 |
| 08:54 | <Hixie> | i've removed the prompt, we'll see how many people file bogus bugs |
| 08:54 | <wycats> | ha |
| 08:54 | <Hixie> | that makes it 3 steps |
| 08:54 | <Hixie> | let me see if i can make enter work |
| 08:54 | <wycats> | "the http://www.whatwg.org/specs/web-apps/current-work/multipage/browsers.html#active-document of the http://www.whatwg.org/specs/web-apps/current-work/multipage/web-application-apis.html#script's-browsing-context"; <- is there a way we can have a phrase that's more descriptive for that particular combination? |
| 08:55 | <Hixie> | hm? |
| 08:55 | <hsivonen> | I don't see how it helps for WAI specs to have theoretically malleable non-normative exegeses if government entities snapshot those as normative (like Québec) |
| 08:55 | <wycats> | "the active document of the script's browsing context" -- is there more author-friendly terminology we can use here (in addition to the existing) |
| 08:55 | <wycats> | is what I'm submitting |
| 08:55 | <wycats> | :) |
| 08:56 | <wycats> | what do you think about hiding the IDL in author mode? |
| 08:58 | <Hixie> | we could I guess |
| 08:58 | <Hixie> | some people like the IDL though, gives them a nice overview |
| 08:59 | <wycats> | true |
| 08:59 | <wycats> | omg thousands of users |
| 09:01 | <wycats> | I feel like I'm spamming the tracker |
| 09:03 | <Hixie> | heh no worries |
| 09:05 | <Philip`> | It's anonymous, nobody will know to blame you :-) |
| 09:05 | <wycats> | ha |
| 09:06 | <wycats> | a lot of my comments are mainly just asking whether there's a way to make clearer what a term actually means in real life |
| 09:06 | <wycats> | feel free to reject them all, I guess |
| 09:07 | <Hixie> | finding good terms is hard |
| 09:07 | <Hixie> | if anyone has any suggestions, please list them in the bugs! |
| 09:07 | <wycats> | :) |
| 09:07 | <wycats> | I've been :) |
| 09:07 | <wycats> | "User agents raise a SECURITY_ERR exception whenever any of the members of an HTMLDocument object are accessed by scripts whose effective script origin is not the same as the Document's effective script origin." |
| 09:07 | <wycats> | I suggested referencing the same origin policy |
| 09:08 | <annevk> | same origin policy is not really explained yet anywhere though |
| 09:08 | <wycats> | annevk: maybe we should get on that ;) |
| 09:09 | <wycats> | I love the use of quirks mode in the spec |
| 09:09 | <Hixie> | the same origin policy is "the html5 spec", sadly, i don't know that we can simplify it much further |
| 09:12 | <wycats> | Hixie: right -- I wasn't suggesting that we could |
| 09:12 | <wycats> | I was suggesting that referencing the term there would make it clear what we were talking about |
| 09:12 | <wycats> | "scripts whose effective script origin is not the same as the Document's effective script origin." <- took me a few to grok |
| 09:12 | <annevk> | Hixie, well yeah, but a high level overview is something we could someday give |
| 09:12 | <annevk> | Hixie, though maybe it should be in the origin spec |
| 09:13 | <Hixie> | wycats: the one place where i use the term resulted in someone complainig that it wasn't defined :-( |
| 09:13 | <Hixie> | http://www.w3.org/Bugs/Public/show_bug.cgi?id=8866 |
| 09:14 | <Hixie> | feel free to comment on that bug if you have anything to add to it |
| 09:14 | <wycats> | will do boss :) |
| 09:14 | <Hixie> | :-) |
| 09:15 | <wycats> | hmmm... it doesn't find my username... |
| 09:15 | <wycats> | pretty sure I have an account |
| 09:16 | <wycats> | created account |
| 09:17 | <wycats> | done: http://www.w3.org/Bugs/Public/show_bug.cgi?id=8866 |
| 09:19 | <wycats> | Hixie: according to the spec, a title element can exist in the body, but if there's no head, document.title = is ineffective |
| 09:19 | <wycats> | am I reading this wrong? |
| 09:19 | <Hixie> | it shouldn't say it can exist in the body |
| 09:19 | <Hixie> | well i mean it can _exist_ there, but it's not allowed there |
| 09:20 | <wycats> | "The title element of a document is the first title element in the document (in tree order), if there is one, or null otherwise." |
| 09:20 | <wycats> | "Returns the document's title, as given by the title element" |
| 09:20 | <wycats> | doesn't prevent it from being in the body |
| 09:20 | <wycats> | but... "Can be set, to update the document's title. If there is no head element, the new value is ignored." |
| 09:21 | <Hixie> | right, that's an example of error handling, where the spec tries to handle errors gracefully, but tries to minimise authors making new errors |
| 09:22 | <wycats> | Hixie: so if I put a title in the body, document.title works, but document.title= fails? |
| 09:22 | <Hixie> | right |
| 09:22 | <wycats> | also, I seem to have lost the comment box! |
| 09:22 | <Hixie> | well |
| 09:22 | <Hixie> | unless you have a <head>, which most people will |
| 09:22 | <wycats> | Hixie: that seems really unexpected |
| 09:22 | <wycats> | Hixie: understood |
| 09:22 | <wycats> | seems like an error should be raised |
| 09:23 | <wycats> | instead of silent failing |
| 09:23 | <Hixie> | look in the bottom right, there should be an arrow button to make it return |
| 09:23 | <Hixie> | an exception? |
| 09:23 | <wycats> | error |
| 09:23 | <wycats> | me and my ruby ways |
| 09:23 | <wycats> | don't see no arrows |
| 09:23 | <Hixie> | i don't think we can change that, it's probably locked down based on what pages do |
| 09:23 | <Hixie> | odd |
| 09:23 | <wycats> | Hixie: got it |
| 09:24 | <wycats> | I'm here: http://dev.w3.org/html5/spec/dom.html#dom |
| 09:24 | <wycats> | is that the wrong place? |
| 09:24 | <wycats> | it is :P |
| 09:24 | <Hixie> | you don't want the w3c copy, it doesn't have the review comments thing |
| 09:24 | <wycats> | right |
| 09:24 | <Hixie> | and it's blue, green is clearly a better colour :-P |
| 09:24 | <wycats> | I got lost |
| 09:25 | <gsnedders> | red > *. |
| 09:25 | <wycats> | ha! |
| 09:27 | <wycats> | is NodeList defined to be document order? |
| 09:28 | <annevk> | ja |
| 09:30 | <wycats> | so I have a question I'm going to submit: How does an author *get* an object implementing DOMHTMLImplementation? |
| 09:30 | <wycats> | is there another place that actually should go? |
| 09:31 | <annevk> | dom3core maybe? |
| 09:32 | <wycats> | annevk: do you think it makes sense to mention it here for authors? |
| 09:32 | <wycats> | yay done with 3.1 ;) |
| 09:32 | <wycats> | hahahaha: "Authors must not use elements, attributes, or attribute values for purposes other than their appropriate intended semantic purpose. Authors must not use elements, attributes, or attribute values that are not permitted by this specification or other applicable specifications." |
| 09:32 | <wycats> | I am laughing hard right now |
| 09:42 | <wycats> | Hixie: I feel strongly about http://www.w3.org/Bugs/Public/show_bug.cgi?id=8928 |
| 09:43 | <Hixie> | i don't look at how strongly people feel about things, only about the strength of the arguments put forward :-) |
| 09:43 | <Hixie> | but that seems like a reasonable bug from a quick glance |
| 09:47 | <wycats> | Hixie: ha I didn't mean to file a specific bug about the volumechange event |
| 09:47 | <wycats> | the entire table is busted ;) |
| 09:48 | <wycats> | I can clarify |
| 09:48 | <wycats> | it doesn't seem like ^^ is a goal of the table |
| 09:49 | <Hixie> | i can't look at specifics right now, but i will definitely look at the bugs in detail in the coming days and weeks -- please include as much detail as possible in each bug so that i can work out what it is you want changed :-) |
| 09:50 | <wycats> | Hixie: will do |
| 09:50 | <wycats> | Hixie: I'm treating it like an annotation exercise |
| 09:50 | <wycats> | going through the spec and annotating things I have questions/bugs about |
| 09:50 | <Hixie> | cool |
| 09:58 | <zcorpan> | wycats: i agree it's more useful if the spec said when and where events fired instead of listing where event handlers can be specified |
| 09:58 | <zcorpan> | since most event handlers can be specified everywhere |
| 09:59 | <wycats> | zcorpan: :) |
| 09:59 | <annevk> | and not all events have event handlers |
| 09:59 | <wycats> | indeed |
| 10:00 | <wycats> | that's the specific issue I had that caused me to hop in here |
| 10:00 | <zcorpan> | wycats: oh but there's an Events section in Index |
| 10:00 | <wycats> | zcorpan: look at it |
| 10:00 | <wycats> | :) |
| 10:00 | <wycats> | I linked to it above |
| 10:00 | <wycats> | it doesn't provide the info |
| 10:00 | <wycats> | it always says "HTML Element" |
| 10:00 | <wycats> | even when it's clearly not true |
| 10:00 | <wycats> | such as volumechange |
| 10:00 | <zcorpan> | you're looking at a different table |
| 10:01 | <zcorpan> | scroll down |
| 10:01 | <zcorpan> | http://www.whatwg.org/specs/web-apps/current-work/multipage/section-index.html#events-0 |
| 10:01 | <wycats> | I don't see volumechange in there |
| 10:02 | <wycats> | no waiting |
| 10:02 | <wycats> | etc. |
| 10:02 | <wycats> | for change: "Fired at controls when the user commits a value change" |
| 10:02 | <zcorpan> | "Note: See also media element events, application cache events, and drag-and-drop events." |
| 10:02 | <wycats> | that could be significantly clearer |
| 10:02 | <wycats> | oy |
| 10:03 | <wycats> | ok I take it back |
| 10:03 | <wycats> | the info is all here... I think... |
| 10:03 | <wycats> | but the organization leaves a lot to be desired |
| 10:03 | <Hixie> | btw, it's usually more helpful to say what question you were trying to answer that you couldn't get an answer for than just saying something is unclear, as i often look at something that is said to be unclear and think "well it looks clear to me..." because i'm asking different questions :-) |
| 10:04 | <wycats> | Hixie: hm I will try to be clearer :) |
| 10:04 | <wycats> | feel free to ask follow-ups |
| 10:04 | <wycats> | Hixie: in this case, what's unclear is what is meant by "the user commits a value change" |
| 10:04 | <wycats> | it's not linked to anything |
| 10:05 | <Hixie> | i'm not sure what i'd link to |
| 10:05 | <wycats> | also, the values available in each event would be useful (I believe they're generally described in the UA algorithms) |
| 10:05 | <wycats> | Hixie: there should probably be a section explaining what "commits a value" means |
| 10:06 | <Hixie> | what it means takes multiple sections to describe |
| 10:06 | <Hixie> | (btw, the "Interface" column links to the definitions of the interfaces, which lists the possible values for the event) |
| 10:06 | <wycats> | Hixie: "commits a value" can link to each explanation |
| 10:06 | <wycats> | Hixie: I see that |
| 10:06 | <wycats> | so the vast majority of these are generic Event? |
| 10:07 | <wycats> | why isn't Event linked? |
| 10:07 | <Hixie> | i don't understand how "commits a value" isn't clear... what's the question you're trying to ask that explains it? |
| 10:07 | <Hixie> | Event doesn't have any values |
| 10:07 | <wycats> | thank you for your patience |
| 10:07 | <Hixie> | (and it's defined in a different spec) |
| 10:07 | <wycats> | Hixie: I know what "commits a value" means in practice |
| 10:07 | <Hixie> | (we don't have cross-spec cross-references working yet... gsnedders is working on a script to do it) |
| 10:07 | <wycats> | but for instance, typing in a text box |
| 10:08 | <wycats> | at what point is it considered "committed" |
| 10:08 | <wycats> | I happen to know that it's committed on blur |
| 10:08 | <Hixie> | that's more or less up to the browser |
| 10:08 | <gsnedders> | (actually, I'm working on 10.50, not on Anolis2) |
| 10:08 | <wycats> | Hixie: It's fine to have a section that says that |
| 10:08 | <wycats> | although that's really not great |
| 10:08 | <wycats> | imho it should be specified |
| 10:08 | <Hixie> | i don't know how it can be specified |
| 10:08 | <wycats> | there are IE/everyone else discrepancies on this that suck |
| 10:08 | <Hixie> | different browsers are different |
| 10:08 | <wycats> | (specifically wrt checkboxes) |
| 10:09 | <wycats> | when I click a checkbox, what is supposed to happen? |
| 10:09 | <Hixie> | when you type something in on an iPhone, it's gonna work differently than when you're using a speech-based browser, than when you're using a braille display, than when you're using a huge display in Times Square |
| 10:09 | <wycats> | committed or not committed? |
| 10:09 | <Hixie> | i dunno |
| 10:09 | <Hixie> | depends how the checkbox works |
| 10:09 | <wycats> | hm |
| 10:09 | <wycats> | Hixie: I think this is fair |
| 10:09 | <wycats> | we should be explicit about it |
| 10:09 | <wycats> | just a little section that says it's UA-specific |
| 10:09 | <wycats> | and link |
| 10:10 | <wycats> | because tbh until right now I didn't assume that to be true |
| 10:10 | <Hixie> | it's defined in the UA parts of the spec, e.g. "The activation behavior is to fire a simple event that bubbles named change at the element, then broadcast formchange events at the element's form owner." in 4.10.5.1.16 Checkbox state |
| 10:11 | <Hixie> | http://www.whatwg.org/specs/web-apps/current-work/multipage/content-models.html#interactive-content defines activation steps (again in the UA-specific bits) |
| 10:11 | <Hixie> | i have no idea how to boil all that down to some author-facing text that is of any use to authors |
| 10:12 | <wycats> | Hixie: understood |
| 10:12 | <wycats> | "It would be inappropriate, however, for the user to use generic software not associated with that music site to search for tracks of a certain length by looking at this data. This is because these attributes are intended for use by the site's own scripts, and are not a generic extension mechanism for publicly-usable metadata." |
| 10:12 | <wycats> | I don't understand this at all |
| 10:12 | <wycats> | why is this true? |
| 10:12 | <wycats> | preserve this space for the RDFa/microdata wars? |
| 10:13 | <Hixie> | it's because otherwise we'd end up with authors not able to use any attribute |
| 10:13 | <Hixie> | the idea of the data-* attributes is to reserve them for authors |
| 10:13 | <wycats> | but why can't I say: "hey world: I've put some info here in data-duration" |
| 10:13 | <Hixie> | because my data-duration might be different than yours |
| 10:14 | <virtuelv> | can anyone give me any good reason why html notifications are a good thing? |
| 10:14 | <virtuelv> | to me, they are "popups version 2" |
| 10:14 | <wycats> | Hixie: but I'm putting it on my page for other people I communicate with to use |
| 10:14 | <wycats> | not as a general-purpose name |
| 10:14 | <Hixie> | wycats: we don't want e.g. google to say "ok, data-snippet is a piece of text we'll use in search results" and then everyone who uses data-snippet already gets screwed |
| 10:14 | <virtuelv> | in terms of annoyance potential, that is |
| 10:14 | <Hixie> | wycats: if you want to communicate with others, that's what microdata is for |
| 10:14 | <wycats> | Hixie: more specs / |
| 10:14 | <wycats> | :/ |
| 10:15 | <Hixie> | wycats: microdata lets you define a vocabulary such that you won't clash with everyone else |
| 10:15 | <Hixie> | microdata is part of the same spec :-) |
| 10:15 | <Hixie> | just liek data-* :-) |
| 10:15 | <wycats> | I know |
| 10:15 | <wycats> | I am aware |
| 10:15 | <Hixie> | (at least on the whatwg side) |
| 10:15 | <wycats> | lemme skim it |
| 10:15 | <wycats> | isn't there some huge war about this? |
| 10:15 | <Hixie> | yeah |
| 10:15 | <wycats> | I'm really not fully briefed |
| 10:15 | <Hixie> | some people prefer rdfa |
| 10:16 | <Hixie> | the microdata section has a long author-facing intro |
| 10:16 | <Hixie> | which hopefully you'll find helpful |
| 10:16 | <wycats> | yeah reading it :) |
| 10:16 | <Hixie> | it's one of the better sections in terms of being friendly for authors |
| 10:16 | <wycats> | huh... so this actually lets you do arbitrary things |
| 10:17 | <wycats> | this seems more appropriate for what we're doing in Rails |
| 10:17 | <wycats> | as opposed to data-* |
| 10:18 | <Hixie> | hsivonen: calendar notifications don't _require_ acknowledgement, they just happen to offer the user a way to jump to certain features (see the event, snooze the alarm, etc) |
| 10:18 | <Hixie> | wycats: possible, yeah. it's newer. |
| 10:18 | <hsivonen> | the distinction is pretty clear: data-* is for scripts, microdata is for bots |
| 10:18 | <Hixie> | basically |
| 10:18 | <wycats> | not interested in stepping into a war |
| 10:18 | <Hixie> | don't blame you |
| 10:18 | <wycats> | hsivonen: in our case, we're a script, but we're also designing a general purpose spec for scripts |
| 10:19 | <hsivonen> | Hixie: iCal alarms, Awaken alarms and alarms or my phone all *require* acknowledgement and are quite distinct from Growl |
| 10:20 | <hsivonen> | wycats: <script>s or server-side scripts? |
| 10:20 | <wycats> | hsivonen: <script>s |
| 10:20 | <wycats> | http://github.com/rails/jquery-ujs/blob/master/src/rails.js |
| 10:20 | <hsivonen> | if the person who controls the attributes also chooses whether to include a particular <script>, data-* is appropriate |
| 10:20 | <Hixie> | hsivonen: ah. the notifications that Google would like for Google Calendar (insofar as Google has a single opinion, which isn't very far) are notifications that self-cancel once the event is over. |
| 10:20 | <wycats> | hsivonen: Rails controls the attributes |
| 10:21 | <wycats> | users control the <script> |
| 10:21 | <wycats> | we also ship with some standard <script>s |
| 10:21 | <wycats> | for say, jQuery |
| 10:21 | <wycats> | or Prototype |
| 10:21 | <wycats> | but you don't NEED to use those |
| 10:21 | <Hixie> | the term "user" here is a bit ambiguous... do you mean the user of rails, or the user of the final app? |
| 10:21 | <hsivonen> | without knowing all the details, I'd go with data-rails-* |
| 10:22 | <wycats> | Hixie: the user of Rails |
| 10:22 | <wycats> | call them end-developers |
| 10:22 | <wycats> | hsivonen: data-rails-* is ugly :/ |
| 10:22 | <hsivonen> | or data-nonrailsformatnamehere-* |
| 10:22 | <wycats> | also we don't want to bind to Rails |
| 10:22 | <wycats> | if CakePHP wants to use the same markup, they can get our libraries |
| 10:23 | <wycats> | and any other libraries someone wrote |
| 10:23 | <Hixie> | it's not clear to me what problem you're solving so it's hard to really give good advice |
| 10:23 | <hsivonen> | wycats: do you have a name for this spec? |
| 10:23 | <wycats> | hsivonen: not yet :) |
| 10:23 | <hsivonen> | data-nameofspec-* :-) |
| 10:23 | <wycats> | Hixie: the problem is: frameworks want to be able to provide JavaScript helpers, but inline JS sucks horribly |
| 10:23 | <wycats> | a better solution is to describe semantically what's happening |
| 10:23 | <wycats> | and then allow people to write JS to script the markup |
| 10:24 | <Hixie> | so you wouldn't want, say, google to do anything with this data |
| 10:24 | <wycats> | As of Rails 3, we are shipping markup |
| 10:24 | <wycats> | Hixie: in general not |
| 10:24 | <Hixie> | then data-* is what you want |
| 10:24 | <wycats> | got it |
| 10:24 | <Hixie> | or rather i should say |
| 10:24 | <Hixie> | data-* is applicable |
| 10:24 | <Hixie> | microdata probably is too |
| 10:25 | <Hixie> | microdata is applicable in many cases where data-* is, they have some overlap |
| 10:25 | <wycats> | an example would be a link that, when clicked, will get an HTML fragment and insert it into a DOM node: <a href="... |
| 10:25 | <wycats> | " |
| 10:25 | <Hixie> | it depends on whether e.g. you're trying to overlay a separate data model, or whether you want to annotate specific elements (e.g. "this element is open") |
| 10:25 | <wycats> | whoops |
| 10:25 | <wycats> | <a href="..." data-remote="true" data-update="#node"> |
| 10:26 | <Hixie> | yeah for that you want data-* |
| 10:26 | <Hixie> | microdata doesn't apply to specific elements, it's just kinda overlaid on top of them |
| 10:26 | <wycats> | so basically what we're doing works? |
| 10:26 | <Hixie> | seems like it to me |
| 10:26 | <Hixie> | (microdata is like a parallel plane of reality that happens to touch the html plane in many of the same places, like in many fantasy stories!) |
| 10:26 | <wycats> | :-D |
| 10:26 | <wycats> | Hixie: ha |
| 10:38 | <wycats> | Hixie: the requests don't seem to be going through anymore |
| 10:38 | <wycats> | I don't get any "thank you"s anymore |
| 10:38 | <Hixie> | that's not a good sign |
| 10:38 | <Hixie> | i may have broken the script, hold on |
| 10:38 | <wycats> | Content-Language:en-GB-x-Hixie |
| 10:38 | <wycats> | hahahahah |
| 10:38 | <Hixie> | (i've been trying to tweak it a bit) |
| 10:39 | <wycats> | :) |
| 10:39 | <wycats> | how can I see a list of the newest reported bugs? |
| 10:41 | <Hixie> | http://bit.ly/blwuuD - look at the bottom |
| 10:42 | <Hixie> | oh i see the problem |
| 10:43 | <wycats> | I'm dave.null? |
| 10:43 | <Hixie> | try reloading the spec, it should work again |
| 10:43 | <wycats> | oh I'm contributor@ |
| 10:43 | <Hixie> | you're contributor⊙wo |
| 10:43 | <wycats> | I signed in |
| 10:43 | <Hixie> | well, the form is contributor⊙wo |
| 10:43 | <wycats> | shouldn't it be submitting it as me? |
| 10:43 | <wycats> | ah |
| 10:44 | <Hixie> | you can mass-cc yourself to bugs you filed from that page btw |
| 10:44 | <Hixie> | which would be helpful if i need to ask for more info :-) |
| 10:44 | <wycats> | yah |
| 10:44 | <wycats> | will do |
| 10:44 | <Hixie> | if you cc yourself you'll get e-mails whenever i update the bug, which you'll see involves some ugly-ass boilerplate that's part of the w3c htmlwg process :-) |
| 10:45 | <Hixie> | tells you your rights and so forth each time i accept or reject a suggestion :-) |
| 10:45 | <zcorpan> | you have the right to remain silent |
| 10:46 | <wycats> | nice |
| 10:46 | <wycats> | I added myself :) |
| 10:46 | <wycats> | seems as though if I log in on the spec page the tickets should come from me |
| 10:47 | <Hixie> | yeah it'd be nice to have something like that set up |
| 10:47 | <wycats> | :-D |
| 10:47 | <Hixie> | but i'd have to ask for your bugzilla password and stuff and i don't want to be responsible for managing the security behind that |
| 10:48 | <zcorpan> | it could set cc |
| 10:49 | <Hixie> | hmm, good point |
| 10:49 | <wycats> | +1 |
| 10:49 | <Hixie> | it could try, anyway |
| 10:49 | <wycats> | Hixie: from what I understand CORS was set up to handle this |
| 10:49 | <wycats> | I kid I kid |
| 10:49 | <Hixie> | if we had CORS set up this would be 100x easier |
| 10:50 | <Hixie> | cos i could just do a cross-site request from JS |
| 10:50 | <wycats> | Hixie: do it |
| 10:50 | <wycats> | Hixie: I'm using a CORS-compliant browser |
| 10:50 | <wycats> | ;) |
| 10:50 | <Hixie> | as it is i have to bounce everything through my server |
| 10:50 | <Hixie> | yeah but bugzilla isn't CORS-aware |
| 10:50 | <wycats> | Hixie: I thought it was really easy to convince people to change their stuff ;) |
| 10:50 | <wycats> | Hixie: yeah this is the problem I was running into |
| 10:51 | <wycats> | that firewall problems sucks |
| 10:52 | Hixie | looks into what it would take to have hie file-bug.cgi script use the email address from the database used by status.cgi |
| 10:53 | <annevk> | CORS-compliant? doubt it :) |
| 10:53 | <wycats> | annevk: earlier I was complaining that there wasn't a way to do a cross-origin request with no credentials and no cooperation |
| 10:53 | <wycats> | on the grounds that HTTP requests should be safe |
| 10:53 | <wycats> | Hixie was explaining the firewall issue :/ |
| 10:54 | <annevk> | we'll create a way prolly |
| 10:54 | <annevk> | credentialfree = new XMLHttpRequest(true) or some such |
| 10:54 | <wycats> | annevk: how do you get around the firewall problem |
| 10:54 | <wycats> | annevk: there's already credential-free CORS |
| 10:55 | <wycats> | but you still have to get permission |
| 10:55 | <annevk> | oh, you'd still need opt in from the server |
| 10:55 | <wycats> | right |
| 10:55 | <wycats> | even though in the vast majority of cases it's not actually needed |
| 10:55 | <annevk> | well, I meant credentialandoriginfree |
| 10:55 | <annevk> | sorry |
| 10:55 | <wycats> | like... I should be able to make an HTTP request to google.com |
| 10:55 | <wycats> | and see it |
| 10:55 | <annevk> | and forced by the constructor |
| 10:55 | <wycats> | I guess that kills CSRF defenses? |
| 10:55 | <wycats> | no it doesn't |
| 10:55 | <wycats> | I lie |
| 10:56 | <annevk> | doing a HTTP request to google and see it won't ever work |
| 10:56 | <wycats> | annevk: why not? |
| 10:56 | <annevk> | IP-authenticated, etc. |
| 10:56 | <wycats> | annevk: I don't know what that means :/ |
| 10:56 | <annevk> | you need server opt-in |
| 10:56 | <wycats> | annevk: why? |
| 10:57 | <annevk> | I thought Hixie explained that issue already |
| 10:57 | <wycats> | right |
| 10:57 | <annevk> | anyway, if you don't mind I'm going back to sorting out getComputedStyle |
| 10:57 | <wycats> | I thought you had something else to add :) |
| 10:57 | <wycats> | k |
| 10:57 | <wycats> | peace |
| 10:57 | <wycats> | the firewall situation just sucks :/ |
| 10:59 | <wycats> | I don't like that mobile web apps are inherently more constrained than their native counterparts :/ |
| 10:59 | <wycats> | (on this front) |
| 10:59 | <Hixie> | if anyone is filing any more bugs in the next few minutes, let me know if it fails |
| 10:59 | <wycats> | Hixie: I will be |
| 10:59 | <wycats> | reading though 3.2.5 |
| 11:00 | <wycats> | whoa <ins> and <del> can straddle <p> boundaries |
| 11:00 | <wycats> | gulp |
| 11:00 | <MikeSmith> | virtuelv: I seem to remember that Matthew Paul Thomas describing some reasonable use cases for notifications |
| 11:03 | <wycats> | Hixie: seems to have works |
| 11:03 | <wycats> | worked |
| 11:03 | <Hixie> | cool |
| 11:03 | <Hixie> | next step is to tell the file-bug script the username of the user |
| 11:04 | <Hixie> | btw if you reload you should see nice new fancy styles that lachy inspired me to do |
| 11:04 | <wycats> | I saw :) |
| 11:05 | <wycats> | Hixie: is there more information on document.write somewhere or is 3.5.3 all of it? |
| 11:05 | <Hixie> | what kind of information? |
| 11:05 | <Hixie> | i mean, the parser is obviously relevant to how documnet.write works |
| 11:05 | <Hixie> | and that's a huge section |
| 11:07 | <wycats> | Hixie: I just filed a bug to say that document.write should note that using it after the parser is done causes a new doc, which is implicit in "calls open() implicitly" |
| 11:07 | <virtuelv> | MikeSmith: there are plenty of legitimate uses of notifications |
| 11:07 | <virtuelv> | however, I would hate to see the onslaught of "V1AGRA!" flash notifications |
| 11:08 | <virtuelv> | which, coincidentally would be incompatible with notification systems like Growl or Ubuntu's own notifications |
| 11:08 | <wycats> | insertAdjacentHTML is huge win |
| 11:09 | <Hixie> | virtuelv: "Drink Pepsi!" |
| 11:09 | <wycats> | get that shit in Webkit! |
| 11:09 | <Hixie> | virtuelv: that's why any notification system has to have a mechanism by which you have to opt-in for the site to be able to use it |
| 11:09 | <virtuelv> | Hixie: my point is that the cognitive load difference between a google text ad, and a doubleclick evony ad is signifcant |
| 11:09 | <virtuelv> | significant* |
| 11:10 | <wycats> | "Wherever a subdocument fragment is allowed in a compound document" <- what cases are these? |
| 11:10 | <wycats> | I can just file a ticket to ask for explanation |
| 11:11 | <MikeSmith> | virtuelv: clearly to prevent that the solution is a policy-based notification mechanism and/or a notification policy framework or some other combination of policies and frameworks |
| 11:12 | <wycats> | ok fading fast |
| 11:12 | <wycats> | bedtime :) |
| 11:12 | <Hixie> | nn |
| 11:12 | <wycats> | thx for everything Hixie |
| 11:12 | <Hixie> | thank _you_! |
| 11:12 | <wycats> | helluva job :) |
| 11:12 | <MikeSmith> | in general, when you need a magic solution to a problem, you just need to throw some policies and frameworks at it and the problems will just sort of solve themselves |
| 11:17 | <wycats> | Hixie: unless I'm crazy I just noticed a circular dependency in the spec |
| 11:18 | <wycats> | Contexts in which this element may be used: Where http://www.whatwg.org/specs/web-apps/current-work/multipage/content-models.html#metadata-content is expected. |
| 11:18 | <wycats> | Metadata content is content that sets up the presentation or behavior of the rest of the content, or that sets up the relationship of the document with other documents, or that conveys other "out of band" information. => base command link meta noscript script style title |
| 11:18 | <wycats> | the first is to "link" |
| 11:18 | <wycats> | I don't see where the "contexts in which metadata-content is expected" is defined |
| 11:19 | <Hixie> | it's not a special term, it just means it's regular english meaning |
| 11:19 | <Hixie> | its |
| 11:19 | <wycats> | so where a human would expect metadata content? |
| 11:20 | <Hixie> | no, where a spec says "expects: metadata content" or some such |
| 11:20 | <wycats> | ah |
| 11:20 | <Hixie> | for example, the <head> element says "Content model: ... Zero or more elements of metadata content." |
| 11:21 | <wycats> | aha |
| 11:21 | <wycats> | "One or more elements of http://www.whatwg.org/specs/web-apps/current-work/multipage/content-models.html#metadata-content, of which exactly one is a title element" :) |
| 11:22 | <Hixie> | right |
| 11:23 | <virtuelv> | MikeSmith: if a solution requires a policy-based mechanism, it's probably going further than it needs |
| 11:36 | <MikeSmith> | virtuelv: yeah, and/or the policy mechanism is really a platform feature that could potentially be used across other applications running on the platform, not something specific to the browser or Web applications running within the browser |
| 11:37 | <virtuelv> | my other concern is that html notifications excludes external notification applications |
| 11:37 | <virtuelv> | which leaves security of the notification up to chance |
| 11:43 | <Hixie> | if anyone tries to file a bug let me know if it fails |
| 11:44 | Hixie | looks at http://www.w3.org/mid/CB173250-44A4-4E98-B723-101BB5673C85⊙wo and the resulting thread and wonders how to fix the problem without offending the xml core wg |
| 11:45 | <annevk> | can't we write an extension to XML similar to Namespaces for XML is an extension to XML? |
| 11:45 | <hsivonen> | positioning that kind of thing as an extension would be mind-blowing |
| 11:45 | <hsivonen> | extensions are supposed to be good but changing XML is bad |
| 11:46 | <MikeSmith> | Hixie: is the Interfaces appendix in the spec auto-generated? if so, there must be a bug in the script for it, because it's missing some elements -- e.g, del and command |
| 11:49 | <Hixie> | nothing is autogenerated |
| 11:49 | <Hixie> | except the entities |
| 11:49 | <annevk> | hsivonen, namespaces is an extension of XML |
| 11:50 | <MikeSmith> | the extensible markup language (...except for the parts that aren't open to further discussion about extending or changing, ever) |
| 11:50 | <annevk> | hsivonen, it's a separate spec after all |
| 11:50 | <annevk> | hsivonen, and every now and then it's positioned that XML without namespaces exists too |
| 11:50 | <annevk> | so it seems reasonable that a separate spec could increase the list of predefined entities... |
| 11:51 | <annevk> | (reasonable and prolly highly controversial at the same time) |
| 11:53 | Hixie | points to the "without offending" part of his comment :-) |
| 11:54 | <Hixie> | ok if you're logged in to the status annotation thingy, it'll cc you when filing bugs |
| 11:54 | <Hixie> | make sure your e-mail address is the same |
| 11:54 | <Hixie> | otherwise it'll break |
| 11:54 | <gsnedders> | Hmm, everything in Spotify is playing at double speed |
| 11:58 | <hsivonen> | sigh. it seems that I have broken the C++ version of named character tokenization but not the Java version |
| 11:59 | <hsivonen> | found the reason |
| 11:59 | <hsivonen> | whew |
| 12:02 | <zcorpan> | hmm, i use different addresses for the annotion and for bugzilla |
| 12:03 | <zcorpan> | Hixie: how does it break? does it just not add the cc? |
| 12:04 | <Hixie> | it probably fails to submit the bug |
| 12:04 | <Hixie> | it does whatever happens when you set a cc and bugzilla complains about the cc being unknown |
| 12:10 | <annevk> | Hixie, even with standardized REST APIs you still need some extra stuff in the browser, no? |
| 12:10 | <annevk> | e.g. I guess you want some kind of magic URI scheme that the browser binds to the appropriate service? |
| 12:10 | <Hixie> | you need a scheme and a path in that scheme, yeah |
| 12:10 | <annevk> | like data-service:contacts/... or some such |
| 12:11 | <Hixie> | yup |
| 12:11 | <zcorpan> | isn't urn in ie like namespaceURI? |
| 12:12 | <hsivonen> | zcorpan: so I've thought |
| 12:13 | zcorpan | creates a new account for the spec annotation system |
| 12:34 | <annevk> | here I thought I knew what should happen when properties allow mixing of identifiers and strings for the same thing and along comes font-family |
| 12:34 | <annevk> | I guess font-family is a special case and not everyone agrees for it anyway |
| 12:38 | <zcorpan> | what about font-family? |
| 12:38 | <asmodai> | hsivonen: Sorry to bother you on IRC -- but I am a bit confused about something, which I currently think is a mistake in the validator services you have as well as W3C's for HTML 5. |
| 12:39 | <asmodai> | hsivonen: Currently both are saying to me that <math> cannot occur enclosed in elements such as <p> or <div>, but looking at the spec it seems to allow this just fine. |
| 12:40 | <hsivonen> | asmodai: the validator doesn't allow it currently to discourage authors from deploying <math> or <svg> in text/html before browsers are ready |
| 12:41 | <hsivonen> | asmodai: there's currently no shipping browser that supports <math> or <svg> in text/html |
| 12:41 | <asmodai> | hsivonen: Ah ok, guess I am a bit unique then since I used XHTML + MathML profiles before. |
| 12:41 | <hsivonen> | but it would be better to allow it and to emit a warning |
| 12:41 | <asmodai> | hsivonen: Sure? Firefox 3.6 is then tricking me |
| 12:42 | <hsivonen> | asmodai: Firefox 3.6 in its default configuration doesn't support <math> in text/html |
| 12:42 | <annevk> | zcorpan, it differs per browser, but e.g. font-family:"foobar", omg omg, serif turns into 'foobar', 'omg omg', serif or "foobar",omg omg,serif |
| 12:42 | <asmodai> | hsivonen: Oh you mean with html5.enable set to false. |
| 12:42 | <hsivonen> | asmodai: right |
| 12:42 | <annevk> | in Opera it does something else altogether |
| 12:42 | <asmodai> | hsivonen: Right, fair point. |
| 12:42 | <hsivonen> | asmodai: if you set it to true, I recommend running trunk builds instead of the release |
| 12:43 | <hsivonen> | the HTML5 parser in the release is a snapshot from the end of June |
| 12:43 | <asmodai> | hsivonen: I haven't encountered much issues though. |
| 12:43 | <asmodai> | hsivonen: Then again, maybe mine are simplistic enough ;) |
| 12:44 | <asmodai> | hsivonen: Can I show you something in private related to this? |
| 12:44 | <hsivonen> | asmodai: ok |
| 12:51 | <annevk> | oh and, "foobar",omg turns into 'foobar', omg or 'foobar',omg |
| 12:51 | <annevk> | it seems nicer if custom values are consistently quoted |
| 12:51 | <annevk> | but maybe that can be changed |
| 12:54 | <asmodai> | So, just to get my thoughts straight, <svg> and <math> should be able to be enclosed with <div>, <p>, <span> and such elements, right? |
| 12:58 | <hsivonen> | asmodai: <math> and <svg> can appear where <img> can appear |
| 12:58 | <zcorpan> | annevk: i thought "foobar", "omg omg", serif was correct |
| 12:59 | <asmodai> | hsivonen: Cool, thanks for that verification. |
| 12:59 | <asmodai> | 23 |
| 13:00 | <zcorpan> | annevk: i think we do that for 2dcontext.font |
| 13:03 | <annevk> | zcorpan, interesting, we don't for fontFamily |
| 13:04 | <annevk> | but yeah, that sounds like how it should be |
| 15:13 | <moine> | hi |
| 15:13 | <jgraham> | hej |
| 15:13 | <moine> | i don't understand how to use websocket in html5 |
| 15:14 | <moine> | i try to understand http://dev.w3.org/html5/websockets/ |
| 15:14 | <moine> | what is this : http://dev.w3.org/html5/websockets/#the-websocket-interface |
| 15:14 | <moine> | javascript ? |
| 15:18 | <AryehGregor> | Yes, WebSockets are a JavaScript feature. |
| 15:36 | <MikeSmith> | AryehGregor: HTML WG wiki content has now all been migrated over to a MediaWiki instance - |
| 15:37 | <MikeSmith> | http://www.w3.org/html/wg/wiki/Main_Page |
| 15:37 | <AryehGregor> | :) |
| 15:37 | <MikeSmith> | byebye moinmoin |
| 15:37 | <MikeSmith> | (..and good riddance) |
| 15:38 | MikeSmith | heads off for some food |
| 15:52 | <TabAtkins> | Oh god, the star wars holiday special is as bad as everyone told me. |
| 15:53 | <Philip`> | There's a reason why they were telling you that :-) |
| 15:53 | <workmad3> | that's still on my 'to watch' list... right underneath 'hercules in new york' |
| 15:54 | Philip` | vaguely remembers its version of Kashyyyk being pretty close to the modern renditions of it |
| 15:55 | <Philip`> | (though with more singing) |
| 16:07 | <TheOutlawTorn> | Afternoon |
| 16:27 | <annevk> | hmm, margin-top behaves like nothing before |
| 16:27 | <annevk> | in theory margin-top "applies" when display is none |
| 16:28 | <annevk> | but there's no used value then... so browsers give the computed value |
| 16:32 | <annevk> | getComputedStyle #$@ |
| 16:35 | <jgraham> | Ahhh, you don't mean that, really |
| 16:39 | <annevk> | #$@ means great o_O |
| 16:47 | <annevk> | I guess padding-*, margin-*, *height/*width, line-height are the most special |
| 16:47 | <annevk> | when it comes to getComputedStyle |
| 16:47 | <annevk> | will prolly test the remaining details tomorrow and hopefully commit something |
| 16:47 | <annevk> | in Firefox top/left/right/bottom are also special but not in other browsers |
| 17:07 | annevk | wonders if HTML Microdata is a delta spec |
| 17:07 | <jgraham> | annevk: I think it effectively is |
| 17:08 | <jgraham> | Although it shouldn't be :( |
| 17:10 | <annevk> | every now and then I try a literal read of the HTML charter to see if the people complaining actually make sense |
| 17:10 | <annevk> | I'm not sure they do |
| 17:10 | <annevk> | but I don't really care either; guess I should find a better hobby |
| 17:11 | <annevk> | such as figuring out getComputedStyle, #$@ |
| 17:11 | <zcorpan> | maybe a hobby that doesn't involve angle brackets, or computers, or electricity |
| 17:12 | <annevk> | they don't really last (with apologies to markp) |
| 17:13 | <gsnedders> | you could try and read a book? |
| 17:14 | <jgraham> | That wouldn't last |
| 17:14 | gsnedders | needs to get more books, so he can give up on Ulysses and read something else |
| 17:14 | <annevk> | I read books, no worries, but currently I'm at Frank's place and have no access to it |
| 17:14 | <jgraham> | plural agreement error |
| 17:14 | <jgraham> | gsnedders: A good plan |
| 17:14 | <annevk> | and I skipped working for about an hour which I'm trying to catch up with now |
| 17:15 | <gsnedders> | jgraham: Not if I get what Jansson pointed me to, I expect, in your opinion. |
| 17:15 | <gsnedders> | (House of Night) |
| 17:16 | <jgraham> | I have no idea what that is, but I assume it involves pale faced young ladies and surprisingly toothy men with a taste for blood |
| 17:16 | <gsnedders> | Yes |
| 17:17 | <Philip`> | What does 'editorial change' actually mean? |
| 17:17 | <Philip`> | I've never quite figured it out |
| 17:18 | <gsnedders> | A change which has no normative changes to the spec? |
| 17:18 | <jgraham> | I think it means "change no one bothers to complain about later" |
| 17:18 | <AryehGregor> | It means a change that's not substantive, it just rewords something or whatnot but the meaning is the same. |
| 17:19 | <jgraham> | (or what gsnedders said ;) |
| 17:19 | <TabAtkins> | plinss: The use-case isn't really when it's like 2.6e-4, it's like 2.6e-30, which is way easier to read than .00000...26 |
| 17:19 | <TabAtkins> | bert?: In what cases is that not 0? |
| 17:19 | <gsnedders> | TabAtkins: Wrong channel? |
| 17:19 | <TabAtkins> | Shit. |
| 17:19 | gsnedders | guesses this is meant to be #css minutes |
| 17:19 | <Philip`> | Normative changes to a spec, rather than normative changes to the set of specs that in combination define the web platform? |
| 17:19 | <gsnedders> | Fail. |
| 17:20 | <TabAtkins> | I was wondering why "plinss" wasn't auto-completing. |
| 17:25 | <zcorpan> | there's a 10.5 beta? |
| 17:26 | <annevk> | beta rc |
| 17:26 | <annevk> | whatever that means |
| 17:27 | <Dashiva> | It's not quite alpha, but not entirely beta either |
| 17:27 | <zcorpan> | candidate for a beta |
| 17:29 | <Dashiva> | I'm surprised there isn't a firestorm about H:TML's name |
| 17:30 | <zcorpan> | suggest it be changed to X:HTML |
| 17:30 | <annevk> | why would there be? |
| 17:30 | <annevk> | it's not edited by Hixie |
| 17:31 | <AryehGregor> | H:TML is an incredibly confusing name, though. |
| 17:31 | <AryehGregor> | I mean, the abbreviation is. |
| 17:31 | <AryehGregor> | Now, random question: why did Apple introduce <link rel="apple-touch-icon"> instead of, say, <link rel="large-icon"> or something? |
| 17:32 | <annevk> | why not just use rel=icon plus sizes? |
| 17:32 | <AryehGregor> | Or that. |
| 17:32 | <annevk> | wc? |
| 17:32 | <zcorpan> | maybe it should be HTML5 Document Conformance Reference or something |
| 17:32 | <AryehGregor> | Does the iPhone support that? MediaWiki and Wikipedia output <link rel="apple-touch-icon">, and it annoys me. |
| 17:32 | <jgraham> | Didn't apple propose sizes for exactly this use case? |
| 17:32 | <annevk> | zcorpan, I'd suggest to let someone else bikeshed it |
| 17:32 | <Philip`> | Maybe because other browsers would always download the large icon and waste bandwidth? |
| 17:33 | <AryehGregor> | Would they? |
| 17:33 | <zcorpan> | annevk: we first need to start the bikeshed |
| 17:33 | Philip` | has no idea |
| 17:34 | <jgraham> | AryehGregor: Of course there is a cynical answer |
| 17:35 | <AryehGregor> | jgraham, enlighten me. |
| 17:40 | zcorpan | files a bug on hte name |
| 17:40 | <jgraham> | Getting your branding in markup is good advertising, especially if other people end up copying it for compatibility. It's one of the problems with namespace URIs; who wants to have a {http://netscape.com}img or a http://apple.com{canvas} |
| 17:41 | <jgraham> | s/http://apple.com{canvas}/{http://apple.com}canvas/ |
| 17:41 | Philip` | imagines that's part of the reason for the proliferation of DTDs |
| 17:41 | <AryehGregor> | Well, maybe. I think it's more likely to be patterned after stuff like -webkit-*, though. |
| 17:42 | <Philip`> | (The old ones with names of companies and WYSIWYG editors in them, that is) |
| 17:42 | <AryehGregor> | Ugh, and Apple also had to replicate the broken well-known-location behavior from favicon.ico. |
| 17:43 | <jgraham> | AryehGregor: There is a clear standardisation path there that typically works |
| 17:43 | <jgraham> | (for -webkit- and so on) |
| 17:43 | <Philip`> | (It's actually been pretty successful since now they get free advertisting in HTML specs for the rest of eternity, in the quirks mode lists) |
| 17:43 | <Philip`> | s/t// |
| 17:43 | <AryehGregor> | jgraham, only if it marks a not-yet-standard property rather than a private-use property that's not intended for standardization. |
| 17:43 | <AryehGregor> | I don't know why standards-conscious vendors allow the latter to be exposed to the public web at all. |
| 17:46 | <jgraham> | This is clearly not like a private-use property since it is intended for developers to use it |
| 17:48 | <AryehGregor> | Well, yes, so I guess they qualify as not standards-conscious. |
| 17:56 | <AryehGregor> | http://developer.apple.com/safari/library/documentation/AppleApplications/Reference/SafariWebContent/ConfiguringWebApplications/ConfiguringWebApplications.html |
| 17:56 | AryehGregor | glares |
| 18:01 | <zcorpan> | at least they don't use <meta http-equiv> |
| 18:01 | <AryehGregor> | Heh. |
| 18:03 | <AryehGregor> | I wish I could add <link sizes> support to MediaWiki and kill the apple-touch-icon thing, but I expect I'd get reverted. |
| 18:03 | <AryehGregor> | Hmm, it wouldn't break anything for Wikipedia, it seems -- the icon is at /apple-touch-icon.png anyway. |
| 18:03 | AryehGregor | plots |
| 22:08 | <TabAtkins> | "Microdata was created as a step towards this goal by people wishing RDFa's use cases not to be satisfied" - um, what? |
| 22:08 | <TheOutlawTorn> | hi |
| 22:09 | <Dashiva> | TabAtkins: The main use case of RDFa is using RDFa |
| 22:09 | <TabAtkins> | FFS, apparently. |
| 22:13 | <jgraham> | TabAtkins: I think that's called "making shit up" |
| 22:14 | <TabAtkins> | There has to be reasonable RDFa people around. They *have* to exist. Why are none of them on the HTMLWG list? |
| 22:16 | <jgraham> | TabAtkins: Maybe they have better things to do than sign up for a world of pain |
| 22:16 | <TabAtkins> | That would be a surprisingly rational action. |
| 22:17 | <jgraham> | FWIW there were several RDFa people who wrote quite reasonable, thoughtful blog posts about Microdata when it was first announced |
| 22:17 | <Dashiva> | TabAtkins: The reasonable RDFa people are mostly in the unification camp, I think |
| 22:17 | <jgraham> | So I have reason to believe that such people exist |
| 22:18 | <TabAtkins> | jgraham: That is a relief to hear. I don't read nearly enough web-tech-related blogs to know what the wider internet thinks about things. |
| 22:18 | <TabAtkins> | Dashiva: What precisely is the goal behind unification? Just finding an intersection between the two technologies, basically? |
| 22:18 | <Dashiva> | Not intersection... it's a bit more flexible |
| 22:19 | <jgraham> | TabAtkins: http://www.jenitennison.com/blog/node/124 was an example of a very well reasoned post |
| 22:19 | <Dashiva> | (And obviously there's no final definition, since if so we'd be debating adopting it.) |
| 22:21 | <jgraham> | I really don't understand the point of unification |
| 22:22 | <jgraham> | It's like saying that ruby and python should be unified because they cover a similar problem space |
| 22:22 | <jgraham> | Well sure, but they have totally different philosophys and make entirely differnt design trade offs |
| 22:22 | <TabAtkins> | jgraham: That is a good post. |
| 22:23 | <jgraham> | Surely better to let end users decide which is the better than spend years trying to reach some compromise that no one likes and has none of the original advantages of either approach |
| 22:24 | <Dashiva> | Surely we should see if improvements are possible before rejecting it |
| 22:24 | <Dashiva> | RDFa 1.1 isn't just "let's keep RDFa 1.0 completely intact" |
| 22:25 | <jgraham> | I am quite happy to let RDFa evolve however it likes and Microdata evolve however it likes and see which one works best at the end |
| 22:25 | <Dashiva> | Similarly, microdata is open-ended with regard to full graphs and data types |
| 22:26 | <jgraham> | I guess fragmentation is a possible issue but it is far from clear to me that it is a bigger issue than the type of compromise that you would have to make for microdata and RDFa to merge |
| 22:28 | <Dashiva> | It's not like it'd be one or the other. The hybrid might favor one side over the other. Even if a hybrid is proposed, people could still use the "originals" if they preferred. |
| 22:28 | <Dashiva> | But if one side can accomodate the other better without any real loss, it would be a better candidate to become majority use |
| 22:30 | Hixie | wonders what public-hypertext-cg is |
| 22:30 | <Dashiva> | The public face of the hypertext cg? |
| 22:30 | <Hixie> | apparently, though it only seems to be used by people cross-posting to it |
| 22:31 | <Dashiva> | Maybe they don't like www-archive |
| 22:33 | <carllerche> | Is there a way in canvas to draw the shadow for a path but not the actual path? when I set the fillStyle to 'rgba(0,0,0,0)' the shadow is not drawn either |
| 22:35 | <Philip`> | carllerche: No |
| 22:36 | <Philip`> | It uses the alpha from the drawn shape to generate the shadow |
| 22:36 | <carllerche> | Philip`: Is there a way to do this? will I have to draw the shadow myself? |
| 22:36 | <Philip`> | and it always composites both the shadow and the original shape onto the canvas |
| 22:36 | <carllerche> | Philip`: Is it possible to render multiple shadows per shape? |
| 22:37 | <Philip`> | You could set the shadow offset to be very large, and draw the shape somewhere off-screen, so only the shadow is visible |
| 22:38 | <carllerche> | hmm, tricky :) |
| 22:38 | <carllerche> | i'll try that |
| 22:38 | <Philip`> | The shadows are rendered once each time you call fill()/stroke(), though you can call fill/stroke multiple times per path |
| 22:39 | <Dashiva> | Maybe easier to just draw the shadows manually :) |
| 22:40 | <Philip`> | http://canvex.lazyilluminati.com/misc/shadow/shadow2.html emulates shadowing manually |
| 22:41 | <Philip`> | by doing the Gaussian blur |
| 22:41 | <carllerche> | thanks for that tip |
| 22:42 | <carllerche> | for some reason, if the fillStyle is set to 'black' the shadow renders correctly, if it's set to a gradient the shadow is only visible right around the edges of the shape... |
| 22:42 | <carllerche> | I might end up doing the shadows by hand :-/ |
| 22:44 | <carllerche> | woah, my canvas renders completely differently in firefox than webkit |
| 22:45 | <Philip`> | Shadows ought to work with gradients, I believe |
| 22:45 | <Philip`> | It'd be great if you could produce a minimal test case that indicates browser differences and report them as bugs :-) |
| 22:51 | <carllerche> | Philip`: this is my test http://carllerche.com/stuff/tests/index.html |
| 22:51 | <carllerche> | I don't think i'm doing anything crazy |
| 22:52 | <carllerche> | the shadow doesn't seem to render when it's a gradient (it does if fillStyle is set to black) and the shape is way off in firefox... |
| 22:52 | <carllerche> | i should probably make sure i'm on the latest FF |
| 22:53 | <carllerche> | Philip`: Indeed, I just updated FF and the shape is correct and the shadow renders. So, it seems to be a bug with webkit nightly |
| 22:54 | <boblet> | hey all, anyone here involved with html5lib? I’m wondering how far off it is from being used as a Tidy replacement for uF tools |
| 22:54 | <carllerche> | yeah, it's an already reported bug |
| 23:18 | <AryehGregor> | The most entertaining thing about doing MediaWiki support is seeing all the crazy things people make wikis for. |
| 23:18 | <AryehGregor> | I've seen furries, Euclidean geometry, and now sneakers. A wiki all about sneakers. |
| 23:30 | <t3rminat0r_> | anyone related with CFD? |