| 00:08 | <Lachy_> | good morning everyone :-) |
| 00:09 | <zcorpan> | Lachy_: morning |
| 00:15 | <Lachy_> | does anyone have a clue what David Daley's latest post on public-html is going on about? He seems to go from word art to physics to markup in one sentence :-/ |
| 00:17 | zcorpan | isn't reading dd's mails |
| 02:41 | <Dashiva> | So speaking of canvas, it has width and height attributes of type long. The content attributes are defined as non-negative integers. Shouldn't the DOM attributes be unsigned long then? |
| 02:42 | <Lachy_> | Dashiva: you should raise that on the mailing list |
| 02:44 | <Philip`> | I've just raised that already |
| 02:44 | <Philip`> | (Well, I didn't explicitly say they should be unsigned long, but I assume that's the logical conclusion) |
| 02:45 | <Dashiva> | Lachy: It was a real question. Canvas is never going to use the upper half of an unsigned long, either type will have a huge unused number space, so the end result wouldn't really change |
| 02:46 | <Lachy_> | so then what's the problem? |
| 02:47 | <Dashiva> | "Should attributes defined to be non-negative always use unsigned long?" |
| 02:48 | <Lachy_> | I don't know. Could it break anything if it were changed? |
| 02:49 | <Philip`> | <img> uses signed long DOM attributes and non-negative [or non-negative percentage] content attributes, but they're not reflecting so it's not a problem |
| 02:49 | <othermaciej> | in ECMAScript they are all IEEE doubles anyway |
| 02:49 | <othermaciej> | so at most this would matter for behavior when you assign an invalid value |
| 02:50 | <othermaciej> | note that unsigned long a 64-bit integer, and an IEEE double can't even address all its values |
| 02:53 | <Philip`> | If you set canvas.width to 4294967296+200, then it gets converted to 200 in every browser, so they seem to be using 32-bit integers |
| 02:56 | <othermaciej> | oh, I guess long is 32-bit in IDL |
| 02:56 | <othermaciej> | my mistake |
| 03:34 | <zcorpan> | http://www.oreillynet.com/xml/blog/2007/03/restarting_the_html_engine.html?CMP=OTC-TY3388567169&ATT=Re-starting+the+HTML+Engine |
| 03:35 | <othermaciej> | what's HTML 4.3? |
| 03:36 | <zcorpan> | there's so much wrong in that article |
| 03:37 | <zcorpan> | in the second comment: "Actually most browsers do have the ability to determine whether an HTML document is valid or not" |
| 03:38 | <othermaciej> | wow, that guy has no idea |
| 03:38 | <othermaciej> | about... anything |
| 03:38 | <othermaciej> | candidate for most clueless sentence: "It is likely that an HTML 5.0 DTD would in fact allow for a valid XHTML1 or XHTML2 schema as one potential use case." |
| 03:38 | <zcorpan> | yeah that one amused me too |
| 03:39 | <Lachy_> | I'm only up to the 3rd paragraph, and already come across countless mistakes. Please tell me it gets better? |
| 03:39 | <zcorpan> | sorry dude |
| 03:40 | <othermaciej> | reading this hurts my eyes and brain |
| 03:40 | <Lachy_> | ok, I'll read it after lunch then |
| 03:40 | <zcorpan> | wonder if it's worth commenting |
| 03:47 | <zcorpan> | added to http://del.icio.us/zcorpan anyway |
| 03:49 | <zcorpan> | (my "whatwg" tags are feedback, the rest are just bookmarks) |
| 03:55 | <zcorpan> | "Probably ought to join at least the whatwg lists; W3C could get scary after a tmie..." -- http://del.icio.us/url/7186620143093f814e8a0652b169d7d3 |
| 05:32 | <marcosc> | is anyone else having problems loading http://www.whatwg.org/specs/web-apps/current-work/ in firefox? |
| 05:32 | <marcosc> | I've tried on two different machines. It seems fine in IE? |
| 05:45 | <marcosc> | Hixie, can you please fix (or remove) the print style from http://www.whatwg.org/style/specification |
| 05:45 | <marcosc> | Currently it's set to: |
| 05:45 | <marcosc> | @media print { |
| 05:45 | <marcosc> | html { font-size: 10pt; } |
| 05:45 | <marcosc> | } |
| 05:45 | <marcosc> | please either leave the spec to use browser defaults or set font-size to something (much) larger. I just tried to print the latest draft of the spec on using 2 pages per sheet and the spec is unreadable. Lets not make people waste paper unessasarily, I personally feel bad enough about my environmental track record :( |
| 05:47 | <zcorpan> | marcosc: i think hsivonen has a better print style sheet |
| 05:48 | <marcosc> | zcorpan, hopefully the spec can point to that instead :) |
| 05:50 | <marcosc> | On my machine, IE7 also really struggles with rendering the spec. It think it might be getting too big. |
| 09:06 | <hsivonen> | what happened to the old whatbot logs? |
| 10:25 | <Lachy> | hsivonen, I think Charl and krijnh are going to recover the old logs |
| 10:31 | <krijnh> | Yeah |
| 10:32 | <krijnh> | Sorry for not having already |
| 10:32 | <krijnh> | I have to copy every file by hand :) |
| 10:32 | <krijnh> | Ow, and I have to work |
| 10:34 | <krijnh> | Regarding that, it's hard selling a CMS without a WYSIWYG editor :] |
| 11:20 | <hendry> | omg, re "HTML should be replaced by Flash" msg |
| 11:20 | <Lachy> | oh gosh, I wonder why he posted that to the list :-/ |
| 11:21 | <hendry> | He must be troll. |
| 11:21 | <krijnh> | Or just a joke |
| 11:21 | <krijnh> | To show how his colleague thinks about the web |
| 11:21 | <krijnh> | Let's ignore :) |
| 11:21 | <hendry> | joke/trolling is the same in my book |
| 11:21 | <Lachy> | jokes are ok sometimes, trolling isn't |
| 11:22 | <hendry> | well this is a bad joke ;) |
| 11:22 | <Lachy> | well, I suppose I laugh at both and don't reply to either |
| 11:22 | hendry | sobs |
| 11:22 | krijnh | doesn't understand the xml input thing |
| 11:25 | <Dashiva> | Maybe it's art |
| 11:27 | <krijnh> | "Expert users could use generic XML editors while children and grandparents would probably prefer more human friendly input tools, restricted to specific schemas." - the latter should still be a generic XML editor, right? |
| 11:33 | <virtuelv> | hendry: url for that msg? |
| 11:34 | <krijnh> | virtuelv: http://lists.w3.org/Archives/Public/public-html/2007JanMar/0516.html |
| 11:35 | <virtuelv> | heh, now -that's- a troll |
| 11:35 | <Dashiva> | krijnh: Well, theoretically the schema could be turned into a BBcode like editor, with buttons for various tags with prompting for attributes and whatnot |
| 11:36 | <Dashiva> | That would be friendly, but probably a nightmare to create |
| 11:37 | <krijnh> | So in stead of <foo> you'd have [foo] |
| 11:38 | <Dashiva> | Oh, badly worded. I meant editor like the BBcode ones used in forums and the like |
| 11:39 | <krijnh> | Or like WordPress |
| 11:40 | <krijnh> | Which knows about semantics, a bit |
| 11:40 | <Dashiva> | Haven't used it, but I imagine there are many similar cases |
| 11:40 | <Dashiva> | The problem would be turning a schema into the right buttons, I think |
| 11:41 | <krijnh> | And the generated foo into something on your screen, if you want wysiwyg |
| 11:42 | <Dashiva> | I figured the xml input thingie would only be for actual xml and no presentation? |
| 11:42 | <krijnh> | Then I don't get how children/grandparents could benefit |
| 11:44 | <Dashiva> | Well, they would press buttons and answer questions presented (about values, atts, etc), and not be writing it directly |
| 17:16 | <krijnh> | marcosc: If my server breaks, I hold you responsible ;) |
| 17:17 | <marcosc> | no probs |
| 17:18 | <marcosc> | Krijnh, what are we talking about? |
| 17:18 | <krijnh> | marcosc: http://lists.w3.org/Archives/Public/public-html/2007JanMar/0527.html |
| 17:19 | <marcosc> | Ah! Welcome!!! :D |
| 17:22 | <tylerr> | I was a bit scared this morning when I opened my e-mail to 100+ messages. :) |
| 17:23 | <krijnh> | marcosc: How fast is my server anyway? Can't test it here, since it's in my LAN |
| 17:25 | <marcosc> | krijnh, I'm lost, sorry? |
| 17:25 | <krijnh> | krijnhoetmer.nl/irc-logs/ |
| 17:25 | <krijnh> | How are does files served? |
| 17:25 | <marcosc> | oh, it's good |
| 17:25 | <krijnh> | Hmm, k |
| 17:26 | <marcosc> | sorry, It's 2:30am for me and I'm trying to have 5 conversations at the same time while debugging... :( |
| 17:26 | <krijnh> | Ah, hehe |
| 17:26 | <krijnh> | Well, 18:38 here, diner time |
| 17:27 | <marcosc> | enjoy! |
| 17:27 | <krijnh> | Nn ;) |
| 17:27 | <tylerr> | Goodness I'd be happy if it were dinner time! I just got in to work 40 minutes ago. :( |
| 17:28 | <marcosc> | krijnh, so I guess I totally mistook your comments about IRC. I thought you were avoiding IRC and there you were actually doing the logging! |
| 17:32 | <Philip`> | krijnh: I get a consistent 50KB/sec downloading the logs from that site, so it's about a second to reload a log page, which seems fast enough (though it could be nice to enable compression if that's easy) |
| 17:33 | marcosc | as a rule should just not make comments on public mailing lists. |
| 17:37 | <zcorpan_> | http://waffle.wootest.net/2007/03/24/now-in-glorious-html5/ |
| 20:35 | tylerr | wonders how the communication flow is going to take shape for the HTMLWG. |
| 20:37 | <othermaciej> | I think we need an issue tracker, but people who can't follow the flow of IRC or even email are going to be less informed and less up to speed |
| 20:37 | tylerr | nods. |
| 20:37 | <othermaciej> | but we still want those people to be able to participate, and they need an issue tracker or the like |
| 20:38 | <tylerr> | Something akin to a bug tracker/ticket system? |
| 20:39 | <gsnedders> | WHATWG's is Hixie's magical memory, right? |
| 20:40 | <tylerr> | Magical what? :-) |
| 20:40 | <kingryan> | gsnedders: it's hixie's inbox |
| 20:41 | <gsnedders> | kingryan: I know, but that's a boring explanation :P |
| 20:41 | <othermaciej> | I think the "hixie's inbox" system is great for hixie but not so much for people who are not him |
| 20:41 | <gsnedders> | especially with the WG wanted to be more open |
| 20:41 | <gsnedders> | *wanting |
| 20:41 | <tylerr> | Well if we're looking for online solutions... |
| 20:41 | <tylerr> | http://www.solutionwatch.com/578/a-roundup-for-developers-developers-developers/ |
| 20:42 | <tylerr> | There's a whole slew of tools to consider. |
| 20:42 | <gsnedders> | as long as we don't choose something with an unusable UI |
| 20:43 | <tylerr> | This is the world of "Web 2.0", everything has a pretty UI these days. ;-) |
| 20:46 | <othermaciej> | adding more separate places where discussion takes place probably won't help the people who feel overwhelmed |
| 20:46 | <gsnedders> | I want a single point of communication |
| 20:47 | <gsnedders> | having multiple places means you don't have a discussion with everyone invovled |
| 20:47 | <othermaciej> | just having IRC and mail is bad enough |
| 20:47 | <gsnedders> | agreed |
| 20:47 | <othermaciej> | but IRC is more responsive and has lower cognitive load per message |
| 20:47 | <gsnedders> | but is harder to catch up on |
| 20:47 | <othermaciej> | whereas mail is more inclusive of asynchronous participants |
| 20:48 | <gsnedders> | anything asynchronous is easier to catch up on, as people have to make their points in a single message |
| 20:48 | <tylerr> | It's going to be a persistant problem. |
| 20:49 | <tylerr> | People needing to catch-up and asking for explaination/follow-up, while those that were part of the original discussion will want to move forward. |
| 20:49 | <Dashiva> | I think making the email archive more forumy could go a long way |
| 20:50 | <tylerr> | So that posts to the list auto-generate replies in forum topics? |
| 20:52 | <Dashiva> | Well, make the archives look more like a forum with automatic thread view, all mail in one thread on the same page, stuff like that |
| 20:53 | <tylerr> | I'd code something up to do that but I don't have the chops. :) |
| 20:53 | <Dashiva> | You could make a fullfledged hybrid where a bot posts incoming mail in threads, and sends mail based on forum replies, but that is overdoing it IMO |
| 20:53 | <Dashiva> | Personally, I believe the thread structure of a forum is too static for this kind of work |
| 20:53 | <tylerr> | Haha yeah. We're here for HTML, not a new parsing/publishing tool. :) |
| 20:54 | <tylerr> | I agree. |
| 20:54 | <Dashiva> | Almost every email in the list with significant replies has branched noticably |
| 20:56 | <Dashiva> | On the other hand, I can fully understand that anyone stuck with a webmail client would love a forum |
| 20:56 | <tylerr> | Aye. |
| 20:57 | <tylerr> | I've mentioned Campfire a few times before, but the consensus always returns to straight IRC. |
| 20:58 | <othermaciej> | tylerr: better archive views (threaded spanning month blocks for instance) would help for people catching up |
| 20:59 | <othermaciej> | tylerr: but I don't think we can ask the group to go slower to help the people who have less time to follow |
| 20:59 | <tylerr> | Sure, that's just not good for the pace of the WG. |
| 20:59 | <Dashiva> | Yeah, thread grouping should take priority over time grouping |
| 21:00 | <othermaciej> | ultimately there will be a final review period |
| 21:00 | <othermaciej> | but I think planning a feature freeze milestone and sticking to discussion of larger features before then may actually help |
| 21:01 | <othermaciej> | so "should we add <video> and how should it work?" would take precedence over things like <acronym> vs <abbr> |
| 21:01 | <othermaciej> | but I also think establishing shared design principles up front is good |
| 21:01 | <tylerr> | Let me know if I'm pushing Campfire too much, but one account gives you access to create multiple "rooms", which have their own log search capabilities. Discussions can be mitigated to individual rooms where discussion can take place and will be logged by both time and "thread". |
| 21:02 | <tylerr> | So a <video> room could be created for all discussions related to video, and logs would be easily accessible and readible by anyone. |
| 21:02 | <Dashiva> | Sounds like a forum with subforums to me, tylerr |
| 21:02 | <tylerr> | Sure, but it has the dynamic level of chat. |
| 21:03 | <tylerr> | Here's a snapshot of the transcript section. |
| 21:03 | <tylerr> | http://campfirenow.com/images/tourshot-transcripts.png |
| 21:04 | <othermaciej> | tylerr: or we could make #htmlwg-video and log that |
| 21:04 | <tylerr> | Sure. |
| 21:04 | <othermaciej> | tylerr: I'm wary of claims that changing to a different chat program will somehow make things better |
| 21:05 | <tylerr> | I'm am as well. I'm just throwing options out there. I'm completely happy with IRC myself. :-) |
| 21:05 | <tylerr> | I just know some people are warry of it. |
| 21:06 | <Dashiva> | We could spend four years designing IRC 2.0 |
| 21:06 | <gsnedders> | surely IRC 5.0? |
| 21:06 | <gsnedders> | :P |
| 21:06 | <gsnedders> | (can we please add a way to declare encoding!?) |
| 21:07 | <Dashiva> | No |
| 21:07 | <Dashiva> | Forced unicode! |
| 21:09 | <gsnedders> | well, specifying an encoding is one way of declaring an encoding :) |
| 21:09 | <gsnedders> | as it declares it in the spec |
| 21:09 | <Dashiva> | Well, IRC is specified to pass octets. The end client decides what to do with them. Isn't that good enough? :) |
| 21:10 | <tylerr> | Heh |
| 21:10 | <tylerr> | Okay, just for fun, here's a campfire room I've set up. Only four people can come in, but feel free to take a look: http://htmlwg.campfirenow.com/01ff9 |
| 21:15 | <bewest> | isn't campfire proprietary? |
| 21:15 | <tylerr> | bewest: Yep, service run by 37signals. |
| 21:17 | <bewest> | I would suggest that might be a reason that your suggestion doesn't gain much traction |
| 21:18 | <tylerr> | I'd gather as much, but sometimes there just isn't an opensource solution readily available, else I'd be all over it. |
| 21:19 | <bewest> | maybe that's why IRC is so popular |
| 21:19 | <bewest> | readily available, widely deployed, well supported |
| 21:19 | <bewest> | it's not old, it's proven |
| 21:20 | <bewest> | and open |
| 21:20 | <bewest> | and it's extensible using bots |
| 21:20 | <Dashiva> | It's open in theory, but every ircd seems to do things differently. Could use a new rfc to standardize things added since 1976 |
| 21:20 | <Dashiva> | (year made up for humorous effect) |
| 21:21 | <tylerr> | Sure. I agree with your points, and I'm going to keep mentioning that I openly support IRC as our communication tool. I'm just open to suggesting other means of communication to let others explore the options while we wait for an offical stance. |
| 21:23 | <tylerr> | I'm just along for the ride. When it comes to getting work done, any environment will suit me fine. :-) |
| 21:23 | <tylerr> | *comes time |
| 22:03 | <Hixie> | regarding the issue tracking |
| 22:03 | <Hixie> | the reason i don't issue track outside my inbox is that issue tracking inside my inbox takes about 500ms per e-mail |
| 22:03 | <Hixie> | plus whatever time it takes to reply to the e-mail |
| 22:03 | <Hixie> | issue tracking outside that would require much more time |
| 22:04 | <Hixie> | people are, however, very much encouraged to do any issue tracking they'd like, e.g. in the wiki or elsewhere |
| 22:05 | <Dashiva> | Issue-001: Hixie has a job, preventing him from devoting his entire day to lggwg |
| 22:05 | <Dashiva> | Actually, we talked yesterday about long vs unsigned long in the DOM attributes |
| 22:05 | <othermaciej> | I think for HTMLWG, we can probably find volunteers to handle the overhead of a more formal issue tracker on your behalf |
| 22:05 | <kingryan> | Hixie: ideally you wouldn't have to process every bit of feedback. that should be parallelized |
| 22:05 | <othermaciej> | Hixie: I think making you do the beurocracy would be too annoying |
| 22:05 | <Dashiva> | image and canvas have height/width defined to be non-negative, but the DOM values are signed. Is this an issue? |
| 22:06 | <othermaciej> | but we might also be able to set up a mailbot where saying magic key phrases in mail marks an issue as resolved |
| 22:06 | <Hixie> | yeah if someone else does issue tracking that's certainly something i'd support |
| 22:06 | <othermaciej> | and where incoming mail can automatically create an issue |
| 22:06 | <kingryan> | Hixie: at the very least having people do triage (is this a preexisting issue? has it already been dealt with?) could lighten the load |
| 22:06 | <Hixie> | i'd still want to actually reply to every e-mail though |
| 22:06 | <Hixie> | because i think distilling e-mails tends to dilute issues and makes it much easier to ignore things |
| 22:06 | <Hixie> | especially annoying, hard things |
| 22:06 | <Hixie> | kingryan: yup |
| 22:07 | kingryan | is *not* volunteering |
| 22:07 | <Philip`> | (Dashiva: I believe it's mainly an issue for canvas and not for img, because only canvas says the DOM and content attributes reflect) |
| 22:08 | <tylerr> | Are you looking for issue tracking software or simply just someone to manage the deluge of mail? |
| 22:08 | <Hixie> | Dashiva: someone sent mail about that (you, maybe?) and it's in my pile of canvas feedback :-) |
| 22:08 | <Hixie> | tylerr: i'm not looking for anything, but i believe two things were being proposed: |
| 22:08 | <Dashiva> | Philip`: Even without reflection, there is the semantic issue |
| 22:08 | <Hixie> | 1. a way to allow people to see what open issues exist |
| 22:09 | <Hixie> | 2. a way to triage incoming feedback so that people raising old issues can have their issues closed without editorial involvement |
| 22:10 | <tylerr> | Hmm... so something like a social ticketing tracking system. |
| 22:10 | <tylerr> | Rather, "open" ticket-tracking system. |
| 22:10 | <tylerr> | Social is so commodified these days. ;-) |
| 22:11 | <othermaciej> | it would be extra nice if it was linked to email |
| 22:12 | <othermaciej> | trackbot already knows how to detect email follow-ups on an existing issue |
| 22:12 | <bewest> | tylerr: see baetle |
| 22:12 | <othermaciej> | just needs a way to add an issue and a way to resolve an issue by email |
| 22:12 | <othermaciej> | the problem is that whether a comment is accepted or rejected can be subjective |
| 22:13 | <tylerr> | Nice bewest. |
| 22:13 | <tylerr> | Thanks. |
| 22:13 | <othermaciej> | in w3c at least, the WG says they agree but then does something the commentor disagrees with |
| 22:18 | <Philip`> | Dashiva: True - I was just thinking of the logical contradiction issue with canvas, whereas img is 'only' semantically odd (and partly undefined, because I don't think it says what happens when you modify the DOM 'width') |
| 22:29 | <hsivonen> | Hixie: should I cross-post http://hsivonen.iki.fi/printing-wa10/ to the WHATWG blog even though it is product-specific? |
| 22:31 | <Hixie> | uh |
| 22:31 | <Hixie> | is there something i can do to just fix the spec instead? :-) |
| 22:31 | <Hixie> | it should not be that hard! |
| 22:32 | <hsivonen> | Hixie: you could start by adding a charset meta :-) |
| 22:32 | <hsivonen> | Hixie: then, I suppose you could take me additions to the style sheet and put them in a @print block |
| 22:33 | <hsivonen> | Hixie: and having a wrapper <div> for the entity table would be nice as long as Prince does not support ::outside on it |
| 22:33 | <hsivonen> | Hixie: for WF 2.0, adding IDs for all tables would be great |
| 22:35 | <Hixie> | i use characters outside US-ASCII? |
| 22:35 | <hsivonen> | Hixie: lots |
| 22:36 | <Hixie> | really?! |
| 22:36 | <hsivonen> | Hixie: and weird ones too |
| 22:36 | <Hixie> | that's worrying |
| 22:36 | <Hixie> | since i'm not using an 8bit-safe editing environment |
| 22:36 | <hsivonen> | I had to google to find a font for WARNING SIGN |
| 22:36 | <Hixie> | where? |
| 22:36 | <Hixie> | but that's not an entity right? |
| 22:36 | <Hixie> | er |
| 22:36 | <Hixie> | is an entity |
| 22:36 | <hsivonen> | the first one crashed Quartz. the second one worked |
| 22:36 | <hsivonen> | NCRs |
| 22:37 | <Hixie> | ok. but am i using actual byte codes outside US-ASCII? |
| 22:37 | <Hixie> | as in, actual characters? |
| 22:37 | <Hixie> | as opposed to entities |
| 22:37 | <hsivonen> | also, the arabic percent sign is an esoteric one considering chiefly western content |
| 22:37 | <hsivonen> | ah. yeah, the page breaks without the charset meta |
| 22:37 | <Hixie> | why? |
| 22:37 | <Hixie> | where, rather? |
| 22:38 | <hsivonen> | I'll try to find the problem. |
| 22:38 | <hsivonen> | meanwhile: |
| 22:38 | <hsivonen> | prince: wa-rev691-2007-03-23.html:11486: error: ID video already defined |
| 22:38 | <hsivonen> | prince: wa-rev691-2007-03-23.html:11622: error: ID video already defined |
| 22:38 | <hsivonen> | prince: wa-rev691-2007-03-23.html:22851: error: Unexpected end tag : p |
| 22:38 | <hsivonen> | prince: wa-rev691-2007-03-23.html:24031: error: Unexpected end tag : p |
| 22:39 | <othermaciej> | does Prince give better results than printing from a browser? |
| 22:39 | <hsivonen> | othermaciej: yes. in particular, page number-based crossreferences for internal links |
| 22:39 | <hober> | oooh, nice |
| 22:40 | <hsivonen> | om_coffee: though, I haven't checked what WebKit nightlies can do in the printing dept. |
| 22:40 | <Hixie> | hsivonen: i'm in the middle of editing the spec, the markup is in flux right now |
| 22:40 | <Hixie> | in particular, the id=video thing is fixed in the source |
| 22:42 | <hsivonen> | Hixie: dash under the main heading, copyright sign, etc. etc. |
| 22:43 | <hsivonen> | Hixie: looks like your preprocessor expands NCRs |
| 22:43 | <hsivonen> | Hixie: so I was wrong. no NCRs at all |
| 22:43 | <hsivonen> | Hixie: lots and lots of weird chars as straight UTF-8 |
| 22:43 | <Dashiva> | NCR? |
| 22:43 | <hsivonen> | Dashiva: numeric character referenc |
| 22:43 | <hsivonen> | e |
| 22:43 | <Dashiva> | ah |
| 22:45 | <Philip`> | hsivonen: I don't see any non-ASCII characters in the current-work page - it's just — and © in the places you mentioned |
| 22:45 | <hsivonen> | ah. |
| 22:45 | <hsivonen> | it is the reserializer in Firefox that produces them |
| 22:46 | <Hixie> | doesn't prince support just getting a URI? |
| 22:46 | <Hixie> | i thought it did |
| 22:47 | <hsivonen> | I though so, too, but couldn't figure it out |
| 22:47 | <Hixie> | also, wouldn't not setting the 'size' be better than having explicit size choice in the style sheet? |
| 22:48 | <hsivonen> | Hixie: quite possible |
| 22:48 | <hsivonen> | Hixie: is there something prince --help doesn't tell me? |
| 22:51 | <Philip`> | hsivonen: Looks like https://bugzilla.mozilla.org/show_bug.cgi?id=331991 |
| 22:54 | <othermaciej> | hsivonen: we don't do page-number-based crossreferences |
| 22:58 | <Hixie> | apologies, i just lost connection here. |
| 22:58 | <Hixie> | and i'm now in a conversation in the csswg |
| 23:02 | <Dashiva> | What about allowing innerHTML on DocumentFragment? |
| 23:03 | <othermaciej> | DocumentFragment is a core DOM interface |
| 23:05 | <Dashiva> | Suppose I could set/get around it using a placeholder div |
| 23:27 | tylerr | needs to memorize the WHATWG spec. |
| 23:27 | <Hixie> | good luck with that |
| 23:28 | <tylerr> | :-) |
| 23:31 | <tylerr> | Hixie: What accessibility work has been done so far on the spec? |
| 23:32 | <Hixie> | the spec. :-) |
| 23:32 | <Hixie> | the entire spec was designed with accessibility in mind. |
| 23:32 | <tylerr> | Ah lovely. |
| 23:33 | <tylerr> | I haven't had enough time to sit down and really study it. |
| 23:33 | <othermaciej> | tylerr: the contents of the spec, or the spec document? |
| 23:33 | <tylerr> | Ah sorry, I believe I meant the contents of the spec. |
| 23:35 | <zcorpan_> | hsivonen: a reason why prince complains about unmatched </p> end tags may be because the status script inserts <div> inside paragraphs in some places (because the annotaions.xml file isn't up to date) |
| 23:38 | <hsivonen> | zcorpan_: ok |
| 23:38 | <webben> | tylerr: what's lacking AFAIK is much in the way of accessibility testing of the spec |
| 23:41 | <webben> | we also seem to lack any discernable involvement from AT developers/manufacturers (who tend not to be very interested in the web for some reason) |
| 23:42 | <webben> | there are also issues inherited from html4 which the spec doesn't yet faciliate resolution of e.g. use of attributes for text that might change language. |
| 23:43 | tylerr | nods. |
| 23:44 | <tylerr> | I'd like to work on some of those issues, as accessibility is an interest of mine. |
| 23:44 | <webben> | cool :) |
| 23:44 | <tylerr> | I was rather taken aback to learn that JAWS doesn't even consider CSS Aural. |
| 23:45 | <webben> | tylerr: Well. A lot of issues are UI issues, and HTML5 is generally wary of specifying UI issues. |
| 23:45 | <webben> | (that's what UAAG is for) |
| 23:46 | <tylerr> | Ah nice. I need to spend a weekend diving into the inner workings and specifications of the W3. |
| 23:46 | <webben> | heh ... i'd allot more than a weekend ;) |
| 23:47 | <tylerr> | Are you a part of the HTMLWG currently webben? |
| 23:47 | <webben> | no no ... i just lurk around here and on the main development mailing list |
| 23:47 | <tylerr> | Oh definitely. I have years till I would consider myself a guru. |
| 23:48 | <tylerr> | Ah nice. |
| 23:49 | <tylerr> | I'm getting involved in the WG as a solid learning experience, and to help shape the web, naturally. :-) |
| 23:50 | <webben> | tylerr: with regards to speech CSS, what we need (IHMO) is less specs and more developers on open source projects like Fire Vox, Orca, LSR, NVDA, and Emacspeak. |
| 23:51 | <webben> | oh and mozilla: https://bugzilla.mozilla.org/show_bug.cgi?id=47159 |
| 23:51 | <zcorpan_> | someone here should work with QA for various AT vendors |
| 23:52 | <zcorpan_> | so they implement html5 and css speech |
| 23:53 | <webben> | I think CSS speech is actually a pretty marginal issue in terms of increasing web content accessibility. |
| 23:53 | <tylerr> | webben: I agree that more work needs to be focused on the developers. Getting them to accept the current specs is a must. |
| 23:53 | <zcorpan_> | ok, so they implement html5 |
| 23:53 | <tylerr> | Sure webben. I think once the web becomes more semantic, then we can start looking at things like aural style sheets with more attention and priority. |
| 23:54 | <webben> | (being able to define how your reader reads html is important ... CSS may be a good tool for doing so) |
| 23:54 | <webben> | but then Orca and Fire Vox and Emacspeak already have crude support for that |
| 23:56 | tylerr | nods. |
| 23:56 | <webben> | bigger issues are 1) helping authors to create accessible content in the first place (hence the stress i put on easy captioning, bookmarking, audio description with <video> 2) ensuring content is easily navigable (stuff like standardized document sectioning, navbars etc, is important there) |
| 23:57 | <tylerr> | Definitely. |
| 23:57 | <tylerr> | See, what I need to do is go through each element "section" of HTML5 and determine what accessibility needs there need to be. |
| 23:58 | <webben> | tylerr: that would be good. |
| 23:58 | <tylerr> | Like how can we make embedded content more accessible, how about phrase elements and prose? |
| 23:58 | <tylerr> | And does tabular data need an accessibility audit? |
| 23:59 | <webben> | dunno ... i haven't looked at what HTML5 has done with tables at all actually |
| 23:59 | <tylerr> | I think I've just found my pet project for the next half a year. ;) |
