| 00:49 | <carllerche> | webkit-background-composite seems to be making up some black space |
| 01:27 | <Hixie> | anyone have any opinions on what i should include in a section teaching people about form controls? |
| 01:32 | <miketaylr> | graphics of shiny new UIs :) |
| 01:33 | <Hixie> | well that'll be up to volunteers to provide :-) |
| 01:33 | <Hixie> | i suck at making pictures |
| 01:33 | <miketaylr> | heh |
| 01:33 | <Hixie> | everyone is welcome to contribute images though |
| 01:35 | <miketaylr> | is this section in addition to what's in http://www.whatwg.org/specs/web-apps/current-work/multipage/forms.html#forms? |
| 01:35 | <Hixie> | yeah i'm adding an intro section after that first paragraph |
| 01:37 | <miketaylr> | hmm, not really sure. but i've got a test page that could possible be added, or repurposed |
| 01:37 | <miketaylr> | http://www.miketaylr.com/code/input-type-attr.html |
| 01:38 | <miketaylr> | s/added/linked to somewhere |
| 01:39 | <Hixie> | i'm thinking more a tutorial-like thing |
| 01:40 | <miketaylr> | gotcha |
| 01:40 | <fantasai> | When html5lib serializes to HTML, it includes a namespace declaration. (And uses the XHTML document's DOCTYPE, if any.) Is that intentional? |
| 01:43 | <Hixie> | hsivonen: i think i need an equivalent of #file and #line in the validator |
| 01:45 | <Hixie> | hsivonen: i'm trying to validate the post-merge (but pre-anolis) file and the line numbers are very confusing |
| 01:46 | <Hixie> | miketaylr: here's what i have so far: http://www.whatwg.org/specs/web-apps/current-work/complete.html#forms |
| 01:49 | <miketaylr> | hmm, i'm seeing the same thing as in the non-kitchen sink spec. |
| 01:49 | miketaylr | clears cache |
| 01:49 | <Hixie> | there should be two new sections that say "This section is non-normative" |
| 01:49 | <Hixie> | at the top of the Forms section |
| 01:51 | <miketaylr> | ah yes, chromium is caching aggressively, apparently |
| 01:54 | <miketaylr> | mmm pizza |
| 01:54 | <miketaylr> | that looks good to me. with <label> is it worth mentioning the for='' attribute as well? |
| 01:54 | <Hixie> | maybe in due course |
| 01:54 | <Hixie> | i'm trying to stay relatively simple |
| 01:55 | <Hixie> | one could write a book about just this section |
| 01:55 | <miketaylr> | indeed |
| 01:55 | <Hixie> | what pizza toppings should we offer |
| 01:55 | <Hixie> | so far i have bacon, extra cheese, and onion. |
| 01:55 | <miketaylr> | mushroom, por favor |
| 01:55 | <Hixie> | mushroom it is. |
| 02:16 | <Hixie> | should i suggest the toppings be sent as topping=a&topping=b&topping=c, or toppingA=on&toppingB=on&toppingC=on? |
| 02:16 | <Hixie> | the former means explaining the value="" attribute on type=checkbox |
| 02:16 | <Hixie> | the latter means explaining that it has a default |
| 02:19 | <miketaylr> | i think i prefer the first, but that's probably just an arbitrary personal preference |
| 02:19 | <ment> | uh... but topping=a&topping=b would get parsed by webserver as topping=b ...? |
| 02:22 | <Hixie> | ment: only if the webserver is buggy |
| 02:24 | <ment> | how it should be passed to application then? like an array? |
| 02:24 | <Hixie> | that's up to the application |
| 02:25 | <Hixie> | webservers that implement CGI just pass the data to the script unparsed |
| 02:27 | <ment> | i understand html 5 doesn't cover this, i'm just curious about the standard behaviour of scripting languages |
| 02:28 | <Hixie> | in perl, CGI.pm seems to offer it in a variety of forms, including an array form |
| 02:28 | <TabAtkins> | PHP has a special behavior to handle it. name="topping[]" makes it collect the values into a $_POST['topping'] array. |
| 02:28 | <ment> | for example, let's say some binding parses those multiple key=val1&key=val2 as an array |
| 02:28 | <TabAtkins> | Without the [] on the name, though, it just gives you the last one. |
| 02:29 | <ment> | then key=a is is string, key=a&key=b is an array |
| 02:29 | <ment> | TabAtkins: that seems reasonable |
| 02:36 | <Hixie> | http://www.whatwg.org/specs/web-apps/current-work/complete.html#forms |
| 02:36 | <Hixie> | now with more pizza |
| 02:36 | <Hixie> | er wait |
| 02:36 | <Hixie> | my script failed |
| 02:36 | Hixie | tries again |
| 02:53 | <Hixie> | ok |
| 02:53 | <Hixie> | http://www.whatwg.org/specs/web-apps/current-work/complete.html#forms |
| 02:53 | <Hixie> | now with actual more pizza |
| 02:54 | <miketaylr> | just read it. looking good. |
| 02:57 | <miketaylr> | and not just because i'm hungry. i think. |
| 02:57 | <Hixie> | heh |
| 05:35 | <Hixie> | anyone have any ideas on what http://www.w3.org/Bugs/Public/show_bug.cgi?id=8936 should look like? |
| 05:35 | <Hixie> | (summary table of content models) |
| 05:35 | <Hixie> | (and what elements are in each) |
| 05:35 | <Hixie> | i'm not sure how best to present the information |
| 06:51 | <othermaciej> | so I'm trying to see how good a version of <details> I can implement with just CSS and JavaScript |
| 06:51 | <othermaciej> | can anyone spare me some CSS clues? |
| 06:51 | <othermaciej> | I am trying to figure out how to style things so that the summary element is visible but other children of details are not |
| 06:51 | <othermaciej> | in the default closed state |
| 06:52 | <othermaciej> | having trouble with this for text children of details, since there's no way to address them with a selector other than via details itself |
| 07:16 | <Hixie> | othermaciej: you need xbl to do that |
| 07:16 | <othermaciej> | Hixie: I decided to fake it just enough for purposes of a demo |
| 07:17 | <Hixie> | http://www.w3.org/mid/4B7B9700.10302⊙gd - shouldn't the question be "how can we fix the obviously broken process?" |
| 07:18 | <Hixie> | it seems like "education" doesn't really work in this kind of situation |
| 07:18 | <othermaciej> | Apple has nothing to do with the iPhone FaceBook app |
| 07:23 | <Hixie> | i made the diagram at http://www.whatwg.org/specs/web-apps/current-work/complete.html#kinds-of-content interactive |
| 07:23 | <Hixie> | it only seems to work in chrome though :-( |
| 07:28 | <othermaciej> | seems to do what I assume is intended in my recent(ish) WebKit trunk build inside Safari |
| 07:30 | <hsivonen> | huh. validator.nu has crashed again |
| 07:31 | <Hixie> | works in safari too |
| 07:31 | <Hixie> | but not in firefox |
| 07:31 | <hsivonen> | so far, I'd be inclined to continue to treat # in a data: URL as a validation error |
| 07:31 | <Hixie> | and opera seems quite buggy with it |
| 07:31 | <Hixie> | oh well |
| 07:31 | <Hixie> | 2/4 ain't bad |
| 07:31 | <Hixie> | i guess |
| 07:32 | <Hixie> | though really it's 1/3 |
| 07:32 | <Hixie> | i kinda like it, it's pretty |
| 07:33 | <Hixie> | the shadow is maybe a bit out of place |
| 07:34 | <nessy> | testing browser support through the spec? hehe |
| 07:34 | <othermaciej> | hsivonen: I have a favor to ask of you |
| 07:35 | <hsivonen> | othermaciej: what kind of favor? |
| 07:35 | <othermaciej> | hsivonen: Accessibility TF is working on a Change Proposal to replace table @summary with a recommendation to use <details>, and I noticed it may have an impact on HTML parsing |
| 07:35 | <hsivonen> | uh oh |
| 07:35 | <othermaciej> | hsivonen: was wondering if you could review with that in mind, and send your comments to the TF list (or send them to me to pass along) |
| 07:36 | <hsivonen> | othermaciej: ok |
| 07:36 | <othermaciej> | looking for the URL now... |
| 07:37 | <othermaciej> | http://www.w3.org/WAI/PF/HTML/wiki/Details_element_as_a_replacement_for_summary_attribute%2C_Feb_15%2C_2010 |
| 07:38 | <othermaciej> | hsivonen: I pointed out to them that replacing <details><summary> with <button> would effectively reopen a closed issue, but on a technical level I also noticed that they suggest allowing <details> as a direct child of <table> |
| 07:38 | <hsivonen> | I love how Negative Effects tend to be "?" or "None I can think of" in Change Proposals |
| 07:38 | <othermaciej> | which I thought might be problematic, though I am not a parsing expert |
| 07:39 | <nessy> | hsivonen: not here http://www.w3.org/WAI/PF/HTML/wiki/Media_TextAssociations#Negative_Impact |
| 07:40 | <othermaciej> | I am more trusting of a Change Proposal if it does mention some negative impacts because I find it unlikely anything is 100% good |
| 07:53 | <Hixie> | othermaciej: i wasn't sure what negative effects not having longdesc="" would have... i'm certainly open to suggestions :-) |
| 08:04 | <annevk> | Hixie, when I looked at your examples this morning the controls did not have values? |
| 08:04 | <annevk> | surely they don't take it from labels |
| 08:10 | <hsivonen> | where's the current status of Change Proposals maintained these days? |
| 08:11 | hsivonen | fails to locate them on the HTML WG wiki front page |
| 08:22 | <othermaciej> | hsivonen: http://dev.w3.org/html5/status/issue-status.html |
| 08:22 | <hsivonen> | othermaciej: thanks |
| 08:24 | <hsivonen> | othermaciej: so if Larry doesn't retract the doctype/versioning proposal by tomorrow, the clock for counter proposals starts tomorrow if the chairs agree the ACTION-172 conformed to the requirements of the Change Process? |
| 08:24 | <hsivonen> | s/the ACTION/the output of ACTION/ |
| 08:25 | <othermaciej> | hsivonen: it doesn't start automatically |
| 08:25 | <hsivonen> | oh |
| 08:25 | <othermaciej> | hsivonen: the owner would revert to Chairs and we are supposed to decide what to do next |
| 08:25 | <hsivonen> | I see |
| 08:26 | <othermaciej> | hsivonen: no clocks ever start automatically without intervention of the Chairs (to avoid flooding) |
| 08:26 | <hsivonen> | ok |
| 08:26 | <othermaciej> | we avoided issuing any new calls for proposals or the like this week because we want the publication question to be settled first |
| 08:27 | <hsivonen> | what's still unsettled about publication? |
| 08:28 | <othermaciej> | the CfC is pending, and the chairs are unclear on the effect of the pending objection/appeal/whatever on our ability to publish |
| 08:28 | <othermaciej> | the CfC goes through tomorrow (inclusive), at that point we'll need the W3C Team to tell us the status |
| 08:28 | <hsivonen> | I thought an objection/appeal/whatever was retracted if it ever existed |
| 08:29 | <othermaciej> | so far as I know, it has not been retracted |
| 08:30 | <hsivonen> | interesting. I'm losing track of what's going on in the WG. clearly, I spend too much time on mochitests these days |
| 08:30 | <othermaciej> | I wish I were more clear on what is actually going on |
| 08:30 | <othermaciej> | since it is in theory my job to be clear on such things |
| 08:30 | <Hixie> | annevk: the forms stuff? look at it again, i changed it since this morning, it's longer now. |
| 08:32 | <othermaciej> | I made some examples of how <details> could work for table summaries without being visible by default, per the A11Y TF's suggestions: http://webkit.org/demos/hover-summary/example1.html http://webkit.org/demos/hover-summary/example2.html |
| 08:33 | <othermaciej> | (the difference is the second one doesn't even have a visible caption by default) |
| 08:33 | <othermaciej> | anyone care to critique the markup or CSS in the <style> elements in those pages? |
| 08:33 | <othermaciej> | (don't worry about the contents of details.js and details.css, I know they are very sloppy; they are just my best attempts to implement details) |
| 08:34 | <othermaciej> | the <details> in each case will appear if you hover the <table>, or tab into the <details> element |
| 08:35 | <annevk> | Hixie, I meant the introduction you just added |
| 08:35 | <Hixie> | the forms intro? |
| 08:36 | <othermaciej> | hmm, my example breaks really bad in Firefox |
| 08:36 | <othermaciej> | it does not like the idea of a table being a containing block :-/ |
| 08:36 | <Hixie> | looks nice in webkit |
| 08:37 | <othermaciej> | you can even use space to toggle the details element if you tab into it |
| 08:37 | <annevk> | <label> <input type=radio name=size> Small </label> |
| 08:37 | <annevk> | there's no value attribute |
| 08:37 | <annevk> | ooh |
| 08:37 | <Hixie> | annevk: keep reading |
| 08:37 | <Hixie> | :-) |
| 08:38 | <annevk> | as somebody mentioned that might not work in PHP |
| 08:38 | <annevk> | PHP requires name=...[] for array stuff :/ |
| 08:38 | <othermaciej> | I am not sure how to make this example work in Firefox without adding a gratuitous <div> |
| 08:39 | <Hixie> | annevk: it's just an intro, i'm sure someone using php will read a php intro too |
| 08:43 | <othermaciej> | looks like only WebKit lets you tab into a display: none element with tabindex=0 |
| 08:44 | <annevk> | i guess |
| 08:44 | <annevk> | othermaciej, does WebKit even implement withCredentials? |
| 08:44 | <annevk> | othermaciej, ap was complaining (quite a while ago) that having withCredentials was silly and WebKit would not have it for the foreseeable future |
| 08:44 | <annevk> | because of some impl difficulty with the network stack |
| 08:45 | <othermaciej> | annevk: we do have withCredentials |
| 08:45 | <hsivonen> | othermaciej: are your demos stable for use as bug report test cases? |
| 08:45 | <othermaciej> | annevk: it was a pain to get the network stack to truly respect not sending as credentials |
| 08:46 | <othermaciej> | hsivonen: I was planning to tweak them a little to behave a little better in other browsers (by slightly defeating the original design intent) |
| 08:46 | <othermaciej> | hsivonen: but I can refrain from checking in that change, or check in new versions under different URLs |
| 08:46 | <annevk> | othermaciej, bugger |
| 08:47 | annevk | would love to nuke it |
| 08:49 | <othermaciej> | annevk: I think part of the reason we added it in the first place is that we didn't want cross-site requests with credentials to be the default |
| 08:49 | <othermaciej> | annevk: I guess it does seem a little silly to have three modes, but no-credentials with-Origin mode is mildly useful for semi-public data sources |
| 08:50 | <othermaciej> | annevk: where you don't have to be a specific user but they would like to log what domains are accessing it and perhaps limit that |
| 08:51 | <othermaciej> | hsivonen: nevermind, I'm not going to change these, too hard to make it perfect in all browsers |
| 08:51 | <othermaciej> | it looks like Opera and Firefox won't focus elements that are visibility: hidden either |
| 08:54 | <hsivonen> | othermaciej: ok. I'll file a bug about the hover thing |
| 08:54 | <othermaciej> | hsivonen: I'm not 100% sure if it's even a bug per CSS that a relative positioned table doesn't count as a containing block for its absolute positioned descendants |
| 08:56 | <othermaciej> | hsivonen: ok, after checking the CSS spec, I think it is: <http://www.w3.org/TR/CSS2/visudet.html#containing-block-details>; |
| 08:57 | <annevk> | othermaciej, in that case you might as well accept credentials too and just ignore them |
| 08:57 | <othermaciej> | annevk: I don't even properly remember the full debate we had about this |
| 08:58 | <othermaciej> | annevk: but I remember we argued about it a long time |
| 08:58 | <othermaciej> | I would be very hesitant to change it now, because anyone who has coded against the current spec has a potential security hole if we transparently change the default on sending credentials |
| 08:59 | <othermaciej> | annevk: I think parts of the reasons for the original decision are: |
| 08:59 | <othermaciej> | - if a server responds with Access-Control-Allow-Credentials: true, it can't use Access-Control-Allow-Origin: * it has to echo back the specific origin |
| 08:59 | <othermaciej> | so servers that allow credentials can't use *, which would be inconvenient |
| 09:00 | <annevk> | but they can use null |
| 09:00 | <othermaciej> | - you can't talk to a server that doesn't use Access-Control-Allow-Credentials: true if you send credentials |
| 09:00 | <annevk> | which works for the globally unique identifier origin |
| 09:00 | <hsivonen> | othermaciej: filed https://bugzilla.mozilla.org/show_bug.cgi?id=546596 |
| 09:01 | <annevk> | that's true |
| 09:01 | <othermaciej> | annevk: if you had to use anon to talk to any server that doesn't allow credentials, that would break any existing use of cross-site XHR without the credentials flag, and it would make it impossible to have semi-public resources |
| 09:04 | <othermaciej> | hsivonen: commented |
| 09:04 | <annevk> | it does not limit anything on the server side of things afaict |
| 09:04 | <annevk> | it might break some existing usage of the API, yes |
| 09:04 | <annevk> | but not everyone implements it yet so I'm not sure how much weight we should give that |
| 09:05 | <annevk> | preferably not much |
| 09:05 | <othermaciej> | I think the third mode has some value, for one thing it matches exactly what XDR does |
| 09:06 | <othermaciej> | it might not be a huge amount of value, but it doesn't seem so terrible that we should risk breaking compat to remove it |
| 09:11 | <annevk> | boo |
| 09:11 | <annevk> | oh well |
| 09:11 | <annevk> | I think I will throw for non same-origin username/password parameters |
| 09:11 | <annevk> | that makes a lot of sense |
| 09:25 | <annevk> | Lachy, hey |
| 09:25 | <annevk> | Lachy, can I use your Windows box for Skype later today? |
| 09:25 | <annevk> | Lachy, I'd like to attend the CSS WG meeting |
| 09:26 | <annevk> | http://www.w3.org/mid/4B7B2919.5050804⊙no is exactly why registries should be wikis or simple web services |
| 09:27 | <Hixie> | personally i don't understand why all the people who care about this stuff don't just do the registrations themselves |
| 09:27 | <Hixie> | instead of "educating" the people who don't |
| 09:27 | <asmodai> | annevk: To at least have the info somewhere? |
| 09:27 | <asmodai> | Hixie: Easier to moan and bitch I'd wager |
| 09:28 | <annevk> | asmodai, basically |
| 09:28 | <Hixie> | if they cared about making things easy, they wouldn't do registries |
| 09:28 | <Hixie> | at least not these complicated ones with forms and e-mails and experts |
| 09:29 | <annevk> | I was a bit surprised that you thought using a rel-registry was suddenly ok |
| 09:29 | <jgraham> | fantasai: Do you have some sample code? |
| 09:29 | <hsivonen> | these custom URIs would be unnecessary if all apps on a system agreed to use one shared HTTP stack and dispatched on MIME type |
| 09:30 | <annevk> | hsivonen, then you'd have custom MIME types |
| 09:30 | <annevk> | hsivonen, just moves the problem elsewhere, since MIME type registries also suck (surprise surprise) |
| 09:30 | <Lachy> | annevk, sure |
| 09:31 | <annevk> | sweet |
| 09:31 | <hsivonen> | annevk: :-) |
| 09:31 | <hsivonen> | annevk: the MIME registry has the vnd stuff, though |
| 09:32 | <hsivonen> | and URLs so far don't |
| 09:32 | <hsivonen> | but then, there are types that don't use vnd |
| 09:32 | <Hixie> | annevk: i didn't say it was ok, i said we should test it to see if it's ok |
| 09:32 | <hsivonen> | so yeah, registries FAIL |
| 09:32 | <annevk> | we ended up with application/x-widget or something because the vnd stuff seemed to complicated |
| 09:33 | <annevk> | I argued we should do vnd, but I didn't have the bandwidth to make it all happen |
| 09:33 | <annevk> | if it was just a wiki I'm sure we would have done the right thing |
| 09:33 | <Philip`> | Dispatching on MIME type wouldn't help this application intercept requests to http://www.facebook.com/profile.php?id=4 |
| 09:33 | <Philip`> | The developers would have to set up their own server on its own domain that responds with their custom MIME type and returns some custom format that tells the application what's the real URL to load |
| 09:34 | <annevk> | IETF is just too hard to get into with all the annoying text/plain documents that are not really straightforward to read |
| 09:34 | <hsivonen> | Philip`: sure it would if facebook UA-sniffed and returned application/vnd.facebook to Mobile Safari |
| 09:34 | <Philip`> | which doesn't seem much better than using a custom protocol handler, and requires a lot more network traffic |
| 09:34 | <asmodai> | And then there's magnet: -- which is not officially registered either ;) |
| 09:36 | <Philip`> | hsivonen: What would it do on devices that use Mobile Safari but don't have the Facebook iPhone application installed? |
| 09:36 | <Philip`> | Would it need some way to sniff that too? |
| 09:36 | <hsivonen> | Philip`: how does fb: work in that case? |
| 09:37 | <Philip`> | hsivonen: People without the application won't see fb: links anywhere (I presume) |
| 09:37 | <Philip`> | whereas they will often see links to normal HTTP Facebook profile pages |
| 09:37 | <hsivonen> | Philip`: so when does a user receive an fb: URL? |
| 09:38 | <Philip`> | I suppose they could make a special /profile-iphone-app.php?id=... that the application uses for this |
| 09:38 | <hsivonen> | (the solution to this seems to be making Web apps instead of native apps) |
| 09:38 | <Philip`> | hsivonen: Sounds like the application inserts the URLs into your iPhone's contacts list |
| 09:39 | <Lachy> | AIUI, the use of fb: URLs is supposed to be entirely transparent to the user. They are never exposed in the App's UI |
| 09:40 | <Lachy> | oh, maybe I'm wrong. |
| 09:47 | <Hixie> | is http://www.iana.org/assignments/media-types/image/ not up to date? |
| 09:47 | <Hixie> | it doesn't have image/svg+xml |
| 09:48 | <annevk> | they still haven't been able to register it |
| 09:48 | <hsivonen> | Hixie: image/svg+xml pretty much sums up what's wrong with registries |
| 09:50 | <Hixie> | maybe IANA5 should be next on the list |
| 09:50 | <hsivonen> | http://www.cssquirrel.com/2010/02/15/comic-update-larry-ate-html5/#comment-31463 |
| 09:51 | <annevk> | Hixie, it's called wiki.whatwg.org |
| 09:51 | Hixie | wonders why hsivonen posted that link |
| 09:51 | othermaciej | too |
| 09:52 | <hsivonen> | Hixie: to point out that the meme that the modularized parts aren't "HTML5" is catching on |
| 09:52 | <Hixie> | I don't think David Orchard is really representative of what most web developers consider HTML5 :-) |
| 09:53 | <othermaciej> | most people think geolocation and sql are part of html5 |
| 09:53 | <annevk> | yeah, he at least has a modest level of "W3C bias" |
| 09:54 | <othermaciej> | he mentions a private list that the W3C set up for the HTML Working Group, I hope someone tells me about that list |
| 09:54 | <hsivonen> | it would be interesting to find out how arguing that the canvas context spec isn't HTML5 correlates with previously arguing for parts to be split out based on spec modularity concerns |
| 09:55 | hsivonen | tries to buy a PC |
| 09:55 | <hsivonen> | it's so hard compared to buying a Mac |
| 09:55 | <othermaciej> | I personally don't care if they "are" or "are not" HTML5 as long as we get to publish them, and are not forced to add disclaimers saying we're not really supposed to publish them |
| 09:55 | <hsivonen> | in the Mac case, it's so easy to see that Apple doesn't sell the kind of box I want |
| 09:56 | <annevk> | has anyone read http://www.tbray.org/ongoing/When/201x/2010/02/15/HTML5 yet? |
| 09:56 | annevk | wonders if it's worth it |
| 09:56 | <othermaciej> | I just read the first half and commented about two seeming factual errors |
| 09:56 | Hixie | found it interesting, and submitted an essay of a comment that hasn't been moderated yet |
| 09:56 | <othermaciej> | (comment waiting for moderation) |
| 09:57 | <othermaciej> | things I thought were inaccurate: "One of the distinguishing features of the Web is that it has never specified APIs or Object Models." |
| 09:57 | <othermaciej> | "The http://www.whatwg.org/specs/web-apps/current-work/multipage/ ... provides detailed algorithms for parsing HTML, even in the face of severe syntax errors, and specifies how the results of parsing should be used to construct the Object Model. Thus, the syntax is ephemeral; the Object Model, interoperable across the network, is what matters." |
| 09:57 | <othermaciej> | (second sentence of the latter) |
| 09:57 | <wycats> | Hixie: you're an animal :) |
| 09:58 | <othermaciej> | DOM Level 1 Core is a clear counter-example to the former |
| 09:58 | <wycats> | Hixie: http://www.w3.org/Bugs/Public/show_bug.cgi?id=8936 |
| 09:59 | <wycats> | what I mean is just to take the info in each of the sections, like "metadata content = base command link meta noscript script style title", and put it in a table |
| 09:59 | <Hixie> | comment in the bug please :-) |
| 09:59 | <Hixie> | otherwise i'll lose track of your feedback |
| 09:59 | <hsivonen> | othermaciej: isn't tbray married to a DOM Level 1 WG chair? |
| 10:00 | <wycats> | <table><thead><tr><th>category</th><th>elements</th></tr></thead><tbody><tr><td>Metadata</td><td>base command link meta noscript script style title</td></tr>...</table> |
| 10:00 | <wycats> | Hixie: sure |
| 10:00 | <Hixie> | wycats: thanks! |
| 10:00 | <wycats> | was just checking if it made sense :) |
| 10:00 | <othermaciej> | hsivonen: I was not aware of that, but that would make it extra hilarious |
| 10:00 | <Hixie> | wycats: listing the columns you want in the table would be ideal for me |
| 10:00 | <wycats> | Just those two :) |
| 10:00 | <Hixie> | cool |
| 10:00 | <Hixie> | make sure to mention them in the bug :-) |
| 10:01 | <wycats> | ok |
| 10:01 | <wycats> | maybe also an "exceptions" column |
| 10:01 | <Hixie> | heh |
| 10:01 | <Hixie> | that might be a fat column |
| 10:01 | <Hixie> | oh if you use safari or chrome btw i made the pretty picture showing how some of the categories are related be more interactive |
| 10:01 | <wycats> | yeah I saw :) |
| 10:01 | <wycats> | svg? |
| 10:01 | <Hixie> | yeah |
| 10:01 | <Hixie> | not sure why it doesn't work in firefox or opera |
| 10:05 | <wycats> | http://www.w3.org/Bugs/Public/show_bug.cgi?id=8936 |
| 10:06 | <Hixie> | cool, thanks |
| 10:06 | <wycats> | my lack of general response to your ticket closing should be construed as approval :P |
| 10:07 | <Hixie> | you can mark them CLOSED if you care to actually go through them |
| 10:07 | <Hixie> | or else just leave them, that's what I tend to do |
| 10:08 | <wycats> | Hixie: any further progress on being able to use the inline form but have it marked as a ticket I opened? |
| 10:08 | <wycats> | Hixie: ha |
| 10:09 | <zcorpan__> | wycats: you get cc-ed if you're logged in to the status annotation system |
| 10:09 | <zcorpan__> | wycats: you need to use the same email address as your bugzilla account |
| 10:09 | <wycats> | status annotation system? |
| 10:09 | <zcorpan__> | top right of the spec |
| 10:09 | <wycats> | when I log in it says: "Error: OK (403)." |
| 10:10 | <wycats> | 403 OK seems incorrect :P |
| 10:10 | <wycats> | I know this isn't the HTTP spec, but ... ;) |
| 10:10 | <zcorpan__> | the status message is just advisory :) |
| 10:11 | <wycats> | zcorpan__: how do I know if I'm logged in? |
| 10:11 | <wycats> | it always says 403 OK |
| 10:11 | <wycats> | ah I need to request an account |
| 10:11 | <wycats> | and I should use the same email |
| 10:11 | <wycats> | and then it'll work? |
| 10:11 | <zcorpan__> | yes |
| 10:12 | <wycats> | w00t |
| 10:12 | <jgraham> | hsivonen: I believe he is |
| 10:12 | <wycats> | can I change my password? |
| 10:12 | <zcorpan__> | no |
| 10:14 | <wycats> | meh... still no clear-after-submitting :P |
| 10:16 | <zcorpan__> | file a bug |
| 10:18 | <Hixie> | wycats: it should select the text after submitting now |
| 10:18 | <Hixie> | wycats: at least if you hit enter |
| 10:18 | <Hixie> | which is almost as good |
| 10:19 | <Hixie> | i don't clear because i sometimes file a bunch of identical bugs on a bunch of different sections |
| 10:19 | <Hixie> | and it would be a huge pain if it cleared |
| 10:29 | <Hixie> | why do i get the crash-recovery dialog every time i open opera? |
| 10:29 | <wycats> | :/ |
| 10:29 | <wycats> | Hixie: "Contexts in which this element may be used" for <base> should not include the idea that "A base element, if it has a target attribute, must come before any elements in the tree that represent http://www.whatwg.org/specs/web-apps/current-work/multipage/links.html#hyperlink"; |
| 10:29 | <wycats> | I'm not sure what the rules are for that section |
| 10:30 | <Hixie> | hm? |
| 10:30 | <wycats> | the <base> element has a more restrictive context than that specified in "Contexts in which this element may be used" |
| 10:30 | <jgraham> | Hixie: Dunno. Does it crash every time you open Opera or? |
| 10:31 | <Hixie> | no |
| 10:31 | <Hixie> | i quit normally |
| 10:31 | <Hixie> | and then i open it again |
| 10:31 | <Hixie> | i get the "how do you want to open opera" dialog |
| 10:31 | <Hixie> | with no "never ask me" checkbox |
| 10:31 | <Hixie> | wycats: file a bug, i'll figure it out :-) |
| 10:31 | jgraham | tries to reproduce |
| 10:31 | <wycats> | Hixie: ok |
| 10:32 | <wycats> | huh... I didn't know about <base target>... claims to be well implemented |
| 10:32 | <wycats> | cool beans |
| 10:32 | <Hixie> | jgraham: huh. I changed prefs from "start form last time" to the homepage option and now it starts normally |
| 10:33 | <jgraham> | Hixie: Ah, I was just about to point out that pref |
| 10:33 | <Hixie> | it wasn't on the last option in that list, dunno if it just wasn't set and two parts of opera have different defaults or something |
| 10:33 | <Hixie> | oh well |
| 10:34 | <Hixie> | afk |
| 10:41 | <annevk> | not having rel=feed sort of sucks |
| 10:41 | <annevk> | my archived pages currently use it, e.g. http://annevankesteren.nl/2010/02/sabotage |
| 10:41 | <annevk> | to point to the main feed |
| 10:41 | <hsivonen> | annevk: not worth the trouble |
| 10:41 | <annevk> | replacing it with rel=alternate would be wrong |
| 10:41 | <annevk> | per spec |
| 10:41 | <annevk> | what to do? |
| 10:41 | <annevk> | fix the spec i guess? |
| 10:42 | <hsivonen> | that would be my choice |
| 10:42 | <annevk> | it's important for the archived pages to include some link to the main feed because if people wanna subscribe from just seeing that page they expect it to work |
| 10:48 | <Hixie> | speak to mark if you want something figured out for this |
| 10:49 | <Hixie> | he did a ton of research on this |
| 10:49 | <annevk> | i just want the spec to say that in case of rel=alternate + type=application/atom+xml it might not be for the current page, but also for the main page |
| 10:50 | <annevk> | maybe a combination of up and alternate would do? |
| 10:50 | <annevk> | or top and alternate |
| 10:50 | <annevk> | though that would not be quite backwards compatible |
| 10:50 | <annevk> | though top and alternate for the link would be uncommon |
| 10:51 | <annevk> | same link* |
| 11:03 | <annevk> | oh google/on2, today |
| 11:07 | <asmodai> | http://clientsfromhell.tumblr.com/post/392772921/client-indian-outsourcer-says-he-can-do-this |
| 11:49 | <csarven> | So, catching up on Storage. Is there any way to implement something like globalStorage? |
| 11:50 | <zcorpan__> | cookies? |
| 11:50 | <zcorpan__> | window.name can be used to simulate sessionStorage |
| 11:51 | <csarven> | Well, cookies won't allow site A to access a cookie set by site B |
| 11:51 | <zcorpan__> | true |
| 11:52 | <zcorpan__> | does globalStorage allow that? |
| 11:52 | <csarven> | I was thinking of being able to store a non-sensitive data that can be accessed globally |
| 11:52 | <csarven> | AFAIK, yes |
| 11:52 | <csarven> | However, globalStorage is obsolete |
| 11:53 | <Hixie> | globalStorage was renamed localStorage and had its API changed a bit |
| 11:53 | <zcorpan__> | there's localStorage |
| 11:53 | <Hixie> | but it's basically the same thing |
| 11:55 | <csarven> | localStorage.setItem('foo', 'bar') from site A. localStorage.getItem('foo') from site B return null |
| 11:56 | <Hixie> | yeah it's per-domain for security reasons |
| 11:56 | <Hixie> | (globalStorage was too, though you had to specify the domain and there was some level of sharing) |
| 11:56 | <Hixie> | you can simulate it using localStorage if you provide a cross-site API using postMessage() |
| 11:57 | <zcorpan__> | or CORS? |
| 11:57 | <zcorpan__> | or does cors not enable dom access? |
| 11:58 | <csarven> | CORS only allows the data for recognized servers |
| 11:59 | <csarven> | For open distributed systems, I don't think it will work |
| 12:00 | <Hixie> | anyway, time for me to sleep |
| 12:00 | <Hixie> | nn |
| 12:00 | <csarven> | I don't think postMessage() helps me |
| 12:01 | <zcorpan__> | cors can do allow: *, no? |
| 12:01 | <annevk> | zcorpan__, it doesn't |
| 12:01 | <zcorpan__> | annevk: ok |
| 12:01 | <csarven> | Simply wanted site A to set a value and let any other site use that value |
| 12:01 | <annevk> | CORS gives access to a single resource, giving access to the DOM would give access to all resources of that origin |
| 12:01 | <annevk> | would be quite a big difference |
| 12:02 | <annevk> | (plus a bunch of other issues) |
| 12:07 | <annevk> | csarven, you could define a postMessage() API that other sites can use, no? |
| 12:08 | <csarven> | That follows a centralised model no? |
| 12:09 | <annevk> | i suppose |
| 12:09 | <csarven> | That is, the other sites shouldn't have to be aware of the site that created the key/value. |
| 12:09 | <csarven> | Consider this: |
| 12:10 | <csarven> | Site A tries to set a key/value for person's username if there isn't already one in use. If there is one, it can reuse it |
| 12:12 | <csarven> | This is sort of like putting some data in your browser so wherever you go, you can carry it around with you. Fill forms etc |
| 12:13 | <csarven> | If site A wants to modify the existing key, it can throw a dialog box for the user to decide whether to update it or not. Similar to storing a new password value |
| 12:15 | <annevk> | I still don't see the problem |
| 12:17 | <csarven> | Do you mean to say that this is a non-issue and that it can be done or that you don't acknowledge this to be a valid problem |
| 12:18 | <annevk> | I mean to say that I don't see the problem |
| 12:19 | <annevk> | for instance, is there a site B? |
| 12:19 | <annevk> | the scenario is not very clear |
| 12:19 | <csarven> | heh |
| 12:20 | <csarven> | Site A looks for the key, if found, it will use it, otherwise it sets it. Site B looks for the key, if found, it will use it... Site C looks for the key.. |
| 12:21 | <annevk> | where do they look for this key? |
| 12:21 | <csarven> | Wherever the UA is storing it |
| 12:21 | <annevk> | what would prevent A from doing something bad with it? |
| 12:21 | <csarven> | Site A, B, C .. need not be aware of each other |
| 12:21 | <csarven> | That's relative based on the data stored |
| 12:21 | <annevk> | I think you need site X that is the storage-broker |
| 12:22 | <annevk> | and otherwise, yeah, not possible |
| 12:22 | <csarven> | As I've said, if site A wants to update the key, UA can prompt the user.. like it does for passwords |
| 12:22 | <annevk> | o_O |
| 12:23 | <csarven> | Storage-broker is a centralised model. It doesn't scale well. |
| 12:24 | <annevk> | UA is also centralized |
| 12:24 | <annevk> | storage-broker would actually work across UAs |
| 12:24 | <annevk> | euh, no it wouldn't |
| 12:24 | <annevk> | nm |
| 12:25 | <csarven> | Even if it did, it would requires site 1...n to be aware of the storage-broker |
| 12:27 | <csarven> | So, do you see the problem now? |
| 12:27 | <annevk> | sure |
| 12:28 | <annevk> | but I don't really think this is something worth solving |
| 12:28 | <csarven> | Really? |
| 12:29 | <annevk> | really |
| 12:30 | <csarven> | Consider your UA having profile data can be used by sites for registration or authentication |
| 12:31 | <Philip`> | Would people want to share that data automatically with every web site that chooses to ask for it? |
| 12:31 | <Philip`> | Seems like it'd be either very restricted data, or else a significant privacy concern |
| 12:32 | <csarven> | You can put whatever you want to share in your profile data |
| 12:32 | <csarven> | The problem is no different than Geolocation |
| 12:32 | <annevk> | sounds like openid |
| 12:32 | <csarven> | Site asks for your location and the UA prompts the user if they want to share it or not |
| 12:32 | <annevk> | anyway, my mom would never understand this |
| 12:33 | <Philip`> | csarven: So the prompt is on reading, not just on writing? |
| 12:33 | <csarven> | It can be both |
| 12:34 | <csarven> | Writing is obviously opens up potential issues but I think that can be solved by UA's UI |
| 12:34 | <csarven> | For instance, the user marks their fullname, username fields to never be asked to be written by a site |
| 12:35 | <Philip`> | I'd expect users would get pretty annoyed with prompts popping up every time an ad iframe tries to read the email addresses from their global profile data, in order to spam them |
| 12:35 | <Philip`> | and even more annoyed if it didn't pop up a prompt first |
| 12:36 | <csarven> | How do users deal with storing passwords when they login? |
| 12:36 | <csarven> | Same problem |
| 12:36 | <annevk> | not at all |
| 12:36 | <Philip`> | Browsers do it automatically, and don't expose any password storage API to pages |
| 12:37 | <csarven> | My response was in respect to user's dealing with UA's prompt |
| 12:39 | <csarven> | or even SSL warnings |
| 12:39 | <csarven> | Users can manage how they want to deal with that information globally from their UA's settings |
| 12:41 | <Philip`> | Is Opera's approach (where you can enter some standard personal information in a settings page, and it fills in forms based on input names or something like that, maybe automatically or when you click a button) insufficient for this? |
| 12:41 | <csarven> | The point is to let users store data they want in their UA and have that accessible without any middle-man, storage-brokers, central systems.. |
| 12:42 | <annevk> | not sure why websites have to get involved in such a feature |
| 12:44 | <csarven> | Philip`: I would say in some ways, yes. What's different is that say you create an account on a federated system, that account username could be accessible by any site in that system (or anyone for that matter) |
| 12:47 | <csarven> | Web sites, UA and users wants to get involved in such a feature because it can automate a lot of mundane tasks |
| 12:48 | <csarven> | Even entering your email or OpenID URL for some identification |
| 12:48 | <csarven> | s/URL/URI |
| 12:49 | <csarven> | It helps data to flow in decentralized systems. |
| 12:49 | <csarven> | I'm not sure what else I need to say on top of this.. :) |
| 13:04 | <othermaciej> | hsivonen: thanks for supporting publication |
| 13:04 | <MikeSmith> | so I'm at an event here in Tokyo tonight and my friend Shiraishi-san gave me a copy of a printed book he wrote which just got published by a major publisher here |
| 13:05 | <MikeSmith> | title translates to "Intoduction to HTML5 & (related) APIs" |
| 13:06 | <MikeSmith> | subtitle: "From canvas and video to Web Sockets" |
| 13:07 | <MikeSmith> | I think this is the first full book about HTML5 that's actually been published as a printed book |
| 13:10 | <annevk> | cool MikeSmith |
| 13:10 | <annevk> | funny that of canvas, video, and Web Sockets, one is in HTML5, one is half in HTML5, and one is not :p |
| 13:10 | <annevk> | well, per W3C definitions anyway |
| 13:11 | <hsivonen> | annevk: what's not in HTML5 is (related) :-) |
| 13:13 | <Philip`> | At least it doesn't mention geolocation in the subtitle |
| 13:16 | <zcorpan__> | annevk: hmm, didn't we have a test for [>] in doctype? |
| 13:18 | <hsivonen> | I mentioned geolocation, Workers, the File API and WebGL yesterday in my talk, since with the recent splits, it doesn't matter so much what has been in a draft titled "HTML5" at some point |
| 13:18 | <hsivonen> | (I did mention that those haven't been in a draft titled HTML5, though) |
| 13:18 | <Philip`> | <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" [ <!ATTLIST P myattr CDATA #implied --><!><!-- >]><!--><!!--><!-- > --> |
| 13:18 | <Philip`> | Oh dear |
| 13:19 | gsnedders | tries to parse that in his head |
| 13:19 | Philip` | waits for cranial explosion |
| 13:20 | <gsnedders> | >]> is what it is without the comments? |
| 13:20 | <gsnedders> | (per SGML) |
| 13:20 | <Philip`> | Don't ask me |
| 13:21 | <zcorpan__> | comment in the attlist decl with data "><!><!" |
| 13:21 | <Philip`> | (Ask Leif, since he said it is "easy") |
| 13:21 | <zcorpan__> | comment after doctype with data "><!!" |
| 13:21 | <zcorpan__> | another comment with data " > " |
| 13:21 | <Lachy> | per SGML rules, that's easy to parse. Per HTML's rules, I'm not so sure without looking at the spec |
| 13:22 | <Philip`> | (I combined it onto a single line - don't know if that'll break the SGML parsing) |
| 13:22 | <annevk> | zcorpan__, http://tc.labs.opera.com/html/parsing/doctype/001.htm ? |
| 13:22 | <gsnedders> | Lachy: Per HTML 5? It just ends after the first >. |
| 13:23 | <Lachy> | yes, up to the first ">" is fine. It's the stuff after that with the bogus comment parsing that's not so easy |
| 13:23 | <gsnedders> | <!> just vanishes |
| 13:23 | <zcorpan__> | annevk: yeah. it seems it only has <!doctype html [ x ]> |
| 13:23 | <gsnedders> | <!-- >]><!--> is a comment with data " >]><!-" |
| 13:24 | <gsnedders> | Then I need to look at the spec |
| 13:24 | <zcorpan__> | we don't close the doctype for <!doctype html [>]> |
| 13:24 | <annevk> | zcorpan__, I honestly couldn't care less |
| 13:25 | <annevk> | I'm tired of the SGML nonsense. SGML has been dead since the first version of HTML. |
| 13:26 | <Philip`> | http://software.hixie.ch/utilities/js/live-dom-viewer/saved/380 |
| 13:26 | <Philip`> | (in Opera) |
| 13:29 | <Philip`> | (Hmm, it seems to have changed a bit in 10.50 (vs 10.10) - it now shows nothing instead of treating the doctype as text, when it's not properly closed) |
| 13:30 | <Philip`> | (but it still does the crazy '['/']' counting thing) |
| 13:31 | <asmodai> | SGML should die already. |
| 13:31 | <asmodai> | Even DocBook moved to XML a long time ago ;) |
| 13:31 | <Philip`> | It has died already |
| 13:31 | <Philip`> | but some people like poking its corpse |
| 13:32 | <asmodai> | Flogging a dead horse so that its legs twitch does not make it alive. |
| 13:32 | <Philip`> | Indeed, but some people do it anyway because they don't want to believe it's dead, and others do it because it's fun |
| 13:33 | <hsivonen> | yet others do it as a matter of principle that nothing can ever be obsoleted |
| 13:34 | <asmodai> | SGMl served its purpose. Time to move on. |
| 13:34 | <othermaciej> | I don't care about hiding the ]> from a bogus doctype, but it does seem potentially risky to make fake internal subset doctypes trigger quirks mode when they used to trigger standards in most browsers |
| 13:35 | <annevk> | filed http://www.w3.org/Bugs/Public/show_bug.cgi?id=9051 on feed autodisco |
| 13:35 | <Philip`> | If the page author has any kind of concern at all about the quality of their page's rendering, they're not going to accept a ]> at the top-left corner of the page |
| 13:35 | <Philip`> | so they're not going to use fake internal subset doctypes |
| 13:36 | <annevk> | mpilgrim, http://www.w3.org/Bugs/Public/show_bug.cgi?id=9051 |
| 13:37 | <Philip`> | http://www.alistapart.com/articles/customdtd/ - "when you display the file in a browser, the ]> shows up on the screen. There’s no way around this bug, so this approach is right out." |
| 13:38 | <Philip`> | so even people following that article will use the safe approach of editing the .dtd file instead |
| 13:38 | <Philip`> | (Safe in terms of parsing, anyway) |
| 13:38 | <annevk> | still a shame that feed autodisco requires so much markup |
| 13:45 | hsivonen | wishes ALA didn't promote custom DTDs |
| 13:48 | <Philip`> | http://www.marlowe.co.uk/epages/Store2_Shop1549.sf - yikes |
| 13:51 | <hsivonen> | Philip`: that's so sad |
| 13:52 | <TabAtkins> | Philip`: hahahahaha |
| 13:53 | <Lachy> | I don't understand what Leif is trying to gain by trying to use an internal subset. It does nothing that can't be achieved with a system identifier and an external DTD, and even the utility of that is questionable. |
| 13:54 | <mpilgrim> | annevk: i agree, that should definitely be conforming |
| 13:54 | <mpilgrim> | if only because a billion pages use it that way |
| 13:55 | <TabAtkins> | Aw crap, we jumped over 9k while I wasn't looking. |
| 13:55 | <TabAtkins> | >_< |
| 13:55 | <hsivonen> | 9k? |
| 13:56 | <TabAtkins> | It's OVER 9 THOUSAAAAAAND! |
| 13:56 | <hsivonen> | It? |
| 13:56 | <TabAtkins> | http://www.youtube.com/watch?v=TBtpyeLxVkI |
| 13:57 | <TabAtkins> | The current bug number for the spec. |
| 13:57 | <annevk> | "This video contains content from Funimation Entertainment, who has blocked it in your country on copyright grounds." omg |
| 13:57 | <TabAtkins> | o_O |
| 13:57 | <hsivonen> | same thing for my country, too |
| 13:57 | <annevk> | I'm starting to dislike copyright |
| 13:57 | <hsivonen> | starting? |
| 13:57 | <annevk> | true |
| 13:58 | <TabAtkins> | Transcript: http://qntm.org/9000 |
| 13:58 | <Lachy> | which country is that youtube video available in? |
| 13:58 | <Lachy> | US? |
| 13:58 | <TabAtkins> | america, at least. |
| 13:58 | <Lachy> | ok |
| 13:58 | <mpilgrim> | sealand |
| 13:58 | Lachy | connects to a vpn there |
| 13:59 | <mpilgrim> | apparently not a very stable one... |
| 13:59 | <asmodai> | rofl |
| 13:59 | <TabAtkins> | In America, VPN connect you! |
| 13:59 | <TabAtkins> | (and disconnects everything else) |
| 14:00 | <Philip`> | http://symptomresearch.nih.gov/index.htm |
| 14:00 | <Philip`> | That one goes into quirks mode with html5.enable |
| 14:00 | <Philip`> | and looks a bit different |
| 14:01 | <Lachy> | ah, right. I've seen that video before |
| 14:01 | <Philip`> | but pages like http://symptomresearch.nih.gov/preface/index.htm look *better* in quirks mode |
| 14:01 | <TabAtkins> | Yeah, silly internet meme. But still stuck in my head. |
| 14:02 | <TabAtkins> | Though it's probably inappropriate to post "It's over NINE THOUSAAAAAND!" in bug 9001. |
| 14:02 | <TabAtkins> | Philip`: Conclusion? The coders are morons. |
| 14:02 | <mpilgrim> | sigh |
| 14:02 | <mpilgrim> | some days, it's amazing the internet works at all |
| 14:03 | <gsnedders> | The internet works? |
| 14:03 | <gsnedders> | Oh. |
| 14:03 | <Lachy> | gsnedders, no, not really |
| 14:05 | hsivonen | wishes Leif didn't post flamebaits like "What kind of theoretical points are these?" |
| 14:06 | <Philip`> | Everybody else (~0.002% of pages) puts their [...] junk after the system identifier, where it doesn't force quirks mode |
| 14:06 | <mpilgrim> | "note, though, that I can count pretty high on two hands" <-- snort |
| 14:06 | <Philip`> | so I think the (unsurprising) conclusion is that there's no significant compatibility problem in practice |
| 14:08 | <mpilgrim> | looking forward to having "can not use internal subset" escalated to a tracker issue |
| 14:18 | <hsivonen> | looks like the context is at http://lists.w3.org/Archives/Public/www-validator/2010Feb/ |
| 14:22 | <Philip`> | It's strange how people really do want their non-standard syntax to successfully validate against standards |
| 14:24 | <hsivonen> | it's sad that there will probably be a tracker issue on this |
| 14:29 | <Dashiva> | Philip`: Maybe they do government work |
| 14:40 | <karlcow> | tim bray created an alternate version of Web Sockets following his reading of the original one. From the article about html5 |
| 14:40 | <karlcow> | http://www.tbray.org/drafts/wsock-00 |
| 14:43 | <mile> | hello |
| 14:51 | <Philip`> | Hi |
| 14:57 | <Crash2108> | Will/does <video> support streaming video? |
| 14:57 | <Crash2108> | And what about webcam and microphone access? |
| 14:57 | <Philip`> | As far as I'm aware, the spec supports streaming |
| 14:58 | <annevk> | webcam/microphone is post-HTML5 |
| 14:58 | <Philip`> | so it's up to browser developers to implement whatever streaming protocols are useful |
| 14:58 | <Crash2108> | Flash will stick around for that. |
| 14:59 | <Crash2108> | What about multicasting? |
| 15:00 | <Philip`> | That seems like just a detail of the streaming protocol, that doesn't have any effect at the <video> level |
| 15:01 | <Crash2108> | It's in the IPv4-6 spec, but doesn't the application have to support it? |
| 15:01 | <Crash2108> | Or is it up to the server and network to support it? |
| 15:03 | <Philip`> | It has to be supported everywhere |
| 15:03 | <Philip`> | You can't use TCP, so you need some other transport protocol |
| 15:03 | <Philip`> | and then you can't use HTTP |
| 15:04 | <Philip`> | The network needs to support IP multicast, and the server and client need to support whatever new protocols you put on top of it |
| 15:04 | <Crash2108> | That's what I'm saying, shouldn't that be built in to the spec so that servers can relieve some pressure for IPTV? |
| 15:04 | <Philip`> | but from HTML's perspective it's just a <video> and a <source> with a non-HTTP URL |
| 15:05 | <Philip`> | It should be in some spec (and probably is already in lots), but HTML doesn't seem a relevant place for it |
| 15:05 | <hsivonen> | Crash2108: multicast on the Internet scale hasn't been a success so far with non-HTML solutions that support multicast |
| 15:05 | <Crash2108> | So it's being open for interpretation just like the actual video codecs. |
| 15:06 | <Crash2108> | Key words: so far. |
| 15:06 | <Philip`> | The first step is convincing every ISP in the world to enable IP multicasting :-) |
| 15:06 | <Crash2108> | IPv6 has better support and it's waiting to be tapped. |
| 15:06 | <Philip`> | (and the second step is probably apologising when their networks collapse) |
| 15:08 | <Philip`> | If/when people sort out the problems and get it implemented and deployed, it should work without any changes to HTML |
| 15:09 | <Crash2108> | ASsuming the browser supports it. |
| 15:09 | <Philip`> | Yes |
| 15:10 | <Crash2108> | So we're back in the 90s in that regard to just hope they all support similar features. |
| 15:10 | <hsivonen> | Crash2108: you'll have better luck convincing browsers to support multicast when some proprietary product has pioneered multicasting and showed it works on the Internet scale |
| 15:10 | <hsivonen> | Crash2108: how do you mean "back"? |
| 15:11 | <Crash2108> | I mean by being forced to design for every browser individually instead of just designing for THE browser. |
| 15:11 | <annevk> | oh shit |
| 15:11 | <annevk> | forgot to review ARIA comments |
| 15:11 | <annevk> | too fricking busy :/ |
| 15:11 | <Crash2108> | You can say shit but not fucking? |
| 15:12 | <annevk> | ? |
| 15:13 | <Dashiva> | Would you rather support javascript... or HITLER? |
| 15:13 | <Philip`> | Crash2108: HTML can't mandate any particular solution because the world does not have any acceptable solutions yet |
| 15:13 | <Crash2108> | Godwin's law |
| 15:13 | <Philip`> | Dashiva: Well, Hitler did have some nice uniforms... |
| 15:13 | <Dashiva> | It always comes down to the uniforms |
| 15:13 | Philip` | is torn between the two |
| 15:14 | <Crash2108> | I forget what we're talking about. |
| 15:14 | <Dashiva> | I'm just baffled by the never-ending list of people going "HTML only needs to support documents, javascript is evil and you don't need it anyway" |
| 15:18 | <jgraham> | I'm just baffled |
| 15:18 | <Philip`> | Javascript is an aberration, it'll go away in a few years |
| 15:19 | <jgraham> | That attitude is so 2004 |
| 15:19 | <karlcow> | Philip`: http://www.google.com/search?btnG=Google+Search&q=%22javascript+is+%22 |
| 15:19 | <Philip`> | jgraham: That just shows we're now closer than ever to the point where it'll go away |
| 15:20 | karlcow | wonders what happened to jgraham in 2004. :p |
| 15:20 | <annevk> | #whatwg doh |
| 15:20 | <jgraham> | Philip`: True. I guess it probably has gone away already and we just haven't noticed yet |
| 15:21 | <karlcow> | jgraham: you forget that it might also have never happened in some universes |
| 15:24 | <hsivonen> | karlcow: http://lists.w3.org/Archives/Public/public-webapps-cdf-discuss/2004Jun/att-0004/2004jun01.html#topic3 |
| 15:26 | <karlcow> | I think Bert is advocating for a separation between two layers, and then Javascript is indeed not in his model of thoughts. |
| 15:26 | <karlcow> | "In my mind, separating the program from the logic is the most important thing, just as we did for HTML, separating the style from the content." |
| 15:33 | <Dashiva> | And then you have people who think cookies (and localstorage) should instead be markup included in every page |
| 15:34 | <hsivonen> | Dashiva: what are you reading? |
| 15:35 | <Dashiva> | http://www.tbray.org/ongoing/When/201x/2010/02/15/HTML5#c1266395267.500515 |
| 15:38 | <karlcow> | I have the feeling that Tim Bray article is doomed to get useless discussions more than constructive comments about writing style of specifications |
| 15:40 | <Dashiva> | I wasn't expecting a call for reviving XHTML2, though |
| 15:41 | <annevk> | karlcow, most of the more detailed comments (exception of the first) seem pretty good |
| 15:41 | <karlcow> | first part of hixie comment is about writing style. On spot |
| 15:42 | <annevk> | what he says pretty much matches my experience |
| 15:42 | <annevk> | XHR was much more declarative initially |
| 15:42 | <annevk> | didn't work out |
| 15:42 | <karlcow> | Maciej's one is not about the writing style but facts of the blog posts, which I classify in I know better (then kind of useless) |
| 15:43 | <karlcow> | rimantas and gretar not very useful either. |
| 15:44 | <karlcow> | Dorian Taylor's one is also off, mostly poetic troll prose. |
| 15:46 | <Liwaaaaa> | hello :) |
| 15:46 | <Liwaaaaa> | can you recommend any books for html5 that are already out? |
| 15:47 | <karlcow> | Liwaaaaa: maybe http://www.google.com/search?btnG=Google+Search&q=html5 |
| 15:48 | <Liwaaaaa> | thank you! |
| 15:48 | <karlcow> | there's a lot in the pipe http://www.amazon.com/s/ref=nb_sb_noss?url=search-alias%3Dstripbooks&field-keywords=html5&x=0&y=0 |
| 15:49 | <karlcow> | amazing |
| 15:49 | <karlcow> | Introducing HTML5 (Voices That Matter) by Bruce Lawson and Remy Sharp (Paperback - July 5, 2010) |
| 15:49 | <karlcow> | Pro HTML5 Programming: Powerful APIs for Richer Internet Application Development by Peter Lubbers, Brian Albers, Frank Salim, and Ric Smith (Paperback - Mar. 15, 2010) |
| 15:49 | <karlcow> | Beginning HTML5 and CSS3: Next Generation Web Standards by Christopher Murphy (Paperback - Apr. 25, 2010) |
| 15:49 | <karlcow> | HTML5: Up and Running by Mark Pilgrim (Paperback - June 15, 2010) |
| 15:50 | <annevk> | I pre-ordered that last one |
| 15:50 | <Liwaaaaa> | my team and I we are developing a online massive multiplayer game. We first thought about flash and we encountered html5 now and we are not familiar with anything html5, so we are trying to get information to compare with technologies |
| 15:51 | <TabAtkins> | Neither is very appropriate for an mmorpg, imo, but if you're looking at something that is roughly Flash-capable, you want <canvas>. We don't yet have a useful 3d context for it, though, so it's probably not useful enough for you yet. |
| 15:51 | <Liwaaaaa> | to compare the technologies and find out the (dis)advantages :) |
| 15:52 | <Philip`> | TabAtkins: The experimental 3D one seems to be getting implemented pretty widely and quickly |
| 15:52 | <TabAtkins> | That's cool, then. I really have no clue about it. |
| 15:52 | <Philip`> | (and now is probably a good time to try experimenting with it, to influence the direction of the spec) |
| 15:53 | <Philip`> | Liwaaaaa: You'll probably find more useful and up-to-date information by reading things on the web, and the spec itself |
| 15:53 | <Philip`> | particularly if there's specific areas you're interested in |
| 15:54 | <Liwaaaaa> | thank you :) |
| 15:54 | <Liwaaaaa> | we are trying to gather the information for now |
| 15:54 | <Philip`> | If you want to e.g. do graphical stuff that works in IE then there's not really any alternative to Flash, though |
| 15:55 | <gsnedders> | Silverlight? |
| 15:55 | gsnedders | hides |
| 15:55 | <Liwaaaaa> | no it shouldn't be 3d or anything fancy... but it should also work in e.g. mobile devices |
| 15:55 | <Philip`> | Ah, if you want to work on mobile devices that don't support Flash then that narrows the options :-) |
| 15:56 | <Liwaaaaa> | also we considered that apple doesn't support flash ;) |
| 16:11 | <TabAtkins> | Liwaaaaa: If it's something meant to work on mobile devices too, then it's lower-powered than I had assumed. In that case, <canvas> is pretty likely to meet your needs. WebSockets would be perfect as well, but that's not widely-supported yet. |
| 16:11 | <TabAtkins> | So I suppose you're stuck with normal long-polling XHR or similar. |
| 16:13 | <Liwaaaaa> | sorry what do you mean by XHR? |
| 16:13 | <gsnedders> | XMLHttpRequest |
| 16:15 | <Liwaaaaa> | thanks, yes its supposed to be "real" realtime... |
| 16:15 | <Liwaaaaa> | we can live with latencies :) |
| 16:15 | <Liwaaaaa> | not supposed to be i mean :P |
| 16:28 | <annevk> | wow, doctype thread |
| 16:46 | <annevk> | making progress with CSSOM, yay |
| 16:47 | <annevk> | guess i can start filling in some more dots tomorrow; it's like a big puzzle |
| 16:47 | <karlcow> | annevk: do you mean this ? |
| 16:47 | <karlcow> | <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" |
| 16:47 | <karlcow> | [<!ATTLIST P myattr CDATA #implied >]> |
| 16:47 | <annevk> | yeah |
| 16:48 | <annevk> | no idea why we're even discussing invalid HTML4 |
| 16:49 | <Philip`> | It would matter if some pages used invalid HTML4 and broke because of changes in HTML5 |
| 16:49 | <Philip`> | but it seems they don't break |
| 16:52 | <karlcow> | last time I have seen this discussion, it was about xhtml 1.1 and the missing target attributes |
| 16:52 | <karlcow> | some people experimented by by modifying the doctype |
| 16:52 | <karlcow> | Jacques Distler went the farther with http://golem.ph.utexas.edu/~distler/blog/files/zeldman.html |
| 16:54 | <karlcow> | http://krijnhoetmer.nl/stuff/html/strict-doctype-target/ |
| 16:55 | <karlcow> | <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"; [ <!ATTLIST a target CDATA #IMPLIED> ]> |
| 16:56 | <Philip`> | The right solution is for HTML to make <a target> conforming |
| 16:56 | <Philip`> | which, happily, HTML5 does |
| 16:58 | <gsnedders> | http://www.tbray.org/ongoing/When/201x/2010/02/15/HTML5#c1266424056.47300 |
| 16:58 | <karlcow> | the interesting thing is that in application/xhtml+xml |
| 16:59 | <karlcow> | <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"; [ <!ATTLIST a target CDATA #IMPLIED> ]> |
| 16:59 | <karlcow> | this is working but |
| 16:59 | <karlcow> | <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" [ <!ATTLIST a target CDATA #IMPLIED> ]> |
| 16:59 | <karlcow> | is not working at all. |
| 16:59 | <karlcow> | XML Parsing Error: syntax error |
| 17:00 | <Philip`> | Why is that interesting? |
| 17:01 | <Philip`> | It's just http://www.w3.org/TR/REC-xml/#NT-ExternalID |
| 17:07 | <karlcow> | interesting to me. I didn't think systemid was required when pubid was there. constraint on well formedness. |
| 17:08 | <karlcow> | reading xml prose |
| 17:10 | <gsnedders> | karlcow: Required in XML, not required in SGML. |
| 17:10 | <karlcow> | yep yep |
| 17:16 | <spikku> | Does anyone know details about HTML5 video tag? I'm confused about how it plays flash video without a plugin... |
| 17:16 | <wycats> | spikku: the browser has native support for playing videos using supported encodings |
| 17:17 | <wycats> | it only works in browsers that have added support for it |
| 17:45 | <spikku> | wycats: Thanks that's what I thought. |
| 17:45 | <spikku> | :) |
| 20:12 | <TabAtkins> | Wow. Check out the shirt on girl + reflection. What's going on here? http://googlesightseeing.com/maps?tw=914&p=&c=&t=h&hl=en&ll=51.515887,-0.076647&z=16&layer=c&cbll=51.517349,-0.083157&cbp=12,54.33,,2,10.09 |
| 20:12 | <miketaylr> | oh they have mirrors like that at coney island |
| 20:15 | <gsnedders> | TabAtkins: Requires Flash, kthxbai |
| 20:16 | <gsnedders> | TabAtkins: The photo of her itself is overexposed, the reflection of her isn't |
| 20:16 | <TabAtkins> | Hmm, maybe. |
| 20:16 | <gsnedders> | TabAtkins: (so her skin becomes white because of overexposure) |
| 20:17 | <gavin> | that doesn't look like overexposure |
| 20:17 | <miketaylr> | was that a pun? |
| 20:32 | <Lerc> | not to mention the arm is on the wrong side for a reflection |
| 20:35 | <Necrathex> | i can see her necklace still |
| 20:35 | <Necrathex> | i'd say simply overexposed |
| 20:36 | <Lerc> | a bilateral inversion overexposure |
| 20:38 | <Hixie> | gavin_: it's over-exposure, she has two shirts on |
| 20:43 | <Lerc> | Am I seeing it wrong? The raised arm is on the side facing the camera in both images isn't it? |
| 20:44 | <Necrathex> | both arms are |
| 20:44 | <Necrathex> | she has her hands together |
| 20:46 | Lerc | whips out screen magnifier. |
| 20:47 | <Lerc> | oh righty. I see that now. |
| 20:51 | <Lerc> | anyone what to trade some working retinas for some corrugated ones? |
| 22:38 | <sicking> | Hixie: is it ok to request features to be added to HTML-next on whatwg? I'm adding support for FormData, and i'm adding API for getting a pre-populated FormData from a <form> |
| 22:38 | <sicking> | Hixie: i.e. i'm adding HTMLFormElement.getFormData() |
| 22:39 | <sicking> | Hixie: it'd be "nice" to get that into a spec so that people can bikeshed about the syntax (for a loose definition of "nice" ;) ) |
| 22:39 | <Hixie> | absolutely |
| 22:39 | <Hixie> | my rate of responding to e-mails is a bit slow currently |
| 22:40 | <Hixie> | which i'm not happy about |
| 22:40 | <sicking> | Hixie: cool, i'll shoot the list a mail |
| 22:40 | <Hixie> | but i will definitely respond to any mail sent to whatwg in due course, and am happy to add new features especially with vendor interest |
| 22:41 | <Hixie> | btw what's the advantage of PING over POST? |
| 22:42 | <TabAtkins> | I have no idea what advantage it might confer. Anne just mentioned it yesterday. |
| 22:42 | <Hixie> | seems like POST has exactly the semantics we want |
| 22:43 | <TabAtkins> | sicking: You looked at the mail from the Sidney dude a week or two ago about a similar proposal? |
| 22:43 | <rektide> | is it possible for a Worker to create a MessageChannel to a page? |
| 22:46 | <sicking> | Hixie: oh, i don't care about PING vs. POST |
| 22:46 | <wycats> | Hixie: file a bug... you seem to be moving quickly at those |
| 22:46 | <wycats> | :P |
| 22:46 | <sicking> | Hixie: i guess you could argue that having a specific http-method that's somewhere inbetween "safe" and "unsafe" is a good idea |
| 22:47 | <Hixie> | wycats: yeah, that's why i'm not moving quickly at the mails :-) |
| 22:47 | <wycats> | Hixie: so I should stop filing bugs? :P |
| 22:47 | <Hixie> | sicking: somewhere between? not sure what that would mean |
| 22:47 | <Hixie> | wycats: no, no, you filing them is separate from my responding to them :-) |
| 22:48 | <sicking> | Hixie: Hmmm... i guess there is a lot that happens server-side with each tracked click. I.e. there is actually money changing hands, not just a counter increasing |
| 22:49 | <sicking> | Hixie: so i guess see my earlier reply; "Hixie: oh, i don't care about PING vs. POST" ;) |
| 22:49 | <TabAtkins> | Yup, it's very clearly a POST from semantics, or a similar unsafe method. Julian is arguing solely from a UI perspective. |
| 22:49 | <TabAtkins> | Which seems unwise. |
| 22:49 | <Hixie> | sicking: fair enough |
| 22:50 | <Hixie> | i think if we don't care if it's PING or POST, we shouldn't bother arguing for PING since nobody seems to actively want that so it wouldn't actually help make progress and certainly wouldn't help get the best possible spec :-) |
| 22:50 | <sicking> | sorry, i thought PING was what the spec currently said |
| 22:50 | <TabAtkins> | Sounds good. I think I'm the only one who actually mentioned it in-thread. |
| 22:51 | <Hixie> | oh is it? i thought it said POST. maybe i'm out of date. |
| 22:51 | Hixie | looks. |
| 22:51 | <sicking> | so in order to reduce the number of options people are arguing between i figured i'd back that proposal |
| 22:51 | <Hixie> | nah it's POST, with a body consisting of just "PING" |
| 22:51 | <sicking> | Hixie: but i could very well be out of date |
| 22:51 | <sicking> | ah |
| 22:51 | <Hixie> | ok glad we sorted that out :-) |
| 22:53 | <sicking> | Hixie: btw, when you wrote the HTML5 form submission stuff. Did you do a lot of testing for things like calling form.submit() from a "submit" event handler? And calling form.submit() twice in a row? Or submitting while another submission had already started |
| 22:53 | <sicking> | Hixie: our form submission code is *ugly*. Would like to rewrite but I know we need to support a lot of quirks |
| 22:54 | <Hixie> | sicking: i did a lot of testing. Whether I did _enough_ is a different matter. |
| 22:54 | <sicking> | ok |
| 22:54 | <Hixie> | sicking: but yeah, i did do a ton of testing |
| 22:55 | <Hixie> | i saw your feedback recently, looked like good stuff. |
| 22:55 | <sicking> | cool |
| 22:55 | <Hixie> | hopefully will get to it in the next few weeks |
| 22:55 | <Hixie> | i really want to get through some of these bugs to get that pile down, then do web sockets |
| 22:55 | <Hixie> | then it's back to the e-mail grind, probably wf2 first |
| 22:55 | <Hixie> | (wf2=forms) |
| 22:56 | <Hixie> | maybe canvas and video, too, there's lots pending on those |
| 22:57 | <sicking> | i have a backlog of emails i need to write :( |
| 22:57 | <sicking> | such as getting rid of the 'title' argument on pushState |
| 22:57 | <sicking> | and modifying <script> parsing |
| 22:57 | <sicking> | really behind on that one :( |
| 22:58 | <Hixie> | if you want long enough, you won't have to send the e-mails anymore, either because someone else did or because it's too late :-) |
| 23:05 | <jgraham> | As far as I can tell the only reason to advocate PING is that some of the people who think that links making POST requests is bad might be confused by having something that acts like POST but is spelled differently |
| 23:06 | <jgraham> | Which doesn't seem like a good reason, but does seem like the sort of reason that is attractive in a consensus based process |
| 23:07 | <TabAtkins> | Yeah, "to confuse the opposition" doesn't seem like a great idea to suggest anything, at least if we're actually trying to make good specs. |
| 23:09 | <Hixie> | jgraham: anyone who thinks that is clearly not familiar with how easy it is to trick users into doing POSTs, even HTTP experts (see e.g. the demos in http://damowmow.com/playground/demos/http/002/) |
| 23:10 | <TabAtkins> | Man, I hate having to deal with a customer who is clearly making a bad decision. >_< |
| 23:13 | <jgraham> | Hixie: Indeed. I think the UI argument is nonsense, not least because it is trivial (and common) to design UIs that don't enforce the distinction |
| 23:14 | <jgraham> | Anyway, sleep |
| 23:15 | <TabAtkins> | who all implements pushState and such so far? |
| 23:16 | TabAtkins | wants to throw some pushState at this ajax effect so it'll actually work with back/forward. |
| 23:17 | <sicking> | TabAtkins: firefox nightlies support it |
| 23:18 | <TabAtkins> | Ah, I was hoping it had made it to a public build already. Never mind, then. |
| 23:18 | <sicking> | pushState and replaceState |
| 23:18 | <sicking> | TabAtkins: our nightlies are public |
| 23:18 | <sicking> | TabAtkins: oh, the latest "developer alpha preview" has it |
| 23:18 | <TabAtkins> | I mean a build that's been pushed out in an auto-update. |
| 23:18 | <sicking> | TabAtkins: our nightlies are in auto-update ;) |
| 23:18 | <TabAtkins> | You know what I mean. >_< |
| 23:19 | <sicking> | actually i don't |
| 23:19 | <TabAtkins> | A build that normal people will have. |
| 23:19 | <sicking> | oh, like a final release? Don't wait that long to start playing with new features |
| 23:19 | <TabAtkins> | I'm not playing, I'm attempting to use it on a production site. |
| 23:20 | <sicking> | well, you should play with it before then to know that it meets your requirements |
| 23:20 | <TabAtkins> | Well, to be fair, I tend to *use* production sites to play with things. |
| 23:20 | <sicking> | we need spec feedback before final shipping |
| 23:21 | <TabAtkins> | k, i'll play with it a bit. I'll make sure it would actually be usable for my purposes. |
| 23:21 | <sicking> | yay! Sweet! Thanks :) |
| 23:21 | <TabAtkins> | Fwiw, I'll be trying it out on www.igofigure.com/spinnergy to make the ajaxified navigation actually play nicely with history. |
| 23:23 | <TabAtkins> | Where are the nightly builds downloadable from again? |
| 23:46 | <Hixie> | hsivonen: i'm considering parsing changes in http://www.w3.org/Bugs/Public/show_bug.cgi?id=8767 -- your input would be very welcome |