| 00:00 | <tylerr> | Here's the section on it. Doesn't seem much has changed: http://www.whatwg.org/specs/web-apps/current-work/#the-table |
| 00:01 | <zcorpan_> | changed since when? |
| 00:01 | <webben> | html4 |
| 00:01 | <zcorpan_> | except that in html4 much was undefined? |
| 00:02 | <zcorpan_> | e.g., how to associate header cells with data cells |
| 00:02 | <webben> | how was that undefined? |
| 00:02 | <webben> | oh you mean without using headers and scope? |
| 00:03 | <Hixie> | how was it defined? :-) |
| 00:03 | <Hixie> | even with scope= and headers= it's somewhat vague |
| 00:03 | <zcorpan_> | and then there's axis="" that no-one understands |
| 00:03 | <zcorpan_> | or uses |
| 00:03 | <markp> | joe clark probably understands it |
| 00:03 | <tylerr> | I read about axis once and forgot what it did about 4 minutes later. ;-) |
| 00:04 | <webben> | does anything support it i wonder |
| 00:04 | <zcorpan_> | don't think so |
| 00:04 | <tylerr> | Time to axe it. ;-) |
| 00:04 | <markp> | Hixie: i was looking for you earlier |
| 00:04 | <webben> | well, not necessarily |
| 00:04 | <webben> | g |
| 00:04 | <markp> | is there any effort afoot to spec out window.navigator? |
| 00:04 | <webben> | could be time to support it with a decent screen reader |
| 00:04 | <markp> | aka window.clientInformation |
| 00:05 | <tylerr> | Oh now you're talking webben. |
| 00:05 | <othermaciej> | markp: if it hasn't been done, I'd assume it will be |
| 00:06 | <webben> | how can you not love an attribute defined like: "This attribute may be used to place a cell into conceptual categories that can be considered to form axes in an n-dimensional space." |
| 00:06 | <markp> | there seem to be recent developments |
| 00:06 | <markp> | in window.navigator |
| 00:06 | <markp> | that i was previously unaware of |
| 00:06 | <markp> | navigator.buildID in firefox 2 |
| 00:06 | webben | tries to think of a useful way to use axis |
| 00:06 | <markp> | navigator.onLine |
| 00:07 | <markp> | and navigator.registerContentHandler / navigator.registerProtocolHandler for feed stuff |
| 00:07 | <zcorpan_> | webben: don't think too hard, you may end up seeing the world as an n-dimensional space |
| 00:07 | <tylerr> | webben: That attribute description is beautiful. |
| 00:08 | <Dashiva> | I can see forever |
| 00:09 | <webben> | hmm looks like JAWS supports axis: http://lau.csi.it/testare/accessibilita/test_user-agent/tabelle_accessibili/screen_reader.shtml |
| 00:09 | <webben> | if i'm understanding the italian right |
| 00:09 | <markp> | awesome |
| 00:10 | <tylerr> | I'd love to hear my web sites being read back to me in an n-dimensional space. |
| 00:18 | <Hixie> | markp: navigator.onLine and navigator.register* are in HTML5 |
| 00:18 | <Hixie> | markp: (sorry, in csswg meeting mon/tue/wed this week) |
| 00:18 | <markp> | ah |
| 00:18 | <markp> | ok |
| 00:18 | <markp> | what about the rest of window.navigator? |
| 00:20 | <othermaciej> | http://www.whatwg.org/specs/web-apps/current-work/#navigator |
| 00:20 | <othermaciej> | markp: looks like not yet |
| 00:21 | <markp> | thanks |
| 00:21 | <othermaciej> | I'm not sure registerProtocolHandler / registerContentHandler is so great; the proposed solution to security issues is confirmation dialogs |
| 00:22 | <markp> | is there interest in filling out that section, and/or making a separate spec like Window has? |
| 00:22 | <othermaciej> | I think it is a matter of priorities |
| 00:22 | <othermaciej> | it would be good to raise the issue that it is missing the traditional navigator stuff |
| 00:23 | <othermaciej> | I think it would be good for it to be a separate spec, to be fair, Windows has kind of stalled in its separate-spec form |
| 00:35 | <Lachy_> | markp: the navigator could probably be moved to a separate spec if someone in the Web API WG was willing to work on it |
| 00:37 | <Hixie> | although it affects 'window' |
| 00:37 | <Hixie> | and 'window' affects things that affect HTML5 |
| 00:38 | <Lachy_> | yeah, that's true |
| 00:38 | <othermaciej> | I think language-neutral bits of API should go in separate specs that are done by Web API, although it may be hard to do the right factoring |
| 07:29 | <Hixie> | hm |
| 07:29 | <Hixie> | so |
| 07:29 | <Hixie> | if currentLoop = 3 |
| 07:29 | <Hixie> | and loopCount = 5 |
| 07:29 | <Hixie> | and position is between loopStart and loopEnd |
| 07:29 | <Hixie> | and you set loopCount to 2 |
| 07:29 | <Hixie> | what should happen? |
| 07:30 | <Hixie> | should it just set currnetLoop to 2 and let it finish on to end? |
| 07:31 | <aroben> | Hixie: I think that makes sense |
| 07:31 | <aroben> | Hixie: loopCount seems like the kind of thing that would only come into play when deciding whether to start a new loop |
| 07:32 | <othermaciej> | another possibility would be to stop immediatly |
| 07:32 | <othermaciej> | but what you suggested is probably better |
| 07:36 | <Hixie> | k |
| 08:01 | <krijnh> | http://gettingreal.37signals.com/ch07_Meetings_Are_Toxic.php |
| 08:01 | <krijnh> | \o/ |
| 08:02 | <Hixie> | if you agree with me and maciej about meetings being a bad idea, feel free to actually say so on the survey page |
| 08:02 | <krijnh> | Yeah, sorry |
| 08:03 | <Hixie> | it seems that despite many people telling me they agree, nobody actually said anything except maciej :-) |
| 08:03 | <krijnh> | Well, there are issues; http://www.w3.org/html/wg/il16 |
| 08:03 | <krijnh> | But I don't know how telcons work ;) |
| 08:03 | <krijnh> | I know the concept |
| 08:03 | <krijnh> | But I don't know how/if it would help |
| 08:04 | <Hixie> | i guess we'll find out thursday |
| 08:04 | <Hixie> | anyway, sleep time |
| 08:04 | <Hixie> | nn |
| 08:04 | <krijnh> | Exactly |
| 08:04 | <krijnh> | Good night :) |
| 08:04 | <othermaciej> | krijnh: I think the odds are very slim of a telecon leading to useful progress on those issues |
| 08:04 | <krijnh> | I think so too |
| 08:04 | <othermaciej> | I wonder if I should reply at all to the complaints about too much mail |
| 08:04 | <krijnh> | But it's not based on experience, just a feeling |
| 08:05 | <othermaciej> | at some point someone has to say, "this is what it will be like, suck it up, learn what threads to follow and whom to pay attention to" |
| 08:05 | <othermaciej> | but better tools for some things may also help |
| 08:05 | <othermaciej> | I think right now the conversation wanders due to lack of clarity on how to start |
| 08:05 | <othermaciej> | whatwg list actually seems more focused currently |
| 14:43 | <maikmerten> | hmm... I guess I'm the only one with a Firefox that directly jumps to <audio> on http://www.whatwg.org/specs/web-apps/current-work/#video (hmmm... konqueror does it right) |
| 14:45 | <Philip`> | maikmerten: That's because there are three elements with id="video" - I believe Hixie said he's fixed it in his working copy |
| 14:45 | <maikmerten> | ah, okay, sorry for the noise then |
| 14:49 | <maikmerten> | as for the audio codecs: It definately makes sense to require PCM in .wav... that should be playable on basically every platform out there that somehow can turn bits into audible noise |
| 14:51 | <maikmerten> | however, if you want to go over board with specifying there may be room to e.g. require integer based PCM (8 and 16 bit... not float based PCM) and if someone feels like being uber-specifc there's always the question of µ-law vs. a-law ;) |
| 14:51 | <maikmerten> | just in case the final spec turns out to be not long enough ;) |
| 14:52 | <krijnh> | Philip`: I've turned compression on for the irc logs |
| 14:52 | <krijnh> | Hope it speeds up a bit |
| 14:55 | <Philip`> | krijnh: Looks good - thanks! |
| 14:56 | <Philip`> | With a 95KB (uncompressed) log from yesterday, it takes 2.5 seconds to download without compression and 1.2 seconds with compression |
| 14:56 | <krijnh> | Wow, from 64493 bytes to 17009 :| |
| 14:56 | <krijnh> | Sweet |
| 14:57 | <krijnh> | Thanks for the tip Philip` :) |
| 15:11 | <krijnh> | Hey Charl |
| 15:34 | <Charl> | krijnh: hi there |
| 15:35 | <krijnh> | Charl: also enabled zlib.output_compression on Miranda, let me know if WP for standards.za.net has trouble with that |
| 15:38 | <Charl> | krijnh: thanks will do |
| 17:20 | <Hixie> | yeah |
| 17:20 | <Hixie> | we need a way of updating the labels |
| 17:21 | <Hixie> | charl and zcorpan are working on that i think |
| 17:21 | <Hixie> | the script has been getting progressively cooler :-) |
| 17:22 | <Lachy> | ok, moving from #html-wg. I've thought about it a bit more, and the major problem with image maps is the lack of ability to style <area> elements in browsers, whcih is really a CSS issue |
| 17:22 | <tylerr> | Morning folks. |
| 17:22 | <Hixie> | ah |
| 17:22 | <Hixie> | yeah |
| 17:22 | <tylerr> | Hey there Lachy, just jumped in and I wanted to say I agree with you on the image maps. |
| 17:23 | <Lachy> | my use case that I had to implement earlier today was a world map where hovering over each country had a hover effect |
| 17:23 | Lachy | is looking up the flash version I'm converting to HTML |
| 17:25 | <Lachy> | http://australia-revealed.com/index2.html (sorry, you have to go the long way cause it's flash) --> click Programming tab (bottom) then "Outback Cowbys" (top), and finally "Schedule" (right) |
| 17:26 | <tylerr> | Ah nice, so you'd like to be able to style the polygonal selections. That'd be beautiful if implemented. |
| 17:27 | <tylerr> | That map is cool. :-) |
| 17:27 | <Lachy> | I had a look at the DOM inspector in Mozilla today and showed weird styles for the area elements. it listed styles that applied to the map element instead |
| 17:30 | <Lachy> | anyway, I should go to bed. have fun at the CSSWG meeting, cya later :-) |
| 17:30 | <tylerr> | Night Lachy. |
| 17:36 | <Hixie> | Lachy: nn |
| 17:36 | <Hixie> | Lachy: i agree with your use case |
| 17:36 | <Hixie> | Lachy: i think it's a csswg issue |
| 17:36 | <Hixie> | or xbl |
| 17:36 | <Hixie> | at least not a core html issue |
| 17:38 | <tylerr> | So folks, anything exciting on schedule for today? |
| 17:41 | <Charl> | Hixie: yeah we are working on the labels; things are going a little slow from my side at the moment because i'm struggling with getting connectivity from home |
| 17:41 | <Charl> | Hixie: if all goes well that should be sorted within the next week |
| 17:41 | <Hixie> | no worries |
| 17:41 | <Charl> | one of those perks of staying in africa i guess ;) |
| 17:42 | <Charl> | thanks |
| 17:42 | <Hixie> | :-) |
| 17:47 | <Lachy> | Hixie, it's actually an issue I sort of brought up on www-style back in 2004 :-) |
| 17:49 | <Lachy> | http://lists.w3.org/Archives/Public/www-style/2004Feb/0529 (geez, it's funny to look at the kind of things I wrote back then) |
| 17:52 | <Hixie> | yeah i usually find that my old e-mails are weird to me |
| 17:52 | <Hixie> | i often find i totally agree with everything i wrote, all the arguments and everything, and get a totally different conclusion |
| 17:54 | <Lachy> | well, that one was back when I was young and naiive, and focussed on solutions rather than use cases - the same thing I complain about with newbies today ;-) |
| 17:54 | <Hixie> | heh |
| 17:54 | <Hixie> | my problem used to be ignoring the real world |
| 17:55 | <Hixie> | i'd suggest things that are ideally correct but wouldn't actually be implementable without difficulties |
| 17:56 | <Lachy> | yeah, that'd be where that blog entry about people who don't realise they're wrong came from |
| 17:56 | <Hixie> | yup |
| 17:56 | <Lachy> | anyway, really off to bed this time, cya (again) |
| 17:56 | <Hixie> | nn |
| 18:05 | <jacobolus> | hi. question about block/inline links. I have some chunk of content that I want to turn into a single link. I made it an <a></a>, and then stuck a bunch of block elements inside of that. This seems to work just fine in Webkit/Gecko, but the w3c validator of course doesn't like it |
| 18:05 | <jacobolus> | so is there any way to make a block element with an href, or is there another mechanism to make a block element act as a link? |
| 18:05 | <jacobolus> | without resorting to javascript? |
| 18:06 | <jacobolus> | (actually, it seems that webkit will even accept nested <a></a> elements, which can be kinda fun ;) ) |
| 18:07 | <jacobolus> | Hixie: maybe you have some idea? |
| 18:08 | <Hixie> | what's the content? |
| 18:08 | <jacobolus> | a div, and a ul |
| 18:08 | <jacobolus> | with a thumbnail and a description |
| 18:08 | <Hixie> | ah, then no, not really |
| 18:09 | <jacobolus> | so we should just use javascript? |
| 18:09 | <Dashiva> | Or turn each part of it into a link |
| 18:09 | <Hixie> | turning each part into a link is probably best |
| 18:09 | <jacobolus> | how to turn each part into a link? |
| 18:09 | <jacobolus> | we want the whole background to be clickable |
| 18:10 | <Dashiva> | That's trickier |
| 18:10 | <Hixie> | i'd recommend making one part into an explicit link, and then using an onclick handler on the outer box to make that link get followed |
| 18:10 | jacobolus | pasted http://pastie.textmate.org/49849 |
| 18:10 | <jacobolus> | here's our example |
| 18:10 | <Dashiva> | But it reminds me of something else. Often you want to make a link which looks like a standard UA button. How about a predefined class which styles an <a> to look like <input type="button"> or <button>? |
| 18:11 | <Hixie> | just use a button :-P |
| 18:11 | <jacobolus> | i guess we could just make the title and the image clickable. |
| 18:12 | <jacobolus> | it's just kind of a drag to require putting the href in twice |
| 18:12 | <Hixie> | i'd make the title be the <a> |
| 18:12 | <Hixie> | and then put a <div> around the whole thing |
| 18:12 | <Hixie> | and make that have an onclick which does |
| 18:12 | <Dashiva> | Hixie: Buttons don't have hrefs, typically |
| 18:12 | <Hixie> | onclick="location = this.getElementsByTagName('a')[0].href" |
| 18:13 | <Hixie> | Dashiva: they do in WF2 (well it's called action="", but same idea) |
| 18:13 | <Hixie> | Dashiva: <form><button action="foo.html">Go!</button></form> |
| 18:13 | <Hixie> | or in HTML4, even: |
| 18:13 | <jacobolus> | Hixie: but then that has to be written in every div? or we have to add that with javascript? |
| 18:13 | <Hixie> | <form action="foo.html"><button>Go!</button></form> |
| 18:14 | <Hixie> | jacobolus: yeah each <a> in your current example would be replaced by a <div onclick="location = this.getElementsByTagName('a')[0].href"> |
| 18:14 | <jacobolus> | yeah. that's kinda ugly. i guess we can have some javascript add that on page load or something |
| 18:14 | <jacobolus> | but the existing markup is very clean |
| 18:14 | <Hixie> | yeah |
| 18:15 | <Hixie> | we're looking at allowing <a> in other places |
| 18:15 | <jacobolus> | or we could just let it be invalid :) (but maybe that's a bad idea) |
| 18:16 | <krijnh> | jacobolus: just invalidate it; http://krijnhoetmer.nl/stuff/html5/block-level-anchors/ :) |
| 18:17 | <jacobolus> | wouldn't want to incur the wrath of the w3c ;) |
| 18:17 | <krijnh> | Ow, wait, me neither, use the onclick thingy ;) |
| 18:18 | <jacobolus> | krijnh: good to know it works in every browser though :) |
| 18:18 | <krijnh> | Didn't test on a Mac |
| 18:18 | <jacobolus> | seems to work in firefox/camino/safari |
| 18:19 | <jacobolus> | krijnh: wait, are all the boxes on that page supposed to be green? |
| 18:19 | <krijnh> | Doesn't in Lynx :( |
| 18:19 | <jacobolus> | krijnh: should the top two be green? |
| 18:19 | <krijnh> | Well, should |
| 18:19 | <krijnh> | I don't know |
| 18:19 | <krijnh> | The bottom three are |
| 18:19 | <krijnh> | But they have a { display: block; } applied |
| 18:20 | <jacobolus> | right |
| 18:20 | <jacobolus> | krijnh: maybe you should clarify that? |
| 18:20 | <krijnh> | Yeah, I should, sorry I'm not that good at clarifying things |
| 18:21 | <krijnh> | Most stuff in, well, /stuff/, isn't clarified :) |
| 18:21 | <jacobolus> | fair enough :) |
| 18:21 | <jacobolus> | Hixie: so, how fearful is the wrath of the w3c? |
| 18:21 | <Hixie> | the top two shouldn't be green without display:block no |
| 18:21 | <Hixie> | hey maciej |
| 18:21 | <Hixie> | jacobolus: ? |
| 18:21 | <othermaciej> | hey Hixie |
| 18:22 | <jacobolus> | Hixie: rather, how fearful should we be of teh wrath of the w3c |
| 18:22 | <jacobolus> | nevermind :P |
| 18:22 | <Hixie> | we = whatwg? |
| 18:22 | <krijnh> | jacobolus: There is none |
| 18:22 | <jacobolus> | no, we = content authors :) |
| 18:22 | <othermaciej> | what wrath of the w3c? |
| 18:23 | <krijnh> | othermaciej: when using <a><block-level></a> |
| 18:23 | <krijnh> | Invalid ^ |
| 18:23 | <othermaciej> | well, that's invalid but works |
| 18:24 | <krijnh> | Yeh |
| 18:24 | <othermaciej> | Hixie: anne, hsivonen, marcos__ and I came up w/ this last night, any comments before I send it to the html wg list: http://esw.w3.org/topic/HTML/ProposedDesignPrinciples |
| 18:24 | <krijnh> | Hixie: How does Googlebot handle that btw? |
| 18:24 | <csarven> | is it true that `textarea` doesn't format the characters in utf-8? |
| 18:26 | <Hixie> | othermaciej: i had a comment on #html-wg |
| 18:26 | <Hixie> | 18:29 < Hixie>|http://www.w3.org/2004/04/webapps-cdf-ws/papers/opera.html might be a good place to start for design principles (re earlier conversation) |
| 18:28 | <othermaciej> | Hixie: a lot of the items there already exist under different names; I'll try to incorporate any that are not reflected or that are insufficiently clear as stated |
| 18:28 | <Hixie> | cool |
| 18:29 | <othermaciej> | "Backwards compatibility, clear migration path" is, I think, the same basic thing as "Don't Break The Web" / "Degrade Gracefully" |
| 18:29 | <gsnedders> | othermaciej: I think it may be sensible to have something about some sort of basic forwards compatibility |
| 18:29 | <othermaciej> | though the latter is less focused on IE6 and doesn't go into detail about how working in unsupported browsers might make use of script, style, bindings, etc |
| 18:30 | <othermaciej> | gsnedders: what do you mean by forwards compatibility? |
| 18:31 | <gsnedders> | othermaciej: things like specifying whether unknown elements should be put in DOM, whether they should be block or inline, whether they can be styled, etc. |
| 18:31 | <moeffju> | +1 |
| 18:31 | <othermaciej> | gsnedders: I think that would fall under "degrade gracefully" |
| 18:32 | <othermaciej> | you need a rule for unknown elements to be able to count on consistent handling of them as features are added |
| 18:32 | <gsnedders> | othermaciej: possibly. I'd assume degrade would mean already existing things, though, unless explicitly said |
| 18:33 | <othermaciej> | well, yes, it's not mainly about second-guessing what things can be in future specs |
| 18:33 | <s|k> | er |
| 18:33 | <s|k> | which should we be using |
| 18:33 | <s|k> | in the future, xhtml or html? |
| 18:33 | <othermaciej> | HTML4 already says what to do with unknown elements (they are in the DOM, inline, and can be styled) |
| 18:33 | <s|k> | I had no idea there was an html 5 planned |
| 18:34 | <othermaciej> | s|k: in the present, you should probably be using html, in the future, who knows what will happen? |
| 18:34 | <kingryan> | there is no xhtml |
| 18:34 | kingryan | waves hand sideways |
| 18:35 | <s|k> | I've been using xhtml for years now |
| 18:35 | <s|k> | even though IE doesn't understand text/xhtml |
| 18:35 | <gsnedders> | s|k: ignoring lack of support of IE and GoogleBot? |
| 18:35 | <s|k> | ;\ |
| 18:35 | <gsnedders> | text/xhtml? |
| 18:35 | <gsnedders> | no such MIME type… |
| 18:35 | <s|k> | doesn't it work with firefox? |
| 18:36 | <gsnedders> | if it works with anything, I'll be amazed. |
| 18:36 | <gsnedders> | application/xhtml+xml is the XHTML MIME type |
| 18:36 | <s|k> | well that's what I meant |
| 18:36 | <gsnedders> | rather large difference… |
| 18:36 | <s|k> | hrm |
| 18:37 | <s|k> | wait no I generally do text/xml for xml |
| 18:37 | <s|k> | should I be doing application? |
| 18:37 | <s|k> | using* |
| 18:37 | <gsnedders> | text/xml MUST have the content-type specified at the transport level, if it isn't ISO-8859-1 |
| 18:37 | <gsnedders> | wait… US-ASCII |
| 18:37 | <s|k> | I'm getting a lot of strange characters from you |
| 18:37 | <s|k> | wait⦠US-ASCII |
| 18:38 | <gsnedders> | any encoding in the prolog is meaningless |
| 18:38 | <gsnedders> | s|k: all the messages I'm sending are UTF-8 |
| 18:39 | <s|k> | xhtml works for me just fine |
| 18:39 | <s|k> | and I prefer it to html |
| 18:39 | <gsnedders> | I prefer support of major UAs. |
| 18:40 | <gsnedders> | XHTML as text/html relies on UAs not following the spec |
| 18:40 | <s|k> | well will HTML 5 feature the same benefits of xml? device independence? easily integrated into new applications? |
| 18:40 | <s|k> | if the web were valid xhtml, my life would be really easy |
| 18:40 | <Hixie> | othermaciej: for backcompat in particular it's critical to explain exactly what is meant |
| 18:40 | <Hixie> | othermaciej: i usually think of it as three separate things: |
| 18:41 | <Dashiva> | If everybody instantly changed to using unicode variants everywhere, that would help a lot too |
| 18:41 | <Dashiva> | But I doubt it'll happen overnight, or even over the decade |
| 18:41 | <Hixie> | othermaciej: uas implementing the new spec should be able to handle old docs without any differences |
| 18:41 | <othermaciej> | Hixie: right now we have two separate things (maybe 4 depending on how you count) |
| 18:42 | <othermaciej> | that one is the "Don't Break The Web" principle - old content should work in UAs implementing the new spec |
| 18:42 | <Hixie> | othermaciej: docs written to the old spec should be able to have features from the new spec added without unrelated changes |
| 18:42 | <gsnedders> | s|k: how is XML device independent? how is it easily integrated? |
| 18:42 | <othermaciej> | I don't think that one is expressed |
| 18:43 | <othermaciej> | I added |
| 18:43 | <othermaciej> | "Handle Errors" and a more general "Well-Defined Behavior" |
| 18:43 | <s|k> | gsnedders: every language and framework I develop in has very powerful xml integration |
| 18:44 | <zcorpan_> | benoitt's <document> proposal is <iframe> with controller="" (or ui="" or whatever) |
| 18:44 | <Hixie> | othermaciej: and old uas should be able to render content using new features in ways that aren't fatal - you should be able to write new docs that provide equivalent although not necessarily as wonderful functionality |
| 18:44 | <Hixie> | to old uas, i mean |
| 18:44 | <gsnedders> | s|k: well, surely that's more up to the languages and frameworks to provide the integration? |
| 18:44 | <Hixie> | i.e. graceful degradation |
| 18:44 | <s|k> | gsnedders: with xhtml I have the option of using xpath and xquery |
| 18:44 | <s|k> | and DOM |
| 18:44 | <Hixie> | which i assume you have |
| 18:44 | <s|k> | and etc |
| 18:44 | <othermaciej> | that one is "Degrade Gracefully" |
| 18:45 | <gsnedders> | s|k: the issue of namespaces in HTML is unresolved. DOM is a separate standard, and has rules for HTML already |
| 18:46 | <s|k> | gsnedders: my point is that from a developer perspective, XML is better supported, at least in the tools I work with, than SGML and HTML. There are more options, and more flexibility, and it's more readable |
| 18:46 | <s|k> | that last part though is subjective |
| 18:46 | <s|k> | I know |
| 18:46 | <othermaciej> | there's nothing specific about being able to use new features without unrelated changes |
| 18:47 | <othermaciej> | nothing specific about scripting, avoiding profiles, or open process |
| 18:48 | <othermaciej> | I don't think open process is a design principle |
| 18:48 | <gsnedders> | s|k: writing a spec you can do little about support. if languages chose to support it, so be it. HTML5, not being based on SGML, will be easier to parse |
| 18:48 | <s|k> | oh it's not based on SGML? |
| 18:48 | <othermaciej> | I think many of the stated principles imply and assume that scripting is ok, not sure if it needs to be called out again |
| 18:48 | <gsnedders> | no |
| 18:48 | <s|k> | what's it based on? |
| 18:48 | <gsnedders> | s|k: itself |
| 18:48 | <s|k> | I see |
| 18:48 | <othermaciej> | also, profiling html is clearly out of scope for the group |
| 18:49 | <hasather> | s|k: it's based on browser practice |
| 18:49 | <s|k> | uh oh |
| 18:49 | <gsnedders> | s|k: most documents (including all XHTML served as text/html) rely on browser's error handling, which goes against SGML. HTML5 is partly about standardising error correction |
| 18:49 | <s|k> | I get that comment about User Agents gsnedders was making now |
| 18:49 | <s|k> | well I am all for standardizing the error correction |
| 18:49 | <gsnedders> | s|k: in both cases, both WHATWG and W3C's HTML WG, will have both XML and HTML serialisations of the standard |
| 18:50 | <s|k> | personally I wish browsers didn't correct errors |
| 18:50 | <s|k> | ahhhh |
| 18:50 | <s|k> | I get it |
| 18:50 | <s|k> | it's like RDF |
| 18:50 | <s|k> | and the dublin core |
| 18:50 | <gsnedders> | how? |
| 18:50 | <s|k> | it can have an xml schema |
| 18:51 | <s|k> | or it can have some other implementation |
| 18:51 | <s|k> | it's implementation independent I guess |
| 18:51 | <s|k> | or am I misunderstanding it? |
| 18:51 | <gsnedders> | it can only have two serialisations |
| 18:51 | <s|k> | oh okay |
| 18:53 | <othermaciej> | Hixie: I added the third form of compatibility as "Evolution Not Revolution" |
| 18:53 | <othermaciej> | "Don't Reinvent The Wheel" and "Pave The Cowpaths" are arguably also forms of compatibility (in the sense of compatibility with existing practice) |
| 18:56 | <Dashiva> | I support cowpaths |
| 18:58 | <Philip`> | Hixie: Have you had any feedback on the canvas globalCompositeOperation since http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2006-June/006771.html ? (If not, I believe I could write up something useful about how it is / should be implemented) |
| 18:58 | <kingryan> | othermaciej, Hixie: this is all sounding very familiar (http://microformats.org/wiki/microformats) :D |
| 18:59 | <othermaciej> | kingryan: not entirely an accident |
| 18:59 | <kingryan> | :D |
| 19:03 | <othermaciej> | not really quite the same though |
| 19:09 | <zcorpan_> | if the spec has SHOULD requirements for support of various other things, would we need to write test cases for those as well in order to move beond CR? |
| 19:10 | <zcorpan_> | if so, then i think such a list should just be non-normative guidelines |
| 19:11 | <zcorpan_> | such a list may become obsolete in 15 years from now too |
| 19:12 | <othermaciej> | I'm not sure how much it makes sense to test SHOULD-level requirements |
| 19:13 | <gsnedders> | zcorpan_: for which WG? |
| 19:13 | <zcorpan_> | othermaciej: fair enough |
| 19:13 | <Hixie> | Philip`: in meeting, dunno, there's lots of canvas feedback i haven't yet dealt with but feel free to send more |
| 19:14 | <Hixie> | othermaciej: so long as you have descriptions as well as the titles :-) |
| 19:15 | <othermaciej> | Hixie: there are descriptions |
| 19:15 | <Hixie> | good good :-) |
| 19:15 | <Hixie> | ship it |
| 19:46 | <zcorpan_> | "Error handling should be defined interoperably.", is this some construction of english i don't understand or is the sentence wrong? shouldn't it be "Error handling should be defined so that interoperable implementations can be achieved." or something like that? |
| 19:51 | <othermaciej> | zcorpan_: that sounds better |
| 19:51 | <othermaciej> | zcorpan_: please feel free to improve it |
| 20:19 | <zcorpan_> | om_lunch: ok |
| 20:53 | <jacobolus> | Hixie: go here (http://dev.laptop.org/pub/content/newlib/) and click on math & science |
| 20:53 | <jacobolus> | Hixie: i think we'll just go with the invalid markup (block a's) for now |
| 20:54 | <jacobolus> | the rest of that page is of course in various stages of disrepair :) |
| 21:56 | <Hixie> | hmm |
| 21:56 | <Hixie> | if someone sets loopCount to 0, we should ignore it? or raise an exception? |
| 21:57 | <othermaciej> | probably good to clamp it to 1 or greater |
| 21:58 | <othermaciej> | I'm not a big fan of exceptions on property setting |
| 22:26 | <webben> | Does/could HTML5 have any sort of official profiling system for UAs? such that one might have graphical UAs with a certain profile (e.g. support for PNG, OGG, Vorbis), end-user UAs which provide certain UI functionality, etc? would that be useful or un-useful? |
| 22:26 | <webben> | (just looking through recent discussions re <video> |
| 22:27 | <othermaciej> | HTML5 is against profiles |
| 22:27 | <webben> | what does it mean to be against profiles? |
| 22:27 | <othermaciej> | some sort of baseline integration spec for desktop browsers might be interesting, but I don't know who would have motive to make it |
| 22:28 | <webben> | what's the difference between the two? |
| 22:28 | <webben> | (or do you mean HTML5 is against, but profiles might still be useful?) |
| 22:28 | <Lachy> | profiling segregates the web into websites built for one type of UA, and other other web sites for everything else |
| 22:28 | <Lachy> | it's already happening with the mobile profile, for instance |
| 22:28 | <hsivonen> | webben: do you mean that the browser would advertise its capabilities to server or scripts? or do you mean requiring implementors to ship particular features in one go? |
| 22:29 | <webben> | hsivonen: primarily the later actually |
| 22:29 | <hsivonen> | webben: won't work |
| 22:29 | <Lachy> | that wouldn't work in practice |
| 22:29 | <webben> | hsivonen: i don't think authors should depend on featuresets: e.g. they should have text fallbacks |
| 22:29 | <hsivonen> | webben: HTML5 is being implemented piecemeal |
| 22:29 | <Lachy> | again, mobiles are attempting it and failing miserably |
| 22:30 | <webben> | hsivonen: well sure, but one could build profiles piecemeal too |
| 22:30 | <hsivonen> | webben: which is a bit of a problem for the usefulness of conformace checking against the full spec |
| 22:30 | <othermaciej> | it would be good to have an agreement among implementors for something to target |
| 22:30 | <othermaciej> | right now there is a super vague rough almost-consensus |
| 22:31 | <webben> | it would be interesting to have actual targets set (e.g. (say) implement a given CSS3 module by date X) |
| 22:31 | <webben> | perhaps |
| 22:31 | bewest | would be shocked to see MS agree to such a thing |
| 22:31 | <webben> | agreed by at least the major non-IE browsers |
| 22:31 | <webben> | bewest: MS is a special case. |
| 22:31 | <Lachy> | I'd like to see all browsers ship <video> support within 12 to 18 months |
| 22:31 | <bewest> | yes |
| 22:32 | <bewest> | the market distribution would have to change |
| 22:32 | <hsivonen> | othermaciej: it would certainly be nice for authors to have Opera, Apple and Mozilla implement the features roughly in the same order instead of each vendor implementing different pieces during the transitional period |
| 22:32 | <othermaciej> | it would be nice to see a complete and correct implementation of CSS 2.1 |
| 22:32 | <othermaciej> | in even one browser, let alone all |
| 22:32 | <webben> | bewest: thinking of Outlook 2007, MS is doing okay as long as they don't go backwards ;) |
| 22:32 | <bewest> | then it seems highly impractical |
| 22:32 | <othermaciej> | hsivonen: it's not really practical for us to synch schedules, let alone priorities |
| 22:32 | <Lachy> | webben, what? Outlook 2007 is backwards |
| 22:32 | <webben> | othermaciej: that's less important actually than implementing the same things |
| 22:32 | <webben> | Lachy: that's what i mean |
| 22:33 | <Lachy> | oh, ok |
| 22:33 | <hsivonen> | I don't disagree about what would be nice, I just don't believe Hixie could enforce requirements on vendor schedules and priorities |
| 22:33 | <bewest> | sure |
| 22:33 | <webben> | othermaciej: e.g. at the end of the day, more helpful to ordinary authors to implement a common subset of CSS than to implement different subsets in pursuit of complete implementation |
| 22:33 | <othermaciej> | we do talk to each other |
| 22:33 | <Lachy> | I don't think it would be worth enforcing in a spec either |
| 22:33 | <othermaciej> | but we are also competitors to some extent and don't have identical goals |
| 22:33 | <bewest> | we == (vendors - MS)? |
| 22:33 | <webben> | othermaciej: sure. But anything like this would have to work through areas of consensus. |
| 22:34 | <othermaciej> | of course any feature that becomes popular will more likely see rapid implementation in other browsers |
| 22:34 | <webben> | (hopefully stuff like CSS, PNG, XBL support is an area of consensus) |
| 22:34 | <bewest> | I suppose you could come up with some kind of consumer group that rates things, much like consumer reports |
| 22:34 | <bewest> | and they could enforce timelines for a particular kind of rating |
| 22:34 | <othermaciej> | well, afaik no browser has complete/correct CSS 2.1, even though that is the rough consensus target for CSS |
| 22:35 | <othermaciej> | PNG is generally agreed, but there are details |
| 22:35 | <Lachy> | if, e.g. WF2 was implemented in FF, it would start taking off |
| 22:35 | <bewest> | but that's completely different from a standards body doing such a thing |
| 22:35 | <othermaciej> | for instance, only Safari respects embedded color profiles in PNGs |
| 22:35 | <webben> | maybe ... SVG and MathML aren't exactly taking off and they're implemented in FF (and XForms too with an addon) |
| 22:35 | <webben> | (admittedly the MathML implementation is presentational) |
| 22:36 | <Lachy> | SVG and MathML can't really be used in HTML and aren't backwards compatible with IE |
| 22:36 | <hsivonen> | othermaciej: my vanity feed suggests that PNG color management in Safari causes confusion :-/ |
| 22:36 | <Lachy> | WF2 was designed with back compat in mind |
| 22:36 | <othermaciej> | SVG is seeing implementation in other browsers |
| 22:36 | <webben> | Lachy: I suspect a decent JS implementation of WF2 is much more important than FF support. |
| 22:36 | <webben> | all authors need is a plugin toolkit a la scriptalicious or something |
| 22:37 | <webben> | because that's what will be needed for IE |
| 22:37 | <Lachy> | yeah, unfortunately, the current WF2 script is horrible |
| 22:37 | <othermaciej> | hsivonen: part of the problem is that we don't do colormatching for untagged images |
| 22:37 | <Lachy> | anyway, I gotta go |
| 22:37 | <Lachy> | cya |
| 22:37 | <hsivonen> | othermaciej: actually, not doing color management for untagged images is the Right Thing. people were more upset pre-Tiger, when you did |
| 22:39 | <othermaciej> | hsivonen: colormatching for everything would be good |
| 22:39 | <hsivonen> | othermaciej: shipping OS X with 2.2 gamma default would be a far easier fix |
| 22:39 | <othermaciej> | hsivonen: we don't do it for untagged images in part because we can't get plugin changes to match |
| 22:39 | <othermaciej> | hsivonen: well that's out of my hands |
| 22:40 | <othermaciej> | anyway, colormatching, whoo hoo |
| 22:41 | <hsivonen> | othermaciej: I don't object to all-encompassing opt-in color management |
| 22:41 | <othermaciej> | just an example of how listing something you support doesn't give very strong guarantees |
| 22:45 | <webben> | but a consensus group could articulate whether to support stuff like color management |
| 22:45 | <webben> | perhaps such things actually work better separately from the specs |
| 22:45 | <webben> | since in practice browser makers pick and choose what to implement any how |
| 22:46 | <hsivonen> | I had one very confrontational situation at WWDC 2005 and it was with the prepress guy who seriously dislike me voicing my opinion about color management default in WebKit |
| 22:46 | <othermaciej> | color management is a quality-of-implementation issue |
| 22:46 | <webben> | why not push for implementation of color management elsewhere? |
| 22:46 | <othermaciej> | so it's not clear agreement is necessary or good |
| 22:47 | <webben> | or is safari's implementation broken in some way? |
| 22:47 | <othermaciej> | it would be like agreeing exactly how to rasterize text |
| 22:47 | <webben> | (don't know much about the details of PNG so I don't really know what the issue is) |
| 22:47 | <hsivonen> | othermaciej: my point was that color consistency within a page is more important than color managing a piece of the page |
| 22:47 | <othermaciej> | windows doesn't really have good color management APIs, so it would be hard to do there |
| 22:47 | <hsivonen> | in general to be safe, that is. |
| 22:47 | <webben> | how does photoshop do it on win then? |
| 22:47 | <othermaciej> | hsivonen: that's why we don't do colormatching for untagged images (well, that and the perf hit) |
| 22:48 | <othermaciej> | but for a tagged image, it's likely to look terrible if you do no colormatching, and it is assumed the author has expressed a preference for color "correctness" over consistency |
| 22:51 | <jacobolus> | hsivonen: untagged images should be assumed to be sRGB |
| 22:52 | <jacobolus> | hsivonen: that's the spec, and would create the least problems |
| 22:52 | <hsivonen> | jacobolus: nope |
| 22:52 | <hsivonen> | jacobolus: untagged images should be assumed to be in the same color space as CSS colors |
| 22:52 | <jacobolus> | hsivonen: yes, that's right |
| 22:52 | <jacobolus> | css colors are sRGB |
| 22:52 | <jacobolus> | or should be |
| 22:53 | <jacobolus> | that's the spec |
| 22:54 | <hsivonen> | jacobolus: the reality is that in most implementations, by default, CSS colors are in the system color space |
| 22:54 | <jacobolus> | hsivonen: yes, which means on a mac everything looks different than it looks everywhere else |
| 22:54 | <jacobolus> | because in most systems, system color space ~= sRGB |
| 22:54 | <hsivonen> | jacobolus: people write all sorts of things in specs |
| 22:55 | <jacobolus> | okay, but this one is actually a good idea |
| 22:55 | <hsivonen> | jacobolus: see shipping OS X with 2.2 gamma above |
| 22:55 | <jacobolus> | hmm, well that just makes every interface designed for 1.8 gamma overnight look crappy |
| 22:55 | <hsivonen> | jacobolus: the Mac 1.8 default seriously is not worth the grief |
| 22:56 | <jacobolus> | what you mean is, the lack of color management in web browsers isn't worth it |
| 22:56 | <jacobolus> | hsivonen: esp. in 2-3 years this will be a huge problem |
| 22:56 | <hsivonen> | jacobolus: no. |
| 22:56 | <jacobolus> | display gamuts, white points, etc. will diverge |
| 22:56 | <jacobolus> | quality can exceed sRGB, etc. |
| 22:56 | <hsivonen> | what I am saying is pretty much in http://hsivonen.iki.fi/png-gamma/ |
| 22:57 | <jacobolus> | hsivonen: the only good (IMO) reason hyatt gave me for not color managing css colors was that flash would break |
| 22:57 | <hsivonen> | jacobolus: moreover, aligning the Mac system color space with the world that we cannot change would be practical |
| 22:57 | <jacobolus> | hsivonen: okay, but not everyone in the future is going to be sRGB |
| 22:57 | <jacobolus> | hsivonen: take for instance the One Laptop Per Child machines |
| 22:57 | <hsivonen> | jacobolus: sRGB is bullshit |
| 22:58 | <jacobolus> | their screens aren't even close to sRGB |
| 22:58 | <hsivonen> | jacobolus: but 2.2 gamma is reality everywhere except in Apple's niche |
| 22:58 | <jacobolus> | argh. you aren't getting it. the gamma issue is not the problem. the lack of color management is the problem |
| 22:58 | <hsivonen> | jacobolus: I don't object to color management. I object to gratuitously different baseline |
| 22:58 | <jacobolus> | it's not gratuitous |
| 22:59 | <jacobolus> | print designers have been using it for 20 years |
| 22:59 | <hsivonen> | jacobolus: you sound like the prepress guy at WWDC 2005 :-) |
| 22:59 | <jacobolus> | i'm not a prepress guy, but I can see where they're coming from |
| 22:59 | <jacobolus> | anyway, at the point where you have color management, it *really* doesn't matter whether it's 1.8 or 2.2 |
| 22:59 | <hsivonen> | jacobolus: color management in every trivial app is a nice pie in the sky |
| 23:00 | <jacobolus> | hmm/ |
| 23:00 | <jacobolus> | ? |
| 23:00 | <hsivonen> | jacobolus: but if you have uncalibrated hardware, color management is garbage in, garbage out |
| 23:00 | <jacobolus> | color management is pretty much a reality in 99% of where it matters on the mac, *except* the web |
| 23:00 | <jacobolus> | whatever. it's still better than assuming all hardware has the same characteristics |
| 23:00 | <hsivonen> | jacobolus: making OS X default to 2.2 gamma would remove the gratuitous incompatibility for the best benefit per cost |
| 23:01 | <jacobolus> | well, the cost would be every app has to completely redesign its interface |
| 23:01 | <jacobolus> | and the benefit would be almost nothing, except for letting browsers not worry about color management |
| 23:01 | <hsivonen> | jacobolus: not even close on the Mac. I have my parents run their Macs at 2.2 gamma to make Windows-oriented camera and print workflows work right |
| 23:02 | <jacobolus> | windows-oriented camera/print workflows work just fine |
| 23:02 | <jacobolus> | OS X image frameworks take embedded profiles into account |
| 23:02 | <hsivonen> | jacobolus: I run at 1.8 to avoid double darkening when watching West Wing |
| 23:02 | <jacobolus> | so if your camera stores images in sRGB, everything just works |
| 23:02 | <jacobolus> | watching west wing? |
| 23:02 | jacobolus | shrugs |
| 23:03 | <hsivonen> | the old TV app sucked and didn't take the display profile into account |
| 23:03 | <hsivonen> | (I should checke if my new TV software suffers from the same bogosity) |
| 23:03 | <hsivonen> | jacobolus: West Wing has dark colors |
| 23:03 | <hsivonen> | jacobolus: and the TV app hard-coded gamma correction with 1.8 display target |
| 23:06 | <hsivonen> | jacobolus: and it is pointless to say that color managed workflows with devices designed to interoperate with Windows PCs work, when I can see that they work better with 2.2 gamma without color management than with 1.8 gamma and color management on |
| 23:11 | <hsivonen> | hendry: congrats on Debian bug #413926. |
| 23:15 | <jacobolus> | hsivonen: dunno. i have no color-management issues on my mac with 1.8 gamma ;) |
| 23:16 | <jacobolus> | hsivonen: either way though, browsers should do color management of css colors |
| 23:17 | <jacobolus> | right now, css colors look wildly different than their intent when moving from one display to another |
| 23:18 | <othermaciej> | I so didn't want to raise this discussion topic |
| 23:18 | <jacobolus> | i'm not really a 1.8 gamma partisan: I don't much care what gamma the display has beyond using the gamma that application designers were targeting :) |
| 23:18 | <hendry> | hsivonen: thanks |
| 23:18 | <jacobolus> | othermaciej: sorry |
| 23:18 | <hsivonen> | othermaciej: sorry, too |
| 23:18 | <hendry> | hsivonen: you see http://webconverger.com/about/ ? :) |
| 23:19 | <hendry> | my dad bought a Macbook today. I am trying to figure out where the terminal is... any recommended Mac resources to get started? |
| 23:19 | <jacobolus> | othermaciej: who can i talk to at macrodobe to get them moving? |
| 23:19 | <hsivonen> | hendry: hadn't seen it before |
| 23:19 | <jacobolus> | i'm happy to go pester them instead of webkit guys :) |
| 23:20 | <jacobolus> | hendry: the terminal is in /applications/utilities/ |
| 23:20 | <hendry> | i see no applications : |
| 23:20 | <jacobolus> | hendry: umm. it should be in the root of the boot volume |
| 23:21 | <hsivonen> | hendry: /Applications/Utilities |
| 23:21 | <jacobolus> | isn't that what I just said? :) |
| 23:21 | <hendry> | oh yes! found it |
| 23:22 | <hsivonen> | jacobolus: you said it in lower case |
| 23:22 | <jacobolus> | well hfs+ is usually case-insensitive |
| 23:22 | <jacobolus> | ;) |
| 23:22 | <hendry> | hsivonen: i was wondering is there was a way of decorating the table column in CSS in http://webconverger.com/about |
| 23:24 | <hsivonen> | hendry: are you familiar with http://ln.hixie.ch/?count=1&start=1070385285 ? |
| 23:24 | <hendry> | i still have not figured out how right click works with the track pad. I am also amazed it can't recognise my external USB fat32 hard drives. |
| 23:24 | <jacobolus> | webben: photoshop does color management by assuming untagged images are in the "working space", which could be sRGB or Adobe RGB (though you can decide how it should treat them, or get a prompt when opening untagged images if you want) |
| 23:25 | <jacobolus> | hendry: put 2 fingers on the trackpad, and click the button |
| 23:25 | <hendry> | hsivonen: ah, tahnks for than |
| 23:25 | <jacobolus> | hendry: or do ⌃ + click |
| 23:26 | <hendry> | two fingers thing doesn't work me |
| 23:27 | <hendry> | what the hell is "⌃"? |
| 23:27 | <hsivonen> | hendry: ctrl |
| 23:27 | <hendry> | anyway, is there some apple support channel out there? |
| 23:27 | <hendry> | hsivonen: thanks again |
| 23:27 | <jacobolus> | hendry: ⌃ == ctrl |
| 23:28 | <jacobolus> | hmm, dunno about mac support channels. i just ask mac support questions in ##textmate ;) |
| 23:30 | <hendry> | hey, can we try ichat? though... do I really have to sign up for a .Mac account? |
| 23:30 | <jacobolus> | no, it is AIM |
| 23:30 | <kingryan> | it does jabber, too |
| 23:30 | <jacobolus> | and can also work with jabber (so probably google talk?) |
| 23:32 | <hsivonen> | jacobolus: google's jabber server: yes. audio interop: no |
| 23:33 | <jacobolus> | hendry: this might be useful: http://arswiki.info/wiki/index.php/Main_Page |
| 23:38 | <hendry> | my id is kai.hendry⊙gc if you'll like to try ichat |
| 23:40 | <hendry> | jacobolus: thanks for the link |
| 23:41 | <jacobolus> | hey, is there any distinction between "0" and "0px" in css? |
| 23:42 | <webben> | hendry: sure there's #mac for one |
| 23:43 | <jacobolus> | like is margin:0; ever different from margin:0em; or margin:0px; |
| 23:43 | <webben> | jacobolus: better to address such Qs to #css but the answer is no, and 0 is the preferred syntax |
| 23:44 | <webben> | 0em and 0ex and 0px being superfluous units |
| 23:44 | <jacobolus> | sorry, i'll duck out of here now :) thanks all for the earlier answers about <a> blocks :) |