| 00:17 | <Hixie> | hsivonen_: really unuseful error message: it told me that on line 60000, when it hit the </body>, it had some unclosed elements |
| 00:17 | <Hixie> | hsivonen_: which ones? what lines did they start on? |
| 00:18 | gsnedders | needs to be less good at procrastinating |
| 00:22 | <Philip`> | gsnedders: You need to get better at procrastinating, so you can direct it towards tasks that weren't worth doing anyway |
| 00:28 | <xydyx> | probably similar to http://bugzilla.validator.nu/show_bug.cgi?id=440 |
| 00:35 | <Hixie> | if the people who comment on sam's blog would instead take part in the actual official mailing lists, we might drown out the nonsense on public-html with at least semi-sane discussion |
| 00:59 | <Hixie> | given the following sentence: |
| 00:59 | <Hixie> | The DOM attribute relList must reflect the rel content attribute |
| 00:59 | <Hixie> | ...can you come up with a way of phrasing it whereby it means the same as that, but by only removing characters, you can get it to mean the equivalent of: |
| 01:00 | <Hixie> | The DOM attribute relList reflects the rel content attribute |
| 01:03 | <Dashiva> | What's that s doing to cause trouble? |
| 01:05 | <Hixie> | mostly, it's grammatically required |
| 01:05 | <Hixie> | if you can get an s into the first one that works too |
| 01:07 | <gsnedders> | me gets confused by the question |
| 01:07 | gsnedders | wonders why Hixie needs that |
| 01:08 | <Hixie> | the former is what i need for the full spec, the second is what i need for the author-only spec |
| 01:08 | <Hixie> | but for QA purposes i really want to keep the second a pure subset of the former |
| 01:08 | <Dashiva> | <span class="main-spec-only">s</span> :) |
| 01:08 | <Hixie> | you mean author-spec-only? |
| 01:09 | <Hixie> | that unfortunately doesn't satisfy my "keep the second a pure subset of the former" goal :-) |
| 01:09 | <Dashiva> | You'd have the tag in both specs |
| 01:10 | <Hixie> | there is only one spec |
| 01:10 | <Dashiva> | Yes |
| 01:10 | <Hixie> | and one tag, which hides stuff from the author version |
| 01:10 | <Dashiva> | And you do the opposite with this |
| 01:10 | <Hixie> | hiding from the main version is what i'm trying to avoid |
| 01:11 | <Hixie> | because then the specs aren't a pure subset of each other |
| 01:11 | <Hixie> | and QA becomes a huge pain |
| 01:11 | <Hixie> | because you have to always check things in two specs |
| 01:11 | <gsnedders> | You need a script that magically fixes grammar issues, while removing RFC2119 keywords :P |
| 01:12 | <Dashiva> | "must always be in a state where it reflects" |
| 01:12 | <Hixie> | hm, interesting approach |
| 01:13 | gsnedders | tweets his feelings |
| 01:13 | <Dashiva> | I don't think it's possible to do without looking silly |
| 01:13 | <Hixie> | Dashiva: so i fear |
| 01:13 | Hixie | types /invite gsnedders into his #twitter channel |
| 01:13 | <gsnedders> | Hixie: What do you think of that, so far, BTW? |
| 01:13 | <Hixie> | effing awesome |
| 01:14 | <Hixie> | makes twitter usable |
| 01:14 | gsnedders | used the IM interface till that died |
| 01:14 | <gsnedders> | Is it real time, or do tweets come bunched together? |
| 01:14 | <Hixie> | having the same interface for msn, yahoo, aim, icq, jabber, freenode, moznet, w3net, quakenet, operanet, and twitter is pretty spectacularly awesometastic. |
| 01:14 | <Hixie> | gsnedders: it polls every 2 minutes |
| 01:15 | <Hixie> | or something like that |
| 01:15 | <gsnedders> | That sucks a bit. |
| 01:15 | <Hixie> | feels real time |
| 01:15 | <Hixie> | since i only check irc every 2 minutes or so :-) |
| 01:15 | <Hixie> | and so far people haven't replied anywhere near that fast |
| 01:15 | <gsnedders> | :) |
| 01:16 | <Hixie> | sod it, i'll use an author-only class |
| 01:16 | <Hixie> | but it's for grammar only! |
| 01:16 | <gsnedders> | Hixie: What do you use for IM? |
| 01:16 | <Hixie> | bitlbee |
| 01:17 | <gsnedders> | Hixie: How does that show who is online? I guess you need to manually poll using ISON? |
| 01:18 | <Hixie> | when they come online they join the channel |
| 01:18 | <Hixie> | when they are away they get -v, and when they are not away they get +v |
| 01:18 | <gsnedders> | It seem a bit like trying to shoehorn things into IRC |
| 01:18 | <Hixie> | how so? |
| 01:19 | <Hixie> | i mean, it is, but it seems like a near perfect fit |
| 01:19 | <gsnedders> | Well, most IM clients have proper ways to note whether people are away or not without misusing some other feature for it |
| 01:19 | <Hixie> | if irssi did /away polling, i'd see if bitlbee supported using that instead |
| 01:19 | <Hixie> | but i prefer seeing the mode changes |
| 01:19 | <Hixie> | it works well |
| 01:20 | <Hixie> | and it works in all im clients |
| 01:20 | <Hixie> | er, irc clients |
| 01:20 | <Hixie> | Dashiva: i can;t use the class actually, because then it means you must use css to view the spec |
| 01:20 | <Dashiva> | <del>s</del> :P |
| 01:21 | <Hixie> | uh huh |
| 01:23 | <Hixie> | one option is to go through and change all the uses of the term reflect to be definitions instead of requirements |
| 01:23 | <Hixie> | and move the requirement to the definition of "Reflect" |
| 01:23 | <Hixie> | but that would be a huge pain |
| 01:24 | <Dashiva> | A one-time pain? |
| 01:24 | <Hixie> | all of this is a one-time pain |
| 01:24 | <Hixie> | the easier option is to hide the entire paragraph and use a domintro thingy instead |
| 01:24 | <Hixie> | another option is to say that all attributes that are omitted reflect by default |
| 01:25 | <Dashiva> | One-time as in it won't hurt if you write new sections, since the pain is only rewriting and not writing. |
| 01:25 | <Hixie> | yes |
| 01:25 | <Hixie> | i dunno if it's a good idea though |
| 01:28 | gsnedders | plays around with BitlBee |
| 01:30 | <gsnedders> | Heh |
| 01:30 | gsnedders | realizes everyone is away on IM |
| 01:40 | <Hixie> | ok problem solved |
| 01:40 | <Hixie> | i'll just hide all these paragraphs and rely on a summary table that future ian will write |
| 01:51 | <MikeSmith> | heh |
| 01:51 | <MikeSmith> | does future Ian have a lot more time on his hands than existing Ian? |
| 01:53 | <Hixie> | actually yes |
| 01:53 | <Hixie> | future ian has a whole week in august for writing summary tables |
| 02:32 | <annevk> | should HTML5 say that the initial value of font-size is 16px ? |
| 02:32 | <annevk> | oh, I suppose medium is good enough |
| 02:48 | <annevk> | I realize quibbling about exceptions is pedantic and near useless but I think insertAdjacentHTML() should throw HIERARCHY_REQUEST_ERR and not NO_MODIFICATION_ALLOWED_ERR |
| 02:54 | <deltab> | ohh, pretty: (insertAdjacentHTML docs) http://msdn.microsoft.com/en-us/library/aa170709(office.11).aspx |
| 03:06 | <gsnedders> | Writing to-do lists in unreadable hand-writing is not a good idea. |
| 03:08 | deltab | notes: improve handwriting to point of legibility |
| 03:10 | <deltab> | actually I'm trying out a program called NoteCase |
| 04:07 | <jwalden> | Hixie: another redirect loop for you, just noticed in reader: http://pastebin.mozilla.org/630108 :-) |
| 05:41 | <gsnedders> | hsivonen_: You have any validator tests? |
| 05:41 | <gsnedders> | (I guess yes, where?) |
| 06:52 | <annevk> | http://eligrey.com/2009/03/03/apng-feature-detection/ hmm; a data: URL should not do that :/ |
| 07:03 | <hsivonen> | gsnedders: there are old and incomplete tests at http://syntax.whattf.org/relaxng/tests/ |
| 07:04 | <hsivonen> | gsnedders: there's also a testing framework without tests waiting for a go-ahead from Hixie & the HTML WG that the conformance definition has stabilized |
| 07:04 | <hsivonen> | gsnedders: given http://intertwingly.net/blog/2009/02/25/Safari-and-Standards , I'd expect a bit of a shake-up still |
| 07:41 | <olliej> | hsivonen: who is it who is writing the html5 validator? |
| 07:41 | <annevk> | it is hsivonen |
| 07:41 | <olliej> | annevk: i thought so, but i figured i'd ask to be safe :D |
| 07:47 | <hsivonen> | there are other code contributors |
| 07:52 | <hsivonen> | Hixie: does the frameset-ok stuff clone any particular browser? |
| 07:55 | hsivonen | sees that frameset-ok matches WebKit but not Gecko |
| 07:56 | <hsivonen> | matches Opera, too |
| 07:57 | <hsivonen> | actually, doesn't match either of those exactly |
| 07:57 | <hsivonen> | weird |
| 07:57 | hsivonen | starts IE8 |
| 08:02 | <olliej> | hsivonen: i was actually going to ask about the apple.com/safari results -- it's claiming required attributes are missing on script nodes, and text is not allowed inside <script>, and i'm like "what?" (bare in mind i don't know any of the markup related stuff in html5) |
| 08:02 | <hsivonen> | olliej: yeah, noted, that sucks |
| 08:03 | <hsivonen> | olliej: artifact of RELAX NG validation |
| 08:03 | <olliej> | hsivonen: oh? |
| 08:03 | <olliej> | hsivonen: so is the script thing a validator or page bug? |
| 08:03 | <olliej> | hsivonen: eg. should i be harassing people |
| 08:04 | <annevk> | olliej, if the script is inline charset is not allowed |
| 08:05 | <annevk> | olliej, the other errors should be obvious |
| 08:05 | <hsivonen> | olliej: the page is in error, but the lousy error message is an artifact of RELAX NG validation |
| 08:05 | <hsivonen> | olliej: the charset attribute causes the RELAX NG engine to accept the linked script derivation |
| 08:06 | <olliej> | annevk: ah ha, you mean no putting utf16 inside the script tags of a utf8 document? how boring |
| 08:06 | <olliej> | ;D |
| 08:06 | <hsivonen> | olliej: then it sees that src is missing, so it complains |
| 08:06 | <hsivonen> | olliej: then it sees the element has text content, so it complains about that, too |
| 08:06 | olliej | pokes people |
| 08:06 | <olliej> | hsivonen: yeah |
| 08:06 | <olliej> | once i know the start error, it's easy to see how the waterfall starts |
| 08:07 | <olliej> | hsivonen: still not as bad as c++ template errors :D |
| 08:07 | <hsivonen> | :-) |
| 08:07 | <Philip`> | Someone should make a validator.nufilt program |
| 08:07 | <annevk> | or a validator fully based on custom code |
| 08:08 | <hsivonen> | or get the Oxygen Jing patches landed on the Jing trunk and then synced to the V.nu branch |
| 08:08 | <hsivonen> | or better yet, get the Jing trunk to implement all the features V.nu needs |
| 08:09 | <hsivonen> | or by moving various attribute co-occurrence constraints to custom code |
| 08:10 | <hsivonen> | fwiw, for ARIA, I have a hack that permutes the attribute array such that the role attribute always comes before the states and properties to make Jing commit to the derivation on role making the rest of errors sane |
| 08:10 | <MikeSmith> | off-the-shelf error messages from Jing are near useless, just at they are in sp (SGML-based thing that validator.w3.org relies on); same guy wrote both libraries, so... |
| 08:11 | <hsivonen> | MikeSmith: I intend to check in your patches today |
| 08:11 | <MikeSmith> | hsivonen: cool, but no hurry |
| 08:12 | <MikeSmith> | I'd reckon you probably got something more important you're working on |
| 08:12 | <MikeSmith> | but would be cool to have them upstream |
| 08:12 | <MikeSmith> | may still be a couple of element or attribute changes that Hixie made recently but I missed |
| 08:13 | <MikeSmith> | (btw) |
| 08:13 | <Hixie> | hsivonen: IE, iirc, modulo craziness |
| 08:26 | <hsivonen> | Hixie: actually, it seems the frameset-ok stuff matches Opera modulo craziness |
| 08:26 | <hsivonen> | and is roughly similar to WebKit |
| 08:26 | <hsivonen> | the DOM I get in IE8 is much crazier, but maybe it renders sanely. dunno |
| 08:27 | <hsivonen> | Hixie: should I expect frameset-ok to be stable except for editorial changes of making it a mode? |
| 08:28 | <hsivonen> | Hixie: fwiw, I implemented it as a mode |
| 08:28 | <hsivonen> | Hixie: did less damage to (expected) perf that way |
| 08:28 | <hsivonen> | (didn't measure) |
| 08:28 | <Hixie> | k |
| 08:29 | <hsivonen> | so currently, the V.nu parser diverges from test cases on 4 points |
| 08:29 | <hsivonen> | 1) new AAA |
| 08:29 | <hsivonen> | 2) frameset-ok |
| 08:29 | <hsivonen> | 3) taint |
| 08:29 | <hsivonen> | 4) </body> and </html> in head |
| 08:30 | <hsivonen> | I hope #1 and #2 are now settled enough to update test cases? |
| 08:33 | <Hixie> | man have y'all seen this crazy idea that text/html with a <svg> tag at the start should create an SVG document? |
| 08:34 | <heycam> | Hixie, is this the one in our wiki page? |
| 08:34 | <Hixie> | yeah |
| 08:34 | <Hixie> | the svg group have gone from being scared of text/html to wanting to have it as a primary serialistion for svg |
| 08:34 | <heycam> | :) |
| 08:35 | <heycam> | so that proposal is to solve that problem with the svg sizing and scripting thing |
| 08:35 | <Lachy> | heycam, where's the evidence that it's a real problem? |
| 08:35 | <heycam> | but i'm not sure how to get around the problem of not having a <body> somewhere to pop back up to |
| 08:35 | <Lachy> | and the justification for why we should attempt to address it? |
| 08:36 | <heycam> | Lachy, you can't serve svg as text/html to current browsers, so it's speculation of course |
| 08:36 | <hsivonen> | Hixie: do you mean that <svg> as the first tag should not imply <html>, <head> and <body>? |
| 08:36 | <annevk> | which wiki page? |
| 08:36 | annevk | would like a loose SVG serialization |
| 08:36 | <Hixie> | hsivonen: yeah |
| 08:36 | <annevk> | would make it way easier to write simple graphics |
| 08:36 | <heycam> | annevk, the one that svg wg is using for staging our svg in text/html reply |
| 08:36 | <Hixie> | heycam: which problem? |
| 08:36 | <annevk> | no need for xmlns and other stuff :) |
| 08:37 | <annevk> | heycam, pointer handy? |
| 08:37 | <heycam> | Hixie, the problem that <svg> would be placed under body and because of css rules would get rendered with 150px height |
| 08:37 | <heycam> | instead of filling the viewport |
| 08:37 | <Hixie> | heycam: ? |
| 08:37 | <Hixie> | heycam: which <svg> |
| 08:37 | <hsivonen> | annevk: http://www.w3.org/Graphics/SVG/WG/wiki/SVG_in_text-html_2009 |
| 08:37 | <heycam> | http://www.w3.org/mid/20090303002433.GC17647⊙amia |
| 08:37 | <heycam> | Hixie, the root svg |
| 08:38 | <Hixie> | heycam: what root svg. text/html is for HTML documents, why would there be a root svg? |
| 08:38 | <heycam> | because people will mistakenly serve a whole svg document as text/html |
| 08:38 | <heycam> | they will paste svg in as a whole something.html file |
| 08:38 | <Lachy> | heycam, do they do that now? |
| 08:39 | <heycam> | Lachy, no, because there are no browsers that do svg in text/html |
| 08:39 | <Hixie> | heycam: people will put <html> elements as children of <svg>, but we're not asking the svgwg to change their rendering rules to handle html :-) |
| 08:40 | <hsivonen> | Hixie: I think this idea is worth researching for feasibility given existing content |
| 08:40 | <heycam> | no, but then xml is of course more constrained about that sort of thing |
| 08:40 | <heycam> | so a whole svg document server as html will sort of work but not be sized properly |
| 08:40 | <Hixie> | it'll be invalid |
| 08:40 | <Hixie> | missing <title>, for one |
| 08:40 | <heycam> | if it's possible to tweak how the parser treats it so that it works, then i think we should consider that |
| 08:40 | <Hixie> | and DOCTYPE |
| 08:40 | <Philip`> | body > svg:only-child { width: 100%; height: 100% } - easily fixed :-) |
| 08:41 | <Lachy> | annevk, so the problem you're trying to solve seems to be different from what the SVG WG have described. Namely, that you want non-draconian parsing and easier namespaces for XML |
| 08:41 | <hsivonen> | Hixie: we could make <svg> trigger stardards mode if the first tag token |
| 08:41 | <heycam> | Philip`, so have that as suggested UA style sheet? |
| 08:41 | Hixie | thinks this whole idea is ludicrous |
| 08:41 | <Lachy> | and you think using text/html as a hack to achieve that is good enough? |
| 08:41 | <Philip`> | (I have no idea if that would actually fix the sizing issue, or if it would even be sane) |
| 08:41 | <Hixie> | it's text/html, not text/svg |
| 08:42 | <heycam> | brb phone |
| 08:42 | <hsivonen> | Hixie: I think the idea isn't prima facie crazy |
| 08:42 | <hsivonen> | Hixie: I am worried about an <?xml slippery slope for charset sniffing, though |
| 08:42 | <Hixie> | i think it would make sense if we were not in a Content-Type world |
| 08:42 | <Hixie> | but we are |
| 08:43 | <Lachy> | Hixie, it gets worse when you realise that they want the <svg> to trigger standards mode, and then have it switch to quirks mode and employ adoption agency like behaviour to change the root to HTML in the event of an error, like trailing HTML after the </svg> |
| 08:43 | <hsivonen> | Hixie: is application/xml in a content type world? |
| 08:43 | <Hixie> | if a document is labeled as text/html, it means it's HTML, not some sort of dumping ground for every wg that picked the wrong serialisation format |
| 08:43 | <Philip`> | Extend the content-sniffing algorithm to interpret documents starting with "<svg" as image/svg+xml or whatever it is |
| 08:43 | <heycam> | "and then have it switch to quirks mode and employ adoption agency like behaviour to change the root to HTML in the event of an error" -- not sure we asked for that |
| 08:43 | <annevk> | Philip`, width:100vw and height:100vh would do the trick prolly along with absolute positioning |
| 08:43 | <heycam> | just noted that the fact that there's no <body> would be a problem that we don't have a good solution for atm |
| 08:43 | <annevk> | Philip`, 100% would not work and you would not want quirks mode either |
| 08:43 | <Hixie> | hsivonen: application/xml has a coherent (if not particularly wonderful) vocabulary dispatch mechanism |
| 08:43 | <Lachy> | Philip`, we've already done that for RSS and Atom. That's bad enough already |
| 08:44 | <heycam> | yeah i'm not sure it'd be a good idea for it to be sniffed as image/svg+xml |
| 08:44 | <hsivonen> | Hixie: the difference between SVG and every working group is that SVG has serious implementation on the higher layers of three of the top four Web engines |
| 08:44 | <heycam> | applicateion/please-guess-the-type-for-me |
| 08:45 | <hsivonen> | octet-stream |
| 08:45 | <Hixie> | hsivonen: so? |
| 08:45 | <heycam> | well, if only octet-stream didn't in reality mean "pop up a download window" |
| 08:46 | <Hixie> | unknown/unknown is treated as "guess for me" in the mime-sniff spec |
| 08:46 | <Philip`> | heycam: I thought that was what no-Content-Type-header-at-all was for |
| 08:46 | <hsivonen> | Hixie: it's more worthwhile to bring SVG over to the text/html serialization world |
| 08:46 | <Philip`> | (please-guess-the-type-for-me, that is) |
| 08:46 | <hsivonen> | (unless, of course, full-blown RDF/XML in <metadata> comes as a rider) |
| 08:46 | <heycam> | Philip`, quite possible (i'm no expert on such things) |
| 08:47 | <heycam> | hsivonen, that's not something we're pushing for |
| 08:47 | <Hixie> | hsivonen: i'm all for XML5-like ideas, but there's a difference between that and overloading text/html to mean "this could be an HTML doc or an SVG doc maybe" |
| 08:48 | <hsivonen> | Hixie: anyway, I don't have an informed opinion about <svg> root yet, but I think it's not prima facie crazy and is worth researching for feasibility |
| 08:48 | <heycam> | Hixie, so we don't definitely want document.documentElement to be <svg>, we just want to solve the problems |
| 08:48 | <heycam> | if default UA styling can fix that... |
| 08:49 | <heycam> | script would need to be changed, still |
| 08:49 | <Philip`> | If it's not prima facie crazy, that makes it inconsistent with the rest of the web platform |
| 08:49 | <Hixie> | hsivonen: oh i think it's pretty clear that it's not really feasible in practice, i mean, even if there's only a few HTML docs that start with <svg>, we wouldn't want a format that changed so radically based on a the presence or absence of two BOMs at the start, for instance |
| 08:49 | <Hixie> | heycam: i really don't understand the problem. |
| 08:50 | <Hixie> | heycam: since when has the svg worried about errors being handled gracefully? |
| 08:50 | <Hixie> | heycam: you do realise that SVG's default serialisation will show a fatal error for the slightest syntax error, right? |
| 08:50 | <heycam> | given that graceful error handling is what we'll get by having svg in text/html, it makes sense to try and reduce paint points related to that error handling where practicable |
| 08:51 | <hsivonen> | for perf reasons, I really don't want to make the tokenizer case-preserving. particularly not for tokens that are a case-insensitive match with a well-known token name |
| 08:51 | <Hixie> | heycam: wouldn't that argue for allowing case-insensitive tag names too? |
| 08:51 | <heycam> | Hixie, i don't think we've said we want to make incorrect-case tag names not work |
| 08:52 | <heycam> | (with our current proposal in development anyway) |
| 08:52 | <Hixie> | heycam: i don't see how incorrect case tag names could work without the table |
| 08:52 | <heycam> | hsivonen, if you could elaborate on those perf reasons, when we get to officially send our comments, that'd be helpful |
| 08:52 | <hsivonen> | heycam: it's easier to make the incorrect case well-known tokens to work than to preserve case |
| 08:52 | <hsivonen> | heycam: I think I've elabored on it in the long email I sent about the previous proposal |
| 08:52 | <Hixie> | hsivonen actually already commented in detail on the perf reasons in response to the svg group's last proposal, iirc |
| 08:53 | <Hixie> | ok i'm just 500ms slower than hsivonen reliably today, it seems |
| 08:53 | <hsivonen> | heycam: but basically, it comes to early token interning and having static pre-interned tokens for all well-known names |
| 08:53 | <heycam> | Hixie, the implementation of course would need a table to map them. but organisationally, it's not good if we need to edit html to make a new svg element work. |
| 08:53 | <heycam> | hsivonen, ok i'll dig it up |
| 08:54 | <Hixie> | editing html to add a new tag name or attribute takes all of 10 seconds |
| 08:54 | <hsivonen> | heycam: organizational reasons are bad reasons to foil code optimizations, though |
| 08:54 | <heycam> | now, yes, but when it's not a WD? |
| 08:54 | <heycam> | hsivonen, i don't want code optimizations to be foiled by having the table removed |
| 08:54 | <Hixie> | it'll be a wd until 2022, and html6 will be a wd before that's over, i expect |
| 08:54 | <Hixie> | so... |
| 08:55 | <Hixie> | we could put it on a wiki though :-) |
| 08:55 | <heycam> | the point about the table is merely about the svg wg being able to mint new element/attribute names and for implementations to be able to support them in text/html without having to edit the html spec |
| 08:55 | <Hixie> | implementations have never been beholden to what the spec says in the past :-) |
| 08:55 | <heycam> | guess we can all go home now then and save the effort :) |
| 08:56 | <hsivonen> | My preferred way forward is SVG deciding not to mint new names with upper-case ASCII letters. My second-preferred solution is SVG being able to amend the case fix-up tables without having to respin HTML through the REC process. |
| 08:56 | <heycam> | hsivonen, there is agreement in the group to avoid uppercase letters |
| 08:56 | <annevk> | Hixie, we could just defer to an SVG spec right? |
| 08:56 | <heycam> | as i pointed out somewhere recently though, e.g., introducing new filter primitive element names that are all lower case could be very confusing |
| 08:57 | <hsivonen> | heycam: cool |
| 08:57 | <heycam> | annevk, exactly. and it doesn't even need to be The SVG Spec, it could be some small separate spec |
| 08:58 | <annevk> | a wiki page would work for me too btw |
| 08:58 | <annevk> | i like wiki pages |
| 08:59 | <Hixie> | annevk: if the svgwg committed to actually doing the research necessary before adding each tag name, maybe |
| 08:59 | heycam | wonders what happens with edit wars on spec-critical wiki pages |
| 08:59 | <Hixie> | annevk: but since their research so far has been lacking, i'm not convinced they will :-) |
| 08:59 | <Hixie> | anyway, editing html is a low-cost affair |
| 08:59 | <heycam> | Hixie, it's clear that in the past little consideration was given to adopting svg element names directly into text/html |
| 08:59 | <hsivonen> | heycam: see http://hg.mozilla.org/users/mrbkap_mozilla.com/html5parsing/file/e2713bb08d00/content/html/parser/src/nsHtml5ElementName.cpp and http://hg.mozilla.org/users/mrbkap_mozilla.com/html5parsing/file/e2713bb08d00/content/html/parser/src/nsHtml5AttributeName.cpp |
| 09:00 | <heycam> | and that now that's something we're working towards |
| 09:00 | <Hixie> | heycam: i was just thinking of the discussion recently, e.g. the suggestion to add <textArea> to the list |
| 09:00 | <Hixie> | (notwithstanding that <textArea shouldn't exist in the first place regardless of its name) |
| 09:00 | <hsivonen> | Hixie: editing HTML is lower cost that changing parsers and syncing the test suite... |
| 09:00 | <Hixie> | (but that's a whole other discussion) |
| 09:00 | <Hixie> | hsivonen: exactly |
| 09:00 | <Philip`> | heycam: I think the idea is that nobody cares enough about web standards to edit-war or vandalise or spam the relevant wiki pages |
| 09:01 | <Philip`> | heycam: which is the same idea behind having whatwg.org let any random visitor update its Twitter status |
| 09:01 | <Philip`> | heycam: (I'm not absolutely convinced this is an infallible mechanism) |
| 09:02 | <heycam> | right, i think it's demonstrably fallible if you wanted to fail it now :) |
| 09:02 | <annevk> | Hixie, if browsers agree with the SVG WG, things should be fine |
| 09:02 | <annevk> | Hixie, if stuff breaks, we can fix it |
| 09:07 | <heycam> | anyway, i'm confident that we're (svgwg and htmlwg/whatwg) getting closer on our proposals and that we'll get to an agreement at some point |
| 09:07 | <Hixie> | heycam: cool. it would be helpful if the svgwg could clarify what the perceived requirements are (as per my last e-mail on the subject), as that will definitely help in evaluating the proposals |
| 09:08 | <heycam> | perceived as in what our requirements are? |
| 09:09 | <Hixie> | as what the svgwg thinks the requirements are, yes (as opposed to what i think the requirements are based on feedback within the htmlwg) |
| 09:09 | <Hixie> | as in |
| 09:09 | <annevk> | gtg |
| 09:10 | <heycam> | probably there are still a couple missing for that wiki page; it'll get fixed up by the time we send our Official E-mail |
| 09:10 | <heycam> | (which'll be soon) |
| 09:14 | <Hixie> | hsivonen: all four of the things you mentioned as far as test case variations are things that should be stable enough, though the spec still needs fixing for 2 (to mode), 3, and 4; i hope to do that sometime this month |
| 09:14 | <Hixie> | heycam: i meant high-level requirements |
| 09:15 | <Hixie> | heycam: like "it must be possible to embed svg in html" |
| 09:15 | <Hixie> | heycam: or "syntax errors must be caught and must not work" |
| 09:15 | <Hixie> | or whatever |
| 09:15 | <hsivonen> | Hixie: do you mean you are going to revert the </body> and </html> in head rev? |
| 09:15 | <Hixie> | hsivonen: wasn't that one of the things you raised as an issue? |
| 09:16 | <hsivonen> | Hixie: do you mean the spec is going to adopt WebKit-style taintless foster parenting? |
| 09:16 | <Hixie> | hsivonen: wasn't that what you concluded would be best? |
| 09:16 | <hsivonen> | Hixie: yes to both :-) |
| 09:16 | <Hixie> | well then probably :-) |
| 09:16 | <hsivonen> | cool. Thanks |
| 09:16 | <Hixie> | to both :-) |
| 09:17 | <Hixie> | i tend to do whatever implementors say, especially when they're actually coding it :-) |
| 09:17 | <Hixie> | i find it increases the odds of the specs matching implementations dramatically |
| 09:19 | <Hixie> | who are the active whatwg blog admins these days? |
| 09:19 | <Hixie> | lachy and jgraham? |
| 09:23 | <Hixie> | ooh, the admin site got prettier |
| 09:28 | <Hixie> | oooh, admin graphs |
| 09:28 | <Hixie> | with ham |
| 09:28 | <Lachy> | Hixie, me |
| 09:28 | <Hixie> | too late, i already mailed the list |
| 09:29 | <virtuelv> | hm - http://intertwingly.net/blog/2009/03/03/Interesting-Times |
| 09:30 | <Lachy> | ok, I think jgraham is also an admin, as is hsivonen, markp, annevk and a few others |
| 09:30 | <Hixie> | yeah, i checked the list :_) |
| 09:30 | <Lachy> | oh |
| 09:30 | <Hixie> | first list = mailing list, second list = admin users page, just for clarity |
| 09:36 | <Lachy> | Hixie, btw, there are instructions on the blog for how to post http://blog.whatwg.org/submit-article |
| 09:36 | <Hixie> | oh, cool |
| 09:36 | <Hixie> | oh hey look at that, it's even right there at the top |
| 09:37 | <Hixie> | is there no way to make it come before the copyright link? |
| 09:37 | <Hixie> | nobody cares about the copyright |
| 09:39 | <Hixie> | (i did try to do it myself, for the record! :-) ) |
| 09:45 | <Lachy> | I don't know how |
| 09:45 | <Hixie> | oh well |
| 09:45 | <Hixie> | no worries |
| 09:45 | <Lachy> | done |
| 09:46 | <Lachy> | there's an order setting in the page editor |
| 09:48 | jgraham | considers blogging to ask for a new theme |
| 09:48 | <Lachy> | we did have a volunteer once. I don't know what happened to that |
| 09:49 | <jgraham> | Clearly nothing useful because the blog is still f— ugly |
| 09:55 | <Lachy> | jgraham, we could also try using 99designs.com if we don't get any volunteers to do it for free. But that would cost a little to run the competition there |
| 09:55 | <Lachy> | I'm going to be using that to get a redesign for my site |
| 09:57 | <Philip`> | Aren't there a zillion free themes available, of which at least one must be decent? |
| 09:57 | <Lachy> | Philip`, feel free to find one |
| 09:58 | <Philip`> | I never read the blog so I don't care enough to find one :-p |
| 09:58 | <Philip`> | and I don't mind the current theme anyway |
| 09:58 | <hsivonen> | are there test cases already to go with HTML5 frameset parsing? |
| 09:58 | <hsivonen> | (the kind of test cases one can try in a browser) |
| 10:00 | <hsivonen> | are the Epson and HP CSS formatters independent of any better-known code bases? |
| 10:02 | <Hixie> | i believe hp's is, dunno about epson |
| 10:02 | <Hixie> | fantasai might know more about hp's |
| 10:02 | <hsivonen> | ok |
| 10:03 | Hixie | gets to the sections section of the spec in his Big Author Spec Effort |
| 10:05 | <hsivonen> | http://www.w3.org/mid/49ADD04B.4010206⊙vnn |
| 10:05 | <hsivonen> | (V.nu should be fine in Opera Mini and other mobile UAs that support media queries) |
| 10:06 | <Hixie> | Lachy: does the selectors api test suite test dynamic modifications to the dom? |
| 10:07 | <hsivonen> | "emerging nations" hmm. |
| 10:16 | <Lachy> | Hixie, I'm not sure. |
| 10:17 | <Hixie> | k |
| 10:21 | <Hixie> | Lachy: what does "subtrees" mean in your spec? |
| 10:21 | <Hixie> | (in particular, how do i tell if foo.querySelector('*') should return foo or foo.firstChild or something else?) |
| 10:21 | <Hixie> | er, firstChildElement, i guess |
| 10:23 | <Lachy> | Hixie, that question has been asked so many times. Isn't the spec clear enough?! |
| 10:23 | <Hixie> | oh, found the definiton |
| 10:23 | <Hixie> | i only looked in the terminology section |
| 10:24 | <Hixie> | and didn't see the one in the prose because it came out all garbled due to some charset issue |
| 10:24 | <Hixie> | ok, so the node isn't included, got it |
| 10:26 | <Lachy> | Hixie, that example also explains why it isn't included, becuase having foo.querySelector("*") return foo would be useless |
| 10:26 | <Hixie> | yes |
| 10:26 | <Hixie> | you should hyperlink your terms so that it's obvious they're terms :-) |
| 10:27 | <Lachy> | hmm, that's weird. I don't know why they're not hyperlinked |
| 10:31 | <Lachy> | Hixie, fixed |
| 10:34 | <Hixie> | stweet |
| 10:34 | <Hixie> | sweet, even |
| 10:45 | <Hixie> | what are the browsers that we have interop on? |
| 10:49 | <Hixie> | Lachy: is there an implementation report? |
| 10:50 | <Lachy> | Hixie, there were emails on public-webapps that described the implementations status |
| 10:51 | <Lachy> | WebKit passes everything except querySelector() with no parameters. Mozilla passes everything except querySelector(null) |
| 10:52 | <Lachy> | Internally, we fail :checked, :enabled and :disabled tests on disconnected elements. We have patches that should allow us to pass the null/undefined, but I haven't yet got a build with those patches yet |
| 10:52 | <Hixie> | man, there's really not much to test in querySelector |
| 10:53 | <Hixie> | it's a tiny tiny spec |
| 10:53 | <Lachy> | and Travis sent an email describing IE's failures |
| 10:53 | <Lachy> | sure, but given it's size, we still managed to get over 2000 tests |
| 10:54 | <Lachy> | and people laughed when we said we'd need 20,000 for HTML5 :-) |
| 10:55 | <Hixie> | we'll need 20,000 tests for HTML5 in a reckoning that considers what we have for Selectors API to be 1 test. :-) |
| 10:55 | <Hixie> | but yes, i am impressed at the coverage |
| 10:57 | <Philip`> | I guess most of the Selectors test complexity is in how it interacts with everything in the CSS spec? |
| 10:57 | <Hixie> | yeah it's really mostly a selectors test suite |
| 10:58 | Hixie | adds 85 test assertions to the pile |
| 10:58 | <Hixie> | i'm very impressed at how hard it was to find new bugs |
| 10:58 | <Philip`> | so it doesn't seem entirely valid to assume the number of tests vs size of Selectors API spec will correspond to any other testable feature |
| 10:58 | <Hixie> | there's just not much to test! |
| 10:58 | <Hixie> | and not because the spec is vague, either |
| 10:59 | <Hixie> | Philip`: right, hence my comment above (that it would count as one test in the reckoning that results in 20,000 tests) |
| 11:02 | <Philip`> | Hopefully most of the rest of those 20,000 will be features that aren't dependent on large chunks of other very large specs, so it won't end up being 400,000 test cases in total |
| 11:03 | <Hixie> | html5 depends on large chunks of http, dom core, dom events, unicode, and other specs |
| 11:03 | <Hixie> | i could well see us having tests that check something for every unicode character |
| 11:03 | <Hixie> | or even combinations thereof |
| 11:06 | <Philip`> | Given the overhead involved in loading an HTML document, hopefully the tests for every Unicode character would be folded into a single test case in a single file |
| 11:06 | <Hixie> | that's what i mean |
| 11:06 | <Hixie> | it'd be one test |
| 11:06 | <Philip`> | (Hmm, that reminds me that some Mozilla people were complaining about the canvas tests taking too long to run, so I ought to merge them all into a single file...) |
| 11:06 | <Lachy> | no, I want 65536 files, each testing a single unicode character :-) |
| 11:06 | <Hixie> | but by the reckoning used to get to 2000 tests for selectors api, it would be counted as 65000+, which is silly imho :-) |
| 11:06 | <Philip`> | Lachy: Don't forget non-BMP characters |
| 11:07 | <Lachy> | I don't care about such characters |
| 11:07 | <Hixie> | they're a great source of bugs! |
| 11:07 | <Hixie> | as a qa person, you should care :-P |
| 11:07 | <Philip`> | Oh, what reckoning does the Selectors API test use, then? |
| 11:07 | <Hixie> | Philip`: test assertions |
| 11:07 | <Philip`> | Is it every single assert() call or something? |
| 11:07 | <Philip`> | Ah, right |
| 11:07 | <Hixie> | as far as i can tell, yes |
| 11:07 | Philip` | assumed otherwise |
| 11:07 | <Hixie> | i only found one actual file |
| 11:07 | <Hixie> | i've now added two more, with 80 or so assertions |
| 11:07 | <Philip`> | In that case, I have thousands and thousands of canvas tests |
| 11:08 | <Hixie> | right, that's what i mean |
| 11:08 | <jgraham> | The problem with tests taht loop over 0X10FFFF characters is that they take rather a long time to run :( |
| 11:08 | <Hixie> | jgraham: you can skip over most and just check the interesting ones, e.g. all of planes 3-14 or so are blank right now and highly unlikely to act differently |
| 11:08 | <Hixie> | so you can just spot check them |
| 11:09 | <Philip`> | 512 test cases to make sure the stack is large enough, 1024 test cases to make sure getImageData returns the right pixels, etc |
| 11:09 | <jgraham> | Hixie: Even so, just looping over the whole BMP can be rather slow |
| 11:09 | <Hixie> | well again, you can skip large chunks using just spot-checking |
| 11:10 | <Philip`> | jgraham: It's only a million, and computers are really really fast |
| 11:10 | <jgraham> | That alays raises the possibility that you chose the wrong spots |
| 11:10 | <Lachy> | what are you adding test assertions to? |
| 11:10 | <Hixie> | so long as each test spot checks different characters, you'll get good probablity of catching whatever bugs there are |
| 11:10 | <Hixie> | Lachy: see main to public-webapps |
| 11:10 | <Hixie> | |
| 11:10 | <Hixie> | anyway what matters isn't the number of tests but the number of _bugs_ |
| 11:11 | <Hixie> | it always bugs me as a QA person when someone says "i wrote 100000000 tests!" -- if they found zero bugs, and i write one test and find a bug, then i did a better job as a qa person. |
| 11:11 | <Philip`> | Not if they found zero bugs when writing the tests but are going to find two bugs in the future when someone introduces a regression |
| 11:12 | <Hixie> | (the metric that matters is the number of bugs you found per unit time, per engineer that isn't already saturated with bugs, weighted to bug seriousness) |
| 11:12 | <Hixie> | Philip`: one bug now is better than two bugs later |
| 11:12 | <jgraham> | A bug in the hand? |
| 11:12 | <Hixie> | Philip`: though i agree that many bugs later is better than few bugs now |
| 11:13 | <Hixie> | Philip`: but in practice the tests that find bugs later also find bugs now |
| 11:13 | <Hixie> | Philip`: it's rare for a huge test suite that found no bugs to actually find as many regressions later as a test suite that tests things that were actually broken when the tests were written |
| 11:13 | <Hixie> | Philip`: note that i'm not saying you should throw away tests that don't fail |
| 11:14 | <Hixie> | Philip`: i'm just saying that the best qa person only writes tests that fail, because they just are amazingly lucky / skilled and they find bugs intuitively |
| 11:14 | <jgraham> | Hixie: I guess there is sme danger of always trying to look for "evil", likely to fail cases |
| 11:14 | <jgraham> | and not spending enough time ensuring that trivial cases work as expected |
| 11:15 | <Hixie> | some of the best qa people i found for crash bugs would log onto a computer, run the program they were supposed to test, and the program would crash, despite it never crashing for anyone else in the dev team. |
| 11:15 | <Philip`> | You could bribe the developers to write really rubbish code so that you can find lots of bugs with every test case, so you look really good on your end-of-year progress reports |
| 11:15 | <Hixie> | jgraham: right, you have to weigh it by seriousness of bug |
| 11:15 | <Lachy> | Hixie, it's impossible to write only tests that fail, since you need to write the tests to discover if they fail first |
| 11:16 | <Lachy> | or have prior knowledge, based on, e.g., a site that demonstrates the bug |
| 11:16 | <Philip`> | Lachy: Or be lucky |
| 11:16 | <Hixie> | Philip`: oh it's trivial to game any metric here, yes. |
| 11:16 | <Philip`> | Lachy: or be good at guessing where problems are likely to occur |
| 11:16 | <jgraham> | Philip`: Still pretty much impossible to find only cases that fail |
| 11:16 | <Hixie> | Lachy: in practice, really good qa people have an intuition which just leads to them writing test cases that find bugs at an unlikely rate |
| 11:17 | <Lachy> | somehow I managed to find a relatively high proportion of bugs when I was testing transitions recently. About 60 or so tests, found roughly a dozen bugs |
| 11:17 | <Hixie> | not bad |
| 11:17 | <Philip`> | jgraham: It seems pretty trivial actually - just think of something that's almost certainly going to fail, write a single test case, and now you've written only test cases that fail |
| 11:18 | jgraham | notes that there are other strategies like writing fuzzers |
| 11:18 | <Hixie> | again, fuzzers come in good varieties and bad varieties |
| 11:18 | <Hixie> | you can write a bad fuzzer that doesn't actually fuzz anything useful |
| 11:19 | <jgraham> | Hixie: Of course |
| 11:19 | <Hixie> | or you can write a fuzzer that just hits every single bit that is going to screw things up |
| 11:19 | <Hixie> | good qa people have an intuition for writing the latter |
| 11:19 | Philip` | wrote a floating-point maths fuzzer that accidentally found a security vulnerability in Firefox |
| 11:20 | <Philip`> | (Well, I suppose it wasn't really a fuzzer, it was just a thing that tried a lot of combinations of stuff) |
| 11:20 | <Philip`> | (and didn't do anything random) |
| 11:20 | <jgraham> | Philip`: Interesting. Is it avaliable? |
| 11:22 | <Philip`> | jgraham: The code? |
| 11:22 | <jgraham> | Philip`: Yes. I don't care about the security vunerability |
| 11:22 | <jgraham> | ;) |
| 11:22 | jgraham | does not plan to make a botnet from out-of-date firefox installs |
| 11:23 | <Hixie> | hsivonen: 66931.2-66931.8: error: End tag for "body" seen but there were unclosed elements. |
| 11:23 | <Hixie> | hsivonen: ...is not a useful error message :-P |
| 11:25 | <Philip`> | jgraham: I think http://philip.html5.org/misc/fp-test/ was it |
| 11:26 | <Philip`> | (It doesn't really test stuff, it just prints output that you can compare between implementations) |
| 11:26 | <Philip`> | (or between the same implementations with different compilers and different compiler settings, which is what I was interested in) |
| 11:26 | <jgraham> | Philip`: Thanks |
| 11:30 | jgraham | never feels good after conversations about the qualities of a good $X |
| 11:33 | <Philip`> | Replace "good" with "implausibly ideal" and you won't have to worry about it so much :-) |
| 11:34 | <jgraham> | Philip`: But usually an impluausibly ideal $X would have superhuman powers, and these conversations never seem to involve those. So that would be lying to myself. |
| 11:34 | <jgraham> | WWhich is a natural part of the human condition but doesn't work so well if you know that you're doing it |
| 11:36 | <Philip`> | It's just an unstated assumption that a good QA engineer should be able to see through walls, leap over tall buildings and teleport to Mars |
| 11:37 | <olliej_> | Philip`: well yeah, those are standard phone screening questions though |
| 11:38 | <olliej_> | Philip`: why would you have a real interview for someone who couldn't :D |
| 11:38 | <Philip`> | The only reason these conversations never explicitly state such things is that it's just a basic assumption and not worth discussing further |
| 11:38 | <Philip`> | and it's not because people don't believe those are the requirements |
| 12:10 | <hsivonen> | heycam: what's Batik's DOM building and script running threading like? Have you considered writing a script-capable Batik-DOM tree builder subclass for the V.nu HTML Parser? |
| 12:11 | <Philip`> | http://avatraxiom.livejournal.com/97999.html - "it would be nice if this was all standardized some day" - is that relevant for HTML5? |
| 12:14 | <heycam> | hsivonen, it's not particularly web compatible |
| 12:14 | <heycam> | scripts are only run once the whole document is loaded |
| 12:15 | <heycam> | changing it to run them upon </script> would be good, but not at the top of my list of things to do... :) |
| 12:15 | <Lachy> | Philip`, that's an issue I've run into before too. Although the case I needed for is addressed by placeholder, since what I was trying to do was simulate a placeholder using a background image on the password input that said "Password", that needed to be removed when there was text in it |
| 12:16 | <heycam> | hsivonen, so subclassing the v.nu parser would get me scripts running at appropriate times? |
| 12:16 | <hsivonen> | heycam: I see. anyway, if you are interested in changing stuff, the V.nu parser core is independent of the java.io threading model and could run with java.nio in a Web-compatible way (if someone writes a java.nio IO driver) |
| 12:16 | <Lachy> | the problem I had was that when the background image was applied onload, browsers would autocomplete the field afterwards and end up with text overlaying the image |
| 12:16 | <Philip`> | Lachy: It might be important for interoperability even if there are other ways authors could achieve the same effect, I guess |
| 12:17 | <hsivonen> | heycam: the tree builder supports subclassing for custom tree back ends |
| 12:17 | <heycam> | ok. so yeah at the moment it just uses whatever jaxp supplied xml parser is available. |
| 12:17 | <Lachy> | it would have been nice if an onchange event had fired when the browsers autocompleted. |
| 12:17 | <Lachy> | I think that's what I tried first, but found that some browsers didn't fire the event |
| 12:17 | <hsivonen> | heycam: the tokenizer can be driven in a push fashion, but the current Java IO driver pulls from a java.io stream |
| 12:17 | <heycam> | hsivonen, can it do xml parsing with script running on </script>? |
| 12:18 | <hsivonen> | heycam: the V.nu HTML Parser doesn't support XML parsing at all |
| 12:18 | <heycam> | hsivonen, ah ok |
| 12:18 | <heycam> | still i guess it would be an interesting exercise to plug in an html5 parser to it |
| 12:18 | <heycam> | though i don't know what it would do with actual html elements... |
| 12:18 | <hsivonen> | heycam: I think you may get away with writing a tree back end that runs script on </script> if you don't support document.write |
| 12:19 | <hsivonen> | heycam: if you want document.write, you need a Web-compatible IO driver |
| 12:19 | <heycam> | hsivonen, ok |
| 12:19 | <hsivonen> | i.e. not the java.io one |
| 12:19 | <heycam> | so basically doing lots of ungetc()s or something? |
| 12:20 | <hsivonen> | heycam: no, the IO driver needs to manage a UTF-16 buffer queue from which it pushes to the parser |
| 12:20 | <hsivonen> | document.write needs to be able to insert to the queue |
| 12:20 | <heycam> | insert at some arbitrary places, or just at the front? |
| 12:21 | <hsivonen> | heycam: at certain slice boundaries |
| 12:21 | <hsivonen> | heycam: see http://hg.mozilla.org/users/mrbkap_mozilla.com/html5parsing/file/e2713bb08d00/content/html/parser/src/nsHtml5Parser.cpp#l334 onwards |
| 12:22 | <heycam> | well, getting html rendering in foreignObject (using a library like Flying Saucer) is a distant goal |
| 12:22 | <heycam> | once that was there, having an html5 parser to feed to it could be useful |
| 12:22 | <hsivonen> | heycam: that IO driver is hand-written C++. it hasn't been automatically translated from Java, so corresponding Java code for that piece doesn't exist |
| 12:24 | <heycam> | since v.nu doesn't run scripts, i suppose |
| 12:24 | <hsivonen> | right |
| 12:24 | heycam | heads to bed |
| 12:24 | <hsivonen> | nn |
| 12:25 | <heycam> | i'll probably forward a pointer to the svg-as-root-element stuff on www-archive to public-svg-wg |
| 12:25 | <hsivonen> | ok |
| 12:25 | <heycam> | feel free to use www-svg for those kinds of discussions |
| 12:25 | <hsivonen> | ok |
| 12:26 | <heycam> | unless you're specifially trying to avoid starting a big conversation about ideas you're bouncing around |
| 12:26 | <heycam> | ok, bfn |
| 12:26 | <hsivonen> | I kinda was expecting Hixie to poke major holes into my notes first :-) |
| 13:33 | <annevk5> | Lachy, btw, I was just caring about non-draconian parsing for SVG there |
| 13:33 | <annevk5> | Lachy, no need to generalize it |
| 13:34 | <annevk5> | Lachy, we already have it for SVG embedded in text/html, sort of makes sense to also allow SVG to be root though there's merit for the body > svg:only-child idea too |
| 13:41 | <rubys> | svg:only-chlid? |
| 13:42 | <hsivonen> | rubys: making the <svg> element size as if it were root if it is the only child of body |
| 13:43 | <annevk5> | the only other thing i'd do in that case is set standards mode to true |
| 13:43 | <Philip`> | Not much fun when you insert some whitespace or a comment and suddenly everything breaks in entirely unexpected ways |
| 13:44 | <hsivonen> | Philip`: perhaps selectors should behave more like XPath/RELAX NG here |
| 13:44 | hsivonen | hides |
| 13:44 | <annevk5> | you know that only-child ignores that right? |
| 13:44 | <hsivonen> | ah they already do. good |
| 13:45 | <Philip`> | That's illogical |
| 13:45 | <annevk5> | no, Selectors is about elements |
| 13:45 | <annevk5> | not about nodes |
| 13:46 | <Philip`> | It's logical for it to be about DOM trees |
| 13:46 | <Philip`> | and children in DOM trees include all nodes |
| 13:46 | <annevk5> | it's about DOM trees where you filtered all non-elements |
| 13:46 | <hsivonen> | rubys: do you have a text/html view of planet intertwingly for UAs that Accept application/xhtml+xml? |
| 13:47 | <annevk5> | (though not all extensions follow this, e.g. :-moz-first-node) |
| 13:47 | <Philip`> | annevk5: That seems conceptually awkward |
| 13:47 | <annevk5> | Philip`, what are you trying to say? it's not going to change |
| 13:47 | <Philip`> | Understanding documents as trees is hard enough, but now you've got to understand it as a tree plus a subset of that tree |
| 13:47 | <Philip`> | I'm just trying to justify my claim that it's illogical |
| 13:47 | <hsivonen> | Philip`: inter-element white space FTW! |
| 13:48 | <annevk5> | Philip`, mu |
| 13:48 | <Philip`> | (since you disagreed with my claim, so I thought I should justify it :-) ) |
| 13:50 | <annevk5> | I still disagree with your claim |
| 13:50 | <annevk5> | :) |
| 13:51 | <Philip`> | Well, I disagree with your disagreeing |
| 13:51 | <Philip`> | and you have to agree with that |
| 13:53 | <annevk5> | I'm not following your sense of logic |
| 13:54 | Philip` | points at the door |
| 13:55 | <Lachy> | annevk5, I hadn't heard the body>svg:only-child idea before. |
| 13:55 | <annevk5> | Philip`, after you |
| 13:55 | <Lachy> | how is that supposed to work? |
| 13:55 | <annevk5> | :p |
| 13:56 | <annevk5> | body > svg:only-child { height:100vh; width:100vw; position:absolute; top:0; left:0 } + standards mode would do the trick I think |
| 13:56 | <Philip`> | (Well, not so much at the door as at the collection point adjacent to the dor) |
| 13:57 | <annevk5> | or remove the absolute positioning and do body { margin:0 } besides changing the rendering mode |
| 13:57 | <annevk5> | either way should work |
| 13:58 | <annevk5> | or body:matches($>svg:only-child) { margin:0 } if you want to into undrafted territory |
| 14:01 | <Lachy> | then that would also occur for this document: <!DOCTYPE html><title>...</title><body><svg>...</svg></body> |
| 14:01 | <annevk5> | though alternatively what hsivonen proposes could work as well |
| 14:01 | <annevk5> | that's pretty much what I had in mind initially and would work better for "SVG as image" and all |
| 14:01 | <annevk5> | Lachy, right |
| 14:02 | <annevk5> | and would also work better for SVG scripts that deal with root elements, etc. |
| 14:03 | <Lachy> | I'd be sligihtly more comfortable with that solution, than I am with messing around with the parsing |
| 14:03 | <Lachy> | *slightly |
| 14:05 | <Lachy> | though I still have some concerns about incremental rendering for the case where authors use <body><svg>...</svg> <p>content...</body>, where the SVG is used as, e.g. a site logo |
| 14:07 | <annevk5> | that seems rather theoretical |
| 14:08 | <annevk5> | especially since this would be implemented together with SVG in HTML support in general |
| 14:08 | <annevk5> | and there is not that much stray <svg> stuff going around |
| 14:09 | <Philip`> | Does/will anyone implement incremental rendering of SVG? |
| 14:09 | Philip` | can't imagine it would work well |
| 14:09 | <Lachy> | if they don't, then it's not really a problem |
| 14:10 | <Lachy> | it's only a problem if it is because you don't know if the SVG element is the :only-child until after you fiinished parsing it |
| 14:10 | <hsivonen> | Philip`: Gecko does |
| 14:10 | <Lachy> | but that's a problem with :only-child in general, I think |
| 14:20 | <Lachy> | actually, in most cases, that won't be a problem, because the author would generally have specified a size they want the SVG to be in the page, which would override that default |
| 14:20 | <Lachy> | most won't want the default of 300x150, or whatever it is |
| 14:25 | <Philip`> | Could the default size be {height:100vh;width:100vw} instead of 300x150? |
| 14:26 | <annevk5> | the default size is actually different for SVG elements with an aspect ratio |
| 14:28 | <Philip`> | Oh, I guess it needs to be consistent with existing SVG-in-XHTML implementations |
| 14:29 | <annevk5> | mostly with other replaced elements that lack intrinsic sizes |
| 14:34 | <annevk5> | e.g. <iframe> |
| 14:36 | <Lachy> | annevk5, what's the default size for SVG? |
| 14:37 | <annevk5> | see CSS |
| 14:38 | <Lachy> | doesn't CSS say the deafult is 300x150? |
| 14:38 | <Lachy> | for replaced elements |
| 14:41 | <annevk5> | not anymore |
| 14:41 | <annevk5> | it's more complex |
| 17:27 | <gsnedders> | Oh how fun |
| 17:28 | <gsnedders> | I'm gonna have to make my own BibTeX style |
| 17:32 | <Philip`> | Why can't you do it like everybody else in the world and use the defaults? :-) |
| 17:34 | <gsnedders> | Because the SQA is stupid? |
| 17:36 | <Philip`> | Do they really care that much about bibliography formatting? |
| 17:36 | <gsnedders> | Probably not, and nor do I relly. |
| 17:36 | <gsnedders> | *really |
| 17:37 | <gsnedders> | And I'm going to do terribly at this project anyway so it makes little difference ;P |
| 17:37 | <gsnedders> | "Books - Author, title, edition, page numbers" |
| 17:38 | <Philip`> | Maybe that's because you're spending all your time on infrastructure matters, and not on the content :-) |
| 17:38 | <gsnedders> | :P |
| 17:38 | <gsnedders> | No, it's not actually |
| 17:38 | <gsnedders> | It's mainly because I suck at experimental physics |
| 17:38 | <Philip`> | Oh, okay then |
| 19:01 | Philip` | uses <footer> for a day, before realising he's just being an idiot and should use <div class=footer> instead |
| 20:54 | <gsnedders> | http://twitter.com/isofarro_public/statuses/1278017272 |
| 21:15 | <hsivonen> | gsnedders: did I understand coorectly that they say that Ben doesn't get accessibility when he prefers <footer> over <div role="contentinfo"> once browsers expose both to AT in the same way? |
| 21:16 | <gsnedders> | hsivonen: No |
| 21:17 | <hsivonen> | gsnedders: what did I misunderstand? |
| 21:17 | <gsnedders> | http://www.accessifyforum.com/viewtopic.php?p=66854 |
| 21:18 | <gsnedders> | "Incidentally, I think all HTML5's new section-ish elements are bad." — Ben |
| 21:20 | <hsivonen> | ah. I thought the tweet referred to a blog post |
| 21:20 | <hsivonen> | gsnedders: the part of using JS to get around validation is sad |
| 21:20 | <gsnedders> | The blog post is in that context |
| 21:27 | <Philip`> | We need to add markup to address the use case of wanting to write documents that validators won't accept, since the current script-based solution is horrid and we could come up with a much better way of doing it, like <html please-shut-up-validator> |
| 21:36 | <sayrer> | http://www.browsertests.org/ |
| 22:09 | <Lachy> | damn, looks like the W3C didn't agree to use the MIT licence :-( |
| 22:32 | <BX> | wow - good thing I didn't come here for the action :-) |
| 22:35 | <BlankXavier> | XHTML question -> Firefox appears to ignore accept-charset in a <form> -> anyone successfully prodded FF3 into emitting UTF-16LE? or indeed anything which isn't UTF8... |
| 22:47 | <Lachy> | I'm writing a python script to generate a table for the HTML5 Reference, based on some info in a datafile I have. I'm trying to use the ElementTree interface this time... |
| 22:48 | <Lachy> | I have it set up to parse the table template from a template file, which basically sets it up with the right headings and another row to be filled in. |
| 22:48 | <gsnedders> | ElementTree is crazy |
| 22:48 | <Lachy> | gsnedders, I thought that's what was recommended for me to use, instead of the DOM, which I used last time |
| 22:48 | <Lachy> | is there something better I should use? |
| 22:49 | <gsnedders> | No, all tree models suck basically |
| 22:49 | <Lachy> | ok |
| 22:50 | <Lachy> | so, what I need to know, is there an easy way for me to make copies of that row from the template (basically like cloneNode from the DOM API), and fill in each with its own data? |
| 22:50 | <gsnedders> | import copy |
| 22:50 | <gsnedders> | x = copy.deepcopy(y) |
| 22:51 | <Lachy> | ok, I'll try that |
| 22:54 | <Lachy> | I have this: table = ET.parse("indexelements-template.xhtml") |
| 22:54 | <Lachy> | that returns an ElementTree instance. How do I access the elements within that? |
| 22:54 | <Lachy> | the API documentation isn't really clear |
| 22:55 | <Lachy> | oh, getroot() |
| 23:00 | <annevk5> | hmm, is <input type=text spellcheck> really invalid? |
| 23:00 | <annevk5> | that would be different from contenteditable |
| 23:06 | <Lachy> | yeah, it appears so. The spec should probably say the empty string and the true keyword map to the true state, like it does for contenteditable |
| 23:24 | <Lachy> | does html5lib support parsing fragments, like using innerHTML? |
| 23:25 | <Lachy> | I have a config file with descriptions of elements, and each of those descriptions can contain fragments of markup. I need those parsed so that I can add them to the element tree |
| 23:25 | <gsnedders> | Lachy: Yes, it does |
| 23:26 | gsnedders | can remember from hacking on the code it does… what the API is is a different question |
| 23:27 | <Lachy> | I can't find much API documentation for it, which makes it hard |
| 23:28 | <gsnedders> | Yeah, you basically have to code read… |
| 23:28 | <gsnedders> | Or ask jgraham |
| 23:28 | <Philip`> | Try "import html5lib; help(html5lib.HTMLParser)" in the interactive shell? |
| 23:29 | <Philip`> | That lists parseFragment(self, stream, container='div', encoding=None, parseMeta=False, useChardet=True) |
| 23:29 | <gsnedders> | p.parseFragment instead of p.parse |
| 23:29 | <Lachy> | oh, nice |
| 23:29 | <Lachy> | I didn't know I could get documentation from there |
| 23:29 | <Lachy> | would be nice if that were provided on the html5lib project page though |
| 23:30 | <gsnedders> | Lachy: Patches welcome. :) |
| 23:40 | <Lachy> | what kind of object does the parseFragment() method return? |
| 23:40 | <Lachy> | it doesn't seem to be returning an element tree |
| 23:47 | <Lachy> | ah, I figured it out. It returns a list of elements |
| 23:53 | <Lachy> | I can't find an easy way of appending a list of elements and text nodes, which are returned by parseFragment(), to an existing element. |
| 23:54 | <Lachy> | I can see getchildren(), which reutrns all the children of an element as a list, but there doesn't seem to be a matching setchildren() method |