| 00:00 | <paul_irish_> | i will not disagree. |
| 00:00 | <paul_irish_> | AlexNRoss: the css validator team is looking for help maintaing the codebase to keep up with these changes, if you're interested |
| 00:01 | <AlexNRoss> | Sure. It is something I strive to do; keeping up to the latest in web initiatives and standardizations created by the browsers. |
| 00:02 | <Hixie> | AlexNRoss: it's supposed to be irritable. The whole point of vendor prefixes is to irritate authors so that they won't use them except when experimenting to give feedback to the working group and browser vendors. |
| 00:02 | <paul_irish_> | AlexNRoss: http://lists.w3.org/Archives/Public/www-validator-css/ shoot a message onto this list and ask if anything could be done and how you could help |
| 00:15 | <zewt> | Hixie: that's ... just silly, heh |
| 00:15 | <Hixie> | what's silly? |
| 00:16 | <zewt> | annoying people isn't going to stop them from using the APIs; it'll just annoy them |
| 00:16 | <AlexNRoss> | paul: I just e-mailed. |
| 00:16 | <paul_irish_> | :) |
| 00:16 | <Hixie> | zewt: how can we stop them from using the apis? |
| 00:16 | <AryehGregor> | It's already annoying enough that you have to write the same markup four times to get it to work in all browsers. |
| 00:16 | <zewt> | i've always seen the api prefixes as just to localize any dependancies on early behavior to that prefix and that vendor, so they don't have to affect the final API |
| 00:16 | <AryehGregor> | No more annoyance than that is necessary. :) |
| 00:16 | <zewt> | ... you can't, of course |
| 00:16 | <AryehGregor> | Hixie, if you want to stop them from using the APIs, then don't implement them. |
| 00:16 | <AryehGregor> | Easy. |
| 00:16 | <Hixie> | AryehGregor: we need to implement them to get implementation experience |
| 00:16 | <AryehGregor> | Then don't enable them. |
| 00:16 | <zewt> | i was annoyed when WebKit prefixed (iirc) the URL interface when it was previously unprefixed, but the only affect was to make me grumble for a minute and then update my code |
| 00:17 | <AryehGregor> | Now, if you want *authoring* experience too, well, you want people using them. |
| 00:17 | <Hixie> | AryehGregor: we need to enable them to get authoring experience |
| 00:17 | <AryehGregor> | Okay, so then you do want people using them. |
| 00:17 | <AryehGregor> | Presumably on production sites, so they get real-world experience. |
| 00:17 | <Hixie> | to a small extent |
| 00:17 | <AryehGregor> | To a large extent, because no matter what, only a tiny percentage of authors will provide any feedback. |
| 00:17 | <Hixie> | but they're still proprietary technologies, so we don't want them used like regular features |
| 00:17 | <zewt> | (as an addendum to the above--another point being as a clear declaration to authors that the API is unstable) |
| 00:17 | <Hixie> | anyway i'm not sure what we're arguing ehre :-) |
| 00:18 | <AryehGregor> | Anything that works will be used like a regular feature. |
| 00:18 | <AryehGregor> | If it doesn't work, it won't be used and you won't get authoring feedback. |
| 00:18 | <AryehGregor> | Take your pick. |
| 00:18 | <Hixie> | i'm happy with the current situation |
| 00:18 | <AryehGregor> | In practice authors use them and it works out fine, as long as the prefix gets dropped reasonably soon. |
| 00:19 | <AryehGregor> | (you know, unlike border-radius) |
| 00:19 | <Hixie> | border-radius is mainly funny because it's taken so long that the trend for rounded corners has kinda passed already :-) |
| 00:19 | <The_8472> | sometimes it would be nice if feature-detection would be easier. e.g. if i have to apply some custome javascript magic for <meter> elements or if the browser already styles it for me. things like that |
| 00:20 | <Hixie> | yeah that's a harder problem without js |
| 00:20 | <The_8472> | need js to style the meter element atm. since i can't use attr() inside calc() |
| 00:21 | <The_8472> | the progress bar look has to depend on the min/max/value attributes after all |
| 00:22 | <Hixie> | if you have js it's pretty easy to just stick a class on the elements that need styling |
| 00:22 | <The_8472> | yeah |
| 00:22 | <The_8472> | but you need to figure out if the browser doesn't do it already for you |
| 00:23 | <The_8472> | or think of input[type=number] ... do i add a spinner manually or does the browser already provide one? |
| 00:25 | <The_8472> | modernizr helps with most things though |
| 00:34 | <heycam> | jwalden, I'm told the w3.org/Bugs/ access is fixed now |
| 00:34 | <heycam> | jwalden, something to do with their preparations for world ipv6 day -- from the mozilla network is was connecting via ipv6 |
| 00:35 | <jwalden> | heh |
| 00:36 | jwalden | is not quite certain that making a spec change that suddenly declares common wordpress templates not-valid is a good idea, but meh |
| 00:36 | <jwalden> | I can probably update my templates in about five minutes to remove it, if I feel motivated |
| 00:42 | <AryehGregor> | Aren't lots of the common Wordpress templates invalid anyway? |
| 00:43 | <Hixie> | heycam: oh that makes sense, google's network is also ipv6 |
| 00:44 | <The_8472> | still 11 minutes to v6 day |
| 00:45 | <Hixie> | oh wow that's today? |
| 00:45 | <Hixie> | i had no idea |
| 00:45 | AryehGregor | watches the process argument between othermaciej and Roy T. Fielding with interest |
| 00:45 | <AryehGregor> | Aw, I'm going to miss the start of IPv6 day by a matter of minutes. Oh well, no helping it. |
| 00:46 | <othermaciej> | AryehGregor: I'm gonna have to duck out cause I can only spend so much time in email during WWDC |
| 00:47 | <jwalden> | AryehGregor: plausible |
| 00:48 | jwalden | knows he's barely touched his as far as validity's concerned in ages |
| 00:48 | <jwalden> | had to fiddle with a [caption] shortcode I implemented to wrap up figure/figcaption, but I was well aware I was on the bleeding edge doing that |
| 00:48 | <jwalden> | which was figure/legend when I first wrote it |
| 04:01 | [tm] | waves from Beijing |
| 07:23 | <hsivonen> | Hixie: I notice that the microdata vocabularies use microformats.org URLs. What kind of Microformat community participation was there when formulating the Microdata versions of the vocabs? |
| 08:38 | <Akilo> | héhé |
| 08:38 | Akilo | from atelier cym |
| 08:38 | Akilo | impressioné par la déco ;) |
| 11:10 | <jgraham> | gsnedders: You there? |
| 11:54 | <kost-bebix> | Hi everyone! Hope someone will help me) https://groups.google.com/forum/#!topic/html5lib-discuss/MOvXMzQRMzE |
| 11:59 | <Workshiva> | Keep in mind that this makes you vulnerable if there's a redirection servlet on youtube.com |
| 12:07 | <jgraham> | kost-bebix: Umm, I would probably have to look over the sanitizer code a bit to help you, which I don't really have time to do right this moment |
| 12:08 | <kost-bebix> | Workshiva: no, in future (if that would work) I'd just take by [a-zA-Z0-9] regexp youtube video ID and build <iframe> "from scratch" |
| 12:09 | <kost-bebix> | jgraham: it's not sanitizer. I mean, sanitizer works like it should. It returns this token for youtube one and "data" token (where iframe is a text) as text one |
| 12:09 | <kost-bebix> | jgraham: it's serializer, i guess |
| 12:10 | <jgraham> | kost-bebix: I think you need to allow the first </iframe> you see after the <iframe> you allow |
| 12:11 | <jgraham> | It does look like there might be another bug in the serializer, but that should fix the issue for you |
| 12:11 | <kost-bebix> | jgraham: i did that, don't remember what was the result, but still, will that be safe? I mean, if there won't be any closing tag or something? |
| 12:12 | kost-bebix | went doing that first iframe thing |
| 12:13 | <jgraham> | Well it's a bit hard. If something else already closed the iframe you could end up with a stray </iframe>. But I don't think that should be harmful unless you are outputting this inside another iframe |
| 12:13 | <kost-bebix> | or some content inside that iframe |
| 12:14 | <jgraham> | Anyway, what you have there can't work |
| 12:19 | <kost-bebix> | http://paste.pocoo.org/show/402719/ |
| 12:20 | <kost-bebix> | ok, I'll just put some extra testing on that in next couple minutes |
| 12:27 | <danbri> | hsivonen, thanks for writing up http://hsivonen.iki.fi/schema-org-and-communities/ :) |
| 12:27 | <danbri> | can't say I entirely agree on all points, but it's good to have your perspective there so clearly |
| 12:27 | <hsivonen> | danbri: you're welcome |
| 12:28 | <danbri> | (for example, after FB launched opengraph with their own made-up vocab, loads of rdf folk were quite bothered by that too, ... and by 'pedantic web' issues such as that the OG properties were technically written in rdfa to make them properties of the page, ... not the thing-that-the-page-describes... |
| 12:29 | <danbri> | but fortunately a lot of that energy got channeled into collab w/ fb folk on mappings etc, rather than ranting about corporate evil |
| 12:29 | <hsivonen> | danbri: there might be a big difference between long-time RDF folks and RDFa folks who are eager to see adoption of RDFa |
| 12:29 | <danbri> | you're quite right of course that if schema.org were using rdfa, ... it would be being celebrated by rdf folk more heavily now. Still it's been welcomed by a bunch of us... |
| 12:29 | <danbri> | yeah maybe |
| 12:30 | <danbri> | i wouldn't mind if schema.org used microdata, i just use toby inkster's parser and treat it as rdf ... |
| 12:30 | <danbri> | ... but it does bug me that they say 'don't use microformats or rdfa' |
| 12:30 | <danbri> | googlebing can probably afford to parse both |
| 12:31 | danbri | wonders how small the design gap between microdata and 1.1 flavour of rdfa really is |
| 12:31 | <danbri> | the example in http://schema.org/docs/datamodel.html is encouraging |
| 12:31 | <hsivonen> | danbri: the gap is probably rather small for RDFa 1.1 with certain syntax options |
| 12:32 | <hsivonen> | as I said in the blog post, part of the problem with RDFa are the rest of the syntax options |
| 12:32 | <hsivonen> | danbri: the data model gap is large |
| 12:32 | <danbri> | do you have a feel for a what an 'rdfa1.1-lite' microdata-esque profile might look like? |
| 12:33 | <kost-bebix> | jgraham: thanks for your help anyway) |
| 12:33 | <danbri> | data model: 'cos properties are bundled with types in microdata? |
| 12:33 | <hsivonen> | danbri: it would be awesome if googlebing could afford to write down how to consume microformats and stuff claimed to be RDFa but that isn't :-) |
| 12:33 | <hsivonen> | danbri: tree vs. graph |
| 12:33 | <hsivonen> | danbri: I don't have a good feel about the looks of a profile |
| 12:34 | <danbri> | when properties in the tree have URI values, ... different trees that mention the same things can be joined / aggregated to form a graph ... that's enough for me |
| 12:38 | <danbri> | is http://www.whatwg.org/specs/web-apps/current-work/multipage/links.html#microdata the latest, greatest version of the microdata spec? |
| 12:38 | <hsivonen> | danbri: yes |
| 12:39 | <danbri> | from that link ... 'Properties can also have values that are URLs' seems enough to make graphs |
| 12:39 | danbri | assumes relative URIs are allowed, which should help verbosity |
| 12:40 | <hsivonen> | danbri: there URLs are Web addresses. they aren't the abstract kind of URLs that occur as RDF predicates |
| 12:40 | <hsivonen> | danbri: or RDF objects |
| 12:41 | <hsivonen> | in Microdata, an item is more like a bnode and a URL can be be one of its properties |
| 12:41 | <hsivonen> | danbri: like in the licensing case, the URL of the work is a property of the item |
| 12:41 | <danbri> | yup |
| 12:42 | <hsivonen> | instead of the item itself being the URL |
| 12:42 | <danbri> | this reminds me of the old Microsoft SOAP graph data model; it doesn't privilege URI identifiers as special node labels; if you want 'em, you have to put them in as properties explicitly |
| 12:42 | <danbri> | just like any other data |
| 12:42 | <danbri> | benefit there is you can more easily have two urls (uris, ahem whatever) for same entity |
| 12:43 | <danbri> | http://schema.org/docs/gs.html Here is the book's <a itemprop="url" href="http://en.wikipedia.org/wiki/The_Catcher_in_the_Rye">Wikipedia page</a>. ... so that's ok |
| 12:43 | <danbri> | and if another part of the page had 'Dan's favourite book is <a itemprop="faveBook" href="http://en.wikipedia.org/wiki/The_Catcher_in_the_Rye">Catcher in the Rye</a>. ' |
| 12:44 | <danbri> | ...the nodes would join, but the descriptions would be in terms of pages about the book, not some more abstract "identifier for the book itself". right? |
| 12:44 | <danbri> | so it's a graph but a graph that encourages the nodes to be modelled as Web pages not real-world-things |
| 12:50 | <hsivonen> | danbri: in the Microdata model, the nodes wouldn't join |
| 12:50 | <hsivonen> | danbri: mapped to RDF, I suppose they would |
| 12:50 | <danbri> | that sounds reasonable |
| 12:50 | <danbri> | an editor built over a document DOM wouldn't want them joined; but a query answering system might |
| 12:53 | <danbri> | btw this Perl works to parse and query schema.org's schema as rdf: https://gist.github.com/1012713 |
| 12:53 | <danbri> | ...with a bit more fiddling -> http://foaf.tv/tellyclub/schema.org/protovis-3.2/ex/den3.html (ok unreadable, but a start on visualizing the chaos) |
| 12:58 | <hsivonen> | it will be interesting to see how the taxonomy of everything (down to BowlingAlley and TattooParlor) works out |
| 12:59 | <danbri> | the sooner they bridge it to wikipedia/dbpedia or freebase the saner it'll be |
| 12:59 | <danbri> | that was one reason i tried the radial visualization ... to show an outer layer from those sources, when the mappings come thru |
| 12:59 | <danbri> | hmm reading spec, ... is itemscope always needed? does presence of an itemtype imply a new scope? |
| 13:01 | <hsivonen> | danbri: afaict, it's not implied |
| 13:01 | <hsivonen> | that may have something to do with the usability test |
| 13:01 | <danbri> | 'The relevant type for a typed item is the item's item type, if it has one, or else is the relevant type of the item for which it is a property's value.' --> say that 3 times fast after a couple of drinks :) |
| 13:04 | <danbri> | ah 'The itemtype attribute must not be specified on elements that do not have an itemscope attribute specified.', ... seems itemscope is needed then, yup. |
| 13:06 | danbri | notices that properties are partially ordered (same-name properties remember their order); again something that wouldn't pass into the rdf representation... guess that's ok? |
| 13:06 | <Workshiva> | hsivonen: Are you interested in editorial bugs in your schema.org text? |
| 13:07 | <hsivonen> | Workshiva: yes |
| 13:17 | <Workshiva> | People sure like confusing microdata and the schema.org vocabulary with each other |
| 13:21 | <hsivonen> | Workshiva: did I? |
| 13:21 | <Workshiva> | No, other people did |
| 13:23 | danbri | sends whatwg mail re microdata data model |
| 13:41 | <MikeSmith> | anybody know where the editors draft of http://www.w3.org/TR/animation-timing/ is at? |
| 13:41 | <MikeSmith> | heycam: ↑ |
| 13:47 | <karlcow> | MikeSmith: http://dvcs.w3.org/hg/webperf/ ? |
| 13:48 | <karlcow> | http://dvcs.w3.org/hg/webperf/file/8bf49567d58d/specs/NavigationTiming |
| 13:49 | <MikeSmith> | karlcow: yup |
| 13:49 | <MikeSmith> | thanks |
| 13:49 | <MikeSmith> | http://dvcs.w3.org/hg/webperf/raw-file/tip/specs/RequestAnimationFrame/Overview.html |
| 13:49 | <karlcow> | http://dvcs.w3.org/hg/webperf/file/tip/specs/NavigationTiming/Overview.html |
| 13:50 | <karlcow> | :) |
| 13:50 | <karlcow> | my inner brain search engine |
| 13:50 | <karlcow> | :p |
| 13:55 | <gsnedders> | jgraham: am now |
| 14:00 | <MikeSmith> | reading "if the Sponsors have patent claims that are necessarily infringed by including markup of structured data in a webpage, where the markup is based on and strictly complies with the Schema, they grant an option to receive a license under reasonable and non-discriminatory terms without royalty" |
| 14:01 | <MikeSmith> | and then, "solely for the purpose of including markup of structured data in a webpage, where the markup is based on and strictly complies with the Schema" |
| 14:01 | <MikeSmith> | does that mean if I build schema.org vocab support into a product -- e.g., an editing application -- that I don't necessarily get granted a royalty-free license? |
| 14:02 | <MikeSmith> | that is, I only get granted a royalty-free license if I am the published of the content that contains the markup? |
| 14:03 | <MikeSmith> | and incidentally, what does "receive a license under reasonable and non-discriminatory terms without royalty" mean? |
| 14:03 | <MikeSmith> | isn't that an oxymoron? |
| 14:03 | <MikeSmith> | why not just say, "receive a royalty-free license"? |
| 14:04 | <Philip`> | You could have unreasonable terms that don't require a royalty but do require something else |
| 14:04 | <kost-bebix> | when you make iframe acceptable everything inside becomes allowed? Please help https://groups.google.com/forum/#!topic/html5lib-discuss/X5UY6JITmJU |
| 14:05 | <MikeSmith> | Philip`: OK |
| 14:05 | Philip` | is just guessing, though |
| 14:06 | <MikeSmith> | I don't think I've ever seen the words "reasonable and non-discriminatory" used in any royalty-free license statement |
| 14:08 | <Philip`> | http://en.wikipedia.org/wiki/Reasonable_and_non-discriminatory_licensing says "The RAND-Z (RAND with zero royalty) or RAND-RF (RAND Royalty Free) licensing means that the company promises to license the technology at no charge, but implementers still have to get the licenser's permission to implement." |
| 14:10 | <Philip`> | kost-bebix: Anything inside <iframe> is parsed as text, not as markup, so <iframe><script>... means an iframe element containing the text "<script>" |
| 14:11 | <karlcow> | it is a question of respiration… everything will go through at one point. |
| 14:12 | <kost-bebix> | Philip`: oh, so that should be safe? |
| 14:12 | Philip` | has absolutely no idea what karlcow is talking about |
| 14:12 | <karlcow> | rand license |
| 14:12 | <kost-bebix> | Philip`: oh, sorry, that can't be safe)) |
| 14:13 | <Philip`> | kost-bebix: It's safe since it'll never create a script element (unless you accidentally parse the document as XHTML instead of as text/html) |
| 14:14 | <kost-bebix> | Philip`: so this code is ok? https://groups.google.com/forum/#!topic/html5lib-discuss/MOvXMzQRMzE |
| 14:14 | <kost-bebix> | Philip`: if I'll return not just token, but some safe <iframe> structure? |
| 14:18 | <jgraham> | If it creates </iframe> inside the iframe without escaping that is a bug |
| 14:20 | <kost-bebix> | jgraham: thanks for tip. So I should just close next /iframe I see and everything should be (at least now) safe and bugless? |
| 14:21 | <Philip`> | Is it actually possible to escape the text "</iframe>" in an iframe? |
| 14:22 | <Philip`> | It seems to be RAWTEXT so I don't think you can |
| 14:22 | <Philip`> | Also the point of the fallback content is to be for browsers that don't support iframe, and it's not much good if your sanitizer produces content that falls back to something dangerous in such browsers |
| 14:22 | <kost-bebix> | Philip`: I think it should be just stripped out maybe? Or spec says it should be there? |
| 14:24 | <kost-bebix> | Philip`: all I need is a sanitizer that doesn't strip out <iframe>'s that have src="http://www.youtube.com... . I thought that's quite popular problem) |
| 14:24 | <Philip`> | I expect the safer thing to do is for the sanitizer to maintain some "is currently in iframe" flag, which is set when you accept a YouTube iframe start token; then if you see an iframe end token while that flag is set, you accept the token and reset the flag; and if you see anything else while that flag is set (including text tokens) you reject them |
| 14:25 | <kost-bebix> | Philip`: yeah, that's what I did and that seems to work |
| 14:25 | <kost-bebix> | Philip`: I was just looking at that <script> inside <iframe> that wasn't escaped anymore |
| 14:25 | <kost-bebix> | and thought that's a bug and insecure |
| 14:26 | <Philip`> | Explicitly dropping the fallback content inside the iframe element seems the best way to be secure here |
| 14:26 | <jgraham> | I think the important point is to reject anything other than </iframe> tokens once you see an iframe you want to accept |
| 14:26 | <Philip`> | rather than relying on escaping |
| 14:26 | <kost-bebix> | jgraham: good point, i'll do that) |
| 14:30 | <kost-bebix> | works like a charm http://paste.pocoo.org/show/402771/ |
| 14:30 | <kost-bebix> | thank you everyone )) |
| 14:31 | <Philip`> | You should probably just make next_iframe_safe a field of the HTMLSanitizerMixin class |
| 14:32 | <kost-bebix> | Philip`: maybe. At that time I didn't know how instance of that is created. Thanks. |
| 14:32 | <Philip`> | especially since it won't get reset to False if you parse a document that omits the </iframe> |
| 14:32 | <kost-bebix> | oh, yeah, that's true |
| 14:41 | <kost-bebix> | class HTMLTokenizer should be newstyle class |
| 14:44 | <kost-bebix> | and do super(HTMLTokenizer, self).__init__() |
| 14:44 | <gsnedders> | kost-bebix: It's slower. |
| 14:44 | <foolip> | Philip`, <video> is still in the iframe section: http://www.whatwg.org/specs/web-apps/current-work/multipage/the-iframe-element.html#the-video-element |
| 14:44 | <foolip> | I like this kind of BTS :) |
| 14:45 | <kost-bebix> | gsnedders: but thanks to that I can't make my sanitizer mixin's __init__() that does self.next_iframe_safe = False |
| 14:45 | <kost-bebix> | gsnedders: if you use multiple inheritance you should use newstyle classes |
| 14:46 | <kost-bebix> | otherwise your constructor won't be called) |
| 14:46 | <gsnedders> | kost-bebix: Blame Philip` :) |
| 14:46 | <Philip`> | Why me? :-( |
| 14:47 | <kost-bebix> | Philip`: so what about adding that? (1. making HTMLTokenizer new-style 2. calling super(HTMLTokenizer, self).__init__()) ? |
| 14:47 | <gsnedders> | Philip`: Didn't you change it to being an old-style class? |
| 14:47 | <Philip`> | gsnedders: How should I remember something like that? :-p |
| 14:48 | <kost-bebix> | gsnedders: where can I read about slowness? |
| 14:49 | <kost-bebix> | and please someone tell me should I search for that or it will always be old style class? |
| 14:49 | <kost-bebix> | ) |
| 14:49 | <Philip`> | http://code.google.com/p/html5lib/source/detail?r=decbf3278e3b197865b76fc30860b3a88c618813&path=/python/src/html5lib/inputstream.py |
| 14:49 | <Philip`> | Oh, it was me |
| 14:50 | <kost-bebix> | > (It seems unlikely that anyone will be depending on the new-style class |
| 14:50 | <kost-bebix> | semantics here.) |
| 14:50 | <kost-bebix> | haha) |
| 14:51 | <gsnedders> | kost-bebix: It was done by Philip` benchmarking it with the HTML5 spec, I believe. :P |
| 14:52 | <kost-bebix> | ok, I'll just try to do that withoug mixining (multiple inheritance) somehow, or something else |
| 14:53 | <gsnedders> | kost-bebix: You can see how big the perf difference is. If it's not too big, I have no objection to changes it back. |
| 14:53 | <kost-bebix> | found the dirty solution: write __init__ that sets |
| 14:53 | <kost-bebix> | self.next_iframe_safe = False |
| 14:53 | <kost-bebix> | for HTMLSanitizer, do the rest in Mixin |
| 14:53 | <kost-bebix> | gsnedders: yeah, that's big (10-15%) for parser like this |
| 14:54 | <Philip`> | Maybe newer Pythons are faster and have less of a difference |
| 14:54 | Philip` | has no idea what affects the performance |
| 14:54 | <jgraham> | Maybe PyPy is the future! |
| 14:54 | <Philip`> | Hasn't it been the future since about a decade ago? |
| 14:54 | <kost-bebix> | it's like a year of linux on desktop |
| 14:54 | <jgraham> | Yeah, but now it seems to actually work, which is nice. |
| 14:54 | Philip` | wonders if it's actually usable for real yet |
| 14:55 | <jgraham> | I should try it I guess |
| 14:55 | <gsnedders> | PyPy JIT makes html5lib quick, at least |
| 14:55 | <kost-bebix> | ok, here's the resulting code http://paste.pocoo.org/show/402784/ |
| 14:55 | <kost-bebix> | yeah, pypy is nice, my home projects run on that |
| 14:55 | <kost-bebix> | (still it's slow for things like intensive work with mongodb, since there's BSON encoder written in C) |
| 14:56 | <kost-bebix> | thank you everyone again |
| 14:59 | <Workshiva> | 2011 really is the year of linux on the desktop, now that it runs in the browser |
| 14:59 | <gsnedders> | Workshiva: (on little endian arches) |
| 15:01 | <Philip`> | (How many big-endian desktops are there?) |
| 15:01 | <gsnedders> | Philip`: (Mostly old Macs, I guess) |
| 15:02 | <Philip`> | (Do any modern browsers still support old Macs?) |
| 15:08 | <kost-bebix> | Philip`: only firefox 3.6, but maybe 5.0 will be |
| 15:13 | <kost-bebix> | gsnedders: have you tried using __slots__ in that test? |
| 15:13 | <kost-bebix> | or that doesn't help? |
| 15:25 | <danbri> | foolip, http://foolip.org/microdatajs/ http://foolip.org/microdatajs/live/ is handy! care to put some opensource license statement on the code? |
| 15:25 | <gsnedders> | kost-bebix: For perf? I haven't at least. |
| 15:26 | <kost-bebix> | gsnedders: yeah, for perf |
| 15:26 | <kost-bebix> | i don't remember what happens to inheritance with __slots__ (need to read), but it should be faster |
| 15:26 | <foolip> | danbri, https://gitorious.org/microdatajs/microdatajs/blobs/master/LICENSE |
| 15:27 | <gsnedders> | kost-bebix: Feel free to test/create bug with patch |
| 15:27 | <foolip> | perhaps a link from the demo to the git repo would be in order... |
| 15:27 | <kost-bebix> | gsnedders: is it somewhere in source repository? |
| 15:27 | <gsnedders> | kost-bebix: On Google Code |
| 15:27 | <danbri> | thanks foolip! |
| 15:27 | <kost-bebix> | gsnedders: ok, thanks. I'll do my best |
| 15:27 | <danbri> | yes please |
| 15:27 | <danbri> | do you consider it up-to-date re latest whatwg spec? |
| 15:28 | <foolip> | mostly, yes |
| 15:28 | <foolip> | I've deliberately not implemented the logic the spec suggests for eliminating itemref loops, because I don't think it makes sense |
| 15:28 | <foolip> | and the guy implementing it natively in Opera sent out feedback on that topic today, so it's likely to change again |
| 15:29 | <danbri> | do you implement property value order preservation? |
| 15:30 | <danbri> | -> http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-June/031959.html ""Within an item, the properties are unordered with respect to each other"" |
| 15:31 | <foolip> | danbri, yes, they will be in tree-order because that's the order the algorithm crawls |
| 15:31 | <danbri> | ok, so you don't respect itemref there either? |
| 15:31 | <foolip> | itemref is followed and tree order is preserved even then |
| 15:31 | <foolip> | the only thing about itemref is when you have loops (which is invalid) |
| 15:32 | <foolip> | the spec suggests one complicated way of ensuring that they aren't exposed to the API, and I've implemented another, which is probably different in minute ways |
| 15:32 | <foolip> | unless you plan to write invalid markup with itemref loops, I wouldn't worry about it |
| 15:32 | <danbri> | in 5.2.3 Names: the itemprop attribute the 4th example, ... you get ', the "a" property has the values "1" and "2"' ? |
| 15:32 | <zcorpan> | http://remysharp.com/2011/06/08/link-elements-block-dom-parsing-too/ - i'm pretty sure no browser blocks parsing for <link>, but how to prove it with black-box testing? |
| 15:33 | <danbri> | i'm curious how much meaning publishers will expose thru this ordering mechanism, eg. a list of authors ranked by importance... |
| 15:33 | <foolip> | danbri, try pasting it into http://foolip.org/microdatajs/ and look at the JSON view |
| 15:33 | <zcorpan> | apparently DOMContentLoaded/readyState waits for the stylesheet |
| 15:33 | <foolip> | (or give me a direct link to the example :) |
| 15:34 | danbri | finds closest anchor - > http://www.whatwg.org/specs/web-apps/current-work/multipage/links.html#names:-the-itemprop-attribute |
| 15:34 | jgraham | should try to follow the loops duscussion |
| 15:34 | <jgraham> | *discussion |
| 15:34 | <danbri> | ok it fails |
| 15:34 | <jgraham> | Presumably it is a requirement to be able to say that A is a friend of B and B is a friend of A |
| 15:35 | <foolip> | danbri, did you find a bug? |
| 15:35 | <danbri> | i think so... how does https://gist.github.com/1014546 seem to you? |
| 15:35 | <danbri> | ...you're supposed to go chasing the reference first, it seems |
| 15:36 | <foolip> | I think the example is wrong |
| 15:36 | <foolip> | or I have not understood the crawling algorithm |
| 15:37 | <danbri> | could you check opera's internal impl too? |
| 15:37 | <foolip> | I'm not involved with that, but I can ask that they check this example |
| 15:37 | <danbri> | thanks |
| 15:38 | <foolip> | in http://www.whatwg.org/specs/web-apps/current-work/multipage/links.html#crawl-the-properties you'll see that step 6 is "Sort results in tree order." |
| 15:38 | <foolip> | I'll also file a spec bug then |
| 15:40 | <danbri> | can you post a link here when you do? |
| 15:42 | <foolip> | yes |
| 15:47 | <foolip> | danbri, http://www.w3.org/Bugs/Public/show_bug.cgi?id=12911 |
| 15:47 | <danbri> | thanks :) |
| 15:48 | <kost-bebix> | I don't get it. I do hg clone https://html5lib.googlecode.com/hg/ html5lib , and in your file there's no parser= attr http://code.google.com/p/html5lib/source/browse/python/src/html5lib/html5parser.py?r=decbf3278e3b197865b76fc30860b3a88c618813#87 , but in mine there is one (and tests fail). |
| 15:48 | <kost-bebix> | Branch is default. |
| 15:51 | <jgraham> | kost-bebix: You have latest tip? |
| 15:51 | <kost-bebix> | jgraham: 1702:7d147d0cb759 |
| 15:51 | <kost-bebix> | hg log -l 1 shows me latest one |
| 15:51 | <kost-bebix> | (changeset) |
| 15:51 | <kost-bebix> | that's strange |
| 15:56 | <kost-bebix> | jgraham: oh, sorry, I think I looked at older file at google code (didn't use google code to view sources before) |
| 16:01 | <kost-bebix> | ok, so still, I run html5lib/tests/test_sanitizer.py and it gives me a bit bunch of errors like this http://paste.pocoo.org/show/402835/ |
| 16:01 | <kost-bebix> | am I doing something wrong or is it broken? |
| 16:03 | <kost-bebix> | self.tokenizer_class is html5lib.sanitizer.HTMLSanitizer at that point of failure |
| 16:04 | <kost-bebix> | and it really doesn't take any parser argument) |
| 16:04 | <jgraham> | It is quite possible that test has bitrotted |
| 16:06 | <gsnedders> | Almost certainly I broke it, I expect |
| 16:06 | <gsnedders> | If it wasn't broken before, that is :P |
| 16:07 | <kost-bebix> | oh, I ran that test by mistake) |
| 16:07 | <kost-bebix> | what I needed is test_tokenizer.py as I understand |
| 16:07 | <kost-bebix> | :-D |
| 16:09 | <kost-bebix> | on new-style HTMLTokenizer tests run about the same time |
| 16:09 | <gsnedders> | kost-bebix: They're not going to show the cost difference, really. Try tokenizing the spec. |
| 16:10 | <kost-bebix> | gsnedders: sorry, tokenizing the spec? |
| 16:10 | <gsnedders> | kost-bebix: As in the HTML5 spec |
| 16:11 | <kost-bebix> | gsnedders: you mean like take super-big html page and parse it 100 times and count how fast was that? |
| 16:11 | <gsnedders> | kost-bebix: Parse it once. It takes long enough. :) |
| 16:11 | <kost-bebix> | gsnedders: ok) |
| 16:12 | <gsnedders> | Now, go annoy other people, seeming I'm heading out into town. (And no, you're not actually annoying.) |
| 16:16 | <foolip> | danbri, license and link now added to http://foolip.org/microdatajs/live/ (and some other minor fixes committed) |
| 16:16 | <danbri> | great, thanks! |
| 16:17 | danbri | hopes jenit might integrate it with rdfquery js library |
| 16:17 | <jgraham> | gsnedders: You were supposed to be code reviewing for me dammit! |
| 16:26 | <kost-bebix> | oh, so it looks like it's really-really broken now) not just tests |
| 16:31 | <kost-bebix> | I've updated to tag 0.90 and there isn't even __init__.py there. hmm.. |
| 16:37 | <jgraham> | I wouldn't look at 0.9 or anything other than tip |
| 16:40 | <kost-bebix> | real 0m41.488s |
| 16:40 | <kost-bebix> | user 0m40.560s |
| 16:40 | <kost-bebix> | sys 0m0.590s |
| 16:40 | <kost-bebix> | real 0m39.232s |
| 16:40 | <kost-bebix> | user 0m37.820s |
| 16:40 | <kost-bebix> | sys 0m0.800s |
| 16:40 | <kost-bebix> | maybe I did something wrong |
| 16:41 | <kost-bebix> | but new-style classes seem faster |
| 16:43 | <kost-bebix> | no, looks like it's all correct |
| 16:43 | <kost-bebix> | code: http://paste.pocoo.org/show/402862/ |
| 16:44 | <kost-bebix> | file: |
| 16:44 | <kost-bebix> | http://www.whatwg.org/specs/web-apps/current-work/ |
| 16:46 | <kost-bebix> | hmm |
| 16:46 | <kost-bebix> | pypy |
| 16:46 | <kost-bebix> | real 0m38.438s |
| 16:46 | <kost-bebix> | user 0m37.590s |
| 16:46 | <kost-bebix> | sys 0m0.350s |
| 16:46 | <kost-bebix> | I definitely do something wrong |
| 16:46 | <kost-bebix> | anyway |
| 16:46 | <kost-bebix> | see you tomorrow, maybe we'll discuss it) |
| 16:46 | <kost-bebix> | thanks for help |
| 17:35 | <gsnedders> | jgraham: I'm sorry, but I like food. |
| 18:50 | <asmodai> | Mmm, the 3DS' browser scores 101 on the html5test.com site |
| 18:51 | <Ms2ger> | What a broken site that is, too |
| 18:54 | <asmodai> | In what sense? |
| 18:55 | <gsnedders> | asmodai: The points given to things is random, it tests things not in HTML5 (e.g., H.264 support) |
| 18:55 | <asmodai> | Ah |
| 18:55 | <asmodai> | Mmm, oh, the 3DS browser's built on NetFront |
| 18:56 | <gsnedders> | WTF? |
| 18:56 | <gsnedders> | And it does that well? |
| 18:56 | <asmodai> | *chuckle* |
| 18:56 | <asmodai> | Well enough it seems |
| 18:56 | <gsnedders> | asmodai: Try running the jQuery testsuite in it. |
| 18:56 | <jgraham> | gsnedders: I thought netfront used webkit these days |
| 18:57 | <Ms2ger> | Also, promotes the broken kind of implementations webkit usually ships |
| 18:57 | <asmodai> | gsnedders: http://view.jquery.com/tags/1.3.2/test/ ? |
| 18:57 | <gsnedders> | jgraham: They have two browsers. |
| 18:57 | <jgraham> | gsnedders: Also, to be fair, (I don't plan to make a habit of it, don't worry) it lists H.264 as a bonus point |
| 18:57 | <gsnedders> | jgraham: One of which uses WebKit, this is true. |
| 18:58 | <gsnedders> | jgraham: Their own is still diabolical (myself and Tarquin were playing around with this a couple of months back). |
| 18:58 | <gsnedders> | asmodai: Go for 1.6 |
| 18:58 | <gsnedders> | Ms2ger: Yeah, it generally screws around with browser prioritization. Yay marketing… |
| 18:59 | <asmodai> | Ah duh, of course |
| 18:59 | <jgraham> | The main problem with html5test.com is that the tests are extremely shallow so favour crappy implementations over honesty, and the scoring system is exhibit A in the case against ranking browsers based on test scores |
| 18:59 | <jgraham> | s/is/are/ |
| 18:59 | <jgraham> | s/problem/problems/ |
| 19:00 | <jgraham> | (the points-per-feature aren't correlated to dificulty of implementation or usefulness to authors or, as far as I can tell, much of anything at all) |
| 19:04 | <asmodai> | gsnedders: Trying to locate the 1.6 test suite :S |
| 19:08 | <asmodai> | http://jquery.bassistance.de/validate/test/?jquery=1.6.1 <-- this one? |
| 19:11 | <gsnedders> | asmodai: that'll do |
| 19:12 | <asmodai> | gsnedders: 613 passed of 613 |
| 19:13 | <jgraham> | (that is a test for the validate plugin not for jQuery itself) |
| 19:13 | <gsnedders> | asmodai: Definely WebKit/NetFront then |
| 19:13 | <gsnedders> | jgraham: (Yes, but NetFront's own browser is so broken with jQuery it'd totally break) |
| 19:17 | <Hixie> | hsivonen: none, the url was just what tantek asked me to use |
| 19:17 | <asmodai> | gsnedders: that's positive in a way |
| 19:18 | <gsnedders> | asmodai: Yeah, definitely. I think they still push their own engine primarily on platforms that need memory safety, or at least that's my guess. |
| 19:19 | <jgraham> | I imagine they will quietly drop their own engine |
| 19:20 | <gsnedders> | jgraham: And drop everywhere they sell to which needs OOM handling? I doubt it was a small amount they got paid for, e.g., the PS3. |
| 19:21 | <jgraham> | It seems very unlikely that there will continue to be a market for browsers that don't work on any useful websites |
| 19:22 | <jgraham> | Anyway if Webkit is acceptable for 3DS I have a hard time believing that next generation consoles couldn't run presto/webkit/gecko |
| 19:22 | <jgraham> | Or that a mini-like solution wouldn't be better if they really can't |
| 19:24 | <gsnedders> | jgraham: Well, for the PS3 it's an interesting question why not. It has a HDD, so could quite easily have swap space, which I presume is what is done in the 3DS. |
| 19:24 | <asmodai> | Ok, so what would be a better test to see what this little browser does support or not? It seems it uses a sandboxed iframe at least, that's nice |
| 19:26 | <gsnedders> | jgraham: But still, a lot of products that could trivially run a proper browser (e.g., PS3) just want a browser as a selling point, not caring if it works. |
| 19:26 | <gsnedders> | NetFront claims a min memory footprint of 2MB, which is insane. |
| 19:29 | <gsnedders> | (For comparison, Opera Devices SDK 2.8 claims 7MB footprint on ARM, with 2–15MB per runtime, 1–5MB per widget, 2–10MB per tab.) |
| 19:30 | <gsnedders> | (<http://www.opera.com/media/b2b/Opera_Devices_SDK_PS.pdf>;) |
| 19:33 | <asmodai> | gsnedders: insane in what they claim is min? |
| 19:33 | <asmodai> | (as in impossible?) |
| 19:34 | <gsnedders> | asmodai: Well, there's a very obvious reason why they manage to reach such a low number (it doesn't work with anything). |
| 19:36 | <wilhelm> | I worked on a couple of devices with 8-16 MB RAM around 2004. It worked great, until you loaded an image-heavy site. (c: |
| 20:39 | <hober> | hsivonen: #schema here on freenode for the http://www.w3.org/2001/sw/wiki/SemTech2011BOF going on right now |
| 21:30 | <mpilgrim> | here's an odd request: i need some problematic javascript strings |
| 21:30 | <mpilgrim> | are there any unicode characters disallowed in javascript? |
| 21:31 | <mpilgrim> | or characters that are allowed but that might trip up a storage system? |
| 21:32 | <Ms2ger> | I hear some browsers dislike nulls |
| 21:32 | <RichardJ> | mpilgrim: try any unicode character that is not in the basic multilangual plane |
| 21:32 | <mpilgrim> | null is good |
| 21:32 | <mpilgrim> | how do i denote a non-BMP character in javascript? |
| 21:33 | <Philip`> | JS is sort of UTF-16 |
| 21:33 | <Philip`> | so you need a string of length 2, like "\ud800\udc00" or whatever the syntax is |
| 21:33 | <RichardJ> | strings *should* be encoded in UTF-16 |
| 21:34 | <Philip`> | You could include things like unpaired surrogates to trip up any storage system that foolishly thinks JS strings are really UTF-16 |
| 21:34 | <RichardJ> | I believe some testsuites (like ACID3 perhaps) have tests for this as well |
| 21:35 | <Philip`> | U+FFFE and U+FFFF are always fun, too |
| 21:36 | <Philip`> | If string length isn't too limited, you could just use a string with all 64K possible character values |
| 21:36 | <mpilgrim> | checking if string length is limited... |
| 21:36 | <Philip`> | or 64K one-character strings |
| 21:37 | <mpilgrim> | "any string value" |
| 22:12 | <karlcow> | http://inliner.leftlogic.com/ |
| 22:27 | <linclark> | hsivonen: read your blog post, I have a question about your graph data model comment |
| 22:27 | <linclark> | I would have left a comment on the post, but I didn't see the option |
| 22:34 | <jgraham> | linclark: hsivonen is probably sleeping for the next 7 hours or so |
| 22:34 | <linclark> | jgraham: ah cool, thanks |