| 02:09 | <Hixie> | http://lists.w3.org/Archives/Member/w3c-ac-members/2007JulSep/0060.html |
| 02:09 | <Hixie> | someone should probably tell them about <video> |
| 02:27 | <doublec> | Hixie: definitely |
| 04:06 | <Hixie> | aa: yt? |
| 04:06 | <Hixie> | crap, i need othermaciej |
| 05:44 | <Hixie> | grr |
| 05:44 | Hixie | runs into all sorts of edge cases with the offline storage stuff |
| 06:16 | <Hixie> | "I'll try to find another way to get an update on design principles draft |
| 06:16 | <Hixie> | status, spec review, issue tracking, and such." |
| 06:17 | Hixie | doesn't understand what DanC needs that he doesn't get from reading e-mail |
| 08:35 | <Lachy> | I wonder why the W3C set up member-video instead of public-video |
| 08:38 | <Lachy> | it would probably be a good idea to get some HTMLWG representatives involved in that work |
| 08:47 | <Hixie> | the summary="" attribute video is interesting |
| 08:48 | <Hixie> | he makes a comment about how he has hit so many sites that use it incorrectly that he just doesn't use it anymore |
| 08:49 | <Hixie> | (stuart does, that is) |
| 11:28 | Hixie | mails his latest offline proposal to the list |
| 11:28 | Hixie | goes to sleep |
| 11:29 | <zcorpan> | nn Hixie |
| 11:39 | <hsivonen> | interesting. I'm seeing a bogus YSoD in Gecko on Maemo but not on desktop |
| 11:41 | <zcorpan> | hsivonen: for what page? |
| 11:44 | <hsivonen> | zcorpan: http://planet.intertwingly.net/ |
| 11:45 | <hsivonen> | it is even possible that it is my fault (fallout from bug 18333 but fixed on trunk) |
| 13:46 | <hsivonen> | Does IE6 support .foo.bar combined class selectors? what about IE7? |
| 13:52 | <gsnedders> | hsivonen: IE7 does. IIRC IE6 doesn't |
| 13:54 | <hsivonen> | gsnedders: thanks |
| 13:55 | <hsivonen> | any opinions whether I should flatten my microformat(ish) class names from class='error fatal' and class='error' to class='error-fatal' and class='error'? |
| 13:56 | <hsivonen> | and same on the JSON side |
| 13:56 | <Lachy> | IE6's handling of chained selectors is that it ignores all but the last one. so .foo.bar would match class="foo bar" and class="bar", but not class="foo" |
| 13:56 | <hsivonen> | hmm. in that case I might just about get away with using two class names |
| 13:57 | <Lachy> | yes, if you're careful and put the most important one at the end. So use .error.fatal rather than .fatal.error |
| 13:59 | <Lachy> | though you could just use .fatal by itself since it will be slightly more efficient than .error.fatal |
| 14:00 | <hsivonen> | Lachy: ok. what's your take on putting "type":"error fatal" in JSON and giving semantics to splitting the type on space as opposed to having two fields? |
| 14:01 | hsivonen | still hasn't found a JSON design pattern guide |
| 14:02 | <Lachy> | or you could do "type":["error", "fatal"]. It depends on how you expect authors to make use of the values. |
| 14:03 | <Lachy> | do you expect authors to be able to use the value as-is in a class name, for example? If so, then it would make sense to use a space separated list |
| 14:03 | <Lachy> | But if you expect that authors will want easier access to the individual values, then the array might be better. |
| 14:04 | <hsivonen> | Lachy: I expect most client developers to merely test the string for identity and I expect angel developers to write proper fallback code when the string doesn't match |
| 14:07 | <Lachy> | oh, I see, you're attempting to combine the type and subtype properties into one value |
| 14:11 | <zcorpan> | hsivonen: class="error fatal" seems more useful since you won't use "fatal" for other than errors, and you might want to have common styles for all errors |
| 14:12 | <zcorpan> | so style rules like .error {...} .fatal {...} works fine (also in ie6) |
| 14:13 | <Lachy> | hsivonen, have you seen http://ajaxpatterns.org/Patterns |
| 14:14 | <Lachy> | http://ajaxpatterns.org/JSON_Message |
| 14:30 | <hsivonen> | zcorpan: ok. |
| 14:30 | <hsivonen> | Lachy: I think I haven't read those. thanks |
| 14:33 | <hsivonen> | Lachy: actually, that is one of the pages that presents the use of JSON as an Ajax pattern instead of telling about patterns for designing JSON formats themeselves |
| 14:34 | <Lachy> | ok |
| 14:34 | <Lachy> | well, it was the first search result for "JSON Design Patterns", I didn't read it thoroughly myself |
| 14:34 | <hsivonen> | perhaps JSON is so new that there aren't solid patterns yet |
| 14:35 | <hsivonen> | yeah, I googled for that already |
| 14:50 | <aaronlev> | hsivonen: i only see one reply to the ARIA thread |
| 14:50 | <aaronlev> | but it is an affirmative in the end |
| 14:51 | <aaronlev> | is there a weekly call where people discuss stuff like that? |
| 14:51 | <hsivonen> | aaronlev: I think that's a good sign |
| 14:51 | <aaronlev> | ok |
| 14:51 | <hsivonen> | aaronlev: there's an almost weekly telecon but it is canceled this week |
| 14:51 | <hsivonen> | aaronlev: and the telecon attendance doesn't reflect the mailing list |
| 14:52 | <aaronlev> | ok |
| 14:54 | <hsivonen> | aaronlev: we tried to get rid of "+1" messages, so plain agreement doesn't show |
| 14:55 | <aaronlev> | ah |
| 14:55 | <aaronlev> | yeah because the list is too busy |
| 14:55 | <aaronlev> | to keep up with otherwise |
| 15:41 | <hsivonen> | http://wiki.whatwg.org/wiki/Validator.nu_GNU_Output |
| 15:41 | <hsivonen> | if anyone knows how to solve the issues, please chime in on the wiki. thanks |
| 15:41 | <hsivonen> | MikeSmith: ^ |
| 15:48 | <Lachy> | zcorpan, in your email about ARIA, did you really mean that dojo is using http://www.w3.org/TR/xhtml2 as the namespace URI, or are they using the namespace URI defined in that spec, http://www.w3.org/2002/06/xhtml2/ ? |
| 15:48 | <Philip`> | Mozilla uses both html:role and xhtml2:role in its XUL code |
| 15:49 | <zcorpan> | Lachy: the former |
| 15:49 | <Philip`> | (where xmlns:html="http://www.w3.org/1999/xhtml"; and xmlns:xhtml2="http://www.w3.org/TR/xhtml2";) |
| 15:49 | <zcorpan> | Philip`: ouch |
| 15:49 | <hsivonen> | yay, legacy! |
| 15:50 | zcorpan | was hoping that html:role wouldn't be implemented or used |
| 15:50 | <Lachy> | aargh! I despise dojo even more now |
| 15:50 | Lachy | wonders why would anyone use a spec URI as a namespace URI??? |
| 15:51 | <gavin> | Philip`: that looks like a bug |
| 15:51 | <Lachy> | and it confirms that aria is a real mess :-( |
| 15:51 | hsivonen | reminds Lachy of the ancient practice of using the uri of the HTML 4 spec as the XHTML 1 namespace URI |
| 15:52 | <hsivonen> | Lachy: more to the point, it confirms that namespaces are a mess |
| 15:52 | <Lachy> | I don't recall that ever happening |
| 15:52 | <Lachy> | but yes, they're a mess too |
| 15:52 | <hsivonen> | Lachy: local names overlive organizational URI choices |
| 15:52 | <hsivonen> | Lachy: oh, it happened |
| 15:53 | <hsivonen> | Lachy: Gecko had the HTML 4 URI built in early on |
| 15:53 | <hsivonen> | Lachy: and MS tools might still emit it somewhere |
| 15:53 | <Lachy> | does it still support it? |
| 15:53 | <zcorpan> | Lachy: http://www.w3.org/TR/1999/REC-xml-names-19990114/ search for "html40" |
| 15:53 | <hsivonen> | Lachy: no |
| 15:53 | <hsivonen> | IIRC |
| 15:54 | <Philip`> | From the Mozilla code, it looks like they accept non-namespaced role attribute starting with 'wairole:' in text/html, or namespaced role attribute in the XHTML or unofficial-XHTML2 namespaces with more complex prefixing rules |
| 15:54 | <zcorpan> | hmm, opera supports the http://www.w3.org/TR/REC-html40 namespace |
| 15:55 | <hsivonen> | some of the classes in validator.nu have survived three package name changes... |
| 15:55 | <Philip`> | I found some of those REC-html40 namespaced pages a while ago, since they broke hsivonen's parser |
| 15:55 | <hsivonen> | domain name-based Java package names have the same problems as XML namespaces |
| 15:55 | <hsivonen> | code outlives organizational stewardship |
| 15:55 | <Philip`> | It looked a lot like some version of Word was emitting them |
| 15:56 | <Lachy> | hsivonen, what would you recommend for a namespace identifier other than a URI or the java like syntax? |
| 15:57 | <hsivonen> | Lachy: the well-known name of the language |
| 15:57 | <Philip`> | A UUID |
| 15:57 | <hsivonen> | Lachy: e.g. xml, atom, aria, xbl, svg |
| 15:58 | <Lachy> | makes sense. |
| 15:58 | <hsivonen> | Lachy: where those who pick the name are informed of what's already out there |
| 15:58 | <Lachy> | though the (possibly theoretical) problem that the URI solves is what happens when 2 languages share the same name? |
| 15:58 | <hsivonen> | Lachy: like if you are inventing a new binary format, you should probably consult file(1) for taken magic numbers |
| 15:59 | <Philip`> | What about people developing private technologies that are not out there and that need to interact with other private technologies that are not out there? |
| 15:59 | <hsivonen> | Lachy: somehow, magic numbers have worked fine most of the time (since the seventies?) |
| 15:59 | <Lachy> | yeah, I suppose magic numbers work reasonably well for binary formates |
| 15:59 | <hsivonen> | Philip`: I though this was about Web formats ;-) |
| 16:00 | <hsivonen> | anyway, baking in the name of a private company sucks |
| 16:00 | <hsivonen> | when you try to advance the tech to IEFT, OASIS or the W3C |
| 16:00 | <hsivonen> | or, worse, first advance to OASIS and then to ISO |
| 16:01 | <Philip`> | I guess the idea with XHTML is that web formats benefit from sharing tools and ideas with what's widely used outside the web, hence universally-unique namespaces and stuff |
| 16:01 | hsivonen | waves to the ECMA team who has to deal with ISO comments on having microsoft.com namespaces in OOXML |
| 16:04 | hsivonen | points out that the old Mac OS did fine with 4-letter type codes for a couple of decades |
| 16:05 | <Philip`> | http://lxr.mozilla.org/seamonkey/source/toolkit/components/feeds/src/FeedProcessor.js#1495 - "// Thanks for QNames in content, W3C // This will even be a perf hit for every single feed" - they don't sound too happy |
| 16:05 | <Lachy> | yeah, well, it seems far too late to fix namespaces now. |
| 16:06 | <Philip`> | http://www.w3.org/WAI/PF/GUI/roleTaxonomy-20060508.html - hmm, a .bmp image? That doesn't seem very standard |
| 16:10 | <hsivonen> | Lachy: it isn't too late to oppose to qNames in content, though, whenever someone suggests that something new should use that anti-pattern |
| 16:10 | <Lachy> | hsivonen, of course, qnames in content should be banned |
| 16:10 | hsivonen | once interviewed for a job that involved an XML language that had stuff that looked like qNames in content but wasn't |
| 16:14 | zcorpan | points out that xbl2 has qnames in content |
| 16:14 | <zcorpan> | effectively |
| 16:14 | <Lachy> | for selectors, yeah |
| 16:15 | <Lachy> | but that's ok because it's just using xmlns as the namespace declaration mechanism, instead of @namespace or something new |
| 16:16 | <Lachy> | XSLT does a similar thing e.g. <template match="x:p"> where xmlns:x="..." is defined somewhere |
| 16:17 | <zcorpan> | yeah |
| 16:17 | <Lachy> | so I guess they're acceptable uses of qname-like features in content |
| 16:18 | zcorpan | heads over to get some friday beer |
| 16:18 | <Lachy> | CURIE's, on the other hand, are not acceptable uses. |
| 17:34 | <aaronlev> | hsivonen: still there? |
| 18:01 | <annevk> | aaronlev, hey, it seems that the standards are not really helping here :( |
| 18:02 | <annevk> | this role= stuff is getting pretty insane just to please some WG members |
| 18:02 | <aaronlev> | annevk: just the fact that it accepts qnames? |
| 18:02 | <hsivonen> | aaronlev: I'm back now |
| 18:02 | <aaronlev> | annevk: my point is we can deprecate that later, it's not as urgent |
| 18:02 | <aaronlev> | we can open a discussion on it |
| 18:02 | <aaronlev> | it's just hard to do everything at once, right? |
| 18:03 | <aaronlev> | we've gotten pretty far since last year when html 5 was just for outsiders |
| 18:03 | <annevk> | aaronlev, well, not only that, but also role= in some weird XHTML2 namespace |
| 18:03 | <annevk> | yeah, I regret not having paid more attention to it now |
| 18:03 | <aaronlev> | annevk: i see an acceptance that the w3c is moving to html 5 |
| 18:03 | <aaronlev> | it just takes time for everyone to "Get it" |
| 18:04 | <aaronlev> | plus i think html folks need to figure out a strategy for svg |
| 18:04 | <aaronlev> | or is *Everything* supposed to be html |
| 18:04 | <annevk> | the main problem I have with "deprecate" is that it's not entirely clear to me how it affects the Firefox code base (and that of other browsers) |
| 18:04 | <annevk> | (if it's not actually going to be removed it might only increase as such to issue warnings etc. to developers which doesn't seem very helpful) |
| 18:05 | <hsivonen> | I don't really believe that we can ever deprecate anything in a way that would actually allow UAs to drop stuff |
| 18:05 | <aaronlev> | annevk: i don't see it as an issue because almost everyone is going to be using this in html |
| 18:05 | <aaronlev> | they can't use the namespaces anyway |
| 18:05 | <annevk> | well, it still needs to be tested and implemented correctly |
| 18:06 | <annevk> | if there was no cost attached it would be fine, but the number of possible combinations you can have right now is huge |
| 18:06 | <annevk> | which makes interoperability a lot harder |
| 18:06 | <hsivonen> | Lachy: what makes qNames in content semi-bearable in XSLT is that you are assumed to compile a stream of SAX events into a representation of a transformation |
| 18:06 | <hsivonen> | Lachy: you aren't supposed to do live DOM modifications |
| 18:07 | <annevk> | as for SVG, I'm not sure why people would want to write applications directly in that format; seems like transferring a bunch of <font> elements over the wire |
| 18:07 | <hsivonen> | Lachy: but it seems that imitating XSLT is what gave us qNames in content elsewhere |
| 18:07 | <annevk> | then again, this may be what people want |
| 18:07 | <annevk> | ... |
| 18:08 | <aaronlev> | annevk: then why does opera have such good svg support? :) |
| 18:08 | <hsivonen> | and qNames in content as such would not be quite as bad if the DOM captured the namespace mapping scope on a per-Element basis at node creation time and had methods for getting qName values as ns,local pairs |
| 18:09 | <hsivonen> | aaronlev: my vision regarding SVG is that we should extend the HTML5 parsing algorithm to do the right namespace magic for subtrees rooted at <svg> (and <math>) |
| 18:10 | <hsivonen> | aaronlev: (though SVG is harder than MathML due to camelCaps and xlink:href) |
| 18:11 | <aaronlev> | hsivonen: i guess, i find that to get rid of qnames, the larger political issue is in my way |
| 18:11 | <aaronlev> | i've had to straddle the 2 worlds for a while |
| 18:12 | <aaronlev> | i feel people are coming around to the html 5 wg |
| 18:12 | <aaronlev> | but are scared of the size and don't know how to deal wit hthat |
| 18:12 | <hsivonen> | aaronlev: yeah, I realize that. I'm just noting that I don't really believe deprecation later solves anything. |
| 18:12 | <aaronlev> | and i think they still hang on to belief in namespaces |
| 18:12 | <aaronlev> | hsivonen: no one is going to want to use namespaces if they don't have to anyway |
| 18:12 | <hsivonen> | aaronlev: Gecko and others will still have to support content that gets authored to Gecko as of Firefox 3 |
| 18:12 | <aaronlev> | yeah but it's not expensive to support qnames for roles |
| 18:13 | <aaronlev> | it doesn't hurt us |
| 18:13 | <aaronlev> | i'm just prioritizing the fixes that i have to squeeze in before ff3 release first |
| 18:13 | <aaronlev> | if i get those in and can breathe again |
| 18:13 | <aaronlev> | then we can tackle this qname issue, but it brings up a lot o other issues people have |
| 18:13 | <aaronlev> | and old divisions |
| 18:13 | <hsivonen> | sure, I'm not suggesting unsupporting qNames at this point. I just don't believe you'll be able to unsupport them ever |
| 18:14 | <aaronlev> | oh ok, i think ff will proably still support them but the docs can say it's not the preferred way |
| 18:14 | <annevk> | that doesn't help anybody I'm afraid :( |
| 18:14 | <aaronlev> | annevk: it helps a lot -- authors don'[t have to use them |
| 18:14 | <aaronlev> | it's not expensive code at all, a couple of lines really |
| 18:14 | <aaronlev> | so what's the big deal |
| 18:15 | <aaronlev> | i mean it's not expensive in the user agent to allow the qname role values |
| 18:15 | <annevk> | sorry, I agree that it helps to simplify things |
| 18:15 | <annevk> | I don't agree that it helps to deprecate things but don't actually change the code as well |
| 18:16 | <aaronlev> | annevk: if you can get chaals to advocate for it, soon, in pf |
| 18:16 | <aaronlev> | but we have to open up a huge discussion then |
| 18:16 | <aaronlev> | and i reallyu don't believe pf wants that right now, we're on the march to get aria 1.0 out the door |
| 18:16 | <hsivonen> | If we get to the point of tackling SVG and MathML in text/html, we should probably introduce namespaceless aria-foo attributes on SVG and MathML elements at that point |
| 18:17 | <aaronlev> | hsivonen: good point |
| 18:17 | <aaronlev> | i haven't thought of a use case for aira in mathml |
| 18:17 | <aaronlev> | but i haven't thought that hard |
| 18:17 | <aaronlev> | interactive math of some kind |
| 18:19 | <aaronlev> | annevk: some folks in pf are still trying to hold on to the idea of using rdf to define roles |
| 18:19 | <aaronlev> | that authors could define new ones that way |
| 18:19 | <annevk> | right... |
| 18:19 | <aaronlev> | i wrote about it in the faq |
| 18:19 | <aaronlev> | the qname points to the role definition on the web |
| 18:20 | <aaronlev> | but everyone agrees this is aria 2.0 or whatever |
| 18:20 | <annevk> | you'd think the accessibility folks realize that authors don't get complex stuff (see longdesc)... but then they go ahead and use RDF! |
| 18:20 | <hsivonen> | afk |
| 18:20 | <aaronlev> | some of the a11y folks involved in standards love that kind of crap |
| 18:21 | <aaronlev> | it does have 1 gigantic advantage over xbl |
| 18:21 | <annevk> | yeah, but that doesn't make it practical :( |
| 18:21 | <aaronlev> | i'm not arguing for it |
| 18:21 | <aaronlev> | the chances of all browser manufacturers having XBL support is like, zero |
| 18:22 | <aaronlev> | the big content developers do what some kind of capability like this |
| 18:22 | <annevk> | I'm not sure why the chances are different from them supporting something else |
| 18:22 | <aaronlev> | let's just take IE as an example, not sure why i would do that |
| 18:23 | <aaronlev> | if they don't support ARIA, it doesn't kill ARIA usage --because the pages don't render any differently in IE |
| 18:23 | <aaronlev> | so users that need it to be accessible use firefox or opera instead |
| 18:23 | <aaronlev> | same with the custom roles |
| 18:23 | <aaronlev> | if IE doesn't support it, no big deal, there's another free browser that does |
| 18:23 | <aaronlev> | but with XBL it's different |
| 18:23 | <aaronlev> | you're defining your whole widget in XBL, which is cool |
| 18:23 | <aaronlev> | but the page simply won't work in IE at all |
| 18:23 | <aaronlev> | therefore no one will use it |
| 18:24 | <annevk> | that's not really how XBL is designed, but I see your point |
| 18:24 | <aaronlev> | what do you mean? |
| 18:24 | <annevk> | XBL is an optional language |
| 18:24 | <aaronlev> | unless it's a lot different from how XBL works in mozila |
| 18:24 | <annevk> | like CSS |
| 18:24 | <annevk> | XBL2 anyway |
| 18:25 | <aaronlev> | what good is it as an option, if the widgets i designed in it will only work in a couple borwsers |
| 18:25 | <aaronlev> | with Javascript my widgets even work in IE |
| 18:25 | <annevk> | XBL is implemented in JS at least partially |
| 18:25 | <annevk> | I'm sure people will make that work in IE in some way as well |
| 18:25 | <aaronlev> | yes but IE won't go fetch the JS definition |
| 18:26 | <aaronlev> | annevk: if that's the case, then XBL would be by far the best solution |
| 18:26 | <annevk> | the page will just point to it, similar to how <canvas> works in IE today |
| 18:26 | <aaronlev> | it works in ie? |
| 18:28 | <annevk> | http://code.google.com/p/explorercanvas/ |
| 18:29 | <Philip`> | http://philip.html5.org/tests/canvas/suite/tests/results.html - it only works correctly in fairly trivial cases |
| 18:30 | <aaronlev> | wow |
| 18:30 | <aaronlev> | i wish i had time to read how that works |
| 18:30 | <annevk> | Web Forms 2 has also been made to work in IE |
| 18:31 | <annevk> | most of HTML5 can be implemented in IE in one way or another, although not always optimally of course and it would be far better if they started doing some stuff |
| 18:31 | <Philip`> | ExplorerCanvas mostly works by building up VML strings, which IE can render |
| 18:31 | <aaronlev> | Philip`: ah |
| 18:32 | <aaronlev> | i can't find any canvas example in there that does curvy lines or something |
| 18:32 | <aaronlev> | annevk: that's the part that scares me |
| 18:32 | <aaronlev> | i've never seen one of these middleman IE things get used widely |
| 18:33 | <aaronlev> | i mean, it needs to be something that companies like Yahoo and IBM are willing to base their stuff on |
| 18:33 | <aaronlev> | i order for it to relevant to the accessible extended widgets discussion |
| 18:33 | <Philip`> | http://canvex.lazyilluminati.com/misc/curve.html has curvy lines and I think it works in IE |
| 18:34 | <annevk> | aaronlev, Y! has used that plugin actually on Y! Pipes |
| 18:35 | <annevk> | or, they're using <canvas> on Y! Pipes, not sure what they do with IE |
| 18:35 | <aaronlev> | annevk: you know what i mean |
| 18:35 | <aaronlev> | large scale stuff tends not to want to use these things |
| 18:35 | <aaronlev> | it's never quite good enough for some reason or another |
| 18:35 | <aaronlev> | i suspect XBL in IE would be the same |
| 18:35 | <hsivonen> | annevk: if XBL becomes successful, it'll be "optional" to entering into the market the same way CSS was "optional" for Apple |
| 18:36 | <annevk> | aaronlev, http://pipes.yahoo.com/pipes/pipe.info?_id=gOkiTeFS3BGRTwZy8ivLAg uses excanvas for instance |
| 18:38 | <aaronlev> | annevk: i'm skeptical any big org wil change their strategy based on an exXBL library |
| 18:38 | <aaronlev> | but i could be proven wrong |
| 18:38 | <aaronlev> | i just don't see google using it in something like google office |
| 18:39 | <aaronlev> | that kind of thing, where you have tons of widgets |
| 18:39 | <aaronlev> | and it all is already brittle enough |
| 18:39 | <aaronlev> | that's where you need the custom widgets to be accessible |
| 18:41 | <annevk> | if you see the amount of code Joel Spolsky is talking about a simple wrapper for XBL would not be too much code :) |
| 18:42 | <annevk> | anyway, I agree it's a problem if a browser with a lot of market share stops implementing, hopefully that doesn't happen |
| 18:43 | <aaronlev> | annevk: when have they started implementing? |
| 18:43 | <aaronlev> | we can't rely on anything being implemented, because it 90% won't be |
| 18:45 | <aaronlev> | XBL heaven is proably not going happen, i'm sorry, because i would love it to happen |
| 18:47 | <annevk> | you're saying the web will just stay like it is now for the coming 20 years? |
| 18:47 | <annevk> | (in terms of stuff you can use) |
| 18:47 | annevk | doesn't really believe in that |
| 18:48 | <aaronlev> | annevk: who cares abouit 20 years from now? |
| 18:49 | <annevk> | I do |
| 18:49 | <annevk> | HTML5 is not exactly short term stuff |
| 18:50 | <aaronlev> | ok |
| 18:51 | <aaronlev> | well, web 2.0 or whatever people want to call it is already underway |
| 18:51 | <aaronlev> | so, yes, ideally i would love xbl to help out with a11y |
| 18:51 | <aaronlev> | but lots of standards have come and gone |
| 18:51 | <aaronlev> | don't get me wrong, i'm the biggest xbl proponent in pf |
| 18:51 | <hsivonen> | XBL needs a killer app that is so cool it can bootstrap business even if only two of top four browser work with it |
| 18:52 | <aaronlev> | i love using it -- i've done a lot of work with it in mozilla |
| 18:52 | <hsivonen> | kinda like Google Maps made Opera and Apple implement XHR |
| 18:52 | <aaronlev> | right, but who is going to bootrtrap their business with a technology that cuts out most of their markeshare |
| 18:52 | <aaronlev> | cutting out opera and apple is one thing |
| 18:53 | <aaronlev> | but cutting out ie, uh, no new business does that |
| 18:54 | <annevk> | to early to tell whether or not IE will implement |
| 18:55 | <annevk> | (and there's the aforementioned library solution) |
| 18:55 | <hsivonen> | I think it isn't quite that bleak. Just like Macs are the "top 6%" (or whatever the figure was) and that's enough for some desktop apps, hopefully for the XBL killer app, Firefox, Safari and Opera are the top 20% |
| 18:57 | annevk | wonders if Julian Reschke on public-webapi uses the tactic that if you keep saying it enough times it will become true :) |
| 18:58 | <aaronlev> | but xbl can't do anything that you cant' do with dojo |
| 18:59 | <aaronlev> | or plain javascript or some other js toolkit |
| 19:00 | <aaronlev> | annevk: well if it is too early to tell if they will implement it, that means you can't rely on it for a strategy now if you need something now |
| 19:00 | <annevk> | hmm, html4all is discussing whether my blog is valid and whether I care about standards... fun |
| 19:00 | <aaronlev> | maybe we can convince everyone they don't need extended widgets yet, and that it's worth waiting to see |
| 19:00 | <aaronlev> | but i think they'll be waiting for a long time |
| 19:00 | <aaronlev> | fun |
| 19:01 | <annevk> | short term there's nothing you can really rely on |
| 19:01 | <aaronlev> | yes there is |
| 19:01 | <aaronlev> | javascript |
| 19:01 | <annevk> | not if you want it to be accessible too |
| 19:01 | <aaronlev> | javacsript +aria |
| 19:01 | <annevk> | hmm |
| 19:01 | <aaronlev> | or dojo |
| 19:03 | <annevk> | html4all people, hi!, my page has 4 errors because it uses Web Forms 2 features that supposedly improve usability in browsers that support said features |
| 19:03 | <annevk> | html4all people, at some point I'll change the doctype to <!doctype html>, but it doesn't really matter much |
| 19:04 | <annevk> | actually, I'll change the doctype of that page |
| 19:05 | <aaronlev> | hsivonen: xbl would have to provide some new functionality you can't get already with dojo |
| 19:05 | <aaronlev> | in order to make up for the huge market share of non-xbl browsers, otherwise no killer app will happen |
| 19:06 | <aaronlev> | sorry, i don't mean to be pedantic |
| 19:07 | <aaronlev> | does html 5 have anything like cc/pp? |
| 19:07 | <aaronlev> | if you want to communicate client capabilities better |
| 19:08 | <hsivonen> | aaronlev: true. |
| 19:09 | <hsivonen> | aaronlev: capability sniffing that is based on the UA stating its own capabilities is considered doomed |
| 19:09 | <annevk> | hsivonen, heh, changing the doctype doesn't help much: http://validator.nu/?doc=http%3A%2F%2Fannevankesteren.nl%2F2007%2F09%2Falt |
| 19:10 | <aaronlev> | hsivonen: why? |
| 19:10 | <aaronlev> | hsivonen: is there a good article? |
| 19:10 | <hsivonen> | aaronlev: there's a risk of accidental errors as well as an incentive to lie |
| 19:10 | <annevk> | (those are all bugs in the validator as far as I can tell) |
| 19:10 | <aaronlev> | so what's the big deal if the ua lies about being, say, a screen reader |
| 19:11 | <hsivonen> | aaronlev: otoh, if you exercise the feature you want to sniff for, you are more likely to get the right answer |
| 19:11 | <aaronlev> | i see |
| 19:11 | <aaronlev> | i guess there are some folks that want to use it in the learning space, it's crazy researchy stuff that's far out |
| 19:12 | <aaronlev> | but i need to have an answer |
| 19:12 | <aaronlev> | for educational content, they want to be able to express a lot about the user and their prefs/capabilities |
| 19:12 | <hsivonen> | aaronlev: the big deal is this: browser A supports features foo and bar that are coupled as foobar. Part foo becomes part of a killer app from company G. Browser B implements support for only foo, not bar, but lies and claims support for foobar in order to get the killer app working |
| 19:12 | <aaronlev> | and change the content accordigly |
| 19:13 | <hsivonen> | result: asking for foobar support gives you the wrong answer if you want to use bar |
| 19:13 | <aaronlev> | right, but for user preferences that might not be an issue |
| 19:13 | <aaronlev> | makes sense for capabilities |
| 19:14 | <annevk> | hmm, accept-language and such is often wrong |
| 19:14 | <annevk> | which is something that depends on the user |
| 19:14 | <annevk> | (in theory, anyway) |
| 19:14 | <hsivonen> | annevk: hmm. interesting error messages... |
| 19:15 | <annevk> | yeah |
| 19:15 | <annevk> | totally weird |
| 19:17 | <annevk> | I think it might be because of the "http:http://asbjornu.myopenid.com/"; value for href= |
| 19:17 | <annevk> | that fixes at one message |
| 19:18 | <annevk> | not sure what the problem is with the other two, although I think you might not allow the empty string for type=url |
| 19:23 | <hsivonen> | annevk: cool. at least one of the messages was useful ;-) |
| 19:23 | <annevk> | in a way :) |
| 19:24 | <annevk> | that it pointed hilited rel=nofollow didn't really help :) |
| 19:24 | <hsivonen> | annevk: I'm not stopping what I'm doing right now, but I intend to fix the two other errors soonish |
| 19:24 | <hsivonen> | annevk: yeah, that's what I'm fixing now |
| 19:25 | <hsivonen> | getting showing the source right isn't a small thing |
| 19:25 | <hsivonen> | so far, I've doubled the number of classes in the validator subrepo... |
| 20:37 | <Philip`> | Blending rgba(0,255,0,0.5) on top of rgba(0,255,0,1) gives dark green, in APNG with default gamma, which is annoying because it means I'll have to learn how gamma works |
| 20:39 | <Philip`> | ...although I'm not convinced it actually should give dark green |
| 20:39 | <Philip`> | but it does in both Firefox and Opera |
| 20:56 | <Hixie> | wow, 2.1% of pages using accesskey="" is a lot |
| 20:57 | <annevk> | all my weblog pages used it until a few hours back |
| 20:57 | <Hixie> | heh |
| 20:57 | annevk | had accesskey=1 for home and accesskey=9 for contact |
| 20:58 | <annevk> | which are not all that useful I think |
| 20:59 | <Hixie> | i'm not really all that convinced access keys are that useful in general, but that's just me |
| 20:59 | <Hixie> | (in particular it seems obvious to me that the touch model of the iPhone is the way visual browsing should work when you don't have a mouse) |
| 21:01 | <annevk> | I think chaals wants to make it some kind of "this link is more important than others" hint |
| 21:01 | <annevk> | but I'm not entirely sure that's a correct representation |
| 21:02 | <Hixie> | importance can be indicated using <strong> |
| 21:02 | <annevk> | I guess |
| 21:05 | <tantek> | Hixie, access keys are quite an accelerant for editing/previewing/saving wiki pages. It makes it "feel" much more like a "real" text editor. |
| 21:05 | <Hixie> | i wonder how long i should wait for feedback on the latest offline proposal |
| 21:05 | <Hixie> | tantek: ah |
| 21:06 | <tantek> | specifically, MediaWiki installs, e.g. Wikipedia.org, and pbwiki.com have consistent editing accesskeys |
| 21:06 | <tantek> | on a Mac, ctrl-E to edit, ctrl-P to preview, ctrl-S to save. |
| 21:07 | <tantek> | but this may be a specific instance, and your comment about *in general* may still be correct. |
| 21:12 | <Philip`> | (Oh, whoops, I was being stupid and using premultiplied alpha in the APNG which means my expectation was completely wrong...) |
| 21:33 | <hsivonen> | annevk: I get timeouth when connecting to your site |
| 21:33 | <hsivonen> | timeouts even |
| 21:35 | <annevk> | wfm, although it's somewhat slow |
| 21:38 | <hsivonen> | annevk: well, my timouts are quite reasonable considering other sites |
| 21:40 | <annevk> | avg ping is 161.354ms |
| 21:42 | <hsivonen> | ok. not it responded in less than 5 seconds |
| 21:43 | <hsivonen> | I now have range start guessing code, but it appears to be very broken |
| 21:43 | <hsivonen> | (the ranges start far too early) |
| 21:43 | <hsivonen> | will debug tomorrow |
| 22:44 | <gsnedders> | really odd semantics question: if I'm calling two girls that I loved "her", how do I stress the importance of the "her", and note that they are different people? |
| 22:44 | <gsnedders> | far harder to do semantically than it is to do visually |
| 22:50 | <gsnedders> | oh, and with something like http://script.geoffers.uni.cc/node/9, how would I offset the actual poem from the introduction? should I treat it as a quote of something I wrote elsewhere, or…? |
| 22:51 | <gsnedders> | (the last link includes some profanity, actually) |
| 23:01 | <jgraham_> | gsnedders: I don't understand the first question. "Calling two girls that I loved her" is giving me a parse error... |
| 23:02 | <gsnedders> | jgraham_: can you enter HTML mode, so we don't have draconian errors? :) |
| 23:03 | <jgraham_> | s/calling/{something}/ maybe? |
| 23:03 | <Hixie> | othermaciej: any input on the latest proposal? (just a quick read followed by a "looks good" or a "i have comments that i'll send later" would be fine) |
| 23:03 | <gsnedders> | jgraham_: I have a long standing tradition of calling any girl that I like "her" on IRC, with different markers around the names, e.g., _her_ and *her*. how could I use "her" and make it clear that it is important (thereby |strong|) without mixing up different people |
| 23:03 | <Hixie> | (just need to know whether i should start writing it up or not) |
| 23:04 | <othermaciej> | Hixie: I'm in a meeting that will be over momentarily and then I'll do a quick scan |
| 23:04 | <Hixie> | excellent, thanks |
| 23:04 | <Hixie> | by the way, you need to work on being in fewer meetings. |
| 23:04 | <gsnedders> | (don't ask here that naming convention comes from, it's a long story) |
| 23:04 | <Hixie> | i swear you're always in a meeting where i ping you :-) |
| 23:04 | <othermaciej> | Hixie: I sure do |
| 23:04 | <jgraham_> | gsnedders: Oh, I see. |
| 23:05 | <othermaciej> | that's what I get for being promoted to my level of incompetence |
| 23:05 | <Hixie> | no comment |
| 23:05 | <gsnedders> | :D |
| 23:05 | <gsnedders> | ergh. I want a parent selector in CSS. |
| 23:05 | <Hixie> | don't we all |
| 23:05 | <Hixie> | :matches() baby |
| 23:06 | <gsnedders> | I want something like p < cite { text-align: right; } |
| 23:06 | <annevk> | p:matches($>cite) { text-align:right } |
| 23:06 | <Hixie> | or p:has(>cite) { text-align: right; } |
| 23:06 | <jgraham_> | gsnedders: I think the answer is "use surrounding context to differentiate the two people". Although that might not go down well with some members of public-html who don't believe in context |
| 23:06 | <Hixie> | though in this case it doesn't really improve much |
| 23:07 | <gsnedders> | if only there was a block level cite element :P |
| 23:07 | <deltab> | gsnedders: why not use the same convention? |
| 23:08 | <gsnedders> | jgraham_: if you read two posts of mine, one from last year, the other from this, you could end up thinking they were the same person |
| 23:08 | <aa> | it stinks that xpath and css are different |
| 23:08 | <Hixie> | just use <p class="cite"><cite> ... </cite></p> and then set .cite cite { display: block; } |
| 23:08 | <Hixie> | or some such |
| 23:08 | <Philip`> | p.parent-of-cite { text-align: right; } <script>for each (var c in document.getElementsByTagName('cite')) c.parentNode.className += ' parent-of-cite'</script> |
| 23:08 | <Hixie> | ah if only you could enumerate NodeLists |
| 23:08 | <gsnedders> | jgraham_: (which is further complicated by the fact that I have gone on about people for over a year) |
| 23:08 | <gsnedders> | Hixie: I already use such a thing |
| 23:09 | <Hixie> | good good |
| 23:09 | <gsnedders> | just annoying :P |
| 23:09 | gsnedders | is going to end up with an insane number of posts tagged "lust" merging all his blogs into one |
| 23:09 | <jgraham_> | gsnedders: Isn't language wonderful. Also why do you need <cite>? Are you expecting anything special from UAs? |
| 23:10 | <gsnedders> | jgraham_: or, more just using it as a styling hook :P |
| 23:10 | <gsnedders> | s/or/oh/ |
| 23:10 | <deltab> | gsnedders: use different fonts for different people |
| 23:10 | <gsnedders> | deltab: that only helps in visual UAs |
| 23:10 | <Philip`> | Or different colours |
| 23:11 | <gsnedders> | (I'm currently using underlining/bold/etc for visual UAs, and using |strong| for all) |
| 23:11 | <gsnedders> | thereby relying on context for non-visual UAs |
| 23:12 | jgraham_ | wonders if <cite> has a compelling usecase |
| 23:12 | <Philip`> | You could have her<sub>1</sub> and her<sub>2</sub> |
| 23:13 | <gsnedders> | Philip`: I thought of that… If I do that, do I start with him<sub>1</sub> or him<sub>3</sub> though? |
| 23:13 | <jgraham_> | him<sub>3</sub> is futureproff against sex change operations |
| 23:14 | <Philip`> | That depends on whether you are talking about anyone who is likely to change gender, because that would cause conflicts if you had two distinct numbering systems |
| 23:14 | <gsnedders> | I didn't even think of it in that way… |
| 23:15 | gsnedders | wonders whether any of his ex-bfs would ever have a sex change operation |
| 23:16 | <jgraham_> | Or you could go URI happy and do <a href="http://geoffers.uni.cc/people/girls/1">her</a>; |
| 23:17 | <jgraham_> | The resources at the end of the link would be RDF I guess |
| 23:17 | <Philip`> | People can start thinking of themselves as "she" without having an actual operation, and then maybe switch back to "he" a while later, so you can get namespace collisions even if the people involved don't do anything drastic |
| 23:17 | gsnedders | sighs |
| 23:17 | <gsnedders> | meaning monosexual would probably simplify this |
| 23:17 | <gsnedders> | s/mea/be/ |
| 23:18 | <Philip`> | (I tend to avoid using pronouns in that case, so I don't have to decide which one to apply to the person, which isn't actually too difficult) |
| 23:18 | <gsnedders> | I'd use their names, but I'm too secretive about my private life to use names |
| 23:19 | <ozamosi> | But names aren't unique either... |
| 23:19 | <ozamosi> | (usually) |
| 23:19 | <Philip`> | You could use the SHA-1 of their name |
| 23:19 | <gsnedders> | ozamosi: forename + surname is unique enough |
| 23:19 | <gsnedders> | Philip`: but collisions? |
| 23:20 | <ozamosi> | gsnedders: well... I think forename + surname collisions are more likely than sex changes, actually |
| 23:21 | Philip` | says hello to the other Philip Taylor in the HTML WG |
| 23:21 | <gsnedders> | ozamosi: that's probably true. |
| 23:21 | <gsnedders> | Philip`: s/Taylor/TAYLOR/ |
| 23:21 | <Philip`> | You could use their MSN address |
| 23:21 | <gsnedders> | Philip`: no, friends would be able to find out who |
| 23:21 | <ozamosi> | SHA-1 on MSN address! :) |
| 23:22 | <gsnedders> | Philip`: and I've had enough people kill me for spreading their MSN address among one or two people, yet alone the web |
| 23:22 | <Philip`> | You could use the hash of their MSN address, with a prepended salt so other people can't work out who it is |
| 23:22 | <gsnedders> | ozamosi: that might work, if I knew all of their MSN addresses |
| 23:22 | <gsnedders> | Philip`: a salt wouldn't help |
| 23:22 | <ozamosi> | FoaF use SHA-1 on email addresses as UID:s, I think |
| 23:22 | <Philip`> | It would have to be a secret salt which only you know |
| 23:22 | <Philip`> | though maybe that's not a salt any more |
| 23:22 | <gsnedders> | Philip`: if you find a string that happens to be the original, which is infinitely unlikely anyway, having a hash wouldn't help |
| 23:23 | <gsnedders> | s/hash/salt/ |
| 23:23 | gsnedders | is too tired |
| 23:23 | <Philip`> | but then people couldn't just hash the MSN user database to find out who you're talking about |
| 23:23 | <gsnedders> | Philip`: ah. true. |
| 23:23 | <gsnedders> | actually, I know all of their bebo usernames… |
| 23:23 | <gsnedders> | that's a UID I could use (hash + salt, obviously) |
| 23:24 | jgraham_ | points out that more ambiguity = more privacy |
| 23:24 | <gsnedders> | jgraham_: some of the names involved are quite rare where I live, and I'm in a relatively small town |
| 23:25 | <jgraham_> | I was just saying that y'know /not bothering/ will improve privacy even if it offends your instincts for attaching objects unique identifiers ;) |
| 23:26 | <gsnedders> | her<sub>f3fbff01d2a29fb88526a6be2f7d3d97c78bc87b</sub> is a bit awkward, though |
| 23:26 | <jgraham_> | Oh, and per your second question; I think <article> or <section> is what you want. |
| 23:27 | <gsnedders> | <section> probably |
| 23:27 | <gsnedders> | jgraham_: not bother? me? :) |
| 23:27 | <gsnedders> | (looking up bebo username to calculate that hash made me laugh — her username is to do with lust :P) |
| 23:28 | <Philip`> | Base 16 encoding is very inefficient - you should probably be able to do it in base 32768 if you use Unicode characters |
| 23:29 | gsnedders | bursts out laughing |
| 23:30 | <kingryan> | Philip`: wouldn't there be numbers that couldn't be expressed? |
| 23:30 | <gsnedders> | surely base 0x1400 would be enough? |
| 23:31 | <gsnedders> | kingryan: yeah, that would be an issue |
| 23:32 | <om_sleep_> | Hixie: ok, out of meeting, reading now |
| 23:32 | <Philip`> | kingryan: Why would that be? |
| 23:32 | <Hixie> | wow, othermaciej fell asleep during his meeting |
| 23:32 | <gsnedders> | Philip`: not all unicode code points are assigned |
| 23:32 | <gsnedders> | Hixie: Apple is exciting. I thought you knew? :) |
| 23:33 | <hsivonen> | hmm. why is it that so many Java libraries implement their own UTF-8 encoding or decoding? |
| 23:33 | <othermaciej> | Hixie: no, my IRC client just sucks :-( |
| 23:34 | <Philip`> | You don't need 32K consecutive code points - just pick some subset that doesn't conflict with HTML (like avoid whitespace and control characters), and I assume there's enough allocated code points to manage that |
| 23:39 | <hsivonen> | the Xalan XML serializer is surprisingly big |
| 23:39 | <gsnedders> | if I had binary data, how would I get it into a state from which I could get a codepoint (I really am too tired)? |
| 23:39 | <hsivonen> | and all I wanted was an easily hackable ContentHandler to stream serializer |
| 23:40 | gsnedders | realises |
| 23:40 | <kingryan> | hsivonen: some java libraries (namely lucene) do their own utf-8 encoding b/c they implemented it before the spec was done, IIRC |
| 23:40 | gsnedders | facepalms |
| 23:41 | <hsivonen> | kingryan: yeah, there's a lot pre-1.4.2 stuff out there |
| 23:41 | <othermaciej> | Hixie: looks good to me |
| 23:42 | <hsivonen> | some Java libraries are surprisingly conservative about support for old JDKs |
| 23:42 | <othermaciej> | Hixie: I may have feedback on details once I see it in spec form but the basic model seems sound |
| 23:43 | <Hixie> | othermaciej: k |
| 23:43 | <Hixie> | othermaciej: thanks |
| 23:44 | hsivonen | seriously considers writing a non-configurable *simple* UTF-8-only XML serializer |
| 23:45 | <hsivonen> | I know that I could write a namespaceless serializer faster than I could familiarize myself with the Xalan codebase |
| 23:45 | <hsivonen> | but namespaces will be yucky |
| 23:50 | <othermaciej> | Hixie: actually, I'm still not sure how to address login, since with many web apps the main URL normally goes to a login page - perhaps it's ok for a first cut to say the offline API only works with "remember me on this computer" style login |
| 23:54 | <Hixie> | othermaciej: the mail url typically goes to a login page unless you're already logged in |
| 23:54 | <Hixie> | othermaciej: it's trivial for that page to check if you are logged in |
| 23:54 | <gsnedders> | numeric subscripts it is, starting at 1 for both male and female. |