| 03:39 | <Hixie> | jgraham: yt? |
| 04:02 | <Hixie> | is pms broken for anyone else? |
| 04:26 | <jarek> | Hi |
| 04:27 | <jarek> | are there any chances for getting ::selection pseudo-element back in CSS Selectors spec? |
| 04:27 | <jarek> | it seems to be supported by all major browsers |
| 04:29 | <jarek> | even IE9 supports it |
| 04:30 | <jarek> | https://developer.mozilla.org/en/CSS/%3a%3aselection |
| 04:31 | <jarek> | I wonder why all browsers except Firefox are using unprefixed version |
| 04:31 | <jgraham> | Hixie: Sems to be at least a bit up |
| 04:31 | <jgraham> | +e |
| 04:32 | <Hixie> | jgraham: http://pimpmyspec.net/aquarium.py/output?uri=http%3A%2F%2Fwww.whatwg.org%2Fspecs%2Fweb-apps%2Fcurrent-work%2Fsource-whatwg-complete&process_filter=on&process_toc=on&process_xref=on&process_sub=on&process_annotate=on&filter=&annotation=&newline_char=LF&tab_char=SPACE&min_depth=2&max_depth=6&w3c_compat_xref_a_placement=on&parser=lxml.html&serializer=html5lib&output_encoding=ascii |
| 04:32 | <Hixie> | jgraham: gives me an exception |
| 04:32 | <Hixie> | gotta go, bbiab |
| 04:34 | <jgraham> | Hixie: node=<?p?> in the traceback looks suspicious |
| 04:35 | <jgraham> | My first guess is that it is falling over on a PI that shouldn't be there |
| 04:45 | <divya> | foolip: does this html to atom algo removal mean there is no more toatom microdata interface? |
| 05:33 | <Hixie> | jgraham: ah, good to know, didn't realise PIs would be a problem |
| 05:33 | <Hixie> | jgraham: fixed, retrying |
| 05:43 | <jgraham> | Hixie: Yeah, it has no idea how to serialize them. That could be seen as a bug |
| 05:43 | jgraham | -> sleep |
| 05:43 | <Hixie> | nn |
| 05:43 | <Hixie> | (that did fix it btw) |
| 05:58 | <boblet> | hey all, does XML (and by extension XHTML5) require lowercase element/attribute names? |
| 05:59 | <Hixie> | XML does not, though it is case-sensitive. All the elements in XHTML are lowercase, so it effectively does. |
| 05:59 | <Hixie> | elements and attributes |
| 06:00 | <boblet> | Hixie: All the elements in XHTML are lowercase meaning XHTML 1.x right? thanks |
| 06:00 | <Hixie> | meaning XHTML, any version |
| 06:00 | <boblet> | aah ok |
| 08:11 | <hsivonen> | I wonder how often the 2D canvas is used for vector drawing vs. bitmap blitting |
| 08:11 | <hsivonen> | also, I wonder what vector drawing use cases there are in the wild that wouldn't be more appropriate as SVG |
| 08:13 | <hsivonen> | what ojan said in IRC logs about SVG name case handling scares me |
| 08:13 | <hsivonen> | I wish Chrome just did what Firefox does (which is spec-wise right) and now try to invent new behaviors |
| 08:35 | hsivonen | sees "Our mission is to create the semantic web." in an HTML WG bug comment |
| 09:03 | <zcorpan> | Hixie: i think the websocket garbage collection rules might need tweaking now that message can't be fired in CLOSING (can error be fired in CLOSING?) |
| 09:06 | <zcorpan> | Hixie: i think i see more typos in r6798 (s/the// s/it/if/) |
| 09:07 | <Ms2ger> | zcorpan, filed |
| 09:14 | <hsivonen> | maybe I should email ojan with references to relevant Gecko bugs to avoid a situation where Chrome just proceeds to make stuff up |
| 09:27 | <Ms2ger> | glwt |
| 09:32 | <Ms2ger> | gsnedders, I believe the conclusion was "What the hell? We don't want to implement that" |
| 13:08 | <JakeA> | Anyone know why — in html comments are still disallowed? |
| 13:09 | <JakeA> | Stupid auto correct, I mean -- of course |
| 13:09 | <Ms2ger> | It is allowed now, IIRC |
| 13:10 | <Ms2ger> | Hmm, I'm wrong |
| 13:10 | <Ms2ger> | Not sure |
| 13:11 | <Ms2ger> | Because that breaks in some browser versions, perhaps |
| 13:11 | <JakeA> | Wonder if there's a particular faulty browser that goes nuts, or if it just wasn't considered to be relaxed |
| 13:11 | <JakeA> | yeah |
| 13:12 | <Ms2ger> | Firefox < 4, I think? |
| 13:12 | <Ms2ger> | Some versions of Opera as well, I suspect |
| 13:12 | <zcorpan> | we generally want legal trees to be serializable in both text/html and xml |
| 13:13 | <zcorpan> | but i guess it will be changed at some point |
| 13:13 | <JakeA> | Makes sense, I guess it should be covered by the error handling, maybe already is |
| 13:14 | <JakeA> | Cheers guys |
| 14:06 | <bga_> | how easy http://www.youtube.com/watch?v=FNWcy8S2k4Y |
| 14:06 | <bga_> | like flexbox |
| 15:05 | <zcorpan> | is automatically resizable textarea solved already by css.next ? |
| 16:25 | <Hixie> | hsivonen: http://www.w3.org/Bugs/Public/show_bug.cgi?id=14596#c3 |
| 16:45 | <annevk> | Hixie, I think we should remove FF now from WebVTT, I know you don't care, but I do a little bit |
| 16:51 | <Hixie> | annevk: why? |
| 16:52 | <Hixie> | annevk: it's a pain to do (e.g. means implementors and i have to duplicate their definitions of "skip whitespace", "space character", etc) |
| 16:52 | <Hixie> | annevk: what's the benefit? |
| 19:40 | <Ms2ger> | Hmm, Hixie fixed bug 1462814628 |
| 19:41 | <oconnore> | is there an html5lib fork compatible with python3? |
| 19:41 | <oconnore> | I pulled from: https://github.com/mikexstudios/html5lib-python |
| 19:41 | <oconnore> | er.. cloned |
| 19:43 | <Ms2ger> | oconnore, yeah, but it's rather out of date |
| 19:44 | <oconnore> | Ms2ger: what would you use that is up to date? |
| 19:44 | <Ms2ger> | The python2 version |
| 19:44 | <oconnore> | hmm, python people are so weird... |
| 19:44 | <oconnore> | ok |
| 19:45 | <Ms2ger> | Lots of work, little benefit.. |
| 19:46 | <oconnore> | utf8 by default is pretty spiffy :) |
| 19:46 | <oconnore> | is that github link a reasonably up to date python 2 version? |
| 19:47 | <hober> | whoa, confusing nick :) |
| 19:47 | <Ms2ger> | http://code.google.com/p/html5lib/ |
| 19:47 | <oconnore> | uploaded jan 2010? |
| 19:58 | <heycam> | jamesr, ping |
| 20:01 | <gsnedders> | oconnore: Expect html5lib to start working with Python3 again within a week |
| 20:02 | <Ms2ger> | Oh? |
| 20:02 | <gsnedders> | http://code.google.com/p/html5lib/issues/detail?id=187 |
| 20:02 | <gsnedders> | Most of the work was done by jgraham ages ago, it's just we've regressed 2to3 making something useful |
| 20:05 | <Ms2ger> | Philip`, you don't happen to have time to have a look at http://www.w3.org/Bugs/Public/show_bug.cgi?id=14356 ? |
| 20:06 | <gsnedders> | I'm just in general planning on trying to crack through as many html5lib issues as possible after all my work due in tomorrow is done |
| 20:06 | <gsnedders> | Speaking of which, I should do some of that :) |
| 20:13 | <dglazkov> | Hixie: are you coming to webapps? |
| 20:14 | <annevk> | Hixie: so the reason to remove FF is because cache manifests don't have it either |
| 20:14 | <annevk> | Hixie: if you think we should have FF we should add it to cache manifests I suppose |
| 20:25 | <oconnore> | gsnedders: thanks! |
| 20:30 | <jamesr_> | heycam, pong |
| 20:30 | <heycam> | jamesr_, hey. I'm at TPAC, I'm going to be meeting with the Web Perf WG in half an hour. |
| 20:30 | <heycam> | jamesr_, and I've been ignore raf for a while :) |
| 20:30 | <jamesr_> | cool! i'm not able to attend any TPAC stuff this round |
| 20:30 | <heycam> | jamesr_, so just wanted to check in and see what the status is |
| 20:30 | <jamesr_> | heycam, there are open issues on RAF, but afaik nothing about it to be resolved at TPAC |
| 20:30 | <heycam> | jamesr_, yeah I would be reluctant to resolve things here |
| 20:30 | jamesr_ | finds the list of open issues |
| 20:31 | <jamesr_> | any idea where i could find it? |
| 20:36 | <heycam> | yeah, hang on |
| 20:36 | <heycam> | http://www.w3.org/2010/webperf/track/products/5 |
| 20:36 | <jamesr_> | heycam, i don't think there are any open editorial issues. the open issues are behavior things that we need to hash out w/ vendors and are all basically waiting for feedback |
| 20:36 | <heycam> | yes |
| 20:36 | <jamesr_> | i haven't been able to provide the implementor feedback for chromium on them, been busy doing other things |
| 20:36 | <heycam> | there was one specifically you said you were going to experiement with |
| 20:36 | <heycam> | which I think was the running animations at all in bg tabs |
| 20:36 | <jamesr_> | yes. i have had some talks with jquery guys about that offline |
| 20:36 | <heycam> | ok |
| 20:36 | <jamesr_> | the last discussion was mostly about jquery behaving badly |
| 20:36 | <jamesr_> | but the current text in the spec matches what MS and we would prefer |
| 20:36 | <heycam> | ok |
| 20:36 | <jamesr_> | gecko had a different implementation, but i think the main motiviation was jquery behavior which has since changed |
| 20:36 | <jamesr_> | so i asked the jquery guys (paul) to experiment a bit and see if they had feedback |
| 20:36 | <heycam> | yeah, i didn't see explicit message from boris about being ok with it though |
| 20:36 | <jamesr_> | right |
| 20:37 | <jamesr_> | my hope is that paul can make a definitive statement at some point that jquery would be OK or not OK with this behavior |
| 20:37 | <jamesr_> | and then re-raise the issue on the list |
| 20:37 | <heycam> | ok |
| 20:37 | <heycam> | wrt the monotonic clock, I think everyone agrees to include it |
| 20:37 | <heycam> | not sure whether it should live in this spec or not |
| 20:37 | <jamesr_> | the other open issue is about the timestamp parameter. due to some implementation issues we haven't been able to experiment with that yet, so i don't have a concrete proposal to raise yet |
| 20:37 | <jamesr_> | right |
| 20:37 | <jamesr_> | we need to have a normative reference in some location TBD |
| 20:37 | <heycam> | yeah |
| 20:37 | <jamesr_> | i think tonyg might have wanted to raise that somewhere within WebPerf |
| 20:37 | <heycam> | when you say about the timestamp parameter, do you just mean whether that is also referring to a monotonic clock? |
| 20:37 | <jamesr_> | which woudl be fine with me |
| 20:37 | <jamesr_> | yes |
| 20:37 | <heycam> | i think there was the issue of whether the time there represents the next sample time, or the "current" time, or what |
| 20:37 | <heycam> | or whether that matters |
| 20:37 | <jamesr_> | ah yeah |
| 20:37 | <jamesr_> | or whether to provide multiple values |
| 20:37 | <jamesr_> | i think we want to be consistent with CSS animation APIs |
| 20:37 | <jamesr_> | once those exist |
| 20:37 | <heycam> | ok :) |
| 20:37 | <jamesr_> | but i don't think dino has a concrete proposal there yet |
| 20:37 | <jamesr_> | so it's hard to say |
| 20:37 | <jamesr_> | would rather try to get the script-based and CSS-based animation APIs in sync |
| 20:37 | <heycam> | that would be good |
| 20:37 | <heycam> | not sure if dean has made progress on a proposal |
| 20:38 | <heycam> | what do you think about the comment about worrying about 59Hz screens? |
| 20:38 | <heycam> | in response to the issue about a submillisecond clock |
| 20:38 | <jamesr_> | well 60hz doesn't map to an integer number of milliseconds |
| 20:38 | <jamesr_> | i'd prefer to use a submillisecond precision clock, which implies not using DOMTimeStamp |
| 20:38 | <jamesr_> | because DOMTimeStamp has to be integer milliseconds for legacy reasons |
| 20:43 | <heycam> | so a Number isn't sufficient resolution? |
| 20:43 | <jamesr_> | number is fine |
| 20:43 | <heycam> | ah ok |
| 20:43 | <heycam> | I didn't see anyone object to having submillisecond resolution |
| 20:43 | <heycam> | so let's just do that |
| 20:43 | <heycam> | being able to handle 59Hz exactly doesn't seem as important |
| 20:43 | <jamesr_> | yeah that's fine. milliseconds since when is the issue |
| 20:43 | <jamesr_> | since unix epoch has issues when the system clock is adjusted |
| 20:43 | <jamesr_> | which is why i'd prefer to use a timebase like user timing does |
| 20:43 | <heycam> | yes |
| 20:43 | <heycam> | i think document start time or whatever is fine, nobody objected to that in the end, i think |
| 20:43 | <heycam> | and the final issue is the element argument to raf |
| 20:43 | <heycam> | and I think you were just going to add that to the spec |
| 20:43 | <jamesr_> | well no |
| 20:43 | <heycam> | no? |
| 20:43 | <jamesr_> | we didn't agree on behavior |
| 20:43 | <heycam> | maybe i misread |
| 20:43 | <heycam> | ok |
| 20:43 | <jamesr_> | i dunno what to do there. boris and i thought it should do different things :) |
| 20:43 | <heycam> | then should we just leave it off for now? |
| 20:43 | <jamesr_> | yeah |
| 20:43 | <jamesr_> | leave the issue open, have no spec text |
| 20:43 | <heycam> | ok |
| 20:43 | <jamesr_> | which is what the current spec text does |
| 20:43 | <heycam> | yep |
| 20:43 | <heycam> | not a blocking issue then |
| 20:43 | <jamesr_> | has an editorial note referencing the issue but no normative text |
| 20:43 | <heycam> | ok cool. so i'll relay all this to the group. |
| 20:43 | <heycam> | not sure if you wanted to call in :) |
| 20:43 | <jamesr_> | don't think i'll be able to |
| 20:43 | <heycam> | ok |
| 20:43 | <jamesr_> | but i don't think any of the open issues can/should be resolved at the f2f, although if anyone comes up with proposals and posts them to the list i'd be happy to discuss there or make edits as appropriate |
| 20:43 | <jamesr_> | but mostly i think everything's waiting for some external action |
| 20:43 | <heycam> | yes ok |
| 20:44 | <heycam> | feel free to hang in irc on #webperf though |
| 20:44 | <jamesr_> | in channel - will try to check it |
| 20:44 | <jamesr_> | if you ping here i'll be more likely to see it |
| 20:45 | <heycam> | k |
| 21:48 | <heycam> | jamesr_, so it seems no minutes were taking during that session :) but I think people were ok with the current state of those issues in general, seems people were in favour of having a separate spec defining the monotonic clock for raf to reference |
| 21:48 | <heycam> | jamesr_, so i made sure no decisions were made, but the room had consensus. jatinder will mail to the list with what we discussed so that you and others can respond. |
| 21:49 | <jamesr_> | heycam, sounds good |
| 22:29 | <dglazkov> | mutation events are hard. |
| 22:29 | dglazkov | suggests shopping |
| 22:29 | <Ms2ger> | Or something Component Modelish? |
| 22:30 | <dglazkov> | :D |
| 23:01 | <roc> | Hixie: we need to make some changes to the spec for plugin instantiation for Web compatibility ... would you prefer a W3C bug or a WHATWG email? |
| 23:01 | <Hixie> | either's fine by me |
| 23:01 | <Hixie> | what's the change? |
| 23:02 | <roc> | we need to not instantiate display:none plugins, basically |
| 23:02 | <roc> | no browser does that, and doing it breaks the Web |
| 23:02 | <Hixie> | <embed>, <object>, and <applet>? |
| 23:02 | <roc> | I've only tested <embed> |
| 23:03 | <roc> | there are a details to be worked out |
| 23:03 | <Hixie> | send mail, sounds like it'll need discussion |
| 23:03 | <Hixie> | bug is better for quick things |
| 23:03 | <roc> | OK |
| 23:05 | <zcorpan> | roc: what broke? |
| 23:05 | <roc> | https://bugzilla.mozilla.org/show_bug.cgi?id=697651 |
| 23:11 | <jgraham> | Hmm, I thought we had changed some behaviour here recently, but maybe I am wrong |
| 23:12 | <roc> | Maybe you did, but I tested 11.52 |
| 23:13 | <Hixie> | jgraham: in the spec, or opera? |
| 23:13 | <Hixie> | i seem to recall this topic has been discussed before, but off-hand i can't remember what the exact discussion was |
| 23:14 | <zcorpan> | afaik opera hasn't changed its behavior around display:none plugins |
| 23:16 | <jgraham> | Oh, maybe we didn't change then :) I remember discussion about this case at least |
| 23:16 | <jgraham> | And web-compat concerns |
| 23:16 | <jgraham> | Hixie: In Opera |
| 23:17 | <jgraham> | (so possibly we dropped the ball around reporting a spec bug; if so I apologise) |
| 23:19 | <zcorpan> | i remember discussing it also, but we didn't have any new information as a basis to file a spec bug, iirc |
| 23:21 | <zcorpan> | so now we know of one site that breaks |
| 23:21 | <zcorpan> | and it's a google site? |
| 23:34 | <roc> | yeah |
| 23:34 | <roc> | note though, our patch that makes display:none plugins run hasn't even landed yet |
| 23:35 | <roc> | this is just something one of our developers found with the patch applied locally |
| 23:35 | <roc> | and given no browsers instantiate display:none plugins right now, I doubt we were lucky enough to find the only broken site |
| 23:36 | <zcorpan> | ah, ok |
| 23:47 | <jamesr_> | roc, webkit hasn't been capable of instantiating display:none plugins for a very long time |
| 23:47 | <jamesr_> | but i thought firefox was |
| 23:47 | <roc> | no |
| 23:47 | <roc> | we never have |
| 23:47 | <jamesr_> | ah ok. we'll keep not doing it then |
| 23:47 | <jamesr_> | easy enough |
| 23:47 | <jamesr_> | although it feels like a layering violation (style changes plugin loading?). compat > purity |
| 23:47 | <roc> | grrrrrrr my brain can't keep jamesr and jgraham separated |
| 23:47 | <rillian_> | if only they used nicks derived from their names :) |
| 23:49 | <roc> | jamesr: there is some weirdness, like if you make the element temporarily display:none and flush layout, that doesn't cause the plugin to be reinstantiated (on any browser) |
| 23:49 | <roc> | oh wait |
| 23:49 | <roc> | I didn't actually test that properly |
| 23:49 | <jamesr_> | yeah - if you set a classname on a parent but don't trigger a style recalc, then we won't know it's display:none |
| 23:49 | <jamesr_> | in webkit it depends on exactly how you set things |
| 23:50 | <jamesr_> | i think writing to style.display will immediately kill the plugin |
| 23:50 | <jamesr_> | but would have to test to be sure |
| 23:51 | <roc> | ugh |
| 23:52 | <jamesr_> | because of details of our style resolution process that should never be observable |
| 23:52 | <roc> | temporarily setting display:none and then flushing (and setting display:none back) reinstantiates the plugin in Firefox, Opera and Chrome |
| 23:52 | <roc> | that's deplorable |
| 23:52 | <roc> | that should just be fixed |
| 23:55 | <roc> | in fact just setting style.display to none and setting it back doesn't reinstantiate in Chrome |
| 23:59 | <gsnedders> | roc: It seems better that when layout is flushed isn't black-box observable from script. |