| 00:01 | <jamesr_> | roc, even if we (chrome team) want to do new features this way (channel restrictions but no prefix), that's generally not sufficient for us to actually do it unless apple agrees |
| 00:02 | <roc> | I see, they might be worried about landing stuff unprefixed on any branch? |
| 00:03 | <jamesr_> | right, roughly. we don't have separate SVN branches for our releases, for instance |
| 00:03 | <jamesr_> | we land stuff in trunk and then we cut release branches off of trunk and they advance through the channels as a numbered branch |
| 00:03 | <roc> | Can you easily support having both prefixed and unprefixed aliases with independent enabling/disabling? I assume so |
| 00:04 | <roc> | anyway, if it hasn't been discussed on webkit-dev yet, I hope it can be soon |
| 00:05 | <jamesr_> | we've talked about this at webkit meetups, not sure if it's been discussed on the mailing list |
| 00:05 | <jamesr_> | i know simon and tab are flying/will fly soon back from paris |
| 00:05 | <jamesr_> | and they'll probably both have input |
| 00:05 | <roc> | none of this affects what we have to do for existing stuff of course |
| 00:26 | <BenoitRen> | Leaving. Laters! |
| 04:54 | <josephg> | hey guys |
| 04:55 | <josephg> | does anyone here know anything about mutation observers? |
| 04:55 | <josephg> | I'm playing with them in chrome canary, but they're quite buggy… I wonder if I should file the bugs I'm finding. |
| 06:29 | <jamesr_> | josephg, you mean the new API |
| 06:29 | <jamesr_> | josephg, ? |
| 06:29 | <jamesr_> | josephg, i don't know much about them in particular, but you should definitely file bugs! |
| 06:29 | <jamesr_> | it's new stuff and some rough edges are probably expected |
| 06:29 | <jamesr_> | bugs.webkit.org, minimal testcases preferred but not required |
| 06:30 | <jamesr_> | josephg, you can cc me (jamesr⊙co) if bugzilla will let you do that |
| 06:30 | <jamesr_> | cheers |
| 07:16 | <josephg> | jamesr_: yeah the new api. I filed a bug on chromium - should I file a bug on webkit as well? |
| 07:29 | <josephg> | jamesr_: http://code.google.com/p/chromium/issues/detail?id=113584 |
| 07:48 | <mhausenblas> | hsivonen, congrats for http://validator.w3.org/nu/ - KUTGW! |
| 08:02 | <zcorpan> | Hixie: why did https://www.w3.org/Bugs/Public/show_bug.cgi?id=15941 get in the "other Hixie drafts" bucket? |
| 08:16 | <zcorpan> | "Instead of coding against a single CSS specification developers will need to code against changing vendor prefixes." http://www.webmonkey.com/2012/02/webkit-isnt-breaking-the-web-you-are/ |
| 08:16 | <zcorpan> | of course, -webkit-foo is stable and the spec is the one that's changing |
| 08:17 | <zcorpan> | i don't understand the argument "it'll break the standards process" |
| 09:12 | <jgraham> | zcorpan: People seem to believe as an article of faith that -vendor- is needed to allow innovation in CSS (but not, apparently in other areas like HTML). The desire to not critically examine that particular belief is the number 1 cause of tortured, convoluted, and often nonsensical, reasoning in this whole discussion. |
| 09:15 | <zcorpan> | i see |
| 09:17 | <annevk5> | so someone wants to advertise a commercial good on blog.whatwg.org? |
| 09:17 | <annevk5> | is that okay? |
| 09:17 | <annevk5> | in particular: http://alaramills.com/store.html |
| 09:18 | <annevk5> | does not really strike me as something we want to do |
| 09:18 | <jgraham> | It sounds kind of not-OK to me |
| 09:21 | <GlitchMr> | Not interested in this Periodic table of HTML5 elements |
| 09:23 | <GlitchMr> | It seems less useful than for example http://www.smashingmagazine.com/2009/07/06/html-5-cheat-sheet-pdf/ (if you want something printable of course :P) and it's paid... |
| 09:24 | <GlitchMr> | Artistically, I like the format of it, but that's all. |
| 09:26 | <jgraham> | I think you can stop advertising them in the irc logs now ;) |
| 09:26 | <annevk5> | thanks for the feedback |
| 09:26 | <annevk5> | the samshingmag is free jgraham |
| 09:26 | <jgraham> | No, I meant the other thing |
| 09:27 | <jgraham> | I imagine that "it seems less useful than" will still make it more likely that people will investigate the link :) |
| 09:29 | <zcorpan> | oh, oh, but surely http://simon.html5.org/html-elements is the most useful of all! and FREE!! |
| 09:30 | <annevk5> | anyway I declined |
| 09:31 | <zcorpan> | I ALSO SELL VIAGRA PILLS |
| 09:31 | <zcorpan> | what? i didn't say anything |
| 09:31 | <GlitchMr> | Sorry, you were logged in IRC logs... |
| 09:44 | <annevk5> | cats |
| 09:44 | <Ms2ger> | dogs |
| 09:44 | <jgraham> | pigs, but after 9 months you slaughter them, and then bacon. |
| 09:45 | <annevk5> | btw |
| 09:45 | <annevk5> | tomorrow is my talk on XML5 |
| 09:45 | <annevk5> | it'll be a bit over 20 minutes so there's not too much time |
| 09:46 | <annevk5> | anything I should cover? |
| 09:54 | <Ms2ger> | Vendor prefixes |
| 09:57 | <annevk5> | dude |
| 09:58 | <Ms2ger> | Yes dude? |
| 09:58 | <annevk5> | XML already has its own prefix hell |
| 09:58 | <annevk5> | no need for making it worse |
| 09:59 | <Ms2ger> | We could start using namespaces called http://www.mozilla.org/newlayout/xml/parsererror.xml |
| 09:59 | <Ms2ger> | Oh wait, we do |
| 09:59 | <jgraham> | Ms2ger: Oh may, you nailed it. |
| 09:59 | <jgraham> | *man |
| 09:59 | <Ms2ger> | Opera must be really evil to implement that instead of http://www.opera.com/newlayout/xml/parsererror.xml |
| 09:59 | <jgraham> | Vendor prefixes have failed because they're not URIs! |
| 09:59 | <Ms2ger> | jgraham++ |
| 10:00 | <annevk5> | making them URLs might actually solve the problem |
| 10:01 | <jgraham> | annevk5: Not if your argument is "they would be hard to type" |
| 10:01 | <jgraham> | Because no one actually types CSS anymore |
| 10:01 | <jgraham> | Not the cool kids anyway |
| 10:03 | <annevk5> | I was going for too confusing |
| 10:03 | <annevk5> | but I was also mostly joking |
| 10:03 | <jgraham> | :) |
| 10:04 | <annevk5> | the main problem with this XML5 talk is that I'm not sure we want the hassle of changing XML anymore |
| 10:04 | <Ms2ger> | Heh |
| 10:04 | <Ms2ger> | "XML5: I dunno if we want this" |
| 10:05 | <jgraham> | Well if we had a non-sucky XML it might solve the problems that the Web Components people are having with templates, or something |
| 10:05 | <annevk5> | if XML has to become some kind of authoring format used by web developers I think XML5 is pretty much required |
| 10:05 | <annevk5> | but it seems we moved past that and nobody cared |
| 10:06 | <Ms2ger> | We have XML5, no? |
| 10:06 | <annevk5> | jgraham: well yeah, that's certainly true, and SVG/Math and Components might have provided a compelling story for it |
| 10:06 | <Ms2ger> | It's <br /> sent as text/html |
| 10:06 | <annevk5> | but now all is text/html anyway |
| 10:06 | <annevk5> | Ms2ger: only works in Belgium |
| 10:07 | <Ms2ger> | lulz |
| 10:08 | <annevk5> | whoa |
| 10:08 | <annevk5> | http://arstechnica.com/tech-policy/news/2012/02/jury-rules-that-eolass-interactive-web-patent-is-invalid.ars |
| 10:08 | <annevk5> | can we countersue now? |
| 10:08 | <annevk5> | we implemented all kinds of silly techniques iirc |
| 10:09 | <Ms2ger> | Alright |
| 10:09 | <Ms2ger> | If anybody said something useful in an email in my inbox that has "prefix" in the subject, send it again |
| 10:10 | <Ms2ger> | And add "responsive" to that |
| 10:14 | <jgraham> | YOu didn't like my email "Vendor prefixes for responsive web design nirvana" then? |
| 10:19 | <annevk5> | Ms2ger: just fix all the DOM bugs, mkay |
| 10:21 | <annevk5> | seems like it is time to fly |
| 10:21 | <annevk5> | bah |
| 10:22 | <annevk5> | from -6 to -13 |
| 10:22 | <annevk5> | and there's hail |
| 10:22 | annevk5 | wants to go back on vacation |
| 10:28 | <Ms2ger> | jgraham, I dunno if I liked it, it's moved to /dev/null |
| 10:40 | <MikeSmith> | annevk5: right after you got back you pinged me about the thing |
| 10:40 | <MikeSmith> | but I forgot what it wa |
| 10:40 | <MikeSmith> | was |
| 10:41 | <MikeSmith> | we were going to do something but we had to wait for some consensus call from webapps WG |
| 10:41 | <MikeSmith> | or www-dom list or something |
| 10:41 | <MikeSmith> | and I was all ready to do it |
| 10:41 | <MikeSmith> | but I forgot what it was I was all set to do |
| 10:42 | <MikeSmith> | haha that posters costs $47.99 |
| 10:51 | <MikeSmith> | yee hah for CORS for XHR in IE10 |
| 11:08 | <MikeSmith> | https://twitter.com/#!/ryah/status/167743028637872128 |
| 11:10 | <zcorpan> | i saw a tv commercial the other day, for a smartphone. it included "internet, email and facebook" |
| 11:11 | <MikeSmith> | heh |
| 11:11 | <MikeSmith> | zcorpan: they know their market I guess |
| 11:11 | <MikeSmith> | annevk5: https://twitter.com/#!/mnot/status/167792607890644992 |
| 11:12 | <zcorpan> | let's change CORS to suck less! wait, first we need to prefix all implementations... |
| 11:28 | <bga> | new regexp engine http://code.google.com/p/brre/ |
| 11:29 | <MikeSmith> | Object Pascal |
| 11:29 | <MikeSmith> | cool |
| 11:59 | <Taggnostr> | I'm looking for broken html pages with lot of markup errors to test a parser, does anyone know where can I find it? (does the html validator at w3.org keep an high-score list of the sites with most errors?) |
| 12:00 | <Ms2ger> | Maybe try google.com? |
| 12:00 | <MikeSmith> | Taggnostr: Alexa keeps a list like that |
| 12:00 | <Taggnostr> | I found http://www.trentmueller.com/Top-10-Websites-with-the-Worst-HTML_Article/ |
| 12:01 | <Taggnostr> | but those sites now have less errors |
| 12:01 | <Taggnostr> | MikeSmith, a list of sites with broken html? |
| 12:01 | <jgraham> | Taggnostr: http://code.google.com/p/html5lib/source/browse/#hg%2Ftestdata%2Ftree-construction |
| 12:02 | <MikeSmith> | http://www.alexa.com/topsites |
| 12:02 | <jgraham> | heh |
| 12:04 | <zcorpan> | MikeSmith: do the stars indicate the brokenness? |
| 12:04 | <MikeSmith> | haha |
| 12:04 | <Taggnostr> | I already tested the parser with 1000 popular sites, but I was looking for websites like http://www.dokimos.org/ajff/ |
| 12:04 | <MikeSmith> | number of errors per page is not a great metric |
| 12:04 | <MikeSmith> | it's the quality of the errors that matter |
| 12:05 | <MikeSmith> | any jackass can ring up the error meter just by putting a bunch of &s or such |
| 12:05 | <MikeSmith> | Taggnostr: oh man |
| 12:05 | <MikeSmith> | how'd you find that one? |
| 12:06 | <MikeSmith> | this is gold |
| 12:06 | <Taggnostr> | googling for "worst websites" or something similar |
| 12:06 | <MikeSmith> | the security warning at the top is genius |
| 12:06 | <Ms2ger> | Forget all the other browsers and |
| 12:06 | <Ms2ger> | down with the Web 2.0 net police. |
| 12:06 | <Taggnostr> | but it only has 375 errors on the main page |
| 12:07 | <MikeSmith> | Error: meta element between head and body. |
| 12:07 | <Taggnostr> | (the people who signed the guestbook seem to like it though) |
| 12:07 | <MikeSmith> | that's the kind of thoughtful error I'm talking about |
| 12:08 | <Taggnostr> | I assume that a website made with word and photoshop and put together with frontpage has enough creative errors |
| 12:10 | <jgraham> | Taggnostr: Seriously, have you tried the tests I linked to |
| 12:10 | <jgraham> | ? |
| 12:10 | <jgraham> | If you pass those you shoud do fine on websites |
| 12:11 | <Taggnostr> | I'm looking at them, but I was searching for real-world pages (it's also easy for me to wget them and use them in my tests) |
| 12:11 | <Taggnostr> | thanks for the link btw! |
| 12:11 | <jgraham> | Passing the tests is much more likely to be helpful than finding real world pages |
| 12:11 | <jgraham> | They are much easier to debug too :) |
| 12:12 | <jgraham> | The only thing that they really lack is crazy-deep nesting and so on |
| 12:13 | <zcorpan> | Taggnostr: what do you use the parser for? |
| 12:13 | <Taggnostr> | it's the Python built-in parser |
| 12:13 | <zcorpan> | ah |
| 12:14 | <zcorpan> | well i can only concur with jgraham, you really want to pass the testsuite |
| 12:14 | <Taggnostr> | my goal right now is to make it able to parse everything without errors, the next goal is to make it parse everything as correctly as possible (following the html5 standard) |
| 12:14 | <jgraham> | I don't understand the difference between those goals |
| 12:15 | <zcorpan> | just implement the parsing algorithm in the spec, it covers all cases |
| 12:15 | <Taggnostr> | right now when the parser finds invalid markup it just raises an error and give up parsing, and there's nothing you can do |
| 12:15 | <jgraham> | Unless you consider "without error" to simply mean "not throwing". In which case lambda html:"" meets the goal |
| 12:16 | <Taggnostr> | and I'm changing that so that it tries to figure out what to do with the invalid markup and keep going till the end |
| 12:16 | <Ms2ger> | You're modifying an existing parser? |
| 12:16 | <Taggnostr> | zcorpan, I can't start from scratch, so I'm adapting what I have to get closer to the specs gradually |
| 12:16 | <Taggnostr> | yes |
| 12:16 | <Ms2ger> | I... wouldn't recommend that |
| 12:17 | <zcorpan> | why can't you start from scratch? |
| 12:17 | <Ms2ger> | I don't know of anybody who's done that |
| 12:17 | <Taggnostr> | well, so far I managed to have it parse a list of 1000 pages successfully with 0 errors, so it's going quite well |
| 12:18 | <Taggnostr> | zcorpan, because I could just use html5lib if I wanted a python parser that follows the specs |
| 12:18 | <jgraham> | Pretty sure we had this conversation before |
| 12:18 | <Taggnostr> | we did |
| 12:19 | <jgraham> | But if I were you I would wrap html5lib in an API that looks more like the stdlib |
| 12:19 | <jgraham> | Rather than trying to make the internals of the stdlib more like html5lib |
| 12:19 | <zcorpan> | so you want something that is closer to the spec, but still isn't 100% compliant? |
| 12:20 | <Taggnostr> | but the goal is providing a better html parser in the stdlib, and improving the existing one is the only viable solution (replacing it with html5lib is not really an option) |
| 12:20 | <Taggnostr> | zcorpan, I want to get as close as 100% compliant as possible |
| 12:21 | <zcorpan> | why is replacing it with html5lib not an option? |
| 12:21 | <Taggnostr> | but if it does the wrong thing with some obscure corner cases it probably doesn't matter too much now |
| 12:23 | <Taggnostr> | zcorpan, for several reason, if html5lib is added to the stdlib it will have to follow the python release schedule (so you have to wait many months between releases), it needs someone willing to maintain it, it needs to have a compatible license, it has to be "good enough" to get in the stdlib and replace the existing one and have everyone to switch and so on |
| 12:24 | <jgraham> | So it would get a faster release schedule than today? |
| 12:24 | jgraham | has neglected html5lib recently |
| 12:25 | <jgraham> | The license shouldn't be a problem |
| 12:25 | <Taggnostr> | how often do you make html5lib releases? |
| 12:25 | <Taggnostr> | for python is more or less 16 months for new features and maybe 4 for bug fixes |
| 12:25 | <jgraham> | Well, uh, the last one was a few years ago. It is horribly out of date compared to trunk. This is somewhat embarassing |
| 12:26 | <Taggnostr> | are people even using it? |
| 12:26 | <jgraham> | It turns out that at any given moment there is always something more fun to do than make a release |
| 12:26 | <jgraham> | Yeah, we get a steady flow of bug reports |
| 12:27 | <jgraham> | and Mozilla use it in their html sanitizer, for example |
| 12:27 | <Ms2ger> | Philip`_, so about your canvas tests... |
| 12:27 | <Ms2ger> | jgraham, oh? |
| 12:27 | <jgraham> | (most of the bug reports as Invalid, I should say) |
| 12:27 | <jgraham> | Ms2ger: The one you use on your websites |
| 12:27 | <Taggnostr> | do they use the development version then? |
| 12:27 | <jgraham> | Nothing in the browser ofc |
| 12:27 | <Ms2ger> | Oh |
| 12:27 | <Ms2ger> | Those people use git |
| 12:27 | <jgraham> | And for that they are to be praised |
| 12:27 | <jgraham> | :p |
| 12:28 | <jgraham> | Taggnostr: I am not sure. A release is long, long overdue. And if I could do one right away I think I would now feel guilty enough to do one |
| 12:29 | <jgraham> | But we will see how the feeling persists to this evening |
| 12:29 | <Ms2ger> | jgraham, today isn't do what the hell you want day? |
| 12:30 | <Taggnostr> | these are some numbers about Python html parser btw: http://dpaste.com/699552/ |
| 12:30 | <jgraham> | Nope :| |
| 12:31 | <Taggnostr> | the percentage represent the pages parsed till the end with no errors |
| 12:31 | <Taggnostr> | (with a sample of ~1000 pages) |
| 12:34 | <Philip`_> | Taggnostr: Have you tried parsing e.g. a PDF file and seeing if that hits any errors? |
| 12:34 | <Taggnostr> | nope |
| 12:35 | Philip`_ | vaguely remembers a few difficulties with such files when parsing lots of random pages, though maybe that was just because he hadn't implemented a length limit before then |
| 12:38 | <Philip`_> | Taggnostr: If you want a larger selection of real-world pages to test, http://www.dotnetdotcom.org/ has something like half a million |
| 12:40 | <Taggnostr> | thanks |
| 13:18 | <zcorpan> | hmm. should track bugs be in the texttracks CG component? |
| 13:19 | <hsivonen> | sigh. http://www.change.org/petitions/microsoft-mozilla-opera-dont-make-webkit-prefixes-a-de-facto-standard |
| 13:21 | <zcorpan> | we won't. it already is. we'll make it a de jure standard. |
| 13:21 | <zcorpan> | that page doesn't load for me btw |
| 13:22 | <hsivonen> | WFM in Opera |
| 13:22 | <zcorpan> | ah now it loaded |
| 13:24 | <hsivonen> | glad to see PPK calls the BS on the call for action |
| 13:26 | <Ms2ger> | annevk5, so, what do you think about the DOMTokenList / space separated token list thread? |
| 13:35 | <zcorpan> | i don't follow how PPK recognizes that the problem lies with prefixes, yet proposes other prefixes |
| 13:36 | <zcorpan> | having -alpha-foo, -beta-foo, foo and -webkit-foo seems worse than just foo and -webkit-foo |
| 13:49 | <jgraham> | zcorpan: I refer you to what I said ~4h 37m ago |
| 13:50 | <jgraham> | Which really applies to -anything-, not just -vendor- |
| 13:52 | <zcorpan> | yeah |
| 14:19 | <MikeSmith> | "specs are not magical" |
| 14:19 | <MikeSmith> | sad but true |
| 14:19 | <MikeSmith> | I wish they were magical |
| 14:33 | <hsivonen> | amen to http://krijnhoetmer.nl/irc-logs/whatwg/20120210#l-693 |
| 14:37 | <MikeSmith> | "This is not a game where the objective is to win independent of the merits of the arguments. This is all about the merits of the arguments." |
| 14:37 | <MikeSmith> | well said |
| 14:37 | <MikeSmith> | http://lists.w3.org/Archives/Public/public-html/2012Feb/0110.html |
| 14:38 | <MikeSmith> | that should be put word-for-word into the W3C process doc |
| 14:39 | <Ms2ger> | Along with "longdesc is broken, don't waste your and my time on it" |
| 14:40 | <soapyfish> | Ahoy! |
| 14:43 | <karlcow> | MikeSmith: missing mushrooms? |
| 14:43 | <jgraham> | I wonder by what factor the number of characters in emails about longdesc attributes outweighs the number of characters of useful text pointed to by longdesc attributes. |
| 14:43 | <karlcow> | cf http://krijnhoetmer.nl/irc-logs/whatwg/20120210#l-1029 ;) |
| 14:44 | <MikeSmith> | karlcow: yeah, but I make my own substitutes -- windowpane |
| 14:44 | <karlcow> | heh |
| 15:10 | <annevk> | MikeSmith: it was about sending email for resolved bugs on www-dom |
| 15:11 | <annevk> | weather in Prague btw is better than expected, as long as you don't go outside for more than ten minutes |
| 15:13 | <MikeSmith> | annevk: oh so I did that already |
| 15:13 | <MikeSmith> | I recommend you go for the lulz in your talk |
| 15:13 | <jgraham> | annevk: So you mean the weather *indoors* in Prauge is better than expected |
| 15:13 | <jgraham> | ? |
| 15:14 | <Ms2ger> | Will the talk be recorded? |
| 15:16 | <annevk> | I think there might be live broadcast even |
| 15:16 | <annevk> | not sure though |
| 15:17 | <annevk> | MikeSmith: cool that it's already done! |
| 15:19 | <MikeSmith> | "Rorschach test for standardistas" is good |
| 15:21 | <karlcow> | Roooarrrschach test even |
| 15:23 | <Taggnostr> | http://www.w3.org/TR/html5/tokenization.html#end-tag-open-state links to "tag name state", and "tag name state" includes attributes. Does that mean that <foo></foo some="attr"> is not a parsing error? |
| 15:24 | <MikeSmith> | Taggnostr: that's a parsing error |
| 15:24 | <MikeSmith> | Taggnostr: is the default python parser written in python? |
| 15:24 | <Taggnostr> | MikeSmith, yes |
| 15:25 | <Taggnostr> | how is that a parsing error? |
| 15:25 | <MikeSmith> | because it is? |
| 15:25 | <MikeSmith> | I don't have the spec open |
| 15:25 | <Taggnostr> | if I follow the page, after </ there's "f", so it's the second entry that redirects to "tag name state" |
| 15:26 | <MikeSmith> | but it might help you to read the code of the validator.nu/Mozilla parser |
| 15:26 | <MikeSmith> | the source |
| 15:26 | <MikeSmith> | lemme get you a URL |
| 15:26 | <MikeSmith> | it's an error-reporting parser |
| 15:26 | MikeSmith | can't remember if html5lib is error-reporting |
| 15:26 | <Philip`_> | Taggnostr: I think the error occurs when the tokeniser emits the end tag token |
| 15:26 | <MikeSmith> | Taggnostr: when in doubt I read hsivonen code |
| 15:26 | <Philip`_> | since the spec says it's an error to emit end tag tokens that have attributes |
| 15:27 | <MikeSmith> | rather than the spec |
| 15:27 | <Taggnostr> | Philip`_, is that after the parsing? |
| 15:27 | <MikeSmith> | I find hsivonen code much easier to follow and it has comments that reference the spec |
| 15:27 | <Taggnostr> | MikeSmith, I think html5lib is error reporting |
| 15:27 | <Philip`_> | "When an end tag token is emitted with attributes, that is a parse error." (http://www.whatwg.org/specs/web-apps/current-work/multipage/tokenization.html#tokenization) |
| 15:28 | <MikeSmith> | Taggnostr: ok |
| 15:28 | <MikeSmith> | Taggnostr: http://hg.mozilla.org/projects/htmlparser/file/default/src/nu/validator/htmlparser/impl is worth perusing |
| 15:28 | <Taggnostr> | Philip`_, so I should parse all the attributes in the end tag normally, and then simply ignore them and emit only the tag name? |
| 15:29 | <Philip`_> | The tree construction algorithm never looks at the attributes of an end tag token, so you don't need to actually bother storing them when tokenising |
| 15:29 | <Taggnostr> | but I have to go through them in order to figure out where the tag ends |
| 15:30 | <Philip`_> | Yeah, I think you need to at least partially tokenise them, so you can handle </foo bar=">" baz> correctly |
| 15:31 | <Taggnostr> | yep, so in that case I'll just emit a foo, and ignore the rest |
| 15:31 | <Philip`_> | Storing the attributes then ignoring them later is presumably not going to hurt efficiency in practice (compared to having the tokeniser skip over them without storing anything), because almost nobody puts attributes in end tags in practice |
| 15:32 | <Philip`_> | but the spec doesn't care how you implement it as long as the visible end result (i.e. the DOM tree) is the same as what the spec says it should be |
| 15:32 | <Taggnostr> | there's also the case of e.g. </li<ul>, I think this should emit 'li<ul' as token name |
| 15:33 | <Ms2ger> | Indeed |
| 15:33 | <Philip`_> | By "should", do you mean you think the spec says that, or you think the spec ought to say that? |
| 15:33 | <Taggnostr> | the python "parser" just does tokenization, it doesn't build the tree |
| 15:33 | <Ms2ger> | The spec does say that, IIRC |
| 15:33 | <Taggnostr> | I mean that if I read them correctly that's what I should emit |
| 15:34 | <Philip`_> | That does seem to be the case |
| 15:35 | <Taggnostr> | MikeSmith, the code you linked doesn't seem too clear to me |
| 15:35 | <MikeSmith> | Taggnostr: so what does python use for tree building by default? |
| 15:35 | <MikeSmith> | Taggnostr: blame hsivonen |
| 15:35 | <MikeSmith> | it conforms to the spec anyway |
| 15:35 | <MikeSmith> | most of the time the spec is very clear |
| 15:35 | <MikeSmith> | as long as you know where to look |
| 15:35 | <MikeSmith> | problem is, some of the stuff is kind of spread around in the spec |
| 15:36 | <MikeSmith> | and once you know where it is it's clear |
| 15:36 | <Taggnostr> | MikeSmith, there's nothing in the stdlib for that, one option is BeautifulSoup, otherwise there are other alternatives like lxml and html5lib |
| 15:36 | <MikeSmith> | ah |
| 15:36 | <MikeSmith> | yeah |
| 15:36 | <Taggnostr> | MikeSmith, apparently all that I need is in http://www.w3.org/TR/html5/tokenization.html , but with all those states it might get a bit confusing to follow |
| 15:36 | <Philip`_> | One problem with only doing tokenisation and not building the tree is that it's hard to parse stuff like <script><div></script> properly, since it's not obvious when you should switch to the spec's 'script data state' or whichever state it is |
| 15:37 | <MikeSmith> | Taggnostr: be glad I guess that you don't have to implement tree-building |
| 15:37 | Philip`_ | doesn't know whether "hard" means "impossible" or merely "not directly specified" |
| 15:37 | <Taggnostr> | luckily that's not my problem, for that I would emit a start 'script', a start 'div', and an end 'script' |
| 15:38 | <jgraham> | Taggnostr: Wow, really? |
| 15:38 | <Taggnostr> | jgraham, yes |
| 15:38 | <MikeSmith> | Taggnostr: fwiw seems like you are doing the wise thing by asking here instead of just trying to read teh spec in isolatin |
| 15:38 | <Philip`_> | What about <circle/><svg><circle/></svg> ? |
| 15:39 | <Taggnostr> | iirc <circle/> is seen as start+end, and the default implementation emits a start and an end |
| 15:39 | <Taggnostr> | so start circle, end circle, start svg, start circle, end circle, end svg |
| 15:40 | <Taggnostr> | jgraham, why are you surprised? |
| 15:40 | <Philip`_> | It should be more like start-circle, start-svg, start-circle, end-circle, end-svg, to match what a full HTML5 parser would do |
| 15:41 | <Philip`_> | What about <script><!--</script> ? (Should be start-script, text-"<!--", end-script; otherwise some pages will get all of their content slurped into the comment, which is probably undesirable) |
| 15:41 | <Taggnostr> | I think even <br/> emits start-br, end-br (unless you override the start/end method |
| 15:42 | <Taggnostr> | that should do the right thing, i.e. read everything between <script> and </script> and emit it as data |
| 15:43 | <Philip`_> | That makes sense for <br> and <br/>, since they're both equivalent to XML's "<br/>", but <circle/> is equivalent to XML "<circle>" if outside of <svg> etc or equivalent to XML "<circle/>" if inside of <svg> etc |
| 15:43 | <Philip`_> | so whether it should be treated as self-closing is context dependent |
| 15:44 | <Taggnostr> | can you elaborate on this a bit? |
| 15:46 | <Philip`_> | See e.g. http://livedom.validator.nu/?%3C!DOCTYPE%20html%3E%0D%0A%3Ccircle%2F%3Ex%3Csvg%3Ey%3Ccircle%2F%3Ez%3C%2Fsvg%3E |
| 15:47 | <Philip`_> | The "x" is a child of the first circle element, but the "z" is a sibling of the second circle element |
| 15:49 | <Philip`_> | (i.e. "<circle/>x<svg>y<circle/>z</svg>" is equivalent to "<circle>x<svg>y<circle></circle>z</svg>") |
| 15:49 | <Taggnostr> | I was looking for a dom viewer, this will be useful, thanks! |
| 15:51 | <Taggnostr> | so the first circle is parsed following the html rules so the / is discarded, whereas inside <svg> an xml parser is used and the / implies a self-closing tag? |
| 15:53 | <jgraham> | Yes |
| 15:53 | <jgraham> | Sort of |
| 15:53 | <Philip`_> | It's not a real XML parser - it's just a different mode in the tree construction algorithm which handles the token's self-closing flag differently |
| 15:53 | <Philip`_> | (in particularly, by treating the token as self-closing, rather than by ignoring the flag) |
| 15:54 | <Philip`_> | s/ly// |
| 15:54 | <Taggnostr> | ok |
| 15:54 | <Taggnostr> | I wonder why </br> is seen as a <br> whereas <hr> is ignored |
| 15:55 | <Taggnostr> | is hr gone from html5? |
| 15:55 | <Taggnostr> | s/<hr>/</hr>/ |
| 15:56 | <Philip`_> | Maybe I'm confusing things since I don't know whether you're aiming to output a properly-nested stream of start/end tokens that correspond to an XML serialisation of the DOM produced by the HTML5 parser (which requires unlimited buffering to do it properly), or a usually-incorrectly-nested stream of tokens that match the HTML5 tokeniser's output (which requires an explicit self-closing flag so consumers can decide how to handle the token in a way tha |
| 15:56 | <Philip`_> | ...that matches HTML5), or some mixture |
| 15:56 | <jgraham> | Don't you use irssi, Philip`_ ? |
| 15:56 | <Philip`_> | </br> is a special case due to the insanity of HTML |
| 15:56 | <Philip`_> | jgraham: Yes |
| 15:57 | <Taggnostr> | I just tokenize and emit tokens as soon as I parse them, I don't build trees and/or keep states |
| 15:57 | <jgraham> | /load splitlong.pl ? |
| 15:59 | <Philip`_> | http://www.whatwg.org/specs/web-apps/current-work/multipage/tree-construction.html#tree-construction says "↪An end tag whose tag name is "br" Parse error. Act as if a start tag token with the tag name "br" had been seen. Ignore the end tag token." |
| 16:00 | <Philip`_> | jgraham: That might be convenient |
| 16:05 | Philip`_ | can't think of enough to say to test whether it actually works, but assumes it will since it didn't give any error messages or anything, so he conditionally thanks jgraham for the suggestion |
| 16:06 | Ms2ger | conditionally thanks Philip`_ for updating his canvas tests |
| 16:07 | <MikeSmith> | btw, I think Hixie likes his "no-quirks mode" term |
| 16:07 | <MikeSmith> | but who knows |
| 16:07 | <Philip`_> | Ms2ger: warning: conditional expression is constant |
| 16:07 | <MikeSmith> | sometimes you can't predict when Hixie will change his mind |
| 16:08 | <MikeSmith> | I like "no-quirks mode" myself |
| 16:08 | <Ms2ger> | MikeSmith, it's a lie, though |
| 16:08 | <Ms2ger> | "no-quirks mode" has plenty of quirks |
| 16:08 | <MikeSmith> | many things are a lie |
| 16:08 | <Hixie> | the problem is "standards mode" is a sillier name :-) |
| 16:08 | <Hixie> | and "almost-standards" doubly so :-) |
| 16:09 | <MikeSmith> | heh |
| 16:09 | <Ms2ger> | Because we have no standards? |
| 16:09 | <Hixie> | if we spec it all, it's all standards mode |
| 16:09 | <MikeSmith> | yeah, please "almost standards"? c'mon |
| 16:10 | <Wilto> | Something something dating joke. |
| 16:10 | <MikeSmith> | heh |
| 16:10 | <MikeSmith> | Wilto: please hang out here more often |
| 16:10 | AryehGregor | votes for "quirks mode", "marginally more quirks mode", and "appreciably more quirks mode" |
| 16:10 | <Wilto> | I’ll be like the Jar Jar Binks of #whatwg. |
| 16:11 | MikeSmith | seconds AryehGregor proposal |
| 16:11 | <Wilto> | Quirkiness should be measured on a scale of “zero” to “Zooey Deschanel.” |
| 16:12 | <Ms2ger> | AryehGregor, I still hope that "appreciably more quirks mode" will become appreciably less quirky |
| 16:12 | <AryehGregor> | Me too. |
| 16:12 | Philip`_ | was going to suggest "quirks mode", "quirkier mode", "quirkiest mode", but realises that won't be extensible in the future when we discover an even weirder mode that browsers have to be compatible with |
| 16:12 | <Ms2ger> | Also, removing document.all entirely |
| 16:12 | AryehGregor | was also going to, but realized that the first mode would have to be called "quirky mode" instead of "quirks mode" for consistency |
| 16:13 | <Philip`_> | AryehGregor: The naming inconsistency is just another quirk |
| 16:13 | <karlcow> | we should pick up the name of modes according to a random selection of insect names |
| 16:21 | <MikeSmith> | so I started http://platform.html5.org/history/ recently |
| 16:21 | <MikeSmith> | for anybody who cares to help with the forensics |
| 16:22 | <MikeSmith> | https://github.com/sideshowbarker/platform.html5.org/tree/master/history |
| 16:23 | <MikeSmith> | ara |
| 16:23 | <MikeSmith> | Do Not Track support in Opera |
| 16:24 | <MikeSmith> | http://my.opera.com/desktopteam/blog/2012/02/10/core-dnt-mail-themes |
| 16:25 | <karlcow> | MikeSmith: well I have to write something about this. |
| 16:25 | <MikeSmith> | karlcow: merveilleux |
| 16:25 | <karlcow> | Because the DNT header on the client side is… peanuts. It's not really the part which matters. And the BIG HUGE battle will be on the server side |
| 16:26 | <MikeSmith> | yur caps hurts my eyes |
| 16:26 | <karlcow> | I hope I will take the time this afternoon on ODIN blog http://my.opera.com/ODIN/blog/ |
| 16:26 | <MikeSmith> | "BIG HUGE" is good those in most context |
| 16:27 | <karlcow> | MikeSmith: I like to hurt you :p |
| 16:29 | <MikeSmith> | on an unrelated note, how do I say "peanut gallery" in your France language? |
| 16:31 | <PandaZ> | jquery |
| 16:31 | <PandaZ> | oops |
| 16:31 | <Ms2ger> | Gallerie d'arachide? |
| 16:41 | <MikeSmith> | gallery of spiders? |
| 16:41 | <Ms2ger> | No 'n' |
| 16:42 | <MikeSmith> | dammit why can't France people just use ENGLISH like the rest of the world |
| 16:42 | <MikeSmith> | I mean it's quaint and amusing |
| 16:42 | <MikeSmith> | but please |
| 16:42 | <MikeSmith> | enough is enough |
| 16:42 | <karlcow> | peanut gallery? which meaning for peanut |
| 16:43 | <karlcow> | sex or fruits |
| 16:43 | <Wilto> | Woah, I tuned back in at a weird time. |
| 16:43 | <Ms2ger> | There are no others |
| 16:43 | <karlcow> | Wilto: with me, it's always NSFW for americans crowd |
| 16:45 | <MikeSmith> | karlcow is a sexiste |
| 16:45 | <MikeSmith> | with the e on the end |
| 16:45 | <karlcow> | :) |
| 16:46 | <MikeSmith> | cf. alcholiste |
| 16:48 | <AryehGregor> | ARGH. |
| 16:49 | <AryehGregor> | https://www.w3.org/Bugs/Public/show_bug.cgi?id=15508 |
| 16:49 | <MikeSmith> | AryehGregor: hah |
| 16:50 | <MikeSmith> | more of the same on the way |
| 16:50 | <Ms2ger> | Ah, CSS |
| 16:50 | <AryehGregor> | What do you mean? |
| 16:51 | <MikeSmith> | I mean that lots of stuff getting implemented hard and fast these days without much thought about how it should work with existing features |
| 16:51 | <MikeSmith> | or other proposed features |
| 16:51 | <AryehGregor> | It's not an implementer here, it's someone from Adobe. |
| 16:52 | <MikeSmith> | Adobe is an implementor |
| 16:52 | <AryehGregor> | I mean, maybe Adobe pays some WebKit people, I don't know. |
| 16:52 | <MikeSmith> | um |
| 16:52 | <AryehGregor> | For all I know he could work on transforms for WebKit. |
| 16:52 | <AryehGregor> | I was assuming not, but maybe that was unjustified. |
| 16:52 | <MikeSmith> | you know who Dirk is, right? |
| 16:52 | <AryehGregor> | . . . no. :( |
| 16:52 | <MikeSmith> | ah |
| 16:52 | <MikeSmith> | well |
| 16:52 | AryehGregor | shouldn't make assumptions |
| 16:52 | AryehGregor | definitely shouldn't make assumptions in a publicly-logged IRC chat |
| 16:52 | <MikeSmith> | Dirk's been working on Webkit since before it was Webkit |
| 16:52 | <karlcow> | "absolutely" and others… are words that I would absolutely bannish. |
| 16:53 | <AryehGregor> | Heh, okay. |
| 16:53 | <AryehGregor> | My bad. |
| 16:53 | <MikeSmith> | no |
| 16:53 | <MikeSmith> | no way to know |
| 16:53 | <AryehGregor> | Well, I could have looked before making assumptions . . . |
| 16:53 | <MikeSmith> | since we don't record this stuff anywhere |
| 16:53 | <MikeSmith> | anyway, he knows a thing or two about a thing or two |
| 16:55 | <gsnedders> | AryehGregor: Adobe have quite a few people working on WebKit, on stuff like regions. |
| 16:55 | <AryehGregor> | Yeah, I somewhat knew that. |
| 16:55 | <AryehGregor> | Should have thought before I spoke. |
| 16:55 | <AryehGregor> | I think this would be a bad change, but it's not the end of the world. |
| 16:55 | AryehGregor | doesn't think CSS transforms should be brought in line with SVG transforms at all |
| 16:58 | <MikeSmith> | maybe should give up on SVG transforms at all |
| 16:58 | <MikeSmith> | or whatever they're called |
| 16:59 | <AryehGregor> | They should be deprecated presentational attributes. |
| 16:59 | <AryehGregor> | Or not deprecated. |
| 16:59 | <AryehGregor> | Since SVG is meant for display. |
| 16:59 | <AryehGregor> | Or whatever. |
| 16:59 | <AryehGregor> | I don't car.e |
| 16:59 | <AryehGregor> | care. |
| 16:59 | <AryehGregor> | But I don't want us complicating CSS to be more compatible with them. |
| 16:59 | <MikeSmith> | Doug and heycam|away and others might not be so keen on that |
| 16:59 | <AryehGregor> | Which part? |
| 17:00 | <MikeSmith> | dropping SVG transforms |
| 17:00 | <AryehGregor> | I'm being hasty and rash here. I'm tired, and I shouldn't be so vocal just because I'm in a group of like-minded people. I still think the change is a bad one, though. |
| 17:00 | <MikeSmith> | I don' think SVG actually calls them transforms |
| 17:00 | <AryehGregor> | Well, obviously keep them for compat. |
| 17:00 | <AryehGregor> | I think it does, no? |
| 17:00 | <MikeSmith> | I dunno |
| 17:01 | <MikeSmith> | don't know it well enugh |
| 17:01 | <MikeSmith> | but anyway |
| 17:02 | <MikeSmith> | I think for web author-developers, if they can do something usng CSS, that's what they're going to use |
| 17:02 | <MikeSmith> | if they have a CSS way to do it, they don't care if SVG can do it because after all for them them wtf is SVG anyway |
| 17:03 | <Wilto> | For what it’s worth, yeah, I’ll attest to that. |
| 17:03 | <Wilto> | Not that there’s any excuse for not keeping up with the New Hotnesses™, but… yeah. |
| 17:03 | <AryehGregor> | Right, exactly. |
| 17:03 | <AryehGregor> | People know about CSS but not SVG. |
| 17:04 | <AryehGregor> | I don't think it's worthwhile to make CSS more similar to SVG, but rather the reverse. |
| 17:04 | <Wilto> | Right. Not saying I wouldn’t be interested, but the lower the barrier to adoption the better. |
| 17:04 | <AryehGregor> | I think my disagreement with Dirk is mostly because he has a strong SVG background, and I'm just about at the point where I can make a red circle without having to look stuff up. :) |
| 17:04 | <AryehGregor> | (except the namespace) |
| 17:04 | <Wilto> | I put borders on things for a living; I like things to be simple. |
| 17:32 | <AryehGregor> | . . . I admit that now I'm getting annoyed at git. Is there really no way to set the default number of context lines for patches? |
| 17:36 | <AryehGregor> | Also, git doesn't figure out copies. |
| 17:36 | <AryehGregor> | That's one good thing about hg. |
| 17:36 | <AryehGregor> | Sigh . . . |
| 17:37 | AryehGregor | just hates everything now indiscriminately. |
| 17:38 | dglazkov | offers AryehGregor a hug |
| 18:08 | <AryehGregor> | I also forgot how it takes at least five minutes to find anything in a git man page, because every command has 200 options, half of them documented by reference to other man pages. Most of which seem gratuitous, insofar as I've never missed them in hg. |
| 18:08 | <AryehGregor> | The not-tracking-renames thing is very bad when submitting patches to a non-git project. I think for Mozilla, I'll stick to hg. |
| 18:08 | <AryehGregor> | When in Rome . . . |
| 18:09 | <AryehGregor> | It's not really nice to submit patches that won't work correctly in hg just because I generated them using git because I don't like hg. |
| 18:54 | <jamesr_> | how does 'null' convert to an optional double parameter? |
| 18:55 | <jamesr_> | someone's passing 'null' in for the maxWidth parameter of canvas2d's fillText(). trying to figure out if IDL says that it's ignored, or if it converts to 0 |
| 18:55 | <Ms2ger> | |
| 18:56 | <Ms2ger> | Er |
| 18:56 | <Ms2ger> | Or NaN |
| 18:56 | Ms2ger | checks |
| 18:56 | <Ms2ger> | jamesr_, +0 |
| 18:56 | <Ms2ger> | (undefined would be NaN) |
| 18:57 | <Ms2ger> | And http://es5.github.com/#x9.3 is the relevant spec |
| 18:58 | <jamesr_> | well |
| 18:58 | <jamesr_> | the HTML spec says "If maxWidth is present ..." |
| 18:58 | <Ms2ger> | It is |
| 18:58 | <jamesr_> | what if you say fillText(..., undefined) ? |
| 18:59 | <jamesr_> | is it still present, even though the IDL is declared optional? |
| 18:59 | <Ms2ger> | It is present |
| 18:59 | <jamesr_> | so wait |
| 18:59 | <Ms2ger> | Unless |
| 18:59 | <jamesr_> | if i had a function with parameters (optional double a, optional double b), how the flip do i call it without 'a' being present? |
| 18:59 | <Ms2ger> | [TreatUndefinedAs=Missing] is on the argument |
| 18:59 | <Ms2ger> | You don't |
| 18:59 | <jamesr_> | void fillText(DOMString text, double x, double y, optional double maxWidth); |
| 19:00 | <jamesr_> | ok so i'd have to declare it void foo(optional [TreatUndefinedAs=Missing] double a, optional double b) then do foo(undefined, 1.0) ? |
| 19:00 | <jamesr_> | hmmmmm |
| 19:00 | <Ms2ger> | You can't omit a if you're passing b |
| 19:00 | <Ms2ger> | Impossible |
| 19:01 | <jamesr_> | so now i'm not sure what fillText(..., undefined) should do. the first line of the the fillText algorithm reads "If maxWidth is present but less than or equal to zero, return without doing anything; abort these steps." |
| 19:01 | <jamesr_> | so if someone passes undefined, that turns into NaN. NaN <= 0 is false, but so is NaN > 0 |
| 19:02 | <Ms2ger> | Ah |
| 19:02 | <Ms2ger> | But there's a catch-all somewhere |
| 19:02 | <Ms2ger> | Except where otherwise specified, for the 2D context interface, any method call with a numeric argument whose value is infinite or a NaN value must be ignored. |
| 19:07 | <jamesr_> | so what's that mean for null? |
| 19:08 | <Ms2ger> | null turns into +0 |
| 19:13 | <Hixie> | jamesr_: (optional double a, optional double b) is just shorthand for declaring three overloaded operations with (), (double a), and (double a, double b) respectively |
| 19:18 | <Ms2ger> | readonly attribute (DOMString or ArrayBuffer)? result |
| 19:18 | <Ms2ger> | That works, right? |
| 19:23 | <jamesr_> | hm ok |
| 19:48 | jwalden | sees days-ago scrollback talking about Mozilla (?) spewing CSS warnings for vendor-prefixed stuff and is quite sure we don't do that (except if it's a -moz- property we don't recognize), seeing as he implemented it |
| 19:50 | <jwalden> | well, more day-ago |
| 19:59 | <matjas> | hsivonen: can you explain why in old Firefox (3.6) the iframe gets rendered? <style>*{font-family:'</style <iframe onload=alert(1)//';</style> |
| 20:00 | <matjas> | i understand why `</style` followed by space acts as end tag for the <style> element |
| 20:02 | <Ms2ger> | matjas, treating the < as part of the tag name is an IEism, Gecko would imply a > when seeing a < |
| 20:06 | <Wilto> | So this is where you get your dark and arcane secrets, matjas. |
| 20:06 | <matjas> | HTML5 parsers seem to discard the iframe in <style>*{font-family:'</style <iframe onload=alert(1)>';</style> |
| 20:07 | <matjas> | not sure I understand why though |
| 20:07 | <Ms2ger> | Because it's an attribute in an end tag |
| 20:07 | <matjas> | i thought </style + space = ETAGO, which would close the element |
| 20:08 | <matjas> | but it only does so after the >, i see |
| 20:08 | <matjas> | that makes sense |
| 20:08 | <matjas> | thanks Ms2ger :) |
| 20:08 | <Ms2ger> | ETAGO? |
| 20:16 | <matjas> | well, </ = etago |
| 20:16 | <matjas> | and </style and </script followed by a space character, >, or / will close their respective opening tag |
| 20:16 | <matjas> | i knew that much |
| 22:38 | <zewt> | This webpage has disabled automatic filling for this form. <- yeah, uh, webpages shouldn't be able to do that. heh |
| 22:39 | <zewt> | This webpage has deliberately inconvenienced you. |
| 23:36 | <Hixie> | zewt: aw man i hate that |
| 23:36 | <Hixie> | zewt: i made sure to spec autocomplete="off" as optional, but no browser lets me override it as far as i can tell :-( |