| 00:06 | <Philip`> | The PHP manual's user comments are fun - there's one with a code sample saying "This might help a bit for security (no guarantees)" which, naturally, is buggy and doesn't help with security at all |
| 00:20 | jgraham | just checked in the html5lib parse tree viewing web-app bits to http://code.google.com/p/html5/ |
| 00:22 | <jgraham> | If anyone has any suggestions for a place to host that more stable than "over my dsl connection" that would be good :) |
| 00:23 | jgraham | feels he should emphasise again the code is not production quality |
| 00:28 | <hasather> | jgraham: do you want a suggestion for a place where you could host it, or do you want someone to host it for you? |
| 00:29 | <jgraham> | hasather: Well preferably the latter but if you know of somewhere that has cheap webhosting with excellent python support and reasonable customer service that would be good too :) |
| 00:30 | <hasather> | jgraham: I could throw it up on my server if you want |
| 00:31 | <jgraham> | That sounds good |
| 00:33 | <jgraham> | Assuming you don't mind and won't object to getting the occasional request to update it, that is :) |
| 00:33 | <hasather> | jgraham: nope :) |
| 00:34 | jgraham | has to sleep now |
| 00:35 | <hasather> | jgraham: I fix it tomorrow, good night |
| 00:53 | <zcorpan> | Hixie: you think you could add jdandrea⊙gc to the html5 google project? |
| 00:54 | <zcorpan> | (he wants to contribute to the style sheet) |
| 00:54 | <Hixie> | done |
| 00:54 | <zcorpan> | thanks |
| 01:20 | <Hixie> | othermaciej: btw, john is wrong on almost all counts on his description of the problems with the wf2 repetition model |
| 01:20 | <Hixie> | notwithstanding that it does suck |
| 01:20 | <othermaciej> | Hixie: at least he gave actual technical feedback on a specific point! |
| 01:21 | <Hixie> | indeed |
| 01:21 | <othermaciej> | Hixie: B.F. Skinner says he must receive a treat to reinforce this behavior |
| 01:22 | <bewest> | is there some short javascript function I can use to detect whether a browser is in strict or quirks mode? |
| 01:22 | <Hixie> | if we do this <repeat> thing, i really would want the repeated blocks of the template to be in the DOM, but that doesn't really mesh well with the requirements |
| 01:22 | <Hixie> | hm |
| 01:22 | <Hixie> | bewest: look at document.compatMode |
| 01:22 | <Hixie> | it'll be CSS1Compat or QuirksMode, iirc |
| 01:22 | <Hixie> | or something like that |
| 01:22 | <Philip`> | BackCompat, I think |
| 01:23 | <Hixie> | oh right |
| 01:23 | <Hixie> | BackCompat |
| 01:23 | <bewest> | oOOoo |
| 01:23 | <bewest> | nice |
| 01:23 | <Philip`> | (http://developer.mozilla.org/en/docs/DOM:document.compatMode) |
| 01:23 | <Hixie> | is doesn't expose Almost Standards Mode |
| 01:23 | <Hixie> | it |
| 01:24 | <Philip`> | (A more consistent naming convention for the various frozen-bug modes might be nice) |
| 01:25 | <zcorpan> | opera used to have QuirksMode. now it's BackCompat |
| 01:25 | <Philip`> | (except the old inconsistent names have to be frozen too, for backward compatibility...) |
| 01:26 | <zcorpan> | Hixie: you think it would be realistic to get the css21 spec changed to reflect almost standards mode (so the two modes can be merged)? |
| 01:27 | <bewest> | thanks |
| 01:28 | <zcorpan> | (aiui, it would only affect handling of replaced inline elements when there is no text or non-replaced inline elements in the same line box) |
| 01:29 | <Hixie> | zcorpan: realistic how? |
| 01:55 | <zcorpan> | that the wg would accept the proposal to spec how almost standards mode works |
| 01:57 | <Hixie> | oh. no. |
| 01:57 | <Hixie> | they won't even accept that we define how tables render in quirks mode |
| 01:57 | <Hixie> | _and_ standards mode |
| 01:57 | <Hixie> | (which is the same) |
| 01:57 | <Hixie> | instead insisting that the css spec say that html tables are undefined and xhtml tables are different |
| 01:57 | <zcorpan> | yeah |
| 01:59 | <zcorpan> | what i thought was that if i could spec something that implementors can agree on and implement then the csswg could either ignore reality and or accept the proposal |
| 01:59 | <zcorpan> | s/and or/or/ |
| 01:59 | <Hixie> | almost standards is basically an entirely different inline box model |
| 01:59 | <zcorpan> | yes |
| 01:59 | <Hixie> | the inline box model is the most complicated part of css |
| 02:00 | <zcorpan> | yeah... i'm not saying it's trivial... just that any ua would have to implement almost standards mode anyway |
| 02:00 | <Hixie> | yeah |
| 02:00 | <Hixie> | certainly i'm not going to discourage you from trying to spec it |
| 02:00 | <zcorpan> | so having something different in the spec is not helful imho (since there are more ASM documents than there is SM documents on the web) |
| 02:01 | <Hixie> | but it's not something i plan on being involved with for a while :-) |
| 02:01 | <Hixie> | yeah i gave up on the csswg a few months back |
| 02:01 | <zcorpan> | ok |
| 02:22 | <othermaciej> | Hixie: well, it seems like The Director didn't accept the CSS WG's stance on tables |
| 02:22 | <othermaciej> | although of course that has limited value in getting to do something good |
| 02:23 | <othermaciej> | zcorpan: I think there are factions in the csswg that are low on willingness to acknowledge reality |
| 02:24 | <zcorpan> | well... so long as implementors can agree on implementing something then i'm happy. if the csswg ignores it then oh well |
| 02:24 | <othermaciej> | csswg has not gone sufficiently down the tubes yet for implementors to entirely rebel |
| 02:25 | <zcorpan> | keeping almost standards mode and standards mode is also an option, but i'd still like to spec ASM |
| 02:25 | <zcorpan> | i would like them to be merged though |
| 02:26 | <zcorpan> | my limited testing so far has shown that there is not interop in ASM handling |
| 02:26 | <othermaciej> | I would prefer standards mode to change to match ASM |
| 02:26 | <othermaciej> | zcorpan: what's the lack of interop? |
| 02:26 | <zcorpan> | when to use the real line box model or not |
| 02:26 | <zcorpan> | e.g. if you have <div><img> <img></div> |
| 02:27 | <zcorpan> | vs. <div><img><img></div> vs. <div><img>x<img></div> |
| 02:27 | <othermaciej> | which one of those has layout differences, and in what browsers? |
| 02:29 | <zcorpan> | iirc, the first is equivalent to the second in ie, but equivalent to the third in gecko |
| 02:29 | <zcorpan> | i'll have to do a lot more testing on this though |
| 02:32 | <zcorpan> | also, is a non-replaced empty inline element that has a border enough to trigger the real line box model or not? at least opera and gecko disagree about that in ASM |
| 02:33 | <zcorpan> | (gecko does the same as in SM in that case, opera doesn't) |
| 02:33 | <othermaciej> | well, IE has no difference between ASM and SM |
| 02:33 | <zcorpan> | i know |
| 02:33 | <othermaciej> | and both may be wrong |
| 02:34 | <othermaciej> | the first matching the third is probably an artifact of IE dropping whitespace text nodes entirely |
| 02:34 | <othermaciej> | wait, I guess they wouldn't in that case |
| 02:34 | <zcorpan> | no, the text node is there |
| 02:34 | <othermaciej> | so nevermind |
| 02:34 | <othermaciej> | if you can't easily test in Safari yourself I can help (though not right now, most go soon) |
| 02:35 | <zcorpan> | sure, thanks |
| 02:35 | <zcorpan> | i'll let you know when i have more tests |
| 02:37 | <bzed> | jgraham: btw, html5lib is in Debian's testing/unstable since a few days |
| 02:47 | zcorpan | finds the new buzzword "POSH" |
| 02:47 | <zcorpan> | seems to be the same as the "XHTML" buzz a few years back |
| 02:47 | <zcorpan> | just without the X :) |
| 03:04 | <zcorpan> | so HTML5 without style="" would be POSH5 :) |
| 03:05 | <marcosc> | :D |
| 03:10 | <zcorpan> | http://www.ilimitado.de/blog/allgemeines/whatwg-kundigt-html6-an/ |
| 03:18 | <Philip`> | The danger of making April Fools' jokes not quite obvious enough :-) |
| 03:19 | zcorpan | commented |
| 03:26 | zcorpan | notes that the whatwg blog's tagline is now "Please leave your sense of logic at the door, thanks!" |
| 03:26 | <Hixie> | heh |
| 09:50 | <hsivonen> | whoa. so many points about style='' that I think I'll reply to list |
| 09:52 | <annevk> | please also point out the problems with style= |
| 09:53 | <hsivonen> | Philip`: Konq doctype: ack |
| 10:47 | <annevk> | help, HTML5 links to CSSOM |
| 10:58 | <annevk> | hsivonen, the case study is really about adding target= through scripting |
| 11:03 | <hsivonen> | annevk: is that really what the ALA types are doing these days? |
| 11:04 | <annevk> | that's the script on sitepoint |
| 11:04 | <annevk> | i also made one of those scripts |
| 11:04 | <annevk> | using rel=external |
| 11:04 | <annevk> | as indicator |
| 11:04 | <hsivonen> | wow. aren't people even interested in fooling themselves anymore? |
| 11:05 | <annevk> | i don't really see the difference with window.open() |
| 11:05 | <annevk> | people are also using <script> to write out <embed> |
| 11:05 | <annevk> | for Flash |
| 11:05 | <annevk> | (before Eolas) |
| 11:10 | <Philip`> | Maybe there could be a i-know-this-is-nonconforming-but-let-me-do-it-anyway="true" attribute, which makes conformance checkers look away while you do something naughty because the alternatives are worse |
| 11:11 | <zcorpan> | ...or you make those cases conforming |
| 11:14 | <annevk> | "embrace and extend" :) |
| 11:14 | <hsivonen> | annevk, Philip`: do you have suggestions with better net effects? |
| 11:15 | <annevk> | i'm not against |
| 11:15 | annevk | is all for target |
| 11:15 | <annevk> | let authors indicate what they want |
| 11:15 | <annevk> | let the user decide what to do with that information |
| 11:17 | <annevk> | implemented EndTagShort, EndTag, Pi so far... |
| 11:17 | <annevk> | didn't do anything fancy for Pi though... just extracting the name and its contents |
| 11:21 | <hsivonen> | annevk: is your XML5 error recovery streamable (i.e. SAX-friendly)? |
| 11:22 | <annevk> | like not having adoption agency? |
| 11:22 | <hsivonen> | annevk: yes |
| 11:22 | <annevk> | yes |
| 11:23 | <hsivonen> | annevk: cool |
| 11:23 | <annevk> | although it's not entirely clear how this will work out with entities |
| 11:23 | <annevk> | because of the looping |
| 11:23 | <hsivonen> | looping? |
| 11:23 | <annevk> | two entity definitions that refer to each other |
| 11:23 | <annevk> | (entities are like templates) |
| 11:24 | <hsivonen> | my point is that if you are looking for adoption and a wide buy-in, you cannot sacrifice the performance properties of streaming parsers |
| 11:24 | <hsivonen> | annevk: that's not exposed through ContentHandler anyway |
| 11:24 | <annevk> | yeah, so presumably this is a solved problem already because their entity checking happens during streaming |
| 11:25 | <annevk> | except that I don't throw an error but print out the looping entity or simply drop it |
| 11:25 | <annevk> | (well, an error too) |
| 11:25 | <hsivonen> | annevk: do you have a prescribed anti-billion laughs limit? |
| 11:26 | <hsivonen> | you need 16 for the XHTML+SVG+MathML DTD, IIRC |
| 11:26 | <hsivonen> | 16 as the depth, that is |
| 11:27 | <annevk> | what's that? |
| 11:28 | <annevk> | I'm not doing DTDs |
| 11:28 | <zcorpan> | annevk: one more thing i'm curious about, will there be only be one conformance level? e.g. non-validating that don't fetch external entities, but know about some FPIs? |
| 11:28 | <zcorpan> | annevk: but you'll have to spec the internal subset, right? |
| 11:29 | <annevk> | yes, yes |
| 11:29 | <zcorpan> | ok |
| 11:29 | <zcorpan> | good :) |
| 11:29 | <annevk> | (i'm not sure I'll do the crap about known FPIs) |
| 11:29 | <annevk> | just predefine a bunch of cool entities |
| 11:30 | <annevk> | actually, I'm sure I won't do FPIs in my initial version |
| 11:30 | <annevk> | the initial version will ignore all that |
| 11:30 | <zcorpan> | ok |
| 11:30 | <hsivonen> | annevk: aren't you required to do the internal subset? |
| 11:31 | <annevk> | FPIs != internal subset right? |
| 11:31 | <hsivonen> | Formal Public Identifier |
| 11:31 | <hsivonen> | -//blahblah DTD// ffo //EN |
| 11:31 | annevk | will do the internal subset, including entities, default attribute values, attribute types and parameter entities |
| 11:31 | <annevk> | right, that's simply ignored |
| 11:31 | <hsivonen> | annevk: billion laughs can be delivered in the internal subset |
| 11:32 | <annevk> | still need to know what it is |
| 11:32 | annevk | -> lunch |
| 11:32 | <hsivonen> | annevk: it is a denial of service attack |
| 11:32 | <hsivonen> | annevk: I'd rather not paste a test case URL here, because someone might open it in a vulnerable browser |
| 11:33 | <zcorpan> | <!ENTITY ha "ha! ha! "><!ENTITY ha1 "&ha; &ha;">... &ha128; |
| 11:33 | <hsivonen> | http://agorf.void.gr/blog/archive/2005/11/05/the-billion-laughs-attack/ |
| 11:33 | <hsivonen> | beware of the further links there |
| 11:34 | <zcorpan> | those links are 404s :) |
| 12:05 | <annevk> | hsivonen, so laughs is looped entities? |
| 12:06 | <annevk> | that page doesn't tell me much |
| 12:06 | <annevk> | given that the links are broken |
| 12:09 | <hsivonen> | annevk: not looped. growing to power of two. see what zcorpan said above |
| 12:11 | <annevk> | oh right |
| 12:11 | <annevk> | suggestions for entity tokenizing welcome |
| 12:54 | <Dashiva> | This seems relevant: http://www.bash.org/?684098 |
| 15:16 | <annevk> | is <x foo=bar/> a start or empty tag? |
| 15:17 | annevk | leaves it a start tag for now |
| 16:08 | <annevk> | hmm, doctypes |
| 16:22 | <jdandrea> | annevk: <x foo=bar/> - my knee-jerk reaction is "that's a start tag." |
| 16:22 | <jdandrea> | (which happens to comprise an empty element) |
| 16:23 | <Lachy> | it would make the most sense to parse <x foo=bar/> similarly to HTML5, which treats it like <x foo="bar/"> |
| 16:24 | <Lachy> | so it's just a start tag |
| 16:24 | <jdandrea> | Lachy: Oh! I see the distinction. Subtle. :) |
| 16:24 | <jdandrea> | It's not even an empty element then. |
| 16:27 | <Philip`> | Given how people like writing <x /> in XML, it could be convenient to have <x foo=bar/> === <x foo="bar/"> and then <x foo=bar /> === <x foo="bar"/> |
| 16:27 | <Lachy> | Philip`, yes |
| 16:28 | <Philip`> | (so, rather than forcing them to go back and add two quotes when they get it wrong, they only have to go back and add a space if they get it wrong) |
| 16:29 | <Lachy> | that depends on whether or not omitting quotes is conforming or not |
| 16:29 | <Philip`> | Does anyone care if that's conforming, as long as it parses correctly? :-) |
| 16:30 | <Lachy> | yes, it's important to have sensible document conformance requirements, so that conformance checkers can issue errors, that help authors fix documents if the error recovery isn't what they actually intended |
| 16:31 | <Lachy> | it could be that the author intended <x foo=bar/> to be an empty element, but because quotes were omitted accidentially, it's not |
| 16:32 | <jdandrea> | So, at the very least, the author should be warned. |
| 16:32 | <Lachy> | conformance checkers should mostly emit errors instead of warnings |
| 16:33 | <jdandrea> | In the <x foo=bar/> case, would the checker issue a warning or an error? |
| 16:33 | <Lachy> | though, warnings are ok for things that are technically conforming, but not advisable, or explicitly requested by the person checking the doc |
| 16:34 | <Lachy> | an error |
| 16:34 | <jdandrea> | Ah, because it's non-conforming. Got it. |
| 16:37 | <Philip`> | Hmm, I think I'm missing the reason why rather than having error recovery for non-conforming documents that works almost but not quite properly, which will hurt people in rare cases (like when they add a / to an attribute value), it isn't more convenient to have error recovery that makes it obvious those cases are wrong (e.g. by parsing <x foo=bar> into <x foo="" bar="">) so the author knows their code is likely to break in the future (without them usi |
| 16:37 | <Philip`> | ...using a conformance checker) |
| 16:39 | <Lachy> | Philip`, that would be an example of non-fatal error recovery that could significantly break a document |
| 16:41 | <Lachy> | e.g. consider this XHTML: <div class=content> (div used for layout)</div>, the .content selector would no longer apply with that suggested parsing, and so the layout could break significantly |
| 16:43 | <Philip`> | The lack of "" doesn't seem like an error that's going to creep in without the document author noticing (unlike how unencoded &s and badly-nested tags and broken character encodings can creep in) - maybe they'd write 'print "<x foo=$bar>";' once but then they'd notice when testing (since it's not complex dynamically-generated output) and fix it to 'print "<x foo=\"$bar\">;' and it'll work alright |
| 16:44 | <Philip`> | Lachy: Is this meant to be somewhat backward compatible with HTML5 documents? |
| 16:44 | <Lachy> | being somewhat consistent would have the path of least surprise for authors |
| 16:45 | <Lachy> | s/have/be/ |
| 16:46 | <Philip`> | Ah, okay |
| 16:47 | <Philip`> | I guess the problem is <x foo="bar/"> would be the least surprising parse for HTML authors, but <x foo="bar"/> would be the least surprising for XML authors, so you have to consider which is more prevalent and which is least good at writing well-formed documents, in which case I guess you should minimise surprise for HTML authors :-) |
| 16:48 | <Philip`> | *consider which group of authors is ... |
| 17:02 | <jdandrea> | Minor nit: In WA 1.0 section 3.9.4 shouldn't the example dt and dd elements have end tags? |
| 17:02 | jdandrea | is looking at http://www.whatwg.org/specs/web-apps/current-work/multipage/section-prose.html#dialog |
| 17:06 | <Philip`> | http://www.whatwg.org/specs/web-apps/current-work/multipage/section-writing.html#optional says the end tags are optional |
| 17:17 | zcorpan | points to http://forums.whatwg.org/viewtopic.php?t=30 |
| 17:23 | <jdandrea> | Philip `: Ahh, yes indeed - just when I think I've stumbled upon something. Thx. :) |