| 00:00 | <Hixie> | dashiva: though ironically, and possible presciently, it gets parsed as <html><accessibility>...</accessibility></html> :-) |
| 00:01 | <Dashiva> | I did have fun at one time with <invisible> |
| 00:01 | <Lachy> | Dashiva, you forgot the level="AAA" attribugte |
| 00:01 | <Lachy> | *attribute |
| 00:01 | <Lachy> | maybe this http://en.wikipedia.org/wiki/Image:HTML.svg |
| 00:01 | <Lachy> | if I edit it to use an HTML5 DOCTYPE |
| 00:02 | <Dashiva> | You put <invisible>The content of this page is hidden to protect the author's rights.</invisible> followed by 100 newlines at the top of the document |
| 00:02 | <Hixie> | heh |
| 00:03 | <Philip`> | http://www.newtacoma.com/ has some <hidden input="...">, which is peculiar |
| 00:03 | <Philip`> | Looks like a failed SEO attempt |
| 00:07 | <Hixie> | i still haven't finished dealing with e-mail |
| 00:07 | <Hixie> | sheesh |
| 00:07 | <Hixie> | today is an especially bad day for e-mail |
| 00:09 | <Dashiva> | There was one mail where someone claimed to read all the public-html mail, and also claimed there had never been a mail from you about @alt alternatives |
| 00:09 | <Hixie> | i saw that |
| 00:09 | <Hixie> | that was funny |
| 00:09 | <Dashiva> | I wonder if anyone's going to call him out on that |
| 00:09 | takkaria | notes hixie now has a zzz folder as well as an aaa-productivity folder :) |
| 00:10 | <takkaria> | I was going to, but I couldn't find the post that wasn't made |
| 00:11 | <Hixie> | i've had zzz for a while, though until recently it only had notes from myself to myself in there (which don't appear on the issues list) |
| 00:11 | <Hixie> | zzz is for things that i don't want to deal with until after we're in CR |
| 00:11 | <Hixie> | or at least near going to CR |
| 00:11 | <Dashiva> | takkaria: This one? http://lists.w3.org/Archives/Public/public-html/2008May/0073.html |
| 00:11 | Philip` | never noticed that part of the email, since he gave up reading it long before that point |
| 00:12 | <takkaria> | Dashiva: yeah, that one |
| 00:14 | <Philip`> | Since nobody raised any decent objections to that proposal, it is clearly perfect and should be implemented |
| 00:15 | <webben> | objections were raised in this channel (mainly along the lines of what attribute to use) |
| 00:15 | <webben> | IIRC |
| 00:16 | <annevk> | oh crap, it's 1:20 |
| 00:16 | <Philip`> | webben: Ah, I'm not counting minor syntax details, because if I did count them then my statement would be proved false |
| 00:16 | annevk | blames HTML5 |
| 00:16 | <webben> | using some other attribute to square the circle does seem to meet most of the raised concerns |
| 00:16 | <Dashiva> | At some point, we'll have to get a shed just tok keep all our bikesheds in |
| 00:16 | <Hixie> | HTML5 takes the blame for time advancing |
| 00:16 | <Hixie> | anything of the size of HTML5 is bound to have effects on the time space continuum |
| 00:17 | <webben> | Well, it does include a TIME element, doesn't it? ;) |
| 00:17 | <annevk> | in this case it was more having to deal with comments from shepers because of fear of the html5 dependency |
| 00:17 | <annevk> | and how it would badly affect vendors |
| 00:17 | <Hixie> | you'd think he'd let the vendors raise their own concerns |
| 00:17 | <annevk> | apparently he doesn't trust me when i say that vendors have requested that so i actually had to dig up an e-mail from maciej |
| 00:18 | <Dashiva> | The vendors need to start using that backroom channel nobody gets to see :) |
| 00:18 | <annevk> | would be nice if he read the thread about it first before starting a new one on the same subject |
| 00:19 | <Philip`> | Dashiva: We'd have to teach them the secret handshake first |
| 00:19 | <annevk> | Dashiva, moving everything to a less bureaucratic forum would be fine with me, but WHATWG doesn't have a PP yet |
| 00:20 | <takkaria> | Philip`: hmm, somehow lolzapolooza doesn't work when typed... |
| 00:20 | <Hixie> | yeah we really need a patent policy |
| 00:20 | <takkaria> | uh, that backfired |
| 00:20 | <Hixie> | annevk: get your lawyer people to write down what they would want a patent policy to cover, and mail it to me |
| 00:20 | <annevk> | PP involves lawyers, that's scary |
| 00:21 | <Hixie> | opera's lawyers aren't too bad |
| 00:22 | <Dashiva> | It was a bit disconcerting to get an office in the middle of legal. Suddenly there are suits all around you |
| 00:22 | <Dashiva> | Go one floor up, and it's shorts and t-shirts |
| 00:24 | <Philip`> | Several people where I work don't even wear socks or shoes, which doesn't seem a great idea to me given the stuff I know I've dropped on the floor |
| 00:25 | <annevk> | maybe you should tell them :) |
| 00:28 | <annevk> | (that was in reply to Philip`, not Hixie, fwiw) |
| 00:29 | annevk | tries to be extra careful now he mentioned lawyers |
| 00:31 | <roc> | dbaron: did you make any progress on the spurious menu command firing bug? |
| 00:32 | <dbaron> | roc, no... but did you mean to ask that in #developers ? |
| 00:32 | <roc> | yes I did! |
| 00:33 | <MikeSmith> | lastlog mike |
| 00:33 | <MikeSmith> | oops |
| 00:33 | <MikeSmith> | heh |
| 00:34 | <MikeSmith> | "<Lachy> though I still have to fit the drunk MikeSmith photo in somewhere too" |
| 00:34 | <Dashiva> | Checking if we talk behind your back? :) |
| 00:35 | <annevk> | hehe, we could use that as a gimmick |
| 00:35 | <annevk> | "works on your mobile: <picture>" |
| 00:35 | <MikeSmith> | Dashiva: making my IRC client show me if anybody was trying to ping me while I was asleep.. |
| 00:41 | <Hixie> | annevk: btw, i could live with the hardcoded client-side limitation on the path component containing "..\" |
| 00:42 | <takkaria> | I accidentally send \0s to IRC far too often, I wonder if I can make my client stop me |
| 00:43 | <Hixie> | how?? |
| 00:43 | <takkaria> | I'm not sure, I think I manage it by hitting the wrong button when switching tabs in irssi |
| 00:44 | <annevk> | yeah, it seemed sort of reasonable to me too, although it's amazingly ugly and i wonder if it'll ever fly |
| 00:44 | <Hixie> | why wouldn't it fly? |
| 00:44 | <Hixie> | html5 has far worth things |
| 00:44 | <Hixie> | worse |
| 00:44 | <annevk> | it may also be a slippery slope, not sure |
| 00:44 | <Hixie> | well if you find yourself going down the slope, just say no and remove it |
| 00:45 | <annevk> | i'd like to hear from the webkit guys if they feel this is needed |
| 00:45 | <othermaciej_> | if we feel what is needed? |
| 00:46 | <othermaciej_> | the crazy IIS workaround? |
| 00:46 | <othermaciej_> | I haven't studied it enough to know |
| 00:46 | <Hixie> | yeah |
| 00:46 | <Hixie> | not much to study really |
| 00:46 | <Dashiva> | When Doug says "commercial browser vendors", who does he mean? |
| 00:46 | <Lachy> | gsnedders, first draft of your slide http://lachy.id.au/temp/gsnedders.jpg :-) |
| 00:46 | <annevk> | (another option would be to simply disable the whole feature for IIS based on the Server response header from the OPTIONS request) |
| 00:47 | <annevk> | (but that seems worse) |
| 00:47 | <shepazu> | Dashiva: like, mobile vendors... Opera, for one :) |
| 00:47 | <othermaciej> | Dashiva: probably vendors of per-unit licensed mobile browsers |
| 00:47 | <othermaciej> | though I don't think Opera specifically objects to referencing HTML5 |
| 00:48 | <Dashiva> | Yeah, I didn't see Opera objecting to that... |
| 00:48 | <othermaciej> | also I am not sure why charging a license fee is related to needing to market something, or how that relates to specification cross-references |
| 00:48 | <annevk> | I put it in the spec... |
| 00:48 | <annevk> | so far, no viable alternative has been propposed, so this is a non-issue |
| 00:52 | <annevk> | I'm also a bit confused with shepazu asking me to provide a reference for where implementors have requested that, and he, spokesman of the commercial browser vendors, has not done the same... |
| 00:52 | annevk | -> bed |
| 00:53 | <shepazu> | annevk: it's a simple question |
| 00:54 | <shepazu> | where do your requirements come from? |
| 00:54 | <annevk> | public-webapi |
| 00:54 | <Philip`> | Hmm, Google Code does autolinking between issues and commit messages, but it doesn't seem to do clever stuff like in Trac where you can close an issue via a commit message :-( |
| 00:54 | <Philip`> | (*autolinking of references of the form "issue 123" and "r123") |
| 00:55 | <annevk> | shepazu, I hope you followed the pointers I provided and snipped in your reply |
| 00:56 | <shepazu> | annevk: of course, but it's not much of a "requirement", and doesn't refute removal from HTML5 |
| 00:58 | <Dashiva> | I'm a bit surprised that there are commercial browser vendors who don't plan on implementing HTML5 |
| 00:59 | <annevk> | shepazu, nothing does, it's just that nobody has done that yet |
| 00:59 | <annevk> | shepazu, and because nobody has done that yet, there's no incentive to change references |
| 00:59 | <annevk> | shepazu, as the current references serve implementors best |
| 01:05 | Philip` | discovers the 'pv' tool, which is quite neat |
| 01:05 | <Philip`> | since I can use it to e.g. feed a big HTML file to html5lib, and get a progress bar and estimated-time-to-completion and everything |
| 01:09 | <Dashiva> | If Hixie added alt="_none" as the missing value to the spec today, what would the responses be? Discuss |
| 01:10 | <Philip`> | I'd complain that it doesn't degrade gracefully |
| 01:10 | <shepazu> | alt="_blank" |
| 01:10 | <Dashiva> | Would you? Would you really revive the whole debacle when it might be over? |
| 01:10 | <Philip`> | Nobody would want their page littered with "_none" tooltips |
| 01:10 | <Philip`> | Dashiva: Yes, since I'd like to have the best possible solution :-) |
| 01:11 | <annevk> | Dashiva, the whole point of the debacle is that people have different views; if one party just gives in to the other of course it would be over... |
| 01:11 | <annevk> | anyway, should really go to bed now |
| 01:12 | <Dashiva> | It's a dual-sided question, I suppose. Who would think it was a good solution, and who would realize it's a bad solution yet remain silent. |
| 01:13 | <Philip`> | Only crazy people would think it's a good solution ;-) |
| 01:14 | <Dashiva> | Yet people are suggesting it on this very day :) |
| 01:14 | <Philip`> | I never suggested that people are not crazy |
| 01:15 | <Dashiva> | But if you believe there are crazy people on the list, should you not feel obliged to attempt to rectify this? |
| 01:15 | <Philip`> | I don't feel any need to argue against people who are suggesting crazy things, only against the crazy things that are currently in the spec |
| 01:16 | <Philip`> | (unless it seems likely that the crazy suggestions are going to be put into the spec, in which case it'd be good to pre-emptively argue against the craziness) |
| 01:17 | <Dashiva> | Even though the crazy people are claiming a lot of bandwidth and other finite resources? |
| 01:18 | <Philip`> | "You are currently using 102 MB (1%) of your 6767 MB." - that's equivalent to, like, 5 pence of bandwidth? I'm not too concerned about that particular resource |
| 01:19 | <Philip`> | Arguing against crazy people won't stop the arguments - only arguing against the spec's craziness and getting that fixed will stop them |
| 01:19 | <Dashiva> | I meant mental bandwidth, e.g. how much of the mailing list discussion is about it :) |
| 01:20 | <Philip`> | (I think the spec's view on alt is crazy, since it forces information loss by making important images and lazy-author images indistinguishable) |
| 01:22 | <Hixie> | it would be an interesting exercise to have a spec editor just agree to every request |
| 01:22 | <Hixie> | and see what you end up with |
| 01:22 | <Dashiva> | Hixie: Remember, you aren't reflecting the WG |
| 01:22 | <Dashiva> | That means everyone! |
| 01:22 | <Hixie> | i hope i'm not! |
| 01:23 | <Philip`> | You should reflect the majority of the WG, by doing nothing whatsoever |
| 01:23 | <Hixie> | hah |
| 01:23 | <roc> | "alt" is supposed to be shown in tooltips now? |
| 01:23 | <roc> | I thought I won that battle 7 years ago |
| 01:23 | <Hixie> | the spec in fact says it is not |
| 01:24 | <Philip`> | roc: No, but pages need to degrade gracefully in IE6/7/etc |
| 01:25 | <Philip`> | Then again, you can just do <img src=... alt="_none" title=""> to avoid the tooltip, though then it'll look ugly while the page is loading and displays the image placeholder thing |
| 01:43 | <Hixie> | i really don't understand this obsession from shepazu and julian about not referencing html5 |
| 01:44 | <shepazu> | "obsession"? |
| 01:44 | <shepazu> | I'm not obsessed, I just don't think it's a good idea to normatively reference something so early in the Rec track, with years to go |
| 01:45 | <Hixie> | btw john wanted me to remind you all that he did apologize for not remembering my post proposing to make alt="" mandatory |
| 01:45 | <Dashiva> | shepazu: It's even harder to reference implementations |
| 01:46 | <Hixie> | shepazu: why not? |
| 01:46 | <Hixie> | shepazu: it's by far the most detailed and complete definition so far |
| 01:46 | <Hixie> | shepazu: by all previous standards of quality, html5 is already far beyond REC |
| 01:46 | Philip` | assumes shepazu does not believe the timeline in the HTML WG charter, that suggests CR by 2008 Q3 and REC by 2010 Q3 |
| 01:47 | <shepazu> | Hixie: not in terms of stability |
| 01:47 | <Hixie> | shepazu: REC doesn't mean jack with respect to stability, just look at CSS2 |
| 01:47 | <Hixie> | shepazu: or HTML4 |
| 01:47 | <shepazu> | Philip`: the editor doesn't believe it, why should I? |
| 01:47 | <Philip`> | shepazu: I think that's quite sensible :-) |
| 01:47 | <shepazu> | :) |
| 01:48 | <Dashiva> | I think more and more people are caring less and less about REC :) |
| 01:48 | <Hixie> | also it's not like the stuff anne is referencing can actually change |
| 01:48 | <Lachy> | damn, I really should finish reading the whole thread before responding :-( |
| 01:48 | <othermaciej> | it would be great to switch to a better reference if there were one, but currently there isn't |
| 01:48 | <Hixie> | since it's all just describing actual implementations |
| 01:48 | <othermaciej> | referencing a document that doesn't yet contain the right info does not seem like a wise move |
| 01:48 | <othermaciej> | if the goal is to improve progress |
| 01:48 | <shepazu> | Dashiva: I think your sample may not be representative :) |
| 01:49 | <Dashiva> | shepazu: Really? I'd think CSS2.1 and CSS3 would be elsewhere on the track if so |
| 01:49 | <shepazu> | I'm not proposing dereferencing it, I'm proposing allocating resources to redirect it |
| 01:50 | <shepazu> | Dashiva: CSS is not a sane measure :) |
| 01:50 | <shepazu> | that's a good example of a bad example |
| 01:51 | <shepazu> | but that WG is getting its act together recently |
| 01:51 | <Dashiva> | Well, the other example being that HTML was left on the backburner for how many years? And javascript, to close the trinity. |
| 01:53 | <Hixie> | wow, http://www.w3.org/mid/OF7B780188.FAF5B9D6-ON85257456.00453CE0-86257456.0045F764⊙uic was totally ignored |
| 01:53 | <Hixie> | so much for caring about the blind |
| 01:55 | <Philip`> | Why does the lack of responses within 12 hours to an email that didn't raise any obvious questions indicate that people don't care about the blind? |
| 01:56 | <Hixie> | well, lots of other e-mails got replies |
| 01:56 | <Philip`> | That's not answering the question at all :-p |
| 01:57 | <Hixie> | e-mails that, just like that one, suggested allowing alt to be optional |
| 01:57 | <Hixie> | so why did they get replies and not this one? |
| 01:58 | <Philip`> | That one doesn't suggest allowing alt to be optional, as far as I can tell |
| 01:58 | <Hixie> | hey, nobody picked up JF on his false claim that html5 requires a DTD |
| 01:58 | <Philip`> | (I interpreted "DTD" as a typo for "doctype") |
| 01:58 | <Hixie> | ah, maybe |
| 01:58 | <Hixie> | he's saying that flickr is irrelevant to accessibility, basically |
| 01:59 | <Hixie> | (at least for the totally blind) |
| 01:59 | <Dashiva> | And that valid html is useless, since google is doing fine |
| 01:59 | <Philip`> | That email seems to just suggest that it's not particularly interesting what alt text Flickr uses, so it could use alt="" or alt="_none" or alt="14097651074651076.jpeg" or [nothing] and we should instead consider the effect that the conformance requirements will have on other web pages |
| 02:00 | <Hixie> | fair enough |
| 02:00 | <Philip`> | (*That email == the 0F7B one) |
| 02:00 | <Philip`> | (Uh, OF7B) |
| 02:00 | <Hixie> | (of course we do still have to consider flickr in non-blind cases, e.g. text browsers) |
| 02:00 | <Hixie> | (and other threads go into that in more detail) |
| 02:02 | <Hixie> | http://www.w3.org/mid/012301c8c056$7d03ca60$6d01a8c0⊙se is probably the clearest statement of john's opinion that i have seen so far |
| 02:02 | <Philip`> | "300 Multiple Choices" - that's far too many to choose from :-( |
| 02:03 | <Dashiva> | <movie title/> |
| 02:04 | <Hixie> | woot, i finally got to an e-mail actually discussing my proposal |
| 02:04 | <Dashiva> | Hixie: As I read it, he's got two concerns. One is that there must be some kind of presence, and the other like RB that he wants different image roles. |
| 02:04 | <Dashiva> | Anything I'm missing? |
| 02:04 | <Hixie> | not sure what you mean by either of those |
| 02:05 | <Philip`> | "Complete this sentence: This is ______: (A) orange (B) an elephant (C) madness (D) Greece" |
| 02:06 | <Dashiva> | Philip`: If you had said my name in that line, it would've been orange. |
| 02:07 | <Dashiva> | Hixie: As in, he wants there to be an explicit statement of missing alt data. And, like RB, he wants to subdivide the missing alt data images into several classes. |
| 02:07 | <Hixie> | Dashiva: ah. well that's what importantimage="" does. |
| 02:08 | <Hixie> | wish i could come up with a better name for it |
| 02:08 | <Philip`> | importantimage only subdivides into two classes |
| 02:08 | <Philip`> | which isn't quite the same |
| 02:09 | <Philip`> | (I'm not sure how any UA would make use of the extra subdivisions, though) |
| 02:10 | <Dashiva> | I wonder if <img src missingalt="personal photo"> would be acceptable, or if it would need alt="" (some value, not necessarily empty) as well |
| 02:11 | <Hixie> | Philip`: no it changes the alt="" attribute into something that categorises (freeform) the image |
| 02:12 | <Hixie> | Dashiva: my proposal is <img src alt="personal photo" important> |
| 02:12 | <Hixie> | well, src="..." |
| 02:13 | <Philip`> | Dashiva: <img alt="personal photo" almostmissingalt> conveys the same information but degrades better in existing UAs, and means you don't have to worry about what <img alt="foo" missingalt="bar"> means |
| 02:13 | <Philip`> | Hixie: Ah, I assumed it was just a boolean attribute |
| 02:13 | <Lachy> | Hixie, is the intended purpose of importantimage="" only for images where there is no good alt text, and whatever is there is a just a poor substitue, or for all images that are important content, regardless of their alt text quality? |
| 02:14 | <Hixie> | it's only for the images that right now can have alt="" omitted |
| 02:14 | <Hixie> | it says "the alt attribute isn't an alternative, it just tells you what kind of photo it is" |
| 02:14 | <Dashiva> | Philip`: I'm not sure if it's better or not, to give legacy browsers the same information-less alt text over and over. As in, I'm not sure either way. |
| 02:14 | <Lachy> | ok. Then that makes the name importantimage really bad. |
| 02:14 | <Hixie> | yes |
| 02:15 | <Hixie> | it allows UAs to change from rendering the image as "%s" where %s = alt, to rendering the image as "[IMAGE: %s]" where %s = alt and "[IMAGE: ... ]" is rendered in some UA-specific way |
| 02:15 | <Hixie> | different voice, different color, etc |
| 02:15 | <Hixie> | showing an icon |
| 02:15 | <Dashiva> | onlyimage, missingalt |
| 02:15 | <Philip`> | Dashiva: It's not informationless - it shows that the image is a personal photo, and not a graph or whatever, and it ensures legacy browsers won't pretend the image doesn't exist or display it as "[10496518746051746506.jpeg]" |
| 02:16 | <Dashiva> | Philip`: If the values are fine-grained enough |
| 02:16 | <Hixie> | <img src="..." alt-just-say-what-kind-of-image-it-is-and-doesn't-provide-a-replacement alt="photo"> |
| 02:17 | <Hixie> | maybe that attribute name is a bit long |
| 02:17 | <Dashiva> | descriptive-alt :D |
| 02:17 | <Hixie> | it's not descriptive |
| 02:17 | <Hixie> | that's the problem! |
| 02:17 | <Hixie> | nondescript="" maybe |
| 02:17 | <Dashiva> | alternate-alt |
| 02:17 | <Philip`> | Seems more useful if it is descriptive, rather than just saying what kind it is |
| 02:17 | <Hixie> | the point is it can't be descriptive |
| 02:17 | <Hixie> | you don't know what the image is! |
| 02:20 | <Philip`> | You can use metadata like Flickr titles, which has a non-zero chance of describing the photo better than just saying "photo", and UAs can automatically detect and remove repetition if they've recently read the same text from the page title/heading/etc |
| 02:21 | <Hixie> | uh huh |
| 02:21 | <Philip`> | (That's much more plausible than them containing advanced image analysis algorithms :-p ) |
| 02:22 | <Dashiva> | I think the feature is very different depending on how specific the alt-replacing value is |
| 02:22 | <Dashiva> | If it's just "image" or "photo" or "icon", compared to "personal photo" and "graph or chart" |
| 02:23 | <Dashiva> | The latter case borders on descriptive, but would it ever occur in practice? |
| 02:23 | <Hixie> | could be either |
| 02:23 | <Philip`> | Nobody's going to use this new attribute so it doesn't need to be particularly easy to type |
| 02:23 | <Dashiva> | There's a point |
| 02:24 | <Hixie> | (i'm not sure how you could end up with it being a graph or chart) |
| 02:24 | <Dashiva> | Hixie: If it's a middle management chart sharing photo site |
| 02:24 | <Hixie> | fair enough |
| 02:24 | <othermaciej> | how about calling the attribute noalt |
| 02:24 | <othermaciej> | that is at least brief |
| 02:24 | <Dashiva> | Or some kind of CMS where you know the usage of a subarea of the content |
| 02:24 | <othermaciej> | and all it would be is a conformance checker silencer |
| 02:25 | <Hixie> | having an attribute noalt="" which requires alt="" to be present would at a very minimum make us the butt of several jokes over the next few years. |
| 02:25 | <Lachy> | othermaciej, noalt would be somewhat confusing for authors because, in this case, it would still require authors to provide alt="something" |
| 02:25 | <othermaciej> | I don't think it should require alt to be present |
| 02:25 | <Hixie> | oh, then you're proposing something else |
| 02:25 | <Dashiva> | othermaciej: Then you're making a different proposal |
| 02:25 | <othermaciej> | yeah |
| 02:26 | <Hixie> | noalt="" as just an alternative to alt="" is just dumb imho |
| 02:26 | <Dashiva> | Do you plan <img src noalt="personal photo">? |
| 02:26 | <Hixie> | it doesn't solve anything |
| 02:26 | <Philip`> | othermaciej: If (alt XOR noalt) was required, that would incentivise inappropriate insertion of noalt just to silence conformance checkers, whereas requiring (alt OR (alt AND importantimage)) would remove that harmful incentive since you'd have to come up with alt text anyway |
| 02:26 | <Hixie> | and adds a number of new error conditions |
| 02:26 | <othermaciej> | I think the conformance checker insisting that you say <img src="foo.jpg" very-long-terrible-attribute-name alt="something useless"> then no one will respect the conformance checker |
| 02:26 | <Hixie> | that's why we're looking for a nice short name for very-long-terrible-attribute-name |
| 02:26 | <othermaciej> | Philip`: it would create an incentive to add alt="" just as now |
| 02:26 | <Philip`> | othermaciej: How could the conformance checker insist on that? All it knows is whether you've got an alt attribute or not |
| 02:27 | <Philip`> | and it has no idea whether you need the very-long-etc attribute or not |
| 02:27 | <Philip`> | so it has to assume you don't |
| 02:27 | <othermaciej> | in that case it wouldn't solve the problem of incentive to add alt="" incorrectly |
| 02:27 | <othermaciej> | though I will agree it does not give materially more or less incentive than now |
| 02:27 | <Lachy> | but why would authors bother using <img alt="something" importantimage=""> when they can just as easily use <img alt="something">, especially since most authors won't notice the difference unless they test in non-visual browsers |
| 02:27 | <Dashiva> | Are there use cases for this attribute in hand-written content (and not counting templateish html for generated content) |
| 02:28 | <Philip`> | Dashiva: I could hand-write <img src="random-image.cgi" alt="???"> |
| 02:28 | <Dashiva> | That counts as templateish in my book |
| 02:28 | <othermaciej> | the only semi-sane reason to insist on mandatory alt, even if it is bad, is to make it harder to accidentally omit alt |
| 02:29 | <Dashiva> | Philip`: Basically, are there cases where you'd be writing the attribute name often |
| 02:29 | <othermaciej> | if the way to say "I omitted alt on purpose" is longer to type than alt="", then authors will either ignore it or use alt="" anyway, which was the original problem the spec wanted to solve |
| 02:30 | <Hixie> | so we need a solution that's 6 letters or less |
| 02:30 | <Hixie> | badalt? |
| 02:30 | <hdh> | not-alt(ernate) sounds better than noalt, being a bool |
| 02:30 | <Philip`> | Do they have to be ASCII letters? |
| 02:30 | <Hixie> | yes |
| 02:30 | <Philip`> | :-( |
| 02:30 | <Hixie> | :-P |
| 02:30 | <Dashiva> | alt0 |
| 02:31 | <Dashiva> | Hmm... x-alt, maybe |
| 02:31 | <Philip`> | <img src=... alt="Some kind of photo, I don't know really" altsucks> |
| 02:32 | <Hixie> | the effect i would expect this attribute to have on visual (graphical) browsers is that when they have images disabled, they'd show icons only for images with this attribute set (and maybe also those without alt="" set at all) |
| 02:32 | <Hixie> | so maybe an attribute name that plays on that? |
| 02:33 | <Philip`> | And they'd show the alt text (but no icon) for other images? |
| 02:33 | <Hixie> | <img src="..." alt="photo" icon> is confusing since the image isn't an icon... |
| 02:33 | <Hixie> | Philip`: right |
| 02:36 | <Philip`> | othermaciej: Hmm, I thought it was more about making sure conscientious authors are able to write conforming content - I don't see how we can do anything with lazy authors, since all the useful things we could do would be requiring the authors to give us more information, which they won't because they're lazy |
| 02:36 | <Philip`> | (Nearly all authors (except the most conscientious) will just write non-conforming content anyway, so we can't do anything to them) |
| 02:37 | <othermaciej> | Philip`: well, there's two different issues for conscientious authors |
| 02:38 | <othermaciej> | ok let me backtrack |
| 02:39 | <othermaciej> | is it better for an author who is serving a truly random unknown image to say <img alt="image" src="random.cgi" altsucks> or <img alt="" src="random.cgi" altsucks> or <img src="random.cgi" noalt>? |
| 02:39 | <othermaciej> | (though perhaps arguably all of these may be worse than saying nothing) |
| 02:40 | <othermaciej> | I would argue that saying "image" is worse in current AT, since it is likely worse than the localized image indicator, and alt="" is worse in current AT because it will make many screen readers skip the image entirely |
| 02:40 | <Hixie> | with my proposed attribute alt="" would be required to be non-empty |
| 02:40 | <othermaciej> | future AT would presumably ignore alt="" on such images so it won't be a benefit in that case |
| 02:41 | <Philip`> | othermaciej: The first option seems to produce the best output in current UAs, since the second is often entirely skipped and the user will never know there was an image, and the third is sometimes read as "random.cgi" (which is uglier than "image") or as "image" (which is no better than "image") |
| 02:41 | <othermaciej> | but alt="image" may well still be worse than letting the AT do its normal image identification heuristic |
| 02:41 | <othermaciej> | Philip`: reading as "image" is better because it is localized |
| 02:41 | <othermaciej> | and can use a distinguished voice |
| 02:41 | <Philip`> | It seems hard to be much worse than ATs' normal image identification heuristics :-) |
| 02:42 | <Dashiva> | I think we all know existing AT is not quite optimal in many ways |
| 02:42 | <Hixie> | we're not targetting today's ATs |
| 02:42 | <Hixie> | (by definition) |
| 02:42 | <Hixie> | though it is important that contain degrade well in today's ATs |
| 02:42 | <Hixie> | which is the main argument against making alt="" optional |
| 02:42 | <othermaciej> | future ATs would not benefit from saying alt="image" and may well do worse than if it is not specified (unless they hardcode a big list of alt text that is too generic to be helpful) |
| 02:43 | <Philip`> | Future UAs can read <img alt="image" altsucks> in a distinguished voice, and it will be localised consistently with the rest of the page's textual content |
| 02:43 | <Dashiva> | Only image is spelled correctly |
| 02:43 | <Dashiva> | :) |
| 02:44 | <Dashiva> | As I see it, AT needs to cope with images missing alt. That's a fact of life. So if we give them a missing alt and the magic future-supported new attribute, they will do no worse than they would with most images, and they will do better in the future |
| 02:44 | <othermaciej> | <img alt="image"> would degrade worse than <img> with no alt attribute in at least some current AT (e.g. VoiceOver) |
| 02:44 | <Philip`> | othermaciej: In what ways is it worse? |
| 02:45 | <Philip`> | (At least by default, VO says "image" in the same voice as normal page content, if I remember correctly) |
| 02:45 | <othermaciej> | because it is not localized to the user's OS language |
| 02:45 | Philip` | has no idea how many people reconfigure those voices |
| 02:45 | <Philip`> | Is that much of a problem, given that the entire page is not localised to the user's OS language either? |
| 02:46 | <othermaciej> | (localizing to the page content is not the same; we don't translate all the menus to French if you visit a French web page on a German system) |
| 02:47 | <Philip`> | If you don't understand French, you might not understand it saying "image" in a French accent (or whatever the translation is), but you also wouldn't understand anything else on the page so the image part is a relatively trivial inconvenience |
| 02:48 | <Dashiva> | The utility of this attribute in the first place is rather minimal |
| 02:48 | <Hixie> | http://junkyard.damowmow.com/325 btw if people want to play around with various UAs |
| 02:48 | <Philip`> | You'd just want to be able to find the <img src=german-flag.gif alt=Deustch> and then you'd be happy |
| 02:49 | <Philip`> | Hixie: Try them in <a href>s too, since that gives different behaviour |
| 02:49 | <Dashiva> | But ironically enough, I have a design & usability exam in a few hours, so I gotta sleep. :) |
| 02:49 | <Hixie> | can't right now. may later. |
| 02:49 | <Hixie> | bbiab |
| 02:49 | <gavin_> | "image" is "image" in french |
| 02:51 | <Philip`> | Oh, bed is a good idea |
| 02:54 | <Philip`> | About attributes names: For consistency with <img src alt>, it ought to be a hard-to-understand few-letter abbreviation |
| 02:57 | <hdh> | mpa, missing-proper-alt, just not from one word |
| 02:58 | Philip` | fails to think of an expansion for "lol" that can fit in front of "cat(egory)" |
| 03:17 | <MikeSmith> | Lachy: you there? |
| 06:20 | <Dashiva> | Philip`: "lazy or lacking" |
| 07:53 | <MikeSmith> | Lachy: ping me when you back around |
| 07:53 | <MikeSmith> | please |
| 08:07 | <Lachy> | ping |
| 08:07 | <Lachy> | MikeSmith, |
| 08:07 | <MikeSmith> | Lachy: hei |
| 08:07 | <MikeSmith> | wanted to ask if you had seen Thomas Roessler's HTML5 slides yet |
| 08:07 | <Lachy> | no |
| 08:08 | <MikeSmith> | http://www.owasp.org/index.php/AppSecEU08_HTML5 |
| 08:08 | <MikeSmith> | PDF slides: http://www.w3.org/2008/Talks/0521-owasp-html5-tlr/0521-owasp-html5-tlr.pdf |
| 08:09 | <MikeSmith> | he has some fun images in there |
| 08:09 | <MikeSmith> | maybe some that you could repurpose |
| 08:14 | <Lachy> | nothing suitable in there |
| 08:14 | <Lachy> | I'm looking for a spirit level or something similar to represent validation |
| 08:14 | <Lachy> | and maybe a hammer or some other tool for html5lib |
| 08:41 | <hsivonen> | Lachy: Re: photo representing tools: http://flickr.com/photos/geishaboy500/100043823/ |
| 08:44 | <Lachy> | hsivonen, nice! |
| 08:47 | <virtuelv> | heh, what's this supposed to mean? http://twitter.com/mollydotcom/statuses/821528080 |
| 08:57 | <hsivonen> | whoa. lots of irc log about noalt |
| 08:58 | <annevk> | I skipped it |
| 08:58 | <annevk> | just like some of the e-mails :) |
| 08:59 | <othermaciej> | so can anyone help me find a good CC-licensed (or otherwise reusable) photo of a beaker or flask of acid (or some chemical that could pass for such)? |
| 08:59 | <othermaciej> | I could use a presentation picture for "acid tests" |
| 08:59 | <hsivonen> | fwiw, I agree with othermaciej that the only semi-sane reason for noalt is helping forgetful authors, but I think the Image Report already covers that case |
| 08:59 | <othermaciej> | I think the image report covers it too |
| 08:59 | <othermaciej> | hsivonen: although, there is value to a warning that you can drive down to 0 |
| 08:59 | <othermaciej> | compared to a long list you must review on every change |
| 09:00 | <othermaciej> | (that's why WebKit builds with -Werror even though it causes us no end of pain in central builds for Mac OS X) |
| 09:00 | <Philip`> | hsivonen: Forgetful authors will forget to turn the image report on, or if they do turn it on then they'd forget to look at it |
| 09:01 | <hsivonen> | Philip`: will they forget to run a validator at all? |
| 09:01 | <hsivonen> | (that's what I forget occasionally when updating an existing page) |
| 09:02 | <Philip`> | (and it doesn't provide any immediate feedback like "you forgot to put alt on 3 images here and here and here", so it takes a reasonable amount of effort and concentration to work out where you've gone wrong) |
| 09:02 | <hsivonen> | (leading to comical stuff like validator documentation being invalid) |
| 09:02 | <hsivonen> | the Image Report has a group for missing alt that you can drive to zarro and links to source locations |
| 09:03 | <Philip`> | hsivonen: Not all people will forget to validate at all, and some of those who remember will fail to use the fancy options |
| 09:04 | <othermaciej> | hsivonen: but that's no good if you have cases where missing alt is the right thing |
| 09:04 | <Philip`> | hsivonen: It takes effort and concentration to find that group, since it looks the same as all the other groups of images |
| 09:04 | <othermaciej> | hsivonen: thus, noalt to tag such locations |
| 09:04 | <hsivonen> | othermaciej: yeah, that's a semi-sane use case for noalt |
| 09:05 | <Philip`> | <!-- #pragma warning(disable:missing-alt) --><img src=random.cgi> |
| 09:05 | <hsivonen> | Philip`: shouldn't authors maximize the effort and concentration on accessibility?????? |
| 09:05 | <zcorpan_> | i don't see why missing alt is worse than alt='' when the right thing should be alt='something else' |
| 09:06 | <Hixie> | it's not |
| 09:06 | <Hixie> | it's better :-) |
| 09:06 | <zcorpan_> | both authors and tools emit alt='' out of cargo cult fasion |
| 09:06 | <Philip`> | hsivonen: Yes, but we should maximise the return for a given level of (typically quite low) effort |
| 09:07 | <hsivonen> | Philip`: sure ( ?????? means :-) ) |
| 09:08 | <hsivonen> | what does XXX4 mean on tlr's slide of window props? |
| 09:10 | <MikeSmith> | hsivonen: referring to http://www.whatwg.org/specs/web-apps/current-work/#xxx4index |
| 09:10 | <MikeSmith> | I guess |
| 09:10 | <othermaciej> | it is surprisingly hard to find a good free picture of a beaker or flask of acid |
| 09:10 | <Philip`> | (Also the Image Report has way too many words in it, partly because the alt requirements are too hard to explain, and so people simplify to "alt is optional" (which isn't what we want since in almost all cases alt is required)) |
| 09:11 | <hsivonen> | MikeSmith: thanks |
| 09:11 | <MikeSmith> | hsivonen: placeholder method name from Window interface |
| 09:11 | <MikeSmith> | hsivonen: np |
| 09:11 | <hsivonen> | sometimes the Web is so weird that I'm not sure if there's an implemented property named XXX4 |
| 09:11 | <MikeSmith> | othermaciej: we should consider other image metaphors for acid |
| 09:12 | <MikeSmith> | blotter-paper, windowpane |
| 09:12 | <MikeSmith> | Sandox Labs ampule |
| 09:13 | <annevk> | lol, XXX4 is a reference to Web IDL for something that's not defined yet |
| 09:13 | <othermaciej> | MikeSmith: I don't want people to get the impression that this is an electric kool-aid acid text |
| 09:14 | <othermaciej> | now I want to add window.XXX4 to WebKit |
| 09:14 | <othermaciej> | but I need to figure out what is should do |
| 09:14 | <Hixie> | http://www.whatwg.org/specs/web-apps/current-work/#xxx4index |
| 09:14 | <Hixie> | it's the index getter on Window |
| 09:15 | <othermaciej> | maybe this picture for "acid test": http://www.dkimages.com/discover/previews/967/65020227.JPG ? |
| 09:15 | <othermaciej> | or maybe this one looks friendlier: http://www.koh-development.com/Images/erlenmeyer_flask.jpg |
| 09:15 | <Hixie> | use the pictures on acidtests.org/images |
| 09:15 | <Hixie> | :-) |
| 09:15 | <MikeSmith> | othermaciej: that first one says "noxious odor" to me |
| 09:16 | <MikeSmith> | othermaciej: second one says, "beaker full of brandy" |
| 09:16 | <othermaciej> | how about this: http://z.about.com/d/chemistry/1/0/B/T/flask.jpg |
| 09:16 | <othermaciej> | does that one say, "this web stuff is totally scientific"? |
| 09:17 | <hsivonen> | tlr has an interesting photo choice for introducing the HTML WG |
| 09:17 | <othermaciej> | or this: http://www.koh-development.com/Images/filtration_flask.jpg |
| 09:18 | <annevk> | heh, that presentation is great |
| 09:18 | <annevk> | (the one from thomas) |
| 09:18 | <hsivonen> | (the photo introducing the WG is http://www.flickr.com/photos/lassmatazz/325437141 ) |
| 09:19 | <annevk> | hsivonen, isn't that a photo about what will happen with registerContentHandler ? |
| 09:19 | <annevk> | hsivonen, web sites fighting over who will get the media type? |
| 09:20 | <hsivonen> | annevk: oh |
| 09:20 | <annevk> | hsivonen, could be your way as well I suppose |
| 09:20 | annevk | thought http://www.flickr.com/photos/nathansnider/497536082/ was introducing HTML5 |
| 09:28 | <MikeSmith> | fwiw, while taking a look at the following page I came across an issue that seems to me to illustrate to authors one of unintended consequences of serving XHTML content as text/html |
| 09:28 | <MikeSmith> | page is this: |
| 09:29 | <MikeSmith> | http://www.w3.org/TR/xmlschema-1/ |
| 09:29 | <MikeSmith> | I looked at it because David Storey from Opera pointed out a CSS mistake in it |
| 09:29 | <MikeSmith> | http://www.w3.org/TR/xmlschema-1/#c-selector-xpath |
| 09:29 | <MikeSmith> | the table there |
| 09:30 | <MikeSmith> | has negative text-indent set on it |
| 09:30 | <MikeSmith> | which causes the text to overflow the left edge of the table |
| 09:30 | <MikeSmith> | in Opera and in Webkit |
| 09:31 | <MikeSmith> | but in looking at that, the other thing I noticed was duplicate <a name>s with the same ID values all over the place |
| 09:32 | <MikeSmith> | in Web Inspector |
| 09:32 | <othermaciej> | blech |
| 09:34 | <MikeSmith> | http://www.w3.org/2008/05/dup-a-name.png |
| 09:34 | <MikeSmith> | so I filed a bug: |
| 09:34 | <MikeSmith> | https://bugs.webkit.org/show_bug.cgi?id=19282 |
| 09:34 | <Philip`> | http://code.google.com/p/aza/source/browse/trunk/SocialHistory/SocialHistory.js - that detecting-visited-links thing is catching on |
| 09:34 | <MikeSmith> | knowing pretty much what the answer would |
| 09:35 | <Philip`> | "The best part is that this information leak will never be plugged because it’s a fundamental feature of the browser.", apparently |
| 09:35 | <annevk> | MikeSmith, it's an Appendix C violation |
| 09:35 | <MikeSmith> | Philip`: hmm, that's Aza Raskin's stuff |
| 09:36 | <Philip`> | MikeSmith: Indeed |
| 09:36 | <MikeSmith> | annevk: yeah. I guess it must have been generated from xmlspec source |
| 09:37 | <MikeSmith> | so maybe same problem will occur with anything generated from xmlspc |
| 09:37 | <annevk> | there are other specs with the same issue, yeah |
| 09:38 | <annevk> | or some issue like that anyway |
| 09:38 | <annevk> | W3C is just as much responsible for TAG soup as the rest of the Web :p |
| 09:38 | <MikeSmith> | heh |
| 09:39 | <MikeSmith> | well, particular end result of that problem, in Webkit at least, is duplicate IDs (and fragment identifiers) all the hell all over the place in the DOM |
| 09:40 | <annevk> | maybe you guys should deploy validator.nu ;) |
| 09:40 | Philip` | had the same problem when his spec-annotation code produced <span style="background:red">%s</span> and then %s = '' and then it was serialised as XML and interpreted as HTML, so he had to write an HTML serialiser instead |
| 09:41 | <Philip`> | The problems tend to be annoyingly subtle |
| 09:43 | <hsivonen> | annevk: validator.nu doesn't catch duplicate IDs in text/html at the moment |
| 09:46 | <annevk> | the specific issue is <a/> not duplicate IDs |
| 09:46 | <hsivonen> | oh ok |
| 09:48 | <Lachy> | I need one more picture for the How to Contribute slide, and I'm done! |
| 09:50 | <Lachy> | what's an animal that's typically known for working together in a community, or could otherwise convey teamwork? |
| 09:50 | <Philip`> | A human? |
| 09:50 | <Lachy> | Philip`, other than a human |
| 09:50 | <hsivonen> | Lachy: an ant |
| 09:50 | <hsivonen> | Lachy: but I read somewhere that ants are actually pretty chaotic |
| 09:51 | <Philip`> | Teamwork is often chaotic :-) |
| 09:51 | <MikeSmith> | Lachy: a jackal |
| 09:51 | <Lachy> | what's a jackal? |
| 09:51 | <hsivonen> | Lachy: a lone assassin |
| 09:52 | <MikeSmith> | pack of jackals |
| 09:52 | <hsivonen> | the lone gunmen?-) |
| 09:53 | <Lachy> | http://en.wikipedia.org/wiki/The_Lone_Gunmen ? |
| 09:53 | <Philip`> | http://www.flickr.com/photos/kasimetcalfe/118471837/ |
| 09:54 | <hsivonen> | Lachy: http://en.wikipedia.org/wiki/The_Jackal_(fictional_character) |
| 09:54 | <Hixie> | i wouldn't liken this community to ants |
| 09:55 | <Lachy> | what about bees? |
| 09:55 | <Philip`> | But they're so cute |
| 09:56 | <Hixie> | nor bees |
| 09:56 | <Hixie> | sharks, maybe... |
| 09:56 | <roc> | piranhas |
| 09:57 | <Hixie> | yeah, or piranhas |
| 09:57 | <Hixie> | do they school? |
| 09:57 | <annevk> | http://upload.wikimedia.org/wikipedia/en/6/69/New_FOXHOUND.jpg |
| 09:57 | <roc> | "It is not rare to find individuals with one eye missing due to a previous attack." |
| 09:57 | <annevk> | though not everyone might get the reference |
| 09:59 | <Lachy> | annevk, I don't get it |
| 09:59 | <Lachy> | what about http://en.wikipedia.org/wiki/Image:School_of_reef_fish_at_Rapture_Reef%2C_French_Frigate_Shoals.jpg |
| 10:00 | <Lachy> | http://commons.wikimedia.org/wiki/Image:School_of_Chaetodon_ulietensis.jpg |
| 10:01 | <roc> | Piranhas seem more appropriate, for their tendency to mutilate and cannibalize each other |
| 10:02 | <MikeSmith> | biker gang |
| 10:03 | <Lachy> | roc, I could only find photos of individual piranhas |
| 10:03 | <hsivonen> | roc: we don't do that |
| 10:04 | <roc> | the alt-fest sounds pretty painful for everyone |
| 10:05 | <othermaciej> | how about beavers? |
| 10:05 | <othermaciej> | they cooperate in a way that doesn't exactly signal hive mind |
| 10:05 | <othermaciej> | and are productive |
| 10:05 | <Lachy> | I almost forgot, I need to find a higher resolution photo of the rosetta stone with an appropriate licence |
| 10:06 | <othermaciej> | I still haven't found good acid |
| 10:06 | <othermaciej> | a picture thereof I mean |
| 10:06 | <othermaciej> | not gonna complain about drug sourcing here |
| 10:10 | <hsivonen> | roc: I think the alt and the ARIA colon threads are making people careful to avoid discussing accessibility topics |
| 10:12 | <annevk> | Lachy, http://www.oceanlab.abdn.ac.uk/blog/wp-content/pw-tight-family-cri.jpg |
| 10:13 | <hsivonen> | annevk: are those orcas? |
| 10:14 | <annevk> | they're described as whales on the page |
| 10:16 | <annevk> | i found them on |
| 10:16 | <annevk> | http://www.oceanlab.abdn.ac.uk/blog/?p=236 |
| 10:17 | <hsivonen> | should I make the XML side of Validator.nu match character encoding names according to the HTML5 rules? |
| 10:24 | <hsivonen> | are SVG WG meeting minutes public these days? |
| 10:26 | <Lachy> | This one will do http://flickr.com/photos/nathanphilpot/458372179/ |
| 10:26 | <annevk> | should be, http://lists.w3.org/Archives/Public/public-svg-wg/latest |
| 10:27 | <hsivonen> | annevk: thanks. so many lists to choose from |
| 10:28 | <annevk> | hsivonen, I think that's their new list but they seem to be using the member-only one as well sometimes |
| 10:45 | <gsnedders> | Lachy: LOL |
| 10:46 | <gsnedders> | Lachy: (that's re: my slide) |
| 10:47 | <gsnedders> | Philip`: That commit took around six seconds off parsing HTML 5's source (as opposed to the postprocessed index) |
| 10:47 | <gsnedders> | Philip`: (on my local machine, taking it down to 11s) |
| 10:55 | <Lachy> | gsnedders, I changed it. I'm just going to say that funny bit |
| 10:55 | <Lachy> | I'm publishing the slides now |
| 11:03 | <Lachy> | http://lachy.id.au/dev/presentation/hands-on-html5/hands-on-html5.pdf |
| 11:04 | <Lachy> | keynotes slides are still uploading |
| 11:04 | <gsnedders> | 31.4MB!? |
| 11:05 | <Lachy> | yeah. If I zip the PDF, then it only reduces it to 30.4 |
| 11:05 | <Lachy> | the keynote slides are only 14 |
| 11:06 | <Lachy> | http://lachy.id.au/dev/presentation/hands-on-html5/hands-on-html5.zip |
| 11:07 | <gsnedders> | Lachy: Where are you giving it, anyway? |
| 11:07 | <Hixie> | i see you agreed with my Gill Sans suggestion :-) |
| 11:08 | <Hixie> | i think your "solve real problems" picture is ironic |
| 11:08 | <Hixie> | and should have a "no" symbol over it :-) |
| 11:08 | <Hixie> | (circle with a slash) |
| 11:10 | <Lachy> | it's supposed to convey the concept of solving things, not be technically accurate :-) |
| 11:12 | <gsnedders> | Lachy: html5lib only has complete parsers in Python and Ruby, and has a incomplete tokeniser in C. There is no C++ |
| 11:12 | <Dashiva> | It seems Lachy ignored all my comments *sob* |
| 11:12 | <Lachy> | ok, I'll fix that |
| 11:13 | <gsnedders> | ah. @media. Mols was trying to con me into going there |
| 11:13 | <Lachy> | gsnedders, I just changed it to "Python, Ruby, C" |
| 11:13 | <Dashiva> | Are there supposed to be two identical kitteh blog slides? |
| 11:14 | <Lachy> | they're not identical |
| 11:14 | <Lachy> | oh, I see. the PDF printed each individual step, rather than the whole slide |
| 11:14 | <Dashiva> | I can't tell the difference between the two first in the pdf. |
| 11:14 | <Lachy> | I'll fix that later |
| 11:14 | <Dashiva> | oh |
| 11:22 | <hsivonen> | Hixie: do you intend the HTML5 encoding matching to be normative over XHTML5? |
| 11:27 | <hsivonen> | Lachy: "C++" under "html5lib"? |
| 11:28 | <Hixie> | gsnedders: is she the one who is working with microsoft? |
| 11:29 | <Hixie> | or is this another molly |
| 11:29 | <Hixie> | i get them all so confused |
| 11:29 | <Hixie> | hsivonen: um |
| 11:29 | <Hixie> | hsivonen: elabroate? |
| 11:30 | <hsivonen> | Hixie: the step where punctuation is ignored when finding a decoder to instantiate |
| 11:30 | <hsivonen> | Hixie: is that supposed to apply Web platform wide |
| 11:30 | <hsivonen> | to XML, CSS, text/plain, etc.? |
| 11:30 | <gsnedders> | Hixie: yes, that Molly |
| 11:30 | <gsnedders> | Hixie: as in "molly" on IRC :P |
| 11:31 | <gsnedders> | Hixie: and molly.com |
| 11:31 | <Hixie> | hsivonen: oh. dunno. what do UAs do? Does XML define anything? |
| 11:31 | <Hixie> | or CSS? |
| 11:31 | <hsivonen> | Hixie: I thought you'd have it figured out :-) |
| 11:32 | <Hixie> | i just wrote the html5 spec, not the others :-P |
| 11:32 | <Hixie> | it probably should apply platform-wide, but the validator should complain about anything not matching the real names in any case |
| 11:32 | <hsivonen> | ok |
| 11:37 | <Lachy> | hsivonen, yeah, I know. I looked at the html5lib repo and saw python, ruby and C, but I accidentally wrote C++ instead. |
| 11:43 | <hsivonen> | I think I'll just let the punctuation weirdness fall under the "not the preferred name" error |
| 11:46 | <annevk> | "Who thinks they know more about it than we do?" is slightly arrogant |
| 11:46 | <annevk> | and makes me want to come over and make fun of you :p |
| 11:46 | hsivonen | agrees it is arrogant |
| 11:48 | <Dashiva> | Remove "thinks they" |
| 11:48 | <Dashiva> | And then they can see if it's anne before mocking them |
| 11:58 | <annevk> | hsivonen, I think the SVG WG is going to proppose using an XML parser in text/html in some way |
| 11:58 | <Lachy> | hsivonen, annevk, what should I use instead? |
| 11:58 | <annevk> | (glancing over their minutes) |
| 11:58 | <annevk> | Lachy, just drop it |
| 11:58 | <Lachy> | ok |
| 11:59 | <Dashiva> | annevk: That'll be fun |
| 11:59 | <hsivonen> | annevk: I'm eager to see their implementation |
| 12:00 | <hsivonen> | annevk: also, I'm eager to see an explanation how it solves a Real Problem |
| 12:01 | <Hixie> | annevk: if they manage to find a way to do that while addressing the constaints we have to work with, that'd be great! |
| 12:01 | <Hixie> | i totally failed to do so |
| 12:01 | <othermaciej> | having an implementation is merely an implementation issue |
| 12:02 | <othermaciej> | no need to be concerned with that sort of thing |
| 12:02 | <annevk> | Hixie, I'm personally not that intrigued by the idea of doubling the complexity of the HTML parser, but we'll see |
| 12:03 | <othermaciej> | annevk: obviously a worthwhile tradeoff for the benefit of dracanoian error handling in text/html, plus the all-important ability to cut & paste source fragments into illustration tools |
| 12:03 | <Hixie> | if they seriously find a way to do it while not violating the constratints, i'm definitely interested |
| 12:03 | <Hixie> | however, i'm 99% sure that's not possible, so that may be a moot point |
| 12:04 | <Hixie> | i wonder if i wrote down the constraints anywhere convenient |
| 12:04 | <Hixie> | other than irc logs... |
| 12:05 | <annevk> | I think they're scattered around on varoius wiki pages, e-mail archives and IRC |
| 12:05 | <Hixie> | pity |
| 12:07 | <annevk> | given that including a new vocabulary is something we don't expect to happen often it's probably not much of an issue to repeat them now and then, though having them somewhere on a wiki would be preferred of course |
| 12:14 | <Hixie> | http://krijnhoetmer.nl/irc-logs/whatwg/20080417 has the constraints |
| 12:19 | <zcorpan> | Hixie: could you click on one or more of those yellow boxes so i know where to look? |
| 12:22 | zcorpan | found |
| 12:23 | <annevk> | starts about here: http://krijnhoetmer.nl/irc-logs/whatwg/20080417#l-238 |
| 12:26 | <Lachy> | I've fixed all the issues with the slides and uploaded new copies |
| 12:27 | <Hixie> | http://wiki.whatwg.org/wiki/Constraints_for_New_Vocabularies |
| 12:28 | annevk | downloads a new copy |
| 12:28 | <gsnedders> | Someone will be happy about <http://hg.gsnedders.com/http-parsing/rev/dc816eb2bc3a>; :P |
| 12:30 | <annevk> | Lachy, it's not too clear on where people should go to join this stuff, e.g. whatwg.org / w3.org/html |
| 12:32 | <Hixie> | well crap. i can't find why i added rel=contact. |
| 12:33 | <hsivonen> | Hixie: XFN? |
| 12:33 | <Hixie> | nope, that's the problem |
| 12:33 | <Hixie> | it clashes with xfn |
| 12:33 | <Hixie> | i need to work out whether to nuke it altogether, or rename it |
| 12:34 | <hsivonen> | I've finally seen a reasonable use case for a subset of XFN |
| 12:34 | <annevk> | hmm, it's not in http://www.w3.org/TR/html4/types.html#type-links |
| 12:34 | <annevk> | though I remember using it way before XFN |
| 12:34 | <hsivonen> | social network portability by scraping XFN+hCard-enabled profile pages |
| 12:36 | <Hixie> | oh well, i guess i'll comment it out |
| 12:37 | <Hixie> | oh wait, i see why i have it |
| 12:37 | <Hixie> | it's the 8th mode used rel= value |
| 12:37 | <annevk> | s/mode/most/ |
| 12:39 | <hsivonen> | does WordPress emit it on blogrolls or something? |
| 12:39 | <Lachy> | annevk, I added this as the second last slide just before the credits http://lachy.id.au/temp/links.jpg |
| 12:40 | <Lachy> | is that ok? |
| 12:40 | <Lachy> | or should I left align it like the others? |
| 12:40 | <Lachy> | or center align the other links for blog, etc. |
| 12:41 | <annevk> | that's great |
| 12:41 | <annevk> | though'd put it as the last slide |
| 12:42 | <Lachy> | ok |
| 12:48 | <hsivonen> | hmm. WAI really like to use "Best Practices" instead of "Guide" or "Primer" |
| 12:51 | <Lachy> | those changes have been made and are uploading now. if anyone finds any more problems with the slides, email me and I'll try and fix them tonight or tomorrow morning. |
| 12:51 | <Lachy> | gotta go. bye |
| 12:54 | <gsnedders> | annevk: is there any way to get something like responseHTML? |
| 12:56 | <annevk> | it's called responseXML |
| 12:57 | <gsnedders> | annevk: Without using XML? :P |
| 12:57 | <annevk> | responseXML is a misnomer for responseDocument |
| 12:57 | <gsnedders> | what does IE do if it gets something for XHR that's app/xhtml+xml? |
| 12:58 | <annevk> | I forgot |
| 12:58 | <gsnedders> | annevk: See, I'm trying to work from XHR1 — that makes it clear that responseXML is XML :P |
| 13:00 | <gsnedders> | bbiab |
| 13:04 | <Hixie> | ah, our platform is so quirky |
| 13:04 | <Hixie> | responseXML contains HTML, innerHTML contains XML... |
| 13:05 | <annevk> | and no vendor lock in |
| 13:05 | <annevk> | it's amazing that it survives |
| 13:06 | <annevk> | wait, in retrospect, that's contradictory :) |
| 13:10 | <Hixie> | the img-alt folder has risen to the top of the list of folders sorted by number of e-mails, ignoring folders that i am intentionally delaying handling of |
| 13:10 | <Hixie> | (e.g. wf2, rendering, aria) |
| 13:11 | <Hixie> | dom-focus is the next biggest non-delayed folder |
| 13:11 | <Hixie> | and that's mostly about tabindex and friends |
| 13:11 | <Hixie> | no idea what to do with that... |
| 13:12 | <annevk> | I thought there was a proposal for having some kind of focus model |
| 13:12 | <Hixie> | i guess i'll find out when i read the folder |
| 13:13 | <annevk> | Hixie, use 'set' for unordered and 'list' for ordered? |
| 13:13 | Hixie | points at the topic |
| 13:13 | <Hixie> | :-P |
| 13:13 | <hsivonen> | Hixie: tabindex is considered part of the aria folder these days, isn't it? |
| 13:13 | <Hixie> | aria is about what you report to the AT, not what the non-AT-user sees |
| 13:14 | <annevk> | Hixie, meh, that's what Python does and it's quite understandable :) |
| 13:14 | <Hixie> | :-) |
| 13:16 | <Hixie> | actually it seems i've already resolved tabindex="" in the spec |
| 13:16 | <Hixie> | these comments are just minor editorial things, mostly |
| 13:16 | <Hixie> | or requests for new features |
| 13:18 | <annevk> | the e-mail I thought of is titled "Focus management" from May 2007 |
| 13:21 | <Hixie> | yeah that's just new ideas and fixes |
| 13:22 | <hsivonen> | hmm. does one become an implementor by writing a Cocoa app that embeds WebKit? |
| 13:22 | <Hixie> | how to do notifications (toasts, bouncing the dock icon, etc) is also in this folder |
| 13:22 | <Hixie> | i wonder how to do that without opening it up to abuse |
| 13:23 | <Hixie> | hsivonen: if you just use it as a black box and write pages for it, you become an author and likely an unimportant one, since that's not an interop case) |
| 13:23 | <annevk> | hsivonen, yeah... |
| 13:23 | <Hixie> | hsivonen: if you write a browser with it, you become an implementor |
| 13:24 | <Hixie> | hsivonen: if you actually hack on webkit itself, you are an implementor. |
| 13:24 | annevk | wonders if we're investing too much time discussing pointless e-mails |
| 13:25 | <annevk> | probably not |
| 13:30 | <Hixie> | stress relief :-) |
| 13:30 | <Hixie> | ok bed time |
| 13:30 | <Hixie> | nn |
| 13:30 | <hsivonen> | nn |
| 13:38 | <annevk> | g'night |
| 13:41 | Philip` | sees http://lists.w3.org/Archives/Public/public-html-diffs/ |
| 13:41 | <hsivonen> | who is "TZ" in http://lists.w3.org/Archives/Public/public-svg-wg/2008AprJun/0057.html ? |
| 13:42 | Philip` | assumes it's a bad list to subscribe to, if it's going to get ~2.5MB diff-marked emails for every commit |
| 13:43 | <hsivonen> | the minuted claims about Gecko's parsing behavior don't look right |
| 13:44 | <annevk> | Tony Zlatinski I think |
| 13:45 | <annevk> | (samsung) |
| 13:45 | <hsivonen> | annevk: thanks |
| 13:47 | <MikeSmith> | Philip`: about the diffs list, yeah, you probably would not want to subscribe to thaat |
| 13:47 | <MikeSmith> | but it may be moot |
| 13:47 | <MikeSmith> | for the time being at least |
| 13:47 | <roc> | hum |
| 13:48 | <MikeSmith> | because I've not actually been able to deliver to it |
| 13:48 | <roc> | what Opera developer is in favour of switching to XML parsing in the middle of an HTML document |
| 13:48 | <MikeSmith> | not able to deliver the diffs to it (because I'm running into delivery issues with the W3C mail server) |
| 13:48 | <Philip`> | Do they also want to switch back to an HTML parser for doing inline HTML in SVG? |
| 13:49 | <roc> | I can tell you for sure that we do not switch between our HTML parser and our XML parser |
| 13:50 | <annevk> | I think their idea is having something like the <style> or <script> element for XML |
| 13:51 | <Philip`> | Like IE's <xml>? |
| 13:52 | <annevk> | I guess so, yes |
| 13:53 | <gsnedders_mibbit> | they've sent anything yet? |
| 13:53 | <annevk> | I believe the aforementioned Tony is tasked with writing a proposal |
| 13:53 | Philip` | wonders how many of their concerns would be satisfied by using the spec's old SVG-in-HTML parsing behaviour, but with conformance requirements such that any conforming SVG-in-HTML is trivially copy-and-pasteable into well-formed XML |
| 13:53 | <annevk> | From their minutes, anyway |
| 13:54 | <shepazu> | Philip`: that was indeed my initial thought, and it's possible that that's a way forward |
| 13:56 | <shepazu> | Philip`: but that's a rather big long road to walk (with roadblocks and minefields), and while it's worth looking into, a certain time pressure's been put on the SVG WG (the looming threat of "well, if they don't propose something soon, we'll put this back in") |
| 13:57 | <roc> | oh boy |
| 13:58 | <Philip`> | shepazu: XML-style error handling seems likely to face far more roadblocks and minefields than tightening the conformance requirements would |
| 13:58 | <shepazu> | note that that's not why we're looking at this alternative... Samsung has direct implementation experience that we're drawing from |
| 13:58 | <roc> | just propose something and the whatwgistas will debug it for you |
| 13:59 | <shepazu> | roc, I've been proposing something for months, and that's not the case.... it's met with unreasonable resistence |
| 13:59 | <shepazu> | resistance |
| 13:59 | <annevk> | well, iirc, it didn't meet the constraints: http://wiki.whatwg.org/wiki/Constraints_for_New_Vocabularies |
| 13:59 | <shepazu> | ... case in point. |
| 13:59 | <annevk> | anyway, back to merging xhr1 / xhr2 |
| 14:00 | <roc> | shepazu: the constraints are unreasonable? |
| 14:01 | <shepazu> | roc: not necessarily, but the interpretation seems to be |
| 14:02 | <shepazu> | I don't see how my proposal fails any of those constraints |
| 14:02 | <Philip`> | shepazu: Do you have a link to your proposal? |
| 14:02 | <roc> | I'm not well enough informed to comment on the substance |
| 14:02 | <roc> | unfortunately |
| 14:03 | <shepazu> | http://wiki.whatwg.org/wiki/Extensions#Proposal_2:_Extensibility_Element |
| 14:04 | <shepazu> | Philip`: but the bit about adding an element is not necessary to the proposal (merely to allowing fallback content, which I also think is necessary) |
| 14:05 | <Philip`> | shepazu: That doesn't "Fail gracefully in the face of ignorant author copy/paste", because someone will copy-and-paste the <ext> into the top of their document and test it in a legacy UA and it will break nastily in <ext>-supporting UAs |
| 14:05 | <shepazu> | Philip`: explain how? |
| 14:06 | Philip` | realises he didn't read the whole of the proposal |
| 14:08 | <roc> | interesting |
| 14:08 | <Philip`> | shepazu: How they would copy-and-paste it, or how it would break nastily? |
| 14:08 | <shepazu> | the latter |
| 14:09 | <Philip`> | Depending on how the error handling is defined, it would probably result in parts of the page disappearing (e.g. if the HTML content after an unclosed <ext><svg>... is misinterpreted as SVG) |
| 14:10 | <shepazu> | so, there are 2 parts to my proposal: one, the <ext> element (and the fallback element child), and the parsing aspects (which say, essentially, parse this in HTML5 but with XML constraints) |
| 14:10 | <shepazu> | Philip`: no, the parser should be able to handle that, just as it does overlapping elements, etc., in the current HTML5 spec |
| 14:10 | Philip` | has to go for an hour |
| 14:11 | <roc> | I have to go to sleep |
| 14:11 | <roc> | but it seems like this wiki page is where energy should be focused |
| 14:11 | <roc> | for now |
| 14:12 | <roc> | regarding "Note also that the fallback idea doesn't work." |
| 14:15 | <roc> | the main danger seems to be that SVG script nodes would be executed by legacy UAs |
| 14:15 | <shepazu> | interesting |
| 14:15 | <roc> | which isn't that big a deal IMHO |
| 14:16 | <shepazu> | without an SVG context, most of those scripts would merely fail silently, no? |
| 14:16 | <roc> | probably |
| 14:16 | <shepazu> | still, worth noting |
| 14:16 | <roc> | but no approach to this problem is going to be able to avoid this |
| 14:16 | <shepazu> | right |
| 14:17 | <shepazu> | we want to concentrate the most effort on enabling good functionality, not recovering funky stuff |
| 14:17 | <roc> | some weird stuff might happen with <font> tags too |
| 14:17 | <shepazu> | though of course we have to consider failure cases, as well... |
| 14:17 | <roc> | but I think you should probably ditch the <fallback> idea since it's a bit leaky |
| 14:17 | <roc> | and it seems that resource constraints on speccing this out are an issue |
| 14:18 | <shepazu> | roc: I'd like to talk more when you have more time |
| 14:18 | <shepazu> | not sure what you mean by "leaky" |
| 14:18 | <roc> | I mean, no approach to this can be foolproof |
| 14:18 | <roc> | except, perhaps, putting all the SVG markup in an attribute |
| 14:19 | <roc> | which I do not recommend :-) |
| 14:19 | <shepazu> | heh |
| 14:20 | <annevk> | <iframe doc=... type=text/xml></iframe> ... |
| 14:20 | <roc> | exactly |
| 14:20 | <annevk> | we might get that anyway btw for sandboxing |
| 14:20 | <roc> | right |
| 14:21 | <roc> | I don't think of that as a satisfactory solution here though :-) |
| 14:21 | <annevk> | agreed |
| 14:21 | <roc> | shepazu: in my ignorance, it seems to me that your proposal could be made to work, i.e. that Hixie's comments could be addressed |
| 14:22 | <shepazu> | roc: well, at least you admit that you're ignorant ;) humility is an important personal attribute :) |
| 14:22 | <shepazu> | jk |
| 14:22 | <roc> | as long as things are defined so that any malformed content, such an unexpected tag end, bails out of <ext> immediately |
| 14:22 | <shepazu> | roc: that was my intent |
| 14:22 | <roc> | you're absolutely right :-) |
| 14:23 | <shepazu> | :) |
| 14:24 | <roc> | so one comment that would really help to address is "What elements/attributes are known?" |
| 14:24 | <roc> | and probably "What are you considering an error in tree construction?" |
| 14:24 | <roc> | since for example |
| 14:24 | <roc> | given <p>foo bar <ext>baz qux <p>foo bar |
| 14:25 | <roc> | it would be good to bail out of <ext> when we hit the next <p> |
| 14:25 | <roc> | I should also point out that implementing full-on XML parsing inside the HTML parser could be painful, despite what TZ may think |
| 14:26 | <roc> | /could be/would be/ |
| 14:26 | <annevk> | this bailing out would require reparsing in some way to not lose content |
| 14:27 | <roc> | in which case? |
| 14:27 | <annevk> | that's probably not acceptable |
| 14:27 | <annevk> | but it's not really clear to me how the XML parsing works |
| 14:28 | <annevk> | (when nested inside text/html) |
| 14:28 | <annevk> | say you have <p><ext>X</p><p>Y</p> |
| 14:28 | <annevk> | what would happen? |
| 14:29 | <roc> | I would leave <ext> at the </p> |
| 14:29 | <roc> | the XML parser would parse "X" as a DOM text node |
| 14:29 | <roc> | then you would leave <ext> mode and parse </p> as HTML |
| 14:29 | <roc> | I guess retokenization would be necessary |
| 14:30 | <roc> | but this is the discussion that you and shepazu should be having, instead of the pistols at dawn impression I'm getting |
| 14:30 | <annevk> | <p><ext><x>...</p> |
| 14:30 | <shepazu> | probably |
| 14:30 | <annevk> | roc, heh |
| 14:31 | <annevk> | there's also issues with decoding, incorrect byte sequences, etc., incremental display |
| 14:31 | <shepazu> | roc: I believe I've been acting in good faith... this is something I've been asking for for a while |
| 14:31 | <roc> | I'm not accusing anyone of bad faith |
| 14:31 | <annevk> | someone putting <ext> at the start of a well-formed fragment and changing the semantics of all the elements it includes |
| 14:32 | <shepazu> | annevk: that's an interesting point |
| 14:32 | <annevk> | (elements might end up in the wrong namespae, <image> would no longer be treated as <img>, etc.) |
| 14:32 | <roc> | incremental display? |
| 14:32 | <shepazu> | roc: progressive rendering |
| 14:32 | <shepazu> | (I assume) |
| 14:33 | <annevk> | yeah, depending on specifics that could be affected |
| 14:33 | <annevk> | the fallback proposal is pretty badly for that |
| 14:33 | <shepazu> | annevk: it's possible, but not a necessity |
| 14:34 | <shepazu> | annevk: the fallback proposal wouldn't have any effect there |
| 14:34 | <annevk> | sure, it's not really clear to me what exactly the use cases are people envision with this |
| 14:34 | <annevk> | shepazu, i think it would |
| 14:34 | <annevk> | shepazu, document sitll downloading, you're displaying some XML, at the end you suddenly hit a parse error... |
| 14:35 | <roc> | I think the fallback proposal should be tossed over the side, it is a lot less important than the problem we're trying to solve here |
| 14:38 | <shepazu> | roc: as an author, I disagree that it's unimportant... there were many times I'd have liked to provide a PNG or text fallback if SVG wasn't supported |
| 14:38 | <annevk> | isn't the assumption that going forward all UAs support SVG natively? |
| 14:38 | <roc> | you can probably cobble together some <switch> and <img xmlns="..."> to get fallback that actually works |
| 14:39 | <roc> | and not only work in legacy UAs that don't support <ext>, but also in UAs that support <ext> but not SVG |
| 14:40 | <annevk> | that's seems like a rather odd case to optimize for imo |
| 14:41 | <roc> | I'm not saying we should optimize for it |
| 14:42 | <roc> | just commenting that it (probably) falls naturally out of shepazu's direction |
| 14:42 | <shepazu> | annevk: I'm not assuming that IE will support SVG (though it would be great if it did)... and in the meantime, I'd like for authors to use SVG with confidence that the user will see *something* |
| 14:43 | <shepazu> | roc: <switch> only works if the UA supports <switch>, which is a bad fallback assumption :) |
| 14:43 | <annevk> | for IE people can use some library that plugs into silverlight in the meantime |
| 14:43 | <annevk> | assuming IE will implement <ext> but not SVG also seems like an odd case to optimize for |
| 14:43 | <roc> | optimizing for UAs that support <ext> and SVG but not <switch> seems like a very silly thing to do |
| 14:43 | <shepazu> | annevk: the <ext> proposal doesn't assume that <ext> will be implemented... it works anyway |
| 14:44 | <roc> | or even thinking about them for one second |
| 14:44 | <hsivonen> | shepazu: <desc> can be used for fallback |
| 14:46 | <shepazu> | hsivonen: that's not the intended use (it breaks the semantics), and it's not robust anyway |
| 14:46 | <shepazu> | there can be many <desc> elements in a file |
| 14:46 | <shepazu> | svg file |
| 14:51 | <annevk> | yeah, <desc> is prolly best for that if needed |
| 14:53 | <zcorpan> | <svg><fallback><img> |
| 14:55 | <roc> | so |
| 14:55 | <shepazu> | zcorpan: that makes it a feature of SVG, not of HTML, and it would need to be added as a feature of every language that is intended to work in HTML (mathml, etc.)... and I don't think it solves any problems that <ext><fallback> doesn't |
| 14:56 | <roc> | shepazu: your intent is that browsers would do strict XML conformance checking on the <ext> fragment, right? |
| 14:57 | <shepazu> | roc: depends what you mean by "strict" |
| 14:57 | <shepazu> | but generally, yes |
| 14:57 | <zcorpan> | shepazu: right but fallback would be nice to have in xhtml too, not just text/html |
| 14:57 | <shepazu> | zcorpan: I'd like <ext> to be added to XHTML, too |
| 14:58 | <zcorpan> | shepazu: ah |
| 14:58 | <shepazu> | roc, until such time as there is an infrastructure of parsers and toolchains that understand a looser parser for XML, which I think is likely |
| 14:59 | <shepazu> | roc: it's a matter of deployment strategies, in part |
| 14:59 | <roc> | wouldn't you consider that a disaster? |
| 14:59 | <shepazu> | consider what a disaster? |
| 15:01 | <roc> | loose XML parsing |
| 15:01 | <roc> | anyway |
| 15:01 | <shepazu> | if inkscape, and validators, and XML generators and parsers all had a looser parser that recovers particular validity and certain well-formedness "errors", and if it were widely deployed, I would be totally comfortable with having SVG use that syntax |
| 15:02 | <shepazu> | just not as it stands |
| 15:02 | <roc> | it seems that the biggest problem you're going to have is convincing people that browser should parse the <ext> fragment in strict XML syntax |
| 15:02 | <shepazu> | yeah :) |
| 15:03 | <shepazu> | well, not all people, just certain ones :) |
| 15:03 | <roc> | it seems that your wiki proposal doesn't even mention that |
| 15:03 | <roc> | directly |
| 15:03 | <shepazu> | hmmm... yeah, maybe I assumed that, it had been my stance for a while and it was talked about on IRC... I'll add it |
| 15:03 | <shepazu> | thanks |
| 15:04 | <roc> | in fact it says "Inside you can use XML or another format. " |
| 15:04 | <hsivonen> | shepazu: I wouldn't be too surprised if down the road Inkscape had an HTML5 parser |
| 15:05 | <annevk> | parsers are cheap |
| 15:05 | <hsivonen> | annevk: depends on how contorted they are |
| 15:05 | <roc> | hsivonen: is that true? |
| 15:05 | <roc> | :-) |
| 15:06 | <hsivonen> | roc: parsers are not exactly cheap :-) |
| 15:06 | <roc> | so until people agree on whether it's permissible or required to have strict XML parsing inside HTML, there's not much point in discussing <ext> |
| 15:06 | <roc> | so I advise you to focus on that... |
| 15:06 | <roc> | now I really have to sleep because North Americans are waking up and giving me work to do |
| 15:06 | <annevk> | well, HTML parsers until now have been pretty expensive, but now that it is properly defined they're relatively cheap |
| 15:07 | <roc> | I hope that's true |
| 15:07 | <annevk> | roc, hah |
| 15:07 | <roc> | we may not really know until a major browser implements HTML5 parsing |
| 15:07 | <annevk> | (re: sleep/work) |
| 15:07 | <hsivonen> | annevk: chances are that an HTML5 parser will be cheap for Inkscape |
| 15:08 | <hsivonen> | annevk: however, for Mozilla not as cheap |
| 15:09 | <hsivonen> | anyway, I think the SVG WG's copy-paste concern is much better solved by a serializer than by complicating parsing, in my opinion |
| 15:10 | <hsivonen> | I think Hixie's solution is remarkably elegant and (relatively) low-impact on the parser |
| 15:11 | <gsnedders> | annevk: I would throw a fatal error when <ext> doesn't start with an element |
| 15:11 | <gsnedders> | I'd rather <ext> was special like <script>: the only thing that ended it was another <ext> |
| 15:11 | <annevk> | hsivonen, true, if you have an existing HTML parser it might be relatively expensive on the short term |
| 15:11 | <gsnedders> | This is why I really expect making <ext> CDATA easier |
| 15:11 | <gsnedders> | <try> <except>? :P |
| 15:11 | <gsnedders> | (And no, that isn't a serious suggestion) |
| 15:11 | <annevk> | the first bit was? |
| 15:16 | <shepazu> | http://www.securityfocus.com/bid/29386/exploit |
| 15:23 | <Philip`> | shepazu: Hixie is concerned about cases like http://www.cocopahrv.com/map.html where extension elements like <svg> contain HTML elements that must still be treated as HTML elements by the error recovery system, which is a bit of a pain |
| 15:24 | <Philip`> | and I'm not sure how that could be handled correctly by only using abort-on-XML-ill-formedness (instead of abort-on-HTML-elements) |
| 15:26 | <Philip`> | (particularly since people seem to dislike unwinding and reparsing upon detecting errors (like with unclosed <script> elements)) |
| 15:27 | <Philip`> | (It'd still be possible to do abort-on-XML-ill-formedness-and-on-HTML-elements and have that work, though) |
| 15:30 | <Philip`> | (though if it was actual real XML-ill-formedness, that'd be irritating since it'd prevent copying output from SVG tools directly into HTML, because SVG tool output sometimes has crazy namespace doctype stuff and you couldn't copy the doctype into the HTML document) |
| 15:31 | <hsivonen> | does the SVG WG have other stated issues with Hixie's approach except for copy-paste? |
| 15:32 | <annevk> | prolly namespaces |
| 15:32 | <hsivonen> | annevk: do you mean round-tripping Inkscape cruft? |
| 15:33 | <annevk> | yeah, or author created namespaces to work around the lack of data- |
| 15:33 | <Philip`> | http://www.w3.org/Graphics/SVG/WG/wiki/SVG_in_text-html has various SVG WG comments, in case you haven't seen that |
| 15:33 | <Philip`> | (Hmm, that page looks far less ugly now that I have appropriate fonts (Gill Sans?) installed) |
| 15:34 | <hsivonen> | annevk: it seems to me that adding that feature to Hixie's design would be less disruptive than requiring an XML tokenizer mode |
| 15:34 | <hsivonen> | "SVG should remain XML when inline in HTML." is not a use case |
| 15:34 | <hsivonen> | as a requirement, it lacks rationale |
| 15:35 | <annevk> | i suppose, it's not really clear to me at all, so far it's all rather vague and people seem very focused on specific solutions rather than what we actually need (likely on both sides) |
| 15:35 | <Philip`> | We need to compete with VML-in-text/html |
| 15:36 | <hsivonen> | "Should allow for unrestricted growth of the SVG language by the SVG specifications" having legacy restrictions comes with the text/html territory. that's tough, but that's the way it is |
| 15:39 | <Philip`> | gsnedders: How do you parse the spec in 11 seconds? It seems to take me at least 17, and your computer shouldn't be 50% faster than mine :-( |
| 15:39 | <Philip`> | (on the latest version of 'source') |
| 15:40 | <hsivonen> | I disagree with even more stuff under "Use Cases and Requirements Discussion" |
| 15:40 | <gsnedders> | Philip`: I has leet computer. |
| 15:41 | <gsnedders> | Philip`: I just run `python parse.py --no-html --profile --treebuilder=lxml ../../html5` |
| 15:41 | gsnedders | shrugs |
| 15:43 | <Philip`> | gsnedders: Hmm, if I run that then it takes minutes and says "25.673 CPU seconds" |
| 15:44 | hsivonen | strongly disagrees with "Already used for SVG, so small cost of implementation " under "XML Parser" |
| 15:45 | gsnedders | tries time … to see if that agrees with the number of CPU seconds |
| 15:47 | <Philip`> | (I'm using a C2D 2.0GHz, with frequency scaling locked at maximum, so it ought to be pretty hard to get 50% better single-threaded performance, unless it's just because my python is slow or something) |
| 16:31 | <lightyear> | good evening everybody |
| 16:32 | <lightyear> | who can I ask some questions about the python html5lib? |
| 16:34 | <Philip`> | lightyear: It may be best to just ask the question here, and somebody will reply if they know the answer |
| 16:35 | <zcorpan> | are the requirements on sizes='' testable? |
| 16:35 | <lightyear> | k |
| 16:36 | <lightyear> | I was wondering if there is any nice API to search something in a tree that I get from html5lib |
| 16:36 | <jgraham> | lightyear: It depends which treebuilder you use |
| 16:36 | <jgraham> | I suggest using lxml with python |
| 16:36 | <lightyear> | like lets say, I want to have the element "html->body->div" with the attribute "class" set to ".my_class" |
| 16:37 | <jgraham> | If you use lxml you can use xpath to express that constraint |
| 16:37 | <lightyear> | I was using beautifulsoup before but that fails with a "maximum recursion depth exceeded" on my content |
| 16:37 | <lightyear> | lxml... sounds good |
| 16:37 | <jgraham> | like /html/body/div[@class='my_class' or something |
| 16:38 | <jgraham> | lightyear: Is the maximum recursion depth being exceeded only when you try to find stuff? |
| 16:38 | <lightyear> | yeah... that sound pretty good |
| 16:39 | <lightyear> | jgraham: no, when I try to parse it with the bsoup parser |
| 16:39 | <jgraham> | lightyear: Oh, that may be a html5lib bug. Can you file an issue and attach a testcase for which that happens please |
| 16:39 | <Philip`> | http://code.google.com/p/html5lib/issues/detail?id=59 ? |
| 16:40 | <lightyear> | read this, so I guess it the problem... |
| 16:40 | <lightyear> | but that one works here... |
| 16:40 | <jgraham> | Philip`: Could be. I was secretly hoping people weren't hitting the issue. I guess I need to prioritize fixing it then |
| 16:42 | <jgraham> | lightyear: It would be really useful to see a testcase if your issue is distinct from that one |
| 16:42 | <lightyear> | I try to parse http://tvshack.net |
| 16:42 | <lightyear> | the homepage |
| 16:42 | <hsivonen> | I'm tempted to write a TreeBuilder subclass for the GWT DOM wrapper |
| 16:43 | <jgraham> | On a differnt topic, has anything interesting happened in the last 3 days? The email subject lines on public-html don't look promising... |
| 16:43 | <jgraham> | lightyear: Thanks |
| 16:43 | <zcorpan> | Hixie: was adding ruby now in response to robert burns in http://www.w3.org/2002/09/wbs/40318/wd-html5-may/results ? :) |
| 16:44 | <jgraham> | (I guess Ruby is quite interesting) |
| 16:45 | <Philip`> | "Date: 2008-05-26 03:12:10 -0700; [cit] (2) <ruby> support." |
| 16:45 | <Philip`> | "Robert Burns: last responded on 26, May 2008 at 16:09 (UTC)" |
| 16:46 | <Philip`> | zcorpan: Presumably it wasn't in response, since it was done six hours earlier :-) |
| 16:46 | <zcorpan> | Philip`: ah, so good timing them :) |
| 16:46 | <zcorpan> | then |
| 16:46 | <lightyear> | jgraham: that is the way I can reproduce it everytime: http://pastebin.com/m4cd3b2be |
| 16:46 | <Philip`> | jgraham: There was, uh, some discussion of alt |
| 16:47 | <jgraham> | Philip`: That's why I said interesting ;) |
| 16:47 | <Philip`> | jgraham: Also I made inputstream a bit faster, which may be handy |
| 16:47 | <jgraham> | Philip`: Wow, cool. |
| 16:48 | <Philip`> | (but the effect is only tens of percents, not orders of magnitude) |
| 16:49 | <hsivonen> | GWT's JDK class library is much more limited than I thought :-( |
| 16:50 | <jgraham> | Still, nice to have :) Did you consider pre-populating the regexp cache with common regexps? I guess that might not make much difference since you have to compile them at least once anyway |
| 16:51 | <Philip`> | I'm not sure how that would help, since it would not decrease (and might increase) the number of regexp compilations, and anyway they take about zero time to compile |
| 16:52 | <jgraham> | It would make excepting the try/except less common which afaik is relatively slow |
| 16:54 | <Philip`> | There's only six regexps ever used (at least when parsing the spec), so that case seems pretty rare, although I wonder if precompiling ['A', 'B', ...] to /[A-Za-z]/ would make the regexp execution faster... |
| 16:55 | <takkaria> | I imagine it would, assuming python uses the pcre library |
| 16:56 | <Philip`> | Um, it would help if the regexp cache didn't totally ignore 'opposite' |
| 17:01 | <Philip`> | Hmm, /[A-Za-z]/ makes no measurable difference according to my measurements |
| 17:05 | <jgraham> | takkaria: I think python has its own regexp engine |
| 17:10 | <takkaria> | evidence I should learn python, really, so I don't keep on giving out counterfactual advice |
| 17:11 | <hsivonen> | Philip`: do you have experience with GWT? |
| 17:14 | <hsivonen> | it seems that the Validator.nu parser is not quite ready for GWT use, but with a little refactoring it could become suitable for use inside the GWT |
| 17:29 | <Philip`> | hsivonen: None at all |
| 17:32 | <hsivonen> | ok |
| 17:33 | <hsivonen> | it seems awesome in principle, but in practice it would be a lot more awesome if it supported a larger subset of the JDK class library |
| 17:36 | <Philip`> | gsnedders: Oh, whoops, I'd limited my CPU to 1.67GHz a while ago when trying to avoid it overheating while upgrading Gentoo - it goes a bit faster when I remove that limit |
| 17:39 | <gsnedders> | Philip`: That doesn't help. |
| 17:43 | <Philip`> | Also it seems I can save ~10% in the tokeniser by improving the entity matcher |
| 17:47 | Philip` | commits that and wonders how much it really helps |
| 17:49 | <Philip`> | Hmm, seems like around 7% in parsing the spec |
| 17:50 | <gsnedders> | The only problem with trying with the spec is there are very few people who actually care about paring the spec. |
| 17:50 | <gsnedders> | (or anything of the size) |
| 17:50 | <gsnedders> | I mean, one of Hixie's requirements for the spec-gen was speed. "speed is the most important." |
| 17:51 | <gsnedders> | Philip`: It seems to have regressed here |
| 17:51 | <gsnedders> | Philip`: 12.5s ow |
| 17:51 | <gsnedders> | *now |
| 17:51 | <Philip`> | It's not particularly non-representative of all HTML content, and the performance should be proportional to shorter documents |
| 17:51 | <Philip`> | gsnedders: Oh. That's not good |
| 17:51 | <Philip`> | Does it give the same result when you run multiple times? |
| 17:52 | gsnedders | is just trying a second time |
| 17:52 | <gsnedders> | Back down to 11s |
| 17:52 | gsnedders | shrugs |
| 17:52 | <gsnedders> | Probably just CPU throttling |
| 17:52 | <Philip`> | Ah |
| 17:52 | <Philip`> | That's why I disable the frequency scaling :-) |
| 17:53 | <Philip`> | ('cpufreq-set -g performance' etc) |
| 17:53 | <gsnedders> | On what? A laptop? |
| 17:53 | <Philip`> | Yes |
| 17:53 | gsnedders | cares too much about battery life :) |
| 17:53 | <gsnedders> | My next laptop (that I'll probably get end of next summer) will be specifically bought for its battery life |
| 17:54 | <Philip`> | That's why I only disable the frequency scaling temporarily while doing performance testing, and also have the AC power plugged in all the time :-) |
| 17:54 | <gsnedders> | I'm lazy :) |
| 17:54 | <Philip`> | (It resets automatically from 'performance' to 'ondemand' whenever I suspend the machine, so it doesn't matter if I forget) |
| 17:55 | <Philip`> | (Oops, no, I think it resets whenever I put the AC adapter in/out) |
| 17:56 | <Philip`> | (since that's what /etc/acpi/actions/ac_adapter.sh is set to do) |
| 17:58 | <Philip`> | gsnedders: Is battery life now considered more valuable than a 17" screen? |
| 17:58 | <gsnedders> | Philip`: Certainly. |
| 17:59 | <gsnedders> | If I was to buy one now, I'd likely get the Dell XPS M1330 |
| 18:12 | gsnedders | stares |
| 18:12 | <gsnedders> | Mail.app is at 784MB RAM usage |
| 18:12 | <gsnedders> | and increasing at 1MB/s |
| 18:42 | <zcorpan_> | btw, has something interesting happened in this space since friday? |
| 18:42 | zcorpan_ | hasn't been around |
| 18:43 | <Dashiva> | Yes |
| 18:43 | <Dashiva> | Log reading recommended |
| 18:44 | <zcorpan_> | Dashiva: can you summarize? :P |
| 18:44 | <Dashiva> | If I could, I would :) |
| 18:45 | <zcorpan_> | then i'm going to assume that nothing interesting happened and do other things :) |
| 18:46 | <Dashiva> | There was some constructive talk on @alt, for one. |
| 18:47 | <zcorpan_> | that's cool |
| 18:47 | <zcorpan_> | although i think i should try to ignore alt discussions altogether |
| 18:47 | <Dashiva> | Commentary on the SVG group's plans to use XML for SVG in HTML |
| 18:48 | <zcorpan_> | oh that might be interesting |
| 18:48 | <Dashiva> | A little ruby here and there. Feedback on Lachy's upcoming slideshow. |
| 18:49 | <zcorpan_> | k |
| 18:49 | <zcorpan_> | thanks |
| 18:53 | <hober> | I think I missed the constructive @alt discussion... it got completely drowned in the, err, other parts of the @alt threads |
| 18:55 | <takkaria> | there were a good five or six posts which advanced the discussion |
| 18:55 | <takkaria> | I still don't see it ever being resolved though |
| 19:14 | <gsnedders> | I need to blog something before this month ends |
| 19:34 | <takkaria> | heh, a whole string of proposals from RB have just hit the issue tracker |
| 19:35 | <hsivonen> | takkaria: also http://www.w3.org/mid/AFB93528-A1CA-49EC-B342-5A8CD2B4080B⊙rc |
| 19:35 | Dashiva | checks |
| 19:35 | <smedero> | gregory rosmaita opened a few too. |
| 19:36 | <takkaria> | smedero: he opened them for RB |
| 19:36 | <smedero> | ahh, I see now |
| 19:37 | <takkaria> | hsivonen: oh, lord, I wonder if the tag and xhtml2 know what they're in for |
| 19:39 | <Dashiva> | "I, Robert - One man saw it coming." |
| 19:42 | <takkaria> | I find the summaries and proposals RB puts forward thoroughly confusing |
| 19:43 | <takkaria> | I'm never quite sure what he sets out to achieve because he never gives a real problem statement |
| 19:44 | <jgraham> | Please someone make it stop |
| 19:45 | <Philip`> | takkaria: The problems are that his proposed features are not supported |
| 19:46 | takkaria | grins |
| 19:47 | <Philip`> | They're nice problems since they have an easy obvious solution (i.e. supporting the proposed features) |
| 19:47 | <takkaria> | also, putting all these things on the wiki makes it very hard to discuss them |
| 19:49 | <Philip`> | At least the wiki pages do give problem statements |
| 19:53 | <Philip`> | Do Python profilers exist with timings per line/statement/etc rather than per method? |
| 20:19 | <takkaria> | the entry for ISSUE-49 on the wiki appears to contain parts of another proposal |
| 20:29 | <annevk> | damn, he hijacked ISSUE-42 |
| 20:32 | <gsnedders> | The answer to the first question in the physics exam last week was (I hope) 42. |
| 20:32 | <gsnedders> | Therefore, I now know the ultimate question! |
| 20:33 | <jmb> | is it any good? :) |
| 20:33 | <takkaria> | if it was on a physics paper, I doubt it |
| 20:33 | <gsnedders> | It's quite long |
| 20:34 | <gsnedders> | It's all about how far Q is from P, given a car breaking in the area to a complete rest with a given mass and initial speed, IIRC |
| 20:34 | <takkaria> | mm, I miss physics |
| 20:35 | <gsnedders> | I need to decide whether to do phys at uni |
| 20:36 | <Philip`> | Utilising the uncertainty principle, you could simultaneously do and also not do physics |
| 20:36 | <takkaria> | but only if gsnedders was in a quantum state and we weren't observing him :) |
| 20:36 | gsnedders | headdesks |
| 20:37 | <takkaria> | as soon as we observed him he'd have done one or the other |
| 20:37 | <Philip`> | As soon as we observe him, we just get entangled with him |
| 20:37 | <Philip`> | so it's only a problem if somebody then observes us |
| 20:38 | <takkaria> | I ended up doing philosophy |
| 20:38 | <takkaria> | don't do that |
| 20:38 | <Dashiva> | ISSUE-50 (associate-attributions-citations-quotations-and-references) |
| 20:38 | Dashiva | winces |
| 20:39 | Philip` | avoids thinking about it |
| 20:39 | <gsnedders> | takkaria: Don't worry, I wasn't planning on it |
| 20:41 | <Dashiva> | takkaria: You'd have to make him completely oblivious to himself as well, since he's macroscopic enough to be his own observer |
| 20:45 | Philip` | wonders if calling somebody "macroscopic" could be considered an insult |
| 20:51 | <takkaria> | hm, I'm going to reply to RB's use-cases for one of the issues |
| 20:51 | <takkaria> | let's see how this goes |
| 20:51 | <Philip`> | Uh oh |
| 20:57 | <annevk> | interesting, the TAG starts talking about solving real problems |
| 20:58 | <annevk> | that could be a slippery slope for them :D |
| 20:59 | <takkaria> | where? |
| 20:59 | takkaria | runs to look |
| 21:05 | <annevk> | http://www.pacificspirit.com/blog/2008/05/28/xri_solves_what_real_problems is one thing (linked from www-tag) |
| 21:13 | <takkaria> | well, that's sent. probably the worst decision I've ever made to reply to that, but there we go |
| 21:15 | <annevk> | you mean so far? |
| 21:15 | <Dashiva> | Your sacrifice will not be forgotten |
| 21:15 | <annevk> | :p |
| 21:16 | <annevk> | takkaria, btw, non-hierarchy use case is the bible iirc |
| 21:17 | <takkaria> | oh? |
| 21:17 | <Dashiva> | the reason why |
| 21:17 | <Dashiva> | they want to why they want to |
| 21:17 | <Dashiva> | Isn't the bible very hierarchical? |
| 21:17 | <takkaria> | I edit my own mail, did you know? |
| 21:17 | <takkaria> | I still think it's nuts to try and put non-hierarchical data in a hierarchical data format, regardless of use-cases |
| 21:18 | <takkaria> | it's like wanting to embed binary video data in an Atom feed |
| 21:18 | <annevk> | Dashiva, I remember being explained it overlapping things |
| 21:18 | <Dashiva> | I'd think hyperlinks would handle that |
| 21:18 | <annevk> | I haven't looked into a bible in a while |
| 21:21 | <smedero> | http://lists.w3.org/Archives/Public/public-html/2008May/0690.html |
| 21:22 | <smedero> | he's a busy man today |
| 21:23 | <annevk> | fortunately e-mail clients have filters |
| 21:24 | <annevk> | he prepared this stuff sometime in advance (see html4all archives) |
| 21:25 | <Dashiva> | What on earth is IDENT supposed to do? |
| 21:27 | <Dashiva> | It looks like class v2 |
| 21:27 | <takkaria> | will he stop bloody pretending that wikis are good places to propose things? |
| 21:28 | <Dashiva> | You should tell him so, if you feel strongly about it |
| 21:28 | <annevk> | Dashiva, I thought it would be some DTD thing, but I can't find it |
| 21:28 | <Dashiva> | The wiki page says it would only need to be unique within siblings |
| 21:28 | <takkaria> | Dashiva: I already have |
| 21:28 | <Dashiva> | So like some kind of local subtree id... but that removes the whole purpose of having a _unique_ value |
| 21:29 | <annevk> | Dashiva, seems best to not invest much time in this |
| 21:30 | <Dashiva> | Well, some time at least. Wouldn't want to dismiss him only because of precedent :) |
| 21:32 | <takkaria> | you say that, but... |
| 21:35 | <takkaria> | I can imagine that few people reply to any/most of his points and then he complains in six months time that the editor hasn't done what he said |
| 21:36 | <takkaria> | anyway, this isn't productive, bbl |
| 21:36 | <annevk> | that's ok, it's not possible to do what everyone wants it seems |
| 21:40 | <takkaria> | I lied about being back later |
| 21:40 | <takkaria> | the idea of providing a mechanism for describing the semantics of styling is amazing |
| 21:46 | <Dashiva> | Maybe there should be a dogfood requirement for proposals |
| 21:46 | <Dashiva> | E.g. if you want a new attribute, you have to use that attribute yourself for 6 months first |
| 21:57 | <Hixie> | woot, my VP is publicly pimping HTML5: http://www.techcrunch.com/2008/05/28/live-from-google-io/ |
| 21:58 | <Dashiva> | Hixie: I think RB means "page authors" when he says implementors |
| 21:58 | <Hixie> | well then he's misusing the word |
| 21:58 | <Dashiva> | Specifically "me" |
| 21:59 | <csarven> | Is there a way to mix multiple encodings in the same document? e.g., Document being UTF-8 and a component in ISO58859-1 |
| 21:59 | <Hixie> | i'm not ignoring rob burns |
| 21:59 | <Hixie> | heck i even have a special filter set up to prioritise his e-mails! |
| 21:59 | <Hixie> | it marks them AAA-Productivity! |
| 21:59 | <Hixie> | what more can he possibly want |
| 22:00 | <csarven> | *ISO8859-1 |
| 22:00 | <Dashiva> | I can't seem to find that folder in /issues/, Hixie :) |
| 22:01 | <Philip`> | csarven: There isn't |
| 22:01 | <Hixie> | it's a prioritisation level that happens before sorting feedback into feedback issue folders |
| 22:02 | <csarven> | Philip` Thanks |
| 22:02 | <Philip`> | csarven: Convert everything to UTF-8 on the server, and then the world will be happy :-) |
| 22:03 | <csarven> | That's almost the case but there is a 3rd party component which is in iso8859-1 :S |
| 22:03 | <Philip`> | Can't you add some kind of filter to translate that component's output? |
| 22:04 | <Dashiva> | What kind of component? iframe? json? |
| 22:04 | <csarven> | I probably could |
| 22:04 | <csarven> | Just an external JavaScript |
| 22:04 | <annevk> | Hixie, WHATWG was also pimped on the google blog |
| 22:04 | <annevk> | well, mentioned |
| 22:05 | <Hixie> | oh? |
| 22:05 | <Philip`> | csarven: As in <script src="some-iso-8859-1-file.js"></script>? |
| 22:05 | <Hixie> | oh today you mean |
| 22:05 | <csarven> | Yes |
| 22:05 | <Hixie> | yes |
| 22:06 | <annevk> | http://googleblog.blogspot.com/2008/05/happy-birthday-google-gears.html |
| 22:06 | <Hixie> | yeah |
| 22:06 | <Hixie> | that was today :-) |
| 22:06 | <Hixie> | part of the same push, i imagine |
| 22:06 | <Philip`> | csarven: I guess <script src="..." charset="iso-8859-1"></script> might work for that |
| 22:06 | <Hixie> | as in, part of the Google I/O stuff |
| 22:06 | <annevk> | i see |
| 22:07 | <csarven> | Philip` More like <script>document.write("<script>..)</script> |
| 22:07 | <annevk> | you there as well? |
| 22:07 | <Hixie> | nah |
| 22:07 | <annevk> | seems that Chris Wilson is around |
| 22:07 | <annevk> | (from twitter) |
| 22:07 | <Hixie> | Gears had several announcements today, though, and so it makes sense they'd mention HTML5 in that context |
| 22:07 | <Philip`> | csarven: Hmm, I'm not entirely certain what the problematic situation is |
| 22:11 | <csarven> | Philip` http://www.lebelage.ca/argent_et_droits/vos_droits/ -- Contest links, bottom right |
| 22:12 | gsnedders | is trying to write the exact kind of email he hates writing |
| 22:13 | <Hixie> | in the latest tag minutes tbl says ignoring rdf for html5 is unacceptable |
| 22:13 | <Hixie> | http://www.w3.org/mid/m2ej7mwhed.fsf⊙nc |
| 22:14 | Hixie | looks forward to saying that technologies have to prove themselves _before_ html5's design is warped to handle them |
| 22:14 | <Hixie> | aha, there's the google alert for the google blog mentioning whatwg :-) |
| 22:17 | <Philip`> | csarven: Ah - are you allowed to change it to <script>document.write("<script charset='iso-8859-1' ... ? |
| 22:17 | Philip` | doesn't actually have any idea whether browsers respect <script charset> |
| 22:18 | <Hixie> | they do |
| 22:19 | <Philip`> | Does it take precedence over Content-Type charset? |
| 22:20 | <roc> | hmm |
| 22:20 | <Hixie> | it does whatever the spec says, roughly |
| 22:20 | <Hixie> | though brosers differ in various complicated ways |
| 22:21 | gsnedders | wonders whether the HTTP of "HTTP/1.1" needs to be case-insensitive |
| 22:22 | <gsnedders> | In everything except CFNetwork (WebKit/OS X) and HTTP.sys (IIS) it is |
| 22:22 | <Philip`> | Ah, I missed the part of the spec where it said what to do with charset |
| 22:22 | <csarven> | Philip` Hixie Yes, it works! :) |
| 22:23 | <roc> | shepazu: you arond? |
| 22:23 | <Hixie> | gsnedders: is it really case insensitive? or is it ignored? |
| 22:24 | <gsnedders> | Hixie: case-insensitive |
| 22:24 | <csarven> | Although, I don't know how stable that is cross-browsres as Hixie says |
| 22:24 | <gsnedders> | Hixie: I think, from what I can see |
| 22:24 | <gsnedders> | Hixie: In Fx it is certainly |
| 22:25 | <annevk> | I thought you could also omit it |
| 22:25 | <gsnedders> | annevk: In what? Responses? Only if you're HTTP/0.9, which isn't used any more, so is irrelevant |
| 22:26 | gsnedders | discovers for compat. you can't use HTTP/5.0 :( |
| 22:27 | <annevk> | yeah, in the response |
| 22:27 | <Hixie> | ...and that's why version numbers are bad. :-) |
| 22:27 | <gsnedders> | HTTP/1.5 it'll have to be :P |
| 22:27 | <Philip`> | How about "HTTP/1.<backspace><backspace>5.0"? |
| 22:28 | <gsnedders> | Philip`: 400 Bad Request |
| 22:28 | <Philip`> | Hmph |
| 22:28 | gsnedders | wonders |
| 22:28 | <annevk> | do we need a new version number? |
| 22:29 | <annevk> | don't browsers have rules when you omit it altogether? |
| 22:29 | <gsnedders> | Should I keep non-strict parsers (which are meant to be used for responses) as close to RFC2616 as possible while still being useful in the real world, or just go for lax as hell? |
| 22:30 | <gsnedders> | annevk: In Fx at least if it doesn't start with "HTTP/" it is treated as HTTP/0.9 |
| 22:30 | <gsnedders> | annevk: Which is to say that the entire response is the body |
| 22:30 | <annevk> | gsnedders, what does "lax as hell" mean? compatible with the real world? |
| 22:31 | <annevk> | gsnedders, I see, so we need HTTP/ as a flag at the start to indicate headers are part of the response? |
| 22:31 | <gsnedders> | annevk: It doesn't throw any sort of error, even when the real world doesn't rely on it, and it isn't allowed as part of RFC2616 |
| 22:32 | <gsnedders> | annevk: Currently if you send something really odd to a non-strict parser you can get a fatal error (it really has to be really mucked up to get that to happen, though) |
| 22:32 | <annevk> | gsnedders, does that happen with browsers? |
| 22:33 | <gsnedders> | annevk: In some, yes |
| 22:33 | <annevk> | if it has to be something really odd you might as well never get a fatal error... |
| 22:34 | gsnedders | wonders what causes it currently |
| 22:36 | <gsnedders> | It's far easier to cause when you're dealing with a request and a strict parser. |
| 22:37 | <gsnedders> | annevk: Basically the response line needs to be invalid at the start (i.e., the "HTTP/1.1 200" part) |
| 22:38 | <gsnedders> | annevk: Or if it doesn't have a blank line before the body |
| 22:38 | <gsnedders> | annevk: I think that's all that currently causes a fatal error in a non-strict response parser |
| 22:39 | <annevk> | wow, http://www.builderau.com.au/program/html/soa/HTML-5-A-change-in-course-straight-for-the-iceberg/0,339028420,339289373,00.htm?feed=rss is quite confused |
| 22:40 | <takkaria> | we need a crack PR team to get blog posts like that sorted out |
| 22:43 | <Hixie> | annevk: that's old |
| 22:44 | <Hixie> | annevk: came out in january |
| 22:44 | <Hixie> | i do like the bit that says that html5 is a 15 year step backwards |
| 22:44 | <Hixie> | that basically puts the web back at where it started |
| 22:44 | <Hixie> | which would be impressive |
| 22:44 | <gsnedders> | and HTTP/0.9! |
| 22:44 | <gsnedders> | I mean, that didn't even have headers, or status codes :P |
| 22:44 | <annevk> | Hixie, maybe they republished some content |
| 22:45 | <Hixie> | yeah |
| 22:56 | <roc> | finally! http://ajaxian.com/archives/announcing-ajax-libraries-api-speed-up-your-ajax-apps-with-googles-infrastructure |
| 23:01 | <Philip`> | The internet is hard because all the functionality and data is distributed and distributed systems are hard, so it's good that Google is aiming to save us by providing a single centralised source for all services and data |
| 23:01 | <roc> | yes it is |
| 23:01 | <Philip`> | We won't need internet connections at all, we can just have a Google connection |
| 23:03 | <Philip`> | Single points of failure that can break vast swathes of the web are always good too |
| 23:03 | <roc> | yeah. http://webaccelerator.google.com/ |
| 23:04 | <annevk> | that product is nice, it exposes incorrect usage of GET |
| 23:05 | Philip` | wonders how the hosting of ajax.googleapis.com compares to e.g. Akamai |
| 23:06 | <roc> | perhaps comparable service levels, but AFAIK random people can't use Akamai for free |
| 23:07 | <roc> | actually, at least early on, random people *could* Akamize their URLs, because the sales staff were selling service faster than they could whitelist referrers, so they'd just track down heavy unauthorized usage after the fact. Not sure if that's changed |
| 23:10 | <Philip`> | Hmm, Akamai seems to be directly peered to all the ISPs I can test, and ajax.googleapis.com looks like it is too (except with four more hops and no reverse DNS) |
| 23:12 | <annevk> | http://six03.com/blog/html5/ |
| 23:19 | Hixie | looks at notifications APIs |
| 23:24 | <Hixie> | http://www.whatwg.org/specs/web-apps/current-work/notes |
| 23:25 | <Philip`> | OS notifications apply to windows, which seems pretty useless when the notifier is probably in a non-visible tab in that window |
| 23:27 | <othermaciej> | one interesting form of notification you are missing is badging the dock icon |
| 23:27 | <Hixie> | good point |
| 23:27 | <othermaciej> | on mac |
| 23:27 | <Hixie> | though that wouldn't make much sense if you have shared tabs |
| 23:27 | <othermaciej> | it is common to badge with unread counts |
| 23:28 | <othermaciej> | but it might make sense in a window-per-app model like Fluid |
| 23:28 | <othermaciej> | I'm not sure how you would reconcile it with use in a general browser (probably not allow it, or maybe badge the tab instead) |
| 23:28 | <Hixie> | yeah |
| 23:29 | <roc> | I don't think Fluid or Prism actually restrict the app to one window, so they'd probably need to implement something flexible |
| 23:29 | <roc> | or provide a configuration option |
| 23:30 | <othermaciej> | I believe Fluid has some form of dock icon badging |
| 23:30 | <Philip`> | Presumably notifications are useful only for web apps which the user uses a lot, not for random web pages, so would it be reasonable to require it to be opt-in per site? (preferably with the site offering the option to the user, then calling some script function which makes the browser non-modally ask the user for confirmation, or whatever) |
| 23:31 | <roc> | the browser could show the notification in the tab, with some UI that lets it move out to the dock or taskbar or whatever |
| 23:31 | <othermaciej> | it would be annoying to let a random tab bounce the browser dock icon |
| 23:31 | Philip` | doesn't fancy ads making any part of his browser UI start bouncing and flashing |
| 23:31 | <Hixie> | the proposal i wrote up in that file suggests that the notifications would only appear inside the window until the user clicked a button on a notification to opt that origin into being able to send them system-wide |
| 23:31 | <roc> | yeah, that sounds good |
| 23:32 | <Hixie> | not sure what to do about bouncing the dock icon, i think maybe we should not provide that separately and just make the notifications bounce the icon if that origin is opted in to the side-wide thing |
| 23:32 | <Hixie> | it seems bad form to ask for the user's attention without saying why anyway |
| 23:32 | <Philip`> | That doesn't sound good since I have one browser window and dozens of tabs, and I don't want all of them to be able to distract me when I'm working on something totally unrelated in a different tab |
| 23:33 | <Hixie> | s/window/tab/ |
| 23:33 | <Philip`> | (even if it's in the same window) |
| 23:33 | <Philip`> | Ah, okay |
| 23:36 | <Hixie> | gears' version of this has displayAtTime, displayUntilTime, and addAction() APIs |
| 23:37 | <Hixie> | i wonder what the use case for those was |
| 23:37 | Hixie | shall have to contact them |
| 23:37 | <Philip`> | Do those get scheduled and displayed even if you've navigated away from the page that added them? |
| 23:38 | <Philip`> | (e.g. you could visit your calendar page once, and it'd remind you of all events for the rest of the day) |
| 23:38 | <Philip`> | (at least until your browser crashed and restarted and then you forgot to revisit the calendar to reset the scheduled notifications and missed your appointments) |
| 23:38 | <roc> | that wouldn't be a great approach |
| 23:38 | <roc> | meetings could change online and you'd get stale data |
| 23:39 | <annevk> | what was the whatwg.org link again for the expected timeline? |
| 23:40 | <Philip`> | annevk: http://www.whatwg.org/specs/web-apps/current-work/TIMETABLE ? |
| 23:40 | <annevk> | ah |
| 23:40 | <annevk> | I was trying current-work/timeline |
| 23:40 | <annevk> | and also TIMELINE |
| 23:40 | <annevk> | but not table |
| 23:41 | <Philip`> | I tried Google instead :-) |
