| 00:16 | <zcorpan> | could we say that class names in html are case insensitive? (so that they match case insensitively in css) would it break any documents? (it is required for quirks mode, i'd presume) |
| 00:17 | <zcorpan> | or is that just considered a css quirk not in html's domain to fix? |
| 00:21 | <othermaciej> | zcorpan: they are case insensitive in quirks mode, but making them CI in quirks mode would likely break things |
| 00:21 | <othermaciej> | zcorpan: I don't know what non-CSS use of classes would be relevant here though |
| 00:22 | <zcorpan> | getElementsByClassName, getElementsBySelector |
| 00:22 | <othermaciej> | neither of those would be used in old content |
| 00:22 | <othermaciej> | so there's no need for compatibility workarounds |
| 00:23 | <zcorpan> | indeed |
| 00:23 | <zcorpan> | you said "but making them CI in quirks mode would likely break things" -- i don't follow, they already are CI in quirks mode |
| 00:23 | <othermaciej> | er |
| 00:23 | <othermaciej> | in strict mode I meant |
| 00:23 | <zcorpan> | ah |
| 00:24 | <zcorpan> | ok |
| 00:24 | <zcorpan> | so it's considered a css quirk then |
| 00:24 | <othermaciej> | you could make those APIs switch on quirks vs. strict mode, but I think that would be unhelpful |
| 00:25 | <zcorpan> | yeah |
| 00:26 | <zcorpan> | i'm just interested in having quirks mode specced... |
| 00:26 | <zcorpan> | most of the web rely on quirks |
| 00:27 | <zcorpan> | not speccing them means new vendors would have to reverse engineer others anyway |
| 00:28 | <zcorpan> | (implementing html5 and css21 would only work with standards mode content) |
| 00:30 | <othermaciej> | yes, although most quirks mode issues are CSS issues, not HTML |
| 00:30 | <othermaciej> | there are a few exceptions, mostly parsing issues |
| 00:30 | <othermaciej> | but I think many parsing quirks could safely be put in both modes |
| 00:32 | <zcorpan> | if not all, though that would perhaps also include <p><table> (could content rely on it being a child? how?) |
| 00:33 | <zcorpan> | why can't <p><table> parsing be dropped from quirks mode? is there an example page that relies on it? |
| 00:34 | <zcorpan> | (either way, i'd like it to be parsed the same in both modes...) |
| 01:33 | <zcorpan> | so ms don't actually want to implement the spec. just use it as a guide and implement something near it. how depressing. and they are introducing more rendering modes that all other browsers will be forced to implement. |
| 01:35 | <zcorpan> | ...unless they become a minority vendor |
| 01:36 | <zcorpan> | in which case it's just a problem for them |
| 01:36 | <jdandrea> | ... and we instigate that by ... :) |
| 01:36 | <jdandrea> | I hear ya. |
| 01:37 | <Lachy> | I wonder if Chris would be willing to compromise on the versioning switch... |
| 01:37 | <Lachy> | Let the authors decide if they want the page to render according to IE[n] bugs when they write the page, or if they want to always render in the latest standards mode |
| 01:38 | <zcorpan> | that could work |
| 01:38 | <Lachy> | e.g. so <!DOCTYPE html> would always trigger the latest standards mode, but if the author adds some version switch, they get that versions |
| 01:38 | <Dashiva> | He would agree to that, I think. However, he argues that most/many/some authors would opt in without meaning to |
| 01:38 | <Lachy> | it's the lesser of two evils |
| 01:39 | <Dashiva> | After all, standards mode was supposed to be for standards, but now it's a frozen bug state |
| 01:40 | <zcorpan> | we should remember what standards are for... to foster interop |
| 01:42 | <zcorpan> | or a shortcut to get interop, if you will. without standards vendors could still reverse engineer each other to get interoperable |
| 01:42 | <Lachy> | ha! "Huh? Wrong about what, exactly?" -- Chris Wilson :-) |
| 08:53 | <hsivonen> | Lachy: do we have a mechanism for blacklisting commenter URLs on the WHATWG blog? |
| 08:53 | hsivonen | deals with yet another einemillioneurohomepage spam |
| 08:56 | hsivonen | finds the Akismet blacklist |
| 08:58 | <hsivonen> | hmm. I guess it is called Spam Karma 2 |
| 08:58 | <hsivonen> | Lachy: how do Akismet and Spam Karma 2 interact? |
| 09:12 | <gavins> | Lachy: yt? |
| 09:14 | <gavins> | nm :) |
| 09:35 | <Lachy> | hey |
| 09:37 | <Lachy> | hsivonen, those plugins seem to work well together. I'm not sure of the details, but if one doesn't catch the spam, the other generally does |
| 09:37 | <Lachy> | gavins, yes? |
| 09:37 | <gavin> | Lachy: I was going to ask where I could find "Lachy's #xhtml log", but I found it |
| 09:42 | <Hixie> | hsivonen: ask lachy |
| 10:37 | <hsivonen> | Hixie: ask Lachy about spam? |
| 10:46 | <Hixie> | about the blog, yeah |
| 10:46 | <Hixie> | i don't admin it |
| 16:58 | <gsnedders> | what would be a good way to mark up a list of aims, and justifications behind those aims? a <dl>? |
| 17:01 | <hsivonen> | gsnedders: depends on the presentation you want |
| 17:01 | hsivonen | hides |
| 17:03 | <gsnedders> | a numbered list of aims (so <ol>), with the justifications set off in a box out of line from the content (an <i>?) |
| 17:06 | <gsnedders> | I think really what I'm unsure about is how to mark up the justification… just another paragraph? |
| 17:11 | gsnedders | settles on nested ol elements, combined with headers for each aim, with a paragraph(s) for the justification |
| 19:26 | <hsivonen> | http://seo.has.no.com/2007/04/seo-tip-for-html5/ |
| 21:41 | bewest | is wondering where to find the appropriate venue for feedback regarding http://www.w3.org/TR/2006/WD-web-forms-2-20060821/#form-submission |
| 21:42 | zcorpan | points out that bewest isn't reading the most resent version of the spec |
| 21:43 | <zcorpan> | but, since the html-wg haven't decided yet about adopting wf2 (might be mistaken here, still have 45 emails to read), -> whatwg list |
| 21:44 | <bewest> | that seems to be the most recent version |
| 21:44 | <bewest> | erm |
| 21:44 | <zcorpan> | it's the most resent WD |
| 21:44 | <bewest> | oh |
| 21:44 | <bewest> | should I be looking somewhere else? |
| 21:45 | <zcorpan> | http://whatwg.org/wf2 |
| 21:45 | <bewest> | great |
| 21:46 | <bewest> | so whatwg mailing list is good? |
| 21:46 | <hsivonen> | would be nice to get the decision in the HTML WG... |
| 21:46 | <hsivonen> | bewest: yes |
| 21:46 | <zcorpan> | bewest: yes |
| 21:47 | <bewest> | hmm I should probably do some homework before posting |
| 21:48 | <bewest> | I'll do some searching as well, but can anyone recall any discussion around using some protocol to allow the application to communicate it's input expectations to the user agent, instead of doing strict type checking of input on the client side? |
| 21:49 | <bewest> | AFAICT the application will have to perform the validation routines again, anyway, since I don't see any mechanism for ensuring that incoming input has already been checked |
| 21:50 | <hsivonen> | bewest: yes, the server has to do it again, because it would be dangerous to trust stuff arriving over HTTP |
| 21:50 | <bewest> | right |
| 21:51 | <bewest> | and in addition, the format/type of input is probably some subset of requirements for validity for many applications, I would suspect |
| 23:18 | <othermaciej> | hsivonen: I will leave it to the chairs to decide when to call the question on adopting the WHATWG specs |
| 23:19 | <othermaciej> | so far there has been no actual objection to the proposal |
| 23:19 | <othermaciej> | I'm not sure if there are even any really serious amendments |