| 00:37 | Philip` | notices that his text node coalescence thing totally breaks with foster parenting |
| 01:13 | <kig> | img src=x.svg is a canvas with x.svg drawn onto it |
| 01:13 | <kig> | (ha ha) |
| 01:48 | <Philip`> | Oh, and now the foster parenting breaks my previous mechanism for splitting the generic CDATA algorithm to work on tokens one at a time |
| 01:49 | Philip` | really doesn't like it :-( |
| 02:18 | <Philip`> | http://parsetree.validator.nu/?doc=http://philip.html5.org/misc/fostered-adoption-2.html |
| 02:18 | <Philip`> | html5lib and Validator.nu don't match Firefox or Safari for that |
| 02:20 | <Philip`> | (I don't know whether html5lib etc is implementing HTML5 non-buggily or not) |
| 02:20 | Philip` | just wants to decide that the fostering thing is broken so he can not bother implementing it |
| 02:24 | <dbaron> | Hixie, do you still stand by https://bugzilla.mozilla.org/show_bug.cgi?id=54696#c13 ? |
| 02:24 | <dbaron> | Hixie, or do you think Mozilla's list-around-float behavior should just switch to match Safari and IE? |
| 02:24 | <dbaron> | Hixie, (I'd note that float-displace seems to have disappeared from all CSS drafts...) |
| 02:26 | <SadEagle> | dbaron: if you care: http://lists.kde.org/?l=kde-commits&m=119170968024486&w=2 |
| 02:27 | <SadEagle> | IOW, at least some people rely on something like that. |
| 02:29 | <SadEagle> | Not sure it's the same thing, actually, but perhaps the testcase in http://bugs.kde.org/show_bug.cgi?id=150474#c2 will tell you something. (Could just be a similar-sounding bug, I don't know the rendering/CSS stuff) |
| 04:11 | <Hixie> | dbaron: what do the other two browsers do? |
| 04:11 | <dbaron> | Hixie, other browsers make the bullets overlap the floats |
| 04:11 | <dbaron> | Hixie, the bullet is always displaced from the first line by border+padding |
| 04:11 | <dbaron> | Hixie, but the line isn't moved to compensate |
| 04:12 | <Hixie> | so the bullet are on the left of a left float? |
| 04:12 | <dbaron> | Hixie, (see also the three messages I just sent to www-style about float-displace) |
| 04:12 | <dbaron> | Hixie, no, they overlap a left float |
| 04:13 | <Hixie> | right but on which side though? left? |
| 04:13 | <dbaron> | they're a fixed distance (border + padding of the list item) from the right edge of the left float |
| 04:14 | <dbaron> | it's the formula you'd want if you also had float-displace indenting the line |
| 04:14 | <Hixie> | then i don't understand what you mean by "the line isn't moved to compensate" |
| 04:15 | <dbaron> | except float-displace isn't indenting the line, so the bullet overlaps the float |
| 04:15 | <dbaron> | Starting from the beginning, what other browsers do is position the bullet relative to the first line box of the block. |
| 04:15 | <dbaron> | or the place that said line box would start if there were one |
| 04:16 | <dbaron> | that line box is flush against the float |
| 04:16 | dbaron | looks for a testcase |
| 04:16 | <Hixie> | i guess i don't understand how that differs from float-displace, given the right values of float-displace |
| 04:17 | <dbaron> | https://bugzilla.mozilla.org/attachment.cgi?id=302070 |
| 04:17 | <dbaron> | it's like everybody's doing the right thing, except without setting float-displace:line on list items |
| 04:17 | <dbaron> | which means if we become consistent |
| 04:17 | <dbaron> | we'll never be able to change that default |
| 04:17 | <dbaron> | whereas now Mozilla is doing something that means float-displace:line would be a compromise between existing browsers |
| 04:18 | <dbaron> | so people could move to that default |
| 04:19 | <Hixie> | i have to admit finding it difficult to really care :-) |
| 04:19 | <Hixie> | i think we should introduce float-displace and the other property |
| 04:19 | <dbaron> | well, float-displace as specced is rather broken |
| 04:19 | <dbaron> | but it's easily fixable |
| 04:19 | <Hixie> | but i've given up trying to make bert and fantasai see reason, so i'm not planning on trying to get any work done in the csswg any time soon |
| 04:20 | <dbaron> | ok, I guess I'll back out my patch |
| 04:20 | <Hixie> | what did your patch do? |
| 04:20 | <dbaron> | or most of it, anyway |
| 04:20 | <dbaron> | it made Mozilla match the behavior of other browsers |
| 04:20 | <dbaron> | where the bullets overlap the float |
| 04:20 | <dbaron> | but we don't move blocks |
| 04:22 | <Hixie> | isn't that one of the values of float-displace and company? |
| 04:22 | <dbaron> | moving blocks is, but it really sucks |
| 04:22 | <dbaron> | I think we want to get rid of it, except for things that introduce new BFCs |
| 04:22 | <dbaron> | where it would be the default |
| 04:23 | <Hixie> | so what's wrong with the behaviour of other browsers? |
| 04:23 | <dbaron> | bullets overlap floats |
| 04:23 | <dbaron> | pretty much any time they're next to floats |
| 04:30 | <Hixie> | hm |
| 04:30 | <Hixie> | that does suck |
| 04:30 | <dbaron> | So I don't think I have a good excuse for implementing float-displace this far after feature freeze. |
| 04:31 | <dbaron> | But I think I can leave most of what I fixed in. |
| 04:31 | <Hixie> | yeah |
| 04:42 | <dbaron> | but still back out the change removing -moz-float-edge: margin-box from li |
| 05:14 | <dbaron> | Hixie, actually, backing out doesn't yield as good behavior as I thought it did. |
| 05:14 | <dbaron> | Hixie, we had -moz-float-edge on the wrong element, essentially, so we overlapped the bullets too. |
| 05:14 | <dbaron> | Hixie, so we're probably stuck with it... |
| 05:15 | <dbaron> | Hixie, although I'd consider implementing float-displace and seeing what breaks |
| 05:47 | <dbaron> | Hixie, and I think bug 57882 was your fault, too :-P |
| 05:49 | <MikeSmith> | hendry - ping me when you are back on |
| 05:51 | <Hixie> | dbaron: oh? |
| 05:51 | <dbaron> | Hixie, moving -moz-float-edge from ul,ol to li in your html.css cleanup |
| 05:51 | <dbaron> | Hixie, when I wanted to back out, I was thinking our use of -moz-float-edge prevented bug 57882 and I had caused it |
| 05:51 | <dbaron> | Hixie, but we had it all along, so I think what I did is an improvement |
| 05:52 | <dbaron> | anyway, enough confusing myself for today. |
| 05:57 | <Hixie> | heh |
| 06:52 | <Hixie> | i have no idea how to find examples of what julian is saying doesn't happen |
| 08:22 | <Hixie> | roc: yt? |
| 08:23 | <roc> | aye |
| 08:23 | <Hixie> | i'm looking at your application cache feedback, in particular your use case for a map application wanting to pick a tile that is known to be available locally as the starting point of a transition |
| 08:23 | <Hixie> | is this something you think we should resolve in v1 of the api? |
| 08:24 | <Hixie> | or something for the future? |
| 08:25 | <roc> | I don't have an opinion on that |
| 08:25 | <roc> | I know people have asked for it |
| 08:25 | <roc> | Google Maps people |
| 08:25 | <roc> | I don't know how to prioritize these things |
| 08:25 | <Hixie> | k |
| 08:28 | <Hixie> | roc: let me know if you end up pressured to implement something for that use case and i'll bring it up, but for now i'm going to shunt that to v2. |
| 08:28 | <Hixie> | roc: i want to try and get the basic API nailed down first. |
| 08:29 | <roc> | sounds reasonable |
| 08:29 | <roc> | we did actually implement something |
| 08:29 | <roc> | should we take it out? |
| 08:29 | <roc> | http://mxr.mozilla.org/seamonkey/search?string=islocallyavailable |
| 08:30 | Hixie | looks |
| 08:31 | <Hixie> | lordy, nsGlobalWindow is trying to catch up to nsCSSFrameConstructor |
| 08:31 | <roc> | don't look there |
| 08:36 | <Hixie> | well, i would rename it mozIsLocallyAvailable |
| 08:37 | <Hixie> | in case we introduce it later with different semantics or something |
| 08:37 | <Hixie> | but no, don't remove it, it'd be good to find out how people use it |
| 08:37 | <Hixie> | implementation feedback is a great way to inform the spec |
| 08:38 | <roc> | ok |
| 08:39 | <roc> | you know we're actually shipping supposedly-HTML5-complaint offline-application support in FF3 |
| 08:39 | <Hixie> | really? sweet |
| 08:40 | <Hixie> | is that implemented yet? |
| 08:40 | <roc> | yeah |
| 08:40 | <roc> | yeah it is |
| 08:40 | <Hixie> | wow, cool |
| 08:40 | <Hixie> | didn't hear any feedback from whoever implemented it, as far as i recall; i hope the spec was clear enough |
| 08:40 | <roc> | If you have a recent FF3 build, check out "Tools ... Clear Private Data" |
| 08:40 | <Hixie> | Offline Website Data? |
| 08:40 | <Hixie> | cool |
| 08:40 | <roc> | yeah |
| 08:41 | <Hixie> | i guess i should test it :-) |
| 08:41 | <roc> | that would be interesting :-) |
| 08:42 | roc | is busy testing SVG filters :-( |
| 08:58 | <Hixie> | i've already found two bugs |
| 08:58 | <Hixie> | and i've only written five lines of code |
| 09:25 | <Hixie> | http://www.hixie.ch/tests/adhoc/html/offline/ |
| 09:25 | <Hixie> | firefox fails at least 003 |
| 09:25 | <Hixie> | bed time now |
| 09:38 | <hsivonen> | any opinion whether Validator.nu TLS cert handling should copy trusted certificates from e.g. Mozilla or just skip trust checking? |
| 09:55 | <Philip`> | hsivonen: Maybe it would be useful if the validator trusted the intersection of what's trusted by each major browser, so it can tell you if some fraction of users will experience problems |
| 09:57 | <Philip`> | but I'd expect it really needs some way to validate pages that are behind untrusted certificates, because people might do that intentionally (and ask users to accept or install the certificate) and will still want to validate their pages |
| 09:58 | <hsivonen> | Philip`: yeah, given the current state of HttpClient, it is hard to have it both ways |
| 09:58 | <hsivonen> | Philip`: and having yet another checkbox would suck |
| 09:59 | <hsivonen> | I've tried to find a way to manage HttpClient cert trust on a per HttpClient instance or on a per request basis |
| 10:00 | <hsivonen> | but it seems that it can only be managed on a per-classloader basis, which is rather bad in case someone wants to run the validator servlet in a larger app server |
| 10:00 | <hsivonen> | Philip`: as for the intersection, I can see practical reasons to to the intersection thing |
| 10:02 | <hsivonen> | Philip`: I can also don't like the inherent problem of root trust-based trust management that blesses a relatively small number of gatekeepers who can extract money from anyone who wishes to do TLS in a user-friendly way |
| 10:23 | <hsivonen> | http://html5.validator.nu/?doc=https%3A%2F%2Flabs.mozilla.com%2Fforum%2F |
| 10:23 | <hsivonen> | validator.nu is now totally promiscuous when it comes to cert checking |
| 10:30 | <annevk> | "On Sat, 13 Nov 2004, Henri Sivonen wrote:" heh |
| 10:30 | <annevk> | fortunately comments are not addressed in chronological order |
| 10:58 | <hsivonen> | hmm. the French Wikipedia says that its XHTML article is part of a series on programming languages... |
| 11:26 | <annevk> | so defaultChecked does change the checked state in browsers, but only if it was not changed before |
| 11:42 | <annevk> | oh, defaultChecked is actually more weird than that |
| 11:42 | <annevk> | :( |
| 11:44 | <annevk> | Firefox makes a distinction between setAttribute("checked", "checked") and defaultChecked |
| 11:54 | <annevk> | Hixie, either Acid3 should test a bunch of other things regarding defaultChecked so that we can extract a sane spec/impl out of it. If not it should simply avoid it so we won't be constrained further on |
| 11:56 | <annevk> | to the people doing dom5: kill hasFeature |
| 11:56 | <annevk> | (and friends) |
| 12:05 | Philip` | begins to suspect that http://james.html5.org/cgi-bin/parsetree/parsetree.py?uri=http://philip.html5.org/misc/fostered-adoption-3.html is a bug in html5lib, because it should be impossible to append the p to the table element |
| 12:06 | <hsivonen> | Philip`: http://parsetree.validator.nu/?doc=http://philip.html5.org/misc/fostered-adoption-3.html |
| 12:07 | <hsivonen> | Philip`: looks like two independent implementations share the bug... |
| 12:08 | <annevk> | yaiks |
| 12:08 | <annevk> | Firefox does move the <p><b> thingie before <table> |
| 12:11 | <annevk> | probably time for revising the parser section |
| 12:38 | <Philip`> | annevk: I'm not sure the spec is wrong here |
| 12:40 | <annevk> | those two statements were not tightly related :) |
| 12:40 | <annevk> | sorry |
| 12:46 | <Philip`> | Ah, okay :-) |
| 13:13 | <Philip`> | Oh, looks like html5lib/validator.nu are correct, and the spec is wrong |
| 13:14 | <annevk> | my main issue with spec changes at this point is fixing html5lib |
| 13:14 | <annevk> | i hope someone will add more parsing tests based on the updated spec and that we can then sort of figure out what needs to happen |
| 13:49 | <Philip`> | Hmm, Gmail's sponsored links aren't entirely appropriate when reading email about the foster parenting algorithm |
| 14:05 | <annevk> | latest rumors: Y! to merge with AOL, Y! to form alliances with Google/Disney |
| 14:05 | <hsivonen> | Hixie: do you have feedback on text/html encoding sniffing from browser vendors? is the current spec language considered virtually final? |
| 14:09 | <Philip`> | Mozilla should buy Yahoo |
| 14:09 | <annevk> | heh, that'd be something |
| 14:10 | <Philip`> | using money secretly donated by Google |
| 14:10 | <annevk> | hsivonen, I doubt it had much review... |
| 14:10 | <hsivonen> | annevk: ok. |
| 14:10 | <hsivonen> | I won't implement it now then |
| 14:11 | <hsivonen> | I've already written one tentative implementation, so now it's someone else's turn :-) |
| 14:11 | <hsivonen> | "The attribute value must be serialised without the use of character entity references of any kind. " fun, fun, fun |
| 14:11 | <hsivonen> | go layering |
| 14:13 | <annevk> | that's actually pretty complex if you don't encounter it in the prescan |
| 14:13 | <annevk> | and since there's no longer a max bytes limit... |
| 14:14 | <hsivonen> | Hixie: why are entities prohibited if the algorithm now involves running the real tokenizer? |
| 14:15 | <Philip`> | http://james.html5.org/cgi-bin/parsetree/parsetree.py?source=<table><b><p></b>; - hmm, EOF should cause an implied </p> which should get foster-parented which should result in one more parse error than is shown |
| 14:15 | <hsivonen> | } else if ("meta" == name) { // XXX do charset stuff |
| 14:15 | <hsivonen> | that explains why the parser wasn't doing what Sam Ruby suggested |
| 14:16 | <hsivonen> | although I though it already did... |
| 14:16 | Philip` | wonders if it would be bad to commit evil tests to html5lib without offering to fix the code to pass them |
| 14:16 | <annevk> | yes |
| 14:17 | <hsivonen> | Philip`: I suggest putting evil tests to a separate test file |
| 14:17 | <annevk> | we still need to organize all those tests one day |
| 14:17 | <annevk> | but maybe we should wait for the spec to update itself first |
| 14:18 | <gsnedders> | the spec updates itself? oh, |
| 14:18 | <gsnedders> | I thought Hixie did the updating. |
| 14:18 | <hsivonen> | does the spec say anywhere that it is an error for HTTP charset and meta charset to disagree? |
| 14:18 | <gsnedders> | </bad_joke> |
| 14:20 | <gsnedders> | hsivonen: as far as I can see, no |
| 14:20 | <hsivonen> | gsnedders: ok |
| 14:35 | <Philip`> | Hmm, I assume that <table><td><a><table></table> shouldn't give a stack overflow |
| 14:36 | <hsivonen> | Philip`: does it somewhere? |
| 14:37 | <Philip`> | It does in my implementation |
| 14:38 | <Philip`> | Actually, that <a> is unnecessary |
| 14:41 | <Philip`> | Ah, it's just my ReprocessAsIf being broken if the insertion mode changes while reprocessing... |
| 14:52 | <Philip`> | ...which seems impossible to solve without adding even more state variables :-( |
| 15:19 | <annevk> | http://en.wikipedia.org/wiki/Acid3 |
| 15:29 | <Lachy> | wow, webkit has improved a lot in acid3 over the last few weeks |
| 15:33 | <krijnh> | Are there IE8 previews somewhere already? :) |
| 15:36 | <alp> | sigh, we still get data url parsing wrong :-( |
| 15:37 | <gsnedders> | alp: "we"? |
| 15:37 | <alp> | WebKit, GTK+ port |
| 15:39 | <alp> | is there a published algorithm? maybe that's going to work better than my interpretation of the RFC |
| 15:47 | <Lachy> | krijnh, not yet |
| 15:47 | <krijnh> | Bummer |
| 15:47 | <Lachy> | krijnh, the IE blog will most likely annonce it when there are |
| 15:48 | <krijnh> | Would be cool to see how it's doing now |
| 15:49 | <hsivonen> | hmm. Gecko and WebKit don't require http-equiv='content-type' to sniff charset |
| 15:49 | <hsivonen> | it seems that Opera 9.5 and IE7 do |
| 15:49 | <hsivonen> | http://browsershots.org/screenshots/63d26493fb4be33bb27db91ac31fd9a1/ |
| 15:49 | <hsivonen> | yay for interop |
| 16:00 | <alp> | gsnedders: it turned out i was using a base64 decoder special-cased for window.atob(). using a generalised base64 decoder fixed acid3 test 97 |
| 16:00 | <gsnedders> | ah. |
| 16:01 | <alp> | webkit's special-case b64 decoder needs a better name than base64Decode() clearly |
| 16:13 | gsnedders | wonders if anyone who knows XPath is around |
| 16:18 | <gsnedders> | Is there anyway to find any comment node in the document with the content, "foobar"? |
| 16:19 | <annevk> | http://www.w3.org/TR/xpath |
| 16:19 | <Philip`> | I'd use grep |
| 16:20 | <gsnedders> | annevk: Reading the spec (actually, 2.0, not 1.0) makes me think no |
| 16:20 | <gsnedders> | Philip`: does that work on trees? :P |
| 16:20 | <gsnedders> | (i.e., I can't use grep) |
| 16:21 | <Philip`> | Serialise the tree then use grep |
| 16:21 | <gsnedders> | Philip`: I really don't want to be playing around with HTML with grep. HTML is too mad :) |
| 16:21 | <annevk> | something like //comment() plus something else might work |
| 16:22 | <Philip`> | Serialise the tree to XML then use grep |
| 16:22 | <gsnedders> | Philip`: too much serialising and parsing :) |
| 16:23 | <gsnedders> | annevk: seems to work in Safari (though that only claims to support 1.0), so I guess the Python impl I'm using is broken |
| 16:23 | gsnedders | dives back into Python |
| 16:23 | <Philip`> | It sounds like you have determined the limit of "too much" totally arbitrarily just so you can reject my idea :'-( |
| 16:25 | <gsnedders> | Philip`: 2MB documents + Python = Slow enough all ready |
| 16:25 | <gsnedders> | Philip`: and seeming a stated aim of the spec-gen clone is to be quicker than the official one (which is written in Perl, sed, and C), parsing it too many times will make it too slow |
| 16:26 | <gsnedders> | (the real reason why the spec-gen is so slow is that it parses _loads_ of times) |
| 16:26 | <annevk> | from skimming the XPath spec it should be possible |
| 16:26 | <gsnedders> | annevk: that's what I think, too |
| 16:26 | <gsnedders> | I think I've just hit a bug in my very new Python impl |
| 16:26 | <gsnedders> | (well, not my impl, but the one I'm using) |
| 16:56 | <Philip`> | Hooray, more text issues |
| 16:57 | <Philip`> | html5lib says <!DOCTYPE HTML><frameset>test should only create one parse error for the text, but the spec unambiguously requires each character token to generate an individual parse error |
| 17:01 | <jruderman> | conclusion: "test" is a single character |
| 17:02 | <SadEagle> | or a single "character" token? :-) |
| 17:02 | <Philip`> | Perhaps it's a single Multicode character |
| 17:03 | <Philip`> | SadEagle: A single character token contains a single character |
| 17:03 | <Philip`> | (except in the reality of implementations) |
| 17:03 | <hsivonen> | Philip`: IIRC, Hixie said that in principle you should be able to treat runs of characters as units |
| 17:03 | <hsivonen> | Philip`: but the foster parenting stuff breaks that |
| 17:03 | <hsivonen> | what WebKit does is most sane IMO |
| 17:03 | <hsivonen> | what Gecko does seems unnecessarily complex |
| 17:04 | <Philip`> | Even without foster parenting, whitespace breaks that |
| 17:04 | <hsivonen> | Philip`: where? |
| 17:05 | <hsivonen> | (I'm assuming that the frameset case above isn't *really* mean to spew an error on each char separately) |
| 17:05 | <annevk> | hixie also mentioned that parse errors may be collapsed |
| 17:05 | <annevk> | no idea if that's reflected by the spec |
| 17:06 | <hsivonen> | Philip`: fwiw, the cases where html5lib and V.nu disagree on the exact # of tree construction errors, either one is just collapsing errors that would be guaranteed to fire together |
| 17:06 | <hsivonen> | Philip`: it didn't make sense to follow html5lib exactly, because IIRC, html5lib didn't follow the spec 100%, either |
| 17:06 | <Philip`> | With something like "<frameset> test" the spec says the whitespace and non-whitespace characters are handled through different paths, so you have to handle characters individually or split the text run up into whitespace and non-whitespace runs or think cleverly about how to make it work regardless |
| 17:07 | <hsivonen> | oh, right. |
| 17:07 | <hsivonen> | you can only coalesce runs of whitespace and runs of non-whitespace |
| 17:08 | <Philip`> | It'd be inefficient to not coalesce combined whitespace-and-not characters in the common cases of big paragraphs of un-marked-up text |
| 17:08 | <hsivonen> | the trick case that shows WebKit vs. Gecko difference is when you have: <table>foo<!-- --> <!-- --> bar</table>, IIRC |
| 17:08 | <hsivonen> | Philip`: yeah |
| 17:09 | <hsivonen> | from the impl point of view I like what WebKit does: coalesce a run first and then check if it is all whitespace |
| 17:09 | <hsivonen> | which is why the crafter comment case tricks WebKit |
| 17:09 | <hsivonen> | crafted |
| 17:09 | <Philip`> | What if you want to do incremental display, and add Text nodes to the document before you've finished tokenising a run of characters? |
| 17:10 | <hsivonen> | Philip`: you'd assume that no single text run on normal pages is long enough without intervening markup to justify rendering a run of text incrementally |
| 17:10 | <SadEagle> | 1) how common is the case of a long run of characters w/o whitespace? 2) you can always update TextNodes, as long as you don't let JS run prematurely, anyway |
| 17:12 | <Philip`> | "<plaintext>5MB of text from Gutenberg" |
| 17:13 | <SadEagle> | that has whitespace, no? |
| 17:13 | <gsnedders> | SadEagle: that has no whitespace |
| 17:14 | <Philip`> | SadEagle: 2) The difficult is that you'd have to move the Text node from inside the table to outside, once you've discovered a non-whitespace character at the end |
| 17:14 | <Dashiva> | Maybe stating the definition would help the discussion :) |
| 17:15 | <Philip`> | SadEagle: 1) I'm assuming whitespace in the middle of a run of characters is coalesced with non-whitespace, because it seems inefficient otherwise |
| 17:15 | <SadEagle> | Philip`: ah, and you mean the rendering might "jump" due to the node movement? |
| 17:16 | <Philip`> | I mostly mean that the node movement is kind of complex and likely to include bugs :-) |
| 17:16 | <SadEagle> | what does the 5mb matter then? :-) |
| 17:17 | <zcorpan> | justify incremental rendering? |
| 17:18 | <SadEagle> | ah :-). Well, never mind me, I am dumb when 90% of my brain is dedicated to something else </lameexcuse> |
| 17:19 | <Philip`> | parse error: unmatched closing tag lameexcuse |
| 17:21 | <Philip`> | Grargh, I'm adopting children backwards |
| 20:56 | <hsivonen> | http://vesa.piittinen.name/doctype/ |
| 21:14 | <krijnh> | Doesn't really work in Opera.. |
| 21:16 | <annevk> | works in Opera 9.5 I think |
| 21:17 | <annevk> | string based apps and XML always go wrong: http://vesa.piittinen.name/doctype/?doctype=%3C%21DOCTYPE+html+PUBLIC+%22-%2F%2FWAPFORUM%2F%2FDTD+WML+2.0%2F%2FEN%22+%22http%3A%2F%2Fwww.wapforum.org%2FDTD%2Fwml20.dtd%22%3E&content-type=text%2Fxml |
| 21:18 | <annevk> | seems he never tested the XML stuff him/herself... |
| 21:18 | <gsnedders> | annevk: XML is easy. Don't you know? :) |
| 21:21 | <annevk> | better than you :p |
| 21:22 | <gsnedders> | Hey! My brain is a non-fatal XML parser! It's easy! |
| 21:25 | <SadEagle> | how well does it support external entities? :-) |
| 21:25 | <gsnedders> | SadEagle: it ignores them |
| 21:26 | <gsnedders> | (the built-in memory is too restrictive, as it would cause a segfault) |
| 21:33 | <Dashiva> | gsnedders: So it's non-validating? |
| 21:34 | <gsnedders> | Dashiva: totally. |
| 21:34 | <gsnedders> | Dashiva: it totally ignores all errors, so why bother using a validating parser? It just complicates matters by needing to get external entities! |
| 21:37 | <Dashiva> | Well, even if you ignore errors you might want to keep track of them, so you don't propagate them onto other, validating parsers ;) |
| 21:43 | <zcorpan_> | gsnedders: how about the internal subset? |
| 21:43 | <gsnedders> | zcorpan_: yeah, I parse that |
| 21:44 | zcorpan_ | feeds the billion laughs attack to gsnedders' brain |
| 21:44 | gsnedders | notes recursion (at any level) and throws a "too lazy" error |
| 21:45 | Philip` | passes a U+2664 SPADE through gsnedders' head |
| 21:45 | gsnedders | shrugs |
| 21:45 | <Dashiva> | Surely it would be better to use U+FDD0 before the joke gets too old |
| 21:47 | <gsnedders> | oh gwad/. |
| 21:47 | <gsnedders> | I actually looked that up. |
| 21:47 | <gsnedders> | I'm that willing to believe a comic! |
| 21:48 | <gsnedders> | brb |
| 22:51 | <Hixie> | hsivonen: the html5 spec requires that the content type declarations match the encoding used |
| 22:52 | <Hixie> | hsivonen: so that's one way you could justify mismatched declarations as being an error |
| 22:57 | <hsivonen> | Hixie: ok. thanks. It could be clearer, though. |
| 22:58 | <Hixie> | yeah |
| 23:00 | <webben> | are there any test-cases for cross-browser syntax for embedding Java applets without applet that don't rely on conditional comments? |
| 23:01 | <webben> | (or alternately, any good description of why the draft currently obsoletes applet?) |
| 23:01 | <annevk> | we need someone to figure out how <applet> works, last i checked |
| 23:02 | <Philip`> | The problem with <applet> is that it's a vendor-prefixed name |
| 23:02 | <hsivonen> | hah |
| 23:02 | webben | isn't sure what that means |
| 23:02 | <Hixie> | that's funny |
| 23:04 | <webben> | not having worked out how something works doesn't sound like a rationale for obsoleting it. |
| 23:04 | <annevk> | html5 isn't done |
| 23:05 | <webben> | I don't really see how it's un-doneness is relevant. People are being asked to look at a series of draft documents. |
| 23:05 | <annevk> | can't help you there |
| 23:06 | <webben> | if something is simply un-thought-out, it's better to mark it as such |
| 23:06 | <hsivonen> | annevk: is there a reason to expect that how <applet> really works is significantly more complex than what Sun documents? |
| 23:06 | <Philip`> | It might be helpful to add a placeholder section that just says we don't quite know what should be done yet, to avoid misleading people that it's been intentionally removed |
| 23:06 | <Philip`> | Oh, like what webben said |
| 23:07 | <webben> | or alternately, don't publish official drafts |
| 23:07 | <annevk> | webben, you're overreacting |
| 23:08 | <annevk> | hsivonen, dunno |
| 23:08 | <Hixie> | i have no intention of adding <applet> to the spec, btw |
| 23:08 | <Hixie> | <object> should be enough for any proprietary binary embedding, whether it's activex, java, sliverlight, or whatever. |
| 23:09 | <webben> | you mean object plus conditional comments? |
| 23:09 | <annevk> | conditional comments are not part of html5 |
| 23:10 | <gsnedders> | if anyone wants to do something minor to help the spec-gen clone, can they get Py html5lib's dom treebuilder/walker to work with other dom implementations (i.e., not minidom, I need pxdom). I looked through it very quickly earlier and it really looks like next to no work. |
| 23:10 | <Hixie> | why conditional comments? |
| 23:10 | <webben> | Hixie: to get markup that works in IE too? |
| 23:10 | <gsnedders> | Also, on the subject of the spec-gen clone, I hope to get something working over my half-term (this Wednesday to Sunday). |
| 23:11 | <Hixie> | webben: IE doesn't support java in <object>? |
| 23:12 | <hsivonen> | Hixie: what's in the spec now doesn't cover activex |
| 23:12 | <hsivonen> | Hixie: by the time HTML5 is done, Java will be non-proprietary |
| 23:12 | <webben> | Hixie: AFAIK, you need conditional comments if you want both non-IE and IE to work with OBJECT + Java. I was hoping the idea of deprecating APPLET was prefaced on test cases showing that somehow this wasn't necessary. |
| 23:13 | <Hixie> | hsivonen: in the same way that open office is non-proprietary? |
| 23:13 | <hsivonen> | Hixie: in the way that you can get a Free Software impl |
| 23:13 | <Hixie> | webben: no, the obsoletion of applet is based purely on my prejudices. |
| 23:14 | <Hixie> | hsivonen: "proprietary" may be hte wrong term here. |
| 23:14 | Philip` | noticed recently that the spec changed from section numbers like "1.2.3." to "1.2.3", and wonders if that's an artifact of the spec-gen script |
| 23:14 | <gsnedders> | webben: HTML 5 is being developed from a clean slate, so everything has made it's way in it through use cases being presented, and not the other way around |
| 23:14 | <gsnedders> | Philip`: yeah, that's all spec-gen |
| 23:14 | <Hixie> | Philip`: no idea, i didn't even notice that |
| 23:14 | <gsnedders> | Hixie: I've seen that elsewhere too |
| 23:15 | <Philip`> | http://lists.whatwg.org/pipermail/commit-watchers-whatwg.org/2008/000397.html |
| 23:15 | <gsnedders> | <http://www.w3.org/Tools/HTML-XML-utils/>; — 4.4 update |
| 23:15 | <Hixie> | wow, i wonder what caused that |
| 23:15 | <gsnedders> | (a lot of the spec-gen is just calling those utils, all of which parse the HTML themselves then serialise it, which makes it that dog slow) |
| 23:15 | <annevk> | Philip`, Bert changed his tool, yes |
| 23:16 | <hsivonen> | what parser does the script use? |
| 23:16 | <webben> | The drafts don't dispute that applet has a /use/. |
| 23:16 | <gsnedders> | num(1), specially |
| 23:16 | <webben> | They claim it's unnecessary for its use. |
| 23:16 | <Philip`> | http://lists.w3.org/Archives/Public/www-html-editor/2005JulSep/0003.html - the non-dot form is apparently an ISO standard |
| 23:16 | <gsnedders> | hsivonen: very naïve ones. download the source and look, it's really basic custom stuff |
| 23:16 | <webben> | "The following elements are not included because they have not been used often, created confusion or can be handled by other elements: .... applet has been obsoleted in favor of object." |
| 23:16 | <jgraham> | gsnedders: Are you really sure you want to use DOM? :) |
| 23:17 | <gsnedders> | jgraham: yes. |
| 23:17 | <jgraham> | why? |
| 23:17 | <Hixie> | webben: the only reason <applet> is not in html5 is my own personal prejudice against Java and my desire to not special-case one particular extension language. |
| 23:17 | <webben> | HTML5 already does special-case JS. |
| 23:18 | <Hixie> | webben: i would personally be quite happy to not support Java at all. |
| 23:18 | <Hixie> | webben: JS isn't an extension language for HTML, it's its scripting language. |
| 23:18 | <Hixie> | java is at the level of flash or silverlight |
| 23:18 | <gsnedders> | jgraham: all the decent XPath impls. require it, and not using XPath means recursing through the document manually, while changing it, even more times than otherwise needed |
| 23:18 | <gsnedders> | (by all the decent XPath impls., I basically mean WebPath) |
| 23:18 | <webben> | oh, I'm not sure "extension" is quite the word for such things. |
| 23:19 | <jgraham> | (btw I will be happy to support pyxdom or whatever in html5lib but I can't promise any time to look at it soon) |
| 23:19 | <hsivonen> | I have a strong prejudice against Java *applets*, but I still think that Java via <applet> is better than Java via <object> |
| 23:19 | <webben> | JS seems more like an "extension" of HTML. |
| 23:19 | <jgraham> | gsnedders: lxml |
| 23:19 | <Hixie> | webben: ok, well, whatever you want to call them :-) |
| 23:19 | <gsnedders> | jgraham: needs to be compiled to be used. I'd really like it to work without compiling anything. |
| 23:19 | <hsivonen> | Java applets might have been great if AWT didn't suck so incredibly badly |
| 23:20 | <jgraham> | Any reason for that requirement? easy_install lxml isn't so hard... |
| 23:20 | <gsnedders> | and there was some other reason why lxml wouldn't do. |
| 23:20 | <hsivonen> | webben: please raise the <applet> issue on public-html |
| 23:20 | <hsivonen> | nn |
| 23:20 | <gsnedders> | jgraham: I can't actually get it working locally. |
| 23:20 | <webben> | hsivonen: I'm not a member of the WG. (And I can't join either.) |
| 23:20 | <gsnedders> | (but that wasn't the reason, I admittedly didn't try hard) |
| 23:20 | <gsnedders> | webben: s/public-html/whatwg or public-html-comments/ |
| 23:21 | <webben> | gsnedders: Yep, not at all clear to me I can safely post there either. |
| 23:21 | <gsnedders> | why? |
| 23:21 | <webben> | Indeed, just chatting here is a bit dodgy. |
| 23:21 | <Hixie> | webben: feel free to e-mail me directly ian⊙hc |
| 23:21 | <Hixie> | webben: i can keep any feedback confidential |
| 23:22 | <jgraham> | (actually if specgen requires comments before the html element our current lxml treebuilder won't work so well. Although it could be fixed I think) |
| 23:23 | <jgraham> | webben: that sucks (not being able to post feedback) |
| 23:23 | <webben> | gsnedders: Basically because of the way the W3C patent policy infects pretty much everything employees of member companies do. |
| 23:24 | <gsnedders> | jgraham: you should see what the real spec-gen does. it doesn't actually really parse it then serialise it, it just spits out everything until it finds something it wants to add/remove/change |
| 23:24 | <Hixie> | like i said, feel free to send me unofficial feedback straight to ian⊙hc |
| 23:24 | <Hixie> | it will never be made public |
| 23:24 | <jgraham> | webben: Can you say who your employer is? |
| 23:25 | jgraham | is just curious, it's not important |
| 23:25 | gsnedders | hasn't set about trying to break the spec-gen (because he don't have access), but it could be easily done |
| 23:25 | <annevk> | http://benjaminhawkeslewis.com/ suggests Y! |
| 23:26 | <webben> | that information is still accurate |
| 23:26 | gsnedders | wonders where he's seen webben before. rss-public? uf-*? |
| 23:26 | <roc> | maybe not for long, depending on how the takeover struggle goes :-) |
| 23:26 | jgraham | discovers that reading the specs properly in case the insane behaviour of one's code is actually correct and not a bug is a good idea |
| 23:26 | <webben> | roc: That I definitely can't comment on ;) |
| 23:27 | <roc> | :-) |
| 23:27 | <webben> | gsnedders: Oh, I used to post to whatwg quite a lot and often lurk/grumble in here. |
| 23:27 | <gsnedders> | ah |
| 23:28 | <webben> | (just to be 100% clear, nothing I say is an official Y! position, or a semi-official Y! position, or likely to be based on even talking to other Y! employees) |
| 23:29 | <webben> | gsnedders: I do post on the uf- mailing lists though, along with a couple other Y! folk. |
| 23:30 | <gsnedders> | webben: ah. I was sure I'd seen you elsewhere. I rarely post on the uf- lists, though I read quite a bit |
| 23:31 | <Philip`> | http://james.html5.org/cgi-bin/parsetree/parsetree.py?source=%3C!doctype%20html%3Efoo%3Chtml%20x%3E - why is that a parse error? |
| 23:31 | <Philip`> | The <html> shouldn't hit the "If this start tag token was not the first start tag token, then it is a parse error." case since it is the first start tag token |
| 23:32 | <gsnedders> | jgraham: if I allow other dom modules to be used for the dom treebuilder/walker, I assume I should just add a second param (like on etree), and have it default to minidom for backwards compat.? |
| 23:33 | <gsnedders> | Should I just commit it as long as it doesn't break anything? |
| 23:33 | <Philip`> | http://parsetree.validator.nu/?doc=http://philip.html5.org/misc/html-after-chars.html complains too, and I think it shouldn't |
| 23:34 | <gsnedders> | (someone who isn't jgraham who knows about html5lib policy can answer too) |
| 23:34 | <jgraham> | gsnedders: Exactly |
| 23:34 | <jgraham> | I think I even wrote in the docs that that might happen in the future |
| 23:34 | <gsnedders> | yeah, you did |
| 23:34 | <annevk> | Philip`, with implied start tag tokens it's not |
| 23:35 | <jgraham> | gsnedders: You should add the new dom thing to the tests as well. Then check they all pass :) |
| 23:35 | <gsnedders> | jgraham: add in what way? |
| 23:36 | <gsnedders> | jgraham: add param for mindom? |
| 23:36 | <jgraham> | In the tokenizer tests file we run all the tests on every DOM implementation we claim to support, if the user has them installed |
| 23:36 | <Philip`> | annevk: That would be annoying for me, since implied tokens are handled in the same way as reprocess-the-current-token tokens, and the <html> gets reprocessed a couple of times before it's tested for firstness |
| 23:37 | <Philip`> | and the spec isn't clear enough about what it means there, so I'll stick with my interpretation because it's easy |
| 23:37 | <annevk> | either way there's a parse error there |
| 23:37 | <annevk> | i guess it's ok if you collapse them, but Hixie should clarify that |
| 23:37 | <Philip`> | and http://canvex.lazyilluminati.com/misc/cgi/issues.cgi/message/%3C251FD893-EFFA-4A53-9015-21349E494B74%40iki.fi%3E should allow it to work better in the future anyway |
| 23:37 | <Philip`> | annevk: I'm not sure why there's a parse error either way |
| 23:38 | <gsnedders> | jgraham: where? |
| 23:38 | <annevk> | Philip`, oh wait... hmm |
| 23:38 | <jgraham> | gsnedders: |
| 23:38 | <jgraham> | try: |
| 23:38 | <jgraham> | import pyxdom |
| 23:38 | <jgraham> | treeTypes["pyxdom"] = treebuilders.getTreeBuilder("dom", "pyxdom") |
| 23:38 | <jgraham> | except ImportError: |
| 23:38 | <jgraham> | pass |
| 23:38 | <annevk> | Philip`, there should be a parse error there though |
| 23:38 | <gsnedders> | jgraham: what file? |
| 23:39 | <jgraham> | in python/tests/test_parser.py |
| 23:39 | <Philip`> | annevk: Do you mean there should be one according to the spec, or there should be one according to common sense? |
| 23:39 | gsnedders | will probably have a go tomorrow |
| 23:39 | <annevk> | Philip`, currently only the latter I guess |
| 23:39 | Philip` | wonders if he should bother emailing about it |
| 23:41 | <annevk> | it's also easier to handle this case if you turn insertion modes into phases |
| 23:41 | Philip` | does that in his implementation |
| 23:42 | <annevk> | in that you can never end up with <html> in the in body phase |
| 23:51 | Philip` | continues hating things that require more than one token at a time |