| 01:10 | <Lachy> | Very interesting comment from Joe Clark http://blog.whatwg.org/the-longdesc-lottery#comment-9051 |
| 01:23 | <jruderman> | Lachy: internal server error |
| 01:24 | <Lachy> | I know |
| 01:24 | <Lachy> | I don't know why the wiki broke |
| 01:24 | <Lachy> | oh, now the blog too! |
| 01:24 | <Lachy> | Hixie, yt? |
| 01:38 | <Lachy> | error message from the blog: "Fatal error: Out of memory (allocated 4718592) (tried to allocate 19456 bytes) in /home/.hardangervidda/lhunt/blog.whatwg.org/wp-includes/widgets.php on line 610" |
| 02:12 | <Lachy> | krijnh, there's a bug in your URL detection code for the logs, '>' should not be included as part of a link. http://krijnhoetmer.nl/irc-logs/whatwg/20070911#l-368 |
| 05:36 | <Lachy> | the wiki and blog seem to be having intermittent problems. One minute it works, the next it doesn't. |
| 05:36 | <Lachy> | I suppose I should make a backup of the DB ASAP in case something serious should happens to it |
| 06:08 | <Lachy> | it is impossible to make a back up when the server keeps dying every 2 minutes :-( |
| 10:44 | <comster404> | you should check out http://fluidsurfandsport.com surf shop and http://jeffpelton.com |
| 13:39 | <Dahu> | Hi, I read this last sentence in the FAQ : "It is important to make the distinction between the rules that apply to user agents and the rules that apply to authors for produce conforming documents. They are completely orthogonal." Knowing that the majority of authors develop by copying examples on the web, and testing in their favorite browsers, how to make them aware of that distinction ? |
| 13:44 | <Dashiva> | Badges |
| 13:44 | <Philip`> | I expect the main ways would be conformance checkers and tutorials/guides/books and discussions (on forums etc) with people who understand the rules |
| 13:48 | <Philip`> | (By the way, I think it could be good to have a "Developed with help from the HTML5 conformance checker" badge, since it can be very widespread and effective advertising for that service) |
| 13:48 | <Dahu> | Well, forums/tutorials/books have existed from the beginning. And it has nonetheless led to the poor web we can now experience... And about conformance checkers, wouldn't their implementations differs, as browsers do ? Will there be an official checkers ? |
| 13:49 | <webben> | Dahu: The books and tutorials have not been very good ones. |
| 13:49 | <webben> | Dahu: One of the interesting goals in the HTML WG is to produce semi-official tutorials |
| 13:49 | <webben> | (the current official ones aren't too hot either) |
| 13:50 | <Dashiva> | The current official spec isn't so hot either ;) |
| 13:50 | <Philip`> | Dahu: Conformance checkers should agree on most aspects, since the specification defines what is conforming and the checkers just have to implement that |
| 13:51 | <Philip`> | though there are some requirements which are impossible to check, and implementations will tend to have bugs and missing features, so there would be some differences |
| 13:52 | <Dashiva> | And the differences would lead to those bugs being discovered (in theory) |
| 13:53 | <Philip`> | Given how people have adopted XHTML in the past few years, it looks like a significant number do actually follow expert advice to some extent, so it's not totally hopeless :-) |
| 13:54 | <karlUshi> | for what is worth, there will be news very soon about HTML 5 for Authors |
| 13:55 | <webben> | what exactly is HTML 5 for Authors? a document? a book? a project? |
| 13:56 | <karlUshi> | a document |
| 13:56 | <webben> | ok |
| 13:58 | <Lachy> | karlUshi, are you referring to this? http://canvex.lazyilluminati.com/misc/ref/ref.html |
| 14:00 | webben | wonders what the order of elements is based on there. Frequency? |
| 14:00 | <Philip`> | I think he's referring to some secretive cabal, about which I know nothing except that it exists :-p |
| 14:00 | <karlUshi> | Lachy: no |
| 14:00 | <Philip`> | webben: It's the same order as the HTML5 spec |
| 14:00 | <webben> | oh |
| 14:01 | <webben> | Philip`: So are you just stripping out the UA parsing information? |
| 14:01 | <karlUshi> | which is a good starting point but doesn't help that much in the context of authors. It makes a good detailed index though. |
| 14:02 | <Dahu> | Ok. I work with developers who have no IT diploma. When they need to do a tricky stuff, they search on google, usually find a popular horrible browser specific hack, and are just happy with it. So HTML5 is just a bet that it will change ? |
| 14:02 | <webben> | Having no IT diploma isn't some sort of bar to reading the HTML spec. |
| 14:03 | karlUshi | is off to a F2F |
| 14:03 | <webben> | Dahu: The solution to that is to work on the search engine visibility and end-user attractiveness of the tutorials. |
| 14:03 | <webben> | And make sure they offer solutions for common problems. |
| 14:03 | <Philip`> | webben: It's more like writing a whole new document, by going through the spec and copying the points that apply to authors (and rearranging some related points so they're described in the same place) |
| 14:04 | <Dahu> | i know, but it's not in their culture to read a spec. They prefer practical solutions and examples. |
| 14:04 | <Philip`> | (Almost all of the text is new, and just a couple of examples were copied from the original spec) |
| 14:04 | <webben> | Dahu: That's a different set of people than they people who "have no IT diploma". |
| 14:05 | <webben> | (some people are doubtless members of both sets) |
| 14:05 | <webben> | Philip`: If you're not reordering the elements alphabetically, perhaps it would help to group them a bit? |
| 14:05 | <webben> | (i.e. with headings? |
| 14:06 | <Philip`> | webben: Like the grouping that the HTML5 spec uses when describing elements? |
| 14:06 | <webben> | yeah maybe |
| 14:07 | <Philip`> | I agree something like that would be good |
| 14:08 | <Philip`> | (though I don't know what'd be the best way to write it) |
| 14:10 | <Philip`> | (It should be easy enough to rearrange things, since the element definitions are mostly independent of each other) |
| 14:11 | <webben> | Philip`: If you want to make things really fancy, have you seen the user-customisable draft WCAG 2 quickref |
| 14:12 | <webben> | http://www.w3.org/WAI/WCAG20/quickref/ |
| 14:13 | <hsivonen> | hmm. Google Translator translates the contents of <code> |
| 14:13 | <hsivonen> | so much for semantics |
| 14:13 | <Philip`> | webben: No, but I have now |
| 14:13 | <hsivonen> | <code>old</code> |
| 14:13 | <hsivonen> | (German to English) |
| 14:13 | <webben> | hsivonen: So much for Google Translator. |
| 14:14 | <webben> | Last time I used it, it translated the German for "elderly cats" into "elderly tigers". |
| 14:14 | <Philip`> | webben: Looks kind of like that's designed for printing |
| 14:14 | <webben> | Philip`: I don't /think/ so. |
| 14:15 | <webben> | It's a lot less useful if you can't follow the links. |
| 14:15 | <Philip`> | I'm not sure why you'd want to remove e.g. the Introduction section if you were just reading it on the screen, since it's trivial to scroll past |
| 14:15 | <webben> | I think it's more meant to provide a usable way of getting to content inside the WCAG2 labyrinth. |
| 14:15 | <webben> | Philip`: I think it remembers your settings. |
| 14:16 | <webben> | yeah, last option: Keep these settings when I leave the page. |
| 14:16 | <webben> | Just a thought, it may not help as much with HTML. |
| 14:16 | <Philip`> | Ah, okay |
| 14:17 | <Philip`> | Maybe it could be useful for showing/hiding things like the "Further details: ..." sections |
| 14:23 | <Dahu> | I think the main problem is that developers just test their page on the browser at that's it. If it works, they don't bother if it conforms to the specs. Checking if it conforms to the spec is a waste of time. What can we do against that kind of developping behaviour ? |
| 14:30 | <Philip`> | One of the problems in that case can be solved by making all browsers act the same, so something that's tested in one browser will work in the others (even if it's nasty ugly non-conforming code) |
| 14:31 | <Philip`> | (I can't think of any realistic ways to solve the problem of people writing nasty ugly non-conforming code, though) |
| 14:31 | <hsivonen> | Dahu: the thing to do is the make the notion of conformance useful in such a way that if your document is conforming, you could expect fewer counter-intuitive surprises |
| 14:32 | <hsivonen> | Dahu: in particular, even if browsers are consistent, if they are consistently counter-intuitive, it is still worth flagging |
| 14:32 | <hsivonen> | Dahu: example: forbidden stuff in tables |
| 14:34 | <Dahu> | hsivonen: ok. interesting. Philip: it's forgetting about browsers wars. The most popular always want to add exclusive features (see MNG APNG for exemple), in order to assure its position. |
| 14:36 | <Philip`> | APNG is in the alpha builds of Opera 9.5 as well as of Firefox 3, so it's not really exclusive |
| 16:29 | <hsivonen> | http://plasmasturm.org/log/469/ |
| 16:44 | <MikeSmith> | hsivonen - the whole comment that he's quoting is worth reading as well |
| 16:44 | <MikeSmith> | http://www.tbray.org/ongoing/When/200x/2007/09/14/Lousy-Aggregators#c1189816400.193978 |
| 16:44 | <MikeSmith> | "it might be time to acknowledge that the problem is the spec instead of the implementors" |
| 16:47 | <hsivonen> | MikeSmith: yeah. |
| 16:48 | <hsivonen> | MikeSmith: which is the reason why it might make sense to resist the kind of text/html extensibility that'd bring XML-style namespacing to HTML |
| 16:58 | <MikeSmith> | hsivonen - I think more people would see value in adding a general extensibility mechanism if it there were any problem cases other than dealing with SVG for which it would address any real market/user demand |
| 16:59 | <MikeSmith> | extensibility mechanisms that didn't solve any specific existing or forseeable problems were what the SGML guys specialized in |
| 16:59 | <MikeSmith> | and we can see how far it got them |
| 17:04 | <hsivonen> | MikeSmith: I agree. Though I do see a little bit of market demand for MathML integration as well (to the extent there's MathML demand in the first place). |
| 17:04 | <MikeSmith> | but perhaps the HTML case is different in that we know it's going to be around for good while longer, so building extensibility mechanisms for future possible down-the-road problems may not be as much of a waste of time as it turned out to be for SGML (now that SGML is dead and most people think it's good riddance) |
| 17:05 | <hsivonen> | the main problem with Namespaces in XML is that the cure (namespaces) seems to cause more grief than the problem (name collisions in cases where people *actually* merge two vocabularies) |
| 17:06 | <MikeSmith> | yeah, exactly |
| 17:06 | <MikeSmith> | cure is worse than the disease |
| 17:07 | <hsivonen> | (the "problem" of giving a global identity to elements seems less real than the collision issue in the case of an actual merge) |
| 17:14 | <MikeSmith> | design principle: Don't try to get too far ahead of the implementor requirements and user requirements... |
| 17:17 | <MikeSmith> | don't add additional pain/hassles for all users by introducing mechanisms for solving problems that most users don't encounter and aren't asking you to provide a solution for |
| 19:46 | <zcorpan> | lol... http://annevankesteren.nl/ |
| 19:48 | <Philip`> | Sadly browsers don't sniff that it's meant to be text/plain :-( |
| 19:48 | <zcorpan> | hah |
| 19:52 | <hsivonen> | :-) |
| 19:53 | <hsivonen> | Shouldn't that be 503? :-) |
| 19:54 | <zcorpan> | he wants to loose page rank :) |
| 19:54 | <hsivonen> | 503: Google Please Don't Break My Rank While My Hosting Sucks :-) |
| 20:06 | <Philip`> | Hmm, I need to write about forty test cases for shadow rendering, because otherwise Opera will still be winning in terms of canvas test passes |
| 20:29 | <zcorpan> | Philip`: that would be really bad :) |
| 20:47 | <Philip`> | Oh, that's not fair - Opera is passing about a third of the cases, despite not implementing the feature at all |
| 20:49 | <zcorpan> | perhaps you need a baseline test such that if that doesn't pass, the rest are invalid |
| 20:54 | <Philip`> | Since shadows (and gradients) are meant to be optional, I suppose browsers should be able to get a perfect score without implementing them at all, so it would be useful to determine whether the browser is attempting support for the feature before counting all the tests that rely on that feature |
| 20:54 | <Philip`> | but that sounds like slightly more effort, and it wouldn't be as good at encouraging people to implement the optional features |
| 20:55 | <Philip`> | (I don't understand why they're optional, though - it would be easier if everything was just required...) |
| 21:22 | <zcorpan> | hmm, expanding the allowed characters for unquoted attributes might make conformance checking not catch some mistakes, e.g. alt=="foo bar" |
| 21:23 | <zcorpan> | though i guess they could emit a warning |
| 21:25 | <Philip`> | They could emit a warning for all unquoted attributes, because unquoted attributes look kind of ugly and people don't use them much anyway |
| 21:26 | <zcorpan> | naw |
| 21:26 | <zcorpan> | i use them :) |
| 21:27 | <Philip`> | I occasionally try using them, but then I rediscover that they look ugly so I add the quotes again :-p |
| 21:27 | <zcorpan> | warning about things that aren't mistakes nor conformance violations just makes the checking less useful |
| 21:27 | <hsivonen> | zcorpan: have you already tested alt=="foo bar" in browsers? |
| 21:28 | <zcorpan> | hsivonen: yes, they don't do anything stupid |
| 21:28 | <zcorpan> | same as alt='="foo bar"' |
| 21:29 | <zcorpan> | er |
| 21:29 | <zcorpan> | same as alt='=foo' bar"='' |
| 21:30 | <zcorpan> | alt='="foo' bar"='' even |
| 21:30 | <hsivonen> | I think we should make that non-conforming in order to alert authors |
| 21:30 | <hsivonen> | that is, non-conforming for docs |
| 21:31 | <hsivonen> | zcorpan: are you going to send email or should I? |
| 21:31 | <zcorpan> | hsivonen: you can do it if you want :) |
| 21:31 | <hsivonen> | zcorpan: ok |
| 21:34 | <zcorpan> | hsivonen: btw, perhaps the input's title in http://html5.validator.nu/ should drop the last sentence since there are no options to save :) |
| 21:35 | <Philip`> | http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0D%0A%3Ca%20b%3D%60c%20d%60%3E - IE thinks that's a single attribute |
| 21:37 | <hsivonen> | zcorpan: good point. thanks |
| 21:49 | <hsivonen> | zcorpan: email sent |
| 21:50 | <zcorpan> | hsivonen: thanks |
| 22:11 | <zcorpan> | "HTML is extremely high profile, and everybody knows enough about it to have an opinion. HTML5 is the world's biggest bikeshed." -- http://www.jaim.at/2007/09/14/brendan-taylor-the-flamewars-are-fun-to-read-though/ |
| 22:16 | <gsnedders> | green. _please_. |
| 22:31 | <Philip`> | I think the bikeshed should be coloured "bogus", since that's a nice shade of red |
| 22:35 | <Dashiva> | Haha, I remember that |
| 22:35 | <Philip`> | (I don't think the HTML5/bikeshed analogy is particularly strong - bikesheds are simple so anyone can know enough to have an opinion; HTML is complex so almost nobody knows enough except about tiny parts of it, and people have opinions about lots of tiny parts of it instead of about the whole) |
| 22:36 | <Dashiva> | But it seems simple enough that people think they can |
| 22:37 | <hsivonen> | Dashiva: I think the key to the HTML issue is that it isn't obvious to everyone that it is the power plant--not the bikeshed |
| 22:37 | <Philip`> | (so maybe HTML5 is more like a city which has lots of bikesheds and atomic power plants in it, and almost all the discussion focuses on several of the bikesheds) |
| 22:37 | <Dashiva> | That might be closer |
| 22:38 | <Philip`> | (Not that I know of many cities which have "lots of ... atomic power plants" in them) |
| 22:38 | <Dashiva> | sim cities |
| 22:59 | <Philip`> | Current status: Firefox 3 + shadow patch: 44/44 passed. Safari 3: 35/44. Opera 9.5: 12/44. |
| 23:00 | <Philip`> | (The failures in Safari are (in my opinion) definitely bugs, rather than just being differences with the (proposed) specification) |