| 00:12 | <jgraham> | (I think my approach would be to make it very easy to not do and have the people who want the data fill in the gaps) |
| 02:55 | <Hixie> | wtf |
| 02:55 | <Hixie> | http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1246 |
| 02:56 | <Hixie> | <!DOCTYPE html><script>window.addEventListener('click', function (event) {w(event);}. true);</script><p>TEST |
| 02:56 | <Hixie> | am i wrong that clicking on TEST should invoke w() ? |
| 02:56 | <Hixie> | oh dear lord |
| 02:56 | Hixie | sees a comma that is really a period |
| 03:02 | <wilhelm> | "ACTION: Mary Brady get NIST to submit the 1,000,000 test cases Wilhelm said we will need for HTML5 [recorded in http://www.w3.org/2011/11/02-tpac-minutes.html#action01]"; … Apparently my work here is done. |
| 03:02 | wilhelm | plays Transport Tycoon instead. |
| 08:15 | <zcorpan> | shouldn't the quotes thing use :lang(foo) > q ? |
| 10:07 | <zcorpan> | what happened to https://github.com/sideshowbarker/console-object ? http://www.w3.org/Bugs/Public/show_bug.cgi?id=10694 |
| 11:58 | <annevk> | sigh |
| 12:04 | <zcorpan> | annevk: ? |
| 12:10 | <annevk> | zcorpan: it's 5AM |
| 12:13 | <zcorpan> | ah |
| 12:16 | <smaug____> | there are good reasons to not travel |
| 12:17 | <smaug____> | (though, sounds like it has been great fun in TPAC, and more interesting than last year) |
| 12:19 | <boblet> | does anyone remember if there was an attribute for article revision dates, similar to @pubdate? I heard talk of @revdate, but can’t seem to find any mention of it (specifically why it was dropped) |
| 12:20 | <annevk> | unconference made it good |
| 12:20 | <annevk> | group meetings are not that great though |
| 12:23 | <boblet> | also, git log -S is damn slow on webapps repo :) |
| 12:26 | <smaug____> | annevk: has there been any discussion about implementation status of webidl |
| 12:27 | <annevk> | not much; some people are going to work on a test suite though I believe |
| 13:10 | <foolip> | boblet, I don't think revdate has ever existed |
| 13:11 | <boblet> | foolip: yeah I couldn’t find any mention of it either. btw thanks for the git mirror of webapps :) cool seeing those 2006 commits |
| 13:12 | <foolip> | boblet, since log -S is so slow, sometimes git bisect is faster if you want to figure out when something was added/removed, but then you need to find a point before and after first |
| 13:13 | <boblet> | foolip: luckily Hixie’s commit msgs are pretty informative, so git log --grep has been working for me (much faster) |
| 13:14 | <foolip> | right, that should work a lot of the time |
| 15:15 | <zcorpan> | is the DOMException "type" exposed to scripts? |
| 15:16 | zcorpan | looks at webidl |
| 15:18 | <zcorpan> | .name |
| 15:24 | <linclark> | foolip: is there a bug with http://foolip.org/microdatajs/live right now? |
| 15:24 | <linclark> | foolip: I'm not getting any results for this snippet |
| 15:24 | <linclark> | http://pastebin.com/iBWKxig2 |
| 15:24 | <foolip> | linclark, of course, but none that I know of :) |
| 15:25 | <foolip> | wfm, which browser are you using? |
| 15:25 | <linclark> | Chrome.... which, now that you mention it has been having problems with YouTube's JS since I updated it |
| 15:26 | <foolip> | works in Chromium for me too |
| 15:27 | <foolip> | does the error console say anything? |
| 15:27 | <linclark> | I just closed out Chrome to see if restarting would help, it's working in FF for me |
| 15:27 | <linclark> | I'll let you know when I open Chrome back up |
| 15:27 | <foolip> | ok |
| 15:27 | <scor> | works in both chrome and FF for me |
| 15:28 | <linclark> | Uncaught TypeError: Object name has no method 'each' |
| 15:28 | <linclark> | must be something with my Chrome |
| 15:29 | <scor> | works with fresh chrome 15.0.874.106 |
| 15:29 | <scor> | https://skitch.com/scor/gf3nh/about-google-chrome |
| 15:32 | <linclark> | scor: I believed you ;) |
| 15:33 | scor | has been overskitching lately... |
| 15:43 | <linclark> | foolip: just FYI, it was a hiccup in Chrome. working now |
| 15:43 | <foolip> | good good |
| 16:09 | <kennyluck> | Is reading the error message the only way how you test what kind of error IE throws? |
| 16:11 | <michel_v> | w3 |
| 16:12 | <michel_v> | whoops, keyboard mistake. please don't sink my battleship. |
| 16:17 | <foolip> | zcorpan, does the latest bid on http://www.w3.org/Bugs/Public/show_bug.cgi?id=14260 sound good to you? |
| 16:20 | <Hixie> | latest bid, heh |
| 16:21 | <zcorpan> | foolip: do if i do document.createElement('video') and append tracks, those won't block playback since the element was empty at creation time? |
| 16:22 | <foolip> | yeah |
| 16:22 | <zcorpan> | not sure i like that |
| 16:22 | <foolip> | I'm not sure either |
| 16:22 | <zcorpan> | now i really have to go. |
| 16:22 | <foolip> | not sure what I would like, though |
| 16:24 | <Hixie> | we could say that you also set the list when the element is inserted into the document |
| 16:25 | <Hixie> | but that would only help if the script doesn't try to start playback until after that happens |
| 16:26 | <smaug____> | /> should not be used in html, right ? |
| 16:26 | <smaug____> | just <input>, not <input/> |
| 16:28 | <Philip`> | It's permitted on some elements but always unnecessary and confusing |
| 16:29 | <Philip`> | (...except on foreign (MathML/SVG) elements where it might do stuff) |
| 16:43 | <david_carlisle> | Hixie: I asked this the other day, but only answer I got was to ask you:-) whatwg weekly highlighted that microdata attributes don't apply to MathML. If we wanted them to apply to MathML, what would be the right course of action? |
| 16:43 | <Hixie> | hmm |
| 16:44 | <david_carlisle> | :-) |
| 16:44 | <Hixie> | does MathML have a DOM API? |
| 16:44 | <Hixie> | or does it just use Element? |
| 16:44 | tantek | thinks microdata (microformats, RDFa etc.) should apply to any practical markup language. |
| 16:44 | <david_carlisle> | It did, but th ebrowser implementers didn't really like it and just used a plain xml dom, but we could do something if it was needed |
| 16:45 | <Hixie> | david_carlisle: interesting |
| 16:45 | <david_carlisle> | so mathml2 had a dom api in chapter 8 but we pulled it in mathml3 saying it would be a separate spec if needed |
| 16:45 | <Hixie> | well what i really meant was "do browsers implement a DOM API for it" which i think you answered :-) |
| 16:45 | <Hixie> | david_carlisle: the answer then would probably depend on whether SVG wanted to add it as well |
| 16:46 | <Hixie> | david_carlisle: if SVG wants to add it too, then the answer is that I would just move the API to the Element node, and then define the attributes as applying to SVG and MathML in the HTML spec and the MathML and SVG specs would just need to mention in passing that the attributes are conforming, to make sure the loop was closed |
| 16:47 | <david_carlisle> | True, although for mathml perhaps more than svg, I think that the language should seem to the author as a unified markup for mathematical documents and the mathml/html distinction lost as far as poss |
| 16:47 | <shepazu> | Hixie: add microdata et al? |
| 16:47 | <shepazu> | or something else? |
| 16:47 | <Hixie> | shepazu: right (itemscope, itemtype, itemid, itemref, and itemprop) |
| 16:47 | <Hixie> | shepazu: global attributes |
| 16:47 | <shepazu> | Hixie, I think the SVG WG does want to add those, yes |
| 16:48 | <Hixie> | david_carlisle: from the authoring perspective it would be transparent, yeah |
| 16:48 | <Hixie> | shepazu: ok |
| 16:48 | <Hixie> | shepazu, david_carlisle: in that case i recomment filing a bug saying to add the item* attributes to SVG and MathML |
| 16:48 | <shepazu> | in general, we'd like to have parity with HTML features like that (for some value of "like that") |
| 16:48 | <shepazu> | k |
| 16:49 | <david_carlisle> | OK thanks |
| 16:49 | <shepazu> | david_carlisle: would you be so kind as to do that? |
| 16:49 | <Hixie> | shepazu, david_carlisle: please make sure to include in that bug a list of any elements that should be considered URL elements |
| 16:49 | <david_carlisle> | shepazu: yes |
| 16:49 | <Hixie> | shepazu, david_carlisle presumably <svg:a> and <mathml:image>, in particular |
| 16:49 | <Hixie> | shepazu, david_carlisle: but there's probably others too |
| 16:49 | <shepazu> | david_carlisle: great, please do add that you want them for SVG, not just MathML |
| 16:49 | <david_carlisle> | Hixie: yes although we also allow href on (more or less anything) echoes of xhtml2 don't you know:-) |
| 16:49 | <shepazu> | Hixie: yes, I'll try to ask the SVG WG this week about it |
| 16:50 | <Hixie> | david_carlisle: well for microdata you have to define for each element where the value comes from. it's usually textContent, but sometimes it's an attribute (we try to keep these to an absolute minimum) |
| 16:51 | <Hixie> | david_carlisle: do browsers implement href=""-everywhere? |
| 16:52 | <david_carlisle> | Hixie: I think it got added to firefox which is the main browser native version, and it will work in IE/Mathplayer after the next mathplayer release |
| 16:52 | <Hixie> | pity |
| 16:52 | <Hixie> | but ok |
| 16:53 | <david_carlisle> | the alternative (mathml2 variant) was to allow xlink:href everywhere but that wasn't overwhelmingly popular either |
| 16:53 | <david_carlisle> | and worked in firefox 2 but not 3 + |
| 16:54 | <Hixie> | the alternative is to just use <a> :-) |
| 16:54 | <shepazu> | <a> seems logical to me |
| 16:55 | <shepazu> | not much more verbose, I'd guess |
| 16:55 | <david_carlisle> | Anyway thanks for teh advice, i'll re-read the microdata spec before raising the bug, to try to make some coherent suggestions |
| 16:55 | <Hixie> | roger |
| 16:55 | <Hixie> | it should be pretty simple to do |
| 16:55 | tantek | agrees with just use <a> |
| 16:55 | <shepazu> | david_carlisle: please email me when you've filed it, and I'll add the SVG stuff |
| 16:55 | <david_carlisle> | shepazu: OK |
| 16:55 | <shepazu> | thanks, david_carlisle, Hixie |
| 16:56 | <tantek> | IMHO allowing xlink:href everywhere is already an anti-pattern (was effectively attempted in XHTML2) and should be avoided. Instead, re-use <a> as is and then all the existing logic about microdata/microformats/RDFa that applies to <a> should "just work" |
| 16:58 | <shepazu> | david_carlisle: is there a version of MathML that talks about HTML5 integration? |
| 16:58 | <shepazu> | SVG is working on such a spec |
| 16:58 | <stercor> | Where can I find a HTML5 template? |
| 16:59 | <stercor> | s/a/an/ |
| 16:59 | <Hixie> | stercor: <!DOCTYPE HTML><title>Insert title here</title><p>Insert document here |
| 16:59 | <stercor> | Hixie: no head, body tags? |
| 17:00 | <stercor> | or <html> |
| 17:00 | <Hixie> | they're optional |
| 17:00 | <Hixie> | you can add them, but i was lazy :-) |
| 17:00 | <stercor> | How do I specify utf-8? |
| 17:00 | <Hixie> | make sure to send the HTTP Content-Type header with charset=utf-8 |
| 17:01 | <annevk> | or <meta charset=utf-8> |
| 17:01 | <annevk> | before <title> |
| 17:01 | <shepazu> | stercor: you can also use http://html5boilerplate.com/ |
| 17:02 | <stercor> | My script is at http://pastebin.com/4xDjk5a4 It's good for 10 min. |
| 17:03 | <annevk> | ok, I cannot hold it to myself |
| 17:03 | <stercor> | shepazu: I'll go there. Thanks. |
| 17:03 | <annevk> | HTML WG inner circle: HTML co-chairs and accessibility representatives (as seen in today's meeting setup) |
| 17:07 | <david_carlisle> | tanteck: using html's a makes a lot less sense if mathml used elsewhere or on its own |
| 17:07 | <shepazu> | annevk: world's got to see, see all the love, love that's in you for the HTML WG? |
| 17:07 | <annevk> | shepazu: just my wit, or lack thereof, depending on your perception |
| 17:08 | <david_carlisle> | shepazu: yes mathml 3 spec mentions this briefly http://www.w3.org/TR/MathML3/chapter6.html#interf.html |
| 17:08 | <shepazu> | annevk: I was just making a lame song reference, actually |
| 17:08 | <annevk> | the t-shirt I wear today says "HTML LOVE & PEACE", by the way |
| 17:09 | <shepazu> | nice |
| 17:09 | annevk | needs to listen to more music |
| 17:09 | <shepazu> | annevk: this is really old 70s stuff |
| 17:10 | <shepazu> | annevk: what's so funny about peace, love, and understanding? |
| 17:10 | <david_carlisle> | shepazu: is your svg/html integration spec draft available anywhere (could probably try to coordinate something from mml side) |
| 17:11 | <shepazu> | david_carlisle: http://dev.w3.org/SVG/modules/integration/SVGIntegration.html |
| 17:11 | <shepazu> | but it's out of date, going to be modified soon |
| 17:11 | <david_carlisle> | thanks |
| 17:12 | <shepazu> | david_carlisle: maybe you should add <a> to MathML so it works even outside HTML… and microdata would need to be added too |
| 17:13 | <david_carlisle> | shepazu: well people already think mathml s rather markup heavy, if you had to wrap everything you wanted to be a link in another element it wouldn't be massively popular with mathml users, I think. |
| 17:15 | <shepazu> | understood, david_carlisle, but you might consider whether it should be allowed, so that content that comes from HTML would work everywhere |
| 17:15 | <tantek> | david_carlisle - as much as mathml users are also html authors, re-using <a> is likely to be more popular than a global (namespaced/prefixed) attribute. |
| 17:15 | <hober> | "i want this to be a link, so i put it in <a>" is pretty much the first thing any web author learns |
| 17:15 | <Ms2ger> | tantek, mathml3 href isn't namespaced, fwiw |
| 17:16 | <hober> | the set of mathml authors who aren't html authors isn't a very interesting set |
| 17:16 | <tantek> | Ms2ger - but xlink:href is ^^^^^ |
| 17:16 | <Ms2ger> | Well, yeah, don't do that :) |
| 17:16 | <tantek> | and universal 'href' attribute failed already in XHTML2, so no need to repeat that mistake. |
| 17:16 | <tantek> | ergo … <a> ftw |
| 17:17 | <Ms2ger> | Well, the difference is that browsers actually implement global href for mathml |
| 17:17 | <shepazu> | you could simply allow both syntaxes, but specify that for MathML in HTML, only <a> "works" |
| 17:18 | <hober> | why diverge mathml-in-html and mathml-in-fantasyland? |
| 17:18 | <david_carlisle> | shepazu: well of course mixing an html a in mathml already has defined (and unusually almost sensible:-) parse behaviour so users can already do that if they want |
| 17:19 | <tantek> | Ms2ger - really? So that mutant DNA from XHTML2 propagated to MathML? Sorry to hear that. |
| 17:19 | <david_carlisle> | hober: why mathml-in-fantasyland (there is far more mathml there than in html, currently) |
| 17:20 | <david_carlisle> | ODF inside openoffice for example |
| 17:22 | <david_carlisle> | tantek: href= wasn't specifically from html2, it came after consulting what people would rather implement given that xlink wasn't that popular with anyone. |
| 17:23 | <stercor> | annevk: Hmmm...HTML5 doesn't like <?php...?> What to do? |
| 17:23 | <annevk> | have it parsed by PHP first? |
| 17:23 | <annevk> | the output of PHP matters, not the input |
| 17:23 | <stercor> | Doh! |
| 17:24 | <stercor> | Just need to change the extension from .html to .php... |
| 17:24 | <annevk> | shepazu: love & peace are great, they're also slightly ironic in the context of HTML :) |
| 17:27 | <karlcow> | stercor: or change the way your html file are processed |
| 17:28 | <karlcow> | putting an extension in your uris make them weaker |
| 17:28 | <karlcow> | if in the future you change your technology, you will break links |
| 17:30 | <Hixie> | tantek: has hcard been updated to rfc6350? |
| 17:34 | <karlcow> | http://www.guardian.co.uk/technology/blog/2011/nov/03/will-html5-replace-native-apps?CMP=twt_gu |
| 17:34 | <tantek> | Hixie - working on it |
| 17:34 | <Hixie> | tantek: what's your plan for the XML property? |
| 17:34 | <Hixie> | (i'm updating the microdata vocab right now) |
| 17:34 | <tantek> | likely to subset based on properties with public web-based use-cases |
| 17:35 | <tantek> | XML property is not useful on the web |
| 17:35 | <Hixie> | so is your plan just to ignore the vcard requirement that vcard UAs never drop XML if they don't support it? |
| 17:35 | <tantek> | key additions/changes are things like "gender" (which has broad publishing support etc) |
| 17:35 | <Hixie> | i.e. if someone does a vcard->hcard->vcard round trip |
| 17:36 | <tantek> | well vcard->hcard wouldn't really be an vcard UA per se would it? that would be an hcard UA |
| 17:36 | <Hixie> | fair enough |
| 17:36 | <Hixie> | so we just say we're not "propagating vcards" when we go to hcard/microdata and so this isn't a problem |
| 17:36 | <Hixie> | i could get behind that |
| 17:36 | <Hixie> | ok |
| 17:37 | <tantek> | a possible sensible interpretation of vcard's XML property is to convert it to additional embedded markup inside an hcard |
| 17:37 | <tantek> | for the vcard->hcard direction |
| 17:37 | <tantek> | but for hcard->vcard, until someone documents some practical use cases, I see no reason for an xml property in hcard |
| 17:38 | <Hixie> | soudns good to me |
| 17:38 | <tantek> | Hixie, see http://microformats.org/wiki/microformats-2#h-card for my work in progress on updating hcard for RFC6350 (new/changed properties from RFC6350 and others noted) |
| 17:38 | <tantek> | consider that the "living spec" as it were ;) |
| 17:39 | <Hixie> | noted |
| 17:39 | <tantek> | and please do report back if you see something wrong or nonsensical |
| 17:44 | Hixie | learns from mf2 and flattens sex and gender-identity into top-level properties |
| 17:48 | <annevk> | mf2 |
| 17:48 | <annevk> | like XHTML2 but better? |
| 17:48 | <Hixie> | microformats 2 |
| 17:49 | <annevk> | looks like it is finally simpler |
| 17:49 | <annevk> | with implied things and such |
| 17:49 | <annevk> | <a class="h-card" href="http://benward.me">Ben Ward</a> |
| 17:49 | <tantek> | annevk - more like HTML5 in philosophy. documenting what's actually been implemented, then simplifying and adding more features for authors/designers etc. |
| 17:49 | <annevk> | is what I suggested informally to someone at a conference a couple of years ago |
| 17:49 | <annevk> | looks great |
| 17:49 | <tantek> | annevk - turns out you were right :) |
| 18:14 | <sicking> | and ECMAScript uses it |
| 18:14 | <sicking> | wrong window |
| 18:16 | dglazkov | now wonders what's the right window |
| 18:20 | <jgraham> | Is this jepoardy? |
| 18:20 | <jgraham> | We have to guess what "it" is |
| 18:21 | jgraham | goes for "Microsoft Word" |
| 18:21 | <jgraham> | ;) |
| 18:22 | <dglazkov> | It's clear to me that by "it", sicking means character "f" |
| 18:24 | <sicking> | today's TPAC meeting, in collaboration with sesame street, brought to you by the letter "Q" |
| 18:25 | <ojan> | how's the rest of tpac going? anything exciting? |
| 18:25 | <ojan> | i read all the various notes on component model related stuff |
| 18:26 | <ojan> | sicking: on a random note, is there documentation on how mozilla uses reftests? |
| 18:26 | <ojan> | sicking: we're figuring out how to extend our reftest support and it woudl be good if whatever we design is mozilla reftest compatible |
| 18:27 | <sicking> | ojan: http://lmgtfy.com/?q=mozilla+reftest ;-) |
| 18:27 | <ojan> | ojan-- |
| 18:27 | <sicking> | haha |
| 18:27 | <ojan> | sometimes i still forget that i work on and with open source projects |
| 18:28 | <sicking> | sorry, i couldn't help myself :) |
| 18:28 | <ojan> | nah...well deserved |
| 18:29 | <sicking> | ojan: lots of good meetings at TPAC this year though |
| 18:30 | <ojan> | sicking: yeah, i felt that monday and tuesday were very productive |
| 18:30 | <astearns> | AFAIK mozilla is moving away from the manifest (reftest.list) in favor of metadata in the test that the test harness uses to construct the manifest |
| 18:30 | <ojan> | i certainly don't regret going |
| 18:30 | <sicking> | yeah, i think this was the best one yet |
| 18:30 | <ojan> | sicking: i can't be there the rest of the week for health reasons :( |
| 18:30 | <sicking> | astearns: that could be |
| 18:30 | <sicking> | ojan: you might want to ping dbaron (who's still at TPAC i'd guess) |
| 18:31 | <ojan> | astearns: the thing we're currently trying to figure out is whether we can assert that references files always end with -ref or -notref |
| 18:31 | <sicking> | ojan: ugh, sorry to hear :( |
| 18:31 | <ojan> | or whether we need to parse all the tests first to figure out which ones are references files...which would suck |
| 18:31 | <ojan> | or to have some sort of manifest...which would also suck |
| 18:32 | <astearns> | definitely not a maintained manifest. On the filename I'm asking Peter Linss - just a sec |
| 18:32 | <sicking> | ojan: i don't think you can rely on -ref |
| 18:32 | <ojan> | sicking: :( |
| 18:32 | <sicking> | ojan: but the manifest is pretty easy to parse |
| 18:32 | <jgraham> | ojan: There are tests that use e.g. about:blank as the ref |
| 18:32 | <ojan> | maybe we'll need to add some sort of manifest format for the rare cases where we import other test suites |
| 18:33 | <jgraham> | We have a parser for the Mozilla format |
| 18:33 | <jgraham> | Well, several, I think |
| 18:33 | <jgraham> | It is pretty easy to write |
| 18:33 | <ojan> | i strongly strongly prefer self-describing tests to a manifest format |
| 18:33 | <jgraham> | That's not an either/or proposition |
| 18:33 | <ojan> | astearns: https://bugs.webkit.org/show_bug.cgi?id=66295 is where we're discussing this |
| 18:33 | <jgraham> | Also, the data is a triple |
| 18:34 | <jgraham> | (test, ref, type) |
| 18:34 | <jgraham> | where type is typically 'equals' or 'not equals' |
| 18:34 | <astearns> | Peter says there are different naming conventions. Sometimes refs start with ref- |
| 18:34 | <jgraham> | Sometimes 'not equals' is useful for making sure that you don't hit some bug |
| 18:35 | <ojan> | astearns: oh, i'm ok with that as long as you can always tell from the filename |
| 18:35 | <jgraham> | So (test.html, about:blank, !=) would ensure that test.html displays *something* |
| 18:35 | <astearns> | sometimes the refs are in a separate folder |
| 18:35 | <ojan> | jgraham: yeah, i see the benefit of being able to compare against about:blank |
| 18:36 | <ojan> | astearns: yeah, that's fine too |
| 18:36 | <astearns> | I'll add what Peter is telling me to 66295 |
| 18:36 | <ojan> | astearns: thanks |
| 18:36 | <ojan> | jgraham: ok...it sounds like we'll eventually need to add support for mozilla manifests... |
| 18:36 | <dbaron> | astearns, that's news to me |
| 18:36 | <ojan> | jgraham: but we'll probably use it exclusivly for mozilla reftests that we import |
| 18:37 | <dbaron> | ojan, sicking, ping me regarding what? |
| 18:37 | <jgraham> | right, we don't actually use the manifest directly either |
| 18:37 | <ojan> | dbaron: we're working out our reftest support for webkit... |
| 18:37 | <Ms2ger> | astearns, that's only the CSSWG |
| 18:37 | <jgraham> | But if we all have a common format that we can read, it is helpul for sharing stuff |
| 18:37 | <ojan> | dbaron: trying to figure out what design we need in order to be able to support both the mozilla reftest and the w3c ones |
| 18:37 | <ojan> | s/w3c/csswg |
| 18:38 | <Ms2ger> | Just support the reftest.list |
| 18:38 | <ojan> | jgraham: we certainly have no intention of creating a new manifest format |
| 18:38 | <astearns> | ms2ger: so far. I believe the intent is to have a single ref test format across the w3c |
| 18:38 | <jgraham> | One question I was talking to dbaron about is the size of the area that we screenshot |
| 18:38 | <Ms2ger> | astearns, yeah, and? |
| 18:38 | <jgraham> | In some cases it might be useful to standardise that |
| 18:39 | <ojan> | jgraham: fwiw, you can compare against about:blank using self-describing tests as well...the link element just points to about:blank |
| 18:39 | <Ms2ger> | asmodai, it's only the CSSWG that wants to get rid of the manifest afaik |
| 18:39 | <astearns> | dbaron: sorry, what's news to you? |
| 18:39 | <ojan> | Ms2ger: i support getting rid of manifest |
| 18:39 | <jgraham> | ojan: That's not really what "self-descibing" mens to me, but yes |
| 18:39 | <jgraham> | *means |
| 18:39 | <ojan> | Ms2ger: and i expect webkit in general would |
| 18:40 | <ojan> | jgraham: sure....i couldn't htink of a a better term for it |
| 18:40 | <ojan> | self-contained? |
| 18:40 | <jgraham> | (I think of "self-describing" as meaning "can be tested manually" |
| 18:40 | <jgraham> | ) |
| 18:48 | <dbaron> | astearns, mozilla switching away from manifest format |
| 18:49 | <ojan> | dbaron: what are you doing instead? |
| 18:50 | <ojan> | dbaron: would be good if mozilla + csswg use the same system if possible |
| 18:50 | <astearns> | dbaron: ah, OK. I forget who I was talking to about this, but I thought this was happening in order to share tests more efficiently |
| 18:51 | <dbaron> | astearns, though once the CSSWG settles on internal != and == links I suppose we might... |
| 18:51 | <dbaron> | (I don't remember what the CSSWG settled on regarding and vs. or.) |
| 18:51 | <dbaron> | instead of what? |
| 18:51 | <astearns> | csswg is still using manifests, it's just that the data is in the test file and the manifests are ephemeral artifacts of the test harness |
| 18:51 | <ojan> | astearns: i don't understand that sentence at all |
| 18:51 | <ojan> | lol |
| 18:52 | <ojan> | astearns: isn't the csswg just using link elements and/or test/directory naming? |
| 18:52 | <astearns> | you'll have to talk to Peter Linss to get the real explanation :) |
| 18:53 | <Ms2ger> | The build system produces the manifest files from the markup, sounds right |
| 18:54 | <ojan> | but the existence of the manifests isn't required to run the tests...you could write a different test runner that doesn't generate manifests, no? |
| 18:54 | <Ms2ger> | I guess |
| 18:54 | <astearns> | I expect that's the case |
| 18:55 | <Ms2ger> | I know that we're moving towards manifests for non-reftest tests |
| 18:55 | <Ms2ger> | Because pulling all tests out of a directory was too much of a pain |
| 18:57 | <ojan> | manifests-- |
| 18:58 | <Ms2ger> | Tell me what's better, then |
| 18:58 | <ojan> | i guess i don't know how the non-refttest tests you're talking about work |
| 18:59 | <ojan> | for webkit, we just use filename conventions... |
| 18:59 | <Ms2ger> | Yeah, we want to get rid of that |
| 18:59 | <ojan> | foo.html is compared against foo-expected.txt and foo-expected.png |
| 18:59 | <ojan> | why? |
| 19:00 | <Ms2ger> | Haven't been following closely myself |
| 19:00 | <ojan> | needing to maintain manifest files seems like a lot of unnecessary work |
| 19:00 | <astearns> | + |
| 19:00 | <Ms2ger> | It's not too bad, IMO |
| 19:00 | <ojan> | if there's huge benefit, it might be worth it, but i don't see any benefit |
| 19:01 | <astearns> | benefit over naming scheme: more interesting relationships than 1-1 |
| 19:01 | <astearns> | multiple tests sharing a reference |
| 19:02 | <astearns> | tests having more than one reference |
| 19:02 | <ojan> | you can do this with link elements in the test...the only case where that doesn't work is if the presence of the link element messes with what you're testing |
| 19:03 | <ojan> | and in those cases you just have to live with 1-1 |
| 19:03 | <astearns> | yes, I was just listing benefits over naming schemes |
| 19:03 | <astearns> | I prefer metadata because then I can modify one file instead of keeping track of two |
| 19:04 | <astearns> | (sorry, metadata over manifests) |
| 19:23 | <TabAtkin1_> | ojan: The CSSWG uses explicit links to references, which allows you to reuse a single ref for many tests (which we do a lot). |
| 19:23 | <TabAtkin1_> | ojan: And then, yeah, the build script extracts metadata from the tests into the manifest file. |
| 19:24 | <TabAtkin1_> | ojan: Manifests are probably necessary at some point because not all languages expose a metadata functionality like HTML's <link>. |
| 19:25 | <wilhelm> | dbaron: The Chrome team wishes to discuss reftests today. Do you have time to meet us in the lobby around 14:00 today? |
| 19:25 | <dbaron> | wilhelm, depends on the agenda in #fx, but probably yes |
| 19:26 | <wilhelm> | dbaron: Great. If there's any other time that works better for you, do tell. (I have another meeting at 15:30.) |
| 19:28 | <smaug____> | svg in html doesn't really support namespaces, right? |
| 19:29 | <smaug____> | it is just that svg elements get svg namespace |
| 19:29 | smaug____ | is too lazy to read the spec |
| 19:31 | <Ms2ger> | smaug____, correct |
| 19:31 | <Ms2ger> | (Also, xlink) |
| 20:02 | <ojan> | TabAtkins: yeah, i like that, but for the links to references, i want all references to be clear that they are references and not test from either the filename or the path |
| 20:03 | <ojan> | TabAtkins: as in, <link ref="bar.html"> should not work. <link ref="bar-ref.html"> is fine though |
| 20:03 | <ojan> | TabAtkins: i'm also ok with refs being about:blank or data urls though |
| 20:04 | <ojan> | TabAtkins: the part i care about is that it's clear looking at a given file in the tree whether it is a test or a reference |
| 20:04 | <ojan> | wilhelm: unfortunately, i can't make it to tpac today...who from chromium did you talk to that will be there? |
| 20:07 | <wilhelm> | ojan: Ryosuke. |
| 20:09 | <ojan> | wilhelm: k...well, if notes are taken, i'll read the minutes and comment appropriately. :) |
| 20:21 | <Hixie> | man, the list of changes in the new vcard is woefully incomplete |
| 21:21 | annevk | tries to play foolip |
| 21:21 | annevk | is not that great at it |
| 21:21 | <annevk> | (discussing adaptive streaming in the HTML WG) |
| 21:30 | <foolip_> | annevk: good luck! |
| 21:31 | <foolip_> | say no to defining a manifest format before we have the JS API to do it without manifests |
| 21:34 | <annevk> | I think I got that bit right :) |
| 21:39 | <foolip_> | also say no do DRM :) |
| 21:39 | <annevk> | so they brought it up |
| 21:39 | <annevk> | and I said JavaScript |
| 21:39 | <annevk> | and they said no |
| 21:39 | <Hixie> | "if we don't support drm it's limiting to users" |
| 21:39 | <Hixie> | ummm |
| 21:40 | <Hixie> | i think he got that backwards |
| 21:40 | <foolip_> | when they say "replace your media framework with a 3rd party binary blob", you say no :) |
| 21:40 | <annevk> | what is wrong with the javascript thingie though? |
| 21:40 | <annevk> | they said something about not secure enough |
| 21:40 | <annevk> | but I'm not sure what that means |
| 21:41 | <annevk> | you can get the key separately from the content and make things work, no? |
| 21:41 | <rillian_> | I gather there are layers of snake oil |
| 21:41 | <rillian_> | encrypting the stream from the server is just one layer |
| 21:41 | <foolip_> | anything that doesn't replace the media framework is trivial to circumvent, since you could otherwise just modify the browser demuxer to write to disk |
| 21:41 | <rillian_> | others are things like querying random system information and blocking playback if the locale or timezone is wrong |
| 21:42 | <annevk> | foolip_: I see |
| 21:42 | <rillian_> | and passing keys and encrypted data out of javacript to the binary blob that actually decodes the video |
| 21:42 | <foolip_> | so implicitly what is required is a plug-in architecture for <video>, or they cooperate only with the browsers they think are important |
| 21:42 | <foolip_> | in either case, not so great for us |
| 21:42 | <rillian_> | also, they want access to things like hardware identifiers so they can track users better |
| 21:43 | <annevk> | foolip_: and some kind of "standard like looking API on top" |
| 21:43 | <annevk> | ? |
| 21:43 | <annevk> | they were asking for that API I guess |
| 21:43 | <foolip_> | yeah, kind of like ns4plugins is a standard |
| 21:43 | <annevk> | great success |
| 21:44 | <foolip_> | gotta sleep, I'll leave it to you now :) |
| 21:44 | <annevk> | g'night! |
| 22:05 | <roc> | annevk: FWIW http://hg.mozilla.org/users/rocallahan_mozilla.com/specs/raw-file/tip/StreamProcessing/StreamProcessing.html can be used to implement adaptive streaming quite well IMHO |
| 22:06 | <roc> | for lame DRM, something else is needed though ... probably the best thing would be an API that lets you implement codecs (and containers) in JS |
| 22:06 | <roc> | some kind of worker API that takes compressed data in and produces audio and video tracks out |
| 22:31 | <remysharp> | (probably wrong place for this - but) do browsers wait until the connection is closed before rendering the DOM tree? |
| 22:32 | <franksalim> | remysharp: connection? do you mean until an HTTP response body has loaded? |
| 22:33 | <remysharp> | basically I have this simple server: http://jsbin.com/ovahuf/js |
| 22:33 | <remysharp> | curl that server and I get hello...(2 seconds) world |
| 22:34 | <remysharp> | view in a browser like Chrome (for instance) and it hangs until the whole this is delivered |
| 22:34 | <remysharp> | I just thought browsers rendered the DOM as it was recieved |
| 22:34 | <annevk> | remysharp: no |
| 22:34 | <franksalim> | remysharp: some browsers wail until a certain amount of data has arrived |
| 22:34 | <remysharp> | like I said - probably wrong place for this Q - but you guys and gals are all smart! |
| 22:34 | <jarek> | remysharp: I guess browsers render the DOM on the fly, otherwise all pages would be awfully slow |
| 22:34 | <annevk> | remysharp: that is, we don't wait |
| 22:35 | <remysharp> | ah - but you want a certain amount of data before rendering? |
| 22:35 | <annevk> | there is some timeout and the specifics differ per browser |
| 22:35 | <annevk> | but some pages don't close their connection, so not rendering does not work |
| 22:35 | <franksalim> | remysharp: make that a setInterval of res.write(...) and see what you get :) |
| 22:36 | <remysharp> | franksalim: good idea |
| 22:36 | <jarek> | remysharp: here is a nice article on this topic: http://taligarsiel.com/Projects/howbrowserswork1.htm |
| 22:36 | <franksalim> | remysharp: every browser has some way of delivering a partial response |
| 22:36 | <jarek> | "For better user experience, the rendering engine will try to display contents on the screen as soon as possible. It will not wait until all HTML is parsed before starting to build and layout the render tree. Parts of the content will be parsed and displayed, while the process continues with the rest of the contents that keeps coming from the network." |
| 22:37 | <remysharp> | great - cheers. That's what I suspected (and was pretty sure I had seen in the past) - but my test obviously was too contrived! |
| 22:40 | <bga_> | remysharp and why css hasnt ::parent rule. style and draw once during onfly rendering |
| 22:42 | <remysharp> | btw - Acknowledgements in Introducing HTML5 (2nd edit) - annevk in particular: http://dl.dropbox.com/u/43399/acks.jpg |
| 22:43 | <annevk> | uppercase V, really? |
| 22:43 | <annevk> | thanks though :) |
| 22:44 | <annevk> | almost like adactio wrote it :p |
| 22:44 | <remysharp> | annevk: shit - really. ah, bugger, I guess that's a reason to cash in on a 3rd edition ;-) |
| 22:44 | <annevk> | hehe |
| 22:44 | <franksalim> | ha, nice |
| 22:45 | <annevk> | ah yeah, I read parts of that book mostly due to Bruce |
| 22:45 | <annevk> | nice read |
| 22:46 | <jgraham> | annevk: You look lost |
| 22:47 | <remysharp> | cheers, I'm pretty sure I wouldn't have finished my parts had it not been for bruce still writing his parts. |
| 22:53 | <jarek> | http://dev.w3.org/SVG/modules/ |
| 22:53 | <jarek> | there is not much work going in SVG space |
| 22:54 | <heycam> | jarek, a bunch of those have basically moved to be joint CSS/SVG specs |
| 22:55 | <jarek> | hendry: is there anything besides https://dvcs.w3.org/hg/FXTF/raw-file/tip/filters/publish/Filters.html ? |
| 22:55 | <jarek> | s/hendry/heycam |
| 22:55 | <heycam> | jarek, maybe? :) would have to look |
| 22:55 | heycam | must afk |
| 22:55 | <annevk> | jgraham: I'm trying to pull a jgraham :p |
| 22:56 | <heycam> | the transforms stuff at least, though |
| 22:57 | <annevk> | rules for pronouncing Ms2ger in meetings: "miss-two-ger" (roughly) |
| 22:58 | <jgraham> | Make him sound like a girl? |
| 22:59 | <bga_> | microsoft2 german |
| 22:59 | <hober> | post-tpac in-n-out run tonight anyone? |
| 22:59 | <annevk> | ooh |
| 22:59 | annevk | had pancakes for breakfast and too much coke |
| 22:59 | jgraham | proposes we call him "Missy Too-ger" |
| 23:00 | <annevk> | (as in cola) |
| 23:00 | <annevk> | hober: is there more "healthy" food in SC? |
| 23:07 | <TabAtkin1_> | hober: Apparently I'm not allowed to do dinner an in-n-out tonight. >_< |
| 23:07 | <TabAtkin1_> | (According to Shane, who is apparently MY MOM NOW GEEZ.) |
| 23:08 | <jgraham> | It's that the role your wife is supposed to take? |
| 23:09 | <annevk> | SAD TabAtkin1_ IS SAD |
| 23:09 | <jgraham> | *Isn't that |
| 23:09 | <annevk> | also, what is there to do 2AM Sunday and why was I not told? |
| 23:09 | <Hixie> | tantek_: (from #htmlwg) Google does; but if you just search for [mv] we currently seem to assume that you mean the unix command or other things actually called "mv". Try searching for "la fiesta, mv" and notice that "Mountain View" is boldend (i.e. matched) in the result |
| 23:10 | <franksalim> | hober: I would try to crash that. I could use another burger |
| 23:10 | <tantek_> | Hixie, maps doesn't seem to recognize it |
| 23:10 | <tantek_> | last I checked (a few weeks ago?) |
| 23:10 | <tantek_> | MV = Mountain View that is |
| 23:10 | <tantek_> | I think it put it in Missouri or something |
| 23:10 | <Hixie> | yeah, weird |
| 23:10 | <tantek_> | search engine heuristics are pretty flakey |
| 23:10 | <annevk> | Google services are often inconsistent |
| 23:11 | <tantek_> | often good, but yeah |
| 23:11 | <annevk> | e.g. G+ was awful when it came to "WHATWG" |
| 23:12 | <jgraham> | Well it's a common problem. Heuristics are flakey but work everywhere; specific markup can still be flakey but might be less so on average, but only works when people specifically add extra stuff |
| 23:21 | <TabAtkin1_> | annevk: 2am on Sunday is the DST switch in the US. |
| 23:22 | <annevk> | cunning |
| 23:22 | <TabAtkin1_> | Also: we're done today in SVG. Is it worthwhile to attend HTML? |
| 23:22 | <annevk> | sort of status update session |
| 23:22 | <TabAtkin1_> | That sounds not very interesting. |
| 23:27 | <ojan> | random question...anyone know the history behind percentage sizes in standards mode? specifically, in quirks mode, to resolve a percentage, you walk up the tree until you hit the first non-auto, non-percentage valu (roughly)...for standards mode, if you hit an auto value you bail. |
| 23:27 | <ojan> | this behavior seems totally wrong to me and i'm wondering how the decision got made |
| 23:27 | <ojan> | so i can propose a fix for the future |
| 23:28 | <ojan> | i figure dbaron or sicking might know? |
| 23:28 | <tantek_> | ojan - is that a CSS question? |
| 23:28 | <ojan> | yeah...i guess i should get on some other irc channel |
| 23:28 | <annevk> | hixie resolved 80% of 1550 bugs since we had the HTML5 Last Call |
| 23:29 | <tantek_> | might have better luck on irc://irc.w3.org:6665/css |
| 23:29 | <annevk> | that's about 200 bugs per month |
| 23:29 | <tantek_> | especially this week |
| 23:29 | <ojan> | tantek_: thx. |
| 23:29 | <annevk> | and it excludes emails and other specs |
| 23:29 | annevk | amazed |
| 23:30 | <ojan> | that's pretty crazy |
| 23:30 | <tantek_> | ojan, I used to have the answer to your question in my head (CSS 2.1 details and reasoning for all compat/strict switches etc.), but unfortunately haven't used that info in code in ~10 years, sorry. |
| 23:31 | <ojan> | tantek_: yeah, i figure this decision was made a lloooong time ago |
| 23:33 | smaug____ | clearly needs to file some more HTML bugs so that Hixie has something to do |
| 23:36 | <AryehGregor> | ojan, FWIW, I've run into this behavior in practice, and it was really confusing. |
| 23:36 | <AryehGregor> | I assume it's impossible to change now, though. |
| 23:36 | <roc> | ojan: which behavior seems wrong? |
| 23:36 | <AryehGregor> | I'd guess it has to do with the fact that in some cases, the width of an auto element depends on its contents. |
| 23:37 | <AryehGregor> | E.g., a floated div with width: auto will be as wide as its contents, so trying to set contents' width relative to it is obviously going to be bad. |
| 23:37 | <AryehGregor> | But there are people here who are much more expert in CSS than me, so why am I talking? |
| 23:38 | <ojan> | roc: the standards behavior |
| 23:38 | <AryehGregor> | (the cases where it's confusing are where "auto" translates to "100%", which IIRC is the case for blocks in normal flow with no margin or padding, so you have to add a magic width: 100% which doesn't actually do anything noticeable) |
| 23:38 | <ojan> | roc: it's clearly not what people want/expect |
| 23:38 | <ojan> | roc: the way you get the behavior you want these days is to have to put height 100% on every ancestor including the html element |
| 23:38 | <AryehGregor> | Yes, that's extremely confusing. |
| 23:38 | <ojan> | roc: then when you change your structure a little, you have to remember to put height 100% on any new elements you add |
| 23:39 | <roc> | yeah, sounds reasonable, but I doubt we can change the standards-mode behavior without hitting compat issues |
| 23:39 | <ojan> | AryehGregor: the thing that bugs me is that the quirks behavior does it right, so it's clearly solvable |
| 23:39 | <ojan> | roc: yeah, we'd have to add a new unit |
| 23:39 | <ojan> | roc: which sucks...but it's better than the status quo imo |
| 23:39 | <roc> | maybe there are better features for the use-cases |
| 23:40 | <AryehGregor> | There'd be no graceful fallback for a new unit, so it would be useless for ages. |
| 23:40 | <AryehGregor> | Although the same is true for any solution here, I guess. |
| 23:40 | <roc> | a lot of uses for percentage height blocks are covered by flexbox for example |
| 23:40 | <AryehGregor> | Really, the same is true for any feature that merely lets you do an existing thing more easily. |
| 23:41 | <ojan> | roc: the problem is that a lot of times the flexbox is in a perctnage container |
| 23:41 | <ojan> | roc: e.g. if you want the flexbox to fill the whole viewport |
| 23:41 | <ojan> | roc: i guess the new viewport units address that specific use-case |
| 23:42 | <ojan> | roc, AryehGregor: what people actually do in practice is make the element positioned and give it top/left/right/bottom=0 |
| 23:42 | <ojan> | but most people don't think to do that |
| 23:42 | <AryehGregor> | Interesting. |
| 23:43 | <ojan> | so they either learn to put percentages up the whole tree, or they hard code using javascript |
| 23:43 | <AryehGregor> | That only works for fixed width. |
| 23:43 | <ojan> | it's a case of people doing the latter that got me worked up enought to try to address it |
| 23:43 | <AryehGregor> | The use-case is just making a column that's the height of the whole page? |
| 23:43 | <ojan> | AryehGregor: not necessarily the whole page... |
| 23:43 | <ojan> | AryehGregor: image in a dialog where you want the contents to fill the dialog |
| 23:44 | <ojan> | AryehGregor: the dialog is fixed height |
| 23:44 | <AryehGregor> | If the dialog is fixed height, then the problem is only if you have a wrapper intervening between the dialog and its height: 100% contents? |
| 23:44 | <AryehGregor> | Which has height: auto? |
| 23:44 | <ojan> | AryehGregor: which is the common case |
| 23:44 | <AryehGregor> | Right, makes sense. |
| 23:44 | <ojan> | AryehGregor: or...a common case anyways |
| 23:44 | <AryehGregor> | The current behavior is indeed pathological. |
| 23:45 | <AryehGregor> | Although you do have to bail out in some cases. <div style=float:right><div style=width:100%>foo</div></div> can't do anything sensible except ignore the width property. |
| 23:46 | <AryehGregor> | Unless it makes the parent div width:100% despite being floated, which would be weird. |
| 23:46 | <AryehGregor> | Although perhaps not entirely unexpected. |
| 23:48 | <ojan> | AryehGregor: yes, there are cases you need to bail...but the common case of auto-sizing shoudl not be one of them |
| 23:48 | <ojan> | a coworker had an interesting idea of an altnerative to a new unit |
| 23:48 | <ojan> | we could add a new property a la box-sizing |
| 23:48 | <ojan> | ok...i'll stop littering whatwg with css discussion... |
| 23:49 | <AryehGregor> | Yeah, I thought of that too, but a new unit makes more sense here. |
| 23:50 | <AryehGregor> | It's more predictable. |
| 23:50 | <AryehGregor> | It won't change random the meaning of random other rules. |
| 23:50 | <AryehGregor> | (#whatwg is fine for CSS discussion) |
| 23:50 | <AryehGregor> | (although not for making actual decisions, of course) |
| 23:50 | <AryehGregor> | s/random// |
