| 00:11 | <MikeSmith> | hsivonen: I wonder if it would make sense to switch the order of processing in v.nu such that the assertions checking is done prior to the schema checking in the processing pipeline |
| 00:12 | <webben> | sayrer: "how does it lead to inaccessible sites?" it doesn't _necessarily_. |
| 00:12 | <webben> | sayrer: Presentational markup can produce inaccessible sites indirectly if style rather than semantic markup is depended upon for communication. |
| 00:12 | <sayrer> | webben, I definitely agree there are bad things |
| 00:13 | <sayrer> | webben, I don't think "presentational markup" is a meaningful term however |
| 00:13 | <webben> | sayrer: You can (of course) produce exactly the same accessibility problem using generic elements (hello div and span) plus CSS. |
| 00:14 | <webben> | sayrer: do you think "markup conveying formatting information rather than explicitly implying the type of content and its relationship to other content" is meaningful? |
| 00:14 | <sayrer> | webben, no |
| 00:14 | <sayrer> | sometimes, yes. but not as a general principle |
| 00:14 | <webben> | when yes and when no? |
| 00:15 | <webben> | or, why yes when yes, and why no when no |
| 00:15 | <sayrer> | webben, presentational information can lend context to words in the same way that intonation can when words are spoken |
| 00:16 | <webben> | there's a difference between humans inferring information from context and machines inferring informationm, that they can then present to humans in a regularized fashion, from explicit instruction. |
| 00:16 | <sayrer> | accessibility is about humans, I though |
| 00:16 | <sayrer> | thought |
| 00:17 | <webben> | yes. and being about to regularize information into a tailored format is about making information accessible to humans. |
| 00:17 | <webben> | *able to |
| 00:17 | <sayrer> | I think the goal is a good one |
| 00:18 | <sayrer> | I'm not sure banning the <font> element is going to help much |
| 00:18 | <sayrer> | I could see the value of doing that if one could say "rest assured, you are creating an accessible site" in its absence |
| 00:19 | <webben> | Why would you expect it to be a silver bullet? |
| 00:19 | <sayrer> | that is not what I said |
| 00:19 | <sayrer> | or what I meant, rather |
| 00:19 | <webben> | Seems implied in what you said. Can you rephrase perhaps? |
| 00:20 | <sayrer> | banning <font> does not prevent the exact problems we are discussing |
| 00:20 | <sayrer> | since they are all still there with different markup |
| 00:21 | <webben> | the substitution of ambiguous formatting information for (more) unambiguous information about types and relationships? |
| 00:21 | <sayrer> | webben, my view is that these elements are syntactic sugar for CSS properties |
| 00:21 | <sayrer> | they are no more evil than the CSS, and it takes some judgement to figure out whether they are ok |
| 00:22 | <webben> | I think it's confused to say they are syntactic sugar for CSS properties. |
| 00:22 | <sayrer> | why? |
| 00:23 | <webben> | Because what's "objectionable" about font and style is that they bake formatting information into the structured content layer. |
| 00:23 | <sayrer> | that is not an accessibility objection |
| 00:24 | <sayrer> | I definitely agree that there are maintainability concerns, and accessibility concerns |
| 00:26 | <webben> | sayrer: If your point is it's possible to bake formatting information into the structured content layer, without making it impossible for a machine to separate the two, that's strictly true. |
| 00:26 | <sayrer> | webben, concrete examples are better |
| 00:26 | <webben> | Concrete examples of what, sorry? |
| 00:27 | <sayrer> | webben, can you create something that is strictly worse, from an accessibility perspective, that is only enabled by <font> or <center>? |
| 00:32 | <webben> | sayrer: "enabled", probably not. "encouraged", probably yes. encouragement isn't enablement though. |
| 00:32 | <sayrer> | webben, ok, I believe that might be true. what is an example? |
| 00:33 | <webben> | an example of encouragement? |
| 00:33 | <sayrer> | yeah |
| 00:33 | <sayrer> | I am particularly interested in cases that aren't of the form "you aren't smart enough to understand CSS" |
| 00:33 | <webben> | Not entirely sure what that means. |
| 00:34 | <webben> | I think the context is WYSIWYG and the idea that by changing the font you've communicated that something is e.g. a heading, or a field label, or some code. |
| 00:34 | <sayrer> | webben, it seems to me that lots of things we consider to be "good markup" are getting mixed up. Good maintainability, good accessibility, etc. |
| 00:35 | <webben> | Mmm. "mixed up" or ... happen to be produced by the same practices. |
| 00:35 | <sayrer> | and a lot of it is motivated by a sophomoric division of "presentation" and "data" |
| 00:35 | <webben> | "sophomoric" seems like a way to criticise something without having to actually state your criticism. |
| 00:36 | <sayrer> | that is not the definition! :) |
| 00:36 | <sayrer> | but anyway, "the idea that by changing the font you've communicated that something is e.g. a heading, or a field label, or some code" |
| 00:36 | <sayrer> | sure |
| 00:36 | <sayrer> | but do we get an element for each visual subtlety out there? |
| 00:37 | <webben> | Not in HTML. |
| 00:37 | <webben> | CSS came along before that happened! ;) |
| 00:37 | <sayrer> | ok, we're in the same place I think |
| 00:37 | <sayrer> | different ideas of what's right |
| 01:00 | Hixie | ponders whether to make it possible to insert rows into a datagrid dynamically |
| 01:00 | <Hixie> | and how this should affect the IDs of previously-inserted elements |
| 01:08 | <MikeSmith> | Hixie: it would be great if some smart student developer could take on implementing datagrid in Mozilla or Webkit as a GSOC project |
| 01:09 | <MikeSmith> | Hixie: how long do you reckon it will take you to finish the datgrid redesign? |
| 01:11 | roc_ | wonders if datagrid is a good idea |
| 01:12 | <roc> | I'll wait and see :-) |
| 01:12 | <Hixie> | MikeSmith: a few days. |
| 01:12 | <Hixie> | MikeSmith: i'm mostly done, but writing it up takes a while. |
| 01:13 | <Hixie> | ironically, my proof of concept implementation was done in a few hours, speccing it is taking much longer. |
| 01:14 | <MikeSmith> | Hixie: that seems like the way such things usually go |
| 01:14 | <MikeSmith> | hmm, Webkit not participating in GSOC this year |
| 01:15 | <MikeSmith> | http://socghop.appspot.com/program/accepted_orgs/google/gsoc2009 |
| 01:15 | <MikeSmith> | unfortunately |
| 01:21 | <olliej> | MikeSmith: it was a lot of work for relatively little gain last year |
| 01:24 | <MikeSmith> | olliej: I see. I had been hoping the XBL2 stuff would have gotten further along |
| 01:25 | <olliej> | MikeSmith: the xbl guy was basically doomed -- there's no way a GSoC student has a real hope of getting xbl done -- you need to have an astonishingly good knowledge of the way everything needs to work |
| 01:26 | <MikeSmith> | olliej: yeah, I can imagine |
| 01:26 | <MikeSmith> | Keishi Hattori's Web Inspector stuff mostly got done, didn't it? |
| 01:26 | <olliej> | MikeSmith: yeah, and thingy |
| 01:27 | <Niictar24> | Hrm, does a nightly build like minefield automatically update to the latest build? |
| 01:27 | <olliej> | michaelangelo got some good work done |
| 01:27 | <olliej> | but the majority of devs did little to no work |
| 01:27 | <Niictar24> | Or do I need to download a new one if I want to be super up to date? |
| 01:27 | <olliej> | and consumed many hours from actual developers |
| 01:27 | <olliej> | Niictar24: it updates automagically |
| 01:27 | <olliej> | Niictar24: on mac |
| 01:28 | <olliej> | Niictar24: but #webkit would be a more appropriate place to ask |
| 01:28 | <MikeSmith> | olliej: Michaelangelo did WF2 stuff? |
| 01:28 | <olliej> | MikeSmith: i think he ended up doing a mix of inspector and other stuff |
| 01:28 | <MikeSmith> | OK |
| 01:28 | <olliej> | can't remember the specifics, just remember liking his patches :D |
| 01:29 | <MikeSmith> | WEb Inspector is quite a piece of work - definitely has raised the bar as far as expectations for developer tools, and UI for them |
| 01:29 | <MikeSmith> | olliej: what thingy? |
| 01:29 | <Niictar24> | Webkit? Know I know about that channel, but are they going to tell me to go somewhere else when I ask about a mozilla product? :P |
| 01:30 | <olliej> | Niictar24: oh i completely miread your quetion sorry |
| 01:30 | <Rik`> | MikeSmith: I remember he added the autofocus attribute |
| 01:30 | <olliej> | Niictar24: i read "nightly build" as "webkit nightly" |
| 01:30 | <MikeSmith> | Rik`: cool |
| 01:32 | <MikeSmith> | Niictar24: there's also a Help > Check for updates |
| 01:32 | <MikeSmith> | in Minefield |
| 01:33 | <MikeSmith> | and in the Minefield preferences, you can set what the update behavior should be |
| 01:34 | <MikeSmith> | you can have it automatically download and install updates in the background |
| 01:34 | <Niictar24> | Thank ye |
| 01:34 | <MikeSmith> | or can have it prompt you each time if finds a new update |
| 01:34 | <MikeSmith> | I forget what the default is |
| 02:20 | <annevk5> | hmm ok, I suppose i'll file a bug at some point on obsolete feature |
| 02:20 | <annevk5> | s |
| 02:20 | <annevk5> | simply taking HTML4 as reference I think, not want to make it too complicated |
| 07:21 | <hsivonen> | MikeSmith: it's doable to change the RNG/assertion order. Is there a particular pair of messages that would be better that way? |
| 07:24 | <MikeSmith> | hsivonen: obsoleted elements |
| 07:24 | <MikeSmith> | see also my comment at http://bugzilla.validator.nu/show_bug.cgi?id=480 |
| 07:25 | <MikeSmith> | hsivonen: was the design choice to include the obsoleted element in the schema because of the order of the error messages, or for other reasons? |
| 07:25 | <hsivonen> | MikeSmith: so switch order AND remove legacy.rnc? |
| 07:26 | <MikeSmith> | hsivonen: if you remove legacy.rnc, I think it might not be important to change the order at all |
| 07:26 | <hsivonen> | MikeSmith: IIRC, the design choice was to have a single but more sensible error message |
| 07:26 | <MikeSmith> | OK |
| 07:26 | <MikeSmith> | that I can understand |
| 07:26 | <MikeSmith> | having a single message |
| 07:27 | <MikeSmith> | and having it not be the near-useless message "Error: Element foo not allowed as child of element bar in this context" that jing gives |
| 07:27 | <hsivonen> | no, now I remember the real reason |
| 07:27 | <hsivonen> | I wanted the subtree not be suppressed |
| 07:27 | <MikeSmith> | ah |
| 07:27 | <MikeSmith> | yeah |
| 07:27 | <MikeSmith> | hmm |
| 07:27 | <MikeSmith> | that's sort of critical |
| 07:27 | <hsivonen> | but in the general case, not making Jing suppress the subtree was badness |
| 07:27 | <MikeSmith> | really? |
| 07:27 | <MikeSmith> | why? |
| 07:28 | <hsivonen> | I think I had a good reason to change that, yes |
| 07:28 | <hsivonen> | but I've forgotten the details |
| 07:28 | <hsivonen> | that is, the vanilla Jing didn't suppress errors from bogus subtrees |
| 07:28 | <MikeSmith> | oh |
| 07:28 | <hsivonen> | hmm. maybe it was just that Jing's pattern recovery sucked really badly |
| 07:29 | <hsivonen> | so pretty much any element became an error |
| 07:29 | <hsivonen> | or something like that |
| 07:30 | <MikeSmith> | hsivonen: so maybe it would be useful to experiment with tentatively removing legacy.rnc and see? |
| 07:33 | <hsivonen> | MikeSmith: I think it would be worthwhile to see if there have been good patches to Jing trunk before experimenting |
| 07:33 | <MikeSmith> | OK |
| 07:37 | <MikeSmith> | hsivonen: btw, as I mentioned before, NicolasRaoul is here at W3C Japan for a while, half days (he studies Japanese at a language school in mornings, is here at Keio U. in the afternoons -- and he has some time and interest in helping with patches and potential enhancement to v.nu |
| 07:37 | <MikeSmith> | I was talking with him about Jing this morning |
| 07:38 | <MikeSmith> | and I guess you saw the patch he Aelfred2 patch he posted to the whatwg implementors list |
| 07:38 | <hsivonen> | MikeSmith: I'll look at his patch right soon, once I've unblocked another patch over at b.m.o |
| 07:38 | <hsivonen> | s/right / |
| 07:39 | <MikeSmith> | hsivonen: OK. btw, you still trying to solve that mystery crash? |
| 07:41 | <hsivonen> | MikeSmith: no, I resolved it on Friday |
| 07:41 | <hsivonen> | (yay!) |
| 07:41 | <MikeSmith> | ah great |
| 07:41 | <MikeSmith> | congrats on that |
| 07:41 | <MikeSmith> | that must have been pretty frustrating |
| 07:41 | <MikeSmith> | hsivonen: speaking of patches, please put this one in your queue: |
| 07:42 | <MikeSmith> | http://bugzilla.validator.nu/attachment.cgi?id=81 |
| 07:42 | <hsivonen> | yes. OS X gave me totally bogus stacks, but I failed to inspect the stack for bogosity until vlad pointed out to me that it was bogus |
| 07:42 | <hsivonen> | with the right stack, it was less mysterious |
| 07:42 | <MikeSmith> | hsivonen: ah, I saw your tweet about that |
| 07:43 | <hsivonen> | interestingly, the OS X crash reporter and Mac Valgrind gave consistent bogus stacks. I guess they use the same stack grabbing mechanism. |
| 07:43 | <MikeSmith> | yeah, would see so |
| 07:44 | <MikeSmith> | surprised that Valgrind wouldn't use its own thing and not trust the built-in |
| 07:44 | <MikeSmith> | instead |
| 07:44 | <MikeSmith> | that sounds like a major OS bug |
| 07:44 | <MikeSmith> | but not a totally uncommon kind of one |
| 07:45 | <MikeSmith> | I remember seeing problems kind of like that when I was involved with customer work for customers running AIX, HP-UX, Tru64, etc. |
| 07:47 | <MikeSmith> | I learned a lot about OS bugs and about how untrustworthy some so-called enterprise/carrier-grade OS/platforms can be |
| 08:06 | <zcorpan> | hsivonen: your site is now harder to read :( |
| 08:07 | <hsivonen> | zcorpan: which browser/OS? |
| 08:07 | <hsivonen> | zcorpan: due to colors or fonts or something else? |
| 08:07 | <zcorpan> | hsivonen: opera/windows |
| 08:07 | <zcorpan> | hsivonen: font for the body text |
| 08:08 | <hsivonen> | zcorpan: it looks great on Mac and on Linux with no hinting or little hinting in FreeType |
| 08:08 | <hsivonen> | zcorpan: ClearType sucks :-( |
| 08:08 | <hsivonen> | zcorpan: I don't know what I should do. |
| 08:08 | <hsivonen> | zcorpan: Opera and Firefox need to ship font renderer that don't suck on Windows the way Safari does, I guess |
| 08:08 | zcorpan | tries disabling cleartype |
| 08:10 | <zcorpan> | well that made it even worse :/ |
| 08:10 | <hsivonen> | the heading fonts is the one that *really* sucks with any hinting |
| 08:11 | <hsivonen> | (either Windows hinting or FreeType hinting) |
| 08:11 | <hsivonen> | zcorpan: do I have any other course of actions than removing the fonts from Mac and Linux users, too? |
| 08:12 | <hsivonen> | which reminds me that Safari makes it really hard to test the issue sayrer reported if the affected font happens to reside on one's hard drive |
| 08:13 | <hsivonen> | secondary hard drive even! |
| 08:13 | <hsivonen> | it as though Safari had total information awareness of all fonts around all my hard drives |
| 08:14 | <zcorpan> | hsivonen: dunno. maybe try some other font that is easier to read with cleartype? maybe one that isn't italics |
| 08:15 | <hsivonen> | zcorpan: italics??? |
| 08:15 | <hsivonen> | http://api.browsershots.org/png/original/b6/b6e53e1d3771b5ebc8bd9a738257b2aa.png looks interesting |
| 08:15 | <zcorpan> | hsivonen: everything is in italics for me. but might be a bug in opera |
| 08:17 | <MikeSmith> | hsivonen: it might be useful to have an "Error messages" component for v.nu bugzilla |
| 08:18 | <MikeSmith> | or "Error reporting" |
| 08:19 | <zcorpan> | hsivonen: i see that it's not italics in safari and firefox |
| 08:20 | <zcorpan> | hsivonen: it looks good there |
| 08:26 | <zcorpan> | hsivonen: http://img19.imageshack.us/img19/8633/hsivonenfontopera.png |
| 08:26 | <hsivonen> | zcorpan: should I file an Opera bug? I'm seeing it on my virtual machine. |
| 08:27 | <Philip`> | hsivonen: You should add an EOT file for IE |
| 08:27 | <hsivonen> | MikeSmith: why not file the bugs under the components that are responible for errors |
| 08:27 | <hsivonen> | Philip`: nope :-) |
| 08:27 | <zcorpan> | hsivonen: yes please |
| 08:28 | <hsivonen> | zcorpan: ok |
| 08:28 | <hsivonen> | Philip`: I wanted to have an IE-only feature for a draft CSS feature, but it sucked too much in practice to use |
| 08:31 | <Philip`> | hsivonen: If you don't have an EOT file, then the IE developers will be discouraged from adding TTF support because it will make your site start using weird ugly fonts :-) |
| 08:34 | <MikeSmith> | hsivonen: for some cases, I'm not sure users will have any idea what component is responsible |
| 08:34 | <MikeSmith> | for some cases I'm not sure I know myself |
| 08:34 | <MikeSmith> | hsivonen: I meant mostly of reporting of bugs from general public |
| 08:34 | Philip` | supposes he can just disable styles entirely when reading hsivonen's site |
| 08:35 | <MikeSmith> | e.g., if somebody sees a typo in an error message and wants to report it |
| 08:35 | <MikeSmith> | or a formatting problem (e.g., in the spe-scraped output) |
| 08:35 | <MikeSmith> | hsivonen: btw, v.nu bugzilla just gave me a message I've not seen before: |
| 08:36 | <MikeSmith> | undef error - Insecure dependency in exec while running with -T switch at /usr/share/perl5/Mail/Mailer/sendmail.pm line 22. |
| 08:37 | <zcorpan> | MikeSmith: i've got that a few times iirc |
| 08:40 | <Hixie> | set your path to '' |
| 08:40 | <Hixie> | local $ENV{PATH} = ''; |
| 08:41 | <Hixie> | before calling exec(), system(), ``, or qx() |
| 08:41 | <Hixie> | or open('|') |
| 08:42 | <Hixie> | (and use absolute paths) |
| 08:53 | <hsivonen> | zcorpan: DSK-251114 |
| 08:53 | <hsivonen> | MikeSmith: the perl thing is a know bug that I don't know a fix to |
| 08:54 | <hsivonen> | Hixie: I'll try that. thanks! |
| 08:55 | <Hixie> | thank me if it works :-) |
| 08:55 | <hsivonen> | Philip`: does the serif font suck or do you feel like disabling the sans serif font? |
| 08:56 | hsivonen | wishes FreeType and ClearType stopped this hinting business. it's so last century |
| 08:59 | jgraham | doesn't like hsivonen's choice of background colour :) |
| 09:00 | <hsivonen> | maybe I should try 42 shades and get some data :-) |
| 09:01 | <zcorpan> | hsivonen: thanks |
| 09:04 | <Philip`> | hsivonen: The serif font is the only one that doesn't get rendered really badly (in Firefox on Linux) |
| 09:04 | <hsivonen> | Philip`: what's your FreeType hinting setting? |
| 09:04 | <Philip`> | (It doesn't seem like a hinting issue - the shapes are just wrong) |
| 09:04 | <Philip`> | hsivonen: Don't know |
| 09:04 | <hsivonen> | Philip`: do you have a suggestion for a Free as in Freedom sans-serif font that isn't trite and doesn't suck |
| 09:05 | <hsivonen> | Philip`: MgOpen Cosmetica looks good with full AA and no hinting and looks terrible with hinting |
| 09:06 | <hsivonen> | I expect many more Mac users to use fonts that utterly suck on Windows and with FreeType hinting |
| 09:06 | <Philip`> | hsivonen: You could use the one called "sans-serif" :-) |
| 09:07 | <hsivonen> | I wanted to use Linux Biolinum, but I didn't find any public test version of it |
| 09:08 | <hsivonen> | Cosmetica even ships with Ubuntu for Greek use cases |
| 09:08 | <hsivonen> | Philip`: I claim the wrongness of shapes is hinting |
| 09:09 | <hsivonen> | Philip`: because the issue goes away if I tweak FreeType hinting settings |
| 09:09 | <Philip`> | hsivonen: How do you tweak the hinting settings? |
| 09:09 | Philip` | has to go away and will look later |
| 09:10 | <hsivonen> | Philip`: under Ubuntu, System->Preferences->Appearance->Fonts |
| 09:14 | <hsivonen> | w00t. the latest libertine package comes with biolinum!!! |
| 09:18 | <hsivonen> | perhaps I should experiment with the OTF variants, too. in order to get a different glyph rasterizer |
| 09:26 | <hsivonen> | I love this comment in an XML of all places: "many versions of nwalsh docbook stylesheets have bogus URLs; so this can't be an error..." |
| 09:26 | <hsivonen> | I guess Draconian software needs to work with existing content :-) |
| 09:44 | <MikeSmith> | hsivonen: btw, I noticed that the spec snapshot that v.nu is using is gone pretty stale -- it's from November |
| 09:44 | <MikeSmith> | though i guess there have not been so many content-model/attribute changes since then |
| 09:44 | <MikeSmith> | there is addition of keygen, though, for one |
| 09:44 | <MikeSmith> | so message links won't be generated for that until spec snapshot is updated |
| 09:46 | <MikeSmith> | and spec snapshot update will break the build unless Html5SpecBuilder.java is patched |
| 09:46 | <hsivonen> | MikeSmith: yeah, that's what tends to happen :-( |
| 09:46 | <MikeSmith> | yeah, I learned a bit from looking at that code |
| 09:47 | <MikeSmith> | I'm wondering why you just didn't use your HTML parser instead |
| 09:48 | <MikeSmith> | to populate urisByElement etc. |
| 09:48 | <MikeSmith> | hmm, you did I gues |
| 09:48 | <zcorpan> | MikeSmith: you filed the same bug thrice |
| 09:48 | <hsivonen> | MikeSmith: http://bugzilla.validator.nu/attachment.cgi?id=81 looks good, but I didn't test it |
| 09:48 | <MikeSmith> | zcorpan: oops, sorry |
| 09:49 | <hsivonen> | MikeSmith: "Malformed spec: no element currentName.", locator); |
| 09:49 | <hsivonen> | MikeSmith: that looks like my bug |
| 09:49 | <hsivonen> | currentName should be a concatenated variable, not part of the literal |
| 09:50 | <MikeSmith> | hsivonen: I have tested it as much as I could figure to |
| 09:51 | <MikeSmith> | I have some simple per-element tests at http://dev.w3.org/html5/tests/validation/full/invalid/unknown-attribute/ |
| 09:52 | <MikeSmith> | putting an unknown attribute on each element was the simplest single-invalidity test case I could think of that would generated the error messages with those links |
| 09:53 | <zcorpan> | MikeSmith: what about <embed>? |
| 09:53 | <MikeSmith> | zcorpan: embed allows any unknown attribute |
| 09:54 | <MikeSmith> | I have another test for it |
| 09:54 | <MikeSmith> | some other tests |
| 09:54 | <MikeSmith> | http://dev.w3.org/html5/tests/validation/full/invalid/bad-value/embed-height.html |
| 09:55 | <zcorpan> | MikeSmith: i think 0 is allowed now |
| 09:55 | <MikeSmith> | zcorpan: only on <img> |
| 09:55 | <MikeSmith> | I think |
| 09:55 | <zcorpan> | oh |
| 09:55 | <zcorpan> | ok |
| 09:56 | <zcorpan> | consistency++ |
| 10:10 | <MikeSmith> | hsivonen: OK, fixed the problem with the variable name literal in the message string, and re-tested |
| 10:10 | <MikeSmith> | http://bugzilla.validator.nu/attachment.cgi?id=83 |
| 10:12 | <MikeSmith> | though I'm not sure how to malform the spec in such a way as to cause that code to be exercise |
| 10:15 | <hsivonen> | MikeSmith: looks good for check-in |
| 10:24 | <MikeSmith> | hsivonen: cool, thanks |
| 10:39 | <MikeSmith> | hsivonen: http://svn8.cvsdude.com/vvc/whattf/validator?view=revision&revision=311 |
| 10:40 | <MikeSmith> | checked in snapshot of latest spec along with the SpecBuilder change |
| 11:29 | <annevk5> | meh, getting IE8 to run is a pain |
| 11:29 | <annevk5> | just told me two restarts are required |
| 11:46 | <annevk5> | hmm, IE8 dispatches the storage event on the document object?! |
| 11:52 | <annevk5> | in Safari I can't seem to get it dispatch at all |
| 11:52 | <annevk5> | (and curiously onstorage exists on both document and window in Safari) |
| 11:56 | <jgraham> | Note for the curious: getting one's thesis bound remotely is both stressful and insanely expensive |
| 11:57 | <annevk5> | I thought the IE team had fixed the issues :/ |
| 11:57 | hsivonen | wonders how much "insanely" is |
| 11:57 | <hsivonen> | jgraham: would 22.50 EUR per copy incl. VAT be "insanely"? |
| 11:57 | <jgraham> | hsivonen: It is going to end up cosing roughly 60GBP/copy |
| 11:57 | <hsivonen> | wow |
| 11:58 | <hsivonen> | jgraham: did you get leather covers or something? |
| 11:58 | <Dashiva> | Gold plating |
| 11:58 | <jgraham> | hsivonen: No cloth covers are mandatory though |
| 11:58 | <jgraham> | And cost about 30GBP/copy |
| 11:59 | <jgraham> | The remaining cost is printing which I can't easilly do and get the documents to the binders |
| 11:59 | <jgraham> | and delivery of the documents to the depertment |
| 11:59 | <Dashiva> | There's no binding service at the uni? |
| 11:59 | <jgraham> | Dashiva: I think they recommend the commercial service |
| 12:00 | <jgraham> | It is likely that I have done this in a more expensive way than is strictly necessary |
| 12:01 | <annevk5> | IE also throws for trying to set storage keys to invalid XML characters now |
| 12:02 | <annevk5> | which notably violates the spec |
| 12:03 | <jgraham> | annevk5: Is there a testsuite? |
| 12:04 | <jgraham> | Dashiva: It turns out that there is a Uni binding service that is actually just a frontend for the commercial service |
| 12:04 | <jgraham> | With the same prices and so on |
| 12:05 | <annevk5> | I'm just toying with the Live DOM Viewer |
| 12:06 | <Dashiva> | That's... weak |
| 12:06 | <annevk5> | writing an update on IE8 and standards |
| 12:06 | <annevk5> | I actually thought they had fixed most except for a few things but it's a bit worse than that :/ |
| 12:07 | <jgraham> | annevk5: Right but I'm wondering if there is a testsuite or not becuase having testsuites for features that are known to be in development is good |
| 12:07 | <jgraham> | and we have known that storage is in development for some time now |
| 12:07 | <jgraham> | (and obviously it has been released) |
| 12:07 | hsivonen | is again amazed at the epic design failure that .h files are |
| 12:08 | <jgraham> | So if there were a WG testsuite we could have pointed them at it would have been good |
| 12:08 | <Dashiva> | hsivonen: I'm more amazed by the people who defend them |
| 12:09 | <jgraham> | In general it would be good if the HTMLWG created a community around testing features that are known to be in development for various browsers |
| 12:09 | <jgraham> | So that the whole web isn't affected by lame QA at one company |
| 12:10 | jgraham | wonders what happened to takkaria's test czar plan |
| 12:10 | <annevk5> | sure, everyone has bugs |
| 12:11 | <annevk5> | but dispatching an event on a completely different object? come on |
| 12:11 | <annevk5> | I mean, these are not edge case bugs |
| 12:11 | <jgraham> | Sure :) |
| 12:11 | <jgraham> | But a testsuite makes it really obvious that they suck |
| 12:12 | <jgraham> | Marketing "we introduced a cool new HTML5 feature" is undermined somewhat if you are known to fail every test for that feature |
| 12:13 | <jgraham> | So if you want to dispatch the event on a different object for whatever reason then you have to involve the community in that |
| 12:13 | <jgraham> | Or at leeast there is some incentive to |
| 12:16 | <Dashiva> | Whoever made that YTSO mashup must love timpani |
| 12:21 | <annevk5> | Safari seems buggy too |
| 12:21 | <annevk5> | returns undefined rather than null for unknown keys; events don't seem to function |
| 12:22 | <annevk5> | "If there is one thing the world needs, it’s more testcases." |
| 12:23 | <jgraham> | Returning undefined for unknown keys does make more sense, to be fair |
| 12:23 | <jgraham> | (obviously if the spec says otherwise, that's what they should do) |
| 12:24 | <annevk5> | IE does undefined too |
| 12:24 | <jgraham> | We should change the spec than |
| 12:24 | <jgraham> | *then |
| 12:24 | <jgraham> | it makes sense since o = {}; o.p === undefined in normal js |
| 12:24 | <annevk5> | It's nice that we have to figure that out by reverse engineering them |
| 12:25 | <annevk5> | I thought clear unambigious specs were supposed to safe us from this mess? |
| 12:27 | <jgraham> | annevk5: I guess they will just make it better rather than solve all problems |
| 12:28 | <annevk5> | You know, I wonder what Firefox does here. I'm guessing they do it right. |
| 12:29 | annevk5 | will know in few minutes |
| 12:29 | <annevk5> | a few, even |
| 12:33 | <annevk5> | and they do, someone buy me a beer |
| 12:34 | <Dashiva> | Sorry, the GMFMWG hasn't responded yet |
| 12:35 | annevk5 | doesn't get the joke; also not after reading http://krijnhoetmer.nl/irc-logs/html-wg/20090326 |
| 12:36 | <Dashiva> | http://krijnhoetmer.nl/irc-logs/html-wg/20090326#l-104 |
| 12:37 | <annevk5> | heh |
| 12:38 | <annevk5> | Firefox doesn't do events either? Am I missing something? |
| 12:39 | <annevk5> | code: |
| 12:39 | <annevk5> | window.onstorage = function(e) { w(e) } |
| 12:39 | <annevk5> | localStorage.x = "y" |
| 12:40 | <Dashiva> | Maybe they have it on document? |
| 12:40 | <annevk5> | nope |
| 12:40 | <annevk5> | they also do not expose onstorage on document unlike WebKit |
| 12:56 | <heycam`> | qq: "center of rotation" or "centre of rotation" in en-US? |
| 12:56 | <jgraham> | I believe the former |
| 12:56 | <jgraham> | But I don't speak en-US |
| 12:56 | <hsivonen> | :-( https://html5lib.googlecode.com/ is 503 |
| 12:57 | <heycam`> | jgraham, ok thanks |
| 12:57 | <heycam`> | i think it's the former too, since the latter is how i would spell it... but wanted to be sure |
| 12:57 | <jgraham> | hsivonen: http://html5lib.googlecode.com/svn/trunk/ seems to work |
| 13:01 | <remysharp> | qq: is a div still an appropriate element to wrap an arbitrary block of content for styling? Or is that wrong? this particular example doesn't add any semantic value, just required for JS effect |
| 13:05 | <beowulf> | remysharp: yes |
| 13:06 | <remysharp> | ta |
| 13:06 | <remysharp> | I've another question, but it's possible it's not appropriate for this chan - if so, I'll go looking elsewhere - |
| 13:07 | <remysharp> | I'm using xhtml content type serving to get FF2 to render the html5 properly - which works just fine, but - |
| 13:07 | <remysharp> | when it encounters an html entity that it doesn't know about, i.e. • it borks |
| 13:08 | <remysharp> | Obviously this would be fixed by specifying a DTD, but that's not the way html5 is done |
| 13:08 | <beowulf> | that's xml for you, define the entity in the dtd or use xml entites |
| 13:08 | <beowulf> | entities |
| 13:09 | <annevk5> | or don't use XML |
| 13:09 | <remysharp> | annevk5: sure, and I know FF2 has zip all usage, but it looks aweful - and the JS fix for FF2 needs a lot more work |
| 13:11 | <annevk5> | I wouldn't know, I'm running Firefox 3.6something |
| 13:11 | <jgraham> | remysharp: Seriously ignore FF2 |
| 13:11 | <remysharp> | I would if I had justified ignoring IE6, but since the site works perfectly in that browser, I can't live with the idea that it's shot all over the place in FF2 |
| 13:11 | <remysharp> | and the htaccess fix is easy |
| 13:12 | <remysharp> | and working - but it's just html entities that was tripping me up |
| 13:12 | <annevk5> | doesn't sound like working to me :p |
| 13:12 | <beowulf> | would it be better to have an #html5 room for html authors like me to ask q's or is here fine? |
| 13:12 | <jgraham> | remysharp: You know that is not a rational argument, right |
| 13:12 | <jgraham> | beowulf: Here is fine |
| 13:12 | <remysharp> | jgraham: absolutely! |
| 13:13 | <remysharp> | just a matter of pride if it doesn't blow my mind to fix it :-) |
| 13:14 | <jgraham> | remysharp: OK, well the other solution is to not use entities |
| 13:14 | <jgraham> | Ideally you should just use UTF-8 over the wire |
| 13:14 | <remysharp> | jgraham: I've just changed it to xml entities and it works perfectly |
| 13:14 | <annevk5> | jgraham, that's not an argument against entities |
| 13:14 | <remysharp> | oh - as in the raw bullet character? |
| 13:14 | <jgraham> | annevk5: What isn't? |
| 13:15 | <jgraham> | That they don't work? |
| 13:15 | <annevk5> | jgraham, "just use UTF-8" because it's still easier to type an entity than the actual character |
| 13:15 | <jgraham> | annevk5: I agree |
| 13:15 | <annevk5> | e.g. … |
| 13:15 | <jgraham> | But if you are producing XML you need a real serializer anyway so doing entity->UTF-8 conversion should be trivial |
| 13:16 | <annevk5> | in fact, when I want the character I usually construct a data URL and copy and paste |
| 13:16 | <jgraham> | annevk5: &hellip is not a great example (it is erasonably easy to type) |
| 13:16 | <jgraham> | But $cint; probably is |
| 13:17 | <annevk5> | the character the entity represents is not easy to type |
| 13:17 | <annevk5> | not for me anyway |
| 13:24 | <jgraham> | annevk5: It is … right? If you set a compose key under Linux, that is just Compose then .. |
| 13:28 | <annevk5> | dunno, I'm using my Mac atm because I'm running Windows XP on the other machine to play with IE8 |
| 13:28 | <annevk5> | also, I don't know of Compose or its shortcuts nor do I know for most other characters |
| 13:29 | <annevk5> | (even the euro character...) |
| 13:29 | <jgraham> | annevk5: I don't know most entities :) |
| 13:30 | <jgraham> | (nor do I know most compose shortcuts) |
| 13:30 | <annevk5> | I know a bunch for umlauts and such |
| 13:30 | <annevk5> | and for the euro :) |
| 13:32 | <remysharp> | if you want entities - there you go, a nice little dashboard widget too: http://leftlogic.com/lounge/articles/entity-lookup/ |
| 13:52 | <beowulf> | what is wrong with <h1><p>Typeline</p><p>Mainline</p></h1>? |
| 13:53 | <annevk5> | you want <header> |
| 13:54 | <beowulf> | I do for sure, but when we then go onto describe what header means and how it's used it sounds very much like the above, so why not do that? i'm curious is all |
| 13:55 | <Dashiva> | Because those aren't paragraphs? |
| 13:56 | <annevk5> | because typeline and mainline can't be distinguished then |
| 13:56 | <annevk5> | would be one reason I can think of |
| 13:56 | <hsivonen> | Grr. Parallels refuses to virtualize non-Server Mac OS X |
| 13:57 | <beowulf> | Dashiva: are they not paragraphs because they are in a <h1> or because of the content? |
| 13:58 | <Dashiva> | Both? |
| 14:19 | <hsivonen> | whee! now that I worked around the Opera 10 @font-face bug, WebKit shows me all italics! |
| 14:20 | <annevk2> | fonts are a nightmare :/ |
| 14:27 | <hsivonen> | filed https://bugs.webkit.org/show_bug.cgi?id=25207 and https://bugs.webkit.org/show_bug.cgi?id=25208 |
| 14:27 | <hsivonen> | WebKit has such small bug ids :-) |
| 14:33 | <virtuelv> | hsivonen: details on our @font-face bug? |
| 14:33 | <Rik|work> | hsivonen: damn, i've filed https://bugs.webkit.org/show_bug.cgi?id=25209 :) |
| 14:33 | <Rik|work> | i'll close mine |
| 14:36 | <annevk2> | fwiw, I think dhyatt did that on purpose |
| 14:36 | <Rik|work> | annevk2: there's maybe a reason behind but the result is really ugly |
| 14:36 | <hsivonen> | virtuelv: DSK-251114: font-weight and font-style modifiers ignored on @font-face |
| 14:37 | <virtuelv> | hsivonen: thanks |
| 14:37 | hsivonen | wishes these face selection issues within a family get fixed before Opera 10 final and Safari 4 final |
| 14:37 | <hsivonen> | otherwise, multiface families will suck badly |
| 14:38 | hsivonen | wonders why OpenType models italics as a separate face but small caps as alternative glyphs |
| 14:49 | <takkaria> | jgraham: my test czar plan got taken over by real life |
| 14:50 | <jgraham> | takkaria: You should consider abandoning rel life then |
| 14:50 | <jgraham> | *real |
| 14:51 | <takkaria> | I have, many times, but it always seems to come back like some kind of weed between the cracks of the pavement |
| 15:00 | <jgraham> | annevk5: Are you going to mention the undefined vs null thing for stoarge somewhere? |
| 15:20 | <hsivonen> | how do I intercept a email that is waiting for sending when Mail.app is being stupid with its threads? |
| 15:22 | <hsivonen> | hmm. http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0188.html went through, so I can kill Mail.app |
| 15:24 | <annevk2> | jgraham, other than on my blog? not really :p |
| 15:33 | <jgraham> | annevk2: I'm pretty sure that your blog doesn't count |
| 15:34 | <annevk2> | watch and learn |
| 15:34 | annevk2 | files a bug |
| 15:39 | <annevk2> | http://www.w3.org/Bugs/Public/show_bug.cgi?id=6814 |
| 15:39 | jgraham | wwonders what he is supposed to be learning |
| 15:40 | <jgraham> | In other, marginally related, news, I wonder if there is any point in filing web-compat bugs on the ES5rc |
| 15:42 | <annevk2> | seems useful |
| 15:42 | <annevk2> | you were supposed to learn that blogs work and then I gave in and filed the silly bug report |
| 15:42 | <jgraham> | Well, we shall see |
| 15:43 | <annevk2> | maybe also keep track of web-compat issues with the spec on a wiki page |
| 15:43 | <annevk2> | i made one for HTTP |
| 15:43 | <annevk2> | where they also don't care too much |
| 15:46 | <jgraham> | Yeah, it would be nice to do a "Web ECMAScript" spec that documented all the things that actually have to be supported in browsers |
| 15:47 | <hsivonen> | aargh. Google still hasn't a proper mechanism for filing bugs on Google Maps |
| 16:51 | <annevk2> | hsivonen, I think both your changes to Selectors make sense |
| 16:52 | <annevk2> | hsivonen, maybe it helps if we provide explicit change requests |
| 17:09 | <zcorpan> | hsivonen: "Downloadable fonts are not supported." - https://developer.mozilla.org/en/Mozilla_Web_Developer_FAQ |
| 17:11 | <zcorpan> | hsivonen: also, "According to the Accept header, Mozilla prefers application/xhtml+xml over text/html." - is that still the case? |
| 17:12 | <zcorpan> | hsivonen: also "Currently Mozilla does not catch character encoding errors" |
| 17:14 | <zcorpan> | hsivonen: "HTML-specific CSS exceptions do not apply. For example, the body element gets no special treatment." |
| 17:16 | <zcorpan> | hsivonen: "Simple XLink" - is that still supported? |
| 17:32 | <annevk2> | Is Steve arguing ATs trump authors? |
| 17:34 | <tantek> | would that just be a special case of user preferences trumping authors? e.g. user stylesheet etc. |
| 17:35 | <annevk2> | more like change the spec because AT might not be fixed |
| 17:35 | jcranmer | struggles to expand the acronym |
| 17:35 | <jcranmer> | Applachain Trail is funny though :-) |
| 19:14 | <zcorpan_> | annevk2: "The menu element is redefined to be useful for actual menus." - please elaborate on "menus" so people don't confuse it with <nav> |
| 19:14 | <zcorpan_> | annevk2: e.g. s/actual menus/toolbars and context menus/ |
| 19:19 | <zcorpan_> | annevk2: "Defined that this in the global object returns a WindowProxy object rather than the Window object." - clarify that it's the javascript "this" |
| 19:20 | <zcorpan_> | annevk2: "The way media elements load resources has been clarified." - changed, even |
| 19:21 | <zcorpan_> | annevk2: "You are now allowed to specify the meta element with a charset attribute in XML documents if the value of that attribute matches the encoding of the document." - not the full truth |
| 19:24 | <zcorpan_> | annevk2: "A "storage mutex" concept has been added to deal with separate pages trying to change the document.cookie and localStorage object at the same time." - could be interpreted as the problem being changing document.cookie and localStorage at the same time |
| 19:41 | <zcorpan_> | annevk2: btw, i've made createElement() case-folding in xml in web dom core |
| 19:42 | <annevk2> | saw that, wondered whether I should mention it in the email, but decided not to |
| 19:49 | <dbaron> | annevk2, your latest public-html message has an mid URI that doesn't resolve for me |
| 20:33 | <annevk2> | dbaron, oh, it was meant to point to http://lists.w3.org/Archives/Public/www-style/2009Apr/0273.html |
| 20:33 | <annevk2> | dbaron, I just copied it from the email |
| 21:00 | jgraham | discovers dsypathy is a real word |
| 21:54 | <annevk2> | "HTML5 looks great but I think you should stick to page layout and leave protocols either to JavaScript or to some other extension mechanism." |
| 21:54 | <takkaria> | excellent, if only all comments were along those lines |
| 22:03 | <franksalim> | annevk2: where is that quote from? |
| 22:09 | <Hixie> | didn't we get rid of all the protocols already? |
| 22:09 | <Hixie> | oh that's the registerProtocolHandler() e-mail? |
| 22:12 | <takkaria> | http://blog.nihilogic.dk/2009/02/html5-canvas-cheat-sheet.html is nice |
| 22:33 | <annevk2> | it's the one about <keygen> and why we should drop it |
| 22:34 | <annevk2> | this is the closing line |
| 22:34 | <annevk2> | I think it's great |
| 22:37 | <mpilgrim_> | annevk2: |
| 22:37 | <mpilgrim_> | annevk2: "representa control for key pair generation" --> "represents control for key pair generation" |
| 22:37 | <mpilgrim_> | in http://dev.w3.org/html5/html4-differences/ |
| 22:38 | <mpilgrim_> | annevk2: "For the XML syntax authors" --> "For the XML syntax, authors" |
| 22:39 | <mpilgrim_> | annevk2: "The HTML 5 language has a "custom" HTML syntax" --> "The HTML 5 language has a "custom" SGML syntax" ? not sure what else you would mean here, the way it's phrased now doesn't make sense |
| 22:40 | <Hixie> | s/"custom" HTML/dedicated/, probably |
| 22:42 | <mpilgrim_> | "space separated list" --> "space-separated list" |
| 22:43 | <mpilgrim_> | also, @ping attribute description mentions URIs in one sentence, then URLs later in the same paragraph |
| 22:43 | <annevk2> | I'll just make it "in HTML syntax and in XML syntax" |
| 22:43 | <mpilgrim_> | but section 2.4 says HTML now has native support for IRIs. |
| 22:44 | <mpilgrim_> | "The area element, for consistency," <-- consistency with what? |
| 22:45 | <mpilgrim_> | (i assume the a and link elements) |
| 22:45 | <mpilgrim_> | "The base element can now have a target attribute as well, mainly for consistency with the a element (it is also widely supported)." --> "The base element can now have a target attribute as well, mainly for consistency with the a element. (This is already widely supported.)" |
| 22:46 | <annevk2> | changed all URI to URL and clarified the IRI paragraph |
| 22:49 | <mpilgrim_> | "Using this feature should enhance the user experience as the user can turn it off if he does not like it, for instance. " --> "This is a superior alternative to script-based solutions because browsers and assistive technologies can more easily override it." |
| 22:49 | <mpilgrim_> | bah, still not happy with that sentence |
| 22:49 | <mpilgrim_> | feel free to ignore some or all of this |
| 22:49 | <mpilgrim_> | especially that one |
| 22:49 | <annevk2> | i'll ignore that last one then :) |
| 22:50 | <mpilgrim_> | "(e.g. one they are not a descendant of)" --> "e.g. these elements can now be placed anywhere on a page, not just as descendants of the form element" |
| 22:52 | <mpilgrim_> | "They are equivalent to the attributes not prefixed with form on the form element and override those." --> "If present, they override the action, enctype, method, novalidate, and target attributes on the form element." |
| 22:52 | <annevk2> | I guess I should e.g. to i.e. as well then |
| 22:54 | <mpilgrim_> | "because their effect is purely presentational and whose function" --> "because their effect is purely presentational and their function" |
| 23:02 | <mpilgrim_> | should mention somewhere that @alt is now optional if-and-only-if (whatever the spec says these days) |
| 23:06 | <mpilgrim_> | "This API has the necessary security restrictions in place" seems like a bold and unsubstantiated claim :) |
| 23:09 | <mpilgrim_> | rest looks great |
| 23:12 | <Philip`> | jgraham: About binding: Can't you just ask somebody in the remote location to do it for you? |
| 23:12 | <Philip`> | (like, a proper person, not a representative of a commercial service) |
| 23:12 | <Philip`> | annevk5: I thought IE8 final had changed (since beta) to return undefined instead of null, since I pointed it out in response to their submitted tests |
| 23:20 | <annevk2> | you said they should return undefined instead? |
| 23:23 | <Philip`> | I think I said they should do what the spec says, and I think they said they changed their tests to match that, and I think I might have tested the implementation and found it was fixed, but I might be hallucinating |
| 23:41 | <annevk2> | Philip`, I'm pretty sure I did w(localStorage.foobar) and it said undefined but if someone could verify that again that'd be cool |
| 23:47 | <Hixie> | why would it not say undefined |
| 23:54 | <Philip`> | annevk2: Oh - it looks like they changed localStorage.getItem('foobar'), but not localStorage.foobar |
| 23:55 | <Philip`> | (At least getItem('foobar') returns null in current IE8, while .foobar returns undefined) |
| 23:57 | <Hixie> | that's what the spec says should happen |
| 23:58 | <Philip`> | Really? |
| 23:59 | <Hixie> | localStorage.foobar doesn't exist on the object, and ECMA-262 says it should thus return undefined |
| 23:59 | <Hixie> | getItem() says to return null for unknown values |
| 23:59 | <Dashiva> | But doesn't property access map to get/setItem? |
| 23:59 | <Philip`> | That's quite non-obvious from the spec |
| 23:59 | <Hixie> | yes, for properties that are present |
| 23:59 | <Hixie> | Philip`: read WebIDL |
