| 00:29 | <annevk> | Hixie, you around? |
| 00:50 | <jwalden> | weep: https://bugzilla.mozilla.org/attachment.cgi?id=301408&action=diff |
| 00:51 | <annevk> | thanks for not changing the API completely :) |
| 00:51 | <annevk> | move from document to window was already slightly annoying, though justified |
| 00:52 | <jwalden> | I have difficulty believing we'd have changed the API |
| 00:52 | <jwalden> | I'm not sure what would have been done, to be honest |
| 00:53 | <jwalden> | manually adding the method at runtime is gross |
| 00:53 | <annevk> | brendan suggested changing the name |
| 00:53 | <jwalden> | I think there'd have been enough pushback for that not to happen |
| 00:55 | <jwalden> | we need to get away from this ABI compat thing, pronto |
| 00:55 | <gavin> | annevk: he suggested changing the method name in our code, and exposing it to content using JS API trickery |
| 00:55 | <gavin> | he wasn't suggesting we change the API... |
| 00:55 | <annevk> | my bad, i inferred that from other comments |
| 00:59 | <annevk> | gavin, then again, are you sure? |
| 00:59 | <annevk> | oh well, doesn't matter |
| 01:00 | <gavin> | yes, I'm sure |
| 01:00 | <gavin> | he was talking about implementation details to avoid the bustage |
| 01:01 | <annevk> | why did he cc hixie then and why did jonas reply the way he did? |
| 01:02 | <gavin> | I think sicking misunderstood |
| 01:02 | <gavin> | and I think he CCed Hixie just to point out the conflict |
| 01:03 | <gavin> | (and perhaps they had discussed Windows macros before or something) |
| 01:08 | <jwalden> | in all honesty, I kinda think it's not a bad idea to avoid name conflicts |
| 01:08 | <jwalden> | witness cssFloat for example |
| 01:09 | <jwalden> | although I'm worried doing so for a Windows API would set a bad precedent |
| 01:09 | <jwalden> | and I don't think it matters now anyway |
| 01:10 | jwalden | wishes push_macro and pop_macro functionality were built into the standards |
| 01:11 | <jwalden> | since people do that sort of thing so much anyway |
| 01:11 | <annevk> | cssFloat, className |
| 01:11 | <annevk> | there are some others |
| 01:13 | <Dashiva> | Speaking of cssFloat, is that being standardized? |
| 01:13 | <annevk> | i think it's part of DOM2Style |
| 01:14 | <Hixie> | Philip`: re creating an element for a token and re the login box, please send mail, i'm ooo for a few days |
| 01:14 | <Dashiva> | I was thinking more if IE had made any hints about adding support |
| 01:15 | <annevk> | Chris Wilson edited that spec, ask him ;) |
| 01:15 | <annevk> | Hixie, he did |
| 01:16 | <annevk> | Hixie, though if you could outline your position on the slash business with access control before you're ooo that'd be nice |
| 01:16 | <annevk> | s/though// |
| 01:16 | <Hixie> | i'll be back wednesday |
| 01:16 | <Hixie> | (i'm already ooo, just checking in from the hotel) |
| 01:16 | <Hixie> | what's the issue? |
| 01:16 | <annevk> | i'd like to know why add a slash at the end |
| 01:16 | <annevk> | and then remove it later on when doing the actual request |
| 01:17 | <annevk> | (prepending a slash instead of resolving against the current URI is also slightly unclear) |
| 01:17 | <Hixie> | oh that's just to make sure that you don't treat /foo.txt as being able to set the rules for /foo.txt.other/file |
| 01:18 | <jwalden> | Dashiva: it's in acid3 :-) |
| 01:19 | <Dashiva> | Ooh, that's probably as good a guarantee as it gets |
| 01:19 | <jwalden> | which is about as much magical pixie dust as can be applied to the problem, externally |
| 01:19 | <annevk> | Hixie, thanks |
| 01:20 | <annevk> | Hixie, I guess I'll draft something up and we'll see what needs changing |
| 01:21 | <Hixie> | cool |
| 01:21 | <annevk> | hopefully done by Wednesday :) |
| 01:21 | <Hixie> | fwiw i got several people send me private feedback about that proposal saying it solved their only concerns with the spec |
| 01:21 | <Hixie> | people from google, that is |
| 01:22 | <annevk> | at least one of them said so on the list |
| 01:22 | <Hixie> | who i'd guess will be amongst the first people to do any large-scale work with this :-) |
| 01:22 | <Hixie> | yeah, indeed |
| 01:22 | <annevk> | good good |
| 01:22 | <annevk> | time for bed now :) |
| 01:22 | <othermaciej> | is this the access-control spec? |
| 01:22 | <annevk> | ttyl |
| 01:23 | <annevk> | othermaciej, yeah, though I'm leaving now; questions -> e-mail |
| 01:23 | <othermaciej> | I don't have any other questions |
| 01:38 | <jwalden> | <https://bugzilla.mozilla.org/show_bug.cgi?id=387706#c61>; clarifies brendan's thoughts, fwiw (wasn't suggesting a rename) |
| 08:41 | <hsivonen> | http://crisp.tweakblogs.net/blog/455/the-road-to-html5-conformance-of-html4-documents.html |
| 08:43 | <zcorpan_> | the first fragment would be conforming with the old rules since ul is struct-inline... but then no-one would understand the old rules anyway |
| 08:46 | zcorpan_ | notes that the article refers to error numbers |
| 08:49 | <zcorpan_> | if we were to allow unescaped ampersands, then we'd still want to catch stuff like &1234; and ∧ |
| 08:50 | <Hixie_> | &this and that; ? |
| 08:50 | <zcorpan_> | i'm not sure we want to allow unescaped ampersands at all |
| 08:50 | <Hixie_> | it's clear that people don't care about the requirement when it comes to href="" attributes |
| 08:50 | <Hixie_> | where commas are rare and ampersands frequent |
| 08:50 | <Hixie_> | er, semicolons |
| 08:51 | <Hixie_> | and so long as no semicolon occurs between the & and the =, which is author-controlled, i don't see that there could be a problem, really |
| 08:52 | <zcorpan_> | right, but it's easy to make mistakes if you don't escape ampersands, since ©=... is replaced with © |
| 08:53 | <Hixie_> | not in attributes, is it? |
| 08:53 | <zcorpan_> | it is |
| 08:53 | <zcorpan_> | but perhaps we should add = to the [a-zA-Z0-9] check |
| 08:54 | <zcorpan_> | and then allow unescaped ampersands but only in attributes |
| 08:55 | <Hixie_> | i thought we'd established that in attributes, you always needed a semicolon |
| 08:55 | <Hixie_> | maybe i remember wrong |
| 08:55 | <zcorpan_> | only if the next character is a-zA-Z0-9 |
| 08:58 | <zcorpan_> | ha! http://www.sitepoint.com/forums/showthread.php?p=3693559#post3693559 is the first i've seen that <p><table> parsing would actually break |
| 08:58 | <hsivonen> | Hixie_: when replying to Jim Correia, I noticed that the obsolete-happiness of HTML5 undermines the argument that everyone should trust we don't need versioning for validation going to HTML5 + 1. |
| 08:58 | <Hixie_> | why? |
| 08:59 | <Hixie_> | zcorpan_: ah |
| 08:59 | <Hixie_> | zcorpan_: well |
| 08:59 | <Hixie_> | zcorpan_: then i don't know what to do |
| 08:59 | <Hixie_> | zcorpan_: i agree it would be nice if everyone added semicolons... but they don't |
| 08:59 | <zcorpan_> | Hixie_: indeed |
| 08:59 | <hsivonen> | Hixie_: the non-versioning story goes that when HTML6 is out, people just start using HTML6 conformance checking |
| 09:00 | <Hixie_> | zcorpan_: so i'm not sure whether we're helping anyone by being pedantic about it |
| 09:00 | <Hixie_> | hsivonen: right |
| 09:00 | <hsivonen> | Hixie_: but for that to happen, HTML6 mustn't disrupt their authoring practices |
| 09:00 | <Hixie_> | hsivonen: or must do so in a way that only improves the web, right |
| 09:00 | <hsivonen> | Hixie_: why should they believe that when HTML5 does disrupt things by obsoleting Transitional stuff? |
| 09:01 | <Hixie_> | hsivonen: obsoleting stuff today that was marked for obsoletion 10 years ago should not come as a surprise to anyone. |
| 09:01 | <zcorpan_> | Hixie_: consider this. you're a cms dev and write a cms that doesn't escape ampersands in attributes |
| 09:01 | <zcorpan_> | Hixie_: you test it and it works fine and you ship |
| 09:01 | <Hixie_> | hsivonen: if people are still stuck in the mid-90s, they need to be informed. |
| 09:01 | <zcorpan_> | Hixie_: one day a user complains that his link doesn't work |
| 09:01 | <zcorpan_> | Hixie_: because it contained ©= |
| 09:01 | <hsivonen> | Hixie_: in practice, the real world lives in Transitional--not Strict |
| 09:01 | <hsivonen> | Hixie_: the Transition never came |
| 09:02 | <Hixie_> | hsivonen: it's coming now. |
| 09:02 | <hsivonen> | Hixie_: the issue is that people disagree on what "only improves the Web" |
| 09:03 | <zcorpan_> | Hixie_: s/test/validate and test/ |
| 09:03 | <hsivonen> | I'd rather see authors spend their time on improving the Web instead of firefighting border='0' copy-paste snippets |
| 09:04 | <othermaciej> | document conformance is hard because there's less at stake |
| 09:04 | <Hixie_> | hsivonen: sure. but that's different from <font>, bgcolor=, align=, etc. |
| 09:04 | <othermaciej> | because people can publish nonconforming documents and there isn't really a problem |
| 09:04 | <othermaciej> | so there's always the temptation to be paternalistic |
| 09:04 | <hsivonen> | Hixie_: I think obsoleting align on th and td doesn't improve the Web |
| 09:05 | <Hixie_> | i think making markup minimal and moving to all css improves the web dramatically |
| 09:05 | <hsivonen> | Hixie_: fwiw, I wouldn't take Transitional wholesale. I want to get rid of <basefont> and <isindex>, for example. |
| 09:05 | <Hixie_> | both in terms of performance and reuse. |
| 09:06 | <Hixie_> | hsivonen: i think that allowing media-specific markup is giving a very wrong message at a time where author are slowly learning the right way. |
| 09:06 | <hsivonen> | Hixie_: if we cared about performance enough to use it as an excuse to ban border='0', we should ban comments for consistency |
| 09:07 | <hsivonen> | and liberal use of whitespace |
| 09:07 | <Hixie_> | hsivonen: i would be more inclined to go back up the slippery slope and remove /> and xmlns="" than i would be to add align="". |
| 09:08 | <hsivonen> | Hixie_: alignment of table cells is conceptually often dependent on the kind of content but Selectors cannot do AI-based matching on the nature of element content |
| 09:08 | <hsivonen> | Hixie_: so letting the author set alignment is the simplest solution |
| 09:09 | <hsivonen> | Hixie_: I don't see what good it would do if authors had to use class='number' instead of align='right' |
| 09:09 | <zcorpan_> | perhaps allow only align=right on <td> and make it mean "number" |
| 09:10 | <hsivonen> | zcorpan_: what if you want to right-align ths that are column heads for numbers? |
| 09:10 | <Hixie_> | hsivonen: just put the class on the table and then use css to set the align on the relevant cells |
| 09:10 | <zcorpan_> | hsivonen: ok, <th> too, meaning that this is a header for a column of only numbers |
| 09:11 | <hsivonen> | Hixie_: what kind of GUI do you envision for writing those selectors? |
| 09:11 | <Hixie_> | hsivonen: emacs |
| 09:11 | <hsivonen> | Hixie_: would my mother who uses dreamweaver be better off if she had to tweak CSS to content instead of using a pre-designed style sheet? |
| 09:12 | <hsivonen> | Hixie_: I think the pro-CSS principle goes wrong if the authors has to tweak CSS to particular content and a pre-designed style sheet won't work |
| 09:13 | <hsivonen> | Hixie_: stuff that changes on a case-by-case basis like image dimensions and cell alignment should be settable in HTML |
| 09:14 | <hsivonen> | Hixie_: with HTML 4.01 Transitional for contextual stuff, I haven't had to add stuff to the style sheet my mother uses in years |
| 09:14 | <Hixie_> | i disagree. i think it's quite reasonable for a wysiwyg editor to work out what rules are necessary to get the desired effect, and i think the incremental rendering argument for img height/width is ok, but the per-image argument is moot |
| 09:15 | <othermaciej> | hsivonen: for tables (proper data tables at least) the main thing missing is column styling, which in theory should be offered but in practice has been too thorny to implement |
| 09:16 | <othermaciej> | (it's rare for alignment to be something tweaked per-cell, but it applies more often to a whole row than a whole column) |
| 09:16 | <hsivonen> | othermaciej: true |
| 09:16 | <othermaciej> | er, I meant that the other way around |
| 09:16 | <hsivonen> | othermaciej: but the point is moot until CSS delivers column styling and top browsers implement it |
| 09:17 | <hsivonen> | othermaciej: until then, authors need to deal with the current per-cell aligment |
| 09:18 | <Hixie_> | well, html5 won't be done for years, maybe someone can get something done in css by then |
| 09:18 | <hsivonen> | Hixie_: have you used Word with autostyles enabled? the user experience becomes horrible, when the editor tries to guess styling rules and adds a level of indirection by guessing |
| 09:19 | <Hixie_> | (i've long proposed [#col=3] and similar) |
| 09:19 | <Hixie_> | hsivonen: that's not what i'm suggesting |
| 09:19 | <othermaciej> | it's too bad tables are row-major instead of column-major, in retrospect the other way would be better for styling |
| 09:20 | <hsivonen> | Hixie_: adding an ID and an # selector doesn't really solve something that authors need solved. I think HTML5 should just let go of the strict non-presentationalism principle |
| 09:21 | <hsivonen> | Hixie_: or what are you suggesting when you say the editor should work out the rules? |
| 09:21 | <Hixie_> | hsivonen: if the user sets all the cells of one column to one type of alignment, it's trivial to come up with a single rule for that with no classes and no IDs, or maybe one class if there are multiple tables. |
| 09:22 | <hsivonen> | Hixie_: is it trivial to round-trip such a rule without editor-specific annotations and have the rule reasonbly editable in GUI? |
| 09:23 | <zcorpan_> | <table><style>...</style><tr>... ? |
| 09:23 | <hsivonen> | Hixie_: CSS isn't threatened if we allow so pragmatic presentationalism in HTML. The extremism isn't pragmatic. |
| 09:23 | <Hixie_> | nothing is trivial when it comes to wysiwyg editing |
| 09:24 | <hsivonen> | zcorpan_: great for legacy parsing... |
| 09:24 | <Hixie_> | i don't think css is threatened even by xhtml transitional |
| 09:24 | <zcorpan_> | hsivonen: indeed |
| 09:24 | <Hixie_> | that's not the concern |
| 09:24 | <hsivonen> | Hixie_: what's the concern? |
| 09:24 | <Hixie_> | < Hixie_> i think making markup minimal and moving to all css improves the web dramatically < Hixie_> both in terms of performance and reuse. |
| 09:25 | <hsivonen> | Hixie_: performance is a red herring if you allow comments at the same time |
| 09:25 | <Hixie_> | why? |
| 09:25 | <Hixie_> | comments are near zero-cost |
| 09:25 | <hsivonen> | Hixie_: and reuse is something that authors need to grow to want instead of some from above forcing it |
| 09:25 | <Hixie_> | not author reuse |
| 09:25 | <Hixie_> | user reuse |
| 09:25 | <hsivonen> | Hixie_: are you referring other than bandwidth performance? |
| 09:26 | <Hixie_> | "mashup", as some people call it |
| 09:26 | <Hixie_> | i mean performance throughout the stack |
| 09:26 | <hsivonen> | Hixie_: wouldn't align on table cells make alignment that is coupled with the nature of content travel better? |
| 09:26 | <Hixie_> | from rendering, to scripting, to editing, to comprehension and maintenance |
| 09:27 | <hsivonen> | Hixie_: do you have quatitative data showing that align on cell performs worse that elaborate selectors? |
| 09:27 | <hsivonen> | than |
| 09:28 | <Hixie_> | nope |
| 09:28 | <Hixie_> | (at least, no hard data at hand.) |
| 09:28 | <othermaciej> | from my experience, it's pretty unlikely that it would perform better on the client side |
| 09:28 | <othermaciej> | presentational attributes are much easier to handle than elaborate selectors |
| 09:29 | <hsivonen> | othermaciej: that's what my intuition tells me |
| 09:29 | <othermaciej> | that's not to say this is a reason in itself to encourage presentational attributes |
| 09:30 | <hsivonen> | Hixie_: as for maintenance, since aligment is coupled with cell content, contextual attributes make more maintenance sense than elaborate (and brittle!) selectors stored at a distance |
| 09:30 | <othermaciej> | on the other hand align on table cells seems to be very much a special case |
| 09:30 | <othermaciej> | mainly due to lack of usable column styling |
| 09:30 | <Hixie_> | hsivonen: i think you are assuming a world where <td align> is used just for saying "this is a number", and i think in practice that this is far from what it is used for. |
| 09:31 | <franksalim> | you're just talking about the align attribute, not inline styling of table cells, right? |
| 09:31 | <othermaciej> | so one wouldn't want to go down the slippery slope to <p align> or other stuff like that |
| 09:31 | <hsivonen> | franksalim: I'm talking about align='right' |
| 09:31 | <hsivonen> | othermaciej: I don't want align on p or div |
| 09:31 | <franksalim> | hsivonen: i don't understand the necessity of preserving that |
| 09:31 | <zcorpan_> | Hixie_: same goes with <table> being used for data tables... |
| 09:32 | <Hixie_> | othermaciej: we're already going down that slope. hence my comment earlier that arguments like this are more likely to see me go back _up_ the slope and remove /> and xmlns="", than they are to see me go further down the slope with adding img border=0, td align="", etc. |
| 09:32 | <othermaciej> | /> and xmlns="" aren't really in the same category |
| 09:33 | <othermaciej> | those are pointless talismans that make chameleon markup theoretically possible for the joy of those who care about such things |
| 09:33 | <othermaciej> | not presentational markup |
| 09:33 | <Lachy> | border=0 certainly isn't needed. That can be handled by a fairly simple selector: a img, img[usemap] { border:0 } |
| 09:33 | <Hixie_> | nor are img border=0 and td align=right compared to, say, style="" or <font>. |
| 09:33 | <othermaciej> | <td align> is more analogous to <b> and <i> |
| 09:33 | <Hixie_> | there are a number of categories |
| 09:33 | <zcorpan_> | Lachy: img { border:0 } |
| 09:34 | <zcorpan_> | othermaciej: indeed |
| 09:34 | <hsivonen> | Lachy: the point of allowing border='0' is to save people the trouble of getting rid of it again, and again, and again |
| 09:34 | <othermaciej> | though I don't think the case is as strong for <td align> as for <b> |
| 09:34 | <Lachy> | for cell alignment, I generally use class names on each table cell that needs special styling, and then style them all at once using a class selector |
| 09:35 | <Hixie_> | hsivonen: i want people to get rid of it. |
| 09:35 | <hsivonen> | Lachy: how is that more noble than <span class='italic'> to avoid <i>? |
| 09:35 | <Lachy> | hsivonen, it's more work to put border=0 on each img, than it is to put a single rule in a reusable stylesheet |
| 09:35 | <Hixie_> | othermaciej: for <b>, i can see how we can define it in a completely non-presentational manner quite legitimately. |
| 09:35 | <Hixie_> | same with <i> |
| 09:36 | <hsivonen> | Lachy: I'm not suggesting that people write border='0'. I'm suggesting that we don't ask people to delete it when a tool or a cute badge template put it in the markup |
| 09:36 | <Hixie_> | so how do we catch new authors writing it? |
| 09:36 | <othermaciej> | so is this because Gecko puts borders around images in links by default? |
| 09:37 | <Hixie_> | that's the problem transitional never solved |
| 09:37 | <hsivonen> | othermaciej: Mosaic, Netscape, Gecko, ... |
| 09:38 | <Lachy> | hsivonen, I'd rather discourage tools and pre-written templates to omit it |
| 09:38 | <hsivonen> | Hixie_: Cathing them isn't that important. it is a relatively benign cargo cult. |
| 09:38 | <hsivonen> | Lachy: good luck |
| 09:38 | <hsivonen> | Catching even |
| 09:38 | <hsivonen> | actually, it isn't quite a cargo cult, since it actually works |
| 09:39 | <hsivonen> | border='0' actually makes planes land |
| 09:39 | <othermaciej> | Gecko should just get rid of the default border |
| 09:39 | <hsivonen> | othermaciej: I agree |
| 09:39 | <hsivonen> | othermaciej: but that doesn't fix the legacy templates, habits and tools |
| 09:40 | <Hixie> | hold on brb |
| 09:40 | <othermaciej> | (I wonder if there's a bug?) |
| 09:41 | <hsivonen> | othermaciej: I couldn't find one yesterday |
| 09:41 | <othermaciej> | hsivonen: yes, 5-10 years after they ship a version of Firefox that does that people might stop including the border='0' |
| 09:41 | <Lachy> | othermaciej, does webkit use a border? |
| 09:41 | <hsivonen> | othermaciej: right, so during that time, is it good use of human time to keep hunting instances of border='0'? |
| 09:41 | <Hixie> | hsivonen: i think catching it is important, because it's one of many things (like align=right, and />, and xmlns="") that litters the web and for which the web would be a better place without |
| 09:41 | <othermaciej> | Lachy: no |
| 09:42 | <Lachy> | ok. So it's just IE and FF |
| 09:42 | <othermaciej> | IE does it too? |
| 09:42 | <othermaciej> | (IE/Mac doesn't) |
| 09:42 | <Lachy> | IE/win does |
| 09:43 | <hsivonen> | :-( |
| 09:43 | <othermaciej> | I wonder if anyone has ever filed a bug about lack of this behavior in WebKit |
| 09:43 | <hsivonen> | Hixie: I think the cost of improving the Web on this particular point is unfavorable compared to the expected improvement |
| 09:44 | <Lachy> | I wonder if IE could drop it for IE8 in all modes? |
| 09:44 | <hsivonen> | Lachy: if they don't for the IE 5.5 mode, copy-pasteable snippets will continue to have border='0' or, worse, style='border:0' |
| 09:45 | <Hixie> | hsivonen: i think that the cost of having an unclear message (you can have border, but only if it is 0, and only on img, not on table, and you can have align=right on td but not on col and not on p...) |
| 09:45 | <Hixie> | hsivonen: is way higher |
| 09:47 | <hsivonen> | Hixie: I'm not convinced that authors think of image border and table border or p and td align as the same things |
| 09:48 | <Hixie> | i'm not convinced of the opposite :-) |
| 09:48 | <Hixie> | sadly, you control the validator, and i control the spec, so we're at somewhat of an impass :-P |
| 09:48 | <hsivonen> | does any client really appreciate the theoretical difference of content-language and lang=''? http://www.w3.org/International/questions/qa-http-and-lang |
| 09:50 | <Lachy> | hsivonen, I think the more important question is does any client do anything useful with either? |
| 09:50 | <hsivonen> | Lachy: pre-Pango Gecko at least did something useful with lang |
| 09:50 | <hsivonen> | Lachy: albeit, theorists didn't like what it did |
| 09:50 | <hsivonen> | (font selection) |
| 09:51 | <othermaciej> | Lachy: seems pretty clear Microsoft wouldn't drop the border for IE5.5 mode or IE7 mode |
| 09:51 | <hsivonen> | obviously, http-equive='content-language' doesn't help with conneg, so the conneg meaning does not matter |
| 09:55 | <annevk> | they all affect :lang() |
| 09:56 | <annevk> | ooh, mediawiki at the W3C: http://www.w3.org/2008/webapps/wiki/Main_Page |
| 09:58 | <hsivonen> | and so PHP tools replace Python tools... |
| 09:58 | <hsivonen> | worse is better, I guess |
| 10:01 | <roc> | we still use lang/xml:lang as part of the font selection process |
| 10:02 | <othermaciej> | if anyone is still curious... |
| 10:02 | <othermaciej> | we do have a bug filed for lacking a border on broken images, but no such bug as far as I can tell for link images |
| 10:03 | <Hixie> | "With browser vendors tripping all over themselves to implement draft modules from the CSS3, HTML5 and XHTML2 specifications, the first wave of web standards is drawing to a close." |
| 10:03 | <Hixie> | browser vendors doing _what_? |
| 10:03 | <Hixie> | http://blogs.pathf.com/agileajax/2008/02/web-standards-w.html |
| 10:03 | <roc> | two out of three ain't bad |
| 10:27 | <takkaria> | also makes reference to WC3 |
| 10:28 | hsivonen | smiles at the paragraph starting with "That's not how fanatics see it, however." |
| 10:47 | <annevk> | zcorpan_, http://forums.whatwg.org/viewtopic.php?t=143 is spam |
| 11:32 | <zcorpan_> | annevk: thanks |
| 11:37 | <Philip`> | Hmm, </br clear=left> is like <br clear=left> in Opera, but like <br> in IE (and is ignored in FF/Safari) |
| 11:40 | <zcorpan_> | Philip`: also in 9.5? |
| 11:41 | <zcorpan_> | (try quirks mode for fx/saf) |
| 11:43 | <Philip`> | Ah - FF2-quirks does it like <br>, Safari-quirks still ignores it |
| 11:43 | <Philip`> | and O9.5 does it like <br> |
| 11:43 | <annevk> | and HTML5 does that too? |
| 11:44 | <zcorpan_> | annevk: yeah |
| 11:44 | <annevk> | good good |
| 11:44 | <Philip`> | "An end tag whose tag name is "br" Parse error. Act as if a start tag token with the tag name "br" had been seen. Ignore the end tag token." |
| 11:44 | <Philip`> | I guess it's implicit that the generated token has no attributes |
| 11:44 | <zcorpan_> | that's how i read it anyway |
| 11:45 | <zcorpan_> | since the attributes are attached to the token that is ignored |
| 11:45 | <Philip`> | A start tag token corresponding to <br foo=bar> satisfies the explicit condition of being a start tag token with the tag name "br" |
| 11:47 | <zcorpan_> | the spec has lots of "act as if a start tag token with...", but it could be clarified that such tokens have no attributes |
| 11:47 | <Philip`> | Might just be a waste of time, though |
| 11:47 | <hsivonen> | looks like the Opera 9.5 approach to MathML can't deal with http://golem.ph.utexas.edu/~distler/blog/archives/001594.html |
| 11:47 | <annevk> | if it's not said explicitly that it has attributes it should've none |
| 11:47 | <annevk> | that's how specs work |
| 11:48 | <Philip`> | annevk: Is it specified anywhere that that's how specs work? |
| 11:48 | <hsivonen> | do both v.nu and html5lib do the right thing already with the current spec wording? |
| 11:48 | <annevk> | Philip`, I'm not sure how explicit it is that doing something that the specification does not explicitly forbid is non-conforming |
| 11:49 | <annevk> | Philip`, but it's pretty much agreed upon that inserting random attributes during full moon is wrong |
| 11:49 | <hsivonen> | Philip`: speccing how specs work reminds me of "entity-escaped HTML in RSS <title> |
| 11:49 | <annevk> | hsivonen, I think html5lib does </br> correctly |
| 11:50 | <annevk> | not sure how many tests we have for that though |
| 11:50 | <Philip`> | hsivonen: Both do |
| 11:50 | <hsivonen> | ok |
| 12:08 | <annevk> | hmm, IETF got media types messed up: http://www.ietf.org/rfc/rfc3986 |
| 12:09 | <hsivonen> | server config is hard |
| 12:10 | <annevk> | I don't disagree |
| 12:10 | <franksalim> | lets go shopping |
| 12:12 | <franksalim> | sorry i was a little bit slow there. call and response joke, right? |
| 12:14 | <annevk> | i guess i'm slow too, because I don't get it :) |
| 12:15 | <Philip`> | http://en.wikipedia.org/wiki/Barbie#Controversies |
| 12:16 | <hsivonen> | http://diveintomark.org/archives/2004/07/06/tough |
| 12:18 | <annevk> | hehe |
| 12:18 | <annevk> | I found markp's post funny the first time I read it, I didn't know they actually made talking Barbies |
| 12:19 | <gsnedders> | hsivonen: peh. it's not hard in RSS! you just check whether it has anything that looks like an end tag (without attributes) or an entity and if it has either, treat it as HTML :P |
| 12:21 | <gsnedders> | annevk: do browsers return the last header if you request Content-Type (or something else relevant to the protocol) and there are multiple headers of the type? What if there are occurrences of the header in the trailer of a chunked response? |
| 12:21 | annevk | tries to make access control more friendly to lots of non-GET methods to lots of different URIs on the same domain |
| 12:22 | <annevk> | gsnedders, no clue |
| 12:22 | <gsnedders> | heh. |
| 12:23 | <annevk> | the method check result cache will now become slightly more complicated |
| 12:23 | <annevk> | is there anything in non-writing that has two mutually exclusive primary keys? |
| 12:24 | <annevk> | plus one primary key that is consistent throughout... |
| 13:08 | <zcorpan_> | http://www.w3.org/TR/wai-aria/ |
| 13:08 | <zcorpan_> | hmm, i'm not in acks |
| 13:09 | <annevk> | was that the plan? |
| 13:09 | <annevk> | :) |
| 13:09 | <annevk> | it still has 'xmlns:aria="http://www.w3.org/2005/07/aaa"';... |
| 13:10 | <annevk> | and lots of RDF and OWL crap |
| 13:10 | <zcorpan_> | indeed |
| 13:10 | <annevk> | "java script snippet :" |
| 13:10 | <zcorpan_> | there are lots of known issues |
| 13:11 | <zcorpan_> | but it's getting there |
| 13:12 | <annevk> | I see |
| 13:12 | <annevk> | your draft was so much better |
| 13:13 | <zcorpan_> | implementing my spec makes you conform to the other, i think :) |
| 13:15 | <annevk> | still seems highly suboptimal |
| 13:15 | <hsivonen> | does the RDF in appendix 7.1.1 embody the data contained in the tables earlier in the document? |
| 13:16 | <zcorpan_> | hsivonen: no idea |
| 13:17 | <zcorpan_> | annevk: feel free to send feedback |
| 13:18 | <hsivonen> | the RDF schema is surprisingly short |
| 13:18 | <annevk> | zcorpan_, k... |
| 13:18 | annevk | makes access control even more complicated first |
| 13:19 | <annevk> | with access control QA teams can rejoice as they'll be guaranteed with work for the coming decade |
| 13:19 | <hsivonen> | is the RDF schema under the Document License or the Software License? |
| 13:20 | <zcorpan_> | annevk: so *that's* why you're working on access control ;) |
| 13:20 | <zcorpan_> | hsivonen: the document conformance criteria are wrong at this point |
| 13:21 | <zcorpan_> | hsivonen: that was pointed out but not fixed before publication |
| 13:21 | <zcorpan_> | (dunno about the license though) |
| 13:22 | <hsivonen> | zcorpan_: ok. I'm looking for reasonably machine-readable copyright-wise unencumbered data about what the roles are, what states and properties apply to which roles and the datatypes of the states/properties |
| 13:22 | <hsivonen> | Document License being encumbered but Software License or MIT license being unencumbered |
| 13:24 | <hsivonen> | though the RDF schema is so small after all, that perhaps typing a RELAX NG schema is simpler than writing a converter |
| 13:25 | <annevk> | zcorpan_, ssh |
| 13:26 | <annevk> | the access control spec will three-level deep <dl> |
| 13:26 | <annevk> | will feature |
| 13:26 | <zcorpan_> | annevk: sounds like a table? |
| 13:27 | <zcorpan_> | or nested state machines? |
| 13:30 | <annevk> | nested state machines |
| 13:31 | <annevk> | i hope it looks reasonable when styled |
| 13:31 | Philip` | thinks there should be a machine-readable way of describing state machines like that, which can get converted into human-readable spec text |
| 13:32 | <annevk> | some people prefer models rather than this, but I'm unsure how to write them down accurately |
| 13:32 | <Philip`> | (I'd particularly like that since it'd save me the work of converting the human-readable text into a machine-readable form...) |
| 13:32 | <annevk> | my state machines don't exactly map to code straigh away |
| 13:33 | <annevk> | at least not the code we write nowadays |
| 13:33 | Philip` | now supports comments, non-special start tags and non-special end tags in his OCaml HTML5 parser |
| 13:34 | <Philip`> | which is not particularly impressive yet :-( |
| 13:35 | <annevk> | ah, you started with doing the treebuilding phase? |
| 13:36 | <Philip`> | I started with the tokeniser, and finished that months ago :-) |
| 13:45 | <annevk> | <ol> -> <ol> -> <dl> -> <dl> -> <dl> ... |
| 13:46 | <hsivonen> | gsnedders: do you cover multiple HTTP status lines? Wikipedia seems to send the status line twice |
| 13:47 | <zcorpan_> | hsivonen: isn't that just interpreted as an unknown/broken header? |
| 13:48 | <hsivonen> | zcorpan_: dunno |
| 13:48 | <hsivonen> | hmm. perhaps the debug features of Common HttpClient are broken--not Wikipedia |
| 13:48 | <hsivonen> | I can't reproduce the problem with telnet |
| 14:00 | <hsivonen> | too easy to make a system unresponsive by simply sending too much data to a browser :-( |
| 14:00 | <hsivonen> | I guess I have to limit the number of error messages V.nu reports |
| 14:01 | <Philip`> | Add a "show more errors" button which dynamically loads the next n error messages using XHR |
| 14:02 | <hsivonen> | Philip`: too complicated. I think I'll just cap the # of errors at a couple of thousand |
| 14:09 | <zcorpan_> | yeah, you'd have to validate again after fixing a bunch anyway |
| 14:10 | <zcorpan_> | 1000 tests are more than enough to fix in one go |
| 14:10 | <zcorpan_> | s/tests/errors/ |
| 14:11 | <annevk> | I ponder if I'd even bother with more than a 100 |
| 14:12 | <zcorpan_> | it's likely simpler to rewrite from scratch |
| 14:13 | <Dashiva> | And you will no longer have the benefit of being able to "fix" hundreds of errors just with alt="" and /> |
| 14:15 | <Philip`> | http://validator.nu/?doc=http://philip.html5.org/misc/quadratic.html |
| 14:20 | <Dashiva> | Error: The s element is obsolete. | At line 3, column 228 | p>x<p>x<p>x |
| 14:20 | <Dashiva> | Seems like the offset is off, somewhat |
| 14:21 | <hsivonen> | Dashiva: I think there's an implied <s> start there |
| 14:22 | <zcorpan_> | yep, it's reconstructing active formatting elements |
| 14:22 | <zcorpan_> | or whatever the algorithm is called |
| 14:24 | <zcorpan_> | http://parsetree.validator.nu/?doc=http%3A%2F%2Fphilip.html5.org%2Fmisc%2Fquadratic.html&submit=Print+Tree |
| 14:25 | <Dashiva> | Shouldn't the error be about implied elements instead, then? |
| 14:25 | <zcorpan_> | i guess the validation layer doesn't know which elements were implied |
| 14:26 | <hsivonen> | Dashiva: there are many "Error: Unclosed elements." |
| 14:26 | <Dashiva> | hsivonen: Then maybe there shouldn't be an error at all for the implied ones |
| 14:27 | <Dashiva> | It seems odd to error on <s>, error on unclosed, and then later create an additional error about an implied duplicate, after all both issues have been reported |
| 14:27 | <hsivonen> | Dashiva: like zcorpan_ said, the validation layer doesn't know which elements were implied. besides, the DOM conformance requirements don't discriminate between implied and explicit |
| 14:27 | <zcorpan_> | or it could perhaps figure it out by comparing the error with the sax event that carries location information (or how it's implemented) |
| 14:27 | <Philip`> | Safari seems to limit things by not cloning a node more than once |
| 14:28 | <hsivonen> | It's more likely that this issue isn't worth tweaking on the validation layer, because nodes getting cloned to this extent is rare in real content |
| 14:29 | <hsivonen> | which is why Safari can get away with its limit |
| 14:29 | <zcorpan_> | Philip`: that might be a good perf win |
| 14:30 | <Philip`> | It looks like a DOS vulnerability in the validator, since an attacker can do O(n) work to make the validator do O(n^2) |
| 14:32 | <hsivonen> | Philip`: yes. I'd prefer fixing this in the spec, though, instead of me putting arbitrary limits in the parser on my own |
| 14:33 | <zcorpan_> | and the validator isn't the only target |
| 14:34 | <hsivonen> | I think the biggest DoS attack vectors against the validator right now are user-provided regular expressions is schemas and user-provided XPath in schemas |
| 14:35 | <hsivonen> | s/is/in/ |
| 15:48 | <gsnedders> | hsivonen: yeah, it'd just be a invalid header |
| 15:48 | gsnedders | did worse than he expected in the computing exam: only 68/80 |
| 16:08 | <zcorpan_> | annevk: spam on your blog |
| 16:10 | <annevk> | :( |
| 16:10 | <annevk> | then again, "without" protection whatsoever it goes surprisingly well |
| 16:11 | <hsivonen> | annevk: is well-formedness the only protection? |
| 16:14 | <annevk> | forced preview and a static nonce too |
| 16:16 | <annevk> | i suppose that if someone really tries to target me i'm screwed |
| 16:16 | <annevk> | i'm not too worried though |
| 16:19 | <zcorpan_> | perhaps the forums need forced preview |
| 16:19 | <zcorpan_> | but i think most of not all spam on the forums are manually entered anyway |
| 16:19 | <zcorpan_> | s/of/if/ |
| 16:20 | <zcorpan_> | or there's a way to register that doesn't involve the register form |
| 16:20 | <krijnh> | annevk: gezien dat ppk het over de IE8 switch gaat hebben vrijdag? |
| 16:21 | <annevk> | ja... |
| 16:21 | <annevk> | en ook dat het vol is! |
| 16:21 | <krijnh> | Juh :) 60 aanmeldingen |
| 16:21 | <annevk> | ik wilde het nog op m'n blog zetten om meer mensen uit te nodigen :) |
| 16:21 | <annevk> | ben ik nu dus te laat mee |
| 16:22 | <krijnh> | Sjah, kantine van Info is niet echt heel groot |
| 16:22 | <krijnh> | Lon komt ook btw |
| 16:22 | <annevk> | leuk |
| 16:22 | <annevk> | geen probleem trouwens, 60 is meer dan genoeg |
| 16:22 | <annevk> | moet ik wel m'n best doen :p |
| 16:22 | <zcorpan_> | hebben jullie en link of so? |
| 16:22 | <krijnh> | ;) |
| 16:23 | <annevk> | zcorpan_, http://fronteers.nl/blog/2008/02/bijeenkomst-8-februari-is-vol |
| 16:23 | <zcorpan_> | s/en/een/ |
| 16:23 | <krijnh> | Hehe |
| 16:23 | <annevk> | zcorpan_, en, "of zo" |
| 16:23 | <zcorpan_> | annevk: bedankt :) |
| 16:23 | <krijnh> | Wordt bijna tijd om de fixed positioning van dat rechtermenu weg te halen :\ |
| 16:24 | <annevk> | misschien moet ik ook even wat vragen voorbereiden voor ppk :evil: |
| 16:24 | <krijnh> | Graag! :) |
| 16:27 | <krijnh> | Maar ik denk wel dat jij de enige browserbouwer bent daaro :) |
| 16:27 | <krijnh> | Dus hou een beetje rekening met het publiek |
| 16:27 | <krijnh> | Ow, btw, 50 aanmeldingen |
| 16:39 | <krijnh> | annevk: zet je je presentatie ook online op je site? Of op de site van Fronteers? |
| 17:29 | <anne_mibbit> | krijnh, my site, www-archive, fronteers, several places, dunno really |
| 17:29 | <anne_mibbit> | krijnh, it's not done yet though :) |
| 22:25 | <aseem> | hi all, I had a question about entity-ized charachters like & $ etc and the way the serializer processes the |
| 22:26 | <aseem> | it seems that other than & all others - for e.g. ¤ ¥ ¢ etc get transformed to the unicode representations |
| 22:26 | <aseem> | I was wondering if there was any way to not make it do that |
| 22:27 | <aseem> | code to read and process html is :http://groups.google.com/group/html5lib-discuss/browse_thread/thread/c2209e63aae5585c |
| 22:27 | <aseem> | sorry not unicode representations I mean character representations |