| 00:49 | <Hixie> | heh, i just did a study to look at the average page rank of pages with different kinds of scripts |
| 00:49 | <Hixie> | and pages with rollovers on average have low pagerank :-P |
| 06:17 | <Hixie> | maybe instead of "high quality" and "low quality" as conformance levels, we should have "high priority" and "low piority" errors |
| 06:17 | <Hixie> | where high priority = things that really cause a lot of problems and should definitely be fixed |
| 06:18 | <Hixie> | and low priority = things that cause problems, but not disasters |
| 06:18 | <Hixie> | so for example a missing </style> is a high priority error since it hides the whole rest of the page |
| 06:18 | <othermaciej> | wouldn't most content model violation bugs then be low priority? |
| 06:19 | <Hixie> | but a style="" attribute in a production page is a low priority error since it just means that you can't easily add an alternative style sheet |
| 06:20 | <othermaciej> | now there's a marginally good argument against using style="" (though it applies equally to <style scoped> and even <style>, no?) |
| 06:20 | <Hixie> | <style> can have a title="" |
| 06:20 | <Hixie> | (without one it's a "persistent style sheet") |
| 06:21 | <Hixie> | (but it's easy to migrate from one persistent style sheet to a set of alternatives just by adding titles) |
| 06:22 | <othermaciej> | that seems about as good a reason for warning as it would be to warn on onclick because you can't have more than one handler set that way, and additional ones get slightly different behavior (scope chain, etc) |
| 06:23 | <othermaciej> | i.e. not completely bogus, but if it were a compiler I'd probably turn that warning off |
| 06:25 | <othermaciej> | and if we're talking mandatory vs. optional diagnostics, then it might be better to leave it up to individual validators to decide what warnings they emit in addition to errors, and compete on usefulness and quality of those |
| 06:25 | <othermaciej> | much as C compilers all give basically the same syntax errors, but compete on usefulness of optional warnings |
| 06:26 | <Hixie> | yeah |
| 06:26 | <Hixie> | maybe |
| 06:26 | <othermaciej> | (I suspect gcc has far more useful warnings than it would if they were all defined by the C standard) |
| 06:26 | <othermaciej> | it wouldn't hurt for the spec to editorially suggest some things as possible optional diagnostics |
| 06:27 | <othermaciej> | I should get going |
| 06:27 | <Hixie> | ttyl |
| 06:27 | <othermaciej> | (btw some people might find a warning on use of inline event handler attributes actually useful) |
| 06:27 | <othermaciej> | (since it's not uncommon to ban them as a house style for a particular site) |
| 06:44 | <Hixie> | i have no idea if sql does what i want it to do here |
| 06:44 | <Hixie> | but i guess i'll find out |
| 06:47 | <MikeSmith> | Hixie - sql for the status-annotations server-side stuff? |
| 06:47 | <Hixie> | yeah |
| 06:47 | <Hixie> | i'm doing: |
| 06:47 | <MikeSmith> | you got the database schema put together now? |
| 06:47 | <Hixie> | SELECT `annotation`, `section` FROM `section` GROUP BY `annotation` ORDER BY `change` DESC |
| 06:48 | <Hixie> | with a table that has annotation, section, change fields |
| 06:48 | <Hixie> | and i'm hoping that it'll give me the most recent section for each annotation |
| 06:49 | <MikeSmith> | seems like it will if the data is actually what it should be |
| 06:49 | <Hixie> | how about: |
| 06:49 | <Hixie> | SELECT `annotation`, `key`, `value`, CONCAT(`annotation`, ':', `key`) AS `group` FROM `implementations` GROUP BY `group` ORDER BY `change` DESC |
| 06:49 | <Hixie> | ...giving me the most recent value for each annotation-key pair |
| 06:50 | <MikeSmith> | what is in "key"? just a generated id? |
| 06:50 | <Hixie> | key is a string |
| 06:50 | <Hixie> | one of 'firefox', 'ie', 'safari', 'opera |
| 06:50 | <Hixie> | ' |
| 06:50 | <MikeSmith> | oh |
| 06:52 | <MikeSmith> | that don't look quite right to me |
| 06:52 | <Hixie> | oh? |
| 06:53 | MikeSmith | takes a look at mysql reference |
| 06:54 | <Hixie> | it's syntactically correct |
| 06:54 | <Hixie> | i just don't know if it's correct :-) |
| 06:54 | <MikeSmith> | ah, ok |
| 06:55 | <Dashiva> | hm |
| 06:57 | <Dashiva> | I suspect it would work because of how MySQL does things, even though it's not technically a reliable feature |
| 06:57 | <Hixie> | how would you do it reliably in sql? |
| 06:58 | <Dashiva> | I can only think of ugly ways at the moment (subqueries and whatnot) |
| 06:59 | <Hixie> | so yeah, like i said, i dunno if sql can do what i want of it :-) |
| 07:00 | <Dashiva> | Let's see how un-ugly I can imagine it |
| 07:04 | <MikeSmith> | Hixie - I think the high-priority vs low-priority distinction could be useful |
| 07:06 | <MikeSmith> | would be really useful to try to get some more implementors to work on conformance checkers, and for people to use those |
| 07:06 | <Hixie> | webkit is starting to have more and more of one |
| 07:06 | <MikeSmith> | in order to get some real feedback |
| 07:06 | <Hixie> | the iphone can even tell you about html parse errors |
| 07:06 | <MikeSmith> | nice |
| 07:07 | <MikeSmith> | so I think one real risk is that conformance-checker maintainers would start adding "ignore someClassofErrors" options |
| 07:08 | <MikeSmith> | due to pressure from users |
| 07:08 | <Hixie> | how much i care depends on what the error is |
| 07:08 | <Hixie> | or rather, what i think about it |
| 07:09 | <MikeSmith> | yeah, of course |
| 07:09 | <Hixie> | if it's because the spec has some requirement that really doesn't help anyone, then we should change the spec |
| 07:09 | <Hixie> | if the error is there because they're screwing users, then... |
| 07:13 | <Dashiva> | Hixie: If your MySQL is new enough to support subqueries, this should work |
| 07:13 | <Dashiva> | SELECT annotation, section FROM section WHERE (annotation, change) IN ( SELECT annotation, max(change) FROM section GROUP BY annotation ); |
| 07:13 | <Dashiva> | I hope there's an index of annotation :) |
| 07:14 | <Hixie> | yeah |
| 07:14 | <Hixie> | there are indexes all over the place |
| 07:15 | <Hixie> | what on earth does that do? :-) |
| 07:15 | <Hixie> | fwiw i'm using mysql with VERSION() == 4.1.16-standard-log |
| 07:16 | <doublec> | Quick <video> question. If there are no <source> elements that are picked, and there is therefore no media resource, can a non-javascript enabled browser do anything meaningful to let the user know? |
| 07:16 | <Dashiva> | It gets the newest date for each annotation, and then selects the rows containing those annotation,date pairs |
| 07:17 | <Hixie> | wow |
| 07:17 | <Hixie> | that's some fancy syntax right there |
| 07:17 | <Hixie> | looks like this version of mysql doesn't do that |
| 07:17 | <Dashiva> | Yeah, MySQL only started doing subqueries recently. Might be 5.0 |
| 07:18 | <Dashiva> | Could no doubt emulate it with a join on itself and so fancy tricks, though |
| 07:18 | <Hixie> | you know, maybe i should have implemented the code that actually _adds_ annotations first |
| 07:18 | <Hixie> | leaving it til last is somewhat preventing me from actually _testing_ anything |
| 07:19 | <Hixie> | well we'll see if i just get what i need by luck first |
| 07:24 | Hixie | realises he's actually completely left off the ability to add sections, both in his UI, in his client-side logic layer, in his client-side network layer, in his server-side network layer, and in his server-side database logic |
| 07:24 | <Hixie> | "oops" |
| 07:27 | maikmerten | gives moral support to doublec's question |
| 07:27 | <MikeSmith> | Hixie - you get points for consistency at least |
| 07:28 | <maikmerten> | I was under the impression that if <video> fails it should display the fallback content to be fed into non-<video> browsers |
| 07:29 | <doublec> | does having no media resource count as fail though? |
| 07:29 | <doublec> | as they might add <source> dynamically later |
| 07:29 | <Hixie> | with no <source>, or no suitable media, you display a black rectangle |
| 07:29 | <Hixie> | according to the spec |
| 07:30 | <Hixie> | in a <video>-supporting UA, you never see the fallback |
| 07:30 | <Hixie> | again, according to the spec |
| 07:30 | <doublec> | good point |
| 07:30 | <Hixie> | (sorry, didn't see your question earlier) |
| 07:30 | <Hixie> | to answer your question, the UA is always allowed to be helpful |
| 07:31 | <Hixie> | it could, e.g., overlay a message on the <video>'s black screen saying "No media available..." |
| 07:31 | <Hixie> | there's no restriction on what the UI is or can do really |
| 07:31 | <Hixie> | and when JS is disabled, controls="" is implied, so the UI should be in full swing |
| 07:32 | <Hixie> | doublec: hth |
| 07:32 | <Hixie> | gonna go home now, will probably be online again in a bit |
| 07:32 | <doublec> | cool, thanks |
| 07:33 | <doublec> | where this came up is for user agents that don't support Ogg. Can a page detect that no meda resource was available and report a message themselves. |
| 08:11 | <Hixie> | doublec: yeah, there's an event |
| 08:11 | <Hixie> | iirc |
| 08:17 | <doublec> | ahh, the abort event, thanks |
| 12:07 | <Hixie> | http://www.w3.org/mid/bgdfl31rqfj95uhpkkjkmg0kc1bbg6612v⊙hbhd <- hahahaha, awesome, microsoft caught at it again |
| 12:07 | <Hixie> | hopefully that puts the final nail into the EOT coffin |
| 12:20 | <om_sleep> | harsh |
| 12:21 | <othermaciej> | now wait a second |
| 12:21 | <othermaciej> | if that's true, I don't understand why Microsoft was pushing EOT so hard |
| 12:21 | <othermaciej> | I assumed it was because they're a font vendor |
| 12:24 | <hsivonen> | othermaciej: perhaps the MS Core Fonts initiative has lead to some internal discussions |
| 12:25 | <hsivonen> | othermaciej: Paul Nelson's www-style future tense statement of what MS won't do is something they have done in the past |
| 12:25 | <othermaciej> | hsivonen: I don't understand how that would explain the seeming inconsistency in the message Hixie linked |
| 12:25 | <othermaciej> | (inconsistency demonstrated by the message, that is) |
| 12:25 | <hsivonen> | it doesn't |
| 12:26 | <hsivonen> | too bad that message is Member-only |
| 12:26 | <othermaciej> | you have Member access, right? |
| 12:26 | <hsivonen> | otherwise, it would be a good "recent successes" addition to the Björn Höhrmann Project :-) |
| 12:26 | <hsivonen> | othermaciej: I do |
| 12:27 | <othermaciej> | I'd guess Bjoern wouldn't mind posting it somewhere public too |
| 12:28 | <othermaciej> | hsivonen: what www-style statement are you referring to by the way? |
| 12:29 | <hsivonen> | othermaciej: http://www.w3.org/mid/49C257E2C13F584790B2E302E021B6F914F6B1D2⊙wswcmc |
| 12:30 | <hsivonen> | later amended, though: http://www.w3.org/mid/49C257E2C13F584790B2E302E021B6F914F6B1DD⊙wswcmc |
| 12:32 | <hsivonen> | the network effects, the development cost and the ways of making money on fonts do make fonts a hard problem for the Web and for any non-final form documents |
| 12:36 | <hsivonen> | I don't really know how to make fonts so that font designers get paid but users aren't bound by onerous licensing terms except developing free fonts under a patronage model |
| 12:36 | <hsivonen> | But that yields a practically necessary number of fonts |
| 12:37 | <hsivonen> | and the embedding issue is pretty much about high-quality fonts that go beyond what would be merely necessary for textual communication to work |
| 12:40 | <othermaciej> | whatever the complexities of the font business model, it seems clear that using a Microsoft-specific format with trivial DRM doesn't solve any of the problems and creates extra annoyance for web developers and browser developers, and even Microsoft seems to acknowledge that for technologies that they'd like to see succeed |
| 12:40 | <hsivonen> | I agree |
| 12:52 | <hsivonen> | clearly, making the font restriction too tight will drive a foundry out of business |
| 12:53 | <hsivonen> | a few years ago, I found a small private foundry that had great designs but wouldn't license them for embedding in PDF |
| 12:53 | <hsivonen> | it seems to me the foundry is out of business |
| 12:53 | <hsivonen> | the irony was, of course, that in order to communicate samples of their fonts, they had to embed them in PDFs |
| 12:54 | <othermaciej> | heh |
| 12:54 | <othermaciej> | fortunately they can't violate their own license, legally |
| 12:54 | <othermaciej> | but still amusing |
| 16:56 | <rubys> | is input/@size legal in html5? |
| 16:57 | <gsnedders> | rubys: no |
| 16:58 | <rubys> | what's the alternative? |
| 16:59 | <gsnedders> | CSS is just meant to be used instead |
| 17:44 | <csarven> | gsnedders how do non-presentational UAs allocate space for the input size? |
| 17:45 | <gsnedders> | csarven: non-presentational or non-CSS-supporting? non-presentational ones don't present anything :P |
| 17:46 | <csarven> | i was referring non-CSS-supporting UAs. e.g. Lynx |
| 17:47 | <gsnedders> | in some they always use the same width, others use @size |
| 17:48 | <csarven> | and if CSS is turned off CSS-supporting UAs? is it expected to default to browser stylesheet? |
| 17:49 | <gsnedders> | AFAIK they all use @size falling back to a default |
| 17:49 | <Dashiva> | I don't recall anyone switching width based on the font, though |
| 18:11 | mpt | has a vague memory of the meaning of size= being dependent on the width of an "e" in the relevant font |
| 18:14 | gavin | has a vague memory of a recent mozilla bug about mpt's vague memory |
| 18:23 | Philip` | has a memory of it being different in every browser |
| 18:42 | <rubys> | hsivonen: ping? |
| 18:54 | <annevk> | I think <input size> is probably something that should be allowed |
| 19:05 | <mpt> | <input size= has weak semantics in that it suggests approximately how long the entered data should be |
| 19:06 | <mpt> | (people will write less in a narrow field than a wide one) |
| 19:15 | <rubys> | any idea on how I can "recover" a nick? nickserv doesn't seem to like the password I thought I used, and /info seems to indicate that this nick was registered by me over four years ago, and even used by me just over a week ago. |
| 19:19 | <gavin> | rubys: I'd just /msg someone in /stats p |
| 19:19 | <gavin> | this server's nickserv doesn't appear to have a "reset password and email it to me" option |
| 19:19 | <Dashiva> | Doesn't even ask for email on registration, it seems |
| 19:21 | <annevk> | gavin, I believe /msg does not work when you're not registered |
| 19:21 | <gavin> | for everyone? hrm |
| 19:21 | <annevk> | hsivonen, http://forums.whatwg.org/viewtopic.php?t=123 reports a bug in validator.nu (<form target> is marked non-conforming, but it is conforming) |
| 19:21 | <gavin> | I do seem to recall something like that |
| 19:21 | <gavin> | on other servers it's usually a off-by-default per-user switch |
| 20:07 | <annevk> | rubys, search forms should indeed be easier |
| 20:08 | <annevk> | that is, <form> <input type=text> <input type=submit> </form> should just be conforming |
| 20:10 | <rubys> | i think the problem is more general than that, the notion of "strictly inline content" probably should go away. |
| 20:11 | <annevk> | that might have been agreed on already |
| 20:11 | <annevk> | not sure if that solves the <form> thingie |
| 20:11 | <annevk> | btw, there's now http://html5.fr/ besides http://html5.jp/ |
| 20:12 | <annevk> | (html5.fr made a validator button for validator.nu :) ) |
| 20:15 | <Philip`> | Perhaps HTML5 could say that including a validator button on your web page is non-conforming |
| 20:15 | <Dashiva> | I made one too |
| 20:16 | <Dashiva> | Well, I stole one. But much the same :) |
| 20:16 | <Philip`> | It must be good for the validators' page-rank |
| 20:17 | <Dashiva> | http://dashiva.net/banner/valid-html5.png |
| 20:17 | <Dashiva> | I don't recall who made it |
| 20:24 | <annevk> | Simon I think |
| 20:24 | <rubys> | the downside of things that benefit the validator's page rank is that every crawler known to man will then proceed to pound your server to sawdust. |
| 21:37 | <annevk> | does anyone know how the document.all hiding works in Mozilla? |
| 21:38 | <gavin> | a bit |
| 21:39 | <annevk> | http://developer.mozilla.org/en/docs/DOM:document.all does not exist |
| 21:40 | <gavin> | do you have specific questions, or are you just looking for a comprehensive spec? :) |
| 21:41 | <annevk> | I wonder if document.all returns some quirky object that "booleanizes" to "false" |
| 21:41 | <annevk> | or if it's some other trickery |
| 21:42 | <Hixie> | hsivonen: yeah, they never did reply to http://lists.w3.org/Archives/Public/www-style/2007Nov/0274.html |
| 21:42 | <annevk> | and whether "booleanizes" is an actual JS concept or specifically added |
| 21:42 | <gavin> | other trickery |
| 21:42 | Hixie | sends a proposal to solve the inline/block problem |
| 21:42 | <Hixie> | but it basically requires us to stop allowing <ol> and co in paragraphs |
| 21:42 | <gavin> | I believe it hooks gets of document.all and returns "undefined" if it's in a "detecting" context |
| 21:44 | <annevk> | interesting |
| 21:44 | <gavin> | hmm |
| 21:44 | <gavin> | http://lxr.mozilla.org/seamonkey/source/dom/src/base/nsDOMClassInfo.cpp#7889 |
| 21:45 | <annevk> | Hixie, you could make <ol> and <ul> imply <p> around them too |
| 21:46 | <gavin> | as I read that, it makes document.all exist if you try to get .length, .item(), or something that matches an id from it, but not exist otherwise |
| 21:46 | <annevk> | that file seems to beat HTML 5 in bytes |
| 21:47 | <gavin> | yeah, it's got a lot of icky DOM magic built into it :) |
| 21:48 | <Hixie> | annevk: but then you could never use <p> in <li> |
| 21:48 | <Hixie> | or <hx> in <li> |
| 21:48 | <Hixie> | etc |
| 21:49 | <annevk> | sorry, what I meant was that <aside> TEXT <ol> is like <aside> <p> TEST </p> <ol> |
| 21:49 | <Hixie> | right, that means not allowing <ol> in <p> |
| 21:50 | <annevk> | yes, but you marked that example as non-conforming |
| 21:50 | <annevk> | <aside> TEXT <ul> <li> <p> TEXT |
| 21:50 | <annevk> | to be more specific |
| 21:51 | <annevk> | oh, or that because of the <em> on the line before? |
| 21:51 | <Hixie> | an <ol> is either inline or block |
| 21:51 | <Hixie> | if it's inline, it can't contain blocks |
| 21:51 | <Hixie> | if it's inside a paragraph, it's inline |
| 21:52 | <Hixie> | if we allow <ol> inside paragraphs, then <aside> text <ol>... looks the same as <aside> <p> text <ol>... |
| 21:52 | <Hixie> | (assuming we do implied <p>s) |
| 21:53 | <Hixie> | (i think doing implied <p>s around only elements that can't be blocks would be even more confusing) |
| 21:53 | <annevk> | <aside> the way people use IMHO doesn't seem humble at all most of the time |
| 21:53 | <Hixie> | heh |
| 21:54 | <gavin> | that's completely wrong and you're stupid, IMHO |
| 21:54 | <annevk> | <aside> TEXT <ul> <li> TEXT <p> TEXT |
| 21:54 | <annevk> | why is the <p> non-conforming with implied paragraphs |
| 21:54 | <annevk> | ? |
| 21:56 | <Hixie> | if we assume that <ul> can be inline, and if we assume that implied paragraphs wrap all potentially inline elements in a run, then the <ul> in that example is inline and inside a paragraph. Elements that are inline can't contain blocks. |
| 21:58 | <annevk> | ok, my proposal (on top of implied paragraphs) was to make <ul>, etc. block elements |
| 21:58 | <Hixie> | that's what i said. remove the ability for <ol> to be inside <p>. |
